Adding String data type to CNS/ZSS

[Lazin3ss]

Right now, Ikemen's bytecode machine only handles strings for certain isolated situations, like comparison of name trigger or certain parameters in SCTRLs, like Text or DisplayToClipboard. This makes string support in character code essentially hardcoded. By adding strings as a new data type that can be manipulated in the code, we're unhardcoding an essential part of coding. We'll be able to create custom, dynamically-changing texts with Text SCTRL, store strings in maps, do BGM changes with only one PlayBGM, produce more understandable code, etc.

Bytecode seems like the easiest part to implement. To add basic string support, the first idea I had was the next:

• Add a new StringPool for temporal storing of strings while a StateBytecode is getting executed
• Create a new BytecodeValue type, VT_String, which will store an index of the StringPool where the string is located
• Create necessary methods for string handling (ToS(), SetS(), PushS(), EvalS(), BytecodeString())
• Add OC_string OpCode to push a string from the compiled code to the stack

After all this, relevant parts of the bytecode machine can be rewritten to use these new methods and ensure proper handling of strings at runtime. Here's an example commit where I apply all this: Lazin3ss@964a8f1

Now, the most troublesome part is the compiler. Current compiler code is kind of a mess, with a mix of japanese and english in identifier naming and most of the code being designed with only numbers in mind. This means all instances of string parsing are reduced to its hardcorded situations, like the ones described at the start of this post. A deep refactor of current compiler code is necessary so strings can be parsed in a more general way.

[potsmugen]

I'm not sure about how to go about implementing it, but I can provide one application for it I wish were possible to maybe give you some ideas:

hitflag = ifelse(var(x) < y, MAF, MA)

Ideally those MAF and MA wouldn't need format specifiers before them.

[LasombraDemon]

The biggest usefulness for this I can think of, in current creations, is to truly detect character names within reason via InString stuff.

Right now, if we want to detect a "Ryu", we have to go for "Ryu", "Ryu Hoshi", "Hoshi Ryu", "Ryuu", and every other variant all the way to "El Chabón que Jadoquens".

This is impressive.

[Lazin3ss]

Another issue that has presented is the inconsistency on how CNS/ZSS currently handles strings. There are situations where strings are parsed only if they're enclosed in quotation marks (like SCTRLs, for example), but, in cases like arguments on function-like triggers (like map(), var(), stagevar(), const(), gethitvar()), quotation marks are not accepted by the compiler, throwing an error if they're used.

This makes me think we should add "versions" to ZSS, much like Lua, Sff, Fnt, etc. In its most recent version, syntax will be more consistent with its rules, mainly in String-related stuff. After discussing the idea a little bit in the discord server with other users, I considered three possible major versions:

• Version 1: ZSS as it was originally envisioned by Suehiro
• Version 2: ZSS with all the backwards-compatible changes we've been adding to it, like const parsing in Statedef headers, IgnoreHitPause inheritance, Switch, Loops, etc. (This can be the version by default)
• Version 3: String data-type addition. Prominent, not backwards-compatible changes to syntax, like all strings having to be enclosed in quotation marks, Command trigger being function-like, etc.

ZSS version can be declared at the start of a .zss file, with syntax like this:

ZSS_VERSION = 200

[Statedef -4]

lifeSet{value: 1000}

