[1.12.x] Editor Extensions Redux released (with SelectRoot merge. StripSymmetry & NoOffsetLimits)

[zer0Kerbal]

7 minutes ago, linuxgurugamer said:

Actually, those keys are stock keys, and every once in a while, they go funny.  You didn't need to delete everything, just delete the stock settings file

Would love a small add on to EE : maybe something as simple as a button to reset X/C to work again without having to go out to the main menu or restart the game. Just a thought. Love the mod, really has made life easier in the VAB/SPH.

[linuxgurugamer]

2 hours ago, zer0Kerbal said:

Would love a small add on to EE : maybe something as simple as a button to reset X/C to work again without having to go out to the main menu or restart the game. Just a thought. Love the mod, really has made life easier in the VAB/SPH.

I've often thought about it, I'll  see what I can do

[linuxgurugamer]

New release, 3.3.19.5

• Added button to Settings page 2 to "Reset Symmetry Mode & Angle Snap keys"

[zer0Kerbal]

4 hours ago, linuxgurugamer said:

New release, 3.3.19.5

• Added button to Settings page 2 to "Reset Symmetry Mode & Angle Snap keys"

Now that is a golden service moment! Now to talk to the author of node editor and have 'rename node" added in!

Maholo. This is a great QoL enhancement!

Just updated, had the issue, and 'presto' one or two clicks later all working!

Edited August 7, 2018 by zer0Kerbal

[linuxgurugamer]

5 hours ago, zer0Kerbal said:

Now that is a golden service moment! Now to talk to the author of node editor and have 'rename node" added in!

Maholo. This is a great QoL enhancement!

Just updated, had the issue, and 'presto' one or two clicks later all working!

Your comment came in at an appropriate moment.

[4x4cheesecake]

I found a bug regarding the autostruts applied with the 'mass tweakable' feature. The struts are applied to parts which usually don't allow autostruts on them and some parts creating a NRE in this case.

I got NREs with these parts so far:

• OX-STAT Photovoltaic Panels
• FL-A5 Adapter
• Pegasus I Mobility Enhancer

There are probably more. Strange to say, everything works fine with bigger versions of the parts (Rockomax Brand Adapter 02 and OX-STAT-XL Photovoltaic Panels). The autostruts are applied as well but it doesn't result in a NRE.

A joint can't connect the body to itself.
 
(Filename:  Line: 362)

NullReferenceException: Object reference not set to an instance of an object
  at PartJoint.SetupJoint (Vector3 jointPos, Vector3 jointOrt, Vector3 jointOrt2, Int32 size) [0x00000] in <filename unknown>:0 
  at PartJoint.create (.Part child, .Part parent, UnityEngine.Transform nodeSpace, Vector3 nodePos, Vector3 nodeOrt, Vector3 nodeOrt2, Int32 nodeSize, AttachModes mode, Boolean rigid) [0x00000] in <filename unknown>:0 
  at PartJoint.Create (.Part owner, .Part parent, .AttachNode nodeToParent, .AttachNode nodeFromParent, AttachModes mode) [0x00000] in <filename unknown>:0 
  at Part.SecureAutoStrut (.Part anchor) [0x00000] in <filename unknown>:0 
  at Part+<SecureAutoStruts>c__Iterator3.MoveNext () [0x00000] in <filename unknown>:0 
  at UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) [0x00000] in <filename unknown>:0 

Exploded view of an affected probe (solar panels and adapter), showing that autostruts are applied:

Spoiler

To reproduce, you can attach one of these parts to a tank/probecore/whatever, apply autostruts via mass tweakables (preferable grandparent but it happens also when using root or heaviest) and spawn the vessel on the runway/launchpad.

Output_log: https://www.dropbox.com/s/2cjrdk2eru2qf4q/output_log(EEX-Autostrut).txt?dl=0

Tested in KSP 1.4.3, EEX v. 3.3.19.5.
I've experienced this bug already in 1.4.1 and 1.4.2 but I wasn't able to nail it down.

Edited August 24, 2018 by 4x4cheesecake

[Lisias]

On 8/23/2018 at 10:01 PM, 4x4cheesecake said:

I found a bug regarding the autostruts applied with the 'mass tweakable' feature. The struts are applied to parts which usually don't allow autostruts on them and some parts creating a NRE in this case.

[ CUT ]

