[1.12] Extraplanetary Launchpads v6.99.3

[pmoffitt]

20 hours ago, Snoman314 said:

I found this hard to believe so I did the numbers, and wow. Yeah OK.

USA 2019 average industrial electricity was 6.83c / kWh, or $18.97/GJ. Coke goes for roughly $150/short ton = $165/tonne @ approx 31 GJ/tonne = $5.37/GJ

That makes sense, as it would therefore be the first method developed, and so the most mature method, even if other methods have been developed.

I've learnt more about smelting in the last few days than I ever thought I would! 

Yes, this is the kind of stuff I remember from when I was in college many years ago.  Something about aluminum using 3 times the electricity to smelt compared to iron.  Electricity is relatively cheap here, the aluminum smelter is right next to the hydroelectric dam on the Columbia River.

The other advantage to using coke to reduce iron is that putting carbon into iron makes it steel a big improvement over just raw iron.

[HebaruSan]

Historically, aluminum production is a common solution to the problem, "What do we do with all this surplus (hydro)electricity?"

See: Holtwood Dam on the Susquehanna River in Pennsylvania, Akosombo Dam on the Volta River in Ghana.

[TomfooleryYT]

My game keeps crashing every time I go to place a craft with this mod. not sure if it's the mod to blame, but I'm starting here. It does seem to be one particular craft which has a lot of parts from KSPIE so I'll probably check in with them as well. I just figured I'd ask here first since it only happens when loading this craft with  extraplanetary launchpads, it doesn't crash when launching the craft from the SPH. let me know if you need to see any crash log or if you need any other files. thanks!

[taniwha]

@TomfooleryYT Though it seems you're new here, as always, logs (KSP.log) or no help (because without the log file, it's impossible to provide that help).

however, before you try to get the log file, ensure LOG_INSTANT_FLUSH is set to true in your settings.cfg file.

[TomfooleryYT]

2 hours ago, taniwha said:

@TomfooleryYT Though it seems you're new here, as always, logs (KSP.log) or no help (because without the log file, it's impossible to provide that help).

however, before you try to get the log file, ensure LOG_INSTANT_FLUSH is set to true in your settings.cfg file.

should I do the settings.cfg edit then reproduce the bug? if not here's the ksp.log file https://drive.google.com/file/d/1DXlKgAAjy2excXTHV_297wa32JkQ0M6m/view?usp=sharing from just now, after a pc restart

[taniwha]

Before you try to reproduce the bug because some of the log may be missing due to the crash.

As appears to be the case (the end of the log file does not indicate anything untoward)

[TomfooleryYT]

Might help if I give you the log from the proper install....but I just replicated the bug and this should have what you need.

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

[taniwha]

While AdjustableModPanel and kOS are decidedly unhappy about something (might be good to send this log file to those authors), I don't think they're related to your crash.

RecoveryController is decided unhappy about the vessel being built by EL, so certainly worth contacting that author.

InterstellarFuelSwitch is very unhappy, but it looks to be due to module mismatch (did you install or remove mods after creating the craft file?)

However, real trouble began with KspiFoldingRadMed and DeployableMicrowaveInfraredRectenna complaining about Infinity or NaN values (probably due to one of the earlier issues).

 

[TomfooleryYT]

11 hours ago, taniwha said:

InterstellarFuelSwitch is very unhappy, but it looks to be due to module mismatch (did you install or remove mods after creating the craft file?)

I uninstalled and reinstall EL just in case, but also this is kind of an older craft, I made it earlier this year on a separate save (with the same mods) and imported to this career mode save once I got all the parts unlocked. it's worth noting I have been able to launch this craft with EL before but for whatever reason it's not working now.

I removed the beamed power receiver from the craft (the DeployableMicrowaveInfraredRectenna) and it loads without crashing the game now, BUT the craft is broken physics wise and wants to flip wildly for no reason. I'm currently working on a new craft file based off of the earlier craft that hopefully will work...

Edited December 11, 2020 by TomfooleryYT

[HebaruSan]

On 12/22/2019 at 4:55 AM, taniwha said:

No, just dynamic IPed, both external and internal (my last attempt to make the internal IP static failed miserably, darn Japanese modems). The external IP issue was sorted on the 14th, and the internal one partially, but I had forgotten that http was separated from everything else and I needed to update that address too.

FYI, server's kaput again.

[Snoman314]

On 12/9/2020 at 4:35 PM, taniwha said:

Yesssss..buuuuut......

It looks like there might be a bug in my code that works though the efficiency curve. It looks like it fails if there is only one point on the efficiency curve (in the part cfg).

I'm currently knee-deep in other code, so could you file an issue on github, please?

Finally got around to creating the issue on Github. I'm really hoping I can pick that play through up again, I was having fun up to that point.

[taniwha]

3 hours ago, HebaruSan said:

