[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[Gaalidas]

It seems to me that a little generator that isn't producing any noticeable thrust (unless you strap on 30 billion of them, then you might be able to see a few numbers changing somewhere) wouldn't produce much noise at all. Might just need a little tweak to the noise settings. If you're running a ton of them, however, I could see that realistically making a bit of noise.

[lo-fi]

Thanks Gaalidas, that's brilliant. Good point about scaling small wheels down, they do not work well below a certain size. Maybe define three KF modules, one for small stuff that only scales up, one for mid size that hues either way etc.?

Speaking of the noise that little generator makes, I tried running eight of them to power that repulsor field thing - that was LOUD! Louder than a gaggle of boosters at lift-off when they all revved up to full power. I noticed in BD Armory he's got some code that reduces the noise of explosions when there's more than one, just thought I'd mention that, you know, encase you've got a few minutes with nothing to do or something

Chance would be a fine thing good idea, though, I'll poke about in the BDA code and see what I can find.

It seems to me that a little generator that isn't producing any noticeable thrust (unless you strap on 30 billion of them, then you might be able to see a few numbers changing somewhere) wouldn't produce much noise at all. Might just need a little tweak to the noise settings. If you're running a ton of them, however, I could see that realistically making a bit of noise.

I'll see if I can find a better noise, it's just running the stock jet sound at the moment (which is annoying). There's a better model knocking about too, I'll try and take it out.

[Gaalidas]

That would be great, especially if the new model has textures defined for all the surfaces. The current model can't even be fully painted using KerbPaint because the white surfaces aren't textured.

I'll look into some special definitions for extreme sized wheels. I'm thinking those huge wheels should maybe have one level larger than they have for flexibility with large and heavy crafts, but should have a lot of room to shrink so they can be used with standard sized crafts. I'll create one for smaller wheels as well that gives them a single shrinking value and more room to expand, giving attention to the maximum that they can expand before their visual appearance becomes distorted (texture wise that is.)

I'm also thinking maybe the free scaling method should be looked at again. I remembered yesterday that even if you use a free-scale, you can define a maximum and minimum value that can be used and, while I was experimenting a while back with your original implementation, I discovered that recent updates to TS included two sets of buttons beside the scale slider, one for small increments and one for large increments. This makes it a lot easier to get the same scale value for multiple independently scaled parts, where in the old system you could easily get stuck with a slight difference and no way to sync it up due to the limitations of the step-size and the bar size. There simple wasn't enough pixels to make the selection specific enough.

I'll mess around and update stuff when I get a chance. This github thing is making it a lot easier to contribute to this project.

And... I can give a bit more time to it now that school is out for the holidays.

EDIT: Okay, so I haven't heard back from the TweakScale people yet, so I went ahead and added the definition for that "tweakScaleCorrector" variable in the part modules and did some testing. I discovered something a bit messed up. First of all, those long tracks do not respond very well when being manipulated in the scale. I am unsure if they were working right anyway before we implemented TS but, at full suspension, the "wheels" parts were below the ground and the track was stretched down with it. The ride-height seemed to be stuck at one level while the suspension dropped to the floor (or below the floor as it seems). Upon testing the medium tracks (up-scaled to the maximum value I altered them to be able to reach) they seemed to be okay, except for a small problem with the bottom of the track clipping with the ground when the craft was stationary. However, upon trying to move around a bunch, I noticed that I was turning to the right constantly. Furthermore, the context entry in flight labeled "TS" which I just code dived to find out corresponds with the current "tweakScaleCorrector" value on that part was not the same for both, equally scaled, tracks. When the imbalance finally turned me on my back, it appeared that the tracks were compensating for the different in their corrector values but in reality one of them was trying to suspend about twice the distance than the other one.

I don't know what this means yet, but I suspect it might have something to do with multiple instances of the same module in a part being manipulated by TweakScale's exponent system. My theory is that when it scans for the appropriate modules it finds all instances of that module, but when applying the exponent it isn't resetting its base value back to the defined value for each instance of the same module, thus causing the value to continue to be exponentially altered. As far as your plugin is concerned, the latest value is going to be used for all the calculations despite the different values for the different modules in the same part, so they all end up with super high "tweakScaleCorrector" values upon launching. Doing some work on a calculator has revealed that it is quite plausible that this is what is happening. Every time it moves on to the next instance of the module, it already thinks that the new exponent is equal to the new scale, so it applies that new exponent to the current base, then again, and then again. For that long track, with all of it's "wheels" that all get an exponent applied to them, but number that gets reported to your plugin in the end could end up as far as 9.512 (the decimal keeps going in seemingly random directions for a while, I cut it down for legibility) with only 5 wheel modules in the part. Since the plugin is tracking not only the single part with the module, but the other parts on the craft as well so that these things can work together, then that number likely gets added to when TweakScale continues working on the next part that it needs to scale, thus creating that imbalance that I experienced.

At this time, I am unsure how to deal with this. We might have to revert back to designating specific values for the variable to coincide with the scales we choose to implement. That would surely keep it from calculating the wrong values for multiple modules of the same name. Other possibilities would be to create a new module that would have only one responsibility: managing the "tweakScaleCorrector" variable and passing that on to the other modules so that it doesn't compound itself. This options appeals to me just because I've often create entire batch files to be called by my other batch utilities that have only one purpose: to define and manage environment variables. This could allow for each part to have that variable only defined in it once, and thus only manipulated by TweakScale once. You'd just have to figure out how to update the rest of the modules that use that variable when they need it.

Anyway, my brain is cooked now so I'll leave you with that for the moment until I get my second wind, so to speak.

EDIT AGAIN:

Okay, so I did some more research by code diving into the TweakScale source. It seems that if I prefix the variable name with a "!" symbol it will cause the exponent to be calculated based on the default size for the part, and not on the current size. This makes a lot more sense, but it also isn't working quite right still. I got it to stop shooting "tweakScaleCorrector" to abnormal heights, which is great. But, I'm still getting mismatched values. I first launched a rover with two medium tracks up-scaled to 150%. The correction value was 2.8 on the right side, and 1.9 on the left. It should be 1.5 on both. I then launched the same craft with the tracks at default scale. I would expect that the corrector would be untouched and remain at 1. Instead, the left was at 1.3 and the right was at 1.9. So, it seems that even at the default level, the "tweakScaleCorrector" is being manipulated by something. I don't see how it would be manipulated beyond what I have defined it to be in the exponent definition, and I don't see anywhere in your code that the value gets altered. Your code just uses it to calculate other things. I have verified that I put the correct value into the part configs as well, though so far no response as to whether I need to define them there or not. So, I'm rather irritated and stumped. I'm going to try it with some wheels next. If two parts are getting that much of an offset, imagine what the 6th wheel in a set will be boosted to.

Edited December 11, 2014 by Gaalidas

[AccidentalDisassembly]

Sadly I think Biotronic may have given up on TweakScale for real-life reasons (maybe he'll show up again in a month or two), I'm just trying to make any sense of it because I really want your parts to be tweakscaleable and work right because they're so cool =)

Anyhoo, I obviously don't understand what's going on in your code - but why do you need a TweakScaleCorrector variable in the first place? What does it do?

It seems to me the only real issue with the tracks in the past was that things like the suspension weren't changing with size (because the variable for suspension length, or however it works, wasn't defined in TWEAKSCALEEXPONENTS anywhere, and therefore not addressed by TS at all), but for the most part, when I tweakscale the currently-released tracks, they work. Their torque values are insanely high when scaled up, but they still work - no weird wheels going through the ground kind of stuff.

Or, otherwise stated: what are the actual variables/values used by the MODULE{} at work in the wheels and tracks that need to change with the size of the part, and in what way(s) do they need to change when the part's larger or smaller?

[Gaalidas]

All good questions. I have an update: wheels work pretty well with this system, only one minor oddity. At a scale level of 0.75, "tweakScaleCorrector" = 0.8. Shouldn't it equal 0.75? So that confuses me a bit. But, it seems that the really weird troubles are related to the tracks when it comes to these exponents. I still worry ever so slightly that the ERS level-indicator shows that even with the wheels I am slightly off balance still, but I'm not too worried at this point about that little detail. Unfortunately the wheels and the tracks use the same modules, so we'll have to either sort this out or revert our support for tweakscale until we can get this resolved. One thing I thought of: if "tweakScaleCorrector" could be equalized between all the parts in a wheel-group to the lowest value found similar to how we can modify the suspension and apply it to the group, then it might be possible to overcome this little oddity.

As to the question "why do you need a TweakScaleCorrector variable in the first place?" well, that is a good question indeed. From what i can tell, it reduces the amount of work needed for a plugin like TweakScale to modify all these variables in a consistent way. If tweakscale only has to modify a single variable, and then we implement that variable into a bunch of different equations, we are effectively killing a dozen birds with one stone. (I always thought of that as having a ton of birds in a single nest, and throwing a really freakishly huge stone on top of it, though it does feel a bit like cheating.) Otherwise, TweakScale would need to adjust tons of variables and with the current weird effects we're getting with tracks, tracking down the errors would have been a real pain in the tailpipe. I still question why we need to reduce the workload though, cause in using one variable we limit the tweaking we can do to each equation that uses it. If TweakScale were modifying a bunch of other values separately, we could easily tell it to double something, while tripling another, and using the single exponent on still more, all in one go without modifying the source. It's a tradeoff either way.

Edited December 12, 2014 by Gaalidas

[lo-fi]

Ah, you've reached that "TweakScale. What the deuce?!?! stage. Are you adding the TS stuff in the configs ahead of KF modules? The KF code does a lot of stuff on startup, so if the TS exponent hadn't already been changed by TS, as things are fired sequentially, bad stuff will happen.

Hell of a long day - also a little drunk - so that's about the best I can come up with right now. The long tracks are nothing special, other than having more KFWheel modules (which govern suspension movement) than other models. Push it all to Git though (genius, itsn't it! Thanks, Linus) and I'll see if I can offer any insights over the weekend.

