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

[AccidentalDisassembly]

Join the dark side. It is your destiny... Ahem.

I have another model for the APU, I just keep forgetting to update it...

I'll need to add something into the plugin to be used as a TS exponent - will try and get to that soon. Setting up TS configs would be much appreciated

Gotcha. I assumed (don't really understand the DLL though obviously) that if I had the name of the variable used to determine strength of a repulsor, or the height, for example, I could already write a TS thing as-is... But I gather that's not how it works! =(

[AccidentalDisassembly]

Also wanted to share what may be an unusual behavior with the tracks. They are scaled up, however, so I don't know if that's the cause. They cause a vehicle to very suddenly stop and turn if you're moving forward at moderate speed and suddenly steer. I've made a video (sorry it's a bit crappy, first I've ever made!) to show what I mean:

https://dl.dropboxusercontent.com/u/59567837/TracksTurning.mp4

No embed, sorry, but it's around 1MB so isn't huge to DL.

[oniontrain]

Lo-fi, your inbox is full and I got some questions, send me a PM when you get the chance.

[lo-fi]

Inbox cleared.

I'm not sure if I need one or more extra variables yet, and I'd hate to have you go through loads of work to then turn around and give you different info. I'll get back to you shortly..

Really not sure what's going on with the trip, would be interesting if you get the same thing not scaled. If definitely looks like a collider catching on the floor, but you're on flat ground and they're carefully designed for that not to happen. I certainly can't think of anything in the plugin which would cause that kind of behaviour. Is it always in the same place?

You could try setting breakingTorque and breakingForce on the tracks quite low, which will result in the offending article being ripped from the vehicle if it is non wheel collider contact with the ground that's causing the problem, which would tell us something.

[lo-fi]

Bah! This TweakScale thing is a nightmare.

A little reading reveals this seems to be a known issue with symmetry that has yet to be fixed, but I didn't dig too deep. Tired, bored and moving on. There is now a public variable in KFWheel called suspensionCorrector, if anyone who has more experience wants to have a go.

I've been using:

MODULE
{
    name = TweakScale
    type = free
    scaleFactors = 0.5, 1.0, 1.5
    scaleNames = Small, Medium, Large
    defaultScale = 1.0

    MODULE
    {
        name = KFWheel
        suspensionCorrector = 0.5, 1.0, 1.5
    }
}

Which works sometimes, but TS seems to move my parts around in flight and not scale the symmetry counterparts correctly. Always fine going back into SPH, but there seems to be some kind of disconnect between SPH and flight :/

[MonaBabii]

+lo-fi Not sure if this will help for your parts specifically as it may be something else entirely, but I've found that in order to get TweakScale to work 100% of the time on every part without some symmetric parts being completely left out, I do the following:

1) Grab the part from the parts list with -1x- symmetry first (aka no symmetry).

2) Place it on your craft anywhere you want, remember to place it without symmetry.

3) re-take that part and apply symmetry, then put it back down.

4) Finally tweak its scale.

Same goes for people using KerbPaint and experiencing issues when painting symmetrical things... well not the same thing but there's also a quick-ish work-around for a similar issue. Let's say you're painting a pair of symmetric wings on a plane:

1) Paint one wing however you want it; create your custom color, paint as many layers as you want (primary, secondary or tertiary). Doesn't matter which wing you pick first.

2) Once the one wing is painted, re-open the KerbPaint window on that first painted wing and click "copy set".

3) Open the KerbPaint window on the symmetric clone of that wing even though it will appear to be correctly painted at first.

4) Click Paste Set once on any of the layers (primary, secondary or tertiary), and then select a second layer (say you first picked the primary color, now select the secondary or tertiary) and click Paste Set again.

That will successfully apply the entire color set of the first wing and ensure that your craft will be fully painted when in or out of the assembly buildings and safely saved.

Hope that helps

Edited November 15, 2014 by MonaBabii

[lo-fi]

Cheers dude, that's really helpful. I'll drop into the TS thread and see what the latest is - I assume someone is working on it.

[AccidentalDisassembly]

MODULE
{
    name = TweakScale
    type = free
    scaleFactors = 0.5, 1.0, 1.5
    scaleNames = Small, Medium, Large
    defaultScale = 1.0

    [B]TWEAKSCALEEXPONENTS[/B]
    {
        name = KFWheel
        suspensionCorrector = 0.5, 1.0, 1.5
    }
}