FYI, server's kaput again.

Yeah, I noticed. It should be good now. I had fixed the name server addresses a few hours ago, but forgot to update my nameserver's database (oops)

[taniwha]

Though it looks like it could take some time for the fixes to come into effect for everyone.

[taniwha]

3 hours ago, Snoman314 said:

Finally got around to creating the issue on Github. I'm really hoping I can pick that play through up again, I was having fun up to that point.

Thanks. BTW, you should be able to fix your issue by either adding a second efficiency key, or having no keys.

[taniwha]

I have updated the manual and zip download links to use https. The ssl certificate is self-signed, so it may cause some problems, thus the old http links are provided as well.

[Snoman314]

9 hours ago, taniwha said:

Thanks. BTW, you should be able to fix your issue by either adding a second efficiency key, or having no keys.

I thought I already had the second efficiency key?:

Spoiler

EL_ConverterRecipe {
	name = ElectricRemelter
	Input {
		efficiency = 1
		ScrapMetal = 3000
		ElectricCharge = 3822 -3822
	}
	Output {
		efficiency = 1
		// See "Theoretical Minimum Energies To Produce Steel" by
		// R.J. Fruehan, O. Fortini, H.W. Paxton, R. Brindle
		Metal = 3000 -3822 // 1274kJ/kg of Metal, 3kg Metal
	}
	
	// When the smelter is too cold to reduce the ore, it's just heated by the arc.
	// I set it to 10 MJ to heat the smelter when not warmed up.
	Input {
		efficiency = 0
		ElectricCharge = 10000 -10000
	}
	Output {
		efficiency = 0
	}
}

Should I just remove the zero efficiency part?

[taniwha]

hmm, it looks like it might be a problem with massless efficiency keys. For now, it might be best to remove the 0 keys and the efficiency lines from the 1 keys.

However, what it even more looks like is I need to rig up a test harness for the converter so I can test it outside of KSP.

[Snoman314]

47 minutes ago, taniwha said:

hmm, it looks like it might be a problem with massless efficiency keys. For now, it might be best to remove the 0 keys and the efficiency lines from the 1 keys.

However, what it even more looks like is I need to rig up a test harness for the converter so I can test it outside of KSP.

OK, Removing the 0 keys and all mentions of efficiency got me going again, thanks!

Now that the smelter is going, it was time to recycle some of the now obsolete station parts that I used to start the bootstrapping process. I gently nudged the original station seed craft into a large recycling bin, and I got a nasty surprise. Unlike back in the day, the whole craft was not recycled, just the root part (which was one of the first into the bin). I had RCS thrusters, radial monoprop tanks, docking ports and all sorts, flying everywhere. What gives?

I found this in the manual:

Quote

Some of you
may have
had spotty
results recycling entire
vessels: that
is intentional, and
there is a
way around
it (see if you
can guess).

No I can't guess. I have no idea what is going on, other than the recycling bin only recycles one part at a time now? Is zero-G recycling basically dead now?

[taniwha]

1 hour ago, Snoman314 said:

I had RCS thrusters, radial monoprop tanks, docking ports and all sorts, flying everywhere. What gives?

  Bwahahahaaaaaaaa }:>

1 hour ago, Snoman314 said:

No I can't guess. I have no idea what is going on, other than the recycling bin only recycles one part at a time now? Is zero-G recycling basically dead now?

No, it's not dead. It's just not free. As a bit of a hint, recycling bins are dumb, they have no idea how to take apart a ship: they just much on the most convenient part. They need intelligent direction.

Less subtle: the recycler code goes through the vessel part tree, and at every part that has children it makes a random decision as to whether to move on to a random child recycle that part. When it gets to a part that has no children, that part is unconditionally recycled. Now, the probability of that decision is a direct translation (ie, no scaling) of a very specific vessel-wide statistic.

[Snoman314]

26 minutes ago, taniwha said:

  Bwahahahaaaaaaaa }:>

No, it's not dead. It's just not free. As a bit of a hint, recycling bins are dumb, they have no idea how to take apart a ship: they just much on the most convenient part. They need intelligent direction.

Less subtle: the recycler code goes through the vessel part tree, and at every part that has children it makes a random decision as to whether to move on to a random child recycle that part. When it gets to a part that has no children, that part is unconditionally recycled. Now, the probability of that decision is a direct translation (ie, no scaling) of a very specific vessel-wide statistic.

OK, first of all, let me go on record saying I think this whole idea is stupid. The first thing that happens is that it looks like a bug: The recycling operation fails straight away. Then if you see a little side note tucked away in the manual you get a clue that this is actually a 'feature', but with absolutely no clue how to figure out what's going on. Getting led by the hand above, plus spending more than half an hour reading through the source code to find the SelectPart function, I now see what's going on.

My conclusion: Yes, zero-G recycling is stuffed.