Thanks, as ever!

[AccidentalDisassembly]

All good questions. I have an update: wheels work pretty well with this system, only one minor oddity. At a scale level of 0.75, "tweakScaleCorrector" = 0.8. Shouldn't it equal 0.75? So that confuses me a bit. But, it seems that the really weird troubles are related to the tracks when it comes to these exponents. I still worry ever so slightly that the ERS level-indicator shows that even with the wheels I am slightly off balance still, but I'm not too worried at this point about that little detail. Unfortunately the wheels and the tracks use the same modules, so we'll have to either sort this out or revert our support for tweakscale until we can get this resolved. One thing I thought of: if "tweakScaleCorrector" could be equalized between all the parts in a wheel-group to the lowest value found similar to how we can modify the suspension and apply it to the group, then it might be possible to overcome this little oddity.

As to the question "why do you need a TweakScaleCorrector variable in the first place?" well, that is a good question indeed. From what i can tell, it reduces the amount of work needed for a plugin like TweakScale to modify all these variables in a consistent way. If tweakscale only has to modify a single variable, and then we implement that variable into a bunch of different equations, we are effectively killing a dozen birds with one stone. (I always thought of that as having a ton of birds in a single nest, and throwing a really freakishly huge stone on top of it, though it does feel a bit like cheating.) Otherwise, TweakScale would need to adjust tons of variables and with the current weird effects we're getting with tracks, tracking down the errors would have been a real pain in the tailpipe. I still question why we need to reduce the workload though, cause in using one variable we limit the tweaking we can do to each equation that uses it. If TweakScale were modifying a bunch of other values separately, we could easily tell it to double something, while tripling another, and using the single exponent on still more, all in one go without modifying the source. It's a tradeoff either way.

