[1.8.x] KSPWheel - Physics Based Alternate Wheel Collider [API Only]

[Climberfx]

Many many many thanks for this plugin Shadowmage. You save my wheels mod.

couldn't make it work with stock ones, i read about your dll from a friend, and after some digging in how it work, i manage to put it to function on Omicron.

Spect release update soon. Will have you mention there as a contributor.

Cheers!

 

Update:

Done!

 

Edited January 4, 2017 by Climberfx

[gomker]

On 12/4/2016 at 2:38 PM, Shadowmage said:

Took a look over the Adjustable Landing Gear models and setup yesterday.  While I can get the basic functionality working for them (suspension, brakes, wheels spinning), none of the advanced functionality is working as those models were specially constructed with the BD plugins in mind (and/or the plugins were written for the modules).  Not even the deploy animations work, as no actual animations exist, the transforms were all driven manually by the plugin.  To top it all off, the models are rigged in such a way as to make it very problematic to support the features (such as objects that need to rotate around other objects' origin points, randomly interspersed with normal-rotation setups).  Sad, because they are nice looking models; but I would have to have access to the original modeling files to re-rig them for standard uses / easier coding for support of the intended features, or do some very custom code to support them in their current state.

Hi, I remember seeing this awhile back and wanted to pop in and say that the animations are being maintained here now and should all be working

https://github.com/raidernick/BDAnimationModules

I see the wheel colliders seem to be referencing classes here

https://github.com/raidernick/BDAnimationModules/tree/master/BDAnimationModules/FSwheel

Not sure if this helps at all - I can see if the rest of the team knows where the original model files are.

[Shadowmage]

On Tuesday, January 03, 2017 at 9:05 PM, Climberfx said:

Many many many thanks for this plugin Shadowmage. You save my wheels mod.

couldn't make it work with stock ones, i read about your dll from a friend, and after some digging in how it work, i manage to put it to function on Omicron.

Spect release update soon. Will have you mention there as a contributor.

Cheers!

 

Update:

Done!

 

Glad it is working out for you, even in its currently unpolished state.

Are you using the included PartModules, or have you written your own to use the new collider?  Have you run into any problems with the wheels in standard use, or are they mostly working as you would expect?

Also a quick heads up that in the upcoming releases most of the current 'example' PartModules will be changing substantially, so there is potential for craft/part breakage.

 

17 hours ago, gomker said:

Hi, I remember seeing this awhile back and wanted to pop in and say that the animations are being maintained here now and should all be working

https://github.com/raidernick/BDAnimationModules

I see the wheel colliders seem to be referencing classes here

https://github.com/raidernick/BDAnimationModules/tree/master/BDAnimationModules/FSwheel

Not sure if this helps at all - I can see if the rest of the team knows where the original model files are.

I'll take a closer look at the updated animation modules, sadly I don't think they'll be workable as from a brief look they still reference the U5 wheel-collider class.

Additionally the models and the animation modules driving them are so closely linked together, there is no way to get those parts to be functional without those animation modules; and as the animation modules use the stock-wheel collider (which won't actually work with those parts the way they are rigged due to limitations/restrictions in the Unity/PhysX code regarding rigidbody+suspension orientation), there is zero chance of getting those parts working properly even with the updated animation modules.

If the original modeling files for those parts are available somewhere I could (in time... lots of time) re-rig them, write some additional custom part-modules for them, and re-release them under the new KF banner once that end of things is up and running again.  (Of course, only with proper permissions and if licensing allows).

I love the concept of configurable and adjustable landing gear, it is something that KSP aircraft need very badly.  So even if the existing 'Adjustable Landing Gear' mod/models aren't updated, I may introduce something similar in the distant future.
 

[Climberfx]

2 hours ago, Shadowmage said:

Glad it is working out for you, even in its currently unpolished state.

Are you using the included PartModules, or have you written your own to use the new collider?  Have you run into any problems with the wheels in standard use, or are they mostly working as you would expect?

Also a quick heads up that in the upcoming releases most of the current 'example' PartModules will be changing substantially, so there is potential for craft/part breakage.

...

Well, i use the dll inside Unity (copy it into Gamedata of KSP and into Unity project folder Assets/plugins/KSPAssets), then on a game object i put your component, and on the wheel collider i put Ksp wheel collider and a rigid body. So, on Kspwheel settings, i link the rigid body, then the wheels, direction and suspension parts to it. And adjust the wheel suspension parameter to match my real model, and wheels diameter, etc. This was Unity part. Then o config,i adapt from your stock models.

 

Edited January 6, 2017 by Climberfx

[Shadowmage]

1 hour ago, Climberfx said:

Wheel, i use the dll inside Unity, then on a game object i put your component, and on the wheel collider i put Ksp wheel collider and a rigid body. So, on Kspwheel settings, i link the rigid body, then the wheels, direction and suspension parts to it. And adjust the wheel suspension parameter to match my real model, and wheels diameter, etc. This was Unity part. Then o config,i adapt from your stock models.

 

 

To save a bit of time in the future you don't need to do any of the work in Unity.  None of those scripts will make it through PartTools exporting, they are all added to the parts by the PartModules (KSPWheelBase, etc) at run-time.  As long as things are configured properly in the part .cfg file for the model being used in the part (names, sizes, etc) it should all work.

The KSPWheelComponent that you see in UnityEditor is intended to allow for testing of wheel physics while in the editor and is not used in KSP.  I should probably move it off into a secondary .dll in the near future that only resides in the repository, it really doesn't need to be in the .dll used in KSP.

 

 

On the development note, I think I have the 'easy-mode' suspension auto-tuning off to a very good start.

This testing craft can go from ~5t to ~750t on the same wheels without changing of any spring/damper/etc settings:

(poor rover...)

Even works with tracks:

This is accomplished by using using the vessel mass as the primary basis for the spring value and further adjusting it if it leaves a specified 'valid' range, using a both time-and-distance evaluated adjustment curve, that will eventually (~1s) resolve to a stable spring value that results in a compression within the specified valid range.  It responds to and corrects both over and under compression, though I've still some work to do on the under-compression handling.  This should prevent the previous problems of the craft riding on the bump-stop collider when overloaded, and so far has not interfered with dynamic suspension response in any noticeable manner (though it will in theory, depending on craft design).  It is not very realistic, but probably very beneficial to general use of the existing PartModules.

Lots more testing and tuning to do on the curves and a bit of cleanup work to do on some of the functions, but it is so far looking to be a quite usable system.  No spring configuration necessary, though there are user-adjustable ride-height and damper ratio controls.  Auto struts might be beneficial in some craft designs but I did not n

This however brings up the questions of balancing for such a large usable range of wheel loadings on a single part -- Should wheels have any sort of specified max load range?  What should happen if it exceeds the max?  How should this maximum be calculated for a given wheel, at a given scale? (The stock answers are yes, break/explode, and 'arbitrarily / by hand')

 

Manual load rating ('hard-mode') suspension turning will still be available if desired.  This can currently be enabled through the in-game stock settings/difficulty menu, but I may move it to a per-part toggle.  I'll quite likely also add an over-compression prevention spring adjustment to this suspension mode as well, but it would only kick in when the wheel is near-fully compressed (~90%-95%), being intended solely to prevent dragging the bump-stop colliders on the ground while still giving proper friction/torque.

Wheel UI toggle is also in place and functional; it shows/hides all wheel gui controls and display except for motor EC use.  It hides the motor invert/lock/limit, steering invert/lock/limit/bias, and the ride-height/damper-ratio controls.

Seems likely that I'll have an updated release this weekend with the initial implementation of suspension auto-tuning.  Probably won't have too many other changes to the modules, but they should be coming in short order now that I've cleaned up the suspension code for easier testing (and easier use in general).  I will possibly re-add the stock-part patches to the distributions as an optional patch set (config file with a .disabled extension, change extension to enable patches); if so they will be updated to in-place patch the stock parts rather than clone.

[Climberfx]

16 hours ago, Shadowmage said:

To save a bit of time in the future you don't need to do any of the work in Unity.  None of those scripts will make it through PartTools exporting, they are all added to the parts by the PartModules (KSPWheelBase, etc) at run-time.  As long as things are configured properly in the part .cfg file for the model being used in the part (names, sizes, etc) it should all work.

The KSPWheelComponent that you see in UnityEditor is intended to allow for testing of wheel physics while in the editor and is not used in KSP.  I should probably move it off into a secondary .dll in the near future that only resides in the repository, it really doesn't need to be in the .dll used in KSP.

Ohh man. Ok, now it's done. Next time i need i will just use the config's

Thanks.

Edited January 6, 2017 by Climberfx

[riocrokite]

18 hours ago, Shadowmage said:

auto-tuning stuff

Oh man, that's so awesome!

Still busy in RL but will do some wheels testing in February/March when I have more time

concerning the question about overloading:

First option is stock mechanics i.e. wheel is broken when it's overloaded (or exceeds max speed). So in config one would configure what speed and load would the wheel endure.

Another option (enhancement) of that - I think that is closer to RL - is to take into account speed and load where wheel loading is a function of load and wheel speed. I.e. loader trucks move slower when loaded to save tires. so i.e. tire is experiencing higher stress and wear when it's rotating faster and when it carries heavier load. Potential bugs might be i.e. in situations with jumps, when wheels are temporarily not on the ground and start spinning fast. then during landing combining high spin ratio, high load ratio and relatively slow physics ticks might produce instant broken wheel when it shouldn't (at least in arcade game mode ;)) But I might be mistaken.

Last option that comes to my mind is to have something like 'wheel condition' variable that goes from 100 to 0%. In easy mode it only decreases when max load (max speed too?) is exceeded. In harder mode it constantly (albeit slowly) goes down depending on wheel loading (in variant B loading+speed function). The nice thing for modders in this option would be to i.e. have 3 wheel models i.e. 1)new, 2) optional worn down and 3) optional broken - 2nd model being new when wheel is under i.e. 20% durability (configurable) - wheel still works ok (or if we want to complicate further have another set of friction and other stats lol) (so player could indicate quickly which wheel is reaching end of life status and needs replacement or repair).

