[Plugin/Parts] Kerbal Foundries - Continuation [Latest: 1.9g]

[damerell]

19 hours ago, *Aqua* said:

Yep, I also saw a lot of optimization potential. For example if doesn't need to poll for all KFModuleWheels each physics frame. It's sufficient to do it once when loading the vessel and later again when the vessel changes (docking, lithobraking, etc.). But I don't believe the accelerated processing will be noticable. The code will look more streamlined though.

One idea I had when looking into the KF plugin was to add an explicit on-off switch to all KF parts. This would be particularly useful with the screws, which churn away quite unpredictably, even when their torque setting is zero. However, it would also mean that a lifter carrying a rover wouldn't have this issue - a lifter's mass unavoidably changes every frame but if all the wheels were shut down they wouldn't care.

The check could also be not for a tenth of a unit but for (say) a 1% chance in vessel mass since the recalculation was last done.

[xEvilReeperx]

1.0.5 introduced Vessel.totalMass so the mass calculations are redundant anyway. This is probably just some legacy code from before that's gone unnoticed

[damerell]

13 minutes ago, xEvilReeperx said:

1.0.5 introduced Vessel.totalMass so the mass calculations are redundant anyway. This is probably just some legacy code from before that's gone unnoticed

KF uses Vessel.GetTotalMass(), it's not adding up the mass of every part on the vessel itself.

[xEvilReeperx]

Guess what Vessel.GetTotalMass() does? ;|

[damerell]

On 12/03/2016 at 8:52 PM, damerell said:

One is that MoleTracks.mu seems to reference "RoadWhee2". I wonder if this explains why one Mole Track wheel always droops into the landscape.

It doesn't, although it does explain why one Mole Track wheel doesn't rotate in sync with the others.

I don't yet have an explanation for "rover's droop": I didn't take many external shots but this image shows it, with the forward wheel in each set dipping into the landscape. (On the other side the rear wheel droops because the tracks were added as subassemblies not by mirror symmetry). Unfortunately it only seems to occur after long periods of roving, making it hard to reproduce.

[lo-fi]

Ah, got you. Trouble is, if you maintain a list and a wheel gets ripped off, you'll end up with a nullref. I remember battling with a good way to do this... I hope there's a better way.

[*Aqua*]

There are events for exploding parts, docking, etc. we can hook. I don't know if they work reliable enough but I believe we should investigate that.

[lo-fi]

Apologies, I missed other replies earlier... new forum takes some getting used to.

I thought about using the hooks myself, but I've no doubt there are edge cases that they don't cover, and that's the kind of stuff that keeps you awake at night :/ I'd hope that continued enlightened discussion may find a better solution, though and, of course, this may all change with the dreaded...

The mole track likely has something mis labeled in the .mu - I was probably lazy enough to fix in the config rather than the prefab. Wheel droop likely a collider layer error.

[damerell]

17 hours ago, lo-fi said:

The mole track likely has something mis labeled in the .mu - I was probably lazy enough to fix in the config rather than the prefab. Wheel droop likely a collider layer error.

It does have something mislabelled - obvious from reading the plaintext strings in the .mu, but I used taniwha's tool to import it to Blender to make sure.

[SpannerMonkey(smce)]

17 hours ago, lo-fi said:

Stuff

Hey, you just can't stay away lols. (how's the train?)

Anyway is there any chance i could get a look at this stuff, very interested in getting to grips with the tracks, something i neglected last time around. Quite happy to beat it with a stick until it works correctly, plus I really need some custom tracks desperate like, as all the native models don't quite fit my projects, and making my own has always been my preferred option

Spoiler

 

[lo-fi]

Hehe. Doing what I can to hand over, you know?

Train is great thanks, will be running again in a few weeks after boiler ten-yearly overhaul and light mechanical exam. A joy to work on that project. Catch up with latest progress here: https://www.facebook.com/GWR-Hawksworth-Large-Pannier-Tank-9466-202746429748847/?fref=ts

Have you seen my track tutorial here? That ought to get your started, but you're welcome to anything else you need - just shout

[V8jester]

39 minutes ago, SpannerMonkey(smce) said:

stuff

Ooo! I see that solid axle in the background, there's no hiding that one my friend

[damerell]

11 hours ago, lo-fi said:

Train is great thanks, will be running again in a few weeks after boiler ten-yearly overhaul and light mechanical exam. A joy to work on that project. Catch up with latest progress here: https://www.facebook.com/GWR-Hawksworth-Large-Pannier-Tank-9466-202746429748847/?fref=ts

GWR stands for Gresley Was Right, as I recall? :-)

[lo-fi]

Or Green, Wet and Rusty

 

[lo-fi]

Have there been any substantial changes since the last release? Gaalidas made a load of OCD formatting changes in the last commit before a few people took a fork by the looks of it, so it's hard to see if there's anything substantial?

I just installed all the dev tools and raked the old projects out to have a little play around in an idle moment.

[damerell]

34 minutes ago, lo-fi said:

Have there been any substantial changes since the last release? Gaalidas made a load of OCD formatting changes in the last commit before a few people took a fork by the looks of it, so it's hard to see if there's anything substantial?

I have hardly been looking closely but I haven't been aware of any very substantial changes.

