Crzyrndm

Even in cases of CTD, typically this is the one mod makers are after

Logs. That sounds like something fell to pieces and started spamming errors, and I can't do anything without a log.

Sounds like a good idea to me

Well, that's something new...

Ah, missed the bit where we weren't looking at KSP engines. atmosphereCurve { key = 0 300 key = 1 280 key = 9 0.001 } ^^ example isp curve definition from the Twin Boar (key = pressure, ISP). That third point isn't linear off the first->second, and the tangents aren't being used so the first->second point will curve a little as well to keep the curve smooth. The change in 1.0 was to make fuel flow constant and thrust vary based on the fraction of vac_ISP the engine currently had Since thrust is linear with ISP changes and ISP depends on pressure, a non-linear relationship between pressure and ISP makes a non-linear relationship between pressure and thrust (probably nozzle related losses caused b non-optimal pressures causing the non-linearity that equation doesn't account for)

That is definitely not true. Linearity is not at all guaranteed (infact, given how float curves normally look, I'd be rather surprised if any of them were given they aren't using tangents). fourfa: KER calculates exactly what the engine would give you under those cirumstances. It would actually be significantly more complex to try and do it linearly because the samples are already packaged up into "floatcurves"

Parts use ModuleCoreHeat to get Core heat simulation. For examples of it in use, see stock ISRU/Drills, and USI & NFE reactors (IIRC that is.. NFE may not be using it anymore and I haven't touched USI in a while). Plugin stuff, most of the function signatures and variable are fairly self explanatory

None. Window oriented plugin you're looking at something very similar to what I posted 2 above your post. KSPAddon attribute on a monobehaviour, window drawn in OnGUI, lookup Unity GUI or GUILayout classes for documentation NOTE: Unity's new GUI system isn't particularly plugin friendly, so you'll probably want the editor to play with that. However I'm under the impression that requires loading asset bundles which I don't believe are currently directly loadable by KSP

You'd be better off with a nosecone sized to w/e the final attach node is. A larger cone is harmful in stock (larger front face, only partial occlusion of the back face. Doesn't care about any radial parts ever), and under most circumstances is harmful in FAR as well (same reasons, except it actually cares about everything).

if you're using MFT or RF, look up how they are configured. If you're using the release version without RF/MFT, you can't, the fuel types are hardcoded into the plugin. I haven't finished the configurable fuelling on my development version at this time. tl;dr RF/MFT or bust

