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

[Stone Blue]

40 minutes ago, Horus said:

Is it possible to untie the wheels textures from TexturesUnlimited? I personally don't need those shiny chrome textures on wheels. It also messes up the stock gold\silver foil textures.

A few posts above yours:

https://forum.kerbalspaceprogram.com/index.php?/topic/155056-142-kerbal-foundries-continued-tracks-wheels-and-gear-04-10-18/&do=findComment&comment=3552607

[Horus]

1 hour ago, Stone Blue said:

A few posts above yours:

https://forum.kerbalspaceprogram.com/index.php?/topic/155056-142-kerbal-foundries-continued-tracks-wheels-and-gear-04-10-18/&do=findComment&comment=3552607

Thanks. Totally skipped that long text. It really does contain all info I need. Sorry.

[Shadowmage]

In development news:

APU got a new smoke particle effect, as I've implemented an asset-bundle loading system to allow for creation of particles in the Unity Editor and loading into game fully configured.  I'm a complete newbie when it comes to particles... but I think it looks sufficiently smoke-like for its intended use.

Repulsor effects are now loaded through AssetBundle, so could technically be replaced/swapped out.  Also using a new particle texture for better visibility.

Repulsors not turning on properly has been fixed.  Apparently the new stock function call for getting resources from a part differs in functionality from the old deprecated function, and was failing out when trying to pull EC.  My bad for trying to clean up the use of the deprecated function...  (at some point I should find out how the new function works and use it.. but for now... back to using the old stuff).

Initial (re)balance pass is underway, with everything being re-balanced relative to stock parts.  Mass, cost, motor torque, and max speed should all be comparable to stock parts.  I've realized that stock doesn't seem to actually implement any sort of 'max load' function (or does it?)... at least not that I can infer from the part stats, so I may well set the 'overload damage' function to be disabled by default.  Shouldn't these legs instantly buckle under this sort of a load?  (max length 5m fuel tank...full of fuel)  (the ones in the image will eventually break; but only when the unstable stock legs pogo themselves into oblivion, gaining energy the whole time...)

 

So, aside from the 'max load' stat which is yet undetermined, here is a bit of the data that I've put together for the re-balance so far.  Haven't touched the part configs yet, figuring it all out as data first.  Sorry, its an image... no clue how to paste tabular data into these forums (if its even possible).  Motor torque also not included in chart as I haven't gotten that far yet...

Few more stats to fill in, and then transfer it all to configs and do some tests to see how it all feels with some simple craft.  Lots of parts to test, so that part of things might be an ongoing process.  Then to address balance for scaling...

 

 

On 3/6/2019 at 6:10 PM, Kolago said:

After update to the latest version (KerbalFoundries 2.3.7.17), if I use the "KF-RepulsorStandard" they shut down on the spot. Anyone else has this problem?

Is exactly why that release is a 'testing release'; so many changes to code/models/configs and only limited testing time... bound to have some bugs and issues to be ironed out .  Have found and solved that problem in dev branch, and fix for it will be available with the next testing release which should be available likely over the weekend.

[linuxgurugamer]

@Shadowmage

Is this a change to the basic KSPWheel, or just the KF stuff?  This caught me by surprise (not your problem), and I don't have time right now to read the entire thread.

I guess what I'm getting at is, will other mods which use KSPWheel need to be fixed?

Also, since this appears to be game-breaking change, have you thought about changing the names of the parts, and then you could have a legacy pack and then the new KF2 pack?  This would ease the transition for many people, I think

[Shadowmage]

2 hours ago, linuxgurugamer said:

Is this a change to the basic KSPWheel, or just the KF stuff?  This caught me by surprise (not your problem), and I don't have time right now to read the entire thread.

Just changes to KF stuff; basically just refreshing models and textures and a few other minor cleanup bits.  Other mods using KSPWheel should be unaffected unless they were using the specialized KF-specific modules (APU/Repulsor).  They are otherwise free to make use of the new features, but those features are optional where implemented.

2 hours ago, linuxgurugamer said:

Also, since this appears to be game-breaking change, have you thought about changing the names of the parts, and then you could have a legacy pack and then the new KF2 pack?  This would ease the transition for many people, I think

Its about 90% there right now -- but I have no intention of supporting multiple releases (no time, nor desire).  I think there are only 1-2 part names that overlap, so if someone _really_ wants to use the old version alongside the new one, they should also be motivated enough to figure it out and get it working.

The old release will continue to work as long as its plugin is kept up to date, so its not like there is any forced breakage here;  one could choose to simply continue to use the old version until ready to start a new game, then switch to the new one at that time.

