On EULA Trolling :: A sad history about immaturity and ego trips

To be read listening to Sowing the Seeds of Love, Tears for Fears.

Time to eat all your words
Swallow your pride
Open your eyes

Chapter 1: Sowing the Seeds of Bitterness

When KSP 1.4.0 came, the change from Unity 5 to Unity 2017 caused some breakage. It was expected as it was a major version change on an engine that changed a lot.

Such an endeavour, obviously, is pretty hard to accomplish by itself. But on a problematic development process and less than adequate technical leadership, things can go down trough the tubes pretty badly.

One of these problems was that apparently the development was crunched to the limit, and some API calls were left unimplemented... One of the victims of the problem was TweakScale (that was suffering badly both from the new KSP problems but also from some terrible practices on the add'on scene).

(I'm not implying this was the worse problem, not by a mile - it's only the one I know pretty well, since I was - and still is to this date - TweakScale maintainer)

Let's talk about this one:

FindAttachNodeByPart is M.I.A.

In April/2018, on the early 1.4 era, a very interesting feature from TweakScale was decommissioned on this commit by the previous maintainer.

I never understood the reason until recently, when I finally managed to resurrect it on this commit.

(this is not a criticise, the dude did what he thought was the best at that time - it worths to mention that I only got time to be confident enough to reimplement it 3 years later, not because it was a hard feature to implement, but because I wasn't understanding why it stopped work and had more urgent issues to handle. Once I tacked down the critical problems, I got time to dig into the problem)

As time gone by and another major change on Game Engine happened (KSP 1.8, switching to Unity 2017), I was able to understand what had happened. This is what I found:

When KSP 1.4.0 came out, TweakScale broke terribly for a lot of reasons. Some were TweakScale's fault (race conditions, barely legal behaviours on Unity5 that became illegal on 2016, etc).

But not all of them.

Some API calls just ceased to work and well, TweakScale was calling these ones for a reason. Some of that calls are returning NULL no matter what I shove on the parameters even today, what hints me the function was just not coded at all and short-circuited to return NULL (I would prefer the function being deleted, it would had saved a lot of trouble).

One of the worst mistakes on Project Management is the misunderstanding of the Pareto Principle. Pareto postulated that 80% of the consequences came from 20% of the causes. So, if you manage to prevent that 20% of causes from happening, you get rid of 80% of all problems of the project, saving time.

BUT... Modern Project Management, I just don't know how, inferred from the Pareto Principle that it's enough to deliver 80% of the project to have success, solemnly ignoring that the client has paid for 100% of the project. And I'm not kidding, I really had worked on projects where the Manager came with this stunt as a measure to meet tight deadlines.

So, and I'm guessing now (besides being a very educated guess), when KSP was migrated from Unity5 to Unity 2017 for the 1.4.0 release I'm reasonably sure that they hadn't enough time to close all the tasks, so some tasks were left behind. Less than ideal, but if the tasks at hand are enough to deliver a viable product, it's almost impossible for a Manager to postpone the deliver.

Problem - someone had worked on all that use cases on the Unity5 times for a reason, and by shunting some of them, something stopped working for sure. Since a lot of code for the core game were rewritten (as the modules for wheels, for chutes and for wings and control surfaces), the dev guys avoided using the shunted calls - but the rest of the World (we, add'on authors) ended up high and dry on this stunt.

Obviously, not 100% of the KSP guts were rewritten - so it's probable that some of the shunted functions were harming the game too, but not on an obvious way. And as an incredible sequence of bugs were being discovered over time, they were being tackled down on the spot they were detected, instead of solving the root cause (what would also preemptively fix problems not yet discovered).

(full article published on Forum )

I would be naive on thinking that this was the only case, and that TweakScale was the only victim. A lot os add'ons broke badly on the 1.3 -> 1.4 transitions (and, just to be fair, a good part of them due changes on Unity too). The cost we had paid for the development crunch was high - not exactly due the crunch itself, but because how the crunch were hidden from us.

Had they just removed the shunted API calls with a Release Notes entry like "guys, we had to remove some less used API calls due scheduling demands, sorry for that", and we would had known what was happened and what we had to do - we could just write an library with the missing calls and so the fix would be simple for everyone involved.

But without knowing what was happening, most Authors just did as the previous TS maintainer - due the exact same constraints from RL (we all have to feed our sons and loved ones, right?), they just removed affected features to satisfy the increasing pressure from the Users to have the add'ons working on 1.4 (that was not a bad series, there're pretty good features on it, by the way. I played 1.4.5 for a very long time).

And, obviously, this had an impact on the user base. New kids on the block (as I was at that time) didn't noticed, but old school players did - and they react less than pleasantly. I wish I had the knowledge I have today at that time - frankly, I would had wrote way less posts supporting Squad than I had (not because most people there didn't deserved, they did - but because the Team as a whole perhaps didn't... More about it on a new chapter).

The lesson that should be learnt here (but wasn't) is that the Pareto Principle was never meant to be used to cut down scope of projects, but to minimize the efforts to fulfil the tasks needed for the project (you prevent 20% of some key problems, you save 80% of the trouble). Pareto was a Civil Engineer and worked on the rail industry - and he delivered 100% of the railroads he built.

Lisias
2021-0910