OK, I think I understand - that makes sense, and if indeed TweakScale is messing up stuff when you have 8 wheel MODULE{} in one part (or whatever), then having it chew on only that one variable might address that, too. I just can't think of a part I've seen that has two identical MODULE{} in it that would provide some kind of test case other than the wheels & tracks here. But maybe I'm not understanding - do you mean that there need to be multiple of the same MODULE{} in a given part to make the wheels/tracks work, or do you mean that the same variable gets mentioned X times in one MODULE{} (and therefore possibly borked by TS)? If it's the latter, I thought TS had a method of dealing with stuff like that so long as the same variable names are somehow nested (like different MaxThrust within a multi-mode engine MODULE{}, maybe?)...

Are you using TS 1.44 to test all this? TS 1.47 produces some "creative" numbers when you scale stuff, just in case that's the version you're using.

[Gaalidas]

Really? That's the first I've heard of any issues with the latest tweakscale versions. I have yet to have any problems with it until now, but I'm also a lot more conservative with my scaling. Well, that's interesting. might have to try and find a previous release to try out. I'm just a bit curious why anyone would go back three versions? If 1.47 is the problem, I'd think that 1.46 would be the logical step to take.

Also, here's a sample of what a track looks like in the part config:

(just a small sample of where the wheels are defined)
MODULE
{
    name = KFModuleWheel
    tweakScaleCorrector = 1
    raycastError = 0.035
    springRate = 0.8
    damperRate = 0.05
    smoothSpeed = 8
    torqueCurve
    {
      key = 0 50 0 0
      key = 10 75 0 0
      key = 15 100 0 0
      key = 20 125 0 0
      key = 25 95 0 0
      key = 30 15 0 0
    }
    torqueSteeringCurve
    {
      key = 0 85 0 0
      key = 10 42 0 0
      key = 15 20 0 0
      key = 20 0 0 0
    }
    steeringCurve
    {
      key 0 0 0 0
    }
    brakeSteeringCurve
    {
      key = -25 -240 0 0
      key = -10 -120 0 0
      key = 0 0 0 0
      key = 10 120 0 0
      key = 25 240 0 0
    }
    brakingTorque = 70
    rollingResistance = 10
    maxRPM = 600
}
MODULE
{
    name = KFWheel
    tweakScaleCorrector = 1
    wheelName = RoadWheel1
    colliderName = WC1
    sustravName = Link1
    steeringName = Link1
    isIdler = false
    hasSteering = false
    rotationCorrection = 1.5
    smoothSpeed = 40
    wheelRotationX = 0
    wheelRotationY = 0
    wheelRotationZ = 1
    susTravAxis = Y    
}
MODULE
{
    name = KFWheel
    tweakScaleCorrector = 1
    wheelName = RoadWheel2
    colliderName = WC2
    sustravName = Link2
    steeringName = Link2
    isIdler = false
    hasSteering = false
    rotationCorrection = 1.5
    smoothSpeed = 40
    wheelRotationX = 0
    wheelRotationY = 0
    wheelRotationZ = 1
    susTravAxis = Y
}
MODULE
{
    name = KFWheel
    tweakScaleCorrector = 1
    wheelName = RoadWheel3
    colliderName = WC3
    sustravName = Link3
    steeringName = Link3
    isIdler = false
    hasSteering = false
    rotationCorrection = 1.5
    smoothSpeed = 40
    wheelRotationX = 0
    wheelRotationY = 0
    wheelRotationZ = 1
    susTravAxis = Y
}
MODULE
{
    name = KFWheel
    wheelName = SprocketF
    colliderName = wheelColliderSF
    sustravName = LinkF
    steeringName = LinkF
    isIdler = false
    hasSuspension = false
    hasSteering = false
    rotationCorrection = 1.5
    smoothSpeed = 40
    wheelRotationX = 0
    wheelRotationY = 0
    wheelRotationZ = 1
    susTravAxis = Y
}
MODULE
{
    name = KFWheel
    wheelName = SprocketR
    colliderName = wheelColliderSR
    sustravName = LinkR
    steeringName = LinkR
    isIdler = false
    hasSuspension = false
    hasSteering = false
    rotationCorrection = 1.5
    smoothSpeed = 40
    wheelRotationX = 0
    wheelRotationY = 0
    wheelRotationZ = 1
    susTravAxis = Y
}