[DoubleUU]

I'm finding that the KF tracked wheels have less traction than stock wheels (with adjusted traction) on low gravity bodies, Minmus specifically.  There doesn't seem to be any traction adjustment for KF wheels like there is for stock wheels.  I find that increased traction on stock wheels makes them very grippy and suitable on Minmus.  Is there anything I can do to increase the grip for the KF tracks specifically?  They're not usable on Minmus for me right now.

Edited March 18, 2019 by DoubleUU
Clarifications and corrections.

[Shadowmage]

12 hours ago, DoubleUU said:

There doesn't seem to be any traction adjustment for KF wheels like there is for stock wheels.

Because traction isn't really something you can just 'adjust'; much more of a physically derived parameter than say, spring stiffness.  The values stock uses are ranging in on the 'absurd' end of things; like rolling balls of glue.

But, you can adjust them in at least three different methods.  First, in the in-game settings for KSPWheel there is an option to allow for applying a multiplier to the friction for all wheels.  Second, you can patch specific parts to have different friction curves.  Third, in each part config file, there are some friction multipliers you can adjust (pop open one of the track files and take a look).

If you need specific examples of each, I might be able to dig them up, but it won't be fast.

[damerell]

16 hours ago, DoubleUU said:

I'm finding that the KF tracked wheels have less traction than stock wheels (with adjusted traction) on low gravity bodies, Minmus specifically.  There doesn't seem to be any traction adjustment for KF wheels like there is for stock wheels.  I find that increased traction on stock wheels makes them very grippy and suitable on Minmus.  Is there anything I can do to increase the grip for the KF tracks specifically?  They're not usable on Minmus for me right now.

I think you should be extremely suspicious of any wheel that is grippy on Minmus. In that tiny gravity, it is surely impossible for a wheel to be grippy (short of it being magnetised and the surface of the world being ferrous, or something like that). If a wheel is grippy, it's cheaty.

[Shadowmage]

11 minutes ago, damerell said:

If a wheel is grippy, it's cheaty.

Pretty much.  The max traction for a wheel is determined in majority by the downforce, which on an airless body comes entirely from gravity (or downward momentum... from gravity).  Low gravity = low downforce = low traction.

In a static setup (e.g. not landing after a jump, just sitting still or driving normally), MaxFrictionForce = Downforce * CoefficientOfFriction   where CoefficientOfFriction depends on the tire material and surface qualities, but in the best cases generally peaks at around a ~1.2 muliplier for the stickiest of tires on the roughest of surfaces.   I took that 1.2x scalar and made it the default for all wheel simulations, so in theory, the friction output is already at peak without any further adjustments (assuming the simulation does everything else without error).

 

16 hours ago, DoubleUU said:

Is there anything I can do to increase the grip for the KF tracks specifically?

I should also mention that decreasing the torque output can result in higher apparent traction.  Less slippage due to wheels breaking loose / less spinning of wheels = lower slip ratio = more force transfer between surface and vehicle.

Edited March 18, 2019 by Shadowmage
ration != ratio

[DoubleUU]

@Shadowmage @damerell Thanks for the tips!  Perhaps "grippy" was a poor choice of word.  I wish I could record what is happening because it's comical how little traction I get with a full set of tracks on a 5t vehicle compared to using stock wheels with traction tuned to 3.  It just seemed illogical that a track would be less "grippy" than a round wheel of any type.  I mean, I was spinning nearly out of control at 4m/s with tracks driving on the side of a hill.  Stock wheels on the same vehicle on the same hillside was no problem.  I thought I was just doing something wrong.  Also, I have a bit of an issue with calling something "cheaty" when it's included as part of stock but I get your point.  For me, I'm really not concerned about something being "cheaty" or not since that's a matter of opinion.  I mostly just care if it's working as intended and the traction on these seemed so bad on Minmus I couldn't believe it was working as intended and I assumed I was doing something wrong or missing something.  Clearly I'll just need to use a different strategy going forward.  Thanks again for the replies.

 

[FellipeC]

I'm noticing that when a plane have the ALG, KSP stutters every couple of seconds. Do you are aware of this?

[Shadowmage]

3 hours ago, FellipeC said:

I'm noticing that when a plane have the ALG, KSP stutters every couple of seconds. Do you are aware of this?

