Jump to content

Security Re-map


Recommended Posts

15 minutes ago, Dreamix said:

Why not? Because other things need to be closer to the entrance. Things that with your remap are further away. Unfortunately, we can't have everything be at the entrance, and something needs to be further away.

The brig should be optimized around the canonically most common and everyday situations - crew getting unruly and needing a fine and/or a short break to calm down in the cells. Previous brig was optimized for exactly that, with the processing rooms and the prisoner cells being right at the entrance.

We are not getting raided by mercenaries every day, to necessitate the officers being always on the ready and within arms reach of weapons. The new brig is optimized for this instead. Especially since security tends to crowd at the lobby or just outside, this will probably make for crazy fast response times, to arm up and go kill, which is not desirable.

 

I do not care about how it was on Aurora. It's irrelevant. And even if it is relevant, looking at the mapping of Aurora, it certainly should not be taken as an example of great mapping, with its huuuuuge rooms and looooong hallways.

I have to disagree. We cannot do everything with "this is how it would really be" in mind. If we applied that philosophy to how we map things or even code - Then a lot of  things would be different. 
Why would we have a crew armory when it makes more sense to have a specialized SWAT team aboard for situations that'd call for it? 
Why does security only have three cells for an entire ship filled with hundreds of people? 
Why does the engine have to be set up every single round and it isn't always running? 

We have to prioritize gameplay over actual "canon sense" when it comes to certain things. For example, allowing antags an easier way to either escape security or break into security. This remap allows for the gear to be closer to the entrance - making it easier to 1. Respond whenever there is a really big threat. 2. Steal from - due to the maintenance tunnel and exterior windows. I have prioritized gameplay over realism, which is something that has to be done with majority of decisions/contributions made on the server. 

 

Link to comment
  • Replies 63
  • Created
  • Last Reply

Top Posters In This Topic

25 minutes ago, ReadThisNamePlz said:

I have to disagree. We cannot do everything with "this is how it would really be" in mind. If we applied that philosophy to how we map things or even code - Then a lot of  things would be different. 
Why would we have a crew armory when it makes more sense to have a specialized SWAT team aboard for situations that'd call for it? 
Why does security only have three cells for an entire ship filled with hundreds of people? 
Why does the engine have to be set up every single round and it isn't always running? 

We have to prioritize gameplay over actual "canon sense" when it comes to certain things. For example, allowing antags an easier way to either escape security or break into security. This remap allows for the gear to be closer to the entrance - making it easier to 1. Respond whenever there is a really big threat. 2. Steal from - due to the maintenance tunnel and exterior windows. I have prioritized gameplay over realism, which is something that has to be done with majority of decisions/contributions made on the server. 

 

At no point I have mentioned "realism", or any "philosophy", or "this is how it would really be". Only you did mention that now.

And you also did so yesterday too, on the discord, about having SWAT instead of a crew armory, or bringing back ERT, saying that it'd make more sense ICly and OOCly and be more immersive than what we have now. So why are you saying that I want "realism"?

 

The previous brig I believe was optimized around gameplay. The "crew getting unruly and needing a fine and/or a short break to calm down in the cells" are the most common situations that crew and players experience. The merc rounds are not even guaranteed to happen once per day. And even then, making it even easier to respond to threats with guns and armor, is not a positive thing.

Antags having an easier way to escape is a noble goal, but most antags do not survive long enough to be put in the communal brig, and if they do, they are stripped of any equipment or gear, or the round is basically over anyway. Those that do not require HuT, can just wait a few minutes and get out. I had some ideas on how to rearrange the previous brig's armory, put it a bit up northward, add some maintenance there, to make escaping from the communal brig easier... but then this remap was merged, so there's little point in even making a mockup for that, is there?

And speaking of merging. Why was this not test-merged? It was speed-merged after, what, five days, which is not nearly enough to get any actual feedback from players or devs. The PR was approved by two devs who mostly do spriting (good spriting, but still), and not by devs who do mapping.

I'm not sure I have anything else to say, as we are going circular, so that's it I guess.

Edited by Dreamix
Link to comment

@Dreamix

When you said 

Quote

The brig should be optimized around the canonically most common and everyday situations 

I took this as trying to be more realistic over gameplay. Sorry. 

