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

[budda]

lol I want 2 please

[0111narwhalz]

This excites me immensely.

[Shadowmage]

@USB4

I think this screenshot should say enough...

Single module that allows for manipulating controls for multiple independent motor modules on a given part, while respecting their individual and relative invert toggles/etc.

Should be available as soon as this weekend, pending a bit of work on some ...other things....

[USB4]

10 minutes ago, Shadowmage said:

@USB4

I think this screenshot should say enough...

Neat

[Shadowmage]

3 minutes ago, USB4 said:

Neat

And here is another goody that you'll probably be able to make use of...

        /// <summary>
        /// If true, will update the wheels internal steering values.  If false, will only update the visible steering mesh (if specified).
        /// </summary>
        [KSPField]
        public bool updateWheelSteering = true;

(part of the regular steering module)

[USB4]

51 minutes ago, Shadowmage said:

And here is another goody that you'll probably be able to make use of...

        /// <summary>
        /// If true, will update the wheels internal steering values.  If false, will only update the visible steering mesh (if specified).
        /// </summary>
        [KSPField]
        public bool updateWheelSteering = true;

(part of the regular steering module)

WIll this be able to pivot wheels on an axle per se? Either way it sounds good.

[Shadowmage]

1 hour ago, USB4 said:

WIll this be able to pivot wheels on an axle per se? Either way it sounds good.

It will do exactly what you accomplished with the 3rd wheel, but without the overhead of simulating that extra wheel.

[Shadowmage]

Updated release is available:

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

Minor enhancements and a few new modules.  See the link for change-logs and downloads.

[USB4]

22 hours ago, Shadowmage said:

Updated release is available:

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

Minor enhancements and a few new modules.  See the link for change-logs and downloads.

So erm, for public class KSPWheelMultiMotorUI : KSPWheelSubmodule How would this look in a typical setup, particularly for public string wheelIndices = "0";

Is KSPWheelMultiMotorUI its own module in the config?

[Shadowmage]

20 hours ago, USB4 said:

So erm, for public class KSPWheelMultiMotorUI : KSPWheelSubmodule How would this look in a typical setup, particularly for public string wheelIndices = "0";

Is KSPWheelMultiMotorUI its own module in the config?

	
	//multi-motor UI module - single UI buttons to control all motor module UI functions
	MODULE
	{
		name = KSPWheelMultiMotorUI
		wheelIndices = 0,1,2,3,4,5
		gearRatio = 1
		
		//optional, can be set to false to disable a field, defaults to true
		showGUIMotorLimit = true
		showGUIMotorInvert = true
		showGUIMotorLock = true
		showGUISteerLock = true
		showGUISteerInvert = true
		showGUIHalfTrack = true
		showGUIGearRatio = true
		showGUIStats = true
	}

 

[Beetlecat]

On 12/27/2017 at 6:09 PM, Shadowmage said:

Hmm... what might this be?

(yes, it moves; it turns; it doesn't yet -walk- while doing either though; and no, you can't have any....)

 

It's baaaaaaack!

[Shadowmage]

Updated release is available:

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

Minor maintenance update -- fixes a issue with 'on motorized wheels' contract objectives.

[ZodiusInfuser]

Hi, I've been away from KSP for a while (a few years) and would like to update my pre-KSP 1.1 wheel parts to 1.3 using KSPWheel. I was wondering if there was a tutorial somewhere on how to set up parts both on the config side and on the model side for KSPWheel? My old wheels no longer work in the game so will need re-rigging, particularly the multi-collider ones.

Also, is there a module that lets me flip the orientation of a wheel rather than have two separate parts? Previously I used a mirror module within Kerbal Foundries, but that doesn't look to be a thing any more.

Also, also, is there a guide for making tracks?

Thanks

[Shadowmage]

1 minute ago, ZodiusInfuser said:

I was wondering if there was a tutorial somewhere on how to set up parts both on the config side and on the model side for KSPWheel?

Modeling side -- the old classic U4 rigging tutorials are all still applicable; so if your wheels worked in KSP 0.90/1.0, they should be compatible at the model level with KSPWheel.  Wheel collider is the only transform with a mandatory orientation, all others can be set through config.  WC must have Y+ = up, Z+ = forward.  Wheel collider should be outside of the suspension mesh hierarchy -- the wheel collider moves the suspension, so you don't want it to be moving itself. 

