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

[Gaalidas]

No need to vote, guys. The linked config that started this discussion is is the MM patch that I've been updating in the wheel config repository. The MM patch has been a thing for a long time, just not officially released. I even recently updated it to include the DustFX module, which will be functional once we release 1.9 of KF.

Unfortunately, we never actually implemented a damage and repair system into the KF modules so, for the time being, this effectively makes the wheels indestructible (as far as the functionality that is, not the whole part). You can still break the entire part in the usual way, but the wheel won't require any repair work while on the field.

The rest is a brainstorm session:

The only way we could make using KF with the stock wheels any easier is if we found some way to hot-swap the control modules being used for the wheels. There's another mod being developed out there, though I forget the name of it, which is attempting to create a system for being able to swap out the modules that are active on a part in conjunction with a texture/mesh/fuel-capacity swap that we've already seen done in several ways. I'm waiting for that development to make a working appearance before I start to brainstorm ways to use it for our purposes. In theory, we could then keep the stock modules on the part and simply add our modules at the end of the config, then set up a module that would reference the different modules much the same way that the mirror modules in KF can reference the mesh objects by name, and then swap them. Alternatively, if this development never sees daylight, we might be able to mimic stock wheel functionality and put a swapper module to swap out the config variables between KF behavior and pseudo-stock behavior. Or, maybe simply set up another switch in the settings GUI that would simply, upon being created in the editor/flight, just remove all the KF modules from the part and leave the stock ones alone. In this same way we could have it simply remove offending modules from the stock wheels during the running of the game much like we can add DustFX to a part if the wheel collides with something and doesn't find the DustFX module present. Lots of different ways to handle stock wheels.

For the time being, an MM patch is the easiest way to make it happen.

Edited July 31, 2015 by Gaalidas

[V8jester]

No need to vote, guys. The linked config that started this discussion is is the MM patch that I've been updating in the wheel config repository. The MM patch has been a thing for a long time, just not officially released. I even recently updated it to include the DustFX module, which will be functional once we release 1.9 of KF.

Thanks Gaalidas

[lo-fi]

Bah. Forum keeps losing my posts!

MM patch, just remove stock modules and add KF. Won't be a problem

Damage been talked about, but won't make it into 1.9. Will be progressive, so prolonged heating will affect motor power, abused suspension will get glitchy. Stuff like that. Not just magically break, dig into the ground and flip the rover over..

Thanks guys!

[smjjames]

Regarding the damage stuff, wasn't wheel damage mentioned in the devlogs? Might be something to hold off on until 1.1. Though I'm not sure what SQUAD is doing with the wheel damag stuff. Maybe I'll try to find it.

found it: http://forum.kerbalspaceprogram.com/threads/128067-Devnote-Tuesday-Chugging-Along

Edited August 1, 2015 by smjjames

[Gaalidas]

MM patch, just remove stock modules and add KF. Won't be a problem

Like I said, already did that a long time ago.

[renePRO]

thanks for this mod i love it:kiss:

[Gaalidas]

So, I've something to report. I tried this with two different sets of wheels and in two different locations around Kerbin and it's not looking great. First off, it looks like neither context menu nor action group control of the suspension height (aka ride height) is working. The wheels sit at the same height no matter what I do. Secondly, while under power (so, while the W key is held down, not when just cruising) I'm getting a strange rotation of the vehicle. It's not always the same direction either, but both powered forward and backward movement seems to not go quite straight even when on a flat surface.

So, I'm unsure if this is a problem with the code, the model, or something else entirely.

[LitaAlto]

The second Kerbal Foundries vs KerbinSide Air-Race challenge has now begun! Details at http://forum.kerbalspaceprogram.com/threads/130403

[lo-fi]

In both cases, it's possible I broke something. The rotation is not something I'd noticed, so I'll try to replicate. Which wheels?

Thanks, renePRO, that's quite impressive. TT wheels on that?

- - - Updated - - -

Lita! As ever, that's brilliant!

[Gaalidas]

In both cases, it's possible I broke something. The rotation is not something I'd noticed, so I'll try to replicate. Which wheels?

I tried it with both the small wheels and the medium wheels, but I also noticed a while back that the medium track wasn't responding to height changes either. I didn't test all the parts for the rotation thing. It's very subtle, and it took me a few various tests to even notice it. I even tried to take into consideration if I was on an incline or not, but it doesn't seem to matter.

[lo-fi]

I guess I broke the height update. The turning I'm not so sure about - certainly odd..

