Aelfhe1m

Hey @Snark good point about the Stratus tank although I do very rarely use it in the cargo bays of really big spaceplanes. For those that want to keep it but still have a LFO variant then this slightly modified version of your patch will clone it:

Here it is on GitHub.

I can't think of anything else off hand that has RSS or RO configs but there's a DynaSoar mod, several versions of the Gemini MOL concept (in addition to the FASA BDB versions), various concept Mars landers and rovers (such as NKR's DEM) or one's "inspired" by The Martian (e.g. the Phoenix Industries rover and MAV - not updated since 1.1.2 unfortunately). And I think the Tantares packs includes several parts for the proposed Soviet Moon lander and N1 rockets.

Well the NFT Vasimir engines have RO configs as do some of the "advanced" ion-engines and there's a couple of nuclear engines from the AtomicAge mod with RO configs. Other than that KSPI-E has RSS fixes and patches for most of the RO dependencies but not RO per se.

That's from STS 61c. I think the original is at around the 51 minute mark in the flight highlights audio here.

It is generated by the AVC version file - GameData/PlanetShine/Plugins/PlanetShine.version. Modifying the version numbers in that file can remove the message (or you could simply delete the file) but doing so may prevent you getting a notification if/when a new version is ever released.

I'm not familiar with this particular mod's source but since the mod is written using the old style immediate mode interface, it should be sufficient to wrap this block at the bottom of George.cs in a GUILayout.BeginScrollView()/GUILayout.EndScrollView() block with appropriate parameters (Unity docs).

Actually the commented line is just something I left in by accident from when I was testing different ways to write this patch. The use of %MODULE[MechJebCore] (and % at start of the other lines) adds the module if it doesn't exist or modifies the module if it has already added by another patch (e.g. probesplus). No duplicate module is created so MechJeb won't get confused over which settings you want it to use.

@Gordon Dry I don't think the real issue here is with the mod supplied patches (such as @akron's) but rather that MechJeb Embedded specifically does not add its patch to any part that already includes a MechJeb module. If you really want to force all command pods to have all features from the start (which seems to be the intent of that mod) a better patch is: which gets applied whether a pre-existing patch already exists or not.

The rotation is specified in degrees and you want to rotate around the Y axis in this instance. Try this: @PART[probeCoreHex] { -mesh %MODEL { %model = Squad/Parts/Command/probeCoreHex/model %position = 0.0, 0.0, 0.0 %scale = 1.0, 1.0, 1.0 %rotation = 0, 30, 0 } }

I put a pull request on @ObiVanDamme's GitHub repository with my changes. You can get my modified DLL from there. (Click the files changed tab then the view button beside the DLL file to get a download link) According to his profile ObiVanDamme was last on the forum 3 weeks ago which isn't all that long really. If he stays away for a while longer I'll consider releasing a "continued" version.

Apparently I was wrong about this. I just tried an actual test by creating a dummy part with: PART { name = loctest title = Localization Test category = none MODEL { model = #PARTTEST_modelname texture = #PARTTEST_texturename } } Localization { en-us { #PARTTEST_modelname = Squad/Parts/FuelTank/fuelTankT400/model #PARTTEST_texturename = Squad/Parts/FuelTank/fuelTankT400/model000 } } After running the game looking in the ModuleManager.ConfigCache showed that the MODEL node had been completed with the localised values. A couple more tests showed that config values were automatically localised provided the #localisation_key was the only thing in the value. If it was mixed in with any other text then it was passed through unchanged. I think this method would still result in both the default and localised version of the texture being loaded into RAM but more testing would be needed. TL:DR; Textures can be switched in parts using just localisation files provided localisation value contains the full path to the texture

File paths accepting localization ids would need to be written into the various modules that consumed those paths. AFAIK the stock MODEL {} node doesn't have that support for its textures. Until that support is widely available an extension to MM might fill the gap (not sure whether the demand would be worth the development effort though) I completely agree that packs are best for large/many textures both from a RAM and download size perspective.

Manoeuvre Planner's Hohmann transfer works fine in most cases. Too well often as it will plot a collision course with the Mun unless you adjust the manoeuvre afterwards. How well you might be able to execute the node will vary depending on vessel design (especially TWR and balance - any off-centre thrust can have a big effect) and whether you perform the burn manually or tell MJ to execute it. Besides what sort of final orbit do you want after your transfer - prograde, retrograde, polar, rendezvous with a space station, landing orbit for a surface base? The options are too many to fit into a convenient interface. So instead you get an answer and the tools to tweak it to fit your specific requirements. But you shouldn't just immediately warp to the destination after the burn. Even if you performed it perfectly there may be a need (especially with Minmus) to do a small correction half way and this is what Manoeuvre Planner's "Fine Tune" option is for.

Not for text as far as I can see but you might need some sort of special support if you were going whole hog and also localising image textures (post it notes in interiors, warning messages or signage on part exteriors etc.). Also Squad localise their KSPedia pages by swapping in separate files with the same names. Maybe some MM clause like :LANG[es-es] that would be equivalent to a :NEEDS[] but filters by installed language rather than available mod. With this you could conceivably write a patch to replace the part texture with one of several alternatives depending on which language the player was running. But this seems like a very limited need at the moment as I doubt there will be many mods localised to that degree. Language packs for text in mods with localisation support doesn't even need MM. You can just drop a config file with a Localisation node and inner language id node and then a list of all the key/value pairs defined for that mod. You'd only need MM if you were wanting to overwrite one or more existing translations from another mod and the existing MM syntax works fine for that.

I'm pretty sure it's KAC's persistence. If you look at the alarm in KAC immediately after you make it then the formatting looks fine but one that was created several game sessions ago...

Fair enough but the question was just about using the heads from GPP so I thought it was worth an answer anyway.

Yes TRR woks with replacement heads (Diverse Kerbal Heads in this example)

It's KIS - from the changelog:

It's not supposed to work? I'm having no problem with TRR, JSI ATP and Feline Utility Rover working together:

I've had mixed results. Some of the USI parts like the Karibou and Otter cabs work fine in editor but show stock cut-away view in flight. Others like the Feline Utility Rover (pictured below) work perfectly.

This is part of the firespitter buoyancy module. It controls whether any visible "foam" effects are shown. The part has a built in decoupler. This controls the ejection force like with any other decoupler. I don't think so - again this is from the FireSpitter plug-in. It only has effect if the current body has an ocean and the part's altitude is less than 0. Then it's used in the calculation of the uplift from the water. There's a separate ModuleBounce supplied by SXT for surface impacts with airbags.

It's been spun off into a separate mod:

FYI: That link is to PathFinder The DeepFreeze update is timely thanks. I'm just about to send out a long range colony ship and I was hoping to use the DSEV part.

You ran the 32 bit version and it used up all its available memory space (mods can need a lot of RAM) Error occurred at 2017-06-24_073908. C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP.exe, run by Dave Bowman. 32% memory in use. 0 MB physical memory [0 MB free]. 0 MB paging file [0 MB free]. 0 MB user address space [1601 MB free]. Read from location 00000000 caused an access violation. Try launching the 64 bit version (KSP_x64.exe) instead. Oh and general advice is not to mod the Steam copy of KSP since it is likely to break whenever Squad release a new update and Steam autoupdates your files. Better to copy the KSP directory out of Steam and mod that version.