Config side -- no real tutorials per-se; the KF and stock-conversion patches have lots of examples in them though.  And of course you can always bug me if you get stuck on something.  Tons and tons of config options for setting up for various transform orientations and offsets, so unless your part has very strange rigging, it should be able to be setup using KSPWheel.

3 minutes ago, ZodiusInfuser said:

Also, is there a module that lets me flip the orientation of a wheel rather than have two separate parts?

Yes, but it relies on having two independent .mu models; one for left, one for right. I'm really not a fan of having multiple functional models inside the same .mu, so had to come up with something a bit different.

It is used on a couple of the KF parts (or maybe just one?), so you should be able to use those for samples/examples (the 'simple' track I think..).

4 minutes ago, ZodiusInfuser said:

Also, also, is there a guide for making tracks?

Not that I have... those were all done by @lo-fi and others, and nothing that I've messed with much.  (I did re-rig one of the tracks at one point, so I know a little bit about it, but far from an expert)

Basically what it comes down to is a skinned-mesh-renderer being used for the actual tracks, with a bone setup for each road wheel in the track, with various bone-weights used to link the vertices in the SMR up to the bones for each road wheel.  So each road wheel is responsible for its own section of track, with diminishing influence out towards the next road wheel.  Finally, the texture on the surface of the track is animated through plugin to line up with the apparent drive speed.

[lo-fi]

Track tutorial here:

 

Hope it's going well guys, still looks like there's some excellent stuff going on

[Alex Silvermane]

loving the mod the dust effects give alot more to driving  very good job on it

[Drew Kerman]

I think I've uncovered an issue with kOS not being able to properly set the wheel friction fields. Have a gander at this short video demonstrating the issue:

So the first run I manually tweak down the friction at 25m/s (note the delay between tweaks) and get a smooth takeoff roll and departure. Then I try again but this time I let my kOS script pull down the friction values to 0, however I still get a spinout during the takeoff run. Then the third attempt I keep all friction sliders set to 1 and roll until the aircraft spins out. Now, the reason I think this is a KSPWheel issue is if you look at the 2nd roll again, you'll see the spinout happen around 35m/s with all three wheels on the ground. Now watch the 3rd attempt again and you'll see the spinout happen ~45m/s after the tail wheel comes off the ground. What this indicates to me is the 2nd roll the tail wheel friction was properly disabled by kOS, but the main gear still had friction even though the value was set to 0 and thus without tail wheel friction keeping the vehicle straight, it slid out earlier.

So kOS is having the proper effect on the tail wheel but not the KSPWheel main gears.

And despite this brilliant deduction, literally just now as I'm writing this I realize hey duh, remove the KF patches and try again with all stock wheels. So I did and had no issues taking off using my kOS script.

BTW in regards to my earlier issue on the spinout in general, you can see there's a slight load difference on the wheels, likely caused by the aircraft trying to roll a bit despite no control input so perhaps a very minor imbalance in part placement of some sort. What does the Anti-roll option do? I was hoping that would be more tolerance for when sideways pressure was placed on a wheel but tweaking it around didn't seem to help anything

[Shadowmage]

2 hours ago, Drew Kerman said:

I think I've uncovered an issue with kOS not being able to properly set the wheel friction fields.

Did you read the disclaimer in the settings that states --

"If you play with these settings you are entirely on your own for support"

?

[GameParameters.CustomParameterUI("Enable Friction Control", toolTip = "If enabled, per-part friction controls will be available.\n "+
            "WARNING: Adjustments to friction are un-supported, and may cause instability.  You are on your own for support if you adjust these settings.")]

 

Basically, you can't just set those through KOS.  The fields in the module link into internal code that updates the actual wheels' internal data structures.  Changing the field alone does nothing.

