Jump to content

Nertea

KSP2 Alumni
  • Posts

    4,858
  • Joined

  • Last visited

Everything posted by Nertea

  1. Official update. Marked for KSP 1.2.2 Added Exotic Solar Technology
  2. For one thing, ditch your Alternator and ModuleActiveRadiator blocks. The first is harmless but you don't need it, the goal of FissionGenerator is to replace that. The additional ModuleActiveRadiator will make things problematic (use the PassiveCooling field of FissionFlowRadiator to simulate an integrated radiator).
  3. Considering how in flux this patch is, there is no documentation to use (I would rather people not base stuff off it too much because it'll break). However, I'll try to help. What overheats - the core or the engine?
  4. Finally have some time to work on things. I am looking for a way to re-incorporate the heat exchangers from the old version of HC, and I think I have a solution I like. They will act like radiators in that they will move heat with the use of EC, but not have high emissivity and will have a high thermal mass. So you can use them to pump heat (probably non-core for now) to a specific location on a vessel, either for storage or to then use local static radiators to dump the heat.
  5. I can't reproduce this. I placed a NTR on the pad, turned on the reactor and engine, then played with various throttle items. Power setting adjusted core lifetime when the throttle was zeroed as expected, and when the throttle was taking over the throttle adjusted core lifetime. Some examples: Throttle 0, Power 50: Lifetime 200% of normal Throttle 100, Power 50: Lifetime 100% of normal Throttle 25, Power 50: Lifetime 200% of normal Throttle 75, Power 25: Lifetime 150% of normal I did manage to reproduce this, I'll be looking into it.
  6. Occupational hazard of ingesting user-provided patches I guess. Logged. That should work. Known issue, won't have any effect on the game.
  7. Eh, no idea what's wrong then. It looked like it was fixed based on other poster's evaluation and my evaluation of the length of the arrows.
  8. Did you rebuild your craft? The nodes will have changed, so you will have to disconnect everything from the bay and reconnect everything.
  9. I typically find these overheating problems really hard to reproduce. But this change is fixing persistent bug that's been around since at least v2.0, so it might help.
  10. There's literally dozens of posts in this thread talking about this. from one page ago there's this: There's also already a mk2 tank. The fuel switcher should apply the patch to the stock LFO ones by default.
  11. *shrugs* I've been puttering along, slowly improving this patch for months (it's a highly optional, highly WIP product - note that it isn't mentioned in the OP, has a big EXPERIMENTAL flag in the readme). I'm just a little miffed that the first I learn about... let's call it "strong user dissatisfaction" is from poking about in someone else's thread and seeing misinformation about my mod being "fundamentally broken". Disheartening, for sure. And yes, it gets highly complex quickly. What I have learned while writing these mods is that people will always create an approximation of the most complex situation, very quickly. Even a very simple system with two reactors on a ship results in problems (look a page or two ago to see the unexpected interactions in the highly limited auto-throttling that is currently implemented). Also... auto throttling is a weird kettle of fish. What do you auto-throttle? If you link reactor throttle to effective cooling, you create situations where the engine is operating at low performance while the reactor warms up, which creates a direct waste of propellant (low performance = low Isp). If you make the opposite binding, then you get another strange situation where the user has low control over the engine itself (propellant flow is then controlled by heat, which has inertia and nonlinear increases). Essentially there are two throttles to manage, a performance throttle and a propellant flow throttle, and without creating great complexity or creating strong performance penalties for automation, the human mind seems far better suited to optimizing this. If you can think of a nice algorithm that hits 95% of the edge cases, I'm all for it.
  12. *Resigns form modding ever again* Goddamnit. As of the last CryoTanks update though that won't actually cause any problems beyond the EC use in the VAB info box being incorrect. It will be fine on the ship.
  13. I wasn't able to reproduce the problem despite following your methods. I rexported the collider, don't know if that'll do anything though. Let me know. MkIV 2.3.3: This should fix a few things, plus add an oft-requested feature - the larger tanks should get Cryo LH2/LH2O versions when CryoTanks is installed. Fixed problems with Heavy RCS Blister thrust vectors Fixed cargo bay module occluding the wrong nodes for all regular/ventral bays Added patch to add cryogenic LH2 and LH2/O fuel storage modes to certain parts (fuselages, tails and adapters) if CryoTanks is installed.
  14. Oh god, SEVERE? We're doomed. There's no efficient analytical way to do this. There are too many edge cases when you start to factor in multiple reactors, you end up needing to create a vessel-wide prioritization and distribution logic (aka, KSPI, and the associated problems). If you do it non-analytically, you run into a considerable number of issues with timewarp. Log of the event is required for any meaningful debug. I've never, ever seen this! I'll look into the other things you mention.
  15. The crew cabin doesn't have nodes like that and I don't see any issues, really. More info is needed: Does this occur when the other aviation fuel tanks are used? Does this occur when the part is not intersecting with the wing? Does this occur when the part is intersecting with a non-procedural wing? Does this behaviour occur when a near-identical, but stock part (jumbo-64) is intersecting with a Pwing?
  16. Can you expand on this please? Or potentially notify me of these "bugged beyond belief" things?
  17. Ok that's good to know.. basically the cargo bay automatically occludes the nodes inside it. However, the outer nodes were misconfigured. This meant that when you attached things to the bay, they were using the inner nodes, and the outer nodes were always unused and unconcluded. It's an easy fix luckily. I'll do a patch tomorrow.
  18. I do see a bug in that picture (the turbo exhaust shouldn't show a gauge), but it's pretty hard to tell whether there is anything wrong. The engine intentionally produces a lot of heat. It should produce less when NFElectrical is patched in... hmm. There might be a problem there. There's technically 2 "engines" on that part and the patch that reduces the heating might not be targeting the right one. I'll look into that.
  19. If any of you are comfortable looking at cfgs, please help me test a fix... I'm not so good at aero things so I don't know what is normal. Replace the similar block in mk4cargo-1.cfg with this one: // --- node definitions --- node_stack_top = 0.0, 5, 0.00, 0.0, 1.0, 0.0, 4 node_stack_bottom = 0.0, -5, 0.00, 0.0, -1.0, 0.0, 4 node_stack_top2 = 0.0, 5, 0.0, 0.0, -1.0, 0.0, 2 node_stack_bottom2 = 0.0, -5, 0.0, 0.0, 1.0, 0.0, 2 node_attach = 0.0, 0.0, 1.6576, 0.0, 0.0, -1.0, 4
  20. Here's version 0.3.3 Marked for KSP 1.2.1 Updated bundled MM to 2.7.4 Updated bundled CRP to 0.6.3 Fixed missing CTT patch for Emancipator engine Increased thermal mass and explosion heat maximum of Emancipator engine KPBS ISRU now produces LH2 (thanks Wyzard256)
  21. Here's version 0.4.3 Marked for KSP 1.2.1 Updated MM to 2.7.4 Updated CRP to 0.6.3 KPBS ISRU now produces LH2 (thanks Wyzard256)
  22. MKIV 2.3.2 released Marked for KSP 1.2.1 Updated CRP to 0.6.3 Updated MM to 2.7.4 Cabin lights are now tied to the Lights action group Increased collection distance for EVA science for both cockpits @DrunkenKerbalnaut: It has a plan!
×
×
  • Create New...