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

[Kerbas_ad_astra]

"Why do we fall into craters, sir? So we can learn to boost ourselves out." -Alfred Kerman

[Corovaneer]

Yeah, KAS can pull you out allright, but it's kinda hard to do on every 25-degree slope, if you're taking on a contract to chart something with a rover, and the area is 70km away))) With time warp and good traction (and careful driving), it's possible to get there in an hour or so, I think. Climbing out of every hole with KAS will take you days

[lo-fi]

"Why do we fall into craters, sir? So we can learn to boost ourselves out." -Alfred Kerman

Haha! Is there a thread of Kerbalised quotes anywhere? This should be in it..

Yeah, KAS can pull you out allright, but it's kinda hard to do on every 25-degree slope, if you're taking on a contract to chart something with a rover, and the area is 70km away))) With time warp and good traction (and careful driving), it's possible to get there in an hour or so, I think. Climbing out of every hole with KAS will take you days

Is there no projectile KAS winch? It's been so long since I used KAS.. if there isn't, there ought to be

By the way, climbing 30 degree hills with latest track setups seems no bother on the Mun. Finding some weird issues driving on Eve, though :/ a lot of places the ground collider doesn't match the position of the mesh and sometimes the rover will just bounce weirdly like it's an American low rider. Very strange... Anyone else found this?

[Gaalidas]

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.

Edited December 8, 2014 by Gaalidas

[lo-fi]

Well, I hyperedited this trip Maybe that's the problem, but it still occurred after a save/reload, so I don't think it's that.

I think my next proper Eve visit will involve a space plane of some kind to glide down, plus repulsors for landing on those nice big open stretches of liquid, then balloons to get back up out of that heavy gravity well.

Haha, shame about your tug experiment, was the other vessel still on rails for some reason? That sound hilarious! Hopefully have better success with nli2work's tug....

[Madrias]

Lo-fi, it's something I noticed too, both with HyperEdit and with an actual flight. I think Eve's just a big purple... um, perhaps I shouldn't say exactly the words on my mind.

I think it's the fact that it's running the old, unrefined mesh/collider mess, combined with the stupidly high gravity, leads to the tracks bouncing along.

[lo-fi]

Ah, that's useful to know! I thought I'd done something stupid and was beginning to worry.

Are some of the planets more refined in their construction?

[Gaalidas]

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.

[lo-fi]

I see. Annoying, but at least it's not my issue to deal with...

[Gaalidas]

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.

Edited December 9, 2014 by Gaalidas

[AccidentalDisassembly]

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'm not Biotronic, so take it for what it's worth - I believe you can simplify this further. All of your tweakScaleCorrector values scale linearly with your scaleFactors - increase the scaleFactor to 2.67, the tweakScaleCorrector is then 2.67, for example. The following will do the exact same thing you're doing, but it will make it so that you can add or remove ScaleFactors without having to change values inside the TWEAKSCALEEXPONENTS{} - you'd still have to have names for the scaleFActors and all, just one less step:

SCALETYPE
{
    name = KFScale
    freeScale = false
    scaleFactors = 0.75, 1.0, 1.25, 1.5 (or more)
    scaleNames = Small, Medium, Large, ExtraLarge (or more)
    defaultScale = 1.0
}
TWEAKSCALEEXPONENTS
{
    name = KFWheel
   [B] tweakScaleCorrector = 1[/B]
}
TWEAKSCALEEXPONENTS
{
    name = KFModuleWheel
   [B] tweakScaleCorrector = 1[/B]
}
}

[Gaalidas]

I'm not Biotronic, so take it for what it's worth - I believe you can simplify this further. All of your tweakScaleCorrector values scale linearly with your scaleFactors - increase the scaleFactor to 2.67, the tweakScaleCorrector is then 2.67, for example. The following will do the exact same thing you're doing, but it will make it so that you can add or remove ScaleFactors without having to change values inside the TWEAKSCALEEXPONENTS{} - you'd still have to have names for the scaleFActors and all, just one less step:

SCALETYPE
{
    name = KFScale
    freeScale = false
    scaleFactors = 0.75, 1.0, 1.25, 1.5 (or more)
    scaleNames = Small, Medium, Large, ExtraLarge (or more)
    defaultScale = 1.0
}
TWEAKSCALEEXPONENTS
{
    name = KFWheel
   [B] tweakScaleCorrector = 1[/B]
}
TWEAKSCALEEXPONENTS
{
    name = KFModuleWheel
   [B] tweakScaleCorrector = 1[/B]
}
}

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.

