Crzyrndm

distance is meters, mass is (metric) tons, and force is kN

1) Yes 2) Timewarp.(fixed)DeltaTime is the timestep for (fixed) update which will be the time any force application will happen over 3) all partModules can override OnFixedUpdate (and anything physics related should definitely be done in the fixed update cycle)

The assumption there was you'd replace VesselModule with your derived class (of which there will only be one per vessel). A list of vesselModules isn't all that useful, but getting the one I need is Would I be correct in saying they only get added to non-debris vessels? I'm not always seeing enough instances to cover every single vessel that I'm launching (or don't think I am atleast, I could just be miscounting) On another note, is there a way to force an engine into a flameout state (or equivalent) without depriving it of a propellant? (E: nvm, careful use of EngineIgnited should do the trick)

Puttering around in MFI and FAR solved that one Vessel v = GetComponent<Vessel>(); // from a vessel module VesselModule vm = vessel.GetComponent<VesselModule>(); // from the vessel reference Very handy class to have, already wishing I'd investigated this about a month ago >.<

Vessel Modules. What stock ones are there (other than FlightIntegrator), what should they be used for, and how do you access them (there isn't a public list in the vessel class for them)? From a quick experiment they get created automatically on flight start (and I'm assuming whenever another vessel is created). If there is an instance per loaded vessel that would be really useful for several things I'm working on, except neither the vessel or the vessel module have a public reference to the other so I'm not sure of the best way to link up (or even if using VesselModule is a good idea).

15.3 fixed the issue with the port facing wings being too large

Not at the moment. Module specific data is still waiting on a few other improvements

I'm still trying to locate the cause of that one. It's probably something clearing that shouldn't be, I just haven't been able to nail it down

Version 1.11.3 Fixed another stupid typo (note to self: pay attention when cleaning up code...) Throttle settings from the speed control module are permanent Deactivating the Asst vertical control releases the last pitch input over a period of 10 seconds if an atmosphere is present

IIRC there was a thread around showing that atmospheric density with 1.0 was actually lower in the upper atmosphere than it was prior. Atmospheric drag being different shouldn't surprise anyone given the entirely new system that doesn't just assume a coefficient of 0.2 for everything. The decreasing thrust at altitude is to my knowledge approximating atleast two things. The decreasing mass flow rate and the change in compressor efficiency. Combustion engines can't run on the extremely thin air in the upper atmosphere so it needs to be run through a compression stage first to bring it into operational densities. That compressor is going to have a limit past which it can't do it's job effectively enough to feed the engine even if the total flow would be high enough. Larger objects heating up faster is actually somewhat to be expected. Larger objects generally experience a lesser drag force per unit mass (mass is ~cubic with size while frontal area is ~size squared) leading to them decelerating slower and carrying greater speed into the denser parts of the atmosphere. Heating rate is most likely proportional to atleast speed2 if not a higher power, so even a slight increase in speed would have a dramatic impact on the generation of thermal energy. Focus that into only a couple of parts that receive the brunt of the airflow and you get more explosions with the heavier vessel

The GUI systems the devs refer to are not really relevant to plugin developers unless trying to edit stock UI elements (which is normally a huge PITA). Creating a completely new UI element goes through the Unity legacy GUI scripting system which lives in OnGUI, or if you're feeling really adventurous the new Unity system that Squad are shifting all their GUI to (which isn't particularly script friendly, although in syaing that, GUI scripting sucks either way). Tutorial, and the only KSP plugin example AFAIK is the building shortcut buttons)

Thats what happens when the part selection tabs don't get initialised properly. You can (or atleast could in 0.90) see it briefly when entering the editor (eva kerbal, flag, and the asteroid are just parts that are normally not visible) @beabop I no longer see the need to strip down an install anymore. Loading times are less than half what they were (used to be 60-90+ seconds just for stock...) and missing parts can be annoying when testing things. If you do still want to remove parts, try deleting the partDatabase file next to KSP.exe

Well at half a million kJ, you'd expect some (rapid) change. Is there any chance that section of code is not being reached (does it print a log statement)?

The change in heading is intentional, it keeps the vessel direction constant (following an "orbit" so to speak). Look up great circle routes for more information. Short term trimming would be easy enough to implement (fading out the last control input over a set period) which sounds like it would cover what you want to do.

You're requesting -5 Ec per physics frame. Multiply it by Timewarp.fixedDeltaTime to make it per second

Is it being called in the fixed update (physics) cycle? How much heat are you adding/removing per physics frame? Are you accounting for "change in temperature" being equal to "change in heat" / "thermal mass"? Nertea is using part.AddThermalFlux for his active radiators so the issue is probably in its usage

Throttle: I should really do something about that... (it's a quirk of how KSP allows control, not a conscious effort on my part) Setting trim: I would rather not mess with vessel trim. There are a lot of players that don't know about it and it can be a cause of great frustration unless you know what is happening and how to clear trim. If you're just looking for a less jerky release I can do that, but trim setting is something I am rather hesitant to do.

Er, it isn't your keyboard. I seem to have missed a negative while cleaning up Version 1.11.2.1 Fix typo causing target to increase when using pitch down keybinding

Version 1.11.2 SSAS heading target is back to being a direction lock Direction lock for both SSAS and Asst is now planet relative which should greatly improve accuracy over long distances

List<ProtoCrewMember> crew = vessel.GetVesselCrew(); // a list of all kerbals on the vessel (for the active vessel, replace <vessel> with <FlightGlobals.ActiveVessel>) Debug.Log(crew[0].courage); // print the courage value of the first crew member in the list Is that what you were after?

That's because the draw queues are part of OnGUI (UI elements), not the scene rendering. One of the functions in the scene rendering section of MonoBehaviour is much more likely to be what you are after

You have declared an array of length 3 (new string[3] so the fourth entry (with index 3) is going to generate an index out of range exception. If you make the array length 4, index 3 is a valid position Yup, just list them all out in Start and OnDestroy Are you actually testing this yet? It would be faster to check this yourself instead of asking every time

Dammit, I've confused myself. I was wrong, each event belongs to an instance of the module so the function wouldn't be called multiple times if you only entered the scene once. Addon type plugin also won't work because you need the part location. Start again from the beginning. Event subscription in OnStart. Check. That's fine because the callback is specific to the module. You need one for each module so the sound gets played in the correct location Event subscription removed in OnDestroy(). Not happening. If you enter the flight scene, leave it, and then come back, that original event is still floating around waiting to fire (with a null function to call because the part module instance it was attached to is dead void OnDestroy() { GameEvents.On*Dock.Remove(<func>); } Event callback checks to see if either of the parts that are undocking are the one it is attached to. Also not happening. The callback will fire for all subscribers, not just the ones attached to parts involved in the event. if (!dockSound.audio.isPlaying && [B]partAction.part = this.part[/B]) // or w/e the part lookup is in the event parameter { dockSound.audio.Play (); } My bad for making things confusing EDIT And now I'm really confused, if the first one worked...

Your answer to that is whether it works as you want it to (which looking closer at it, isn't going to happen because msgsflagplace[3] doesn't exist, valid indices are 0-2)

Well for one, that's going to add the DPFXundock once for every part that has the module every time you enter the flight scene (so if you have 5 parts with the module active, the function will get called 5 times for each time you enter the flight scene on an undock event). Try the KSPAddon type of plugin for which there is only a single instance per scene (simple example), and remove the event in OnDestroy so you only ever have a single event trigger