Continuing discussion on Smart repair #9250

[MINIMAN10000]

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

Quote

It's fairly intuitive. a more harmful action requires a more harmful intent, where as a helpful action (repairing) requires a helpful intent. This is the way it's been with a lot of things in SS13. Is it a change from existing behavior? Absolutely. Has it caught me off guard a few times? Absolutely, but it is consistent with a lot of intent based behavior (and this norm is going to expand as things go forward).

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

Quote

I like the new system more. Aggressive intent was turning into mostly ‘fists only’ or block mode.

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.

Edited July 26, 2018 by MINIMAN10000
grammar

[necaladun]

18 minutes ago, MINIMAN10000 said:

When a player is trying to use a welder on a door that is already repaired they are trying to weld it shut,

Or I haven't noticed it's finished repairing, or I clicked it too many times by accident, or I'm lagging and thus kept clicking even though it was already repaired. Accidentally welding an airlock is much more annoying than doing nothing.

18 minutes ago, MINIMAN10000 said:

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.

That's a real mix of strawmanning and slippery slope. Complaining about a hypothetical situation that no one is intending to actually implement is kinda ridiculous. Just because they want to go in that direction in regards to how welders work, doesn't mean it's going to be extended to every other possible interaction. 

It would however make sense if harm intent made you punch the door, since we can damage airlocks now. It might even encourage/remind people not to stay on harm intent when walking down corridors (I can dream right?).

[MINIMAN10000]

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.

Quote

That's a real mix of strawmanning and slippery slope. Complaining about a hypothetical situation that no one is intending to actually implement is kinda ridiculous. Just because they want to go in that direction in regards to how welders work, doesn't mean it's going to be extended to every other possible interaction. 

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.

[necaladun]

You already can threaten people with a weapon btw - point at them with a weapon in hand.

Regardless, those are all situations that can be judged on their own merits and have nothing to do with door welding/repairing. How help/harm should work in other hypothetical situations doesn't effect at all how door welding/repair should be handled. 

[MINIMAN10000]

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"

[necaladun]

58 minutes ago, MINIMAN10000 said:

1. If the new action can not be performed on the intent it should fallback to the existing action

I don't agree here, especially for stuff that can be harmful like welding doors. I don't think if I can't perform repairs on a cyber limb because it's fully repaired, I should instead hit them with the welding torch/cable either. 

59 minutes ago, MINIMAN10000 said:

2. We should try to work towards logical code that is self descriptive over favoring "it's for legacy reasons"

This is really up to the people who have to maintain the codebase itself.

[MINIMAN10000]

Quote

I don't agree here, especially for stuff that can be harmful like welding doors. I don't think if I can't perform repairs on a cyber limb because it's fully repaired, I should instead hit them with the welding torch/cable either. 

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.

Quote

This is really up to the people who have to maintain the codebase itself.

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

Edited July 26, 2018 by MINIMAN10000
Quotes broke

[Renaultus]

Honestly, it all strikes me as a bit unintuitive right now. To put it this way, when you use a welder on someone,

1. If they have a robotic limb and are on help intent, you fix it or do nothing.

2. If they have a robotic limb and are on harm intent, you damage them.

But, if they have a fleshy limb, 1 and 2 are exactly the same; you always harm them regardless of stance.

This creates this weird inconsistency, where stance only matters if you THEORETICALLY could do multiple things to something with your item, even if you can't ACTUALLY do multiple things to something with an item.

The new airlocks thing is definitely consistent with how help/harm has usually worked; I'm personally not sure why it worked that way in the first place, though. Why can you bash people with a fire extinguisher on help intent?

Is it just because it's funny? Because it IS kind of hilarious.

Edited July 26, 2018 by Renaultus

[Eler00]

I disagree with the assessment that welding a door is somehow 'harmful' to the door. If anything, I'd expect 'harm' to the door to be actual damage. It is simply unintuitive, changing how things work for no good reason. Even mentorhelp didn't know how to weld a door when I asked, which shows this is causing considerable confusion in the playerbase.

Besides, airlocks are welded far more than they are repaired, IMO. If anything, airlock repairing should require something like opening the maintenance panel first.

Edited July 26, 2018 by TDS

[Threeinone]

Seems like a good optimization. I can't really see many of the downsides besides lagging games could inconvenience you for a couple seconds. Are there any more things that need to be taken into account here?

[Threeinone]

19 minutes ago, TDS said:

I'd expect 'harm' to the door to be actual damage.

Aha! so we should change the welding action to DISARM intent! Fixed!