Fraz86

@ShotgunNinja Personally, I would consider EC/mass to take priority over EC/area, as mass is much more important for gameplay/balance (surface area is largely cosmetic in most situations). That said, it would of course be ideal for both mass and area to be well balanced; I have no objection to tweaking their masses.

@ShotgunNinja I've drafted some possible EC output numbers for NearFutureSolar that would align with your latest plans for the stock panels: Part name EC Mass EC/mass Type solarpanel-static-truss-1 3.2 0.1 32 Solar (static) solarpanel-static-truss-2 1.6 0.05 32 Solar (static) solarpanel-deploying-1x3-1 1.4 0.0541 25.8780037 Solar (nonretractable, concentrating, fragile) solarpanel-deploying-1x4-1 1.75 0.1 17.5 Solar (retractable, concentrating) solarpanel-deploying-1x4-2 2.25 0.095 23.68421053 Solar (nonretractable, concentrating) solarpanel-deploying-1x5-1 4.2 0.1475 28.47457627 Solar (nonretractable) solarpanel-deploying-1x5-2 6.5 0.22 29.54545455 Solar (nonretractable) solarpanel-deploying-2x1-1 17 0.55 30.90909091 Solar (nonretractable) solarpanel-deploying-2x1-2 8 0.375 21.33333333 Solar (retractable) solarpanel-deploying-2x3-1 26 1.2 21.66666667 Solar (retractable) solarpanel-deploying-circular-1 2 0.0941 21.25398512 Solar (retractable) solarpanel-curved-deploying-25-1 6.5 0.33 19.6969697 Solar (retractable, curved) solarpanel-curved-375-1 3 0.0925 32.43243243 Solar (static, curved) solarpanel-curved-25-1 10 0.3 33.33333333 Solar (static, curved)

I can live with that. Everything lines up logically except the OX-STAT, and as you said, it can just be thought of as an early game part, obsoleted once other panels are unlocked. Maybe add some flavor text to the OX-STAT description to make it clear that it sucks? By the way, did you know you can addend descriptions like so: @description ^= :$: Text here will be added to the end of the part description.:

@ShotgunNinja Hmm, well, I'm not sure I follow your logic on those numbers. That results in an EC/mass hierarchy with Tracking (redeployable) > Tracking (nonredeployable) > Static, which is opposite from what I find intuitive. One would imagine that static panels would be the most mass efficient (as they do not require extra mass for deployment/tracking mechanisms), and redeployable panels would be the least mass efficient.

@ShotgunNinja I like that you standardized solar panel EC output by surface area (0.08 EC per panel), however, there are now inconsistencies in EC per mass: Part EC Mass EC/mass OX-STAT 0.08 0.005 16 OX-STAT-XL 0.64 0.02 32 OX-4W 0.48 0.0175 27.42857143 OX-4L 0.48 0.0175 27.42857143 SP-W 0.48 0.025 19.2 SP-L 0.48 0.025 19.2 Gigantor 4 0.3 13.33333333 As you can see, EC/mass for OX-STAT and Gigantor aren't where they ought to be relative to the other panels. Gigantor is an easy fix (an EC output of 6 would be fine), but the OX-STAT is a bit more tricky. Doubling its EC output would break EC/area consistency with other panels, while halving its mass would make it the only object with a mass <0.005 in the entire game. I suppose that leaves the option of doubling the mass of all panels except the OX-STAT (you could also double all EC outputs if you want to keep the EC/mass in the 19-32 range)? So, something like this: Part EC Mass EC/mass OX-STAT 0.16 0.005 32 OX-STAT-XL 1.28 0.04 32 OX-4W 0.96 0.035 27.42857143 OX-4L 0.96 0.035 27.42857143 SP-W 0.96 0.05 19.2 SP-L 0.96 0.05 19.2 Gigantor 12 0.6 20

@ShotgunNinja Did you decide to move forward with your idea of quadrupling your EC production/consumption/storage numbers? That would certainly improve out-of-the-box compatibility with various mods, since you could generally assume that most EC-producing/consuming mod parts don't need modification, and the few that do (e.g., solar panels and batteries) could potentially be accounted for with catch-all patches.

@ShotgunNinja I'm glad to hear you're opting for full compatibility with CRP. I think it will avoid headaches down the road. If you find yourself dissatisfied with the existing CRP definitions, it's also an option to just switch to unused resource names (e.g., Rations, Provisions, OxygenGas, etc.).

