E.g. FS / B9 mesh-switch. Uses meshes from transforms within a given model, enabling/disabling the meshes as specified in the config.

Single mesh-switch module responsible for managing a config-specified list of meshes. These meshes cannot be shared by other modules.

Should include basic attach-node positioning.

Needs to work correctly with the existing scaling functions.

Absolutely need to find a solution to this to stop the vessel-sliding problems.

• As KSP now has some internal tracking of forces at the part (and vessel?) level, it may be possible to tap into those and find the necessary counter-force to keep things from sliding. This will only work if -all- forces are tracked (gravity, engines, etc).
  • Finding the necessary 'static' friction isn't too hard.
  • When input forces exceed static friction, let thing slide
  • When input forces are below static friction, clamp things in place.
• Possibility to force-re-position each wheel part, with some jitter control. Yes, this will play hell with physics, but unsure how else to accomplish the goal.
• Can determine current input force by working backwards from the calculated acceleration?
  • Can this be done in a place early enough to cancel out that accel?

Noticed when using ALG parts flying a spaceplane to orbit. One of the landing gear was broken...

Needs more testing, information, and repro steps.

May need to clear the part.grounded check when wheels are not grounded.

Use two configurable brake-input curves for tank steering.

• Inverse proportional to torque output on the 'reverse' wheel.
• Full time, full-brake on the 'reverse' wheel.

How to tell what is the reverse wheel?

Even bigger problem -- where to put the code?
It needs access to the input state and calculations in motor module update code.
It also needs access to the input state and calculations in brake module update code.
It cannot logically be a part of either module, but needs to be part of both -.-
Make it a third module that can reference the first two? (won't work, needs to be part of the motor input calculations to know what direction is 'fwd')
Make it a part of motor module and use max motor torque as max brake output for steering function?

Current potential solution appears to be to link the feature into the motor module (so that it has access to the tank-steering input setup, which is needed to determine fwd-vs-rev direction), use the inverse output from the motor torque curve, and use the max motor torque and current-vs-max-rpm-percent to determine the 'brake-steering' torque.

Incorrectly setting the 'current length' to repulsor height, even if it should have been set to zero from being off.

Even when repulsors are un-powered when saved, power button always initializes to 'on'.

Is this value persistent? Why is it not saving and reloading properly? Is it being improperly overwritten by init code?

In cases of a vehicle riding on another vehicle -- use the velocity of the rigidbody attached to the hit collider and add that velocity to the 'local wheel velocity' used to calculate friction.

What happens currently is that the 'carried' craft slides around on the 'carrier' as if the carried craft were interacting with the ground.

With the proposed changes the carried craft would be 'drug' along with the carrier due to the additional velocity.

Might need to use the velocity of the carrier relative to the carried craft (not just raw velocity).

Zero friction collider materials, and handling for zero-length suspension.

Seems like the simplest way is to merely set the materials to Multiply mode and leave them be (along with assigning materials to those colliders that are missing materials).

Investigation needs to include checking what the default settings are on normal part colliders (null?), and what the default settings are for other 'null' materials (runway).

Testing needs to include testing of a kerbal walking around on the ground while the vehicle has set the colliders to Multiply mode, as well as testing how stock wheels interact, and standard part colliders.

Need to investigate FAR support...

Need to submit stock bug report to have them change rover-controls to not recenter instantly... or something....

Seems to be applying incorrect scaling to the lifetime and velocity of the particles, but only on repulsors in water mode.

Need to hook into deployment states and re-render drag cubes when states are updated. Possibly re-render at 2-3 points between retracted and deployed.

A full and robust solution (only usable in flight scene) would be to render one cube for each of deployed and retracted states and lerp between them, however as the entire model is driven through constraints this will not work (unless the constraint module is linked into the ALG module and force-updated between setting of deployment states).

Either way it will conflict with the base-modules handling of part scale, which manually rescales whatever drag cubes are present on the part. This rescaling might be setup to enable/disable through a config field

Erm.. yeah... no clue where to even start on this one.

Is there an 'on origin shift' event? -- If yes, subscribe, and offset existing particles according to origin-shifting

Unfortenly KSP 1.3 not ready yet for RSS+RO, so i'm steal use 1.2 version.
But latest versions of your awesome mod craching my game on loading due 'localizator' class issue.
Any chance to solving this problem?

Happens in the editor, resulting in the following stack trace:

NullReferenceException: Object reference not set to an instance of an object
at KSPWheel.KSPWheelAdjustableGear.onStateChanged (KSPWheelState oldState, KSPWheelState newState) [0x00000] in :0
at KSPWheel.KSPWheelBase.changeWheelState (KSPWheelState newState, KSPWheel.KSPWheelSubmodule module, Boolean selfCallback) [0x00000] in :0
at KSPWheel.KSPWheelSubmodule.changeWheelState (KSPWheelState newState, Boolean selfCallback) [0x00000] in :0
at KSPWheel.KSPWheelAdjustableGear.b__54_0 (KSPWheel.KSPWheelAdjustableGear m) [0x00000] in :0
at KSPWheel.Utils.symmetryUpdate[KSPWheelAdjustableGear] (KSPWheel.KSPWheelAdjustableGear t, System.Action1 act) [0x00000] in <filename unknown>:0 at KSPWheel.KSPWheelAdjustableGear.deploy () [0x00000] in <filename unknown>:0 at BaseEvent.Invoke () [0x00000] in <filename unknown>:0 at UIPartActionButton.OnClick () [0x00000] in <filename unknown>:0 at UnityEngine.Events.InvokableCall.Invoke (System.Object[] args) [0x00000] in <filename unknown>:0 at UnityEngine.Events.InvokableCallList.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 at UnityEngine.Events.UnityEventBase.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 at UnityEngine.Events.UnityEvent.Invoke () [0x00000] in <filename unknown>:0 at UnityEngine.UI.Button.Press () [0x00000] in <filename unknown>:0 at UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <filename unknown>:0 at UnityEngine.EventSystems.ExecuteEvents.Execute (IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00000] in <filename unknown>:0 at UnityEngine.EventSystems.ExecuteEvents.Execute[IPointerClickHandler] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction1 functor) [0x00000] in :0
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMousePress(MouseButtonEventData)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent(Int32)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent()
UnityEngine.EventSystems.StandaloneInputModule:Process()
UnityEngine.EventSystems.EventSystem:Update()

