Gaalidas

Those are the Kerbal Foundries parts. They're on kerbal stuff I think, and the WIP thread is usually on the first page of the mod-dev forums. We're working hard on a new release. I'm unsure why sudden stops would cause a lot of problems. Under some of our new modules, this is a common problem due to the fact that the craft's weight is taken into account and doesn't have a lower bound to keep the parts from becoming too powerful under an extremely light load. I still intend to drill lo-fi (KF creator) on why that happens and how to dampen it.

Hmm, that engine lighting mod comes to mind. Anyway, the effect should be swappable, if you can find the internal effect path. Of course, you'd need to swap out the entire color configuration as well. I thought about it myself, but abandoned it due to the lack of control over the splash effect itself. To get the effect you're going for in the repulsor dust, you might have to look at what the stock surface effects do. There's also the possibility that you could give the effect we're using now a starting horizontal velocity that moves away from the repulsor field's center. Aren't those inverting RBI tracks capable of being driven on the inverted side? Not that it's very doable due to the size of the track itself, but I seem to remember someone making it happen in the past, pre-KF. In my mind, the only way to do Something like a true wheel with the suspension is to make it into two parts: one which has the suspension system, and another with the wheel, and do something similar to what MSI does to move objects with their associated attach nodes when the parent part is animated.

Sorry, I get carried away sometimes. Actually looks like proper code? I'd better go fix that... -grabs a hand-blender and an old sock-

The look-up for the global variables is actually extremely easy. I added the config file to the "assets" repository and the config manager is in the plugin repository. You don't need to modify anything in that file though. For the globalDisableDust variable, I called it up using: -snipped, obsolete- from a locally defined variable. You simply have to make sure that the variable you're trying to pull exists in the config file, and you're good to go. However, I'm thinking about changing the name of the global variable to something like "isDustEnabled" to make it easier to work with. In fact, I'm going to do that now. Also, yeah... I like the idea of moving as much as possible into the vessel module. I think there's a lot that this mod does that could be done at that level, reducing the amount of work needing to be done on every single part. EDIT: Scratch some of that above, I wasn't awake yet. If you want to add a new variable to the file, you will want to add the variable to the config manager in a similar fashion as I did with the "isDustEnabled" parameter. The log part is optional of course. If the config was instead loading a list or a dictionary of everything in that node, then we could add/subtract variables at will. As it is we'll need to define them. For the Dust stuff, however, you shouldn't need to touch the config manager, just call up the variable with: your_variable = [COLOR=#004085]KFConfigManager[/COLOR].[I]KFConfig[/I].[I]isDustEnabled[/I];

I doubt there will be any issues with the module not being in the config, but it's something that could come up for future modders. My thought was to simply not make the call to DustFX if the part in question didn't have the module on it. That way a future wheel-maker could make that choice for themselves. Once I get something better working for the global on/off switch, I can safely add the module to all the parts in a more permanent way instead of relying on an MM patch system for it. Another thing about all that, I would like to look into not having the camera even become active if the particles are globally turned off. This would further reduce a performance impact for a user with a weak machine. That is assuming that the camera is doing much for performance as it is. I would still like to hash together a test module that would implement a camera per-wheel fixed just slightly above that wheel and taking in the color just below the part itself and see what it does to the performance. I'm just curious as to how it would perform. I could probably just grab the code from the vessel module stuff and stick it into a part module, rewriting the positioning code to use the specific part as a point of reference. That reminds me, I need to look into perhaps detecting the part size, both in relation to the stock size and the scaled size, so I can set a baseline for particle emission size without having to use MM and some good old fashioned guessing to set that. I want the module to be able to figure out how large the effect should be based on how large the wheels are, if possible, so that those tiny wheels don't start producing dust plumes the same size as a mega-wheel (or whatever). Research into figuring out the craft size has hit a lot of dead ends. It seems that all the other mods that rely on figuring out the craft size all make use of those methods in the environment that they were originally supposed to be used in: the VAB/SPH. There doesn't seem to be anything in place already to determine the craft size in the flight scene. I'm now wondering if I'm going to have to try and determine the offsets from the center of the craft for all the wheels attached to the craft, and then keep the furthest discovered distances to use as a range in which to adjust the camera FOV. Anyway. that's all something to deal with in the morning. Time to rest this brain of mine.

