ID:2764919
 
Not a bug
BYOND Version:514
Operating System:Windows 10 Home
Web Browser:Firefox 96.0
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
I'm attempting to recompile IainPeregrine.Regressia to work with the latest version of BYOND. While testing I noticed a problem with the graphics in the game. I use custom code to convert a string into a series of icon states to display in the game's HUD. I use non-ASCII characters to represent special icons, such as a sword or scroll, that can be embedded into text. For example, the character for sword is "À", and the string "Àcopper" used to display as the word "copper" preceded by a sword icon.

After recompiling to get the game to play in a modern version of BYOND, the same string now displays as "äcopper". I'm guessing there's been a switch to some new flavor of unicode, and that's what's causing the issue?

Can you provide any insight into the issue, or suggest a work around that doesn't involve editing the icon_states or substantially modifying the code? Can I wrap my strings in some sort of ascii_safe() function to preserve previous behavior?
Yeah, BYOND now uses UTF-8 encoding, so the ASCII in the old icons should get "upsampled" to UTF-8.

In theory I would expect old icons to work just fine. IIRC the loader should be turning the old strings to UTF-8, so the issue might be with the way your code is handling grabbing the first character. If you're using copytext() and text2ascii(), you'll want to look at the _char versions of those procs. E.g. you'd still use text2ascii() to grab the first character, but for the rest you'll want copytext_char(name,2) instead of copytext(name,2). The _char versions count by characters and are slightly slower (fairly meaningless in this case though), whereas the original procs count by byte.

So I'm not sure there's a bug here, unless your old icons really aren't changing to UTF-8 on load. My guess is they are, and it's just that your old code isn't compatible with the change, but you should be able to make changes to adjust for that.
Got it. I didn't know if I had an edge case, or if breaking backwards compatibility was intended. The changes you suggested worked. Feel free to resolve this as not-a-bug.
Lummox JR resolved issue (Not a bug)