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

[linuxgurugamer]

46 minutes ago, Shadowmage said:

For KSPRepulsor the Max EC draw is unbounded, it depends upon the load being supported.  It is calculated from ' energyUse' * wheel.spring*0.1f (current tons supported)
Current EC draw can be queried from the 'guiEnergyUse' field ( https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelRepulsor.cs#L21 ).

 

so I see a problem, the "wheel" is an internal value which I don't have access to.

Could you add a way for me to get a theoretical max EC draw, based on an entered weight (or use the weight of the vessel it is on)?

 

Edited April 2, 2017 by linuxgurugamer

[Shadowmage]

17 minutes ago, linuxgurugamer said:

so I see a problem, the "wheel" is an internal value which I don't have access to.

Could you add a way for me to get a theoretical max EC draw, based on an entered weight (or use the weight of the vessel it is on)?

 

Theoretical max EC = infinite.  There is no way to calculate it, even with knowing the vessel mass -- as at some points, while arresting downward motion, the spring force will exceed the sprung mass.

As a 'best guess' you could use (vessel.mass * energyUse); (where energyUse is the field from the repulsor module) this would give the maximum EC use if the vessel was entirely supported (at steady state) by a single repulsor.  In normal use the repulsor would not exceed that value, but might in extreme situations.

Much of this with repulsors might be changed in the next few releases.  I intend to add 'max loading' to them (in support of the damage model), which would give a maximum to the spring output, and thus a maximum to the EC draw.  When I add these features, I'll make sure there is a way to query for current and max EC use.

[linuxgurugamer]

6 minutes ago, Shadowmage said:

Theoretical max EC = infinite.  There is no way to calculate it, even with knowing the vessel mass -- as at some points, while arresting downward motion, the spring force will exceed the sprung mass.

As a 'best guess' you could use (vessel.mass * energyUse); (where energyUse is the field from the repulsor module) this would give the maximum EC use if the vessel was entirely supported (at steady state) by a single repulsor.  In normal use the repulsor would not exceed that value, but might in extreme situations.

Much of this with repulsors might be changed in the next few releases.  I intend to add 'max loading' to them (in support of the damage model), which would give a maximum to the spring output, and thus a maximum to the EC draw.  When I add these features, I'll make sure there is a way to query for current and max EC use.

Ok, I've added it using that, thanks.

I've also broken the repulsor out from the wheels, since they are rather different.

If you could ping me when you make those changes, I'll be able to incorporate the changes.

 

Edited April 2, 2017 by linuxgurugamer

[linuxgurugamer]

5 hours ago, linuxgurugamer said:

5 hours ago, Shadowmage said:

Theoretical max EC = infinite.  There is no way to calculate it, even with knowing the vessel mass -- as at some points, while arresting downward motion, the spring force will exceed the sprung mass.

As a 'best guess' you could use (vessel.mass * energyUse); (where energyUse is the field from the repulsor module) this would give the maximum EC use if the vessel was entirely supported (at steady state) by a single repulsor.  In normal use the repulsor would not exceed that value, but might in extreme situations.

Much of this with repulsors might be changed in the next few releases.  I intend to add 'max loading' to them (in support of the damage model), which would give a maximum to the spring output, and thus a maximum to the EC draw.  When I add these features, I'll make sure there is a way to query for current and max EC use.

Ok, I've added it using that, thanks.

I've also broken the repulsor out from the wheels, since they are rather different.

If you could ping me when you make those changes, I'll be able to incorporate the changes.

One more thing about the max EC use:  What I think people will really need is not what you describe as the max possible, but the max sustained, as in no springing going on.  So maybe that "best guess" will be enough

[SpaceEnthusiast23]

On 12/2/2016 at 8:53 PM, Azimech said:

Nice writing @damerell! Really love the amount of effort you've put into this!

It's a shame nobody replied. Maybe later

[Azimech]

3 minutes ago, Commander223323 said:

It's a shame nobody replied. Maybe later

Welcome to the forum! Hope you enjoy your stay.

[SpaceEnthusiast23]

On 4/22/2017 at 5:00 PM, Azimech said:

Welcome to the forum! Hope you enjoy your stay.

Thank you. Is this mod worth downloading

[0111narwhalz]

16 minutes ago, Commander223323 said:

Thank you. Is this mod worth downloading

As per my experience: very. YMMV, but I have found it quite worthwhile.

[Nightside]

25 minutes ago, Commander223323 said:

Thank you. Is this mod worth downloading

If you spend much time with wheeled vehicles then yes it is. After using these parts (and getting used to the settings) you will find that they work much more realistically than than the stock parts. 

If you only use wheels and landing gear rarely you can probably skip it.

[HafCoJoe]

I've had my eye on this for a while now Shadowmage  - Though I haven't used it because I generally play with only stock parts. Has someone made a pack for pre-1.1-esque stock wheel physics? I'd love to play around with the old physics again.

Edited April 27, 2017 by Avera9eJoe

[0111narwhalz]

I don't think KSPWheel is compatible with the old-physics model. You might be able to tweak the values into a degenerate form which approximates U4 wheels, but I think it's unlikely.

[HafCoJoe]

2 minutes ago, 0111narwhalz said:

I don't think KSPWheel is compatible with the old-physics model. You might be able to tweak the values into a degenerate form which approximates U4 wheels, but I think it's unlikely.

Aye that's what I mean sorry - the old physics model was dropped with U5, but I was wondering if someone has emulated the old physics? Or at-least done something to the stock wheels in U5 to make them less of a headache?

[Shadowmage]

KSPWheel is about as close to the U4 wheel physics as you will be able to get under U5.  In fact, the wheel collider component itself, in the absence of the KSP-based PartModules, emulates the old Unity4 wheel collider quite well as far as setup and performance goes (though it does have better friction calcs than the old U4 wheels ever did).  All of the dynamic suspension behaviour is done by the PartModules and not the WheelCollider itself.

If you look in the KSPWheels repository there is/was/should be a collection of patches to apply the KSPWheels part-modules to the stock parts.  It has not been updated/maintained in quite some time, but could form a good base to start a 'stock conversion' patch from.  ( https://github.com/shadowmage45/KSPWheel/tree/master/GameDataDisabled/Patches )

[0111narwhalz]

While you're here, Shadowmage: Could you briefly elucidate on steering bias?

[Shadowmage]

12 minutes ago, 0111narwhalz said:

While you're here, Shadowmage: Could you briefly elucidate on steering bias?

Its a quick-and-dirty form of Ackermann steering, allowing you to specify that a wheel should turn more in one direction than the other.  I believe you need to un-group the wheels before setting it up though (set the wheel to group=0), and if I remember correctly the left and right wheels need opposite bias (e.g. if left = 0.5, right should be -0.5).

[riocrokite]

hey @Shadowmage is there a manual how should I prepare the model in Unity for it to work in KSP with your KSPWheel modules? (i.e. part parenting, collider layers, animation setup etc)

edit: from what I read I have to setup proper names and values only in cfg?

another question - where I can find 'vehicle controller' component? are there any examples of its use (i.e. change values for all wheels from the pod / cabin?)

Edited May 31, 2017 by riocrokite

[Shadowmage]

4 minutes ago, riocrokite said:

hey @Shadowmage is there a manual how should I prepare the model in Unity for it to work in KSP with your KSPWheel modules? (i.e. part parenting, collider layers, animation setup etc)

edit: from what I read I have to setup proper names and values only in cfg?

another question - where I can find 'vehicle controller' component? are there any examples of its use (i.e. change values for all wheels from the pod / cabin?)

Manual -- not really.  Any of the U4-KSP-wheel tutorials should work though, rigging is mostly the same (and the remaining differences can be sorted through config).  Basically just don't parent the wheel-collider to any moving bits;  the wheel collider does not get moved, but will drive the movement of the suspension/steering/etc transforms.  (you -can- put the wheel collider under an animated transform and let it deploy naturally).

From there, yes, you just need to fill out the config properly.  You do not need to add any wheel-colliders or do any special setup in Unity (aside from the rigging/hierarchy).

Vehicle controller -- does not exist; not sure where you are seeing anything about it?  I had wanted to write a single vehicle-level control GUI.... but getting all of the functions laid out cleanly into the GUI was not working out well (each part may have...infinite...wheels, each wheel can have infinite modules; no guarantee that there is just a single steering or motor module for any given wheel... makes consistent GUI layout...difficult)..

 

[Shadowmage]

Cross-linking/posting this from the KF thread, just so as the news is visible on this thread as well:

 

 

[Shadowmage]

To anyone interested in testing a KSP 1.3 version of KSPWheel/KerbalFoundries, you can find an updated .dll  here:   (  https://github.com/shadowmage45/KSPWheel/blob/dev/GameData/KSPWheel/Plugin/KSPWheel.dll  ). 

You should be able to download that file and replace the existing KSPWheel.dll in your KSPWheel folder, and it should load and work fine after that.  Please make sure to report any problems you run into on the relevant trackers (KSPWheel for physics problems, KerbalFoundries for config problems), and if everything looks good, I will pack this up for an official release later this week/weekend.

There shouldn't really be too much/any changes compared to the current 1.2.2 release versions.  Possibly some very minor changes to the back-end motor EC-use calculation code.... that simply made the existing calculations more accurate for arbitrary inputs, but should not have changed the input/output values that much.

[riocrokite]

hello again, so far I'm stuck on a wheel that bounces violently off the ground

my unity hierarchy:

I've set up wheelCollider at layer 27, then set it up like this (dunno if it's important since those values should be overriden in config:)

\

link to cfg: https://pastebin.com/invCEpbg

paging @V8jester for help

Edited May 31, 2017 by riocrokite

[Shadowmage]

@riocrokite  -- that violent bouncing would be caused by having the wheel collider be a child of the suspension (don't feel bad, everyone wants to rig their wheels that way as it would seem 'natural'.... but it doesn't work at a technical level).

Wheel collider should -not- be a child of the suspension (or grandchild, or great grandchild, etc) (i'm guessing that is wheelpivot?).  It should be parented entirely outside of the suspension hierarchy, as a child of one of the lower level meshes/objects.

E.G.:

-base
 |-piston-L-top
 |-piston-R-top
 |-piston2
 |-wheelCollider (name it whatever you want, as long as it matches in the config)
 |-wheelMount (guessing this is the 'suspension transform'?)
    |-piston-L-bottom
    |-piston-R-bottom
    |-wheelPivot
      |-wheel
        |-tire

Ohh, and remove that stock Unity wheel collider component; it is completely unused by KSPWheel, and you are only wasting your time by setting it up  
Layers setup doesn't matter either (or hasn't so far for my uses); just get the rigging setup properly, and everything else should 'just work'.

 

If you still can't get it figured out, feel free to send me the blend or .fbx file through a PM, and I'll rig it up properly for the KSPWheel setup.

Edited May 31, 2017 by Shadowmage

[SpannerMonkey(smce)]

11 minutes ago, riocrokite said:

hello again, so far I'm stuck on a wheel that bounces violently off the ground

Hi , your wheelcollider seems to be in the wrong place.  only based on the wheels I've made recently though,  in you hierarchy you wheelcollider seems to be a child of the wheelpivot, while I admit this is the intuitive place for it to be . All the wheels i've done have had the collder as a child of the GameObject rather than of a part of the mesh.  

Ive likely just been ninjad by Shadowmage but anyway have a hierarchy pic

Spoiler

 

[riocrokite]

Thank you both for the help, I've got wheels to work:)

Here are a couple of questions:)

- what is groundHeightOffset? tried to set it to different values with no visible effect

I've read about it in code description

- AFAIR spring setting keeps the wheel on the same level no matter how loaded it is?
However upon testing it seems that spring setting takes into account whole vessel weight so I can't entirely balance vessel with CoM moved back like here:

in other words front wheels are quite high even with lowest spring setting. In effect I can barely level vehicle with 2 rear axles set to max spring setting.

Consequent question - would it be possible to have something like ride level slider setting when driving so I could i.e. lower front wheels do dock somewhere? For now I cannot do that unless I dump all resources from the vessel and make it much lighter (consequently moving CoM closer to front wheels)

 

- I have a problem with setting steeringCurve:

MODULE
{
	name = KSPWheelSteering
	steeringName = wheelPivot
	maxSteeringAngle = 20
	steeringAxis = 0, 1, 0
	steeringCurve
	{
		key = 0 1
		key = 5 0.2
		key = 10 0.1
		key = 20 0.01
		key = 40 0.01
		key = 60 0.01
	}

}

It doesn't seem to work

Hmm it seems it works when I normalized key first value (from 0 being 0 and 1 being max speed)

- is there a way to hide some info / settings sliders for an end user (i.e. anti-roll, steering limits, steering response, gear ratio, steering bias, info about kW usage, efficiency and others)? The aim is that I would like to declutter a bit info window for an end user and prevent him to change some of values.

edit:

- do you think it would be possible to change wheel collider size with deploy/retract animation (inflating/deflaitng tyres)

- related to above question - would it be possible in future dev to slightly change wheel collider diameter when driving simulating ground softness (the softer the ground - the higher rolling resistance and smaller wheel collider that would imitate 'sinking' wheel in the ground)

edit2:

- would it be possible to have a simple motor module that just use floatCurve to adjust torque based on speed (much like in KSP 1.0.5 - Unity4) with I think constant settable EC usage? I mean all that realistic EC motor mechanics are great however for stockish KSP it might be viable option too

Edited June 1, 2017 by riocrokite

[Shadowmage]

@riocrokite

Glad you got it figured out    Did it come down to just the model hierarchy needing a bit of adjustment?

 

7 hours ago, riocrokite said:

AFAIR spring setting keeps the wheel on the same level no matter how loaded it is?

No;  it sets the base maximum spring value from the vessel mass.  From there the vessel COM, wheel distribution, number of wheels, and finally the 'spring' slider all determine the actual ride height of each individual wheel.  (What you explain was what I desired the implementation to be originally, however I could not find a reliable method to analytically setup the spring properly for arbitrary vehicle setups; how do you determine which wheels would contact the ground, and at what shares of the load they would be?  What happens when someone puts wheels on the roof, how do you include those in the calculations?  Or wheels as bumpers on the front/rear of the craft?; certainly I could figure it out for standard 4-wheeled vehicle setups, but those are not the only possibility in KSP).

Basically it is setup that if you were to quadruple the mass of the vessel (with relative COM and part placement staying the same), there should be no appreciable difference in ride height.  Half the gravity?  Same ride height.

Move wheels around, add/remove wheels, or adjust COM?  Now you would be changing the ride-height depending on what you moved/added/removed.

In your example craft -- you either need more wheels in the rear, to move the COM forwards, or to use the spring-adjustment sliders to set up a level ride (that is what the sliders are there for... .they ARE the ride-height adjustment). 

I will investigate options to allow for increasing the available range on the spring slider (e.g. to allow 0.1 -> 2.0); the current range was setup a bit earlier in the dev process and was intended to keep things in the 'stable' range, but I think the 'stable' range is now a bit larger than it used to be due to some back-end integration changes... so it might be possible to increase the upper limit on the spring slider.  No guarantees, but I'll look into it for the official 1.3 release/update over the weekend.  At the very least I can add the option to set the min/max through the config, and let any instabilities it cause be the problem of whomever did the configs/setup the parts.

 

7 hours ago, riocrokite said:

is there a way to hide some info / settings sliders for an end user (i.e. anti-roll, steering limits, steering response, gear ratio, steering bias, info about kW usage, efficiency and others)? The aim is that I would like to declutter a bit info window for an end user and prevent him to change some of values.

Currently, no.  Possibly in the future.  Shouldn't be too hard to add per-module config fields to override the GUI display state; just a bunch of clutter that I didn't want to deal with in my code when I was writing things up originally (oh how I wish KSP used a sane GUI system that didn't need all these hacks and workarounds).  Basically each module would end up with a 'showXXX' line in the config to determine if each control should be shown or hidden (invert toggles, limit sliders, etc).

Will work on getting these added in for the official 1.3 release over the weekend.  I have a few uses for these already on the SSTU-SC-E part series, which doesn't need most of the wheel controls exposed.

 

7 hours ago, riocrokite said:

do you think it would be possible to change wheel collider size with deploy/retract animation (inflating/deflaitng tyres)

- related to above question - would it be possible in future dev to slightly change wheel collider diameter when driving simulating ground softness (the softer the ground - the higher rolling resistance and smaller wheel collider that would imitate 'sinking' wheel in the ground)

I have no interest in writing or using such a feature.  Certainly possible, but I'm not going to do the work for it (feel free to write it up and submit a PR though; as long as it is an optional module, I have no problem with it).  From a technical perspective, the wheels will accommodate changes to wheel size (and/or suspension length) at run-time without problem (already used for the wheel scaling feature).

 

7 hours ago, riocrokite said:

- would it be possible to have a simple motor module that just use floatCurve to adjust torque based on speed (much like in KSP 1.0.5 - Unity4) with I think constant settable EC usage? I mean all that realistic EC motor mechanics are great however for stockish KSP it might be viable option too

As with the variable wheel collider, this is not a feature that I desire or would use (so I will not be writing it).  Feel free to write up your own motor module though, absolutely nothing stopping you (hit me up with a PM if you need any pointers on the API or where to start).  I would even be willing to accept a PR on this to include it in KSPWheel itself, there have been a few requests from others for a 'simpler' motor module setup and I wouldn't mind having an alternative available for their use.  With it being a simpler implementation it should probably only be an hour or two worth of work to write it up and do the testing/validation on it.

[Shadowmage]

8 hours ago, riocrokite said:

- is there a way to hide some info / settings sliders for an end user (i.e. anti-roll, steering limits, steering response, gear ratio, steering bias, info about kW usage, efficiency and others)? The aim is that I would like to declutter a bit info window for an end user and prevent him to change some of values.

Have just pushed an update to the 130 branch that includes per-module config toggles to hide the various controls for the module.  Hopefully what each toggle does should be evident from its name, but if not, feel free to poke me with questions.    (  https://github.com/shadowmage45/KSPWheel/tree/130updates  )

To hide a specific field, add the 'showGUIXXX = false' to the relevant module.  Every field that needs hidden will need an entry for each module.

E.g. to hide the 'spring' slider from the part, you would add

MODULE
{
	name = KSPWheelBase
	//rest of the standard config stuff
	//...
	//newly added line to disable spring slider in the GUI
	showGUISpring = false
}

 

 

List of modules, and their showGUIXXX field names:

KSPWheelBase:

+        [KSPField]
+        public bool showGUISpring = true;
+
+        [KSPField]
+        public bool showGUIDamper = true;
+
+        [KSPField]
+        public bool showGUIAntiRoll = true;
+
+        [KSPField]
+        public bool showGUIScale = true;
+
+        [KSPField]
+        public bool showGUIWheelGroup = true;

 

KSPWheelBrakes:

+        [KSPField]
+        public bool showGUIBrakeLimit = true;

KSPWheelMotor:

+        [KSPField]
+        public bool showGUIMotorLimit = true;
+        [KSPField]
+        public bool showGUIMotorInvert = true;
+        [KSPField]
+        public bool showGUIMotorLock = true;
+        [KSPField]
+        public bool showGUISteerLock = true;
+        [KSPField]
+        public bool showGUISteerInvert = true;
+        [KSPField]
+        public bool showGUIGearRatio = true;
+        [KSPField]
+        public bool showGUIHalfTrack = true;
+        [KSPField]
+        public bool showGUIStats = true;

KSPWheelSteering:

+        [KSPField]
+        public bool showGUISteerLock = true;
+        [KSPField]
+        public bool showGUISteerInvert = true;
+        [KSPField]
+        public bool showGUISteerBias = true;
+        [KSPField]
+        public bool showGUISteerResponse = true;
+        [KSPField]
+        public bool showGUISteerLimit = true;

 

KSPWheelRepulsor:

+        [KSPField]
+        public bool showGUIHeight = true;
+