[1.12.x] Kerbal Atomics: fancy nuclear engines! (January 22, 2022)

[Whirligig Girl]

3 hours ago, Nightside said:

Cryo cooling on the tanks?

that might be it, yeah. Still wondering about the radiators though.

[Nertea]

I'm on a business trip now so I can't say much, but do you have 3GW of radiators, because as I recall the thermal output of the Emancipator is the ballpark of 1.5 GW? Picture kinda looks like no, I think the big square ones are 2MW so you need about 100...

Edited May 17, 2019 by Nertea

[captinjoehenry]

@GregroxMun I would recommend getting KSPI.  I don't use much from it other than the radiators and with a good portion of the tech tree done 4 skin 2.5m radaitors can handle the Emancipator no problem

[Whirligig Girl]

11 hours ago, captinjoehenry said:

@GregroxMun I would recommend getting KSPI.  I don't use much from it other than the radiators and with a good portion of the tech tree done 4 skin 2.5m radaitors can handle the Emancipator no problem

KSPI is far too large and extensive for me, when combined with the Near Future suite.

Edited May 17, 2019 by GregroxMun

[Nertea]

On 5/15/2019 at 2:22 PM, toric5 said:

Ill try. I could remove the multi-mode restriction, but I think there are some possible edge cases where it could affect non-nuke engines. (I think. It might be safe...)

 

Also, when did the LV-N get the patch to become a liquid fuel-LH2 hybrid? that patch needs to be applied after the dynamic NTR patch, so something like :FOR[zzzKerbalAtomics].

 

Ill pull request when I have something.

No, don't modify the universal patch. Suggest stats for a non dynamic patch - it's controlled by me so it should be balanced specifically.

LVN has been multi patched for a while now - the order of the patch is fine, because it contains !MODULE[MultiModeEngine], which naturally means the dynamic patch won't touch it, as the dynamic patch is still :FOR[zzLH2NTR], which will run considerably after FOR:zKerbalAtomics.

@GregroxMun, I see 20x square radiators (2 MW) and 4x triangular radiators (1 MW) for a total of 44 MW of cooling power. I confirmed that the Emancipator requires 1.125 GW per reactor so you are way, way below the the threshold to idle the reactor at full power. You should be able to run the reactor at about 2% there. 

[Nertea]

Also, KSPI... completely modifies how these things work in terms of balance and functionality. Warranty is totally void in that case, because the reactor is now a KSPI nuclear engine plugged into KSPI's heat system. Anything I say will no longer be at all relevant.

Edited May 17, 2019 by Nertea

[Whirligig Girl]

3 minutes ago, Nertea said:

No, don't modify the universal patch. Suggest stats for a non dynamic patch - it's controlled by me so it should be balanced specifically.

LVN has been multi patched for a while now - the order of the patch is fine, because it contains !MODULE[MultiModeEngine], which naturally means the dynamic patch won't touch it, as the dynamic patch is still :FOR[zzLH2NTR], which will run considerably after FOR:zKerbalAtomics.

@GregroxMun, I see 20x square radiators (2 MW) and 4x triangular radiators (1 MW) for a total of 44 MW of cooling power. I confirmed that the Emancipator requires 1.125 GW per reactor so you are way, way below the the threshold to idle the reactor at full power. You should be able to run the reactor at about 2% there. 

Thanks for the response.

Couldn't bump up the power of the reactor by an extra 0.085 jigawatts?

But seriously, I could have sworn I got the numbers right, looks like I misremembered how many orders of magnitude difference between a gigawatt and a megawatt, never double-checked it. I do feel pretty silly about now. I can't imagine having enough radiators to run the reactor with available parts. I only used the NFE integration to be able to refuel the engine's supply of enriched uranium. It's a real hassle to have to turn on and off the reactor every time I want to fire the engines, especially if I were to want to do something like a landing, with lots of on-and-off with some times when I'm not burning that the reactor could overheat.

Is it possible to either make it so that the reactor is on only when the engine is, or more simply, is there a setting that would allow me to refuel the Emancipator in non-NFE mode?

[Nertea]

10 minutes ago, GregroxMun said:

Is it possible to either make it so that the reactor is on only when the engine is, or more simply, is there a setting that would allow me to refuel the Emancipator in non-NFE mode?

It's a balance decision. You're describing a process by which you are trying to get around a set of constraints I put on the engine to make it... not the best choice in every situation (as it has pretty crazy stats and would be in most cases). You can do what you want with it but it requires careful engineering.

• In basic mode with no integration, the cheat engine is not refuelable, but fully throttleable
• In enhanced mode, you need to deal with handling the idle heat load. You can
  1. Put enough radiators to handle full power (not realistic with this engine)
  2. Put enough radiators to handler lower power and run the reactor at that power level, relying on the auto-ramp power level w/throttle to get to full power
  3. Be careful with the throttle and on/off state and hope/pray