Just my thoughts on the subject, it might be to time-consuming and inefficient to implement so I would be perfectly happy with stock behavior.

cheers

[Shadowmage]

Updated release is available:

https://github.com/shadowmage45/KSPWheel/releases/tag/0.9.1.7

Only changes are adding a suspension auto-tuning feature (enabled by default, changeable through in-game settings), and adding one-shot animation support for deployment (e.g. for use on shuttles, landing-legs).

[Shadowmage]

On Friday, January 06, 2017 at 1:01 PM, riocrokite said:

Oh man, that's so awesome!

Still busy in RL but will do some wheels testing in February/March when I have more time

concerning the question about overloading:

First option is stock mechanics i.e. wheel is broken when it's overloaded (or exceeds max speed). So in config one would configure what speed and load would the wheel endure.

Another option (enhancement) of that - I think that is closer to RL - is to take into account speed and load where wheel loading is a function of load and wheel speed. I.e. loader trucks move slower when loaded to save tires. so i.e. tire is experiencing higher stress and wear when it's rotating faster and when it carries heavier load. Potential bugs might be i.e. in situations with jumps, when wheels are temporarily not on the ground and start spinning fast. then during landing combining high spin ratio, high load ratio and relatively slow physics ticks might produce instant broken wheel when it shouldn't (at least in arcade game mode ;)) But I might be mistaken.

