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

[Deconda]

20 hours ago, Shadowmage said:

Link -> https://github.com/shadowmage45/KerbalFoundries2/releases/tag/2.0.2.10

Should work for KSP 1.3.0, and is otherwise identical to the 1.3.1 version.

Thank you

[Shadowmage]

I do have the KSPWheel-Stock patch set back to a functional state.  All of the parts (that I've tested) -work-.  Animations function, colliders are positioned appropriately, and things roll (or don't roll) as they should.

This brings it back to the same spot it was before when it was 'almost ready to release' -- balancing.  What should be the max load, speed, and motor-torque for each of the stock parts (where applicable)?  Some of the information I can derive from the stock config files -- mostly the 'max speed' and 'max torque' bits.  The load rating though... is far more difficult to calculate from the stock parameters.

So, I'll likely be posting up sometime this week a basic 'questionnaire' regarding the preferred balance for the stock parts (legs, wheels, landing-gear).  Going to need to get it all figured out before I can release the patch set.  And then still need to figure out -where- to release the patch set (I'm hesitant to include it in KF releases for the inevitable 'why did you adjust/patch/mess with the stock parts' support posts).

[damerell]

2 hours ago, Shadowmage said:

And then still need to figure out -where- to release the patch set (I'm hesitant to include it in KF releases for the inevitable 'why did you adjust/patch/mess with the stock parts' support posts).

Clearly someone who wants stock behaviour wheels over KSPWheel wheels has suffered an unplanned disassembly above the neck, but I see the problem. More seriously I'll try and provide some sensible replies to the coming questionnaire, and thanks awfully for sorting out the stock parts.

[Shadowmage]

12 hours ago, damerell said:

Clearly someone who wants stock behaviour wheels over KSPWheel wheels has suffered an unplanned disassembly above the neck, but I see the problem. More seriously I'll try and provide some sensible replies to the coming questionnaire, and thanks awfully for sorting out the stock parts.

Hehe, I feel much the same way.  While KSPWheel is far from perfect, it is quite good, and very usable.  Actually spent a few hours roving around over the weekend, doing a 'plant-flag-at-every-anomaly' career, and did not see a single error caused by the wheel physics (can't say the same when I've used the stock wheels/legs).  They even climbed (both going up and down..) some rather impressive mountains on the way to a few of the destinations.  EC hungry?  Sure.  But they work very well

However I learned long ago to not touch stock/other mods' parts, especially not as any part of a regular update.  Far too much confusion stems from people not reading the change log before installing the update, and then coming to the forums with fun posts of 'what happened to X'...  (okay, so really not so much fun)

 

Thanks for the offer -- I'll hopefully have something put together in the next day or two.  Likely going to be little more than a table of part-names and boxes for input of load/speed ratings, but need to gather info on how these should be balanced from somewhere.

[kcs123]

Is anywhere beta test version to download ? I just recently started my KSP 1.3.1. career after long time being on hiatus regarding KSP playing.
Might going to try it and give some feedback.

As general rule, what should be apropriate for stock wheels to be able to handle:

• LY-01 and LY-05 unretractable stock wheels - should be able to support crafs up to 10-15 t
• LY-10 small retractable landing gear - for crafts up to 20-25 t - not much more from LY-01, but their advantage is to be retractable to reduce drag
• LY-35 medium retractable landing gear - for crafts up to 45-60 t
• LY-60 large retractable landing gear - for crafts up to 150-200 t
• LY-99 extra large retractable landing gear - for crafts up to 200-300 t

Values are mostly from personal experience/needs trough career with consideration what kind of planes I'm able to create with various SPH/runway levels. I mostly end up with crafts that are heavier than stock wheels are intended to support. More gamebalance needs than that real life counterparts wheels are designed for.

Might be also good to hide/rewrite stock variable values, instead of "Stress tolerance" to use "Load" like the rest of Kerbal foundries wheels. Or vice versa, for your wheels to use "Stress tolerance" instead of "Load". Also measurment unit for it would be good. Currently it is unknown is it tons, kilograms or newton unit used for "Stress tolerance" and "Load". I assume that is load per wheel axle or something, but measurment unit is unknown what it is.

Have yet to inspect config files for wheels, what variables are used in it.

[Nightside]

18 hours ago, Shadowmage said:

I do have the KSPWheel-Stock patch set back to a functional state.  All of the parts (that I've tested) -work-.  Animations function, colliders are positioned appropriately, and things roll (or don't roll) as they should.

This brings it back to the same spot it was before when it was 'almost ready to release' -- balancing.  What should be the max load, speed, and motor-torque for each of the stock parts (where applicable)?  Some of the information I can derive from the stock config files -- mostly the 'max speed' and 'max torque' bits.  The load rating though... is far more difficult to calculate from the stock parameters.

So, I'll likely be posting up sometime this week a basic 'questionnaire' regarding the preferred balance for the stock parts (legs, wheels, landing-gear).  Going to need to get it all figured out before I can release the patch set.  And then still need to figure out -where- to release the patch set (I'm hesitant to include it in KF releases for the inevitable 'why did you adjust/patch/mess with the stock parts' support posts).

