[1.9-1.10] Global Construction

[Terwin]

As far as using stock ISRU modules to produce material kits, I think the rate of production makes this option little more than an after-thought in any scenario where you can already produce material kits unless your MKS production line is severely resource constrained.  But it can also be very helpful when trying to kick-start a colony.

While aerodynamics are a non-trivial problem to address for bases, GC also either allows you to break apart your base delivery vessel into multiple parts(DIY Kit and one or more MK cargo vessels), or produce part of the mass on-site(if using locally produced Material Kits).  And launching multiple smaller payloads is much easier than launching fewer larger ones, especially when you need a large dV budget such as interplanetary transfers.

 

@allista I would probably transfer the kit either by attaching a Klaw to a sky-hook type apparatus, or by using KAS to put it in place on the transit vehicle(may require construction vehicles to have enough mass capacity to move it, possibly even a crane on the transit vehicle).

 

Edited June 22, 2017 by Terwin

[allista]

@Kobymaru, @Terwin, any comments on the scheme?

Edited June 22, 2017 by allista

[Kobymaru]

14 minutes ago, allista said:

@Kobymaru, @Terwin, any comments on the scheme?

I like it, but I have questions.

First, where does the Kit Spawn when in Orbit? Does it spawn attached to part with PartModule KitAssemblyLine?

Second, did I understand correctly that on the surface, you want to first spawn an AssemblyYard vessel, which then spawns a DIY kit? Why the indirection? Why not just spawn the kit right there instead of the AssemblyYard?

Third, I think it would be easier and more consitent, if there were as few distinctions between Surface/Orbit as possible. Admittedly, it's kind of weird to spawn DIY kits in free-Floating space in a random location (because pointing with a 2D mouse in 3D space is not really feasible), but on the other hand, why not?

Quote

Spawn completed DIY kit at its location. But again how to transport it?

See my previous post.

Edited June 22, 2017 by Kobymaru

[allista]

8 minutes ago, Kobymaru said:

I like it, but I have questions.

First, where does the Kit Spawn when in Orbit? Does it spawn attached to part with PartModule KitAssemblyLine?

Second, did I understand correctly that on the surface, you want to first spawn an AssemblyYard vessel, which then spawns a DIY kit? Why the indirection? Why not just spawn the kit right there instead of the AssemblyYard?

Third, I think it would be easier and more consitent, if there were as few distinctions between Surface/Orbit as possible. Admittedly, it's kind of weird to spawn DIY kits in free-Floating space in a random location (because pointing with a 2D mouse in 3D space is not really feasible), but on the other hand, why not?

First question bothers me as well. Probably so. It would also make sense logistically: you'll have a hatch from inside the AssemblyLine into the docked kit container and would simply put everything in it until it's full, then undock it.

Second: correct. The reasoning goes like this:

1. Kit production takes much time, and completed kit takes some space. A kit may be well bigger than the AssemblyLine. Kerbals would work on part-kits in the line, but where would they put the products? So you need a storage for parts of incomplete kit, and a place for assembling them into the box.
2. When you spawn something, it's best to be sure that nothing gets in the way. As with the kits themselves, inflatable parts are the best to achieve this, as they can physically push objects away. Unlike the kit, AssemblyYard would be a very small and flat thing when you spawn it, but then it can inflate to the size of the future kit. So it's also a matter of aesthetics.

Third: for the same reason of respecting the kraken's slumber 

[Kobymaru]

14 minutes ago, allista said:

First question bothers me as well. Probably so. It would also make sense logistically: you'll have a hatch from inside the AssemblyLine into the docked kit container and would simply put everything in it until it's full, then undock it.

Excuse my ignorance, I still don't quite understand it. In terms of game objects as parts with a rigidbody, colliders and mass, what is the "AssemblyLine", what is the "hatch", what is the "docked kit container", how does the kit container become docked, and where does it come from? 

 

14 minutes ago, allista said:

