New SolarPanels.cfg break Near Future Solar

[drake127]

After installing R-T-B dev1101 with new SolarPanels.cfg, it looks like NearFutureSolar mod is broken. When removing SolarPanels.cfg entirely, the problem disappear. Any quick ideas?

[LOG 20:21:34.654] PartLoader: Part 'NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-1x1-ikonos-1/nfs-panel-deploying-advanced-1x1-ikonos-1' has no database record. Creating.
[LOG 20:21:34.654] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes.
[LOG 20:21:34.655] DragCubeSystem: Creating drag cubes for part 'nfs-panel-deploying-advanced-1x1-ikonos-1'
[WRN 20:21:34.682] Warning on PartSubtype Basic on module ModuleB9PartSwitch (moduleID='cellSwitch') on part nfs-panel-deploying-advanced-1x1-ikonos-1: Could not find matching module
[EXC 20:21:34.685] Exception: Could not find matching module
    B9PartSwitch.ModuleMatcher.FindModule (Part part) (at <b85eabe067044bcb9aeabe863954a5ce>:0)
    B9PartSwitch.ModuleModifierInfo+<CreatePartModifiers>d__10.MoveNext () (at <b85eabe067044bcb9aeabe863954a5ce>:0)
    B9PartSwitch.PartSubtype.Setup (B9PartSwitch.ModuleB9PartSwitch parent, System.Boolean displayWarnings) (at <b85eabe067044bcb9aeabe863954a5ce>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:LogException(Exception)
    B9PartSwitch.PartSubtype:Setup(ModuleB9PartSwitch, Boolean)
    B9PartSwitch.ModuleB9PartSwitch:InitializeSubtypes(Boolean)
    B9PartSwitch.ModuleB9PartSwitch:GetInfo()
    PartLoader:CompilePartInfo(AvailablePart, Part)
    <CompileParts>d__56:MoveNext()
    UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

[drake127]

I tried to use old .cfg and KSP froze on loading of "nfs-panel-deploying-advanced-1x1-ikonos-1.cfg" - the first solar panel of NFS. Either the old Kopernicus solar panel patch didn't work or there's new incompatibility.

[R-T-B]

Yeah, this looks more like an issue with b9partswitch. I run with near future solar as well and don't experience bugs, so rather than replacing or removing the config I'd make sure your b9partswitch is up to date.

If that fails, you can always post back and I'll investigate with you. But if the core issue is the new solar module hijacking system, it looks like the author of b9partswitch and/or nearfuturesolar would be where to report this, as there is not much we can do to change how it must work for multistar.

[R-T-B]

Yeah I just tested my game again and I am not getting your bug, I suspect because I use Kerbalism. I will test again without. EIther way, if this bug is real, it's down to the authors of NFS to fix it. They should be able to look at our config file and know what to do. Closing for now as it's not something I can really do anything about, though I will update if I can replicate and/or find a workaround.

Also, you should note that flights in progress are going to have a hard time with parts packs installed making that jump. It's a technical limitation due to changes we had to make. It may be you aren't using a fresh flight, and that's part of the issue. If so, just return al flights to KSC asap, and all should return to function for that game.

[drake127]

That's odd. I just deleted all my mods except: B9PartSwitch 2.17.0 Kopernicus 1.10.1r17 ModularFlightIntegrator (1.2.7 bundled with Kopernicus) Near Future Solar 1.2.3 ModuleManager 4.1.4

I get the errors right at the start before loading any gamesaves. I am not saying that Kopernicus is to blame but changes in Kopernicus made bug to appear (why?). Also, are you certain you are not getting the bug? So there's problem somewhere else?

[7ranceaddic7]

I'm running 191RC17, upload a KSP.log and I'll compare it with one of mine.

[drake127]

KSP.log

[7ranceaddic7]

@R-T-B Can you upload your log too. I'm getting that EXC too. Both in 1.9.1 and 1.10.1. I've been getting it but thought it was something else. (Wasn't concerned about it because I haven't reached those parts yet.)

KSP_B9PS_EXC.log

And, yes, I agree it's NOT a Kopernicus issue.

[R-T-B]

I will upload a log shortly. We are going through a record breaking heatwave in my hometown right now and lack air conditioning, so computers won't come on until late evening (posting from cellphone).

Note that the solar panel changes between 1.8/the latest 1.9 are not completely compatible with existing games with flights in progress. For best results, ground all your flights (you can delete solarpanels.cfg briefly to do so). Then reinstall the mod as normal.

[R-T-B]

As promised, my log and a list of what I was running when I tested it:

KSP.log

The only thing I notice is our modulemanager versions are different. Can you retry with 4.1.3? It's possible this is something introduced by the new modulemanager?

[R-T-B]

Nevermind, the difference was running JNSQ, which aparently suppresses the error somehow. Most curious.

I now have the same error with your same config. It is B9Partswitch or near future solar. I will advise the appropriate devs. EDIT: Advised. https://forum.kerbalspaceprogram.com/index.php?/topic/155465-110x-near-future-technologies-all-110-nfa-returns/&do=findComment&comment=3838988

[R-T-B]

Fixed in new release 18, we now ship a config patch for this. Thanks for the report!

[hemeac]

@R-T-B, my one concern with the patch as is, is that will only work for Nertea's Solar. While I don't know of any others, I think I have a general solution that should future-proof (if others use it or Nertea adds a 4th subtype): //B9PartSwitch support @PART:HAS[@MODULE[ModuleB9PartSwitch],~useKopernicusSolarPanels[false]]:FINAL { @MODULE[ModuleB9PartSwitch] { @SUBTYPE,* // Choose all subtypes { @MODULE:HAS[@IDENTIFIER[ModuleDeployableSolarPanel]] { @IDENTIFIER[ModuleDeployableSolarPanel] { @name = KopernicusSolarPanels } } } } }

Sorry, I don't know how to get this to look nice

[R-T-B]

Thank you, I know I'm no good at modulemanager syntax as I just learned it, hehe.

I will use that version next release, which'll probably be CKAN for stable, and same time for me (sometime monday, we are dealing with a heatwave here that makes operating my computer hard until evening).

[hemeac]

Your comment was quite timely as I had just spent Saturday adapting Nertea's solar part switching to stock solar panels. Definitely test the patch though. I ran it with the latest Kopernicus bleeding edge with your Nertea patch removed and B9 didn't throw any warnings and the solar panels were charging at the launch pad. I didn't add any planet packs, so it was just stock planets.

Definitely not a MM expert, but it's been a good challenge to learn. The syntax is a lot different than the interpretive languages I script in for work.

[R-T-B]

Just tested it, works. Before it gets too hot to run my computer, I spliced the .cfg into existing releases. No need to make a fuss over it as the old one worked (for now) but I definitely will use your config moving forward.

[democat3457]

Lmao @hemeac you just pinged 5 random people in that message, enclose it in ``` and make sure they're on new lines before and after.

[7ranceaddic7]

Just to drop the discussion from a non-related thread...

The only reason I suggested using :NEEDS[Kopernicus] is maintaining convention with the intended design.

People do stupid stuff all the time and if you say :FINAL it still gets applied.

[R-T-B]

Yes, but the final lines are literally just making sure that a Kopernicus config is obeyed. Anything else would be unintended behavior I think.

I mean I can change it if there's a reason. I just got to be honest: I don't see one personally.

[7ranceaddic7]

No, you're fine.

Like I said, :FINAL is a conditional best left solely for the end-user unless absolutely necessary.

I can get behind the "unintended behavior" aspect.