EDIT: Yes, I broke the height update. Will fix. Think I know what's going on with the wonky steering: I bet you'll find that it doesn't happen until you steer for the first time? Won't be hard to fix either

Edited August 2, 2015 by lo-fi

[renePRO]

In both cases, it's possible I broke something. The rotation is not something I'd noticed, so I'll try to replicate. Which wheels?

Thanks, renePRO, that's quite impressive. TT wheels on that?

- - - Updated - - -

Lita! As ever, that's brilliant!

:confused:that wheels are not from this mod? (still love it)

[lo-fi]

Lol! That is quite funny. Nice video, though

[Gaalidas]

It's an easy mistake to make with all these wheel mods everywhere. Especially considering lo-fi could probably convert all those wheels to use this mod.

I'll try it again and see what happens before steering. It seems to me that if we had it working properly a while back, we should be able to compare what's changed.

One thought I had about the steering is that it could have something to do with some wonky alignment considering both of the vehicles I tried. I should really give them a try on the ERS system. I never had steering problems with that.

EDIT: Had a wild laugh after seeing your comment on one of the SharpDevelop suppression comments. Those help me when I'm editing the code. SharpDevelop analyses the source for places where something could be converted to a simpler form. As I've discovered while simplifying some of Aqua's stuff, the simple form often doesn't work quite the same. So, for cases where I either cannot read the simplified form, or the simplified form has changed the function in an unexpected way, I add a suppression into the code. I try to turn them into class-wide suppressions when I can, but I often forget to do that, and sometimes a global suppression doesn't fully take for things like suggestions for static methods and such. I'll try to go through and clean some of that up. All that means is that the suppressions will loose the "once" in them and I'll move them to the top of the class where they can suppress every case of that suggestion all at once.

But first... fix that stuff you broke. Dooo eeeeet! Naaaaooooow! -waves hands in the air like he's completely nuts-

Edited August 2, 2015 by Gaalidas

[*Aqua*]

I don't write complex code! I swear!

I wonder what's your opinion on the architecture discussion between lo-fi and I. Do you think my proposal makes things better or worse? Yeah I know you don't have the same programming experience I have but that doesn't matter. If we choose to implement what I suggested you'll be affected by that, too.

[lo-fi]

Apologies, I will get back to that! I've been looking at it, and I can see what you're aiming at. Whether it's better, as flexible or worth the work to re-write it, I have yet to be convinced. I think what you're describing is probably how the stock module works. One of the worries I have is that it will involve a lot of custom config node work, which means there's room for error. I can foresee a lot of time spent hunting down what wrong when loading nodes, instantiating classes and so-on, where at the moment, KSP does all the hard work setting the various different bits up as PartModules. That bit of it is simple, it's rock solid; I like that.

I need to flesh out my architecture so you can understand why I did what I did. Some of it is out of date, other bits are speed hacks.

Maybe you could set up a dummy framework for how you envisage the base and abstract classes, how they're defined in the config and how they handle startup routines, etc? Though I'm not sure whether that's a lot of work, or not?

Gaalidas: I had it fixed ages ago, just forgot to commit.

[*Aqua*]

A dummy framework? Hm... it's not difficult but it'll need a bit of time. And I'll probably leave out the mechanics (steering, braking, etc.).

One of the worries I have is that it will involve a lot of custom config node work

I'm pretty sure it's possible to let KSP load and save the states of the new classes by simply adding [KSPField] or something similiar to them.

Although I still haven't checked all the capatibilities of KSPField yet.

I need to flesh out my architecture so you can understand why I did what I did.

