Jump to content

ABZB

Members
  • Posts

    822
  • Joined

  • Last visited

Everything posted by ABZB

  1. Is there a way to append to a string value? I want to do something like this: +PART[*]:HAS[@MODULE[ModuleRCS]] { @name = *whatever name is* LFO (so KWrcsPod becomes KWrcsPodLFO) ... }
  2. Interesting discussion going on here today. In RL - I guess we'll wait and see. On the other hand - if someone wants to add more-or-less-that parts, regardless of the veracity of the claims: ATMOSPHERIC_NTR_PROPELLANT { name = AirAugmented[LF] guiName = IntakeAir ispMultiplier = 0.4 isLFO = True isJet = True PROPELLANT { name = IntakeAir ratio = 20 } PROPELLANT { name = LiquidFuel ratio = 1 DrawGauge = True } } ATMOSPHERIC_NTR_PROPELLANT { name = AirAugmented[Al] guiName = IntakeAir ispMultiplier = 0.3 isLFO = True isJet = True PROPELLANT { name = IntakeAir ratio = 20 } PROPELLANT { name = Aluminium ratio = 1 DrawGauge = True } } ATMOSPHERIC_NTR_PROPELLANT { name = AirAugmented[CH4] guiName = IntakeAir ispMultiplier = 0.5 isLFO = True isJet = True PROPELLANT { name = IntakeAir ratio = 20 } PROPELLANT { name = LqdMethane ratio = 1 DrawGauge = True } } This will add jet-like functionality to those engines for the three propellants in KSPI that utilize Oxidizer. From what I read on the wiki article, they should function as standard rockets with the IntakeAir added: ATMOSPHERIC_NTR_PROPELLANT { name = AirAugmented[LF] guiName = IntakeAir ispMultiplier = 0.4 isLFO = True isJet = True PROPELLANT { name = IntakeAir ratio = 20 } PROPELLANT { name = LiquidFuel ratio = .9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } } ATMOSPHERIC_NTR_PROPELLANT { name = AirAugmented[Al] guiName = IntakeAir ispMultiplier = 0.3 isLFO = True isJet = True PROPELLANT { name = IntakeAir ratio = 20 } PROPELLANT { name = Aluminium ratio = 1 DrawGauge = True } PROPELLANT { name = Oxidizer ratio =4.05 } } ATMOSPHERIC_NTR_PROPELLANT { name = AirAugmented[CH4] guiName = IntakeAir ispMultiplier = 0.5 isLFO = True isJet = True PROPELLANT { name = IntakeAir ratio = 20 } PROPELLANT { name = LqdMethane ratio = 1 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 2.72 } } Of course, the out-of-atmosphere functionality comes with later tech tree upgrades. I did not make it work with the generic intakeatmosphere from KSPI - as that can be had out of the presence of oxygen. I assumed that all 3 in each case have greater ISP than the just-intake sources. I arranged them as ISP[CH4]>ISP[LF]>ISP[Al] - the multipliers are .5,.4,.3 - if anyone has better numbers, feel free to post as such
  3. I just installed Real Solar System (I am using the 6.4:1 Kerbin config). All of the planets atmospheres are messed up - the EVE enhancements are appearing also in a shell that seems to be a few thousand KM above the actual surface (and the end of the atmosphere). [i am using the OVERHAUL-8 release]
  4. you can make one easily if you want. You can make a copy of the part1 or part2 file in the turbojet/ folder, then in the new file change the name to ThermalTurbojet3, change the rescaleFactor to 3, and in the FNNozzleController module change the radius to 3.75
  5. No, this means that every second, the generator will [try to] convert 2000 ElectricCharge to 2 MJ.
  6. Yes. I had had it running using the TAC life support generator, but that only works with manned pods (hardcoded into its dll, it seems). The only reason I use the kethane generator module is that (as far as I know) the stock generator module will generate even if the target resource is full (it has a node that can define it to stop if the source resource is empty). Any other module that does that will work. I have it at 50000 as this is a blanket config. in my game, I use the models from nearfutures' capacitors with configs that increase the megajoule storage and rate of conversion for higher-tech parts in that. on second thought, the start amount might be better at 10 or something (with same big max) if you are worried about balance issues. I have two opposing independent generators (MJ to ec and ec to MJ) for this reason: I originally intended this to be a way to save extra e-c that I could release relatively quickly, mainly for probes. nearfutures' capacitor module has the issue that for a probe, if I am already out of electricity it is too late to discharge a capacitor. By having two opposing nodes I did the following: If both are enabled: - If ec is full and MJ is full, nothing happens (both gens do nothing, as target resource is full) - if ec is full and MJ is not full (and something is charging up the batteries to keep ec full) - then the excess ec goes to MJ - if ec is not full and MJ is full -then MJ drains into ec - if both are not full - then nothing happens (both gens run, but net change is 0) I can also enable only one or the other (use action groups, especially if you have many (but be careful on a probe - if you accidentally only have the 'to MJ' enabled and no sun you can drop out all your ec and go dead)) if I want to quickly dump into ec (say for an ion engine burn) (if both are enabled, then, probably due to a kethane quirk, the draining is much slower) or vice versa.
  7. that would be really nice, considering that the only current option is to awkwardly attach it to the body of the lander - or build it on-site with KAS (which is kind of difficult)
  8. I love this! Would a space-plane-compatible (i.e. aerodynamic) biodome be plausible? maybe such a thing could be achieved by having some kind of retractable nose-sheath for in-atmosphere flight.
  9. All Solar panels use that module - the non-deployable ones simply have that noted in thier configs. just make a text file in the gamedata directory and name it kspmod.cfg or something. paste @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]] { RESOURCE { name = Megajoules amount = 50000 maxAmount = 50000 } MODULE { name = KethaneConverter Label = Store MJ InputRates { ElectricCharge = 500 } OutputRates { Megajoules = .5 } } MODULE { name = KethaneConverter Label = Release MJ InputRates { Megajoules = .5 } OutputRates { ElectricCharge = 500 } } } into that file. module manager will then apply this to all solar panels
  10. For some reason, the tweakable size bar for all of the bases, except for the interstage fairing adapter, is not showing up. And that one is giving me a bar that only goes up to 1.15
  11. Thanks for the compliment! The posted module manager code will add this to any battery (and also to any other part that has electricCharge as a resource. To use this code to add this to all solar panels, replace the first line [the @PART[*]....] with: @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]
  12. I'm not sure - it might be. I has the same general feature- the final resource node of a part with 3 or more such nodes does not always fill.
  13. Yeah I first created, and mostly use this, as a backup battery for probes - as this way I can store a large amount of backup ec that will trickle out when needed. (in fact, i use the nearfuture parts, with the capacitor module he made replaced with my kethane-based node)
  14. I have noticed that some parts (such as Novapunch2's freyja and odin trunks) sometimes load with 0 electric charge (but with the normal maximum) and refuse to fill. In some cases (such as with the megajoule converter I posted above) electriccharge basically dissapears into this 'void' - and you end up with no electricity at all. I 'solved' this by deleting that resource node in the cfg. this may not be the issue here, but it is probably worth mentioning.
  15. Yeah, I didn't install any of the parts. I just wanted the converter module. The same solution works for any generator that will stop producing if the target resource has no free space left
  16. I think I posted my solution a while ago. The simplest solution is this modulemanager code (requires kethane modules): adds switcher to any part that stores electric charge but not megajoules (so it won't modify generators) @PART[*]:HAS[@RESOURCE[ElectricCharge],!RESOURCE[Megajoules]] { RESOURCE { name = Megajoules amount = 50000 maxAmount = 50000 } MODULE { name = KethaneConverter Label = Store MJ InputRates { ElectricCharge = 500 } OutputRates { Megajoules = .5 } } MODULE { name = KethaneConverter Label = Release MJ InputRates { Megajoules = .5 } OutputRates { ElectricCharge = 500 } } }
  17. Happens to me to, with other mods - I think this is a KSP-wide issue
  18. For myself, I made a module manager config for the Near Future Propulsion mod's capacitors - I remove the storedcharge resource, and instead they use the kethane converter to swap MegaJoules and electriccharge (using the 1:1000 exchange rate). I made the larger capacitors hold greater amounts of Megajoules and have faster rates of conversion. Since the kethane converter module auto-stops if the target resource is full, I simply add two kethane converters that convert at the same rate in opposite directions - as long as there is sufficient inflow of electriccharge, the excess goes straight into megajoules. The TAC converter also can do this, but it seems to only work if the ship has the whole tac module stuff going on, which seems to cause issues for probes.
  19. I really like 4 and 5. Ion engines, most likely. 4 happens to match the custom flag I made for myself
  20. I quicksaved while at A-Warp 2.0, then slammed into a planet while answering my phone. When I reloaded that quicksave, my orbital velocity remained fixed at the ludicrous speed that it reports when at A-warp speed, even after dropping out of warp. I ended up ediiting my save file to fix this, but I assume that some general fix could be worked out. I am posting here, rather than as a github error, in case it is already being worked on/not going to be worked on/something I missed (beyond "don't save while Awarping")
  21. I think that long-term considerations will come into play - presumably there will eventually be interstellar travel, with corresponding travel times (even with Alcubierre).
  22. Wait a second, a wild solution appeared!: The Fusion reactions should have byproducts! From Wikipedia: [A] D + D → He3 + n + 3.268 MeV D + D → T + H-1 [p (protium)] ('Normal' Hydrogen, this could be treated as LiquidFuel, assuming it is being treated as H2 (ok, so you need some electrons) + 4.032 MeV D + T → He4 (not useful for fusion, but is needed for that telescope cooling, so convenient source for the Gravitational Lense mission) + n + 17.571 MeV So: D-D Fusion produces Tritium, which is useful for D-T reactions, as well as for decay into He-3. It also produces some amount of He-3 directly. It also provides [some, did not do the math, presumably relatively small output compared to needs of most engines] of LiquidFuel which IS useful for the plasma thrusters, given their high ISP. It supplies noticeably less power. The ratio of occurrence of reaction [A] to is 1:1. D-T Fusion supplies the most power, but the products are not useful unless you are running a telescope. http://en.wikipedia.org/wiki/Fusion_power#Possible_Approaches D-He3 yields He-4 and H-1 (Helium Coolant and LiquidFuel) He3-He3 yields He-4 and 2 H-1 (ditto) it also yields about 2/3 the energy of D-He3
  23. It is trivial for anyone who wants to to add a modulemanager config to move the rtg to an earlier node
×
×
  • Create New...