Crzyrndm

The intention on my part is to fold some of the useful features of this (particularly editing by angle) into the merged pwings plugin (which I can't currently find the link for so...). The only problem with that is that it will require work/time to match the stability of the existing B9PWings plugin so it may not be a thing for a while yet

There will be an update for 1.2. I don't like "encouraging" people to use the pre-release as just another release (ie. it's there for testing, not playing...), hence no mod update until 1.2 is the current release version

Not anytime soon.

It is, there was no problems between 1.1.2 and 1.1.3

@theSpeare 1) Those calls were never "free" (as mentioned by sarbian in the linked post), they just looked like they should have been cached or linked internally in older versions of Unity which caught more than a few people out (presumably why they've been removed) 2) The GetComponent<>() function is a convenient wrapper on a null check to save a few lines of code. ie. T componentRef; // global scope for cache if (componentRef == null) { componentRef = GetComponent<T>(); } // use componentRef... // replaced with GetComponentCached<T>(ref componentRef); // use componentRef...

part.partInfo.name Note: I haven't checked this still applies to 1.2 yet

Finally getting back to this, do you have any pictures of how those vessels are supposed to look, particularly focused on the control surfaces

I just committed it to github

The right click menu does require a refresh in the editor IIRC. I don't remember how though OnGUI is a part of Unity's monobehaviour class (which all plugins can be traced back to). This often referenced page can be quite helpful for understanding MonoBehaviour

vessel.transform.position is only really useful inside the active physics bubble (ie. positions between two relatively close objects). It has no meaning if you're trying to save the position (worldPos3D isn't exactly that great either since while it gives you a constant position, that doesn't matter much when everything else is moving). I would be looking to hold onto the position relative to the planet with something like: (don't trust untested Quats...) double altitude = vessel.altitude; // length of the vector Vector3d upVec = (vessel.transform.position - vessel.mainbody.position).normalized; Quaternion planetPosRot = Quaternion.FromToRotation(vessel.mainbody.rotation * Vector3d.up, upVec); // orientation of the vector // recovery Vector3d planetRelativePos = (vessel.mainbody.rotation * planetPosRot) * Vector3d.up * altitude - (refPos - planetPos);

Thanks for the log, I'll have to fix that one. You have two icon files at the correct size for FE somewhere in GameData that have the same name (most often happened when png files were converted to dds and then the old png not removed) and the assumption was made that the icon name would be unique

AFAIK, it is 1.1.3 compatible. @Calvin_Maclure When 1.2 is *public* I will update it as required

Going to need a log with debug enabled (from restart. Change it either in the space center window + scene change or go to 000_FilterExtensions\PluginData\Settings.cfg and set debug to true)

no

The direction (pitch/heading, no bank) to point towards is a subset of that represented by the vector ( TargetModeSwitch() * Vector3d.forward ). Everything after that is all about making the vessel point in that direction (calculate error on each axis, output control inputs). In TargetModeSwitch, the StabilityAssist->Surface mode is where the pitch/yaw are input as a value in degrees (output as a Quat, then evaluated for control purposes)

Oops, missed that one. VesselData is where I store all the extra bits of information that the control system required for vessel speed/position/orientation/etc. that have to be calculated. Update attitude gets called once per physics frame to keep those values up to date. The vessel control update happens in the calls to "setCtrlState". The function SASControl is a callback that gets called by the vessel every physics frame and hands the function a reference to the control outputs that are to be applied this frame. There are actually three of them now ( <OnPre/On/OnPost>AutoPilotUpdate ) which can be quite useful, but the only one that will reliably overwrite stock SAS is OnPost

https://github.com/Crzyrndm/TweakableSAS/blob/master/TweakableSAS/TweakableSAS.cs#L197-L313 I haven't updated it recently (was intening to port the control core to PA, but never got around to it), but all the maths you'll need is in that ~100 lines (and the majority of that is the various targets...). Outside that, both MJ and ^^ use a PID controller to handle the actual actuation (the maths is just to calc the rotational error :P) The ArrowPointer class is very helpful for visualising vectors ingame Be warned, this is an area where the Quaternion rules supreme. Things can get bent out of shape really quickly so take it slow when making changes

What is it you are trying to achieve? Saturation Scale: Basically just a number that increases the amount of time you can run the wheel for. 10 means 10x as long, etc, etc. Torque Percentage (in order of appearance) The saturation fraction, where 0 is completely discharged and 1 is completely saturated The torque fraction at that percentage. 1 == 100% torque, 0 == no torque, 3 == triple torque. 100% torque is the torque defined by the reaction wheel module Slope in. Used for creating curves, you can leave them off if you aren't requiring precise adjustments Slope out. Used for creating curves, you can leave them off if you aren't requiring precise adjustments

@SpaceCommanderNemo Nearly lost my drink to that one (). Can you try again without the old plugin .dll installed please (everything required is in the GameData for this one, you can just delete the folder prior to install). It does look like the edges are doing something really wacky though

Correct, On* methods will not work when inheriting from a module that doesn't implement them for you (including direct from MonoBehaviour (general partless mod)). and no Fixed update will not store variables for you. You just need to declare them outside the method (loose globals, global wrapper struct instance, global wrapper class instance) int global var = 0; // increments with every call to Update class wrapperClass { // wrapper vars int var1; // wrapper functions void AutoPilotStuff() { ++var1; } } wrapperClass dataClass = new wrapperClass(); // persistent across method invocations and groups variables nicely struct wrapperStruct { // wrapper vars int var1; // wrapper functions void AutoPilotStuff() { ++var1; } } wrapperStruct dataStruct = new dataStruct(); void FixedUpdate() { // not persistent int i = 100; // will be lost when FixedUpdate completes for that frame // persistent ++var; // increase by 1 every physics frame dataStruct.AutoPilotStuff(); // increase by 1 every physics frame dataClass.AutoPilotStuff(); // bundle function and vars for the function together } Only variables declared inside the method are lost upon completion of each invocation (If you're new at this, I would avoid using the struct implementation. There are a few gotchas with it)

Normally I'd go with a wrapper class/struct and a function called from fixed update (function in the class, or just another function for a struct). I prefer to use coroutines for periodic checks (NOT every frame) or as a sort of psuedo-thread for responding to an event over a finite number of frames. Using them to generate additional infinite loops just fragments code that's running on the same events (ie. I like being able to trace all functions that run every frame back to (fixed) update). I'd say that's just my personal style guidelines though. Running an infinite loop in a coroutine is not going to have major downsides so if that works for you, why not.

Latest github version should be doing a lot more than just square boards on original vessels. I wouldn't be loading anything important in the flight scene just yet, but you can load vessels in the editor and see where I got it wrong...

At orbital velocities the physics reference frame is the vessel unless I'm completely misremembering things (switchover ~700m/s, really obvious it's happened if you watch the exhaust smoke behaviour). There is a switchover around 100km (I don't remember the exact altitude) for terrain rendering but other than the altitude I don't recall anything linking the two. I can't think of anything that would cause such a switch, but I would be checking on other related measurements to see if they change at the same altitude on Kerbin (eg. solar velocity, solar velocity less kerbin velocity, velocity direction, acceleration, etc.)

https://www.dropbox.com/s/urp5tqsyljwjodw/GameData.zip?dl=0 Copy over the files in GameData. Blame moments of daft ideas for that one

Without the brackets, yes (see the example, the brackets were me trying to indicate a representative value)