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

[TiktaalikDreaming]

1 hour ago, damerell said:

Of course this was not quite right.

If torque is inversely proportional to RPM, that would produce infinite torque at 0 RPM and produce a curve on the graph not a straight line. Oddly http://lancet.mit.edu/motors/motors3.html which you cite above first says "torque is inversely proportional to the speed of the output shaft" and then shows some straight-line graphs which show nothing of the kind. :-(

I think Tiktaalik is correct when they write that real EV applications typically show an inversely-proportional relationship with a torque cap.

I still think what I wrote above is basically OK, but there needs to be a torque cap to prevent silly torque values at very low RPM. Rather than set this explicitly (with the usual issues about getting it right and TweakScale proportions) it could just be a fixed proportion of wheel diameter which would naturally make it higher on bigger parts. I'd determine the proportion by taking some part and seeing how much torque it produces at 5 m/s then guessing that's a reasonable cap.

There's always a torque cap of course.  You can apply one with software, or with broken shafts/gears/bearings.   But yes, the cap is generally going to scale up with the size/strength of the components,as that affects the breaking points.  Whether you're controlling it to match your breaking points, or just hoping things don't break.

[damerell]

8 minutes ago, TiktaalikDreaming said:

There's always a torque cap of course.  You can apply one with software, or with broken shafts/gears/bearings.   But yes, the cap is generally going to scale up with the size/strength of the components,as that affects the breaking points.  Whether you're controlling it to match your breaking points, or just hoping things don't break.

I agree that's true in reality (but I'm saying I was wrong before and there needs to be an explicit one in-game or of course comedy will ensue at 0 RPM).

[Shadowmage]

You are free to adjust torque curves if you want (for lower stall torque / flat spots on the graph near the start), but I am and will be using an 'idealized brushless DC motor' as the template for the basic wheel module/functionality.

Torque output goes from Stall Torque @ 0RPM (this is the -maximum- torque that the motor can ouput), to zero torque at 'Max Motor RPM'.  The 'max torque' specified in the motor config -is- the torque cap.  Want a motor with less torque output?  Change the gearing or decrease the max motor torque.... (or setup a custom torque curve).
Power use (EC/s) goes from maximum at 0 RPM, down to near-zero at maximum RPM.
Power output follows the standard 'power out = rpm * torque' functions, though this value is never actually used anywhere (the motor torque at a given RPM determines the power applied to the wheels).
Torque output follows power input, from max torque at zero rpm, to zero torque at max rpm.

