set status on a target

[devakm]

The current implementation of /status works on the selected token rather than the target. It supports @self but this works very different from the way @self works for animations. This inconsistency is confusing.

Something like: /status on Stunned @target would work. I know the chat commands are older, but /status could really use a buff. Thanks!

[crnormand]

Perfect! Yes, I think we can add an @target parameter to do just that. Since this involves changing an actor's data.. only the owner or the GMs could do it. Do you ever envision a scenario where a player might want to set a status on someone else?

Or do we make the @target function "GM-only"?

P.S. I thought @self worked the same for status and animations. @self on a status command means that it will apply the status to the current "LastActor", and in animations, @self is used by "centered" animation to center it over the LastActor instead of the target. I mean, they aren't exactly the same... but. I guess I don't quite understand why it works very differently. But no worries... if we can solve the /status issue with an @target parameter, will that work? (it is how we are currently handling /hp and /fp commands).

[devakm]

Awesome! Thank you!

Your question is a really good one. I had originally imagined baking this into a script macro that would use:

GURPS.executeOTF(OtF);

The players will be executing these macros to make attacks. I don't think there would be any harm in letting a player do it since unruly players can easily be kicked or banned, and it would make things a bit more automated, but I'm not sure this is the best solution.

Rather than just blocking it, it would be better if we had a way to prompt the GM to execute it, especially since it probably requires the GM to make a "saving throw" (attribute check) for that actor first. I filed a separate issue about using: /sendmb [modifier] [OtF] @target to just create a chat message for that actor so the GM can execute the OtF.

The only problem I see with that is that the GM won't know for sure which token was the target unless /status on Stunned @target gets translated into an OtF using the actual actor/token ID, i.e. /status on Stunned @tokenID

Does that make sense? Sorry this is sounding a bit more complicated now, but not really much different than a player executing a damage roll against a target, which results in a prompt to the GM to Apply Damage. The goal of all these ideas is to make the process of executing follow-on effects work similar to the way damage to a target is handled already.

Ultimately, both of these changes would need to be implemented for it to work well, but we have to start somewhere!

Thank you for responding and thinking about how to best accomplish this. I really appreciate it.

[devakm]

P.S. I thought @self worked the same for status and animations. @self on a status command means that it will apply the status to the current "LastActor", and in animations, @self is used by "centered" animation to center it over the LastActor instead of the target. I mean, they aren't exactly the same... but. I guess I don't quite understand why it works very differently. But no worries... if we can solve the /status issue with an @target parameter, will that work? (it is how we are currently handling /hp and /fp commands).

/anim @self recognizes that the GM picks "self" by selecting a token. Using /status @self as GM results in a banner notice telling the GM that he owns multiple tokens and should use the command without @self. This makes testing and debugging more difficult than it should be. Animations in contrast just work. Commands should work roughly the same for players and GMs. I can't say for sure since I wasn't there, but it seems like /status was perhaps created much earlier with a less refined way of handling the GM development process for things.

Does that make sense?