xEvilReeperx

Yes, I've tried every way I can think of to get into the persistence file (as it's saved) and the only way that worked was using a ScenarioModule. I posted about it here.

You might simply be trying too early. I just had a similar problem: I wanted use ResearchAndDevelopment.GetScience() in a MonoBehavior's start function during flight, but it returned null (likely because RnD.Instance didn't exist). Creating a coroutine that waited for RnD.Instance to exist solved the problem for me.

I believe the correct way to do this is to invoke Part.PromoteToPhysicalPart(), else your rigid body will have a bunch of default properties and won't act like the AvailablePart you spawned it from in terms of physics Edit: At least I'm 100% certain this is the case for parts that don't normally have a rigid body, like cubic struts and other similar pieces that have their transforms attached to a parent instead of a breakable joint

GameEvents.onPartDie (since onPartExplode doesn't seem to provide the exploding part or position of the explosion) and GameEvents.onSplashDamage might be of interest as well.

If you can make PartModule work, that's absolutely the way to go. I've never worked with IVA stuff so I had no idea you could use PartModules there. As far as I know, nobody has managed to get custom KSPField types to work sadly. I'd love to be wrong.

The example code bothers with flightIDs for exactly that reason. Edit: I see what you're saying now. What prevents you from making relevant InternalModules share a common interface? That shouldn't matter. My understanding was that they don't receive OnLoad/OnSave at all, but even if they do and calling them again from ScenarioModule somehow screws things up, you could just move your persistent logic to a function unique to your class (CustomLoad/CustomSave) and then call those functions in ScenarioModule:OnSave instead.

I know, but I couldn't find any other decent way to get into the persistent file. When you say "keep its data" you actually mean just resolving which ConfigNode goes with which internal module, right? You shouldn't need to keep any InternalModule data in there. Aside from writing the load function, InternalModuleSaver is complete.

flightIDs don't change between loads (but constructID does). I don't know if they're globally unique or not. Probable but unconfirmed. As for finding parts which no longer exist, that might not even be necessary depending on how the game saves. But you could easily look through existing vessel guids and part flightIDs; if you don't find the one you're looking for it's gone. Here's some untested code I hacked together that might help you decide if you want to try this route. Note that I've never worked with Internal* stuff before so it might need fixing. It it works, every time the game saves, your module's OnSave should be called. If you're really lucky, KSPFields might work as well. [KSPAddon(KSPAddon.Startup.Flight, false)] public class InternalModuleSaverScenarioCreator : MonoBehaviour { public void Start() { bool scenarioExists = !HighLogic.CurrentGame.scenarios.All(scenario => scenario.moduleName != typeof(InternalModuleSaver).Name ); if (!scenarioExists) { try { Debug.Log("Adding InternalModule scenario to game '" + HighLogic.CurrentGame.Title + "'"); HighLogic.CurrentGame.AddProtoScenarioModule(typeof(InternalModuleSaver), new GameScenes[1] { GameScenes.FLIGHT }); // the game will add this scenario to the appropriate persistent file on save from now on } catch (ArgumentException ae) { Debug.LogException(ae); } catch { Debug.Log("Unknown failure while adding scenario."); } } Destroy(this); } } /// <summary> /// The main purpose of this module is to get our paws on the game's ConfigNode /// being saved to so we can store our own data in there as well. /// </summary> public class InternalModuleSaver : ScenarioModule { public override void OnSave(ConfigNode node) { base.OnSave(node); if (HighLogic.LoadedSceneIsFlight) { /* Node structure (as I would envision it) * * SCENARIO * { * name = blah // here by default * scene = 7 // here by default * * VESSEL_INTERNAL // keep internal modules for each vessel organized separately * { * guid = vessel's guid here: if we can't find the vessel it's gone and none of these * inner nodes are relevant * * YOURINTERNALMODULE // an instance of your module that combines identification and data * { * flightID = part this module is attached to (may be unnecessary) * propID = id or other way of identifying which InternalProp the module is attached to * * DATA * { * your stuff here * } * } * } * VESSEL_INTERNAL {} etc */ foreach (Vessel vessel in FlightGlobals.Vessels) { ConfigNode vesselNode = node.AddNode("VESSEL_INTERNAL"); vesselNode.AddValue("guid", vessel.id.ToString()); foreach (Part part in vessel.parts) foreach (InternalProp iprop in part.internalModel.props) foreach (var yourModule in iprop.internalModules.OfType<YourInternalModule>()) { ConfigNode internalModuleNode = vesselNode.AddNode("YOURINTERNALMODULE"); internalModuleNode.AddValue("flightID", part.flightID); internalModuleNode.AddValue("propID", iprop.propID); yourModule.Save(internalModuleNode.AddNode("DATA")); // save or OnSave? maybe try both } } } } public override void OnLoad(ConfigNode node) { base.OnLoad(node); // reverse OnSave here } }

If it needs to be persistent per-save (so different for quicksave/persistent.sfs), the best way I've found is subclassing ScenarioModule and handling your business in the OnSave/OnLoad functions there. You'll still have to deal with matching the data to a vessel and part but that's easily done with the vessel's GUID (id) and part flightIDs

I'll third blizzy's tutorial. I went through it three or four times and rendezvous was never a problem again. I went through it even more times to practice docking, too. It'll make you much better at intercepting planets and moons as well

This looks like something TaranisElsu (iirc) was working on a few days ago. You might look him up on IRC to see if he made any progress on it

Looking around in Add-On development forums or searching google didn't lead you to this stickied post?

You're only retrieving the first result in this snippet. If this is the code you're using, then you've forgotten to add all the other results in resources

If those parts had no meshes, their MeshRenderers wouldn't be rendering anything. Build this and watch the chaos unfold: using UnityEngine; namespace MeshFilterEditorTest { [KSPAddon(KSPAddon.Startup.EditorAny, false)] public class MessWithEditorMeshes : MonoBehaviour { public void Start() { GameEvents.onPartAttach.Add(NewPartAttached); } public void NewPartAttached(GameEvents.HostTargetAction<Part, Part> action) { if (action.host) { Debug.Log("Found action host: " + action.host.ConstructID); if (EditorLogic.fetch.ship.parts.Count > 0) { Part sourcePart = PartLoader.Instance.parts[Random.Range(0, PartLoader.Instance.parts.Count - 1)].partPrefab; MeshFilter sourceMf = sourcePart.FindModelComponent<MeshFilter>(); MeshFilter mf = action.host.FindModelComponent<MeshFilter>(); Debug.Log("Found mfs? " + (sourceMf != null ? "found sourceMf" : "") + (mf != null ? " found mf" : "")); mf.sharedMesh = sourceMf.sharedMesh; } } } } }

Here's what I came up with, it should get you there foreach (Part part in FlightGlobals.ActiveVessel.parts) foreach (PartModule module in part.Modules.OfType<ModuleEngines>()) { ModuleEngines engine = module as ModuleEngines; // propellant type foreach (ModuleEngines.Propellant propellant in engine.propellants) UnityEngine.Debug.Log("Engine '" + part.name + "' uses " + propellant.name); UnityEngine.Debug.Log("Can you shut it down? " + (engine.allowShutdown ? "yes" : "no")); UnityEngine.Debug.Log("Can you change its throttle? " + (engine.throttleLocked ? "yes" : "no")); }

Part.FindModelComponents<MeshFilter>();

I'm glad it's helpful! Have there been any issues so far? Especially on non-Windows platforms

This is a little something I put together to enhance the editor. It applies a shader to a part (or group of parts) when you mouse over its staging icon. Great for quickly locating a part you're setting up staging for No more fiddling with the camera (well, a lot less) so you can find the radial decouplers you're looking for while setting up asparagus staging Highlighted part will be visible through other parts, such as fairings or on the other side of the rocket VAB/SPH Color can be changed in settings.cfg VERSION: 1.0 (rebuilt for KSP 0.23.5) HOW TO USE: Mouse over the staging icons in the editor. Grouped items will all be highlighted. Expand the group and mouse over each item to highlight them one at a time. INSTALLATION: Extract the zip into your GameData folder LICENSE: GPLv3 SOURCE: Available here KNOWN ISSUES: Highlighted parts don't cast a shadow Single part craft won't be highlight-able until you add a second part THANKS TO: The KSP modding community Bruno Rime for his free Xray shader If you encounter any issues, please provide as much information as you can and I'll have a look. DOWNLOAD (updated April 7) Update: Sometime between 0.22 and now the XML config broke. It's been replaced by settings.cfg. No other changes

The software owner already has all rights to his works. S/He isn't bound by the terms of the licenses s/he issues. It'd be thrown out of court immediately. Edit: beaten! Gah

May I suggest this in-game tutorial? I too had the most awful time with rendezvous and by the third time I went through the tutorial I was spending more time practicing RCS translation at the end than the actual interception part

Have you seen PartCatalog?

Assuming those are retracted solar panels I see near the command pod, you can EVA a kerbal and extend them to begin recharging your batteries. The moment you have some charge you'll be able to re-enable those other batteries and you'll be in good shape again. Why have cheat batteries in the first place though? Electric charge is plentiful. The only time I ran out was when I forgot to extend the panels on my first unmanned ship on its way to the Mun, and that turned into a learning adventure that involved a rescue mission and my first manual intercept Edit: actually now I'm not sure. Surely there's at least one electric battery you didn't disable somewhere? How did you run out otherwise?

Unity uses PhysX 2.8, which supports GPU acceleration only for cloth, fluids and soft bodies. KSP won't be able to make use of GPU accelerated physics. PhysX does support multithreading, but apparently Unity3D has disabled it. You'll have to ask someone more familiar with Unity3D why that is

Great mod! The free, open source tool Spacescape would probably go great with this.

It works for me unless I load a quicksave. After that, the hex map is broken. Seems like its scaling gets inverted, so when you zoom out of a planet you can see the hex grid collapse in (and past it) to disappear, zoom in and the opposite occurs. Have to restart the game entirely to get things working again once it happens