Gaalidas

The DDS loader won't affect you at all unless you want to package DDS textures instead of the standard ones. The only thing you need to do is flip the texture vertically when using DDS, otherwise your textures will load upside down. I would suggest shipping the way you have been, however, since you'd have to place a dependency on the DDS loader mod. The end user can always download the nVidia DDS tools and use a batch file like I have to convert all texture formats to DDS, vertically flipping them in the process, and deleting the old textures IF the conversion was successful. The reason for that "IF" in there is because textures that do not follow the "dimensions must be a multiple of two" rule, the conversion fails. I have also noticed a few weird errors, so far only with the B9 package's flat panels. They appear really strange despite the vertical flipping of the texture and all that. I'm going to revert those textures and see if it changes anything tomorrow. At least this new loader doesn't exclusively take over the texture system. It simply gives KSP the ability to use DDS if they are present in the same way it is able to use MBM, TGA, or PNG (and even JPG in some cases) regardless of what file extension the model references. On another note, supposedly the creator of "LoadOnDemand" mod has solves the .25 incompatibilities, which may make any improvement caused by the use of DDS to be unnecessary. I'm going to see if it will work with the DDS loader tomorrow. If they work together alright, then my initial loading times may go through the roof. I'll let y'all know what happens if I live to tell the tale. EDIT: Good news about the new wheel stuff. Sounds like just the thing I was hoping to see. Now we need to make some really awesome landing legs with your sweet suspensions and all that... only other thing I could ask for in that case is an auto-levelling system that would adjust the suspension of the landing legs to attempt to make a craft level while maintaining a certain clearance from the ground... within reason of course. But hey, we're getting closer to totally redefining landing gear and wheels entirely. Of course, when I saw "we" I definitely mean you, cause really I'm doing hardly anything at all here. I can just imagine that day when you can post this baby to the release forum. it's gonna be huge, especially if we can show off all the awesome videos chronicling the progress.

So, I tried this with one of the B9 pods, that oddly shaped drone thing. It seems that the textures, once converted into DDS format, need to be transformed in some way as well to align properly on the model. In this case, it appeared that the texture was loaded in upside down from what it is supposed to be. I wonder if this is related to the flipped state of the textures you extract from the asset files? Those come out flipped vertically and if you want to modify them for use in TextureReplacer you need to flip them vertically again to make them load up properly.

I should say something witty about taking a leak now... but my brain is fried after classes today. Interestingly enough, I believe we were just discussing file formats the other day in one of the dev threads I frequent. I just can't quite remember which one...

Yeah, don't you just hate that?

They have plenty to do. They must sit in their little command stations and die when ordered. I never saw any need for a more fulfilling role. Edit: New cool thingie here... we have a DDS texture loader plugin now. Apparently this will save no room in memory, but it will likely load a ton faster because DDS is the exact same format that textures are saved in when loaded into RAM. Initial tests have shown that a standard TGA or PNG loading over more than 3000ms loads in less than 200ms when coming from a DDS format.

Broken wheels? -Bleep- that! I made a custom MM patch to disable that functionality on wheels. I had issues in the early days where I would build a really large rover with wheels that were obviously made for that kind of load and they would break the moment physics kicked in on launch. It really ruins the fun factor. Of course, if you implemented broken wheels that really catastrophically broke instead of the stock "my tire fell off the rim!" behavior, well, it could have a bit of entertainment value. We need something along the lines of "Holy Jebediah's Ghost, the suspension frame just exploded, the wheel is flying over the landscape and we just dug a new irrigation ditch with our rover's nose. ... Lets do it again!"

So, if this has been reported then I apologize... I noticed last time I used this mod that the images in the launch selector were all being displayed as if they were shifted to the right a bunch. in fact, it appeared that they were being centered in the middle of the image space, but with the center origin located along the left edge of the image, forcing the window to cut them off half way through.

If this mod adds light sources, the performance hit could be due to the use of shadows. If those light sources are causing more shadows to be calculated based on the objects they are colliding with then performance will drop drastically. I turn off my shadows cause this laptop really doesn't like them at all. I imagine if someone has their light sources option turned down really low that these lights could conflict with vessel lighting and cause some flickering in/out due to that limit. Add that to anyone using the RCS sounds and light mod and you've got a real battle on your hands over the limits of light projections. Another little tidbit of info: I was looking at the color configs and comparing them to Distant Objects and I discovered that the colors for the planets are an exact match to the other mod. I mean exact down to each decimal value.