Regardless, I do not think we're going to get anywhere. I stand by my changes and a lot of other people are pretty happy with them too. Most being security mains. 

The merge stuff - I do not know. It was a test merge candidate. I do not know how test merges work on the technical side, but ultimately it's in the game now. I'd love to see your mock up though. If we ever do revert, maybe it'd be better. People reacted harshly to my first remapping attempt, so this is what I came up with for a round 2. 

Link to comment
13 hours ago, Dreamix said:

And speaking of merging. Why was this not test-merged? It was speed-merged after, what, five days, which is not nearly enough to get any actual feedback from players or devs.

The contributing guidelines require that a feature pr is up for two days and has two approving reviews.

That has been met, hence there was no “speed merge”. A speed merge is when a PR is merged without those requirements being met. (Which can also happen for a number of reasons)

Test merging requires that you have something that is generally “resistant” to merge conflicts. (I.e. it’s not likely to create merge conflicts if something else is merged).

With code that is generally not a concern, but mapping changes (especially larger ones) are very bad in that regard.

Link to comment

Then the PR should habe had a DNM or Maintainer discussion label, both have been applied for less in the past. Since apparently a lot of people are unhappy in general, a lot of oversights are/were present and the re-map in general was not well received there should have been a longer feedback thread or maybe the PR should have been a WIP PR instead 

Link to comment
9 minutes ago, KingOfThePing said:

Then the PR should habe had a DNM or Maintainer discussion label, both have been applied for less in the past. Since apparently a lot of people are unhappy in general, a lot of oversights are/were present and the re-map in general was not well received there should have been a longer feedback thread or maybe the PR should have been a WIP PR instead 

There are three or four people who are unhappy with these changes. It is not "A lot of people". 

There were a few oversights that I missed, which is expected from my inexperience. 

Link to comment
2 hours ago, ReadThisNamePlz said:

There are three or four people who are unhappy with these changes. It is not "A lot of people". 

That is relative. If others don't give feedback or are just indifferent then I cannot take it into account, since I cannot read people's mind. If people take their time to line out their problems here then you should take take this criticism serious, even if it is "just three or four people". 

The reality is that most either don't care or don't have a forum account or both. 

Link to comment
35 minutes ago, KingOfThePing said:

That is relative. If others don't give feedback or are just indifferent then I cannot take it into account, since I cannot read people's mind. If people take their time to line out their problems here then you should take take this criticism serious, even if it is "just three or four people". 

The reality is that most either don't care or don't have a forum account or both. 

I have taken everyone’s feedback into account. People wanted Windows? I worked on finding out a way for windows. 

People wanted the wardens office swapped? I swapped the office.

People wanted the processing cells moved? I moved them and altered the size as requested.

People wanted the Maintenance tunnel to connect to service maintenance? I made it happen.

I am currently reworking the wardens office as well, as requested. 

I listen to feedback.

Link to comment
3 hours ago, KingOfThePing said:

Then the PR should habe had a DNM or Maintainer discussion label, both have been applied for less in the past. Since apparently a lot of people are unhappy in general, a lot of oversights are/were present and the re-map in general was not well received there should have been a longer feedback thread or maybe the PR should have been a WIP PR instead 

This is incorrect, I believe, testmerges are done on code PRs, not mapping PRs to my understanding, and a search on the github onlyfinds this PR with such a label, added by a dev instead of a mantainer, and I think I also saw an admin/mantainer explaining that they aren't done on mapping PRs (though I am not finding it anymore).

My personal and only issue so far, apart from the viewing bathroom meme on D3 (but it's not something that hinders your ability to play, so kind of minimal) is the single line access to the lockers, everything else seems fine to me, and the new positioning proved itself useful already when we used the isolation cell to let the antag escape prison yesterday, so overall, it's a positive gain, I believe

Link to comment
1 hour ago, Fluffy said:

This is incorrect, I believe, testmerges are done on code PRs, not mapping PRs to my understanding, and a search on the github onlyfinds this PR with such a label, added by a dev instead of a mantainer, and I think I also saw an admin/mantainer explaining that they aren't done on mapping PRs (though I am not finding it anymore).

Never have I mentioned testmerges on my reply in any way?

Link to comment
  • 2 weeks later...
  • Gem locked this topic
Guest
This topic is now closed to further replies.

×
×
  • Create New...