# Bug with understanding new kinds of value

6F95 (or maybe 6Exx, I’m not sure) apparently introduced a bug with understanding certain author-defined kinds of value in player input. I’ll report this on Mantis later in the day, but I’m wondering whether there might be a workaround…?

The main problem arises when one sets up a new type of value, such as the “real number” from Michael Callaghan’s Fixed Point Maths extension, and then tries to use a conditional understand statement to parse values of that type in player input. The spoilered code provides a full example:

[spoiler][code]Test is a room.

A real number is a kind of value. -999999.9999 specifies a real number with parts whole and fractional.

The element-selection set is a list of numbers variable. The element-selection set is {1}.

Scaling elements is an action applying to one real number. Understand “scale at [real number]” or “scale element/elements at [real number]” or “scale to [real number]” or “scale element/elements to [real number]” as scaling elements.

Understand “scale [real number]” as scaling elements when the number of entries of the element-selection set > 0.

Carry out scaling elements:
say “Scaled to [real number understood]!”

Test me with “scale element at 0.8000 / scale element at 1.2500 / scale 0.8000 / scale 1.2500 / scale -1.0000 / scale -0.9000 / scale 0.9999 / scale 1.0000”[/code][/spoiler]

Basically, under 6G60, parsing of real numbers fails when using the command form defined in the conditional understand line (Understand “scale [real number]” as scaling elements when the number of entries of the element-selection set > 0), but only when the real number is greater than 0.9999 or negative; otherwise it works fine. Under 5Z71, only negative real numbers failed, all positive real numbers parsed correctly. See spoilered test outputs for each compiler:

6G60

[spoiler]>[1] scale element at 0.8000
Scaled to 0.8000!

[2] scale element at 1.2500
Scaled to 1.2500!

[3] scale 0.8000
Scaled to 0.8000!

[4] scale 1.2500
I don’t think much is to be achieved by that.

That’s not a verb I recognise.

[5] scale -1.0000
You can’t see any such thing.

[6] scale -0.9000
You can’t see any such thing.

[7] scale 0.9999
Scaled to 0.9999!

[8] scale 1.0000
I don’t think much is to be achieved by that.

That’s not a verb I recognise.[/spoiler]

5Z71

[spoiler]>[1] scale element at 0.8000
Scaled to 0.8000!

[2] scale element at 1.2500
Scaled to 1.2500!

[3] scale 0.8000
Scaled to 0.8000!

[4] scale 1.2500
Scaled to 1.2500!

[5] scale -1.0000
You can’t see any such thing.

[6] scale -0.9000
You can’t see any such thing.

[7] scale 0.9999
Scaled to 0.9999!

[8] scale 1.0000
Scaled to 1.0000![/spoiler]

[A separate problem: Parsing of “negative” real numbers has never worked in player input, it seems, though the I7 compiler does recognize them properly in source code.]

Does anyone see a workaround other than avoiding conditional understand declarations altogether?

Thanks,
Erik

emacsuser points out on the Mantis page that the 6G60 bug is due to interaction with the existing “scales” command (which I didn’t know existed–it’s a synonym for “climb”). This means that there is an easy workaround:

Understand the command "scales" as something new.

This fixes my main problem (and also makes me feel a little silly for not trying a different grammar from the start). Thanks, emacs!

–Erik