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

[riocrokite]

yah, i'll be interested in rock spawner too but later on

as for surface bucket wheel operation is now best described as 'choppy' I don't code however I'll need to start to

I'll have to rig it as a deployable wheel sooner or later since it's too low for KF wheels and to high for IR wheels

[lo-fi]

Brilliant. Yeah, you need some way of modifying the height, don't you! You can definitely rig that up as a KF "Wheel", though there's a cunning options which I added for IR rework which removes all the control input and tweakables so it won't appear as such, other than setting up the colliders and making dust.

[Gaalidas]

At the moment, it's mapped to the numpad. 8,2 4,6 1,9 move it around linearly, then if you hold alt, 8,2 4,6 1,3 rotate. GUI is too fiddly, mouse control might be a little too inaccurate. I don't like explicit mapping, but will be tough to get around. I'll merge into the dev branch later so you can have a play, but it's still to be considered "experimental".

Moving the increment slider to the GUI sounds like and ideal solution! A debug toggle would be good too - could make a lot of use of that! Adding some extra methods into the KFLog class which only print to the log if it's enabled could be really useful.

That's definitely a KF bug, I'm sorry to say. I thought b had at least fixed that, but apparently not. I'm happy with the temporary one, which I've been testing myself, so I think I'll send that out to KerbalStuff and put and end to the wayward vessel modules and random colliders!

I keep enabling the water slider because I want to see where the damn thing has ended up! I'm quite glad I did, it's been handy knowing that it's been appearing where it shouldn't, though the GUI debug toggle would be perfect for that.

I'll get to work on something like that as soon as I can and we'll get this on/off business buried.

I'll do a little research on some of the mods I use which feature remapping for keys as well, which could help with your little numpad thing.

- - - Updated - - -

well ideally I would like to set up bucket wheel like a deployable wheel, but for now it is just a collider with animation. if it were a wheel would it be possible for it to generate dust with no speed as well?

The repulsors currently generate dust without even moving, though that's just a hack where the speed is replaced with the repulsor force. Still, it can be done. Alternatively you could just put your own plugin together for it. I'm not super attached to the code considering it started out as a totally separate mod that I didn't even make. All of our work is based on interaction with the biomes of a planet and a wheel-like object though.

Edited August 21, 2015 by Gaalidas

[lo-fi]

I wouldn't worry too much about it just yet, there's a lot of work needs doing before it gets to that stage!

I need to finish some wheels and the rollcage too.

[Gaalidas]

Okay, weirdness ensues!

So, I got a working slider into the GUI that rounds itself to the nearest whole number (so we don't get change rates of 2.0012658701 or ride height, which would be nuts.) and it all works great... except if you select a number that isn't within the rule of fives (5, 10, 15, 20, etc...) in which case it does some really strange stuff. One such effect is that not all the repulsors will update. Another is that they will all update, but instead of changing by, for example, 2 they will instead change by 5. On one occasion I even managed to mess it up enough that instead of the repulsors turning off at height of zero, I had to hit the button once more so that all the height sliders reported -1 before they would shut off completely.

I do, however, have a theory as to why this is happening and I think it has to do with the context slider that is attached to the ride height variable. Since the KSPField that contains the slider for the context menu is set to an interval of 5, then setting a requested interval of anything other than a rule-of-five will either fail or have varying results because it is trying to limit the end value to that interval. I thought, before doing this experiment, that the min/max ride height was a free slide between those two values and the interval would only affect the change rate. Instead it actually locks the values to that interval in relation to the min/max. That's why the old implementation of this feature worked, because the interval for the field was also changed to match on every part on the craft with that field present on it.

So, I'm hit with a bit of an issue. KSPField sliders can be set to an interval like that, but GUI sliders don't have such a feature. I can set the value to round to the nearest whole number (nearest int to be precise, but it seems to work for any data type that takes numerical input) but I have no way of rounding to the nearest 5th int. Alternatively, I could change the context slider to take intervals of 1. Second alternative would be to actually set the sliders for every part on the current craft to match the interval in the GUI, or do the opposite and have every part check on their fixed update (or whatever is available) against the persistent variable and reset their sliders to match. in the end it may turn out to be more hacky than the original implementation, but with some fiddling I'm sure I can get it to work properly. If only we had a "Mathf" method similar to "Round(float x, float y)" to let me round the value x to the nearest y then this would be so much easier. That would also let me make your dust amount slider a little more friendly by rounding to the nearest 0.25 since the current huge decimal is a bit of an overkill.

In other news, I couldn't seem to get the repulsor lights to turn off no matter what I switched on or off. I think something got broken somewhere down the line in our frenzy to fix that dusty bug.

EDIT: Great Jebediah's Ghost (and he ain't even dead yet) I think I've got it! I'm not ready to share the details, cause the math is rather... for me anyway. Besides, I think I can merge my two extension methods into a single method... and that should fix all our problems... at least in relation to this post.

