DocMop

Make sure you install all the dependencies listed in the first post. They are not mentioned on the spacedock site unfortunately.

This is offtopic but .. where the heck do you get all the time (and strength) to do that?!

That mod you mentioned should be this one: If that one will not be updated ... I would say that I would like it very much if you (or someone else) takes over the screeching and rumbling stuff. It adds so much feel to the not-so-good landings and stuff.

Got some random crash. Accepted satelite contract > Went to tracking station > Went to VAB > crash Log stuff: https://github.com/docmop/KSP_Logs/tree/master/Crash_2018-03-21_210628 Another one (on entering Tracking Station): https://github.com/docmop/KSP_Logs/tree/master/Crash_2018-03-22_210444

@blackheart612 I have build one simple car and set the spring strength of all wheels to 0.2 for testing purposes. http://steamcommunity.com/sharedfiles/filedetails/?id=1337074481 The car is currently drifting sideways (in direction of the camera on the screenshot) with no friction at all. I removed KerbalFoundries for this test but that didn't make a difference. After some more testing: The grip is missing only in the direction perpendicular to the driving direction. This means I can accelerate and brake but have no sideways grip. This does not happen when the spring strength is higher. However I have no spring articulation whatsoever. I'll do some mod conflict tests. Edit: No spring articulation problem persists even with stock game. No sideways grip under low spring power persists with stock game

Works in 1.4.1 Maybe a recompile should be done just to be on the safe side.

Is it just me or is there something off with the suspension? It looks like it's largely dysfunctional. And If I set it to a really low value to test if the suspension moves at all, the vehicle behaves like there is no grip at all.

I have kind of a bug report but with some caveats. KSP Version: 1.4.1 (yeah I know) KSPWheels (Kerbal Foundries) installed The Wheels rotate on the wrong axis while steering. You can steer the vehicle though (to some degree). Screenshot: http://steamcommunity.com/sharedfiles/filedetails/?id=1332862791

Wait. You can not use the Missionbuilder missions inside career?!

@ryan234abc Try setting the "Gunrange" lower. As far as I remember, only targets which are further away than Gunrange will be attacked with missiles.

In that case the landing point and trajectory are based on the current velocity and gravity only. Which means, as far as I know, it can not show the correct landing spot when the craft is influenced by aerodynamic drag / lift on its future flight path. Interesting non the less.

It will work. But entities will not load before 2km. Even with WW2 style planes, that's not much.

For ease of use and extendibility I would suggest a part config value like "waterPropulsionLevel". That would be a float value which works like this: 0.0 = No water propulsion >0.0 to 1.0 = maximum percentage of part immersion depth for water propulsion to work I guess that would catch all possible use cases. Then, for propulsion effectiveness you can do the following: //immersion = percentage of part immersion in water //toDeepFactor = ineffectiveness factor of too deep immersion float getWaterPropulsionFactor(float immersion, float toDeepFactor) { float propulsionFactor = 0.0; if(immersion <= 0.0) //above water return 0.0; if(waterPropulsionLevel <= 0.0) //no water propulsion return 0.0; if(immersion > waterPropulsionLevel) //to deep -> reduced propulsion propulsionFactor = waterPropulsionLevel / (toDeepFactor * immersion); else //not deep enough -> reduced propulsion propulsionFactor = immersion / waterPropulsionLevel; return propulsionFactor; } Disclaimer: Just a fast prototype, no actual KSP coding experience. Warning: toDeepFactor can not be 0.0 because of DBZ!

@Shadowmage It should be considered that the screwdrives have no technical need to be partly over water for propulsion. Unfortunately no time for testing interesting stuff right now

The thing in question is: Should overspeed damage occur when the wheels are not under load? The wheels could as well hang in mid air. Note: Haven't tested wheels in water / in air yet.

I wouldn't use this mod in 1.2.2. Its technically broken.

Use the "switch to next vessel" buttons located right of the number keys to switch to the Kerbals.

@Shadowmage Could the sideways folding gear be done with the current ALG if you enable the wheel to be rotate-able around the vertical axis additional to the horizontal that is currently implemented?

Forces are only one way to break inter part connections, there is also torque. In the end you would have to implement lots of extra code to catch any and all exceptions. And I guarantee you that there would still be cases where it would not work as intended. Implementing it this way would just create more bugs at the cost of limited performance gain in exceptional cases only.

How would you know about whether the forces are high enough for breaking or not if you do not calculate the physics for each part?

Anytime. At least when my exams are not hindering me Some thoughts: In my opinion the response mode (instant / gradual) should be changeable via the game settings menu. There is no need to further clutter the wheel context menus for something thats either globally on or off. And of course the instant mode can very well hide any steering speed tweak-ables. Always a fan of clutter free menus and stuff. PS: Literals! For a coder the only value between -1 and 1 is 0

@Shadowmage It should be irrelevant then whether Precision Mode is enabled or not, as long as you always approach the target value rI (minus the different limiters) with the speed steeringReponse from the current value of wheel.steeringAngle. Something like this: internal override void preWheelPhysicsUpdate() { base.preWheelPhysicsUpdate(); float rI = -(part.vessel.ctrlState.wheelSteer + part.vessel.ctrlState.wheelSteerTrim); if (steeringLocked) { rI = 0; } if (invertSteering) { rI = -rI; } if (rI < 0) { rI = rI * (1.0 - steeringBias); } if (rI > 0) { rI = rI * (1.0 + steeringBias); } rI = Mathf.Clamp(rI, -1.0, 1.0); float perc = Mathf.Clamp01(Mathf.Abs(wheel.wheelLocalVelocity.z) / (controller.maxSpeed * controller.wheelMaxSpeedScalingFactor)); float limit = ((1.0 - perc) * steeringLimit) + (perc * steeringLimitHigh); if (useSteeringCurve) { limit *= steeringCurve.Evaluate(perc); } float targetAngle = maxSteeringAngle * rotInput * limit; wheel.steeringAngle = Mathf.MoveTowards(wheel.steeringAngle, targetAngle, steeringResponse); } That should always do a smooth transition. And I removed one unnecessary variable (bias). The only issue I can see right now is that steering speed and centering speed could differ in Precision Mode if steeringResponse is faster than the rI gain. Warning: I never touched KSP code. Seems like some C derivate though. Edit: You might want to scale steeringResponse dependent on the current speed of the vehicle so it turns the wheels slower if the vehicle is really fast. Could be as simple as this although it should be clamped so it doesn't get too slow maybe: float steeringResponseScaled = steeringResponse * (1.0 - perc); //Optional Clamping to prevent steeringResponseScaled from geting too low steeringResponseScaled = Mathf.Clamp(steeringResponseScaled, MIN_STEERING_RESPONSE, steeringResponseScaled); wheel.steeringAngle = Mathf.MoveTowards(wheel.steeringAngle, targetAngle, steeringResponseScaled); However, gameplay testing would have to be done in order to see if the scaling is needed. Edit2: I swear someday I'll do a post without editing it 3 dozens times afterwards -.-

How are the steering inputs handled codewise? What values does KSP give you when I press 'A' or 'D'? Edit: I derived most of it from your code snipped. What are the differences between normal and precision inputs codewise? Maybe something comes to my mind .. tomorrow. Should sleep ... now.

Install only one of them (the continued one) and provide logs.

@Shadowmage Just wanted to say this here: I absolutely love those long explanatory posts of yours. As a fellow programmer it is incredible interesting to read all this "behind the scene" stuff.