Nertea

[1.7.x] Kerbal Atomics: fancy nuclear engines! (Sept 11)

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

Share this post


Link to post
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.

 

Share this post


Link to post
Share on other sites
12 hours ago, KIMCHI said:

Is there a specific way to allow Nuclear Rockets in the atmosphere?

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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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!

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
Just now, Zorg said:

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

OK, good to know.  I'll keep my pull request open, then.

Share this post


Link to post
Share on other sites

Thanks for looking into this, I'll merge it and release it when I have some time. 

Share this post


Link to post
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.

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.