Jump to content

SpaceTimeNow

Members
  • Posts

    400
  • Joined

  • Last visited

Everything posted by SpaceTimeNow

  1. I am so confused right now, doesn't it bother them having a non functional atmos-system? If only i would have known what it meant when there was this conversion to Linda going on. I honestly don't understand how that PR went through, we practically downgraded the sort of working-ish atmos-system we had to something that was fundamentally flawed and basicly proven not to work.
  2. All i know is that every 2 seconds it processes tiles that have a higher or lower pressure than the neighbouring tiles and tries to equalize with those tiles. Which makes pressure literally jump from one tile to the next and so on. So it spreads or sucks from the point where gas is introduced (vent) or sucked (space, scrubber). Theoretically a good idea, but in practice atmospheric changes are happening in slowmotion while the rest of the game is running with normal speed. Even in those tiny airlock systems at the singularity we had to add a additional vent because LINDA is to slow and it became annoying to wait inside those airlocks. For Linda to work it would have to calculate pressure like a several times a second and not once every two seconds. Which would probably kill the server performance, so we are now stuck with slowmotion atmospherics. This is so sad because the atmospheric simulation we had before was probably the coolest part of SS13. The first time I opened a airlock to space and were instantly sucked outside while the rooms equipment was shooting towards me and air alarm was going off, I instantly fell in love with this very special game. All we have left now are space winds
  3. Do we really need to roll everything back, wouldn't it be easier to make LINDA calculate bigger areas as it would be one tile. Sort of like ZAS did it but maybe with some limitation, so it does not calculate an entire hallways as one. Currently Linda seems terribly inefficient because gas has to literally travel from tile to tile which makes it so much slower resolving a atmos situation. Which probably is a performance issue in itself, Linda cannot in a resonable amount of time vent an area to space. Every frigging breach that happens will slow down the server and that will stack up over a entire round making the server slower and slower because it has to resolve all this atmos situations which it is dragging along. And the crew no longer really cares about some of the remote breaches because they don't bother anyone. Which will increase the amount of unresolved breaches. And the worst part of Linda is that impacting gameplay dramaticly.
  4. Why not just take the pAI from the hardsuit when you killed someone? The pAI will scream either way, if it's inside some slot on the hardsuit or the in your targets pockets, you have to deal with it either way. Obviously the pAI should not be able to instantly assume control if someone dies.. Don't see this as a big issue at all.
  5. As I said, I have only seen this floating admin text once and i honestly assumed it was a thing that was there but not used. If that was a false perception than that is fine with me. I just thought, why not have this for other occasions. Whatever the case, it does not make sense for me to argue for a tool only to be used for administration, if the admins seem to be against this.
  6. To make this perfectly clear, i am suggesting visual indication for rule enforcing and damage control (repairs). I don't want to force everything that a admin does to have a visual effect, it should be optional to drop a indication of divine intervention in cases of rule enforements (OOC stuff). I have no intention to create a tool to judge admins, neither do i want it to have effects on how events are created or controled. A Admin rejuv a grief victim is reversing something that should not have happened and it should have the least IC implications as possible. In order to have low IC implications I think there needs to be a obvious tell "This was done by a admin, you can ignore it and move along". A admin answering a prayer and heal someone (a bad example, but just go with it) should have IC implications, people should be asking themself why did that happen. Being forced to ahelp "Did this guy just got rejuved by you?" is the biggest immersion breaker of all, because i can't just ignore it and move on, i have to leave RP and pm a admin and wait for a response until i know how my character should proceed. Neither do i know what do to when the person in question just starts runnning off before i get clarification by a admin. Do i have reason to chase behind him or do i go back to minding my own business? I do agree, gibbing should never be used as a tool rule enforments. And obviously the "admin is doing this" tells should not stay indefinite for the rest of the round.
  7. It already stumps RP if the person is just falling on the floor and the moment you try to restrain him you are getting told to back off via admin pm. There are quite a few reason why someone could just fall over, sleep toxin, pain, stuff like that. If everyone just sees a visual indication, that the person is being held by an admin, you actually have a better chance to keep in character than if you are not sure what you are allowed to do. If i know there are lings on the station it's quite the tell and confusing to see someone going from crit to perfect condition in a matter of seconds. I have no problem accepting it as a miracale, but why not make some holy light appear, some fitting sound and make it a proper miracale. Rejuv is OOC and for it to have IC implications is wrong in my opinion. I have to agree that admin repairs are very rare and of course space turning into grass is extremly obvious. This part i mostly added for consitency.
  8. A topic that kinda bugs me for a long time. I am not sure but i think i saw some admin text floating above a person a few days ago. Not sure if that was a less used feature, a bug or whatever. Anyways we should have something like that and use it consistently, it should be made obvious if and when a admin is "interfering" with the game, like stunning someone or rejuvenating someone. For example a target that is stunned should automaticly get a admin text above it and a rejuvenating spell should have a very obvious and unique visual effect. If a admin destroys a body it should not just gib and leave a giant crime scene... If a admin is enforcing a rule or repairing damage then this is strictly a OOC action and should be made blatantly obvious as one. Not saying admin shouldn't have the ability to do something unoticed, but the default should be a visual thing.
  9. Nah, i think we are already well saturated wtih people trying to grief every chance they get.
  10. It's very inefficient just to let a good idea getting buried, just because nobody has time, or is willing or able to do it right now. If we would have a list of good or accepted ideas that would be really helpful helpful for everyone, even if this ideas happen far down the road (or never). And honestly i think it's quite rude just to let peoples work disappear unresolved into nothingness. Just mark them as useless and remove them from the list. Then everyone knows this idea will not happen.
  11. I think it's very confusing now that we now have so many places where suggestions are discussed: - The Suggestions forum - Code Discussion (Used like Suggestions forum 2) - Github Issues (This should only be for 100% Bugs, everything else should be closed) - Github Pull Requests (Here should be no more discussion as to why something is beeing done, that's what the suggestions are for) Sadly the actual Suggestions Forum is the place where topics go to die. Most topics will be buried somewhere below page 2 and just die out, warmed up with a new topic a few month later and die again. The Github pull request system is 10 times better, every pull request will get a definate yes or no before it dissapears. Not saying we should do everything thing in pull requests, but we need ONE similar system for suggestions.
  12. Changing records via the HUDs is very convenient and removing this option would only result in security records not beeing used at all, but it would be really useful if it's automagicly loged who changed the arrest status. I don't think it's to unrealistic to have to swipe your ID once on your headset in order to transfer the access to your secHUD and gain the abillity to change records. It would finally explain why a secHUD has access to the write record database. Stolen and activated headset could still access the sec recrods, but it would stop people from literally printing security access out of thin air via a protolathe.
  13. Not sure if i understand, but i don't think you can just display a "healthbar" in the chatbox. While i would appriciate such elaborate changes, i don't think it's really necessary. Nicely formatted and shortened text with maybe some highlighting would already be sufficient.
  14. Lockboxes can be deconstructed and you gain the same research as you would with the item that is locked inside the lockbox. This issue was already adressed when the lockboxes for firearms were implemented.
  15. @Fox McCloud I think all of this boils down to the folowing question: "Does it make sense that a SecHUDs and MedHUDs can change records without the coresponding access on the ID-Card?" There is no other way to change this records, except from a Security or Medical terminal with the proper access on the ID. All other access to this records is read only like pAIs programms, PDA cartridges. Wouldn't it make sense that you at least have to swipe your ID once on your SecHUD in order for the SecHUD to have wirte access to the Security records?
  16. Just because the fun of it. It just seems so fitting for this topic and sometimes a screenshot says more then 1000 words. Even if the screenshot contains less then 1000 words, which is really weird. The key must be in the delivery of those words. Of course the person inside the Mech (marked blue) is a Roboticist and the person with the ION rifle is the Warden. Sure enough the roboticist was not revealed as traitor.
  17. This is and has always been the way laws work, its why traitor AI boards work and its why ion laws work, it will not be changed. Pretty sure this server started of with laws beeing equally important, and i am sure this was also true at the time most lawsets were created (which was even before this server came to be). Baystation is still running the rule of all laws beein equally important unless otherwise specified within the laws. The fact that certain laws needed to state that law 2 is more important than 1 was because by default all laws were equally important.
  18. Creating a new type of camera is hardly changing the entire system.
  19. Given how most of the crew are mental cases, I think psychological harm from being locked trumps "lock all doors for lulz". I think this is too far fetched and a excuse people come up with because they have to somehow be a useful AI while beeing running a ridiculously useless lawset for what they are supposed to do. Edit: NT default is a much better version of crewsimov, and NT default is a believable ruleset that NT would run. Everything else should be purely situational at the discretion of the Head of Staff or the Centcom. Additionally we should get rid of the rule that Laws are to be followed in order, that's not how they were designed in the first place. We just forced that rule onto existing rulesets and messing up their meaning. If one rule is more important than another, then it's stated in the laws already.
  20. The amount if crap you have to deal with when playing security is crazy. The fact that we keep screwing security over with things like this, only results in security continuing beeing one of the least played jobs on the station. Which in turn results in very poor performance of security, because all experienced players will sooner or later realise that playing security is a massive pain in the ass and not worth sinking your time in. All we are left with are a bunch of new / inexperienced players that don't have proper guidance and thus we create shitcurity as it currently exists.
  21. The crewsimov lawset in it's current form is not the right default lawset for an AI. If players would actually honor their laws, a AI with crewsimov would have to everything it is told unless it would be obvious that it would hurt a crewmember. It would have to open almost every airlock, mess whit every equipment it is told to. A civilian could literally tell the AI to bolt every airlock on the station and the AI would have to obey. Since all rooms have life support there is no reason why this order would harm anyone (law 1) if he would be locked inside a room for an hour. It would be inconvinient, but not dangerous. Crewsimov fails to acknowledge any sort of command structure, which makes it basicly useless for NT.
  22. The fact that this has not been implemented is very confusing to me. At this point i can't even remember when have last seen a combat mech built in robotics to end up as a tool for security. The only instance one is built, is if the robtocist is building it for him or herself or a friend. At best the combat mechs are useless and at worst they are used to grief, or borderline grief where you are just annoying enough for the entire security having to chase you around.
  23. Way to be a role model for other players.
  24. Even though discussions about medical stuff can be interessting, but please don't derail this topic with discussions of how or how not to treat that person. My point is not that it is impossible to figure out what happend to the person, but the display of those information is necessary complicated and confusing.
  25. Dont say that and proceed to go off topic :V If fail to see how i am beeing off topic. I am explaining that we should expand on this feature that cameras can break, which i thought would imply that we should not remove this feature. Removing this feature probably the same level of coding difficulty than adding a sub class like "Adv. Security Cameras" which cannot break randomly. This cameras could be simply mapped in instead of the exisiting ones. A different sprite would be cool but i don't see this as a must have. So i say we should rather fix the immediate issues instead of just removing this feature altogether and i hope we can expand on this feture in the future. I don't really care where those cameras are used as long as long as they are rare enough. I used the AI core as an example because there it has much bigger implications that just beeing unable to see what's going on in the room.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Terms of Use