kOS partmodule parameters balancing - a documented list of what RP-0 can configure

[Dunbaratu]

(Speaking as one of the kOS devs)

All kOSProcessor PartModules have some config options that can be set in the Part.cfg file (or ModuleManager config).

One of them is the disk space. But in RO/RP-0 the disk space is always set to the minimum value (5000) regardless of where you are in the tech tree. Since RP-0 does not 'cost' the parts provided by the kOS mod (i.e. it bans the kOS parts if you have NoNonRP0 present) this ends up making the kOSProcessor PartModules inserted by RO and RP-0 be the only ones the player has access to, and they're all stuck at the minimum small disk space tech level that we only intended to be that way early in the tech tree.

Here's a complete list of the KSPFields we intended to be configurable via a Part.cfg file or a modulemanager patch for kOS, with their meanings below:

MODULE
{
    name = kOSProcessor

    diskSpace = [integer, defaults to 1024 although the min we ever really use is 5000]
    baseModuleCost = [float, defaults to 0.0]
    baseModuleMass = [float, defaults to 0.0]
    diskSpaceCostFactor = [float, defaults to 0.0244140625 (100Funds per 4096 bytes)]
    diskSpaceMassFactor = [float, defaults to 0.0000000048829 (0.02kg per 4096 bytes)]
    ECPerInstruction = [float, defaults to 0.000004]
    ECPerBytePerSecond = [float, defaults to 0.0]
}

Meanings:

• diskSpace = number of bytes of script code the local volume on the part can hold at minimum. Note that all kOS processors can be tweaked in the VAB/SPH for double or quadruple their default disk capacity, costing more Funds and mass to do so. The user can choose one of 3 options only, via a slider widget: 1x diskSpace, 2x diskSpace, or 4x diskSpace (can't go higher than 4x). So in other words, if diskSpace is set to 10000, that really means the user can choose either 10000, 20000, or 40000, but no higher.
• baseModuleCost = If you want to make it cost some overhead flat amount to insert a kOSProcessor into a part than the part would normally cost without the kOSProcessor, you can put that amount here. We always set it to zero because in stock kOS, the kOSProcessor is always inside a kOS part that has the cost we already wanted. This setting is for cases where someone other than the kOS developers is inserting the kOSModule into some other part (i.e. exactly the sort of thing RP-0 or RO would be doing.)
• baseModuleMass = This is just like baseModuleCost, except for mass instead of Funds. It's in megagrams like all the other mass measures in the game.
• diskSpaceCostFactor = How much Funds per byte does it cost when the user chooses to increase the size of diskSpace to 2x or 4x using the slider described above under diskSpace. (so, for example, if the part has diskSpace at 10000, but the user selected the 4x disk size option so the disk space is going to be 40000 instead, this cost is applied to those additional 30000 bytes beyond the base amount.)
• diskSpaceMassFactor = Just like diskSpaceCostFactor, but for mass. It's in megagrams, like all the other mass measures in the game.
• ECPerInstruction = How much ElectricCharge does it take to actually run a program in the computer? This number is a micropayment of electricity per pseudo-opcode the virtual computer executes. Thus your program eats very little power if all it's doing is something like until timeToWakeUp {print "waiting..". wait 1.} This is how we simulate the notion that power drain varies by CPU utilization and you can reduce power load by having your program yield frequently. In stock kOS, this is a fixed number and all parts have the same setting, but we made it configurable for future expansion. So you can change it for RP-0 to represent tech tree progression if you like. Bulky, older computers would have a higher ECPerInstruction than newer more compact ones.
• ECPerBytePerSecond = If you want disk space to cost power per second that it is present, you can set this to something other than zero. We default it to zero in stock kOS. It would represent the idea that your "disk" storage isn't so much a permanent secondary storage, but rather more like a ramdisk that has to be "kept alive" by a constant flow of current every moment for the entire vehicle's lifetime. I'm not sure how realistic this is. We have the code in place to respond to this setting if you want to use it, but I think you'd probably want to keep it at zero.

If you want to get a rough idea of how these numbers work in stock kOS, look at the Part.cfg files under GameData/kOS/Part. At the moment we really only change the diskSpace setting. The other settings are left at the default and we do obey them, but we haven't decided on what would be a good balance in the stock game to make them all vary. Regardless, whatever balance we pick for stock, you'd want to do something different in RP-0 anyway so I'm telling you what all the settings do so you can make your own decisions.

[Dunbaratu]

I should point out that the IPU setting in kOS (Instructions Per Update) is currently a global config the player chooses and isn't encoded into the parts or the partmodule (they choose it on the kOS settings of KSP's "difficulty" settings screen). It represents the computer's speed. A value like 200 makes the kOS computer a very slow and clunky model. The fastest we allow is only 2000, for game lag reasons (We could safely allow it to go higher if we could guarantee the user avoids certain high-level complicated instructions, but we can't.)

