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.

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 - - - 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 - - - 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.

Hey, if we can then it should totally be done. It worked out well for the people who brought the dinosaurs back, right? Sure, most of them died as dino-food but, when you think about it, what else could they have expected to happen in the end? So, in reality, it was a complete success. - - - Updated - - - Granted... but rules are meant to be broken. Besides, we don't really know if that really works since we have yet to be able to produce temporal distortions in the real world.

Actually, the spacial problem is not an issue because the time distortion follows the gravity well that it is attached to. Gravity wells distort time as well, so there would probably be some connection between them. If we treat this like a temporal wormhole, so to speak, then that puncture through space-time would create a sort of anchor between the two time-space coordinates. Now, the situation of it disappearing until the time that is specified is a valid way of doing it, especially if the activation is done from a remote console, or a swap of crafts is performed while the requisite speed it being attained. If, however, you activate it in person you would likely have to put everything on rails temporarily (including your craft at the exact time the requisite speed is attained) and then have the simulation warp ahead the specified time, taking into consideration where all the orbiting objects will be when the time has passed. Upon reaching that time, the craft should then resume it's previous planetary-relative direction at the speed it entered the space-time warp at, roughly 88mph. We could then grab the source for the upcoming DustFX feature of the as-of-yet unreleased 1.9 update of Kerbal Foundries and modify it to output a flame-trail to be emitted post-warp. The challenge will be how to handle the external travel of the time machine... that is, how to spit out the craft at that velocity and vector when you are not currently in physics range of that spot.

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.

To stay true to the original, we basically need to figure out what 88mph is when you apply the same scaling constant that is used to scale everything else (basically the difference between the human and kerbal rough sizes). Or... simply stick to the straight conversion of 88mph to 39.34m/s (if that's actually the straight conversion). as far as rovers are concerned, that's pretty insane considering my average roving speed is around 18-25m/s on average. I could only reach a rough 40m/s if I used KF repulsors. For this to work like the original, you'll need to be able to specify an exact date/time to travel to, even if you're only changing the universal time value, going both forwards and (if possible) backwards. Changing the world and/or events and vessels to match is another story... and another toilet seat accident.

More than likely the edges of each bubble will still rip apart the craft parts that they intersect with.

Y'know, I was thinking a bit (I know, scary right?) while reading back a page or so (yes, I know that pretty much means every page, since there are only two other pages at the time of writing this) about the kerbal inheriting the vessel class and got to thinking that if this magnetic boots thing can be realized, we might then be able to make it into a magnetic-landing-gear mod to allow for artificial gravity on a space-based landing strip or something. In the end, this could factor into the development of a non-docking tie-down for cargo. Don't mind me, just dreaming here. Also, I remembered another mod from back when asteroids were still parts that you could build a craft around and I remember that one of them was supposed to have some form of gravity field around it. I don't remember if that allowed kerbals to walk on it, and I don't think the mod is even available anymore, but it likely would have helped somewhere along the way.

ahh, the memories. I still remmeber Doc. K'brown walking into the hangar with a huge bruise on his forehead complaining about faulty toilet seats and time travel. Good times. Then he walked out of the same room again, without walking into it first, complaining about the temporal flux of "meeting yourself" and that was weird too... and then he suddenly appeared on the runway during a launch in what looked like a wooden fruit cart with a spinning bowl on top and springs wiggling in the wind... without wind... ...what was I talking about again?

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.

The wheel problems are always due to not attaching them in the correct orientation. They're not as intuitive as other wheels.

You'd better. Otherwise we'll sick a rent-a-zilla on you.

This whole thing, especially after the little video lo-fi made, reminds me of the sea-sickness cure mod. It allowed Kerbals to walk normally on a floating craft.

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.

It all seems to work for me, but I haven't actually tried it in a few weeks. That's two weeks without any sort of update done to either mods though. To be fair, I still run a custom override module for handling transparent pods, so that might have something to do with it.

Granted, your code can be pretty whacky... but it works so I'm not going to complain. - - - Updated - - - 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.

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.

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.

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.

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.

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.

Supposedly some HTML (renamed to Unity markup) can be used for some things, but I'm afraid for the layout you'll either need to write an HTML-to-GUI translator (it would be easier to rebuild the planet out of toothpicks I think) or tackle the GUI code.

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 - - - 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.

-bang-

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-