Which works sometimes, but TS seems to move my parts around in flight and not scale the symmetry counterparts correctly. Always fine going back into SPH, but there seems to be some kind of disconnect between SPH and flight :/

I'm not exactly sure either, but I think that you need "TWEAKSCALEEXPONENTS" and not another MODULE tag inside the TS module. I think if you go in ScaleExponents.cfg in the TS directory, too, you can define it globally like so:

TWEAKSCALEEXPONENTS

{

name = KFWheel

suspensionCorrector = 1

}

Applying the exponent of 1 should make it scale linearly - 2x scaled size, 2x the value for that, and it should work for any scale people want to come up with. Far better not to define it for individual scale values.

EDIT: actually I have no idea if you have to put that in scaleexponents.cfg - you may be able to put that in any cfg anywhere so long as it is NOT inside another MODULE{}

Edited November 15, 2014 by AccidentalDisassembly

[Gaalidas]

You can define your own exponents in a separate config. That's the nice thing about these custom nodes, you can define them anywhere (inside or outside of a part, below a part in the same file, a completely separate file, an MM patch to insert them into the official file) it really doesn't matter at all, as long as the formatting is done correctly. For instance, if you look at IR they have some specific code for their use that makes use of a Tweakscale redistributable and they have their own exponent definition file, plus some separate exponent definitions in a few of the specific parts. These are sometimes defined as a separate node in the part config, and sometimes they are defined in the tweakscale node itself. I've even seen two of them in one part file, one for generic exponents and one for a specific module.

On the other hand, there have been a lot of weird things to happen and it's a bit hard to track down if you do not have all of your tweakscale modules in a single MM patch, and your exponents in a separate config on the side. It might be a good idea to look into the ways that a plugin-writer can interface with tweakscale as well for your more complicated needs. Also worth noting is that Tweakscale is being actively developed. They recently updated it with compatibility for the FS fuel switching module.

On the topic of symmetry issues, I always find it a good practice to remove my symmetry one I am happy with the product and ready to launch with scaled or painted parts. I use "PartWizard" to switch off, or optionally re-group, my symmetrical parts to ensure launch stability. I even took at 8x symmetrical arm-piece and separated it into two 4x symmetrical groups to aid in creating a probe out of the PunyProbe parts which had four prop engines and four monoprop engines staggered around the central core. The reason I had to use PartWizard to pull this off was that I was using a modified thrust plate adapter (tweakable node size/number/offset on a flat plate of tweakable size itself) to provide stack nodes to attach the arms to. In an 8-node configuration I had a node for each of my two sets of four engines. When placing different connections to those arm pieces, I was being forced to use 8x symmetry. After re-grouping them I could create the two sets separately while still, technically, arrayed in 8x symmetry. Normally, I would have had to rely solely on surface attachment do pull this off, which is sometimes unreliable.

I may not be an ingenious pod-racer builder but I do have some mad skills with all these little tools and such.

EDIT:

Okay, so I took a look at your config updates and I've decided to write up some example configs for you.

Note: all of this can be defined in the same file, and even put into the part configs. I like to put them in separate files for modularity.

First is our scale type:

SCALETYPE
{
    name = KFWheel  //or whatever you feel like calling it.
    freeScale = false  //you can imitate free scaling by providing lots of specific scale options..
    scaleFactors = 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 2.75, 3, 3.25, 3.5, 3.75, 4, 4.25, 4.5, 4.75, 5, 5.25, 5.5, 7.5, 6
    minScale = 0.25  //minimum scale factor.
    maxScale = 6  //maximum scale factor.
    scaleNames = 0.25x, 0.5x, 0.75x, 1x, 1.25x, 1.5x, 1.75x, 2x, 2.25x, 2.5x, 2.75x, 3x, 3.25x, 3.5x, 3.75x, 4x, 4.25x, 4.5x, 4.75x, 5x, 5.25x, 5.5x, 7.5x, 6x
    defaultScale = 1
}

