Gaalidas

I know that there are some strange things done when the tracks/wheels are also scaled up to accommodate the heavier and larger craft, but if you're using the standard scale I would expect the heavier one to accelerate and handle more like an obese pregnant yak with a lame foot. I keep meaning to find a few places where I am unsure why you did what you did when the wheels are scaled up, but at the moment I forgot my references in the code and I'm too lazy right now to dig them up. That, and I have yet to test my local tweaks in my latest recompile of the mod. maybe I'll get around to doing that later and can finally merge the changes needed to integrate DustFX fully with KF. All that needs to be figured out after that is how I might make use of the "tweakscalecorrector" field to modify the base dust effects without having to merge the dust effects with the KFWheel module itself. hmm... I wonder how hard it would be to grab the value of that variable from outside of that module and use it in mine... must do some research later... after my Statistics quiz. -shudder- EDIT: Nailed it! (both the quiz and the variable grabber). Turns out all I had to do was instantiate the KFModuleWheel class and point a getter towards the variable I wanted. Hopefully that will grab the value for the current part properly. Needs testing I suppose.

I've been looking at the Unity 5 stuff that's been discussed and while those effects are cool and all, the switch to Unity 5 will likely break just about everything the community has done to mod the game and likely make some of the more ingenious mods completely unable to even function no matter what is done. I'm afraid Unity 5 is going to be a dark time for KSP, and I for one am disabling my Steam auto-updating feature in preparation for this game-changing event.

Leave it to these crazies to attempt to further fix something and end up breaking it more than before, and ruining our ability to make it all better.

Actually, I did nothing to any of the files, otherwise I wouldn't have attempted to ask about it here. I just re-downloaded the mod from KerbalStuff and checked for identical files and here is the initial result: In the folders named "125AHMS" and "250AHMS" there are files named "model.mu" which, under a binary difference comparing program, turn out to be identical. The configs both place their scale and rescale parameters to 1. I'm no expert, but that tells me that the part, when placed in the editor, will be exactly the same as the other one, in shape and size. When placing the third part in that set, I discovered that the model was slightly different, but had the same dimensions and stack nodes that were embedded too far inward, resulting in clipping between connected parts. This is from a fresh, unaltered copy of the files. Nothing added or removed.

Having a strange thing occur where all the parts are the same size. Upon checking the different models, they are all identical, and all the configs are identical in the scaling values. So, considering the evidence, it's not all that strange. The strange part is that the parts are claiming to be different sizes when they aren't.

Perhaps a note in the part description should read: "Warranty void if inverted." Either way, I'd think that inverting the inverting tracks would cause the tracks to behave normal, except that they're inverted. Guess we need to investigate into some form of check to see if the tracked part itself (as well as the craft so we can track pre-inverted tracks being put right-side up by an inverted craft) is inverted and thus invert all the controls to compensate. Hmm... I think I just confused myself. Which way is up again? On another note, I messed about with the ERS wheel implementation last night, and it's interesting at the very least. Having the issue where the wheel treads seem to be doubled (either that or it's showing both the forward and reversed tread model at the same time), but otherwise not too bad. I have no idea what that other wheel is that you posted a config for, nor where it's available.

well, lo-fi, you've got my post a few pages back which explains what I've found in the area of texture sharing. I've even done it to a few parts using config bash methods to save ram locally, but in the end you'll have to choose one of the options available and do some reorganizing of the assets. It's mostly easy to do, just a bit of a pain in the brain to keep track of. Of course, it'll be completely pointless for the parts that have dedicated textures.

We definitely need more general assets available for non-model-making modders. I've got quite the artistic side to my personality, but I have no clue how to wrap my brain around the modelling stuff. Some things just don't mix in my brain. So, I'd encourage you to release some of this stuff for general use.

I suppose I was mainly thinking along the lines of something brand new that KSP wouldn't, obviously, be doing already. Otherwise we'd have stock reflective windows. Take the old mod "KerbPaint" which, before we even had alternative asset loader capabilities (which lead to the DDS loader mod), used texture masks (which were not actually loaded into the game) to define the color replacement regions. I believe it also used custom shaders to accomplish all this. If something similar could be developed to work with the reflection part of TR it would allow much more freedom of texture modification without the need for nearly-completely transparent regions of the texture in the areas where you don't want it to reflect. Either way, this line of thought isn't even a "request" at this point. Just something to look into when you're up to it. If texture-mask usage could be done before, surely it can be done again. Otherwise, we'll never be able to have freely-retextured parts with reflections. Another way of going might be if we could simply invert the behavior of the "reflection plugin" part of TR in that instead of non reflecting in the transparent areas of the texture, it would treat the transparent areas as the reflective areas. Granted, you'd have to cross some wires somewhere between the texture load and the reflection rendering, and current mod authors would have to invert all their alpha levels to match it, but it would sure do the trick. I don't really know much about all this though, just thinking out loud, so to speak. With some research and fiddling, all of this might be possible sometime.

