Some release notes-in-progress:
* Upgraded the game to Unity 2019.1.0f2! The prior version was on 2018.2.0 or something along those lines, so this is a big jump.
** The really big improvement is time-sliced garbage collection:
https://blogs.unity3d.com/2018/11/26/feature-preview-incremental-garbage-collection/*** Or here:
https://www.youtube.com/watch?v=XhfzzLyG7_w** This also has numerous bugfixes, and lets us upgrade from a VERY old version of TextMeshPro to the newest version, which in turn fixes a variety of bugs relating to text, blurry text, textboxes, etc.
*** That said, as part of this, we knew this was going to happen, but it breaks ALL the references to any sort of text-based thing inside of any of our unity projects.
*** But we kind of needed to go ahead and have this done before we started in o na bunch more UI updates or else it was just going to be creating even more work for ourselves in the future.
** There are also a variety of stability improvements to the unity engine in general, and a few performance improvements. I think that Linux machines will see the biggest boost.
*** There are some new capabilities that we can in theory use in the future, too, and nested prefabs are an amazing thing for sure. But we're not really needing those bits in this specific project right at the moment.
** Oh and this does upgrade us to the latest version of the post processing stack v2, as well, which means probably better performance and some edge bugfixes for some folks in that area, too.
* Okay, so we've been using the mcs.exe compiler for the last two years, and it turns out that doesn't support the newer versions of C#. It would have been nice if that had been more clear.
** Instead, when we were updating our TextMeshPro component or a few other things -- or trying to, anyway -- we would instead get mysterious "System.MissingMethodException: Method not found: "Void System.Array.Reverse(!!0[])" compilation errors. Good luck googling that, almost nobody has that.
** The solution is to STOP USING MCS.EXE, and instead use csc.exe. That's the new Roslyn compiler that Micrsoft created and unity is using for the newer C# 6.0+ features.
*** The !fun! part about that is that all the syntax is different, and also it requires references to... a whole bunch of dlls that are the "reference dlls" instead of the "runtime ones."
*** If you ever find yourself referencing a dll called System.Private.CoreLib.dll, or anything like that, STOP WHAT YOU ARE DOING and try a different dll.
**** Even though the compiler just told you that what you need is in that dll, it's actually lying.
**** Actually what you need is in... good luck figuring that out!... but probably it's in the REFERENCE version of System.Core.dll or similar. It has nothing to do with "netcoreapp" or "netstandard," unlike the few non-unity-related references to this on the internet would have you believe. That's unrelated to unity, and is just a fun thing on some web servers and various other software.
**** What the heck is a "reference dll" in terms of what the compiler needs? Well, it's a fuller version than is used at runtime, I suppose. I haven't explicitly seen that said anywhere, but that seems to be the general feeling I'm getting. Why they needed this split I'm not sure, but I'm guessing different compiler flags or perhaps the ability to have different per-platform versions. Something like that.
**** Where do you find those reference dlls?? Ha! Good luck with that. Some of them seem to be in the Roslyn compiler folder... except not really, some of them have way too small of sizes. Others are almost certainly in your [UnityInstallLocation]\Editor\Data\Managed\UnityEngine folder, but there again it's not perfect.
***** Generally you're going to find yourself searching around inside the unity install folder, and you might even find yourself (if you're on windows) searching around inside C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\ or whatever your equivalent is. Nicely packaged for you? NO.
** So that explains one of the big mysteries that Keith and I have been scratching our heads on for a couple of years now.
*** But even with that "solved," I couldn't get all of the aspects of LINQ working, and some of our third-party networking code uses LINQ, so I moved that into an external dll that will get loaded at runtime. That's more efficient anyway, but annoyingly indirect.
*** All of the network code has been open-sourced by the original authors anyhow, so that actually will work out extra well for us when we get to that point. But in the short term it's another pain in the rear we didn't need.
* One bonus of all this upgrading of unity-stuff is that the editor is no longer complaining about our external dlls being something that will crash the editor and so something they refuse to load. That's... always a plus. And is related to the whole compiler saga.
* Okay, nested prefabs from the latest versions of unity are actually indeed insanely useful and we're starting to use those more than we otherwise might have.
* ALL of the fonts in the game have been reworked (in terms of how they are imported into TextMeshPro and thus how they look in general).
** And a bunch of new fonts have been added to the game as options for us to use in various contexts.
** And we've completely redone what fonts we are using in almost all contexts as it is.
** There was a lot of complaining about the fonts not feeling properly militaristic, or otherwise being non-thematic, and hopefully this helps.
* The background story is again its own window and scrolls rather than is paginated, but this time is a lot more condensed, uses an improved version of the more-recent rewritten version, and uses strategic coloration to make it easier to read quickly.
BackgroundStory 600x400
------------------
But I still have a fair bit to go through. This is a HUGE leap forward for us in terms of being able to not have to do this sort of major rework again anytime soon, though. The unity upgrade had been hindered by the compiler thing that Keith and I couldn't figure out last year. The textmeshpro upgrade was then further hindered by the fact that I'd have to go in and manually fix every freaking UI. Good thing you guys hated the fonts, some more than others, so I could hit both with one stone.
In the future, a unity upgrade will still be using the same compiler for the foreseeable future (that was the case for the prior 10 years or so), so those aren't such a big deal. This game has already had something like 5 unity version upgrades, anyway.
In the future, a textmeshpro upgrade won't be such a big deal because of the new way we're compiling that in general, and the fact that all the GUIDs will match. So it will just get us the new bugfixes and features without all this other mess.
Anyway, so that's where I'm at right now.
