Fraz86
-
Posts
462 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Fraz86
-
-
This mod looks amazing! ShotgunNinja, it seems you have an impeccable vision for game mechanics that introduce fun, interesting new elements without becoming overly complicated or burdensome.
I read the wiki, but I'd like to know more on the specific mechanics of quality of life. How do you calculate living space? Is it just based on the number of seats? Are living space, entertainment, and social needs tracked as three separate needs, or do they combine into a single quality of life value? Any chance we could see a zero-G deconditioning mechanic in the future, encouraging the use of centrifuges (cf. Porkjet's hab mod)?
-
41 minutes ago, blowfish said:
You can use whatever approach you want, I was just trying to explain how I designed the default tank types. They're based heavily upon B9's parts, for which there's usually a default tank-less subtype. No one using B9PartSwitch is under any obligation to use this paradigm or use the default tank types.
E: However, I could probably come up with some MM to calculate the correct "structural" mass based on the default mass, tank type mass, and volume pretty easily.
Fair enough. Your approach makes sense if you're starting with structural parts rather than fuel tanks.
-
23 hours ago, blowfish said:
@Nertea the idea is that the part's base mass should be recalculated to only include the "structural" mass.
Hmm, I get the idea - that, theoretically, dry mass comprises both a fixed "structural mass" and a variable "tank mass," but it strikes me as needlessly complicated. Config mass obviously already includes both, and we can easily leave the implied "structural" element constant by simply making adjustments based on differences in tank mass alone (with no need to modify the config mass). See my above numbers for examples. I believe that this approach is easier, more robust, and more precise in reproducing stock masses and costs.
-
22 hours ago, Nertea said:
Well, as long as the right numbers are arrived at, I don't particularly care how they're done. What are cost numbers in this method?
Well, because of the silly way that KSP calculates cost (where dry cost = config cost - fuel cost), I would need to experiment with the fuel switcher to see how exactly it interacts with those calculations. If tankCost is modifying the total cost, including fuel, akin to the config cost, I think the following should be right:
LFO, LH2Cryo = 0 (default configurations; no modification of config cost)
LF = 0.341
OX = -0.279
LH2 = -0.0915
LH2O = -0.1665
LH2OCryo = [deleted - see below]
EDIT - It turns out there isn't a way to accurately calculate LH2OCryo's cost using the tankCost variable alone, due to non-linear scaling. Instead, we need both of the following:
costOffset = -0.2 * config cost
tankCost = -0.1116
EDIT 2 - If the part switcher doesn't have a costOffset variable, or if the use of this variable is deemed undesirable, I came up with an alternate solution:
Modify the part configs for all ZBO tanks, cutting their config costs in half (matching the costs of their stock analogues). Then, set tankCost at 1.0 for LH2Cryo, and 0.4884 for LH2OCryo. The resulting costs would scale a bit more linearly than other fuel tanks, but it would be reasonably similar.
-
1 hour ago, Nertea said:
Yeah, now I'm a bit confused. If realDryMass = cfgMass + volume*tankMass + massOffset, then tankMass should be 0 for stock tank types, or else they will be too heavy.
I think that zeroing the mass does make sense from a consistency point of view. I mean, for pretty much everything derived from stock, there is a fixed dry mass per unit, right, so any fuel tank mass can be given by realDryMass = numUnits*tankMassPerUnit. There is no offset parameter for a basic tank. It makes sense to me to make tankMassPerUnit the same as tankMass, so in B9PartSwitch terms, I want realDryMass = cfgMass + volume*tankMass + massOffset. In most cases I want massOffset to cancel out cfgMass, because the base "structural" cost of the tank is part of the tankMassPerUnit variable, and thus tankMass.
Actually, there are important exceptions to the standard tankMassPerUnit (0.000625), namely, all spaceplane parts (0.0007125), multi-purpose modules (with fuel + X, e.g., batteries or MP), and your truss tanks. Granted, we could find a way to zero out config mass and still account for these variances, but I think it would be a more robust and simpler implementation to leave config mass untouched. It would also allow for better consistency with tankCost calculations, where we definitely can't zero out the config costs because they scale non-linearly.
Here are the tankMass values for this approach:
LFO, LF, OX, and LH2Cryo = 0 (these configurations should use the unmodified config mass)
LH2 = -0.000375
LH2O = -0.000225
LH2OCryo = 0.000125
With these values, there would be no need for any massOffset or modification of existing config mass values.
-
7 hours ago, blowfish said:
Those values are the amount of base mass and cost the part should have (per volume) in addition to what the tank adds. But they were mostly just there for for my own reference (and I never bothered to remove them). And they're very approximate values based on stock anyway.
But still @Nertea I think your configs might be making the tanks lighter than they should be, since you're using the provided tank types but then subtracting the base part mass. I'm not going to say that you can't include the structural mass in tank types, but you should probably make your own set of tank definitions if you want to do things that way.
Ah, that makes a bit more sense. But then, shouldn't tankMass = 0 for LFO, LF, and OX? If the mass specified in the part config is left untouched, then shouldn't stock tanks already have the correct mass for those fuel types?
I do think this approach makes more sense overall, as opposed to zeroing out the part config mass. Nertea, I'd be happy to provide corrected tankMass and tankCost values for this implementation.
-
9 hours ago, Nertea said:
Just an FYI, I did not bundle the correct version of B9PartSwitch, the one that ended up in the zip is only good for pre-1209 releases. I recommend not downloading this until I fix it tonight.
Looking at CryoTanksFuelTankTypes.cfg, I believe there are a few other issues to address:
- Oxidizer's tankMass should be 0.000625
- Based on the values in B9PartSwitch.cfg, I think tankCost is meant to be the dry cost per unit volume (I imagine it adds the fuel cost automatically), whereas LH2 and Oxidizer's tankCost is currently set equal to the fuel cost per unit volume
- I believe we need two more tank types (LH2Cryo and LH2OCryo) in order to give ZBO tanks their higher mass and cost; tankMass should be 0.0003125 for LH2Cryo and 0.0004375 for LH2OCryo
Edit - It should also be noted that B9PartSwitch.cfg appears to contain errors/misinformation, and thus should not be relied on as the basis for setting your variables. For example, based on stock values, rocket mass should be 0.000625, and spaceplane mass should be 0.0007125, in disagreement with the comment section at the top of the config:
// Structural values (should be set by user) // Rocket // Mass = 0.0005 // Cost = 0.25 // Spaceplane (re-entry shielded, maxTemp > 2000) // Mass = 0.000625 // Cost = 0.375 -
Two of Nertea's mods - CryoEngines and KerbalAtomics - use IFS. See the ModuleManager file at the bottom of my post for specifics. It seems to work as intended, however, a couple interface issues have been noted. First, the "Engineer Report" in the VAB appears to miscalculate the mass of the fuel tanks, using twice the actual dry mass. Second, when you right-click one of the tanks in-flight, there is a line that reads "Dry mass: 0t." Both of these errors don't appear to have any real effect (the game still uses the correct mass values), but it's annoying nonetheless.
If there's a different way to write the IFS config that would avoid these issues, please let me know.
// Lifting tanks @PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels] { %LH2ConversionFactor = 10 // <- EDIT HERE (units of LH2 that occupy a volume equivalent to one unit of LF or OX) %LH2OUnitRatio = 15 // <- EDIT HERE (LH2:OX unit ratio for LH2O configuration; should correspond to burn ratio of cryogenic engines) %mixOXProportion = 0.4 // <- EDIT HERE (proportion of tank volume containing OX; should approximately = 1 / [1 + [LH2OUnitRatio / LH2ConversionFactor]]) %dryMassPerUnitLH2 = 0.000025 // <- EDIT HERE (dry mass per unit LH2 capacity) %LF = #$RESOURCE[LiquidFuel]/maxAmount$ %OX = #$RESOURCE[Oxidizer]/maxAmount$ %totalCap = #$RESOURCE[LiquidFuel]/maxAmount$ @totalCap += #$RESOURCE[Oxidizer]/maxAmount$ %onlyLH2 = #$totalCap$ @onlyLH2 *= #$LH2ConversionFactor$ %mixOX = #$totalCap$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= #$LH2OUnitRatio$ // masses %massOffset = #$mass$ %tempVar = #$totalCap$ @tempVar *= 0.000625 // standard dry mass per units of LF/OX @massOffset -= #$tempVar$ // accounts for non-standard tank mass, which should remain constant across fuel configurations, e.g., extra mass for spaceplane tanks %onlyLH2mass = #$onlyLH2$ @onlyLH2mass *= #$dryMassPerUnitLH2$ @onlyLH2mass += #$massOffset$ %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 @tempVar = #$mixLH2$ @tempVar *= #$dryMassPerUnitLH2$ @mixLH2mass += #$tempVar$ @mixLH2mass += #$massOffset$ // costs %LFOcost = #$LF$ @LFOcost *= 1.02 @cost -= #$LFOcost$ %mixLH2cost = #$mixLH2$ @mixLH2cost *= 0.03675 @tempVar = #$mixOX$ @tempVar *= 0.18 @mixLH2cost += #$tempVar$ %LFcost = #$totalCap$ @LFcost *= 0.8 %OXcost = #$totalCap$ @OXcost *= 0.18 %onlyLH2cost = #$onlyLH2$ @onlyLH2cost *= 0.03675 !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} MODULE { name = InterstellarFuelSwitch volumeMultiplier = 1 massMultiplier = 1 resourceGui = LF/OX;LH2/OX;LF;OX;LH2 resourceNames = LiquidFuel,Oxidizer;LqdHydrogen,Oxidizer;LiquidFuel;Oxidizer;LqdHydrogen resourceAmounts = #$../LF$,$../OX$;$../mixLH2$,$../mixOX$;$../totalCap$;$../totalCap$;$../onlyLH2$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../mass$;$../mixLH2mass$;$../mass$;$../mass$;$../onlyLH2mass$ tankCost = #$../LFOcost$;$../mixLH2cost$;$../LFcost$;$../OXcost$;$../onlyLH2cost$ } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen // in % per hr BoiloffRate = 0.05 } } // ZBO tanks @PART[*]:HAS[@RESOURCE[LqdHydrogen],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels] { %LH2ConversionFactor = 10 // <- EDIT HERE (LH2 vs LF/OX capacity conversion; should be identical to LH2ConversionFactor for lifting tanks above) %LH2OUnitRatio = 15 // <- EDIT HERE (LH2:OX unit ratio; should be identical to LH2OUnitRatio for lifting tanks above) %mixOXProportion = 0.4 // <- EDIT HERE (proportion of tank volume containing OX; should be identical to mixOXProportion for lifting tanks above) %dryMassPerUnitLH2 = 0.00003125 // <- EDIT HERE (dry mass per unit LH2 capacity) %LH2 = #$RESOURCE[LqdHydrogen]/maxAmount$ %mixOX = #$LH2$ @mixOX /= #$LH2ConversionFactor$ @mixOX *= #$mixOXProportion$ %mixLH2 = #$mixOX$ @mixLH2 *= #$LH2OUnitRatio$ // masses %mixLH2mass = #$mixOX$ @mixLH2mass *= 0.000625 %tempVar = #$mixLH2$ @tempVar *= #$dryMassPerUnitLH2$ @mixLH2mass += #$tempVar$ // costs %LH2cost = #$cost$ @LH2cost *= 0.5 @tempVar = #$LH2$ @tempVar /= #$LH2ConversionFactor$ @tempVar *= 0.459 @LH2cost += #$tempVar$ @cost -= #$LH2cost$ %mixLH2cost = #$LH2cost$ @tempVar = 1 @tempVar -= #$mixOXProportion$ @mixLH2cost *= #$tempVar$ @tempVar = #$mixOX$ @tempVar *= 0.18 @mixLH2cost += #$tempVar$ !RESOURCE[LqdHydrogen] {} MODULE { name = InterstellarFuelSwitch volumeMultiplier = 1 massMultiplier = 1 resourceGui = LH2;LH2/OX resourceNames = LqdHydrogen;LqdHydrogen,Oxidizer resourceAmounts = #$../LH2$;$../mixLH2$,$../mixOX$ displayCurrentTankCost = true hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = 0 tankMass = #$../mass$;$../mixLH2mass$ tankCost = #$../LH2cost$;$../mixLH2cost$ } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen // in % per hour BoiloffRate = 0.05 // in Ec per 1000 units per second CoolingCost = 0.08 } } -
10 minutes ago, bertibott said:
still 16 litres of water is a lot. a grown human needs about (please don't quote me on this... not really my field of expertise) 2.5 - 5 liters per 24-hour-day depending on the kind of activites one would engage in... if you run a marathon you'll need more... or if you live in a very hot area...
I think 16L/day is meant to include water used for hygiene, food preparation, etc.
-
@mikegarrison @blowfish @Crzyrndm
I noticed the same issues regarding the dry mass indicated in the Engineer's Report (doubled) and in-flight right-click (zero). As far as I can tell, they're purely display errors with no actual impact on gameplay, but annoying nonetheless. If any of you know a different way to set up the IFS config that avoids these issues, I'd be happy to re-work the fuel-switching patch.
-
On 2/9/2016 at 11:30 AM, RoverDude said:
I've actually yanked replacementparts from the recyclers as these are already consumed as part of life support itself
Sounds good. However, the Mobile Processing Lab's recycler (added by LSModule.cfg) still consumes replacementparts.
-
26 minutes ago, Businfu said:
after seeing a new "Radioactivity.cs" file on your Git, I'm even more excited.
Good find! Nertea, do you have any teasers regarding what this might entail?
-
12 minutes ago, Kirondoll said:
That tank should hold 4800 LH2 and 320 OX. Either something went wrong with the latest release, or you have some other mod that is overwriting the tank capacities.
-
3 minutes ago, goldenpsp said:
Are you using other USI mods, like MKS or MKS-L? if so did you verify the settings for USI-LS in those mods? they may be overriding the USI-LS defaults.
No, I am not using any other USI mods. Regardless, I don't think the USI-LS settings have any impact on Recycler ReplacementParts consumption (it's simply an INPUT_RESOURCE for the recycler module).
-
5 hours ago, Kobymaru said:
It seems that when the Recyclers are enabled, they produce "Wear" (consume ReplacementParts), that reduces the vessels maximum habitation time which in turn reduces the kerbals current habitation time, faster than the game time.
I'm not sure if the Wear produced by the Recyclers is a feature (why would recycling cause wear on the parts?).
It bothers me that Recyclers consume ReplacementParts even when ReplacementParts consumption is otherwise disabled (i.e., when "ReplacementPartAmount = 0," as in the default settings for USI-LS). Not only does this result in faster-than-expected depletion of habitation time, as you observed, but it also means that Recyclers will eventually deplete all available ReplacementParts and stop working.
@RoverDude I believe there's a way to set the Recyclers' ReplacementParts consumption based on ReplacementPartAmount. "Ratio = #$@LIFE_SUPPORT_SETTINGS/ReplacementPartAmount$" ought to work. Add another line that reads "@Ratio *= 10" if you want "ReplacementPartAmount = 0.000001" to correspond to a Recycler consumption rate of 0.00001 (the current rate).
-
8 minutes ago, Nertea said:
I think I view the modulegenerator approach as the bad thing in this case. It's really not very good in terms of balance with stock, much less with any pack that cares about electricity consumption.
I agree. The NFE implementation will be all around much more interesting and well balanced. The modulegenerator version is the problem; it's overpowered. For example, the Poseidon's modulegenerator (100 EC/s) is equivalent to 133 stock RTGs, which corresponds to a mass of 10.7t and a cost of 3,106,667 funds - for the generator alone.
A lower mass and cost relative to RTGs can be justified for the NFE version, because it comes with additional challenges and limitations. But the "free electricity forever" version (i.e., modulegenerator) should probably produce substantially less EC in order to maintain reasonable balance.
-
8 hours ago, Nertea said:
Yes they will work with NF Electrical that way, I am not ready to enable that patch yet though.
I'm looking forward to NFE integration, however, I'm curious - do you plan to include any positive balancing factors to compensate for the challenges/limitations that NFE will add to the engines? A FissionGenerator producing 100 EC/s is significantly inferior to a ModuleGenerator producing 100 EC/s (no fuel required, no heat generated, etc.). It would strike me as fair if the NFE version was capable of producing at least twice as much EC as the ModuleGenerator version.
-
13 hours ago, Bluebottle said:
Thanks for your considered answer here. LOX can hardly be considered a "storable" - usually it would be gone in a couple of weeks - but I understand that altering a stock resource would be wrong. This isn't Realism Overhaul. Then again, LH2 is now the only propellant with RO-like properties, i.e. boiloff.
LH2 boiloff isn't intended to feel like an "RO-like property." It's intentionally simplified and easily prevented, so hopefully it feels more like a small factor that sets LH2 apart from other fuels in an interesting way, as opposed to a rigorous simulation of real-world challenges.
QuoteThis petite darling, my "Olympus" station...
Yes, 18 spherical tanks wrapped around Speedy's hex truss in the LH2 section for 20,760,000 LH2, and another 4 million in the hydrolox section with the tweakscaled Mondo tanks. Each section is only 1 welded part (I love that Ubio plugin) which works well after some part file editing. Everything except LFO will be dry for the Minmus-Kerbin transfer, and then I'll have to make some similarly large tankers to service it.
That's where I'm running into problems with the feasibility of LH2/NTR and hydrolox.
Haha, well, as I'm sure you're aware, that thing is very far from a typical craft.
QuoteYes, they are. And the mass and volume ratios you've implemented are remarkably realistic (very close to the Delta IV CBC). A Centi-2 + Centi-3 tweakscaled (I know, I know) to 5m give me something very close to a D-IV CBC tank (http://spaceflight101.com/spacerockets/delta-iv-heavy/), so the 2x fudge isn't actually unrealistic in that case. The engine TWRs, though, have relegated cryo engines to being niche parts - suitable only for a 2nd/3rd stage lifter - which is somewhat realistic, but therefore unbalanced versus the now-magical-by-comparison LFO. What I'm saying is: nobody's going to use them, at least nobody who uses KER or Mechjeb for dV calculations, or anybody cares about part count and doesn't weld (so, so many tanks on interplanetary vessels). That makes me sad because I love the idea/concept of the cryo engines.
It may be the case that hydrolox engines and NTRs need some buffing to make them more attractive. I think Nertea has wisely approached these balancing issues conservatively, because we absolutely don't want to create uber-engines that outright obsolete LFO.
-
47 minutes ago, Psycho_zs said:
If LH2 fudge factor were 1.5, it would result in much more handy (matching-wise and a bit closer to RL) 2:1 tankage ratio with OX. Just a thought occurred while trying to mash up a ship with cool looks, separate LH2/OX tanks and sane part count.
The LH2/OX tankage ratio is currently 3:2, which I think is plenty handy, and much easier than the stock LF/OX ratio of 9:11. It's true that real-world LH2/OX tankage ratio is closer to 2:1, but Nertea's cryogenic engines run a bit more fuel-rich than their RL counterparts. Regardless, these ratios are reasonably close to RL, and precise realism has never been a high priority in Nertea's mods - balance take precedence, and I believe the current volume ratio offers the best balance.
-
4 hours ago, blowfish said:
I think it's more meaningful to look at the tank mass per unit of fuel mass rather than per volume. Since just about everything in rocketry is about mass (volume affects drag a bit but it's usually not a major concern).
Fuel:dry mass ratios are certainly much more meaningful for analysis of performance. However, when arguing that LH2 tanks ought to be lighter, based on comparisons to specific real-world rocket stages or lack of need for internal bracing (as Bluebottle was doing), I believe it's useful to step back and remember that empty LH2 tanks are actually the lightest objects in the game for their size.
-
6 hours ago, Bluebottle said:
The dry mass argument doesn't quite stack up, given that Centaur was incredibly light, and RP1 tanks require(d) significant internal bracing (in lift stages). Centaur's structural strength came from the pressurization of the contents.
Nertea's LH2 tanks are incredibly light. An LH2-only ZBO tank has only half the dry mass of an equivalently-sized LFO tank. LH2 lifting tanks are even less.
QuoteAlso, did you take into account the cryogenic nature of the LO in an LFO tank? It seems only LH2 is being penalized for insulation weight/dry mass disadvantages, and LO gets away with it.
The fuel:dry mass ratio for oxidizer (8:1) is derived from stock KSP, and as such is not something we would alter. Nor would we add boiloff to a stock resource. Adding boiloff for LH2 but not LOX makes a certain amount of sense anyway, as boiloff is a much less severe problem for LOX compared to LH2 in the real world. Moreover, the mass "penalty" for extra insulation/refrigeration for LH2 is actually relatively minor - that is, the interval mass difference between LH2 lifting tanks and ZBOs is equivalent to only 10% of the dry mass of a volume-matched LFO tank.
The true dry mass "penalty" for LH2 tanks is primarily related to fuel density. LH2 is far less dense than other fuels, and therefore requires much greater (~700%) tank volume for an equivalent fuel mass. Greater tank volume means greater tank mass, though the mass per volume is actually only half as much (or less), as mentioned above, which partially offsets this penalty. The penalty is further mitigated by using 2x the real-world density of LH2. What we're left with should be a bit inferior to LFO as a fuel type, but reasonably easy to balance by giving NTRs attractive properties.
QuoteWhen you need upwards of 2000Ec/s for ZBO, those reactors get heavy!
What kind of craft are you building that requires 2000 EC/s for ZBOs? That should correspond to 18 of the ridiculous 10 meter tanks.
QuoteWith absolutely no snark (I know how difficult the IFS configuration is), has the outcome matched your intentions?
Yes, absolutely. I'm not aware of any significant problems with the current implementation. It may come to light that a few things need some minor balancing tweaks, but I think it's a very robust framework.
-
1 hour ago, Jimbodiah said:
What was the intent for switching from 10:1 to 15:1, as I thought the balancing was out for realistic weights and volumes?
It was motivated by a balancing dilemma: how to give LH2O tanks a meaningful dry mass disadvantage relative to LFO, despite LH2 representing only a small percentage of the tanks' mass (mostly OX), without making LH2-only tanks unplayably terrible as a result. I would recommend reading the dev thread if you'd like to know more.
In regard to realism, the LH2:OX mass ratio was a little below real-world before, and a little above real-world now. The LH2:OX volume ratio is now closer to real-world.
-
@Shadowmage Your interpretation is correct, and yes, it's completely intentional. With CryoTanks, LH2 is given 200% real-world density inside fuel tanks for gameplay and balance reasons. Even with 2x real-world density, it remains far less dense than other fuels (e.g., ~14% LFO density) and thus still poses an interesting challenge to the player without becoming un-fun. Ideally, it would be nice for the LqdHydrogen resource definition to reflect this greater density (rather than being fudged via configs), but it's a CRP resource and thus can't be altered ad hoc.
-
Currently all recyclers consume 1 EC/s. I wrote a patch that sets recyclers' EC consumption as the product of their capacity and efficiency. For example, the science lab consumes 3.5 EC/s (5 capacity x 0.7 efficiency). I'll post it here if anyone is interested:
@PART[*]:HAS[@MODULE[ModuleLifeSupportRecycler]] { @MODULE[ModuleLifeSupportRecycler] { @INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]] { @Ratio = #$/MODULE[ModuleLifeSupportRecycler]/CrewCapacity$ @Ratio *= #$/MODULE[ModuleLifeSupportRecycler]/RecyclePercent$ } } }
That's where I'm running into problems with the feasibility of LH2/NTR and hydrolox.
[1.3.0] Kerbalism v1.2.9
in KSP1 Mod Releases
Posted · Edited by Fraz86
@ShotgunNinja EnergyTweaks.cfg concerns me. These tweaks make Kerbalism effectively incompatible with any mod that has EC-generating or EC-consuming parts. Compatibility patches will be difficult to write, as there are no easy-to-follow rules about the adjustments that need to be made - EC rates are variously cut by 0% (ISRU, drills), 33% (RTG), 50% (radiators, lights), 67% (fuel cells), 75% (wheels, alternators), ~72% (ion engine), ~77% (static solar panels), and >90% (deployable solar panels). Furthermore, there is some discrepancy/imbalance among these tweaks (e.g., the OX-STAT generates 16 EC/mass while the OX-STAT-XL generates only 10 EC/mass) that exacerbates the lack of clarity.
Because all EC rates are decreased except mining/ISRU, the primary effects of these tweaks are to increase the relative significance of batteries and make mining/ISRU more difficult. Personally, I would have preferred that you accomplish these effects by the opposite approach; i.e., increase battery capacities and mining/ISRU EC-consumption (with perhaps a modest decrease in solar panel output if necessary), while leaving other EC rates untouched. If you stick with the current implementation, I would ask that you please provide clear documentation on the recommended compatibility tweaks for other mods.