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.

Wait a sec... was that nuke engine getting too hot during the lunch break, or was the kerbal thinking about it during his lunch break? Honestly, that description could go both ways in that area. Maybe it was getting too hot because they forgot to turn it off during lunch. Just sayin'...

Doesn't this mod have action group mimic? If you set the engine toggles to action groups, you'd be able to switch them alright I'd think. Might have issues if you're using different command parts for different orientations though. Those crafts remind me of my days in Orbiter. I had to have the hovers on all the way up as well as the mains just to keep myself from falling back the earth. Ah those were the good old days, when I was too new to this space thing to even known about circulization and such. Sure explains why I could never get a stable orbit though.

You sure lost me with the "IK" and "upTargetNodes" but I want it anyway.

I want to let you know that your currently implementation in the MM patch you distribute which is supposed to disable interaction with Kerbal Foundries parts will become obsolete with the next release of lo-fi's mod. The module names have changed quite a bit since the days of ModuleTrack. Right now, the best way to check for lo-fi's reinvention of the wheel is simply to check for a module named KFWheel. I'm posting the updated patch for that below: @PART [*]:HAS[!MODULE[ModuleLandingGear],!MODULE[ModuleWheel],!MODULE[CollisionFX],!MODULE[FSwheel],!MODULE[KerbalEVA],!MODULE[TTModularWheel],!MODULE[*Repulsor*],!MODULE[KFWheel]] { MODULE { name = CollisionFX scrapeSparks = true collisionSound = CollisionFX/Sounds/Bang1 scrapeSound = CollisionFX/Sounds/GroundSkid } } You'll notice that the repulsor search in surrounded with wildcards. This is because there are actually several variations on the repulsor module and I've found in some of my own patches that encapsulating the word "repulsor" with asterisks allows MM to catch all of those variations. The module "KFWheel" exists in all of the parts (wheels and tracks, even the hypno-drive aka. screw-drive has a KFWheel module, only the repulsors are lacking it) and so is an easy catch-all for Kerbal Foundries wheel-like parts. Again, this update will only be necessary after lo-fi's next update.

That's a difficult thing to say. Once something has been scaled, you might not get it back unless you edit your persistence file manually to fix it. i may be wrong, but if you scale something, launch it, save your persistent state, then remove the mod, the parts you have saved will continue to be the scale they are at unless a different mod tries to rectify the situation itself.

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.

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.

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.

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.

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.

I'd release a full size version just so some crazy video makers can try to see if they can get it into orbit the old fashioned way. I mean, attach enough boosters to it and you should be able to get it up there, you'd think. In theory...

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've got another question regarding my imminent commit to the KerbalFoundries Tweakscale implementation. For a variable in a "TWEAKSCALEEXPONENTS" node to be adjusted, I would assume the variable in question needs to be defined in every instance of the module as it appears in every part that is to be scales, am I right? So, if a track part has four or five instances of "KFWheel" module, they must all have the variable that I have put in my "TWEAKSCALEEXPONENTS" setting present in that module's parameters for them to all be updated with the new value?

30 kerbals? That's some crazy stuff. I don't think my KSC even has 30 employees. EDIT: Alright, lo-fi, I've committed an update most of the wheel parts to include my node tweaks and updated TS modules. I also added the file to the root directory that contains the TS definitions. One thing to note, however, is that all the wheels start as if they were all the same size. They haven't been scaled yet though, so scale of 1.0 on the really big wheels is, as far as TS is concerned, equal to 1.0 on the really tiny wheels. Some testing might need to take place on those extreme wheel sizes to see if the current levels those can be scaled to will work as intended. I'm mainly worried about the tiny ones being scaled so small that they become completely useless. Also, I thought of something else that could cause problems with your exponent variable. I don't think that TS necessarily is able to change a variable that's not present in the part itself. So, we're going to need to update the part files to make sure that the default level for "tweakScaleCorrector" is defined for each of the modules in the parts. I'll be looking at that next. The part I'm a bit shaky on is how to determine if that variable in your code can be defined/overridden in the config or not. I have a good feeling that TS needs the variable to be defined not only in the exponent definition, but also in every instance of the module in the part configs themselves. I intend to make an inquiry on the TS tread shortly about that.

Not absolutely necessary, but some sort of image editing software is helpful.