I wouldn't say anything really "goes nuts" - it would just mean that whichever patch's parent directory comes later in the alphabet would take precedence. That said, I agree that it's generally bad practice to use :FINAL, because it doesn't leave room for others to overwrite your values (without resorting to the use of a "zzz_name" directory). Regardless, I did a bit more experimenting, and in this case it's actually entirely unnecessary for Kerbalism's resource modifications to come after CRP (or any other resource-defining mod), so I would recommend the use of a simple ":FOR[Kerbalism]" instead: // ============================================================================ // Define resources // ============================================================================ RESOURCE_DEFINITION { name = Food density = 0.05 unitCost = 66.0 flowMode = ALL_VESSEL transfer = PUMP isTweakable = true } @RESOURCE_DEFINITION[Food]:FOR[Kerbalism] { @density = 0.05 @unitCost = 66.0 @flowMode = ALL_VESSEL @transfer = PUMP @isTweakable = true } RESOURCE_DEFINITION { name = Oxygen density = 0.01 unitCost = 0.0 flowMode = ALL_VESSEL transfer = PUMP isTweakable = true } @RESOURCE_DEFINITION[Oxygen]:FOR[Kerbalism] { @density = 0.01 @unitCost = 0.0 @flowMode = ALL_VESSEL @transfer = PUMP @isTweakable = true } RESOURCE_DEFINITION { name = Waste density = 0.0 unitCost = 0.0 flowMode = ALL_VESSEL transfer = NONE isTweakable = false isVisible = false } @RESOURCE_DEFINITION[Waste]:FOR[Kerbalism] { @density = 0.0 @unitCost = 0.0 @flowMode = ALL_VESSEL @transfer = NONE @isTweakable = false @isVisible = false } RESOURCE_DEFINITION { name = CO2 density = 0.0 unitCost = 0.0 flowMode = ALL_VESSEL transfer = NONE isTweakable = false isVisible = false } @RESOURCE_DEFINITION[CO2]:FOR[Kerbalism] { @density = 0.0 @unitCost = 0.0 @flowMode = ALL_VESSEL @transfer = NONE @isTweakable = false @isVisible = false }

