[State 0, Helper]
type = Helper
trigger1 = time = 0
helpertype = normal ;player
name = "Odb718's helper"
ID = 718
stateno = 187
pos = 41,-87
postype = p1 ;p2,front,back,left,right
facing = 1
keyctrl = 0
ownpal = 0
supermovetime = 0
pausemovetime = 0
;size.xscale =
;size.yscale =
;size.ground.back =
;size.ground.front =
;size.air.back =
;size.air.front =
;size.height =
;size.proj.doscale =
;size.head.pos = ,
;size.mid.pos = ,
;size.shadowoffset =
;ignorehitpause =
;persistent =
In the picture, does the stage's horizontal zoom work further out? Like was it maxed out? If it was it's acting like it has to because of the stage's definitions, not because the helper didn't work right.
Are there any other known strategies for making a character appear to have learned? The simplest I could think of was to have a character count the seconds it was defeated in and update its "random conditions" accordingly as the match unfolds.
Felicia's projectile safety check is basically checking for and error. "Did I get through the projectile with this?" "Nope, try this one." "Did that work?" "Yes." "Then keep using it.
Doesn't work for pure helper projectiles though, sadly. I may put an invisible projectile in mine that stays alive as long as the helper is just so projectile detection can work.
[State ]
type=parentvarset
trigger1=!parent,var(1)
trigger1=movehit=1
var(1)=1
[State ]
type=selfstate
trigger1=movehit=1
value=1001+(parent,var(1)=1)
[State ]
type = changestate
trigger1 = moveguarded
value = 1001
ignorehitpause=1
[State ]
type=destroyself
trigger1=ishelper
trigger1=Time>=12
[State ]
type=parentvarset
trigger1=1
var(1)=2
[State ]
type=destroyself
trigger1=ishelper
trigger1=P2MoveType!=H
[State -2, VarSet]
type = VarSet
trigger1 = P2MoveType != H
var(1) = 0
1.1b ExclusiveAlthough the remappal parameter in the Helper state controller is exclusive to 1.1, you can still use a RemapPal controller within the Helper's code in both 1.0 and 1.1.
Optional parameter:
remappal = dst_pal_grp, dst_pal_item (int, int)
Forces a palette remap of the helper's indexed-color sprites to the specified palette. This parameter is used only if ownpal_flag is non-zero. If dst_pal_grp is -1, this parameter will be ignored. Defaults to -1, 0.
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!Applying this to a Helper offers a pretty easy of fixing the reverse command bug (you would basically use the helper to process all commands, and have it always face to the right, so that the character can always know what the player's input is without the commands reversing or anything), and on the more complicated end of things, making a lag-free buffering system.
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.
triggerall = !NumHelper(*)