[Bug]: Regional / language settings data issues

[Driffx]

📋 Guidelines

• I have encountered this bug in the latest release of NMSE.
• I have encountered this bug in the official downloads of NMSE.
• I have searched the issue tracker for open and closed issues that are similar to the bug report I want to file, without success.
• I have searched the documentation for information that matches the description of the bug I want to file, without success.
• This issue contains only one bug.
• I have read and agree to follow the code of conduct.

🐞 Bug Description

If I save after clicking the "Fishing" tab, even without changing anything, my save file becomes corrupted. During the loading of the save file, the error message appears: Failed to load save file: Invalid token at line 1, column 6827135.

It seems to me that the problem has to do with the "FishingRecord>LargestCatchList" field and items with a value with a zero after the decimal point.

If I delete the entire "LargestCatchList" block through the JSON Editor, the save file becomes valid again.

⚙️ Steps to Reproduce

1. Open a save file.
2. Click the "Fishing" tab.
3. Save.
4. Open/Reload the same save file.

🔎 Expected Behavior

Save file not being corrupted.

🖼️ Screenshot or Video

💻 Environment

• OS: Windows 11
• Version:
• Branch/Commit: NMSE Build 1.0.355
• Additional context:

[davemager]

I wonder if it has something to do with your regional settings - the display for both my Largest Catch and the lines in the Raw JSON Editor show the values with a decimal point, not a comma (I know comma's are common in many European languages as the separator) and I wonder if that's being entered into the JSON at save time making it invalid.

Can you confirm if you are using a language that normally uses a comma as the "Decimal symbol" in Windows? This might assist vectorcmdr in tracking this down.

[Driffx]

Can you confirm if you are using a language that normally uses a comma as the "Decimal symbol" in Windows? This might assist vectorcmdr in tracking this down.

Good catch, davemager!
Yes. I confirm that I am using Windows in English, but with decimals separated by commas.

[Driffx]

If I use the Raw JSON Editor without clicking on the Fishing TAB, those values ​​are preserved with the decimals separated by periods.

[vectorcmdr]

Ah! Good catch. Sorry about that!
I didn't think about regional differences in decimal separators. Thanks for the investigation guys. I'll get this fixed up ASAP.

[vectorcmdr]

Fix for this should be live in the new preview build. Please let me know how you go!

[vectorcmdr]

Closing as fixed, please comment again if the issue continues and I will reopen it

[Driffx]

In the frontend interface, decimals remain separated by commas, following my Windows configuration. In the backend, now decimals are separated by periods.

Yesterday I created a new save to better test your program. Some bugs invalidated the save, resetting it to that white page with "E" to initialize. What I noticed is that if I add any Known Technologies or Known Products, bugs occur - Game presets and/or Account name become invalid, the save is reset or completely corrupted. Furthermore, some value fields show zero where there were positive values. And I noticed some confusion related to the save time vs. Steam sync, I'm not sure.

Before I try to track down these problems and better report the bugs individually, I wonder if they might be related to my Windows 11 locale settings - decimals separated by commas, date in Day/Month/Year format separated by periods, not slashes. Hence the question: Wouldn't it be better to keep the program in the standard used by the game, regardless of the user's region settings?

[vectorcmdr]

Definitely seems like a localisation problem.

Game presets and/or Account name become invalid

This is likely the key indicator. Could you share the save so I can test it specifically? I am guessing there is a language related bug with writing back the games meta info and/or names causing cascading issues.

Wouldn't it be better to keep the program in the standard used by the game, regardless of the user's region settings?

Unfortunately there aren't ways to enforce some of these things using windows native control in WinForms - some are managed by the environment/OS - so they have to be safeguarded manually.
This is essentially what it is doing via CultureInfo.InvariantCulture or similar String-><-Latin-1-><-Byte custom safety conversions where I am aware it is an issue - but I can only mitigate it where I am aware of it. It also affects localisation support if I enforce things like date format which isn't welcoming for other users.

Knowing some of the value fields that seem to not be working for you would help narrow it down as well if you can let me know.