In that sample I've already removed the corrector definition from a few of those "wheels" that aren't actually being used as "wheels" in that sense, and I've been experimenting with some very detailed torque and steering settings in my personal copy, but overall it's pretty accurate to what is really in a standard track. Most of them actually don't have those "sprocket" wheels.

On the topic of TS having stuff to handle multiple thrust settings and such... I've not heard or seen anything like that, but it does remind me a lot of how Module Manager works. Unfortunately, that helps us very little in this case. The two mods handle their detection of modules and their variables quite differently from what I can tell, and the search parameters cannot be translated between them.

Edited December 12, 2014 by Gaalidas

[lo-fi]

Are you sure that putting the tweakScaleCorrector line in the config for the KF modules is the right thing to do? It's defaulted to 1 explicitly in the code (like a lot of the variables I use so you don't have to define them in the config unless you want something other than the default), and made available for TS to change. I'm wondering if TS changes it, then it gets reparsed through the KFWheel config node back to 1. It may well explain the long track weirdness. I could be completely wrong, but I can't see much sense in redefining it? I'll do a bit of testing myself.

Thanks for pushing changes to Git, it makes life so much easier!

[EpicCybertronian]

When's the new track being added?

[lo-fi]

I think the TS stuff is one of the last bits to be sorted before I can think about sending the next release out. It's proving tricky, though, so difficult to give an exact timescale I'm afraid.

[AccidentalDisassembly]

MODULE

{

name = KFModuleWheel

tweakScaleCorrector = 1

raycastError = 0.035

springRate = 0.8

damperRate = 0.05

smoothSpeed = 8

torqueCurve

{

key = 0 50 0 0

key = 10 75 0 0

key = 15 100 0 0

key = 20 125 0 0

key = 25 95 0 0

key = 30 15 0 0

}

torqueSteeringCurve

{

key = 0 85 0 0

key = 10 42 0 0

key = 15 20 0 0

key = 20 0 0 0

}

steeringCurve

{

key 0 0 0 0

}

brakeSteeringCurve

{

key = -25 -240 0 0

key = -10 -120 0 0

key = 0 0 0 0

key = 10 120 0 0

key = 25 240 0 0

}

brakingTorque = 70

rollingResistance = 10

maxRPM = 600

}

MODULE

{

name = KFWheel

tweakScaleCorrector = 1

wheelName = RoadWheel1

colliderName = WC1

sustravName = Link1

steeringName = Link1

isIdler = false

hasSteering = false

rotationCorrection = 1.5

smoothSpeed = 40

wheelRotationX = 0

wheelRotationY = 0

wheelRotationZ = 1

susTravAxis = Y

}

MODULE

{

name = KFWheel

wheelName = SprocketR

colliderName = wheelColliderSR

sustravName = LinkR

steeringName = LinkR

isIdler = false

hasSuspension = false

hasSteering = false

rotationCorrection = 1.5

smoothSpeed = 40

wheelRotationX = 0

wheelRotationY = 0

wheelRotationZ = 1

susTravAxis = Y

}

In that sample I've already removed the corrector definition from a few of those "wheels" that aren't actually being used as "wheels" in that sense, and I've been experimenting with some very detailed torque and steering settings in my personal copy, but overall it's pretty accurate to what is really in a standard track. Most of them actually don't have those "sprocket" wheels.

On the topic of TS having stuff to handle multiple thrust settings and such... I've not heard or seen anything like that, but it does remind me a lot of how Module Manager works. Unfortunately, that helps us very little in this case. The two mods handle their detection of modules and their variables quite differently from what I can tell, and the search parameters cannot be translated between them.

1.44 is the last really stable release - 1.45 and on introduced some features that interfere with other features (far as I can tell) in the presence of certain mods. 1.47's auto-scaling deal is also more or less broken for the moment - it works, but odd things seem to happen on spawns & reloads, masses go to infinity, stuff like that. Could be wrong, but I'm pretty sure lots of people have had issues even with 1.47 on stock...

Anyhoo, so here's what I'm thinking for that code -I'm going to make a bunch of guesses, so I'm sure half of what I'm about to say will be wrong, but:

As the MODULE{} is written now, I am going to assume that TweakScaleCorrector is only modifying the other variables that I can see in the code there. If it's being applied to stuff that's not in the MODULE{}, then this will be REALLY wrong, but you should be able to just write a TWEAKSCALEEXPONENTS{} fairly straightforwardly to deal with all of those MODULE{}s:

TWEAKSCALEEXPONENTS

{

name = KFWheel

raycastError = 1 // (scale linearly, I assume this has some relationship to model size?)

springRate = 1 // (also linear, assuming the "rate" is a physical measurement and not a percent or fraction despite "Rate")

damperRate = 1 // (also assuming linear with scaled size)

smoothSpeed = 1 // (also assuming this value should increase/decrease with scaled size - but if this is the maximum speed of the wheel, maybe not)

brakingTorque = 1 // (if this should scale in proportion to the mass of the wheels, then change to 3)

rollingResistance = 2 // (I am assuming this variable should scale with the surface area of the part)

}

