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

[DeadOnDuna]

5 minutes ago, Fireheart318 said:

Save for the hoverpads. Those just make things faceplant around like a drunken horse

I thought i wouldn't build a rover again ... tracks are good enough for me ... for now ...  I believe  "minor" problems will be corrected ...

[Shadowmage]

2 hours ago, SpannerMonkey(smce) said:

Hi, tested the latest DLL and sorry to report   I'm having nothing but grief , nothing i've built so far  to use the plugin works straight away as it was left, and when i get it set up ,  it's move two feet break a wheel move 1 meter break everything , even things like a little two wheeler (resto from 0.18!) which is very light, cant move without breaking wheels or suspension.  Sadly as i couldn't get anything to launch with endlessly repairing wheels I can't say anything about the rest of the changes  Fortunately a quick revert to the old version puts everything right.

Am I missing something? The little two wheeler (pseudo motorcycle) has naturally very small wheels, and I just can't get any speed out of it, upping the motor torque has a small effect, upping the wheel rpm has a negligible effect, it's almost as if the brakes were on all the time.  SO what have i missed? as i understand it the collider fitted in unity is removed and any setting applied go with it,  apart from travel and diam which of course translates to the cfg value, so is there an issue with rolling resistance?  There's something odd happening here as at rest the vehicle appears to slip around slightly and slide down gradients, whereas under power it shows rapid reduction in speed when the go button is released indicating some king of drag perhaps.  

  Reveal hidden contents

 

 

There are two different wheel damage systems in play -- speed, and load.

Current defaults for speed is based on max rpm of 400 for a wheel -- a small wheel will have a max speed of... <10m/s.  This can be adjusted in the KSPWheelBase config by adding a 'maxSpeed = XXX' in m/s to the config.  If the max safe speed is exceeded for a duration, the wheel will 'pop'.  NOTE:  There is currently a problem with this where super-torquey motors will output enough torque in a single tick to push the wheel past its max safe speed, this is due to the simple euler integration being used;  upping the 'wheelMass' is a temporary fix, but I'll be investigating a more proper derivative based integration for motor torque.

Load based damage currently uses the 'maxLoad' specified in the KSPWheelBase.  If the max load is exceeded for a duration, the wheel will pop.  maxLoad is specified for the entire part;  for your single-part test vehicles you should make sure it is at least the mass of the part * 1.5.

Both can be disabled by going to the difficulty menu and selecting the 'NONE' wear/damage type.  Independent multipliers can be adjusted there as well to turn off (or tune) the damage amount from speed, load, etc.  ('advanced' damage model is not-yet-implemented and defaults to using the code for the simple model)

No, you didn't really miss anything, but I had not explained any of the damage stuff before (and much of it is still WIP) -- I probably should have mentioned that you should turn off the damage stuff until it is finished

 

50 minutes ago, Fireheart318 said:

I'll elaborate - Y'know how wheels work when they get pushed around with the brakes on? They work like that, you cannot adjust the friction, suspension, anything. So combine weird twitchy friction with a high rideheight and y'got a drunk horse plane thing

...Umm.. maybe because their plugin hasn't even been written yet and they are simply using the entire wheel system at the moment?  ( dynamic friction is turned off, but the static friction/sticky friction is still enabled, which is probably what you are seeing ).  Also, I have never used the repulsors in previous versions of KF (always too sci-fi for my uses)... so I have no idea what they functioned like before; having no means of comparison, they will likely function a bit differently in the new releases.

