Crzyrndm

This could work very well indeed for improving the contracts system. You have a big target that you can choose (eg. "Put a kerbal on the mun") which comes with a group of related sub-objectives (eg. return a kerbal safetly to Kerbin from a mun intercept) through which you can develop and test multiple parts of the mission (ie. can my return vessel survive reentry coming in from a lunar orbit). Wrap several contract types together with objective related goals and create a reason to be doing things like testing an lv-909 in lunar orbit (because you things always hit the fan the first time you try something) Objective: Put a kerbal on the munar surface and return it to Kerbin safetly Suggested sub-objectives: Dock two vessels while in orbit around Kerbin Perform a lunar intercept and return to Kerbin's surface in one piece Put a comsat/surveyor in lunar orbit Land a probe on lunar surface Assorted related parts testing (eg. lv-909 in lunar orbit. Can be used to suggest parts that may be suitable for various mission stages for newer players as well) Nothing stopping you from just throwing a rocket together to complete the main objective, but the sub contracts being tied to a bigger goal makes things like satelites and part testing less random and annoying. Completing one objective could also open up others Establish a mun base (survey contracts to establish a good location, improvements to comsat coverage) occasional tourist contract ISRU base expansion Another advantage would be the reduced annoyance of trying to find a contract that fits your current development goals, since all the contracts are roughly grouped towards a similar aim (assuming you can find a group that's similar to what you want) I guess this is something like a smaller version of tater's suggested strategies (which I can't say I'm a fan of. Long term stuff railroads the player a bit too much IMO) E: Keep parts testing to "explorative" groups that are breaking new ground (eg. getting to the mun for the first time). Long term the player should really be seeing less and less of them, and not testing the same thing in the same general situation multiple times ever.

With the way that KSP handles parts, the upgrade/tech level would have to be specified in the persistence and/or handled through seperate part definitions. Otherwise you can upgrade engines while they're on a solar escape trajectory/landed on Tylo which is just stupid (note that this doesn't mean multiple parts have to be visible to the player)

Can't do anything about a specific way of reloading resetting things (quick load AFAIK resets the flight scene) So there are probably a few things at play here. 1) You're probably running into the angle of attack limiter, and the elevator integral limiter. Under options, toggle on show limits and show control surfaces In the VSpeed controller, increase the output limit slightly (this is the angle of attack that PA is clamped to), and probably increase the integral clamp a bit as well. In the elevator controller, increase the integral limit from 0.4 to 0.6 or 0.7 2) Your tuning constants look to be quite high, particularly Ki and Kd. Rule of thumb: Ki should be ~40% of Kp (increasing Ki increases occilatory tendencies more than the others), and a craft that size I'd expect to see a Kd of ~2-3 Once you have something that works at one altitude/speed, you shouldn't need to drastically alter the balance of Kp/i/d. Just scale the output with scalar when it gets unsteady.

Unless we head into upgrades territory (of which testing could be a part of), then a fully agree with this, cost is the only variable that should be altered on parts (2-3x costs is somewhat overkill. You end up with a 50-66% discount from the players PoV, which is pretty darned high). It would be nice to have another system to tie part testing into. Testing for currency doesn't make a whole lot of sense and just comes across as a grind to the player.

