Chimichanga

Lisias, I just wanted to say that your willingness to troubleshoot old mods is commendable! Keep up the awesome work, thank you!

Good day sir, thank you for all your maintenance! I am having issues where this mod (v0.2.5) is causing nullrefs in the VAB editor. Clean KSP installation, with only FTLDrive and dependencies Player.log: https://www.dropbox.com/s/r26376pj0qhpxy1/Player.log?dl=0 Reproduce: Go to VAB, pick up any FTL drive (not beacon) -> nullref console spam. As soon as you drop the part (or remove it from the rocket) the spam stops. Log file line 20793 is as soon as VAB loaded. Clicking on an FTL drive to select it as the root part causes nullrefs. I then deleted the part (line 37333) and the spam stopped. I then added a non-FTL root part, and clicked to select another FTL drive, and the spam resumed (line 46855). The nullref happens as soon as the part is selected (before it can be added to a ship) so there are nullrefs before the "part added to ship" log events. Thank you for looking into this!

I just found these awesome mods via CKAN - great stuff, thank you! Can't wait to try out SLOTH!

Thank you! Working well.

Thanks for this LGG! Disregard my pre-edit, didn't realize my CKAN was out of date. Great looking mod, Aahz88!

Running 1.8.1 I get 2 B9 warnings on load: [LOG 18:07:42.902] PartLoader: Compiling Part 'HabTech2/Parts/Trusses/ht2_trussPort/ht2_trussPort' [WRN 18:07:42.913] Warning on PartSubtype Bearing on module ModuleB9PartSwitch (moduleID='mount') on part unknownPart: No transforms named 'ht2_truss_trussConnectorBearing_colliders' found [LOG 18:07:42.916] PartLoader: Part 'HabTech2/Parts/Trusses/ht2_trussPort/ht2_trussPort' has no database record. Creating. [LOG 18:07:42.920] DragCubeSystem: Creating drag cubes for part 'ht2.trussPort' [WRN 18:07:42.935] Warning on PartSubtype Bearing on module ModuleB9PartSwitch (moduleID='mount') on part ht2.trussPort: No transforms named 'ht2_truss_trussConnectorBearing_colliders' found Didn't try messing with the part switchers on them in-game but other than that, the modules seem to be working okay. I hope Benjee continues this awesome mod!

IgorZ, you're the best! Have loved this mod since forever and it's always updated! Thank you! Unfortunately it looks like the latest version of ReStock broke your patch - as soon as I remove MM-StockLights.cfg operation resumes as normal on stock Mk1 and Mk2 illuminators. With the patch, the stock Mk1/Mk2 lights are always on but emitting no light. All your other lights work fine! Running KSP 1.8.1, all mods up to date, etc. Looking forward to a fix!

Thanks for the update ! (please disregard pre-edit issue.)

As always Nertea, thank you for what you do! You've made countless KSP'ers happy for years and we appreciate your dedication.

Ah-ha! I just spent 30 minutes trying to figure out where these went! I was checking old screenshots and KSP installs trying to figure out if I missed a mod install or not, and didn't think to dig deeper into KSP's menus looking for deprecated parts. Your 3.75m "FL-R-C1500" sees a lot of use in my station builds, and there aren't any 3.75m tanks in ReStock or ReStock+. Please do continue these flatter mono tanks!

Can confirm this issue on dev #875, 1.6.1 w/ MH

I thought this was only for Launch to Rendezvous - in the past I used to use Launch to Plane successfully to get around having to revert when using Launch to Rendezvous - anyway I am home and will start mucking around trying to get a good baseline to submit logs. EDIT: Reverting to launch does not fix the issue - first launch was 12° off target, second launch was 8.5° off target. Will continue doing this by eye / using Engineer Redux for determining rendezvous angles at launch.

Thanks, sorry I forgot a completely necessary detail - I was launching to match inclination with a targeted vessel at a 30-35° inclincation Will do additional testing when I get home from work.

Sorry to be a bother, but I still can't quite get Ascent Guidance's Launch Into Plane to work correctly... this looks to have been "fixed" in dev #865, but using current dev #872 it's still not matching inclination correctly. It's late and I need to sleep, but I will test again with a clean KSP install tomorrow after work. Can anyone else confirm if Launch to Plane is working correctly for them?

That one did it... perfect, thank you!

Running 1.3.0.2 from CKAN and still unable to load some crafts, image below:

