Gaalidas

Honestly I don't know what's happening with CKAN. It might be working perfectly fine, but before trying to diagnose any issues I would usually suggest installing manually. - - - Updated - - - Hey, no one said repulsor crafts were a good idea. We did it because we could. Still, I see that the command module survived the jump which makes it a success no matter what the rest of the craft did. - - - Updated - - - what are those repulsors attached to? That looks really strange. - - - Updated - - - Just the malfunctioning water repulsion for the surface repulsors. But I think that one is for lo-fi to tackle. I have no idea why Github says I'm British. I'm from Seattle, WA. (west coast of the US) and, while I have been known to pick of accents disturbingly fast, I am definitely an American-English speaker. However, it seems that our specific accent is what the world generally tried to mimic, at least as far as news casters are concerned. They call it "accent-less" English. Except for those of us with an accent that is...

If it's all about the database reload, then that's also the user's fault and there's nothing we can do about it. At least this means we didn't screw up horribly. I'm gonna consider that a no-brain-required fix and congratulate myself on doing absolutely nothing and still managing to fix it. Yes, that's really strange of me... but I'm low on sleep and, when I stay up this late, absolutely anything can happen. - - - Updated - - - Texan English sounds like that to the rest of us AE speakers too. - - - Updated - - - Well, goats make that noise too. But you see... humans can mimic these noises, and do so often even without thinking. For this instance, it's the noise we make when we're being noncommittal and/or pathetic. The difference between the goat version and the human version is that the goat will end the phrase with a solid break, while the human will leave it trailing into a sort of sigh. I'm afraid, however, that no dictionary will recognize it... unless you have a goat dictionary... in which case it will. - - - Updated - - - At least someone has only positive things to say. I'm going to take that as a success.

Well, we'll have to see what's different between the two repulsors and patch that. Don't give up on the old design, it may still work in the future.

Explosions are totally your own fault. Neither I nor lo-fi can be blamed for those. The icons on the AppLauncher... will be looked into. Uninformed procreation of icons is not permitted.

To be fair, Kerbals are rather unstable as well... so if you contrast the stability of the mod with the Kerbal itself, then this is totally stable. This approach is, however, rather unstable. Be advised.

I'm not going to claim that this will fix all your problems, it's just a good idea for this update. Future updates shouldn't require that as long as we don't redo everything, practically, like we did this time around. I'm going to see about that icon reproduction thing. I really suspect that "revert to launch" is the culprit, because that's the only thing I never tested.

Well, we really don't officially support CKAN as far as I'm aware, since we've still in beta. That said, anything strange that happens when installing via CKAN is not something we can account for. Once we're ready for a public release thread we'll have to make sure CKAN installs and/or updates work correctly. Until then, my suggestion is to cleanly install the mod manually. The folder structure has been revamped completely which could be an issue if a mod is installed without properly removing the old version of it. Oh, and lo-fi... We really need to get a new image up for the mod on Kerbal Stuff. Those old wheels in the image now are so old I don't even think I ever used them, and I think I'm on the first page of this forum too. That's really old.

Ugh. Okay, one thing we should make absolutely clear is that version 1.9 is one of those "clean install of the mod" releases. That's something I forgot to say beforehand. Other than that... I sure hope lo-fi isn't releasing patches haphazardly. These things were working fine yesterday. - - - Updated - - - No, this sort of thing is not due to different mods interacting. It's a situation where KSP doesn't respond with certain events that it was when the AppLauncher was first unveiled to the public. It causes some headaches when trying to clean up AppLauncher buttons on scene switches. My guess is that we have everything covered except for reverts that don't switch back to a different scene, such as "revert to launch." is that what you were doing? If not, then I'm stumped.

Rocket dust has nothing to do with our dust. Rockets produce dust from the SurfaceFX module, which is a completely different module. That being said, yes there should be dust on any planet with a definition in that file and technically, if no planet/biome is matched in the file, a generic dust color (grey) will be used. If the camera is also enabled then the dust definition file will not really even matter so much. This means that new planets added from other mods will get dust effects in one way or another. The only thing that won't be taken into account are any specific dust density values (aka, the alpha value of the color).

