HarveyBirdman
Liturgist
- Joined
- Jan 5, 2019
- Messages
- 1,048
Sucks, but lesson learned. Good thing you didn't lose more than two weeks of data.
What is the mechanism by which an update of external software can actually mess up your own code and data? I'd understand API calls not functioning properly any more, but it sounds like Cleve's own source code and assets were somehow altered - how does that work?
My understanding from Cleve's "Mucked up the shaders, destroyed the lightmapping, crashed 3/4s of the assets." and the bit about Enlighten later isn't that it messed up his actual code and data, but that the engine changed the way it treats shaders (especially lighting, since Enlighten is a lightmapping middleware used -among others- by Unity) and that was what messed up his work. Essentially it is as if you used some external library that had a SetPopStrength(float strength) function and in the newest version the function still has the same signature (so it is technically backwards compatible from an ABI perspective) as it had before, but the meaning of "strength" changed so even though nothing changed in your code that called that function, the actual behavior of your program did end up changing.
Note that this is just a guess, i do not use Unity myself so i have no knowledge about its quirks.
But i doubt he can do much about it and in the case i describe above a backup wouldn't help since it isn't his code that changed, it is Unity and unless he decides to never update to newer versions, at some point he'd have to adjust his assets to work with the changes.
This is one of those cases where the new engineer hires at Unity wanted to work on their own code instead of improving and maintaining the existing codebase- throwing away all backwards compatibility in the process.
Considering Unity Technologies has more than 2000 employees as of 2018, i'm not sure how there is any hope for a consistent vision with the engine when there have been entire AAA games that were made with by companies having a tenth of that headcount (sure, not everyone works on the engine but still that is a huge number of people and it isn't like they work on a large number of projects anyway).
Epic games also has over 2000 employees, and they haven't managed to screw up their engine that bad. Granted, C++ is kind of terrible, but at least blueprints and the material editor are relatively consistent. Unreal does split their rendering tech between a mobile renderer, and the normal renderer(with optional Forward path), but the difference is all under the hood. The material editor inputs are mostly the same, and you can switch back and forth. I guess Epic are too busy making actual games rather than inventing features that no one needs(ie DOTs).
Whats wrong Unreals use of C++? I only have minor experience with modern cpp, but with smart pointers and std algorithms it doesn't seem much worse then C# from a programming perspective.
And just generally C# is cleaner without having header files, forward declarations, or crashing whenever you accidentally dereference a null pointer.
OK, folks, I am genuinely curious and would hope to be educated by you (and condolences to Cleve...). My idea of software development is typing code into vi (that was a lie, actually I'm part of the unwashed EMACS masses) and then entering 'g++' into bash, linking against any external libraries as needed.
What is the mechanism by which an update of external software can actually mess up your own code and data? I'd understand API calls not functioning properly any more, but it sounds like Cleve's own source code and assets were somehow altered - how does that work?
URP is a horrible failure that has less features than the built-in pipeline and has no compatibility. This is one of those cases where the new engineer hires at Unity wanted to work on their own code instead of improving and maintaining the existing codebase- throwing away all backwards compatibility in the process. The only thing that URP has over the old built-in system is that it does single pass lighting with multiple lights, and I guess it does batching better. Would it really have killed them to just improve the existing pipeline instead of inventing this for NO REASON?
Sadly, this is happening with many different parts of Unity. They have already deprecated their second networking solution and are working on a third. There are now two completely different visual scripting systems. They deprecated realtime GI with no replacement, but they're working on a new one which will probably be in experimental for years.
It's like they're staffed by a bunch of bumbling idiots who each exist in their own bubble- completely cut off from communication with each other and the outside world. I'm using Unity for my project because I like to use C#, but after this I am done with them.
As for not backing up your stuff sooner- that one is on you.
Epic games also has over 2000 employees, and they haven't managed to screw up their engine that bad. [...] I guess Epic are too busy making actual games rather than inventing features that no one needs(ie DOTs).
yes, that is by far the most frustrating thing about Unity. they keep adding new shit and never finishing any of it.Unity adds a lot of new features but never gets most of them at a stable level.
It really gives you the impression they make new stuff to appeal to investors instead of their users. Godot is kinda of heading in that direction.