[AccidentalDisassembly]

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.

Oops, missed that! Sorry!

[lo-fi]

One exponent to rule them all....

That is cool, though. Make it so, number one!

Actually, could you do me a massive favour with those configs you edited the nodes on, and push them into the github repo please? Same goes if you're setting up the TS config - it'll save me a load of copy/paste and potentially screwing something up in the process

[Gaalidas]

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.

[loler43214]

Question, is it necessary to use unity or photo-shop for custom textures to redesign a part?

[Gaalidas]

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

[leopardenthusiast]

I decided I needed faster land transportation than wheels could provide.

I briefly used a propeller from Kerbal Aircraft Expansion, but it kept tailstriking, and the jet was faster anyway.

EDIT: Turns out I posted an old screenshot. WHOOPS.

Edited December 10, 2014 by leopardenthusiast

[lo-fi]

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.

Yep, absolutely. The desktop client is really cool too, I have it setup so it clones the KerbalFoundries folder in gamedata directly, so when I've made changes all I have to do is hit commit and sync. The same is true if the repo has changed and you want to update your local copy. Give it a go, it makes things really easy!

http://i5.minus.com/iSEG21nQbRl26.png

I decided I needed faster land transportation than wheels could provide.

I briefly used a propeller from Kerbal Aircraft Expansion, but it kept tailstriking, and the jet was faster anyway.

EDIT: Turns out I posted an old screenshot. WHOOPS.

Cool, how fast can you go?

[leopardenthusiast]

Cool, how fast can you go?

The fastest I've seen it hit was about 135m/s. It's also very good at handling drops - I suspect that I could drop it from orbit and, as long as the repulsors were oriented correctly, land just fine with no parachutes.

EDIT: I just tested it by getting to about 100m/s downwards. The result: No, I could not.

Edited December 10, 2014 by leopardenthusiast

[Madrias]

Low-velocity Anti-Lithobraking devices, XenonBlade. I've found the vertical descent limit, for me, is about 50m/s on Kerbin, with light vehicles.

The higher your repulsors are set to hold, the more cushion you have, and obviously, the more repulsors you carry, the safer you'll be, but there's two limits.

Mass will overwhelm repulsors and you'll inevitably either slam into the ground first, or you'll overcome even an insane repulsor array and shear several of them off.

I've found my best flight settings are to set the repulsors to maximum on all sliders. They behave somewhat differently (can't describe it, it's both like having softer suspension and stiffer suspension at the same time.) and thereby save small craft from instant death.

And then because your repulsors are consuming electric charge at an astronomical rate, you'll need some form of super-powerful power supply. I use Interstellar's reactors, but I've heard people using NearFuture and it's even possible to part-mod yourself an RTG with some several hundred ElectricCharge a second.

[leopardenthusiast]

Low-velocity Anti-Lithobraking devices, XenonBlade. I've found the vertical descent limit, for me, is about 50m/s on Kerbin, with light vehicles.

The higher your repulsors are set to hold, the more cushion you have, and obviously, the more repulsors you carry, the safer you'll be, but there's two limits.

Mass will overwhelm repulsors and you'll inevitably either slam into the ground first, or you'll overcome even an insane repulsor array and shear several of them off.

I've found my best flight settings are to set the repulsors to maximum on all sliders. They behave somewhat differently (can't describe it, it's both like having softer suspension and stiffer suspension at the same time.) and thereby save small craft from instant death.

And then because your repulsors are consuming electric charge at an astronomical rate, you'll need some form of super-powerful power supply. I use Interstellar's reactors, but I've heard people using NearFuture and it's even possible to part-mod yourself an RTG with some several hundred ElectricCharge a second.

Mine's about 50 as well, though I haven't quite maxed out the strength. I'm currently using the little LF/O generator included with the repulsors - it doesn't noticeably drain my fuel.

[Madrias]

The little LF/O generator isn't too bad. I'm just not fond of the noises it makes. Yes, I could config-mod it away, but I've got a silent option that works.

So it seems 50m/s is Kerbin's descent velocity maximum. I've not tried destructive lithobraking tests on other worlds yet, but I'm bound to find when they don't work. So far most of my Mun landings are touch-downs at 20 m/s or less. My Eve landing was parachutes and tracks, and touched down at 5 m/s, then slid all the way down a big hill. Minmus, I haven't landed on in a while. Still have 30 Kerbals stranded there 'cause I keep knocking my engines off on landing.

[Gaalidas]

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.

Edited December 10, 2014 by Gaalidas

[Darren9]

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