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

[Gaalidas]

Ah, I see. I found that the lighting only showing up every few minutes when I got lucky was rather strange.

My post above has updated since you last saw it I think.

[lo-fi]

Hehe. I know exactly what you've done with the AG don't worry, I'll fix.

The repulsors dust module is a terrible, terminal bodge and should be destroyed! Which is my fault. The only thing that's stopped me doing so is figuring out what you added so I can build into the DustFX module, which is actually working as it should. Not sure about the particles, I don't think I messed with any of the emitter stuff when running the camera.

[Gaalidas]

I think maybe the camera stuff is simply because we're doing a bunch of math on the numbers which might be screwing up the alpha layer of the particles themselves... but that's jsut a guess. I also noticed something about the repulsor effect sound. Or rather, I didn't notice it, which is a problem. I notice in your code that on the update event you set the effect power to equal zero, and then you call the effect method and pass that value to it. That method then tries to divide that zero by the max effect (50) which is still, you guessed it, zero. In the end, we have a sound effect with a power of zero.

Anyway, I'm messing around with the code a bit myself to see what can be done, but if you fix anything in the meantime I'll be happy enough.

EDIT: well, my attempt at fixing that stuff resulted in the entire thing breaking. Persistence manager was failing to read the config file (I didn't even touch that) and DustFX was giving exceptions on every update, and the context actions for the repulsors (at least the apply settings button) was missing. I literally added a single, tiny little if/else statement and everything went to heck.

Edited August 3, 2015 by Gaalidas

[ThorBeorn]

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.

You're probably right. It must be so frustrating to not being able to implement clever (imho) features because of median user stupidity/lack of effort. Though this game can be quite tricky sometimes.

I'm all for toggleable controls like Gaalidas mentioned if you ever feel like doing that.

On the other hand, I should probably make a request for a plugin in the general add-ons forum to adress all rover wheels.

This is a sweet mod no matter what

[Gaalidas]

Actually, a general mod to handle remapping of rover controls would be ideal. I've often thought that we needed some mods to handle remapping of a number of things to the numpad with toggles to handle what is currently being controlled. For instance, one could make RCS translation much more intuitive using numpad keys.

For use with a throttle-control cruise setting the + and - keys on the numpad would be perfect along with rover control running from the same keys. The numpad would actually be my vote for when we finally get around to trying to complete the crawler steering.

[lo-fi]

Believe me, Gaalidas, I've been there. Understanding what code does almost requires that you run through it in your head, which has taken me nearly a year to get good at. Code that gets run over again several times a second is another level of hard. Stick with it! I ought to apologise for my wacky coding to start with, though!

Thanks, ThorBeorn. It can be kinda frustrating...

[Gaalidas]

Success! Almost anyway...

So, first off, I've discovered something annoying. Module Manager tests the loaded configs for changes between the last cached configs and the current loaded configs. When no changes are found, it can load the patches from the cache instantly instead of having to iterate through every MM config. When our global variable file is changed and then the game is shut down and reloaded, MM counts that change even if it doesn't actually patch it ever. So, I'm wondering if we need to swap out the .cfg file for a simple .txt file to contain all our globals. I've already done this locally and am going to test that now.

Also, I've added a little check for the ride height of the repulsors to turn off the repulsor lights when the rest of the repulsor is shut down. Otherwise, I got the GUI toggle working in real time and the action group update working perfectly. Maybe not as efficiently, since I basically created a secondary ApplySettings method. Well, I guess the accurate way of saying it is that I re-purposed the ApplySettingsAction method from being an action group item to simply being a standard method that skipped the "foreach" part of the other ApplySettings method, but did all the other things to update the right variables, and then referenced that method from the action groups. Either way, it works like a charm. I'll commit my changes after one more test unless you've done it a better way, in which case I defer to your code. I'm still fiddling with the light settings. Running them as vertex lights is much more reliable, but also doesn't get that intermittent on/off that you were liking about the others. They also aren't spotlights anymore, but I kinda like them better overall. It would still be nice if they could light up the ground more when running at night, so I'm fiddling around with different intensity settings. In the end, an intensity based on the repulsor power (and the work required to maintain that power vs. the weight bearing down on them), and possible a fade to zero effect that played in time with the shrink/grow effect when the repulsors turn off/on would be awesome. I think the effect power for the sound needs to be given a lower clamp, or needs to be divided by less than it is now. I'm still not ever actually hearing anything from the repulsors while they're running.

EDIT: AH HA! Found it! This is in the MM cache found in the "Gamedata" root directory:

UrlConfig
{
    name = KFGlobals
    type = KFGlobals
    parentUrl = KerbalFoundries/KFGlobals
    url = KerbalFoundries/KFGlobals/KFGlobals
    KFGlobals
    {
        isDustEnabled = True
        isDustCameraEnabled = True
        isMarkerEnabled = True
        isRepLightEnabled = True
        writeToLogFile = False
        logFile = KF.log
    }
}

So, it looks like MM does indeed take notice of any config nodes loaded by the game, even ones it does not modify. So, every time we save a different value to that config file we are also forcing MM to abandon its cache and reload the patches all over again. If, however, we change the KFGlobals.cfg into a KFGlobals.txt, both in the file name and the code, it should load up and save more or less exactly the same, but won't cause MM to take notice of it and thus allow users who don't change their mods out often to not have to re-patch every single load. I've done this already and am going to test now.

Edited August 3, 2015 by Gaalidas

[lo-fi]

Cool, go for it. I need to merge some changes from the dev to master branch too. Will check out the lights! The repulsor sounds were working last time I used them; that's very odd

[Gaalidas]

Stick with it! I ought to apologise for my wacky coding to start with, though!

Granted, your code can be pretty whacky... but it works so I'm not going to complain.

- - - Updated - - -

Cool, go for it. I need to merge some changes from the dev to master branch too. Will check out the lights! The repulsor sounds were working last time I used them; that's very odd

Perhaps it's a local setting of mine. However, other sounds work fine including the wheel ones.

EDIT: So, still can't seem to get the repulsor lights to turn off when the repulsor is shut down. Also, turns out Vertex lighting doesn't affect the ground or static objects at all. at least, not from what I've discovered. No matter what, all I'm getting is more intense lights that light up the craft. There's got to be a way to light up the ground under the repulsors without having to require that extra point lights be enabled in the user's settings and without causing a lot of performance drops. On the up side, changing the KFGlobals.cfg into KFGlobals.txt seems to have done the trick of making MM ignore it. I'll do some more fiddling later this afternoon.

Edited August 3, 2015 by Gaalidas

[lo-fi]

Very cool about the globals file. The vertex lighting doesn't surprise me; there could be many things that prevent that from working on the terrain. Maybe it might be better to keep the lights in the part, rather than at the hit point? I rather liked the way they make the vessel glow blue when it's close to the ground. It's far more effective than randmonly appearing on the ground, now I think about it. The vertex lighting is quirky, but does suit the application.

I've been feeling a little under the weather and got intrigued with the magnetic boots project Aqua has been working on, so I took a little time out to play. It needs turning into a proper thing, rather than super hacky craziness, but I've actually got it to work. See his thread in plugin support for a little youtube of a Kerbal walking on a vessel in zero-g!

[Gaalidas]

Sweet. I'll keep fiddling with the lights and try to get it up to release standards. We still need to get this this out to the public.

I tried to use a different light type (area instead of point) and ended up totally breaking the lights. So, back to the drawing board. Having the lights spawned at the hit point would explain why they don't show up half the time, especially considering the terrain is sometimes slightly above the actual collision point, even at high terrain detail.

Edited August 4, 2015 by Gaalidas

[damerell]

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.

I confess I am somewhat confused by this reply, since it seems to bear little or not relationship to what I wrote. Perhaps it was meant as a reply to ThorBeorn's suggestion above of a separate throttle control?

I was simply observing that KSP has separately bindable controls for pitch/yaw and rover forward/backwards/left/right, although the default bindings have them overlap on WASD, something one rapidly becomes aware of if driving a rover with plenty of reaction wheel authority on a low-gravity world (because every time you press W the rover noses-down into the landscape). This is nothing to do with KF's design inasmuch as it is a stock behaviour. I was expressing surprise that you, personally, might not have rebound the rover controls onto separate keys.

[Gaalidas]

I was replying to both posts in one. In fact, I was just replying in general to everything I think. No one was really targeted in that reply really.

Honestly, I like to keep things simple. If I have problems with reaction wheels, I disable the reaction while I'm roving. I've tried to mess with mods that forced different keys on me and I just got confused because the majority of PC games make use of the same set of keys for movement. Besides, the WASD set of keys are situated in a perfect spot for quick access to the first several action group keys, the light toggle key (I remapped that one to Z like I do in most other games that have flashlights or whatnot) and X for instant cutoff of the throttle. It really makes sense to keep those keys as they are. a better way of handling control issues, in my opinion, would be to further expand on the mode-switching plugins (like the one that swaps the keys for yaw and roll when running in either rocket or plane mode). I'd think a "rover mode" would be great, which would suspend pitch and roll control while the craft is grounded, which would suit rovers great, but would still swap back to the previously active mode when loosing contact with the ground so that orientation can be adjusted for flight and/or landing after "catching air" so to speak.

EDIT: We have success with all the previously discussed fixes I was working on related to the repulsors.

Edited August 4, 2015 by Gaalidas

[lo-fi]

I'm currently working on simplifying, moving the repulsor stuff into DustFX, then deleting RepulsorDustFX, which is mostly redundant. It's been doing my head in!! I've just grabbed your latest bits; will modify the lights too. I can see a way forward with them now. I want to fix the bug with the dust position too.

[Gaalidas]

There's a bug with the dust position? The only thing I noticed was that the dust no longer trails behind when repulsing, it just sprays out in random directions and dissipates.

You'll notice I've changed how the average color is calculated between the biome definitions and the camera output. It may, in the long run, do the exact same thing as the simplified version of the equation, but I've experienced slightly better results from the extended calculations. I'm still not sure we actually need to compare it with the biome color defines however. With that comparison in place, we are somewhat defeating the purpose of a camera system because in that little errant area around the KSC where it flags the grass area as tundra, we still end up with a snowy effect in that spot. I think we should simply use the camera alone, along with maybe a slight modifier to brighten it a little bit, and only use the defines when the camera is turned off. I'd still sample the alpha channel from the defines though, so that specific material thicknesses can be set. I still want to allow for sandy areas to put up more dust than grassy/rocky areas.

As for merging the classes, I always figured adding a Boolean field to the config (bool isRepulsor = true;) or maybe have a way of detecting if the part the module is attached to has the repulsor module on it and setting a Boolean to identify it as that, then simply using if/else checks to define what particle setups to use.

Edited August 4, 2015 by Gaalidas

[lo-fi]

You really need to start using the bug tracking system in GitHub more

Funny you should say that! I've just mavericked up a cohesive single module with an "isRepulsor" field. Detecting wouldn't be hard either; that's not a bad idea. Commit will follow when I've tested a bit. Used to overloaded methods? I just used in a proper module for the first time. Very cool (as a coding newbie), I have to say.

[*Aqua*]

I used a lot of method overloading in the log utility. You can refer to that if you want to know what you can do with them.

[lo-fi]

I've seen them used; never had opportunity to get stuck in myself. Thanks

[smjjames]

I thought you were releasing 1.9 without the dust effects or I dunno?

[lo-fi]

Nah, that's stable enough and coming out with 1.9

It's light on parts, heavy on features. I'm literally just putting final stuff together... Seriously, SOON... Final milestone is checking all the configs work, I believe. Though there may be some stuff that's not in the issue tracker, Gaalidas? I lost track in the thread. And I've just shredded the dust stuff and taped it back together, so it maybe wants testing...

Edited August 4, 2015 by lo-fi

[Gaalidas]

Great... I'll grab the commit and do some testing then... after I take a look at the digital carnage.

I first tried to use overloading when I started making the log utility. Then it started complaining about it in the compile process so I gave up.

- - - Updated - - -

I thought you were releasing 1.9 without the dust effects or I dunno?

Hey, no complaining. We've even got a persistent toggle via GUI... via the stock app launcher. So it's toggle-able. DustFX is definitely here to stay.

- - - Updated - - -

Funny you should say that! I've just mavericked up a cohesive single module with an "isRepulsor" field.

Like they say, "great minds nullify each other and end all life on the planet of origin." Or was that "great minds think alike?" No, I like the other one better.

Anyway, my metaphorical bug tracker (aka, my brain) is pretty empty right now, so it's all down to continuing to fix the wheel configs (don't forget the stock/mod configs in their own repository) after which I'll update the MM config in that same repository that will allow direct replacement of the wheels.

