CNS's Last Hurrah, Part 1 - Recursive redirection

As previously outlined in the Roadmap for M.U.G.E.N, new CNS development will be discontinued in the eventual 2.x engine. But before then, we'll look at adding some features that help improve CNS usability for developers without being too much of a problem in terms of backward- or forward-compatibility. In the "CNS's Last Hurrah" blog post series (which may be sporadically updated), we'll take a look at CNS features that are in the planning or development stages for 1.1.

Today we'll be looking at recursive redirection. Triggers can currently be redirected once, as in

helper(<helperID-expression>), stateno

This would evaluate <helperID-expression>, find PLAYER's helper with that ID, and then get its stateno. Another example would be

enemynear(var(1)), stateno

which would get the stateno of PLAYER's var(1)'th nearest enemy. But there is currently no way in CNS to get PLAYER's helper's nearest enemy's stateno (or any other such trigger evaluation).

Recursive redirection solves the problem by allowing us to write expressions of the following form:

helper(<helperID-expression>), enemynear(var(1)), stateno

Recursive redirections can be nested to arbitrary depth (actually, a very large fixed number). The order of evaluation is left-to-right. Thus each redirection is relative to the player that was computed by the keyword binding to it on its immediate left.

Now, consider var(1) in the preceding expression. Whose var(1) is it -- PLAYER's or PLAYER's helper's? The answer is that since var(1) is not directly bound by a redirection keyword, it is evaluated in the original context, i.e., it is PLAYER's variable. To get the helper's var(1), you would have to redirect that access as well.

- R.