Second: correct. The reasoning goes like this:

1. Kit production takes much time, and completed kit takes some space. A kit may be well bigger than the AssemblyLine. Kerbals would work on part-kits in the line, but where would they put the products? So you need a storage for parts of incomplete kit, and a place for assembling them into the box.

I think this is one of those times where it might better to abstract/roleplay. Sure, the Kit can theoretically be bigger than the AssemblyLine part, but we can all pretend that they build the part outside of the AssemblyLine part, and only when it's finished, do we actually see it.

In a sense, that's what we do with the DIY-kits, don't we? We pretend that the Kerbals are working on them for days/weeks, but we only see that in the menus. Only when they are done do we get to see the result. And the actual vessel is also bigger than the DIY kit, isn't it?

 

14 minutes ago, allista said:

1. When you spawn something, it's best to be sure that nothing gets in the way. As with the kits themselves, inflatable parts are the best to achieve this, as they can physically push objects away. Unlike the kit, AssemblyYard would be a very small and flat thing when you spawn it, but then it can inflate to the size of the future kit. So it's also a matter of aesthetics.

So in a sense, an AssemblyYard part would just be an intermediary part for safety and aesthetics reasons? I don't have an opinion on aesthetics, but I think if the user can pick a spawn point, it's the users responsibility to pick one where things don't horribly collide. But that's just my opinion.

 

14 minutes ago, allista said:

Third: for the same reason of respecting the kraken's slumber 

Alright, let's not wake the Kraken  But don't we risk waking him anyway each time we create Parts/Vessels out of thin air?

[RoverDude]

Hey @allista  Sorry for the late reply, but here are some thoughts.  Context wise, I'll be focusing on Core (the bit that MKS includes) understanding that there may be some differences with the full GC version

First RE mass/balance.  Mass should be the same - a 10 ton part should be assembled from 10 tons of resources.  The reason you'd use GC is to reduce launch mass by leveraging local ISRU for MatKits, and to make it a lot easier to land something stuffed in a box or two vs. a more complex assembly.  i.e. I like things the way they are

For MKS, I also assume that the DIYKit itself is made up of the SpecializedParts component of any part that's built.  I've had no issue with the costing of the DIYkit, as long as it's in the same ballpark we're good.  Any variances will even out in the mix.

For MatKits, as noted, the ISRU version is slow, but I would agree that this should be a fallback and overridden when other mods that provide their own chains are used.  In the case of MKS, production speed is traded for resource complexity and infrastructure.  Most of the time, I just ship the MatKits out until I have better infrastructure built up.

Re de novo kit production.  To paraphrase the flowchart, you need SpecParts to make a DIYkit.  This is exactly how I would envision it for MKS (including the Machinery requirement).  the only diff between GC with MKS and without is that without, you'd use ISRU to make everything (Machinery, matKits, SpecParts) where MKS has separate bits and workflow for this.

From there, I agree with the flow RE spawning, etc.

For transport, this IMO is an exercise for the user.  the kit spawns, and is either in orbit (via hanger or attached to some other part with a decouple option like a dry dock), or spawns as a vessel on the ground (same way I do resouce lodes today in MKS - feel free to borrow any code!).

You could also do the attach method on the ground I suppose.  And in theory could also limit orbital vessel size to the dry dock dimension, thus encouraging more bootstrapping for larger and larger space docks.

Transport in core GC could be as simple as running over with a claw.  In MKS land, you would probably do something Akita based.  Remember there's also the Osprey in the wings which can easily move some massive DIYKits.

[Terwin]

2 hours ago, allista said:

Kobymaru, Terwin, any comments on the scheme?

As far as the Assembly yard, I thought that was a reference to the vessel with the assembly module, but the idea of an inflatable scaffolding that is removed to expose the completed DIY Kit is appealing.

Personally, I would use a DIYKit deployment node on any assembly yard module that is capable of producing kits, sort of like the EL does.  

