dMZX Forums: Out-of-range param numbers in param fields -> MegaZeux Bugs -> Tracker

When inputting a number in the parameter field of a command outside of the typical values of 0-255 or 256 (p??), the interpreter visually resolves the param for the command in one of two ways:

• Simply declares it as p??, though it will not actually act as p?? (it acts, AFAICT, as the param resulting from the number modulo'd by 256).
  
• It declares the parameter to be a hex number with more than two digits, leaving a line that would fail validation if highlighted. (For example, -30000 would turn into p8ad0.)

Updating status to: Confirmed

Updating Introduced In Version to: 2.80X

The first version that will assemble

put c2a CustomFloor 32766 at 5 5

is 2.80h, which exhibits this behavior—the new CustomFloor has a param of 254, but the command clearly still has a param of 32766 because it displays p??. (Same behavior as you described for -30000 too.)

I don't think there's any value in extended parameter syntax yet, probably what would need to be done is either

• modulo literal parameters by 256 or
  
• convert e.g. 32766 into "(32766)"

during both assembly and disassembly.

Updating status to: Flagged For Future Version

Disassembly into invalid Robotic source is fixed in GIT 415385b3; disassembly now "corrects" out-of-range values using the semantics of the non-bugged replacement commands, i.e. cXX <0 is modulo 256, cXX >288 is clamped to c??, pXX <0 or >256 is modulo 256. "Correcting" these values at assembly is more complicated and probably not worth the effort, but we can figure out what to do with them later.

It would also be nice to have either more context-dependent "correction" (as matching commands behave differently) or extended syntax so these weird values can be expressed as part of the language. The latter would require a minor version at minimum.

This behavior also affects chars, which I included in the color/param tests. These are still disassembled modulo 256, except for CHAR EDIT, SCROLL CHAR, FLIP CHAR, and COPY CHAR, which I added conditional support to for disassembling to imm16 when the char is outside of char range. (This is limited to those four commands because they're the only ones where out-of-range values are relevant, but also because CHANGE OVERLAY had a bugged second char argument that would not accept imm16 prior to this patch, and disassembling to imm16 would cause potential breakage for this extreme edge case.)