Edit:  Its not even an internal method that handles the code, but an lamda/closure/delegate, so there isn't even a real method signature that I could expose/make public.

            Callback<BaseField, System.Object> frictionAction = delegate (BaseField a, System.Object b)
            {
                float fMult = HighLogic.CurrentGame.Parameters.CustomParams<KSPWheelSettings>().globalFrictionAdjustment;
                this.symmetryUpdate(m =>
                {
                    if (m != this) { m.frictionControl = frictionControl; }
                    int len = m.wheelData.Length;
                    for (int i = 0; i < len; i++)
                    {
                        m.wheelData[i].wheel.surfaceFrictionCoefficient = m.frictionControl * m.frictionMult * fMult;
                    }
                });
            };

 

Edit2 :

You really need to figure out what is causing yaw on that aircraft.  I highly doubt it is the wheels.  If you manually set the friction control to 0 (through the UI) on all wheels, does it still yaw?  (if so, the problem is not the wheels)  (aerodynamics alone should keep it going straight down the runway; there is a reason aircraft have vertical stabs... they work, and work well)

2 hours ago, Drew Kerman said:

What does the Anti-roll option do?

https://en.wikipedia.org/wiki/Anti-roll_bar

With implementation basically borrowed from Edy --

https://forum.unity.com/threads/how-to-make-a-physically-real-stable-car-with-wheelcolliders.50643/

Edited January 26, 2018 by Shadowmage

[Drew Kerman]

1 hour ago, Shadowmage said:

"If you play with these settings you are entirely on your own for support"

Yea I read that and you told me that but I feel completely justified here as I don't see this as a case of mis-using the friction control but as a case of the friction control not working as it should. I believe it is within reason that I would submit an issue if it didn't seem to be working as it should. I totally understand that submitting an issue for something that would be considered an unintended use of the feature would be in line with not getting support, but I disabled the friction and the friction obviously did not get disabled. I'm not going to assume it can't be indicative of a larger issue not just related to friction.

1 hour ago, Shadowmage said:

Its not even an internal method that handles the code, but an lamda/closure/delegate, so there isn't even a real method signature that I could expose/make public

Bummer. This makes me wonder now if all the KSPWheel fields cannot be set via kOS? If so I may have been the first person to try but I doubt I'll be the last. Might want to make it known kOS can't tweak the fields of wheels.

1 hour ago, Shadowmage said:

If you manually set the friction control to 0 (through the UI) on all wheels, does it still yaw?  (if so, the problem is not the wheels) 

If you watch the video, this is precisely what I do for the first takeoff roll (I assume by UI you mean the PAW) and as you can see I have no problems. At this point I'm just like "whatever" and disabling friction is a good enough workaround for me

I've also finally remembered to update the wiki with the answers you've been giving me

Edited January 26, 2018 by Drew Kerman

[Shadowmage]

8 minutes ago, Drew Kerman said:

I totally understand that submitting an issue for something that would be considered an unintended use of the feature would be in line with not getting support, but I disabled the friction and the friction obviously did not get disabled.

You are misunderstanding.  As soon as you check that box to enable friction controls, you are on your own for support (even if something seemingly unrelated to friction... still on your own).

The entire feature is 'unsupported'.  I don't care if it works or not.  I don't need it, don't want it, don't use it, don't test it, and not going to spend time 'fixing' it.  I only added it as someone kept badgering me for it and wouldn't take 'no' for an answer.  If it doesn't work... then whomever that was (don't even remember), can go ahead and take the time to fix it.  I would remove it entirely if it wouldn't result in undue harassment (and honestly I should just remove it and add the problematic user to my ignore list...).

 

You can easily test if the wheel colliders are incorrectly adding friction when set to zero friction by opening up the ksp-wheel debug menu.  Look for the fields fX, fY, fZ -- these are forceX, forceY, and forceZ outputs for the wheel collider, and are the exact values applied to the rigidbody.  fY = spring force, so it should always be >0 when the wheel is on the ground.  fX and fZ are the lateral and longitudinal force outputs respectively, and if you set the friction slider to 0, these should always be 0.

 

 

15 minutes ago, Drew Kerman said:

Bummer. This makes me wonder now if all the KSPWheel fields cannot be set via kOS? If so I may have been the first person to try but I doubt I'll be the last. Might want to make it known kOS can't tweak the fields of wheels.