Due to the ability to combine workshops, you could even make a 'deployment module' that has the deployment node and perhaps a place for the science kerbal that is required for making the kits, then use the already existing Engineering workshop modules to provide the engineer-time inputs.

Having a deployment node approach means that users can plan to have this elevated with a path underneath it to allow for a flat-bed truck equivalent(possibly with a klaw mounted in the bed) to catch the kit when it detaches and carry it to it's destination(in addition to all the other options).

The possibilities of uneven terrain, and the potential complexities of things like survey stakes, make me cautious about the prospect of just spawning a kit that is not attached to anything(this would also make it harder to use in orbit).

In orbit, my understanding was that there would need to be a 'hangar' type module where the kit could be expanded and assembled, and if you allow detaching an un-deployed kit for delivery elsewhere, I see no reason that you would not just populate any new kits(possibly starting with a scaffolding again) inside a Hangar module.

[allista]

1 hour ago, RoverDude said:

Hey @allista  Sorry for the late reply, but here are some thoughts.  Context wise, I'll be focusing on Core (the bit that MKS includes) understanding that there may be some differences with the full GC version

First RE mass/balance.  Mass should be the same - a 10 ton part should be assembled from 10 tons of resources.  The reason you'd use GC is to reduce launch mass by leveraging local ISRU for MatKits, and to make it a lot easier to land something stuffed in a box or two vs. a more complex assembly.  i.e. I like things the way they are

For MKS, I also assume that the DIYKit itself is made up of the SpecializedParts component of any part that's built.  I've had no issue with the costing of the DIYkit, as long as it's in the same ballpark we're good.  Any variances will even out in the mix.

For MatKits, as noted, the ISRU version is slow, but I would agree that this should be a fallback and overridden when other mods that provide their own chains are used.  In the case of MKS, production speed is traded for resource complexity and infrastructure.  Most of the time, I just ship the MatKits out until I have better infrastructure built up.

Re de novo kit production.  To paraphrase the flowchart, you need SpecParts to make a DIYkit.  This is exactly how I would envision it for MKS (including the Machinery requirement).  the only diff between GC with MKS and without is that without, you'd use ISRU to make everything (Machinery, matKits, SpecParts) where MKS has separate bits and workflow for this.

From there, I agree with the flow RE spawning, etc.

For transport, this IMO is an exercise for the user.  the kit spawns, and is either in orbit (via hanger or attached to some other part with a decouple option like a dry dock), or spawns as a vessel on the ground (same way I do resouce lodes today in MKS - feel free to borrow any code!).

You could also do the attach method on the ground I suppose.  And in theory could also limit orbital vessel size to the dry dock dimension, thus encouraging more bootstrapping for larger and larger space docks.

Transport in core GC could be as simple as running over with a claw.  In MKS land, you would probably do something Akita based.  Remember there's also the Osprey in the wings which can easily move some massive DIYKits.

Hey, nothing's late about it: a hobby is a hobby 

Ok, so I'm leaving everything concerning mass/cost balance as is.

And I'll add the :NEEDS[!KolonyTools] stanza to the ISRU patch (is it the correct way to check for MKS, though?).

RE spawning: this is still the most troubling part for me.

• The ground is simple, as basically it is already implemented.
• The attachment:
  • in orbit is prone to blow things up if the attach node becomes obscured by other parts of the station. Or if something flies by.
  • on the ground has the same flaws + gravity will force to always attach the container on top, vertically.
• The dry-dock method is, essentially, what the Hangar does; so I will need to either move some things from it into AT_Utils (which is tedious), or we'll have to bundle Hangar.dll too.
  • Except that Hangar stores and launches ProtoVessels, not ShipConstructs, so I'll need to adapt to that too.
  • And that will require, as you said, several dry docks of different sizes; and some larger kits will still be restricted to ship-from-Kerbin only.

Transport: agreed.