I can push things into there? I'm so not very well educated as to how that stuff works. I barely have a hold of the vocabulary. And yeah, I've actually got the whole thing set up, I just have yet to actually see if that variable is being updated properly. As far as I can tell, though, it should work as intended. I'm crossing my fingers on that.

Yes, I mentioned that later on in my post you are replying to. We can indeed make it an exponent of one and eliminate needing to modify the exponent settings again in the future, which will also make it completely compatible with any other wheel sets that use their own tweak scale factors without needing to take into account the exponent settings.

No, and don't you dare try anyway. Once you go down that road, we'll never see you again... at least not sane, or even alive. Oh, hey, so I did some digging around as to how best to format modular tweakscale implementations. It looks like the easiest way to do it is to add a config file to the root directory of your addon ("GameData\KerbalFoundries\" would seem best), name it whatever you like. I called mine "KF_Scaletype.cfg" In this file you add something like what I have here: SCALETYPE { name = KFScale freeScale = false scaleFactors = 0.75, 1.0, 1.25, 1.5 scaleNames = Small, Medium, Large, ExtraLarge defaultScale = 1.0 } TWEAKSCALEEXPONENTS { name = KFWheel tweakScaleCorrector = 0.75, 1.0, 1.25, 1.5 } TWEAKSCALEEXPONENTS { name = KFModuleWheel tweakScaleCorrector = 0.75, 1.0, 1.25, 1.5 } You'll notice I added another specific setting to your variable, just cause I was fiddling with what I could do with this stuff. Anyway, the Scaletype is then what you specify under "type" in the part config. The two "TWEAKSCALEEXPONENTS" nodes are what control the specific levels of that variable to coincide with the specified values for scale in the scaletype. If these are not equal in number, bad things happen (or so they tell me). The exponent data itself doesn't need to be referenced by the part config or the scaletype, they just get applied to any module found in the part when it is scaled. The way it was explained to me is that the name "TWEAKSCALEEXPONENTS" is really a bit misleading. If only one number is provided, that number is used as an exponent to apply to the variable specified. If multiple values are specified then it treats it like a specific value where the value's place in the list coincides with the scaling level's position it the list of scales. This lets you simply call this scaletype with this in the part config: MODULE { name = TweakScale type = KFScale } And that's all there is to it. You can now make any changes you need to make for expanding the list of scales, or the values for the variable-handling, or even replace the specific values with an exponential value instead and all parts that reference that scaletype will take on those new settings. Now you don't have to edit every single part (including the stock-wheel configs that you have under a different project) to reflect any scaling settings you decide to change in the future. One possible problem could be if you want to create configs to handle other mod wheels, such as teh ASET wheels for that ERS rover system. If those parts already have specific settings for their scaling levels, then your specific values will not amtch the number of scale sets that the other wheels have. This brings me to another interesting little factoid about exponents and how it relates to your implementation. Exponents, as you probably know, have their identity properly at the "#^1" (whatever-number raised to the single power). I noticed that the values you have in the scale levels exactly match the values for your variable. I think, though I'm no expert here, that, technically, the value for a scale of 1.5 on the wheel would result in a " tweakScaleCorrector" valued at 1.5. Is that not, then, the scale-value raised to the single power? So, if you changed the "tweakScaleCorrector = 0.75, 1.0, 1.25, 1.5" to "tweakScaleCorrector = 1" then you would get the same result. This basically means it'll modify the "tweakScaleCorrector" variable to equal the current scale setting. This would then allow you to freely expand on your own scale levels, and allow parts that use their own scaling sets to also use your plugin to drive their wheels without having to change how they scale themselves. Since you'd be using an exponent to handle the variable change, it would never cause any issues with the scale levels and the exponent values matching. Anyway, I've rambled on long enough. I have yet to be able to verify this stuff because I still can't figure out how to get the wheel parts to show the current setting for that variable in the context menu while in the editor. If the people on the TweakScale forum post are to be believed, though, this should all be accurate enough to work. At the very least, it was explained to me that using something like: MODULE { name = TweakScale type = free scaleFactors = 0.75, 1.0, 1.25 defaultScale = 1.0 MODULE { name = KFWheel tweakScaleCorrector = 0.75, 1.0, 1.25 } } Where you have, basically, "Module{Module{}}" in the part config, supposedly that's the absolute worst way to accomplish this. Also, specifying "type = free" causes it to ignore your "scaleFactors" settings entirely. I need to get that debug view open to really test this thing though. Who'd have thought it would be so complicated? But, in the end, it saves a lot of work.

I gotta say, until I saw the lack of smoothing there, I really had no idea how the curved models in this program got to look so nice. Not too surprising though, I'm as much of a modeller as my pet cockatiel is a grand-piano tuner. And it's not...

Most definitely. When's the last time you saw any mention of the other planets in the official release notes? These days everyone is doing the Mun, or orbital maneuvers, or space stations. Extra planets are low on the priority for terrain upgrades.

I've never been to that planet. The first, and last apparently, time I was in orbit, I chickened out because I couldn't tell what was land and what was... uhh... not-solid. At the time I had no idea if there was even actual water on the other worlds and also had no idea if KSP had any mechanics to handle other liquid forms that could incinerate my craft. I was also only actually in space because of mechjeb. Now I know a lot more, and I'm still scared to land there. This is one situation where knowing more about your destination does not make it any easier to land there. I would probably have survived the landing though. That was one awesome little craft I had. I used two giant half-spherical fuel tanks and anchored a huge toroidal fuel tank to the center to create a sorta-spherical setup for the main hull. Stuck RCS thrusters on the outer edge of the giant toroid and a cupola on the top of the top-side half-sphere. I then attached a bunch of fuel tanks and a few fuel generators (yeah, a bit of a cheat, but it did take some time to generate that fuel and it took a lot of power to make happen.) on the bottom, followed by a procedural fairing ring (non-decouplable) and then a large multi-adapter for a ton of engines. I then made it really smooth looking by forming my procedural fairings so that there was only enough room for the engine nozzles to barely stick out and have a little room to gimbal. Attached three symmetric landing legs to the outside of the fairings, strutted them in (quantums, cause they were still new to me and super strong), and that was that. Added a few lights to the edges and a few spotlights to light up the surfaces I landed on. A guant array of boosters for launching and I was good to go. Made it into orbit, waiting for the fuel to generate back up, and I was off. Landed on almost all the inner planets, and managed to get into orbit of Jool only to get my orbit screwed up and get smacked by one of it's orbitting moons and obliterated. A sad day. I think I'd had KSP for about two weeks at that point. Haven't been out to the rest of those planets again since. As to projectile winches, I beleive all the winches can "eject" their attachments at quite a bit of force so that you can attach to something at some distance, but there does not seem to be anything like an aim and fire sort of mechanism. You pretty much have to fire it out at the angle it's already in and hope for the best. I remember trying to tow a craft that ran out of fuel into an unstable orbit when I was experimenting with ways to de-orbit dead crafts without simply using the map interface to obliterate them. I spent forever lining it up, fired them out (dumbfire, got lucky) and attempted to fire a short, low-thrust burn to yank that offending craft out of its orbit. The damn thing didn't even budge, but my winches tore the back end of the tow craft off and send me into a wild turn-kerbals-into-green-goo high-speed spin which left even me feeling ill in front of my computer screen. Never tried that one again.

Yeah, I just spent some time fiddling and discovered my error with the IR example. I think I get it now though. Calling them exponents does confuse it a bit. Alright, I should be able to upgrade lo-fi's implementation of Tweakscale in the next day or so then. Thanks.

I like the idea of boosters better, honestly, but that's probably because I'm starting to turn into a kerbal the more I spend engineering rockets like one.

I suppose I should point out that the example I gave is from the first post in this thread, and that same method is used with IR parts. So, the method I put in my other message is already a workable method. I just wanted to find a way to further reduce the amount of work for applying the same module-specific variables for each scale level when all the parts are using the same numbers for those variables. Also, if you look at the official distribution, most of their exponents are defined outside of a scaletype, so your recommendation to not define them outside of a scale type is... how do I put it... nuts? It was an excellent effort however. I suppose, if your examples do work, that you may have answered some of my questions. I was confused a bit by the explanations on the first page as to what I could define under what in the different definitions that I can um... well... define. For instance, it shows how exponents are defined, but then shows the other way to define variables with fixed values for a fixed number of scales. I got the impression that you couldn't define those specific variable values udner exponents because it was not using an exponential curve with those variables.