Gaalidas

All the current tracks are configured to work correctly with TweakScale and thus can be made larger within reasonable limits. If you're looking for longer tracks, that's another bag of beans entirely... and not in the good way either. On the note of ducted fans, if you're really in need if a ducted fan that works like the repulsor, you could probably get away with grabbing a ducted fan model from other mods that have them and replacing the engine configs for repulsor configs. No promises there, but it's likely possible. Heck, you could probably get the blades to spin like they do for the engine configs by using something like the FS propeller spinner module to set up an idle spin for them. UPDATE: This probably won't be so easy now that I think about it.

Not to worry, we'll have little arrows on all of them shortly... heck, maybe we should split this off to a "put a this-way-up arrow on any part you want" mod. Maybe I'll see if I can hack something together for MM, sorta like those old "translate all your animageGeneric modules into FSanimateGeneric" from back before we had editor-enabled animations.

Looks like you've got way too many tracks and wheels overlapping each other. Wheels sinking and turning but not moving the vessel is due to them being upside down. A good portion of the wheels that don't have obvious orientations will look like they're upside down when you attach them to your craft because the suspension defaults to the fully retracted position. For instance, the tiny double-wheels that attach in the center between them are supposed to look like their attachment bars are angled upwards, and the other smaller (but not too small) wheels will look like their attachment plate is all the way on the bottom of the wheel itself. You would think they should be attached the other way around but in fact they should be attached in the exact opposite orientation. What this all boils down to is this: if the wheel is misbehaving, go back to the editor and try attaching them in a different orientation. I'll bet that you'll figure out how they're meant to be attached very quickly that way. For symmetry to really work the way you would expect for a rover or other horizontal craft, you'll either need to use the SPH or (I'm unsure if this is possible right now) use an SPH-style symmetry mode. In the VAB it will simply use a radial symmetry mode which will have rather unintuitive controls for symmetrical wheel placement. Or just refer to lo-fi's post that he made just before I submitted mine. Honestly, I thought you were taking a break. eesh! UPDATE: Just looked at the github and you made a little booboo in "TTTrack/part.cfg." It's "KFModuleMirror" not "KFoduleMirror" y'know.

-cackles wildly at the inside joke that only he really understands-