Yeah, so... at one time in the far past this actually made a difference and there was even a tool to convert all those extensions to to correct the textures. However, I joiend the KSP bandwagon around when .18 was released, and at that time the extension in the .mu file no longer made a difference. However, I will say that the stock DDS support is rather buggy and so I would still suggest that the mod author make up their own mind about DDS and if they don't do it, then it is up to the end user to convert them if they wish. DDS presents a number of issues related to quality (mip-maps may increase performance, but often times you will see a blurry mip-level even when the camera is pressed against the part) and, as I have experienced (along with several others, though we are a minority at this time), KSP will sometimes be unable to load a particular DDS image for unknown reasons leading to pure white parts. Because of this, I have had to, quite annoyingly, manually re-convert most textures back into PNG to avoid "missing texture syndrome."

Be careful when converting to DDS though, I've had a lot of trouble with textures suddenly being unreadable by KSP and ending up with pure white parts. For the time being, I've had to convert all the DDS textures from most of the mods I use back into PNG to get them to load properly. In other news, I just got a ton of new inspiration for rover design thanks to a heavy dose of off-road mayhem. My father and I just went to see Mad Max. There are really no applicable words for the whacky stuff I've just seen. - - - Updated - - - That is what we need screenshots of. Rocket powered dragsters with parachutes. The only thing that could be done with that, to make it more "Kerbal" is to have rocket power dragsters with rocket powered brakes, and no parachutes.

Technically, the stairways are just really steep inclines and not actual steps. I've seen small wheeled vehicles go up them, I took a kerbal up to the control tower on the island runway before, and I even witnessed someone land a small probe in the tower, then roll it down the stairs. I imagine navigating them with a craft requires some very careful movements. - - - Updated - - - A few notes on what lo-fi has said here: The wheel sounds mod, last I checked, still relies on the stock wheel module to determine what pitch/volume to play the sounds at. So, while KF wheels and the stock conversions will behave alongside the sound mod, the sounds will only actually react to wheels still using the stock module. Anything running the KF module would rely on the way lo-fi implemented the sounds himself and not the way the other mod handles them. So, as lo-fi said, you'll have no problems, unless you consider the wheel sound mod not actually working on the KF-configured wheels a problem... in that case you'll have tons of problems. It's all a matter of perspective really.

Just needs that reflection plugin stuff added and you've got yourself a winner. I loved that movie as a kid.

Actually, the idea is not to load it over the normal texture, but to simply use it as a reference mask. The old KerbPaint mod didn't even load the masks with the rest of the assets, and this was before we had anything like a custom asset loader (added before we left KSP beta) and simply used them to define where on a part you were allowed to recolor, and what level of coloring it would accept and/or mix. I had a look at the TR code however and it looks like the texture is being referenced directly in the shader, but I'm no expert in C# so I'm not going to set that in stone just yet. At the moment, however, it looks like we're a bit stuck. The only other alternative would be to try and import the model into an editor and add an object in the place where the window should be which could be mapped to the same texture coordinates as the original window, but given a separate texture that would hold the modified window values. It's all rather complicated. It might be easier for me to just take your texture and... err... no, that would still result in reflections bleeding into the non-reflective areas. No, to make this compatible with re-texture packages, we need to be able to reference the windows either as replacement objects in new models, or using a texture mask. I guess we're stuck until a more seasoned programmer can take a stab at it. Too bad KerbPaint totally died a while back... though there might still be some usable code in there... I must see if it's still available.

