Unity is not .NET

5.1 to 2018.2 have huge impact, if you didnt need to change anything then the game must we very trivial. I remember 5.5 to 5.6 as the biggest pain.

edit: Checked our git history, here is one of many changes going from 5.5 > 2017

 

In the scope of serious changes (things removed and/or replaced), that's just refactoring. Your IDE should solve this for you, almost entirely automagically.

 

When it comes to shaders UNity has a migration tool that automatically fixes changes like that. But not for C#
There was a ton of these going from 5.5 > 2017 we skipped 5.6 but most changes was in 5.5 > 5.6. There was not only compile time breaking changes but runtime breaking changes.

 

A few days lost, thousands of benefits gained.

 

Unity 2018 definitely feels that way. I'm both scared and excited to see what they have left to add for 2019.

 

Agreed, most unity devs do not, they stay on LTS and stuff like that. Crazy
edit: though it took us a couple of months moving from 5.5 to 2017 Not full time but on and off

 

At least one of the consoles only adds support for the latest release with each new solar eclipse.

 

Its up to the console to support latest version? Thats fubar

 

Not really, there are just processes that need to be completed in the inter-business realm. But yeah, our considerations when upgrading are definitely impacted by such things.

If we look at the marketing spiel, sure, thousands of benefits. But there's a genuine question mark over whether or not those benefits are worth "a few days" when you're working to a deadline, especially when many of those benefits are unrelated or tangential to the things you're trying to get done.

I'm highly averse to involuntary crunch time, so I'm ruthless when it comes to prioritising things and sticking to those priorities. I've been in situations before where we're under the pump doing stuff at the last minute after having wasted a bunch of time earlier on "nice to have" stuff. Knowing the feeling of having been there I'll take all reasonable steps to avoid inflicting that on myself, and moreso on others. On the flip side, if an update has something that's directly relevant to a must-have or has things that will boost productivity then sure, the cost of upgrading may effectively be nil.

Of course, for my projects and target platforms engine updates are rarely must-have tasks, they're usually nice-to-have. In other circumstances they're a must-have thing that you just regularly need to get done. It's a typical case of "Your Mileage May Vary".

 

Ha. Trivial it wasn't. There were two heavy full body IK fight games and stance to stance combat systems with procedural world building, a racing game with multiple characters and multiple vehicles with correct custom physics solution suitable for car companies to feed numbers into and vehicle characteristics out in a simulation, and well, I could list about ten or more other non trivial systems and machine learning modules. I don't do trivial. I do adhere to the Unity API.

Now lets take all your overblown architecture for pointing a gun and pulling a trigger. I would have made hand animations for trigger discipline and a pose for starting a pull and ending the longest possible pull on a trigger. I would have made a BlendTree for the finger layer with the TriggerDiscipllne pose being the default, 0 being the StartTriggerPull and +1 being the longest trigger pull. On the second layer would have been the grip poses for various cants and shapes of the Grip. I would set up the blend tree so +Y gets tighter and -Y gets looser. I would use the X axis for the angle of the wrist to keep the gun level with -X being rotated towards the thumb as far as can be and tilting the wrist forward and down to it's natural extent would be the farthest..I could then put any gun in the hand..set up Mecanim with a Fire bool and feed it manually discovered floats for Grip and TriggerPull. Player presses the button..the TrggerDicipline pose transitions to the pull trigger animation and is limited by the floats fed there. Bullet fires with a raycast of the distance it had traveled in the previous frame so it don't go through anything. Drag and weight and muzzle velocity properly set on an actual rigidbody. I could take into windspeed vector as well with another line of code.

I could set it up in a few hours from scratch and it would handle most any single handed gun or pistol with a single component of less than 100 lines of code..if that... Cocking hammer is just another animation transition which start and end pose can be handled by Mecanim with a bool and a BlendTree float, maybe two. No need for finger IK or all that fuss. But hey.. knock yourself out and make something trivial a rocket science if that pleases you. My pleasure is taking something complex and making it simple and more powerful. That to me is beauty.

 

Bad coders overengineer. It's why I never call myself a good coder, even if my code works 99.9% of the time.

 

This. Your job as a programmer is to solve a problem, and an overly engineered solution is not better than a simple solution

 

What's the problem?

 

An animation that pulls a trigger.

 

Those hacks, like waiting x seconds to workaround (Unity) issues, seem to exist in so many projects...

 

When you don't have access to the engine source code the only way to solve problems that the company hasn't solved yet are to make hacks. That's not to say they wouldn't happen with access to the engine source. They'd just be less common.

 

Or they'd just be in the engine source.

 

Maybe I should revisit that though, that code have been like that for ages. The code fires in a methid with attribute

[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]

This is way too early and the settings will not be applied. I recall I also tried it from Start and Awake but that was also too early. Maybe there is a better event?