Jump to content

[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

lo-fi

By lo-fi
in KSP1 Mod Development

 Share

What to work on next?  

1,282 members have voted

  1. 1. What to work on next?

    • More wheels
      123
    • More tracks
      453
    • Rover bodies
      241
    • Landing gear
      137
    • Landing legs
      108
    • Something completely different
      193

Recommended Posts

SpannerMonkey(smce)

SpannerMonkey(smce)

Posted
Posted
2 hours ago, Moggiog said:

but this mod features wheels similar to the ones in KF,

Sadly only similar in the way a compact car is similar to a Ferrari ,  they're both cars.  You probably have yet to experience how much better than a stock wheel,  KF wheels are/were,  so you can be forgiven for making such a comparison. KF wheels,  designed by a former motorsport engineer compared to wheels designed by games designers = no comparison

Link to comment
Share on other sites
flywlyx

flywlyx

Posted
Posted
On 11/10/2016 at 0:29 PM, SpannerMonkey(smce) said:

I can say, with the benefit of having tried,  that this is not possible with U5 wheel colliders,  I could make dual  and quad wheel axles right up to and including KSP 1.0.5. and have things like built in landing gear etc  I have likely tried every possible hierarchy since 1.1 and it simply does not and will not work. Even though the modules themselves lead you to believe it should, with an entry for module position in the cfg.   Which is why the heavy landing gear makes me laugh. all those visible wheels are just decoration, there's still only one wheel collider

On 11/9/2016 at 3:05 PM, lo-fi said:

IIRC, there was some disccussion about that a few pages ago, and the answer was simply "NO". I have no direct experience: I gave up messing with stock wheel modules back around .24.

Thanks for letting me know. Times for some dummy wheel play then....

Link to comment
Share on other sites
JebberJones

JebberJones

Posted
Posted (edited)
On 10/11/2016 at 4:54 PM, TARDISES said:

It's not MY meme.

 

All I did was an image search for "Holy mackerel kill icon" anyway. Second result.

>Not your meme

33?cb=20130708042120

Don't dissolution me like that! I thought I had genuinely stolen someone's meme!

Edited by JebberJones
I thought of something else to add.
Link to comment
Share on other sites
0111narwhalz

0111narwhalz

Posted
Posted (edited)

I would like to reiterate: I would be happy to have the repulsors alone. Stock wheels are at least useable now, and tracks are secondary to my interests.

As for you, Wolfair...

On 11/12/2016 at 1:42 AM, lo-fi said:

Not a lot going to happen in the next few weeks as I'm off on holiday fairly shortly. Will pick up upon my return.

Why don't you sample some of your own goods? :P

Edit: Google searches for "self inflicted fish slap" are barren, at best.

Edited by 0111narwhalz
Link to comment
Share on other sites
lo-fi

lo-fi

Posted
  • Author
Posted

Too busy getting stuff ready for holiday to mess with KSP.

Repulsors are in no better state than tracks or indeed wheels: Odd behaviour I've not narrowed down. 

Back in a few weeks. TTFN!

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
Posted

Have managed to get a bit of time to work on wheels again.  Back into working on cleanup and finishing off of the force-based wheel system.  Have at least a week off from work, and will be spending a bit of that time on getting things finished up and working.  Expect to see (semi) regular progress updates as various bits are finished.

 

So far, so-good.  Two of the major problems I had with the implementation seem to be solved, or at least valid solutions are known. 

First, auto-struts can very nicely cleanup the 'jitters' that were caused by critical/overdamped wheels.  Even if the stock auto-strut feature is not used, some form of adding secondary joints will be needed.  This was the 'big' problem that caused us to rethink things and investigate the joint-based suspension; so having this one solved is a fairly large step.

Second, I've figured out some code that nearly eliminates sliding on hills; it brings it down from cm-per-second to sub-milimeter-per-second movement speed.  From there a joint-based constraint can be used to implement the final bit of 'sticky friction'.

That leaves only one 'major' problem left to solve -- bump stop.  We may be able to use a joint-based setup to fix that as well, or if all else fails we can setup some dynamically-created colliders.  There are a few smaller physics/simulation issues that need attention as well such as handling suspension forces at high-incident angles, and perhaps some force-smoothing.  Also could do with a bit of work on the torque/friction integration and slip calculation, to make them work better at the low simulation frequency used by Unity/KSP (it would prefer >1000hz, Unity/KSP uses 50hz).


Next up will be code refactoring to make it more of a drop-in replacement for the old WC's, after that will be a bit of work on seeing how I can integrate the new colliders with existing KF code, and cleaning up the stock-replacement module and configs I was working on.  Hoping to be able to surprise Lo-fi a bit when he returns with things in a much better state than when he left.  Don't get your hopes or hype up yet though; still a lot to figure out before even test versions could be released, so fish-slapping is still in order for anyone asking of an ETA.

Link to comment
Share on other sites
Gaalidas

Gaalidas

Posted
Posted

Sounds like things are looking up for a change.  Just in time too... I was just on a Twitch stream last week telling a guy about my experiences in modding KSP.  There's still a lot of interest in a wheel overhaul for KSP.  I'd welcome the chance to reinvent the dust plumes too.

Unfortunately my schooling got a monkey wrench thrown into it and I was totally turned off on doing anything in C# for several months as a result.  It'd be nice to get back into the game, so to speak, again.

Link to comment
Share on other sites
Mycroft

Mycroft

Posted
Posted (edited)

So @lo-fi how goes the struggle? I've been gone from the forums for a few weeks, so I wondered what I missed. Good news is, once this nightmare is over, you'll be an expert on 1.2 wheels!

oh and @SpannerMonkey(smce), I'm loving your mods!

Edit: yay 500 posts!

Edited by Mycroft
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
Posted
13 minutes ago, Gaalidas said:

Sounds like things are looking up for a change.  Just in time too... I was just on a Twitch stream last week telling a guy about my experiences in modding KSP.  There's still a lot of interest in a wheel overhaul for KSP.  I'd welcome the chance to reinvent the dust plumes too.

Unfortunately my schooling got a monkey wrench thrown into it and I was totally turned off on doing anything in C# for several months as a result.  It'd be nice to get back into the game, so to speak, again.

Indeed, starting to look up a little bit, after a long spell of not-looking-so-hot.

Basic force-based wheel simulation is looking very good so far.  Not perfect yet, but mostly usable at least, and the dynamic responses it gives are very pleasing and realistic (suspension, friction).  See below for more details on where things are at on the WheelColliders.

Will likely be going through the KF codebase here in the next day or two and work on getting it to compile for KSP 1.2 in prep for integration of the new WheelColliders.  If you are going to be around a bit, I would love to have someone familiar with the codebase that I could ask a few questions of (some of the DustFX stuff won't compile for various reasons, and I'm not too familiar with its functions to know if I can fix properly)

 

5 minutes ago, Mycroft said:

So @lo-fi how goes the struggle? I've been gone from the forums for a few weeks, so I wondered what I missed. Good news is, once this nightmare is over, you'll be an expert on 1.2 wheels!

oh and @SpannerMonkey(smce), I'm loving your mods!

Edit: yay 500 posts!

Haven't missed much.  Just recently (yesterday) started making progress again.  But it was good and very substantial progress, so.. there is something at least.

 

 

Today I'm working through the API and functional interface for the WheelCollider itself.  Determining the requirements for how the code-side interaction should be structured while keeping the WheelCollider itself generic and usable outside of KSP (mostly to enable testing in the Unity Editor, as it is -so much faster- to test things there than to relaunch KSP constantly).

 

The current question I'm looking into is:  Should the WheelCollider be a MonoBehaviour or a 'plain-old-object' managed by a separate Component(PartModule)? 

As a MonoBehaviour -- Considering that its update methods need to be called at specific times / in specific ordering, it would seem less-than-useful to make it a Component itself.  Basically you need to be able to setup some values in the WheelCollider on every physics update, values that are only available inside KSP / external to the WheelCollider itself, and these values -must- be set to the current physics state -prior- to the wheel collider updating (local gravity, input states); there is no way in Unity to enforce specific ordering of FixedUpdate calls among an arbitrary set of Components.  I've considered adding some pre- and post- update callbacks to the WheelCollider to allow for the controller class to set those values at the right time, but it seems to be a bit of a cumbersome method, and still allows less control over the wheels update timing.  There is also the problem in KSP regarding Parts not having RigidBodies until after several physics updates have passed; this complicates when the WheelColliders can be added to the GameObjects, and mostly eliminates any advantages to having them be a MonoBehaviour by themselves (as they would need to be constantly added/removed depending upon what scene is displayed, and even in flight scene they cannot be added until after the Part has its RigidBody assigned).  As the KSP PartTools do not support exporting of custom Components/scripts, keeping them as a MonoBehaviour has no benefit there.

Keeping it as a 'plain-old-object' cleans up the updating code substantially, but slightly complicates the initial setup, and requires custom-written VehicleControllers to instantiate the WheelColliders themselves (which honestly they already would have to do with the MonoBehaviour based colliders, due to KSPs delayed adding of RigidBodies).  Under this setup the wheelcolliders would exist solely as a field in the controlling script (e.g. a single reference or array of wheel colliders), and would not be visible as components on their respective game-objects.

The third option is to keep the WheelColliders as a MonoBehaviour, but move them to having a manually/externally called FixedUpdate method.  This mostly keeps with the 'Unity' way of doing things, while still allowing for 'controlled' update sequences (e.g. if the wheel is disabled, merely don't call its update method), but makes the WheelColliders useless by themselves (without the controller script calling the update method, they will do nothing).  Seems like a bit of a hybrid solution that may confuse (code) users in the future.


In the end I guess it comes down to where the references for these WheelColliders will reside, and how the updates should be processed.  Should they be Components that reside on the GameObjects they effect, or should they be generic Objects maintained by the VehicleController/PartModule script?  Should they use standard Unity driven update ordering (with pre/post callbacks), or rely on external classes calling the update methods?

I suppose the proper 'Unity' way of doing things would be to have them be a Component (so they are easily accessible from the model hierarchy).  However these objects have zero legitimate reason for being a Component, and more precisely being a Component is actually detrimental to their proper functioning, and could lead to more confusing code-side interactions.

 

Thoughts, ideas, suggestions, feedback?

It seems that no matter the method chosen, there will need to be a PartModule responsible for managing the WheelColliders, and it will need to handle input and delayed creation/enabling/disabling of the colliders depending on scene and timing.  Really seems like I'll be going with the third option -- Component with manually called update method.  Can't find any way around having the update method be manually called -- and in fact having it manually called allows for much greater control over updates (e.g. in a tank track type setup you can guarantee that all wheels are updated prior to averaging their RPM, or you can guarantee that any specific 'set' of wheels should be updated together).

Link to comment
Share on other sites
riocrokite

riocrokite

Posted
Posted

One more thing, the off-road vehicle collider for unity 5 by NWH coding got released under name 'universal wheel controller':

https://www.assetstore.unity3d.com/en/#!/content/74512

https://forum.unity3d.com/threads/released-wheel-controller-3d-realistic-three-dimensional-alternative-to-wheelcollider.441618/

I guess you guys lo-fi and Shadowmage might be interested in this stuff :wink:

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...