[1.12] Extraplanetary Launchpads v6.99.3

[cgwhite4]

The relevant math worked out to between 90 seconds and 2 minutes, but waiting (at least) that long after loading my Gilly base before issuing the Build command failed to clear the bug, even when attempted from my main save, which is at a point just before I went to Gilly to begin the build.  I also tried timewarping ahead that amount.  Still the issue persisted.

[taniwha]

Hmm, ok, this bug is deeper than I thought. Just to verify that my surmise as to the nature of the bug is correct, please try setting lastUpdateString to UT on one of your misbehaving bases and build something to check its rate.

[cgwhite4]

That reset the build progress rate to normal, but the smelter is still acting up.  There must be another variable of similar nature that controls it.

[taniwha]

Yes, there will be another variable. Thank you for the confirmation.

[cgwhite4]

Turns out there were a few more variables.  The precise number for any given base will depend on how much equipment is present: one for each auger, two for each smelter, and one for each workshop.  Setting all of them and the lastUpdateString variables for all parts with Kerbals in them yields a workaround.  As a result, my Gilly base is back in business, and I know what to do if any other base is similarly affected.

[taniwha]

Thank you for that. I'll see what I can do. BTW, I suspect there might be a similar issue for stock drills and ISRU units (if not, I want to know!).

[cgwhite4]

No anomalous behavior by the ISRU or drills was detected during fueling for the scanner probe mission to Dres I was working on at my Gilly base.  The payload was lighter than for most of my launches, so its rocket was also the smallest I have sent to Dres (only about 20k or so liquid fuel would have been required).  Thus, I would have expected to observe a noticeable spike in my base's liquid fuel and oxidizer gauges had the issue affected the fueling system as well.

[Lible]

On 2/14/2017 at 3:43 AM, taniwha said:

In the meantime, I'll keep poking to see why the survey station has an empty site in its list.

I have exactly the same problem on one of my Mun bases. Multiple other building sites all over the Kerbol system are just fine. Big fan of your work.

The survey station on the bugged base is manned by a level 3 pilot and the stakes are definitely less than 50m away from the center of mass of the base. However, I have a hypothesis, how it can still be distance related to stakes..

In my case, the problem developed immediately after launching a relatively big build, boosted by 2 SRBs. When I later switched back to the base, two things had happened:

 1. One of the survey stakes (X-) was gone. Possibly, the SRB exhaust blew it off, and landed it either so far away that I could not find it easily, or possibly below-ground.

 2. The survey station Show UI window was bugged out, exactly like on the screenshot posted by Barcel.

I have been able to *temporarily* remedy this problem by removing existing stakes and re-planting them. But the problem re-occurs shortly after that, tho none of the stakes have been blown away subsequently.

Could it be that the survey station picks up two X- stakes and gets confused? Or maybe the missing X- stake ended up still within range, but in a glitched out place?

I will experiment some more, later today.

After experimentation:

Got rid of that glitch with survey station UI being messed up. 

It was indeed a rogue survey stake. Once I switched on "Toggle Unknown" in the KSC tracking station, I could see it floating approximately 10km above my base, whilst mouse-hover over it showed it as "landed".

Once I terminated that object in the tracking station, the base went back to normal.

Edited February 15, 2017 by Lible

[cgwhite4]

The issue occurred a third time, this time at my base on Minmus, giving me a chance to watch very carefully for any effect of the bug on the fuel management side of the base infrastructure.  The workaround was applied to all construction and metal ore / metal / rocket part management equipment.  It was not applied to the ISRU or the drills.  After completing the Finalize Build step and ensuring that the resource gauge pane was locked visible, I started the fueling process, and observed no resource level spikes, confirming that the bug is limited to construction and EL-based resource processing.

[taniwha]

14 hours ago, Lible said:

It was indeed a rogue survey stake. Once I switched on "Toggle Unknown" in the KSC tracking station, I could see it floating approximately 10km above my base, whilst mouse-hover over it showed it as "landed".

