dMZX Forums: Conversion of && for counters named after values -> MegaZeux Bugs -> Tracker

This is probably best shown as a real-world example. Oppo does a comparison as follows:

set "px" "&playerx&"
set "py" "&playery&"

This sets px and py to the values contained in counters NAMED after the values in playerx and playery (the "10" and "11" counters, respectively). They are both undeclared counters, and therefore have a value of 0. However, this is the same code as parsed by debytecode:

set px to `(playerx)`
set py to `(playery)`

This sets px and py to the values of playerx and playery, respectively. They have respective values of 10 and 11.

This difference in parsing messes up Oppo's death animation.

At the moment I'm not going to do anything about this. The current philosophy in debytecode is to convert any external bytecode input into source, then compile it back when necessary for interpretation. This process is key to any future modification of the bytecode format, optimizer, etc.

With the removal of save_bc and save_robot it is already impossible to apply this method and retain full compatibility. This issue is arguably more serious, but compounds the larger issue. In future, it may be necessary to ship a compatibility "layer" that does not do the conversion to source at runtime. This would eventually include tr_msg(), the expression parser, subset of the bytecode VM, and probably some other stuff I haven't thought of. But I don't want to consider this kind of backward solution until we ascertain how important it is, how many games are broken, etc.

--ajs.

Sorry I never saw this until now, I should read the bug tracker.

The legacy decompiler's decision here is correct. The `` around the name forces interpolation into a string name, like with the original, not an expression.

The problem here is a limitation in the current bytecode, which stores expressions as names of this format. So it can't disambiguate between the two. If debytecode progressed to the point where it compiled expressions instead (or at least stored them in some other format) this problem would go away.

Updating status to: Flagged For Future Version

There won't be any workaround for this issue for 2.83b.

--ajs.

Updating version to: None

[terrible idea removed]

Updating version to: GIT (debytecode)

$^!$!

Updating status to: Confirmed

My previous suggestion was really stupid, but this one isn't.

set px to `<>(playerx)`
set py to `<>(playery)`

Since the interpolation brackets are empty, they'll be ignored. Because the name doesn't start with a parenthesis, it will be interpreted as a name instead of an expression.

This hack will only be required until the bytecode representation of names and expressions gets changed, probably in 3.01.

EDIT: tested and works. Just needs to be added to the disassembler.

set local 10
set `10` -10

set a `(local)`
set b `<>(local)`

:l
* "~fa: (a) b: (b)"
cycle 1
goto l

Alternatively (and probably a much better idea), this can be detected and the <> can be inserted into the bytecode on compilation.

Update on this: the plan is to replace <> and () interpolation with unified interpolation brackets []. This would open up ()/`()` for expressions and `fn()` for functions.