etmoonshade

More bug! This one took a while to figure out, because using sandbox mode masks the bug. The KSPI-E integration is slightly broken. KSPI-E uses a "techRequired" key under the integrated Tweakscale module to limit scaling dependent on tech (think miniaturization) This causes Tweakscale to not find a valid scale factor, since none of the tech nodes exist in TETRIX. Example from .\GameData\WarpPlugin\Parts\Electrical\TriAlpha\TriAlpha.cfg in KSPI-E: MODULE { name = TweakScale type = stack_interstellar defaultScale = 2.5 scaleFactors = 1.25, 1.875, 2.5, 3.75, 5, 7.5, 10, 15, 20, 30, 40, 60, 80 techRequired = quantumReactions, exoticReactions, advFusionReactions, advFusionReactions, advFusionReactions, advFusionReactions, advFusionReactions, advFusionReactions, advFusionReactions, advFusionReactions, advFusionReactions, advFusionReactions, advFusionReactions } There are... quite a lot of parts which use this pattern.

I'll fire this up sometime today and kick the tires. Fighting another bug right now If I understand the issue right based on your description, 1.10.1 isn't providing info on the ship's type in the VAB, so you're having to make a best guess based on the stats of the "top" command module (e.g. has crew = ship, no crew = probe) and you can't even extract/force the information otherwise? In general, I think crew > not crew as far as naming goes - if I have crew on a ship, that's usually what I care about. (also, thanks for giving this a look quickly - when I was complaining about bugs, I didn't mean this one though - dealing with KSPI-E being weird right now )

Ouch! Speaking of naughty words... calling me a user mumble grumble

The last situation. The "naughty" word was in the main folder name: E:\KSP Active Installs\Kerbal Space Program - WarpPlugin Test\ (I was testing an issue with KSPI-E on the install.) My assumption was that you're just searching the whole path for the word "Plugin" It's not a huge bug or anything - it was sorted easily by changing the name of the KSP folder - just figured I'd mention it.

Probably an easy bug to find: If your KSP directory has the word "plugin" in it, you get a Houston error saying that KSP Recall is installed in the wrong place. The comparison is probably a bit too simple.

Bug on 1.10.1, using KSPI-E 1.28.10: Attempting to open the Reactor Control Window on a Tri-Alpha reactor causes a spam of nullrefs: [EXC 12:36:53.659] NullReferenceException: Object reference not set to an instance of an object FNPlugin.Reactors.InterstellarReactor.Window (System.Int32 windowId) (at <c78d54ae0cd341cdaa0fac7a64ea25af>:0) UnityEngine.GUILayout+LayoutedWindow.DoWindow (System.Int32 windowID) (at <fa6f9762ac624af092525d37c9d516c4>:0) UnityEngine.GUI.CallWindowDelegate (UnityEngine.GUI+WindowFunction func, System.Int32 id, System.Int32 instanceID, UnityEngine.GUISkin _skin, System.Int32 forceRect, System.Single width, System.Single height, UnityEngine.GUIStyle style) (at <fa6f9762ac624af092525d37c9d516c4>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Log is here: https://www.dropbox.com/s/b6s138v44bwxbla/Tri-Alpha Window Bug.zip?dl=0 (edit: For the record, this is a minimal install via CKAN, only adding the required mods to install KSPI-E)

@theJesuit - quick typo fix in TETRIXTechTree-ModParts.cfg: @PART[dmReconSmall|dmscope|dmUS2Scope]:NEEDS[DMagicOrbitalScience] { @TechRequired = advUnammed } This one had me pulling my hair out trying to find the telescope in my tech tree until I thought about searching for it in the mod files. (for clarity, it should be { @TechRequired = advUnmanned )

So, this next bug (which I casually mentioned on your stream yesterday) may be related to fixing the above: When hitting the Champagne Bottle (CB) button in the VAB, my ship type reads as "debris" - a "D" suffix on the ship class. If I select my command pod and accept whatever vessel type is selected in "Configure vessel naming," CB will display the proper suffix. Removing vessel naming will revert the ship type to to Debris. Selecting a different ship type will use whatever is auto-detecting. Test scenarios in 1.10.2 (all on the same ship): Incorrect: Place command pod, hit CB button, observe "D" vessel type (I suspect this is technically correct, since I'll bet KSP doesn't configure the naming when you place a command pod, but it's certainly unexpected behavior - I assume this is why you said it's "weird." Did you originally test the change you did in 1.11 but not 1.10? May be a difference between the versions...) Correct: Configure vessel naming, accept, hit CB button, observe expected vessel type (ship, for a command pod.) Technically correct: Configure vessel naming, remove naming, hit CB button, observe "D" vessel type (I assume that removing naming sets the vessel type to 0 or whatever debris is.) Incorrect: Configure vessel naming, assign a type other than Ship (e.g. base or rover,) observe ship vessel type. Vessel type should be whatever was chosen in the naming config. No useful logs this time - Champagne Bottle is only mentioned in loading. No nullrefs - no log messages about it at all, in fact.

Oh, I see you're up as early as I am. Excellent, I wrote that way too late in the evening to be sure I gave sufficient info.

@linuxgurugamer - Either nobody but me uses this, or it's working fine for everyone else and my game is just strange. I'm running into a bug in Champagne Bottle in 1.10.2 where it spits out a nullref when I select where I want English, Kerbal, or Both - clicking the button to start picking names causes the following error: [ERR 23:40:56.996] [Toolbar] [ERROR] error while handling click event: ChampagneBottle_NS.champagneBottleButton [EXC 23:40:56.997] NullReferenceException: Object reference not set to an instance of an object ChampagneBottle.ChampagneBottle.GenerateName () (at <155e214df2e4439f81e139276fafe74a>:0) ChampagneBottle.ChampagneBottle.OnAppLauncherTrue () (at <155e214df2e4439f81e139276fafe74a>:0) ToolbarControl_NS.ToolbarControl.SetButtonActive () (at <a925a118c9174edfb82f6b8781e2e04f>:0) ToolbarControl_NS.ToolbarControl.ToggleButtonActive () (at <a925a118c9174edfb82f6b8781e2e04f>:0) ToolbarControl_NS.ToolbarControl.button_Click (ToolbarControl_NS.ClickEvent e) (at <a925a118c9174edfb82f6b8781e2e04f>:0) ToolbarControl_NS.Button.clicked (System.Object realEvent) (at <a925a118c9174edfb82f6b8781e2e04f>:0) Toolbar.Command.click () (at <3b3a73f106c246ecb6e0b071fa9f6c5c>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) Toolbar.Log:log(LogLevel, Exception, String, Object[]) Toolbar.Log:error(Exception, String, Object[]) Toolbar.Command:click() Toolbar.Button:click() Toolbar.Button:drawInToolbar(Rect, Boolean) Toolbar.Toolbar:drawButtons() Toolbar.Toolbar:draw() Toolbar.ToolbarManager:OnGUI() [ERR 23:40:59.240] System.NullReferenceException: Object reference not set to an instance of an object at ChampagneBottle.ChampagneBottle.GenerateName () [0x00018] in <155e214df2e4439f81e139276fafe74a>:0 at ChampagneBottle.ChampagneBottle.WindowGui (System.Int32 windowId) [0x001d2] in <155e214df2e4439f81e139276fafe74a>:0 Full log is here if you think the context will help: https://www.dropbox.com/s/lgofq36hcl1z1t8/KSPLog20210607.7z?dl=0 Reverting to the previous version of Champagne Bottle resolves the error. A quick look at github shows you did change the code the error is complaining about, so I assume it's actually a legit bug this time.

Would it be possible to provide a config option in the XML to tweak the default height above terrain to spawn? Most of my rovers tend to be big, chunky, and able to survive a 50m drop. Default it to 0 so behavior doesn't change for most people, but give those of us with frequent problems an option. (alternately, and obviously more complex, an option in the BV window itself for spawn height above terrain)

I love cats as much as the next person (and perhaps even more,) but would it be possible to at least put a message in the log that says "Nyan Cat - no, your install isn't broken" for when the Nyan Cats show up as an easter egg? I just blew an hour on trying to figure out what went wrong with my install when the answer was apparently "nothing" >_>

Bug report - and the conditions are pretty simple, though the solution probably isn't. Disabling damage on Kerbal Foundries wheels causes Bon Voyage to read tracks as "not online" Reproduction steps: Use a clean 1.10.1 install Using CKAN, install Kerbal Foundries 2, KSPWheel (dependency,) and the last version of BV compatible with 1.10.1 (although I've reproduced this with the 1.11 version on 1.10.1) Start a new game. Set KSPWheel settings for "Wear and damage" to "NONE." It doesn't appear to matter whether this is done in the initial game setup, or later on. Use cheats to give max tech/max VAB (though I don't think the latter is necessary now that I think of it...) Build a simple rover in the SPH - 2x2 structural panel, tracks on the side, BV controller, probe core of some flavor to provide unmanned control. Launch. Open up BV controller window. Observe that "wheels aren't online!" and max speed is 0m/s Craft file for ease of testing: https://www.dropbox.com/s/a88fjuc42b2elo0/Untitled Space Craft.zip?dl=0 Note - leaving damage on "simple" but turning the sliders down to 0 appears to allow BV to work correctly, though I'm not sure it results in truly undamageable wheels. Note 2 - the above workaround also worked on my existing game with 160+ mods. Note 3/question: The most recent 1.11 version appears to work fine in 1.10.1 - should I expect any weirdness from it, or has it proven itself to be mostly compatible?

For what it's worth, I wasn't calling you out - just testing the values and found that it didn't match what MechJeb was saying.

Eh, it's a valid (if vague) question. I had trouble with Sigma Dimensions myself - you might try blowing away your KSP folder entirely (as in, delete it from the Steam folder and THEN hit the uninstall button in Steam,) installing it fresh, and then installing SD/RESCALE/Kopernicus BE. Do NOT transfer configs or anything else over. It's working fine for me now, but there was some sort of crud leftover that made it not work in very weird and curious ways.

I've run into the jumping orbit bug myself, during regular gameplay. One way to trigger it (for me) is to "jump" your timewarp from 1x to something high - if you click the warp bar to go straight to 100000x, or use the "warp to node" feature that comes with KAC (I think that's what gives that function, at least,) I've noticed it'll mess up the orbit.

