[1.12] Extraplanetary Launchpads v6.99.3

[taniwha]

@zer0Kerbal: Thanks, yeah, that's a bug. That'll be why someone else made the mistake of thinking that was a construction part. I'll patch that up.

@Tonka Crash: I'm not 100% certain, but I think I know what that is: the ground mesh being at a different height (usually lower) than that specified by the data PQS uses  to generate the terrain. I think this is what causes floating scatters. It seems to be particularly bad where the terrain quad triangulation puts the diagonal edge running through the terrain rather than over it, forming a valley instead of a ridge. This error can sometimes be subtle and hard to spot. I had a lot of trouble with losing stakes near my Mun base in 1.6.1, and I lost several flags from my Duna Trek to it (that's when I figured out what was going on). Sadly, I have not yet figured out a way to work around the issue.

This screenshot nicely demonstrates the terrain issue. Planing a flag here, going away, and switching back to the flag results in the flag floating in the air about the height of the boulder's center. Reloading a certain distance (exact distance not known) away would result in the flag crashing into the ground.

 

[taniwha]

@zer0Kerbal: I've come up with a new description for the control reference part. It will be in the next release, but for the interim, here it is:

description = For those times where you need to switch control references qu
ickly, such as doing a ventral landing. At the flick of an action button, this d
evice will override your avionics and become your new fore and aft, with suitabl
e indicators highlighting when active. At a second flick of the action buttion, 
the device will remove the override and the previous control reference will be a
ctive once again.

 

[zer0Kerbal]

3 hours ago, Tonka Crash said:

 

Log with stakes disappearing

worse than campaign yard signs!

[schlosrat]

@taniwha

The fix for micro pads is definitely working in my game! As I expected I need to build my modular base designs with their extension micro pad oriented yellow diamond up - a trivial fix at my end! With your new release and that change I'm now able to build my modular bases one unit at a time!

That being said, although the micro pads are working, the launch clamps I'm using are not extending fully. The designs I've tested so far each have just one launch clamp under them, so I had hoped that what I would observe is this:

1. The first build goes in with survey stakes and is resting atop it's singl launch clamp which reaches all the way to the ground

2. Subsequent builds are attached using the micro pads, each design having just one launch clamp which reaches all the way to the ground

My test confirms (1), but only partially confirms (2) in that the launch clamps on the subsequent sections don't get extended properly. They descend different amounts, but not quite to the ground. I think for some reason EL is not picking up those launch clamp parts and extending them. They're being built instead with whatever length they happened to have in the VAB. I'll post a screen shot if I'm not able to solve this, but I suspect what I need is a MM fix to the part so it uses

For a MM solution is this as simple as it needs to be? I've never attempted to change a module's name before and I'm not entirely sure how I'd test that this is working other than to hopefully observe the end result in the game.

// To fix the Bluedog Design Bureau parts
@PART[BDB_FASAlaunchClamp*]:Final
{
	%MODULE[LaunchClamp] {
		%name = ELExtendingLaunchClamp
	}
}