UPDATE: It all works. I added a new method to the Extensions class that allows me to round to the nearest nth numeral. What this means is that we can round to the nearest 5th, 10th, or even the nearest 0.5, or 0.25, you name it. If the number to round to is between 0 and 1, then it simply multiplies that number by 10 and treats it like a divisor. Otherwise it treads the number (1 or greater) as a multiplier and then does the rounding process depending on which (divisor or multiplier) has been determined. So, to round to the nearest 5th, you enter 5 into the "roundto" parameter and it does something like "Math.Round(num / 5) * 5" which outputs the "num" rounded to the nearest "5" value. For a decimal round it's more complicated. You enter something like "0.25" for "roundto" and it first detects that we're dealing with a decimal level and it multiplies that by 10, which doesn't eliminate the decimal but it makes it easier to work with when dealing with the standard "Round" method which only rounds to the nearest whole number. 0.25 * 10 = 2.5. You end up with something like "(Math.Round((num * 10) / 2.5) * 2.5) / 10" which outputs the nearest "0.25" to the input "num." I've done each of these calculations with over a dozen input by hand (okay, not quite by hand, but using "calc.exe" step by step) with over a dozen different "roundto" targets with perfect results, so I've integrated the new method into the GUI sliders and, from what I can tell from testing it thoroughly, all is working perfectly. It's a relatively simple way of duplicating the functionality of the context-menu sliders (at least the interval/min/max parameters of them).

I'll be committing the new stuff shortly. Work on an unfolding debug menu to attach to the GUI settings menu is still a work in progress, but I think I'm close to the solution.

Edited August 22, 2015 by Gaalidas

[Enceos]

Hi lo-fi, would you please explain the meaning of numbers in the steeringCurve section of ModuleWheel.

[Gaalidas]

