The next upcoming feature of CNS that we'll look at is named variables. A particularly tedious and error-prone characteristic of the current version of CNS is the fact that there is a fixed set of variables that can only be accessed by number. With named variables, you'll be able instead to declare your own variables and address them by name; e.g.,
$foo := 1
would set the variable named "foo" to 1.
One-dimensional arrays can also be declared. In fact, arrays are used to handle legacy accesses to Var, FVar, etc. For example, Var(12) + FVar(4) would be internally translated to $_var[12] + $_fvar[4].
Variables can be declared either as int or float, or as a flexible numeric type that takes on the type of whatever is assigned to it. Another new type of variable is the player variable. A redirection keyword, or a recursive series of redirection keywords, can be thought of as returning a pointer to some player or helper. In trigger redirection, triggers use this player pointer to determine whose values to return. Player variables will allow you to save player pointers, making it easy to refer back to the same player later on. Note, however, that player variables can go stale (e.g., due to a helper destroying itself), so you will need to check whether the player variable has become invalid before using it.
By default, variables are not visible via redirected access from unrelated players (where "unrelated" means they do not descend from the same root player). Public visibility must be explicitly enabled in the variable declaration. This allows you to expose only those variables that are necessary for signaling or communication according to a well-defined standard.
- R.
Sounds fun
Well, I hope this is not the last part of "CNS's Last Hurrah".
This is a good improvement, and looks like most MUGEN coders out there are happy to hear this.
Yet I expect this hooray not to be the last for CNS. I do hope you still have a couple of CNS surprises for us like support for transformable multiform chars with interchangeable get hit sprites.
* String values: maybe.
* String values: maybe. They're not a priority, but we can see that they could be useful. Unfortunately all the old stuff that used string values would have to be deprecated.
* Persistence: can be turned on for each variable or whole array. For backward compatibility, only _var and _fvar will inherit the old behavior where part of the array is persistable.
* Getting entire arrays, especially dynamically sized, with one call: not likely. CNS is not a list-processing language and it will most likely be too messy to try to make it into one.
* Array processing: there will be something to make it easier, but this part has not been worked out yet.
* Redirected variable assignment: possible for related players, not possible for arbitrary players.
* 2D arrays: no.
* Variable assignment in custom state, either to target or attacker: not worked out yet.
* Targeting parameters for sctrls: interesting idea, but we will have to see if it makes sense to implement.
Sweet!
Alright! No more referring to numeric variable lists!
Array processing?
Will we be able to assign a whole set of players into an array?
Like
$H[1]:=1.st helper(7800)
$H[2]:=2.nd helper(7800)
$H[3]:=3.rd helper(7800)
$H[4]:=4.th helper(7800)
...
up to numhelper(7800), same with targets, enemies, etc, in a single command, like $Helperarray:=getplayers(Helper(7800))?
Will we be able to specify these "players" as redirections or parameters of the target*** controllers? For example to only do damage to the 3rd target, or to check the second target's 3rd helper(1100)'s velocity, by using targetlifeadd, player=$targetvar[3], or $targetvar[2],$helpervar[3],vel X?
Do we get an easier way to code loops to process arrays of data, and will those work in the minus states as well? Creating an invisible helper that uses changestates to form a loop is not really a good way to do that, and isn't always possible either. Processing an array of unknown size without loops isn't really possible, and in a lot of cases, you don't know what the maximum will be in advance. (like when checking helpers, targets etc, there can be any number of them from 0 up to 56)
Will we get a way to redirect variable assignment just like reading variables? (Assigning values to parent, helper, and root variables? Passing of parameters through helper ID can get very complicated sometimes, and reading parent variables doesn't work if there are multiples of the same helper created at the same time.)
Will we be able to declare variables in custom states that doesn't overwrite the variable of the same name of the player? Will we be able to assign values to those from the player executing the custom stated attack using variable assignment redirection?
Will we be able to redirect to the player whose custom state we are in (reverse of the target redirection)?
Oh yeah, and what about two(or more) dimensional arrays? If you want to process all helpers of all players on your(or opponent's) side, you'd need those.
Whoa, that was a lot of questions. Anyway, keep up the good work!
Really interesting...
This will set a new customization level into Mugen... Several questions :
1) What about resetting the variables ? I mean, actually, at each round/match, variables are reset to 0, except if you use state 5900 and Int/FloatPersistIndex paramaters. But how will it work with the named variables ?
2) Will it be possible to set "index" for a named variable ? For instance, will it be possible to define foo(1), foo(2), etc. (like, actually, var(1), var(2), etc.), to make "groups" of named variables (ex : defining ThrowVar(1), ThrowVar(2), ThrowVar(3), and SuperBustV(1), SuperBustV(2), and so on, in order to use ThrowVar() vars for a throw, and SuperBustV() vars for a move called "SuperBust", etc.) ? And if so, we could be able to use expression to eval the wanted index. For instance : foo(1+(Life>500))
3) Same as interloko : will it be possible to use some text in these new vars ?
YES!!!!
YES YES YES YES YES!!! THANK YOU!!!!!!!!!
in this new type of variables
in this new type of variables will be posible to set and get text?. something like: $sex := 'male' or $sex := "male"