Gaalidas

The closest I ever got to a fade was the size/grow parameters which supposedly allows for the effect to grow over the length of the animation. I thought maybe a negative value for the grow would result in a shrink. Didn't get to test much really. The sudden change might not be totally necessary, but it still annoys me

I noticed a bit of a delay on the color being changed on the video. Is that with one camera per part, or one for the whole vessel? Another thing I'd like to see is eliminating the sudden switch of the colors on the particles that are already in the air. It looks like it applies the color for all frames of the animation at the same time. If it could perhaps only apply to each frame in a sequence synced to the frame rate of the animation, that would look a lot better. For now, I would likely diminish the effect so that it doesn't show so much. That's also why I was looking into a size shrinkage for each effect so it would fade out quicker. He end result of my tests wasn't so great though.

That's why we keep a biome settings file in the plugin, to define biome-based materials and their hardnesses. I need to look into expanding the information we can define in each node in the biome color config. As for varied colors in the dust animator... Currently the color is applied to an array. There are maybe 5-6 index levels that all get the same color. I haven't looked into applying a variance to it, like is done for the relatively untested impact sounds, but I bet it's doable.

I'm glad you think it's the easy part to do nodes... However, I have never made any parts from scratch, so it's still a real pain for me. Also, MM hates database reloads. I just need a way to experiment with node positions and visually see the result quickly so I can fine tune it. This is both for attach nodes and the stack nodes I like to to put on the wheels for use with things like the ERS rover body which uses stack nodes for wheels. They need to be very precise.

Well, as time goes on and I learn more about C#/KSP coding, the future users of this mod will have more and more options available without having to recompile anything. If there's one thing I do well, it's giving the end user a lot of power over the configuration of things. I really hate to hard-code anything at all. what I'd like to see in the far future is the option to use a camera-grab for unknown locations (such as static models where the terrain system won't recognize the difference between pavement and grass), with a global override to disable that if the user has performance issues... which turns back to a biome-config list (like we have now) for PQS collisions which, in turn, can be overridden in the part config itself with either a user-specified list (maybe a config-defined definition file to look for?) or a single color to use in all situations. I'd like to see base emitter strength, density, size, etc. definable per-color-definition, and for those to be modified by weight of the craft, slippage, material, speed, etc. and I'd like to see a global particle emitter implemented much like smokescreen has for the global number of particles allowed to exist from a DustFX effect. Can I make this happen now? Not a chance in heck, but it'll keep me busy for the next few years at the least. On to another subject though... So, a long time ago I went over all of the KF parts with a mod called NodeHelper. This is a very old mod and, needless to say, does not function anymore... at all... and the author had a cultural/personal issue a while back and withdrew his stuff from the world forever. Not to be daunted, however, I found a github repository with the source for that mod and attempted to recompile it. In the recompile I was successful (after disabling the part highlighter, since the old functions for doing that are no longer available and the current version required AA, which slows my machine down a bunch.) However, the mod window still fails to load and I do not have the icon source for the toolbar implementation. Easy fix, I'm sure, but without the window opening up, I'm sunk. So... I'm looking into other ways to alter the positions and orientations of attach and stack nodes. One way I discovered is to import the models into Blender and use a tool from the utility release board that can turn blender-based coordinates into KSP attach node coordinates. But... the blender importer fails to read the KF parts. Another way is to use transforms from unity, but I have no clue how to add new transforms and would probably have better luck entering random values into configs and reloading KSP every 5 minutes until I get it right (I'm not going to do that, it takes longer than 5 minutes the load KSP each time.) So, I'm in a bit of a conundrum right now (did i even use that word right? I've never used "conundrum" before! That was awesome.) So, I have a few requests that don't have to be done right now, but would be awesome for the future. And... not all of them need to be fulfilled at any time, since they all produce the same end result: my ability to adjust the nodes to better fit the parts we're working on. The first choice is to possibly provide some basic exports of the parts (don't have to be functional, just a model will do to use for reference) that will load in basic blender. The second option is to make sure that all the unity stuff in the KSP422 repository are all up to date with the current parts so I can learn how to add the transforms I can use to define nodes. In the mean time, I intend to continue seeing if I can revive Nodehelper from the dead. Anyone know of a good physionecrological specialist I can talk to? (aka, bringer of "dead things" into "not-dead things") So yeah, I'm out now to crawl around on the floor of our church tracing wires! Fun times ahead (and possible rug burn).