The resulting exception seems to prevent the FAR revoxelization event from being sent. The gear does animate as expected though. This is reproducible with a minimum of Kerbal Foundries and FAR installed, but I don't believe that FAR is actually necessary for the exception to happen.

Stock Wheels, Landing Legs, Landing Gear -- patch WIP, needs updating to latest module setups and lots of testing.

Other mods:

• USI - Keribou & Akita Rovers - http://forum.kerbalspaceprogram.com/index.php?/topic/154587-122-modular-kolonization-system-mks/
• USI - Malemute Rover - http://forum.kerbalspaceprogram.com/index.php?/topic/139668-12-the-malemute-rover-020/
• Wild-Blue - Buffalo Rover - http://forum.kerbalspaceprogram.com/index.php?/topic/122617-12-buffalo-120-nasa-inspired-msev-fly-like-jetman-yves-rossy-with-the-jetwing/
• Infernal Robotics (rework?) - http://forum.kerbalspaceprogram.com/index.php?/topic/104535-112-magic-smoke-industries-infernal-robotics-202/
• Feline Utility Rovers - http://forum.kerbalspaceprogram.com/index.php?/topic/155344-122-feline-utility-rovers-020-beta/
• Firespitter Parts Pack - http://forum.kerbalspaceprogram.com/index.php?/topic/22583-firespitter-propeller-plane-and-helicopter-parts-v71-may-5th-for-ksp-10/&page=110#comment-2964124