The icon thing is something I never had happen during my tests. We actually do have it fixed. I'm totally unsure what could cause that.

I'm gonna call it a feature and we'll look into enhancing (aka. fixing) that feature for a future release.

I could see us making an ultra aerodynamic repulsor, and possibly aerodynamic wheel covers, but the current parts aren't really built for aerodynamics whether they end up that way or not. I really don't think we've put any thought into that part of it at all really.

Except some of us wish we could turn on the brakes as a toggle without having to move the mouse. We're lazy that way. So, I think I'm pretty much good to go with all of our features if nothing sticks out in my next test run, so we're good to go when you're done fiddling.

Well, there are others that try to modify how the brakes work, but they're not working very well from what I've experienced. - - - Updated - - - Not that I'm aware, and it would be nice. I grabbed a bunch of the stock textures (extracted them from the assets) and did a basic color pass on the biomes of Kerbin. I also did a basic color selection of the various planets out there and their specific biomes, but I'm sure we'll be patching that file. Good to know on the time zone thing. I'm on the west coast of the US, so that would definitely not be the same "evening" for me. - - - Updated - - - That's always a bit of a laugh. "I'm pressing the button, why don't you obey me? Move forward you stupid rover! I command thee! Move thy wheels! I keeeilll youuuu!!!" and then I turn off the brakes... So, I prefer to use the "Take Command" mod. In the editor it will appear as if the command chair has an internal space for a Kerbal. When you launch, the Kerbal will be placed in the command chair.

Not the mod that tried to make it a toggle, no... and I don't think it was developed beyond the first few versions. Apparently it wasn't even built to do it on a toggle either, but a newer mod (auto brakes? I forget what the mod is called really) tried to accomplish a toggle option that would replace the default action of the 'B' key, but I still found that it didn't work because, when it was active, suddenly the 'B' key wouldn't toggle OR turn on the brakes (when held even). Or are you talking about the paint plugin? I'm unsure if any of those actually work anymore. Some people still use KerbPaint, but last time I tried it I couldn't get anything to actually paint. It would activate the color picker (a really lame color picker if you ask me, it needed to be upgraded to at least a hexagonal color wheel, if not a complete circular one) but the color never got applied. So, lo-fi... You were saying we'd try to let this thing out tomorrow evening but, depending on time zone, that could mean anytime between the two midnights. Which one are you working from? Oh, and did you mean to have a double call to DustParticles in the following code segment? [COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]DustParticles[/B][/COLOR]([COLOR=#ff0000][B]float[/B][/COLOR] force, [COLOR=#004085][B]Vector3[/B][/COLOR] contactPoint, [COLOR=#004085]Collider[/COLOR] col, [COLOR=#004085][B]Vector3[/B][/COLOR] normal, [COLOR=#004085][B]Vector3[/B][/COLOR] direction) { var WaterColor = [COLOR=#008b8b][B]new[/B][/COLOR] [COLOR=#004085][B]Color[/B][/COLOR]([COLOR=#00008b]0.65[/COLOR]f, [COLOR=#00008b]0.65[/COLOR]f, [COLOR=#00008b]0.65[/COLOR]f, [COLOR=#00008b]0.025[/COLOR]f); [COLOR=#0000ff][B]if[/B][/COLOR] (![I]dustEffects[/I] || force < [I]minScrapeSpeed[/I] || [COLOR=#191970][B]Equals[/B][/COLOR]([I]dustAnimator[/I], [B]null[/B])) [COLOR=#000080]return[/COLOR]; [I]kfdustFx[/I].transform.rotation = [COLOR=#004085][B]Quaternion[/B][/COLOR].[COLOR=#191970][B]Euler[/B][/COLOR](normal); [I]kfdustFx[/I].particleEmitter.localVelocity = direction; [COLOR=#191970][B]DustParticles[/B][/COLOR](force, contactPoint, col); [I]kfdustFx[/I].transform.rotation = [COLOR=#004085][B]Quaternion[/B][/COLOR].[COLOR=#191970][B]Euler[/B][/COLOR](normal); [I]kfdustFx[/I].particleEmitter.localVelocity = direction; [COLOR=#191970][B]DustParticles[/B][/COLOR](force, contactPoint, col); [COLOR=#000080]return[/COLOR]; }It's just a bit suspicious, that's all. I also noticed you pass "appliedRideHeight" to "RepulsorLight()" but that method doesn't actually make use of that parameter anywhere. It also looks like the light is never given an intensity value above "0.0f" anywhere. Oh wait... that's what "squish" is for isn't it? I got it now. Are you intending to make use of "rideheight" at some point too?