Gotta love body modifications. We're gonna have some totally ripped Kerbals soon.

I don't see how it would be an artifact of Kerbal Foundries, honestly.

Just need to update all the part configs to handle the updated lookAt stuff, and whatever else you've done, and we're set for a release really. That's all that needs to be done to make everything functional. I have a question about the new way we're handling DustFX on the wheels. It looks like the KFModuleWheel is now calling the DustFX up, instead of the DustFX calling itself up when the part collides and scrapes. What happens when the DustFX is called up and the part does not have the module defined in its configuration?

Indeed, I'm having a grand time thinking of all the possibilities. I'm currently researching some methods in the Unity/KSP DLLs that are used to determine the size of the craft (I think they use it mainly to scale the craft appearance in the new load-screen previewer, but the functionality doesn't seem to be specifically limited to the editors) which I may be able to use to figure out how I want to camera to behave. I have yet to try changing the dimensions of the camera field to a non-square, but I figure if the guys making those bolt-on cameras could make a wide angle camera, then it must be doable. if I do get around to that, and it seems stable enough, I may even look into adding a second camera and trying to aim the cameras at the left/right sides of the craft to get info for those specific sides and then modify the dust color to react to the side of the craft the part is on. Also, I tested the culling mask and it seems to work well. What I want to do now is find a way to put a randomness into the colors so that it's not just a solid average color. Think I could simply do a mathematical operation on the color object to add/subtract a certain value from the color channels within? Of course, that would affect the alpha level as well, which is not what I want... I might have to disassemble the color into separate RGBA values and then apply the variance. Hmm... need to do some research. Anyway, wheels within wheels. For the time being, I have merged all of this with the main repository since the camera grab seems stable, and that includes my Logging Utility that I talked about a while back. It's not a complete implementation of what the other utility mods do for logging purposes, but it works for now and seems stable. I attempted to make it work the way the others do it by allowing the calling methods to simply call it by name, without having to define an object in the local scope, and with automated checks for the class/method name that is calling it, but those things were resisting me. I kept getting situations where, first off, it couldn't find the method name in the current scope even though the other mods I looked at didn't seem to have anything different in them and it worked perfectly. Secondly, once I defined an object in the local scope, it then couldn't locate the name of the class/method and would either display the class/method name of the class it was coded into (the log utility class) or error out on me. It couldn't even locate the names when called into a string in the scope of the class that was calling the log. I threw in the towel on those and simply defined a class-name string at the top of the files I wanted to use the log utility on, and defined at object for it. I want to make this thing work better in the future, but right now it's looking like it can't be done, unless (maybe) I separate it into it's own DLL so the KF_plugin project can reference it properly. Complaints aside, you'll see how it works. It will prefix the log entry with "[Kerbal Foundries - class_name()]: " and will output it as a Warning, Error, or just a basic log entry when you call it with "KFLog.Warning/Error/Log" and even has a "KFLog.Debug" option which will turn the prefix into "[Kerbal Foundries - class_name() : DEBUG]: " so it can be easily found. If the class name is not passed to the utility, then it will come out simply as "[Kerbal Foundries]: " Finally, there's the global variables. I'm still working on those, but I merged in the definition file a day or so ago, and today I've added the source file to the repository, and added it to the project file. Extremely WIP right now, but I can report that the variable is read, and the DustFX module does not give any errors when using that variable data. Whether is all works is another story, but I want a way to toggle it in-game before I do much testing. I'll get a per-wheel toggle working soon enough anyway. I've made some preliminary attempts, and it might even work now if you want to give it a go. It's on the part's context menu and available in the editor and the flight scenes. - - - Updated - - - That work be awesome, but it's a bit out of my range right now. I didn't even create the basic code for emitting a particle, much less create something brand new like that. Besides, I'm trying to create an effect that will be applicable for standard KSP uses, which means off-world dust plumes that don't necessarily react to the gravity/atmosphere on that body. Something like that would only really be useful in a desert region on a Kerbin-like body. My hope is that squad implements something like material densities to the biomes in the future, and creates their own per-biome surface effect system, or even a whole part-scraping particle emission system of their own. Sure, it would make DustFX obsolete, but that doesn't mean I couldn't still try to expand it with cool new features. At least then I'd be able to work off of official modules which would probably have much more efficient ways to detecting the materials we're scraping over. Here's hoping someone at squad is paying attention when we unveil this mod to the public.

On the GUI stuff, I will either take a sample from Smokescreen again, or there's another option that I don't remember the same of... it was a prefabricated set of methods useful in creating GUI windows in any unity environment that I downloaded a while back. Gonna have to dig though some of my sources to find it. Once i get KSP to load properly again (deleting some extra-huge static models from KerbinSide and eliminating overly-useless small statics that don't do anything for game play) I'll get a chance to test my per-part toggle for the dust too, which should disable itself if the global toggle is turned on. Actually, on that note... I'm confusing myself with the global toggle being "true" if the DustFX enabled state is "false." I may just change that around to "EnableDustFX = true" in the global config. Anyway, I'll update the code with the changes soon. we still need to figure out if we can use the DustFX stuff for the repulsors without having to have a separate module, while still maintaining the modifications of the dust based not only on craft speed, but also on repulsor height and with a small emission happening even when stationary. The reason I spearated the modules in the first place was because of the issues with separating the settings based on what type of part it's attached to. That brings up another point... I think the dust is emitted per-wheel collider based on the speed of the vessel. I wonder if that could be changed to take the speed that the individual part is scraping over the surface instead? Actually, it might do that already, but I have not been able to read the code very well in that area, so I'm not sure what it really happening. Anyway, the idea is that if a larger craft with a wide wheel base is turning sharply, you'd expect more dust to be thrown up on the outside of the turn. I also want to find a way to have a very small dust emission from the front/back of a track when turning at a stationary to near-stationary surface speed. Finally, I want to made the base emission amount settable from the biome configs. I'm thinking that, since I was previously trying to use the alpha layer to control the visible dust, I could use the alpha layer to also define the base emission amount if I can figure out how to extract that value from the color in the biome config file. This would also give us a reason to re-enable the biome color definition loader for the DustFX module in addition to loading the camera colors. That brings up yet another thought: the camera currently sits at a fixed height above, I'm assuming here, what would be considered the exact center of the physical craft. I'm wondering if it could be made to set that height based on the size of the craft so that we could sample all the colors that the vessel is currently running over. Either that, or somehow scale the field of view for the camera. Also, if performance becomes as issue with something like that, we might be able to improve performance if we switched from taking a square image to a very short and wide shot, scaled by vessel horizontal size (x/y if looking at it from above, using my limit knowledge on what the axis indicators refer to in KSP) so that you'd get maybe 2 pixels heigh, but... for example only... 20 of them over the width. It's less image space to cycle through when averaging all the colors. Just a thought. Anyway, don't want to bother you with figuring all of this out... you've got other things to finish before we can release this baby. Just sharing my thoughts and plans for the future of the "special effects" department. I'm gonna make this baby look purdy!

So, every time I've tried to load up PP in my game, for quite some time (months, or longer), I have been hit with this "game-load-process-stopping" exception: From KSP.log: [EXC 12:05:56.780] NullReferenceException: Object reference not set to an instance of an object ProceduralParts.ProceduralSRB.InitModulesFromBell () ProceduralParts.ProceduralSRB.InitializeBells () ProceduralParts.ProceduralSRB.GetInfo () PartLoader.CompilePartInfo (.AvailablePart newPartInfo, .Part part) PartLoader+.MoveNext () [EXC 12:29:33.614] ArgumentOutOfRangeException: Argument is out of range. Parameter name: index System.Collections.Generic.List`1[LoadingScreen+LoadingScreenState].get_Item (Int32 index) LoadingScreen+.MoveNext () From output_log: *PP* InitializeBells (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) NullReferenceException: Object reference not set to an instance of an object at ProceduralParts.ProceduralSRB.InitModulesFromBell () [0x00000] in <filename unknown>:0 at ProceduralParts.ProceduralSRB.InitializeBells () [0x00000] in <filename unknown>:0 at ProceduralParts.ProceduralSRB.GetInfo () [0x00000] in <filename unknown>:0 at PartLoader.CompilePartInfo (.AvailablePart newPartInfo, .Part part) [0x00000] in <filename unknown>:0 at PartLoader+.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[LoadingScreen+LoadingScreenState].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at LoadingScreen+.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1)Any ideas?

Looks like an awesome replacement for the old HOME modules. Looking forward to trying these out.

To be honest, I haven't tested it enough myself to be sure that it is still working right now. That said, I also haven't tested the culling mask on the cameras yet, so I'm going to fire KSP up now and try it out. I also did some preliminary work on defining a "KFGlobals" config node and calling up a "globalDisableDust" parameter to use. I've also started work on a "localDisableDust" field for a context GUI option so that it can be disabled on a per-wheel basis, which will hide itself from the context menu if the global option is set. No GUI toggle for the global stuff yet... that's going to take time. The great news is that if we think of other options that could use a global toggle, adding those to the config node will be super simple. I used SmokeScreen as a template for it, since it has a simple top-level config node for its global toggles. I just thought of a tweak I need to make to the config loader though, so off to do that now and then testing time. EDIT: Good news, the config loads and a log entry was able to report back the value of the parameter. No clue if the module will accept it, cause I ran uot of RAM storage before KSP loaded.

This is probably the same issue that makes the parts overheat and explode even when covered by fairings. The skinned meshes use for the tracks tend to report at being massively larger than they are supposed to be when the game's measurement system does its thing. In other news, I am going to test, in a moment here, adding a culling mask to the camera for the dust color sampler. It turns out that the culling mask parameter takes an integer value that corresponds to the unique value for the combination of any number of layers and their corresponding numeric values defined by a binary place value output. For instance... I used the layers for water and local scenery. Water is layer 4, and local scenery is layer 15. You put this together by first defining them as "cullingMask = (1 << 4) | (1 << 15)" which translates to "(16) | (32768)" which are added to get "32784." As far as I can tell, and this comes from a lot of experimentation in the code editor, is that the first number is the identity value for the calculation of the second number, which is a binary place value. Using SharpDevelop I am able to tell the editor to turn this into a multiplication equation which gives me "1 * place_value_value" for each equation. For instance, the number for the place value of 4 in binary is equal to 16. That means it's a zero-based number where "1 << 0" will become "1 * 1" or "1 << 4" will becomes "1 * 16" and so on. Then you strip out the redundant identity value and add all the values together. You can either let the compiler do that, or have your editor calculate a constant value for each set, and then for the entire group. If the tests are successful, then the craft no longer needs to be part of the color calculation and even craft-emitted things such as shadows or lights can be omitted from the calculation.

That's really strange lo-fi. The weirdest thing that ever happened to me using the biome color definitions was when I was heading towards the mountains and hit a patch of polar biome in the wilderness somewhere around the KSC. That's why I like the camera thing better. I wonder if there's a way to get the camera to ignore the current vessel. Either that, or some way to position the camera below the craft (like a little bit above the wheel colliders when grounded) and take a super-wide angle shot of the ground there. Another thought that comes to mind is that the dust color will then also be modified by any engines the user is running, lights that are illuminating the ground around them, and shadows if their computer can handle them. Thought: I wonder if one could grab the visual of the craft's position on the planetary level (such as what it looks like from orbit, or in the map view but without the various node and info layers rendered) and use that instead of the local image. My brain is really going fast now... Overall, it's looking like getting the biome color stuff working properly again might be a better option. The only thing I can think of is that squad might have changed some of the format in which the biome names are handled. It's not like we have a way of directly asking KSP what biome we're in and getting a direct response. I believe some strange parsing is done to nail it down. I need to browse the code again. Also, I believe our local reaper put something into the code that allows us to define colors for a LandedAt definition of some sort, which would take a more specific name for a location instead of just the planet and biome. That, or it might be able to take a specific coordinate set. I never understood how I could make that work or how it would be useful. EDIT: Really guys? I spent 5 minutes looking at the camera stuff in the unity DLLs and discovered something which, unfortunately, I have no clue how to use but seems promising. public int UnityEngine.Camera.cullingMask { get; set; } Summary: This is used to render parts of the scene selectively. I'm going to do some more digging to see what this accepts, but it could be an answer to the problem of the craft itself factoring into the colors.

Well, I don't know why the biome info stuff is defaulting for you, because it works for me, at least as far as showing the default when colliding with the KSC static landscape vs. the actual planetary surface. I have not had a lot of time to test other biomes, though I recently re-installed some of my Kerbal Konstruct stuff that will allow me to launch into other biomes for quick testing. I propose that we keep both systems for selecting colors available and perhaps create a global toggle to switch between the two methods for the end user, or disable it completely. I've been doing some fiddling with the idea of providing a small configuration menu via a toolbar button that would allow for toggling some global settings for the mod, saving and loading from/to a single-layer config node. That way the end user can decide if they can handle the extra effects or not. Even if I never get around to a GUI, I'd like to allow for some global settings to be available. it should be pretty simply to set up compared to the biome color loader, considering we'd be able to define exactly what we're loading and saving, where the biome color stuff is saving/loading an unknown number of nodes. The whole vessel module thing does sound pretty interesting though. Could reduce the amount of redundancy in a lot of mods out there which seek to control multiple parts on a craft in sync. At least that's what my limited knowledge is telling me about what I've heard. So, does this mean that each wheel does not have it's own camera? If half of the wheels are roving over a different material, they will all be the same color still? For small craft, that would be fine, but for larger vehicles you'd have a real continuity issue. I guess my next question is this: where exactly is the camera positioned in relation to the vessel, if indeed every wheel isn't getting it's own camera?

You multitasker you.

I don't mean to be the rear end of a donkey here (okay, maybe a teeny bit) but I'm curious... from the change log it says "Fixes for tweakscale interaction for transalting IR parts". What the heck is "transalting"?

Good to know. I was just a little worried when I noticed the screenshot references. Good luck trying to kill yourself. I'm pulling for you. If you do make it to the other side, be sure to come back and let us know how it is. I'm particularly interested to know if there's baseball in heaven. If I'm pitching tonight, a little heads-up would be awesome. I did some poking around in the code and I really don't think it will emit any dust on non-static or non-PQS collisions. I'll do some testing later if I get a chance. We're getting some record temperatures for my area and it's rather hard to concentrate when the humidity is high enough that you're practically swimming though the air. Of course, it's nothing compared to the hotter areas of the world, but it's all relative anyway. If I get any dust from those non-PQS/static collisions, I suppose I could add something similar to the check for the water collider that, instead of redefining the dust parameters, simply disables it. I also intend to further limit when the dust is emitted since I really doubt that a ton of dust would be emitted when moving very slowly over the terrain. Another thing I want to look at, or get you to look at lo-fi, is further integrating DustFX with the Repulsors, now that you've been integrating it more with the wheels. I also need a way to redefine the default values of the DustFX fields based on whether a repulsor or a wheel is calling for it, so that I can switch between throwing dust when the craft is moving, to throwing dust when the repulsion field is active. The complexity of it all is why I originally planned to have a separate module to run the Repulsor effect This also gives me an idea: perhaps we should extract out the effect-based sound effects for the wheels/repulsors and any sound stuff from the DustFX files into a separate source file that would act as our audio-controller method. That might help to further reduce the redefined code in all of our various audio systems. We might also be able to define an audio modifier for when the wheels are throwing up dust vs. when they're simply rolling slowly/idling. For the repulsors, it would be awesome to have an idling sound for when the repulsors are active, but not moving, and then a sound for when they are active on a moving craft, and a third for when they are active over water. If I get bored later, I think I'll do some messing around with all that and see what the options are. If I use the stock module for the engines as an example, I may be able to come up with something we can use that will be able to be set up the same way the other audio calls are done in the effect nodes. EDIT: A thought about optimization of the camera stuff. One thing to look into is whether or not the camera is still taking samples from the terrain when the dust effect is not running. When the craft is stationary (for wheels at least) the dust isn't being emitted and the camera should probably be turned off. For instances where the craft is over water, for repulsors and the screw or any other propeller enabled parts, you don't necessarily need to take an image for every part. Besides, since the screw and other such parts are probably going to be under the water when running, you'll get the image of the ground below the water and not the water itself, which is why I'm trying to find a good way to define the color to emit when over/in water. I'm thinking that instead of having a camera active for every wheel on the craft, we need to find a way to run the dust controller on the vessel as a whole, taking stock of all the wheels on the craft and building an array of cameras that cover the average areas between wheels that are within a certain distance of each other, or individually for outliers. This would reduce the number of samples being taken on a craft where someone might either tweak the scale of a bunch of medium wheels to really tiny levels and attempt to support a massive craft with, say, 80 of them. Or if someone used the same number of small wheels to do the same thing. Granted, the standard steering and suspension modules would probably slow the game down a ton with 80 medium wheels, but the camera and dust systems would slow it down by a larger factor than the other modules would. I'd like to find a good way to not only average out of the effect between individual parts that have multiple collision points (tracks and such) but also be able to average out the effects between closely-positioned separate wheels. I'd also like to find a good way to limit the dust being emitted from wheels that are in the very front of a craft or are not along the edges of the craft. I don't want to see dust rising through my nearly ground-hugging craft's hull when I have lots of wheels mounted under it to support its massive weight. The trick is going to be finding a balance between attempting to optimize the number of dust and color samples that are being called for, and the performance hit from simply detecting all these conditions. eventually you could optimize the whole system a ton, but the methods for detecting all the situations where optimization can occur could start lagging the simulation a ton on their own. So, yeah... Output output output... I'm going to do some digging through your code, lo-fi, and see what I can figure out from that. I assume you have some way of taking stock of all the wheels of the craft, since they all handle their steering in relation to each other so you can have that variable steering thing going on. Of course, all this should be planned for a future release, and not the one we really should be doing now.

Excellent question. I have absolutely no clue. At its core, if CollisionFX caused sparks to fly when rolling over other non-static objects, then it's very likely that DustFX does as well. I am not completely sure of this, however, as I have done very little testing in non-planetary collisions. I have a feeling that it might not throw up dust on those objects though, since I seem to remember stripping some of the old CollisionFX code for detecting dynamic object collisions and such. I'll need to go dig through the old code vs. the new to know for sure without simply testing it. Dust really shouldn't be emitting from solid objects like those. Hey lo-fi, I have a question. The camera color grabber uses tiny little screenshots, and I noticed something in the code that pertains to saving an image somewhere. Does this mean that, technically, the game is taking tons of miniature screenshots and possibly saving them to disk? If so, are these screenshots then building up in the screenshot output folder and clogging the disk? I ask this without having actually tried it out myself, I'm just curious.

I got into it alright... I didn't even know it was there before. It looks good. I'm ready to merge it back into the main branch whenever you feel it's ready. I intend to look into how we might use the biome definitions and the camera data together... if that's even necessary now. If these camera things don't hurt performance too much, then we might not really need the biome definitions at all, at least not for color. I would still want to use a biome definition file to specify material hardness and such, so that we don't look like we're carving bits of concrete out of the pavement when we roll over it, but don't look like we're rolling over pavement when tearing down the desert sands. I could probably just pull out one of my old test rovers with over 32 wheels attached to the thing (per side, yes I am that insane) and see what happens to my frame rate. I did see that you commented out the line that caused the file writer to activate. At least we don't have to worry about it overwriting the file every time we start it up. What would be nice is if it could populate the file with any planets/biomes that are not defined in the file, while leaving the defined ones alone, in case the end user tries to edit it manually and looses some of those definitions or breaks the format somehow. Anyway, I'm learning slowly what all that stuff does and will probably get the hang of it eventually. It's weird how my brain will make absolutely no sense of anything for the longest time, and then suddenly it's all clear as day. Just wish it would do that faster.

Actually, that's the beauty of it. I started, way back in the day, renaming everything from CollisionFX to DustFX. The original mod didn't have anything called DustFX. Either way, I will rename things back so they can all be identified as a part of the KF plugin. So, you got it to regenerate a file, but will it override the old file if I make changes to it? The default file I believe simply spits out the color that the biome would be represented by in a biome map. That wouldn't necessarily match what's going on with the terrain.

That is just a teeny bit disturbing to visualize. - - - Updated - - - Yeah, everything is going to need updating. You just couldn't leave things alone could you? And now you have to pay for it. Oh, slightly off topic... okay, actually it's really off topic... I was looking at the RPM mod today to try and find a fix for the transparent pod internal props going haywire and I think a few dev versions ago they finally nailed it down. I'm hoping for the best that it will fix the issues I had with the roll cage internals a while back. Okay, back on topic! I updated the wheel config repository with the additional object names for the mirror module. Also, I noticed you uploaded a compiled DLL for the new DustFX stuff, but I'd really love to see what the code behind all that looks like. I'm looking forward to you updating the source.

So, the quoted post is from a few pages back, but I was doing some reading here and had to make a comment on this one. There is one way you could add panels and such for something like a command seat by creating a completely transparent IVA scene for that command seat, using parameters that specify that the helmet is required within, and then adding some props to the front of the IVA scene that would correspond to the seat and whatnot. Visually, you'd still just have a Kerbal in a command seat, but in the configs you'd actually turn the command seat into a pod with an IVA. lo-fi has done something similar with his latest pod which is a sort of roll cage, extremely minimal, looks like a basic part with a command seat inside it, but it actually uses a transparent pod. That's the closest way I can think to have a sorta-external RPM prop. At the very least, you'd be able to command your craft from a first person view from the command seat and the monitors would still show data when outside of the IVA scene. Another idea would be to create an empty (more or less invisible) pod with an IVA that simply contains a large monitor that is placed on the craft radially. You'd still have to have a kerbal inside it somehow, and functionality would only be in the IVA view, but you could probably hide that part of the scene inside the parent craft and leave a copy of the monitor displaying (really large like) on the outside of the craft, thus creating a relatively easy way to display information on the outside of the craft. Yeah, it's a rather weird idea, but it could work possibly. Alternatively, maybe you could have an internal camera and use something like that CCTV mod to display the camera on one of its large external monitors with the camera itself aligned directly with one of the IVA panels. That might work.

That's why I want to define some more parameters in the biome definitions file I have (a config file it gets all the color data from) so that we can define a base size/strength/whatever per biome to be used as a baseline for all the other calculations. In other news... in case you haven't heard, I am awesome. No, really... it's totally true this time. The voices said so, and they never lie. Specifically, I have fixed the KF conversion of the ERS wheel's treads where both tire treads show up for either side, causing flickering and general messiness of the model. All I had to do was load it up in blender (the one wheel I've tried lately that could be imported) and look in the hierarchy for the object names for the wheels. There's actually two objects for each wheel direction, and they are labeled by their intended direction. I simply added those object names to the mirror module, and tested it a few minutes ago. Works perfectly. I'll update the wheel config repository a little later. I'm too tied up with other work right now.