Nertea

[1.7.x] Kerbal Atomics: fancy nuclear engines! (May 29)

Recommended Posts

3 hours ago, Nightside said:

Cryo cooling on the tanks?

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

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Nertea

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites
Posted (edited)
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 by GregroxMun

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Nertea

Share this post


Link to post
Share on other sites
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. 

:o

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?

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by GregroxMun

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 :P

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 by Streetwind

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites
Posted (edited)

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

58754402-0e2eac00-8484-11e9-85c0-30b9dbf

But maybe I went a little overboard!

 

58754637-abd8aa00-8489-11e9-8da5-4e45a02

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.

58777962-8630cb00-8585-11e9-8192-2a70d09

 

Edited by Nightside
Finished patch added pic

Share this post


Link to post
Share on other sites

Looks like a solid improvement. Merged your PR. 

Share this post


Link to post
Share on other sites
Posted (edited)

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 by KSPrynk

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.