That SHOULD make all of those values do what I've said in parentheses without any jiggery-pokery with TweakScaleCorrector and whanot. But again, that's assuming that your module is only using the variables I see in front of me to make the wheels work, and not using some other variable (not written here) that would need to change as a part gets bigger or smaller.

So this stuff:

torqueCurve

{

key = 0 50 0 0

key = 10 75 0 0

key = 15 100 0 0

key = 20 125 0 0

key = 25 95 0 0

key = 30 15 0 0

}

torqueSteeringCurve

{

key = 0 85 0 0

key = 10 42 0 0

key = 15 20 0 0

key = 20 0 0 0

}

steeringCurve

{

key 0 0 0 0

}

brakeSteeringCurve

{

key = -25 -240 0 0

key = -10 -120 0 0

key = 0 0 0 0

key = 10 120 0 0

key = 25 240 0 0

}

... I don't know how to deal with, but if those are multipliers rather than numerical values applied to the steering and braking etc. under certain conditions, then you don't need to deal with it (in theory) if they're just multiplying the same value that TS is going change around (like "brakingTorque" or whatever) when scaling.

What I don't see in there is a variable for the strength of suspension (which ought to scale probably cubically because it needs to match the mass of the part, which also scales cubically by default), unless that's what springRate does... I am assuming too that the Torque values are the only ones controlling the overall amoung of "oomph" the track has.

So in short, I don't see what TweakScaleCorrector is doing that you can't just do with a normal TWEAKSCALEEXPONENTS{} definition, but it's obviously 99% likely that I'm missing something..

EDIT: ACtually TweakScale does seem to be able to handle lists of things, it does so with USI's resource converters by doing this, so maybe it could work with the various Curves too. If not, you could probably just make one variable that the module multiplies the curves by (like TweakScaleCorrector, but not applied to everything; just to each value of key = x x x x or something):

TWEAKSCALEEXPONENTS

{

name = USI_ResourceConverter

inputList

{

rate = 3

}

outputList

{

rate = 3

}

inputResources

{

rate = 3

}

}

Edited December 12, 2014 by AccidentalDisassembly

[lo-fi]

Good thoughts; I tried that way, but it quickly gets unwieldy and unpredictable. I've added tweakScaleCorrector so I can multiply or divide as appropriate within the code, and I have absolutely 100% certainty that if that one value has been set appropriately everything will work correctly. It's also needed to drive the suspension movement of the mesh, as for some reason the inverse transform function that gives you the raycast distance does not take into account the scale of the wheel collider - possibly because its own scale is unchanged; only that of its parent object (the part). Some values like the default suspension strength are baked into the model and not defined in the config, so tweakScaleCorrector is needed along with some code to change those too. Once you're that far down the line with a hard coded exponent, you might as well go the whole hog and do the rest so that's what I did. It's built-in TweakScale support, if you like..

Thanks for tips on TS version, I've had all sorts of issues with the last few releases. I'm actually running 1.47 though, which is the first one that hasn't gone absolutely crazy on me (though it still has its moments!). 1.44 was an unqualified disaster with the wheels for some reason.

[AccidentalDisassembly]

Edited to remove spam... Huh. don't know why that posted twice...

Edited December 12, 2014 by AccidentalDisassembly

[Blarggnugget]

can I humbly suggest anti gravity drives? they could consume electricity but only provide enough lift to keep the ship at the level it started at, obviously applying thrust in any direction would move it. just think of the hack gravity cheat, but in part format that consumes vast amounts of electricity.

please and thank you

[Gaalidas]

So, dealing with those curves and stuff would be totally nuts because there's very little we can do to differentiate one "key = " from the one below or above it which looks exactly the same. If those curves were defined with a numeric marker, like "key01 = , key02 = , etc." then we could maybe handle it better.

Anyway, I've been doing soem more testing and i'm not quite finished yet, but I may have managed to stabilize it even with tracks without any code changes to the plugin. Unfortunately, this means getting rid of the exponential and reinserting the specific values. However, I'm not quite done yet. If I have to make another scaletype for tracks alone with more specific settings, I will. I'm experimenting with something that isn't exactly documented, but might still work considering the many ways that tweakscale can be set up in a config (which seems a bit chaotic, but flexible too) which may allow me to fine-tune the exponents for specific types of parts without having to clone the modules in the code and give them separate names. One thing that does seem to be tripping me up a bit is the fact that the same variable name is used for both modules, but that might not be as bad as it seems. The real issue seems to be that it has to be redefined for both module types (the wheel itself and the drive/steering module.) if the variable could be defined once and used by both modules, then I could eliminate the multi-wheel module oddities by simply editing the variable for the drive/steering module. if that value for "tweakScaleCorrector" could be read for both of those separate modules, then the problem is more or less solved. I'm unsure if a "public" variable like it is defined as in both modules makes it only public to everything on that page, or if it can be included in another page of code for the other module. I suspect that in reality, you would have to define it on a separate page of code (and thus it's own function, which means we'd need a separate module to use it with the part configs) and then include it similar to how you include code from a DLL with your page of code.

