Undocumented change in U29 - saving behaviour in DE/FR clients
 

Users of TravelWindowII were reporting a bug when loading settings. Turns out the DE and FR clients have changed behaviour in U29 and are now saving numericals with English decimals across the board. Shame on me for never fully Vindar'izing the saving in Travel Window :rolleyes: Working on that today.

Hope this helps others if they encounter the issue.

I think it's a bit stranger than that. SSG seems to have been trying to fix the inconsistent format with saved numeric plugindata settings that have caused confusion for authors (and users) for years. Unfortunately, they only implemented it in the 64-bit client so it isn't even consistent within a language and it did not take into consideration values that were previously saved so plugin authors still have to implement a workaround for old uses and 32-bit users that change to 64-bit - so basically, this only fixes 64-bit users that are new plugin installs (or wipe out all their plugin data) and only as long as they never switch back to the 32 bit client. Well intentioned, but more of a step sidewise than a step forward.

I noticed the tonumber() function works the same in the 64-bit DE/FR client as it does in the 64-bit EN client but the 32-bit clients still work the way they did prior to U29. That means that if any FR/DE users change from 32-bit to 64-bit (or vice-versa) they will get an error without even changing client languages. If you execute "return tostring(tonumber('1,000'))" on the various client versions you get:

32-bit EN:nil - the value prior to U29
32-bit FR:1 - the value prior to U29
32-bit DE:1 - the value prior to U29
64-bit EN:nil - the value prior to U29
64-bit FR:nil -changed in U29, FR 64-bit now uses EN version of tonumber()
64-bit DE:nil -changed in U29, DE 64-bit now uses EN version of tonumber()

However, just using the Vindar patch will not resolve this for most of the plugins out there as that just gets past the saving/reading as a string but doesn't coerce numbers into the current format. This could break more plugins than the the EquippedItems() bug back in 2011 that took 3 1/2 years to fix... I would suggest looking into implementing something along the lines of euroNormalize from MoorMap. euroNormalize coerces saved numeric values into the correct current format, that way, numbers will work correctly whether users swap from EN to FR/DE or 32-bit to 64-bit.

FWIW, euroNormalize is defined as:
I haven't fully tested this with the latest changes in the client but initial testing looks as though it still works correctly.
EDIT: After testing MoorMap positioning and size (both decimal numeric values) in various combinations of EN/FR/DE with 32/64 bit clients, it does still appear to coerce numbers correctly. There is definitely a bug in the Wallet plugin that I need to track down (it loads but positions oddly in FR/DE) but does not seem to be directly related to this issue so I believe euroNormalize is working correctly.

I am.actually adding the EuroNormalize functions as we speak - when I wrote "fully Vindar'ed" earlier I should have mentioned I mean adressing all the internationalisation concerns from your Plugins for noobs post.

Amazing work looking into the specifics, Garan. Very useful and thorough.

Holy crap, what a mess. And of course not mentioned in the release notes. Why does SSG hate us? :(

Edit: I wonder if the same inconsistencies now exist in the number-to-string conversions (implicit, e.g. "a .. b"; and explicit, i.e. tostring()).

I believe the answer is yes. That is, for the test code:
the results were:
64-bit
EN= test:1.5:1.5
FR= test:1.5:1.5
DE= test:1.5:1.5

32-bit
EN= test:1.5:1.5
FR= test:1,5:1,5
DE= test:1,5:1,5

64-bit uses EN/US format for EN, DE and FR but 32-bit still uses euro format for DE/FR

I wouldn't say they hate us, but their attempt to help with the numeric format issue was just, well, slightly less than optimal :( Had they implemented it in both 32-bit and 64-bit, it would have been mildly painful but at least it would have been helpful moving forward. As it is, it sort of makes it worse. Hopefully they will eventually implement it in both clients AND announce it in the release notes so Lua authors have some idea it's happening... especially since when we asked for Lua fixes/updates we were told they had no plans for any Lua fixes/updates (per Severlin in his interview on Cordovan's stream). Hey, at least they didn't try to fix the item ID issue, imagine how much damage they could have done with that :p

I am wondering if that change happened because of a library change that only had this result in the 64bit client, and because SSG does not test the plugin environment they did not notice themselves. I smell an unintentional side-effect rather than an intentional change.

Probably right.

Did either of you make an official bug report?

Actually I completely forgot that.

EDIT: I will make one, and more than one probably would help escalate the issue.