[1.9-1.10] Global Construction

[allista]

1 minute ago, gamerscircle said:

HI @allista, I could have swore that I started it from an MKS "Tundra" Pioneer Logistics Module.  While that was working, I also had to move things around in that base, so I am not sure if that might have caused a reset or not?  [moving kerbals around too]

I then landed a 2nd DIY Kit and I was getting the error [No Engineer in the workshop] and I did in fact have one in the MKS "Tundra" Pioneer Logistics Module , but was still getting the error.  I just thought I would try the same thing from the MKS "Tundra" Assembly Plant and well. that worked!!

and.. the GC Panel is showing the status .. again.

Am I allowed to start 2 DIY kits at the same time?

This is strange. If you can reproduce it, could you capture a video for me?

 

No, one workshop can construct only one kit at a time (hence construction queue). But two or more workshops can; they can also build the same kit, accelerating the process.

[gamerscircle]

7 minutes ago, allista said:

This is strange. If you can reproduce it, could you capture a video for me?

 

No, one workshop can construct only one kit at a time (hence construction queue). But two or more workshops can; they can also build the same kit, accelerating the process.

I will attempt to help ... So, bottom line... since it worked from the Assem Plant , I see that on the Logistics, the PUD and the Refinery, that there is a construction window option.  Are those all "Work shops" or just have access to the que?

[allista]

Just now, gamerscircle said:

I will attempt to help ... So, bottom line... since it worked from the Assem Plant , I see that on the Logistics, the PUD and the Refinery, that there is a construction window option.  Are those all "Work shops" or just have access to the que?

They're all separate workshops with separate queues, yes. But each will require at least one engineer inside to work. So if you have only one engineer who's in the PUD, the PUD will work, but Logistics and Refinery won't. And vice versa.

[RoverDude]

A suggestion - maybe have workshops be a white list vs all command parts?  

[mcortez]

Just describing my play style as someone that's used USI & EL/Workshop for a while now :: 

When I land (or crash) supply or expansion missions at an existing base, I often spend quite some real-life time (anywhere from 5 minutes to 30+) going around my recently landed vessel to disassemble various bits into Material Kits and using KIS/KAS to reconfigure things for use on site.  In many cases the fact that I'm getting material kits from the stuff I remove is actually a bonus -- I'm usually not relying on it to actually provide enough materials to build anything specific.  This process is fun and part of my play style, but can be a bit tedious on occasion -- especially when for whatever reason my physics tick slows down and I'm eager to "get on with" whatever I was actually trying to do.  This is particularly true when dealing with Space Station or Exploration Vessel construction in orbit, where the recently arrived vessel may not have the option of docking until I take care of these house keeping efforts -- all the while, it's slowly drifting away from from my station or construction site.

Adding in some kind of time delay to these processes would probably not really add to the play value -- for *me* -- and could make those times that it has become tedious to be even worse.

-==-

Now occasionally I do have an entire vessel that is no longer needed - and I specifically do want to recover every bit of it I can to work on a new vessel or expansion.  In these cases, I usually manually tear the vessel apart with KIS/KAS and store each part I know I'll need later, then demolish the rest back to material kits.  

If I somehow had the option to auto-magically start a process that scans through the parts tree of a vessel and automatically recovered all the parts that could be used as-is in some new construction, for example -- if I started construction of new Vessel A, and while that vessel is being constructed I did a "Recover parts for use in new vessel" command.  And that command not only reduced the materials cost of the new construction, but sped it up -- *that* would be awesome.  

But if all it did was spit out material kits at a slower rate, but with a higher return -- I suspect I'd just make sure my construction crew had enough supplies and would time warp through it -- even if that might awaken the Kraken and other annoying bugs due to time warp catch up.

Edited February 1, 2017 by mcortez

[allista]

Just now, RoverDude said:

A suggestion - maybe have workshops be a white list vs all command parts?  

They're not all command parts, but all crewable parts with enough m3/kerbal of free space. Mk1 pod will not be listed, but the science lab will. The restriction is configurable, so we can exclude almost all cockpits by tweaking it.