These will (if I don't decide to drop them entirely) use a custom plugin that is more....accomodating... to the features needed by repulsors.  As repulsors are simply a spring/damper without any of the extras, I'll be coding a plugin/module specifically for them that doesn't use the rest of the wheel system (which is in fact built for wheels/tracks/etc).  This will also give me an opportunity to add load-based-EC use, multiple angled raycasts for 'self-righting' features (the will use a bit of something like a 'cone-cast'), and add in proper support for levitation over water.

The custom repulsor plugin may or may not make it into the first release; have a few other things I need to clean up first that effect all wheels (damage stuff, UI cleanup).

In short -- have some patience.  Or.. the PR button is that way --> https://github.com/shadowmage45/KSPWheel

Edit:  They seem to work fine for me?  This craft is nice and floaty, just kind of drifting about.  I'm seeing zero friction on this (only air drag is at play).  So perhaps some pics of your craft and stats might be needed to figure out what problem you are having?  (Could also be the aforementioned differences in expectation -- I say these function fine for me, but I have no idea what the old ones worked like)
 

 

6 hours ago, TiktaalikDreaming said:

I'd be inclined to have a torque curve that's cfg configurable like the ISP to atmo curves.  And just build in some defaults.  Just pick a fairly simple system for best-fit to match the curve points and off you go.

Already implemented, and in-use.  The default curve just happens to be a BDC type linear curve.  Others curves could easily be used / built for specific wheels where needed, including something closer to an ICE type torque curve (though some of the other features for good ICE simulation are not in place yet).

 

 

[SpannerMonkey(smce)]

57 minutes ago, Fireheart318 said:

I'll elaborate - Y'know how wheels work when they get pushed around with the brakes on? They work like that, you cannot adjust the friction, suspension, anything. So combine weird twitchy friction with a high rideheight and y'got a drunk horse plane thing

HI well I tested them using the same DLL that you have and I don't really see any problems, they seem to work exactly as I'd expect Adjustable friction  was not a feature of the originals, the big deal was that they had to be controlled by other means rather than just being an invisible wheel, which is doable, but not the intention of LO FI when he made the repulsors.

What i will say is that the task of tweaking each unit individually  once launched is a tad onerous, but in defense the code does seem to pick up on the actual load very well and set the suspension at an appropriate level to start.

Would be interested to see the craft you are having trouble with

[Shadowmage]

2 hours ago, SpannerMonkey(smce) said:

Am I missing something? The little two wheeler (pseudo motorcycle) has naturally very small wheels, and I just can't get any speed out of it, upping the motor torque has a small effect, upping the wheel rpm has a negligible effect, it's almost as if the brakes were on all the time.  SO what have i missed? as i understand it the collider fitted in unity is removed and any setting applied go with it,  apart from travel and diam which of course translates to the cfg value, so is there an issue with rolling resistance?  There's something odd happening here as at rest the vehicle appears to slip around slightly and slide down gradients, whereas under power it shows rapid reduction in speed when the go button is released indicating some king of drag perhaps.  

Also, I should mention that quite a few config fields have changed names/been added/been removed in the past week, so some of the previous config fields may not work any longer.  These names/fields may not be final yet, but are pretty close to what will be in the first KF releases...

KSPWheelBase has the following fields that need configured concerning damage calcs:
maxLoadRating = maximum safe load for that part, in tons.
maxSpeed = maximum safe linear velocity of wheels for that part, in m/s

KSPWheelMotor has the following fields that need configured concerning motor output:
maxMotorTorque -- output torque of the motor at 1:1 direct-drive. 
maxRPM -- max RPM of the motor
motorPower -- EC/s use at max torque
gearRatio -- XXX : 1 gear ratio for motor output.

KSPWheelDamage has the following fields that need configured:
impactTolerance -- maximum sustainable impact, in m/s -- should generally be higher than the max safe speed.  This is used for instantaneous impacts, before any of the loading is checked (an impact can also overload the wheel and break it that way).
 

[SpannerMonkey(smce)]

Once again some great info cheers and confirms a lot of my suspicions .

  Re repulsors and how they worked in KF,   they consumed EC , they could be toggled on or off, when off they are totally disabled and the vehicle will drop to the ground, which is handy as stopping land speeders is an art form   And once again there was group control over all units fitted to a craft so 1 tweak tweaked all . And they had absolutely zero friction in any direction

[SpannerMonkey(smce)]

25 minutes ago, Shadowmage said:

a small wheel will have a max speed of... <10m/s

Will this not cause problems with landing gear,?  .If of course you are using similar systems for that, there's not many aircraft airborne before that speed and certainly not many that could safely land at those speeds, being well below stall speed of most aircraft

[Shadowmage]

Just now, SpannerMonkey(smce) said:

Will this not cause problems with landing gear,?  .If of course you are using similar systems for that, there's not many aircraft airborne before that speed and certainly not many that could safely land at those speeds, being well below stall speed of most aircraft

Yes, which is why the default 400rpm bit can be overridden manually in the KSPWheelBase config (maxSpeed = xxx   in m/s). It probably should be custom specified for many wheels, especially when used on landing gear.  It was important to have some sort of default specified though as the 'maxSpeed' drives both the steering curves and damage models.

The current 400rpm was chosen specifically to limit the max speed on the KF mole-track and large wheel to something... reasonable... (to me anyway), in the range of ~60m/s.  Even this may be a bit low for the large wheels, can easily be adjusted if needed (and probably will).  Smaller wheels should probably have a non-linear increase to the max rpm comparatively, as smaller wheels often can and do operate at higher RPM.

In the end most parts will probably have custom values specified, and even the default value or calculation may be adjusted further.

[Shadowmage]

So, have just fixed up (rather, added some workarounds) to the 'high-torque motor driving wheel past max rpm in a single physics frame' problem.  Added some sub-step integration for motor torque and wheel acceleration which should help with all but the most ridiculously overpowered wheels.  This is not the final solution that will be used, but should be good enough for now.  As an added bonus this should help with traction a bit as well (less slip = more grip!).  The final solution will be the rework to RK4 integration, but I'm still learning the methods and investigating solutions to the lack-of-access to PhysX integration code.

Any sort of wheel-grouping features are still a bit down the road.  They are badly needed for some of the wheel features (gearing, steering/motor controls), but I don't want to even try and use the stock right-click menu for such a complex feature; it would be a pain to code and maintain, prone to bugs, and further clutter up an already quite busy UI for the parts.  This will probably be one of the next big features that are worked on.  Initial implementation will probably use the standard Unity IMGUI system (e.g. MechJeb windows), but after the feature-set and layout are finalized I'll investigate moving it to the Unity prefab-gui setup (which is more efficient and generates less garbage).

Have also cleaned up the repulsor implementation a bit to remove the sideways static friction, and am working on adding energy use and an on/off toggle (with smooth turn off/turn on mechanics).  For now the repulsors will still be using the rest of the wheel code, but a bit in the future I'll work on a custom implementation that will make them much friendlier to use.  They will probably have their own vehicle-level control GUI with some repulsor specific features (like an 'auto-level' button), as well as repulsor grouping and per-group height / power adjustments.

 

Bit more code-side work to do on things today, and then will start on the KF repository rebuild and config cleanup and initial balance pass on the KF parts.  Still on-path for an initial KF release tomorrow afternoon (hey, look, the times are getting more precise ).  At this point there should be any surprises that could pop up, and the largest time-consumer will be the part-balance pass and config cleanup (or perhaps setting up the promo material).

As I'm absolutely terrible at promotional materials (and interesting craft design in general) does anyone have any 'awesome' screenshots of craft using the KF parts that they wouldn't mind sharing to be used in the new KF thread?  I've got a couple, and I can probably re-use some from the old-thread if needed, but would rather have some more up-to-date stuff if possible.

[damerell]

I always thought of the mole track as some sort of crazy alien tech, but not sure what kind. But 60 m/s is pretty huge!

[Fireheart318]

KF - I just tried using the small rover wheels and they did ABOSULTULEY NOTHING! They wouldn't turn, the suspension didn't work. Either I've got a bugged install or something has to be fixed quickly!

[Shadowmage]

37 minutes ago, Fireheart318 said:

KF - I just tried using the small rover wheels and they did ABOSULTULEY NOTHING! They wouldn't turn, the suspension didn't work. Either I've got a bugged install or something has to be fixed quickly!

Either you've got a messed up install, or wheels are put on upside down, or the current configs for those have problems, as they are certainly working in my dev setup.

In the editor the arrow needs to point up.  They also have -very little- suspension travel and almost no clearance, so need to be mounted at the very bottom of a chassis, preferably on a swing-arm.

Wasn't sure if you meant the 'small' or the 'tiny' wheels, so took pics of both (as both are working)

[Fireheart318]

The top one

[Shadowmage]

23 minutes ago, Fireheart318 said:

The top one

Pics of craft that is having the problem?

[Fireheart318]

2 minutes ago, Shadowmage said:

Pics of craft that is having the problem?

Loading game. Gimme a few...

[Fireheart318]

As well as this, the medium wheel behaves like a hoverpad

[sebi.zzr]

44 minutes ago, Fireheart318 said:

As well as this, the medium wheel behaves like a hoverpad

Why not test this with without other mods and post some logs?!

[Shadowmage]

59 minutes ago, Fireheart318 said:

As well as this, the medium wheel behaves like a hoverpad

On the 'small wheel' issue -- something is obviously wrong with your install as when you click on the part in the video there are zero wheel-related options.  There should be at least a motor ec/s and a 'show wheel controls' button on that part.

Seems possible that whatever mod/patch/etc is causing that could also be causing problems with your repulsors.

[Fireheart318]

2 hours ago, Shadowmage said:

On the 'small wheel' issue -- something is obviously wrong with your install as when you click on the part in the video there are zero wheel-related options.  There should be at least a motor ec/s and a 'show wheel controls' button on that part.

Seems possible that whatever mod/patch/etc is causing that could also be causing problems with your repulsors.

The 'small wheel' issue is occurring with ALL KF wheels

[Madrias]

I will admit, I'm not running the latest version, but I may be able to offer up a bit of assistance.

This mod doesn't wipe out the old KF parts, which means that the old parts that won't work, and the new parts that do work, are both active at the same time.

What I suspect has happened is you've unintentionally built your craft with the old KF parts.  I don't know if it has been changed, but the ones I've used have "KSP Wheel" in front of them.  They should work.

[damerell]

13 hours ago, Shadowmage said:

KSPWheelMotor has the following fields that need configured concerning motor output:
maxMotorTorque -- output torque of the motor at 1:1 direct-drive.
maxRPM -- max RPM of the motor
motorPower -- EC/s use at max torque
gearRatio -- XXX : 1 gear ratio for motor output.

In the discussion earlier, I missed the main point. One doesn't have to set both max torque and max power because they are directly derivable from each other. The line on the torque vs. RPM graph with max torque inversely proportional to RPM corresponds along its entire length to the same power output, the maximum of the part.

If you can set both power and torque variables here, the effect will be to make parts have varying efficiencies - perhaps wildly varying ones, or even a motorPower which (at whatever EC:J conversion rate one agrees on) which produces a >100% efficient part.

I suggest the variables here should be motorPower and an optional partEfficiency (default, let us say, 0.95). The throttle setting produces a fraction of motorPower in EC/s. That's converted into watts using whatever EC:J conversion rate you decide on (ISTR 1EC=1kJ). That's multiplied by partEfficiency to produce the output power in watts. That can then be divided by the current part RPM and the conversion factor listed above to produce the current torque. [1]

There's no need to produce a maxTorque because torque is necessarily directly determined from power and part efficiency.

Furthermore I still think that a reasonable starter value for motorPower will be directly proportional to part mass, perhaps with a lower multiplication factor for treads. This will be easy to TweakScale up or down and if it is done this way the torque produced by a TweakScaled part will always be correct.

[1] If that's more than the hypothetical user-set maximum, the proportion of it which is excess can be used to remove a like proportion of the input power.

[silentvelcro]

Hello @Shadowmage i just wanted to thank you for your great mod! It really saved my X-20 DynaSoar mod. I would have not been able to make the landing skids work if it wasn't for your great work.
Check it out here if you want.
Cheers and keep up the good work!

[Mannschaft]

Are you the guy that's going to bring foundries to 1.2.2? If I give you $500USD right now will you finish it?

[Shadowmage]

Updated KSPWheels release is available:

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

See the link for downloads and change-log.  Remove any old KSPWheel versions before installing.
 

Also... KerbalFoundries initial (re)release is available on its new forum thread:

 

[damerell]

16 hours ago, damerell said:

In the discussion earlier, I missed the main point. One doesn't have to set both max torque and max power because they are directly derivable from each other. The line on the torque vs. RPM graph with max torque inversely proportional to RPM corresponds along its entire length to the same power output, the maximum of the part.

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.

[0111narwhalz]

On 1/13/2017 at 2:00 PM, Shadowmage said:

But anyway, its not me coming up with those units -- I was merely posting data that had been derived from other sources (e.g. see the USI/NF nuclear reactors; they list power output in KW, and output that listed value in EC/s).

Ah, but if ec/s is power (kW), then that means ec must be energy (kJ). As for motors reporting in watts, not joules: That makes sense. You should likewise use ec/s, not ec.