totm may 2024 [1.12.x] - Modular Kolonization System (MKS)

[DoktorKrogg]

2 hours ago, Mossconfig said:

Is there a way to scale transport credit production for RSS? I cant just change the config file.

 

1 hour ago, TheSuMa said:

No, in current release there is no way, it's hardcoded, i'll do a pull-request to implement such a setting (as soon as other pull requests i'm working on are done)

Not sure what you have in mind in terms of a setting but it's unnecessary in this instance. A ModuleManager patch for the TransportModule part to change the value of the OutputResources node in the WOLF_ConverterModule would do the trick.

[JamesonKerbal]

1 hour ago, Mossconfig said:

Yeah, but I don't want to loft 10x the material extractors. That makes for boring gameplay. I either want to lower the Tcredit cost or increase the Tcredit production per material.

Options you have to address this issue include:

• Build one 10x bigger launch vehicle
• Experiment with methods to get payload into orbit with the least consumed mass
• Use a system like kOS or KSP RPC to automate the launches (so the boring part of the gameplay is done for you)
• Source your materials for orbital industry from somewhere else beside Kerbin surface

As an example of that last step, what I have done in my own games with WOLF so far has involved building just enough infrastructure on Kerbin to get a shipyard in orbit. Then I build up just enough stuff to establish a Specialised Parts factory on Minmus. Now I can build my own DIY kits on Minmus, including all the future depots to deploy on Minmus (they will all be electric rovers).

So rather than lofting extractors into orbit from Kerbin surface to be shipped to wherever you're going, send a parts factory and build all your equipment in-situ.

I hope this inspires you to find a new solution to your specific concern.

 

[Mossconfig]

20 minutes ago, DoktorKrogg said:

you have in mind in terms of a setting but it's unnecessary in this instance. A ModuleManager patch for the TransportModule part to change the value of the OutputResources node in the WOLF_ConverterModule would do the trick.

the UmbraSpaceIndustries\WOLF\Parts\TransportModule.cfg part file is decoritive, providing information for the tooltip. The actual "10 fuel = 10 Tcredits" is hard coded in the .dll.

22 minutes ago, JamesonKerbal said:

Options you have to address this issue include:

• Build one 10x bigger launch vehicle
• Experiment with methods to get payload into orbit with the least consumed mass
• Use a system like kOS or KSP RPC to automate the launches (so the boring part of the gameplay is done for you)
• Source your materials for orbital industry from somewhere else beside Kerbin surface

As an example of that last step, what I have done in my own games with WOLF so far has involved building just enough infrastructure on Kerbin to get a shipyard in orbit. Then I build up just enough stuff to establish a Specialised Parts factory on Minmus. Now I can build my own DIY kits on Minmus, including all the future depots to deploy on Minmus (they will all be electric rovers).

So rather than lofting extractors into orbit from Kerbin surface to be shipped to wherever you're going, send a parts factory and build all your equipment in-situ.

I hope this inspires you to find a new solution to your specific concern.

Believe it or not, I did consider "moar boosters".

 

KSP is a game that doesn't like high part counts. Part count is the major indicator of performance.  Multiplying your payload count by 10  is going to have a massive effect on my system performance, that I don't want to struggle with.

 

The only difference compared to the stock wolf system is going to be my additional fuel requirements. I don't need 10x food. I don't need 10x power. I don't need 10x material kits. Just fuel. That means shipping monster shipments of hydrate harvesters around the place, monster shipments of extractors, monster shipments of refineries, and all the personnel and support they require. Simply using the stock wolf ratios and increasing the final yield of the fuel chain allows me to play without throwing all the ratios of required parts out of whack.

 

Especially because the fuel production calculations are based on the stock size, which is doubly inapplicable to me because 1) I'm using Realfuels which throws out the stock fuel system, and 2) I'm playing RSS, 10x bigger.

 

2 hours ago, RoverDude said:

Gone like keys in lava.

Umm, Can I assume that applies to incorrectly configured WOLF modules too? Lets say I send a bunch of Wolf harvesters up and I forget to change them from dirt to gypsum. if I click "add to depot"I'll end up with a useless load of extractors I can't reconfigure?

[RoverDude]

1 minute ago, Mossconfig said:

Umm, Can I assume that applies to incorrectly configured WOLF modules too? Lets say I send a bunch of Wolf harvesters up and I forget to change them from dirt to gypsum. if I click "add to depot"I'll end up with a useless load of extractors I can't reconfigure?

You'll end up with infrastructure updated based on what you fed it.  I'd suggest using the planner in the VAB, it's pretty awesome.

To the rest... you've chosen to play RSS - it's 10x larger.  It's massive.  So to have to scale out correspondingly massive fuel refineries to support correspondingly massive routes makes sense.    

