NullReferenceException
  at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject ()

  at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0

  at FerramAerospaceResearch.FARPartGeometry.VehicleVoxel.UpdateFromMesh (System.Object meshParamsObject) [0x00000] in <filename unknown>:0
UnityEngine.Debug:Internal_LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
FerramAerospaceResearch.FARThreading.ThreadSafeDebugLogger:Update()

Steps to reproduce

• Install FAR
• Launch this craft: Auto-Saved Ship.zip (only stock and SSTU parts)
• Activate first stage, then activate the launch escape system (stage 2)
• NRE will appear on debug

Here is what I see on the debug log before the NRE appears:

Destroying game object: FairingPanelPivot (UnityEngine.GameObject)
creating procedural mesh with vertex count of: 200
Updating vessel voxel for Untitled Space Craft

@ferram4 says that all FAR's voxelization is done on a copy of the model's geometry, so destroying a GameObject shouldn't break anything, but a few things might

• Creating a mesh with a null triangles array
• Nulling a geometryMesh belonging to one of the parts
• Other things of that nature

I'm not sure exactly what part is causing this, at any rate it seems to depend on the exact staging sequence. Oddly enough I haven't been able to reproduce on any craft without the LES, even though that doesn't have any procedural meshes.

After looking through the FAR source a bit to find how it interacts, I am still thinking this is related to my deleting game-objects (and their meshes).

Far does duplicate/copy the mesh data (so even if I delete the mesh, the copy still exists), however it appears to add a direct reference to the original mesh's transform / game object. And this is what is getting deleted, and causing the null-ref.

The offending reference is seated at:
https://github.com/ferram4/Ferram-Aerospace-Research/blob/master/FerramAerospaceResearch/FARPartGeometry/GeometryMesh.cs#L93

Without major overhauls on my end of things, I do not think there is a way that I can solve this. (I do want to make some of these changes eventually, but requires a near complete rewrite of how I handle dynamic objects).

However, it would be a single null-ref check in the FAR code to catch the case of a mesh having its game-object deleted.

Could simply add a null-check on the mesh's transform at/near this line:
https://github.com/ferram4/Ferram-Aerospace-Research/blob/master/FerramAerospaceResearch/FARPartGeometry/VehicleVoxel.cs#L1588

I'm going to -try- to get this cleaned up on my end, for the fairing module at least, for this weekends' release (if the problem is what I think it is).

No guarantees though; it might turn out to be a different problem entirely, though all signs point towards the game-object-being deleted as the problem.

Thanks for filing the issue :)

Yes, chances are that it is related to my destroying that fairing mesh (or rather, its game object). Although, I'll need to play around a bit to know for certain.

I've been getting an itch lately to clean that up -- I really need not destroy the entire game object, but could merely replace the mesh that its mesh-renderer uses. Would also be a bit better performance wise; object creation and destruction are some of the slower bits in Unity.

Thanks for the craft file, will likely investigate this issue sometime this week. Sat. morning is the likely candidate, as that is when I would have the free time to do the game setup and extensive testing.

Okay, so based on what ferram4 told me yesterday, I was under the impression that all the meshes were copied in the main thread, and that the threaded parts only dealt with those copies, but clearly that isn't the case.

Working on cleaning this up on my end now, by persisting the game-objects across fairing rebuilds. Should not be craft-breaking if it works out as planned, and might have a slight boost to performance as well :)

Indeed, this fixes the problem. Need to do a bit more testing to make sure I've implemented it properly across all effected modules (node-fairing, procedural decoupler, interstage decoupler), and that there are no bad side-effects.

Should be available with the update later today.

Also at some point would like to look into the 'degenerate triangle' issue -- generally solvable, but I'll need to narrow down what configurations/parts are causing it.