Jump to content


Head Admins / Devs
  • Content Count

  • Joined

  • Last visited

1 Follower

About Arrow768

  • Rank
    Head Developer

Linked Accounts

  • Byond CKey

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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).
  3. This area of the forum is used if you If you disagree with the staff member you need to make a staff complaint.
  4. 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.
  5. Arrow768

    Remove Cargonia

    I'll work on that when I have a bit more time.
  6. 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.
  7. Moving to completed as that bug has been fixed with https://github.com/Aurorastation/Aurora.3/pull/7982
  8. 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).
  9. 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.
  10. I would like to note, that our forum rules include these two points:
  11. I have severe concerns that this just ends up like that most of the time:
  12. 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.
  13. Seconding the dismissal for the reasons stated above
  14. 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
  • Create New...