Well, you are not the first to report such an issue.  But neither has anyone else who reported been able to provide means of replication.  I've done lots of testing on various pieces and have never hit any out-of-the-normal stuttering when using them.  Likely a difference in hardware/configuration that is causing the problem to be more apparent to some people.  I'm normally very cautious regarding potential stuttering issues;  GC lag has caused me to do some crazy things to fix it in the past.

Do you have a stock + KF only craft file that causes the issue?  Does the problem exist in a stock game with only KF and dependencies installed?

Be glad to fix up any problems, but first I have to know what those problems are.  Which means being able to duplicate the issue, reliably.  So... more info please?

[FellipeC]

6 hours ago, Shadowmage said:

Well, you are not the first to report such an issue.  But neither has anyone else who reported been able to provide means of replication.  I've done lots of testing on various pieces and have never hit any out-of-the-normal stuttering when using them.  Likely a difference in hardware/configuration that is causing the problem to be more apparent to some people.  I'm normally very cautious regarding potential stuttering issues;  GC lag has caused me to do some crazy things to fix it in the past.

Do you have a stock + KF only craft file that causes the issue?  Does the problem exist in a stock game with only KF and dependencies installed?

Be glad to fix up any problems, but first I have to know what those problems are.  Which means being able to duplicate the issue, reliably.  So... more info please?

Well, I'm glad that you're aware of this, but right now I can't provide a way to replicate it precisely. Later I will try a fresh install so I can isolate better the issue.

[Shadowmage]

15 minutes ago, FellipeC said:

Well, I'm glad that you're aware of this, but right now I can't provide a way to replicate it precisely. Later I will try a fresh install so I can isolate better the issue.

