Crzyrndm

^^ Pilot Assistant is not an autopilot the same way Mechjeb is, and never will be. The provided control systems remove the repetitive and boring tasks of constantly trimming a vessel which makes long distance flight much more enjoyable. It doesn't remove the player from the pilots seat, you still have to make decisions about when to change direction/altitude/etc., you just don't need to make those decisions at 5 second intervals. tl;dr Tools provided by Pilot Assistant abstract control in order to make flying more enjoyable. That is all Er, I may have gotten side-tracked and completely forgotten about that... (life got busy for a bit). It may or may not happen and it will probably be post 1.0 if it does RE: Waypoint following Target waypoint, set heading target to waypoint heading, make minor course correction every now and again. The only difference is that I leave you to make those course corrections (very minor correction with control being based on direction)

That looks to be a bad interaction with Symmetry Action fix, possibly only 1.7e (it's the same error as this one here reported for a version which Claw pulled after two bug reports) If you have the 1.7e version, try using 1.7d (the current release). Else, try removing the symmetry fixer altogether. EDIT Using 1.7d should fix it. There is a check to gracefully fail for that error that was not present in 1.7e

I don't see any reason that couldn't be done (read: it's relatively simple to implement). The main issue would be coming up with an appropriate conversion between torque/momentum capacity (the tweakable parameters) and mass/cost/EC usage/bleed rate/etc (dependent parameters).

I would say the plugin is about as done as it's going to get, so go ahead.

Can I get this thread shifted to the addon-releases subforum. Thanks in advance

v1.6 Fixed Torque somehow ending up negative Fixed nullref on entering the Flight scene for the first time Removed a bunch of unnecesary logging

Version 1.5.4 Improvement: SSAS pitch and yaw unlock is only synchronised if the bank angle is greater than 5 degrees. Single axis inputs below that threshold only unlock the axis the input is directed at Change: Reduced Pilot Assistant velocity setpoint sensitivity to throttle input by 60% to improve ease of control. Relatively minor update, mostly just a whole lot of cleaning up code. I have no active development targets at this time so I'm not expecting to have another update to this mod before KSP 1.0.

Version 1.5.3 Improvement: SSAS heading control locks to a direction (the same system as Assistant Heading control) Improvement: Pilot Assistant lets raw heading and roll inputs through while landed with no alterations. Massive improvement in handling of takeoff/landing procedures Improvement: Pilot Assistant dual heading displays now show the current target heading and the heading difference to make it easier to turn through a certain angle in polar regions Improvement: Update buttons for SSAS now activate the associated axis Change: Yaw input delay now defaults to zero. Can be changed in the options if needed. Fix: Input regions for Pilot Assistant no longer retain focus after commiting changes Lots of little polishing features for SSAS this update as well, first time in a while I've had an update focusing entirely on it and it was noticeable...

Since 1.5.0 Pilot Assistant is using great circles for it's heading control, the next update (which I'm just ironing out the final kinks in) will give SSAS the same functionality.

Poke the CKAN devs about it. They could just edit 1.3.1 to be 1.3.8 or similar (or make a pull request to that extent)

SSAS vs. Stock SAS Stock SAS does something very simple, it locks to the direction you are currently facing, irrespective of how far you travel or where you travel to (eg. a vessel engaging SAS facing prograde at periapsis will be facing retrograde at apoapsis). SSAS (aka Surface SAS) also locks to a direction, but that direction is relative to the planet surface (eg. a vessel locking to prograde at periapsis will still be pointing prograde at apoapsis). Because of this simple difference in behaviour, Stock SAS will appear to continuously pitch up as you travel around a planet while SSAS will always hold the same pitch. The only other major functional difference is that the roll axis unlocks seperately to pitch and yaw when you give control input (ie. you can pitch without affecting the locked bank angle), plus a few minor things like being able to only control pitch and roll and leaving heading floating (useful for banked turns with SAS). PS: I doubt the interface is obvious to anyone that hasn't used it much. Flight sims (and real aircraft for that matter) hide all the configuration options because no/minimal tweaks are needed when the vessel is always the same. In addition, the Stability system (what KSP refers to as SAS) is a very low level part of the overall system (similar to how it is in Pilot Assistant. There's a whole lot of logic before it reaches the raw pitch/bank/yaw control). KSP is the first time I've ever seen it used as a complete system outside of some microController programs for very small operations. Enabling SAS or SSAS while Pilot Assistant is functioning Pilot Assistant will always have the final say on how an axis responds and completely overrides both flavours of SAS when it does so. However you can combine systems that don't overlap, such as having Stock SAS controlling pitch and use Pilot Assistant's Bank/Yaw control for steering. Basically they peacefully coexist, but any conflicts always resolve in favour of Pilot Assistant. EDIT Forgot to mention, SSAS only really works when you aren't trying to go vertical. Not exactly an issue as it has no advantage at all when travelling along a vertical direction.