Re: Balancing - For the load rating, I would err on the side of OP. Stock parts are heavy, the ground is weird, things tend to jump and fall so it would be nice if these were strong enough to withstand some the quirks of the game universe (Sorry for not providing any numbers to work with, just my opinion.)

Re: Patch - I guess my preference would be a config file to be included but in a disabled state, but that is from the perspective someone who (perhaps too) comfortable altering config files.

A second option might be more like Real Plumes - Stockalike configs, separate from the actual plugin. The advantage of this would be that the patch set could evolve from just the stock parts to also patch legs and wheels from other mods.

 

Also, what is required to write these patches, is it just configs or do you need to get into the models?

[Shadowmage]

5 minutes ago, Nightside said:

A second option might be more like Real Plumes - Stockalike configs, separate from the actual plugin. The advantage of this would be that the patch set could evolve from just the stock parts to also patch legs and wheels from other mods

Yeah, seems like the best way to do it -- an optional sidelined mod that the user can download/install if and when they desire.  My problem with that is still -- where to host and distribute it?

 

6 minutes ago, Nightside said:

Also, what is required to write these patches, is it just configs or do you need to get into the models?

Yes.  To both.  It is just configs (can do it with MM patches), but you need to know how the model is setup in regards to transform hierarchy, orientations, positions, scales... pretty much you need access to the model from within Blender.

Unless the existing configs were setup properly and the model was built in a sane fashion, in which case you can use most of the data from the existing stock wheel modules, and it should 'just work'.... but most wheel models are not built properly from the KSPWheel perspective;  you can still get them working, but it is a ton more work to setup the configs, and you might need to dig into the model to check transform orientation and positions. 

For example, converting the KF parts was simple -- the models were already built 'properly', so no real hacks were needed.  The stock parts though -- I had to open every single one of those models in Blender to examine transform orientations, calculate offsets for incorrectly positioned transforms, and do a ton of work to correct for the fact that stock models are built with inconsistent transform scaling (bad... very bad... someone needed to learn to model things....).

--- basically, if the wheel model was built for the old U4 wheel collider system, you should have no problem plugging in some config values and driving away.  If it was built for the new U5 wheel colliders and stock wheel system.... you -might- need to do a bunch of extra work to fix the crazy setup that those parts/modules use (it is very inconsistent, even on the stock parts; some of them you can just plug in the values... others you have to offset nearly every transform/value to compensate for inconsistent scales/etc).

[Shadowmage]

4 hours ago, kcs123 said:

Is anywhere beta test version to download ? I just recently started my KSP 1.3.1. career after long time being on hiatus regarding KSP playing.

Possibly sometime this weekend -- need to figure out the initial balance stuff first.

4 hours ago, kcs123 said:

Values are mostly from personal experience/needs trough career with consideration what kind of planes I'm able to create with various SPH/runway levels.

I honestly see those values as being far too high.  The smallest gear should maybe support 8t, and even that I think is probably more than it should.  Probably closer to 5t.

But this is why I'm asking -- my craft designs are generally conservative.  I think my early career aircraft are maybe 5-8t fully fueled -- so from my personal perspective, the smallest gear should only need to support ~4-5t each.

(also, keep in mind that these wheels/legs/etc will also now support scaling -- so if you need it to support more load than the default, simply make it bigger -- as such, the load ratings do not need to account for over-built designs; those kind of designs should scale up their gear to support the larger load)

4 hours ago, kcs123 said:

Might be also good to hide/rewrite stock variable values, instead of "Stress tolerance" to use "Load" like the rest of Kerbal foundries wheels. Or vice versa, for your wheels to use "Stress tolerance" instead of "Load".

They will use the KSPWheel PartModules, the same as all the rest of parts in KF -- so they will have the same GUI labels and functions as the rest of the KF wheels/legs/etc.  (not going to be changing UI labels just for this patch... or at all)

4 hours ago, kcs123 said:

Also measurment unit for it would be good. Currently it is unknown is it tons, kilograms or newton unit used for "Stress tolerance" and "Load".