[JamesonKerbal]

14 minutes ago, Mossconfig said:

I don't need 10x food. I don't need 10x power. I don't need 10x material kits. Just fuel. That means shipping monster shipments of hydrate harvesters around the place

This is one of the gameplay issues that WOLF is trying to address. Rather than shipping monster hydrate harvesters around the place, ship a base construction workshop with a few DIY kits to get a bare minimum infrastructure established, then build the hydrate harvesters locally having established the WOLF shipments of parts that are not produced locally yet.

 

[DoktorKrogg]

45 minutes ago, Mossconfig said:

the UmbraSpaceIndustries\WOLF\Parts\TransportModule.cfg part file is decoritive, providing information for the tooltip. The actual "10 fuel = 10 Tcredits" is hard coded in the .dll.

Not true. The values for InputResources and OutputResources are the actual values used by WOLF. I know this because I wrote the code for WOLF and because I also just tested it to make sure I'm not going crazy.  Making that change is not, however, retroactive. The only way to change it retroactively would be to manually edit your save file.

[Mossconfig]

8 minutes ago, DoktorKrogg said:

Making that change is not, however, retroactive. The only way to change it retroactively would be to manually edit your save file.

Yeah, I'm sorry. I tried changing that number and when I booted the game again my Tcredit production didn't change. Made a wrong assumption. Literally 5 minutes ago I dipped my novice toe into the waters of the source code and saw that it does reference the WOLF_ConverterModule once to record the value, but once only. Sorry about that.

 

Right now I was in the middle of trying to setup another transport module, but I've locked myself into a situation where I am using all my water for rocket fuel and cannot afford the extra to add the life support for another transport module and fuel refinery setup. It would be nice to have a way to remove parts from WOLF, but beggars can't be choosers. New save ahoy.

Edited January 14, 2021 by Mossconfig

[DoktorKrogg]

3 minutes ago, Mossconfig said:

It would be nice to have a way to remove parts from WOLF

It's fairly easy to hack yourself some extra resources via your save file. If you're handy with a text editor, you can make the edits manually (just do a search for "WOLF" in the save file). If you're not comfortable doing that, check out the KML mod for editing save files:

Removing parts from WOLF is non-trivial. It would mean a) keeping track of all the parts that have been added to WOLF and bloating the save file and b) possibly causing a cascade of failures if you remove a part that had outputs being consumed by other parts. That's one of the reasons we added the planner to the WOLF window. I understand where you're coming from though. We all have whoops moments and WOLF isn't very forgiving. If you have suggestions on ways to mitigate the facepalm moments, we'll certainly consider them. It's also useful for us to hear folks' impressions of how WOLF plays when coupled with other popular mods. Doesn't necessarily mean we'll do anything about it, but still helpful when it comes to future planning. 

[Mossconfig]

10 minutes ago, DoktorKrogg said:

That's one of the reasons we added the planner to the WOLF window. I understand where you're coming from though. We all have whoops moments and WOLF isn't very forgiving. If you have suggestions on ways to mitigate the facepalm moments, we'll certainly consider them. It's also useful for us to hear folks' impressions of how WOLF plays when coupled with other popular mods. Doesn't necessarily mean we'll do anything about it, but still helpful when it comes to future planning. 

Thank you! Could you tell me where the resource "WaterVein" is pulled from? Its been a flat 0 for my saves, which is putting a crimp on my plans.

[DoktorKrogg]

3 minutes ago, Mossconfig said:

Thank you! Could you tell me where the resource "WaterVein" is pulled from? Its been a flat 0 for my saves, which is putting a crimp on my plans.

The resources are based on the availability/abundance for that resource in the stock resource system. If you're playing with a mod that changes the availability and distribution of resources, then that's probably the explanation. We do "blacklist" some resources on the starting planet (ExoticMinerals & RareMetals for now) to give players a nudge off the starting planet and onto other bodies in order to do the full WOLF resource chain.

[Mossconfig]

Spoiler

This is my harvestable resources tab. As you can see, the wolf system doesn't recognize water, and the resource config for RSS copies the kerbin config exactly. IDK, I'll probably just cheat in 500 and call it a desalination plant.

[Brigadier]

1 hour ago, DoktorKrogg said:

Removing parts from WOLF is non-trivial. It would mean a) keeping track of all the parts that have been added to WOLF and bloating the save file and b) possibly causing a cascade of failures if you remove a part that had outputs being consumed by other parts. That's one of the reasons we added the planner to the WOLF window. I understand where you're coming from though. We all have whoops moments and WOLF isn't very forgiving. If you have suggestions on ways to mitigate the facepalm moments, we'll certainly consider them.

Completely understand your reasoning here.