A better solution is to use a less complex engine for anything that needs precision at that level.

 

[123nick]

when used with KSP-IE, will this mod have module manager compatibility with the KSP-IE set up of nuclear engine, which is a part with both a "reactor" part module and a "thermal nozzle" part module? iirc, the KSP-IE system is in depth enough too manage the various types of nuclear engines in this mod, and can handle things such as a wide variety of fuels (most liquids run) and various reactor fuels. im not saying your modelling of nuclear engines is inferior, but having all nuclear engines in my game run the same way would be nice, is all. 

[Nightside]

23 minutes ago, 123nick said:

when used with KSP-IE, will this mod have module manager compatibility with the KSP-IE set up of nuclear engine, which is a part with both a "reactor" part module and a "thermal nozzle" part module? iirc, the KSP-IE system is in depth enough too manage the various types of nuclear engines in this mod, and can handle things such as a wide variety of fuels (most liquids run) and various reactor fuels. im not saying your modelling of nuclear engines is inferior, but having all nuclear engines in my game run the same way would be nice, is all. 

See nertea’s statement just a few posts up.

Interstellar just uses these awesome models for its own parts (can’t blame them, I remix them a bit in my own game), but any issues can only be addressed in the interstellar thread.

[123nick]

1 minute ago, Nightside said:

See nertea’s statement just a few posts up.

Interstellar just uses these awesome models for its own parts (can’t blame them, I remix them a bit in my own game), but any issues can only be addressed in the interstellar thread.

ah, ok. thanks, id assume id just use the part that comes with the KSP-IE installation instead? i mean, having kerbal atomics and KSP-IE seems to give you an overabundance of nuclear engines anyways, so i guess ill just use whatever works

[captinjoehenry]

@123nick I don't know about the details but the NFT engines seem to have same stats as normal when running with KSPIE.  But KSPIE adds such massively strong radiators that it becomes sort of trivial to cool these engines.

[Whirligig Girl]

4 hours ago, Nertea said:

It's a balance decision. You're describing a process by which you are trying to get around a set of constraints I put on the engine to make it... not the best choice in every situation (as it has pretty crazy stats and would be in most cases). You can do what you want with it but it requires careful engineering.

• In basic mode with no integration, the cheat engine is not refuelable, but fully throttleable
• In enhanced mode, you need to deal with handling the idle heat load. You can
  1. Put enough radiators to handle full power (not realistic with this engine)
  2. Put enough radiators to handler lower power and run the reactor at that power level, relying on the auto-ramp power level w/throttle to get to full power
  3. Be careful with the throttle and on/off state and hope/pray

A better solution is to use a less complex engine for anything that needs precision at that level.

 

Acknowledged. I understand the goal of not wanting to make a cheaty uberengine, although for my own personal headcanon I think the variation I'm imagining is warranted for the tech level of my sandbox space program. I will probably do options 2 and 3. Thanks.

Edited May 17, 2019 by GregroxMun

[toric5]

5 hours ago, Nertea said:

No, don't modify the universal patch. Suggest stats for a non dynamic patch - it's controlled by me so it should be balanced specifically.

LVN has been multi patched for a while now - the order of the patch is fine, because it contains !MODULE[MultiModeEngine], which naturally means the dynamic patch won't touch it, as the dynamic patch is still :FOR[zzLH2NTR], which will run considerably after FOR:zKerbalAtomics.

Manual patch it is. However, I am completely clueless when it comes to balancing. Ill probably compromise between what the dynamic patch would do and the HL2/Ox patch for the NF areo jets. @Streetwind, anything I should be aware of? I don't have much experience with balancing.

 

as for the multi patch, that is completely my bad. I was testing removing the multi-mode restriction, and the comments in the config reference the dynamic patch in a couple of places. I should have tested on a clean install first.

[Streetwind]

10 hours ago, toric5 said:

Manual patch it is. However, I am completely clueless when it comes to balancing. Ill probably compromise between what the dynamic patch would do and the HL2/Ox patch for the NF areo jets. @Streetwind, anything I should be aware of? I don't have much experience with balancing.

I must admit to not using this mod, I'm afraid. Generally I use chemical propulsion or electric, and that covers my needs, so even in those games where I did install Kerbal Atomics, I sort of... never got around to actually making crafts with it. Bit of a shame because the models and effects are so gorgeous... but then again, so are the models and effects of NF Propulsion

Generally when balancing, consider the following questions:

• When I give this engine a capability it did not have before, does it suddenly start to fit a niche that already includes other engines? If so: are my stats in line with those other engines? After I apply my patch, is there still a reason to use those other engines over the one I just patched? Is there even a rational need to put another engine into this niche?
• When I give this engine a capability it did not have before, does it suddenly start to be able to do something that no other engine can do? If so, do I break intentional core gameplay restrictions? How does this alter the progression? Does this enable me to earn more funds and science than I should normally be expected to have at this stage of the game? Does it enable previously unachievable payload fractions to orbit? Is the engine I just made only good in that specific niche, or does it contest the usefulness of other engines? Even indirectly (i.e. a new way of doing something makes an old way look inefficient/cumbersome by comparison).
• Where is this engine in the tech tree (stock and CTT)? Should an engine at this point in the progression actually be able to have this capability/power that I want to give it? Does it remain a smooth step up from previous tech nodes, and are the next nodes forward still better in the same smooth progression?
• Should there be mitigating factors, for example unlock and buy price increases, moving to a different tech node, nerfing other stats in return for buffing some?
• Does it fit with the theme and feel of KSP, and the theme and feel of the part set I am tweaking?

For example, in regards to point 2: an intentional core gameplay limitation is that all engines require propellant, or that speed inside an atmosphere is strictly limited to remain well below Kerbin's orbital speed. Introducing things like an electricity-driven propeller or a mach 10 capable scramjet breaks these core gameplay limitations, and therefore need to be very carefully considered. That doesn't mean "don't ever do this", that means "think about what you're doing and whether this is really a useful addition and not a liability in disguise of looking cool at first glance". Mitigating factors can lessen the impact of such a change, for example the fact that electric propellers are only really useful for subsonic flight or hovering. In other cases, changes can make sense in the context of other mods, even if they don't make sense in stock. For example, to someone using Real Solar System or another big planet resizer, having a mach 10 capable scramjet doesn't actually break the limitation that you cannot reach orbital speed inside you home planet's atmosphere.

 

Edited May 18, 2019 by Streetwind

[toric5]

On 5/17/2019 at 11:08 AM, Nertea said:

No, don't modify the universal patch. Suggest stats for a non dynamic patch - it's controlled by me so it should be balanced specifically.

 

Ok, I think an ISP buff should be all it needs to balance with LH2s lower density. However, I did notice that in closed cycle mode, Project Eeloo has a TWR of 5.5, the best solid core NTR save for the Scylla. Just checking to see if this is intentional.

 