Yep, pretty much all of the fields for KSPWheel UI stuff work that way.  They all link back to an internal delegate method that does the updating of the wheel-colliders' internal values.  No other way to do it, as the PartModule is only a container for the WheelColliders -- separate classes, with separate fields.

I could possibly provide some public methods to 'force update' the wheel-colliders after the UI/PartModule fields have been updated externally, though I'm not personally fond of adding that many methods just for kOS to use (and as I don't use kOS, it would be very low priority unless someone else write up a PR for it).

 

11 minutes ago, Drew Kerman said:

If you watch the video, this is precisely what I do for the first takeoff roll (I assume by UI you mean the PAW) and as you can see I have no problems. At this point I'm just like "whatever" and disabling friction is a good enough workaround for me

Once again, can you present me an otherwise stock craft file that exhibits the problem?  Does the problem manifest when using the converted gear on any of the stock craft files?  Do you have the same problem when using the ALG parts?  I cannot fix that which I cannot reproduce.  And so far I have been unable to reproduce your problem using stock + KF parts (e.g. see the pics I posted last week/whenever it was; craft took off perfectly straight).

I'm more than willing to look into and fix the problem, but first I have to be able to confirm that the problem exists, and that it actually exists in my code (or configs).  I can only do that if provided with a stock/KF craft file that exhibits the problem in an otherwise mod-free environment (e.g. only KF + dependencies installed).

[Drew Kerman]

1 hour ago, Shadowmage said:

Yep, pretty much all of the fields for KSPWheel UI stuff work that way

Ok so this is the real issue here. Anything I would have tried to tweak with kOS would not have worked, it's a bit unfortunate that I happened to discover this while using the unsupported friction control. I probably should have done more testing with some of the other fields and just came here to report that I couldn't control any KSPWheel fields with kOS. Don't worry about the wheel spinout problem, I just had that for use as my example since that's how I initially determined the field settings weren't being applied. I did not mean to re-open that issue in any way, it's "fixed" as far as I am concerned. If adding the ability for kOS to tweak the settings is not worthwhile then I'm fine with that, it's no big deal for me to switch over to stock where needed

1 hour ago, Shadowmage said:

You can easily test if the wheel colliders are incorrectly adding friction when set to zero friction by opening up the ksp-wheel debug menu.  Look for the fields fX, fY, fZ -- these are forceX, forceY, and forceZ outputs for the wheel collider, and are the exact values applied to the rigidbody.  fY = spring force, so it should always be >0 when the wheel is on the ground.  fX and fZ are the lateral and longitudinal force outputs respectively, and if you set the friction slider to 0, these should always be 0.

I'll keep that in mind for future reference but - how do I access the debug menu? I just looked through the wiki, ReadMe and played around a bit ingame. I may have thought to check it for insight if I knew it existed

[Shadowmage]

35 minutes ago, Drew Kerman said:

I'll keep that in mind for future reference but - how do I access the debug menu?

Go into the KSPWheel difficulty settings (stock difficulty menu -> advanced -> mod difficulty settings -> KSPWheel tab), and check the 'enable debug mode' button.  From there, it should add a new button to the stock app-launcher.  When in flight scene and the debug-button is pressed, it should open up a nice big clutter-filled window that details the stats for all of the wheel colliders on the current vessel. 

 

37 minutes ago, Drew Kerman said:

If adding the ability for kOS to tweak the settings is not worthwhile then I'm fine with that, it's no big deal for me to switch over to stock where needed

Its not that it would be hard to add in the ability; its that it would be a fair amount of work that is of no real use outside of kOS.  Would require moving all of the delegate methods over to be a referenced type and field in the class, and/or creating actual non-delegate methods for those updating functions.  

Hmm... actually.... looking at it a bit more, it looks like the friction control is the only one using an anonymous method; the others already have specific methods in place, but a few would need to be made public (currently private).  So wouldn't actually be that much work, and probably wouldn't be too disruptive either (e.g. very little/zero chance to break things).  Could certainly look into making that change for future versions.

Erm... can kOS call actual methods/functions, or is it limited to manipulating field values directly?  (I have zero experience with kOS, I only know that it uses an in-game scripting system to interface with the actual game code, but no references as to how it does said interaction or what capabilities it has)

Methods to call for updates in KSPWheelBase:

Spring/damper:   public void onLoadUpdated(BaseField field, object obj)  (this one should already be usable as long as you can call methods; can safely input null for both parameters)
Scale:  private void onScaleAdjusted(BaseField field, System.Object obj)  (this one would need to be made public)
Friction:  anonymous delegate, cannot be called directly (this one would need to be converted to a standard method)
Anti-Roll: field used directly, no method call needed  (no change needed)
Rolling-Resistance: cannot update dynamically, can only adjust through patches (no runtime manipulation possible; would need method constructed for runtime updating of wheel-colliders internal values)

 

Looks like most of the other modules use the field values directly (steering, motor, brakes).  So for those modules adjusting the fields directly should work fine (I haven't checked every field for every module, so might not apply to all of them).

 

3 hours ago, Drew Kerman said:

I've also finally remembered to update the wiki with the answers you've been giving me

Thanks

Wish I had time to sit down and write up documentation for stuff the way I would like to.  Sadly my choices are 'write documentation' or 'do more development work'.  Man, I need to find myself some interns (the unpaid kind...).

[Drew Kerman]

6 hours ago, Shadowmage said:

Hmm... actually.... looking at it a bit more, it looks like the friction control is the only one using an anonymous method; the others already have specific methods in place, but a few would need to be made public (currently private).  So wouldn't actually be that much work, and probably wouldn't be too disruptive either (e.g. very little/zero chance to break things).  Could certainly look into making that change for future versions.

Lol, I had a feeling I would come back and see something like this, cause you're awesome. But still, put it on the list of things to do when you run short of things to do. It's a thing I would like to have but not a thing I need to have.

6 hours ago, Shadowmage said:

Erm... can kOS call actual methods/functions, or is it limited to manipulating field values directly?  (I have zero experience with kOS, I only know that it uses an in-game scripting system to interface with the actual game code, but no references as to how it does said interaction or what capabilities it has)

Let's ask @Steven Mading

6 hours ago, Shadowmage said:

Sadly my choices are 'write documentation' or 'do more development work'. 

Ahhh, the age-old dilemma. I think it gets to a point where there are enough features and you start answering the same things enough times that it makes sense to put a little time into docs to save you dev time in the long run

Edited January 27, 2018 by Drew Kerman

[Dunbaratu]

7 hours ago, Drew Kerman said:

Let's ask @Steven Mading

Without additional work of adding an Addon to the KOS source in github, the only thing kOS supports by default for all other parts and mods is that it exposes PartModules' KSPFields, KSPEvents, and KSPActions to scripts, provided those KSPEvents and KSPActions would be currently visible if you opened up the rightclick context menu on the part.  (The design principle is that kOS should not allow a user to do anything they couldn't have done manually through the UI.  Anything they can manually do in the UI is fair game, but anything not exposed to the UI might have been left hidden from the user's control for a reason.  We can't read the minds of other mod developers and don't want to tick them off by exposing them to user "bug" reports that are caused by letting users break their mods with bogus variable values that would have been impossible to exist through normal gameplay.  To that effect we even obey the "slider detent" roundoffs in their floating point slider controls (attempts to set a float slider to a value in between two valid UI values will round off to the nearest value the UI would have allowed.))

If that's not sufficient, we do accept pull requests from other mod writers contributing to our ADDONS source folder with modules designed to interface kOS with their mods to allow more than what the UI allows.

[Shadowmage]

On 1/27/2018 at 3:28 AM, Steven Mading said:

the only thing kOS supports by default for all other parts and mods is that it exposes PartModules' KSPFields, KSPEvents, and KSPActions to scripts, provided those KSPEvents and KSPActions would be currently visible if you opened up the rightclick context menu on the part.

Does kOS properly call (or otherwise trigger) the 'on field changed' callback when KSPFields are updated?

E.G:  https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelBase.cs#L397

This is apparently the bit that might be causing problems.  Basically the stuff works fine when using the actual GUI controls.  But there may be problems when those same fields are updated by kOS.  (I cannot confirm any of this as I do not use kOS, and am basing this entirely on one user report that stated the functions were not updating properly)