As soon as it recycles a part that has children attached, then it's over. Those child parts drift off  and the craft is certainly going to be uncontrollable. There's no way to pilot a random fuel tank or solar panel back into the bin. what is the point of this? Best case scenario: there's a loose docking port (that's not tumbling too badly) that my tug will be able to dock to and push back towards the bin. As for the rest of the parts? Just unrecoverable debris. I'm trying to be reasonable here, but this just seems stupid. You say it's supposed to be 'not free'. OK fine, but once the vessel is in fragments what do you expect people to do exactly? Go EVA for 2 hours frustratingly trying to nudge parts back towards the bin by bumping into them?

 

My station that has the recycle bin has a productivity somewhere around 24, so if I'm reading this right, I must have just got unlucky that the root part was immediately recycled first. If you're going to stick with this, perhaps rather than an even chance of having the root part get recycled first, how about some kind of inverse exponential probability that the part with children is selected? e.g.:

while (p != null && p.children.Count > 0) {
	if (prod < 1 && random (0, 1f) < 1 - prod) {
		break;
	}
	
	rootChance = 2^(1-prod) / (1 + p.children.Count)
	if (random (0, 1f) < rootChance) {
		break;
	}
	
	p = p.children[random (1, p.children.Count)];
}

That way you can at least mitigate the issue by adding more workshops and / or engineers.

[taniwha]

1 hour ago, Snoman314 said:

OK, first of all, let me go on record saying I think this whole idea is stupid. The first thing that happens is that it looks like a bug: The recycling operation fails straight away. Then if you see a little side note tucked away in the manual you get a clue that this is actually a 'feature', but with absolutely no clue how to figure out what's going on. Getting led by the hand above, plus spending more than half an hour reading through the source code to find the SelectPart function, I now see what's going on.

My conclusion: Yes, zero-G recycling is stuffed.

First, I just want to clear up that this feature was meant to make the recycling bins a little more interesting than just part-at-a-time recycling, and the fairly low (0.75) productivity requirement was supposed to make it pretty easy to get 100% reliable recycling. It was never meant to be punishing in any way.

Really, I have to thank you: not only have you found some bugs in the recycling code (this post is written in a back-and-forth manner), this is the first actual constructive criticism I've received regarding the behavior of recyclers.

12 minutes ago, Snoman314 said:

My station that has the recycle bin has a productivity somewhere around 24, so if I'm reading this right, I must have just got unlucky that the root part was immediately recycled first. If you're going to stick with this, perhaps rather than an even chance of having the root part get recycled first, how about some kind of inverse exponential probability that the part with children is selected? e.g.:

If your station has a productivity of 24, then the probability of a non-leaf part being recycled should be 0. That it was not is a very deep concern.