If you have time a simple flowchart will be enough for me (one box per method call, don't make it too fancy!). I'm interested in how the suspension and the steering works (especially the interactions between KFMW <-> KFSteering & KFMW <-> KFSuspension).

Maybe I have a tunnel vision about that topic. In school there was never a question about other architectures and designs. My fellow students and I learned what the Gang of Four (they are famous!) wrote about design patterns and it was out of the question to ignore them! And now I'm sitting before code which doesn't always follow the designs I learned and am completely lost. ^^

[Gaalidas]

Gaalidas: I had it fixed ages ago, just forgot to commit.

Bah! I assume you've committed it by now?

Alright, so what's this about a framework of some sort? I think I've missed the entire discussion.

- - - Updated - - -

And now I'm sitting before code which doesn't always follow the designs I learned and am completely lost. ^^

We do that just to annoy you. Is it working?

In other news, I'm going to do a quick test but after that I may be ready to commit a new toggle to our GUI to enable/disable the repulsor lights. The lights were the remaining item that was not actually handled on it's own. Granted, if the dust effects toggle controlled the lights too, and auto-toggling related items when the parent item is enabled/disabled will be something to do later. I had something of that sort working a while back, but it broke at some point and I haven't bothered to try and revive it.

Edited August 3, 2015 by Gaalidas

[sashan]

Is the memory footprint still at 150mb? Or is it fixed?

[lo-fi]

About 50meg now, I think.

I'll write some documentation, Aqua. It needs doing anyway!

Good plan with the light toggle, I hadn't got that far with them!

[damerell]

Secondly, while under power (so, while the W key is held down, not when just cruising) I'm getting a strange rotation of the vehicle.

I don't wish to be Captain Obvious, but I'm surprised that you seem to be using the forward-and-pitch key and not the separately bindable keys for rover movement alone. (Perhaps I am mistaken and you have rebound the keys more extensively).

[ThorBeorn]

I don't wish to be Captain Obvious, but I'm surprised that you seem to be using the forward-and-pitch key and not the separately bindable keys for rover movement alone. (Perhaps I am mistaken and you have rebound the keys more extensively).

I think using throttle (shift, ctrl, x and z) controls would be great. That would make it easier to use KF wheels as landing gear. And you would also have more control of the throttle, less of the ON/OFF thing.

[Kenobi McCormick]

With the digital nature of the control input, irs a bit of a trade off between flipping over and turning a decent amount. Low speed could maybe do with a tweak, though.

I 'spose so, but I imagine most people have at least a 360 pad or something lying around. I used to use one myself, nowadays I use a Dual-Shock 3.

[Gaalidas]

I don't wish to be Captain Obvious, but I'm surprised that you seem to be using the forward-and-pitch key and not the separately bindable keys for rover movement alone. (Perhaps I am mistaken and you have rebound the keys more extensively).

The idea is to keep things simple for the end user. Most rovers created with KSP use the standard WASD key setup for control. With the exception of some repulsors (where sometimes you need to use WQSE instead) we try to keep things as simple as possible. The toggle-option to swap that for a throttle control would be interesting I'll admit, like a cruise control system, with an emergency override key that would disable the throttle on the wheels and return to standard controls. it would be a bit like the auto-run in some MMORPGs out there, where if you don't touch the forward/backward buttons it will continue running, otherwise it will cancel it. In this case we'll have the added ability to modify the speed of the auto-run. In the end, however, making this mod usable right out of the box for a new user is a must. Any alternate control schemes need to be optional add-ons.

Also, I hereby dub you "Captain Obvious" along with all the responsibilities that come with the title. There will be therapy programs made available to you if you survive the mob we've assembled outside to cheer you on as you exit the premises. Good luck.

In other news... lo-fi... I did some testing last night and it seems the auto update for the repulsor height is broken. I'm going to take a look at the action group settings if I get a chance later. The repulsor lights seem to be a very intermittent thing, not at all reliable in any way. I have a feeling it might be due to the point light limits though, and I'm thinking a test with vertex lighting might be a good idea, which I've prepared a test DLL to try.

EDIT: Okay, so I did a test and vertex lighting seems pretty nice, other than the fact that it doesn't seem to play nice with being a directional light and it would ened the intensity turned up. My new toggle for the lights did not function at all, and the DustFX toggle also has no effect on the repulsors. The only toggle which works on the repulsors is the camera enable/disable. Also, I've noticed that the camera toggle changes not only the colors, but some other things about the particles as well. They appear thicker, and possibly larger. I'm investigating, but unsure where the problem is. Also, I got the repulsors to auto-update with each action group hit, but instead of each repulsor updating on its own like the wheels do, it updates all repulsors by the same interval resulting in, for instance on a craft with 6 repulsors, a change of 30 instead of a change of 5. I think maybe an overhaul of that part of the code needs to happen to fix this once and for all.

Edited August 3, 2015 by Gaalidas

[lo-fi]

Hard coding alternate keys is a really bad idea. As Gaalidas points out, the defaults are what most people are used to, unless you've gone to the trouble of remapping them. I can see the "URGENT: wheels no work!!! Plz I really need this mod. Plz help!!!" Support posts piling in now. People never read instructions... I still curse squad for that default mapping, though.

I just try driving with a gamepad sometime!

I've not tried the repulsors AG height update for a while, always use rcm. Worth checking! The lights are intermittent because they're bound to the hit point of the collider, which is sometimes a shade below the surface of the terrain collider. Nothing sinister, and I thought it was quite cool them being a little quirky, so I left like that.