I had a hell of a time with Sigma Dimensions a month or three ago. My eventual solution was to do a FULLY clean install of KSP - don't transfer your configs, don't copy stuff from old folders. Install everything from a clean distribution. Edit: Clean including KSP. Delete the folder from your Steam directory entirely, run the uninstall from Steam, and then reinstall it.

You can even get it on CKAN.

Depending on how far you want to go with the changes: OPM is one I personally use - it adds 4 planets to the outer Kerbol system and doesn't change anything else (except for putting Eeloo in orbit around one of those planets.) I like this because I can apply my own rescale mod on top of it, and I get "mostly stock" everything. I've read good things about the Beyond Home series, and it looks beautiful from all the screenshots. Unfortunately (for me) it replaces the entire solar system, which is something I didn't want when I was looking at planet packs.

Yup, not a big deal, just cussing because I missed something.

I don't think you specified what it actually was, so I figured it was what I'd already done at that point... whatever it was. :V I know I had to uninstall/reinstall for something.

gdi Yes, that's exactly it. I used it pretty much immediately, because R-T-B did it at my request. I'll hit it up after I'm done streaming - thanks @HebaruSan

It looks like CKAN isn't getting updated with the BE releases - I'm on 28 right now. Not sure if this is intentional or not.

It's kind of what I've been discussing with @hemeac - you can see it clearly on his screenshot in the above post. L-Tech SkyLab experiments are biome-specific, but they don't provide the feedback of "Plant Growth experiment <situation>" in the results window. It doesn't keep it from working, per se, but it results in the confusion they're currently having.

Only other thing I can think of is including biome information in the science window popped up by the SkyLab experiments. It's more of a "graphical bug" than anything else, but y'know, still obnoxious. :D