@ShotgunNinja You will need to redundantly define and modify each resource (%RESOURCE_DEFINITION[name] doesn't work), but this appears to function as intended: // ============================================================================ // Define resources // ============================================================================ RESOURCE_DEFINITION { name = Food density = 0.05 unitCost = 66.0 flowMode = ALL_VESSEL transfer = PUMP isTweakable = true } @RESOURCE_DEFINITION[Food]:FOR[Kerbalism] { @density = 0.05 @unitCost = 66.0 @flowMode = ALL_VESSEL @transfer = PUMP @isTweakable = true } RESOURCE_DEFINITION { name = Oxygen density = 0.01 unitCost = 0.0 flowMode = ALL_VESSEL transfer = PUMP isTweakable = true } @RESOURCE_DEFINITION[Oxygen]:FOR[Kerbalism] { @density = 0.01 @unitCost = 0.0 @flowMode = ALL_VESSEL @transfer = PUMP @isTweakable = true } RESOURCE_DEFINITION { name = Waste density = 0.0 unitCost = 0.0 flowMode = ALL_VESSEL transfer = NONE isTweakable = false isVisible = false } @RESOURCE_DEFINITION[Waste]:FOR[Kerbalism] { @density = 0.0 @unitCost = 0.0 @flowMode = ALL_VESSEL @transfer = NONE @isTweakable = false @isVisible = false } RESOURCE_DEFINITION { name = CO2 density = 0.0 unitCost = 0.0 flowMode = ALL_VESSEL transfer = NONE isTweakable = false isVisible = false } @RESOURCE_DEFINITION[CO2]:FOR[Kerbalism] { @density = 0.0 @unitCost = 0.0 @flowMode = ALL_VESSEL @transfer = NONE @isTweakable = false @isVisible = false }

I successfully wrote a patch to modify CRP resources back in 1.05, so unless something's changed with 1.1, it is possible. I'll post an example once I get home from work.

A couple points: It's possible to overwrite/modify CRP's resource definitions using ModuleManager, despite the fact that CRP is loaded first. I'd be happy to write a patch that does so, if you'd like. Count me as another player encouraging you not to worry about breaking savegames at this point. No one should reasonably expect such an ambitious mod to maintain perfect savegame stability this early after initial release (especially considering that many players are probably playing with the wrong resource definitions anyway, due to CRP loading first). If it's really important to someone, they can edit the save file. Just do whatever you think is best for your mod.

@ShotgunNinja I'd like to hear more about your plans for Kerbalism's default behavior when installed alongside CRP. If the default profile will use non-CRP resource definitions, why not have it overwrite the CRP resources? This would allow a default Kerbalism install to function correctly alongside CRP, and it would only cause problems if a player is using other mods that rely on the CRP definitions of Food and Oxygen. In my view, this conflict is relatively unconcerning, because anyone trying to use Kerbalism in combination with other mods that involve food and oxygen is almost certainly going to need a custom profile/compatibility patch anyway. Meanwhile, players who have CRP installed for other reasons (e.g., fuels) could just stick with the default profile.

@Terensky My mistake. I assumed CryoTanks used FOR[CryoTanks], and I didn't have a chance to test it because CryoEngines wasn't updated to 1.0 yet. I would recommend simply changing CryoTanks to zzz_CryoTanks in my patch (no need to use FINAL or create additional FOR passes e.g. zzzzz_Kerbalism): // Power requirements for ZBO (zero boil off) tanks cut to 25% @PART[*]:HAS[@MODULE[ModuleCryoTank]]:AFTER[zzz_CryoTanks]:NEEDS[zzz_CryoTanks] { @MODULE[ModuleCryoTank] { @CoolingCost *= 0.25 } }

@ShotgunNinja The NFPropulsion patch needs to include the stock ionEngine (i.e., @PART[ionEngine, ionArgon-*,ionXenon-*,mpdt-*,pit-*,vasimr-*]). I imagine you removed it because you figured it's already covered by the EnergyTweaks config. The problem is, NearFuturePropulsion overwrites the properties of the ionEngine, which happens after EnergyTweaks. Incidentally, the adjustments made by NFP approximately double its EC consumption, so the subsequent cut to 25% by the NFP patch will end up in about the same place as your original 50% cut to the stock properties.

@ShotgunNinja One more NearFuture compatibility issue: Kerbalism does not recognize NFE's FissionGenerator or ModuleRadioisotopeGenerator as sources of electrical power. As such, when simulated in the background, any craft dependent on either of these modules will run out of power and the crew will die. ModuleRadioisotopeGenerator is hopefully an easy fix, as it's just a custom RTG module whose power output decays gradually over the course of years. FissionGenerator might be more difficult, as it relies on interaction with another custom module (FissionReactor) and complex heat mechanics.

@ShotgunNinja If you would like to cut the capacity of NFElectrical capacitors in half, as mentioned in my last post, the amended patch would look like this: // ============================================================================ // Tweak everything from NearFutureElectrical // courtesy of Fraz86 // ============================================================================ // Fission reactors cut to 25% power generation @PART[*]:HAS[@MODULE[FissionGenerator]]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @MODULE[FissionGenerator] { @PowerGeneration *= 0.25 } } // Nuclear waste recyclers cut to 25% power requirements @PART[nuclear-recycler-*]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @MODULE[ModuleResourceConverter],0 { @INPUT_RESOURCE[#ResourceName[ElectricCharge]] { @rate *= 0.25 } } @MODULE[ModuleResourceConverter],1 { @INPUT_RESOURCE[#ResourceName[ElectricCharge]] { @rate *= 0.25 } } @MODULE[ModuleResourceConverter],2 { @INPUT_RESOURCE[#ResourceName[ElectricCharge]] { @rate *= 0.25 } } } // RTG output tweak applied to Nertea's custom decay module @PART[rtg]:HAS[@MODULE[ModuleRadioisotopeGenerator]]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @MODULE[ModuleRadioisotopeGenerator] { @BasePower = 0.32 } } // Tweaks for Nertea's larger RTG, placing its EC/mass ratio above the stock RTG but below solar panels, with a corresponding cost adjustment @PART[rtg-0625]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @cost = 69900 //3x PB-NUK @MODULE[ModuleGenerator] { @OUTPUT_RESOURCE[ElectricCharge] { @rate = 0.8 //2.5x PB-NUK } } @MODULE[ModuleRadioisotopeGenerator] { @BasePower = 0.8 //2.5x PB-NUK } } // Capacitor charge/discharge rates cut to 25%, and capacity cut to 50% @PART[*]:HAS[@MODULE[DischargeCapacitor]]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @MODULE[DischargeCapacitor] { @ChargeRate *= 0.25 @DischargeRate *= 0.25 @MaximumCharge *= 0.5 } @RESOURCE[StoredCharge] { @amount *= 0.5 @maxAmount *= 0.5 } }

@ShotgunNinja Regarding NearFuture compatibility: The NFSolar patch strikes me as excessively harsh. Stock static panels were cut to ~23% output and stock deployable panels to ~10%, but the NF panels were cut to 5% (non-curved) and 2.5% (curved). As a result, the NF panels have terrible EC/mass ratios - significantly worse than any stock panel despite being much larger and more advanced. I think the capacitors from NFE might need some further changes. In the patch, I only cut their charge and discharge rates, leaving capacity unmodified, because I regarded capacitor capacity as analogous to battery capacity. However, upon further consideration, perhaps capacitors' 800% capacity/mass (relative to batteries) is too great an advantage considering the increased importance of EC storage. Maybe the capacity should be cut in half? I have a few additional patches to share... NFSpacecraft // The Mk3-9 pod was intended to have advanced technology that allows it to continue operating even when there isn't a Kerbal at the helm. The game doesn't allow a part to actually function as both a manned command pod and a drone, so technically it was just a drone (it could not be piloted by a Kerbal). With Kerbalism's signal requirement for drones, this becomes a disadvantage rather than an advantage. Thus, this feature is replaced with conventional crew command, and SAS is converted to standalone. @PART[mk3-9pod]:AFTER[NearFutureSpacecraft]:NEEDS[NearFutureSpacecraft] { @description = This newer command cockpit is optimized for orbital operations - it sacrifices some durability for lower mass. Advanced computer-assisted flight control allows even an untrained pilot to operate the pod with ease. @MODULE[ModuleCommand] { @minimumCrew = 1 !RESOURCE[ElectricCharge] {} } @MODULE[ModuleSAS] { standalone = True RESOURCE { name = ElectricCharge rate = 0.03 } } } // Though the Itinerant resembles a half-capacity Hitchhiker, it feels too cramped and utilitarian to have an Entertainment value. Instead, it seems appropriate for it to have a CO2 scrubber. Also, the power output of its built-in RTG is cut proportionally to the stock RTG. @PART[utilityCabin]:AFTER[NearFutureSpacecraft]:NEEDS[NearFutureSpacecraft] { RESOURCE { name = CO2 amount = 0.0 maxAmount = 2.0 } MODULE { name = Scrubber ec_rate = 0.02 co2_rate = 0.0000926 } @MODULE[ModuleGenerator] { @OUTPUT_RESOURCE[ElectricCharge] { @rate = 0.2 } } @MODULE[ModuleRadioisotopeGenerator] { @BasePower = 0.2 } } CryoTanks: // Power requirements for ZBO (zero boil off) tanks cut to 25% @PART[*]:HAS[@MODULE[ModuleCryoTank]]:AFTER[zzz_CryoTanks]:NEEDS[zzz_CryoTanks] { @MODULE[ModuleCryoTank] { @CoolingCost *= 0.25 } } KerbalAtomics: // Nuclear rockets cut to 25% power generation @PART[ntr-*]:HAS[@MODULE[ModuleGenerator]]:AFTER[KerbalAtomics]:NEEDS[KerbalAtomics] { @MODULE[ModuleGenerator] { @OUTPUT_RESOURCE[ElectricCharge] { @rate *= 0.25 } } }

Thanks for the update! Unfortunately, it looks like the new version still hasn't made its way to CKAN, which is odd because it's been up on SpaceDock for a couple days now...

@ShotgunNinja It seems that living space is currently calculated based on crew capacity alone. It would be nice if there was a module to denote extra space not reflected by a part's capacity. For example, I believe the MPL (Lab) would do much more to relieve claustrophobia than the Mk2 Lander Can, yet both have the same crew capacity. I'm picturing something like this: MODULE { name = ExtraLivingSpace amount = 2 // equivalent to 2 extra crew capacity } Also, would it be helpful for me to share more NFT compatibility patches (like these), or do you have it covered?

Just because some complexity is good doesn't mean more is better. Complexity is a spectrum, and ShotgunNinja has carefully positioned Kerbalism at a moderate level, which will appeal to a broad base of players who want something between Snacks! and TAC-LS.

@ShotgunNinja I thought I'd share a couple compatibility patches I drafted for NFE and NFP; might make things a little easier when you put together your official version. NearFuturePropulsion: // All ion engine power requirements cut to 25% @PART[ionEngine,ionArgon-*,ionXenon-*,mpdt-*,pit-*,vasimr-*]:AFTER[NearFuturePropulsion]:NEEDS[NearFuturePropulsion] { @MODULE[ModuleEnginesFX],0 { @PROPELLANT[ElectricCharge] { @ratio *= 0.25 } } } @PART[pit-*]:AFTER[NearFuturePropulsion]:NEEDS[NearFuturePropulsion] { @MODULE[VariablePowerEngine] { @PowerCurve { @key,0[1, ] /= 0.25 @key,1[1, ] /= 0.25 } } } @PART[vasimr-*]:AFTER[NearFuturePropulsion]:NEEDS[NearFuturePropulsion] { @MODULE[ModuleEnginesFX],1 { @PROPELLANT[ElectricCharge] { @ratio *= 0.25 } } @MODULE[VariableISPEngine] { @EnergyUsage /= 0.25 } } NearFutureElectrical: // Fission reactors cut to 25% power generation @PART[*]:HAS[@MODULE[FissionGenerator]]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @MODULE[FissionGenerator] { @PowerGeneration *= 0.25 } } // Nuclear waste recyclers cut to 25% power requirements @PART[nuclear-recycler-*]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @MODULE[ModuleResourceConverter],0 { @INPUT_RESOURCE[#ResourceName[ElectricCharge]] { @rate *= 0.25 } } @MODULE[ModuleResourceConverter],1 { @INPUT_RESOURCE[#ResourceName[ElectricCharge]] { @rate *= 0.25 } } @MODULE[ModuleResourceConverter],2 { @INPUT_RESOURCE[#ResourceName[ElectricCharge]] { @rate *= 0.25 } } } // RTG output tweak applied to Nertea's custom decay module @PART[rtg]:HAS[@MODULE[ModuleRadioisotopeGenerator]]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @MODULE[ModuleRadioisotopeGenerator] { @BasePower = 0.32 } } // Tweaks for Nertea's larger RTG, placing its EC/mass ratio above the stock RTG but below solar panels, with a corresponding cost adjustment @PART[rtg-0625]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @cost = 69900 //3x PB-NUK @MODULE[ModuleGenerator] { @OUTPUT_RESOURCE[ElectricCharge] { @rate = 0.8 //2.5x PB-NUK } } @MODULE[ModuleRadioisotopeGenerator] { @BasePower = 0.8 //2.5x PB-NUK } } // Capacitor charge/discharge rates cut to 25% @PART[*]:HAS[@MODULE[DischargeCapacitor]]:AFTER[NearFutureElectrical]:NEEDS[NearFutureElectrical] { @MODULE[DischargeCapacitor] { @ChargeRate *= 0.25 @DischargeRate *= 0.25 } }

Well, it's a step in the right direction, though unfortunately it still leaves the OX-STAT-XL without any legitimate use cases. If you don't want to further modify the EC or mass properties, perhaps you could just decrease the XL's cost to 225. Then the XL would be like getting 4 OX-STATs for the price of 3, but requiring twice the surface area - a reasonable trade-off in some situations.

I see what you mean, however, it remains a significant problem that the XL panel currently has zero rational use cases; it is unequivocally inferior to the regular OX-STAT. I believe that balance and consistency within a subgroup (e.g., static panels) is more important than between subgroups (OX-STAT-XL vs deployable panels), though of course I agree it would be nice to have consistency between groups as well. If you want better consistency in regard to EC per surface area without changing current EC per mass, you could simply double the EC output and mass of all deployable panels.

Excellent! These are good changes. However, I remain confused by your values for the OX-STAT-XL. The XL is 8x the cost and surface area of the regular OX-STAT, but you gave it only 3x the EC output and mass. Why would I ever use an OX-STAT-XL when I could just use 3 regular OX-STAT for less than half the cost, and requiring less than half the space? I would encourage you to revert the mass to its stock value and adjust the EC output accordingly, to 0.64.

In principle, I completely agree with your rebalancing among solar panels, with an EC/mass hierarchy in which static > nonretractable > retractable. Unfortunately, I think the spread ended up too wide, and some panels were nerfed too hard. For example, the OX-STAT has an EC/mass ratio of 16, nearly 3x greater than the 5.6 ratio of the SP-L/W panels. Again, I completely agree that the SP panels should be less mass efficient, but at 1/3 the efficiency, they're just plain terrible. They're actually even worse than RTGs (EC/mass ratio of 6.25), which I believe is totally undesirable since RTGs have plenty of other advantages. So what would I do? Maintain the same hierarchy, but bring all the panels closer together, primarily by bringing up the lower end of the range. Here are some sample EC production values: OX-STAT: 0.075 OX-STAT-XL: 0.6, and revert mass to stock value of 0.04 OX-4W/L: 0.2 SP-W/L: 0.2 (their greater mass relative to OX-4W/L is already punishing enough) Gigantor: 2.75 I'd also consider doubling the fuel cell outputs, as the current EC/mass ratio for the smaller one is only slightly better than an RTG (doubling would simply revert to the stock balance relative to RTGs). Finally, I'm happy to hear you plan to write an official patch to support NearFuture. I urge you to bear in mind that NFP's engines are meticulously balanced against NFE's reactors, so the EC production/consumption of all these parts should be reduced by the same amount in order to avoid breaking the balance. For example, an across-the-board multiplier of 0.25 looks like it would work fairly well.