Have you considered creating an "Infrastructure Modification" part that deducts from Available and returns it to Incoming?  It would still cost you to sink the part into the depot but the logic would be that its a cost for an infrastructure change.  It's limited in what it can do but you wouldn't need to remember previous parts sent to the depot.

It still might be a nightmare with all of the added part dependencies (life support, crewpoints, maintenance, etc.).

Just a thought.  You did ask for suggestions

[Mossconfig]

50 minutes ago, Brigadier said:

Have you considered creating an "Infrastructure Modification" part that deducts from Available and returns it to Incoming?

I think that would still run into the problem, you would need to ensure that only superfluous modules are removed. A checker would be time intensive to build.

[Brigadier]

41 minutes ago, Mossconfig said:

I think that would still run into the problem, you would need to ensure that only superfluous modules are removed. A checker would be time intensive to build.

What modules? (rhetorical question)  When you commit a module to the depot, it disappears from the game and is not tracked by the mod.  There are no superfluous modules because there are no modules, just the resources.  When you add, say, a power module to a depot, you add power output to Incoming and add its support requirements (maintenance, crewpoints, etc.) to Outgoing.  Available is simply the difference.  If I understand correctly, only the resources are tracked by the mod, post-commit.

Sure, there must be verification that what you're removing is eligible but all you're doing is deducting from Available (i.e. it's not committed to Outgoing), and returning it to Incoming.  In the Power Module case, you'd be decreasing the available power, and increasing maintenance, life support, crewpoints (whatever the module needs to 'run').  The main check is therefore against the selected module's output, e.g. does removing the output affect other module's resource input in the depot (will the removal cause a power shortage?).  The Planner sort of does this check anyway when you add a module since I don't think you can launch a vessel whose modules' cumulative effect is to have a negative anywhere on the Planner.

That said, I don't have a good understanding of the mod just yet and could be completely off-base (off-depot?? ).  I'm sure this'll generate some feedback from the dev team.

Edited January 14, 2021 by Brigadier
Clarified last sentence in the 2nd para.

[Tacombel]

First thing first, thank you all very much for all your mods. 

I have been away from MKS for some time because of the kraken, but Wolf solves that problem perfectly. That takes me to explain my use case, that differs from your vision of how to use WOLF. For me it is not and endgame feature. I am using it as soon as I stablish my first station in LKO to setup a refueling station and avoid the boring part of supplying it, so the fact that all the relevant modules are so far in the techtree is a problem. IMHO the logistical problem of setting up WOLF bases in distant planets is enough difficulty and I would like to be able to supply LKO sooner. That said, I just cheated my way to the WOLF modules, so I am not requesting anything, only explaining how I play WOLF.

The planner is great. A perfect example of how to make something complex really easy.

The part about changing recipes is a bit confusing. I was also clicking the wrong button until I remembered that the purpose of them was to avoid materials costs when changing them once installed. For newcomers, the important bit you must check is the possible recipes in the characteristics of the part. There you have what the part can produce, and what is needed, although the planner helps with that.

And then the only button that you need to press is the Chemicals=>Fuel(Ore) until Recipe is what you want.

For new comers to WOLF, you can make fuel from water. Don't go the ore way . Unless there is more.

Something that I think is really needed is to show the capacity of the transport route before establishing it. I just spent all the water in KSC in a 33 capacity route when all I wanted to take was 5 fuel to LKO.  I think that @TheSuMais already working on it. Also, Cargo Space could show the available capacity.

But I can't find the resources that are being consumed by the hopper

 

Once more, thank you very much. This is already great as it is.

 

Edited January 14, 2021 by Tacombel

[Mythos]

6 hours ago, DoktorKrogg said:

check out the KML mod for editing save files

I always support that.... I don't get any of the rest of the conversation, though. What the hell is WOLF? Is there some link to a description? Is it only hidden woven into 400 pages of MKS thread (search results say so)? That would mean I may never lern about it, because I will not go through the whole thread 

I have a rough idea what MKS is about, but never used it. Is it not continued anymore and WOLF is a successor?

[Tacombel]

@Mythosthe relevant pages start around page 393. Later I will add links to WIP docs about Wolf. 

[Jasseji]

24 minutes ago, Mythos said:

I always support that.... I don't get any of the rest of the conversation, though. What the hell is WOLF? Is there some link to a description? Is it only hidden woven into 400 pages of MKS thread (search results say so)? That would mean I may never lern about it, because I will not go through the whole thread 

I have a rough idea what MKS is about, but never used it. Is it not continued anymore and WOLF is a successor?

MKS Wiki has some WIP articles

[RoverDude]

5 hours ago, Brigadier said:

Have you considered creating an "Infrastructure Modification" part that deducts from Available and returns it to Incoming?  It would still cost you to sink the part into the depot but the logic would be that its a cost for an infrastructure change.  It's limited in what it can do but you wouldn't need to remember previous parts sent to the depot.

The reverse chain calculations would be brutal, or you'd end up wasting something else (like maintenance, life support, etc.) and tracking the chains goes against what WOLF is solving.   The Planner is there to assist with that, and if you want a more forgiving save, crank up the resource abundance in stock since WOLF derives off of that.

21 minutes ago, Mythos said:

I always support that.... I don't get any of the rest of the conversation, though. What the hell is WOLF? Is there some link to a description? Is it only hidden woven into 400 pages of MKS thread (search results say so)? That would mean I may never lern about it, because I will not go through the whole thread 

I have a rough idea what MKS is about, but never used it. Is it not continued anymore and WOLF is a successor?

Subsystem of MKS.  Best bet is to also look on the WIKI as there are updates going on there as well.   

[TheSuMa]

 

7 hours ago, DoktorKrogg said:

Not sure what you have in mind in terms of a setting but it's unnecessary in this instance. A ModuleManager patch for the TransportModule part to change the value of the OutputResources node in the WOLF_ConverterModule would do the trick.

  Sure, just turn the problem around and produce more Credits instead of reducing the need, stupid simple, probably it was just too late to think of it that way, sorry 

I had nothing special in mind, just wanted to help, do not need it myself. The only reason i said it's hardcoded was the readonly double ROUTE_COST_MULTIPLIER in the TransporterModule. It looks like it should be configurable, but i agree, no need for it 

4 minutes ago, Tacombel said:

Something that I think is really needed is to show the capacity of the transport route before establishing it. I just spent all the water in KSC in a 33 capacity route when all I wanted to take was 5 fuel to LKO.  I think that @TheSuMais already working on it

PR is done and @RoverDude already merged it to DEVELOPMENT branch, it will be available in next release, you will get a "Route Payload" and a "Cost / Payload"  Because current implementation is based on vessel mass you're still not able to know the amount before you have flown the route as it is not a static value, once cargo-space is implemented this changes and the payload can already be shown in VAB/SPH. However, you will at least be able to see it before connecting to destination depot in next release 

 

 

[Tacombel]

2 hours ago, Tacombel said:

@Mythosthe relevant pages start around page 393. Later I will add links to WIP docs about Wolf. 

@Mythos

WIP documentation

Wiki

Transport credits and routes

[Cruesoe]

1 hour ago, Tacombel said:

@Mythos

WIP documentation

Wiki

Transport credits and routes

Very useful stuff, can't wait to get far enough in this career to give it all a go!

[Terwin]

14 minutes ago, Cruesoe said:

Very useful stuff, can't wait to get far enough in this career to give it all a go!

It seems you can do a lot with just ISRU and the transport computer.

Last night I used a SSTO to create a free 140 cargo KSC->orbit when I docked it to my fuel station(turns out I did not even need to transfer the fuel and undock to complete the trip, which was nice but potentially exploitable for multi-stage vessels).

Between my Kerbin and Mun orbital fuel stations and an ISRU vessel, I could probably set up a zero-cost round-trip to Mun now that I have the most expensive leg handled. 

[TheSuMa]

48 minutes ago, Terwin said:

turns out I did not even need to transfer the fuel and undock to complete the trip, which was nice but potentially exploitable for multi-stage vessels

It is a huge exploit even for SSTO. While docked your fuel station mass gets also counted as your vessels mass. This will not only reduce the cost (until zero) of the route but also increase the payload.

There is a PR around the corner to fix all of the exploits i'm aware of currently, just need to test it and currently my game time is a bit limited due to RL work  Once it's done we'll need to see if the devs like it or think it's overcomplicating stuff. If it should be too much i'll do a second PR that fixes only the docking and partially the refueling exploit, this could be done with 4 simple lines of code 

[Terwin]

1 hour ago, TheSuMa said:

It is a huge exploit even for SSTO. While docked your fuel station mass gets also counted as your vessels mass. This will not only reduce the cost (until zero) of the route but also increase the payload.

There is a PR around the corner to fix all of the exploits i'm aware of currently, just need to test it and currently my game time is a bit limited due to RL work  Once it's done we'll need to see if the devs like it or think it's overcomplicating stuff. If it should be too much i'll do a second PR that fixes only the docking and partially the refueling exploit, this could be done with 4 simple lines of code 

I was under the impression that

1) RD would shortly implement containers to be used for generating transport routes (at least partially, if not fully, closing the 'bump in size' exploit of this, something I had not noticed as I had electric rovers establishing routes on kerbin that were much larger than this route, but with rovers that are smaller than my fuel station, if possibly heavier)

2) If you have the infrastructure in-place to refuel your single stage vessel, then reducing/eliminating route costs is reasonable and appropriate.