Tested in KSP 1.4.3, EEX v. 3.3.19.5.
I've experienced this bug already in 1.4.1 and 1.4.2 but I wasn't able to nail it down.

I'm experiencing it too. KSP 1.4.5, EEX 3.3.19.5 (without EERNoOffsetLimits.zip). And a lot of mods.

It appears to have a issue from the NRE for each part of the vessel - I find a lot of the following on my KSP.log.

[EXC 10:06:34.345] NullReferenceException: Object reference not set to an instance of an object
	KSP.UI.Screens.EditorActionGroups.ConstructGroupActionList ()
	KSP.UI.Screens.EditorActionGroups.ConstructGroupList ()
	KSP.UI.Screens.EditorActionGroups.ClearSelection (Boolean reconstruct)
	ClickThroughFix.CBTMonitor.Update ()

I think I managed to make a correlation with another problem I have - until now, the two vessels that have this problem on the editor, also "jumps up" when launching, one just a few centimeters, other, 1000 meters!  

[LOG 11:00:50.545] [Bimotor PAX Carrier Short Range]: ground contact! - error. Moving Vessel  down -0.452m

[CUT]

[LOG 11:03:26.785] [Blimp MEDEVAC]: ground contact! - error. Moving Vessel  up 998.868m

I'm reluctant on pinpoint EEX as the source of the problem. I just don't remember a single KSP installment of mine that doesn't had it, and this "jumping" issue is new to me (I just realized the NRE recently,  but I can't say if it was there before). Worst, the jumping vessels didn't jumped at all when I created them and for some time after, so it's something that happened between last time I used them and now.

So  this can be something else stomping on EEX's feet (but, granted, can be EEX stomping on someone else's feet - and just know the "right feet" were available!).

I don't have the slightest idea if the following is related or not, but I have also the following anomalies on the offending logs:

(lots and lots of this:)
[WRN 11:03:26.751] Physics.ClosestPoint can only be used with a BoxCollider, SphereCollider, CapsuleCollider and a convex MeshCollider.

[CUT]

(lots and lots of this:)
[ERR 11:04:53.070] Non-convex MeshCollider with non-kinematic Rigidbody is no longer supported in Unity 5.
If you want to use a non-convex mesh either make the Rigidbody kinematic or remove the Rigidbody component. Scene hierarchy path "HL.AirshipEnvelope/model/node_collider", Mesh asset path "" Mesh name "X_001-mesh"

 

[4x4cheesecake]