(Note that I think there are still some... errors... in my math on calculating some of this stuff, notably power input vs. efficiency, but the above and below is the overall scheme I'll be going with)

Updated motor graph, with axis labels for each value (sadly Excel is apparently incapable of labeling all of these axis' simultaneously with their relevant domains) (purple plotted on smaller vertical axis so that it did not overlap the torque graph) (edit: and I'm not sure why I put RPM on both X and Y axis... it should only exist on X, and Y should show % of RPM I think..... yeah I'm probably terrible at making graphs..):

What happens at zero RPM is that the motor puts out max torque; that is what the 'stall torque' specification is.  With proper integration this max torque will only be very momentary before the RPM increases and torque output decreases.  There is no 'infinite torque' at zero rpm or anything like that.  (Currently some integration issues result in this first tick of output power persisting for longer than it should as integration is done in discrete euler stepping; so the motor will essentially put out max torque for PhysicsDeltaTime seconds.... which is a problem, but is a problem with integration rather than the curves/motor function modeling).

External example (note X-axis is reversed on this graph), note how input current (A) follows output torque linearly (max input current at max torque, close to zero input current at zero torque).  At a constant input voltage, this will result in constant decreasing total input watt requirement (v*a=w); hence the purple EC line in my graph above.  (This is one of the only external graphs I could find in a quick search that shows input current / input power as well as the rest of the stats).

1.2a @ 7.2v = 8.64w max input
output peak = ~1.1w (from graph) @ ~30rpm, [email protected] input = 4.32w input, eff = ~25%, torque = ~375 mN*m
eff peak = 35% @ ~55rpm, ~124 mN*m, 0.4w output, [email protected] input = 1.44w input  (0.4/1.44 = ~27% calculated efficiency; error likely due to inaccuracies in reading the graph)

 

Edit:  Hmm... also this:
 

public class KSPWheelDustEffects : KSPWheelSubmodule

... Might mean interesting things in the next release....

Edited January 16, 2017 by Shadowmage

[Shadowmage]

Holy rainbow puke batman!:

Really that is just me testing out particle emission.  I set the colors animation array to some random arbitrary colors (black, white, cyan, magenta, blue)... and well, that is what I got out of it -- random rainbow colored particles

But, at least I have the first-step of the dust-fx stuff working -- getting the things to emit something   Now comes the 'easy' part of linking it in to the wheel parameters, and looking up the dust color from the biome map, and setting the rest of the emission parameters from the settings and state.  May add some additional handling for some of the standard KSC prefabs so that there is little/no dust thrown up when traversing the paved portions -- but unsure if things are built in such a way that it will be doable.

This may not seem very exciting, but you'll just have to trust me when I say 'it really is!'.

Edit: A bit more serious -- some repulsors kicking up some dust, with various settings for speed/size/emission/energy (playing with settings, learning the particle system a bit)

More edit:
Biome color lookups working (using the old/original color maps).  Have dust emission factors working based on current forward-speed, side-slip, and wheel load (as compared to max load).

Sadly KSP's biomes don't exactly have clear boundries, so the color can be a bit off.  This is in the 'shores' biome, which has a lookup color of a sandy-brown.

May or may not work back in the camera-polling dust-color methods.  I'm really unfamiliar with the code so might take a bit of time to work it (though, that is what I thought of the dust-emission stuff too, but that only took a few hours to get working).

Still a few bits to clean up, but looks like there will be at least some form of working dust system with the next KSPWheels update (KF will need config updates to enable it, so will need a new release there as well).

Edited January 17, 2017 by Shadowmage

[damerell]

14 hours ago, Shadowmage said:

Torque output goes from Stall Torque @ 0RPM (this is the -maximum- torque that the motor can ouput), to zero torque at 'Max Motor RPM'.  The 'max torque' specified in the motor config -is- the torque cap.  Want a motor with less torque output?  Change the gearing or decrease the max motor torque.... (or setup a custom torque curve).

Power use (EC/s) goes from maximum at 0 RPM, down to near-zero at maximum RPM.
Power output follows the standard 'power out = rpm * torque' functions, though this value is never actually used anywhere (the motor torque at a given RPM determines the power applied to the wheels).
Torque output follows power input, from max torque at zero rpm, to zero torque at max rpm.

Well, you're implementing it, sort of thing, but I am a bit concerned that with no inherent link between power use and the power output that would be calculated from the torque, you may end up with parts with wildly varying (and perhaps >100%) efficiencies. In particular if these values are TweakScaled incorrectly that is almost bound to happen.

I've re-edited this to reflect that you're trying to get a real-world efficiency curve, which is ingenious, and hence is why my idea of a fixed partEfficiency won't work.

However, rather than being determined in the configuration file, the maximum power output could be calculated from torque and RPM at the "sweet spot" in the middle. The advantage would be that the power usage for parts will be "just right" - if someone does go in and halves the max torque, hey presto, the power usage will halve as well. Of course this will be very advantageous when TweakScaled.

(I still think power usage should vary with part mass. In a TweakScale world that could be achieved by multipling up max RPM and torque by factors that multiplied together give the cube of linear dimension...)

Edited January 17, 2017 by damerell

[Shadowmage]

6 hours ago, damerell said:

Well, you're implementing it, sort of thing, but I am a bit concerned that with no inherent link between power use and the power output that would be calculated from the torque, you may end up with parts with wildly varying (and perhaps >100%) efficiencies. In particular if these values are TweakScaled incorrectly that is almost bound to happen.

I've re-edited this to reflect that you're trying to get a real-world efficiency curve, which is ingenious, and hence is why my idea of a fixed partEfficiency won't work.

However, rather than being determined in the configuration file, the maximum power output could be calculated from torque and RPM at the "sweet spot" in the middle. The advantage would be that the power usage for parts will be "just right" - if someone does go in and halves the max torque, hey presto, the power usage will halve as well. Of course this will be very advantageous when TweakScaled.

(I still think power usage should vary with part mass. In a TweakScale world that could be achieved by multipling up max RPM and torque by factors that multiplied together give the cube of linear dimension...)

Indeed, you have a valid point regarding efficiency.  Which is why the current 'motorPower' specification in the configs is a temporary measure.  The plugin already supports loading a 'motorEfficiency' value, which is what I would like to use to calculate motor input at any given scale (output power depends on scale);  put into the config the 'maxMotorTorque' and 'maxRPM', and 'motorEfficiency' for the default scale of the motor, and the rest will be calculated dynamically based on the current scale.

The problem was that I did not have time / was unable to figure out quickly how to implement calculating backwards from motor max torque and efficiency value to motor input power values.  I'm sure it can be done, but I was unable to get it done in time for the initial KF release.  Seems like there are also a couple other bits of data that will need to be known on the motor (or set to defaults) that determine the slope and scale of the efficiency curve (namely the no-load current / power use while at max no-torque RPM).

Yes, motor power use / output power will rise with part mass.  Well, more precisely it rises to the ^3 which is currently what part-mass also scales with (they are separate scaling power options in the settings menu).  Unsure how to handle max motor RPM scaling; it would almost have to be tied to the max-part-speed scaling (or else scale changes would require default gear changes).

 

The current 'balance' on the KF parts went mostly like this:
maxLoad = 20 * partMass (in tons)
motorPower = enough to accelerate the part @ max load at 3,5, or 10m/s/s at stall torque (3,5 or 10 depends on the part; is it a slow part like a probe-rover wheel (3) a track (5), or other wheels(10))
maxSpeed = 23, 43, or 63 m/s (tracks, wheels, med wheel (as it says it is supposed to be fast)
maxRPM = direct-drive 1:1, max RPM selected to make part hit max speed at default scale.
motorInputPower = whatever was needed for 85% efficiency for the calculated motor power and max RPMs; I iteratively typed in values until I found one close enough for this initial pass.

[Shadowmage]

@SpannerMonkey(smce)

In regards to your custom multi-wheel parts -- I should probably mention something that might help out the organization on them.  KSPWheels supports having multiple KSPWheelBase modules.  Simply add 'baseModuleIndex = 0/1/2/4/5/etc' to each of the sub-modules to tell it which base-module it should be linked to.  (e.g. if you have 4 base modules, regardless of where exactly they are in the config, they will be index 0, 1, etc, depending on their order in the config; it is an index-within-base-modules, not raw-index-within-all-modules)

This would allow you to put each wheel (or pair of wheels?) into its own KSPWheelBase, where the controls for that group of wheels will each be grouped for the 'show/hide controls' button.  Wheel groups should still work across multiple base modules in the same part as well.

(Please note that multi-base modules has not been tested, but -should- be working and those setups is/will be supported; if it is not for any reason, please let me know (and if possible provide files so that I can test and fix it; none of my models have multiple wheels setup like those)).

[damerell]

Gosh, the shape of the efficiency curve is another question. I hope I'm not just reiterating what I've said before, but with your torque/RPM relationship, maximum power output is always at exactly half the maximum no-torque RPM. My suggested part efficiency is then the ratio between input and output at that half-max RPM. How an efficiency curve affects power usage at other RPM is a separate question to that; all I'm trying to suggest is a value to avoid your hardcoded max power (which bakes in a hidden overall efficiency) and provides an easy way to differentiate wheels and tracks.

I quite appreciate this is all a bit beside the point when you're just trying to get something out the door.

[SpannerMonkey(smce)]

26 minutes ago, Shadowmage said:

@SpannerMonkey(smce)

In regards to your custom multi-wheel parts -

Excellent news and I'll try it out and report back

Although things have improved considerable since last postings, getting hooked on every module being equal was my downfall,  In the case of the 8 wheelers, it was definitely the wrong way to go. Instead of asking a dozen questions I set about finding setups within that cfg that would make the vehicle plug and play, rather than needing user input before use. and it turned out a simpler than I'd initially thought.

The reversal of rear steering in cfg was a simple matter of a minus in front of the steering rotation axis, and as I'd already discovered that full rear lock is undesirable I halved the steering rotation.  Tried on both large and small versions and it's faultless.  Using the latest release brought no upset or horrors to light and everything worked right out of the box, though i miss the ride height adjustment.  I've tested the new release quite extensively and without issues, very impressed how well the tracks adapt to different vehicles and masses, and if anything I'd say they perform a bit better than my fading memory of KF 1.05 recalls

Going to zip up a copy of the multwheel nonsense, it may be useful to you in some way, may also give you other ideas

 

[Shadowmage]

1 hour ago, damerell said:

Gosh, the shape of the efficiency curve is another question. I hope I'm not just reiterating what I've said before, but with your torque/RPM relationship, maximum power output is always at exactly half the maximum no-torque RPM. My suggested part efficiency is then the ratio between input and output at that half-max RPM. How an efficiency curve affects power usage at other RPM is a separate question to that; all I'm trying to suggest is a value to avoid your hardcoded max power (which bakes in a hidden overall efficiency) and provides an easy way to differentiate wheels and tracks.

I quite appreciate this is all a bit beside the point when you're just trying to get something out the door.

(Not relevant to your post)  I'm honestly a bit confused as to why output power is measured as torque * rpm -- shouldn't output 'power' be simply the torque output?  The amount of 'work' done to increase a wheels RPM comes solely from the torque; the existing wheel/motor RPM has zero impact on the velocity increase from torque (that is determined by wheel inertia/mass), so intuitively, to me, I'm at a loss as to why 'power output' is measured as all of the documents / calculators / motor data says.

However you are right as to how to calculate the efficiency under the current modeling (I believe...) -- find the midpoint of the torque/rpm, calculate the 'output power' at that point, feed in the efficiency value to derive the 'input power' at that point, and feed that 'input power half-point' back into the linear functions to derive max (stall torque) input power and min (max rpm) input power.  At least, I think that is how it should go.  Otherwise you might end up with a motor that has half-rpm input power < than peak output power, which likely violates some laws of thermodynamics / conservation of energy. 

Thanks for that info though, it let me look at the data in a bit of a different perspective and I think that should give me something to work with for calculating motor input power based on efficiency (rather than config-set input), I'll work up some functions and see what kind of numbers I get out of it.  Likely it means that the power input requirements to all of the wheels will increase substantially as their current input value was derived from the highest efficiency point on the graph, but I could also have some other conversion errors in my spreadsheets that will need to be found and fixed.

 

1 hour ago, SpannerMonkey(smce) said:

The reversal of rear steering in cfg was a simple matter of a minus in front of the steering rotation axis,

That could also be accomplished by adding 'invertSteering = true' to the config; it will set the default to inverted (and the button as well).  Though your method is probably more correct for multi-wheel parts as then it leaves the 'invert' button in proper state for the specific part/craft design (meaning it will read 'not inverted').

Glad to hear it is all working out well for you so far.  I know there are still a few problems with the wheel (and part-module) code that need to be cleaned up (UI, sliding on hills), can only hope that things are 'usable' in their current state, and know that things can only improve in the future with continued work/time/effort.

 

Spent a bit of time this morning working on integrating the dust-camera code from the old KF plugin.  Went a lot easier than I expected, so will likely have optional real-time dust color calculation based on colors of terrain being traversed.  Will be two toggles for the system in the settings menu -- one to enable/disable it entirely, and another to turn on/off the camera-lookup (if camera is disabled it will fall-back to the biome-lookup map).

Dust cameras are handled on a per-vessel basis, using a VesselModule.  Haven't played with VesselModules before, but this seemed like the ideal use-case for them (non-persistent, only exist in flight-scene).  This should be a fair step-up in efficiency compared to the original dust-fx code as it used one-camera-per-whee-part; a craft with multiple wheels on it would be doing multiple extra renders depending on the number of wheels.

Color selection also lerps between the camera polled colors between updates (it only updates once every ~3s currently, may change) so there should be smooth transitions even when the on-screen colors are changing fairly rapidly.

 

Next on the development list will be animated texture and light support for repulsors, or perhaps fixing the water-levitation support for repulsors (it will be one and then the other either way, which is first doesn't matter...).  So repulsors should be a bit more 'flashy' with the next release.

On the subject of repulsors -- I noted some behaviour during testing that may shed some light on some of the comments regarding their functionality.  Notably the point of force application is the raycast hit point (which is the contact spot on the ground) -- on a repulsor equipped craft, this manifests in the vessel seemingly riding on 'sticks' when you try and land at any kind of an angle.  Not really sure the best way to solve this; I suppose I could add some 'force-application-offset' code to the wheel-collider so that, for repulsors, the forces are applied at@ the raycast origin.

Further on the subject of repulsors -- currently they apply their force along the hit-normal of whatever surface they are contacting.  This is very appropriate behaviour for wheels/tracks/stuff using friction, but perhaps not appropriate for a repulsor.  This results in no matter the orientation of the repulsor to the surface, the output forces are always directly away from the surface (e.g 'up' as seen from the surface), and at no point does a repulsor add any 'motive' forces to the craft.

Should I adjust/alter/recode the repulsors to use 'naive' force application, using the suspenion vector as the force-application vector?  This would mean that repulsors angled towards a surface would impart velocity to a craft (and would give a, perhaps overpowered, purpose to the 'gimballed' repulsors).  If this change were implemented it would further help the 'on sticks' problem posted above, as at higher incident angles they would generate less 'up' force and more 're-aligning' force. 

Thoughts, preferences, feedback, ideas?

[SpannerMonkey(smce)]

14 minutes ago, Shadowmage said:

can only hope that things are 'usable' in their current state, and know that things can only improve in the future with continued work/time/effort.

As you're so close to it I can appreciate this sentiment but, unless my craft and tastes a re way off norm I reckon for a first release it's considerably better than you give yourself credit for. I reckon any set of wheels that can carry a 7 tonne truck 57 km without any operator input whatsoever (no RCS SAS either)  are a bit special  (btw was only stopped by a mountain that no EC drive should be able to climb)

Although I've nothing to add on the repulsors , as i've not converted the ones I have as yet,   I'll be glad to see the water capability return, as it means i can wake up the hovercraft project.  

Back to wheels however, gear ratios, brilliant I'll be going back to that mountain with a new ratio.    Is there any vague possibility that sometime in the future  some kind of on the fly selection could be made, even just as far as a two speed high low type arrangement .  This would be the icing on the cake for another rover type modlet of mine.

All in all I've not found anything to gripe about or can't see the reason for and adapt to.   Even the wheel damage which drove me mad for a day, i was tempted to turn it off or down but the all or nothing choice wasn't suitable, i don't mind consequences like broken wheels for driving like a goon.     Damage is under control for the most part now, apart from the two wheeler which had to spout thrust transforms from the exhausts, as I simply can't get it to move under wheel power without instant wheel destruction, but romping along at 30ms under thrust is no problem, and as a toy that'll do fine.

[damerell]

1 hour ago, Shadowmage said:

(Not relevant to your post)  I'm honestly a bit confused as to why output power is measured as torque * rpm -- shouldn't output 'power' be simply the torque output?  The amount of 'work' done to increase a wheels RPM comes solely from the torque; the existing wheel/motor RPM has zero impact on the velocity increase from torque (that is determined by wheel inertia/mass), so intuitively, to me, I'm at a loss as to why 'power output' is measured as all of the documents / calculators / motor data says.

Power is proportional to torque * rpm in the same way work is proportional to force * distance (and hence power pushing something in a straight line increases with the speed of the object). An ideally efficient motor exerting torque at 0 RPM burns no power because it does no work - of course, a real motor burns power from its own internal losses - just as you do no work shoving an immovable object.

This is a bit counterintuitive, but what it comes down to is that it takes more energy to shove something (with a given force) a long way than a short one.

[blowfish]

6 minutes ago, Shadowmage said:

(Not relevant to your post)  I'm honestly a bit confused as to why output power is measured as torque * rpm -- shouldn't output 'power' be simply the torque output?  The amount of 'work' done to increase a wheels RPM comes solely from the torque; the existing wheel/motor RPM has zero impact on the velocity increase from torque (that is determined by wheel inertia/mass), so intuitively, to me, I'm at a loss as to why 'power output' is measured as all of the documents / calculators / motor data says.

Torque and power are physically different things.  Torque can be thought of as how much you're pushing the wheel to rotate, which is independent of how much kinetic energy you're actually imparting to the wheel.  Torque is the rotational equivalent of force.

[Shadowmage]

Hmm... okay, so the increase to kinetic energy depends on current kinetic energy -- the higher the current KE velocity/rpm, the higher the contribution to final KE from any given force/torque?  (this would seem to line up with the KE = 0.5*m*v^2 equation, and I believe is the explanation of the oberth effect and why thrusting at periapsis is the most efficient, as that is when your kinetic energy is highest...).

However I'm still having problems seeing how that factors into motor use / output.  Certainly a given force/torque only imparts a specific velocity/rpm change that depends only on the mass/MOI of a body (and duration of that force), and not on its current velocity (or its movement during the duration of the force-application)?  But the kinetic energy change from the force/torque depend on the starting energy?  Why is kinetic energy a term in calculation of motor power (why would a motor care about the KE of the body it is accelerating?)?  (These are all more or less rhetorical questions, but if someone does have answers they may help me understand things better)

(I'm sure both of your explanations and understandings are correct and that it is my understanding that needs... enlightening...  Apparently I'm going to have to do more study/learning/investigation ....)

Torques and forces I think I have a pretty good understanding of, I'm apparently just clueless when it comes to power/energy changes from those torques/forces (velocity/rpm changes from force/torques I know well though...).  I'm sure I'll get it figured out / learned; it has been the 'learning' process that has comprised the majority of the development time for the wheel system

(And as (bad?) luck would have it, I'm working late tonight doing some very.... boring stuff... so will look into some vids/learning materials )

Edit:  Okay, so, after a bit of research, I have found where part of my understanding diverges from the textbooks -- time-vs-distance derivatives;  being so used to working in a time-dominant environment (stepped physics integration), I take for granted that many of the units used already have time as a factor.  Still more reading to be done...

2nd edit (quote from wikipedia https://en.wikipedia.org/wiki/Power_(physics) ):

Quote

As a physical concept, power requires both a change in the physical universe and a specified time in which the change occurs. This is distinct from the concept of work, which is only measured in terms of a net change in the state of the physical universe. The same amount of work is done when carrying a load up a flight of stairs whether the person carrying it walks or runs, but more power is needed for running because the work is done in a shorter amount of time.

So apparently I've been thinking 'power' when really what it should have been is 'work'.  Where power = work/time.... or something like that....  (still more reading...).  (although this still doesn't help me understand why rpm effects power; I would still think that power would be 'power = torque / time' or similar...)

3rd edit: power calculation derivatives: 
Power = ((torque/radius) * (radius * angularVelocity * time)) / time.
Cancelling out the /radius*radius and *time/time factors leaves:
Power = torque * angularVelocity
(The refactoring makes sense, but still trying to figure out where angular velocity comes into play as a term; shouldn't it be angular acceleration in the above?)

Edited January 18, 2017 by Shadowmage

[damerell]

1 hour ago, Shadowmage said:

But the kinetic energy change from the force/torque depend on the starting energy?  Why is kinetic energy a term in calculation of motor power (why would a motor care about the KE of the body it is accelerating?)?  (These are all more or less rhetorical questions, but if someone does have answers they may help me understand things better)

A motor doesn't care about the KE of the body it's accelerating, but it does care how fast the shaft is turning, because it has to push it around further every second.

I'm not sure how to explain this (and as luck would have this, I am trying to write this comment after a healthy intake of er yeasty beverages) but I should try considering matters without time as a factor. To push with a force of 1N through 2m is clearly twice as much work as pushing with the same force through 1m; to turn the shaft two revolutions exerting a torque of 1Nm is twice as much work as turning it one revolution.

Given that, if the shaft revolves twice a second rather than once, and yet we keep pushing it just as hard all the way around, we have done twice as much work that second - twice as much power.

Edited January 18, 2017 by damerell

[Shadowmage]

Got dust-camera stuff all working yesterday/last night.  Works very well; smooth color transitions, closely matching the current terrain under the vehicle, close to zero performance impact (it renders a 6 x 6 texture once every 3 seconds... thats about as 'low-impact' as it comes).

So.. yeah.. dust is working.  Still some tuning that could be done to the actual particle parameters, but it is working well as-is.  Speed/slip/compression/scale all effect the amount of dust kicked up by a part, with a minimum speed threshold for when it gets 'turned on' initially (below that speed there is no dust, regardless of any slip/compression factors).  Hit a jump especially hard on the way down and it'll kick up quite a bit of dust at the impact point (from the compression and slip), quickly tapering back down to normal levels as the compression normalizes.

Still working through the motor power calc stuff.  The good thing is that I don't really need to understand the concept in order to implement it; I can implement the math/system without knowing the why or the how... I just wouldn't be able to fix it / alter it much without a thorough understanding of the mechanics.

Have also started work on the 'repulsors float over water' bit of code.  Basically will be running an external secondary spring calculation method that kicks in when going over water.  There will be no water sliders(colliders), so there shouldn't be any grief caused by this method; it is being handled purely at the physiscs/forces level by -simulating- a suspension hit at the ocean surface.

Still undecided on the repulsor force-application point and suspension axis vs. hit-normal implementation details.  Perhaps I'll add some settings toggles to switch between the implementations and let the user choose

[DarkOwl57]

Not sure if this really fits here, but I would really like a realistic collision/physics thing, like when one wheel runs over another it LEAPS up over the other wheel, similar to an F1 car

[Shadowmage]

Re: repulsors and the questions of force-vectors and force-application points.

Example 1: current implementation

New implementation (will be testing soon):

As can be seen from my (terrible) force-diagrams, the new implementation method should result in much more stability when using repulsors.  Also they will generate 'thrust' when at a diagonal to a surface.

Technically I don't have to combine the two changes (application point, vector), and have put some debugging toggles on the repulsors so that I can play around with each setting individually and in combination to see what 'feels' best.  Just the change to force-application point should fix most of the 'on-sticks' feeling of the repulsors.  The change to force-application vector is another beast entirely, and removes the need for external engines when using repulsors -- a truly 'game changing' difference.  So going to do bit of testing on it myself, and will likely post/link to a dev-dll for others who want to try it out/give feedback prior to release.  Might just end up making both values be configurable through either part configs or in-game settings menu...

Also have the repulsor water levitation in place with a WIP implementation.  Likely some bits to fix on it when next I can do testing (I hate doing programming without ability to test stuff immediately, but such is the nature of my development time).

[0111narwhalz]

Perhaps the gimbaling ones will act as actual control elements.

[Shadowmage]

7 minutes ago, 0111narwhalz said:

Perhaps the gimbaling ones will act as actual control elements.

Strangely enough the gimballing ones don't actually include any gimbals/gimballing functionality?  At least not that I could find in the original configs, KF plugin code, or models.

What -was- the point in that part (the gimballing repulsors)?  Did they have actual gimbal functionality at some point?

[0111narwhalz]

Yeah, they (and the original ones too) stabilized themselves. The gimbaling ones did not care about orientation at all, which was quite noticeable. The surface-mount ones cared a lot, which was also noticeable.

[Shadowmage]

40 minutes ago, 0111narwhalz said:

Yeah, they (and the original ones too) stabilized themselves. The gimbaling ones did not care about orientation at all, which was quite noticeable. The surface-mount ones cared a lot, which was also noticeable.

Your comment made me take a closer look at the configs/plugins for the repulsors, and you are correct -- they do (rather, did) have gimbaling capabilities; however they are handled at the repulsor module level, using a form of 'auto-point-at-surface' gimballing rather than user-initiated gimballing.  (I was looking for ModuleGimbal, which they do not have or use).

With that said -- I'm not sure that I'll be restoring that functionality.  Keeping the repulsors pointed at the ground (e.g. keeping the vehicle right-side up...) should be the responsibility of the vehicle operator....   Will give it some further thought and perhaps add in some basic test code to see how the gimballing effects their operation (it would render the 'apply force along suspension axis' bit of code moot, as the suspension axis would effectively be the 'up' axis at all times).

I also took another look at the models and apparently they (did/could?) use 5 separate wheel-colliders and raycasts (one straight down, on each at an angle to NSEW).  Also not sure if I'll be restoring that bit of functionality; it shouldn't be needed with the updated force-application model (and would require a fair bit of code changes to get working), and about all that it would accomplish is decrease performance.

[Beetlecat]

The ability to drive around using *only* repulsers is extremely attractive, however knowing how different they are from *actual* engines/thrusters, having a limited ability there is understandable. Gimbaling and self-righting behaviors for craft sounds like something that Throttle Controlled Avionics or KOS scripts could handle.

I love the "frictionless casters" aspect of the KF repulsers, and using jet engines, speed brakes, and retro-thrusters to control navigation is easy.

Maybe a new kind of repulser that's basically a modified rocket could be utilized to get that full hover/vtol/rocket thing going (a-la those Matrix hovercraft...)?

[Fireheart318]

7 hours ago, Beetlecat said:

The ability to drive around using *only* repulsers is extremely attractive, however knowing how different they are from *actual* engines/thrusters, having a limited ability there is understandable. Gimbaling and self-righting behaviors for craft sounds like something that Throttle Controlled Avionics or KOS scripts could handle.

I love the "frictionless casters" aspect of the KF repulsers, and using jet engines, speed brakes, and retro-thrusters to control navigation is easy.

Maybe a new kind of repulser that's basically a modified rocket could be utilized to get that full hover/vtol/rocket thing going (a-la those Matrix hovercraft...)?

What's a "speed brake"?

[Shadowmage]

Yesterday / last night saw the return of repulsors floating over water.  Still on the 'todo' list regarding repulsors are additional dust-fx when over water, animated textures, and lighting.

As far as the changes to suspension --

Apply force at offset position = yes, very helpful.  Eliminates most need for the auto-gimballing that was previously present.  Will be keeping this one in place for repulsors.  Totally removes the 'riding on sticks' feeling.  Come in at a high incident angle (fwd or side)?  No problem, your repulsors will level you out when you 'land'  (as long as they are at least somewhat pointed at the ground, angles beyond 60' may see the repulsor itself collide with the ground at higher speeds due to the nature of stepped integration).

Apply force from offset suspension = meh, wasn't impressed.  Was usable, did exactly what was intended, but would overly complicate craft design and be even more in violation of physics.  Combining it with manual (ModuleGimbal) gimballing, and the effects were quite hilarious; not something that I would recommend.  Apparently the wheels don't like being driven from 5% compression to 50% compression in a single frame by the gimbal snapping back to neutral, causes massive 'jumping' force from the compression when gimbal is released (use of gimbal speed would mostly eliminate the jumping, but that feature has its own problems).  Gimbal also didn't work unless I placed a vertically-oriented control point on the craft... so useless for 'standard' designed craft; the controls were also all reversed on the gimbals, so truly unusable even if it didn't have problems with jumping.

I would like to play around with the 'repulsors can provide driving forces' a bit more (as yeah, the whole matrix-style-hovercraft are...awesome, even if unrealistic).  Or... more likely... I'll put that effort into something a bit more realistic that I might actually use in real gameplay -- plugin support for VTOL ducted fans and ground-effect flyers, helicopter rotors, and props (all electric). 

 

(Testing out repulsors over water; dust-fx works, but is barely noticeable on water at its default land settings... needs some special handling linked into the repulsors/wheels a bit to know when to activate 'water' mode)