Wheel patches would be distributed in a secondary optional download. Too many problems with mucking about with stock/other mods parts when people aren't expecting it.

1. EC consumption for wheels not shows up at VAB module section (or stat section) and units would be helpful.
   So

   • max speed: 65
   • max load: 4

   changes to

   • max EC: xx/s
   • max load: 4 t
   • max speed: 65 m/s

2. EC not shows up at right-click menu.

3. C = 2πr, but ×2 TweakScale → ×2 Speed look like overpower. Not sure.

From forum post:

Unfortunately, it does not seem like this has solved the issue. I have recorded a video clip that shows the issue, and I suspect it has to do with brakes. I fly with AtmosphereAutopilot, and when forcing it to a given speed the brakes will automatically deploy, and as such my brakes will be on as I touch down. As you can see in the clip, landing without brakes seem to work out just fine, but landing with them active, causes it to flip out violently. Here's another happy spin, with brake force set to 100 on the back wheels, but nothing on the front wheel: Wheeeeeeeeee!

Links:
https://www.youtube.com/watch?v=lpJy5ARtyb8&feature=youtu.be
https://youtu.be/17T0m_Amlik

Causing door to clip into the strut when changing the angle

Apparently VesselModules run Update() / OnGUI code even on disabled/inactive/packed/unloaded vessels.

This could be a potential performance drain when lots of unloaded craft are in the game, each running a vessel module with an un-needed OnGUI call. This could be especially bad if every vessel has a dust-camera that is constantly rendering and updating even if not needed.

Best method to handle this is to move the OnGUI code and call off to a class that is not loaded for unloaded vessels (PartModule), or a centralized area (KSPAddon)

Dust Camera

• Use a KSPAddon for dust-camera management. Only have a single camera, single render-texture, for the entire game.
• Use a VesselModule for each vessel. This vesselModule queries the KSPAddon to do the camera rendering, and stores the resultant output on a per-vessel method.

Debug GUI

• Umm... really no clue how else this one should be handled.

Control GUI

• Umm... really no clue how else this one should be handled.

Minor Issue : When tweakscaling parts, colliders (I think) keep the original size, resulting in bouncing everywhere. Also, the part highlighting is wrong when TweakScaled.



output_log.txt

Apparently something in the advanced damage model is causing a div/0 error, which is NaN'ng the world.

Might also happen on normal damage model in some situations.

^^

I randomly encounter some issue when ALG rolling through trigger collider, it will consider trigger collider as typical collider.
Is it necessary to change all collider to layer part trigger to avoid this from happening,

http://answers.unity3d.com/questions/279514/raycast-ignore-trigger-colliders.html

Rework the ALG models and plugin to use a vertical travel suspension (relative to 'down' in the VAB/editors) rather than the strut-aligned suspension that is currently in use.

Will require:

• Re-rigging the models entirely to support the new setup
• Rewriting the animation handling code
• Rewriting the stand-in-collider handling code
• Rewriting the UI/interaction code for adjusting the angles of strut/wheel
• Writing code to show some in-editor rendering of -how- the wheel will function
• Writing an entirely new animation constraints system to handle the strangeness that will be needed by the rigging.
  • Axis-locked look-at
  • Regular look-at constraints
  • Positional follow constraints
  • Rotation follow constraints

Enable wheels/repulsors/tracks placed in symmetry to have 'anti-roll' functionality. User configurable coefficient to determine the output force.

Also enable pre-rigged or welded parts using a single base module with multiple wheels to also have anti-roll functionality; controlled through configuration of the wheel-collider data in the part config.

Not-Yet-Implemented -- multiple base-modules within a single part with cross-base-module anti-roll linking.

Brakes are not showing in the "Brakes" action-group in the SPH editor nor is it available to assign. Brake functionality seems to be missing on all wheels included in Foundries including the ALG-wheels.
Reproduction:
Place any Foundries wheel, check the 'Brake' action-group - it will be empty.
Click any Foundries wheel - Brakes will not be available to be assigned as an Action.
Please tell if you need a log - didn't attach any since this seems to be a minor typo/mistake somewhere..