Last option that comes to my mind is to have something like 'wheel condition' variable that goes from 100 to 0%. In easy mode it only decreases when max load (max speed too?) is exceeded. In harder mode it constantly (albeit slowly) goes down depending on wheel loading (in variant B loading+speed function). The nice thing for modders in this option would be to i.e. have 3 wheel models i.e. 1)new, 2) optional worn down and 3) optional broken - 2nd model being new when wheel is under i.e. 20% durability (configurable) - wheel still works ok (or if we want to complicate further have another set of friction and other stats lol) (so player could indicate quickly which wheel is reaching end of life status and needs replacement or repair).

Just my thoughts on the subject, it might be to time-consuming and inefficient to implement so I would be perfectly happy with stock behavior.

cheers

Leaning on some of what you posted, I'm working towards implementing three different wear scenarios.
None - No damage from impact or overloading.
Simple - Fairly close to the stock model.  Wheels can be damaged by overloading (too much weight for the wheel), and over-stressing (very hard hit / landing); both are accomplished by examining wheel load and compression.  Uses a config specified 'max load', which scales with wheel scaling.  Implemented and working so far, broken wheels can be repaired by any kerbal.  May investigate adding a stress factor for max-speed as well.
Advanced - Time/duration/load/stress/heat/use based wheel wear.  Higher degrees of wear increase the rolling resistance and decrease the safe max speed/etc (thus a worn wheel is easier to 'pop' than a new wheel).  Wheels will only be repairable by an engineer, and may require additional resources to do so.  Still working through the actual implementation details on how to accumulate wear, and how to track it best (per part, per collider, etc).  Will use the wheel loading compared to 'max load', wheel slip amounts and speeds, and monitor impacts and temporary stresses/overloads.  Duration and amount of the load/slip/impact will determine how it effects the persistent 'wear' value.