I have yet to take my programming class, so I'm sure my terms are all incorrect, but it's basically going back to my variable-controller module I wrote about a few posts back (maybe more than a few, I've been keyboard happy lately.)

So far, even though I've had to go backwards in modularity by bringing back the specific values instead of exponents, I have been making progress and even the tracks are behaving properly from what I can tell. When I complete my tests, I'll update the files with my corrections unless you plan to do some more wide-spread changes to any of the current part configs. You can disregard most of my custom torque curves and such in the above posts. I was just showing that there were multiple modules of the same exact name in the part config. The curves I have are for testing a way to decrease the sudden jerk of speed when you first start moving that tends to make a rover, with loose suspensions, wobble forward and back wildly. Testing of that is going well, but now I can't get them to still speed up quickly. I'm still fiddling. In the end, they might just be the most complicated entries for those parts you'll ever see.

[Gaalidas]

Are you sure that putting the tweakScaleCorrector line in the config for the KF modules is the right thing to do? It's defaulted to 1 explicitly in the code (like a lot of the variables I use so you don't have to define them in the config unless you want something other than the default), and made available for TS to change. I'm wondering if TS changes it, then it gets reparsed through the KFWheel config node back to 1. It may well explain the long track weirdness. I could be completely wrong, but I can't see much sense in redefining it? I'll do a bit of testing myself.

Thanks for pushing changes to Git, it makes life so much easier!

missed this post while I was taking some time off to manage my sanity. This stuff is really pushing the learning curve I'm on right now. So, i have yet to get a response as to if I need to define that variable in every instance of every module it modifies. As in my above post, I question if we even need to scale it for both modules separately, or could simply scale it for the one. But, like in my last post, I think we may need to adjust the code to allow that to work. We really need a variable that is public enough to be accessible and editable in both modules without having multiple instances of the same variable, but while still making it local to the individual part. Couldn't we make a new module (call it KF_ScaleCorrector) which simply allows us to scale that variable and make it available to the rest of the plugin for the part it is defined in? I don't know how to do that, or I'd have tried it already.

EDIT: Another option is to do what IR does and define the exponents for every part within the part config itself, which makes it a lot less modular but, considering the wide array of different parts you are using the same modules for, might ease the oddities I'm experiencing. Also, since I separated the KFScale into KFScaleM, KFScaleL, and KFScaleS (medium, large, small) but can't differentiate the exponents to apply only to a scaletype (testing a possible fix for that soon as I get my afternoon chiropractor session done) then I get some odd situations considering each part size has a different position in the list of possible scales for it's own personal "scale of 1.0." So, when I use the same set of corrector values for the M scale with with L scale, the default of 1.0 for the large wheels gets applied with a corrector value of 1.3 to correspond with it's position in the value list. And yes, it's 1.3, not 1.25 as expected. It seems that the corrector is being rounded to the nearest tenth. Either that, or the display is being rounded and the actual value is correct. Might have something to do with the format defined in the code? hmm...

Anyway, I'll get to the bottom of this eventually even if I end up reverting back to something like your original part configs. I'm in too deep to give up on it now.

EDIT2: I have good news. Everything is working. First off, a question for you, lo-fi. What exactly is the "tweakScaleCorrector" variable doing for the KFWheel module? Specifically, I'm talking about what it does for the module when being used by the tracks. The reason is this: I did something that I was pretty sure would not work, but it did and flawlessly too. I took the "TWEAKSCALEEXPONENT" nodes and stuck them inside the "SCALETYPE" node so that the exponent settings would apply only to a part that uses that scaletype. I suspected that the way Scaletype worked was that at run time the scaletype defined in the module would be swapped for all the settings that corresponded to that scaletype. Sorta like creating an array of data and giving it a variable name, then only having to reference that variable name to get all the data from that array. Since you can put exponent definitions inside the TweakScale module, I figure that they could also be brought into the config along with the scaletype. I had little hopes for success, but it worked. For wheels, this was never really an issue, but for Tracks it was pretty big that I get this figured out. The issue of the exponent being multiplied beyond reason is still there, I've just gone around it by not defining an exponent for the KFWheel module, which is causing the problems because it is defined over and over in some of the parts. For the tracks, any fixes for the torque going bonkers on scale would have more to do with the module that controls steering and driving. Since that one is never defined more than once, the corrector variable is only scaled once. I tested it out with two types of tracks on a single vehicle (the mole and the mediums, the mole ones scaled down to 50%, the mediums scaled up to 125%) and first off, I got no clipping with the ground which I got before when KFWheel was being adjusted, and I got no strange torque issues which is why we started this whole process in the beginning. So, I don't believe that the tracks really need anything to be done to KFWheel. The wheel parts, however, I am unsure about. That's why I ask about their supposed function. I know that we had problems with the wheels not even functioning when scaled before. Either way, the wheels are still making modifications to both modules since a wheel only defined each module once, and the tracks are only defining a modification for the drive/steering module and so far no odd behavior. This also means I can probably return to using an exponent instead of the specific values. This also eliminates issues with the different scaletype sizes putting the corrector value at the wrong level because of the difference in the value position in the range of possible values for scale.

I'm quite excited right now as you might imagine. One thing that still bugs me is that the TS reading in the context menu during flight shows that the tweakScaleCorrector is being rounded to the nearest tenth. I'm considering not worrying too much about that, and instead changing the intervals between the scales to 20% hops instead of 25% hops so that the values will remain at the tenth decimal place-value. This would also expand the flexibility of the system. For the time being, I am going to update the repository with the new fixed settings.