Hey, it's a start. - - - Updated - - - I wouldn't have understood anything you were telling me anyway, so it's better for all of us that you didn't try to explain it to me.

I think something needs to be done about the super-flipping when trying to move forward under the influence of the handbrake. I also wonder if a clamp could be created that will limit the power of a wheel/track in the case of them being used on an extremely light vehicle. All this should also respond to the TS corrector. As for the biome color stuff, I suspect maybe it has to do with something between the naming changes I made when merging with KF and the references being called up in the code. If any of the code refers to something else in a string format instead of by object, then the renaming system may not have discovered it and made the change. It's really strange though, because all of my tests have been successful. It doesn't actually change color until you touch the planetary surface though, since the edges of the runway are still part of the static model. If we could get some sort of camera-color-picker working, then you'd get a change immediately upon rolling off the pavement. There's also the chance that some biome names have been altered in the latest update to KSP, in which case the config file would need to be updated. I don't know how the original was generated though, since I've tried launching the game without a config file and the code does have a config writer in it somewhere, but no default file was ever generated. Overall, from what I've seen in other mods, the complexity of this config node loader is a bit baffling. Granted, I'm using an absolute ton of sub-nodes, but it's still pretty crazy. I get the feeling sometimes that I picked a really messed up project to take on all those months ago. Why couldn't I have done something so much simpler?

You know what I find entertaining? When lo-fi commits 8 times to github, in a row, and manages to mess things up, fix them, mess more things up, fix those, and end up with a few messed up things as a grand finale.

The colors seem to be working for me, as far as I can tell. The colors are referenced using the config file that I uploaded which contains all the definitions, and are called up using a body/biome name, and lat/lon coords. I don't really understand much about how it really works, cause that part was written by xEvilReaperx and I barely managed to get it all working with the original CollisionFX code back when the color project was being worked on. I may have to compare the current code with the unchanged project that I have still under a separate folder from back before I merged with KF. By the way, I watched that video. Nice audio. The dust effects on static buildings such as the KSC (including its non-PQS grass and such) will always produce only the default color, which is supposed to be an extremely subtle gray color. In fact, more subtle than you've displayed in that video. I mean, real vehicles don't really produce much of an effect on the road unless they're spinning the tires. That would be an awesome thing to have in KSP by the way, some wheels just stopping completely when the brake is applied, others just spinning and producing massive amounts of dust (and generating lots of heat). Something for the future. The larger dust effects were meant for off-road applications, with the largest dust plumes being emitted on snow and sand, or when being repulsed at high speed. I did a little testing today and found that, probably due to your changing of the modules and the methods they make use of, tracks such as the small ones no longer respond to the ride height adjustments. I also discovered that, when attached to something like the rollcage, they have an immense amount of torque. In fact, with a torque ratio of 1, which is the default, I could flip the craft just by moving forward slightly. That's not the biggest concern though, cause I was able to do an entire back flip (and landed on my head after it continued flipping after a complete flip) when I did the exact same thing but with the E-brake applied. That's right, those tracks were running at full speed, with the emergency brake on, even with the torque ratio set to 0.25! If you thought the mole tracks on an under-weight craft would flip you, you ain't seen nothing yet! Also, the rollcage needs some work. First of all, I would not suggest using the JSI transparent pod stuff in the latest edition of RPM. The results are hilariously messed up. About 5 minutes into my test today, suddenly the dashboard prop grew to massive side, reoriented itself in a strange way, and from the outside of the craft it looked like I was using a giant concrete overpass section for a hood ornament. Not to mention all the interior indicators and stuff were all over the place. I also noticed the rollcage has some funky collision surfaces in which to attach things radially to it, and it contains a single stack node which is oriented towards the back of the pod but is located exactly in the dead center of the part. Weird stuff there. I'm unsure why RPM hasn't received an update to fix the transparent pod issues, but I do know they're rather unique to KSP 1.0.2 and the latest RPM update. Annoying stuff to say the least. So, yeah... things need to be tweaked... a lot... Anyway, sure, I'll leave the DustFX stuff alone for a few days at least. I was just thinking about the ways we could cut out the separate module and integrate it more cleanly with the KF modules. I didn't get a chance to test my first iteration of a possible water collider effect, but I'm sure it'll likely fail on the first go anyway. - - - Updated - - - I have no idea why this is happening to you, but that fix I created using that method to test the null-ness of the data was originally thought up when I was checking for more than just a few simple null cases. It's probably not as necessary now. the thing it, that fix was just thoroughly tested by me today and I got absolutely no exceptions with the above code. I'm thinking right now, however, we could just disable anything in the area of the impact audio. That's all impact is used for right now. CollisionFX uses it for stuff like spark effects too, I think, but those were not useful to me so I chucked them in the ol' proverbial trash bin. If we want to implement rough-impact sound effects for wheels, we'll do it in a much more efficient way. - - - Updated - - - Before KerbalFoundries, that was me sitting back and watching the fun unfold. I've been browsing all these forums for at least a year longer than I've been registered. I found KF maybe a week after becoming a more active member... I think that's the timeframe anyway... it's all a bit of a blur right now. I agree though, multiple developers for a single mod can be down right entertaining at times. EDIT: oh, by the way... is there a reason why the eye-coupler module is being called "KFCouplingEyeOLD" but is still referenced in the part config as "KFCouplingEye" which, obviously, will not function correctly? OUTPUT...OUTPUT...OUTPUT...OUTPUT...