So, there's been a bit of discussion (okay, more of a monologue on my part, not much more than thinking with my typing fingers) about the reflection system. I have yet to do any code diving, though I totally intend to do that later today, but... from the way it has been described to me, the level of reflectivity on a model that does not have specific objects defined for it's windows, as an example, or in the case where you want the specific object to be less reflective overall, is reliant on the transparency of the textures applied to those objects on the model. I was thinking that this could be more controllable if there was an optional parameter that could be set in which the reflection system ignores the main texture of the part and uses a separate mask image instead (a basic white texture with the non-transparent parts made completely transparent, just as it works with the main part texture right now. Completely optional of course, leaving the current functionality untouched if the parameter specifying another texture to use as the mask is not supplied. Any thoughts? As I said above, I fully intend on taking a look at the code and seeing how it might be possible in my own time, but I thought I'd run it by you in case this was already implemented and simply undocumented (not that I've read any documentation anywhere, I'm way too lazy at times for that.)

Ah, I think I get it. So, if the model does not have a specific object defined for the window part, then the entire texture needs to be altered to make only the window become reflective. Otherwise, just defining the object in the config would do the trick and you'd only want to modify the texture if the part where the window is located needs an adjustment to its reflectivity levels. Seems to me a good alternative method would have been to allow the modder to specify an alternate texture to use as a mask for the reflectivity of that part. That would be a lot like how we used to have to mask out additive regions of red, blue, and green to mark areas of interest for KerbPaint to recolor the part (primary, secondary, and tertiary color, respective to red, green, and blue, and/or their resulting mix when additively overlayed onto each other.) This would allow for texture replacement without having to mark most of the texture transparent, which causes the default model texture (blank white) to bleed through, thus washing out the color scheme and making texture replacement a pain. It could simply be a white image with the non-transparent parts made completely transparent just like it is now with the main texture. This is all just concept right now of course, but it has inspired me to look at the TRReflection module code and see what I can come up with. Thanks for setting me straight though. As for the MM configs, if you simply follow the pattern I provided it should work like a charm. Note the word "should" which absolves me of any responsibility if the claim turns out to be completely false. I'm pretty sure it's not false though. Yeah, almost totally positive that it's not a case of not being not false. Are you confused yet? Good, cause I sure am.

Wow, this is exactly what I was hoping someone would do for this kind of thing. I have absolutely no clue about how to write a GUI, nor the patience to figure it out. Besides, I'd probably just get frustrated and pull all my hair out. I'm not old enough for hair loss... only greys.

So, I checked the mod over to get an answer as to why it wasn't already set up with MM patches, and I couldn't find any reason. So, I rewrote the configs for use in MM. I also could find no point in any of the replacement textures, but if there was a point I would think you would continue to use TextureReplacer for that function instead of replacing the files directly considering your use of that mod for the reflections. Anyway, if you're having problems with the MM patch-writing process, here's what I came up with (and placed in the TextureReplacer root folder for lack of a better place): @PART[solarPanels2] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = panel3 panel04 panel05 panel06 panel07 panel08 } } @PART[solarPanels4] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = solarPanel4panels panel2 panel3 panel4 pane5 panel6 } } @PART[solarPanels1] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = basepanel panel1 panel2 panel3 panel4 panel5 } } @PART[solarPanels3] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = basepanel panel1 panel2 panel3 panel4 panel5 } } @PART[cupola] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = obj_base } } @PART[largeSolarPanel] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = panel } } @PART[Large_Crewed_Lab] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = Lab } } @PART[Mark1-2Pod] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = SideWindow FrontWindow } } @PART[Mark1Cockpit] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = body } } @PART[Mark2Cockpit] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = Cockpit } } @PART[landerCabinSmall] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = obj_base } } @PART[mk1pod] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = window } } @PART[mk2Cockpit_Inline] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = Cockpit_inline } } @PART[mk2Cockpit_Standard] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = COCKPIT } } @PART[mk2LanderCabin] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = cabin } } @PART[mk3Cockpit_Shuttle] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.5 0.5 0.5 %interval = 1 %meshes = cockpit } } @PART[solarPanels5] { %MODULE[TRReflection] { %name = TRReflection %shader = Reflective/Bumped Diffuse %colour = 0.2 0.2 0.2 %interval = 1 %meshes = panel } }I used the % operator here which tells MM that, if it finds the module already present, it will simply update it with the values provided, but will otherwise add them if they do not exist in that specific part. I also didn't include one of the items (the file named "CREW.cfg") because it had no definitions in "meshes" which I took to mean it would possibly make the entire thing reflective, which is a bit overkill if you're only after window reflections.