There was a mod somewhere that attempted to make the brake hotkey act like a toggle, which would be awesome... but it didn't work for me at all. I'll take a look at that color stuff. I'm always looking for something of that sort. KerbPaint was one of the great mods that worked all the way up through the entire KSP alpha from the point that is was created onward with no update necessary. That just doesn't happen anymore.

Love the musical selection on that one too. Those are awesome. Should definitely keep those around as a possible content-overhaul update in the future. Just spotted your changes on the repository. I'd like to fiddle over the next afternoon (by the way, what time zone do you reside in?) and see what else I can come up with to fine tune things, but if your latest commit was featured in that video, then as far as wheels are concerned it looks great. my tests have been solely on the repulsors because of the greater distance between them and the ground where the dust is being spawned. I do wonder if some of the directional stuff you did with the repulsors could be applied to the wheel dust so that we don't get as much of the dust particles intersecting with the physical models of the wheels/craft, but I don't want to touch any of that now just in case I break it again. I think for 2.0 of KF I'd definitely like to put more control into the configs to specify what happens when that specific wheel calls for a dust plume. For instance, I want parts like the screw-drive to occasionally throw up a CollisionFX-style spark out (complete with light and sound) as it travels over the terrain, as well as emitting dust plumes not only backward but also outward in a direction that would be consistent with its current rotation. So, in the future I expect to be swapping out the boolean "isRepulsor" for an enumerated list of possible part-types that will have modifiers based on that type. I also enver did really get a good hold on how I might add more watery looking particles when hovering over water, which would also be needed for when propelling through water with the screw-drive. I really hate the stock effect for water impacts. Anyway, I think we're almost there. As for the splashes of color thing... I love color, but there's just one problem with that: matching. The reason we stick to greys, blacks, and whites is because they can fit together rather nicely. When you introduce color you exponentially increase the complexity of making something look "right" in the context it is in. That's why i've been bugging a number of plugin authors that have implemented a form of color-switching to their parts to expand it into a revival of KerbPaint. KerbPaint works for some still, but for others it really has problems. it's mostly due to the restrictions the recent versions of KSP (0.90 and onwards) put on certain shader-based effects such as glowy-outlines requiring AA to be active, which kills my machine. Glowy-outlines never killed it, but AA does so I'm stuck without my glowy-outlines. The modding community here really needs a new spin on KerbPaint to be developed, and I ain't the one skilled enough for it.

Ingenious! More add-ons that we didn't even know we needed.

Definitely. Should be in the development forum, though.

That's wickedly awesome. You wouldn't even need a normal map on that baby. You've got to get some high-def versions configured for us to try out. Especially considering KSP seems to be able to handle high poly counts rather well. I especially like the vibrancy of the blue in the wheel rim.

