LoTROInterface

LoTROInterface (https://www.lotrointerface.com/forums/index.php)
-   General Authoring Discussion (L) (https://www.lotrointerface.com/forums/forumdisplay.php?f=22)
-   -   Undocumented change in U29 - saving behaviour in DE/FR clients (https://www.lotrointerface.com/forums/showthread.php?t=3836)

Hyoss 03-20-2021 04:23 AM

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.

Garan 03-20-2021 08:22 AM

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:
Code:

if (tonumber("1,000")==1) then
        function euroNormalize(value)
                local retcode
                if value~=nil then
                        retcode=tonumber((string.gsub(value,"%.",",")))
                end
                return retcode
        end
else
        function euroNormalize(value)
                local retcode
                if value~=nil then
                        retcode=tonumber((string.gsub(value,",",".")))
                end
                return retcode
        end
end

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.

Hyoss 03-20-2021 12:05 PM

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.

Thurallor 03-20-2021 03:20 PM

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()).

Garan 03-20-2021 08:11 PM

Quote:

Originally Posted by Thurallor (Post 12632)
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:
Code:

a=1.5
return "test:"..a..":"..tostring(a)

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

Hyoss 03-21-2021 05:37 AM

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.

Thurallor 04-09-2021 01:08 PM

Quote:

Originally Posted by Hyoss (Post 12634)
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?

Hyoss 04-12-2021 09:28 AM

Quote:

Originally Posted by Thurallor (Post 12646)
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.


All times are GMT -5. The time now is 06:52 AM.

vBulletin® - Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
© MMOUI