Crzyrndm

If you want to set it globally for all engines on the craft, that's very simple. In your fixed update loop, you can set the throttle percentage using: FlightInputHandler.state.mainThrottle = [COLOR=#ff0000]<0-1> float for throttle percentage on the active vessel. Will retain the value if your code is not constantly updating[/COLOR] More complex vessel control (other vessels and really any further control input) are typically handled through callbacks like these (there are 4 in total, the linked two plus OnAutoPilotUpdate and OnFlyByWire. They are always called in the same order and which to use depends on what you need). The function you give the callback is passed the current control state and you can then modify it before it goes to the next stage (replacing the FixedUpdate loop in some cases) (Example usage). You can get the same effect most of the time by directly assigning to the vessel.ctrlState if you just want to keep things simple. Assuming you don't want to adjust the thrust limiter, the least hacky way of modifying throttle on a per engine basis would involve creating an engine subclass where you update either the output thrust or the maximum thrust with your custom calculation. Doing it outside the engine module just sounds like a PITA

Should make a note here that while the IEnumerator type comes from one of the general C# collections libraries, Coroutines are Unity functionality for classes inheriting from MonoBehaviour.

You should always be using fixedUpdate for resource consumption since you need to scale it by fixed delta time to get a rate per game second. The rate of calls to Update (using delta time) is totally independent to how fast the game time is moving so if you use that you will get resource consumption that varies depending on the vessel and what you are doing with it

part.Resources.Get(resourceID).amount // For the current quantity in a part part.Resources.Get(resourceID).maxAmount // For the maximum a part can hold part.GetConnectedResources(resourceID, flowmode, resources) // returns the quantities of all parts that a part can request fuel from given a flowmode (by reference, "resources" is the resulting list) . The sum of the amounts in resources is the total quantity accessible You can get the resourceID from the instance of PartResourceLibrary by name or from any propellant / resource you have access to

What is your problem with part.requestResource? You tell it which resource to use and how much of it and it returns the amount you actually consumed. The only way I can think of to go wrong is forgetting to scale the request quantity by fixedDeltaTime and getting a consumption rate that is much higher than intended

Will have a fix committed shortly. Probably won't do a "release" until after 1.0.5 hits though Thanks for the confirmation. The retuning for speed/altitude bit sounds to me like you aren't using dynamic deflection (the problem was the driving force behind its creation after all)

It's a modification of Pilot Assistant, and Pilot Assistant only cares about the aero system in that it changes the dynamics of the plane (ie. some retuning may be required when shifting between the two. It is developed 90% in FAR though...). In terms of control consistency, this is a pretty good demonstration (note the lack of port control surfaces which were lost mid flight when the wing dipped into the water in a turn)

If I remember correctly, the bleeding into the other areas is only the first time you launch at a new resolution. There are blackout panels to prevent that occurring but they get initialised before KSP changes the resolution or something like that The rest of it is totally fair. This was hugely experimental and there are just too many thing that I can't fix for me to justify further development (now, if I could get the editor to work properly, that would be a different story...)

