[1.8.x] Kerbal Foundries -- Continued - Tracks, Wheels, and Gear

[Shadowmage]

2 hours ago, V8jester said:

@Shadowmage I may have not explained that very well. The current steering limit slider. Limits the angle of the steering. But when using a keyboard (which is all I have) The wheels will instantly go to max angles when turning. Makes for flippy-floppy issues at any kind of a reasonable speed. The old KF implemented a system of gradually limiting the speed of the steering as well as the available angle of steer the faster you went. Meaning as you speed up, your turning ability is very diminished. But you wouldn't flip your rovers. I would say this is my single "complaint" of the new system is an absence of a steering limiting system such as this. 

Hmm.. that makes a bit more sense.  No there is not currently any built in 'steering response'.  Personally though, I use the stock 'fine-controls' mode for that purpose (caps-lock); I didn't see a need for custom functionality when it is included in stock code (and easily toggle-able).  As a bonus, the stock 'fine-control' mode also works for motor inputs.  When enabled you should see the wheels slowly turn between the commanded inputs.

I'm willing to consider putting one (back) in, but I would need a good reason/examples why the stock fine-control mode is not sufficient for the purpose.  I also enjoy the ability to toggle it on and off with ease, so even if I did a custom implementation it would likely still be linked to (and work in addition to) the stock fine-control mode.

Edit:  Maybe the 'fine-control' mode only works for me because I have rover controls mapped to the same as rocket controls?

 

2 hours ago, 0111narwhalz said:

I think there is a steering-curve thing. Look at the patch notes of KSPWheel's latest version:

I take this to mean that there is a steering curve based on velocity.

Yep, there already is a velocity-based steering curve -- it limits maximum deflection based on the current forward/backward velocity of the wheel. 

The change noted in the patch notes was a 'fix' as previously the 'velocity' was based on how fast the wheel was spinning, and not how fast it was actually moving; as a result it would incorrectly limit steering authority even when the craft was standing still but the wheels were slipping (from too much torque), and would also incorrectly -not- limit the steering when the craft was moving but the wheels were locked (from brakes or reverse motor).

Edited February 7, 2017 by Shadowmage

[Space Kadet]

Spoiler

Spoiler

Video

 

I love these tracks!

 

horrifying post created by ipad

<iframe title="YouTube video player" class="youtube-player" type="text/html" 
width="640" height="390" src="http://www.youtube.com/embed/E5qFpIR8hJM"
frameborder="0" allowFullScreen></iframe>

Edited February 7, 2017 by Space Kadet

[Haifi]

Now a video with fine tuned tracks and autostruts  Yay, working tracks!

Spoiler

 

 Just one question, the "driving over gravel" sound is very dominant, is that on purpose? Could you tone that sound down a bit and have the engine hum a bit louder? Or is it either this or that?

[Shadowmage]

1 minute ago, Haifi said:

Now a video with fine tuned tracks and autostruts  Yay, working tracks!

 Just one question, the "driving over gravel" sound is very dominant, is that on purpose? Could you tone that sound down a bit and have the engine hum a bit louder? Or is it either this or that?

Glad that got things working for you

 

Sounds are actually the combined output of two sounds curves.

1.) The motor sound -- linear with motor torque output, which decreases at higher RPM.  So the motor sound is mostly silent when driving at higher speeds.  (might consider having it decline to ~25% rather than 0%, but it will still be based on torque output)
2.) The running sound -- linear with velocity, which increases at higher RPM.  So the running sound is dominant when driving at higher speeds.  This is the 'driving over gravel' sound (on wheels it is a different hum sound; tracks use the more track-like sound).

As was noted in the release notes, the current values for 'volume' for each will be further fine-tuned in the future for the base size of the part, combined with the current scale; so 'larger' wheels/tracks will be louder.

But to answer your question -- yes it is on purpose (and somewhat realistic I think...).  You can however change the sound-effect used for the 'running' sound into the same one used by the wheels through a simple patch if you are so inclined, or otherwise alter the volume and pitch values in the EFFECTS nodes to suit your tastes.

[V8jester]

5 hours ago, Shadowmage said:

Hmm.. that makes a bit more sense.  No there is not currently any built in 'steering response'.  Personally though, I use the stock 'fine-controls' mode for that purpose (caps-lock); I didn't see a need for custom functionality when it is included in stock code (and easily toggle-able).  As a bonus, the stock 'fine-control' mode also works for motor inputs.  When enabled you should see the wheels slowly turn between the commanded inputs.

I'm willing to consider putting one (back) in, but I would need a good reason/examples why the stock fine-control mode is not sufficient for the purpose.  I also enjoy the ability to toggle it on and off with ease, so even if I did a custom implementation it would likely still be linked to (and work in addition to) the stock fine-control mode.

Edit:  Maybe the 'fine-control' mode only works for me because I have rover controls mapped to the same as rocket controls?

....

Ohhhh! That never even occurred to me to try turning fine control on.... I will try that right now. Thanks!

[Haifi]

Ok, it just does not sound too much like a tracked vehicle to me. Found a "decent" free track sound here:

Spoiler

 

And made a .ogg sample of it. 

For which I could pm you a dropbox link if you're interested.

[V8jester]

With the new version of KSPwheel everything works great now. I have indestructible wheels turned off and so far so goo. Only really harsh maneuvers with that test crane I mentioned earlier will break the wheels now. Much better damage / control in that latest update. Something I noted on the Small rover wheels again.. I built a semi style truck and when the trailer is detached from scale 2 wheels. The collider is much larger / above the wheels so the trailer will not re engage after it is dropped.

[Shadowmage]

13 hours ago, V8jester said:

With the new version of KSPwheel everything works great now. I have indestructible wheels turned off and so far so goo. Only really harsh maneuvers with that test crane I mentioned earlier will break the wheels now. Much better damage / control in that latest update. Something I noted on the Small rover wheels again.. I built a semi style truck and when the trailer is detached from scale 2 wheels. The collider is much larger / above the wheels so the trailer will not re engage after it is dropped.

Is this a stock craft that I could examine? (or at least get pics of if not stock?, preferably with DebugStuff showing the colliders)

The only colliders that should be present like that are the 'bump-stop-colliders'.  If your trailer is hitting those... then it would have been interfering with the wheel suspension travel anyway.  There is a chance that they are not positioned/scaled properly, which is why I would like to at least see the craft.

 

15 hours ago, Haifi said:

Ok, it just does not sound too much like a tracked vehicle to me. Found a "decent" free track sound here:

  Reveal hidden contents

 

And made a .ogg sample of it. 

For which I could pm you a dropbox link if you're interested.

Sorry, that is the best sound I have available in KF....

Thanks for taking a look for other sounds though.  Sadly, the site you linked to does not actually offer truly free sounds.  Well, they are 'free to download' but have some licensing requirements.  Any sounds I use need to be explicitly in the public domain.

 

[V8jester]

24 minutes ago, Shadowmage said:

Is this a stock craft that I could examine? (or at least get pics of if not stock?, preferably with DebugStuff showing the colliders)

The only colliders that should be present like that are the 'bump-stop-colliders'.  If your trailer is hitting those... then it would have been interfering with the wheel suspension travel anyway.  There is a chance that they are not positioned/scaled properly, which is why I would like to at least see the craft.

....

The craft is mostly LLL IR and KF. But I will see if I can toss up a couple pictures when I get back home.

Back on that horse again.. The indestructible wheels have proven to be handy for things like forklifts that are very weighty over the rear. I assume all I would need to do to make that a permanent adjustment is just make an MM patch to adjust the (damage) can't recall the exact line right now. On each of the wheels to raise there weight capacity to ludicrous levels right?

I did try that Docking mode for the wheels. That helps, but it doesn't change the speed at wich the steering centers itself. And it is still pretty fast. My crane generates a ton of grip having 16 wheels under it. And it will flip at anything over 7m/s unless I spam a directional arrow to make the turn a little softer. So I am limited to either good turning radius at low speeds or wide turning radious at high speeds. also I built an off road style forklift that has one heck of a time making a controlable turn. I may make a video of these two crafts so you can see some of what I mean. As a whole, I am still very impressed with the new system you are using. It handles weight far better, it powerslides great (on certain crafts) the suspension moves more presictibly. It really is great just how much you've added to the "reinvention of the wheel" ..... Again

[Haifi]

Then ill keep my eyes and ears open. Sadly I'm not in the military anymore, was a driver on a Leopard II. Would have been easy to record some true track sounds back then, but never thought of needing some. 

[Svm420]

7 minutes ago, V8jester said:

I did try that Docking mode for the wheels. 

 

Not sure if you mistyped, but Shadow didn't mean docking mode, he means fine controls AKA Caps lock(not on Mac). Not docking mode. So Wanted to clarify if you mistyped or misunderstood. I have tried fine controls myself and confirm what shadow said.

[V8jester]

1 hour ago, Svm420 said:

Not sure if you mistyped, but Shadow didn't mean docking mode, he means fine controls AKA Caps lock(not on Mac). Not docking mode. So Wanted to clarify if you mistyped or misunderstood. I have tried fine controls myself and confirm what shadow said.

Sorry that's what I meant. I hit caps and controls turned blue / slowed down.

[V8jester]

Actually... Hey @Shadowmage this is the crane I have been talking about. This video is the old KF on 1.0.5. I have everything converted and working in 1.2.2. If you see something you want a closer look at specifically, let me know so I can get it into the next video.

So things to note in this video. Very heavy so it accelerates very slowly. Wheel steering speed and steering re centering is much slower than new KF. Also all the suspension is maxed out. Another thing to watch is when I drop the trailer from the boom, the suspension will not droop / change. And the docking ports are within range to re dock. You will see some changes in the next video. Hopefully this get's the gears turning. New KF will allow this crane to accelerate / decelerate much more effortlessly.

 

[V8jester]

You know.... I do believe I will need to eat a big hot plate of crow on this one.....

@Shadowmage In preparation to make the aforementioned video. I realized that The turning radius of the new KF is capable of being much tighter than before. I also realized with the vast expansion in user tune ability. You can really make or break a craft, based on just how crazy you go with the setup. I realized my one and only remaining complaint is simply the Steering speed / Steering centering speed. And the ability for KF to narrow the steering at higher speeds. I was able after some additional fine tuning to get my crane handling better but it's still very tippy at 17m/s simply because it would steer to tight too fast. Even with fine controls turned  on. Now there is a vast improvement in drivability using fine controls, thanks a ton for that tip as it never even occurred to me. But my final suggestion on this and I give you my word I will stop harping because I really don't want to beat a dead horse as this mod is absolutely fantastic!

A slider to adjust steering angle narrowing at speed.

Slow down steering return to center to match - steering speed when pressing left or right arrows.

If you still would like to see a comparison in driving between new and old KF on a given craft let me know And I'll gladly still put something together. It just started to seem like a waste of your time at this point.

[Shadowmage]

2 hours ago, V8jester said:

A slider to adjust steering angle narrowing at speed.

Adjust the steering curve in the config files.  What I have currently setup as defaults actually feels far too restrictive for me... so if you want it reduced even further your only option is a patch. (of course, I only use scale=1 on wheels, at larger scales the max speed might be higher, and the curve insufficient...)

You'll need to add the full steering curve definition to the KSPWheelSteering module, as they all use the default steering curve.

Example:

MODULE
{
	name = KSPWheelSteering
	//the rest of the existing stuff...
	steeringCurve
	{
	  //first number is percentage of max speed as a decimal, 50% would be 0.5
      //second number is the percentage of steering authority at that speed
      //these are the default values; at max speed you will have only 10% of max steering authority
      key = 0 1.0
      key = 1 0.1
	}
}

2 hours ago, V8jester said:

Slow down steering return to center to match - steering speed when pressing left or right arrows.

That sounds like a bug that someone should report on the stock tracker.  Nothing I can do to fix it.

Edit:  Its probably not a bug in stock code, but an intentional decision.  It would be bad, for example, if RCS didn't turn off immediately in fine-control mode.

 

With the above in light, I'll look into what I can do to still have a toggle-able steering response setup (that works in both directions).  I asked if there was a good reason, and re-centering being instant definitely classifies.

The main problem that I will encounter is that when the stock fine-control is enabled it alters the base vales that code has access to (the steering and throttle input states), and I'm unsure if I can get the raw inputs.  Alternatively I could set up a custom keybind for the toggle and track the data internally, but I'm not sure how nicely that will play with other mods.  Might be the only option though.

I might be able to add an additional control for 'high-speed-steering-limit' that worked in addition to, or in place of, the existing controls.  But there are already lots of controls on some of these parts...

 

Edited February 10, 2017 by Shadowmage

[Shadowmage]

@V8jester

New steering code.  Includes user-configurable high and low speed steering limits and steering response (all through additional sliders on the part-menu...):

        internal override void preWheelPhysicsUpdate()
        {
            base.preWheelPhysicsUpdate();
            float rI = -(part.vessel.ctrlState.wheelSteer + part.vessel.ctrlState.wheelSteerTrim);
            if (steeringLocked) { rI = 0; }
            if (invertSteering) { rI = -rI; }
            float bias = steeringBias;
            if (rI < 0)
            {
                rI = rI * (1 - bias);
            }
            if (rI > 0)
            {
                rI = rI * (1 + bias);
            }
            rI = Mathf.Clamp(rI, -1, 1);
            rotInput = Mathf.MoveTowards(rotInput, rI, steeringResponse);
            float perc = Mathf.Clamp01(Mathf.Abs(wheel.wheelLocalVelocity.z) / (controller.maxSpeed * controller.wheelMaxSpeedScalingFactor));
            float limit = ((1 - perc) * steeringLimit) + (perc * steeringLimitHigh);
            if (useSteeringCurve)
            {
                limit *= steeringCurve.Evaluate(perc); 
            }
            wheel.steeringAngle = maxSteeringAngle * rotInput * limit;
        }

(note;  Untested prototype code, may have some things that need to be fixed)

Sadly there is no fix for the stock fine control mode.  It will -still- be usable/combinable with the 'steering response' stuff, but will still have the same problems that it does currently (instant-snap-back-to-center).  Nor is the new steering response stuff as easily toggle-able as I would like, but I'm very hesitant to start adding new keybinds, and I cannot use the stock 'fine-control' keybind/state as there is no way to -stop- the stock fine control stuff from interfering.

[DocMop]

How are the steering inputs handled codewise? What values does KSP give you when I press 'A' or 'D'?

Edit:
I derived most of it from your code snipped. What are the differences between normal and precision inputs codewise? Maybe something comes to my mind .. tomorrow. Should sleep ... now.

Edited February 11, 2017 by DocMop

[V8jester]

@Shadowmage That code you posted. This is a little beyond my abilities so I am probably about to ask a really dumb question.

Are you showing us something you intend to try out in the next release of KSPWheel? Or is this a section of code to be placed by a capable user into the source available on Git and then compile there own version of KSPWheel?

[Shadowmage]

22 minutes ago, DocMop said:

How are the steering inputs handled codewise? What values does KSP give you when I press 'A' or 'D'?

Edit:
I derived most of it from your code snipped. What are the differences between normal and precision inputs codewise? Maybe something comes to my mind .. tomorrow. Should sleep ... now.

The inputs that I get from the vessel control state are after stock has applied fine-control mode.  It includes inputs from keyboard and whatever controller the user may have assigned to those axis.  Can range from -1 to +1, with one extreme being right/forward, and the other being left/backward.

10 minutes ago, V8jester said:

@Shadowmage That code you posted. This is a little beyond my abilities so I am probably about to ask a really dumb question.

Are you showing us something you intend to try out in the next release of KSPWheel? Or is this a section of code to be placed by a capable user into the source available on Git and then compile there own version of KSPWheel?

Prototype code that I'm testing now to see how well it will do;  I'm really not a fan of having even more controls on the UI (for the response and high-speed limit), but unsure of any other way to expose them to user-configuration.  If testing goes well you will probably see them with the next release of KSPWheel; will let you know how it turns out.  Posted the code as that is the easiest way to explain the functionality of how all the various limits and curves interact.

[rasta013]

I've been following this discussion of steering limits for a bit now and have a curiosity question.  The menu solution you provided for SSTU to choose nose/mount sections as well as the tank config window work fantastically, could something like that be done for the wheel system to put these varying controls into something a little more easier to arrange and see?  I ask mainly since the other menus I mentioned are specific for the editor and not exposed in flight whereas the wheels are via RC.  Just didn't know if this might even be a viable choice to get all these little sliders/toggles in a controllable interface...

Edited February 11, 2017 by rasta013

[DocMop]

@Shadowmage

It should be irrelevant then whether Precision Mode is enabled or not, as long as you always approach the target value rI (minus the different limiters) with the speed steeringReponse from the current value of wheel.steeringAngle.

Something like this:

internal override void preWheelPhysicsUpdate()
{
    base.preWheelPhysicsUpdate();
    float rI = -(part.vessel.ctrlState.wheelSteer + part.vessel.ctrlState.wheelSteerTrim);
    
    if (steeringLocked) { rI = 0; }
    if (invertSteering) { rI = -rI; }
    
    if (rI < 0)
    {
        rI = rI * (1.0 - steeringBias);
    }
    if (rI > 0)
    {
        rI = rI * (1.0 + steeringBias);
    }
    
    rI = Mathf.Clamp(rI, -1.0, 1.0);
    
    float perc = Mathf.Clamp01(Mathf.Abs(wheel.wheelLocalVelocity.z) / (controller.maxSpeed * controller.wheelMaxSpeedScalingFactor));
    float limit = ((1.0 - perc) * steeringLimit) + (perc * steeringLimitHigh);
    
    if (useSteeringCurve)
    {
        limit *= steeringCurve.Evaluate(perc); 
    }
    
    float targetAngle = maxSteeringAngle * rotInput * limit;
    
    wheel.steeringAngle = Mathf.MoveTowards(wheel.steeringAngle, targetAngle, steeringResponse);
}

That should always do a smooth transition. And I removed one unnecessary variable (bias). The only issue I can see right now is that steering speed and centering speed could differ in Precision Mode if steeringResponse is faster than the rI gain.

Warning: I never touched KSP code. Seems like some C derivate though.

 

Edit:
You might want to scale steeringResponse dependent on the current speed of the vehicle so it turns the wheels slower if the vehicle is really fast. Could be as simple as this although it should be clamped so it doesn't get too slow maybe:

float steeringResponseScaled = steeringResponse * (1.0 - perc);

//Optional Clamping to prevent steeringResponseScaled from geting too low
steeringResponseScaled = Mathf.Clamp(steeringResponseScaled, MIN_STEERING_RESPONSE, steeringResponseScaled);

wheel.steeringAngle = Mathf.MoveTowards(wheel.steeringAngle, targetAngle, steeringResponseScaled);

However, gameplay testing would have to be done in order to see if the scaling is needed.

 

Edit2:
I swear someday I'll do a post without editing it 3 dozens times afterwards -.-

Edited February 11, 2017 by DocMop

[Shadowmage]

11 hours ago, DocMop said:

@Shadowmage

It should be irrelevant then whether Precision Mode is enabled or not, as long as you always approach the target value rI (minus the different limiters) with the speed steeringReponse from the current value of wheel.steeringAngle.

Something like this:

That should always do a smooth transition. And I removed one unnecessary variable (bias). The only issue I can see right now is that steering speed and centering speed could differ in Precision Mode if steeringResponse is faster than the rI gain.

Warning: I never touched KSP code. Seems like some C derivate though.

 

Edit:
You might want to scale steeringResponse dependent on the current speed of the vehicle so it turns the wheels slower if the vehicle is really fast. Could be as simple as this although it should be clamped so it doesn't get too slow maybe:

However, gameplay testing would have to be done in order to see if the scaling is needed.

 

Edit2:
I swear someday I'll do a post without editing it 3 dozens times afterwards -.-

Not sure I explained the inputs very well.  When 'precision mode' is enabled, KSP gives an input state of whatever is displayed on the little input widget on the bottom-left of the screen; the value slowly moves between 0 and 1/-1, actually accelerating its change the longer the button is held down.  When 'standard' control is enabled, keyboard inputs give either a 0 or a 1/-1 instantly changing value with key state, while controller axis inputs can be anything between 0 and 1/-1 depending on the axis input.  There is no way to disable stock precision mode, so that input will also be effected by the KSPWheel response speed.

 

Sadly I cannot adjust the response speed based on current speed/percent of max.  Response speed = 1 means 'instant response'; any adjustment to that and the whole thing breaks.  It doesn't seem to be needed though; as the response speed is calculated on the actual control inputs, separate from limiter calculation, and combined for actual output; thus the limiters automatically decrease the response speed proportionately to the current limit.

I have to keep the 'instant response' ability in place, because franky, I hate the steering response and limit mechanics.  I also use controllers (saitek-x52 or steam controller, depending on my mood  and what I'm doing), so all of this steering limit and response stuff is useless to me and only gets in the way of the inputs that I'm actually giving the game (because, you know, sometimes I actually want to initiate a slide at high-speed; difficult if the steering is artificially limited or response speed is not instant).

You're right on the removal of the extra 'bias' variable; it shouldn't have had much effect though as it was declared in a local scope and would be cleaned up when the stack was popped (declaring primitive variables on the stack is generally very cheap, though not quite free).  Have removed that extra declaration though in favor of using the UI value directly, no reason to allocate when it is not needed, even if it would be cheap.

 

KSP/Unity use C# (c-sharp) as (one of) their scripting language.  Its kind of a mashup of C++ and Java from my perspective; memory managed and no use of pointers like Java, but with operator overrides like c/c++ (and a few other things like lambdas that didn't exist in Java last I used it).

Good write-up though; I'm glad there is someone who I can converse with intelligently about this stuff    Far too often I get the feeling that I'm entirely alone in my understanding of all of this, which is quite depressing considering the game is about rocket science; I would think there would be quite a few other interested parties around the forums who would understand at least the math bits of the code.  There are a few others around, but seem to be a bit rare.

(Edit: After posting the above I realized it could be interpreted in a negative manner; it is not intended as such, it is merely an expression of the signal-to-noise ratio of the info and bug-reports I see; quality feedback is hard to come by)

 

18 hours ago, rasta013 said:

I've been following this discussion of steering limits for a bit now and have a curiosity question.  The menu solution you provided for SSTU to choose nose/mount sections as well as the tank config window work fantastically, could something like that be done for the wheel system to put these varying controls into something a little more easier to arrange and see?  I ask mainly since the other menus I mentioned are specific for the editor and not exposed in flight whereas the wheels are via RC.  Just didn't know if this might even be a viable choice to get all these little sliders/toggles in a controllable interface...

Yeah, I've been working on one for awhile now in the background (the per-vessel debug GUI is the usable results of the efforts so far).  Gotta get all the rest of the functions and features implemented first though so that I know exactly how I need to lay out the GUI.  Probably still a few weeks out from seeing any comprehensive control GUI, but I would like to get one in place eventually.

Edited February 11, 2017 by Shadowmage

[DocMop]

1 hour ago, Shadowmage said:

Good write-up though; I'm glad there is someone who I can converse with intelligently about this stuff    Far too often I get the feeling that I'm entirely alone in my understanding of all of this, which is quite depressing considering the game is about rocket science; I would think there would be at least a few other interested parties around the forums who would understand at least the math bits of the code.

Anytime. At least when my exams are not hindering me

 

Some thoughts:
In my opinion the response mode (instant / gradual) should be changeable via the game settings menu. There is no need to further clutter the wheel context menus for something thats either globally on or off. And of course the instant mode can very well hide any steering speed tweak-ables. Always a fan of clutter free menus and stuff.

 

PS: Literals! For a coder the only value between -1 and 1 is 0

[Shadowmage]

Updated KSPWheel testing version is available; this should be considered an experimental dev version... may contain more bugs than usual, and these changes might not make it back into the master branch depending on how testing/feedback goes.

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

Largest changes are the reworked motor power handling mechanics, but also includes some additional steering functions and some updates to dust-effects.  NOTE:  KF parts have not been rebalanced yet for the updated motor mechanics, so power draw and torque on them will be quite high.  -IF- testing goes well, the KF configs will be updated with the next KF release.

In order to update to this KSPWheels testing version; delete whatever existing KSPWheels folder you have in your GameData folder, and install the testing release as usual.

[Shadowmage]

On a more positive note, I think it is time that I start discussing the medium-to-long term plans that I have for Kerbal Foundries.

As KF is all about 'making things move' I have a few ideas for future part additions that I think would fit in quite well with the overall theme:

• Hovercraft motors/engines and skirt pieces.  Ground-effect enhanced atmospheric engines.  Like repulsors, but based much more in reality rather than 'magic anti gravity force'.
• Rotor-craft rotors (main, tail) - both static and deployable/folding models.
• Aircraft props, fans, vtol-engines, folding/stowable wings.
• Landing Legs -- single (standard), dual (stack-mount, horizontal), quad (stack-mount, vertical).  Scalable, configurable.
• More wheel models? (standard 'car', offroad truck, industrial truck, ??)

Not quite sure where I will start on those, but leaning towards landing legs as nearly all the coding is in-place for those already.  The other option would likely be 'more wheels' as I already have modeling/art assets for a few of those.  Either way I wouldn't expect to see much of any of these before Summer (or 3-6 months out).  Have a few other plans for other mods that I need to get back to work on (and still a few things in KF and KSPWheel that need finished / cleaned up).

Feel free to post suggestions or ideas related to those part-concepts, or even suggestions for new part concepts that you think would fit well in KF.  Though please stay away from one-piece 'tank chassis' or 'aircraft fuselage' and the like; I'm not here to make replicas of anything -- you are free to model and make those parts on your own; I might however field ideas regarding themed sets of aircraft or rover body parts (for example, the hovercraft skirt-part-set listed above).

 

Additionally if there is anyone who would be interested in joining the team as a modeler and texture artist I would be open to collaboration and much appreciative of the efforts (please PM me if interested).  The goal would be to create new part models and textures with stock-alike geometry and texturing.  No real rigging or coding knowledge necessary, I'm capable of taking the finished model and reworking them for rigging, however I'm unsure of my abilities to do modeling (or more-so, the texturing) in a 'stock-alike' fashion.  If there is someone interested in picking up the modeling and texturing of some of the new parts it could move up the timeline on them substantially.