Understood.  Any information you can provide is appreciated -- really would like to get this issue fixed up, if I can ever figure out what is causing it (and why I'm so far unable to replicate it).

Most likely it is some difference in what is being tested (craft design or use-cases), or a hardware related difference.  My dev computer is decently powerful, so it might be that I'm just not seeing the stalls that impact others, or if I am encountering them that they are simply below threshold of perception.

[FellipeC]

1 hour ago, Shadowmage said:

Understood.  Any information you can provide is appreciated -- really would like to get this issue fixed up, if I can ever figure out what is causing it (and why I'm so far unable to replicate it).

Most likely it is some difference in what is being tested (craft design or use-cases), or a hardware related difference.  My dev computer is decently powerful, so it might be that I'm just not seeing the stalls that impact others, or if I am encountering them that they are simply below threshold of perception.

Nice. I just can't tell you how to replicate because my install have several mods and I didn't have a 100% sure way to make it stutter. The only common thing I could find with the stuttering in my KSP install is that it happens when the craft has the adjustable landing gears.  During weekend I'll have time to do a clean install and try adding one mod at time.

BTW I notice there is an update of KSP Wheel, I'll try installing it too.

Did a quick and dirt test: Fresh Install of KSP, Plus Foundries 2.2.6. Open the stock Ravenspear Mk4, changed the landing gears for the ALG and took off. Almost can't notice the stutter, but it's there.

I guess that because my main install have more mods, there are more things to process so it became more noticiable.

Edited March 19, 2019 by FellipeC

[lo-fi]

On 3/14/2019 at 11:57 PM, Shadowmage said:

Just thought I'd pop in and see how it's all going. Love the repulsor effects! New tyres looks great too.

[Stone Blue]

On 3/22/2019 at 8:44 AM, lo-fi said:

Just thought I'd pop in and see how it's all going. Love the repulsor effects! New tyres looks great too.

Dang!... I have no moar "likes" for today...

Nice to hear from you, @lo-fi

Hope all is well with you.

[lo-fi]

I'm great thank you, busy building real stuff with wheels! I'm about to lead a team to restore a steam locomotive, which should keep me busy for the next five years or so.

Love seeing the mod still going with Shadowmage at the helm, and long may it continue. Seems half a lifetime away since I was burning hours making models and bashing code...

[V8jester]

1 hour ago, lo-fi said:

I'm great thank you, busy building real stuff with wheels! I'm about to lead a team to restore a steam locomotive, which should keep me busy for the next five years or so.

Love seeing the mod still going with Shadowmage at the helm, and long may it continue. Seems half a lifetime away since I was burning hours making models and bashing code...

Well, guys like me are very greatfull for your guidance and patience 

You were an irreplaceable part of Kebal history my friend!

[Shadowmage]

Have been a bit quiet of late, because, surprise...  life (meaning work) decided to get a bit crazy again.  Still in the process of reworking the part balance, not really much done since the last update.  Once I can get back on track, should hopefully only take a few hours to update the part configs, and will likely take longer to do the testing and refinement after the initial changes are put in place.  Really hoping to be able to take a few hours this weekend to finish this stage up, but can't promise anything.  Will try at least to get the configs updated and a new testing release packaged so that some external testing might be done on the updated config balance.

The next step after the rebalance pass will be baking and conversion of the legacy texture sets, and determining the final packaging configuration.  I currently intend on offering three different texture packs -- 'standard PBR', 'high-res PBR', and 'legacy', but am unsure on how to publish these in a manner that will be easy to install for users, easy to update for users, and not a complete pain to package on the development side.  The real question in this comes down to -- should the 'standard' and 'legacy' packs be treated as entirely separate packages, or should the 'legacy' pack require that the 'standard' pack be first installed?  Whatever is decided upon, it must also accommodate the potential for additional texture sets to be added in the future in an 'expansion pack' sort of format.

I'm leaning towards the following folder format, but may still change it up a bit before finished --

KerbalFoundries/Parts  //all part config files
KerbalFoundries/Models  //part model (.mu) fies
KerbalFoundries/XXXXX  //other existing subfolders for effects/etc
KerbalFoundries/LegacyTextures  // when installed, legacy textures and their texture-set config files would reside here
KerbalFoundries/StandardTextures // when installed, standard res PBR textures and configs would reside here;  the high-res pack will overwrite these file-names; or could optionally be its own folder
KerbalFoundries/ExtraTextureSet1 // additional texture sets would be subfolders, and would each contain their texture files and config files

This will allow for each 'texture set' pack to be installed separately.  Specific packages could be made for each of the 'standard' and 'legacy' packs that contain only those textures, so the user can choose to install either PBR or legacy textures.  Any additional texture sets could then be easily added/merged into the existing KerbalFoundries root folder, allowing for expansion texture sets to be self contained in their own folder, easing the installation and maintenance of those packs.

[MrFancyPL]

@Shadowmage Hello, I have problem with any wheel or track in this mod (test release 1.6.1). When I am giving power to the wheels (pressing w),  the rover or other vechicle always is turning automatically. I have noticed that I have diffrence in rpm between right and left wheel, and I can't do anything about it. If you want any additional files or screenshots just send me message or reply.

[Shadowmage]

19 hours ago, MrFancyPL said:

@Shadowmage Hello, I have problem with any wheel or track in this mod (test release 1.6.1). When I am giving power to the wheels (pressing w),  the rover or other vechicle always is turning automatically. I have noticed that I have diffrence in rpm between right and left wheel, and I can't do anything about it. If you want any additional files or screenshots just send me message or reply.

Did you place the wheels using the mirror-symmetry tool in the editor?  If not, you will need to right click on the wheels on one side of the vehicle and reverse their motor.

Either way -- that is the solution -- reverse the motors on the wheels on one side.  Which side will depend on craft orientation/control transform orientation.

[MrFancyPL]

22 hours ago, Shadowmage said:

Did you place the wheels using the mirror-symmetry tool in the editor?  If not, you will need to right click on the wheels on one side of the vehicle and reverse their motor.

Either way -- that is the solution -- reverse the motors on the wheels on one side.  Which side will depend on craft orientation/control transform orientation.

Yes, one side was reversed. Here are photos showing that behavior, becasue i don't have recording software. This turning is not instant, it happens 1-2 seconds after pressing w, and disappears when rover is going fast enough.

Spoiler

 

[flart]

On 3/18/2019 at 8:22 PM, Shadowmage said:

Darker icons are being caused in part by a change to lighting model.  It is to be expected with a more realistic lighting setup.  Might be fixable, if I cared... which I don't.  I thought the stock icons looked terribly washed out and overbright to begin with.

I also was wondering... in the OP it would be helpful

[Shadowmage]

20 hours ago, MrFancyPL said:

This turning is not instant, it happens 1-2 seconds after pressing w, and disappears when rover is going fast enough.

Ahh, that is a PhysX quirk that I haven't been able to work around yet (or likely, ever).  Basically it gives some sort of a bias to torque output based on direction / order-of-updating, which then gets compounded because the 'faster' wheel starts to slip, then spin faster, slip more, spin faster, slip more, etc.  ( https://github.com/shadowmage45/KSPWheel/issues/9 )

Thinking on it -- kind of realistic given the insane power output of the wheels in the mod.  Like stomping the gas pedal in an old RWD muscle car -- the rear end just wants to go first     If you reduce/lower the motor output such that your slip ratio is minimized during accelaration the effect should go away (or become much less noticeable).