// To attempt to fix all launch clamps in the game
@PART[*]:HAS[@MODULE[LaunchClamp]::FOR[Launchpad]
{
	%MODULE[LaunchClamp]
	{
        %name = ELExtendingLaunchClamp
	}
}

 

[taniwha]

Use NEEDS instead of FOR. FOR means that you are declaring the mod is installed, not that it must be. Otherwise, I think that's right.

As for testing, the first thing to do is check ModuleManager.ConfigCache (search for the part and check the modules). If that's working, you should be good to go.

@schlosrat: oh, also, even if just for reference, you might want to check out the DGT-NoLaunchClamp in my Diamond Grid mod. The parts may or may not be to your taste, but  the clamp itself shows off some of what EL can do

[schlosrat]

OK, further testing on the Bluedog Design Bureau launch clamps shows an interesting result using the MM code above (which, I suspect is flawed)

https://drive.google.com/file/d/1W4uozKC5W8llppdO9vh6kmW0JNmTexU8/view?usp=sharing

In the screenshot above the first craft launched to the VAB pad is just the Planetary Base Workshop with a few bits and pieces attached. It starts out with Fore and Aft micro pads and has a single 1.25 BDB launch clamp under it. It's also got a big container of rocket parts, and a small nuclear reactor for power. I designed it in the VAB to start more elevated than any of the other designs I'd later attach via micro pads.

The first micro pad build went onto the workshop's forewrd micropad and was the Planetary Base Cupola, which has a single 0.625 BDB launch clamp under it. As can be seen, that clamp did not get extended to the ground. Like all the designs I built in the this experiment it was saved in the VAB at a lower elevation than the PB Workshop design so that if the launch clamp didn't extend it would be apparent. I've got no idea what would happen if I tried to build something which was saved in the VAB at a higher elevation.

All of the subsequent builds were daisy chained off the PB workshop aft pad, and all consist of a PB Scrap Metal Container with various BDB launch clamps attached below them. Each has a micro pad allowing the design to continue.

First up is the 1.0 size launch clamp test, which did not descend to the ground.

Next is the 1.25 launch clamp test, which did descend! Note: That design was saved in the VAB at a lower elevation than the workshop, so it's not just a coincidence that the launch clamp's are the same size and both reach the ground.

Next is the 1.5, followed by the 1.875. Noteworthy here is that each larger LC seems to go futher down to the ground, but all of the scrapmetal storage designs were saved at about the same elevation in the VAB, so bigger LCs go down further, but none are being extended. Perhaps there's some minimum extension?

Not shown in that picture is the test with the 2.5 BDB launch clamp. Judging by where the 1.875 test looked like I wanted to proceed with caution and grab a screen shot before I risked building something that large. Turns out, building it didn't blow anything up, but it did result in the base of the 2.5 LC being below the level of the VAB launch pad in such a way that the end with that LC was sort of quivering. Here's a shot of that, though in a screenshot you can't see the vibration.

https://drive.google.com/file/d/1XCm4yhQHntc7wr2gQxyBnk1sFSqA1Cro/view?usp=sharing

As a final test I tacked on a design with the stock launch clamps. That one appears to have extended correctly and it also managed to stop the vibration of the 2.5 BDB LC part, but the whole structure appears to be under some ungodly stress as it's curved upwards a bit like a banana.

https://drive.google.com/file/d/1XDok7tyKOzR77UCUE3MJeQXYCUagbkSn/view?usp=sharing

Conclusions:

1. I clearly don't know what I'm doing with MM and appear to know barely enough to be dangerous with it (no surprise there).

2. Some LC's seem to work correctly, perhaps despite my crude attempt and a MM fix.

3. All of the BDB LC's look better than the stock LC in this use case, but for the Planetary Base parts it seems like the 1.25 is the largest size that looks good. Hey, esthetics matter!

4. (edit) I should check back here for @taniwha's reply before composing lengthy posts that add little value. I should also fix my MM script (to replace FOR with NEEDS) and check out his other mod of which I was previously unaware - thanks!

Edited April 8, 2020 by schlosrat

[taniwha]

Well, knowing it's BDB helps me if you don't get things working as I will be able to do some tests, but it should work if you get MM working (for initial testing to make sure it works at all, you could edit the .cfg files directly).

I doubt there are many launch clamps that don't look better than stock (they're not bad, really, but everybody does better ones)

[schlosrat]

Hmmm... My MM code is throwing and error (I need to look into that), so I've tried adding some code to your DG LC in an attempt to add tweakscale to those so I can have smaller ones. This is what I tacked in there, but it's not working.

 

    MODULE[TweakScale]
    {
        name = TweakScale
        type = stack
        defaultScale = 1.25
    }

 

[taniwha]

That looks for a module with name=TweakScale, which is not there, so no editing will be done.

Also, I very much doubt tweakscale would work with the DG tower due to cloneStep (I very much doubt TweakScale would adjust that).

[schlosrat]

2 hours ago, taniwha said:

That looks for a module with name=TweakScale, which is not there, so no editing will be done.

Also, I very much doubt tweakscale would work with the DG tower due to cloneStep (I very much doubt TweakScale would adjust that).

Oh, that wasn't the MM code. That's what I placed directly into the .cfg - and you're right. It didn't work.

For my attempt to add that code via MM I used this:

@PART[DiamondGridTrussNoLaunchClamp*]:NEEDS[Launchpad]:Final
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = stack
        %defaultScale = 1.25
    }
}

But now I'm thinking that if I want smaller versions of your part then maybe I need something more like this:

+PART[DiamondGridTrussNoLaunchClamp]:NEEDS[Launchpad]
{
	// Give the new part a unique name and title, with an informative description for the user
	%name = DiamondGridTrussNoLaunchClamp_0.625
	%description = Keeps your base from flying away, even at a 0.625m scale!
	%title = DGT-NoLaunchClamp-0.625

	// These need need to change
	%rescaleFactor = 0.5
	%scale = 0.5
	%mass = 1.046
	%cost = 941

	// Apparently one or more other things also need to change for the part to look right when extending?
}

As noted in the code above, things are not yet quite right. That code mostly works, but the LC doesn't look right when extending as there is a variable gap between the concrete base and the truss structure that lives below the giant golf ball. I took a guess and tried cutting down the cloneStep by a factor of 2 as well, but that did not do it.

Edited April 8, 2020 by schlosrat
Fixed MM code

[Corax]

 

1 hour ago, schlosrat said:

%MODULE[TweakScale] { %name = TweakScale

You're trying to (modify or insert) the module named TweakScale, regardless of whether it already exists or not, and (change or insert) its name to TweakScale, regardless of whether it exists or not (the '%' operator). If this is going to do anything at all, it's likely not what you intended.

If you want to modify an existing module, use '@MODULE', and leave out the %name= part. If you're trying to copy an existing module as a new one, use '+MODULE' and do include the name= part. If you want to add a new module that wasn't part of the config before, just do it as if you were just writing a regular config, not an MM patch, i.e. "MODULE { name = theModuleName }" without any of the @/%/+ operators.

Just my two cents.

 

[schlosrat]

I found the completely trivial bug in my previous MM code for swapping in ELExtendingLaunchClamp for LaunchClamp in all launch clamps. I was just missing a "]"... Now the MM fix loads and works fine!

// To attempt to fix all launch clamps in the game
@PART[*]:HAS[@MODULE[LaunchClamp]]:NEEDS[Launchpad]:Final
{
	%MODULE[LaunchClamp]
	{
        %name = ELExtendingLaunchClamp
	}
}

Here's a screen shot similar to the previous test, but showing that all of the BDB launch clamps now extend properly (still just building with one LC per design though). This screen shot also shows a 0.625 scale DG launch clamp. It's possible to set the elevation in the VAB (provided it's the first part you build) so that it "looks" ok. AFAIK it works OK regarless of how it looks, but I've clearly not done much testing.

https://drive.google.com/file/d/1aZeMfS6m8qror28Paffxu-K2R8dFuzjz/view?usp=sharing

While the DBD LC's do extend properly, that 2.5m variant does make the whole back end jiggle about when not in time warp. I wouldn't recommend using it, or at least not mixed with other sizes. NBD, since I mainly just want the 1.25 and 0.625 variants to work.

4 minutes ago, Corax said:

 

You're trying to (modify or insert) the module named TweakScale, regardless of whether it already exists or not, and (change or insert) its name to TweakScale, regardless of whether it exists or not (the '%' operator). If this is going to do anything at all, it's likely not what you intended.

If you want to modify an existing module, use '@MODULE', and leave out the %name= part. If you're trying to copy an existing module as a new one, use '+MODULE' and do include the name= part. If you want to add a new module that wasn't part of the config before, just do it as if you were just writing a regular config, not an MM patch, i.e. "MODULE { name = theModuleName }" without any of the @/%/+ operators.

Just my two cents.

 

That's a good point! I certainly didn't need to include the name field in the modification. My bad. Thanks for the MM tips, clearly I'm very new at playing with that.

[Corax]

To add to this, it's hard to imagine there being any valid MODULE definition without a name, so regardless of what way you're going to modify it, using "modify" '@name=' should suffice in any case, as opposed to "modify or create" '%'. If it doesn't, I'd take that as an indication of an underlying error.

I doubt %MODULE[something]{} is actually going to insert a module that didn't already exist before, so using '%' instead of '@' seems kind of pointless, but I don't think I've ever tried that before, I may be wrong on that count.

[Siama]

On 4/4/2020 at 1:22 PM, taniwha said:

 

• EC smelter recipe from Tonka Crash (not used by EL, but available to those who wish to use it).

Could you please include this file into release?

[taniwha]

3 hours ago, Siama said:

Could you please include this file into release?

Oh, bah, I forgot to add it to the files lists. Thank you for letting me know.

[Siama]

On 3/22/2020 at 11:42 PM, Tonka Crash said:

but I wasn't having any luck getting the smelter to actually heat up

Change from

ElectricCharge = 0.002459947 // 0.005590789*0.44

to

ElectricCharge = 0.002459947 -0.002459947 // 0.005590789*0.44 and 100% of consumed EC goes to heat

(and same for remelter) will heat the furnace but I'm not sure about proportions (and where excess heat goes).

@taniwha, is 1 Ingredient.heat == 1 Joule == 1 EC ? Will it explode someday if generated heat is not consumed explicitly in the recipe (as in LFOFired mode) or radiators will handle it?

[taniwha]

@Siama: For electric charge, I don't really know what the ratio is because EC is mass-less, but when the resource unit represents grams, the heat unit is kilo-joules. That said, EL assumes 1u EC is 1 kJ, so the ratio might be 1:1.

As for heating, I don't think I've ever had a smelter blow up, but I have had a few nearby parts (including kerbals) overheat. Radiators do help, though. Unfortunately, I seem to remember needing to tweak the "background" behavior of smelters.

[Temeriki]

On 4/7/2020 at 8:58 PM, taniwha said:

@zer0Kerbal: Thanks, yeah, that's a bug. That'll be why someone else made the mistake of thinking that was a construction part. I'll patch that up.

@Tonka Crash: I'm not 100% certain, but I think I know what that is: the ground mesh being at a different height (usually lower) than that specified by the data PQS uses  to generate the terrain. I think this is what causes floating scatters. It seems to be particularly bad where the terrain quad triangulation puts the diagonal edge running through the terrain rather than over it, forming a valley instead of a ridge. This error can sometimes be subtle and hard to spot. I had a lot of trouble with losing stakes near my Mun base in 1.6.1, and I lost several flags from my Duna Trek to it (that's when I figured out what was going on). Sadly, I have not yet figured out a way to work around the issue.

This screenshot nicely demonstrates the terrain issue. Planing a flag here, going away, and switching back to the flag results in the flag floating in the air about the height of the boulder's center. Reloading a certain distance (exact distance not known) away would result in the flag crashing into the ground.

 

Ive always had this issue in the past result in my ground bases being bounced around and ripped apart.  I get around this using usi's "ground tether" module letting me build massive sprawling bases resistant to scene loading and unloading.  Releasing the ground tether has resulted in my bases popping through the air or flying through the ground but until I try to move it their pretty rock solid.  Not sure if something akin to that could help with the survey pylons being bounced and destroyed.

[Tonka Crash]

@Temeriki I use the USI ground tether.  I started using it to keep bases and landers from sliding around.  It seems like the only method that does work reliably to do this. I don't think it will help in this case.  I looked at the USI code once upon a time ago and think it works be stopping motion after the scene is loaded and physics engage. The stakes seem to fail during initialization of the scene before physics engage.

[zer0Kerbal]

9 hours ago, Tonka Crash said:

@Temeriki I use the USI ground tether.  I started using it to keep bases and landers from sliding around.  It seems like the only method that does work reliably to do this. I don't think it will help in this case.  I looked at the USI code once upon a time ago and think it works be stopping motion after the scene is loaded and physics engage. The stakes seem to fail during initialization of the scene before physics engage.

I stumbled (again) across an old mod - am working on bringing it back - Foundations.

[Carrier3000]

I have a Problem. I have the mod version 6.7.2.0 and play on the game version 1.9.1. My Problem is that i can´t finde the part EPL survey station nowhere in my parts list.

Please Help

 

 

Edited May 2, 2020 by Carrier3000

[taniwha]

You need Kerbal Inventory System to be installed for EL's survey parts to be available.

Also, there are no EPL parts anywhere: they're EL

[tinygrox]

I'm going to translate this mod, alone. 

[Carrier3000]

On 5/1/2020 at 5:34 AM, taniwha said:

You need Kerbal Inventory System to be installed for EL's survey parts to be available.

Also, there are no EPL parts anywhere: they're EL

I have Kerbal Inventory System installed but the part is still not showing up

[taniwha]

@Carrier3000: then maybe another mod is disabling it. I don't know if it's still the case, but MKS used to.