I'm one of the forkers; I intend to look first at the issue of power consumption. I hope that's likely to be of some use.

[lo-fi]

Great! And thanks, that's handy to know. I think I remember you mentioning that earlier in the thread. Yes, the power consumption is a rather simple model currently, built to sort of mimic the big draw of acceleration, but it fails to take rising rolling friction at speed into account, which I think was the thrust of your argument. Shout if I can clarify anything. IIRC, in the latest version, I included a rolling friction FloatCurve which adds braking to the wheel colliders against which the TorqueCurve works. This may be of some use to your work, so I thought worth mentioning. Implementing a decent friction model might be a better way to go than otherwise fudging it with correction factors or curves for the power consumption. Power draw, after all, ought to be proportional to torque output against losses.

I'm jut tinkering really, but it's good to keep a hand in on the programming stuff.

[nli2work]

maybe implementing Mecanum wheels in the future? 

[damerell]

5 minutes ago, lo-fi said:

Great! And thanks, that's handy to know. I think I remember you mentioning that earlier in the thread. Yes, the power consumption is a rather simple model currently, built to sort of mimic the big draw of acceleration, but it fails to take rising rolling friction at speed into account, which I think was the thrust of your argument. Shout if I can clarify anything. IIRC, in the latest version, I included a rolling friction FloatCurve which adds braking to the wheel colliders against which the TorqueCurve works. This may be of some use to your work, so I thought worth mentioning. Implementing a decent friction model might be a better way to go than otherwise fudging it with correction factors or curves for the power consumption. Power draw, after all, ought to be proportional to torque output against losses.

Not quite. I saw the rolling resistance term in the recent source, which is a good idea, but fundamentally the issue is that power isn't proportional to torque output against losses. It's proportional to force times distance over time. ("Over time" is not the objection here, we understand when we say "power" we actually calculate energy usage per tick). (Since torque is in Nm and the force is ultimately applied at the rim of the wheel, the distance terms cancel out nicely).

ie, if you're going twice as fast and applying the same amount of shove, you burn twice as much juice. An idealised electric motor shoving as hard as it can but not getting anywhere burns no juice (of course, real electric motors are non-ideal and there are losses internal to the motor that show up as heat).

This may be initially counterintuitive; it's masked in most motors (and KF parts) by the way maximum torque falls at high speeds.

(Which reminds me, I need to look at the torque curves for the KF motors to see what they appear to look like compared to real electric motors).

This would have been an edit but these stoaty new forums won't let me edit posts half the time!

[lo-fi]

3 minutes ago, nli2work said:

maybe implementing Mecanum wheels in the future? 

Actually, it's a shame that never quite worked out. I do know how to do it now, but it's a whole world of maths to figure out :S Good to see you back

2 minutes ago, damerell said:

Not quite. I saw the rolling resistance term in the recent source, which is a good idea, but fundamentally the issue is that power isn't proportional to torque output against losses. It's proportional to force times distance over time. ("Over time" is not the objection here, we understand when we say "power" we actually calculate energy usage per tick). (Since torque is in Nm and the force is ultimately applied at the rim of the wheel, the distance terms cancel out nicely).

ie, if you're going twice as fast and applying the same amount of shove, you burn twice as much juice. An idealised electric motor shoving as hard as it can but not getting anywhere burns no juice (of course, real electric motors are non-ideal and there are losses internal to the motor that show up as heat).

This may be initially counterintuitive; it's masked in most motors (and KF parts) by the way maximum torque falls at high speeds.

Yes, you're right of course. Looking forward to seeing what you come up with.

[nli2work]

9 minutes ago, lo-fi said:

Actually, it's a shame that never quite worked out. I do know how to do it now, but it's a whole world of maths to figure out :S Good to see you back

I imagine so. Yeah it's fun to make stuff for KSP, don't know any other moddable games that's as open this one. I want to make some vehicle stuff like Deserts of Kharak. 

Edited March 23, 2016 by nli2work

[lo-fi]

2 minutes ago, nli2work said:

I imagine so. Yeah it's fun to make stuff for KSP, don't know any other moddable games that's as open this one.

Awesome. Working on something cool?

[damerell]

I fear this may be one from the department of stupid questions, but my understanding is that the .mu files are compiled by Unity and some of the wheel characteristics are already baked in.

If that's so, please, are the corresponding source files available? I'm trying to figure out which bit does what, so to speak, and have the impression I'm missing some of the pieces.

[lo-fi]

 

11 hours ago, damerell said:

I fear this may be one from the department of stupid questions, but my understanding is that the .mu files are compiled by Unity and some of the wheel characteristics are already baked in.

If that's so, please, are the corresponding source files available? I'm trying to figure out which bit does what, so to speak, and have the impression I'm missing some of the pieces.

That will give you all you need. Only sizing, suspension and grip is baked in. I'll have to rake out the source files for you, but I do have them somewhere.

[damerell]

I thought I replied to this, how odd. Anyway, thanks. I vaguely remembered there was a tutorial but hadn't yet found it. I was mainly pondering loadCoefficient and what else we know (eg suspension parameters) about the hypothetical design load for a wheel / track.

No hurry, anyway, I'm AFKerbal for Easter. (And gah these new forums never let me edit my posts.)