[1.9-1.10] Global Construction

[firda]

What is the orientation of the kit? How do I check? How do I make sure up is up?

I have base-addon build in SPH:

Spoiler

build a ship (with seconady mission on top, but that is not relevant)

Spoiler

land and start building, but it grows in wrong direction - it should be flat, not growing up!

EDIT: This little arrow? Is that up? (I do not really care what is left and what forward, but that should be knowable as well .... and things imported from SPH should not end like this!)

Spoiler

However final result is as expected ... strange ... the expansion is wrong/strange, but the result is ok:

Edited March 20, 2020 by firda
Rotate launch direction, final result

[Polokratos]

I am currently trying to build a kit to store my [big fat and heavy] rover.
When i give the order in GAL UI, i get the message "No suitable assembly space was found"
Now, small assemblies/single parts work perfectly fine, and I am able to construct both the kit and the actual vessel.

Is there a hard limit to just how big the kits constructed in a Ground Assembly Line can be or something or am I just being stupid and missing the obvious?

[allista]

Version 2.6.1.1 for Kerbal Space Program 1.9.1

Released on 2020-04-28

• Compatible with KSP-1.9
• Compiled against AT_Utils 1.9.2

 Download 

 

Version 2.6.1 for Kerbal Space Program 1.8.1

Released on 2020-04-28

• Added auto activation/deactivation feature to Magnetic Forklift
• Compiled against AT_Utils 1.9.1

 Download 

[BigFatStupidHead]

Hey! I just started playing the new version. Your timing is impeccable!

[B-STRK]

3 hours ago, allista said:

Version 2.6.1.1 for Kerbal Space Program 1.9.1

Released on 2020-04-28

• Compatible with KSP-1.9
• Compiled against AT_Utils 1.9.2

 Download 

 

Version 2.6.1 for Kerbal Space Program 1.8.1

Released on 2020-04-28

• Added auto activation/deactivation feature to Magnetic Forklift
• Compiled against AT_Utils 1.9.1

 Download 

Good to see you again, allista! Hope things are well on your end.

I know I asked this question before, but I am not sure if I was able to catch an answer from you or anyone who might know. My apologies if an answer was already given.

Given that some constructions' EC requirements may exceed the available battery capacity of the construction station, I assume this would be why construction stalls if the setup is not in scene focus/is in background for some amount of time. I also note that having positive EC flows in the constructing vessel (via enough RTGs to have a surplus of a little over +2EC over consumption while under focus and 1x time warp) will not contribute to being able to have construction ongoing in the background--meaning it will stall construction after leaving the scene for some time.

I'd like to ask is, if it is necessary/advisable for the construction to be in-focus (not in background) throughout the entire process? As it stands, whenever a construction is going on, I only leave it for very short moments (to, say conduct a launch, or a maneuver), then return ASAP to keep the construction going. This would make constructing multiple kits in different locations in the background highly difficult, at least. 

On the other hand, is there a minimum positive EC generation rate that must be on the vessel on leaving the scene in order for the construction to continue in the background? Also as things stand, I'm looking at upwards of 130k EC requirements and there isn't enough batteries to stack to get that much storage on hand. A USI, NFE, or WBI reactor on the other hand would be more part-efficient. (And on that note, what EC sources are required?) 

Thanks again for the update (as well as with Hangar and TCA)!

[allista]

8 hours ago, B-STRK said:

Good to see you again, allista! Hope things are well on your end.

I know I asked this question before, but I am not sure if I was able to catch an answer from you or anyone who might know. My apologies if an answer was already given.

Given that some constructions' EC requirements may exceed the available battery capacity of the construction station, I assume this would be why construction stalls if the setup is not in scene focus/is in background for some amount of time. I also note that having positive EC flows in the constructing vessel (via enough RTGs to have a surplus of a little over +2EC over consumption while under focus and 1x time warp) will not contribute to being able to have construction ongoing in the background--meaning it will stall construction after leaving the scene for some time.