[Dolkramp]

 Perhaps for orbital kits you could make it like KAS attachment; the kit spawns as an item in a "drydock inventory". The player can then drag it to attach to the station/ship they're building on, or even just floating in space. You'd still have the problem of collision when the kit expands or finalizes though.

[TheRagingIrishman]

4 hours ago, allista said:

And I'll add the :NEEDS[!KolonyTools] stanza to the ISRU patch (is it the correct way to check for MKS, though?).

Yes

[Alshain]

@allista I'm getting a freeze on load coming from the v1.2 version of this mod.

https://www.dropbox.com/s/7riphki2eqozgu6/output_log.txt?dl=0

[Kenchikuka]

15 hours ago, allista said:

Ore smelter is not included if you're using GC bundled with MKS; it is only there in stand-alone version. But I'll try to detect MKS and remove it in case of two separate installs. Thanks.

As for the cost, that's a problem really. No matter how you change ComplexityFactor, there's a simple tradeoff that balances mass and cost:

Kit mass = Ship dry mass * complexity

Required MaterialKits = Ship dry mass - Kit mass = Ship dry mass * (1-complexity)

Kit cost = Ship dry cost - cost of required MaterialKits

So unless the cost of required MaterialKits is greater than the dry cost of the ship, you will always spend exactly the same total amount, no matter the value of ComplexityFactor.

But, I'll think of how to better manage the case when the cost of MaterialKits required to build the ship is greater than the dry cost of the ship in editor. Currently you just pay for MaterialKits. But maybe I should correct complexity instead... So thanks again for your keen observation.

 

Talked about the smelter because i see the module working even in a clean install with GC+MKS, but i think you already resolved this.

 

About the balance, its more a thing until we have complete off world construction.

My understand for the code was that complexity will change add_mass and this will change cost, i dont realised that the resourse cost as about Material Kits cost. Read code in Git page is no fun =) (next time i download and open in VS or something else)

I will just increase cost of Material Kits for my game, and wait patiently for complete off world construction, thanks for the attention! =)

 

Playing in career moderate, founds are dificult mid game (still paing for upgrades and parts in research), its dificult to pay for all the things MKS and GC needs, and still have to launch spensive DIY Kits.

I make more difficult (and fun) because some personal rules:

Can only start research nodes on next level after research all nodes on current level;

Can only buy part research on node after buy all part researchs on required nodes.

 

Thanks again, keep the good work!

 

 

 

 

 

[allista]

7 hours ago, Alshain said:

@allista I'm getting a freeze on load coming from the v1.2 version of this mod.

https://www.dropbox.com/s/7riphki2eqozgu6/output_log.txt?dl=0

You're missing ConfigurableContainers folder with core config files that are distributed with AT_Utils. Reinstall AT_Utils: https://github.com/allista/AT_Utils/releases/download/v1.4.4/AT_Utils-1.4.4.0.zip

[Fyrem]

perhaps I mixed and matched something wrong. but, after the updates I did today on :

000_AT_Utils

ConfigurableContainers

GroundConstruction

 

ksp crashes on load.  hmmm,

[allista]

1 minute ago, Fyrem said:

perhaps I mixed and matched something wrong. but, after the updates I did today on :

000_AT_Utils

ConfigurableContainers

GroundConstruction

 

ksp crashes on load.  hmmm,

Logs?

[Fyrem]

yeyep,, was getting them,  

https://1drv.ms/t/s!Atikg8UOEhcyuhZByjYfbwThkbBj output log

https://1drv.ms/u/s!Atikg8UOEhcyuhcuMRylZL6fFAye error file

https://1drv.ms/u/s!Atikg8UOEhcyuhgsM4ZnAs-4wTQ2 crashdump

Edited June 24, 2017 by Fyrem

[allista]

26 minutes ago, Fyrem said:

yeyep,, was getting them,  

https://1drv.ms/t/s!Atikg8UOEhcyuhZByjYfbwThkbBj output log

