Lohikar

I'm a bit on the fence regarding this application applocation. Pacman has shown a healthy amount of dedication to code & shows other traits positive in a developer, however, their DM leaves something to be desired. I don't think this alone is a reason to -1 this as they are showing definite improvement in regards to their skill with DM, as well as a willingness to learn and listen. Overall, I'm going with a cautious +1, but I ask that you keep working on your DM.

Please remember that suggestions posts are restricted to one suggestion per post, per board rules.

The changes required to implement this suggestion are trivial; developer time is not a concern.

Yes, it applies to all reagents minus a few that break when done this way.

You are not required to be a dev to open pull requests to the repository.

The problem with this is that right now, radios must have a frequency assigned to their 'general' mic. Right now all radios just default to this. As far as I know, it is not possible to remove the general mic from radios without changing radio code at a deeper level. The alternative that immediately comes to mind would be to randomize each headset's frequency, but I don't see why they would be randomized, ICly. I suppose the mic could just ship off, but it would be trivial for people to just turn it back on every shift and resume using common as normal.

Bay has holocalls, this is something different assuming I'm understanding the OP correctly.

Yeah, I was planning on doing this already. I have the sprites already, I just need to add them in and make them play nice with ZAS.

This is getting nerfed soon.

lighting is technically something you can see

What would an EMPed loyalty implant do? Melt the poor sod's brain?

This is an administration issue, it should not be handled in code. Voting for dismissal.

I would also like to point out that as far as I am aware, adding a new equipment slot is nearly impossible, because the number we have right now is hard-coded in. I've seen servers that have both a neck and face slot, along with a separate slot for ID and PDA, but from what I have been told, this was largely accomplished via 'really hacky code exploits'. Feel free to correct me if I'm wrong and you know otherwise. Slots can be added in the same manner that the current slots are implemented, it just would be very unpleasant and there's not likely to be a coder willing to go through the trouble of doing it correctly.

I'd reword that a touch. Those complaints were about the rewrite. My bad, post corrected.

The majority of the complaints about the rewrite of the lore were summed up in this document: https://docs.google.com/document/d/1i4yuk3oRuX6Jbi2c15ZI0RkNkHPWW--lQ1B79raS2cw CMF's response is here: https://forums.aurorastation.org/viewtopic.php?f=73&t=8288&start=10#p79671 I don't know if this actually lead to any changes however.

Also voting for dismissal, I don't see this getting fixed any time soon.

Yeah, that's too long. Would need a shortened version of it, preferably under 10,000 characters.

They were removed due to them constantly crashing clients. They're unlikely to be re-added unless someone can figure out a way to make them stable.

Removing the Assistant slot but leaving Visitor will just lead to the troublemakers joining as Visitor, as it is a default job.

Something similar to this might actually make sense considering that in-game time will deviate from real-time due to MC drift. 15% tdrift (currently only visible to server staff) -> game-time is 15% behind real-time.

We literally can't remove assistants without a bunch of refactoring due to how job code works. Assistant or some other equivalent role must be present.

Yes, another feedback thread. Whee. I would like peoples' opinions on the Bluespace Bear event; if anything should be changed about it, if it should be removed, or if it is fine as-is. The main issues with this event that I am aware of are: The event does not make much sense IC. Bears aren't much fun for people who aren't security.

Who are you?

So, there's been some discussion about pylons being overpowered and/or unbalanced, I would like to gather people's opinions on how they are at the moment before I try to address these issues. For references' sake, here are some of the stats associated with pylons as they are in master right now: View range of 9 tiles (players' view range is 7 tiles) Cannot be damaged by weapons that deal BURN damage (actually empowers the pylon) Standard pylon shots deal 3.5 BURN every ~0.5 seconds. Empowered pylon shots deal 10 BURN every ~0.5 seconds, with 10 armor penetration. Empowered pylons slowly self-repair over time. Inert pylons can be activated by sacrificing any living non-cult mob, including small mobs like mice. All living mobs can present sacrifices to pylons.

It already does this.