There are two types of steering curves: brake and torque. Under torque you have two numbers per key which represent craft torque and turning strength (correct me if I'm wrong lo-fi). The higher the torque, the lower the turning strength so you don't end up flipping your craft over. Brake turning is similar, except that you have a positive and negative side to the curve which represents a balance between the direction of steering. positive represents one way, negative the other. Which is which is a mystery to me. Either way, the effect is much the same. The first number would be the braking torque and the second would be the turning strength. So, if you wanted to increase the turning strength for higher torque ratings, you could simply increase the second number in the torque steering for each key's first number, and in brake steering you could simply increase the value of the absolute of each side of the curve (leaving zero alone in the middle) and that would likely do it.

It's not the most intuitive thing, but it's not hard to figure out with some fiddling.

[Enceos]

There are two types of steering curves: brake and torque. Under torque you have two numbers per key which represent craft torque and turning strength (correct me if I'm wrong lo-fi). The higher the torque, the lower the turning strength so you don't end up flipping your craft over. Brake turning is similar, except that you have a positive and negative side to the curve which represents a balance between the direction of steering. positive represents one way, negative the other. Which is which is a mystery to me. Either way, the effect is much the same. The first number would be the braking torque and the second would be the turning strength. So, if you wanted to increase the turning strength for higher torque ratings, you could simply increase the second number in the torque steering for each key's first number, and in brake steering you could simply increase the value of the absolute of each side of the curve (leaving zero alone in the middle) and that would likely do it.

It's not the most intuitive thing, but it's not hard to figure out with some fiddling.

Don't the key numbers in steeringCurve represent the speed and the wheel angle? What kinds of units represent the X axis and the Y axis of this curve?

Edited August 22, 2015 by Enceos

[Gaalidas]

I really don't have all the answers myself, so we'll have to wait for lo-fi to give us the real answer. But, essentially, yes the numbers represent speed and angle. However, float curves are used in many different applications and so I have attempted to define them in more generic terms. For instance, if brake steering were a "speed to turn angle" type of thing, then it's basically saying that at zero speed, no turning, and the higher the speed the more turning you get. That simply is not the case. For torque steering, the more accurate way to describe it is "torque to turn angle" and not necessarily "speed to turn angle" and in the case of that curve, it doesn't account for both directions but simply uses the same angle for both turn directions. The reason for the extra detail in the brake steering I believe is because it needs to somehow balance the effect since, essentially, you're braking one side of the craft slightly to cause the craft to turn.

I'm a novice at all this stuff though, so I make not be on top of things very well. I generally leave those curves alone. I've been known to dabble in the torque curves, but that's it. I'm absolutely clueless about the four-part curves.

As for units... your guess is as good as mine. I always figured that it's all relative to whatever unit it's manipulating in KSP. For speed, it's a 1:1 relationship with m/s. For torque and braking force, again it's going to be a 1:1 relationship with the KSP defaults. To get a better idea of what is what, you'd have to look at what Squad put into the stock modules/parts and scale it from there. There's probably a detailed explanation of units and how they are represented in KSP and how they're scaled from the real-world counterparts, but I don't know where to look really.

Edited August 22, 2015 by Gaalidas

[lo-fi]

If you're asking about the stock module or KF configured as wheels, then the first unit is speed, the second is angle in steeringCurve.

Configured as tank steer, as the tracks are, torqueSteeringCurve defines differential torque at a given speed. This is for low speed in the spot turning. brakeSteeringCurve defines steering behaviour at high speed by specifying braking torque to apply to the inside track. Stock uses steeringCurve for tank steer mode, though the implementation used to be quite buggy and always pull one way. Units will be torque, the same as torqueCurve.

You'll find a YouTube I made listed in the dev links thread, it explains stock module in detail. If you want to set something up with KF, feel free to ask and I'll do my best to explain.

[Enceos]

Thank you very much for your explanation. I was tweaking the Critter Crawler by BahamutoD to be more agile while still stable and not jumpy. I'll take a look at your vid.

Edit: since the beginning the Critter Crawler is walking backwards while I press the Forward (W) button,

what's wrong in the default config which does that? Steering direction is ok.

    controlAxisType = Up (if I make this Forward, then steering becomes inversed)
    steeringModeType = ManualSteer
    brakeTorque = 8
    brakeSpeed = 1.5
    impactTolerance = 200
    overSpeedDamage = 60
    WHEEL
    {
        wheelName = wheel
        wheelColliderName = wheelCollider
        suspensionTransformName = suspensionTraverse
        suspensionNeutralPointName = suspensionNeutralPoint
        //damagedObjectName = bustedwheel
        rotateX = 0
        rotateY = 0
        rotateZ = 0
    }

Edited August 22, 2015 by Enceos

[lo-fi]

Hmmm. IIRC, it uses some of the stock module to active the colliders, then layers some stuff over the top. Try setting the torque values all negative; that's probably a good fix in this situation. Leave the speed values positive, of course.

[Enceos]

Negative torque worked like a charm, thank you lo-fi, who knew we can do that. I didn't notice before, but Critter Crawler has 6 wheel modules. Effect becomes noticeable when I change values in all of them.

Edited August 23, 2015 by Enceos

[lo-fi]

No worries, glad it worked

[Gaalidas]

So, I was doing some testing last night and that strange rotation while roving about still exists to some extent. It seemed to subside after a little while, especially when I got up to speed a bit more, but at slower speeds it was still noticeable.

In other news, The debug options thingie works, but the debug option itself does not. I can set the variable for whether or not to show the collider for the water slider, but it doesn't actually become visible when setting that. While typing this, however, I started thinking... if I'm changing the value of something that happens in the startup procedure, then it would all make sense. I probably need to be changing things in an update procedure. That would make more sense.

I think I re-fixed the repulsor lights turning off when the repulsor becomes inactive. Had to insert a check for the ride height of the repulsor into the on/off state of the light itself.

[sashan]

Negative torque worked like a charm, thank you lo-fi, who knew we can do that. I didn't notice before, but Critter Crawler has 6 wheel modules. Effect becomes noticeable when I change values in all of them.

Can you share a config?

[riocrokite]

hello,

just couple of observations (I use new version of KF tracks for testing new parts of my mods). Maneuvering using 2 tracks (long etc) is really not precise now (I guess due to delayed torque change?). Thus it's hard to use tracks for precise crane movements.

Edited August 25, 2015 by riocrokite

[lo-fi]

Hehe. Your suggestion of making them react realistically to the mass of the vessel they're moving is party to blame - it makes control far less 'wooden feeling. I also opted to smooth the control inputs a little, which makes them a bit more stable to control at the expense of some precision. I've driven a few tracked vehicles (tanks included) - they are not precision instruments IRL - so I decided to go with it. You can adjust the smoothing in the configs though, which may help. smoothSpeed sets how quickly the control inputs react.

[riocrokite]

Hehe. Your suggestion of making them react realistically to the mass of the vessel they're moving is party to blame - it makes control far less 'wooden feeling. I also opted to smooth the control inputs a little, which makes them a bit more stable to control at the expense of some precision. I've driven a few tracked vehicles (tanks included) - they are not precision instruments IRL - so I decided to go with it. You can adjust the smoothing in the configs though, which may help. smoothSpeed sets how quickly the control inputs react.

yah true, more realistic in this way:) this is why probably wheels are used for precision handling of stuff

edit: Anyway I'll experiment with smoothing since it makes it harder to control them at high speeds (!) and as mentioned above turn precisely.

Edited August 25, 2015 by riocrokite

[lo-fi]

Speeding up the smoothing will probably help. I could probably make an action group to toggle it on and off too.

[Gaalidas]

I wonder if that's also the cause of the strange rotation under power bug I've been experiencing again.

Also, if speeding up the smoothing also increases the accuracy, then I have an interesting idea as to how to implement a toggle for it. As you already know, KSP has a precision mode for things like RCS and throttle control (supposedly, I'm unsure if I've ever used it myself). So, if we could tab into that and toggle a bunch of limiters/enhancers when KSP goes into precision mode, we could reduce the need for specific action groups. I'm not saying an action group to toggle a precision mode wouldn't be useful, I'm just thinking if the feature already exists we could easily just tap into it.

The idea would be to boost the smooth speed, while reducing the turning speed so that slow and precise adjustments could be made when KSP is in precision mode.

We could also add a GUI option to enable a precision mode override for the KF parts alone.

This leads to another idea I had a while back for an "overdrive" mode which would basically increase resource consumption a ton while boosting the speed of the craft a ton for a short time, sorta like a nitro boost. That was also a reason to try and get a spark emitter integrated to simulate pushing the parts to their maximums. On that note, I tried to implement occasional sparks to the Screw drive like I was talking about, but could never get the sparks to actually emit.

EDIT: I'm getting close to a workable precision mode toggle both by the stock precision mode and by an override via action group. Exactly how much to modify the smooth speed modifier by is the next question, but that will be definable per-part in the end.

Currently working on fixing my stupid code that would double the smooth speed, but would keep doubling it until it hit infinity. On the up-side that test showed that a value of "infinity" would not spam errors and actually work still. I'll run another test when I get done later and commit it to github.

Edited August 25, 2015 by Gaalidas

[smjjames]

Question on the latest KF, what does the suspension step value do? It's available as an option in the editor.

Also, is anybody seeing this wierd leftwards turning issue? This is on the grassy area just off the runway and all I'm doing is pressing 'w' for forward.

Settings in editor:

Edited August 26, 2015 by smjjames

[Gaalidas]

Ah, so you're experiencing that too? I thought lo-fi killed it, but it's back! The suspension step actually won;t be in the editor anymore in the future, but it'll be found in the KF GUI. This controls the amount that the suspension height is increased/decreased when using the action groups to change the suspension height. feel free to mess around with it, but know that in the future it will be a GUI option rather than a part option, and will be much more stable.

Oddly enough, the rotation thing calmed down for me after a while and only seems to do anything in certain situations. I'll have a look at the commit history and see if I can figure out what lo-fi tweaked to fix it last time, but we're still at the mercy of lo-fi releasing another update. I was actually hoping that he'd address that before releasing again.

Edited August 26, 2015 by Gaalidas

[riocrokite]

yah I see turning issue too, I suspect it might have to do something with KSP shifting mass of the vehicle sometimes in weird directions (so balanced vehicle becomes unbalanced). In effect one wheel/track has higher movement resistance than other. Needs more testing (checking without mass resistance multiplier) since this theory might be false

edit: you can also check whether main parts are mass balanced, sometimes center of mass is slightly moved from the point it should be.

actually balance of the vehicle doesn't affect this issue. It's easiest to replicate this on runway. When you turn left and then go straight the vehicle will very slowly turn left. Similarly if you turn right, then vehicle will slowly turn right when going straight again.

edit2: for wheels one can increase smoothSpeed in cfg to like 20; it solves problem of changing direction (at the cost of sharp movements). for tracks matter is more complicated and cannot be simply resolved by changing aforementioned cfg.

edit3: Tested long tracks: increasing smoothSpeed resolves problem for 4 tracks, doesn't resolve this for 2 tracks.

edit4: noticed another issue: rig: 4 long tracks - torque setting:2, smoothspeed setting:2, speed: more than 20m/s: pressing brakes shortly result in compensation by forward acceleration. thus impulse breaking from top speed is ineffective maybe it has something to do with 'breaking' rev limit which is set on something like 23m/s and after that vehicle uncontrollably accelerates to 28m/s. brakes work ok under rev limit (in nominal zone).

Edited August 26, 2015 by riocrokite

[lo-fi]

Are you sure that's not SAS turning that craft? I've never been able to replicate that issue, and there's nothing in the code which adds random forces. Although... Have you mounted those structural parts sideways? The looks strikingly familiar to the ones SMJJames was struggling with when using tracks. In which case, some of your wheels may be going backwards!

Not sure what you mean about the braking?