Jump to content

The Trouble with the Unity upgrade


Recommended Posts

I've been working my way through all my mods, and was pretty happy with the way things were going.  I had actually finished updating all the code-based mods and was proceeding on the Part-only mods, when a bug report made me aware of a significant issue with a few mods.  So I went ahead and built a full debugging environment, loaded up my new career game and took a look at the log file.

Initially I thought it was just a bug, but then I found the same problem in 4 mods which were not mine, and 3 of mine, so I knew there was something pervasive and started to look.  Then I started realizing that there had been various reports of KSP just hanging, just before it got to the main menu.

As I started looking into this, I found that my new career install was hanging about 3/4 of the time before the main menu, but when I removed the bad mods (at the time, a total of 7 in a 150 mod install), the hangs disappeared.   I realized I was onto something rather big.

These were errors which weren't showing up in the regular log file, I needed to be running a debug version to see the errors; the debug version is much more verbose in logging.

What I found was that as a result of the Unity upgrade, a lot of what used to be acceptable coding was no longer acceptable.  Actually, in one sense the coding never should have been considered acceptable, but it worked, so was never an issue until now.

I broke the issues down into the following categories:

  • UnityException: get_dataPath is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead.

A somewhat misleading description, most often caused by trying to reference KSPUtil.ApplicationRootPath in either a constructor or as a property in a MonoBehaviour class

  • UnityException: RandomRangeInt is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead.

This happened a few times, RandomRangeInt was being called in either a constructor or as a property in a MonoBehaviour class

  • UnityException: SupportsTextureFormatNative is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead. 

Very obscure, took a while to track down.  A Texture2D or Texture3D was being initialized in either a constructor or as a property in a MonoBehaviour class

  • Exception loading ScenarioModule *********** System.TypeInitializationException: The type initializer for *********.********* threw an exception. ---> UnityEngine.UnityException: get_dataPath is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead. Called from MonoBehaviour ********** on game object 'ScenarioLogic'.

A very obscure message.  Turned out that the original mod was written as a ScenarioModule and worked well, but in the updated game it seems that things which were being done inside the ScenarioModule which should have been in a MonoBehaviour were causing problems.  The symptom of this was getting null refs when attempting to enter some or all of the buildings at the KSC

  • Unity not being thread safe

This was a problem with the KSP-AVC and MiniAVC mods.  I had seen a couple of messages about MiniAVC not working, and was planning on getting to it when finished with all the updates.  

Tracking these issues down in over 160 mods, written by at a guess of over 100 authors, turned out to be a major timesink.  As of now I'm pretty sure I've caught most if not all of these issues in my mods.  In total about 30 of my mods, both adopted and ones that I write, were affected.  I also did some work on other author's mods to fix the issues and have submitted PRs (fixes) to all of those authors.  

Please note that while I listed the majority of the issues above, I think there were a few which I fixed which were mostly one-offs.

The main reason this happened now was as a result of the Unity upgrade.  The new version of Unity fixed a lot of bugs as well as adding significant performance improvements.  Many of the issues I found and corrected were actually poor coding practice, but was accepted because Unity allowed it.  There were times in the previous version of Unity that KSP used that these issues arose, but that was in some very limited and specific instances.

For myself, everytime I adopt a new mod moving forward, I'll be testing it in a debug install to catch any issues before it gets released.

Link to post
Share on other sites
1 hour ago, Arco123 said:

I also got the 2d bug as well when trying (Still trying) to find out what mod caused all the lag with solar panels and not producing power.

Post a list of your mods, if you have a .ckan file that would be better

Link to post
Share on other sites
10 hours ago, linuxgurugamer said:
  • Unity not being thread safe

I'm still trying to understand this behaviour, but my tests apparently tells me that is not exactly "threading safe" issues, but "threading bounds violations" issues.

A long time ago, in a galaxy far, far away :P I was programming in Symbian (and late for Bada… urk..), and these guys had a problem - the thread used for instancing your program was not the thread used to run your objects. So you could not make some calls (in special, memory allocation, as your heap and stack was not created yet, as your running thread was not created yet!) on the object constructor. So they created a hook called "Create" (if memory serves me well) where you should put any initialization code that would need using a stack and/or heap - as system calls). You could initialize variables and static memory on the Constructor, however.

This is interestingly similar to the Awake stunt.

On Android, at least on the 2.3 times (and later on 4.x, the latest one I messed with), we had another restriction (Java2ME programmers also had it - yeah, I'm that old!): you could not make calls or update UI objects outside the UI thread. This is how they prevented to have to shove mutexes on the UI objects, what would make the UI somewhat cranky to the user. So, if you would need to create threads to do some grunt work (and we always had to create threads to do grunt work, otherwise that work would be executed on the UI's thread, and again you would have a cranky UI), any update to the UI needed by that thread of yours would need to be inside a Runnable and then inserted into a queue loop, that the UI thread would periodically flush. So, yeah, asynchronous UI updates for you every time you would need to do some I/O or heavy computation. [ If you needed to be sure the current thread would continue only after the UI is updated, you had to create a mutex, shove the Runnable on the queue (with code to free the mutex on a finally - to prevent deadlocks), and then lock on the mutex. Somewhat messy sometimes, but it did had the work done. ]

It's my understanding that Unity (or at least KSP) is/are exploring multiple threads since KSP 1.4, and so apparently different hooks are being called from different threads, and so your code would be using different stacks depending of who is calling your hook.

Edited by Lisias
tyops as usulla… (and a small addendum)
Link to post
Share on other sites

Ima post a list of them along with the log. A couple pics as well. I'm away from my pc so I cant right now. But is there anything else that you need? I'm thinking it's koperous or planet shine but Planet shine has already been tested. I do have 57 mods...

Also, where's the .CKAN file... I just got it.

Also, the bug is like this. Whenever I extend some solar panels (Any kind. Only ones that ARE solar.) or all of them. My frame rate drops to well below 10 fps. About 5-7. I click on them and they aren't producing power. Even when in space and pointed at the sun. So, I checked the console to find some red message spamming it. (I'll post that soon.) Whenever I retract them it stops and doesn't occur. But if I extend them... (It happens...) 

Also, it happens randomly without extending them even if you don't have any. 

Edited by Arco123
Link to post
Share on other sites
31 minutes ago, Arco123 said:

 I'm thinking it's koperous

I hope you dont mean Kopernicus... That mod has not been updated for 1.8.+, which means *any* planet, system, or other mod that depends on it will not work in 1.8.+, and most likely cause ALL kinds of issues... Thats why Kop is version locked: because it can wreak havoc in an incompatable KSP version install

Plus, i vaguely remember some mod cauisng that solar panel issue, and I also seem to feel like it it *was* a Kopernicus issue? vOv

Edited by Stone Blue
Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...