MINIMAN10000

Well, as you point out the procedure is clear, if the roboticist has written consent from the person in question they are permitted to transfer personnel MMIs into cyborgs, I would agree. So yeah I'd say go ahead and give it a title and a your signature and be off to the races. I always try to keep my paperwork as small as I can make it while still getting the desired look, looking at that contract is a very good example of what I don't want from my own created paperwork. I mean seriously look at the requirements "Written consent from the person in question" that's as easy as Cyborgification Authorization [sign] grants authorization for cyborgification [br] It's pretty much the shortest list of requirements for paperwork I've seen. I used http://ps.ss13.net for their what you see is what you get pen code editor... I should use it more often that's neat

The sort of "lets just make it redundant" is the type of tedium "difficulty" that I don't like. I'm all for it being more complex in some way, just not redundant. Just spit balling so I don't shoot down an idea without anything. Maybe require a set of chemicals to be loaded into the machine so that it requires cross job coordination. I don't know of anything gameplay mechanics that depend on the body, I don't like the idea. Everything else seems good to me Related to forum discussion I'm pretty sure vaccines are isolated dead versions which your body then builds its own immunity against not to mention the tedium involved in multiples races and multiple blood types simply is a bad way of adding "challenge." I like the idea of symptom augments. Fuel as you say can multiply effectiveness during use. The idea I have is Inactive in which both the symptom and the stat modifications are inactive until a trigger flips them, for example what if nutrition caused a virus changing the required vaccine. That's the sort of challenge that interests me. It fits well with the idea of making bio hazard more complex.

People already have mixed limbs so when you're repairing someone who has robotic limbs you can still attack him with it if you don't realize that specific limb is not robotic. Thanks for bringing this up as it's a good example that helps me wrap around why the maintainers are telling me "This is expected behavior" It appears they are applying "New behavior must override old behavior" consistently. I can say that your example of not falling back to the default of a damaging action on a atom is logical. Player intent, the player is trying to heal, obviously their intent isn't to damage. However welding a door does not damage the door. Player intent, they are using a welder on a repaired door it is expected to weld the door. We shouldn't disregard usability for the sake of consistency instead case by case asking "What would a player reasonably expect" With how many times engineers ask "How do I weld a door?" We know that a player reasonably expects help intent with a welder on a door to weld the door. Ultimately nothing will ever change if you don't try to hold a discussion. learning why things are the way they are and giving why you want them changed is better than doing nothing. So far the reason why we use "W.remove_fuel(0, user)" over "W.isOn()" is because we copied and pasted remove_fuel() everywhere else but it doesn't explain why we can't switch from "W.remove_fuel(0, user)" to "W.isOn()" when we are using "W.remove_fuel(0,user)" for the purpose of checking if the welder is on

This entire discussion is about stripping away existing behavior with a new behavior on help intent and then instead of falling back to the existing behavior after the new behavior is unable to be performed. How help intents work in other hypothetical situations is being discussed because I am being told by the maintainers that if a new behavior can not be performed you should tell them the new behavior can not be performed instead of doing the existing behavior and I'm doing my best at providing examples of why we should not do that but instead do the existing behavior if the new behavior can not be performed. This whole discussion exists for the sake of community discussion on the two ideas 1. If the new action can not be performed on the intent it should fallback to the existing action 2. We should try to work towards logical code that is self descriptive over favoring "it's for legacy reasons"

Yes if you are still clicking on the door after 40 * W.toolspeed it would weld the door. However if you click to many times it does not matter because the action is assigned at the time of the click. So you can click as many times to repair a door as you want until the door is finished repairing. Yes it was a poor example but it requires more thought to come up with something that fits all the categories of has an existing behavior of a tool used on a atom, is help intent ( the default behavior ), and is extremely common. I didn't do it out of malice I did it because new mechanics with such a specific category but is the default category for the majority of players. I'll spend the next several minutes thinking of one if it'll please you. Lets say I add the ability to quick place flooring by clicking a tile while it is on the ground if the flooring is ripped up. But then strip away the ability to pick up the tile because help intent on a tile must exclusively be used for quick placing. Lets say I add the ability to get and test a blood sample with better virus detection with a medical scanner and make it so you have to switch off help intent to scan a player. Lets say I add the ability to threaten someone with any weapon and you have to switch off help intent to be able to hit them.

Intuitive gameplay and code that is logically sound is something I feel very strongly about and has been the reason I am a contributor to paradise station. #9250 made two changes 1. instead of checking if a welder is on using the function isOn() they state that using zero fuel with remove_fuel(0, user) to check if the welder is on should be preferred for legacy reasons. This is logically broken and makes no sense why would you remove zero fuel, you wouldn't, you would check if the welder is on. "We break code logic because legacy reasons" is how you end up with a messed up codebase and is not an excuse. 2. Currently the behavior works as follows. If you are in help intent and a door is damaged it is repaired. If you are in help intent and a door is not damaged nothing happens. If you are not in help intent and a door you weld the door. The change would make it as follows. If you are in help intent and a door is damaged it is repaired. If you are in help intent and a door is not damaged weld the door. If you are not in help intent you weld the door In #9250 the maintainers Crazylemon and Fox-McCloud stated that making gameplay unintuitive by providing no fallback behavior for when the intent behavior can not be performed is not only intended but the direction in which they wish to take the codebase. Where doing nothing is the preferred action instead of doing something is absolute insanity. Programmers should do everything in their power to understand player intent behind an action and try to work towards that. When a player is trying to use a welder on a door that is already repaired they are trying to weld it shut, we know this because as an engineer we are constantly asked why they can't weld a door while they are on help intent. We should always prefer to do an available action if another action is unavailable due to intent. To quote fox I'll give a hypothetical if we were to go in this direction and how silly it is. Opening a door is a more helpful intent therefore you should only be able to open a door while on helpful intent and every other intent should do nothing. Now you have to mess around with your intents because the programmers didn't provide a fallback behavior to doing nothing. Also a quote and a follow up question for Spartan 6 as the only guy who downvoted my pull request I seriously do not understand what you mean I never removed any intent you still had to be in helpful intent if you want to repair a door. The only thing I changed is making it so that you could still weld a door while in help intent. All responses I got on this topic were completely illogical and I don't understand them. Why would you use remove_fuel(0,user) to see if the welder is on when someone already created the function isOn() to check to see if the welder is on. Why would you say help intent should never be able to weld a door and you should instead have it do nothing at all.