Sometimes you get certain mods that show up on the first page, but the third in the series gets buried to the second page and people just move on to other things rather than go to the next page. KerbalStuff needs to allow the number of items per page to be expanded, or allow a mod entry to expand into a sub-list so modular modification packages can group their stuff together. Another nice feature would be to allow the parent entry that hosts the sub-list to have a "download the latest version of all sub-listed mods" button or something. I'm definitely guilty of not checking out stuff that are buried and later, upon finding out they exist, I'm amazed I never saw it before. If only we payed more attention. As for IR rework... yeah, it's pretty modular, but it also doesn't reuse a lot of assets. Granted, there is a part of it that uses dummy textures, but for the most part there's a ton of textures that are all identical to each other in separate folders. I will grant you that most users would not notice the memory impact, but I'm running on a non-gaming laptop and I have to grab every little bit whenever possible. This leads to me having to do some modifications to how the IR parts reference their models and textures whenever I update.

I'm sure confused easily. That's not to say I don't like modularity, but whenever I modularize something, I confuse myself. It's a confusing conundrum of confusion-inducing confusion. Are you confused yet? I sure am. Something confusing to me right now is the fact that, when using DDS textures, even the stock unmodified ones, the game seems to want to selectively not load some of them properly and display the default white texture on the parts affected. It's apparently a completely random occurrence, and even affected my own conversion of the KF parts into DDS. I've been reverting to using PNG on all my modified textures for the time being. My latest theory is that KSP is not forcing mip-map levels instead of only using them if they are present in the file. Because KSP is forcing the mip-map levels, if the level is not present in the file it will display a null texture. Because KSP has a setting for less-then-full resolution textures on load, then it detects the lack of certain mip-levels when loading the assets and outputs a "texture not found at -insert url here, which can be confirmed to have that texture present and accounted for-" and displays the default white instead. I'm working on proving this theory. Back to modularity... it would actually cease to be all that necessary if we could just reduce the number of duplicate textures being loaded. Right now the repulsor diffuse texture is being loaded for every part that has a repulsor in it, including the model for the medium wheel which is based on the model that was used for the currently perpetual-WIP part "repulsor wheel" and the newer repulsor effects which include that electric texture, and its accompanying emissive. There's also that arrow texture which is being loaded several times for each part that uses it. I've talked before about texture sharing, but I suppose I'll need to reiterate it. In short... there are two ways we can rectify this. First off though, that wheel which needs the repulsor texture for the deleted object within it could either be re-compiled without the need for that texture or the texture itself can be reduced to a 1kb dummy texture. For the others, we need to identify if certain textures can be unified. I suspect that a number of the tread textures could be reduced to one unified texture that would cover all of them, or at least a large number of them. Except for the RBI conversions, I've noticed that the treads are pretty much identical in a number of the more recent tread designs. The next step can be done it two ways: you can use MODEL nodes instead of "mesh" parameters to define the models for the parts in the configurations. This allows you to put the full resolution textures in a separate directory, then reduce the textures in the part folders to dummy texture sizes and use the following to redirect the model to use the full resolution versions such as in this example: MODEL { model = KerbalFoundries/partname/partmodel texture = texturename, KerbalFoundries/Assets/texturename }Where the first "texturename" is the local dummy file name, and the second "texturename" and it's accompanying path are the path to the full resolution texture in relation to the GameData folder. The model itself must also be referenced by its path from GameData onward (not including the model extension ".mu" in this case). This leads to an even better ay of doing this... The second way of doing this is actually my preferred way. This is to emulate what is commonly done for mods in the USI line. While not done in all of Roverdude's mods, the practice is usually to have all models and textures in an "Assets" folder, with each model having a unique name instead of the default "model.mu" that Squad likes to use, and then to put the configs into a second folder called "Parts" without any extra subfolders, and each config to match the name of the part they are assigned to. You still use "MODEL" nodes, but you don't need to set a "texture" parameter because, from the model's perspective, it's loading all of its textures from the same directory as it is currently residing which is what most models in KSP do by default. You simply enter the location of the model in the "Assets" folder within the config and the game does the rest on its own. Each model can then use the same textures, assuming the duplicate textures are named the same. That's where the model-recompilation step takes place. If you have duplicate textures that have unique names, the models need to be recompiled with those referenced textures renamed so that they are the same. The major benefit to this second option is that no dummy textures need to be loaded into memory which, while the dummies are extremely smell (and thus not much of an impact on memory) they still need to be loaded which, in theory, slows down initial asset loading time when starting the game. The second option also makes the directory structure a lot less confusing and, since all the configs are in a single folder, editing the parts on the config level is a lot easier. Now, I'm perfectly willing to re-assemble all the assets to accomplish this myself, but I cannot necessarily recompile the models if textures need to be unified. the one downside to all this is, of course, that modularity of the parts is reduced a bunch. However, if multiple parts can use the same textures, such as the case with those which use the generic brushed metal texture or whatnot which is used in a few of lo-fi's creations, then you can easily release mini-packs which re-use the same assets and don't need to bloat the game any more than a few more configs would do. Roverdude often makes use of the same textures for multiple parts, sometimes even in completely different models from completely different mods. The best example is where a texture is named something like "common.png" in which a lot of commonly used images are used in multiple models across all of his mods which gives them that unique look and feel that Roverdude likes to put in his models. He still has to distribute that same file with all of his mods, but it simply overwrites the old copy of it when installing and doesn't bloat the game with duplicates because he loads it from a common "Assets" folder. I sorta miss this kind of unifying texture management from previous games I've modded. For instance... in the line of games made by Bethesda, most textures are loaded in relation to a "Data/textures" directory. In the models (they use the nif model format, very easy to edit after compilation because... well... they're not a compiled format) you can simply reference the texture by name, leaving out any path. If the texture is located in the root default for the game's search paths, then it uses that. If that is unavailable, then it searches for a possible like-named texture either in the directory that the model resides in, or in alternate locations such as within a compressed game assets file. It prefers the loose file in the root texture folder, but will use the alternate if need be. This is similar to how TextureReplacer will use a texture within its own folder if the texture is present, otherwise KSP will be allowed to use the texture located in its compressed assets. It makes texture management and memory management so much easier. Okay, I'm done now... wall of text completed successfully.

Holy Jebediah... where did this come from? Don't answer that, it's not a real question. I just love it when things like this come straight out of the ozone and smack you where you didn't know you could be smacked. Awesome stuff.

Not just "JSI"; you'll need the specific addon "JSIPartUtilities" if, as I stated, you are having issues with the standard wheel configs, not the KF ones. The italic text there has the relevant information that I assumed would be taken into account when reading that paragraph. I thought you already had an animation handler for retract/extend that was, at one time, placed on those overly large wheels which, while lacking an animation specific to it, caused the wheels to become unresponsive until extended again. Have you removed that since?

Basically, as I mentioned in my update notes for github, I found the ASET config was referencing an old path to the model, which I fixed up. For the people that want to replace the old wheels rather than add to them, I uploaded an updated MM config which will replace all the stock wheels and the ASET wheel. However, the stock wheel MM configs have yet to be gone over for any breaking changes relating to the 1.0 release, so that will be my next project. I have yet to succeed in launching KSP since the update due to mod incompatibilities and exceptions and such. I really need to clean my GameData folder out. For those having problems with the ERS wheels in their standard configuration, I'd make sure you've got the may 15th update for ERS, and be sure that v0.3 of JSIPartUtilities has been installed. As for me working over those experimental modules and such, I really can't help myself. Excess bugs me, and redundancy pisses me off (so to speak, and not necessarily in a negative way all the time) so I just have to filly with them or I'll go nuts... well, more nuts anyway. EDIT: Another thing we need to do now is find a way of re-implementing the ERS wheel's retracted mode. I had a look at the original config and it references the animation as a part of the FSWheel module directly. I remember you had supported something similar in your modules at one time, lo-fi. As it is now, using your wheel module means the ERS wheel cannot go into retracted mode without some more config editing.

That always want more tracks and more rover bodies. Don't see many people out there trying to make any of them on their own. Sure, it's a daunting task even trying to wrap your brain around, much less actually make one, but still... okay, I guess I can see why they aren't even trying. It's depressing the amount of work required to make a successful track when you don't have the talent that you've got with these things. Anyway, all my changes for the time being are synced with github. I'll probably wait a bit before doing any more changes. I'm going to compile a local copy of the plugin with my DustFX stuff plugged in and, if I don't get any exceptions or anything, I'll begin migrating all the appropriate parts over to that module. Gonna go grab the ASET wheel config and give it a try tomorrow (ack! it's tomorrow already. how did that happen?). Scratch that, later today... after I sleep. I've been wanting this ASET wheel set up with your modules since... well, since they were released in the first place.

MM really isn't all that complicated, just tedious. That and you have to deal with the possibility of the part already being modified by other mods for other effect-based nodes. That will drive you completely batty for sure.