Arrow768

At the moment I am not in favor of adding more songs to the game, as this causes a increase in the resources that a player needs to download before they can join (and we are already at 97MB)

A random chance for malfunction isn't really something that contributes to the gameplay as noone enjoys if their rig (or something else) fails randomly because rng decided it should. (See pre-buff rd weapons) In addition a traitor should use the tools they have available to fulfill their tasks. If we add something that allows to bypass the rig restrictions we enable a common theme where a traitor just purchases the rig-unlock-tool and a rig-gun to slap on their rig. (We had that for a while and I am glad we got rid of it; by adding these restrictions) It is also not impossible to acquire a weapon capable rig as a person that needs to go eva, it just requires them to interact with (convince, threaten, bribe,...) certain people that can provide those rigs. But ultimately this point is moot as the PR is awaiting merge.

Not a fan of that as those are (intended) physical limitations of the rig design, which isn't something that can by bypassed by modifying the software (emag) or installing some sort of upgrade. (Much the same way you can't just slap a tank turret on a car/snowmobile/caravan and expect it to work properly).

This area of the forum is used if you If you disagree with the staff member you need to make a staff complaint.

Disagree heavily. The self destruct is a weapon of last resort and can only be used once. Therefore I see no issue if it causes severe damage and does not have a warning duration. In addition the "other antags with simmilar equipment"-part opens up the door to add a delay to all explosives as simmilar things can be achieved by using a deadman switch and any sufficiently potent explosive. Therefore voting for dismissal.

I'll work on that when I have a bit more time.

I do have to clarify something. Most of the stuff thrown from the asteroid ends up somewhere back on the asteroid due to the gravity field. (Which is consistently represented in the game via a number of mechanics) So just because you threw a body into space from the asteroid, does not mean that it's unrecoverable.

Moving to completed as that bug has been fixed with https://github.com/Aurorastation/Aurora.3/pull/7982

I believe that is a good idea, as long as there is still the option to escalate it to ccia on the recommendation of command (i.e. for repeated instances of problematic behavior or cases of extreme stupidity).

You should be able to implement quite a few of those things using integrated electronics by coupling it with a signaller. However I also understand the appeal of having them in the uplink.

I would like to note, that our forum rules include these two points:

I have severe concerns that this just ends up like that most of the time:

The thing is, a lot of events don't "add" anything to the round directly. However they contribute to the atmosphere of the game and add a certain amount of unpredictability to the rounds. I would approve of a way that allows engineering to prevent this event, however I do not support the removal.

Seconding the dismissal for the reasons stated above

Seconding the vote for dismissal for the above stated reasons

Sorry, for the time it took to get back to that topic. Ultimately DM knowledge is not the only deciding factor in a developer application. Another important factor is "social compatibility" with the current team and the willingness to learn. Therefore we are willing to accept people who might not have "great" knowledge of DM if they show the willingness to learn and the development team (as a whole) is willing to work with them. In addition we (the headdevs) generally assign projects to people that allow them to learn various aspects of our codebase. That has happened with drago during and after her developer trial and she has shown a good improvement in her DM skills since then. Regarding the reviews: All pull requests (with the exception of bugfixes) require at least two Reviews and have a waiting period of 3 days. This ensures that more than one person reviews a PR and catches potential issues with the code and the reviews. This system applies to both developer and contributor PRs. Once a PR is in "awaiting merge" maintainer is needed to merge a pull request. The only difference between developer and contributor reviews is that at least one approving developer review is required for a PR to reach the "awaiting merge" state. In addition, if you have any concerns with a review given, you can contact the reviewer and/or the maintainers to clear up any questions you might have regarding it / correct it if needed. (One example, where she gave a review which she later amended is not sufficient to warrant a removal from the dev team) After a discussion with the rest of the development team, we do not see sufficient reason to remove her from the development team at this time. I would also like to note a few things: A staff complaint is not exactly appropriate to address concerns you might have about the performance of a staff member. "For complaints against members of the staff team. Disagree with a judgement? Conduct? An action they've done? Post it here." If you have issues with a decision they made or their conduct in their capacity as a developer, then a staff complaint would be appropriate. For other cases it would be better to inform a headev/maintainer We (headdevs) are aware of the difference in skill and activity between the developers. I care very little about the concerns "people you have talked to" have regarding the performance of someone on the development team. If they wish to express those concerns, they can approach a headdev/maintainer. We do not prevent or punish anyone, including developers, from creating PRs that are controversial or not fully thought out. We make use of draft PRs and the WIP flag (although the WIP flag should at some point be abandoned in favor of the draft PRs) In the worst case the PR is closed without being merged and the creator of the PR wasted their time on it. The only thing that would currently get you a repo ban is using github features in bad faith (which only happened 3 times so far, with two bans lifted) Unless there are further comments I´ll close that complaint in 24h

Actually, looking at it closer, the overall design is much less resistant against intruders than the current design. The shield generators are gone from the core entrance The turret is gone from the core entrance (instead the entrance is only partially covered) The walls to the outside are thinner (and can be breached faster) The back entrance to the AI core is way too easy to breach now, as there isnt even an r-wall that need to be breached to get into the core You have a lot of space around the elevator making it much easier to mount a offensive and setup triage/staging areas right down at the AI core. This seems more like a nerf disguised as a buff than a actual improvement.

The window into the bunker is a nogo, as that is a very severe weakspot. Readd the double r-walls to the bunker.

So to sum up the complaint: You don't think Drwago is good enough to be a developer on the staff team? @Kaed

I do not appreciate being quoted out of context. The quote that was posted refers to a alleged claim "that its not possible to speed up the spawn menu by using vuejs because it is using browse()" In addition, I do not see how Lohikar is involved in this.

Voting for dismissal for the reason mentioned above. If something should be done its a reduction of the number of fuel tanks around.

Seconding the vote for dismissal. We are a HRP server, so you should always roleplay the same way, no matter if there is a antag or not.

I disagree with the way the PR is implemented. Imho it is sufficient to just remove it from the secret rotation. If the intent is to fully remove it, then it should be fully removed from the code aswell, as (due to the magic of git) the code can always be looked up in the future.

I disagree with the way the PR is implemented. Imho it is sufficient to just remove it from the secret rotation. If the intent is to fully remove it, then it should be fully removed from the code aswell, as (due to the magic of git) the code can always be looked up in the future.

No, not until the new PR has been merged and live for a while.