Gaalidas

That bubble is really purdy!

To be less vague (shame on you, you silly person, using a yes/no answer for an either/or question) the second option you specified is what you want. On to another topic... what I find a bit irritating is that half way through a play session, the particles seem to stop working. I can tell it to show in the editor, but nothing happens.

If the cabin lights (exterior) could be tied into the "lights" action group by default, much like the other light parts, then the switch could be made to specifically make use of a "activate" and "deactivate" action on the exterior light animation. I'd suggest using the "toggle" except that if the user turned it on manually it would screw things up... unless (this is a good one, thank the grey matter) the light animation also controlled the interior lights. No clue how easy this would be to implement though. It really sounds like the "silly" approach might be the best solution.

Well, for the texture sharing I do have some good news, but first the bad news. I know, I'm terrible that way. So, the bad news is that when I tried to setup texture sharing via the MODEL node I ran into an issue with paths which contain spaces. The "accordion-tex 2" texture the repulsors use has a space between the texture name and the numerical suffix. This threw all sorts of nuts into the project. I had an idea this morning for a possible fix that would not be a "quick test" because I would have to launch KSP and wait for a error to be thrown. What I did was open the model in notepad++ and change the texture name referenced at the bottom of the gibberish it displayed to me to use a dash instead of a space, new file name: "accordion-tex-2" and adjusted the name of the texture to match. Upon loading the game, the model and texture was loaded as if nothing was changed at all. Success, and first time too. After making sure I was still awake and breathing, I had to conclude that I really did succeed in the test and could move on without worrying about what is real. So, while it would be better to have the official files updated so as to remove all spaces from file names, this work-around will have to do for now. I can now replace the textures in the folders with the model with dummy textures of extremely small size, and place the full-size versions in a new folder that I call "CommonTex" because... well... I don't know, I just do. I can then set up each config to replace the entry "mesh = model.mu" (or whatever you named the .mu) with a multi-line entry: Using the AlphaRepulsor as my demonstration part, with the changed file name I mentioned above. MODEL {[INDENT]model = WheelDev-master/AlphaRepulsor/AlphaRepulsor //model name without extension. texture = accordion-tex-2 , WheelDev-master/CommonTex/accordion-tex-2 //texture name without extension, path to new texture from the root "GameData" directory. [/INDENT] } The folder where the model resides will need to have textures of the same names as it expects, but those can be dummies. You can then add more lines consisting of "texture = " in the format above if the model needs more textures that are common. Textures that come to mind: "CF+A" and "RubberLoGrav" which are used several times. "CF+A" might cause some teeny problems due to the mathematical operator used in its name, but I have not tried it yet. Now, the really good news is that your mod is not heavy on the texture memory at all. I'm just doing this for all of my non-optimized mods right now in an attempt to reduce my occasional issues, especially when running KSP on a non-gaming laptop. I'd also like to set up a MM config to add, if Firespitter is installed, a texture swap module. This I did try recently, but failed miserably because I have no way of figuring out reliably what the "object name" assignment in the texture swap config needs to be. I assume it needs to be the object definition in the .mu that references the texture that's going to be swapped, but I'm browsing the .mu files with a text editor and that provides pure unadulterated gibberish... mostly. It's a work in progress, and not necessary at this moment to even think about.

Those eyes are really bright... kinda creepy.

Some people have the lecturer's gift, other have the gift of seeing a suggestion as a lecture. So many gifts, so little time to study them!

I'll admit it all seems a little too confusing at first with all these separate operators that seem to be doing the same thing, but in the end it does make sense to save some time by simply using ~ instead of ! for parameters and values. Otherwise, you'd need to reinvent the wheel, so to speak, and basically parse the entire part configuration in the same way that KSP does itself in order to make sense of it before you even got the chance to check if you need to edit the part at all, and then figure out what to modify... it's all way too complicated for the needs of the tweakers (why does that sound so dirty? no... I don't want to know.)

It's probably been in production forever practically, and we're just seeing the tip of the iceberg... so to speak.

Yeah, so about those... one thing I'd really like to see when you get around to it would be a way to re-center everything with the push of a button. in my own experiments I have had a number of issues. First, after finding out how to use crawler steering, I discovered that it was really difficult to get everything back the normal after using both steering modes in conjunction. I will say that having my rover steering extremely well while traveling backwards and to the left with a slight right-hand turn all with individual wheel suspension and all that... well, it was amazing to say the least. Second, I discovered that it was impossible to re-center the wheels so I could drive straight. I was always either turning left slightly, or right slightly. A few other observations lately that are not fully related to my previous issues: I have been having performance issues with KSP for a while now. This is not due to your modification exclusively, but rather a memory problem of KSP 32-bit overall, which we are all well aware. I use a number of memory optimizations, and I also resize all my textures (some with a really amazing batch file I wrote, others by hand due to odd size ratios or a personal preference for brightness/contrast of the textures in question) so I don't necessarily need advice on memory optimization. What I've started doing most recently is diving into the .mu files to see if all the textures being included with the model are really being referenced in the model or the config. In your mod specifically I have identified some extra textures that we can safely prune. Next on my list is to try and set up MODEL nodes for these things so that we can have a common texture folder and not have to have so many duplicates of the same textures. For now, I've discovered the following textures which can be safely removed due to them not being used in the models or configurations: (Note: my observations are based on the Github package, not the released alpha tests.) In "AlphaRBIInvertingTrack" you can safely remove "model003_NRM" In "AlphaRepulsor" you can safely remove "accordion-tex" unless you want to sue it to replace the used texture called "accordion-tex 2" In "RepulsorWheel" you can safely remove the following: "CF+A" , "RepWheel-diffuse" , "RubberLoGrav" In "RoverBody" you can safely remove "CF+A" So, if you're an optimization freak like I am, go ahead and trim the usage a bit.

