Jump to content

damerell

Members
  • Content Count

    935
  • Joined

  • Last visited

Everything posted by damerell

  1. Oh, I didn't read it as criticism, just as a straightforward suggestion. While I'm here: Russian RITM-200 icebreaker power plant: 175MW/1100 tonnes = 160 W/kg. USI 0.625m nuclear power plant: 190 W/kg (@ 1EC = 1 kJ) USI 3.75m nuclear power plant: 180 W/kg. I guess I can leave those alone.
  2. I'm not sure if you mean "why are you writing rules for specific mods?" or "why are you writing generic rules which will edit any part with a given function, rather than explicitly naming stock parts for conversion?" The answer to the first question is I'm writing the mod I want to use; since I use Kerbal Foundries, ODFC, and Universal Storage (for example), I'm writing configuration to handle those parts. The order in which I'm doing things reflects what I'm trying to get done in my current game; I wrote the KSPWheel rebalancing bit before the ion engine bit because I'm building big rove
  3. I hit on a better approach; rewrite ion engines as multimodes, with "Accelerated" (realistic EC/s, unrealistic thrust) and "Realistic" (realistic EC/s and thrust) modes, with the default being "Accelerated" to minimise user surprise.
  4. Ah! That makes sense of oddballs like the Ranger Agricultural Module. Thanks.
  5. You're not wrong. It doesn't help that the most up-to-date documentation is in KSPedia... except some bug makes it not appear in KSPedia. Some of this may be wrong, but it reflects my best understanding. "Agronomics" makes Supplies from Mulch and Fertilizer. "Cultivate" is used to produce Supplies from Fertilizer, Water, and Substrate/Dirt. The (to me, rather niche) use case is if you want to produce excess Supplies above and beyond the available Mulch - perhaps because you are sending an expedition from your base that will not carry Agroponics. "Agriculture" makes Organics from
  6. I've posted a new version of the Module Manager config using some help from the MM thread, and which gives more realistic (high!) power requirements for Kerbal Foundries and stock wheels. However, I've run into the first real tangle. IRL, the NSTAR uses 2.1kW for 92 mN thrust. The KSP Dawn uses 8.74EC/s for 2kN thrust. If the thrust isn't adjusted, the electricity requirement will be enormous (ie, circa 40 _MW_), but if the thrust is adjusted, first of all I'm stepping outside my remit of just correcting EC usage and not worrying about parts like reaction wheels that do the impossible wit
  7. I don't wish to be the voice of cynicism (actually, I do) but if you examine their post history you will find the answer to that is almost certainly "no".
  8. I play with FAR, so this may not help with stock aero, but that looks far more convincing to me than those stubby little wings and tiny control surfaces. The other craft just looks very short of control authority.
  9. Gah, this is like being a LISP programmer. However, removing the extra square brackets doesn't make a difference. Sorry, I wrote that in a hurry. To be more clear: @PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]],!OUTPUT_RESOURCE:HAS[~name[ElectricCharge]]]:LAST[CAMREC] { does select an RTG that outputs LF.
  10. Aha, but I can do: @PART:HAS[@MODULE[ModuleGenerator]:HAS[@OUTPUT_RESOURCE:HAS[~name[ElectricCharge]]]]:LAST[CAMREC] { %tags ^= :$: CAMRECnotRTG: } @PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]],~tags[*CAMRECnotRTG*]]:LAST[CAMREC] { @description ^= :$: CAMREC RTG buff.: @MODULE[ModuleGenerator] { @OUTPUT_RESOURCE[ElectricCharge] { @rate *= 3 } } } and that _does_ cut out the modified RTG that makes LF. Thanks.
  11. Now I have @PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]],!OUTPUT_RESOURCE:[HAS[~name[ElectricCharge]]]]:LAST[CAMREC] { Unfortunately, this still selects the RTG that also outputs LF. (Is there a way to test for the number of output resources, please? That would fix all my problems.) @PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]],@INPUT_RESOURCE:HAS[#ResourceName[Oxidizer]],@OUTPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]],!OUTPUT_RESOURCE:HAS[~ResourceName[ElectricCha
  12. KSP 1.9.1, installed only Hangar, SmartParts, and their dependencies (AT Utils, MM, CRP, KSP AVC) via CKAN. If I put down a Box Fairing in the VAB and right-click it, "Edit Contents" doesn't appear, and there's no Hangar button on the toolbar. http://www.chiark.greenend.org.uk/~damerell/games/ksp/hangar/ has the logs. "Cannot find a PartModule of typename 'Hangar'" and "Cannot find a PartModule of typename 'SimpleHangarStorage'" seem curious. (The AT Utils install at the very least looks just like the one I have in a non-clean install where it _does_ work). Anything else you nee
  13. I am taking my first steps into the world of ModuleManager. I wrote the following line to try and identify RTGs: @PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,!OUTPUT_RESOURCE[~ElectricCharge],@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]]]:LAST[CAMREC] { This edits RTGs... but, however, if I temporarily make the RTG generate LF out of nowhere as well as EC, it becomes clear the bit I expected to rule out any part with an output resource that's not EC doesn't work. Then I went for fuel cells: @PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS
  14. I had the time to have a crack at this tonight, and wrote the wall of text below while writing a ModuleManager file; this takes care of my most immediate need, launching comsats in my current game with plausible solar / RTG performance. (But no; there's actually a problem with dish performance. A RemoteTech Reflectron GX-128 pulls 2.8 EC/s just to tick over; stock antennae want between 20 and 200 EC/s to transmit data. If these are kW, this looks odd in view of the way that, say, Voyager 1's RTGs only put out 470W at launch and we can still talk to it now. RemoteTech's root range model do
  15. With this, Squad's shielded docking ports can be opened and attached to in the VAB/SPH. Hooray! https://github.com/SuicidalInsanity/Mk2Expansion/blob/master/Mk2Expansion/GameData/Mk2Expansion/Parts/Utility/DockingPort/part.cfg can't. It's not obvious to me why not, so I was wondering if anyone can shed any light on that. It would be very useful to modify this in order that TweakableEverything can let me attach to it in the VAB.
  16. Just updated, and Player.log is _full_ of: "PWBFuelBalancer.ModulePWBFuelBalancer: FixedUpdate, ActualCoMMarker: False, ActualCoMMarkerVisible: False (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)" Full as in, 40 minutes after starting the game, "grep PWB Player.log |wc" reported 400,000 lines. I found this especially surprising since the one craft used during that time didn't have the part fitted. I've replaced it with one with the part and turned it on. I now have 1,500,000 lines matching "grep PWB" after the few minutes it took me to wri
  17. Sorry. Sometimes I'm not quite sure if the person I reported a bug to knows fine it's still there and I'll just be pestering them, or if they're cursing my inability to supply any more facts. However, I'm pleased to report it works exactly as I expected now with v1.10.1.50, both in an otherwise bare KSP 1.10 install and in a modded 1.9 install.
  18. That seems completely extraordinary. We have no evidence whatsoever of causality violation - and, while this is a slightly pat argument, if _is_ possible, it's not just that it hasn't been done _yet_. To suppose it is possible for the sake of not recognising FTL is impossible is not sensible. If any leg of that triangle is going to give, I'd go for relativity, which does at least have a few problems around the edges like all this spooky dark matter whizzing about. The oddball theories that actually galaxies stick together because things are slightly different at very long distances are pl
  19. Er - relativity, causality, FTL, pick two; doesn't matter how the FTL supposedly works.. The Alcubierre "Drive" is very definitely "physics-breaking"; it is an interesting mathematical model of something impossible.
  20. I notice the medium landing gear is heavier than the heavy landing gear. I wonder if their weights were inadvertently exchanged?
  21. I'm not sure I understand you. What I think is odd is that "lossless physics warp" doesn't mean what I (or metalbass) would expect it to mean. I would expect that to be fixed by renaming it to better describe its function. (That said, I don't see _why_ a mod can't do what I'd like - to be lossless up to the highest possible time acceleration, then decline to accelerate time further - especially since that's what TimeControl does so manifestly it's possible.) BTW, I think this discussion has been confused by the way there's basically no documentation of "max physics delta time per fra
  22. I was just thinking I'd find this useful.
  23. I read this, and while I didn't understand the removed bits, I would expect that "lossless physics warp" would not change the behaviour of the vessel, and so _if_ you had excess CPU to run the vessel normally, you could have KSP time pass faster than IRL time without odd effects. I think some confusion arose because the two GIFs on the front page show different behaviour... but actually, this is expected because one of them is "stock physics warp" and one of them is "lossless physics warp". You would expect these to be different; the thing you'd expect to be like "lossless" is "no physics
  24. Uh, we seem to be missing any context here. Suggested for what?
×
×
  • Create New...