Edited August 4, 2015 by Gaalidas

[lo-fi]

axRPM. Haha!

Anyway. To be honest, it's looking pretty darn good. Stuff is working, tidy and ready. I'll deal with the stock wheel configs during the week, and maybe put a link to it now we know it works and people seem to like them. I'm just doing a final pass now running through all the parts. I don't think there's anything big; anything else can be fixed incrementally, should it crop up. Given all the stuff that's changed, I'd be surprised if there's weren't one or two funnies. Shall we go for it?

[SmashBrown]

Go go go!

[lo-fi]

There will be a 1.9 release this week

I'm so excited to see what everyone thinks of the new features! Only a couple of new parts initially, but loads in the pipeline to follow shortly, which I'll have time to finish now the rest is out of the way.

[Gaalidas]

Okay, so something is wrong with the camera thing. I tried to grab just the camera color average for the dust and got a steady white color even over the grass. I don't get it.

EDIT: After separating the camera from the dust definitions completely, I'm thinking it might be something to do with the alpha constant in the camera code. I'm going to try eliminating any alpha transparency from the colors it picks up and see if that clears things up.

Hey, lo-fi... is it possible that your overload is somehow not allowing the original to run properly? That would definitely explain why the dust colors don't work right anymore... I'm rather stumped here.

EDIT 2: Okay, I don't understand this. I never touched the water repulsor stuff, but now I'm seeing a huge white box just under the surface of the water when I get close to the water/when over water. I also don't understand why I can't get the pure camera color sample to show up as well as the dust color definition version. When they're both active together the colors end up horribly washed out, when the dust definitions are used alone it looks great, and when the camera is used alone it's so transparent that it's impossible to see. To top it off, before you merged everything I had the repulsor lights turning off when the repulsor was shut down, and now even that is broken again. We're going to have to revert the merger I think.

EDIT 3: Never mind, I think I've got it working again. Needs more testing. I still can't run just the camera alone to get the colors all showing up right. I'm unsure what's going on with the camera. As it is, we still have that buggy area around the KSC that reports as a snowy region when it's obviously green, which is why I'd like to find a way to use the camera as the primary means of sampling the colors. It just ends up way too subtle with only the camera. I don't understand what makes the two methods so different as to mean the difference between visible dust and barely noticeable dust.

Edited August 5, 2015 by Gaalidas