Yeah, writing all those scale factors is a pain but at the least it's consistent between different parts. Free scale is limited by the size of the slider and the lack of configurable scale increment size. You could hit a spot where you get 1.14 scale factor with one part, but with another part you may have only 1.19 or 1.11 to select from due to the limited space and the limited pixels you can click on within the selection bar. With some experimentation, you might be able to expand on the tweakscale implementation to allow for a Procedural Fairings style incrementation slider which allows you to set a base incrementation for the arrow buttons, while still allowing use of the double-arrow buttons to increment a static amount, and then using the slider you can increment to the factor of 0.1 on the base scale incrementation setting. This allows for the ultimate in scale control without needing to find a way to make the context menu super huge or frustrate users with free scaling.

Next is the Exponents section.

TWEAKSCALEEXPONENTS
{
    name = KFWheel  //the name of the module being manipulated along with the scale module.
    <your parameter name here> = <your desired factor here>
    <etc.> = <etc.>
}

This is another way that exponents can be defined in the part itself, or the MM patch to plug it into the part:

MODULE
{
    name = TweakScale
    type = IR_RoboticDocking
    TWEAKSCALEEXPONENTS
    {
        mass = 0.0125, 0.025, 0.05
    }
}

In this example, the mass has three values which correspond with the first three scale factors defined in the scale type. This way specific exponential factors can be defined for fine tuning performance for a specific scale. I believe this can be done in the previous example as well.

Then, finally is your own implementation for the part itself which comes in the simple form of:

MODULE
{
    name = TweakScale
    type = KFwheel  //corresponding to your scale type
    defaultScale = 1  //for specific scale-settings that override the scale type.
}

You can override any values in the scale type, and even the exponents as shown in the IR example, by placing them in the module for the part. The most common is "defaultScale" for parts that fall in line with traditional scaling factors for stack rocket parts. In the KF situation, it might be useful to set the really large wheels to default at scale 5 or something, since you'd want to give users the flexibility of scaling those down a ton, but don't necessarily want to account for KSC-sized super-wheels when they are scaled from 1 to 6 where 1 is equal to their current size. I believe tweakscale scales all the other values that control scaling as if the default was actually at the value of 6, and doesn't simply scale the part to 6x upon being loaded. I have not confirmed this, but it seems to not do anything weird when I set up my own custom scale factors.

Hope this helps somebody out there. Also worth noting is that repulsors of both types seem to function out of the box with tweakscale, but you may want to look into any specific factors on their functionality you might want to tweak with their scale. Perhaps you could scale their max/minimum height range based on their scale, and energy usage as well. I believe that scale exponents can attach to anything that is definable in a part config, as long as you specify the module that it is manipulating.

Edited November 15, 2014 by Gaalidas

[AccidentalDisassembly]

You can define your own exponents in a separate config. That's the nice thing about these custom nodes, you can define them anywhere (inside or outside of a part, below a part in the same file, a completely separate file, an MM patch to insert them into the official file) it really doesn't matter at all, as long as the formatting is done correctly. For instance, if you look at IR they have some specific code for their use that makes use of a Tweakscale redistributable and they have their own exponent definition file, plus some separate exponent definitions in a few of the specific parts. These are sometimes defined as a separate node in the part config, and sometimes they are defined in the tweakscale node itself. I've even seen two of them in one part file, one for generic exponents and one for a specific module.

On the other hand, there have been a lot of weird things to happen and it's a bit hard to track down if you do not have all of your tweakscale modules in a single MM patch, and your exponents in a separate config on the side. It might be a good idea to look into the ways that a plugin-writer can interface with tweakscale as well for your more complicated needs. Also worth noting is that Tweakscale is being actively developed. They recently updated it with compatibility for the FS fuel switching module.

On the topic of symmetry issues, I always find it a good practice to remove my symmetry one I am happy with the product and ready to launch with scaled or painted parts. I use "PartWizard" to switch off, or optionally re-group, my symmetrical parts to ensure launch stability. I even took at 8x symmetrical arm-piece and separated it into two 4x symmetrical groups to aid in creating a probe out of the PunyProbe parts which had four prop engines and four monoprop engines staggered around the central core. The reason I had to use PartWizard to pull this off was that I was using a modified thrust plate adapter (tweakable node size/number/offset on a flat plate of tweakable size itself) to provide stack nodes to attach the arms to. In an 8-node configuration I had a node for each of my two sets of four engines. When placing different connections to those arm pieces, I was being forced to use 8x symmetry. After re-grouping them I could create the two sets separately while still, technically, arrayed in 8x symmetry. Normally, I would have had to rely solely on surface attachment do pull this off, which is sometimes unreliable.