Currently the active load is displayed as 'percentage of max-load currently supported'.  Kind of necessary due to the built-in scaling support on the parts.  Internally it is all calculated as newtons.  So the current displayed measurement unit for current load-rating is '% of max load'.

The max-load as listed in the right-click menu is specified in tons of mass @ Kerbin standard gravity, as I figured that would be easier for most people to grasp.  Imagine if it just listed 'max load = 1220kN' -- wouldn't be very useful when designing craft in the editor for most people (though if you know the surface gravity of the target world, it is actually fewer calculations for non-Kerbin destinations).

[kcs123]

21 minutes ago, Shadowmage said:

The max-load as listed in the right-click menu is specified in tons of mass @ Kerbin standard gravity, as I figured that would be easier for most people to grasp.

Agree. I speculated that value on right click menu in SPH/VAB for load might be in tons, but wasn't sure. Having measure unit displayed in right click info menu would be nice. Not absolutely necessary for beta testing, but something to consider when time comes to polish out everything for final release. Percentage of max load for current active load is reasonable choice, it provide good feedback when you try to troubleshoot what went wrong with craft and why those wheels keeps falling apart. Thanks for clarification.

I agree that values from previous post are higher than it is designed for stock game or for weight of some real life craft if you aim for realistic behaviour. However, in career game you are limited with part numbers, especialy early in career. While I'm able to build lightweight aircraft, some more weight is still necessary when you build something that need to carry some science equipment or extra fuel to reach other half of planet.

In sandbox game there is not much issue because if one set of wheels are not enough you can easy add one extra pair to distribute weight over more wheels. In career game, when comes to planes, LY-01 and YL-05 are usualy avoided until better wheels become available, it just don't feel right from gamebalance / progress perspective. 5-8 t is good enough for craft on grounds, but due to mentioned limitations, what kind of parts you have unlocked number and size limits in SPH/runway it is not always possible to create craft capable for gentle touchdowns, therefore come suggestion for increased weight limits.

Mid to late game playtrough it is much less of issue, you are usualy rich enough, have unlocked better parts and bought Lvl 2 or 3 buildings for SPH/VAB and runway/launchpad, whatever someone prefere more.

[vossiewulf]

Mage, as I think I mentioned some time back that I think the best approach is to ignore the parts for the moment and create a "wheel scale" with an arbitrary number of buckets, set the values for the maximum bucket's loads and let the rest fall out from a logarithmic (or linear if you want simple) scale. Then map the parts, adjusting overall mesh size as necessary, against the buckets, and maybe have multiple sizes of parts - for max flexibility you could have (purely based on size) light/medium/heavy versions of each wheel part, with values appropriate for the range covered by the intended bucket for each size. This way you have multiple options for each load rating (bucket) with some flexibility to (E.G.) make these wheels slightly faster but with a slightly lower load rating than those wheels, but have the "Medium Duty" version for both still falling within the valid range for the Medium Duty bucket.

Edited December 6, 2017 by vossiewulf

[Shadowmage]

Sorry for the delay, this week has kept me a bit busier at work than I had anticipated, which unfortunately spills over into my modding time....

Stock patches pre-release version:

https://github.com/shadowmage45/KerbalFoundries2/releases/tag/Stock-1.0.0.0-pre

Figured it might be easier to get feedback on it, if at least something usable was available.

Max speed, motor-rpm, torque, brakes, and steering can all be derived from the stock modules to some extent.  It is really only the load-rating that I'm needing assistance/input on -- the stock config values are... strange.  Very strange.

So, to anyone interested in helping improve the balance of those parts, if you wouldn't mind noting down the vehicle mass and wheel configurations of a few of your craft that use the stock wheels, it would go a long ways in determining how they should be balanced.  I'll be taking a look over the stock craft files that use the wheels to see what kind of configurations/loadings exist there, but that is only a small selection.

Posted info doesn't need to be anything complex -- wheel name/part name, and approximate load from the craft should be enough (craft mass divided by number of wheels).  Multiple data points from different craft using the same wheels is also beneficial.

Thanks in advance

 

@vossiewulf I do have some concepts about how to add some 'light/standard/strong' variant selection to the parts (in addition to the existing scaling); but it will still be based on individual/specific part balance, applying multipliers/adjustments to mass/speed/load rating based on the current variant selected -- even the 'strong' version of a fragile-looking part would still have lower load rating than a visually stronger looking part.  Still just a concept though; nowhere close to being ready to start working on the feature.

[kcs123]

After installing stock patches, previously "good" plane made with stock LY-10 wheels started drifting while just standing still on runway.