I'd like to ask is, if it is necessary/advisable for the construction to be in-focus (not in background) throughout the entire process? As it stands, whenever a construction is going on, I only leave it for very short moments (to, say conduct a launch, or a maneuver), then return ASAP to keep the construction going. This would make constructing multiple kits in different locations in the background highly difficult, at least. 

On the other hand, is there a minimum positive EC generation rate that must be on the vessel on leaving the scene in order for the construction to continue in the background? Also as things stand, I'm looking at upwards of 130k EC requirements and there isn't enough batteries to stack to get that much storage on hand. A USI, NFE, or WBI reactor on the other hand would be more part-efficient. (And on that note, what EC sources are required?) 

Thanks again for the update (as well as with Hangar and TCA)!

"Background" construction in GC is implemented with a catch-up mechanism: 

1. When you switch away from the workshop everything stops, as the ship and all its parts cease to exist. Including generators, so there's no EC production.

2. When you switch back, the ship starts with exact same amount of EC it had before. In that instant GC (and many other mods I know of) calculates the time that had passed, the work that would have been done in that time, and the EC (and other resources) required for that work. Then it consumes it all in one gulp. If the ship had enough, the work is logged. If not, the resources are depleted, and proportionally smaller amount of work is logged.

An alternative would be to switch to Kerbalism for the real background processing of resources and all. But with stock mechanics we're stuck with these catch-ups.

I could somehow measure the net EC flux before switching to include it into the calculation and consume less when catching up. But that would upset the game balance, as one can use solar panels, wait until the sun raises, then switch away, and get the free evgeny. Or enable a fuel cell, leave, and get the energy without consuming any fuel...

Edited April 28, 2020 by allista

[DStaal]

To add to the above (I wasn't sure if GC followed the catch-up, so I didn't add earlier) - catch-up is typically done in 6-hour chunks.  So, @B-STRK you want enough battery to last at *least* 6 hours, and round that up.  Then the catch-up can fill that battery and drain it during the catch up repeatedly.  If you have less than 6 hours of storage, the catch up will act as if it's only online for the amount of storage you had.

[allista]

17 minutes ago, DStaal said:

To add to the above (I wasn't sure if GC followed the catch-up, so I didn't add earlier) - catch-up is typically done in 6-hour chunks.  So, @B-STRK you want enough battery to last at *least* 6 hours, and round that up.  Then the catch-up can fill that battery and drain it during the catch up repeatedly.  If you have less than 6 hours of storage, the catch up will act as if it's only online for the amount of storage you had.

No, GC doesn't work that way. How would you fill EC storage when catching-up without the risk of some other mods doing the same in parallel?

Everyone can consume however they like, but only legitimate generators can produce, again, for themselves, not for the whole vessels.

[DStaal]

1 hour ago, allista said:

No, GC doesn't work that way. How would you fill EC storage when catching-up without the risk of some other mods doing the same in parallel?

Everyone can consume however they like, but only legitimate generators can produce, again, for themselves, not for the whole vessels.

This isn't *GC* working this way.  This is *KSP* working this way: It utilizes the time-skip code to do the background catch-up, by calculating what happened in 6-hour time skip intervals.

[BigFatStupidHead]

@DStaal & @allista

A way to deal with this is Nertea's Dynamic battery storage mod

It is designed to compensate for time compression and the electrical oddities therein.

But what actually brought me here today;  I've been having some freezes when using the recycler. Does it have some problems when digging too deep into a vessel tree?

[allista]

9 hours ago, DStaal said:

This isn't *GC* working this way.  This is *KSP* working this way: It utilizes the time-skip code to do the background catch-up, by calculating what happened in 6-hour time skip intervals.

Oh! Oh!!! Since when?! 

When I made my own catch-up, it wasn't there for sure!

Where do I read on it? 

Spoiler

 

 

7 hours ago, BigFatStupidHead said:

@DStaal & @allista

A way to deal with this is Nertea's Dynamic battery storage mod