I may not be an ingenious pod-racer builder but I do have some mad skills with all these little tools and such.

IR is a big mess when it comes to the tweakscale stuff - so sad, too, I wish I could make absolutely enormous IR parts without having everything go haywire. TS stuff written into every single part CFG. You are absolutely right it is far, far better to put everything you need in an MM patch!

Reason I bring it up is that IR defines individual TWEAKSCALEEXPONENTS values for most modules in those part CFGs, inside individual TS MODULE{} things, as opposed to defining just a few different types and basing them on an exponent. Whatever you do, don't integrate tweakscale into the wheels in such a way that you have to define every single value for a given variable at every scale - pretty please!

EDIT: Also, to be clear about what was happening in the video I posted, the wheels are NOT catching on some terrain feature. That lurch happens when you steer after having built up some speed. Steering from a stop is fine, steering as you accelerate is fine, but if you steer after you are moving straight ahead at reasonably fast speeds, hitting A or D will cause an apparent insta-brake on one side of the vehicle or the other (maybe?). Closer you are to top speed, more violent the lurch.

Edited November 15, 2014 by AccidentalDisassembly

[Gaalidas]

Note, I edited my last post with a lot of useful stuff, some of which might help explain what is being discussed about super-brakes on turning and whatnot.

Edited November 15, 2014 by Gaalidas

[AccidentalDisassembly]

Note, I edited my last post with a lot of useful stuff, some of which might help explain what is being discussed about super-brakes on turning and whatnot.

Saw it - The one thing I would recommend is simply that when lo-fi settles on variable names and whatnot, the TWEAKSCALEEXPONENTS be defined inside the SCALETYPE that is applied to wheels/tracks or that it be defined globally (like TS does in ScaleExponents.cfg). If you do this in an individual part:

MODULE

{

name = TweakScale

type = IR_RoboticDocking

TWEAKSCALEEXPONENTS

{

mass = 0.0125, 0.025, 0.05

}

}

And actually if you do individual definitions for masses or any variable, in general:

TWEAKSCALEEXPONENTS

{

mass = 0.0125, 0.025, 0.05

}

You have to update that list of masses every time you add a new rescaleFactor to the SCALETYPE. It's really annoying, it's what IR does, it's very difficult to work with for people like me that don't always like the particular choices someone makes about the exact sizes their parts ought to be. The number of masses there has to equal the number of rescaleFactor definitions, is my impression, or things get real weird real fast. But I could be wrong on that!

EDIT: also tried the crazy lurching problem with non-scaled tracks, and it seems to work fine. So maybe whatever force is responsible for causing steering to happen is simply being scaled inappropriately right now with TweakScale - seems plausible...

Edited November 15, 2014 by AccidentalDisassembly

[lo-fi]

Thanks guys!

Seems clear I would need to add some more stuff into the plugin to deal with the catching issues, I know exactly what's going on there now. Unity wheel colliders 'torque' is actually just force, not force over moment. The tracks have to apply quite a strong braking force on the inside track to turn, so when scaled up this will give an epic force. Not good, and will require some thinking about. If it's too much of a pain I'll just write it off as a no-go - it may be simpler to make separate configs for larger or smaller parts or just write a part chooser than mess about with the plugin and MM patches I don't want to maintain for a dependency I don't want to distribute.

Edited November 16, 2014 by lo-fi

[Gaalidas]

I hear you on the updating of specific parameters for the scale factors. That was the main reason why people had problems making IR parts larger than they were intended. I fixed that on my local install by adding another set in their exponents for the ExtraLarge scale factor I wanted to introduce. Without adding another set to the exponents I'd have been stuck with a really slow joint for the extralarge parts.

Though, I must admit that after all that trouble to fix everything for that larger size, I've never actually used it.

So, in reality...

The number of masses there has to equal the number of rescaleFactor definitions, is my impression, or things get real weird real fast. But I could be wrong on that!

In this you are absolutely correct. It'll work, sorta, but it'll be really wonky in some situations.

It's just something to keep in mind, lo-fi. You've got your hands full already with all the crazy stuff you're developing. I wouldn't write anything off and a no-go just yet. Lets get these babies into a beta stage before we worry about making them compatible with other modifications. The important thing is that they work with their natively intended scales and configurations.

Edited November 16, 2014 by Gaalidas