My way of doing it was basically the same, but I made it more elaborate in that now the field in both modules is called "resourceConsumptionRate" instead of "chargeConsumptionRate" and there are some new fields such as "resourceName" and, for the modules with a status text, a "statusLowResource" string field which allows the status of "Low Charge" to be renamed per-part to something like "Low -insert_resource_name_here-" though... now that I think about it, I could probably eliminate that field and simply change the resource in that string to be equal to the resource name specified with something like (writing this in freehand): string.Format("Low {0}", resourceName);I might just look into that instead of the extra field, but I'd actually like to have a lot of those feedback type things to be more modular. This allows for modders in the future to make part packs based on this mod without having to write extra code to make up for our hard-coding. by the way, your latest commit totally messed up my change in the repulsor code where I changed the reference from "chargeConsumptionRate" to "resourceConsumptionRate" in the "effectPowerMax" calculation. Don't worry, I'll fix it. I noticed that the repulsors no longer have support for that status stuff. You've commented out a bunch of code that used to update the status text. Are there plans to re-enable that functionality? And yes, I was noting that we hit the 300 page level (if you're running the default posts-per-page settings) which is utterly insane for a non-release thread.

so, lo-fi, I noticed you started work on making the resource consumption more modular... however I have some code that I'm going to merge in which adds a lot more modularity to it. it also renamed the field for the resource consumption in the configs, which I have refrained from committing to the part configs, but is all ready to be committed at any time. Basically, I made all referenced to "charge" or "electric" into a more generic "resource" format. Everything defaults to the standard ElectricCharge, of course.

I bet it is a bit hilariously crazy watching the ol' pong ball bounce between us. I was just noting yesterday that I do believe my posts are getting longer.

Wait... where did you find the blunder? - - - Updated - - - Spoke too soon. There's the culprit. EDIT: Oddly enough, this worked perfectly fine in all my tests. I'll correct it though, hopefully it will work out alright in the end. - - - Updated - - - Alright, so, I remember (thought couldn't find the post) where you asked about the sounds and how to reference them. I dug up the config for the B9 HX-series engine as an example. So, you already know how to set up the effect node for a sound, but the way to reference that sound is actually quite simple. Note, I think you might have to use the FX version of the engine module for this to work right, though I could be wrong. Mess with with it a bit. EFFECTS { power_closed { AUDIO { channel = Ship clip = sound_rocket_hard volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } } power_plasma { AUDIO { channel = Ship clip = sound_rocket_hard volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } } engage { AUDIO { channel = Ship clip = sound_vent_medium volume = 1.0 pitch = 2.0 loop = false } } disengage { AUDIO { channel = Ship clip = sound_vent_soft volume = 1.0 pitch = 2.0 loop = false } } flameout { AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } So, in the above code you have all of the effect nodes (I stripped out the smokescreen stuff to save space). In the engine config you get this: MODULE { name = ModuleEnginesFX engineID = ClosedCycle powerEffectName = power_closed thrustVectorTransformName = nozzle_transform exhaustDamage = true ignitionThreshold = 0.1 minThrust = 0 maxThrust = 19080 // 21200 * 0.9 heatProduction = 390 useEngineResponseTime = True engineAccelerationSpeed = 1.60 engineDecelerationSpeed = 2 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 323 // 308 * 1.05 key = 1 281 // 268 * 1.05 } } MODULE { name = ModuleEnginesFX engineID = HybridPlasma powerEffectName = power_plasma thrustVectorTransformName = nozzle_transform exhaustDamage = true ignitionThreshold = 0.1 minThrust = 0 maxThrust = 4280 // 4761 * 0.9 heatProduction = 500 useEngineResponseTime = True engineAccelerationSpeed = 1.60 engineDecelerationSpeed = 2 PROPELLANT { name = ElectricCharge ratio = 16.5 } PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 840 // 800 * 1.05 key = 1 230 // 220 * 1.05 } } From what I can tell, states such as "engage" and "flameout" are default within the engine module (I plan to look at the code later to find uot if those can be re-targetted) and so you need not reference those effects directly from the engine config, but can redefine the sounds simply by making an EFFECT node that uses the same name as that standard engine state. This includes the running effect, if your engine uses the standard running effect. However, as you can see in the config, you can re-target certain states of the engine as they did with the HX-series (especially since it's a dual-mode engine) by using the parameter "powerEffectName" and specifying the node within the EFFECTS node that corresponds to what audio/effect preset they want to use. So, like in the old system where you would have simply re-targetted the sound file with "sound_file_name = engine_state" without having to re-target anything in the engine config, the EFFECT system allows you to do pretty much the same... just with more work involved, and more power at your fingertips. EDIT: I took a look at the stock ModuleEnginesFX module in ILSpy and discovered this: [KSPField] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]string[/COLOR] flameoutEffectName = .([COLOR=#00008b]140586[/COLOR]); [KSPField] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]string[/COLOR] runningEffectName = .([COLOR=#00008b]140635[/COLOR]); [KSPField] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]string[/COLOR] powerEffectName = .([COLOR=#00008b]140650[/COLOR]); [KSPField] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]string[/COLOR] engageEffectName = .([COLOR=#00008b]140603[/COLOR]); [KSPField] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]string[/COLOR] disengageEffectName = .([COLOR=#00008b]140616[/COLOR]); [KSPField] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]string[/COLOR] directThrottleEffectName = .([COLOR=#00008b]141801[/COLOR]); [KSPField] [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000]string[/COLOR] spoolEffectName = .([COLOR=#00008b]141830[/COLOR]); If you ignore those numeric targets that ILSpy couldn't make sense of, you still get a good idea of all the engine states that you could re-direct to a different effect node. For instance, if you wanted the APU unit to be able to run in an air-breathing mode and a vacuum mode, based on need, you could redirect the different engine configs to use "powerEffectName = Open_power_effect" and "powerEffectName = Closed_power_effect" (open cycle and closed cycle respectively) along with two different nodes under EFFECTS. interestingly enough, I haven't witnessed any custom parts using things like "directThrottleEffectName" or "spoolEffectName" which I'm unsure what would be, honestly, but i think the engine modders need to start looking at all the possibilities. I am also unsure how the engine module determines what the current status of the engine is in order to know what effect to reference. I suspect it's somehow based on an animation state in the model, but it could also be environmental situations and fuel availability of various sorts based on what the engine is requesting and whatnot. Overall it's fairly complicated and way above my paygrade at this time.

Hey, I got no clue there. Last time that happened to me it was because I wasn't compiling in .net 3.5. Either way, it worked last time I tested the last code update I did, so unless you've been fiddling around... -shrugs- - - - Updated - - - Those things are seriously awesome.

Well, in the mean time I got the resource stuff exposed and I already patched a copy set of the part files... but I can keep those around in storage for when you get done doing your rewrite if you'd rather. I thought you'd only just rewritten the repulsors recently. Seems a bit early to be rewriting them again. EDIT: So, I think I know why your repulsors were flinging you to insane heights. i was looking at the latest github updates and saw this in the KFRepulsor.cs file: public float rideHeight = 25; const float maxRepulsorHeight = 100;Now, I'm no expert, but if nothing else has changed in how the maximum and current ride height is calculated and applied, then you've just set the default ride height to 25, and your default maximum to a staggering 100. Another thing I noticed was your attempt to change the sound for the APU unit. I think you might be missing something in how you're trying to do that. The reason sound replacement doesn't use that simple sound definition is because that stopped working the way we expected to a long time ago. It used to be that you could simply put a sound file into the part directory, under a subdirectory named after the part config file, and then another subdirectory called "sounds" under that, and then call it up with "soundfilename = mode_that_calls_it" (for example "engine_low = running"). Squad made some changes to how that system works and now the best way to do sound replacement is either to replace the sound file at the source (for global replacement) or to use EFFECT nodes. Here's the way you set it up most recently in the APU config: sound_jet_low = KerbalFoundries/Sounds/APU sound_jet_deep = KerbalFoundries/Sounds/APUNow, this is basically saying that when a running state of the engine reaches what it will internally call "KerbalFoundries/Sounds/APU" it will then play the sound named "sound_jet_low" which I know is a bit weird, but that's how the old system worked. The name of the sound file came first, then the engine status it was used on after the equal sign. For you to properly use different sounds in the APU, you should use EFFECT nodes like most other engines that are not based n the old stock behavior would use. Either that or write your own plugin to handle the sound effects in your own way. Trying to adapt the old sound definition system is really overly complicated as to where they have to be in the directory structure.

Holy Jebediah! I've been wondering about that for quite some time. (I swear, just this morning I was thinking about KSPAPIExtensions and wondering how I was going to convince lo-fi to accept the dependency.) I wanted to make the min/max suspension levels into variable fields so that we might reduce the number of ineffective suspension levels. Certain tracks do not effectively lower the suspension level beyond a certain point (typically at the 50% mark) and it would be awesome if that "lowest possible level" for the individual part could be defined. We could then refactor the min-max levels to reference that lowest possible value as "zero" and then, possibly, change the "change amount" to reflect the new rate of change that would be needed to maintain the previous level of control. Of course, modifying the tracks themselves so that they could use all the levels of the suspension slider would be a better solution, but that's a lot of work compared to doing some testing and then setting a new config value to match. In theory, this could also be used to limit the suspension range if the model has the tendency to warp in an unpleasant way upon reaching the highest or lowest levels (referencing the way the tracks tend to have these little points on either end of the length areas when retracted fully. Overall, the goal would be to allow the slider to go from zero to full as far as the user is concerned, except that every level the slider goes to would have a visual impact instead of that 0-50 null-zone I've witnessed. I'm excited now, can you tell? Moving on... I did some refactoring in the KFRepulsor and KFModuleWheel modules to try and change the resource consumption from a hard-coded "ElectricCharge" to a variable field. In theory, it should now be possible (once I find out if lo-fi has been messing with those files so I can make sure I'm all merged up and don't conflict when committing) to set a "resourceName" field in the config (defaults to "ElectricCharge") to whatever valid resource you have in your game. I have not yet added any checks to make sure that the resource is valid because, quite frankly, I don't know how to start yet. I'll look into that next. For now, I can only assume that it would cause some sort of fatal error and police would find your lifeless body... or what's left of it, smoking in front of your computer. They don't call them fatal errors for nothing! On top of all that, the variable names themselves have all changed to reflect that it is now a "resource" request and not a hard-coded "charge" request. Status text for the "Low Energy" state has also been given a field, with a default equal to what it was before, so that an appropriate message can be created for that resource. I am unsure at this time if any of those changed variable names include any necessary config updates, but I'll be sure to check that out before committing anything to github. The goal is, of course, to make sure that, if not set in the config, that a default value is still used which is equal to what we currently use so that our fearless leader, lo-fi, does not have to change any of his WIP configs to match the new fields. Of course, an option in the future to change all requests for resources from a wheel or repulsor, at a global level, would be awesome. I've had this long-standing idea of KerbalFoundries having a DefaultSettings.cfg (or something similar) that could be used to define, if not overridden in the part config, a default value for several of the commonly modified, but modified uniformly, variables. In this way a global multiplier could be implemented for all charge consumption (allowing for an "easy mode" setting which would allow the user to disable all resource usage on the KF parts) and a global string could be defined for what resource to consume. I would probably implement a boolean to define whether or not the part configs can override the global settings as well. It's an idea I'm working on anyway, and in the far future could even include a GUI to modify global settings in the game. This would especially be useful to me in the Dust emitters. I could then set a global variable to disable all of the effects without having to add a toggle to every individual part (though, I intend to make that possible for more control in the editor as to how the particles are emitted) and, possibly, a particle limiter similar to the one available in the debug window for smokescreen. Wheels within wheels I say... To wrap up... lo-fi... have you been meddling with your modules recently? If so, I'd appreciate it if you'd update github so I can merge these awesome changes in and get to work on the rest of this monstrosity. That or give me the go-ahead to commit and plan on merging the changes yourself. Unless you've gone and done it yourself, in which case I'll merge my changes anyway... 'cause let's be honest, I do it so much cleaner than you do... (feel free to slap me silly any time you'd like) and, having thus said, my code is surely superior to your inferior attempts at... (Okay, I'm serious... smack me before I say another word...) ... making code that anyone could call "beautiful code" and blah blah blah, blah blah... blah blah inferior blah blah, blahbity blahbity blah blah... (okay, I'm done now... I'll be here all week kerbals and kergals...) EDIT: By the way, we're getting close to that 300 page mark, assuming you're using the default settings for your forum experience. We're gonna be a mega-thread when we do our next release.

I'll look into exposing more of those variables to KSPField usage. I'm all about providing flexibility to the config-level. Just about everything I use in anything I write is, at some point, exposed to the configs sooner or later. - - - Updated - - - I agree, it is likely that those effects are using the same module at the stock rockets. I will admit that the effect is interesting, but it lacks the vertical axis that I am attempting to make happen (and have succeeded in making happen). I just want to make it better. From what I understand, surface effects are just that: surface effects. This means they lack the ability to emit an effect out beyond that surface. I could be wrong of course, but it would actually make sense that the surface effect module would simply do that, and leave the other effects to the engines themselves. That said, I will look at what Firespitter uses just in case it is something custom built that I may be able to draw inspiration from. I won't say that surface effects aren't soemthing to consider adding to the dust effects for an even better experience, specifically with anti-gravity repulsors, but it's not the primary focus right now.

We've had these kinds of discussions before. It's an endless cycle. On a happier note, I'm done with this quarter of school now, and I'm determined to, first off, get some much-needed rest and, secondly, really buckle down and get this particle stuff handled. I think I'm going to dig into the smokescreen plugin and see if there are any techniques I can use for inspiration. I'd like to be able to restrict the total particle numbers for the entire craft so that rovers with over 30 dust-emitting colliders don't cause a massive performance drop. I'd also like to look at what's going on with the surface effects that squad introduced for engines and see if there's anything in there that I could use. With ASP class out of the way, my brain is much more free to pursue these leads. How's the new directory structure working for you, lo-fi? I didn't get a change to fully test it out myself, but I'm pretty confident that everything will work based on the same experiences with other mods doing that on their own, and my modification of some mods into that format by me for local use. I just worry that a few parts might scale weirdly, considering my failure when I set up the Endurance mod to use texture sharing. I ended with with a Ranger that had correctly positioned stack nodes, but smaller-than-normal models. It was a real mess.

That's because we haven't released an update with all the code in a working state. Your experience is entirely expected as such.

You might be able to use a combination of CLS and one of those mods that adds kerbal death to cobble together some sort of airlock mod. It all seems very complicated though. Kerbals wouldn't do that, they'd just open the door and hope for the best.

Still, it flies. That's something anyway.

Bet it's quite the beast to run too, with all those parts.

So, basically you are proposing reinventing the realtree system for KSP. Nice.

Indeed, my patch will eliminate CollisionFX from the parts that have DustFX, at least for the time being. Eventually it would be awesome to be able to allow CollisionFX to do it's thing, but simply override the rolling collisions. I'm afraid to do that I would probably need to reimplement the CollisionFX stuff myself though. Bottom line, I'm making sure they won't conflict in the end. However, as with most MM stuff, I cannot guarantee that all will go as planned due to the fact that CollisionFX, in its currently released state, will add its module to the KF parts, and then my patch will remove them again shortly afterwards. Somewhere down the line I would be great to figure out how to simply have the DustFX override the CollisionFX instead of having to rely on MM. Especially considering eventually I would like to further integrate DustFX into the core KF wheel modules and eliminate the need to use patches at all. As for the compass, surely you could provide Unity with alternate textures to use, or at least use a development package of those props with the old texture formats available or something.

Going for it then. Here's hoping nothing obscure gets broken in the mean time. - - - Updated - - - Haha. That's awesome. EDIT: Commit complete, and synced. I've wanted to overhaul this baby for a long time, but the moment never really felt right. Another thing I'd like to do sometime is further optimize the textures, resizing a few overly-large ones for the detail levels that you'll ever see in KSP, and redoing a few normal maps, as well as introducing my darker wheel textures that I prefer to use... But I'll wait on that stuff for the time being. I still need to look into figuring out what object names to enter into the texture switcher modules to make a texture switch available on some of these parts. All optional of course... not gonna introduce any hard dependencies into anything. Anyway, all stuff I'll look into on my own time later.