There are plenty of pie-in-the-sky plans to make individual kOS parts have differing IPU's from each other, but right now that's not a thing. The setting is global across the whole game.

That means the best you can do for simulating "older" slow computers versus "newer" fast computers is to make it more of a power drain to set the IPU high while using lower-tech parts than using higher-tech parts (via ECPerInstruction). Then the user would have a dis-incentive to set IPU high until later in the tech tree.

[Dunbaratu]

@pap1723 - here's some initial ideas for scaling, if you keep using the idea of adding kOS to the avionics cores: Each section represents a different era of history, with me giving dates to sort of give a rough idea. The thing I'm the least certain about is the electric drain, as I am working mostly off of memory of how RO scaled batteries. But I think it would be really useful to scale electric charge with tech so that people have an incentive to use slower settings early on.

1955: really cruddy big vacuum tube circuits diskSpace = 3000 baseModuleCost = 0 (it's in the avionics core) baseModuleMass = 0 (it's in the avionics core) diskSpaceCostFactor = 1 (1 Fund per byte) diskSpaceMassFactor = 0.000001 (1kg per 1 KB) ECPerInstruction = 0.001 (so that's about 0.2 kW to run 200 IPUs, which is a lot, but real world computers were worse. I toned it down a bit because I don't know how much draw the avionics itself already does.) ECPerBytePerSecond = 0 (I'm going to keep this zero always, I think)

1965: IBM System/360 and the like - that era: Also the Apollo GC was sort of one of these: diskSpace = 8000 baseModuleCost = 0 (it's in the avionics core) baseModuleMass = 0 (it's in the avionics core) diskSpaceCostFactor = 0.1 (1 Fund per 10 bytes) diskSpaceMassFactor = 0.000001 (1kg per 1 KB) ECPerInstruction = 0.0005 (so that's about 0.1 kW to run 200 IPUs) ECPerBytePerSecond = 0 (I'm going to keep this zero always, I think)

1975: diskSpace = 20000 baseModuleCost = 0 (it's in the avionics core) baseModuleMass = 0 (it's in the avionics core) diskSpaceCostFactor = 0.01 (1 Fund per 100 bytes) diskSpaceMassFactor = 0.0000005 (1kg per 2 KB) ECPerInstruction = 0.0001 (so that's about 0.02 kW to run 200 IPUs) ECPerBytePerSecond = 0 (I'm going to keep this zero always, I think)

1980: diskSpace = 40000 baseModuleCost = 0 (it's in the avionics core) baseModuleMass = 0 (it's in the avionics core) diskSpaceCostFactor = 0.01 (1 Fund per 100 bytes) diskSpaceMassFactor = 0.0000001 (1kg per 10 KB) (pretty negligable now) ECPerInstruction = 0.0005 (so that's about 0.01 kW to run 200 IPUs) ECPerBytePerSecond = 0 (I'm going to keep this zero always, I think)

1990: diskSpace = 100000 baseModuleCost = 0 (it's in the avionics core) baseModuleMass = 0 (it's in the avionics core) diskSpaceCostFactor = 0.001 (1 Fund per 1000 bytes) diskSpaceMassFactor = 0.00000005 (1kg per 20 KB) ECPerInstruction = 0.00001 (about 0.01 kW to run 1000 IPUs) ECPerBytePerSecond = 0 (I'm going to keep this zero always, I think)

1995 and up: diskSpace = 200000 baseModuleCost = 0 (it's in the avionics core) baseModuleMass = 0 (it's in the avionics core) diskSpaceCostFactor = 0.0001 (1 Fund per 10000 bytes) diskSpaceMassFactor = 0 (start calling disk mass negligible at this point) ECPerInstruction = 0.000001 (about 0.001 kW to run 1000 IPUs) ECPerBytePerSecond = 0 (I'm going to keep this zero always, I think)