@csx23 What the mod does is try to force KSP to display in only a subsection of the space designated to it (the idea being that you can move information displays from mods into the unused space which is normally inaccessible). *If* you are only going to be flying ships, it does this job almost perfectly (there are a few windows that still show up in the centre of the assigned space rather than the used space). The main problem is the editor, no matter what I tried, it was heavily distorted and the mouse position didn't sync with what was happening on the screen. IIRC, I had to resort to dropping the resolution back to only the "used" area inside the editors to make them somewhat usable. Issue 1: will probably be a non-issue with quickgoto. It's just the button that disappeared Issue 2: I can't remember what this is like in the released version, see above for the workaround I was messing with Issue 3: Some of the UI elements will show up relative to the assigned space (eg. the esc menu in the flight scene will always be centered in height and width relative to the assigned space). For the most part, it's just a little awkward when things end up crossing a screen edge @tryinghard 1) Setup KSP to run in windowed or borderless windowed mode (not full screen). 2) You need to go into the KSP settings and set ResX and ResY by hand to the size (eg. 3840x1080 for two landscape 1920x1080 monitors side by side) 3) The settings cfg sets up the size/position of the display area inside that window. The default makes the display a 1920x1080 display located in the top left corner. (leaving the right half blank if you used the above resolution

So basically, you want stockish throttle control with PA's adjustable sensitivity and direct entry. Sounds like a good idea to me.

The defaults won't automatically change if your resolution changes, but you can change the position and size of the control area ingame by opening the settings window (modifier + O by default, Modifier is LAlt on Windows). The window represents the control zone (IIRC, while control is not active you can move/resize it, and when its active it goes blank to use for visualisation if you wanted to. That sounds closer to http://forum.kerbalspaceprogram.com/threads/92586-1-0-2-RKE-On-screen-Joystick-%28and-Fine-Keyboard-Controls%29-v1-2-1-May-11

That won't have any effect if FAR isn't present. The normal reason for this to happen is when you have used FAR in the past and then removed it using CKAN. Because CKAN doesn't remove the FerramAerospaceResearch folder, the module manager patches for FAR still get applied. The solution is just to delete the FAR folder from GameData

Any of the PA control modes will work pretty much identically since they all only cut in once the craft leaves the ground (Once in the air, for pure stability: bank > direction > heading). From memory SSAS will retain control of the ailerons while grounded (which I should probably let PA do to a degree). Optimum stability is probably both, since SSAS can hold it level on the ground and PA has the yaw control once in the air

Both will see the inputs since they aren't consumed, and the locks are identical to PA's so they get added and removed at the same time so overlap shouldn't be an issue (they even use the same ID's since they are remnants of my work >.>) The lines dealing with the locks should be easy to find. There are boolean values to indicate when the locks are engaged (x2), const strings for the lock ID's (x2), and a couple of lock/unlock calls that look like this

Not at all. I find it downright awesome that someone took what I originally made to make up for the deficiencies of flying by keyboard, and used it to make up for the deficiencies of landing with limited planning and navigational aids. Particularly when you did a decent job of it (if I'd tried to do something like this it would have ended up totally half-assed because I didn't really want it.)

Hahaha, someone actually went and did it (). Well done for deciphering my sporadically documented code and a job well done on the waypoint system and its backend. Just taking a wander through the source, this was a bug I recently fixed caused by the "invert output" field in the PID controller being applied one step too early, and the VSpeed measurement correction should be updated for accurate altitude tracking during supersonic flight (I may be a bit obsessive about precision and accuracy of information... Garbage in equals garbage out and all that). If you have any questions feel free to shoot me a PM

http://forum.kerbalspaceprogram.com/threads/117613-After-reverting-to-SPH-VAB-the-parts-don-t-show-%28

I can confirm that the version from ferram's github works with B9 PWings. I can't remember if the latest release or the one before it was the one which wasn't voxelising the internal section of the wings, but it is quite possibly the latest.

Thermal Monitor adds part/skin temperature and heating rate to RClick menu instead of just the raw values

If you get the .dll from my github you can use the same methods as PWings. The current release version is context menu only I could package up a drop in patch tonight (after I add in the RF/MFT module that doesn't even appear to be in my version for some reason...). I haven't heard from or seen Bac9 recently so I don't know when an official release will happen Patch.cfg was accidentally included in the previous release, it can (and should be) deleted. I'll include a blanked file in the patch to overwrite it. EDIT Full Download There's still the nullref being thrown by the engineers report that I can't locate but: this fixes the issues caused by patch.cfg, adds the (updated) original PWings manipulation method using mouse movement and keys, the mass modifier and probably a few other little bits and pieces

It's on my branch/fork.

If you could verify that this fixes the docking issue that would be great

@Bac9 RE: The wings not working after uninstalling FAR via CKAN. Instead of targeting the patches at "FerramAerospaceResearch" (the folder and main .dll name), either of ferram4's secondary .dll's can be used (ie. "ferramGraph" or "Scale_Redist"). That way it doesn't matter when the folder remains because the .dll pass it's tied to is gone

v1.11.10 Fix minor error with preset loading crashing the information gathering and control callbacks

Easiest way is to just use an identical setup for top and bottom of the wing panel. AFAIK the root cause of the issue is that the "top" is not defined when oriented like that and so it semi-randomly picks a side to use (although it should really pick the same one assuming it's *exactly* the same orientation). Make sure you built the whole wing on the same part, the only reason I can think of is that they're built on symmetry counterparts => different orientation => different top