I would have actually said it just has a lot of trouble with being close to 90 degrees out from it's target, as it's passing through about 100-80 degrees of separation that it suddenly dives off in a seemingly random direction (probably indicates it's using Euler angles or Vectors instead of Quaternions). Even with Quat's, if you do the calculations in single precision the roll error gets really jumpy around 90 degrees (found that one out when I was calculating the shortest roll distance for my SAS mod) Another oddity to note with the current SAS PID modules, the module used for the direction following has damping even when it's only under proportional control. I'd guess this is so the roll controller actually does something without any fixed target, but it does make tuning pitch/yaw for some torque ratio's nigh on impossible.

It's the equivalent of the lift rating from the old aero (wing mass depends on wing area btw, not the other way around. See porkjets post here)

[KSPAddon(KSPAddon.Startup.Flight, false)] public class DrawGravity : MonoBehaviour { public bool inMapView; public void Start() { GameEvents.OnMapEntered.Add(enteredMapView); GameEvents.OnMapExited.Add(exitedMapView); } public void enteredMapView() { inMapView = true; } public void exitedMapView() { inMapView = false; } public void OnDestroy() { GameEvents.OnMapEntered.Remove(enteredMapView); GameEvents.OnMapExited.Remove(exitedMapView); } public void OnGUI() { if (!inMapView) return; // stuff for drawing UI elements // look up Unity's GUI or GUILayout classes } } Should be a fairly good starting point

Anything in particular you're trying to do? I have/know a couple of small ones (KSPAddon, Part Module), but they won't be of much use if you're doing something entirely different

No worries, I was in the same position about twelve months ago when I started on PA. Just have to keep working at it... So to define what you have and what you want: you have a navball reference direction of up / pitch 90 (relative to your navball I'm assuming? ie. it rotates with everything else) you have a KSP vector that corresponds to your navball reference (eg. surface normal) you want to create a vector that matches a KSP vector on the navball (navball space) If ^^ is correct, things are about to get a little curly (in a nice way hopefully...). Transforming one direction to another by a rotation is normally done using Quaternions, and Quat's aren't nice things to try and imagine (particularly if you're already having fun with vectors...). This should be a fairly simple application though // First, calculate the rotation required to go from up to prograde in game space // From: vector from the center of the body through the vessel (up) // To: vessel surface prograde Quaternion progradeRot = Quaternion.FromToRotation(vessel.transform.position - vessel.mainbody.transform.position, vessel.srf_velocity); // Second, use that rotation to translate your *navball* up reference around to the prograde direction in navball space // Quaterion * Vector3 gives a new vector3 which is the original rotated by the rotation the Quaterion defines Vector3 navballPrograde = progradeRot * navballUp; // You can also get a Euler representation of the Quat (just be aware it's only accurate to about 1 decimal place, eg. 180.5 degrees) // from memory it's x: pitch, y: yaw, z:roll, but you will want to check that since KSP is often wierd on that front Vector3 EulerRot = progradeRot.eulerAngles; EDIT If you just want the vector in navball space and don't actually care about the angles, there's a better way than the above. A rotation which can be used for any KSP vector you wish to show in navball space // Calculate the rotation which transforms KSP up to navball up // From: the planet surface normal (ie. planet up / KSP up) // To: navball up / navball reference vector Quaternion navballTransformRot = Quaternion.FromToRotation(planetUp, navballUp); // now we can multiply any KSP vector by that rotation to get the vector in navball space Vector3 navballPrograde = navballTransformRot * vessel.srf_prograde; Vector3 navballRight = navballTransformRot * vessel.transform.right; // etc.

When you say relative pitch and heading from prograde, I assume you're trying to calculate yaw and AoA which Pilot Assistant does here. (I don't see any obvious errors, but maybe another example will shed some light) (ProjectOnPlane) EDIT What on earth is that limit section doing. Vector3d.Angle will always be inside +/- 180 degrees, and since it's relative, shouldn't be exactly what you want?

-.-...

You need to get the active camera/viewport (Camera.main from memory) and use Camera.WorldToScreenPos(Vector3 worldLoc) to translate things to screen coordinates

As blowfish points out, 1 plugin + 2 part packs isn't much different to 1 plugin + 2 plugin/part packs except the extra plugin complexities. From my point of view, a single plugin has the advantage that the two wing types (four types now, separate modules for control surfaces) "know" about each other, and there aren't really any disadvantages for me or the user except an extra GameData folder if I don't end up sticking it one or the other. Chance are this will be post 1.1 before its in general use, seems like there will be plenty of time for testing judging from latest dev notes (if I have to, splitting them is a very easy task)

Just as something to be aware of, any future development on my part for this mod is going to be as part of a new git repository. The reason for this is as I work on both types of PWings, I often find myself porting features from one to the other (eg. the improved fuel switching logic I just added to PWings I will also apply to this mod), resulting in duplicated effort, more possibilities for bugs, etc., etc. By using common base modules, I only need to do this once and it just helps me a lot. There is one possible gameplay advantage (past less bugs and faster feature development...) that I will explore once the merge is more complete, and that is the two wing types being able to work together on one craft (eg. shape matching, edge snapping, joint strength) NOTE: The merger would only apply to the plugin. The packs can/will still be released separately EDIT To give an idea how how much duplication there is, the new root module currently handles all the KSP interfacing, aero, and fuel switching and ends up at about half the code for original PWings, and just under one sixth for B9 (UI related stuff and the texture/mesh math making up most of the extra...). There's still more to go as well... (Updated: 1/3 of the original code didn't become common...)

Maybe not any inverse in that case (haven't dealt with Quat math in a while, but that wouldn't that be 180 when they're aligned?), but yes...

Part.orgRot may do about 90% of what you're trying to do. Something like this (note: only slightly verified Quat math...) Quaternion rotError = part.transform.localRotation * part.orgRot.Inverse(); Should be able to tell you how much the part has deviated from it's original rotation There's also a part.orgPos field that probably can be used the same way. Whether that is relative to it's parent or the vessel would determine how useful it is though Vector3 locError = part.transform.localPosition - part.orgLoc;

^^ Forum thread is the plugin workshop (sig link)

Next update will be breaking craft. Some aspects of how root/tip size were handled were rather error prone so the method is being simplified. Craft will break because originally root/tip scale went from -1 and increased, and now runs from 0. Fixing crafts is a simple matter of adding 1 to all values in (tip/root)scale parameters saved in craft files This applies to any version from github from the time of this post EDIT Testing version. Hopefully not ending up on CKAN (wings carrying fuel most obvious change)

The bad mesh tris was the only useful issue I could pick out (you can ignore the B9PWings exception, it happens when loading the editor scene with a craft already loaded. Haven't been able to prevent it without other issues...) EDIT Well there is one issue, that log is still saying it's KSP v1.0.5.1024