ABZB

at vehicle load - does it not actually matter, then? I am curious if the MC can note the meaning...

Does anyone know what might cause the following to spam for every part on a vessel: FAR Error: Aerodynamic force = NaN AC Loc = 6.99705131294936 AoA = 0 MAC = 1.388 B_2 = 1.311 sweepAngle = 6.12303176911189E-17 MidChordSweep = 27.6 MidChordSweepSideways = 0.111888451949879 at R8winglet (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Do the engine tech level cfgs work with multimode engines, like the rapier?

1)D-T should produce He-4 - the LiquidHelium resource used for the telescope (and my recompile of the cryogenic mod I posted a few pages back). 2)D-D (not currently implemented as a fuel mode) produces either tritium or He-3 (50% each) so if you have X reactions per second - there should be X/2 He-3 produced per second, and X/2 tritium per second.*** 3)D-He3 produces He-4* 4)He3-He3 produces He-4** [quite convenient for Magnetic Nozzle, I guess] *also produces 1 proton - i.e. regular Hydrogen - ie liquidfuel. The justification for capturing anything from fusion is that the way charged-particle power generation works, you can plausibly capture the nucleii (you are essentially transferring the kinetic energy ('speed energy') of the charged products into electrical current - so they slow down, to the point where they can be captured, and re-united with electrons to form regular atoms). ** produces two protons per reaction ***produces one proton per tritium-producing reaction (the he-3 pathway releases a neutron instead) I *think* this is actually relatively easily accomplished from existing code - i think the tritium breeding code could be expanded and adopted to produce the appropriate products scaled to current reaction rate.

I think that USI has something like that in the asteroid mining pack - there are expandable tanks that grow and shrink based on need (so you can presumably hold however much of whatever combination).

I noted previously that firespitter and modularfueltanks already grants this capacity. you just have to MM a patch to add the various KSPI resources to the tank definitions. The following should work for both Modular Fuel Tanks and Real Fuels: @TANK_DEFINITION[*]:HAS[@TANK[XenonGas]]:FINAL { TANK { name = ArgonGas amount = 0.0 maxAmount = 0.0 utilization = 56.0 note = (pressurized) } TANK { name = LqdDeuterium amount = 0.0 maxAmount = 0.0 utilization = 7 note = (pressurized) } TANK { name = LqdTritium fillable = true amount = 0.0 maxAmount = 0.0 utilization = 7 note = (pressurized) note = (Shielded) } TANK { name = LqdHelium3 fillable = true utilization = 56 amount = 0.0 maxAmount = 0.0 utilization = 7 note = (pressurized) } TANK { name = LqdHelium amount = 0.0 maxAmount = 0.0 utilization = 7 note = (Refrigerated) } } @TANK_DEFINITION[ServiceModule]:FOR[ExtraTanks] { TANK { name = UraniumNitride amount = 0.0 maxAmount = 0.0 fillable = true utilization = .8 } TANK { name = UF4 amount = 0.0 maxAmount = 0.0 fillable = true utilization = .8 note = (Shielded) } TANK { name = ThF4 amount = 0.0 maxAmount = 0.0 fillable = true utilization = .8 note = (Shielded) } TANK { name = Actinides fillable = False amount = 0.0 maxAmount = 0.0 utilization = .8 note = (Shielded) } TANK { name = DepletedFuel amount = 0.0 maxAmount = 0.0 fillable = false utilization = .8 note = (Shielded) } } @TANK_DEFINITION[*]:FINAL { TANK { name = Aluminium amount = 0.0 maxAmount = 0.0 } TANK { name = Lithium amount = 0.0 maxAmount = 0.0 } TANK { name = Water amount = 0.0 maxAmount = 0.0 } }

yes the relays relay power transmitted by a transmitter.

I seem to be having a problem with the motor - my wheels don't all spin in the same direction, and enabling reverse motor on the backwards wheels does not seem to help. my craft end up staying in place or veering wildly when I try to taxi.

Single tanks with multiple possible fuel storage options is a currently avaialble feature, at the cost of adding a dependancy to firespitter (for the FSfuelswitch) or Modular/Real Fuel Tanks. I think the USI guy has/is working on a module that can hold multiple fuels, expanding and contracting different fuel's tank as needed (on the fly - I think it's part of his asteroid pack - that allows you to store fuel in asteroids)

