Zelda

After taking the latest KSP_PartVolume update, I saw the following ModuleManager error: [LOG 17:41:05.298] Applying update KSP_PartVolume/AddToAllParts/@PART[*]:HAS[!MODULE[ModuleCargoPart],@MODULE[ModuleInventoryPart],!MODULE[KerbalEVA]]:FINAL to UniversalStorage2/Parts/Science/CargoStorageWedge.cfg/PART[USCargoStorageWedge] [WRN 17:41:05.298] Cannot find key packedVolumeLimit in MODULE [ERR 17:41:05.298] Error - Cannot parse variable search when inserting new key packedVolumeLimit = #$/MODULE[ModuleInventoryPart]/packedVolumeLimit$ And sure enough, the config for the USCargoStorageWedge part does not have packedVolumeLimit defined. It seems like that should be added here, especially if it controls the actual volume limit. What that value should be, though, I don't know. Issue on GitHub.

Thanks for the update! I did encounter an error immediately after updating though, and it appears that a part in Universal Storage II is to blame. The cargo wedge config doesn't have a packedVolumeLimit value defined under ModuleInventoryPart, so it fails trying to parse the variable. I know that's a bug in Universal Storage II and I will be filing a bug report there, but I wanted to mention it here too in case others come here to report, since it wasn't apparent until this mod was updated.

Just my $0.02 - While I acknolwedge this is a megathread and is therefore difficult to browse, having everything in one thread makes it much easier to search since you can limit the search to this topic only. Unless you also were somehow wanting to port over the existing treasure trove of knowledge to a new thread (which would be near impossible given the amount of info here), that would mean needing to look in two places for possible answers moving forward. Also, regardless of how clear it is in the OP, there will still be people who ask their MM questions here before finding the new thread. Likewise, there will be people who could have found their answer searching this thread, but won't realize it and ask duplicate questions in the new thread. So there will be a bit of a tax in redirecting people / looking up old answers that the asker could have found if in the same thread anyway. Again, just my opinion, but I think the time for a separate help thread was years ago. It's a little hard to do that now and not lose some knowledge in the process.

I haven't encountered this same problem before, but putting personal patches in a zzz_* folder is a very useful tip that I'll start doing just to be sure. Thanks!

Oh, great! I will play with it more this weekend then! I did figure out the KSPTOTConnect plugin / generating the bodies.ini file, which seemed to work great, thanks!

Hi! This looks really cool, so I downloaded it to see if I can use it to plan some gravity assist maneuvers in my scaled-up solar system. However, it seems like the only options for time units are Earth time and stock Kerbin time? In a 2.5x scaled up system with OPM and Kronometer, Kerbin has ~10 hour days and ~400 day years, so trying to use something like the Multi-Flyby Tool gives me very different dates for a given UT than what is shown in game. So that brings me to my question - is there a way to get KSPTOT to work with non-stock / scaled up systems?

It happens when I'm directly controlling them. I actually hadn't gotten around to using kOS-EVA yet, even though I installed it months ago with big dreams of scripting EVAs.

Unfortunately I can't help you with the MechJeb questions, but LAN means Longitude of the Ascending Node. It's one of the key parameters that define an elliptical orbit. Basically, the point at which an inclined orbit crosses the equator. If you need to place a vehicle into an inclined orbit, launching into an inclined orbit at a specific LAN means launching at a specific time. It will typically save a lot of dV over launching into an equatorial orbit and then performing a maneuver to change orbit to where you want it to be. https://en.wikipedia.org/wiki/Longitude_of_the_ascending_node

Good call, though I just checked again and I no longer get the error. Either they renewed the cert, or it was a transient issue. ¯\_(ツ)_/¯ If I see it again, I'll definitely report it to the SpaceDock thread though. Gotcha re: no GitHub! I was indeed assuming you used it, but since you don't, I don't think you need to go to the trouble of setting up another location. Now that SpaceDock is working properly for me, I'll give this a spin tonight. Thanks!

