[1.12] Extraplanetary Launchpads v6.99.3

[Angelo Kerman]

On 3/1/2022 at 4:20 PM, Kirbin Kerman said:

Running into a pretty base-breaking glitch with EL. I'm currently running 6.99.0, because someone told me the glitch was exclusive to 6.99.1, but it's present on both versions for me.

The bug: It seems to have something to do with workshops created by EPL vs workshops launched from the KSC, but sometimes, a given vessel becomes permanently unable to have productivity. The vessel can be listed as having productivity on the PAW, but it can never build anything, because productivity is set to "----" in the EL interface whenever I try to build anything. Any ideas?

EDIT: I've done more experimenting. Using KIS, the "---- productivity" bug can be banished if I take apart the entire structure and re-assemble it in such a way that the root part has changed, but the issue seems to come back on scene change. There are no relevant error in the log file, but I can provide it anyways.

EDIT 2: I did some more experimenting and traced down the exact circumstances of the bug: If the root part of the craft is a part that has been spawned in from an EPL site, then whenever the vessel is loaded back in, the productivity is set to ---- until it becomes a new vessel (root part change). However, it works PERFECTLY FINE if the root part of the craft originates from the KSC. No, I don't know either

I seem to have run into this as well. I'm running 6.99.1, and when I use my custom disposable pad, installed via stock EVA Construction, I run into this error when I tap on Show UI. I checked my logs, this is what I'm seeing:

[EXC 20:35:51.832] NullReferenceException: Object reference not set to an instance of an object
	ExtraplanetaryLaunchpads.EL_Utils.MakeSprite (UnityEngine.Texture2D tex) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELBuildCraftView.UpdateFlag () (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELBuildCraftView.UpdateControl (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	UnityEngine.Events.InvokableCall`1[T1].Invoke (T1 args0) (at <12e76cd50cc64cf19e759e981cb725af>:0)
	UnityEngine.Events.UnityEvent`1[T0].Invoke (T0 arg0) (at <12e76cd50cc64cf19e759e981cb725af>:0)
	ExtraplanetaryLaunchpads.ELPadView.set_control (ExtraplanetaryLaunchpads.ELBuildControl value) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELPadView.SetControl (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELBuildManagerView.SetControl (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELMainWindow.SetControl (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELWindowManager.ShowBuildWindow (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELDisposablePad.ShowUI () (at <26d81185874f4d28baa663727b80c757>:0)
	BaseEvent.Invoke () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	UIPartActionButton.OnClick () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	UnityEngine.Events.InvokableCall.Invoke () (at <12e76cd50cc64cf19e759e981cb725af>:0)
	UnityEngine.Events.UnityEvent.Invoke () (at <12e76cd50cc64cf19e759e981cb725af>:0)
	UnityEngine.UI.Button.Press () (at <5336a8686ff14f17888ce9a9f44f29bc>:0)
	UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) (at <5336a8686ff14f17888ce9a9f44f29bc>:0)
	UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) (at <5336a8686ff14f17888ce9a9f44f29bc>:0)
	UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) (at <5336a8686ff14f17888ce9a9f44f29bc>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.EventSystems.EventSystem:Update()

I really should figure out a visual studio project for EL, then I can help debug the issue.

[schlosrat]

On 3/4/2022 at 3:56 PM, schlosrat said:

OK, so removing TweakScale solves my vessel loading issue and I can build things. Great!

Now why are they coming in so dang high?

My modular base sections have FASA launch clamps under then to hold them in place. I've built these before, and always in the past the first one I build comes in at the same height above the origin stake as it is off the floor of the VAB. Now they're coming in at a silly height that isn't especially useful as the built in ladders can't reach the ground now. I even tried adding a -Y Bounds stake (which I had been afraid would cram the thing right on the ground), but it still came in at the same silly height.

Any clues why my build is coming in so high? Is it somehow related to the height above ground of the EL Survey Station in the lander? It almost looks like those might be related, but why?

Hi all,

Still trying to figure out why a first vessel comes in so dang high. This happens with both vessels built using launch clamps (shown in post quoted above) and those that employing more traditional launfing gear where the vessel will appear above the survey stake and then slowly drop in a la Vessel Mover's Place Vessel.

 

On the odd chance this was something that could be controlled via settings I've poked around a bit in settings.cfg within the PluginData folder. Is it correct to understand these are the only user configurable settings? What's making craft start so high nd then drop in? Can this be switched off to go back to the old way when needed.

The settings I've found in settings.cfg look like this:

UseKAC = True
KACAction = KillWarp
PreferBlizzy = False
ShowCraftHull = False
DebugCraftHull = False
WindowManager
{
    MainWindow
    {
        position = -574.324829,292.618164
        visible = False
    }
    SettingsWindow
    {
        position = 0,0
        visible = False
    }
    ShipInfo
    {
        position = 0,0
        visible = False
    }
}

What's the SettingsWindow and how do I get that up on the screen?

 

[taniwha]

On 3/5/2022 at 2:25 AM, schlosrat said:

OK, so I buildt the first section on landing legs since EL is determined to start craft up high and then lower them into place (nice touch, great for vessels, but can we turn that off?)

EL doesn't actually do that. Rather, it finds the base of the vessel's bounding box and uses that to place the vessel. There are two possibilities: the bounding box is wrong (or really, the bounding box of at least one of the parts, since EL builds the box from the part bounding boxes), or there's a bug in the placement code.

On 3/5/2022 at 12:56 AM, schlosrat said:

OK, so removing TweakScale solves my vessel loading issue and I can build things. Great!

TweakScale has always been a thorn in my side: when I went to add support for TS to EL, I found that it broke KSP's camera after reverting to the VAB (or SPH), and when I reported the issue, I was told it was a KSP bug and the TS author (at time time) refused to do anything about it. Thus I abandoned all pretense of supporting TS. Sorry excuse, sure, but that's the way it is.

On 3/5/2022 at 2:25 AM, schlosrat said:

Now it's curious that my modular base craft are coming in oriented wrong. Surely the orientations on the micropads hasn't changed has it? That seems astonishingly unlikely, but I suppose it's possible.

I'm pretty sure I haven't changed the orientation of the micropads, but rotations can be a tricky thing, especially if it's a 180 degree rotation (rotation axis is undefined in such a case when you have only the two reference vectors (current and desired direction): rotations are intuitive only in 2d (ie, there is no 3rd dimension)). It's for this reason the pads have extra geometry internal to them making their orientation semi-apparent (can't tell which direction is which, but you can tell when you've rotated 90 degrees) when placing them using older versions of KIS (before stock inventories, haven't tried with more recent KIS). Ie, build goes wrong, load before building, reorient pad, try again. However, I don't think I've ever been out by 90 degrees, only 180 due to top vs bottom node selection.

Hmm, actually, I might have changed something: it looks like I tried to ensure that starboard (VAB door side of default orientation) stays starboard when flipping, and starboard is aligned with the red arrow (yeah, a bit weird when the port navigation light is red). This code always has me scratching my head (and some of my git log messages aren't so great in hindsight).

Quote

    Ensure the root part is correctly oriented
    
    This works when the root part's forward axis is at least 30 degrees away
    from the node axis (forward (+Z) is towards the VAB north wall, thus
    is many parts' ventral side). This means that when the bottom node is
    used, the ventral side aligns with the micro-pad's blue diamond and the
    starboard side aligns with the red diamond (hmm... that's a bit off
    since red is port and green is starboard...)
 

 

Quote

    Implement starboard alignment
    
    This applies when the root part's forward axis is aligned with the node
    axis: instead of keeping up as up, the micro pad keeps starboard as
    starboard. Except there's a minor bug...
 

What was the bug? (next commit does fix a bug that's related to nodes and orientation, but...)

On top of that, I haven't worked on the code since November 2020, and everything I knew about it has been pushed out of my head.

On 3/8/2022 at 1:43 PM, Angel-125 said:

I really should figure out a visual studio project for EL, then I can help debug the issue.

This shouldn't be that hard: just include all the .cs files mentioned in Source/Makefile.and KodeUI.inc (note: I use a symlink in Source to the KodeUI source directory, check README.txt for KodeUI related instructions), and I directly reference the dlls in KSP's KSP_Data/Managed directory.

[taniwha]

On 3/8/2022 at 1:43 PM, Angel-125 said:

[EXC 20:35:51.832] NullReferenceException: Object reference not set to an instance of an object
	ExtraplanetaryLaunchpads.EL_Utils.MakeSprite (UnityEngine.Texture2D tex) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELBuildCraftView.UpdateFlag () (at <26d81185874f4d28baa663727b80c757>:0)

I just had a quick look at that code and it seems the vessel has specified a flag that doesn't exist, or things have changed in how to fetch a flag texture, but either way, I forgot to check that GameDatabase.Instance.GetTexture() didn't return null.

[Lisias]

On 3/19/2022 at 8:11 AM, taniwha said:

TweakScale has always been a thorn in my side: when I went to add support for TS to EL, I found that it broke KSP's camera after reverting to the VAB (or SPH), and when I reported the issue, I was told it was a KSP bug and the TS author (at time time) refused to do anything about it. Thus I abandoned all pretense of supporting TS. Sorry excuse, sure, but that's the way it is.

LaunchPads has been an issue for me too, but instead of complaining about how a thorn it's being to me, I diagnosed the problem and supported the users the same.

KSP IS BUGGY, TERRIBLY BUGGY. And these pesky bugs are affecting innocent add'ons due common mishaps on one of them, as failing to load an DLL - leading everybody else that tries to load something to bork too.

So instead of blaming the messenger (usually TweakScale, as it has a hell of a big mouth, yelling on anything that smells funny), I invest a bit more of time to diagnose the root cause of the problem and fix it when possible, or advise a workaround when needed.

About the Camera bug, well.. It is KSP related not TweakScale. You are blaming the symptom, not the disease. So, without further information, there's really not too much than an author can do about. Since the Camera's movement is tied to the craft total mass and size, and since TweakScale (obviously) changes mass and size of parts, it's obvious than any bug on the Camera's code will be triggered by TweakScale. What doesn't means that TweakScale can do something about!!!!

About authors deciding not to support TweakScale, it not a problem neither. TweakScale Companion Program is meant to fulfil this role, providing proper crafted and tested patches for 3rd parties, avoiding 80% of the problems TweakScale had in past - specifically, bad patches done by less than careful add'on authors.

 

[Lisias]

On 3/3/2022 at 11:44 PM, schlosrat said:

The apparent TweakScale incompatibility is a bummer for sure - I like that mod! But if it's a choice between being able to build things or being able to tweak the scale of things, I'll go with building things and find other ways to get the part sizes I need.

It's not a TweakScale incompatibility. It's something wrong on the installation.

LaunchPads is triggering some pains due a KSP bug, that once triggered kills TweakScale (and anyone else in need to load DLLs or use Reflection). Keep in mind that you just removed the add'on that was telling you about the problem, all the others that are silently failing on you are still not working - probably LaunchPads itself.

The last occurrence of this problem can be found on this post on TweakScale's thread.

Locate and install a thingy called "ELHelper" and both LaunchPad and TweakScale will work fine.

 

[schlosrat]

On 3/20/2022 at 9:49 AM, Lisias said:

It's not a TweakScale incompatibility. It's something wrong on the installation.

LaunchPads is triggering some pains due a KSP bug, that once triggered kills TweakScale (and anyone else in need to load DLLs or use Reflection). Keep in mind that you just removed the add'on that was telling you about the problem, all the others that are silently failing on you are still not working - probably LaunchPads itself.

The last occurrence of this problem can be found on this post on TweakScale's thread.

Locate and install a thingy called "ELHelper" and both LaunchPad and TweakScale will work fine.

 

Thanks @Lisias

I'm really not sure what ELHelper is. sounds like it might be a config file, but who knows. I read the post you linked and didn't see any info on ELHelper there either, other than to mention it. I've tried googling that and not turned up anything that way either. I don't think this is a mod, but it might be a config file that comes with a mod. I've tried searching in my Game Data folder and nothing is coming up that way. So far my effort has been a dead end to find this.

Can you point me to where you found a reference to needing ELHelper? Was that from a log file?

[schlosrat]

On 3/19/2022 at 7:11 AM, taniwha said:

EL doesn't actually do that. Rather, it finds the base of the vessel's bounding box and uses that to place the vessel. There are two possibilities: the bounding box is wrong (or really, the bounding box of at least one of the parts, since EL builds the box from the part bounding boxes), or there's a bug in the placement code.

TweakScale has always been a thorn in my side: when I went to add support for TS to EL, I found that it broke KSP's camera after reverting to the VAB (or SPH), and when I reported the issue, I was told it was a KSP bug and the TS author (at time time) refused to do anything about it. Thus I abandoned all pretense of supporting TS. Sorry excuse, sure, but that's the way it is.

I'm pretty sure I haven't changed the orientation of the micropads, but rotations can be a tricky thing, especially if it's a 180 degree rotation (rotation axis is undefined in such a case when you have only the two reference vectors (current and desired direction): rotations are intuitive only in 2d (ie, there is no 3rd dimension)). It's for this reason the pads have extra geometry internal to them making their orientation semi-apparent (can't tell which direction is which, but you can tell when you've rotated 90 degrees) when placing them using older versions of KIS (before stock inventories, haven't tried with more recent KIS). Ie, build goes wrong, load before building, reorient pad, try again. However, I don't think I've ever been out by 90 degrees, only 180 due to top vs bottom node selection.

Hmm, actually, I might have changed something: it looks like I tried to ensure that starboard (VAB door side of default orientation) stays starboard when flipping, and starboard is aligned with the red arrow (yeah, a bit weird when the port navigation light is red). This code always has me scratching my head (and some of my git log messages aren't so great in hindsight).

 

What was the bug? (next commit does fix a bug that's related to nodes and orientation, but...)

On top of that, I haven't worked on the code since November 2020, and everything I knew about it has been pushed out of my head.

This shouldn't be that hard: just include all the .cs files mentioned in Source/Makefile.and KodeUI.inc (note: I use a symlink in Source to the KodeUI source directory, check README.txt for KodeUI related instructions), and I directly reference the dlls in KSP's KSP_Data/Managed directory.

Thanks @taniwha,

I suspect that whatever change you made resulted in my needing to rotate my micropads so the yellow arrow is up - that was easily done and really trivial.

The other matter (vessels dropping in ) is more perplexing. I began this 1.12.3 game by bringing in some pre-built craft of mine from KerbalX that have in the past always worked perfectly. They happen to use the FASA launch clamps since I like the look of those, and they also include ladders so my kerbals can easily get back in. Those are the only parts that should intersect the ground, and the as-built craft are being built so high up that the ladder doesn't even come close to the ground. When I strip off the FASA launch clamps and put on landing legs, then they're also built quite high, but are gently eased down to the ground.

The craft I've been seeing this with are all part of a modular base set of craft that incorporate FASA launch clamps and micropads allowing easy base extension. The main parts are all PlanetaryBaseInc parts plus a few lights, radiators on some, etc. Really not a lot of parts and the root part is generally the PlanetaryBaseInc part.

So far, my work around is to build my base core on landing legs, then extend using parts supported by FASA launch clamps until it's supported well enough that I can remove the landing legs if I like.

 

Edited March 21, 2022 by schlosrat

[Lisias]

4 hours ago, schlosrat said:

Thanks @Lisias

I'm really not sure what ELHelper is. sounds like it might be a config file, but who knows. I read the post you linked and didn't see any info on ELHelper there either, other than to mention it. I've tried googling that and not turned up anything that way either. I don't think this is a mod, but it might be a config file that comes with a mod. I've tried searching in my Game Data folder and nothing is coming up that way. So far my effort has been a dead end to find this.

Can you point me to where you found a reference to needing ELHelper? Was that from a log file?

I don't know exactly what's ELHelper, other that it's an Assembly needed by LaunchPad. From that post I mentioned:

Spoiler

[ERR 21:26:37.864] AssemblyLoader: Exception loading 'ELHelper': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoa
  at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0
  at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0

Additional information about this exception:

 System.IO.FileNotFoundException: Could not load file or assembly 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null'

 

Problem: the only way to be absolutely sure about your problem is by inspecting you KSP.log where the problem happens. As I said before, KSP is terribly buggy, and if by any reason something else had borked before on your KSP.log, then LaunchPad is only an innocent bystander being caught in the crossfire and then we need to dig further in order to find the real troublemaker.

Please publish your full KSP.log and we will able to further investigate your case.

[howardxu23]

I am redirected by simpleConstruction here for an issue or a mechanic that I'm not clear on: how do you fuel up newly constructed ships though the mod? as shown in these pictures. releasing the ship at this point would just leave it as an empty tank that is useless.
KSP log

Edited March 31, 2022 by howardxu23

[Revilo2601]

there is a resource manager included in EL, so you can fuel your crafts. But i'm not certain if simple uses this feature

[Revilo2601]

On 3/8/2022 at 5:43 AM, Angel-125 said:

I seem to have run into this as well. I'm running 6.99.1, and when I use my custom disposable pad, installed via stock EVA Construction, I run into this error when I tap on Show UI. I checked my logs, this is what I'm seeing:

[EXC 20:35:51.832] NullReferenceException: Object reference not set to an instance of an object
	ExtraplanetaryLaunchpads.EL_Utils.MakeSprite (UnityEngine.Texture2D tex) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELBuildCraftView.UpdateFlag () (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELBuildCraftView.UpdateControl (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	UnityEngine.Events.InvokableCall`1[T1].Invoke (T1 args0) (at <12e76cd50cc64cf19e759e981cb725af>:0)
	UnityEngine.Events.UnityEvent`1[T0].Invoke (T0 arg0) (at <12e76cd50cc64cf19e759e981cb725af>:0)
	ExtraplanetaryLaunchpads.ELPadView.set_control (ExtraplanetaryLaunchpads.ELBuildControl value) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELPadView.SetControl (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELBuildManagerView.SetControl (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELMainWindow.SetControl (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELWindowManager.ShowBuildWindow (ExtraplanetaryLaunchpads.ELBuildControl control) (at <26d81185874f4d28baa663727b80c757>:0)
	ExtraplanetaryLaunchpads.ELDisposablePad.ShowUI () (at <26d81185874f4d28baa663727b80c757>:0)
	BaseEvent.Invoke () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	UIPartActionButton.OnClick () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	UnityEngine.Events.InvokableCall.Invoke () (at <12e76cd50cc64cf19e759e981cb725af>:0)
	UnityEngine.Events.UnityEvent.Invoke () (at <12e76cd50cc64cf19e759e981cb725af>:0)
	UnityEngine.UI.Button.Press () (at <5336a8686ff14f17888ce9a9f44f29bc>:0)
	UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) (at <5336a8686ff14f17888ce9a9f44f29bc>:0)
	UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) (at <5336a8686ff14f17888ce9a9f44f29bc>:0)
	UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) (at <5336a8686ff14f17888ce9a9f44f29bc>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.EventSystems.EventSystem:Update()

I really should figure out a visual studio project for EL, then I can help debug the issue.

in all certainty i can provide the same error. just by opening up the el main window, when i am on that craft

[Revilo2601]

I wonder... is the disposable launchpad printed from extraplanetary launchpads functional or is it bugged too if printed by other means?

[zer0Kerbal]

On 3/31/2022 at 7:34 AM, howardxu23 said:

I am redirected by simpleConstruction here for an issue or a mechanic that I'm not clear on: how do you fuel up newly constructed ships though the mod? as shown in these pictures. releasing the ship at this point would just leave it as an empty tank that is useless.
KSP log

*chuckle* @howardxu23I could have answered this there.  

your second (bottom) image shows you the screen where you should fuel your newly constructed vessel.  

On the other hand if you don't fill/fuel here - well Kouston, we have a problem. At that point I would suggest using SimpleLogistics! (SLOG!) to transfer resources without need for long hoses and EVA.

 

On 4/1/2022 at 2:42 AM, Revilo2601 said:

there is a resource manager included in EL, so you can fuel your crafts. But i'm not certain if simple uses this feature

+1  @Revilo2601 SimpleConstruction! (SCON!) does because it uses the entire Extraplanetary Launchpad GUI, just simplifies the resource flow and uses only stock parts.

[taniwha]

So long as the parts are spawned "correctly" (ie, such that in the end, KSP thinks it spawned them normally), it shouldn't matter how EL (or any other mod's parts) get into the game. Something many may not realize is that (at least pre stock inventory KIS) even just placing a part using a kerbal spawns the part into the game: the part doesn't exist at all when in the kerbal's inventory, and I'm pretty sure only the model itself exists when strapped to the kerbal's back.

[Revilo2601]

So the basic answer is: they work, as long as they don't go through an inventory in the first place. Alright ^^

[taniwha]

On 4/11/2022 at 2:04 PM, Revilo2601 said:

So the basic answer is: they work, as long as they don't go through an inventory in the first place. Alright ^^

No, the point of my post is that if going through an inventory broke parts when building with EL, something is very wrong.

[Revilo2601]

Well I established a base by now and actually I'm wondering why I haven't used EL earlier. 

Great work 

[Revilo2601]

This printed WITH el are fine, as they are "vessels" and are existent in the world.

But if you use sandcastle or oseworkshop, hell even stock inventory and building system, survey stakes bug out and even other pads stop working. 

Scraping those stakes or what ever solves the problem.

Though I have no clue if it is an el problem or a problem of the other mods. But because stakes in ksp inventory bug out too...

[taniwha]

On 4/16/2022 at 10:54 PM, Revilo2601 said:

But if you use sandcastle or oseworkshop, hell even stock inventory and building system, survey stakes bug out and even other pads stop working. 

This doesn't tell me much of anything at all. What does "bug out" mean? Do insects arrive on the scene and abscond with the stakes? (Not sure I blame them, stakes are tasty).

[Revilo2601]

The ui stops working, as in I can select the pad, I can highlight it, but I can't select a craft to build, finalise the build, release it or what ever other things I can do in the ui. The buttons are simply unresponsive. 

When I have the stakes cleared, it's working again.

 

Going to test if I can get some fresh stakes from vab to the place and try again.

Edited April 21, 2022 by Revilo2601
Addition

[taniwha]

5 minutes ago, Revilo2601 said:

Going to test if I can get some fresh stakes from vab to the place and try again.

Get the KSP.log file, too.

[Revilo2601]

I will, firing up the PC this moment

[Revilo2601]

okay so i don't understand it... but it is working now. not only the via el printed stakes etc, even those printed via sandcastle. can set directions everything. though i had some issue with 2 stakes with the same name.

besides that... no bugging out or anything. i did not change my install or anything... must have been a user issue then. 

when i become able to reproduce the error, i will come back on that one

okay so the survey crone from sandcastle is after scene change not recognized by el ui anymore, but well that is not so important and most likely not even a prob of el.

[taniwha]

On 4/21/2022 at 7:17 PM, Revilo2601 said:

okay so i don't understand it... but it is working now. not only the via el printed stakes etc, even those printed via sandcastle. can set directions everything. though i had some issue with 2 stakes with the same name.

Two or more survey stakes having the same name make for a survey site. Within a site, all stakes of the same type are grouped together to produce a point that is the average of all their positions. Stake [sets] of different types interact in different ways to produce lines (direction stakes, for creating axes), or planes (bounds stakes). Origin stakes are special in that there's no difference between direction and bounds origin stakes (limitation in the PAW UI).

If multiple stakes with the same name are giving you trouble, I want to know what that trouble is so I can either clear up any misunderstandings or fix it.

Edited April 23, 2022 by taniwha