Jump to content

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


Nertea

Recommended Posts

7 hours ago, Zorg said:

Most likely the culprit is rational resources. The version of RR bundled with JNSQ is quite out of date and it has some clashes with a few mods. JNSQ hasnt had a new release since then but you can grab the updated Rational Resources separately from here. Most of these issues have been resolved in the updated RR.

https://github.com/JadeOfMaar/RationalResources/releases

The problem with Kerbal Atomics was because RR patches the NERV with a CO2 mode which clashes with KA LH2 mode. The CO2 mode has been removed in Rational Resources now.

 

I did indeed have an older version of RR.

Updating that, and installing kerbal atomics again, renders me this message upon game launch:

O1q9yH4.png'

 

Do I have wrong version of partswitcher, or lacking some extras from kerbal atomics? Tricky stuff :)

 

Also, relevant log section, I think:

Spoiler

[ERR 18:19:17.479] Module ModuleB9PartSwitch threw during OnLoad: System.Exception: Fatal exception while loading fields on module ModuleB9PartSwitch on part  ---> System.Exception: Exception while loading field subtypes on type B9PartSwitch.ModuleB9PartSwitch ---> System.Exception: Exception while loading fields on subtype PartSubtype LHE3 ---> System.Exception: Exception while loading field tankType on type B9PartSwitch.PartSubtype ---> System.Collections.Generic.KeyNotFoundException: No tank type named 'RR_CryoHe3' exists
  at B9PartSwitch.B9TankSettings.GetTankType (System.String name) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.TankTypeValueParser.Parse (System.String value) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.NodeDataMappers.ValueScalarMapper.Load (System.Object& fieldValue, .ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.NodeDataField.Load (.ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.NodeDataList.Load (.ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at B9PartSwitch.Fishbones.NodeDataList.Load (.ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, .ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.PartSubtype.Load (.ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at B9PartSwitch.PartSubtype.Load (.ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.Parsers.NodeObjectWrapperIContextualNode.Load (System.Object& obj, .ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.NodeDataMappers.NodeListMapper.Load (System.Object& fieldValue, .ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.NodeDataField.Load (.ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.NodeDataList.Load (.ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at B9PartSwitch.Fishbones.NodeDataList.Load (.ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, .ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <filename unknown>:0 
  at B9PartSwitch.CustomPartModule.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at B9PartSwitch.CustomPartModule.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 

 

 

Edited by TackleMcClean
added log part
Link to comment
Share on other sites

Just now, TackleMcClean said:

I did indeed have an older version of RR.

Updating that, and installing kerbal atomics again, renders me this message upon game launch:

O1q9yH4.png'

 

Do I have wrong version of partswitcher, or lacking some extras from kerbal atomics? Tricky stuff :)

Hmm, I would follow up with Jade on the Rational Resources thread since the above is now not related to Kerbal Atomics. Although before you do that make sure you have the latest B9 partswitch and see if you get the same errors. I have RR 0.9.1 and am not getting that. Also make sure you are deleting RR and copying in the new one clean instead of just overwriting.

 

Link to comment
Share on other sites

@Nertea, @Wyzard, I'm getting an exception error for hydrogenNTRsMissingHistory.cfg in the KA LH2NTR Mod Spt extra, using the new RealPlumeStock 1.5.  I'm guessing this is related to the previous issue from June/July regarding the LH2NTR patch pointing to obsolete RealPlume code, and Wyzard's work-around fix.  As far as I can tell, the new plume FX are working properly on the MH part (KANDL in this case*).

BTW, I've only started checking out the NTRs, but the new plume FX are beautiful.  Can't wait to see how all the combustion engines and electric thrusters came out....

*EDIT: I normally remove the BKN NTR Lightbulb, but after a clean install of MH, I get two exceptions, I'm assuming one for each.

Edited by KSPrynk
Link to comment
Share on other sites

10 minutes ago, KSPrynk said:

@Nertea, @Wyzard, I'm getting an exception error for hydrogenNTRsMissingHistory.cfg in the KA LH2NTR Mod Spt extra, using the new RealPlumeStock 1.5.  I'm guessing this is related to the previous issue from June/July regarding the LH2NTR patch pointing to obsolete RealPlume code, and Wyzard's work-around fix.  As far as I can tell, the new plume FX are working properly on the MH part (KANDL in this case).

BTW, I've only started checking out the NTRs, but the new plume FX are beautiful.  Can't wait to see how all the combustion engines and electric thrusters came out....

Hmm I took a look at the previous issue and I dont think I've quite gotten my head around it yet. @Wyzard if theres a way to resolve this in a simpler way on the RealPlume-stock side let me know. If you're updating the previous workaround do note that there are new Nuclear plumes being applied and that workaround needs to be updated accordingly.

Link to comment
Share on other sites

8 hours ago, KSPrynk said:

@Nertea, @Wyzard, I'm getting an exception error for hydrogenNTRsMissingHistory.cfg in the KA LH2NTR Mod Spt extra, using the new RealPlumeStock 1.5.  I'm guessing this is related to the previous issue from June/July regarding the LH2NTR patch pointing to obsolete RealPlume code, and Wyzard's work-around fix.

Yep, the RealPlume update changed the effect names so the LH2NTR patch was once again trying to copy from effect nodes that didn't exist.  I've submitted pull request #79 to update the patch with the new names.

8 hours ago, Zorg said:

@Wyzard if theres a way to resolve this in a simpler way on the RealPlume-stock side let me know.

Ideally the LH2NTR patch should run first and change the engines to multi-mode, and then RealPlume should see that the engine is multi-mode and apply a different version of its plume patch.  That'd be the most elegant way for it to work, and it'd also make it possible for the two engine modes to get different plumes (one for LF, one for LH2).

Currently, though, the LH2NTR patch runs after RealPlume (it's at :BEFORE[zzLH2NTR] in the patch order), which makes it awkward: RealPlume has already patched the single-mode engine with a different effect name, so LH2NTR has to be aware of that and use the new name when copying the effect for the alternate mode.

It might help to have LH2NTR run between RealPlume's early and late phases, instead of after both — e.g. change "zzLH2NTR" to "zLH2NTR", or "zRealPlume" to "zzRealPlume".  That way the new effect name would have already been patched into the engine module by RealPlume's early phase, and LH2NTR could just copy that and the PLUME node to set up the engine's alternate mode.  But I don't know whether RealPlume can correctly handle multiple PLUME nodes on a part, and changing the patches to run earlier or later could change how they interact with other mods, which might introduce other bugs.

Link to comment
Share on other sites

3 hours ago, Wyzard said:

Ideally the LH2NTR patch should run first and change the engines to multi-mode, and then RealPlume should see that the engine is multi-mode and apply a different version of its plume patch.  That'd be the most elegant way for it to work, and it'd also make it possible for the two engine modes to get different plumes (one for LF, one for LH2).

 

Ah ok with your updated patch I guess no action is needed on my part.

For future consideration, if the LH2NTR patch changes at some point to run before RealPlume, it should work fine out of the box. The engine configuration patches have a wildcard @MODULE[ModuleEngines*] so the same plume will be applied to all engine modes unless you take specific steps to apply a different plume to each engine mode.

On that note I am not really planning on making LF nuclear plumes. RealPlume has historically treated LF nuclear engines as abstracted LH2 nukes. And unlike the Lox mode on kerbal atomics you're not going to be switching between LF and Lh2 in flight.

The new set of nuclear plumes are very specific to the reactor type (solid core, solid core lox augmented, gas core closed, gas core open) and I wouldnt want to say apply a gas core plume to the LF mode just to make it look different. I could look into it at some point but I have other priorities.

About this 

3 hours ago, Wyzard said:

But I don't know whether RealPlume can correctly handle multiple PLUME nodes on a part,

A single plume node within the EFFECTS node can still be applied to multiple engine modes. You just need the correct powerEffectName in each engine mode. You can also have several PLUME nodes within EFFECTS. Those PLUME nodes dont do anything until applied to a given ModuleEnginesFX in my understanding.

Edited by Zorg
Link to comment
Share on other sites

13 hours ago, Zorg said:

A single plume node within the EFFECTS node can still be applied to multiple engine modes. You just need the correct powerEffectName in each engine mode.

In my experience, sharing an effect between two engine modules doesn't work — the game only applies the effect to one of them, and the other gets no effect at all.  That's the reason why the LH2NTR patch needs to duplicate the effect node in the first place; see this earlier KerbalAtomics change and this forum post by @JadeOfMaar.  I tested and confirmed that back in KSP 1.3.1. when I added the initial fix to the LH2NTR patch, and again in 1.7.3 when I updated the fix to be compatible with RealPlume.

However, I only only tested with runningEffectName, because that's what the MissingHistory part configs use for the two engines at issue.  I see that RealPlume's patch removes the runningEffectName attribute and adds powerEffectName instead.  I don't actually know the difference between those attributes, or when to use one vs. the other.  Jade's post back in 1.3.1 said the problem applies to both, but I haven't actually tested with the latter.  Do you think switching to powerEffectName would allow both engine modes to use the same effect, so the LH2NTR patch wouldn't have to copy the effect node?

(Actually, I should probably make the patch use powerEffectName for those engines when RealPlume is present anyway, just to stay consistent with how RealPlume configures the engine modules.)

Edited by Wyzard
Link to comment
Share on other sites

14 minutes ago, Wyzard said:

In my experience, sharing an effect between two engine modules doesn't work — the game only applies the effect to one of them, and the other gets no effect at all.  That's the reason why the LH2NTR patch needs to duplicate the effect node in the first place; see this earlier KerbalAtomics change and this forum post by @JadeOfMaar.  I tested and confirmed that back in KSP 1.3.1. when I added the initial fix to the LH2NTR patch, and again in 1.7.3 when I updated the fix to integrate with RealPlume.

However, I only only tested with runningEffectName, because that's what the MissingHistory part configs use for the two engines at issue.  I see that RealPlume's patch removes the runningEffectName attribute and adds powerEffectName instead.  I don't actually know the difference between those attributes, and although Jade's post back in 1.3.1 said the problem applies to both, I haven't tested with the latter.  Do you think switching to powerEffectName would allow both engine modes to use the same effect, so the LH2NTR patch wouldn't have to copy the effect node?

(Actually, I should probably make the patch use powerEffectName for those engines when RealPlume is present anyway, just to stay consistent with how RealPlume configures the engine modules.)

Hmm ok I'm not so sure, I should not have spoken so authoritatively on that issue. My expertise is mostly on the designing the smokescreen plumes rather than deep into the guts of smokescreen and realplume :confused:

I did the RP config for the (reStock) NERV on an install without KA but I see now that the RealPlume exists alongside the stock ones when KA is installed (and on only one mode). I should be able to take care of this on the RP-stock side with the correct MM patching.

Link to comment
Share on other sites

10 hours ago, Wyzard said:

In my experience, sharing an effect between two engine modules doesn't work

Ok can confirm that a single plume node cannot be applied to different engine modules. In fact thats an issue I ran into just last month while doing some bespoke stuff for BDB. I should have remembered.

I've figure out a way to handle the NERV multimode switching. Its not super elegant but it will be handled all on the RP-stock side.

Basically

1. Normal realplume patch with NEEDS:[!KerbalAtomics]

2. Normal realplume patch with NEEDS:[KerbalAtomics,NTRsUseLF]

3. Manually delete effects and insert realplume effects at FOR:[zzKerbalAtomics] with a NEEDS:[KerbalAtomics,!NTRsUSeLF]. Two plumes will be inserted one for each engine mode, the LF one will have lower saturation to visually differentiate it.

And actually need to do this twice, one with NEEDS:[!ReStock] and one with NEEDS:[ReStock] :D

 

Edited by Zorg
Link to comment
Share on other sites

On 9/14/2019 at 10:52 AM, Nertea said:

There are no restrictions on this, sounds like it might be a KSPI feature.

Thank you so much for helping out with that! It was indeed a random KSPI engine and I checked the CFG and there it was "mayExhaustInAtmosphereHomeworld ". Thank you so much now on to polluting Kerbin!

Link to comment
Share on other sites

On 9/16/2019 at 1:49 AM, Zorg said:

I've figure out a way to handle the NERV multimode switching. Its not super elegant but it will be handled all on the RP-stock side.

Hey, sorry for not responding sooner.  I see that you released a RealPlume update whose changelog says it has special handling for KerbalAtomics' stock and ReStock NERV patching.  Does that affect the LH2NTR patch for the MissingHistory "Candle" and "Beacon" engines that we discussed here?  Is my pull request (to update the patch's effect names) still applicable, or should it be changed to something else?

Link to comment
Share on other sites

1 minute ago, Wyzard said:

Hey, sorry for not responding sooner.  I see that you released a RealPlume update whose changelog says it has special handling for KerbalAtomics' stock and ReStock NERV patching.  Does that affect the LH2NTR patch for the MissingHistory "Candle" and "Beacon" engines that we discussed here?  Is my pull request (to update the patch's effect names) still applicable, or should it be changed to something else?

Oh since you seemed to have taken care of Missing History stuff, I only did a patch for the stock and restock NERV.

Link to comment
Share on other sites

On 9/15/2019 at 3:01 PM, Wyzard said:

(Actually, I should probably make the patch use powerEffectName for those engines when RealPlume is present anyway, just to stay consistent with how RealPlume configures the engine modules.)

BTW, following up on this: I tried changing the runningEffectName to powerEffectName in the LH2NTR patch (to match what RealPlume would do in the absence of the LH2NTR patch), but made the plume stop working — I'd get a little puff when the engine started, but no sustained effect.  I still don't know the actual difference between runningEffectName and powerEffectName, or why RealPlume's patches replace the former with the latter, but nothing appears to be broken with runningEffectName in the LH2NTR patch, so I'll leave it as-is in that regard.

Link to comment
Share on other sites

  • 1 month later...

KA 1.1.0!

  • KSP 1.8 update
  • Updated B9PartSwitch to 2.12.1
  • Updated DynamicBatteryStorage to 2.1.0
  • Updated DeployableEngines to 1.2.0
  • Updated CryoTanks to 1.4.0
  • Updated CRP to 1.3.0
  • Updated ModuleManager to 4.1.0
  • Fixed some MM patch pass specifiers
  • Fixed MissingHistory "Candle" and "Beacon" engine plumes under RealPume (Wyzard256)
  • Fixed a plume issue on the Deliverance aerospike
Link to comment
Share on other sites

3 hours ago, Nertea said:

KA 1.1.0!

  • KSP 1.8 update
  • Updated B9PartSwitch to 2.12.1
  • Updated DynamicBatteryStorage to 2.1.0
  • Updated DeployableEngines to 1.2.0
  • Updated CryoTanks to 1.4.0
  • Updated CRP to 1.3.0
  • Updated ModuleManager to 4.1.0
  • Fixed some MM patch pass specifiers
  • Fixed MissingHistory "Candle" and "Beacon" engine plumes under RealPume (Wyzard256)
  • Fixed a plume issue on the Deliverance aerospike

Thanks!

I have update all other mods (CryoEngine, NearFuture, etc) in ckan, but the Kerbal Atomics is not listed!

Link to comment
Share on other sites

I asked a similar question in a nearby branch, but by NearFuture mod. Big thanks for help!!!

Now here I need help on an additional patch for this mod... To play for the first time with the mods Kerbal Atomics and all pack NearFuture, what patches do I need to install?

  • NearFutureElectricalNTRs - This will make the service engine is similar in both mods (Kerbal Atomics and NFE)? If I understand correctly, without this patch they are different?
  • KerbalAtomicsNTRsUseLF 
  • KerbalAtomicsNTRModSupport
Link to comment
Share on other sites

38 minutes ago, nickicool said:

NearFutureElectricalNTRs - This will make the service engine is similar in both mods (Kerbal Atomics and NFE)? If I understand correctly, without this patch they are different?

This makes the engines function like reactors in NFE. Do not use this patch unless you want a more complex engine experience, and do not use it if you haven't got some experience with NFE before. It will absolutely make the game harder.

Without this patch the engines from this mod will just be usual engines. 

40 minutes ago, nickicool said:

KerbalAtomicsNTRsUseLF 

Makes the engines all use LF instead of LH2. Some people don't like the challenges associated with LH2 tanks (size). This nerfs the Isp of all engines to try to compensate and makes the game easier for sure. 

39 minutes ago, nickicool said:
  • KerbalAtomicsNTRModSupport

This changes other mods' NTRs to use LH2. It's good if you want consistent balance but can screw up ships in flight. Obviously you don't want this if you installed NTRsUseLF.

 

Link to comment
Share on other sites

Hello

First, thanks for this great mod! But i cant activate the Cooling of the Liberator Engine and stock radiators aren't working for this engine.

 

 

Edit: Apparently some engines dont have this feature but are there any values how much cooling i need?

The Near Future system manager doesnt recognize the engine

Edited by Domspace
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
×
  • Create New...