[DStaal]

50 minutes ago, RoverDude said:

@allista / @DStaal - my only feedback would be that it would be odd for similar processes (stuff -> MaterialKits) to have different return rates.  It makes things really weird for interop since GC will be bundled with MKS, and starting that off with a conflict is probably not a good idea.  Also, time is really never much of a lever in KSP, so people would just choose the path with the best rate.  Now, if it is a different process (i.e. stuff-> stored parts) then that's a different story.

I actually wasn't really thinking about time being the lever here - It sounded to me like Allista was thinking of having some part (even just the workshop itself) be necessary for the demolition.  So time is there, but really the lever is *mass*: Having the part, vs. just having a Kerbal go EVA.  If you're willing to spend mass on a disassembly yard, you can get better return.

52 minutes ago, allista said:

I agree: controlled slow demolition should have higher yield. Timescale should be much shorter than for construction, but again, the complexity factor should play its role here (one thing is to scrap a fuel tank, the other -- to disassemble a rocket engine). I think something like 1:5-1:10; what takes 5-10 hours to construct will require 1 hour to demolish.

Docking is not required: as far as the demolished ship stays loaded I can process parts remotely. So if the two ships are close enough with ~0 relative velocity, they'll stay that way throughout the full orbit. So I can safely switch to somewhere else, then return back after a time. The drift of some 100-1000m is not an issue. The most that could happen is that ships will drift beyond loading range. In that case demolition will just pause.

USITools provide wireless logistics, which is more complicated that demolition, so I don't want to reimplement it. But I still can have soft dependency and, if without USITools, distribute resulting resources through current ship only.

If the two ships are close enough with ~0 relative velocity, sure, docking isn't *technically* required.  I'm not sure I'm that good a pilot.    And if the ship being demolished drifts beyond loading range, how do I get it back?  Presumably I have it unmanned (so I don't demolish a Kerbal) and some of the parts have been demolished, so there's no guarantee of any type of control.  Of course I could move the ship doing the demolishing - but that's most likely a large station, and may not be very mobile.  So...  I wait until their orbits intersect again?  (Or have a tug just for this purpose, which is a clunky solution.)

And note that KSP has tendency to shift orbital velocities somewhat as center of mass changes - so if you're moving the mass over part-by-part, your relative velocity is changing.

In practice, I'd believe docking should be required - or at least allowed - as it will solve a lot of headache issues for users.  But that can be more complex, which is why I suggested it be 'put in a hanger and disassemble there'.  (Which makes sense from a realism standpoint to me as well: You don't want pieces flying loose, and you want to be able to get at things from different angles without having to worry about where your safety line is, etc.  Keeping the whole process inside - even if you don't pressurize the hanger - will make it much easier and safer.)