Ah, excellent sleuthing. If that was the stake the survey station was trying to access, then it would indeed cause problems (though really, it shouldn't be part of the site if there are other stakes in the site). In the problematic code, the survey station accesses the first stake in the site with insufficient sanity checks (such as the vessel being loaded). However, two stakes must be within 200m of each other to be considered part of the same site (a long line of stakes 199.9m apart will be one site though)

I do wonder why the stake was getting picked up. I'll double check my code there too.

 

9 minutes ago, cgwhite4 said:

After completing the Finalize Build step and ensuring that the resource gauge pane was locked visible, I started the fueling process, and observed no resource level spikes, confirming that the bug is limited to construction and EL-based resource processing.

Hmm, while I'm not 100% confident that's a good test, it does make me think I need to do some more investigation. Thank youl.

[SHiRKiT]

Can someone explain to me what each of the modules does? I suppose they are these, but I needed a confirmation!

1. EL Launchpad: ?????
2. EL Survey Station: ????
3. EL Target: this is to place a rocket at a certain location after it's built?
4. EL Workshop: this is what helps the rocket to be built? Where the construction happens?

[goldenpsp]

53 minutes ago, SHiRKiT said:

Can someone explain to me what each of the modules does? I suppose they are these, but I needed a confirmation!

1. EL Launchpad: ?????
2. EL Survey Station: ????
3. EL Target: this is to place a rocket at a certain location after it's built?
4. EL Workshop: this is what helps the rocket to be built? Where the construction happens?

There is a link to a quick tutorial as well as a video in the OP.  There are also a plethora of mod highlight/overview/review videos for EL that go over all of the parts.  have you tried those?

[taniwha]

@SHiRKiT: the section is meant for modders, but check section 4 of the manual. It describes the modules in detail (though not the conversion modules (auger and smelter), forgot to do those)

[SHiRKiT]

9 hours ago, taniwha said:

@SHiRKiT: the section is meant for modders, but check section 4 of the manual. It describes the modules in detail (though not the conversion modules (auger and smelter), forgot to do those)

Thanks! Exactly what I was looking for, didn't know about that manual!

[ss8913]

so how does the recycling bin work?  I set up a station that has one, and a big empty Kontainer of recyclables (also using MKS).  pointed a test craft at the recycler after activating it.. "docked" with the bin... it recycled the nose cone and one of the reactors from the *middle* of the vessel, and then the rest of it just drifted away.  Also I didn't get any recyclables.  Is this part deprecated or something?  Or am I using it incorrectly?

[taniwha]

@ss8913: it is not at all deprecated (though who knows what RD is doing in MKS). As for only two parts getting recycled and the rest drifting off... well, that's something you can fix in-game by instead of leaving things to random chance, applying a bit of knowledge (not yours).

I'm not certain, but I think you're the first person to mention that particular behavior here. (it is, actually, a very deliberate feature).

[ss8913]

20 hours ago, taniwha said:

@ss8913: it is not at all deprecated (though who knows what RD is doing in MKS). As for only two parts getting recycled and the rest drifting off... well, that's something you can fix in-game by instead of leaving things to random chance, applying a bit of knowledge (not yours).

I'm not certain, but I think you're the first person to mention that particular behavior here. (it is, actually, a very deliberate feature).

I'm  confused as to how I left things to random chance and what knowledge I could have applied?  Again, as I originally asked, "am I doing this right?"   What's the correct method?

[taniwha]

2 hours ago, ss8913 said:

I'm  confused as to how I left things to random chance and what knowledge I could have applied?  Again, as I originally asked, "am I doing this right?"   What's the correct method?

You didn't do anything wrong, as such. I don't what to just give out the answer. I did leave clues in that first paragraph, especially the last phrase. Another hint: people who know how things are put together often know how to take them apart.

[cgwhite4]

While launching a rover to the surface of Duna from my Ike base after having not built anything from it for a while, I noticed that the issue that I had experienced 3 times and was expecting to possibly have to work around again did not occur.  Just prior to the start of construction, I had been performing other operations in the vicinity of the Ike base: landing an incoming vessel, operating a recycler rover on some debris and a module that was no longer needed, and performing EVA's (involving making KAS winch connections).  Perhaps during my earlier tests involving waiting a certain amount of time before starting a build, I somehow did not wait long enough.  My MET indicator does tend to stay yellow while I am operating at one of my bases, though that should not have affected the test involving the time warp.

[taniwha]

Well, a yellow MET can mean time flows at 3:1 or even 4:1 (or worse, though... ugh), so that 90s game time to catch up can translate to 360s (6 minutes) real time, which is a long time to wait.

[cgwhite4]

Then it's a good thing that I don't have to, thanks to what we discovered about the update time variables.

[taniwha]

yeah, though I very much intend on fixing it!

[ss8913]

On 2/17/2017 at 6:36 PM, taniwha said:

You didn't do anything wrong, as such. I don't what to just give out the answer. I did leave clues in that first paragraph, especially the last phrase. Another hint: people who know how things are put together often know how to take them apart.

OK, I think I've got it   What's the expected output, btw?  Recyclables?  Or is it going to want to output RocketParts which I'm not using due to MKS?

[taniwha]

37 minutes ago, ss8913 said:

What's the expected output, btw?  Recyclables?  Or is it going to want to output RocketParts which I'm not using due to MKS?

This depends very much on how MKS has set the recipes. The recycler looks at the part's recipe to determine how to break it down, then looks at recipes for those resources. Look in GameData/UmbraSpaceIndustries/MKS/EL_USI.cfg

Or maybe MKS_EL.cfg.

Edited February 20, 2017 by taniwha

[Trigonaut]

I've been having fun with some USI packs, but is there some sort of incompatibility which makes the survey stakes and mallet inaccessible? I can't find them in the tech tree or even in sandbox mode, though the EL modules don't seem to work without designating a launch site. Is there something else I'm doing wrong?