Hey, quick question lo-fi... So, I've been fiddling about with the crawler wheels and I've come to the conclusion that you have yet to provide a way to switch from standard (as if... these things are anything but standard) steering to true crawler steering. Is this feature not implemented, or am I missing something obvious? It surely wouldn't be the first time... EDIT: Never mind... I did some code diving and discovered the keys you'd assigned to them.

I've found from the numerous reports around the forums that x64 becomes unstable at random for a random number of people in random situations with completely random results. It's a bit of a random situation we have here. So, that train is crazy. I love the fact that it left very little debris behind when it obliterated itself. I was thinking, you might be able to produce some drag so that the train cars would follow the leader more like a wheeled setup if you had some air-brakes permanently turned on at various positions along the craft, better yet if you could get ones on a certain side of the craft to turn off when turning to better facilitate that action. Just a thought. Now that would be useful when trying to set up action groups for crafts with greater than four repulsors, or when dealing with very large vehicles.

It's not only disturbing... it's down right... okay, I guess the word I was going for was also disturbing. I mean literally, not just another disturbing word. I mean... okay, I give up. English (the language) sucks sometimes.

Holy mother of... okay, I never finished that thought. it's about time we saw a competitor for that long under-developed modification. EDIT: Okay, so I installed it and went on to install some of the launch site addons that were originally built for kerbtown. The result was rather irritating. I proceeded to load up my game and was presented not with the space center, but with the SPH. "That's odd..." I said to myself and proceeded to try and exit the building. Notta. Zip. Zilch. So, I shut down KSP the hard way and proceeded to check my logs for the exact instance it decided it could not load the space center and decided to pick the next option on the list. The following code block contains what I discovered in the "KSP.log" and the "output_log.txt" files respectively. KSP.log -> [LOG 09:35:15.692] [PlanetariumCamera]: Focus: Kerbin [EXC 09:35:15.694] NullReferenceException output_log.txt -> [PlanetariumCamera]: Focus: Kerbin (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) NullReferenceException at (wrapper managed-to-native) UnityEngine.Behaviour:set_enabled (bool) at FlightCamera.DisableCamera () [0x00000] in <filename unknown>:0 at PSystemSetup.SetEditor () [0x00000] in <filename unknown>:0 at PSystemSetup.OnLevelWasLoaded (Int32 level) [0x00000] in <filename unknown>:0 (Filename: Line: -1)

Aaaand.... I have no reply to that. It's a rare thing to weird me out.

You silly silly ... uh... silly person.

I know... That's why we're all here. This stuff is simply too good to be true, but it is. It's like my own tendency to say "okay, that thing looks nice as it is... lets triple the size and see what happens!" It's a bit like the redneck's famous last words: "Hey y'all, watch this!" Actually, I'm not sure what this post has to do with anything. I'm a bit groggy from my night's sleep still.

It does seem like things are going extremely well with this simple little project to freaking overhaul how wheels work!!!! It's almost going too well to be real. Is any of this real? Deep stuff here.

Yeah, that would be a lot worse... nothing sucks more than having a new update released, the dev going on vacation, and half of the stuff in the addon broken.

Holy huge menu options! Fortunately, decouplers don't get a ton of attention when it comes to menu options, so it shouldn't be an issue at the moment. I'd be curious if the action group is still called even if tweakable-everything's staging toggle is turned off and the decoupler is activated via some other option.

Everything? I just got used to the new toasters! Darn it all.

I think it's getting a bit over complicated now... but it would explain why the program's reaction is so over the top.

Hey... Mr. wheel-making sir! We have a problem... sound the alarms, everybody panic, boil some hot water somebody! Okay, maybe not that serious but... Remember that issue with the errant bracket? It's still here! Notice errant bracket: } brakingTorque = 100 ) Which should be: } brakingTorque = 100 } Okay, everyone move along. Nothing more to see here...

Actually, I'm a bit worried that this is more serious than we're all seeing here. If he's getting nullrefs from a model not finding its textures, then there's more going on here than a problematic configuration. Usually if a model cannot find a texture, the game simply doesn't use that texture and instead displays the white layer for whatever use that texture was intended for. For a diffuse, that means a while model... for a normal that would simply mean a non-functioning normal map. In the most extreme case, the part will simply not compile properly and the part will be absent from the list. Critical errors do not occur for this kind of configuration issue. As to the underscores, I have not experienced any issues with textures containing them.

That Eve repulsor craft is... cute... bleh... I feel strange just using that word.

Seriously, or are you messing with us? I have experienced a few limited cases of this model reference not working, but it's been a long time since that happened last. I did notice something however... the textures you are trying to replace have the same name as the textures you are trying to replace them with. however, the model you are referencing is a MK1 model, and the textures you are replacing are named as if the MK1 model was referencing MK2 textures originally. My thought would be that the model was originally trying to use MK1 textures, and thus those are the texture names which should be in the first part of the "texture =" line. I'm too lazy right now to check this out myself, but that's my only bit of advice right now. That actually isn't an issue as far as I am aware, and from my own experience of taking un-optimized mods I have downloaded and giving them common-texture swaps to help my memory load.