It is designed to compensate for time compression and the electrical oddities therein.

But what actually brought me here today;  I've been having some freezes when using the recycler. Does it have some problems when digging too deep into a vessel tree?

Thanks, I'll look at DBS. Maybe I could integrate with it somehow.

---

What kind of freezes, how to reproduce?

[BigFatStupidHead]

On 4/28/2020 at 10:17 PM, allista said:

What kind of freezes, how to reproduce?

I have a ship I want to recycle. When I click the recycle button, I use the GUI to open the nodes to navigate to the ship I want to recycle. However; when I attempt to open a node 5 deep, KSP freezes and I have to restart it. I will investigate for repeatability on other vessels.

 

It seems it may be related to the way this ship is designed, as I can go very far in the other direction in the tree with no freezes. I have a pair of nosecones surface attached that may be confusing it. I'll upload the ship for you to take a look at.

 

Here is the ship. It crashes freezes and requires a restart of KSP any time I attempt to open the Rockomax X200-32 node.  ...hopefully you have the breaking ground expansion...

Edited May 2, 2020 by BigFatStupidHead

[DStaal]

7 hours ago, allista said:

Oh! Oh!!! Since when?! 

When I made my own catch-up, it wasn't there for sure!

Where do I read on it? 

As far as I know, it's been there since at least when they implemented time-warp, which this is built off of.  It gets discussed a fair amount in the MKS thread, as it directly impacts the local logistics that MKS uses.  (Which makes in noticeable to players, otherwise typically in most situations it's not really noticeable.  It affects stock ISRU as well, but it's less visible there.)

I'm not sure if there's an official documentation source, it's mostly been 'this is the repeatable behavior we can all see' in MKS, though I think RoverDude has confirmed it.

[BigFatStupidHead]

 

On 4/28/2020 at 10:17 PM, allista said:

What kind of freezes, how to reproduce?

I have refined my opinion on what is occuring. I think it  is getting confused and hanging when the recycler encounters a tree node with anything surface-attached. Problem occurs with the new craft I just added to the repo when the recycler attempts to open the tree node with all the surface-attached greebles and doodads.

 

The only other correlation is both parts it freezes on are fuel tanks modified by ConfigurableContainers. (I use the full version)

Edited May 2, 2020 by BigFatStupidHead
Another thought

[allista]

On 4/29/2020 at 4:18 PM, DStaal said:

As far as I know, it's been there since at least when they implemented time-warp, which this is built off of.  It gets discussed a fair amount in the MKS thread, as it directly impacts the local logistics that MKS uses.  (Which makes in noticeable to players, otherwise typically in most situations it's not really noticeable.  It affects stock ISRU as well, but it's less visible there.)

I'm not sure if there's an official documentation source, it's mostly been 'this is the repeatable behavior we can all see' in MKS, though I think RoverDude has confirmed it.

Unfortunately, the code in BaseConverter->ModuleResourceConverter->ISRU is still basically the same as that of GC. No global catch-up, no resource generation and such. Just normal isolated module operation in 6h chunks.

Even more, ModuleGenerator does not use any catch-up! So if ISRU requires more EC than the ship has at loading time, it will also fail to catch up with its conversion.

So, aside from switching to Kerbalism, the only thing I can think of is switching to a dedicated power source that generates something other than EC and does its own catch-up. Which is not a good solution.

Edited May 1, 2020 by allista

[allista]

So, @B-STRK, @BigFatStupidHead,

I'd say the Dynamic Battery Storage or maybe AmpYear with its EC reserve feature may help to alleviate this problem; but not to solve it.

The real solution is lies in reimplementing stock mechanics, which is beyond our reach.

[allista]

On 3/20/2020 at 10:30 PM, firda said:

What is the orientation of the kit? How do I check? How do I make sure up is up?

I have base-addon build in SPH:

  Reveal hidden contents

build a ship (with seconady mission on top, but that is not relevant)

  Reveal hidden contents