lost a bunch of crafts using the cargo heatshields...

Yay! Looks like dev#859 updated the ToDo file, including Fix "launch to plane" to update the inclination field

#857 is no joy, but it was definitely working before but I can't figure out which version. Might be best to try #849: fix "launch to plane" again again (commit: 615dcaa) — lamont / githubweb https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/849/

Hi @sarbian Ascent Guidance's "launch into plane of target" appears to be broken again. Tested with a new install of KSP 1.6.1 w/Making History: There are no other mods in use except MJ dev-#858 and ModuleManager. 4.0.1. Clicking "launch into plane of target" no longer modifies the inclination in the Ascent Guidance window, and no longer gives me accurate timed launches. Thank you for all of your hard work - I can't enjoy KSP without MJ!

Quite a few of the parts do work with Tweakscale however: The 3.75m Docking Port XL won't dock with Tweakscale installed. You can uninstall Tweakscale, dock your stuff, and reinstall Tweakscale without issue.

Here's the mesh-names you'll need to exclude: excludeMesh = GreenhouseGlass (1) excludeMesh = GreenhouseGlass (2) excludeMesh = GreenhousePlants (1) excludeMesh = Plant01

It's a conflict with Station Parts Expansion, check this threads page 3 for a module manager patch to disable the reskins from SSPEx

One more conflict issue concerning MissingHistory and PorkJet remodels of the LV-909 Terrier, T45 Swivel, and T30 Reliant engines... they have a shell/shroud around them. Fix is identical to the above post, comment out the lines in StandardizeModels.cfg,

The conflict is with Indicator Lights Here's the relevant (I hope) module manager config for that part from IL: @PART[science_module] { // We have to re-specify the model for the stock part, because this is // an older part that uses the "mesh =" syntax in its .cfg file instead // of the newer "MODEL" syntax. The "mesh =" syntax doesn't allow having // multiple models as part of the same part, which would prevent this mod // from adding meshes for the indicator lights. MODEL { model = Squad/Parts/Science/MaterialBay/science_module_small } //------------------------------------------------------------------------- // INDICATOR MESHES //------------------------------------------------------------------------- MODEL { model = IndicatorLights/Meshes/squareLamp scale = 1, 0.4, 0.5 position = 0, -0.34833, -0.49839 rotation = 0, 180, 0 } MODEL { model = IndicatorLights/Meshes/squareLamp scale = 1, 0.4, 0.5 position = 0, -0.34833, 0.49839 rotation = 0, 0, 0 } //------------------------------------------------------------------------- // CONTROLLABLE EMISSIVES //------------------------------------------------------------------------- // The add-on meshes that we use to show science content, availability, etc. MODULE { name = ModuleControllableEmissive target = IndicatorLights/Meshes/squareLamp emissiveName = indicator } // The bluish-glowing center part (from the original model) MODULE { name = ModuleControllableEmissive target = Glass emissiveName = frontPanel } // The orangey-glowing side parts (from the original model) MODULE { name = ModuleControllableEmissive target = DoorAssembly emissiveName = sidePanels } //------------------------------------------------------------------------- // CONTROLLERS //------------------------------------------------------------------------- // These first two controllers take care of the add-on meshes. MODULE { name = ModuleScienceDataIndicator emissiveName = indicator dataColor = $HighScience partialDataColor = $MediumScience lowDataColor = $LowScience emptyColor = ModuleScienceAvailabilityIndicator lowScienceThreshold = 0.25 highScienceThreshold = 0.8 } MODULE { name = ModuleScienceAvailabilityIndicator lowScienceThreshold = 0.25 highScienceThreshold = 0.8 } // Make the blue glowy part pulsate slowly when it has science. MODULE { name = ModuleScienceDataIndicator emissiveName = frontPanel dataColor = pulsate(#00FFFF, 2800, 1, 0.4) emptyColor = #004040 } // Make the orange glowy part pulsate quickly when it has science. MODULE { name = ModuleScienceDataIndicator emissiveName = sidePanels dataColor = pulsate(#FF8000, 777, 1, 0.7) emptyColor = #804500 } } I'm guessing it's double-dipping on the mesh/model change. To anyone running both IL and this patch, the fix is to edit StandardizeModels.cfg, find this section and comment it out: //@PART[science_module]:NEEDS[Squad]:FIRST { // -mesh = DELETE // MODEL { // model = Squad/Parts/Science/MaterialBay/science_module_small // } //}