Can be seen during accel with a motor; always pulls to the right. If motors are reversed, pulls to the left.

Likely there is a >=0 check somewhere that should be only >, or other similar discrepancy in handling between positive, negative, and zero values.

Could also just be floating point imprecision, but the consistency of the problem points to it being fixable in one form or another.

Reports from forums:

I also have this issue; I've found that I can avoid the problem by turning the gear ratio to the lowest possible speed during high-timewarp situations or planetary transfers. The brakes should also be on.

I encounter a problem with some of the wheels provided by this mod : This is the craft I'm trying to get to Mars in RSS but as soon as I'm in orbit around earth and the timewarp starts, the wheels brake due to stress.
Any idea why this is happening? I tripplechecked all the fairings and it seems as if they're fine.

TODO:

General Implementation

• Investigate allowing collider to search for a rigidbody if none has been provided and the update method is called (either automatically or manually).
• Refactor to separate suspension sweep from spring/friction forces integration. Allow external classes to call suspension sweep data and use that for adjustments to friction/etc without them having to run their own raycast.
• Refactor to separate contact patch data into a separate struct/class -- previous attempt at doing so resulted in... problems....

Sticky friction

• Add calculations of actual static friction; use slope, gravity, and specified wheel static friction to enable/disable the gravity fixes
• Investigate force application more thoroughly, still some sliding occurring in some situations
  • Is the gravity vector incorrect for the frame in which the forces are applied? -- is it behind a frame?
    • Minor sliding was still occurring in the unity editor, which used a static gravity vector, so probably not.
  • Could be floating point imprecision?
  • In KSP could it be caused/amplified by rotating reference frame?
• Should investigate using a joint to finish the sticky implementation

Suspension Forces

• Need to handle of angled suspension hit; how to handle cases of, for example, wheel laying on its side
  • This should probably be best handled by adding in a 'maximum spring response' for when spring compression increases vastly between physics ticks; probably can be clamped to a percentage of spring travel * spring rate. Still needs to be large enough to handle regular suspension reaction forces and dynamics, but small enough to clamp out spring response that would cause bouncing or launching into the air.
• Need to handle damper forces properly when going from !grounded to grounded -- zero or add a low multiplier to damper force for that first tick (configurable?)

Fairly simple issue from my testing. Steering (both wheels and tank style) is inverted by default from the actual intended command (steering right actually steers you left, and the opposite applies). This is reasonably easily fixed on the end-user side by manually inverting all intended steering wheels, but it is an issue.