Looking at the code, a little above the while loop you posted, it looks like workNet is null (which is a bug in itself, I wonder if something has changed in KSP because I was pretty certain I tested recycling bins after the switch to VesselModule for the work-net). However, another bug is that the default productivity (prod = 0) should have been passed through HyperCurve (which would result in a probability of 0.5  for a non-leaf part to be recycled.

To save you some effort, HyperCurve passes the value through (sqrt(1+x^2) + x)/2 (core of asinh, actually), so -inf -> 0, 0-> 0.5, 0.75->1 and asymptotically +x -> +x for x >> 1.

Anyway, I'll fix the glaring bug (not using HyperCurve in the right place) and investigate the apparently incorrect workNet reference.

Also, I'll add a note to add a difficulty setting for this, and I've come up with some ideas to make recycling tugs more usable: tie the effective productivity to highest of the local vessel, and a single-hop to a probe control point (or KSC if Kerbin itself is single-hop, where KSC has an assumed very high productivity (0.75 is plenty, so single-hop to KSC would mean no scattered parts)). I might add signal strength in there.

[taniwha]

@Snoman314 Update. Yup, bug in recycling bin handling of the work-net.

commit 8631f12061cde58ee77a2e93414a94f95098911f (tag: v6.3.1)
Author: Bill Currie <[email protected]>
Date:   Tue Nov 13 17:01:03 2018 +0900

    Ensure sources and sinks know the worknet.
    
    As part of the spawn process, especially when using the micro-pad, the
    worknet for some or all parts may be lost. Since the vessel worknet
    rebuilds the network after any vessel modification, simply update each
    source and sink with the current worknet while building the network. Fixes
    the erroneous 0 productivity in the build window.

Recycling bins are NOT part of the work-net, and so they don't get updated when the work-net updates, and I suspect the above describes your situation. I'll need to poke at the work-net code a little to ensure it does the right thing with non-consuming work-sinks, but I'll add recycling bins to the network.

Again, thank you.

[Snoman314]

23 minutes ago, taniwha said:

First, I just want to clear up that this feature was meant to make the recycling bins a little more interesting than just part-at-a-time recycling, and the fairly low (0.75) productivity requirement was supposed to make it pretty easy to get 100% reliable recycling. It was never meant to be punishing in any way.

Really, I have to thank you: not only have you found some bugs in the recycling code (this post is written in a back-and-forth manner), this is the first actual constructive criticism I've received regarding the behavior of recyclers.

If your station has a productivity of 24, then the probability of a non-leaf part being recycled should be 0. That it was not is a very deep concern.

Ahh OK. So sounds like we're on the same page after all, and it was a bug that I encountered. Sweet as then. Having the the recycling be a bit messy when productivity is less that 0.75 seems reasonable enough to me. That's command pod with untrained kerbals territory after all.

I hadn't looked much outside that loop I mentioned, and was assuming that prod was the raw productivity value. I also now realise I got the last part wrong. I mistakenly thought that the 0 - children count part here included the parent part, meaning that regardless of productivity there was a fairly high chance of non-leaf parts being recycled.

p = p.children[random (0, p.children.Count)]

With your reply I see how it's supposed to be working now, and I take back most of what I said: If not for the bug this seems mostly fine.

 

I will stand by my comments about the obscurity however. It's taken all this back and forth because without prior knowledge, the intended behaviour looks like a bug. It was only with more information you were able to tell that what I was reporting was an actual bug.

40 minutes ago, taniwha said:

Also, I'll add a note to add a difficulty setting for this, and I've come up with some ideas to make recycling tugs more usable: tie the effective productivity to highest of the local vessel, and a single-hop to a probe control point (or KSC if Kerbin itself is single-hop, where KSC has an assumed very high productivity (0.75 is plenty, so single-hop to KSC would mean no scattered parts)). I might add signal strength in there.

You can you do tooltips in the difficulty settings UI, so that could at least be a place to give some bare minimum head's up.

I like the idea of allowing a recycler equipped tug or auxiliary craft to go around and scoop up stray parts. I can't think of any other great ways to handle it when loose parts drift out of the recycling process.

 

1 minute ago, taniwha said:

@Snoman314 Update. Yup, bug in recycling bin handling of the work-net.

commit 8631f12061cde58ee77a2e93414a94f95098911f (tag: v6.3.1)
Author: Bill Currie <[email protected]>
Date:   Tue Nov 13 17:01:03 2018 +0900

    Ensure sources and sinks know the worknet.
    
    As part of the spawn process, especially when using the micro-pad, the
    worknet for some or all parts may be lost. Since the vessel worknet
    rebuilds the network after any vessel modification, simply update each
    source and sink with the current worknet while building the network. Fixes
    the erroneous 0 productivity in the build window.

Recycling bins are NOT part of the work-net, and so they don't get updated when the work-net updates, and I suspect the above describes your situation. I'll need to poke at the work-net code a little to ensure it does the right thing with non-consuming work-sinks, but I'll add recycling bins to the network.

Again, thank you.

Yeah OK, that makes sense. The recycling bin in question was constructed onto the station using a micro-pad, so this does seem like it would apply.

I hope you're able to get it all sorted after this 

[taniwha]

21 minutes ago, Snoman314 said:

Ahh OK. So sounds like we're on the same page after all, and it was a bug that I encountered. Sweet as then. Having the the recycling be a bit messy when productivity is less that 0.75 seems reasonable enough to me. That's command pod with untrained kerbals territory after all.

Yeah, that was the intention.

22 minutes ago, Snoman314 said:

I will stand by my comments about the obscurity however. It's taken all this back and forth because without prior knowledge, the intended behaviour looks like a bug. It was only with more information you were able to tell that what I was reporting was an actual bug.

My thinking was that by the time people were recycling, they'd have several engineers on board and thus have more than enough productivity (like you), and thus most wouldn't notice for larger vessels (but would for more maneuverable units). Going by the very low amount of comments I've received on the behavior, I'd say that assumption wasn't too far off the mark.

24 minutes ago, Snoman314 said:

I like the idea of allowing a recycler equipped tug or auxiliary craft to go around and scoop up stray parts. I can't think of any other great ways to handle it when loose parts drift out of the recycling process.

This is already doable, my proposed changes would drastically reduce the occurrence of mini Kessler syndromes.

26 minutes ago, Snoman314 said:

I hope you're able to get it all sorted after this 

Already testing the actual fixes. Came up with a better solution that what I was talking about in my post.

[taniwha]

I have released version 6.8.3 of Extraplanetary Launchpads. This is a quick-fix release for the actual bugs found by @Snoman314 (a very big thank you!)

Changes from 6.8.2:

• Ensure probability of non-leaf parts being recycled is never 1
• Make recycling bins part of the work-net so they never lose track of the network.

The other discussed changes (using CommNet, difficulty, etc) are still planned, but will be part of the next feature release.