EDIT3: Scratch some of what I just said... I just looked at my experimental settings and it turns out the tracks were using the KFwheel modification, and they still performed flawlessly with the exponents being defined in the way I have defined them. I don't know how to explain it, but it's all working now. I haven't yet tested if I can return the exponent back to a single number, as currently it's specifying the value directly, but it's working as it is. I guess I'm better at doing this than I thought.

Edited December 13, 2014 by Gaalidas

[lo-fi]

Good stuff! I'm really confused, but it it works, great

I had a problem with the parts causing massive frame rate drop (.5 fps) due to log spam after getting the latest changes, but the log entry was something related to resource flow so I'm doubly confused now. No idea what's going on, but I'll keep you posted. I need to turn off the crazy auto scale thing, it's driving me completely insane too!

[AccidentalDisassembly]

EDIT2: I have good news. Everything is working. First off, a question for you, lo-fi. What exactly is the "tweakScaleCorrector" variable doing for the KFWheel module? Specifically, I'm talking about what it does for the module when being used by the tracks. The reason is this: I did something that I was pretty sure would not work, but it did and flawlessly too. I took the "TWEAKSCALEEXPONENT" nodes and stuck them inside the "SCALETYPE" node so that the exponent settings would apply only to a part that uses that scaletype.

I'd just like to point out that putting these inside the SCALETYPE is exactly what I suggested you do =) Glad it works, though I can't REALLY take any credit since I have no idea why it would work inside SCALETYPE and not out - except in the case that, for some reason, doing it outside the SCALETYPE was conflicting with some other variable somehow (because defined globally?). That doesn't really make sense though, so...

Don't know what was wrong with TweakScale 1.44 related to the tracks, but it lacks the autoscale feature and seems stable...

Edited December 13, 2014 by AccidentalDisassembly

[Gaalidas]

Autoscale is supposedly something that will be made into a toggle in the future. I downloaded the source which suggests that the change has already been made, but I don't see how the toggle is done, nor do I see any evidence that isn't actually a working toggle yet. Either way, the source fails to compile in its current state.

Hey, I saw this a few minutes ago and it reminded me of your side project to make auto-leveling landing legs. It seems that with some IR, a bunch of really small trusses, a plethora of cosmetic fuel lines, and some stock landing legs the effect of auto-leveling can be achieved. I'd like to see this guy repeat the process on a more extreme incline, but this first video is a success: Link

I haven't changed resource consumption at all, so that's totally on your end. The scaling, as it is currently (I switched to intervals of 0.2 instead of 0.25 so that the TS readout would be equal to the scale. I think it increases flexibility.) seems to be stable for the time being and I have had no issues with it in my tests. Granted, I have yet to test the long tracks which were producing some really strange results, but I don't think I'll have any problems. What I don't understand is how I fixed it in the end. All I did was re-evaluate how the exponents are applied to the different scaletypes. It's a mystery, but I'm not going to try and solve that just yet. I barely understand how the code even works, I'm just trusting SharpDevelop when it tells me that something is wonky.

Also, if you're confused about what just happened over the last few pages of my various updates, don't feel bad. I confuse myself all the time. It's the part of my brain that works, but I'm not too sure how. If we have learned anything from Quantum Weirdness (I'm not sure which quantum science it's contained in, but my astronomy professor called it that) it's that there are some things in the universe that we are not supposed to know about, and/or cannot ever witness. If we were to solve these mysteries, the way in which it works would no longer be true and we would be left knowing nothing. Case in point, the way that light can be a particle and a wave. If we run the tests, we see both particle interaction and wave interaction. If we observe the tests, however, then light begins to behave in only one of those two ways with all other test specifications exactly the same. This is try both of in-person observations and remote observations. Both within the test space and from outside the test space. It does not matter. Once we have witnessed the test in progress, the physics of light no longer works the way it is supposed to. Look it up, I'm not kidding you here.

The good news is that all those suggested changes to the plugin need not be looked into anymore. I do need to look into something though that is in my custom modifications to your code. i have worked action groups for ride height (both for repulsors and the wheels/tracks) however, when I use a plugin like AGX (Action Groups Extended) which automatically selects all objects of the same part on a craft when adding actions to a group (by default, can be overridden but not very easily), Each press can change the ride height by 5*[number of parts being changed] for the entire set. So, I hit my "1" button and if i have a 3-wheels per side setup of wheels, I move by 30 for each button press. I should only move by 5 whether I am activating a single wheel for the change, or all of them. So, it's a bit of a thing I'll have to look at. I have it worked really well for repulsors, but you handle the change of ride height differently for those. That's probably where my problem is. I'll need to construct the function differently based on the different ways that height is managed. I don't want to further bother you with figuring this out, though. I'm going to do some fiddling with my personal copy of your code and I'll get back to you. Lord knows I've broken your code enough times and been forced to re-merge from a fresh copy to fix it. I'm dangerous that way.