Ah ha, that explains that PQS crud... All I knew was that is had to be related to detecting the planetary body and/or biome information. I'm going to have to look at the pause/unpause stuff. I never actually figured out any way to pause the simulation anyway except for using time control to slow things down to an insanely slow rate, but that slows everything down so stopping the particles are not really necessary then. As for the MM patches to add these to the KF wheels/tracks, all you need to do is first add a check for "!MODULE[KFWheel]" in the last patch of the original file, then (if you're using the source I posted) add a new one that looks something like this: @PART [*]:HAS[!MODULE[DustFX],!MODULE[CollisionFX],@MODULE[KFWheel]] { MODULE { name = DustFX //Required. minScrapeSpeed = 1 //Optional, default 1 minDustEnergy = 0 //Optional, default 0, the minimum emission energy. minDustEmission = 0 //Optional, default 0, the minimum emission strength maxDustEnergyDiv = 10 //Optional, default 10, speed is divided by this number to calculate maxEnergy. maxDustEmissionMult = 2 //Optional, default 2, speed is multiplied by this number to calculate maxEmission. maxDustEnission = 35 //Optional, default 35, maximum allowed value of the above calculation, changed from original 75 to make the dust less overpowering. } } And that should do it. I wanted it to be as flexible as possible, but as simple as possible to just add the module name and be done with it. I don't have collision sounds integrated yet, which would be nice for cases where the wheels hit the ground with some speed, but that will come in the future. EDIT: So, I had a look at the modified code, integrated the pause functions and all that. I'm a little confused as to what the additions to the color selection is all about, and I noticed some of the hard coded color sets were commented out (I did not merge that change) which would break some of the functionality of the color selector based on biome/planet. It looks like you were trying to create a sort of color selection field for it. If this is intended to be used as a smoke trail type effect, I might suggest creating a new class/module for it.

Sounds like a really bad idea to me. Dipping sheep could be hazardous, and I can't imagine who'd want to dip a sheep. Are we talking about live or dead sheep? Mutilated or whole? Cooked or raw? So many variables...

that's the detail I totally missed when diving through the code. Oh well, it's still a step in the right direction as far as I'm concerned. I really liked the ease at which a new color is picked in your mod, but I love the flexibility of options in the B9-procedural-wings mod... I'm torn between the two, and neither of them do what KerbPaint used to do. What's more is that i am now getting messages from people who recognize my name from my various informational posts on the subject, but I can do nothing to help them. Oh well. I guess that's the price I pay for being too smart to shrug and walk away, but too inexperienced to actually back up my speech skills. - - - Updated - - - The rear part looks like it's not quite fitting right... otherwise looks awesome.

It may seem up to date, but I compared the source and there's a lot of mis-matched stuff that doesn't cover the features we get from the release. That being said, it's possible hhe updated his github copy in the last day or two, which could explain things. The reason I offered my source file is that I spawned a completely new module from the original file to cover only the dust effected and not the collision effects from the rest of the mod. But either way, it's the same particles that are being spawned. EDIT: So, I looked at the update he made a day ago and it looks like it just updates the source to match what was in his release package. There are a few minor differences that don't actually make any difference in the way it works. Here's a link to my additional source file which includes all my changes to allow for only the dust and none of the other fluff. It's completely stable at this time, I think.

y'know... just as I said in the B9 procedural wing re-do thread, your approach to recoloring the parts is rather interesting. KerbPaint currently has issues with .90 (it doesn't work, that's the issue) and I've been looking around for possible solutions. Might be something to think about if you ever want to expand on your recoloring system.

I am unsure if the engines shown on these pages would count as "ion" engines. They seem more like vtol-enabled low-thrust high-efficiency dual-mode engines. Hard to say from the images though.

Just released and already being abandoned to the whims of the community? That's nuts man. That being said, it sounds like a great companion to CollisionFX which, due to the apparent disappearance of the original author, I've been fiddling with to give KF tracks a good dusty trail as they roll over the terrain. This also reminds me of BAM, which came out practically side-by-side with .90 and added explosion scaling based on fuel and explosion potential. I look forward to diving into your source.

I thought it was a variation on the BFG (Big Friggin Gun) which in this case makes this the BFE (Big Friggin Engine).

Technically.... the correct way of putting it is "you can only launch from a base in the Kerbin SOI" considering my several successful (if slightly cheat-ish) launches from the munar surface. I believe the issues arise only when trying to launch from a non-Kerbin based SOI, like Duna for instance, without using something like the EPL mod. I wouldn't put it past the developers of these mods putting their heads together to come up with a solution, but for the time being you gotta stick to the inside of the original planetary system of Kerbin.

Either way, you'd still have to use that version if you want to use his parts. Considering his parts make use of plugins handled by other parties, then if those mods are .90 compatible so will this mod, no update required.

Now we just need a rocket plume that fits the size of the engine so it doesn't look like a little rocket with a massive nozzle stuck on the end.

I could put my current source file, for the new part module, based on CollisionFX (and packed in the same DLL/namespace), I called DustFX, up on dropbox if you want to mess around with it. Otherwise, the source file in the current distribution of CollisionFX (available on curse, I think, and KerbalStuff) is actually more recent than the one on Github, but the github version comes with a project file. Thankfully, even if you need to make a new project for it, it only uses the basic system references plus Assembly-CSharp.dll and UnityEngine.dll so it's really easy to hack together a project file for it. A little update on my progress: I've successfully exported some of the particle strength variables to KSPField objects and have updated my local tweakscale file for KF with a new exponent entry which will allow for scaling the effect along with the wheel scale... in theory anyway. I am unsure if truely scaling the whole effect is possible. I'm just scaling the strength of the emitter. Testing is nonexistent at the moment. Did a little looking into makign a config node for biome/planetary-body settings for the dust and got about half-way through before my brain started to get fuzzy over all the details of exactly how the configuration data was being brought into the part module, and what the heck I was supposed to put in the config file to make it recognize the settings. I'm going to need to look at some more examples I guess.

I'm getting closer to a way to scale the effects too... sorta. I can scale the dust emitter's strength settings, which seems to have the effect of scaling it's size down... sorta. I've also adjusted the alpha settings for the dust to make them less overpowering so even if they are over sized, at least they're more transparent. It's a work in progress. I am not too sure about exporting the biome/planet settings out to a config node, but I'm working on making the strength scale available as a field which means I could possibly make it scale with tweakscale as well. I added the repulsors to the MM patch that adds the dust effect today as well. Gonna see if the effect is anything we might want. It's likely to be a bit weird though, so I'm not too hopeful that it'll work very well. It's also worth pointing out that the effects as they are only really make sense on the tracks. Wheels would likely produce a lot less dust on more solid materials, and likely not produce any such effect on extremely solid surfaces. I'm going to try and expose more of the effect options to field data so it can be tweaked on a per-part basis. One graphical glitch I discovered is that when you switch from one material to the next (such as when going from the planet surface to the surface of the KSC landscape models) the dust effect as a whole switches it's color profile, rather than just the point of emittance changing. This means that the cloud, which is dissipating behind the rover, suddenly changes color. No clue how to fix that.

Motivation eh? Alright, how's this for motivation... I'm gonna stuff a motorized space car up your -bleeped out in the name of censorship- and use it to rip a new -bleeped out- for your -bleeped out--bleeped out--bleeped out-, got me? Don't take that one too seriously... and use your imagination. It'll be better that way. If that one doesn't work, I'm out of ideas. Anyone have a tactical nuke I could threaten him with? Oh come on, you people are no fun at all. Isn't a little nuclear fallout worth it to get a hold of this baby? Jeb would do it... you know he would.

Yeah, that diffuse for the rover body is huge and will overwhelm the system very quickly. They're originally in TGA format, so easily editable. If you reduce it's size by half, it should be processable again. lo-fi will be updating the official distribution when he gets the chance. In other news... As many of you know, I am awesome. No really, I'm not just talking to hear my head rattle. It says so right here in my file: "subject is extremely awesome." So there you have it, proof positive of my awesomeness. Oh, you want more proof? Well, I did manage to completely, and (as far as I can tell) 100% fix the CollisionFX issue. How you ask? Well... It goes something like this... I decided that trying to run the dust effects separately from the collision sparks within the same module was jsut too complicated to be worth it. So, I copied the relevant parts of the original code into a new part module that I called "DustFX" and re-named all the various functions to take into account this new name. It still runs within the namespace "CollisionFX" but has it's own module and does not share any information with the original module. This means we get dust, colored to match the biome and/or surface (the KSC raised platform meshes give off a generic white/gray dust while the ground around the KSC (the parts that are not raised and/or are part of the planetary mesh) gets a dirt-colored dust. There are no sound effects, but that is taken care of in the KF wheels themselves using an EFFECT node. I will look into re-implementing the sounds for impacts at a later time. Now I just want to spawn off a third class so that I can re-add the sparks to the specific parts that should cause sparks on certain materials such as the hypno-drive. That thing would definitely spark as you twist it over the concrete. Testing will now be a major thing for me, and I need to revert my changes to the original class to eliminate the nullrefs it was producing and still produces right after any of the original sparks are played. Overall, however, this last attempt has been a success. Once I get a chance to take a KF-armed rover to Duna we'll see if the off-world dust will function and then I will start looking into how this stuff could be exported to a config file for easier color/biome definitions. I've never been all that great with putting together albums of screenshots, so you'll all just have to take my word for it that it's working. UPDATE: Woohoo! I broke it again... then fixed it again. I'm on a roll.

The breaking of the wheel, as in what you get when either the craft is too heavy or you run it too fast/brake too hard has something to do with the combination of the break speed and the impact/crash tolerance. I don't have the data right in front of me, but in my tests it really mattered very little what I did to the config because I always broke the wheels right off the bat with anything I used them on. I wrote a MM config to make the ability to break any wheel (stock module) false and have never looked back. Since the way the stock wheels behave is so far from what you would expect in a real-world situation (lack of suspension, bounce due to air-filled tires, or the toughness of airless tires, and the difference between a locking brake and a friction brake which would allow slow-braking and thus no flipping) meant that an invincible wheel was entirely plausible. With lo-fi's reinvention of the wheel, however, I think a breaking wheel would be entirely doable and usable without too much of a frustration for the end user, as long as it took into consideration the pressure on the part that would be reduced by the number of wheels being used to support the craft and limited breaking based on that. So yeah, that's that. Update on the CollisionFX stuff. So, yeah... I noticed the scaling thing too and I'm not going to touch that just yet. Scaling based on speed would also be great. my NullReferenceExceptions continue at full speed, but I do have more information about them. While moving on a surface that can produce an effect, the nullrefs cease. It's only when I am currentlystationary on a surface that is able to produce effects, but is not producing (since there is no active scraping at the time) the dust. I also get nullrefs when moving on a surface that does not produce dust (such as the landscape objects that make up the KSC raised-platform landscape). Details of the log show that it is three functions which are simultaneously producing this exception: "ScrapeParticles", "Scrape", and "OnCollisionStay" which are all functions defined in CollisionFX.dll. EDIT: Link removed, problem has been taken care of. Details below. I'm not ready to give up yet, but I'm running into a brick wall with these nullrefs. UPDATE: I did one more little edit locally and got it to spawn a smoky effect (totally not intentional, wasn't even editing that part) when traveling over the KSC raised-platform stuff. Unfortunately I'm still spammed by nullrefs. I have done everything I can think of to eliminate them, but despite reading countless articles about nullrefs and trying everything I can figure out that might have anything to do with it, nothing changes. Why can't errors be more useful? I'm poking around in the dark trying to find something that I don't even know what looks like with a tool that has no clear way of helping me find anything even if I could see it. It's completely and utterly insane!

Update: Success... sorta. I got the dust to spawn, without the sparks or the scraping noises. However, I also got spammed with NullRefs due to, as far as I can tell, the definition for the "scapeSound" being null. I may have fixed that, will check later. If not, I also have an empty audio file on standby that I can define as the scape sound for the wheels. Next up will be trying to make it work on wheels that do not use the KF module type, but I may just leave that up to the original author of the mod to figure out in his own time. I only use KF wheels now anyway. All of this comes with no "index out of range" issues. I'm still curious as to how you did it and why you were getting that error, but that's less urgent now. - - - Updated - - - Now THAT was epic. I was so glad when you showed off the action groups and the water repulsor parts. I was also impressed by the quality of the video. That's a rare thing, even with the higher-profile video posters. It really felt like it was right here on my monitor. Better, actually, since I cannot use shadows while still being able to move. the good news is that the sparks should be fixed soon, if I can get the null refs under control. This is all assuming we can do a re-release of the mod, or package the edited version with KF... that stuff is all foreign to me. What I'd love to do, however, is find a way to keep the sparks for certain situations such as really hard impacts and/or the screw-drive when on hard surfaces. Contrary to the original mod, I also switched out the water spray effect (just a different color for the dust when on the water) from the desert-dust to the arctic dust. I have yet to test this out at all, but I think it might look a bit better. I've also done an experimental definition for dust on Duna, using the desert dust preset, since the original mod had no settings for dust on non-Kerbin surfaces. Good stuff coming in the future.

I wouldn't worry about breaking the laws of physics. Laws are meant to be broken, after all.

That is a hilarious direct translation. Yes, it is definitely a fun movie. Enough fun now, I want my flying car.

Which movie now? How's the flying death machin... I mean, the flying car... coming along?

Interesting little utility here. Especially interesting is that during KSP load, this mod produces a constant stream of null ref exceptions. I wonder if it would detect it's own exceptions? hmm...