Victor Ludorum

I\'ve been looking at that recently because I\'ve been getting some really weird behaviour in plugins, with bugs appearing or disappearing depending on whether you construct a new ship in the VAB, restart with an unmodified ship in the VAB, or resume an already running ship etc. As far as I can tell, after onPartLoad() is called (during the initial game loading) the game saves the state of the part using serialization. It doesn\'t seem to use the standard C#/.NET serialization routines (maybe Unity\'s built-in serialization but I can\'t find much info on it). Then when a part instance is creat

Make sure you\'ve applied scale and rotation (in object mode, selected everything and press Ctrl+A). I\'m not sure if you\'ll need to re-do the UV unwrap after that. Also make sure your face normals are all pointing out of the mesh.

Yep, that appears to be the bit I was missing. Works great, thank you. I don\'t bother parsing the .cfg manual, just add the needed groups in onPartLoad() and it parses the fx_ lines properly.

Well yes, I\'m guessing those particular groups are standard for all parts, that are fired automatically (?) when those events happen. But some parts (I think only the RCS thrusters at the moment) define custom group ID strings in the .cfg, like rcsGroup0 etc., that I think are triggered manually. If you derive a part from RCSModule, you can list the contents of fxGroups and find those custom IDs there (along with the standard ones). You can also trigger them to fire using [tt]findFXGroup('rcsGroup0').Burst()[/tt] and the like. However if you try to define your own custom fx ID in the .cfg you

Has anyone managed to get fxgroups working? I want to emit a visual burst kind of like when an RCS thruster fires. In the RCS block .cfg, there are lines like this: [tt]fx_gasJet_white = -0.609303, 1.58536, -0.0059382, -0.173648, 0.984808, 0.0, rcsGroup0[/tt] Which I assume is a position and vector, with some kind of ID string at the end. Then Part has a [tt]List<FXGroup> fxGroups;[/tt] which I\'m guessing is a reference to each fx_ line in the .cfg, though I don\'t know if it\'s auto-populated. (Edit: Turns out it is populated, but with FXGroups with ids 'prelaunch', 'activate', act

As far as I\'ve been able to tell, all the Part.on{X} functions marked virtual (Part.onFlightStart(), Part.onPartExplode(), etc.) do nothing by themselves, so they are probably empty. It doesn\'t seem to matter if you call the base function or not, I\'ve yet to see any difference in behaviour.

Consensus on the Unity forums seems to be that the integrator handles the scaling of forces (and torques) so you should not scale them by the timestep. (This makes sense from the way most numerical integration schemes work - the scaling is part of the integration equation, not the input constants.) It would be nice if we had access to the source code of some exemplar parts - an engine, a fuel tank, a winglet, etc. These would be invaluable for plug-in authors to ensure they are doing things the way the game expects.

This is what I\'ve discovered/been using in lieu of any real documentation for the Part class. If you compile this and set is as the module for a part, you\'ll get a debug print (show using Alt-F2) as each member function runs. Note that the commented-out ones will spam the debug console if re-enabled. [tt] using System; using System.Collections.Generic; using System.Linq; using System.Text; using UnityEngine; public class DebugPart: Part { // Called when part disconnects from vessel due to crash etc. - seems to be called first // Also called when part is lowest part of a stack above a d

Man, I was just thinking of how well an Eagle would work as a model in KSP, with its modular structure. I hope you get the chassis/engines and pod parts modelled too. I have to confess I\'m kind of surprised anyone here is old enough to remember Space: 1999. I had the Dinky model of an Eagle when I was little, I used to love it.