However, the other half of the issue is that when pairing two parts together using symmetry (I did not test individual attachment, however, so I can't be sure that the issue exists there), all wheels on the right side will drive backwards. Again, easily fixed on the end-user side by inverting the motor drive for all intended drive wheels, but it can be an unexpected surprise to attempt to accelerate and find yourself spinning instead.

Attached are screenshots of the steering issue (Steering full right gets full left steering lock, and steering full left gets full right steering lock) as well as my KSP.log file. Sadly, I was not able to capture an image of the spin issue, but it is easily replicated.

To replicate either of these issues, attach the Medium Wheels to a structural I-beam with any cockpit and sufficient power, and use the default settings. The steering should start out inverted even though the button claims it to be normal, and attempting to drive forward should result in a spin until the right-side drive wheels have their motors inverted.

Screenshots:

KSP.log: (Saved as .txt to upload) (Note, I turned on Verbose Logging in the KSP options. If, in the future, you have a preference, please let me know.)
KSPlog.txt

Need to crawl up the hierarchy to find the first valid rigidbody if the wheel itself does not have one.

Current code checks the part.parent first, and then defaults to the part itself; if neither have rigidbodies (in the case of a physics-less parent), then no rigidbody will ever be found or assigned to the wheels, and the wheel FixedUpdate code will never run.

TODO

General

• Figure out best default scaling powers for...everything...
• Investigate if wheels should be made a bit more configurable
  • select 'light/med/heavy' structure
    • adjust impact tolerance and stress tolerance
    • effects part mass directly
    • light and heavy both cost more, med uses default cost
  • select 'spiked/soft/med/hard' wheel type
    • adjusts friction output, max safe speed, and wheel persistent wear rate
    • does not effect part mass or cost
  • some other method to adjust max safe speed of the wheel, that comes with some other negative tradeoff (mass, cost, heat tolerance, ??)

KSPWheelBase

• Add methods to disable/remove most/all colliders from the part, except those needed
  • This is a workaround for some of the funny rigging that other mod parts use.
• check how 'manual suspension' effects various features -- do things still work with it enabled?

KSPWheelSuspension

KSPWheelSteering

KSPWheelMotor

• Add handling for motor response curve/throttle response/spool-up?
• When reversing motor at high rpm, should it put out more power?
• When integrating motor values -- only subtract brake torque from motor torque if they would act in opposite directions.
• Regenerative braking?
  • Configurable regenerative efficiency factor
  • Examine long force when motor not engaged, convert back to torque (or convert back into kw/kj/ec?)

KSPWheelBrakes

KSPWheelDamage

• Add flight-logging of break and repair events.

KSPWheelBogey

• handle lerp of bogey pre-retract animation being played (delay animation until retracted)
  • no clue where to best handle this

KSPWheelDeployment

• Make sure 'lights' action group is enabled and/or light is enabled in the lights module before turning the actual light on and off.

KSPWheelTracks

• Overall traction on tracks seems rather low; hard to climb slopes. A very low powered 4x4 was climbing better than more powerful mole tracks. Could simply be unbalanced configs / unconfigured values.

KSPWheelWaterPropulsion

KSPWheelRepulsor

KSPWheelAdjustableGear

KSPWheelDebug

Vessel Modules

KSPWheelVesselDebug

KSPWheelVesselControl

KSPWheelDustCamera

Hi, got a weird bug here. Treads break in my shuttle cargo bay (despite not touching anything) and when I fix them upon landing, they don't work. I figured out keeping the brakes on keeps the failure time at zero, but I would like to know why the treads don't work again after landing and repairing the tread.s
Here's the slightly upgraded probe https://www.dropbox.com/s/b4dob363uqbg6wr/Ore probe.craft?dl=0, the only other mod it has is KAS for a winch point on it.
The entire package is here https://www.dropbox.com/s/ky2s2od3df8rx3j/Artemis.craft?dl=0, it has the shuttle, launch vehicle, and probe, but is highly mod heavy. I have yet to test it out without the shuttle. Mods on the full package are opt, opt legacy, KAS, spacey, and spacey expanded.

Action Groups to Add:

• Steering Invert
• Steering Enable/Disable
• Motor Invert
• Motor Enable/Disable
• Motor Steering Invert
• Motor Steering Enable/Disable
• Suspension Lock Toggle (Landing Legs)
• Gear +/-
• APU On/APU Off (handled by stock code for the converter module?)

In the future, preset AGs may be available for:

• Motor Limit - 0, 25, 50, 100
• Brakes Limit - 0, 25, 50, 100
• Steering Low Limit - 0, 25, 50, 100
• Steering High Limit - 0, 25, 50, 100
• Steering Response - 0, 25, 50, 100
• Brakes Limit - 0, 25, 50, 100

Need to figure out what hackery the stock code is using to set the biome properly when landed.

Apparently also might not clear the landed state as it should / landed biome when in flight.

http://forum.kerbalspaceprogram.com/index.php?/topic/155056-122-kerbal-foundries-continued-tracks-wheels-and-gear-03-05-17/&do=findComment&comment=2981123

Not sure if this is the right place to complain: When i use the ALGs on my planes, the biome detector goes crazy. For example, when i launch my plane, i'm sitting on the runway but x! science claims i am on KSC/shore (so, no runway biome) and the contracts from contract configurator (namely, GAP) don't fire the "Sit on runway and wait for takeoff clearence" event. Any launched experiments also say, "KSC" instead of "runway". Then, when i took off and i am airborne, doing experiments inform me that i'm still landed, like in "Landed on Kerbin Waters". However, when I use Stock landing gear (which i won't because landing with these things is like riding a kangaroo) everything works fine. Is this a known issue? Can i do something about this?

