What happened? This code used to work in an older version of Inform 7 (around 2011)
"Test" by Halkun
a pit is a room
An object particle is some text that varies.
A check particle is some text that varies.
a error message is some text that varies.
When Play Begins:
Let the object particle be "を";
Let the check particle be "を";
if the check particle is not the object particle:
say "mismatch[line break]";
let the error message be "a mismatch occurred";
say "Error message ---> [error message][line break]";
say "done[line break]";
It’s no longer able to check if two Unicode characters are the same anymore. Also, it seems that has some kind of scope even though I declared the variables outside the routine. What’s going on with Inform 7 nowadays?
‘Let’ declares a local variable. It seems like you want to set the global variable you’ve declared (it is unwise to declare both a local and global variable of the same name), so, in the ‘When play begins’ chunk, use
now the object particle is "を";
now the check particle is "を";
The other issue I had was it was not comparing the Unicode literals. Turns out I had to use “exactly matches the text”. Sadly I don’t see the negitive version of this expression “does not exactly match the text”.
here’s my functional test case.
"Test" by Halkun
a pit is a room
The first unicode character is some text that varies.
The second unicode character is some text that varies.
a error message is some text that varies.
When Play Begins:
Now the first unicode character is "あ";
Now the second unicode character is "あ";
Say "The first unicode character is [the first unicode character].[line break]";
Say "The second unicode character is [the second unicode character].[line break]";
Say "These should match. Let's see if it does.[line break]";
if "[the first unicode character]" exactly matches the text "[the second unicode character]":
say "True![line break]";
otherwise:
say "False![line break]";
say "done[line break]";
I saw your previous post (you had one before and changed it when you figured out the issue, right? Or am I hallucinating?) You should probably still file the issue you had before as a bug; “if the first unicode character is the second unicode character” seemed to work when the characters weren’t unicode, and it seems like it should behave the same. At least filing the bug should get us some clarity.
If you need to use “does not exactly match the text” a lot then it can be useful to define it as a phrase yourself. In fact in this case maybe it’d help to just write a phrase to wrap up unicode comparisons, so you don’t have to put everything in quotes and brackets:
[code]“Test” by Halkun
a pit is a room
The first unicode character is some text that varies.
The second unicode character is some text that varies.
a error message is some text that varies.
When Play Begins:
Now the first unicode character is “あ”;
Now the second unicode character is “あ”;
Say “The first unicode character is [the first unicode character].[line break]”;
Say “The second unicode character is [the second unicode character].[line break]”;
Say “These should match. Let’s see if it does.[line break]”;
if the first unicode character unicode-matches the second unicode character:
say “True![line break]”;
if the first unicode character does not unicode-match the second unicode character:
say “False![line break]”;
say “done[line break]”;
To decide whether (X - text) unicode-matches (Y - text):
if “[x]” exactly matches the text “[y]”, yes;
no.
To decide whether (X - text) does not unicode-match (Y - text):
if X unicode-matches Y, no;
yes.[/code]
After some experimentation, I have found that you can work around this bug by applying “substituted form of…” to either side of the equation. Or both sides.
So you could write:
Now the first unicode character is "あ";
now the second unicode character is the substituted form of "あ";
…and then you would get the comparison you expect.
“Substituted form of” shouldn’t make any difference for a string with no substituted variables – but in this case, the code goes down a different path that happens to avoid the bug.