On the note of max-loading and allowing for various vehicle designs with a limited number of wheel parts, I'm pretty sure I'm going to implement built-in scaling of the wheels.  This will allow for out-of-the-box free-form design and use of the wheels while still allowing for each wheel to have a manually specified max load at default scale/size.  Instead of being stuck with wheels that may be too large or too small for the use, you can scale your desired wheel type up/down for whatever use is intended.  Moving it to an internal process (rather than using TweakScale) will allow for cleaner integration of the various scaling features and easier use of an event-driven setup.

Have also just reworked the motor handling mechanics, specifically I've implemented a model for DC electric motors.  Motors are now specified by four parameters:
motorTorque - stall torque of the motor.  This is the torque output at zero rpm, and tapers towards zero at max rpm.
motorMaxRPM - zero-load max RPM of the motor, the point at which the torque output is zero.
motorPower - peak kW output of the motor, attained at ~50% max rpm/torque, determines EC/s use and heat output (heat not-yet-implemented).
gearRatio - starting/default gear ratio for the motor.  Determines max driven RPM and max torque output (inversely).

Generally they follow the curves/functions outlined here ( http://lancet.mit.edu/motors/motors3.html ) as it pertains to torque curves and power usage.  Gear ratios are now specified in the config files, as well as an option to enable user-configurable gear changes (currently active both in editor and in-flight).  Gui will be updated to display the max speed and max output power of the wheels (as m/s and newtons).

Once all of these features are complete and working it will be time to figure out the balancing for all of the KF wheels and tracks, and how all of the settings are effected by scaling.  From there it should be a short path to setting up a new KF thread and actual releases.

[TiktaalikDreaming]

2 hours ago, Shadowmage said:

gearRatio - starting/default gear ratio

Anticipation intensifies ....

[SpannerMonkey(smce)]

9 hours ago, Shadowmage said:

On the note of max-loading and allowing for various vehicle designs with a limited number of wheel parts, I'm pretty sure I'm going to implement built-in scaling of the wheels.  This will allow for out-of-the-box free-form design and use of the wheels while still allowing for each wheel to have a manually specified max load at default scale/size.  Instead of being stuck with wheels that may be too large or too small for the use, you can scale your desired wheel type up/down for whatever use is intended.  Moving it to an internal process (rather than using TweakScale) will allow for cleaner integration of the various scaling features and easier use of an event-driven setup.

Its about time somebody did this, it must have bugged every wheel maker ever that scaling with tweakscale is not ideal for wheels and have six exactly the same but unity scaled for various vehicles is pretty annoying. Do you envisage a free scale arrangement with no steps, this would be the most versatile and suit all wheels or a more restrictive stepped scaling arrangement ?

 

On 06/01/2017 at 1:35 AM, Shadowmage said:

To save a bit of time in the future you don't need to do any of the work in Unity. 

Would this apply to old wheels as well? given that i know all the transform names etc,  is it worth a try setting it with KSPWheel  cfg values before getting into the unity dance?  Either way works for me now I'm back up to speed on KSP wheels  but it would be quite nice if I could avoid the whole imported exported import thing.Nope as the old colliders don't have a rigidbody applied in unity and no RB = no WC

Mightily impressed by the load carrying potential mentioned

Edited January 9, 2017 by SpannerMonkey(smce)
discovered that it doesn't

[damerell]

3 hours ago, Shadowmage said:

Generally they follow the curves/functions outlined here ( http://lancet.mit.edu/motors/motors3.html ) as it pertains to torque curves and power usage.  Gear ratios are now specified in the config files, as well as an option to enable user-configurable gear changes (currently active both in editor and in-flight).  Gui will be updated to display the max speed and max output power of the wheels (as m/s and newtons).

I added to the linear relationship there a maximum torque - below the corresponding rotational speed torque does not increase and so power output drops. This seems to be typical in EV applications - presumably there comes a point where putting the motor's full stall torque into the gearbox will just cause something to break.

[Shadowmage]

15 hours ago, SpannerMonkey(smce) said:

Would this apply to old wheels as well? given that i know all the transform names etc,  is it worth a try setting it with KSPWheel  cfg values before getting into the unity dance?  Either way works for me now I'm back up to speed on KSP wheels  but it would be quite nice if I could avoid the whole imported exported import thing.Nope as the old colliders don't have a rigidbody applied in unity and no RB = no WC

You shouldn't need to add a RigidBody in Unity, as this method uses the rigidbodies of the Part's in the craft, which are assigned by KSP.  The actual WheelCollider components are added at runtime -after- KSP has added rigidbodies to the parts, and uses whatever rigidbody was assigned to the part by ksp.

So yes, this will work with old wheels (U4 based).  It will also work with new wheels (U5 based rigging), and with models that completely lack wheel colliders.  As long as the rest of the rigging is setup properly and transform names are known (and there is a transform for the wheel-collider), the rest of it is handled completely at run-time.

 

15 hours ago, SpannerMonkey(smce) said:

Its about time somebody did this, it must have bugged every wheel maker ever that scaling with tweakscale is not ideal for wheels and have six exactly the same but unity scaled for various vehicles is pretty annoying. Do you envisage a free scale arrangement with no steps, this would be the most versatile and suit all wheels or a more restrictive stepped scaling arrangement ?

Not sure how free-scaling works in TS, so not sure what the analogue will be.  It will use the stock UI_ScaleEdit UI control, that has both < and > buttons and a fine-tuning slider.  So 'free' scaling I would guess; it won't be in only discrete steps only, but should be tunable within those steps as well.

 

15 hours ago, damerell said:

I added to the linear relationship there a maximum torque - below the corresponding rotational speed torque does not increase and so power output drops. This seems to be typical in EV applications - presumably there comes a point where putting the motor's full stall torque into the gearbox will just cause something to break.

If you are referring to the initial torque output from the start of application of throttle -- I will be handling it in a different way, by implementing a spool-up time and/or throttle response speed/delay.  Either way the throttle won't be going from 0-1 instantaneously, there will be some spool up time as a delay.  So the -effective- torque output curve will go from 0 - ~0.95 within the first bit, and then linear from there down to 0 at max rpm.

So, should look about like the img below if it were plotted (though perhaps the left slope would be even steeper):

 

[SpannerMonkey(smce)]

6 minutes ago, Shadowmage said:

So yes, this will work with old wheels

Hi thanks for that, obviously got an error in my setup then, i'll investigate. In more positive news I've got the twin wheel beam axle and comp truck module working again,  still have suspension issues likely due to an error in translation with the constrain FX  locking the suspension instead of pining a joint to a position.   This is based on work LoFi and i did way back when which ensures that we don't have that horrible stretchy suspension effect that you see on wheels like the M1 and keeps every joint pinned in place through the full range of movement

Have you tried a dual wheel steering suspension setup ?  As I'm having a problem or two , now the steering works, the brakes and drive works but I can't disable or invert the steering , i f i can't do it this way I'll have to make a version with no steering for the rear and keep the full steering version for the fronts

For ref some images,  both sides are intended to be fully independent in suspension movement and this was possible in 1.0.5  and was the best simulation of an across the frame  beam axle ( rather than a cantilever)  that doesn't use IR for the Diff pivot i could get working

Spoiler

Below it's not supposed to look like this, this is with the bare minimum of unity collider settings and is supposed to have 0.6 suspension travel per side, thats 0.3 each way, obviously it's extended way past it's intended position, all cfg offsets targets are zero, as mentioned above i think this is due to the complex constraint system getting messed up when i extended the suspension to the latest KSP position which is fully extended,  Do i need to do this though as I see mentioned that you dealt with similar issues when cfg'ing the stock wheels

 

[Shadowmage]

21 minutes ago, SpannerMonkey(smce) said:

Hi thanks for that, obviously got an error in my setup then, i'll investigate. In more positive news I've got the twin wheel beam axle and comp truck module working again,  still have suspension issues likely due to an error in translation with the constrain FX  locking the suspension instead of pining a joint to a position.   This is based on work LoFi and i did way back when which ensures that we don't have that horrible stretchy suspension effect that you see on wheels like the M1 and keeps every joint pinned in place through the full range of movement

Have you tried a dual wheel steering suspension setup ?  As I'm having a problem or two , now the steering works, the brakes and drive works but I can't disable or invert the steering , i f i can't do it this way I'll have to make a version with no steering for the rear and keep the full steering version for the fronts

For ref some images,  both sides are intended to be fully independent in suspension movement and this was possible in 1.0.5  and was the best simulation of an across the frame  beam axle ( rather than a cantilever)  that doesn't use IR for the Diff pivot i could get working

  Reveal hidden contents

Below it's not supposed to look like this, this is with the bare minimum of unity collider settings and is supposed to have 0.6 suspension travel per side, thats 0.3 each way, obviously it's extended way past it's intended position, all cfg offsets targets are zero, as mentioned above i think this is due to the complex constraint system getting messed up when i extended the suspension to the latest KSP position which is fully extended,  Do i need to do this though as I see mentioned that you dealt with similar issues when cfg'ing the stock wheels

 

Would you mind posting/PM'ing the .blend and .cfg files of that model so that I could peek at the hierarchy and setup (or alternatively, the .mu and .cfg files)?  Seems that it should be doable without too much difficulty.

Suspension misalignment -- seems that you'll need a suspension offset specified, the sign and value dependent on how you have your wheels and suspension transforms positioned in the model.  For 'zero suspension offset' the wheel collider should be positioned at the top of its travel, as should the suspension transform (both should be in the exported model as if they were fully compressed);  if they are positioned in any other way you will need to specify offsets (potentially for both suspension and wheel collider).

Otherwise, I don't see any problems with the models that you linked, should be doable with the existing collider and part-modules.  Independent suspension -- check (the tracks do this already).  Independent steering -- not tested, but should work (and should give steering lock and inverts on a per-wheel).  Independent motors -- again not tested, but should work; should be able to have independent L/R wheel motors, with their own controls.  (If the controls aren't showing up, try toggling the 'show controls' button a time or two... I noticed it would occasionally display the wrong state)

[SpannerMonkey(smce)]

10 minutes ago, Shadowmage said:

For 'zero suspension offset' the wheel collider should be positioned at the top of its travel, as should the suspension transform (both should be in the exported model as if they were fully compressed);  i

Good to know as that's the export condition from 3ds , so I have no need to rotate to full extension

 

[riocrokite]

35 minutes ago, Shadowmage said:

Awesome stuff in development

 

This is going to be great One question, will it be possible to use legacy system for motor power? -> something like torqueCurve similar to pre 1.1 ksp?

[Shadowmage]

51 minutes ago, riocrokite said:

This is going to be great One question, will it be possible to use legacy system for motor power? -> something like torqueCurve similar to pre 1.1 ksp?

The torque output graph noted above is already from a torque curve.  So yes.  The default curve just happens to be linear (only two points) and goes from 1 -> 0.  However the system is built around zero torque at max motor RPM, so however you define the curve mid-points, the first point should be >0 (or there will be no torque when starting from a stop), and the last point should be zero (or there will be no limit to acceleration).

[SpannerMonkey(smce)]

A short time later and after some tips from the master   It lives

And you certainly can't do this with stock wheel modules, spent a month trying before switching to the Shadowmage API and managing to get it all working in less than a day, one very happy customer Indeed

 

Ps next  restoration is a two part 8 wheeled buggy with 4 built in wheels per half, that should be fun

 

[SpannerMonkey(smce)]

PPs the unit in the video will get longer shocks  tomorrow allowing for at least another 200mm of travel, thinking i could  add extra colliders in order to make the transition to steep terrain easier , rotated 10deg would do i reckon,

[Shadowmage]

Spent a few hours this morning working on tracks motor/torque/rpm/linear-velocity integration and cleanup.  The previous implementation was violating conservation of energy as it was simply averaging the wheel RPM values, ignoring their radius and mass.  Some setups would gain energy, some would lose it.

The new implementation calculates the total energy of the track system and sets the linear velocity of each wheel appropriate to conserve the total system energy while giving the same linear surface velocity to each 'wheel' in the track.  Have put in some equations/calculations below... if anyone else is familiar with the subject matter, please double check my calculations as I pretty much eyeballed the functions...  could very well be missing some conversions somewhere...

Total system energy = sum of each (wheels angular velocity * moment of inertia)    (this value is essentially a torque, the total torque of all wheels in the track)
Total wheel radius = sum of all wheels radius  (seems weird to sum the radius, but it works when fed into the below functions)
Wheel energy share = (wheel radius / total radius) * total system energy   (this is the share of total system energy for a given wheel, which should give the same linear surface velocity)
Wheel new angular velocity = wheel energy share / wheel moment-of-inertia  (this is the part that 'averages' the wheel RPM, converting the 'torque' back into velocity)

In my spreadsheet that I'm using this gives each wheel in a set of wheels the same resultant linear surface velocity while conserving the total energy of the system.

A similar radius/MOI based system will be used to determine each wheels' share of the input torque that will result in a constant linear-velocity increase across all of the wheels that make up a track.  Looking at the math it is mostly the same functions but arranged slightly differently....

 

 

In general development news:

Scaling is implemented and working.  A bit of cleanup to make sure that all features that are supposed to scale actually do (such as load ratings and some GUI min/max values), but was working quite well during testing last night.  All of the scaling values are adjustable through the in-game settings menu including:  part mass, part cost, wheel mass, wheel max speed, wheel max load, motor torque, motor max rpm, and rolling resistance.  Currently they are -all- set to cubic scaling (x * (scale ^ 3)), but as stated, are easily adjustable through the in-game settings menu.

One of the next 'very important' things that will need to be worked on (before I can publish the next updated release) is figuring out the initial balance (load rating, motor torque, gearing) for each of the KF wheels/tracks, as well as figuring out the best scaling powers for each of the affected values (default is cubic, some functions may need other scaling).  As this is a -highly- subjective subject, I'll likely post up some details on each wheel and ask for feedback/suggestions as to where to best position each one.  Expect something along these lines a bit later this week, probably tomorrow/tomorrow-evening.

Ideally I'd like to find a decent load rating and motor rating for each wheel as used on a 'reference' craft; this would be a craft that where a specific wheel at its default scale would be seen as 'ideal' for that craft in a normal 4-wheeled (or 2-tracked) scenario, where the wheels both look appropriately sized and have appropriate travel for the intended use.

I suppose the best place to start on this would be to ask for pics (and mass stats) for a selection of craft from you guys where you would consider the wheels used to be 'ideal' for the particular craft.  Anyone have pics of craft using the KF wheels (at default scale) that they wouldn't mind sharing in the name of helping out development  (please note the craft mass as well...)?

 

(Most of this can be applied to the stock wheels as well, as I would like to finish up/fix up their patches and conversion; they will all need the load and motor stats determined as well).
(If not enough information can be put together through the thread for the initial balancing, I'll attempt to do some reference craft designs.... but please keep in mind that my craft design techniques are simplistic and spartan, and the resultant balance would reflect that (e.g. load-shares might be far lower than if others had designed the reference craft)).

 

[SpannerMonkey(smce)]

55 minutes ago, Shadowmage said:

I suppose the best place to start on this would be to ask for pics (and mass stats) for a selection of craft from you guys where you would consider the wheels used to be 'ideal' for the particular craft.  Anyone have pics of craft using the KF wheels (at default scale) that they wouldn't mind sharing in the name of helping out development  (please note the craft mass as well...)?

I'd be happy to knock some stuff together with KF wheels, I have a ton of rovers around at the moment from trying the Dakar challenge.  Just a matter of swapping wheels and spending some time on setup  , no probs

Spoiler

 

Edited January 10, 2017 by SpannerMonkey(smce)

[Shadowmage]

Since I got the tracks torque/speed averaging stuff figured out, I've done a bit of work on a feature that I'm sure will make a couple people happy:  half-track steering support.

With 'Half-Track Mode' enabled the tracks work like normal while going 'forward', but will invert their steering when in reverse.  Currently only triggered by actual reverse motor input, but will also be setting it up to be triggered by reverse wheel rpm.

 

Rapidly checking things off of the 'todo' list.  Next up will be finding the best method to handle 'default' steering curves.  Not too much left to be done before I'll be ready for an official KF release, possibly even sometime this weekend.

 

@SpannerMonkey(smce) - If you don't mind sharing -- where did you find that rover test track at, and what all is needed to get it working? 

My current rover testing is limited to the area around the KSC and the bumps on the crawlerway, and the rubble from whatever buildings happen to be destroyed at the moment.  Would be nice to have a proper testing area though.

[damerell]

On 09/01/2017 at 4:21 PM, Shadowmage said:

If you are referring to the initial torque output from the start of application of throttle -- I will be handling it in a different way, by implementing a spool-up time and/or throttle response speed/delay.  Either way the throttle won't be going from 0-1 instantaneously, there will be some spool up time as a delay.  So the -effective- torque output curve will go from 0 - ~0.95 within the first bit, and then linear from there down to 0 at max rpm.

I'm not talking of response time but the relationship between torque and engine RPM. I dug into this a bit more because what you have done is correct based on the actual properties of electric motors, but nearly all EVs have a flat section to the torque curve from 0 RPM up to some point where it transitions to torque inversely proportional to RPM.

It turns out this flat section is not an inherent property of the motor but produced in software - there comes a point where the vehicle has too much acceleration (given that an EV designer also knows the mass of the vehicle) either to be safe or simply because if more torque was applied at zero speed the tyres would be badly damaged.

So I think what you have is entirely correct - but there may in future be a desire for a user-set torque cap, if it turns out players with on/off throttles are doing wheelies away from a stop (especially in low-g!)

ETA: if it's already in the current version you may now point and laugh at me.

Edited January 11, 2017 by damerell

[SchwinnTropius]

1 hour ago, damerell said:

I think what you have is entirely correct - but there may in future be a desire for a user-set torque cap, if it turns out players with on/off throttles are doing wheelies away from a stop (especially in low-g!)

But wheelies are awesome!