land and start building, but it grows in wrong direction - it should be flat, not growing up!

Spoiler

 

EDIT: This little arrow? Is that up? (I do not really care what is left and what forward, but that should be knowable as well .... and things imported from SPH should not end like this!)

  Reveal hidden contents

However final result is as expected ... strange ... the expansion is wrong/strange, but the result is ok:

Spoiler

 

Thanks for the report.

It does look like a bug in calculation of container deployment dimensions, but I need to be able to reproduce and test it on my side.

Could you, please, provide the .craft file of this station addon?

On 4/3/2020 at 9:35 AM, Polokratos said:

I am currently trying to build a kit to store my [big fat and heavy] rover.
When i give the order in GAL UI, i get the message "No suitable assembly space was found"
Now, small assemblies/single parts work perfectly fine, and I am able to construct both the kit and the actual vessel.

Is there a hard limit to just how big the kits constructed in a Ground Assembly Line can be or something or am I just being stupid and missing the obvious?

The hard limit is the size of the assembly space.

The kit in the container has constant density, so the heavier the kit, the bigger the container. And once the kit is assembled in the assembly space, it have to be spawned inside the assembly space. And if it's bigger, you've got yourself big fat explosion.

So before a kit is accepted to the assembly queue, the present assembly spaces are checked for the ability to spawn the resulting container.

However, there's a way to work around this: an empty Kit Container is itself an assembly space without any limit, because it is itself resized before assembly begins.