^^^
Most of the back-end functionality is in place.

• Need to add the accumulation of wear, and decrease part efficiency based on accumulated wear
  • Increased rolling resistance value
  • Decreased motor efficiency
• Need to still allow for complete breakage when damage threshold exceeds XXX

Persistent damage model:

• Wear is accumulated through standard use.
  • Wear is tracked for 'wheels', 'motors', and 'suspension' independently.
• When parameters are kept within the design limitations of the part the accumulated wear is minimal, and lifespan should be measured in years.
• When operated outside of intended design, wear will accumulate -much- faster, and lifespan may be measured in minutes or seconds.
  • Wheel velocity and slip contribute to wheel wear. Wear is accumulated when the wheel velocity approaches maximum, or when the wheel slip is beyond a threshold while the velocity is also beyond a threshold (minor slips cause no damage as they are part of normal wheel functioning). Wheel wear manifests as increased rolling resistance.
  • Motor use creates heat; excess heat accumulates as motor wear and results in reduced motor efficiency.
  • Suspension being near or beyond maximum compression contributes to the accumulation of suspension wear. Suspension wear manifests as reduced maximum spring output, and reduced damping (through wear, these values may no longer reflect the user specified values; user can still adjust upwards to compensate temporarily, but with more accumulated wear eventually it will go outside of the user-adjustable range).
    • Very advanced suspension wear may also contribute to rolling resistance.
• In advanced wear mode, an Engineer will be required to repair the damage.
• Should still use the instantaneous breakage model for suspension based on compression/impact forces -- it is still possible to snap things from riding them too hard.

when I specified a custom steeringCurve for big wheels from kerbal foundries in their config file and then inverted steering in-game the inversion worked only for a part of a steering curve. For example wheels were turning right at slow speed and high speed before inversion and after that they were turning right at slow speed and left at high speed).

Relevant code from wheellarge.cfg in kerbalfoundries:
http://pastebin.com/Q5WSwC32

edit: actually the bug has nothing to do with inverted steering, I've tried without inversion and the bug was still persistant (that is steering one direction up to 10% of max speed I guess and then second direction while driving faster)

This code:

Does not ever seem to fire, even in flight. The end result is that FAR does not distinguish between closed and open ALG.

Also, feature request: can it be left on in the editor? It's useful for debugging voxelization problems and using the FAR analysis tools for gear-down flight.

Add some config fields to the module to enable use from EVA.

Should include both a 'usable from EVA' and an 'only usable from EVA' flags. The first denotes if it can be used via EVA, the second disables the non-EVA controls if the first is also enabled.

Think this is being caused by manually re-updating the field during symmetry/wheel group updates, breaking the input state listeners for the GUI control.

Might be as simple as

if(m!=this){/**update field value**/}

I don't know if this is only a sound bug or not.

Reproduction steps:

1. Plane with ALG
2. Move plane -> ALG's play moving sound
3. Take off
4. Retract ALG -> Sound still plays as if wheels are still moving

The stop the sound from playing you need to redeploy the gears, then brake.

Effects do not properly go back to ground-mode when leaving the water. The last position of the water-effect is maintained, and it continues to emit.

Suspension module needs to be somehow made aware of the deployment state, and have code added to correctly lerp between retracted and deployed positioning for all wheels (some of the stock parts could use this treatment as well).

Likely due to deleting the model regardless of if the correct one is already in place. SSTU suffers the same problem with MFTs/MSRBs/etc.