Yeah, so.. as far as duplicate entries go, I am really not too sure. My best guess is that it would load the second of the two after the first one, and thus override the variable with that new value. However, I do not know how KSP loads that data into its internal database. The best practice is to not have duplicate parameters but, from my experience, nothing bad has ever happened from it. I also just noticed, while trying to figure out a few stock errors, that those configs are pointing to non-existent models. It's rather odd that a config would still load a model without a reference to it, but it's not the first time I've seen this happen. When I was installing Karbonite, back in the very early days of that mod, I noticed that several of the configs which had only one model in the directory (named "model.mu") were also missing a mesh or model reference, and yet still managed to load the part with no issue. I'm wondering if there might be a default behavior in the engine that will load that single model found in the same directory which is named identically to the name of the part and make the connection with that config if the currently defined model is not correct, or not even defined. Similarly, you'll notice that when using "mesh" you have to supply a file extension, but under the "MODEL" node, you have to omit the extension. I'm not too sure what it all means, but I have a feeling that just as a "MODULE" node has default values that, if not defined otherwise in the config, is used to define a certain behavior, configs for parts may also have some default values that are applied when the circumstances and/or environment are set up in a specifically perfect position. The stock error I was tracking down when I discovered the connections was an error that stated, in not-exact words, that the model (defined under the "mesh" parameter) could not be found in the directory (which is not defined, and defies the logic that I just explained above) which was specified as "Squad/Parts/some-other-folders/nameofpart/nameofpartconfig/nameofpart/" which is a directory that does not exist, but that internally would be a good way to define the connection between a part and a model which you can have multiple models and/or parts in a single configuration and/or directory. The problem with the error, however, is that the config and the directory structure for the part was constructed exactly the same way as every other perfectly working part is constructed. My only way to fix this was to remove the stock "mesh" parameter and replace it with a "MODEL" node. I don't think even Squad is fully aware of what's going on here because they just shipped version .25 to us with these errors being thrown about causing stock parts to not load correctly. Even crazier is the lack of any hot-fix patches to fix the problem, which suggests that they have not figured out the problem themselves and thus do not want to start hot-fixing until they do understand it. These little buggers are not unexpected with such a complicated addon-system however. Every game that is moddable from the get-go runs into these weird issues. It makes quantum physics look like a walk in the park. For my standard disclaimer, see my signature area below. EDIT: Holy Mother of Jebediah! I just noticed this is the 107th page of posts, if you're using the default settings. That's just nuts man.

Sometimes, when you sit really still and very quiet while browsing the forums, something really nice comes out of left field and smacks you straight in the face. This is one of those, and holy mother of Jebediah does it feel good!

That's actually a feature of the... uhh... feature. yeah... What this means is that there's good news! At least one small part of the intended function is functioning as expected.

That is really getting old. People have been saying that line for the last 10 years or more.

Missing an equal sign is really bad... but the spaces are quite optional. I feel for you though, I'm a config diver too, and I never install anything without at least taking a peek. I've had to force myself not to fix every badly formatted config I install to save my sanity... or what's left of it. What was that Harvey? No, I don't think that would be a good idea... they still need their heads and my wall isn't big enough to mount them all. Don't give me that look, you're the one who suggested it. Well I don't care if you're angry at me, you're just a figment of my overactive imagination and the only thing you really bring to the talbe is evidence that my grey matter is goop! Did I just say all that out loud? oops...

You better demo that, cause I have absolutely no idea what you're talking about. Warthog eh? You mean the Puma? And from what I remember its wheels were pretty symmetrical. I never noticed a third wheel on one side or anything.

I'd love to see some shots of the improvements when using OGL. It's really good news for me, on a non-gaming laptop, that it seems to improve the RAM usage. I might have to give it a go. I've also been thinking about stopping running KSP locally, and remoting in to my desktop (err... that is, my desk-mounted brick of a machine downstairs) somehow like I do for my SQL class (that is, remoting into a computer on campus so I don't have to install SQL management suite.)

I know the packaged assets are all in that format, or at least the asset browsers extract to that format by default. I'm a little weirded out about the fact that all those textures seem to come out vertically flipped from what the normal texture orientation is. Still, I don't see any reason why it shouldn't be supported. Might be worth an investigation.

I remember back in the days of the original Homeworld, switching to OGL meant the difference between solid-colored engine trails (DX) and smooth semi-transparent engine trails (OGL).

I doubt it'll ever settle completely until Unity gets their act together with 64-bit stability. It's getting a bit ridiculous. There are many other engines out there using 64-bit processing with no issue whatsoever.

memory issue likely. Though, there was talk of some issues with TGA textures as well. I convert all of mine to PNG, so I wouldn't know.

It's definitely not working. Not only does it show as incompatible, it also fails to do anything.

Yeah, and I've failed so many times, surely I've learned something along the way that could be of use. At the very least I could say something really stupid that would lighten the mood and otherwise be completely useless in every way possible.

Surely KF isn't one of those mods you'd even need to roll-back. It's always awesome, no matter what. If you don't believe me, go stare into the hypnodrive for a few hours and get back to me.

Yes... that's the game I was thinking of when I saw this. Wow, I'm really old.

maybe, but without the ability to set variables, manipulate them, and then use them in place of normal config data during a MM patch process, it might be a little bit difficult. What we really need is a MM style plugin that implements a sequential scripting system similar to the windows batch file system with environment variable I/O.

I see your text on the screen but I have no clue what you are saying. Still, it looks like you really researched all this and made us a nice little fix in a compact package which, until I am told it is not needed, will be installed now.