superfromnd / iguana Goto Github PK

This is more of a memo than a proper bug report, but I wanted to leave a note to myself as for how to go about rewriting this.

Iguana's tokenization is a process where it takes a command (such as D, DF, F, a) and converts it into an internal intermediate form (to be exact, a string of characters called tokens such as 2,6,3,a). This works, but it runs into problems when combined with merge() in the case of multiple commands being assigned to the same move.

Because merge() works on a per-character basis, the result is that individual inputs get appended to eachother, and the results can look really messy.

Take, for example, this snippet from Warusaki3's CvS Juni:

[Command]
name = "アースダイレクト1"
command = ~F, D, B, U, x
time = 40

[Command]
name = "アースダイレクト1"
command = ~F, D, B, U, ~x
time = 40

[Command]
name = "アースダイレクト1"
command = ~D, B, U, F, x
time = 40

[Command]
name = "アースダイレクト1"
command = ~D, B, U, F, ~x
time = 40

[Command]
name = "アースダイレクト1"
command = ~B, U, F, D, x
time = 40

[Command]
name = "アースダイレクト1"
command = ~B, U, F, D, ~x
time = 40

[Command]
name = "アースダイレクト1"
command = ~U, F, D, B, x
time = 40

[Command]
name = "アースダイレクト1"
command = ~U, F, D, B, ~x
time = 40

[Command]
name = "アースダイレクト1"
command = ~F, U, B, D, x
time = 40

[Command]
name = "アースダイレクト1"
command = ~F, U, B, D, ~x
time = 40

[Command]
name = "アースダイレクト1"
command = ~D, F, U, B, x
time = 40

[Command]
name = "アースダイレクト1"
command = ~D, F, U, B, ~x
time = 40

[Command]
name = "アースダイレクト1"
command = ~B, D, F, U, x
time = 40

[Command]
name = "アースダイレクト1"
command = ~B, D, F, U, ~x
time = 40

[Command]
name = "アースダイレクト1"
command = ~U, B, D, F, x
time = 40

[Command]
name = "アースダイレクト1"
command = ~U, B, D, F, ~x
time = 40

; ...

[State -1, reppuken]
type = ChangeState
value = 1500
triggerall = !var(59)
triggerall = roundstate = 2
triggerall = Command = "アースダイレクト1" || Command = "アースダイレクト2" || Command = "アースダイレクト3"
; ...

All of those above アースダイレクト1 commands are variations of the 360 motion (2684 in numpad notation), and logically one would just compress all of them down to "do a circle motion then press a button". merge(), however, goes on a per-character basis, and being met with all of those variations (along with the other two sets I've removed from the above snippet) decides instead to concatenate them all together into this hilariously unweildy mess:

reppuken			_F_+_D_+_D_+_B_+_B_+_U_+_U_+_F_+_F_+_D_+_D_+_B_+_B_+_U_+_U_D_+_B_+_B_+_U_+_U_+_F_+_F_+_U_+_U_+_F_+_F_+_D_+_D_+_B_+_XBB_+_U_+_U_+_F_+_F_+_D_+_D_+_B_+_B_+_U_+_U_+_F_+_F_+_D_+_D_U_+_F_+_F_+_D_+_D_+_B_+_B_+_D_+_D_+_B_+_B_+_U_+_U_+_F_+_F^X

Clearly, this isn't ideal! The solution that IGOCLG used (and that I want to reimplement into Iguana) is to instead tokenize motions. That way, instead of combining every input, Iguana would instead combine every motion, which should result in WAY less absurd results.

I think the best way to approach this from a coding standpoint would be to use Go's strings.Split function to split at every comma, analyze each splice, build together a new string of tokens, and then check for motions before returning.

Some MUGEN characters specify multiple command inputs for a move like this:

[State -1, Multiple Moves via &&]
type = ChangeState
triggerall = command = "x" && command = "y"

However, Iguana can only parse the first statement and ignores everything afterwards:

Found move: {Multiple Moves via && [command="x"&&command="y"]}
...
Reading move: Multiple Moves via &&
Tokenizing string: x
Tokenized: x

One solution would be to internally split trigger strings using && as a delimiter. Problem is the current control flow of scrape_moves() doesn't really have an obvious place to slip that in, so a slight refactor might be needed first.

As shown by PoTS with Lucifer by Jade:

Iguana can occasionally output commands that claim you need to press the same button multiple times simultaneously. Since that's both logically silly and inelegant, perhaps Iguana should be able to detect this and remove duplicates.

Likely related to #6.

Iguana does not currently acknowledge the [Remap] section, which allows authors (or more likely, end users) to remap individual characters. This shouldn't be too hard to implement.

IGOCLG had the ability to annotate moves that required specific palettes to activate, detected by checking for the PalNo trigger. These were also given their own special color highlight.

These should probably be disabled by default, only being applied if Iguana's given an argument like -pals or something. In addition to that, a -palcolor argument would likely be added too, as IGOCLG colorized palette requirements.

Like with #3, Iguana also does not currently acknowledge the Defaults section, which is where authors can specify the default time a command must take. Right now, we just hardcode the default time value to 15 and rely on individual to override it.

This one also shouldn't be too hard to implement. Iguana only uses the time value for AI detection, so it's rather low-priority.

As pointed out by Foobs, Iguana does not currently properly strip charge commands, specifically the kind that specify a time (such as ~5a; ~a is fine).

To quote Elecbyte's documentation of KFM:

;   tilde (~) - to detect key releases
;          egs. command = ~a       ;release the a button
;               command = ~D, F, a ;release down, press fwd, then a
;          If you want to detect "charge moves", you can specify
;          the time the key must be held down for (in game-ticks)
;          egs. command = ~30a     ;hold a for at least 30 ticks, then release

We could probably just detect these and replace them with more 'normal' inputs during tokenization, shouldn't be too hard (probably).

It'd be extremely convenient for Iguana to be capable of patching .def files to include a movelist = movelist.dat key if it's not already present in the file.

This probably shouldn't be something it does automatically by default, but rather requires an 'opt-in' via parameter (I've already reserved -def in the code for this purpose).