If anyone's interested, here's some MM to add DRE functionality to the docking ports (the heat shield only functions when they are closed): @PART[bahaPortClosed|bahaPortClosed2] { MODULE { name = ModuleHeatShield direction = 0, -1, 0 // bottom of shield (part that opens up) reflective = 0.20 // 20% of heat is ignored at correct angle (when closed) } MODULE { name = ModuleAnimation2Value animationName = deployShield valueModule = ModuleHeatShield valueName = reflective valueCurve { key = 0.0 0.20 0.0 0.0 //shield is closed key = 0.5 0.05 0.0 0.0 //shield is opening key = 1.0 0.0001 0.0 0.0 //shield is fully opened, no protection (I gave it a small positive value (shields 1/100th of 1 percent - to forestall possibility of bugs involving a reflective value of 0)) } } } @PART[bahaPortOpen] { //reversed from closed model MODULE { name = ModuleHeatShield direction = 0, -1, 0 reflective = 0.0001 } MODULE { name = ModuleAnimation2Value animationName = deployShield valueModule = ModuleHeatShield valueName = reflective valueCurve { key = 0.0 0.0001 0.0 0.0 key = 0.5 0.05 0.0 0.0 key = 1.0 0.20 0.0 0.0 } } }

I've been seeing the same

in warpplugin/resources/resourcesnuclear.cfg - check if in the antimatter resource node the following is the case: flowMode = ALL_VESSEL transfer = PUMP

what altitude/inclination are you at?

energy per µg: 179.8/1 (Gj/mg antimatter)**(1mg/1000 µg) => 179.8*10^(-3) Gj/µg * 1000 Mj/Gj = 179.8 Mj/µg = 179.8 Mj/µg time per .1798 Mj: (.1798 Mj)/(3000 MW) ~ .06 seconds assuming you actually have 3000 MW output.

This Mod grants cryogenic crew storage: http://forum.kerbalspaceprogram.com/threads/92806-WIP-25-PaladinLabs-Dev-Thread-DeepFreeze-cryonic-crew-storage-v-012 It uses a custom resource: Glykerol. It is useful for life-support mods. I made a slight tweak to the code and compiled - to use LqdHelium - for now, convenient really only for the gravitational lensing thing (and for now, the only mission that that might be terribly useful for, anyway). The edited source and .dll can be downloaded from my dropbox: https://www.dropbox.com/s/svy9pgp1qwodlfw/DeepFreeze-v.12-KSPI-Version.zip?dl=0

Those are tweakscalable - just stick the following somewhere in a .cfg: //these tell TweakScale that the 'radius' scales linearly - i.e. that doubling size from 1.25 to 2.5 multiplies the radius by 2^1. (the # that the variable is equal to is the exponent by which the multiplier-to-size is raised) TWEAKSCALEEXPONENTS { name = FNNozzleControllerFX radius = 1 } TWEAKSCALEEXPONENTS { name = FNNozzleController radius = 1 } @PART[smallerThermalRocketNozzle] // 62.5cm Thermal Rocket Nozzle { MODULE { name = TweakScale type = stack defaultScale = 0.625 } } @PART[ThermalTurbojet] // 1.25m Thermal Turbojet { MODULE { name = TweakScale type = stack defaultScale = 1.25 } } @PART[smallThermalRocketNozzle] // 1.25m Thermal Rocket Nozzle { MODULE { name = TweakScale type = stack defaultScale = 1.25 } } @PART[ThermalRocketNozzle] // 2.5m Thermal Rocket Nozzle { MODULE { name = TweakScale type = stack defaultScale = 2.5 } } @PART[ThermalTurbojet2] // 2.5m Thermal Turbojet { MODULE { name = TweakScale type = stack defaultScale = 2.5 } } @PART[bigThermalRocketNozzle] // 3.75m Thermal Rocket Nozzle { MODULE { name = TweakScale type = stack defaultScale = 3.75 } } } EDIT: Here is my .cfg from my dropbox https://www.dropbox.com/s/5qdgwf7vah52wiw/Interstellar_TweakScale.cfg?dl=0 Delete any warp.cfg in the tweakscale folder first (lest you get duplicate modules on parts)

The new interstellar release changed way some nodes work - just copy+paste the new module node and the effects node from the large MPD

Excellent - no problem.

That looks like a problem with the scale node in the .cfg - there was a fix for it somewhere back in the thread.

I am getting errors of the following kind: FAR Error: Aerodynamic force = NaN AC Loc = 5.26257513287772 AoA = 0 MAC = 1.388 B_2 = 1.311 sweepAngle = 6.12303176911189E-17 MidChordSweep = 27.6 MidChordSweepSideways = 0.111888451949879 at R8winglet Many, many lines of that kind of thing - is there some mod/Modulemanager edit that might have caused this? it was working fine a few days ago...

-Hmm do you think I should reduce the amount it produces? I guess that would make sense... scaling from RL is iffy - for comparison, each RTG unit on the Voyagers (each probe had 3 separate units) massed at 37.7 kg (.0377 Metric tons (the KSP mass unit)) including about .0045 MT (4.5 kg) of Pu-238, providing 157 watts. Assuming that 1 ec/sec is 1 KW, that maps to .157 ec/s, or 9.42 ec/minute - much weaker than the stock unit, which is worth about 5 of them. In any event, the ec production can be easily be tweaked by manipulating the ec output ratio. -The decay plugin properly scales by amount remaining (the change per unit time is "resource amount left" * "decay constant"). As Pu-238 decays away, the rate of RTGHeat production falls. The rate for RTGHeat consumption in ModuleGenerator is within +/- .001 of the amount produced when the amount is full (I think). As less is available, the amount of EC produced also falls (the ratio should remain constant).

It seems the decay module scales based on mass - it produces infinite ElectricCharge and wasteheat per unit Pu-238... Also, the convFactor is never actually called in the module, it has no effect. I therefor have made the Pu-238 decay to an intermediate dummy resource, that is then mandatorily converted into EC. I removed wasteheat - all that happens if it overloads is that the radiators explode - it does nothing to the RTG Now every second about 10 units of RTGHeat should be produced, which is instantly transformed into 4 units of EC. I chose this amount, as it should be enough to sustain many/most RTG antennas+probe power drain, with a small amount left over. It will not be enough to also power the stock ion engine - that would require stacking a few of these, or having a stockpile of EC. @PART[rtg] { RESOURCE { name = Plutonium-238 amount = .25 maxAmount = .25 } RESOURCE { name = ElectricCharge amount = 0 maxAmount = 1000 } RESOURCE { name = RTGHeat amount = 0 maxAmount = 10 } @MODULE[ModuleGenerator] { %requiresAllInputs = TRUE INPUT_RESOURCE { name = RTGHeat rate = 10 } @OUTPUT_RESOURCE[ElectricCharge] { @rate = 4 } } MODULE { name = ModuleElementRadioactiveDecay decayConstant = 4.4788965e-10 resourceName = Plutonium-238 decayProduct = RTGHeat convFactor = 1 } } @RESOURCE_DEFINITION[Plutonium-238] { unitCost = 2304.0 } RESOURCE_DEFINITION { name = RTGHeat density = .0001 flowMode = ALL_VESSEL transfer = NONE isTweakable = false } EDIT: typoed the EC. missed the "@". fixed.

I noticed that Plutonium-238 is included in the resources. It is used for power generation on probes: http://en.wikipedia.org/wiki/Plutonium-238 http://www.wired.com/2013/09/plutonium-238-problem/all/ http://www.space.com/20774-plutonium-spacecraft-fuel-nasa-budget.html http://en.wikipedia.org/wiki/Radioisotope_thermoelectric_generator They are generally 'one piece' systems - by which I mean that they would seem to be translated into KSP as a single part (ie not use the generator parts like the other generators) I made a small .cfg to implement this for Squad's RTG part: @PART[rtg] { RESOURCE { name = Plutonium-238 amount = .25 maxAmount = .25 } RESOURCE { name = ElectricCharge amount = 0 maxAmount = 1000 } !MODULE[ModuleGenerator]{} MODULE { name = ModuleElementRadioactiveDecay decayConstant = 2.23944825e-10 resourceName = Plutonium-238 decayProduct = ElectricCharge convFactor = 10 } MODULE { name = ModuleElementRadioactiveDecay decayConstant = 2.23944825e-10 resourceName = Plutonium-238 decayProduct = WasteHeat convFactor = .1 } } @RESOURCE_DEFINITION[Plutonium-238] { unitCost = 2304.0 } I extrapolated the constant for decay Pu-238 from the RL half-lives of Tritium and Pu-238, and the decayconstant for Tritium. The value used here is halved, as I have it decaying into two different things at the same rate (to get wasteheat). I need to verify as to how the decyaconstant works - if that functions properly. Pu-238 has a similar production/stockpile issue as to Tritium (see links above) so I gave it the cost of Tritium. The amount of Pu-238 given should last for around 50 in-game years (timewarped on launchpad). (seems to go decently with the Voyager probes - they are powered by Pu-238, and are expected to have power until around 2025. The electricity production may be way too high - may need to be fine-tuned.

From my playing around with adding reactor types - I think only the fusion reactor module is capable of producing chargedparticles, or the antimatter reactor module is incapable of supporting switching modes. To get around this, The following would work: @PART[AntimatterReactor*] { RESOURCE { name = ChargedParticles amount = 0 maxAmount = #$../RESOURCE[ThermalPower]/maxAmount$ } @MODULE[FNAntimatterReactor] { @name = InterstellarTokamakFusionReator powerRequirements = 0 minimumThrottle = 0 chargedParticleRatio = 0.4 } }

Wasteheat is controlled by entirely by code in the plugin - basically, it seems to simply do stuff whenever the solar panel code is running. The nearfuture tech panels that use the nearfuturesolar module to work (the curved ones) will not trigger wasteheat, unless Fractal adds to the wasteheat.cs to look for and properly interact with that as well