I haven't played with ModuleTestSubject at all, so I can't help with ALTITUDE vs ALTITUDEENV, but whenever I see GT, LT, EQ, NEQ in any kind of programming context, they usually mean: GT: Greater than LT: Less than EQ: Equal NEQ: Not equal Looking at something like this (random example pulled from your wiki link): CONSTRAINT { type = ALTITUDE test = LT value = 300000 situationMask = 16 body = _NotSun } That looks to me like the constraint would be satisfied if your altitude is below 300000m (type, test, and value), you are in space low over the required body (situationMask), and body = _NotSun probably means the body chosen for the test will be anything other than the sun.

Yeah, this looks great! I'm looking forward to trying it out. Would you be able to also link to your repo as an alternative place to download releases? Mainly asking because I went to get this from SpaceDock, and it seems like their SSL certificate is no longer valid: https://imgur.com/a/qmnAKFL

So THIS is the mod that borked the kerbal animations. It's been driving me crazy for months, and I am running over 200 mods so to go through each mod one by one felt daunting. Thanks for flagging this and saving me a ton of time!

You should see a B9 Part Switcher on tank PAWs to choose which fuel they hold. If you aren't, it's almost certainly a Modular Fuel Tanks conflict. I think I had the same conflict and question before, but removing MFT fixed everything.

This looks amazing. Nice work!

That's great! Looking forward to it, whenever you have time to release it. Also hoping your experiment goes well!

I absolutely love this mod, it really takes the audio up to the next level. As an audiophile, I can't thank you enough for working on this! One question though - is there a plan/desire to exempt SoundtrackEditor from muffling in flight / map view? After using SoundtrackEditor for so long with custom playlists, it's hard to go back to the repetitive stock music... but it's also hard to hear engines at full volume unmuffled in space after you've been used to that for a while. Thanks again!

Ah, good callout on redundancy. I have been dabbling in MM patches for a while, but I wasn't aware of that. TIL! Also a good point that other patches work correctly, I should have thought about that. Thanks for the correction!

Snacks is nested in another folder in GameData - WildBlueIndustries. Taking a wild guess, but maybe MM can't see that folder since it's not directly in GameData and needs to depend on Snacks running a patch with :FOR[Snacks] to establish it is present. If that's the case, the problem may be that BetterScienceLabsContinued runs before Snacks does that. Maybe try changing this: @PART[Large_Crewed_Lab]:NEEDS[Snacks] @PART[Large_Crewed_Lab]:NEEDS[Snacks] to this: @PART[Large_Crewed_Lab]:AFTER[Snacks]:NEEDS[Snacks] And see if that solves the problem? Again, this is a total shot in the dark, but it's easy to try.

Fantastic to see you taking this on, zed`K! Like others, this is my favorite of the node editing tools. Glad to know it's in great hands.

Thank you for the super quick fix!!

Hi @cineboxandrew! After upgrading from 0.2.8 to 0.2.9, I noticed that decals no longer seem to work on subassemblies. Any that I had applied to a subassembly when it was saved are blank when I select the subassembly later. This is true of both subassemblies created with 0.2.8, and ones created after upgrading 0.2.9. Reverting CD back to 0.2.8 resolves the issue. Repro steps: Apply a decal to a part (such as a flag decal to a tank) Save the tank as a subassembly Select the subassembly. Note that the decal is blank Pictures showing the result: https://imgur.com/a/nc1cxfC Nothing in the logs stands out, though of course I'm happy to provide them if you would like to look. I tried reinstalling, but got the same result. Is this an issue with upgrading versions of Conformal Decals in general, something related to this particular update, or something related to my specific install? Thanks!

Did you ever figure this out? I now have the same issue.

IIRC he answered this in the thread already. Basically possible, but not easy.

Apologies if this was asked already, but didn't find it in a search of the thread. Should the solar panels in the payload shrouds still generate power when they are closed? In the PAW, I still see it receiving sun exposure and generating EC even when the doors are retracted.

Super late to the party, but even after playing KSP for almost 10 years (and using MM for much of that time), this is my first time seeing this. Amazing.