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

[Shadowmage]

On 11/27/2019 at 4:41 PM, ss8913 said:

The beta/pre-release 1.8.1 DLL for kspwheel fixes the issues 100% and works with the existing version of kerbal foundries2 that's on CKAN... nice job

Now I just need to find the time to package it up properly and do a real release

Now that the holidays are over, and my previous project at work has been finished up (finally!), I'm hoping that the next few weeks will be a bit quieter and will allow me to catch up on some of my non-work-related tasks.  If things play out like they are currently planned, I should have 3-4 months of lower priority projects and training for an upcoming position transition, which should mean plenty of headspace for some modding for a bit.  Still a few unknowns, and always potential for the plans to be changed, but so far the future is looking much better for modding updates.

 

Going to try and make some time during this week to pack up the updated KSPWheel, and after that a TU and an official Kerbal Foundries (PBR) update.  KSPWheel should be available before end of week, with TU and KF following not far behind.

[Shadowmage]

Updated release is available:

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

Just an official recompile and repackage for KSP 1.8.  Should be no functional changes compared to prior versions aside from compatibility with the latest KSP versions.

I'll be working on updating TU next, and Kerbal Foundries shortly after; hopefully both before the end of the weekend (barring anything nasty needing to be fixed).  Please note that this version of KSPWheel should be compatible/usable with the existing KerbalFoundries releases (and SSTU / anything else that uses KSPWheel).

Edited December 5, 2019 by Shadowmage

[Problemless Mods Wanter]

10 hours ago, Shadowmage said:

Updated release is available:

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

Just an official recompile and repackage for KSP 1.8.  Should be no functional changes compared to prior versions aside from compatibility with the latest KSP versions.

I'll be working on updating TU next, and Kerbal Foundries shortly after; hopefully both before the end of the weekend (barring anything nasty needing to be fixed).  Please note that this version of KSPWheel should be compatible/usable with the existing KerbalFoundries releases (and SSTU / anything else that uses KSPWheel).

The game was finally working and loading fine with this dev version of the DLL;

But as soon as I updated the KSP Wheel to 0.16.14.33 the game started having loading issues again. Module manager is warning KSP Wheel is the problem.

To be fair; I am using Module Manager version 4.1.2 because I also had issues with the newest version 4.1.3

I copied the dev version of the DLL into the updated folder and the game is loading fine again.

This could be an issue specific to my setup or a problem with CKAN, but I wanted to report it just in case.

[ss8913]

2 hours ago, Problemless Mods Wanter said:

The game was finally working and loading fine with this dev version of the DLL;

But as soon as I updated the KSP Wheel to 0.16.14.33 the game started having loading issues again. Module manager is warning KSP Wheel is the problem.

To be fair; I am using Module Manager version 4.1.2 because I also had issues with the newest version 4.1.3

I copied the dev version of the DLL into the updated folder and the game is loading fine again.

This could be an issue specific to my setup or a problem with CKAN, but I wanted to report it just in case.

it's not just you, had the same thing happen to me.

[Stone Blue]

Manual install of 0.16.14.33 and KF v2.3.7.17 in a *very* lightly modded install, with MM v4.1.3 loads flawlessly for me...
....(other than 5 missing texture errors from KF, and warnings that KF and TU werent built for 1.8.1... lol )

Also took out two of the stock rover craft for a spin around the end of runway area.... No exceptions thrown, or anything... not a peep from KSPWheel... (I didnt try anything with KF gear, tho...)

@Problemless Mods Wanter @ss8913 , i guess post up your logs, or wait and see if moar reports of similar behaviour roll in? vOv

Edited December 6, 2019 by Stone Blue

[Shadowmage]

6 hours ago, Problemless Mods Wanter said:

This could be an issue specific to my setup or a problem with CKAN, but I wanted to report it just in case.

 

1 hour ago, Stone Blue said:

Manual install of 0.16.14.33 and KF v2.3.7.17 in a *very* lightly modded install, with MM v4.1.3 loads flawlessly for me...

 

Hmm... indeed sounds like there might be a CKAN related issue at play here.  I'll do some additional testing and see if I can root out the problem, but some log files and additional info from those having the problem would likely be helpful.

[Shadowmage]

After looking into the package, it appears that I somehow packaged up a previous DLL version (issue with my project management and build script; been away for too long and forgotten too much about my tools and setup).

I have re-uploaded the 0.16.14.33 release with a correct package, and verified that it has the correct modified date on the binary.

For those experiencing problems, could you verify if the new package fixes the issues?   ( https://github.com/shadowmage45/KSPWheel/releases/download/0.16.14.33/KSPWheel-0.16.14.33.zip )

Edit:  This may or may not work for CKAN related issues.  I have no idea where it gets its downloads from.  If a problem still exists with CKAN, it may require an increment in version number and package/publish of a new release/tag.

Edited December 6, 2019 by Shadowmage

[blowfish]

2 hours ago, Shadowmage said:

Edit:  This may or may not work for CKAN related issues.  I have no idea where it gets its downloads from.  If a problem still exists with CKAN, it may require an increment in version number and package/publish of a new release/tag.

I think someone would have to manually trigger it to reindex.  I believe one of the CKAN staff can do that for you.

[ss8913]

so..  cannot 100% confirm it's this mod doing it, but since installing the latest update i've had a new problem I've never had before... i'm *in orbit*... try to accelerate time, "cannot warp faster than 1x while moving over the ground" - like it still thinks i'm on the ground somehow.  Anyone else having this issue?

EDIT: logs have nothing useful to say.  nothing at all to say, really.

Edited December 10, 2019 by ss8913

[Manul]

16 hours ago, ss8913 said:

so..  cannot 100% confirm it's this mod doing it, but since installing the latest update i've had a new problem I've never had before... i'm *in orbit*... try to accelerate time, "cannot warp faster than 1x while moving over the ground" - like it still thinks i'm on the ground somehow.  Anyone else having this issue?

EDIT: logs have nothing useful to say.  nothing at all to say, really.

I encountered this problem with adjustable landing gear in 1.7.3 or earlier. Sometimes the game thinks that an aircraft did not takeoff, the camera shakes like crazy in flight, orbital information is not displayed and vessel status is "landed". It didn't happen often, maybe once per 100 takeoffs or something like this, didn't meet this in 1.8 but I didn't fly so much in 1.8 yet.

[Shadowmage]

16 hours ago, ss8913 said:

so..  cannot 100% confirm it's this mod doing it, but since installing the latest update i've had a new problem I've never had before... i'm *in orbit*... try to accelerate time, "cannot warp faster than 1x while moving over the ground" - like it still thinks i'm on the ground somehow.  Anyone else having this issue?

EDIT: logs have nothing useful to say.  nothing at all to say, really.

 

6 minutes ago, Manul said:

I encountered this problem with adjustable landing gear in 1.7.3 or earlier. Sometimes the game thinks that an aircraft did not takeoff, the camera shakes like crazy in flight, orbital information is not displayed and vessel status is "landed". It didn't happen often, maybe once per 100 takeoffs or something like this, didn't meet this in 1.8 but I didn't fly so much in 1.8 yet.

Thanks for the reports; first time I've seen mention of such an issue, but certainly seems like there is something going on.

What would be most helpful in tracking this down is having some method that reliably replicates the issue every time; e.g. a set of procedures that result in the issue, that can be documented and followed to reproduce during testing and debugging.  Is this a problem that happens on all craft with wheels?  Does it only happen if an in-orbit vessel is reloaded?  Does it only happen if the vessel was launched from the ground without saving/loading?  Is it only specific wheels?  Only specific craft designs?

[Manul]

5 minutes ago, Shadowmage said:

Is it only specific wheels?  Only specific craft designs?

I met this problem with two crafts: a light jet plane with small ALG and a 100tonn SSTO with large ALG. Both of them are based on my Laythe base and performed many many flights during Laythe exploration (plane) and Jool system exploration (SSTO). The "fake takeoff" happened to each of them in a random period of their life on Laythe. Another time it happened with a modification of the same SSTO during takeoff from the KSC runway, I don't remember if it was newly launched or parked at the KSC. I don't think there is a reliable way to replicate this because it happens so rarely. Both crafts performed hundreds of flights during their long career and it happened only two times with both of them. Every time this happened I noticed a small lag when main gear lost contact with the ground.  Maybe it's a potato computer performance problem because I have problems with stock rover wheels too: sometimes they clip into terrain and everything explodes if  a 100+ parts rover is moving too fast over rough terrain. Possibly some collision data gets lost between physical frames when the game begins to lag.

[Acvila]

20 hours ago, Manul said:

I met this problem with two crafts: a light jet plane with small ALG and a 100tonn SSTO with large ALG. Both of them are based on my Laythe base and performed many many flights during Laythe exploration (plane) and Jool system exploration (SSTO). The "fake takeoff" happened to each of them in a random period of their life on Laythe. Another time it happened with a modification of the same SSTO during takeoff from the KSC runway, I don't remember if it was newly launched or parked at the KSC. I don't think there is a reliable way to replicate this because it happens so rarely. Both crafts performed hundreds of flights during their long career and it happened only two times with both of them. Every time this happened I noticed a small lag when main gear lost contact with the ground.  Maybe it's a potato computer performance problem because I have problems with stock rover wheels too: sometimes they clip into terrain and everything explodes if  a 100+ parts rover is moving too fast over rough terrain. Possibly some collision data gets lost between physical frames when the game begins to lag.

i had this problem when wheels were in contact with other parts of the ship, in flight saying that i'm, landed, when i was trying to cary a rover.

[Shadowmage]

21 hours ago, Manul said:

Every time this happened I noticed a small lag when main gear lost contact with the ground.

Good info there -- and might be related with some other reports of performance issues with 'flying' craft.  Might well be that I missed something in my ground-contact check and how it interacts with the stock code (which is itself a horrendous mess to try and figure out).

I'll see if I can repro the problem with a vessel with wheels in contact with other parts; sounds like that is at least part of the problem (or one of the problems; might be multiple separate issues at play here all manifesting with the same symptoms).

[Krakatoa]

The screen continues to shake like I'm driving along the ground in the couple times where it's happened to me, and I get those same errors.

[Dundrogen]

Hey @Shadowmage,

Sorry to bother you cause i know you're super busy. Just wanted some tips on an issue

I have an idea to create a special type of wheel but it would only work if the kspwheelrotation module can start at different angles. 

for example :   

MODULE
{
    name = KSPWheelRotation
    wheelMeshName = WheelRim
    rotationAxis = 1, 0, 0
    randomStartPosition = true      //just an idea
}

To rotate the wheelMeshName  passed variable by a random degree between 0 - 360 before loading. Could you give me some tips on how i would code this in? is this done in unity or would i have to tweak the actual KSPwheel plugin? 

Thank you!

[Manul]

15 hours ago, Shadowmage said:

Good info there -- and might be related with some other reports of performance issues with 'flying' craft.

I have a guess that overstress and failure time in conjunction with large partcount are involved in this. Sometimes the same sort of lag occurs during hard landings that overstress landing gear. And both of my aircrafts that used to think they're landed after takeoff have 2 common design features: main gear far from CG and a huge pitch authority provided by canards and large elevons. It creates a large load on main gear if I pull up too hard during takeoff.
This guess also explains why it happens on Laythe more often: due to low ASL pressure and a lack of smooth runway takeoff is always extremely bumpy.
But it does not explain why a 150+ parts buggy with a trailer does not experience this sort of lag while jumping over hard terrain at 60m/s constantly braking its wheels. So it may be a wrong guess.

[Shadowmage]

13 hours ago, Dundrogen said:

To rotate the wheelMeshName  passed variable by a random degree between 0 - 360 before loading. Could you give me some tips on how i would code this in? is this done in unity or would i have to tweak the actual KSPwheel plugin?

Do it from in Unity.  Rotate your wheels in your prefab prior to export with PartTools.  That will then be used as the starting state for any KSPWheelRotation module; the part will -always- load in the state described by the prefab, and then the wheels will be further rotated based on the player input/movement of the vessel.  KSPWheel does not store the rotation value persistently, and if/when the craft is reloaded will start in the default state from the prefab.

 

2 hours ago, Manul said:

But it does not explain why a 150+ parts buggy with a trailer does not experience this sort of lag while jumping over hard terrain at 60m/s constantly braking its wheels. So it may be a wrong guess.

Any information is good information on this issue.  I too have ran into one or two random occurrences in my playtesting, truly random and unrepeatable (never did it on a reload).

My likely suspect is this ~100 line block of code that handles the updates to ground-contact for the part ( https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelBase.cs#L975-L1056 ).  Yes, it is as much of a mess as it looks, and took far too long to work through the logic needed due to zero documentation on the stock API on this matter.  Now, what precisely in that code needs to be changed is unknown, but still the primary suspect for anything 'landed state' related.

Edited December 12, 2019 by Shadowmage

[Dundrogen]

@Shadowmage you did say my imagination was the limit to wheel rigs lol

just to give you some context of why i was asking to alternate wheel rotation positions earlier. quite self explanatory from the rig. i realised during testing that steering changes the esthetic rpm so just turning the wheel changed its' rotational position to make the rig more believable. God damn i love KSPwheel.

 

[Shadowmage]

1 hour ago, Dundrogen said:

@Shadowmage you did say my imagination was the limit to wheel rigs lol

just to give you some context of why i was asking to alternate wheel rotation positions earlier. quite self explanatory from the rig. i realised during testing that steering changes the esthetic rpm so just turning the wheel changed its' rotational position to make the rig more believable. God damn i love KSPwheel.

 

LoL, love watching the legs scrabble a bit as it looses traction.  Good times

Indeed -- this is what I wrote the plugin for; all the fun stuff that would be hard/impossible with the stock system.

Edit: After re-watching a few times, it just gets more awesome each time.  Truly, some out of the box thinking and rigging there -- nice work

Edited December 13, 2019 by Shadowmage

[Dundrogen]

6 hours ago, Shadowmage said:

Edit: After re-watching a few times, it just gets more awesome each time.  Truly, some out of the box thinking and rigging there -- nice work

Thank you.

Coming from you, that means alot to me. I've since tweaked the rig so the tips of the foot track with the bottom position of the wheel collider almost perfectly. Difficult to see the floating and clipping in the initial video since i kept moving the 'legs'. 

I'm currently studying and old @lo-fivideo where he demonstrated how to get the tread skin to deform around the inner tread wheels. This is going to blow my rig ideas out of orbit 

The legs in the video are fairly simple. Attach objects to the kspwheelrotate variable at a distance and that will be the radius, have your leg segments track these objects in a single axis. I'll post a video here of the rig in blender going through it's iterations incase someone in the KSPwheel community wants to expand and improve on the idea. 

[ss8913]

On 12/10/2019 at 12:37 PM, Shadowmage said:

 

Thanks for the reports; first time I've seen mention of such an issue, but certainly seems like there is something going on.

What would be most helpful in tracking this down is having some method that reliably replicates the issue every time; e.g. a set of procedures that result in the issue, that can be documented and followed to reproduce during testing and debugging.  Is this a problem that happens on all craft with wheels?  Does it only happen if an in-orbit vessel is reloaded?  Does it only happen if the vessel was launched from the ground without saving/loading?  Is it only specific wheels?  Only specific craft designs?

I'll do some tests using the plane that definitely did it last time, and see how reproducible it is.

[lo-fi]

On 12/13/2019 at 1:33 PM, Dundrogen said:

@Shadowmage you did say my imagination was the limit to wheel rigs lol

just to give you some context of why i was asking to alternate wheel rotation positions earlier. quite self explanatory from the rig. i realised during testing that steering changes the esthetic rpm so just turning the wheel changed its' rotational position to make the rig more believable. God damn i love KSPwheel.

 

Damn that's cool! 

Glad my old ramblings are still helping people out :) 

[Stone Blue]

@Dundrogen Wow... other than the legs unrealistically *not* colliding with each other, that is prett darn *KEWL* ... Nice job!
 

13 minutes ago, lo-fi said:

Glad my old ramblings are still helping people out

Hey!... nice to hear from you again, lo-fi. Hope youre doing well. And as always, THANK YOU for such awesome contributions to the community, that still make *thousands* of people's KSP experience sooooo much better.

Edited January 23, 2020 by Stone Blue

[lo-fi]

Awww shucks! It was worth losing a year to KSP modding, I still get a kick out of seeing stuff I had a hand in creating getting used and enjoyed. 

Big thanks to @Shadowmage as ever for picking up the torch.

Doing great thanks, working with wheels in the real world leading a team overhauling a steam locomotive. Keeps me just as busy!