edited April 24 in ORK Support
It's just a thing that had been bugging me the few days I've been trying it out, and I even tried out using unity 2018 to compare.

Somehow, loading the ORK asset data in Unity 2019 just goes through all the numbers in the thing it loads and goes "What's this? A decimal place? Nah, you don't need any of that!" and then you're stuck wondering "Why is my menu not working? I can press up/down once but then nothing!" until you find out that, for no good reason whatsoever, your 0.25 second wait between accepted inputs went out of the window and instead you have a 25 second window between inputs.

Though I guess it's my fault for jumping straight onto Unity 2019 even though it was barely out of the box.

Edit: After a bit of testing, it seemed to happen both in Unity 2018 and 2019, and rather inconsistently, which makes me think it might have been something I got from the asset store that had some faulty script that screwed that part up... somehow.
It still feels like an odd way of breaking though.
Post edited by barreytor on
  • I can confirm that, although it's strange that this is also happening in Unity 2018 for you.

    I also stumbled upon this while working on Makinom for Unity 2019 yesterday and found out that Unity changed how language locales are handled by the editor, that's what's causing this.
    Updates will be out later this week to fix this (in all Unity versions) and support Unity 2019 officially.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • This is likely due to Unity 2018.3 and later versions defaulting to the .NET 4.x Equivalent scripting runtime for new projects.

    When serializing any floating point numeric data types (float, double decimal), the .NET 4.x Equivalent runtime handles it a bit differently than did the .NET 3.5 Equivalent and now uses the regional settings on the user's computer when converting values into a string format. So if the code that is performing the serialization doesn't use CultureInfo.InvariantCulture when converting the numeric value to a string, it will use the regional settings to determine whether to use a comma or a period as a decimal point.

    Thus, depending on your locale settings, a value of 0.25 will be stored as either "0.25" or "25" -- so it is actually quite logical, once you know the reason. :-)

    So if you're seeing this in some projects but not others, go into Edit -> Project Settings -> Player and look under Configuration for the Scripting Runtime Version. My guess is that any projects that were started in Unity 2018.2 or earlier won't have the issue (unless you manually switched it to the .NET 4.x Equivalent runtime).

    Unity's built-in serialization is handled within their C++ layer, so it's not affected by the scripting runtime change. Any assets that use custom serialization to handle types that don't inherit from UnityEngine.Object (generally that means MonoBehaviour or ScriptableObject) may run into this issue. I fixed the custom serialization code for ootii's assets a couple of months back, as we were seeing that issue come up for developers in some European countries.
  • edited April 25
    So my problem was being european and having the project initially created within Unity 2019 which means the problem persisted when downgraded to Unity 2018, got it.

    What's funny, though, is that it only seemed to break on the first load of the project after loading Unity.

    I'll wait until the bug gets squashed to try and keep figuring things out then, no sense pulling my hair out because my poor decisions and wanting to stick with them aren't compatible with the nonsense they pull on perfectly working stuff.
    Post edited by barreytor on
  • Update will be out tomorrow and make sure ORK's serializer uses invariant culture to avoid these problems in the future.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • I wanted to try Shader Graph, which means I had to install one of the the new render pipelines, which means I had to manually switcht to the .NET 4.x Equivalent runtime. I got dozens of "Error while parsing XML data: at System.String.IndexOf (System.Char value, System.Int32 startIndex, System.Int32 count) [0x0000d] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 at ORKFramework.XML.XMLParser.Parse () [0x00106] in <8fa19c11e6ce44058ebad7a7d8265543>:0 " style messages.

    I assume that this problem is caused by the same thing you are all talking about?
  • @JMR
    I didn't run into that error, but that might be due to your system's language/locale settings. This should be fixed by today's update.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • The ORK/Makinom updates are now available, but please keep in mind that if your project is already broken due to saving with a previous version in Unity 2019, the update can't fix that. You'll have to start from a pre Unity 2019 version again, hopefully you made backups before upgrading to a new Untiy version!
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • Update fixed all my issues, didn't even need to start from pre Unity 2019.
  • So. I'm glad me pointing out this whole problem helped fix someone else's problem.
    But it didn't fix mine: being stupid.

    Once you're done facepalming I'll explain:
    The problem of "Oh no my floating point numbers are all broken" comes from carting the project around and working on it on two different computers, that use different locale settings.

    Yes, it took me a while to realize I was the one breaking my own stuff up, just because one computer uses . as the decimal separator, and the other uses ,

    And yes, that means the update didn't solve my problem because I was pointing in the wrong direction because I didn't realize the most obvious thing.

    At least I know I can just do a find and replace on the asset file before opening it in the differently-localed computer, but I thought I'd mention it anyway just in case there's some way of handling that.
  • Did you also test this with the new version (ORK 2.24.1) on both computers? This shouldn't be a problem with the new version, as it forces using the invariant locale (i.e. using '.' for floating point numbers) - I'm also on a computer with the ',' locale and it works fine here (using '.' for saving).

    You'd need to test it with a version of your project before running into this problems, as the udpate can't fix already 'broken' data.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • ...
    I was pretty sure I had updated ORK, but apparently I must have done that after a point to which I had to rollback to.
    Go me?
Sign In or Register to comment.