@nightingale Everything still comes down to time being a general factor, which it isn't, and probably won't ever be in stock. Victory conditions could be nice though... Achievements are never particularly meaningful in the first place, and should never be a reason to limit mod use... (that and Squad would be creating their own award system since they don't want to tie themselves to steam).

10% extra maximum thrust, 6.25% higher "0 thrust" speed. If the air/fuel ratio is different it's a stock thing. Rapiers have the a definite advantage on large planes IMO. Once you start needing a rocket mode with a 200+kN of thrust, positioning the rockets during building and dragging enough up through the atmosphere is a right PITA. On smaller planes where you can just add a few small radials and still get a decent TWR, turbo's are obviously superior, but having 10 rapiers on your cargo hauler is far easier than 8 turbo's and a half dozen (+) rockets (and probably more efficient). Once in space I'll still leave it to w/e rocket engine fits the bill, but rapiers make orbital ejection a whole lot easier.

To expand on this a bit more (which I should have done initially), XCOM:EU uses investing in workshops to decrease production time and costs, laboratories to accelerate research, power generators to keep everything running (You need space, power and money to build new things), the foundry to upgrade and build stuff. Possible KSP equivalents: Investing money to get cheaper rockets in the future (maybe broken down into fuel discounts, manufacturer discounts, etc.). Invest in the other facilities (gradual increases in their capabilities instead of the huge jumps we have at the moment with huge upfront costs involved). Visual upgrades only at certain levels Parts upgrades, retrofitting our new expertise to older parts. This would require having earlier versions with lower capabilities than what we currently get Then the admin building also starts to live up to it's name... EDIT Hmm, nightingale's earlier post is heading along a similar line, although a bit less program management related I think

Thinking about XCOM:EU and strategies, why don't strategies take after the XCOM base construction a bit more. In particular the investment in the building of laboratories and workshops which gives you benefits later on

Switch over to rockets wouldn't normally be much past that point (some of my lower TWR and L/D planes ignite at 1300m/s). You might be able to do a little better if you drop down a little to a point where your AoA is a little lower which lets you accelerate (17 degrees produces enourmous amounts of drag, as made obvious by the low L/D ratio), which lets you get higher with lower AoA which means you can go faster (I hope that made sense...). You won't be seeing the periapsis break the ground in FAR though, faster jets are only really 1500-1550m/s. That p-fairing/rocket combo would get tossed if it was in my VAB. Because it's wide and then reduces down sharply it's going to be a right PITA to launch (needing a silly shallow turn which just throws away comparitively huge amounts of dV). If you can't/don't want to make that payload narrower, place the fairing base lower down under the tank (IIRC, they crossfeed) so that the diameter reduction can be much shallower. Make it taller at the front for the same reason (the shallower the gradient where cross section changes, the more stable your rocket will be. EDIT The point of the second paragraph I need to emphasise: Throwing a fairing on something doesn't automatically make it aerodynamic. The fairing has to be more aerodynamic than what it's trying to cover which sometimes means it's best to leave it uncovered.

When you download and unzip a mod, most of them will have a GameData folder inside. In steam/steamapps/common/kerbal space program (KSP install directory, shortened to KSPdir from here on), you will find another GameData folder. You merge the GameData folder from the mod with the KSP GameData folder and the mod is installed. The final directory structure will be: KSPdir/GameData/ModDirectory (NOT KSPdir/GameData/GameData/ModDirectory) Mods which don't have a GameData directory in the first or second level should be added to GameData instead of merged with GameData (so you end up with the same final directory structure as above) Module Manager .dlls are the one mod that shouldn't get a folder of their own. They always reside in the GameData directory (eg. KSPdir/GameData/ModuleManager.2.x.x.dll) Some mods also package installation instructions/readme's or have detailed instructions in the first post of the mod thread. If this is the case, refer to those as the way to install.

so it would have to check both? (fairly sure I got the wrong operator for OR...) @PART [*]:HAS[~minimumcrew[]|~minimumcrew[0]] E: This is probably what is needed (mincrew defined and not 0) @PART [*]:HAS[#minimumcrew [*],~minimumcrew[0]] E2: A table of the operators and where they can be used around anywhere? Particularly logicals (always getting confused by things like not where there are atleast two possible (~ and !) that are used slightly differently)

No, ground speed (would be zero in a climb. Velocity vector projected onto the ground plane relative to a point on the ground) is different to surface relative speed (velocity relative to a point on the ground ), which is different to orbital speed (velocity relative to the center of the planet) Intakes use surface speed (what is shown on the navball in surface mode), not ground speed

Has exactly 1 crew @PART [*]:HAS[#minimumcrew[1]] crewed pods only would actually be: Not zero crew capacity @PART [*]:HAS[~minimumcrew[]] // note: might actually be "has no minimumcrew defined" @PART [*]:HAS[~minimumcrew[0]] // should work provided thats the correct not operator (why is there multiple :/)

A screenshot with the VSpeed controller parameters (Kp/i/d/scalar) visible would be very helpful (preferably in flight with the misbehaving craft) Oscillations are sharp and jerky or rather long and slow? If it's the latter, decreasing scalar a little and increasing Kd in the vertical speed controller may get it to behave (a large craft may need to add quite a bit of Kd. The default is ok for a 5-10t craft, while something in the 100+t range may need 6-10+). If it's the former, go the other way (more scalar, less Kd) I tune Kd using the little pips in the bottom left of the screen. If they are jumpy, it normally means Kd is too high (Note the difference between vibrating and jumpy. Vibrating means regular oscillations and Kp/Ki is probably too high. Jumpy is sharp irregular movements). If they are oscillating for a long time (very low damping), Kd is too low. Getting a good Kd for your craft really helps improve smoothness and control stability

Atleast should be changed to entering the same situation as the object to be rescued/tested (stable orbit for an orbital rescue, landing for a ground rescue, sub-orbital for a sub-orbital part test). I don't think I would go quite that far (except for the current numbers...), but I do think they missed the mark by a fair way. Have to emphasise one of the more important reasons that you made about this: in the long run only funds matters. Science is early game grind. Rep is permanently irrelevant. To make the strategy/contracts systems more interesting and player friendly, how the currencies are dealt with needs to be re-examined (there's been plenty of other discussion on revamping science to refer to, rep is just wierd atm). E: Rep should probably just be removed as an element the player can deal with and just leave it as a background system that decides which contracts you can be offered (It's not like the player knows what it does atm anyway...)

https://github.com/Crzyrndm/Pilot-Assistant/blob/master/PilotAssistant/Utility/FlightData.cs#L32 ^^ Vector to the planet center from current vessel position (AKA upVector). I would suggest using the surface velocity vector (Vessel.srf_velocity) for this though, it might be a little more natural If lookAt has a Quaternion input, Quaternion.LookRotation(-upVector) gives you a quaternion pointed towards the planet but doesn't specify the rotation about that vector to use (multiply by Quaternion.Euler(x,y,z) if the orientation is strange, where x/y/z are probably multiples of 90). Use Vessel.transform.forward as the second input to LookRotation if it does wierd rotations (where forward is actually up, because up is forward in KSP...) You also probably want to use Quaternion.Lerp/Slerp to smoothly adjust from the original rotation

Strategies: If the current style of conversion remains (converting from one currency to another), I would like to see one change in function and a good smacking around of the numbers Change in function: Make the conversion factor constant or decreasing with increasing commitment. The current system you increase your commitment and so get more output and the conversion increases in efficiency. This is somewhat backwards IMO. The numbers: The numbers I used for Sane Strategies are 400 funds : 5 reputation : 1 science. On top of that, there is 20% of the conversion that is lost (so converting 1k funds would give: 1000 * 5/400 * 0.8 = 10 rep). 5% commitment on a 100k contract gives you just under 50 rep (before it gets screwed over by the exponential decay that is). For decaying returns I set the 100% commitment factor to be 70% of the base factor. This gives a nice curve that continues to increase output while still creating a notable loss of efficiency. All numbers and equations used to generate the conversion factors for Sane Strategies can be found here. If we don't have to stick to the same conversion style, I much prefer the alternate strategies I made which trade on collection efficiency. Instead of converting 'x' science or rep to funds, you lose x% of the science/rep you collected and gain y% on your funds income. This means that if you don't collect any science, you still don't get any science (which strategies and contracts broke well and truly...). Contracts Testing while landed on Kerbin should be scrapped entirely. It's free currency, and thats all it is. Lets just assume that the various companies can manage this themselves. Testing while splashed down on Kerbin is only very slightly harder, would like to see it scrapped for reasons stated above Testing parts should require having them running for a short period where applicable * No testing an engine with no fuel source, no antenna testing without Ec, etc. (outright declares jet engine in an un-oxygenated situation contracts to be a bug) * Makes next point a bit less ezmode with engines and the like * Allows Engines to be tested with fuel tanks (which currently have no tests). Eg. run x engine with y fuel tank in z flight conditions (obviously needs some thought as to how the fuel flow from multiple tanks is dealt with. Maybe just a volume of fuel needs to be used instead of a specific tank part) Tests should complete when the part is running or activated in any way. Having to screw around with staging and/or right click is awkward. I should be able to use action groups, right click activation, staging, or any other activation method (engines also need a minimum output thrust to prevent throttle limiting to zero and the like) Rescue contracts should require the player achieving atleast one step past the rescue location (eg. to get the kerbin orbit ones, you should have atleast entered an SOI other than Kerbins) Kerbin atmosphere part test rewards need to be atleast somewhat rewarding. Being spammed with contracts that give you less than 1000 funds total is just a waste of time (even if the vehicle is small and single stage, the recovery factor and occasional accident blows any chance of profit) Rewards for contracts involving parts should have an exponentially decaying or logarithmic scaling with part value. This would allow the more expensive parts to not give absolutely insane rewards for tests in Kerbin orbit while still getting enough for cheaper parts to make sense (eg. reward += k1 * part value + k2 * log(part value); NOTE: k1 should be lower for tests close to kerbin where recovery is more likely, and maybe higher for parts with a low impact tolerance) Solar orbits could do with a lot more specific zoning based on deviation from Kerbin's orbit rather than just using the two science areas for multipliers (as far as I can tell anyway).

No disagreement, but there is a distinction that has to be made between a bug (unintended behaviour) and a poorly implemented feature ^^ So many times... PS: It isn't obvious in the OP, but it also resets on touchdown now (and you can turn any of the three off) which is why I linked it (...Why do I always forget to update the OP...) I wouldn't say that's strange at all. The focus for this mod is clearly fixing broken/buggy stock behaviour, not adding/extending functionality (It's not like you don't have enough to look over already...)

Version 1.5 Added a two stage activation when using the GUI. The first stage makes the crosshair visible, and then you can pause and unpause control (always paused when you make the crosshair visible) Enter/Return is now the on/off switch (show/hide the crosshair). Left Mouse Button is pause/unpause (not available if the UI setting is false, activation remains as it was with that) After transferring from an unpaused to a paused state (normal input still functions after you show the crosshair until you unpause control), the mouse position is remembered and continues to be used for outputs. A small dot is placed at the cursor location when control is paused so you can re-engage smoothly The marker texture is a 20x20 PNG, with the last cursor position being centered at (10,10). If you want it gone just replace it with a fully transparent PNG of the same size (or edit it to your preference ofcourse) If you want the pause/hold functionality without the crosshair you can always set the transparency to full. OP usage instructions updated to reflect changes And a new video NOTE: The pause function is only remembering where you had your mouse when it was activated. Changing the trim and switching between yaw/roll control will change the outputs

It's always current surface velocity + 100m/s

@Probus A) *nitpick* Thats not a bug *\nitpick* Solved by this mod here

So I have hacked together a way of making things a lot more stable (once the target is reached that is. It's quite horrific over long distances). Comparing RCS usage, stock's prograde hold vs. my edited version is consuming greater than an order of magnitude more RCS What did I do? Forced it to use the stability assist mode and just updated it's target... Square wheel indeed... ^^ If you have to do it stock, SAS is next to useless for planes. Trim and be done with it

The best one I've seen is in Wanderfounds craft showcase thread (linky), although it's a bit light on the stability derivatives page (that being said, I don't exactly pay much attention to the numbers page past level flight AoA unless there's red everywhere...)

GameDatabase is where KSP dumps everything on start that it knows how to process (everything in GameData folder that isn't inside a PluginData folder and has a file extension that it recognises). Module Manager modifies the configNode data in GameDatabase, so when I load it out later on I see the config post-MM edits.

That was the downside of making SAS and Asst. control not exclusive. I'm currently over-riding any roll signals that come through so that SAS doesnt get any strange ideas (things got very wierd very fast before I did that...). I can monitor roll input manually, so I'll get that added in E: Latest Github build (not a release version) allows roll inputs from the keyboard/controller. Still ignores SAS or inputs coming from other mods on the roll axis.