-
Notifications
You must be signed in to change notification settings - Fork 154
Supporting MKS in your mod
NOTE THIS PAGE MAY BE OUT OF DATE - INFO STILL FROM 0.40.4 - (KSP 1.1.3)
https://www.youtube.com/watch?v=a0oqO3xbswk
One of the main mechanics that USI-Colonization adds is it’s variety of disconnected distribution methods. You’ll likely want to enable some or all of them in your parts if you want to fully support integration.
The simplest is to be a logistics consumer - this can be applied to any part that uses resources (or if USI-LS is installed then any part that has seating so the Kerbals can pull supplies) to allow the part to pull resources to it using any of the logistics methods.
RoverDude now adds it to any part with seats or command, and it works on a per-vessel basis, so it can typically be ignored. It would only be needed for parts that are intended to be stand-alone and unmanned. (Like the light globe in UKS.)
Example:
MODULE
{
name = ModuleLogisticsConsumer
}
UKS allows short-rage (up to physics distance) wireless power transfer between ships. Should either be a central command part, or a dedicated power generation/transfer part.
Example:
MODULE
{
name = ModulePowerCoupler
}
UKS has three forms of warehouses - local warehouses, distributed warehouses, and planetary warehouses. Conceptually they do the same thing, just on different scales: They balance their resources among themselves, and allow resources to be pulled from them.
Not all storage should be a warehouse - it’s really supposed to be base storage, not ship storage.
Regular warehouses work within 150 meters, or can be pulled from using a rover. In general, any part that intends to be a warehouse of any type should also be a regular warehouse, as well as parts designed for base building that aren’t dedicated storage.
Example:
MODULE
{
name = USI_ModuleResourceWarehouse
}
Distributed warehouses share within the local area - up to physics range, of 2km. No other parts or ships are needed to enable sharing within that, but they can only share with other local warehouses or consumers. These should be medium sized dedicated storage parts.
Example:
MODULE
{
name = ModuleDistributedWarehouse
}
Planetary warehouse parts can push or pull to planet-wide storage - when enabled they will try to keep themselves half full, either pushing to planet-wide storage or pulling from it. These should be the largest warehouse parts only.
MODULE
{
name = ModulePlanetaryLogistics
}
UKS allows Kerbals to recycle parts into their components - distributing their resources (and the materials that made up the part) into nearby containers. Add USI_ModuleRecycleBin to allow Kerbals to put stuff into storage when recycling.
Example
MODULE
{
name = USI_ModuleRecycleBin
}
Rovers (manned with a pilot) allow consumers to pull from a larger range - up to the physics limit. To allow a rover to work as logistics rover, the command cab should have resource distributor.
Note that while this is labeled 'Rovers', and was originally rolled out with a rover part, it need not be limited to rovers. (UKS applies it to the Pioneer Module for instance - the central hub of a colony.)
Example:
MODULE
{
name = ModuleResourceDistributor
}
Orbital logistics is currently being reworked - as of 0.04.3 it is non-functional, but may return in the previous form until it gets reworked into a new form. This documentation covers the previous form, without going into detail.
Orbital Logistics operates differently from the other logistics options - it’s contained entirely within one part, which offers the player a GUI to set up and start transfers between any two ships within a SOI - landed or orbiting. (Highly elliptical or parabolic/hyperbolic orbits will cause the transfer to fail.)
Example:
MODULE
{
name = MKSLcentral
ManagedResources = Machinery,Chemicals,ExoticMinerals,Karbonite,LiquidFuel,MetallicOre,Metals,Minerals,MonoPropellant,Ore,Oxidizer,Polymers,RareMetals,Recyclables,Substrate,Water
//Delivery time variables
//preperation time in seconds, a base time for each transfer
PrepTime = 3600
//for surface to surface transfers: the seconds per meter a transfer takes
TimePerDistance = 0.0001
//for orbit to surface and surface to orbit: the seconds a transfer takes
TimeToFromLO = 21600
//Cost variables
//surface to surface
DistanceModifier = 0.00015
//surface to orbit
SurfaceOrbitModifier = 0.00075
//orbit to surface
OrbitSurfaceModifier = 0.00075
//additional multiplier for takeoff in atmospehere
AtmosphereUpModifier = 1.10
//additional multiplier for descent in atmospehere
AtmosphereDownModifier = 0.75
Mix1CostName = LFO
Mix1CostResources = Oxidizer:1.1, LiquidFuel:.9
Mix2CostName = Karbonite
Mix2CostResources = Karbonite:2
transferTime = 300
maxTransferMass = 1000000
}
Kolonization bonuses are benefits Kerbals get for having a colonization presence on or near a body for period of time. It’s enabled by having them in a part with the FIXME module. Note that not all crewable parts should have this module - just those intended for long-term presence on the planet/moon in question.
Example (from the OKS Workshop):
MODULE
{
name = MKSModule
workSpace = 4
livingSpace = 0
hasGenerators = false
}
USI-LS is a separate mod, but it often gets considered with USI Colonization. It adds three main mechanics to the game besides food production and consumption: Habitation, Recycling, and Wear.
USI-LS calculates default habitation based on seating capacity, and for many cases that’s enough. Further support should really only be for dedicated habitation parts.
Habitation can be affected in two ways:
- Habitation parts can add time directly.
- Recreation parts can add multipliers.
Examples of recreation parts include things like cupolas and food preparation areas, while actual living quarters should typically add time directly.
RoverDude’s guidance on habitation time:
For dedicated hab parts (no other generators, etc.):
Kerbal Months should equal mass * 5
ReplacementParts = 100 * crew capacity + 100 * Kerbal Months.
Example (from the stock crewCabin):
MODULE
{
name = ModuleHabitation
KerbalMonths = 12.5
}
RoverDude’s guidance on habitation multipliers:
For parts that act as hab multipliers (dedicated or bundled with other functions/converters), a multiplier equal to the tonnage works well.
Example (From the stock cupola):
MODULE
{
name = ModuleHabitation
KerbalMonths = 0
HabMultiplier = 1.76
}
Recycling is a bit more complex of a mechanic. It represents what percentage of your supplies a Kerbal can reuse - it can be something as simple as a CO2 scrubber, or it can be something as complex as an areoponics greenhouse support system. (Note that the latter may also be able to generate supplies, as well as just recycle them.) It’s important to keep in mind that supplies is more than just food: it includes air, water, food, and other disposables. (Clothing, wrappers, etc. Anything a Kerbal uses in day-to-day life in space.)
Recyclers have two things to worry about: Their percentage, and their crew capacity. Crew capacity is different then seating capacity; it is the number of crew that this part can recycle (at 100% of rated recycle rate) for. That may be higher or lower than the seating capacity. The percentage is the amount they reduce the life support load by (for that crew capacity).
Resist the temptation to make all recyclers high-percentage. A CO2 scrubbing part can be useful, and be a part of good gameplay.
RoverDude’s guidance on recyclers:
For recyclers, their percentage should be mass / crew capcity (i.e. the UKS Pioneer Module at 3.75t = 75%) at crew capacity 5. Increasing crew cap should result in an increase in mass. i.e. a 12-crew recycler that weighs 7.5 tons should have a recycler percentage equal to 7.5 / 12 = 62.5%
Recyclers require (per crew capacity) 0.2 EC and 0.000002 ReplacementParts with a cap of 75%.
If water is used as an input (0.0002 per crew capacity) the cap can be extended to 90%
Example (From Stock Science Lab):
MODULE
{
name = ModuleLifeSupport
}
RESOURCE
{
name = ReplacementParts
amount = 200
maxAmount = 200
}
MODULE
{
name = ModuleLifeSupportRecycler
CrewCapacity = 5
RecyclePercent = .7
ConverterName = Life Support
tag = Life Support
StartActionName = Start Life Support
StopActionName = Stop Life Support
INPUT_RESOURCE
{
ResourceName = ElectricCharge
Ratio = 1
}
}
Wear as a mechanic can largely be ignored by part makers - Roverdude includes a MM file that adds the required modules and resources to anything with seats. The basic idea is that parts wear out over time (losing effectiveness), and need to be repaired. If you want to add this yourself, you need to add the USI_ModuleFieldRepair module, the ModuleLifeSupport module (if the part has seats of some kind), and storage for the invisible resource ReplacementParts. Usually that’s 100 per seat, or 500 per command chair.
Note that repairs only occur in the presence of a Kerbal Engineer.
Example (From Stock Cupola):
MODULE
{
name = ModuleLifeSupport
}
RESOURCE
{
name = ReplacementParts
amount = 100
maxAmount = 100
}
MODULE
{
name = USI_ModuleFieldRepair
}
Repairs can either be done by an Engineer on EVA, or automatically by an Engineer in a workshop. These workshops are usually compatible with Extraplanetary Launchpads or OSE Workshops.
Example:
MODULE
{
name = ModuleAutoRepairer
}