https://1drv.ms/u/s!Atikg8UOEhcyuhcuMRylZL6fFAye error file

https://1drv.ms/u/s!Atikg8UOEhcyuhgsM4ZnAs-4wTQ2 crashdump

This time I don't see any straightforward problems, apart from the presence of OneTimeResourceConverter.dll in GC/Plugins folder, which shouldn't be there, but also shouldn't cause trouble.

Remove it, and if it won't help, try a clean install with only GC(AT_Utils included)+CommunityResourcePack+ModuleManager. If that crushes, something's wrong with my dlls; if not, there's a mod conflict of some sort.

[Fyrem]

removing OneTimeResourceConverter.dll from that folder fixed it.

thanks!

[Kerbal101]

@allista @Fyrem "OneTimeResourceConverter.dll" is part of the GroundConstruction that is shipped as part of USI MKS. In addition, the suborders "Patches" and "Parts/Mobile Workshop"+"../SpaceCrane" are absent.

I would appreciate if @RoverDude would instead create MM patches to mask the unneeded elements, for example in a new subdirectory "USI/GroundConstructionPatches" and ship a stock GroundConstruction instead.
Of course, if its technically possible.

[Kerbal101]

Also for some reason, ConfigurableContainers is included into current 1.2.0 GroundConstruction (+ into AT_Utils)

[RoverDude]

22 hours ago, Kerbal101 said:

@allista @Fyrem "OneTimeResourceConverter.dll" is part of the GroundConstruction that is shipped as part of USI MKS. In addition, the suborders "Patches" and "Parts/Mobile Workshop"+"../SpaceCrane" are absent.

I would appreciate if @RoverDude would instead create MM patches to mask the unneeded elements, for example in a new subdirectory "USI/GroundConstructionPatches" and ship a stock GroundConstruction instead.
Of course, if its technically possible.

Actually, the whole reason @allista broke out GC Core (which is what MKS uses) was to specifically prevent the need for a bunch of MM configs and re-patching.

[Kerbal101]

@RoverDude So you would recommend using the GroundConstruction shipped with MKS instead?

Edit: To clear things up, current GC in MKS is 1.1.2, where lastest GC release is 1.2 (available from SpaceDock, as stated in the only bug report on github).

 

The situation with @Fyrem is that he installed MKS, but then copied stock GroundConstruction over them (GroundConstruction and 00_AT_Utils directories).
Thats about the same situation with me, but I was checking for collisions via google searching for prior to merge, specifically for that file.

Edited August 6, 2017 by Kerbal101

[RoverDude]

3 hours ago, Kerbal101 said:

@RoverDude So you would recommend using the GroundConstruction shipped with MKS instead?

Edit: To clear things up, current GC in MKS is 1.1.2, where lastest GC release is 1.2 (available from SpaceDock, as stated in the only bug report on github).

 

The situation with @Fyrem is that he installed MKS, but then copied stock GroundConstruction over them (GroundConstruction and 00_AT_Utils directories).
Thats about the same situation with me, but I was checking for collisions via google searching for prior to merge, specifically for that file.

Assuming that @allista is using KSP-AVC, my recommendation is to install what comes with MKS, then grab updated versions (in this case, core) as recommended by KSP-AVC.  It's the cleanest way to manage dependencies like this.

[Wyzard]

3 hours ago, RoverDude said:

Assuming that @allista is using KSP-AVC, my recommendation is to install what comes with MKS, then grab updated versions (in this case, core) as recommended by KSP-AVC.  It's the cleanest way to manage dependencies like this.

There doesn't seem to be a separate release of GC-Core, though, just full GC.  I asked about that awhile back and Allista provided some directions on how to manually strip down GC to get the Core subset:

[juanml82]

Hi, I'm trying to launch a 100% complete kit, but I get the error "can not launch from a packed construction kit". What does it mean and how can I launch the ship?