On that note, I use SharpDevelop (free software) to do my modifications and compiles. It works pretty well, and it has been letting me know that you have a lot of redundant "use" items at the top of your code pages. It seems that some of them are not actually necessary. It's also been revealing a number of more efficient ways to make certain equations and function calls. Overall, I don't think it matters since, once the binary is compiled and all is set in stone, it pretty much works at the speed it's going to work either way. Still, there are a lot of interesting ways to do things that I'm discovering. Quite fascinating.

[Gaalidas]

I'd just like to point out that putting these inside the SCALETYPE is exactly what I suggested you do =) Glad it works, though I can't REALLY take any credit since I have no idea why it would work inside SCALETYPE and not out - except in the case that, for some reason, doing it outside the SCALETYPE was conflicting with some other variable somehow (because defined globally?). That doesn't really make sense though, so...

Don't know what was wrong with TweakScale 1.44 related to the tracks, but it lacks the autoscale feature and seems stable...

I think the lack of autoscale, which many people mistake as a bug when in fact it's a feature that wasn't made into a toggle like it should have been, is the only real benefit of it.

As for why my fix works, I have no clue either. But, it does work and it actually allows me some extra flexibility in how I define the scales and their correction values. Otherwise, I was severely limited due to how lo-fi has bundled his various ways of handling tracks/wheels/whatever in the same modules rather than making dedicated modules for each one. it sounds wonderful when making the plugin efficient and making the configs easy to write for different styles of locomotion, but for modifying things from other plugins it's a nightmare. I'm just glad that TweakScale was developed with enough flexibility to allow the scaled values to be defined in a plethora of different ways. It makes the learning curve really steep, but in the end it's worth it. It's a bit like the English language. There are so many different ways to say the exact same thing with you take into account accents from all around the world (half of them in the USA alone) and the different spellings between USA and British, and even Canadian ways of doing things... well, you get the picture. It's a nightmare to learn, but once you get to a certain point in that learning curve you begin to realize it's incredibly difficult to break the language (so to speak) and you can get away with almost anything and still be understood. Then begins the long and arduous task of learning all those various ways to say things in an attempt to master it. The difference here is that I probably won't die of old age before mastering the different ways to define scales in TweakScale.

Edited December 13, 2014 by Gaalidas

[lo-fi]

Actually, I could make it a lot simpler... I have and idea, back to you shortly.

This, by the way, will be necessary because of what I'm about to create next...

EDIT: Gaalidas, please don't hate me, but... The KFWheel modules look for the instance of KFModuleWheel in the part and use a bunch of values from it. It seemed to make sense, seeing as having multiple instances of KFWheel in the part is tricky, to have tweakScaleCorrector as one of those values that KFWheel pulls out of KFModuleWheel. So, as there will only ever be on instance of KFModuleWheel in a part, that's the only one you need worry about in your TS configs. I should have realised sooner, I've just been so busy and barely keeping up with your latest work on TS. Works beautifully for me, let me know how you get on. Great work, the attachment nodes are much better and the various TS size ranges work really well. We might get there eventually after all!

Edited December 13, 2014 by lo-fi

[AccidentalDisassembly]

Well, there are actual bugs in 1.47 too, especially related to part mass - both on stock and on modded stuff. With regard to the modded stuff, anyway, it would make parts with MFT on them (or FS fuel switching, possibly, not sure) gain mass every time their scale was changed, so they got up to the billions of tons pretty quick.

[Gaalidas]

Actually, I could make it a lot simpler... I have and idea, back to you shortly.

This, by the way, will be necessary because of what I'm about to create next...

EDIT: Gaalidas, please don't hate me, but... The KFWheel modules look for the instance of KFModuleWheel in the part and use a bunch of values from it. It seemed to make sense, seeing as having multiple instances of KFWheel in the part is tricky, to have tweakScaleCorrector as one of those values that KFWheel pulls out of KFModuleWheel. So, as there will only ever be on instance of KFModuleWheel in a part, that's the only one you need worry about in your TS configs. I should have realised sooner, I've just been so busy and barely keeping up with your latest work on TS. Works beautifully for me, let me know how you get on. Great work, the attachment nodes are much better and the various TS size ranges work really well. We might get there eventually after all!

If that's the case, then I can remove any changes to that variable being applied to the KFWheel module. That simplifies things even further. In fact, before reading this message I synced up my github copy and noticed you'd made a few adjustments. I'm getting ready to test another tweak to my action group expansion. I've probably broken them further, but I've been so lucky with TS lately, I'm feeling like it might have a shot at actually working right out of the box. Glad to hear you're happy with the TS scales available. I admit, I did not test every part to see if those values worked, I merely gave it a reasonable guess and tested a few of the parts to see what would happen. I then got lazy and said "here goes nothing" with my github update.

Also, don't feel bad you've barely been keeping up with me. I barely keep up with myself sometimes. I look back at my forum posts and think to myself "Did I really type that? What was I thinking?!"

Edited December 14, 2014 by Gaalidas

[lo-fi]

Cool, I've added your AG updates too, though I made some modifications so it won't trigger parts with the same group number too. This was what was causing the giant leaps in the numbers when using AG's, so I've made allowances in the ApplySettings method for dealing with that when triggered from an AG.

There may well be some unused Use statements, it'll be a hangover from earlier code versions. I can't find a similar function in VS Express 2012, but according to the docs the compiler won't bother to include them if they're not actually used. If you'd like to remove them, go for it, though. Efficiency savings will always be good!