Ground of course is a different issue.  There you can actually park and be sure of 0 relative velocity.  (Well, within the confines of KSP's physics.) 

[allista]

@mcortez, what you've described is what I'm currently trying to accomplish with Hangar+KIS, not with GC per se.

@DStaal, @RoverDude, I deliberately left the proposition alone, because see above The question here is: should GC have standalone simplified demolition, or should I just point users to MKS for that? Or to use USI's demolition/logistics as is, but through GC interface?

[RoverDude]

29 minutes ago, allista said:

They're not all command parts, but all crewable parts with enough m3/kerbal of free space. Mk1 pod will not be listed, but the science lab will. The restriction is configurable, so we can exclude almost all cockpits by tweaking it.

Ahh ok - what we're seeing is a lot of the MKS parts (which are large) get this so there may be more workshops than intended   My ideal would be the ability to have a specific 'Workshop' part that I can whitelist for MKS and balance against the mobile workshop that comes with GC (since all of the MKS bits are mass/volume balanced based on capabilities).  

25 minutes ago, DStaal said:

I actually wasn't really thinking about time being the lever here - It sounded to me like Allista was thinking of having some part (even just the workshop itself) be necessary for the demolition.  So time is there, but really the lever is *mass*: Having the part, vs. just having a Kerbal go EVA.  If you're willing to spend mass on a disassembly yard, you can get better return.

This I really like. 

I can totally see having a specific 'disassembly' type part that if you invest in it, you get the option of better yields.  In general, stuff where the parts chosen reflect the function (i.e. a ground based assembly facility kinda looks like one) are, IMO, always good.

 

(Addendum)

in the above scenario, the instant explodey-type demolition is better for bootstrapping, but the version that requires infrastructure is better for yield, resulting in balance.  Which is good.

Edited February 1, 2017 by RoverDude

[allista]

Quote

Ahh ok - what we're seeing is a lot of the MKS parts (which are large) get this so there may be more workshops than intended   My ideal would be the ability to have a specific 'Workshop' part that I can whitelist for MKS and balance against the mobile workshop that comes with GC (since all of the MKS bits are mass/volume balanced based on capabilities).  

Understood. I wonder, could it be done with MM alone? E.g. you add some magic value (like "NotWorkshop = true") directly to the PART node, and my MM patch checks for that value in the HAS block. MM should see such a value even if it's not used by the Part.Load.

FYI, workshop efficiency calculation: 

Spoiler

void compute_part_efficiency()
{
    Efficiency = 0;
    if(part.CrewCapacity == 0) return;
    var usefull_volume = (Metric.Volume(part)-part.mass)*GLB.PartVolumeFactor;
    if(usefull_volume <= 0) return;
    Efficiency = Mathf.Lerp(0, GLB.MaxGenericEfficiency, 
        Mathf.Min(usefull_volume/part.CrewCapacity/GLB.VolumePerKerbal, 1));
    if(Efficiency < GLB.MinGenericEfficiency) Efficiency = 0;
}

 

 

1 minute ago, RoverDude said:

This I really like. 

I can totally see having a specific 'disassembly' type part that if you invest in it, you get the option of better yields.  In general, stuff where the parts chosen reflect the function (i.e. a ground based assembly facility kinda looks like one) are, IMO, always good.

I was thinking that a workshop itself should be the required part; especially if we tune the above efficiency calculation to eliminate most of the would-be workshops. But it could also be a specialized part.

However, @DStaal almost convinced me that the prolonged disassembly in space (as I imagined it) is a bad idea; and that it should be left to the Hangar+KIS project.

[RoverDude]

5 minutes ago, allista said:

Understood. I wonder, could it be done with MM alone? E.g. you add some magic value (like "NotWorkshop = true") directly to the PART node, and my MM patch checks for that value in the HAS block. MM should see such a value even if it's not used by the Part.Load.

FYI, workshop efficiency calculation: 

  Reveal hidden contents

void compute_part_efficiency()
{
    Efficiency = 0;
    if(part.CrewCapacity == 0) return;
    var usefull_volume = (Metric.Volume(part)-part.mass)*GLB.PartVolumeFactor;
    if(usefull_volume <= 0) return;
    Efficiency = Mathf.Lerp(0, GLB.MaxGenericEfficiency, 
        Mathf.Min(usefull_volume/part.CrewCapacity/GLB.VolumePerKerbal, 1));
    if(Efficiency < GLB.MinGenericEfficiency) Efficiency = 0;
}

 

 

I was thinking that a workshop itself should be the required part; especially if we tune the above efficiency calculation to eliminate most of the would-be workshops. But it could also be a specialized part.

However, @DStaal almost convinced me that the prolonged disassembly in space (as I imagined it) is a bad idea; and that it should be left to the Hangar+KIS project.

Sure, a blacklist also works just as well.  Either via property or part module.

[allista]

1 minute ago, RoverDude said:

Sure, a blacklist also works just as well.  Either via property or part module.

Whitelist is too restrictive with respect to mods that provide parts that I don't know of

Would you prefer a dummy module then? Irrationally it seems to be more robust.

[RoverDude]

Whatever is easiest for you

[allista]

1 minute ago, RoverDude said:

Whatever is easiest for you

Let's say:

@PART[*]:HAS[#CrewCapacity[*],~CrewCapacity[0],!MODULE[NotGroundWorkshop],!MODULE[GroundWorkshop]]:FINAL
{
	MODULE
	{
		name = GroundWorkshop
		AutoEfficiency = True
	}
}

 

[RoverDude]

FYI - in the latest GC from SpaceDock, I am seeing every vessel with crew as a workshop - even a single Mk1 pod

It would also be fine to just use your existing module, and pick some variable (even an existing one) that would suppress it being a workshop and save you having to make a new module

[DStaal]

4 minutes ago, allista said:

Let's say:

Quote

 

@PART[*]:HAS[#CrewCapacity[*],~CrewCapacity[0],!MODULE[NotGroundWorkshop],!MODULE[GroundWorkshop]]:FINAL
{
	MODULE
	{
		name = GroundWorkshop
		AutoEfficiency = True
	}
}

 

 

If you're going that way, it would seem to be cleaner to have something like:

@PART[FOO]
{
	MODULE
	{
		name = GroundWorkshop
		Enabled = False
	}
}

as the blacklist.  That simplifies your MM patch, and means people reading .cfg files don't have to look for multiple things.  And it's only one more (static) line for the part author to copy-paste.

[allista]

6 minutes ago, RoverDude said:

FYI - in the latest GC from SpaceDock, I am seeing every vessel with crew as a workshop - even a single Mk1 pod

Heck! What a shame 

*I see it too; the Mk1 pod does not have "Construction Window", nor can it construct anything, but it is still listed in the scenario window.

Thanks!

[RoverDude]

Thanks, and yep I agree with @DStaal - keep it simple, use the same module

[allista]

1 hour ago, DStaal said:

If you're going that way, it would seem to be cleaner to have something like:

@PART[FOO]
{
	MODULE
	{
		name = GroundWorkshop
		Enabled = False
	}
}

as the blacklist.  That simplifies your MM patch, and means people reading .cfg files don't have to look for multiple things.  And it's only one more (static) line for the part author to copy-paste.

1 hour ago, RoverDude said:

It would also be fine to just use your existing module, and pick some variable (even an existing one) that would suppress it being a workshop and save you having to make a new module

1 hour ago, RoverDude said:

Thanks, and yep I agree with @DStaal - keep it simple, use the same module

Except that it would still cause the creation of the GroundWorkshop module, and will require some code tuning to honor this flag in GetInfo, OnStart and other relevant places, which is error-prone.
And it's best to use "isEnabled = False" as it is already present in any PartModule.

I mean, there's no need to actually make the "NotGroundWorkshop" module. It may be just a line in part.cfg without any class backing it up. It's enough that MM will see it and won't patch a part marked that way.

Edit: I've done both. The patch with NotGroundWorkshop works perfectly as is, without any coding from my part. But the isEnabled flag is now also honored by GroundWorkshop module. So you can use either.

Edited February 2, 2017 by allista

[allista]

@RoverDude, @DStaal, so, in the end of the day night: which path seems to be the best?

1. GC uses USITools as is, providing only UI to instantly demolish any vessel in range, converting mass to MaterialKits like the demolition charge does.
2. GC demolished vessels part-by-part over time with higher yield (dealing with catching-up, drifting and other staff):
   1. Using any qualified workshop with engineers inside.
   2. Using new dedicated part (that @RoverDude will create? Or teach me his modelling style ).

[DStaal]

I'd go with 2; let MKS provide the instant demolish if people want it.  Make 1 available via soft-dependency if you want.  Ideally with a dedicated part - but you could do efficiency like you have for construction and have the possibility of a dedicated part (or just use the same workshop) later.

[LatiMacciato]

sorry @allista wrong topic (getting tired here >.<)

Edited February 2, 2017 by LatiMacciato

[The-Doctor]

Meh, this does not look stock alike enough

[allista]

1 hour ago, The-Doctor said:

Meh, this does not look stock alike enough

Nor does it intend to 

[allista]

Question:

Does anybody use small crewable parts (like the stock Mk1 Lander Can) as actual workshops?

Currently so many parts are workshops that it clutters the UI. So I want to increase the threshold that allows a part to become a workshop.

This will disable workshop functionality in-flight in parts that are no longer qualify.