(In this case, we're using major ver. 2, with additional numbers for possible minor versions)

[LasombraDemon]

In favor of all those ideas. ALL strings should be enclosed in "".

[Lazin3ss]

Some days ago I was able to make some progress regarding the compiler.

First, I found raw numbers are compiled as BytecodeValues through (*Compiler) expValue() function. By adding a similar process for strings in the global system StringPool, I was able to innately unhardcode raw string parsing.

Following that, I changed clipboard SCTRL code so a BytecodeValue of type VT_String is excracted from the parameter expression. By evaluating it to a string in the bytecode, I got this:

displayToClipboard{
	text: "%v";
	params: "hello there";
}

Code for all of this can be found in 43e5f93.

Next, I wanted to experiment with character maps, to see if they could hold string values, no matter if it's in the most rudimentary process possible. I got great results by using interfaces in the chars' hashmaps and doing type assertion in the bytecode machine, which got me into these results:

map(someStr) := "I'm saving this string for later";

displayToClipboard{
	text: "%v";
	params: map(someStr);
}

For my last experiment, I decided to unhardcode name trigger and text SCTRL to see if I could print character name into the match screen. Unhardcoding text was trivial at this point, but name is giving me a hard time. Since MUGEN forces you to compare name with another string, not only I had to unhardcode the trigger itself so it returns a string with the character name... but also I had to modify the OpCode function for equality comparison so it also can handle strings, making current name syntax not obligatory anymore. This have been proving difficult to me, as I'm still not able to figure out how to properly handle the bytecode stack in this situation, leading to possible crashes depending on the code used by the character. (see first comment in this post)

Code for all this (including defective string equality comparison) can be found here: 0204496.

[Lazin3ss]

Nevermind, it wasn't defective code. I was adding +4 to the stack iterator by mistake in AuthorName OC op when I shouldn't (since it isn't an I32 operation). Everything in my last experiment works perfectly. Faulty line

[Lazin3ss]

OK, so, coming back to this. I'll list all the State Controllers and Triggers that should be un-hardcoded (in theory).

State Controllers:

• AfterImage (trans)
• AppendToClipboard (text)
• AssertCommand (name)
• AssertInput (flag)
• AssertSpecial (flag)
• BindToTarget (postype)
• DisplayToClipboard (text)
• Camera (view)
• Dialogue (text)
• Explod/ModifyExplod (space, trans, postype)
• ForceFeedback (waveform)
• Helper (helpertype, name, postype)
• HitBy (value)
• HitDef/ModifyHitdef (attr, hitflag, guardflag, affectteam, animtype, air.animtype, fall.animtype, priority_hit_type, ground.type, air.type)
• HitOverride (attr)
• LifebarAction (text)
• LoadFile (savedata, path)
• MapAdd, ParentMapAdd, RootMapAdd, TeamMapAdd (map)
• MapSet, ParentMapSet, RootMapSet, TeamMapSet (map)
• MatchRestart (pdef, stagedef)
• ModifyPlayer (displayname, lifebarname)
• NotHitBy (value)
• PlayBgm (bgm)
• PrintToConsole (text)
• Projectile/ModifyProjectile (postype)
• RemapSprite (preset)
• ReversalDef/ModifyReversalDef (reversal.attr)
• SaveFile (savedata, path)
• StateTypeSet (statetype, movetype, physics)
• Text (text)
• Trans (trans)

Triggers:

• Alpha [This probably should have its syntax fixed to "AlphaSource" and "AlphaDest"]
• AuthorName
• BGMVar
• ClsnVar
• Command
• DisplayName
• EnvShakeVar
• ExplodVar
• FightScreenVar
• GameMode
• GameOption
• HelperName
• HitByAttr
• HitDefAttr
• HitDefVar
• InputType
• IsAsserted
• Map
• MoveHitVar
• MoveType/PMoveType
• Name/PName
• PalFXVar
• Physics
• PrevMoveType
• PrevStateType
• ProjVar
• ReversalDefAttr
• SelfCommand
• StageConst
• StageVar
• StateType/PStateType
• TeamMode

[potsmugen]

A few of those deal with flags rather than strings specifically, so we probably still need to go the long way about them.

For the rest, doesn't that mean something like us still needing the hardcoded strings for legacy stuff while Ikemen 1.0 (or whatever) content needs to use quotes around all strings? Maybe we're too late in the game for the things that don't already enforce quotes (like name triggers do for instance).

• Alpha [This probably should have its syntax fixed to "AlphaSource" and "AlphaDest"]

I thought so too when it was implemented. But I think it was modeled after "vel x" etc.

[Lazin3ss]

Triggers and parameter values expecting a flag in CNS will still work like they currently do. Since strings as a data type we're never really in the mind of Elecbyte devs during MUGEN development, stuff like 'attr', 'statetype', 'stagevars', etc. can be interpreted as constants, like in other languages. We have to possibility to unhardcode them in ZSS any way, to do stuff like:

If expr1 {
    let val = "D";
} else
    let val: "U";
}
AssertInput{flag: $val}

I already proposed some solutions for the quotes issue, like the "ZSS_VERSION" flag, or, like K4thos said, to change the rules and just enforce them from now on, since we're still in a "beta". I see string manipulation as something necessary for triggers like map, where you could use map($val) to dinamically change the expression.

Regarding the compiler, I think it can handle both things, it's pretty robust in itself, though the code is all over the place.

[Lazin3ss]

Strings could be concatenated through an operator. We can use '+' (consistent with our current operators).

List of proposed data assertion triggers/methods

• IsInt/IsFloat/IsString
• ToInt/ToFloat/ToString

List of proposed String manipulation triggers/methods:

• At/CharAt
• Format
• IndexOf
• Join (Requires implementation of arrays)
• LastIndexOf
• Left/Right
• Length
• PaddingLeft/PaddingRight
• Replace
• Repeat
• Split (Requires implementation of arrays)
• Substring
• ToLowercase
• ToUppercase
• Trim