Jump to content

Arrow768

Head Admins / Devs
  • Posts

    1,704
  • Joined

  • Last visited

Everything posted by Arrow768

  1. To post some answers to some questions that have been asked on discord. How is the chance calculated ? Every 3 minutes, the chance to get a ERT is increased by 1% if the station is on green or yellow, 2% if it is on blue and 3% if it is on red (10% if its on delta) This chance is added to the base chance of 10% In addition the percentage of dead people and the percentage of antagonists (amongst the living ones) is taken into account. The more antags and the more dead, the higher the chance. These values are tweakable via config and the intention is to do so once this PR is live and it is actually possible to see how it plays out
  2. https://github.com/Aurorastation/Aurora.3/pull/6012
  3. The Tajara file has been added to the uplink a while ago. As it fulfils the requirements of the OP -> moving it to completed projects
  4. Implemented in: https://github.com/Aurorastation/Aurora.3/pull/6004
  5. Implemented here: https://github.com/Aurorastation/Aurora.3/pull/6003 (The part with the balaclava for the uplink. The other stuff needs sprites. If you can get them, before the pr is merged, then send them to me and I can add another mask to the uplink)
  6. Implemented here: https://github.com/Aurorastation/Aurora.3/pull/6002
  7. I concur with what has been said. Moving the Topic to the Archive.
  8. The ERT and the TCFL have access to the same chems. Because the ERT is powerful enough without standard access to the L6 SAW. If deployed by a somewhat skilled team it has the potential to fuck over any Antag (Group Antag or not) The argument "give ERT more powerful weapons so we can reduce their spawn chance" is flawed. The 50/50 split we have at the moment is fine. Both teams have their respective advantages and disadvantages.
  9. The associated pr has been closed and the branch deleted by the author. Therefore moving it to the archive
  10. Voting for dismissal, as the raised points have not been addressed by the OP
  11. As the OP agreed with the explanation given, I am moving this to the archive.
  12. Voting for dismissal. While it is an interesting idea, it removes a lot of the consequences for doing something that is against corporate regulations. Money, at the current point is not very important and people do not really care if they loose a few 100 credits. In addition, you fail to address what to do with someone who does not have sufficient money. If the only applicable sentence that would prevent characters from returning to the shift and causing further issues (for a time) is a HuT sentence, then this sentence will have to be applied much liberally than at the moment. Security needs a way to deal with constant troublemakers that does not involve throwing them into the permabrig after the first two offenses.
  13. The abuse of bugs is already punishable according to our rules: For something to be deemed a bug there need to be two things: It has been reported on Github. It has been deemed a bug by the developers. As it is quite possible that a certain mechanic is a feature and not a bug. If that has happened and you notice someone abusing this bug ingame, then it is upon you to report it to the administration. As there is nothing new in this suggestion, I am voting for dismissal.
  14. As mentioned on GitHub, I do not see an issue with this PR as it is just temporary and alternative (cheaper) snacks are available. The price increase might get people to actually figure out why it has been increased. Therefore it will be merged once lore is ready to move forward with the event.
  15. You've "seen" that ingame? It just unlocks other, free goods, not making all the goods free. You are incorrect here. It is possible to get all vendor items for free, you just have to be more creative about it.
  16. No longer relevant with the new forum system.
  17. Has been implemented. Moving to completed
  18. No longer relevant with the upgrade of the forum system. Moving to the archive
  19. As far as I know this has been implemented
  20. Has been implemented. moving to completed projects
  21. Voting for dismissal as the raised points have not been addressed
  22. Hm, quite disappointing. This looked like a pretty interesting rework. Moving it to the archive then. Feel free to ping staff in case you want to resurrect it.
  23. Voting for dismissal, as the OP has not explained what the goal of the suggestion is.
  24. You have explained the problem, but did not tell us what you want to achieve with this suggestion.
  25. Do you have a alternative option for a "fun and intuitive" mechanic that would add impact to cloning and prevent cloning from being a quick 3 minute procedure ?
×
×
  • Create New...