So all you have to do is to spawn empty container (orbital if you're building in space, ground otherwise), and, if in orbit, to dock this container with arrows pointing to the docking port.

Then the Assembly Workshop will recognize the empty container as yet another assembly space which is always big enough for any kit.

[Marschig]

Workshops have USI LS modules like:

    MODULE:NEEDS[USILifeSupport]
    {
        name = ModuleLifeSupportRecycler
        CrewCapacity = 6
        RecyclePercent = 0.79
        ConverterName = Life Support
        tag = Life Support
        StartActionName = Start Life Support
        StopActionName = Stop Life Support

        INPUT_RESOURCE
        {
            ResourceName = ElectricCharge
            Ratio = 1.75
        }
    }

But these names were changed in USI LS, so workshop recycler doesn't work with USI LS 1.3.0.0. There is a patch to fix it:

@PART[*]:HAS[@MODULE[ModuleLifeSupportRecycler]]:NEEDS[GroundConstruction&USILifeSupport]:FINAL
{
	MODULE
	{
		name = USI_SwapController
	}
	MODULE
	{
		name = USI_SwappableBay
		bayName = Bay 1
		moduleIndex = 0
	}
	MODULE
	{
		name = USI_Converter
		UseSpecialistBonus = false
	} 
	@MODULE[ModuleLifeSupportRecycler]
	{
		@name = USILS_LifeSupportRecyclerSwapOption
	}
}

Maybe it makes sense to update the USI LS settings in the mod itself?

[Rodonies]

I'd love this mod if the parts were stocklike, for the moment I can't justify putting them on my ships because they have a very different aestethic.

Some of them seem like they would look way better if they were scaled down 800% because the parts on them lack complexity.
Maybe they would also look better if you introduced depth/grey lines to the big white flat surfaces.
Some of them also have things like have bright 'lamps' where the RGB values seem to be just (255,0,0), they look very out of place.

Edited May 2, 2020 by Rodonies

[allista]

49 minutes ago, Rodonies said:

I'd love this mod if the parts were stocklike, for the moment I can't justify putting them on my ships because they have a very different aestethic.

Some of them seem like they would look way better if they were scaled down 800% because the parts on them lack complexity.
Maybe they would also look better if you introduced depth/grey lines to the big white flat surfaces.
Some of them also have things like have bright 'lamps' where the RGB values seem to be just (255,0,0), they look very out of place.

All the models and textures are available in the repo. You are free to remake them as you like.

[allista]

1 hour ago, Marschig said:

Workshops have USI LS modules like:

But these names were changed in USI LS, so workshop recycler doesn't work with USI LS 1.3.0.0. There is a patch to fix it:

Maybe it makes sense to update the USI LS settings in the mod itself?

Thanks for the info. Done.

[Rodonies]

16 minutes ago, allista said:

All the models and textures are available in the repo. You are free to remake them as you like.

I do not have the skills nor the time to do this, I was merely providing feedback/ideas in (what I think was) a constructive way.

[B-STRK]

5 hours ago, allista said:

Thanks for the report.

It does look like a bug in calculation of container deployment dimensions, but I need to be able to reproduce and test it on my side.

Could you, please, provide the .craft file of this station addon?

If I might contribute my own experience of this issue?

I notice that this effect happens when I load an SPH vessel into a Kit in the VAB. The way I see it, when I plop a Kit in the SPH, it is lying on its side, and the expansion/rotation GUI there takes into account that the "floor" of the deployment is the Kit's side facing the floor--or it takes into account the Kit lying on its side. And this carries over even to a Kit plopped in the VAB as well (which is what one would reasonably do to make the skycrane and LV), so as long as the vessel is loaded from the SPH craft tab. Thus a Kit standing up but with an SPH vessel loaded would deploy as though it were lying on its side, but as observed by firda, upon launch the vessel is oriented properly anyway.

But if I save the SPH vessel in the VAB in the proper orientation (the floor is pointing in the right direction), then loaded into the Kit from the VAB craft tab, then the deployment GUI and actual deployment is properly set (e.g. lateral, not vertical), and yes the craft is launched in the proper orientation as well.

So saving SPH vessels intended for GC to the VAB for loading is my workaround at the moment. I'm not a programmer by any means, but intuitively, maybe the logic is working out that the mod's loading SPH deployment behavior into the VAB?

Edited May 2, 2020 by B-STRK
I hate typing kn my phone sometimes

[allista]

On 4/29/2020 at 10:46 PM, BigFatStupidHead said:

 

I have refined my opinion on what is occuring. I think it  is getting confused and hanging when the recycler encounters a tree node with anything surface-attached. Problem occurs with the new craft I just added to the repo when the recycler attempts to open the tree node with all the surface-attached greebles and doodads.

 

The only other correlation is both parts it freezes on are fuel tanks modified by ConfigurableContainers. (I use the full version)

That was puzzlling; the freeze occurred in Unity's native Object.Instantiate method (!!!), not at all related to surface attached parts.

So I got stuck for a day with this... until I realized that the cause was simply the amount of subnodes added to the tree at the same time.

So the fix is to add them one by one; this causes the node to open with a noticeable delay, but it does open now.

Thanks again for you report, analysis and test crafts!

[allista]

17 hours ago, B-STRK said:

If I might contribute my own experience of this issue?

I notice that this effect happens when I load an SPH vessel into a Kit in the VAB. The way I see it, when I plop a Kit in the SPH, it is lying on its side, and the expansion/rotation GUI there takes into account that the "floor" of the deployment is the Kit's side facing the floor--or it takes into account the Kit lying on its side. And this carries over even to a Kit plopped in the VAB as well (which is what one would reasonably do to make the skycrane and LV), so as long as the vessel is loaded from the SPH craft tab. Thus a Kit standing up but with an SPH vessel loaded would deploy as though it were lying on its side, but as observed by firda, upon launch the vessel is oriented properly anyway.

But if I save the SPH vessel in the VAB in the proper orientation (the floor is pointing in the right direction), then loaded into the Kit from the VAB craft tab, then the deployment GUI and actual deployment is properly set (e.g. lateral, not vertical), and yes the craft is launched in the proper orientation as well.

So saving SPH vessels intended for GC to the VAB for loading is my workaround at the moment. I'm not a programmer by any means, but intuitively, maybe the logic is working out that the mod's loading SPH deployment behavior into the VAB?

Thanks, that was very helpful indeed. Found and fixed the problem.