Jump to content

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


Recommended Posts

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.

Link to post
Share on other sites
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

Link to post
Share on other sites
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 by zer0Kerbal
Link to post
Share on other sites
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.

Link to post
Share on other sites
  • 3 weeks later...

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

py62Bae.png

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 by 4x4cheesecake
Link to post
Share on other sites
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. :P

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 ()

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! :D 

[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"

 

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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).

 

Link to post
Share on other sites
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.

Link to post
Share on other sites

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 by Lisias
new info
Link to post
Share on other sites
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^^

Link to post
Share on other sites
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. :D 

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 by Lisias
more info
Link to post
Share on other sites
1 minute ago, Lisias said:

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

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 :P ).
In my test, it works fine though but I would be glad to hear some results from you as well :)

 

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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 by Lisias
uh… Kaboom. :/
Link to post
Share on other sites
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 :D). Guess, I'll wait for you ;)

Link to post
Share on other sites

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 by linuxgurugamer
Link to post
Share on other sites
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 :D). Guess, I'll wait for you ;)

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

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.

Link to post
Share on other sites

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 by Lisias
Clicked on save too soon.
Link to post
Share on other sites
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

Link to post
Share on other sites
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! :) 

Link to post
Share on other sites

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...