4t weight aircraft with 3 x LY-10 wheels. Just launched craft on runway and turned brakes ON without SAS or anything else. I probably would not even notice this if I didn't started to mess around with kOS scripts to create GUI. Script didn't touched craft controls yet, neither stock SAS could influence anything. I will try to provide some screenshots if there is need for it later on.

[Drew Kerman]

6 hours ago, kcs123 said:

After installing stock patches, previously "good" plane made with stock LY-10 wheels started drifting while just standing still on runway.

would you also have to remove and re-add the wheels in the VAB/SPH after installing the stock patches?

Edited December 9, 2017 by Drew Kerman

[Shadowmage]

7 hours ago, kcs123 said:

After installing stock patches, previously "good" plane made with stock LY-10 wheels started drifting while just standing still on runway.

4t weight aircraft with 3 x LY-10 wheels. Just launched craft on runway and turned brakes ON without SAS or anything else. I probably would not even notice this if I didn't started to mess around with kOS scripts to create GUI. Script didn't touched craft controls yet, neither stock SAS could influence anything. I will try to provide some screenshots if there is need for it later on.

Usually this is caused by a combination of craft design, physics integration limits, and the limitations of the Unity joints.  Screenshots would likely help with diagnosing the problem a bit, or if it is an otherwise stock craft file (only stock parts + KF), that would be the best way.  It doesn't seem to pop up often, but I've definitely seen a few designs that push the limitations of the physics and joints. 

The generic solutions are to enable auto struts on the wheels (there is a reason they are force-enabled on stock wheels), adjust the spring/damper settings, or parent the wheels to different parts and re-position using the offset tool.

 

54 minutes ago, Drew Kerman said:

would you also have to remove and re-add the wheels in the VAB/SPH after installing the stock patches?

Shouldn't be necessary in most cases.  The converted wheels on existing craft will reset to the 'deployed' state on deployable parts, but they should otherwise load fine.  At least they have on all of the stock craft files that I've tested out.

[kcs123]

After some more testing it seems to be random occasion. However, I noticed strange things with wheel coliders. When driffting occur, wheels are slightly above ground, barely noticable, only few pixels.

On other occasions when drifting is not happened, wheels touching ground or they were sligtly "sinked" into terrain, just few pixels, also barely noticable.
I can only tell difference by shadow on craft/wheels.

I will try to figure out reliable reproducing steps and some screenshots. It is not easy to figure out true reason behind it when things happens on random occasions.

[Shadowmage]

11 minutes ago, kcs123 said:

After some more testing it seems to be random occasion. However, I noticed strange things with wheel coliders. When driffting occur, wheels are slightly above ground, barely noticable, only few pixels.

On other occasions when drifting is not happened, wheels touching ground or they were sligtly "sinked" into terrain, just few pixels, also barely noticable.
I can only tell difference by shadow on craft/wheels.

I will try to figure out reliable reproducing steps and some screenshots. It is not easy to figure out true reason behind it when things happens on random occasions.

What you are seeing there happens with the stock wheels (and any part really) as well.  From what I can tell It is caused by by the colliders on the terrain/structures being slightly out of sync with the visual mesh, but I'm not sure of the cause of it.  It does seem to change between launches, so may well be related to the floating origin/frame of reference changes.

If you do happen to find a reliable cause, please let me know and I can investigate further.  If the drifting/jitterring is related to the terrain colliders being offset, there might be some corrections/workarounds that I can put in place.

[kcs123]

It is quite possible that it might be stock bug, I didn't played much with stock game to be able to notice and confirm.
Here is link to picture galery that describe issue.

Album a/Nd3h0 will appear when post is submitted

Don't know if album will apear properly, here is first picture from album:

 

I reproduced problem, to get some screenshots, but can't tell reliable reproducing steps yet.

EDIT:

It is a bit of ugly plane, but I don't have much parts unlocked and design payed off itself for scientist contract and tourist high G tour.

Edited December 9, 2017 by kcs123

[0111narwhalz]

Note that damping and strength settings are super important whenever you see jittering or drifting. Small adjustments to the settings can go a long way to improving stability. If your damping is too high, you run a risk of oscillations because of excessive correction. If it's too low, the natural oscillations won't damp out quickly and may reinforce. If strength is too high, it'll behave like excessive damping. Also, you should be well away from the boundrary regions of full extension and compression during normal use; the model starts to break down at extremes of travel.
I've had jitter issues that were solved by a little careful tweaking. Yours might not be the same issue as mine, but I feel it's worth a shot.

[kcs123]