No objections here. Something for you to look at when you get a chance though is the interaction between the water and the repulsor fields. As it turns out, the frictionless behavior of the repulsor doesn't work when over water. You actually slow down quite quickly, and you get splash effects when your ride height is below 50 or so (didn't actually look at it, might be more like 35). I was just going to ask how I could adjust the light origin to not be at the collision point, but if you're working on it then I'll leave that alone. I still intend to do some more fiddling with the dust which I'll merge in when you've committed your light changes. It'll be a close call with a Friday evening release, but I think we'll make it. - - - Updated - - - Good question, and I think I can answer. There are two modes that the dust colors can take. First mode, and this was the mode I built in to the DustFX class before merging with KF, is that the location of the vessel is taken and compared with the biome map. When the biome is identified it then compares the biome name with a set of predefined colors for the body and biome that the craft currently resides in, and then outputs the dust with that predefined color. The actual color of the biome on the biome map is not used if the predefined color is set properly, otherwise you'd get some really whacky colors. The second mode is using a camera. In the original camera mode a 6x6 resolution image is taken every few frames, culled to show water and local scenery only. The colors are then indexed and added to each other and divided by the total number of colors present. This gives us an average of the colors present on the camera. We then create a new color based on that information and pass that to the dust. There are two different ways of handling this data now that it's been passed to the DustFX class. The first one is that the camera color (a subtle representation of those colors) is added to the biome definition-based color for the current biome and then divided by 2 to get an average between the two, and then passed to the dust. The second option is to simply pass the camera colors directly to the dust, however I still set the alpha transparency to the current biome defined alpha channel. This is the mode I'm fiddling with right now actually, so the exact behavior is not yet set in stone... err... binary.

Already nullified by setting the culling mask. I realized some of my idiocy this morning while waking up. It's amazing what the brain can do when it's well rested. I'm thinking there has to be a way cull out the lighting conditions. Either that, or make the dust super subtle or super dark when running at night. I'm going to have another look at the culling masks, and/or look for a way to detect the overall lighting. Anyway, if all else fails I'll just go with what we have that's working on the repo... assuming that all works well enough still? I think we can probably keep our tentative schedule and get this out to the people on say... Friday maybe? EDIT: So, I actually discovered and witnessed the performance drop when using the camera. That thing really does cost some hefty resources. I'm running along with a repulsor craft (converted a rover into a repulsor and stuck 8 monoprop engines on the back) and I decide to switch off the dust effects and suddenly my FPS jumps up a bunch. So, I'm thinking we'll just have to include a disclaimer with the DustFX feature that accuracy of the colors depends on the accuracy of the biome definitions for the planet. If the planet has improperly tagged biomes that do not match the textures, then issues will happen.

Well, that leaves us with an unfixable bug then because there are areas around the KSC that are flagged as the incorrect biome. How can we get camera output less subtle? Unless I can make the camera usable on its own, then we're always going to have snowy particles, or default colored particles, in those improperly flagged areas. I've been struggling for quite some time trying to figure out why the camera particles are so subtle that I can't even see anything when they're running alone, but the biome colors are super strong when used alone. They used to be moderately subtle before we introduced the camera, but now if I use them together I see very little effect from the camera because the errant flagged areas of the planet still display the wrong particle colors. The whole purpose of a camera was so that we could eliminate those issues. For that, we need a camera that isn't so subtle that the biome colors overpower it at every turn. EDIT: okay, I was able to eliminate the subtlety by eliminating the division process of the colors on the camera, however I found that the camera only gave me a grey color. my theory right now is that is is being affected by the ambient light (I'm testing at night due to the repulsor lights) and spitting out the grey because it's only getting a dark grey color in the first place. In the end, we're pretty much stuck. If we can't sample the terrain color without the ambient light affecting the output, then I'm unsure how to make this really work properly. EDIT 2: Nope, I tested it just now during the daylight and I must conclude that the camera is not working properly at all. Using only the camera to grab the color information, other than the alpha value which I'm pulling from the biome defines, all I get is a light grey. It seems that the camera will no longer output anything else. I don't see anything especially wrong or different than what it did before that would cause this, so I'm stumped.

show-off.

Alright, I'll prepare to run another test of the dust myself later on then. With any luck, we'll be able to keep our release schedule.