Command (*,***) (Triggers) (Read 8553 times)

Started by Just No Point, September 13, 2015, 01:15:02 AM
Share this topic:
Command (*,***) (Triggers)
#1  September 13, 2015, 01:15:02 AM
  • ******
Triggers if the user has input the specified command.

Command [oper] "command_name"
=, != (other operators not valid)
"command_name" (string)
Name of the command. Commands are defined in the player's CMD file, and are case-sensitive. If the CMD has multiple commands with the same name, then any one of those commands will work. Command names must appear within double quotes.
Return type:
boolean int (1 or 0)
Error conditions:

trigger1 = Command = "fireball motion"
  True if the user inputs the command corresponding to the
  command name "fireball motion".
Last Edit: September 18, 2015, 02:46:53 PM by Just No Point
Re: Command (*,***) (Triggers)
#2  September 15, 2015, 09:15:51 PM
  • *****
  • Gaps? Where we're going, we don't need gaps...
    • USA
It should be worth noting that if using a redirect on the Command trigger, such as enemynear(0),command, will have unpredictable results. From what I understand, it has something to with the way the commands are ordered in each character's CMD file, so even if Player2 has the same command names as Player1 (i.e., "QCF+x"), having Player2 input that command will not always necessarily correspond to the same command in Player1's CMD file if the order is different. Can someone care to clarify/expand on this?
Re: Command (*,***) (Triggers)
#3  September 18, 2015, 04:15:30 AM
  • ****
  • it's me
  • Maybe something different
    • Chile
    • Skype - koakumadevil69
In order to clarify what @Ricepigeon: wants I set up the following code on KFM's CNS:

[Statedef -2]

[State 0, VarSet]
type = VarAdd
trigger1 = var(15)>0
v = 15
value = -1
[State 0, VarSet]
type = VarSet
trigger1 = enemy,command = "SmashKFUpper"
v = 15
value = 15

[state a]
type = DisplayToClipboard
trigger1 = 1
text = "command = %d"
params = var(15)
ignorehitpause = 1

Some important note about this, KFM's SmashKFUpper command is his second unique command. Why am I pointing this out? Well, I loaded a character that has "back" as a second unique command as P2, which consists of B obviously.

So, I test with P2 as is and try to input KFM's SmashKFUpper with P2 but... What the hey is this!? It's not reacting at me doing SmashKFUpper! It's reacting to the "back" command I defined earlier!!

So then after a while tapping back only to make sure that I didn't do something weird, I decided to custom state my opponent, so I sent her flying using KFM's Fast Kung Fu Palm, which sends P2 to a custom state. What gives, she doesn't react to her command "back" anymore (I did do it according to her facing BTW, so I did it correctly). And then attempted to do "SmashKFUpper", and bam, it worked.

So moral of the story:
  • P2 is custom stated: Enemy,command = "blah" will return whether P2 did your "blah" command, because he dons your command list temporarily
  • P2 is NOT custom stated: Enemy,command = "blah" will return whether the nth unique command from P2's list has been done, where n is the number of unique command "blah" on P1's list.

This seemed to have happenned against one character. But I am not sure of what results this gives to you guys. So please post if this happens as well in your end.
Re: Command (*,***) (Triggers)
#4  July 31, 2017, 04:53:42 AM
  • ******
  • You did better than good... you did gooder
    • USA
An interesting quirk that me and JustNoPoint discovered a few weeks ago (by accident): it's pretty well known that because MUGEN processes characters/helpers one at a time, there is sometimes a one-tick delay in relaying information from one character/helper to another, based on what order the former player/helper's code is executed in relation to the latter. One example of this might be something like this: when P2's time = 60, they set var(0) to 60; and P1 has a ChangeState that sends them into State 195 whenever Enemy, var(0) = 60, then P1 will be sent to State 195 one tick after P2's time = 60. This is because P1's code is executed before P2's code is, and so when P1 checks P2's var(0) on the very same tick that P2's time = 0, it won't have been set to 60 yet!

The Command trigger, however, doesn't work like this! If P2 were to input "down" on a particular tick, then P1 would be able to see that P2 has indeed input "down" on the very tick; this is also true of Helpers (if they have keyctrl = 1, of course). What is most likely happening is that ALL active players/helpers have their commands processed before their respective code is run, so there's no delay relaying that information back and forth. This might be true of a few other triggers (maybe Time? not sure what else), but neither us has done any testing.