So, I’m back on my guide (yes, again). Currently I’ve hit one snag: Displaying {variable} in game without resorting to pictures. Mind you, that's not displaying variables, but straight up displaying *{variable}* in game. I thought I had it working with a non-displaying space between the $ and {, but either it somehow broke (now it displays unknown characters with a question mark), or I just though I had it when I didn’t.
Either way, passing it to the community to find if one of the newer brains can figure it.
Copy and paste produces an unknown character square (White Medium Square: ) in notepad++. And actually trying to run it produces a strange error: startup line 12: invalid ${} variable substitution at letter 1 Also, I tried to punch it in directly and it gets displayed as a question mark.
Just as an FYI, when I did have it working (I’m sure I did, but I have no idea what happened, other than a few crashes, but I saved, well, IDK) (You know what. I updated Notepad++, I might have to try something in a moment), it was through:
*temp super_blank " " (dscourse hates that: Here the “Mongolian Vowel Sepataror”)
$${super_blank}{variable}
(If you copy/paste you should be able to see there’s a non-displaying space between the characters on the linked page).
That works, I swear *print did, but on retrying it I got an error too! Late nights, early mornings…
Your method seems to work, but it’s a little hacky and potentially prone to break in CS updates?
In which case it may just be as well to call the print function directly?
This is from memory, but…
*script printx("$❴variable❵");
Should print straight to the screen without any checks or parsing.
That works too, so long as I use standard curly parenteses, and I’d assume using the already present functions is a better option than switching encoding to use non-standard characters. (To be sure ANSI is the std. to use for CS, right?)
I wonder why *print catches on {foo} by *script printx with standard {foo} doesn’t. Maybe something altered in the function of *print, as it is just legacy after all? Well, I’m not going to dig through github to see if it works on older versions where *print was standard. Despite what it may seem like sometimes, there is a limit to my curiosity after all.
Actually Unicode is what they recommend, but I would (personally) use the inbuilt printx function over the other method.
The reason printx doesn’t catch is because it’s not a command but a core interpreter function (hence *script), it’s what everything is ultimately passed to in order to display it on screen, you’re basically just skipping all the checks and parsing by directly calling printx.
) in notepad++. And actually trying to run it produces a strange error: