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

[0111narwhalz]

I'm developing some general-use trailing arm mechanisms (through use of IR and abuse of antigrav). They're quite robust and resistant to permanent dislocation. I've already experienced some success with bolting them onto other chassis with minimal changes.

They do, however, consume an immense amount of power. Under heavy loads (77T distributed between four arms), the compression repulsor might use as much as 25EC/s at rest. Not to mention the hundred or so EC/s from the actual drive motors (KF Small Rover Wheel, scaled to 2.25).

I also have a design in development with some...double wishbone(?) suspension. That model of suspension is far less sturdy as of yet, being susceptible to permanent dislocations, snapping, and several rather energetic failure modes. It's in need of some tuning as well, as the compression and rebound repulsors are fighting and inflating power consumption, but that will come after the more severe issues are fixed.

I like using the repulsors because they don't have wheels at the other end, and thus should be slightly cheaper on the processor, but the power use associated with them is suboptimal for my purposes. Also, they have no reservations about overextension and are apparently lacking the anti-punchthrough measures afforded to most of the wheels. I think all these problems could be solved for my application by making a specialized shock part containing a KSPWheel suspension module and an IR module. I realise that this is most decidedly unsupported use, and don't expect anything in particular from you guys (I fully expect to do this on my own), but I'd like to know if it's possible for a suspension collider to interact with another mesh in the same part. That is, can I make the same part have both the suspension and the suspension "target," or do I need to have a different part on the distal end of the shock (like the pivot to which struts are attached)?

It's a shame that nonuniform scaling isn't possible. I feel that this suspension part would benefit from having different lengths without changes in thickness. I guess that's what levers are for, though.

[Shadowmage]

@Azimech if the resources that @SpannerMonkey(smce) linked don't work for you / aren't enough for you, let me know and I'm sure I can help you get it figured out.  KSPWheel does also have accommodations for left-handed/right-handed part mirroring, but you have to explicitly create separate left/right handed models (used on a couple of the KF parts), and setup the config for them properly.

 

16 hours ago, 0111narwhalz said:

It's a shame that nonuniform scaling isn't possible.

Its possible -- its just that most models don't support it well (and it also has to be setup at the plugin level).  Mostly it comes down to you can use non-uniform scaling, as long as nothing gets rotated afterwards (or at least not rotated on the skewed axis).  I've used non-uniform scaling in SSTU for various purposes (fairings, fuel tanks).

For your uses -- a specialized suspension strut for use with IR/etc -- could probably be accomplished through a very small/simple new module that manipulated/rescaled a pre-built model according to the strut parameters.  Could also remove the EC use for internal mechanical suspension parts (no reason they should consume EC).

[Gaalidas]

On 6/27/2017 at 9:25 AM, Shadowmage said:

Any new part models / textures would be a ways out.  I'm still very overloaded at work this summer, and won't have time for much of that kind of work for a few months.

Textures would likely come first, though I would need to add/adapt a texture-switching plugin from somewhere (either integrated into KF, or added from one of the SSTU bits; sorry, no Firespitter here).  In fact, if someone were to make the textures, you could likely use one of the existing texture-switch solutions to make it functional (though, obviously, you need the textures first).

On that note, I did at one time extract the texture swapping portion from Firespitter.dll into my local KF project with the intention of digging out useful code to make a part of KF... but never really took it anywhere after migrating the basic functionality.  I actually didn't really like how it was implemented in the part configs and was going to alter it for ease of configuring and, possibly, integrate with the existing KF model swap mechanics at the time (used for non-symmetrical tracks that needed to be able to be attached in symmetry modes such as the Screw, aka hypnodrive, and one of the larger tracks.)  It's just another of my abandoned projects from when I took over KF a long time ago.

if someone were to analyze how it's done in one of those other mod packages and then modify a copy of the existing texture used on the current model, creating a patch with MM wouldn't be difficult.  What can be difficult, however, is if the model is extremely complex and has multiple texture calls for different objects and textures.  I remember a few complex models that called up a copy of the same exact texture several times and using firespitter was nearly impossible because you needed a separate module for each object that needed to be specified exactly and couldn't be multi-specified.

Again, that's why I wanted to rewrite it.  KF already had code to find the model object names for use in other calculations and I figured I could integrate with those modules to make object and texture matches auto-populated (or auto enumerated, in coder-speak).

Edited July 4, 2017 by Gaalidas
nit-picking my own posts.

[Gaalidas]

On 6/8/2017 at 8:07 AM, Shadowmage said:

The 'real' solution to this problem would be for someone (not me) to figure out how to dynamically detect the surface being interacted with and dynamically adjust surface friction based on that information.  That way you can get some slips and sliding on gravel, but get nicer tracking on the runways and paved portions of the KSC.

On that note... The first versions of DustFX used a form of ground-region and/or location and/or biome detection method to specify high and low color ranges (though I pretty much stuck with non-ranged values for them at the time of working on that).  Now we use, primarily, a camera that doesn't see the vessel and just averages the texture colors it's getting.  That aside... you could use a combination of biome-detection and texture-color-range detection to set up an approximate slippage scale that could then be adjusted along with the dust colors.  In fact, that would allow for dust densities to be adjusted not only on the speed of the craft relative to the terrain but also based on the estimated density of the terrain.  Obviously there wouldn't be any perfect setup unless we could get access to the stock terrain/biome stats if they even have any form of terrain density/stability statistics.  I seem to remember there being a setting in the game detail settings that had some form of density setting for planetary features, but I don't know if that means anything when you interact with the planet in the end.

Of course, the code could be revived, which handled complex persistent settings for the old KF, to store pre-generated stats for some estimated terrain locales which could be updated on the go to create a slow-built database of estimated values for this sort of thing.  It shouldn't be too hard to re-implement considering all it did with KSP specifically was integrate with the config node system which, while frustrating at first, turned out to be easier to use than expected.

Another variable that could be used in estimating slippage would be the estimate temperature range of the planet as a whole, and then of the latitude of the craft vs the equator.  Warmer material would likely be muckier than colder surfaces except when dealing with concrete (so, an exception in the case of anything with an estimate color of gray but not if it's blue-gray so ice doesn't become super stable... could be tricky to code).  It would be so much easier if the actual texture could be detected under the camera so you could make overrides for specific texture names on the surface.

I'm rambling again I think... I suspect that most of this would be impossible using the stock game implementation of planets.  Using the code from planet expansion packs might allow detection of such details directly from the planet comfig files included with supporting mods.  As far as I'm aware, however, these mods do not replace the stock planets with their own configurations so it wouldn't be too useful to us for stock surfaces.

Either way, I foresee a lot of interaction between mods we don't control to make it all work.  I could estimate things based on the sampled color of the terrain, but that's pretty much it without reviving and overhauling code form other sources.  I won't say it's impossible though.

[Gaalidas]

On 6/5/2017 at 8:23 AM, Shadowmage said:

The 'small' ALG?  Probably not possible with the current plugin code; the animations are so hard-coded into the module that I doubt it would be possible through the existing config.  The closest you might come would be to disable the action groups (if possible); but that would still leave the standard right-click toggle button.

I am so much of a multi-posting offender today... but you'll forgive me due to the size of my posts I'm sure.  Otherwise... judge me as you will.

As our host has iterated, this isn't something doable at this time.  However... it would be so extremely easy for this to be a thing on the code-end that I'm shocked it wasn't made a thing from the get go.  My philosophy in coding modules for KSP has always been to put the power in the part-config and, if possible, user's hands.  I altered lo-fi's code to his great annoyance, I'm sure, to take away hard-coded values for resource usage and other such things and place them in the configs with a hard-coded default for non-specifying module definitions.  Even then, some of thsoe defaults were put in mod-specific persistent config files in the dll directory so they could be configured outside of the running game.  I even played around with the idea of expanding the config-panel I had in the old KF plugin to allow specifying a default resource to be taken up by the wheels by default, populated from the loaded resource types in the config nodes.  I'm sure lo-fi secretly hated me for that, but I always felt that the person who might use my code in the future would want an asy way to alter things to work the way they wanted them to.  As such, most (if not all) the original KF animation controllers came with an easy way to select whether the default state could be toggled, by scene or globally, as well as what it would start with and whether or not it could be reversed after animating.  When possible I even tried to give the editor scene the ability to alter the speed of the animation.  If I were doing it now, I'd probably try to add adjustable lengths of the extension-retraction animations too on a per-part, per-craft, or global scale.

I guess I just figured it was my job, as the programmer, to think of all the ways a future user might want to configure the part module and then make sure that my code exported as many of those options as possible to the module config while still maintaining default values in case a config is missing something.  It's much the same as if you look at the stock KSP part modules.  You can leave a lot of things out of them and still have a working part because they have allowed almost everything to be specified per-part while maintaining default values for missing data.

So... yeah... if no one else gets to it in the near future, you may see some new code hacked together from me.  Otherwise... hop to it coders.  Chop chop.

[Shadowmage]

On 7/4/2017 at 3:53 AM, Gaalidas said:

On that note, I did at one time extract the texture swapping portion from Firespitter.dll into my local KF project with the intention of digging out useful code to make a part of KF...

On the subject of texture-swapping -- I am quite intimate with how the various texture-swapping plugins work, having written several myself.  No mysteries there -- just time constraints.

If/when I set it up, I'll go the same route I did with SSTU -- you define 'texture sets' in a (potentially separate from the part) config file, these sets a group of transforms and their associate textures, neatly solving the 'multiple different textures used by a single part' problem.  Heck, I can probably import large portions of the code as-is, and there shouldn't really be too much new that needs to be written.  (and yes, can tie it into the left/right handed symmetry module).

Edit:  Here you go, fully implemented, but also fully untested    --   https://github.com/shadowmage45/KSPWheel/commit/f5d2ccf21931853080312e259c97aea35b64c209

I'll work on getting some extra textures made up for some of the parts in the near future.  Heck.... perhaps I should look into adding the full 'Recoloring System' support that I recently created for SSTU (if I'm already creating textures, might as well make them user-configurable).

 

On 7/4/2017 at 4:18 AM, Gaalidas said:

That aside... you could use a combination of biome-detection and texture-color-range detection to set up an approximate slippage scale that could then be adjusted along with the dust colors.

I think this is a wonderful idea.  Obviously wouldn't work with planet-packs unless the biome configs were added for them, but could setup configs for the stock system easily enough.  Taking it one step further, there could even be a 'collider specific' list that would handle stuff like the concrete areas of the KSC.

It would almost have to be setup in a manner so as to have multiple entries for some biomes (mostly the KSC...); as some parts of the KSC are grass, and others concrete, even on a single collider/PQS segment.  So the biome lookup would return 'KSC-XXXX', and the camera color would be some shade of green, or gray -- the biome entry for KSC would have friction values for the green/gray extremities, and the exact friction value chosen would be lerped between the config extreme values based on the current camera color.

Hmm.... a bit more complex than I would like it to be, but certainly doable.

 

Edited July 5, 2017 by Shadowmage

[linuxgurugamer]

Curious, can the wheels (specifically, landing gear) in KF be adjusted using TweakScale?

[Shadowmage]

6 minutes ago, linuxgurugamer said:

Curious, can the wheels (specifically, landing gear) in KF be adjusted using TweakScale?

Not with TweakScale -- but KSPWheel (and thus all KF parts) have built-in support for scaling.  So yes, you can adjust scale, but not with TS.

[linuxgurugamer]

Just now, Shadowmage said:

Not with TweakScale -- but KSPWheel (and thus all KF parts) have built-in support for scaling.  So yes, you can adjust scale, but not with TS.

Ok.  Then, I may have missed it, how do I adjust the scale?

 

[Shadowmage]

Just now, linuxgurugamer said:

Ok.  Then, I may have missed it, how do I adjust the scale?

 

In the editor there should be a UI slider in the part right-click menu labeled 'Scale'; simply adjust the slider/buttons to suit the needs.  If there is not, I might need to see a screenshot of the in-editor part right-click menu (and potentially logs/etc).

Although.... I'm not sure if I ever did any real testing after the 1.3 update, so it might be broken/missing from that (though I think I would have heard about it by now).

[linuxgurugamer]

Just now, Shadowmage said:

In the editor there should be a UI slider in the part right-click menu labeled 'Scale'; simply adjust the slider/buttons to suit the needs.  If there is not, I might need to see a screenshot of the in-editor part right-click menu (and potentially logs/etc).

Although.... I'm not sure if I ever did any real testing after the 1.3 update, so it might be broken/missing from that (though I think I would have heard about it by now).

I'll check again, but I didn't see it (which is why I was asking about tweakscale, which I don't like that much)

Thanks for responding, I'll be able to check later

[Shadowmage]

Just now, linuxgurugamer said:

I'll check again, but I didn't see it (which is why I was asking about tweakscale, which I don't like that much)

Thanks for responding, I'll be able to check later

Yes, please let me know if it is/isn't there and I will look into it further if needed.  I believe it should be present on all KF parts (there is an option to disable scaling, but is normally only used by other mods' parts with integrated wheels).

Yeah, I second the feeling on TweakScale.  Excellent concept, and with good integration with stock parts, but the mod-integration is lacking a bit.  Which is why I try to include built-in scaling capabilities in my mods wherever possible.

[linuxgurugamer]

Here you go, log file and image:

https://www.dropbox.com/s/qcyuv33gya9m9xp/logfile.zip?dl=0

[Shadowmage]

@linuxgurugamer

I'm seeing it there in the screenshot, 5th line down (right below Wheel Group).

Edited July 5, 2017 by Shadowmage

[linuxgurugamer]

23 minutes ago, Shadowmage said:

@linuxgurugamer

I'm seeing it there in the screenshot, 5th line down (right below Wheel Group).

Gaaaah

I  must have been blind.

Thanks

[Gaalidas]

On 7/5/2017 at 7:57 AM, Shadowmage said:

urther, there could even be a 'collider specific' list that would handle stuff like the concrete areas of the KSC.

It would almost have to be setup in a manner so as to have multiple entries for some biomes (mostly the KSC...); as some parts of the KSC are grass, and others concrete, even on a single collider/PQS segment.  So the biome lookup would return 'KSC-XXXX', and the camera color would be some shade of green, or gray -- the biome entry for KSC would have friction values for the green/gray extremities, and the exact friction value chosen would be lerped between the config extreme values based on the current camera color.

Hmm.... a bit more complex than I would like it to be, but certainly doable.

Early versions of the color sampler for the DustFX certainly could have handled the complex predefined values for such things.  Before the camera came into play we even had a "landedAt" method that somehow was able to detect specific places such as the statics around the KSC.  I imagine, with some looking at Kerbal Konstructs, there may be a good way of detecting a static vs. the ground and possibly even what static it is that we're colliding with.

I keep running into things that keep me from spending a large amount of time in the code.  It's irritating.

 

 

On the subject of scaling... TS support was in the previous major iteration of this mod, back when lo-fi and I were the main contributors.  Good times.  In the end, however, there was too much custom code to handle different variables to pass to TS that it just made sense to pull away and implement it separately.  TS was amazing for KF back in the day though.  I built most of the old TS configs for KF.  Heck, I remember when TS didn't exist as anymore more than an afterthought mod for a specific part mod.  Good times indeed.

Edited July 10, 2017 by Gaalidas

[FungusForge]

Would be possible to get tracks and wheels lacking suspension?

[Shadowmage]

13 hours ago, FungusForge said:

Would be possible to get tracks and wheels lacking suspension?

No, it is not possible.  At least not at the current time.

It is a limitation of the physics in use.  In order to know the 'down force' for the friction, there has to be a spring in use in order to calculate that down-force.  Additionally, when trying to use colliders without springs -- Unity has some fairly garbage collision detection.  Take a vehicle with 6 wheels, all at exactly the same height.  Unity may only see 3 of those wheels as colliding/grounded, and thus your friction and traction get all screwey.

[0111narwhalz]

12 minutes ago, Shadowmage said:

No, it is not possible.  At least not at the current time.

Would wheels with very small travel have problems with physics stability, since they're usually at the extremes of their travel?

If not, would such wheels be viable for "composite suspension" like the kind I've been developing? All the suspension is handled higher on the tree, by elements that are very small in mass compared to the complete vessel. Would this be equivalent to giving the wheels large travel?

[Shadowmage]

7 minutes ago, 0111narwhalz said:

Would wheels with very small travel have problems with physics stability, since they're usually at the extremes of their travel?

If not, would such wheels be viable for "composite suspension" like the kind I've been developing? All the suspension is handled higher on the tree, by elements that are very small in mass compared to the complete vessel. Would this be equivalent to giving the wheels large travel?

Very small travel = numerically unstable in a stepped physics environment (e.g. Unity).  Basically it constantly would go from uncompressed, to fully compressed, and if the spring was actually strong enough to hold the vehicle... this would result in jittering and potential jumping/launching.  You could actually see some of that in the stock landing gear during the 1.1/1.2 updates (mostly the small 'fixed' gear, as they tried to have a zero/very small suspension travel) (different wheel physics, but the same outcome, as it is an underlying limitation of the simulation and not the code).

Composite suspension -- no clue, I don't use IR, and such setups will not work without moving/rotating joints.  In the end it would come down to the numerical stability of those joints and Unity's constraints system.  But I don't see that it would help the situation -- adding more constraints and such is much more likely to make things break down even worse rather than fix anything.

[FungusForge]

1 hour ago, Shadowmage said:

No, it is not possible.  At least not at the current time.

It is a limitation of the physics in use.  In order to know the 'down force' for the friction, there has to be a spring in use in order to calculate that down-force.  Additionally, when trying to use colliders without springs -- Unity has some fairly garbage collision detection.  Take a vehicle with 6 wheels, all at exactly the same height.  Unity may only see 3 of those wheels as colliding/grounded, and thus your friction and traction get all screwey.

Well dang. Thanks for the explanation though.

[Shadowmage]

@0111narwhalz

This might be of interest to you:

https://github.com/shadowmage45/KerbalFoundries2/issues/16

(sorry, no ETA, but at least it is on the official 'todo' list)

[FungusForge]

What about something that has suspension inside the wheel sorta like the small wheel, but with the suspension and steering joint all inside the wheel. The idea being an ambidextrous wheel that isn't any wider than the wheel itself, maybe even to the point of having two nodes (one on the left, one on the right).

I know this would totally invite clipping when a steering wheel is placed directly against a flat surface.

[Gaalidas]

5 minutes ago, FungusForge said:

What about something that has suspension inside the wheel sorta like the small wheel, but with the suspension and steering joint all inside the wheel. The idea being an ambidextrous wheel that isn't any wider than the wheel itself, maybe even to the point of having two nodes (one on the left, one on the right).

I know this would totally invite clipping when a steering wheel is placed directly against a flat surface.

That I could see, possibly.  Technically you can make anything appear to be anything, separate from the actual functionality of the part.  A good example of this is the repulsor which, in it's very earliest design, was simply a wheel without the wheel visual geometry.  It's a lot different now of course, but that's where it started.

[FungusForge]

13 minutes ago, Gaalidas said:

That I could see, possibly.  Technically you can make anything appear to be anything, separate from the actual functionality of the part.  A good example of this is the repulsor which, in it's very earliest design, was simply a wheel without the wheel visual geometry.  It's a lot different now of course, but that's where it started.

It wouldn't be too much of a stretch to request it then? There's a lot of ways I could use a wheel like this that I've not done simply because it looks atrocious with the current selection of wheels (and I really don't like the stock wheels, or wheels that work like them)