[lo-fi]

The important thing is that they work with their natively intended scales and configurations.

I think you're absolutely right there. I'm at least going to wait until the issues with TS are fixed, it just makes it too hard trying to work out if it's something I've messed up or a bug in TS. Probably a lot of messing required to get it working properly anyway - from experience, the Unity wheel colliders don't react well to be scaled.

[AccidentalDisassembly]

I hear you on the updating of specific parameters for the scale factors. That was the main reason why people had problems making IR parts larger than they were intended. I fixed that on my local install by adding another set in their exponents for the ExtraLarge scale factor I wanted to introduce. Without adding another set to the exponents I'd have been stuck with a really slow joint for the extralarge parts.

Though, I must admit that after all that trouble to fix everything for that larger size, I've never actually used it.

So, in reality...

In this you are absolutely correct. It'll work, sorta, but it'll be really wonky in some situations.

It's just something to keep in mind, lo-fi. You've got your hands full already with all the crazy stuff you're developing. I wouldn't write anything off and a no-go just yet. Lets get these babies into a beta stage before we worry about making them compatible with other modifications. The important thing is that they work with their natively intended scales and configurations.

I've tried using an MM patch to duplicate IR parts and create large versions (8x scale, so they could then be scaled down to 4x and 2x) but have really spotty luck with it. Some of them seem to work, sometimes, and then something happens so that a gantry stops using its full range of motion or a rotatron won't move. Still haven't figured it out =(

[lo-fi]

Knowing what little I do about it, what TS does is not straightforward. Thinking about it, and looking back at that screen grab I posted, I reckon there is an error that doesn't show up in the logs. On the wheels that didn't scale, TS had moved their positions ready to be scaled, but hadn't actually done so. Also, the variable in my module had not been changed, so this tells me something went wrong in the program flow and TS went "meh", shrugged its shoulders in a fashion only the French usually know how to do and went to have a pint on work time. I'm not going to go code diving, because I'll want to try and fix it!

[Gaalidas]

That's the danger of code diving other people's work. You always need to fix everything.

[lo-fi]

There's a new version out, which I tried. It now wants to make wheels the root part, unmountable and unselectable. Let's just hang that on the fridge and forget about it.

Not much will happen this week, I have a ridiculous amount of work to do. Happy Kerbal throwing, guys

[Gaalidas]

Wait, does that mean you have a life outside of Kerbal Foundries? I'm shocked.

[lo-fi]

Lol. About the only thing I'm not involved in at the moment is sleeping.

[jediKatana]

I actually use the repulsors in all the spaceplanes I make. They're far superior to landing gears. I can barely wait for the beta!

EDIT: I just realized none of the wheels work. They just say low charge.

Edited November 18, 2014 by jediKatana

[Madrias]

Would probably be hard to sleep, being there at the Kerbal Space Center. Heard rumors that Jeb tried to land a Mainsail powered rocket on the roof of the VAB this morning.

[Gaalidas]

That was only half of it. The engine was a mainsail, and Jeb was at the controls, but what they didn't include in the report was the large tank of fuel hanging precariously off of a half-broken truss that Jeb apparently clipped a type B asteroid with. This thing was ready to fall off at any moment, and it was structurally compromised, so the chances of a catastrophic fuel leak, or worse an explosion, were pretty high. I won't estimate the damages, or any fatalities, at this time... lets just say the VAB is safe for the time being, and Jeb is napping in the corner surrounded by debris from the cleanup. The ground keepers are gonna be royally displeased.

[lo-fi]

You have no idea how much we've had to bribe the cleanup crews to keep on working. It's the fifth time this month. Funny you should mention using the repulsors as landing gear, JediKatana.. The amount of space plane debris that's piling up at the end of the runway is phenomenal; Jeb keeps using them and forgetting to add enough batteries. He lands, throttles down, and Kaboom! It's all well and dandy while at full throttle trying to buzz the new intern at the front desk of the admin building in an inverted dive, but as soon as he figured out that it's acceptable to throttle down for landing, and the alternators don't kick out so much charge all hell has broken loose. Still, at least there is no penalty for his crazy designs that simply won't take off, reach the end of the runway and swan dive off like an entrant to the Red Bull pier jump. We have a boat standing by about a mile offshore just in case wings become 'sissy' and fall out of fashion again. Still, never a dull moment.