I added few more screenshots in same album with opened right click menu on wheels in SPH and same to show stress level on take off.
Front wheel have default spring/dumper settings while rear wheels have only slightly higher spring settings from default value. Aircraft seems to behave properly once started to move in desired direction on take off and landing, strange drift happens only when standing still on runway.

I will try to use lower springs to see if that would make any difference. Have yet to try with heavier plane, this one is lightweight as possible for required contracts. With heavier engine and fuel tank I would probably end up much closer to 15t aircraft. That's 5t of load per wheel, but rear wheels in 3 cycle combination always take more load than front wheel, so 8t to 10t of load for LY-10 is reasonable, especialy when you are not able to create aircraft for very gentle touchdowns.

 

 

 

[Robos78]

On 24/11/2017 at 4:41 PM, Robos78 said:

So, it's the leg with the extra length on the side. That help?

 

On 21/11/2017 at 4:06 PM, Shadowmage said:

Longer?  Seriously?

Those legs are already too long for me to actually use them effectively on any of my craft designs.  And you want them to be longer still?  I gotta see some pics of this craft...

Just want to show you this, I don't think you saw it.

[Shadowmage]

On 12/10/2017 at 8:49 AM, Robos78 said:

 

Just want to show you this, I don't think you saw it.

I saw it, but I'm still awaiting screenshots as to what kind of craft you are designing where you need longer legs, as well as what specific part you are looking for.  You've given neither screenshots, nor part-names, or model paths, or anything that could be used to uniquely identify the part.

[Jimbodiah]

Isn't that what the scaling option is for?

[AccidentalDisassembly]

In case it's interesting for anyone else, here's a little tech tree patch I made (for CTT) that moves the KF wheels and a couple of the stock wheels around to better suit my personal tastes. I thought it was odd that KF wheels all show up at the same time, mainly, and also just wanted a couple wheels earlier in the tech tree.

• Moves the truck wheels, the squad Munar Rover wheel, and the small wheel earlier to Advanced Exploration
• Moves the KF Tiny wheels to Space Exploration (they're kind of similar to the smallest stock wheel, so thought they should go together)
• Moves the hydraulic legs all to Heavy Landing (just seems more logical, I guess)
• Moves the TR-2L squad wheel to Field Science
• Moves the skid to Landing (since it seems to be the most basic landing part you could make)

@PART[roverWheel1|KF_WheelSmall|KF-WheelTruck-Single|KF-WheelTruck-Dual]:NEEDS[CommunityTechTree]:FINAL
{
	@TechRequired = advExploration
}
@PART[KF_WheelTiny]:NEEDS[CommunityTechTree]:FINAL
{
	@TechRequired = spaceExploration
}
@PART[KF-LegLarge|KF-LegSimple|KF-LegTruck]:NEEDS[CommunityTechTree]:FINAL
{
	@TechRequired = heavyLanding
}
@PART[wheelMed]:NEEDS[CommunityTechTree]:FINAL
{
	@TechRequired = fieldScience
}
@PART[KF_Skid]:NEEDS[CommunityTechTree]:FINAL
{
	@TechRequired = landing
}

 

[AccidentalDisassembly]

Also, had a question about wheel behavior. With stock wheels, when you place a bunch along the sides of a long rover, so long as you have your control point (a cockpit or whatever) oriented correctly, the wheels are automagically set up to turn in the opposite opposite of the wheels in back when you hit A or D. But with KF wheels placed in symmetry, they seem to be doing this instead, which prevents the rover from actually turning:

https://imgur.com/J0QjxEg

Is that normal behavior, or have I done something screwy? The nav ball is oriented correctly, so far as I can tell (which has an effect on stock wheel behavior at least). 1.3.1, latest version of Kerbal Foundries.

Edited December 18, 2017 by AccidentalDisassembly

[0111narwhalz]

1 minute ago, AccidentalDisassembly said:

Also, had a question about wheel behavior. With stock wheels, when you place a bunch along the sides of a long rover, so long as you have your control point (a cockpit or whatever) oriented correctly, the wheels are automagically set up to turn in the opposite opposite of the wheels in back when you hit A or D. But with KF wheels placed in symmetry, they seem to be doing this instead, which prevents the rover from actually turning:

https://imgur.com/J0QjxEg

Is that normal behavior, or have I done something screwy? The nav ball is oriented correctly, so far as I can tell (which has an effect on stock wheel behavior at least). 1.3.1, latest version of Kerbal Foundries.

You may need to adjust them manually. Steering inversion is not a symmetry-propogated option (for obvious reasons) so you can fix this. AFAIK, there's not a lot of autoconfiguration that happens at the moment, so you'll just have to check things like this.