Also, the stubber says it is supposed to be a high thrust engine, and yet it barely outperforms the Posiden in TWR, (3.3 vs 3 in LH2 only, 8.4 vs 7.5 with oxidizer.) (comparing it to the Neptune isn't much better.) However, its TWR is 275 seconds lower than other solid cores. Again, just checking to see if it is intentional, as  the only advantage I can see is landing leg length.

[Nertea]

On 5/18/2019 at 9:50 PM, toric5 said:

 

Ok, I think an ISP buff should be all it needs to balance with LH2s lower density. However, I did notice that in closed cycle mode, Project Eeloo has a TWR of 5.5, the best solid core NTR save for the Scylla. Just checking to see if this is intentional.

 

Also, the stubber says it is supposed to be a high thrust engine, and yet it barely outperforms the Posiden in TWR, (3.3 vs 3 in LH2 only, 8.4 vs 7.5 with oxidizer.) (comparing it to the Neptune isn't much better.) However, its TWR is 275 seconds lower than other solid cores. Again, just checking to see if it is intentional, as  the only advantage I can see is landing leg length.

Uh I am not sure really.

The high TWR for Eeloo is intended as it has a pretty big chunk of efficiency loss.

The Stubber might use a bit of looking at, but it does have two advantages you have missed - significantly better atmospheric performance and overall lower mass, which leads to better mass fractions for smaller ships:

	Stubber	Neptune
TWR (atm)	1.54	0.59
TWR (vac)	3.39	2.96
Isp (vac)	750	950
Cost	17000	19000
Mass	1.8	2.3

 

 

[toric5]

4 hours ago, Nertea said:

Uh I am not sure really.

The high TWR for Eeloo is intended as it has a pretty big chunk of efficiency loss.

The Stubber might use a bit of looking at, but it does have two advantages you have missed - significantly better atmospheric performance and overall lower mass, which leads to better mass fractions for smaller ships:

	Stubber	Neptune
TWR (atm)	1.54	0.59
TWR (vac)	3.39	2.96
Isp (vac)	750	950
Cost	17000	19000
Mass	1.8	2.3

 

 

I completely missed the atmospheric TWR...

 

Anyways, PR incoming.

[Nertea]

Rolling out Kerbal Atomics 1.0.2 (and CryoTanks 1.1.3)

• Updated bundled B9PartSwitch to 2.7.1
• Updated CryoTanks to 1.1.3
  • Better Russian localization (Sool3)
  • Improvements to fuel tank switcher from @Zorg
• Updates to Russian localization (Sool3)
• Increased thrust of Stubber to 80 from 60 kN in LH2 mode, and to 180 from 152.5 kN in LH2/O mode
• Updates to LH2 NTR support extra: Project Eeloo engine now uses LH2 in closed cycle mode (toric5)

[Nightside]

Trying to make some Engine Light configs that reflect the awesome pink power of energetic hydrogen...

But maybe I went a little overboard!

 

That's looking a bit better!

Edit: OK I toned down the intensity a bit and and made it more of a bluish-pink instead of that hot magenta to better match the plumes. I put up a pull request on Github in case @Nertea wants to include compatibility.

 

Edited June 3, 2019 by Nightside
Finished patch added pic

[Nertea]

Looks like a solid improvement. Merged your PR. 

[KSPrynk]

I've found a couple of Exception Errors that seem to be a combination of Missing History (v1.7.3), Kerbal Atomics (v1.0.2) and the associated KerbalAtomicsLH2NTRModSupport extra, and Real Plume-Stock (v1.3.1).  I think the MH LH2NTR patch in KA is the culprit.

- I can run MH with Real Plume without any errors.

- I can run MH with RP and KA without the LH2NTR patch without errors (I figured this would be the same as above).

- I can run MH with KA and the KA LH2NTR patch without errors.

It seems to be when the LH2 patch for MH goes to RP that it throws the errors.  The error message on the loading screen is "2 errors related to GameData/KerbalAtomicsLH2NTRNModSupport/hydrogenNTRsMissingHistory.cfg"

I'm using KSP 1.7.1 x64 with MM 4.0.2.  I tried the above on a fresh install with just the three mods listed. The engines and the associated RP new plumes seem to run fine, so I'm not sure what the Exception is about.

EDIT: I've added a GitHub Issue in the KA repository.

Edited June 9, 2019 by KSPrynk

[Nertea]

On 6/9/2019 at 7:24 AM, KSPrynk said:

I've found a couple of Exception Errors that seem to be a combination of Missing History (v1.7.3), Kerbal Atomics (v1.0.2) and the associated KerbalAtomicsLH2NTRModSupport extra, and Real Plume-Stock (v1.3.1).  I think the MH LH2NTR patch in KA is the culprit.

- I can run MH with Real Plume without any errors.

- I can run MH with RP and KA without the LH2NTR patch without errors (I figured this would be the same as above).

- I can run MH with KA and the KA LH2NTR patch without errors.

It seems to be when the LH2 patch for MH goes to RP that it throws the errors.  The error message on the loading screen is "2 errors related to GameData/KerbalAtomicsLH2NTRNModSupport/hydrogenNTRsMissingHistory.cfg"

I'm using KSP 1.7.1 x64 with MM 4.0.2.  I tried the above on a fresh install with just the three mods listed. The engines and the associated RP new plumes seem to run fine, so I'm not sure what the Exception is about.

EDIT: I've added a GitHub Issue in the KA repository.

This is not unexpected. The order is going to be something like:

1. MiH adds new engines
2. RP does stuff to new MiH engines
3. KA tries to do stuff to MiH engines but is based on the non-RP configs so may throw an error.

In this case you'd expect some kind of issue. If everything is still working, I'm not highly motivated to look into it. Someone else (can't remember who) wrote the MiH engine configs and I'd prefer they look into it, the patch is not written the way I would have done it and I would guess there is probably a reason. 

[Eridan]

3 hours ago, Nertea said:

This is not unexpected. The order is going to be something like:

1. MiH adds new engines
2. RP does stuff to new MiH engines
3. KA tries to do stuff to MiH engines but is based on the non-RP configs so may throw an error.

In this case you'd expect some kind of issue. If everything is still working, I'm not highly motivated to look into it. Someone else (can't remember who) wrote the MiH engine configs and I'd prefer they look into it, the patch is not written the way I would have done it and I would guess there is probably a reason. 

Good day! I haven't updated the patch ever since I submitted it circa 1.6. KA, RP, and Missing History all have changed significantly since then. I've been using a different config for awhile now. I can submit a more permanent solution by Thursday if it's alright with you.

[Nertea]

40 minutes ago, Eridan said:

Good day! I haven't updated the patch ever since I submitted it circa 1.6. KA, RP, and Missing History all have changed significantly since then. I've been using a different config for awhile now. I can submit a more permanent solution by Thursday if it's alright with you.

Yes that would be great. I looked at the file and one change we should make is to move the NFE integration parts to the Extras location - same with the RTG integration.