I normally budget around 60-65 units of LF per turbojet per 10 minutes of flight time (fuel usage per engine at full throttle sits between 0.08 and 0.11 units per second IIRC, with the most efficient altitude being 5200). Rockets to orbit/deorbit I normally pack around 1000-1200 m/s of dv (typically transitioning at 1400-1450m/s and 25km) depending on rocket TWR and planned ascent profile (some craft can't pitch up very hard so you get hit with a bit more drag).

Without the delay it defeats the purpose of knowing exactly how far you want to turn (delay is configurable btw. You can zero it if you want to try that). Tomorrows version of the UI will be a lot more helpful in that regard (probably, still not quite sure I like how it's presented, but it's getting better). I should manage to get the same system working on the SSAS heading by tomorrow as well, since there doesn't appear to be any issues with the control method itself. Yay for no more issues with polar navigation.

Version 1.5.2 New: Added configurable delay to heading alterations made via. Yaw Left/Right controls. Improvement: Pilot Assistant transition logic improved. Engaging controls and toggling modes is significantly smoother Improvement: Vertical speed measurement improved (again) as detailed here Improvement: Split heading target input/readout into two fields. The left field displays the current setpoint, while the right field is for displaying the final target (NOTE: There is a slight error here. I meant to make the right hand field the target entry field as well). Improvement: Control and data lockouts for vessels moving at a surface speed < 1m/s Fixed: Direction lock now engages instantly for all methods of target entry. Entering manually previously did not lock for a noteable period of time. With the vertical speed changed from Squads measurement to my own I can now guarantee that the altitude hold is capable of attaining and matching a given target to insane levels of accuracy and precision at any height or velocity. Previously errors in Squad's calculation were causing small (but noticeable) offsets to occur with no apparent explanation. The VS calculation method has changed a bit since this data was recorded, but it clearly shows a non-zero VS being reported from Squads number for a constant altitude PS Altitude variation of less than +/- 15mm over a period of 5 minutes. Me likey The split heading readout and delay was a last minute attempt to address this, hopefully it helps a bit. I'll sort something better out tonight EDIT After fiddling around with the dual heading displays a bit more, I think I've got a more intuitive version worked out. The left side will show the current target or the turn amount if yaw input is waiting on the delay The right side will always show the final target and will be used for manual entry (as that is a final target). When yaw intput is waiting on the delay it will show the what the final heading will be after the input is commited.

Larger vessels with a bit of trimming can match the curvature of a planet to their nose down rate over a longer period of time. The extra "stability" is mostly down to the reduced rate of CoM shift and often a bit of luck with trim/altitude/airspeed (the CoM shift could also be self stabilising, but that's fairly rare)

I don't have any ideas about what the cause of your issue is, but there are a few odd things in that script 1) Identical code in OnAwake and OnStart Use one or the other, there's no point using both for the same purposes. My intepretation of Awake in that it exists so you can ensure variables are initialised before other modules go looking for it in Start which just isn't an issue here 2) The delay code in Update What is that for? If you want to skip a frame between running setColor, toggle a boolean or use a coroutine. That delay depends on Time.deltaTime being exactly what you expect it to be for any user which is not guaranteed

KIS will be kerbal inventory system

Improved by using the part velocity (herp derp), still offset. I realise that zero vertical speed == a circular path in KSP. My comment was aimed at whether the fact it is a circular path is throwing off whatever calculation is used for rigidbody.velocity (or possibly something to do with Krackensbane). For example, if the direction is determined from the last position to the current position, that would be rotated slightly upwards. That would make the correct upVec exactly halfway between the current and the previous one. EDIT Initial testing is giving very good indications that the ^^ was exactly the issue. lastUp = vertical; vertical = (thisVessel.rootPart.transform.position - thisVessel.mainBody.position).normalized; velocity = thisVessel.rootPart.Rigidbody.velocity + Krakensbane.GetFrameVelocity(); vertSpeed = Vector3d.Dot((vertical + lastUp) / 2, velocity); // VS calculated from upvec bisecting current and last upVec EDIT2 Unless any other suggestions come up, I'm going to call this solved. The ^^ calculation matches the changes in altitude with no notable offset (9um/s over 3500 samples), and Squad's calculation was already identified as this lastVertical = vertical; vertical = (thisVessel.rootPart.rigidbody.position - thisVessel.mainBody.position).normalized; vertSpeed = Vector3d.Dot(vessel.obt_velocity, lastVertical);

Is one set of updates overriding the other? I thought I set it up so they would both take effect at the same time.

Well, I know where Squad's number came from now. vertSpeed3 exactly matches that of vessel.verticalSpeed (calculating the up vector through the root part, offset by one frame). Neither calculation meets the requirement of zero vertical speed with a constant altitude. lastVertical = vertical; vertical = (thisVessel.rootPart.rigidbody.position - thisVessel.mainBody.position).normalized; velocity = thisVessel.obt_velocity; vertSpeed2 = Vector3d.Dot(velocity, vertical); // worst offset yet, +0.1m/s vertSpeed3 = Vector3d.Dot(velocity, lastVertical); // same as vessel.verticalSpeed I wonder if this is all down to a constant altitude not being a straight line?

Precision isn't amazingly important, accuracy is. Any constant offset just cannot be tolerated Don't worry about writing the code, with a possible cause identified I can handle the logic

Version 1.5.1 Fixed bad calculation of vertical speed for Pilot Assistant if SSAS was armed

Well thats a bug and a half and I'll be dammed if I have the faintest clue whats causing it. E: Found it, fix shortly

Sounds like the analog version of this system (or much closer to it. The update frequency of a modern digital system would be measured in kHz, compared to the sedate 30-60Hz here) I don't know about that. Everything is a straight line so it's a whole lot more intuitive than the oddities that would crop up with the original system. It also works better with anything that provides a heading to a target (eg. waypoints) because if that value is used as the starting value in the heading control it will continue to point in the correct direction.

v1.5.0 release Heading control locks to a direction. NOTE: Because heading is not constant for a given direction, the target heading will change over time (this is particularly noticeable in polar regions) Smoothed engagement of heading control based on current angle of bank Fixed: Vertical speed not being measured as zero at a constant altitude Fixed: Heading control uses prograde heading instead of craft heading in order to manage sideslip