@linuxgurugamer @Lisias Fixed it and raised a pull request (at least the issue reported by me...lisias, I'm not sure if it will fix all of your NREs as well)

Edited August 28, 2018 by 4x4cheesecake

[Lisias]

2 hours ago, 4x4cheesecake said:

@linuxgurugamer @Lisias Fixed it and raised a pull request (at least the issue reported by me...lisias, I'm not sure if it will fix all of your NREs as well)

Hey, things changed here. The EEX Exception is not more, but now another one took his place:

[ERR 17:43:43.336] Exception handling event onPartJointBreak in class VesselNotDestroyed:System.NullReferenceException: Object reference not set to an instance of an object
  at ContractConfigurator.Parameters.VesselNotDestroyed.OnPartJointBreak (.PartJoint p, Single breakForce) [0x00000] in <filename unknown>:0 
  at EventData`2[PartJoint,System.Single].Fire (.PartJoint data0, Single data1) [0x00000] in <filename unknown>:0 

[EXC 17:43:43.337] NullReferenceException: Object reference not set to an instance of an object
	ContractConfigurator.Parameters.VesselNotDestroyed.OnPartJointBreak (.PartJoint p, Single breakForce)
	EventData`2[PartJoint,System.Single].Fire (.PartJoint data0, Single data1)
	UnityEngine.Debug:LogException(Exception)
	EventData`2:Fire(PartJoint, Single)
	PartJoint:DestroyJoint()
	Part:ReleaseAutoStruts()
	Part:UpdateAutoStrut()
	Part:ToggleAutoStrut()
	EditorExtensionsRedux.EditorExtensions:MenuContent(Int32)
	UnityEngine.GUI:CallWindowDelegate(WindowFunction, Int32, Int32, GUISkin, Int32, Single, Single, GUIStyle)

This appears to be something to be dealt on Contract Configurator now.

The "ground contact", "Physics.ClosestPoint" and "Non-convex MeshCollider" issues are still there. So it's not related with EEX for sure.

[4x4cheesecake]

5 minutes ago, Lisias said:

Hey, things changed here. The EEX Exception is not more,

Glad to hear

14 minutes ago, Lisias said:

The "ground contact", "Physics.ClosestPoint" and "Non-convex MeshCollider" issues are still there.

Usually, I suspect part mods to create these type of issues but I already got one of these 'Non-convex MeshCollider' in a stock game, so I'm no longer sure about that...on the other hand, KSP is not known to be bug free, so I really don't know what to do about it.

[Lisias]

6 minutes ago, 4x4cheesecake said:

Usually, I suspect part mods to create these type of issues but I already got one of these 'Non-convex MeshCollider' in a stock game, so I'm no longer sure about that...on the other hand, KSP is not known to be bug free, so I really don't know what to do about it.

The "Non-convex MesshCollider" is on Unity. Recently (or sort of) they deprecated colliders with a non-convex shape. So a lot of mods that used to work fine with such colliders, ceased to do so. It's interesting that even a few stock ones still have this "problem". Since such colliders are not supported anymore by Unity, I wonder how collisions are being handed on such parts, and how it affects the auto-struts (if affects it at all).

 

[4x4cheesecake]

6 minutes ago, Lisias said:

The "Non-convex MesshCollider" is on Unity. Recently (or sort of) they deprecated colliders with a non-convex shape. So a lot of mods that used to work fine with such colliders, ceased to do so. It's interesting that even a few stock ones still have this "problem". Since such colliders are not supported anymore by Unity, I wonder how collisions are being handed on such parts, and how it affects the auto-struts (if affects it at all).

 

Thanks for the infos

When it happend to me on a stock install, I wasn't able to replicate the issue so probably it was just a slightly corrupted savegame. It happend when I tried to undock a lander from the mothership: I got the decoupler sound, engines of the lander disappeared from the staging bar (because I still controled the mothership) but the lander didn't separate. Some timewarp separated them visually, but not physically...I wonder if some autostruts kept them connected.

[Lisias]

And, yeah. I still have problems even with the fix from 4x4cheesecake. But, and it's almost for sure, it's something related to another mod stomping on EEX's feet.

I'm monitoring the Ship's .craft directly now. There're something preventing the EEX to disable all the autotruts - some of them are still on Grandparent. I wonder if it would not worth to "try catch" the inner loop to be able to narrow down the parts being affected. Since EEX is a Editing time plugin, some performance penalty are acceptable in order to help debugging and trouble-shooting.

Anyway, by hand or by luck, I will narrow down the exact part that triggers the problem. I will follow up later.

— POST - EDIT --

By the way, I disabled by hand all the autostruts on the vessel file, and now I'm getting:

[LOG 20:00:59.483] [Blimp MEDEVAC - 2]: ground contact! - error. Moving Vessel  up 998.942m
[LOG 20:00:59.485] Unpacking Blimp MEDEVAC - 2

[CUT]

[LOG 19:59:55.319] [UIMasterController]: HideUI
[ERR 19:59:55.672] Triggers on concave MeshColliders are not supported

[CUT]

[ERR 20:01:03.867] Non-convex MeshCollider with non-kinematic Rigidbody is no longer supported in Unity 5.
If you want to use a non-convex mesh either make the Rigidbody kinematic or remove the Rigidbody component. Scene hierarchy path "HL.AirshipEnvelope/model/node_collider", Mesh asset path "" Mesh name "X_001-mesh"

 

This vessel worked fine last time I used her on a Mission. But reading the .craft file, it appears to be happened on the KSP 1.4.3 times, when I started this Career…

Edited August 28, 2018 by Lisias
new info

[4x4cheesecake]

10 minutes ago, Lisias said:

There're something preventing the EEX to disable all the autotruts - some of them are still on Grandparent

Does it happen to parts which don't allow autostruts and did you create the craft before using my fix? If yes, it is caused by my patch because the 'no autostrut' feature now ignores these parts too.

I also just noticed a visual bug where autostruts are displayed even though there are none but it just happens with the 'heavy' ones and with crafts that uses 3 different parts or less...I have absolut no idea how this happens^^

[Lisias]

39 minutes ago, 4x4cheesecake said:

Does it happen to parts which don't allow autostruts and did you create the craft before using my fix? If yes, it is caused by my patch because the 'no autostrut' feature now ignores these parts too.

Thinking is a very healthy habit. I should do that more frequently.  

Yeah. That's exactly it. Moreover, the Contract Configurator exception almost certainly is also due that!  

I'm prone to conclude that something changed on KSP 1.4.4 . The behaviour in question is novelty, but this savegame and this vessel were "in production" since the 1.4.3 era and they were working fine (including the Contract Configurator).

— POST - EDIT --

Ladders, Struts and Solar Panels are not AutoStruttable.  

Edited August 28, 2018 by Lisias
more info

[4x4cheesecake]

1 minute ago, Lisias said:

Thinking is a very healthy habit. I should do that more times.  

Yeah. That's exactly it. Moreover, the Contract Configurator exception almost certainly is also due that!  

I'm prone to conclude that something changed on KSP 1.4.4 . The behaviour in question is novelty, but this savegame and this vessel were "in production" since the 1.4.3 era and they were working fine (including the Contract Configurator).

I have updated my pull request and removed the additional logic operator from the 'No Autostrut' feature so you can remove autostruts from all parts again. I thought it will break things as well because the mod basically applies autostruts to all parts just to remove them in the next step (The comments somehow explain why this must be done in this way but I don't understand all of it ).
In my test, it works fine though but I would be glad to hear some results from you as well

 

[Lisias]

6 minutes ago, 4x4cheesecake said:

In my test, it works fine though but I would be glad to hear some results from you as well

It will break on Contract Configurator (see my post above).

You wil need to do something like this:

		RefreshParts();
		foreach (Part p in parts)
		{
			try {
				if (!doNotMessWithAutoStrutModes.Contains(p.autoStrutMode))
				{
					p.autoStrutMode = Part.AutoStrutMode.Grandparent;
					p.ToggleAutoStrut();
					// blah blah blah blha
				}
			} catch (Exception as e) {
				Debug.Log("Oh my God, they killed Kenny!!!");							
			}

To prevent that the breakage of some other mods interrupts the process. Replicate in all other commands.

[4x4cheesecake]

25 minutes ago, Lisias said:

To prevent that the breakage of some other mods interrupts the process. Replicate in all other commands.

Have you tried this configuration for your setup? Right now, I cannot reproduce the NRE so I cannot test the try-catch block.

[Lisias]

30 minutes ago, 4x4cheesecake said:

Have you tried this configuration for your setup? Right now, I cannot reproduce the NRE so I cannot test the try-catch block.

Find a ladder or solar panel on the vessel, put "autostrutMode = GrandParent" on it.  Or wait a couple hours, I'm on it.  

— POST - EDIT — 

Make it 3 or 4, my KSP just crashed on my face.  

Edited August 29, 2018 by Lisias
uh… Kaboom. :/

[4x4cheesecake]

22 minutes ago, Lisias said:

Find a ladder or solar panel on the vessel, put "autostrutMode = GrandParent" on it.  Or wait a couple hours, I'm on it.  

So, I loaded the original EEX, put autostruts on solar panels and ladders so it's bugged again but no complains about Contract Configurator in the logs. Then I replaced the the EEX dll with mine, loaded the bugged Vessel and still no NRE (but removing wrong struts and replacing them with correct ones works like a charm ). Guess, I'll wait for you

[linuxgurugamer]

New release, 3.3.19.6

• Thanks to @4x4cheesecake  for these fixes:
  • Added an additional logical operator to prevent autostruts beeing applied to parts which don't allow them.
  • Fixed a visual issue regarding the 'Fine Adjustment' window. It's no longer flickering when dragging it around.
     

Edited August 29, 2018 by linuxgurugamer

[Lisias]

1 hour ago, 4x4cheesecake said:

So, I loaded the original EEX, put autostruts on solar panels and ladders so it's bugged again but no complains about Contract Configurator in the logs. Then I replaced the the EEX dll with mine, loaded the bugged Vessel and still no NRE (but removing wrong struts and replacing them with correct ones works like a charm ). Guess, I'll wait for you

Problem is…. Here too.   CC is not crashing at the moment on that very same craft it was crashing some hours ago! 

I spent some time trying to figure out why, and I think I realized the reason: my last debugging session messed up my save game, and all my accepted contracts were deleted. So I have no contracts running right know. I remember that one of that contracts demanded a flight to be completed without breaking a single part (I was stuck on exactly that one, my planes have that weird tendency to hug the grass), so it make sense that CC would monitor the Joints! A broken joint would invalidate the contract - even if the part is not destroyed.

I also remember failing a bunch of contracts about landing a aircraft without breaking parts (all at the same time!) when two boosters collided after  separation while kicking a rocket out of this world, so the Contract's checking happens all the time for every active contract.

I don't know, yet, how to mangle the savegames so I will pursue a CC contract with that criteria in order to check the thesis.

However, the following exception is being raised, apparently once for each offending part, when launching the vessel setting all the parts to AutoStrut Grandparent (probably all of them, but I didn't tested every single case) on the previous EEX:

[EXC 00:33:15.856] NullReferenceException: Object reference not set to an instance of an object
	PartJoint.SetupJoint (Vector3 jointPos, Vector3 jointOrt, Vector3 jointOrt2, Int32 size)
	PartJoint.create (.Part child, .Part parent, UnityEngine.Transform nodeSpace, Vector3 nodePos, Vector3 nodeOrt, Vector3 nodeOrt2, Int32 nodeSize, AttachModes mode, Boolean rigid)
	PartJoint.Create (.Part owner, .Part parent, .AttachNode nodeToParent, .AttachNode nodeFromParent, AttachModes mode)
	Part.SecureAutoStrut (.Part anchor)
	Part+<SecureAutoStruts>c__Iterator3.MoveNext ()
	UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)

So the issue with non-autostrutable parts being autostrutted is still reproducible on the previous EEX, what confirms the fix on the new one.

As soon as I manage to get a Contract failing with that exception above, I'll try that try-catch stunt to recover mangled vessels.

[Lisias]

I came to this:

if (GUILayout.Button("No Autostruts"))
{
	RefreshParts();
	foreach (Part p in parts)
	{
		if (!doNotMessWithAutoStrutModes.Contains(p.autoStrutMode)) try 
		{
			p.autoStrutMode = Part.AutoStrutMode.Grandparent;
			p.ToggleAutoStrut();
		}
		catch(Exception e)
		{
			p.autoStrutMode = Part.AutoStrutMode.Off;
			Debug.LogException(e);
		}
	}
	OSDMessage("Autostruts turned OFF for all current Parts in Vessel (except forced).");
}

The exception is being raised by p.ToogleAutoStrut(). So, if anything goes wrong, the p.autoStrutMode will have a improper value, and this is what will be saved to file - perpetuating the error.

This way we would have the Exception logged for eventual analysis, and we will also ensure a safe value on the Twekable. User should save the vessel right now (preferably with a new name), and then reload it. Just to be on the safe side.

Edited August 30, 2018 by Lisias
Clicked on save too soon.

[linuxgurugamer]

12 hours ago, Lisias said:

I came to this:

if (GUILayout.Button("No Autostruts"))
{
	RefreshParts();
	foreach (Part p in parts)
	{
		if (!doNotMessWithAutoStrutModes.Contains(p.autoStrutMode)) try 
		{
			p.autoStrutMode = Part.AutoStrutMode.Grandparent;
			p.ToggleAutoStrut();
		}
		catch(Exception e)
		{
			p.autoStrutMode = Part.AutoStrutMode.Off;
			Debug.LogException(e);
		}
	}
	OSDMessage("Autostruts turned OFF for all current Parts in Vessel (except forced).");
}

The exception is being raised by p.ToogleAutoStrut(). So, if anything goes wrong, the p.autoStrutMode will have a improper value, and this is what will be saved to file - perpetuating the error.

This way we would have the Exception logged for eventual analysis, and we will also ensure a safe value on the Twekable. User should save the vessel right now (preferably with a new name), and then reload it. Just to be on the safe side.

Certainly safe enough, go ahead and submit a PR

[Lisias]

3 hours ago, linuxgurugamer said:

Certainly safe enough, go ahead and submit a PR

I'm on it.

However, my vessels are quivering when they are near the Karman Line, and I never saw that before. The parts "flickers" and "tremble", and it appears to affect the face's normals on rendering.

I'm trying to figure out if my change is related, if it's a colateral effect from Kerbal Joint Reinforcement, or it's something new and completely unrelated with this!