It seems that the stock surface attach code may use the parts collider in determining surface attach capability, and this collider is deleted after the mouse/attach setup has been run.

Potential solutions:

• Hacky - force drop and re-pickup the part through code.
• Hacky, but workable for this case - if the correct model is already present, do not delete it. May need some persistence flag as to whether the model has been setup for its clone state or not.
• Implemented and working, but needs a bit more testing.
• Best - find where the stock code uses the part collider and re-seat/re-setup for the new model.
  • Guesses are that it might be related to layer masks used for in-editor raycast checks

• User-driven constraint-type module
• Allows for user to set the 'deploy' extension (linear translation) or angle (rotation) of a specific transform in the suspension hierarchy.
• Intended to allow for user-configurable deploy-angle limits and/or landing-leg height.
• Needs to work along-side the 'locked suspension' setting on landing legs.
• Needs to hook into the deployment module, and move back towards the specified 'retracted' state whenever gear/legs are retracted.

Features

• Config specified 'retracted-default' position. (vector3? float?)
  • Represents where the mesh sits when 'retracted'
  • Also needs a config value to denote when to start and end the retraction sequence relative to the retract animation.
• Config specified 'extended-default' position. (vector3? float?)
• Config specified 'movement axis' - constrained to move (or rotate) along that single axis
• Config specified 'max adjustment' - amount user can adjust away from the default
• Config specification if it is a linear translation, or a rotation.
  • For translation, the defaults are for the X,Y, or Z local position
  • For rotation, the defaults are for the X,Y, or Z local rotation.
• Single UI slider with a 0-1 input range (0-100%),

Functions

• Rotate or position specified transform for the current deployment state (optional) and user-selected 'deployment amount'.

Unsure how best to handle updating drag cubes for parts due to conflicting requirements and setup between parts.

Would like to keep whatever solution is found to be something simple and robust to decrease the chances of incompatibilities with other parts/mods/stock code.

Conflicting requirements:

• Deployment module(s) require multiple drag-states, and are updated using IMultipleDragCube interface. This is managed by stock code and can only be run once, during part initialization.
• Scaling in base module requires a single drag cube state which is updated procedurally with DragCubeSystem.renderDragCube / etc. This can be managed by custom code and can be re-run or updated whenever drag cubes change (with caveats on initialization stuff, see SSTU notes on when drag-cubes can safely be updated).

Things to investigate:

• Can the drag-cube system be forced to properly update the multiple drag-cube states for a specific part without overriding the persistent data in PhysicsDatabase.cfg?
• Can the 'ModuleDragScale' (or w/e it is called) be manipulated at run-time to update the drag-cube scaling directly? (are the values polled directly from the module, or are they used in calculations and cached somewhere?)

Also:

• Whenever drag cubes are updated, should inform FAR to revoxelize. Keep in mind the ordering and initialization that FAR needs, only call the revoxelization method when it is safe to, do not call it prematurely.

• Currently using basic euler integration. Need to swap to some derivative based integration.
  • Pass in the vessel mass and COM into the integration code, use that to extrapolate positions for derivatives/substeps
    • treat entire craft as a single rigidbody for interpolated/extrapolated states, it should be at least close enough to correct for the duration being simulated, especially with the improvements to the base integration code
  • --how to handle changes in suspension compression from attitude changes or terrain changes that would happen in the substeps?
    • assume a single plane exists with surface-normal of the base raycast hit normal, use that plane for suspension interpolation data
  • -- how to accomodate changes to integration across multiple wheels on the same craft?
    • have the integrator simulate at the vessel level as for as rigidbody sub-integration
    • requires the wheel-collider integration code be aware of 'wheel body groups' and have customizable rigidbody com, mass, and ternsor data
    • could result in a fairly accurate simulation if handled properly, with potentially very little overhead cost (and would be much more efficient than if done on a per-wheel basis even at the worst case)