Gaalidas

I will admit I am not... that's probably why I'm not having any issues. ATM has shown itself to cause a lot of problems with its dependence on configurations to tell it what to do. It is a great help to some, but others simply want a mod that works out of the box without any changes needed when installing new content. Besides, this mod can work just fine with texture modification plug-ins as long as they aren't trying to compress anything. Take Texture Replacer as an example. This mod has absolutely no problem with it as long as I let Texture Replacer know that I do not want it to try and compress anything. Once that little rule is settled, everyone gets along just fine. So, I had this happen once. It never happened again, though. It just got stuck at the "prepping textures" thinger after the main menu loaded up. Upon trying to load a game, it totally froze up. What I have yet to experience with any mod is a situation where purple textures show up. The one exception to this is when I had some icons for MKS/OKS showing up as purple square icons in the Toolbar mod. those are always purple, now that I think of it. I'm unsure what that's all about. Gotta hand it to you though, that's some amazing patience you've got there building a plane and flying it all in shades of purple. I'd have never been able to stand it being all bugged up like that.

I tried some of those other hovering solutions and really wasn't that impressed. On the up side, however, I think they had a little less trouble with hovering over non-solid surfaces and whatnot. As long as the raycast hit something, it worked. As for steering, I'm still experimenting with solutions for that. As we know, the repulsors create a zero-friction connection with the ground so if there's any slight slope to the surface you're on, gravity will take over and you will slip sideways. Turning the craft requires something similar to orbital maneuvers. You gotta not only thrust in the new direction, but also thrust in an opposite directly to the one you were previously moving in order to turn effectively. If we could slow the craft down during these maneuvers then we would reduce the amount of retro-thrust required. I've experimented with using air-brakes (provided by a few of the aircraft expanding mods out there) to create this sort of effect, but in many cases I found that I had to fix air-brakes pointing in all directions so I could still turn the craft while trying to arrest my momentum. I've also begun experimenting with RCS and a few mods that have a "kill horizontal velocity" function to make it happen. The trouble is that all of these maneuvers require a lot of different modules to work in order to simply change your direction of movement. In the end, I've been spending much more time using wheels than repulsors. Especially considering the dev. versions lost their water repulsion ability.

Weird, I'm not having any problems with it. At least, nothing that I'm aware of.

Indeed. Most of what you've created I saw as something quite different when I wrote about it here, but I've not yet been disappointed with the result.

A few toggling mesh-swaps for some little structural bits and pieces would be awesome for a little visual flair that could be customized on the fly. It'd be even better if we could swap them in the flight scene. Which leads me to another thing, the abiltiy to modify the ride height by action group keys would be great, along with the automated apply-to-all that the repulsion-height thingie got.

So, this thread has become really freakishly long. There's no way I'm going to search this entire thing for a specific issue, so I'm gonna put it here. First off, some background. I'm running KSP on a heavily unoptimized laptop that was not built for gaming. It's stupid, I know, but it's what I have at the moment. well, okay, I do have a super computer of sorts down-stairs, but this thing is mobile and I have yet to set up a stable and secure way to remote in from my college, so there it is. That said, I'm running several mods that reduce textures and what-not. I don't see how any of them could conflict honestly. The mods I'm using are Texture Replacer (harmless to mods that add new textures, especially if you don't use the compression system), DDS loader (unless I convert your textures to that format, there aint nothin' happenin' there), and LoadOnDemand (currently this is my only concerning one, but I need it to keep my performance up even with super compressed textures.) So, this is what I'm experiencing. When launching from a runway (and only runways, launch-pads are not affected) the models for the runway and buildings themselves are textured with no problems, but the surrounding terrain is all screwy. From certain camera angles it randomly switches to a super low-res texture and when turning the camera around I get a high-res texture. This is not the main problem, because the high-res texture itself is where it gets worse. Instead of the normal higher-res texture, I get this solid color with these blurry black lines going through it, like someone replaced the texture with a grid-texture that they exported to a heavily compressed 5x5 resolution bitmap. Returning to the same spot without the runway (other building do not create this effect) the terrain goes back to normal. I suspect that some parts of the models being used are made up of terrain-like slabs that are meant to reduce the sudden drop off the side of the runway and/or whatnot. if my suspicions are correct, then it is the textures upon those models which are freaking out in this way. I'm still testing combinations and configurations, but I thought I'd throw this out there and see if this is being experienced by anyone else. EDIT: Holy Jeb's Ghost, that post was longer than I thought. And I didn't make nearly the number of typos I normally do. Am I even awake?

yeah, a part menu gets stuck open and stuff too with this mod turned on.

That is so lame. At the very least they could have made it shallow enough that it appears that you're wading in a pond. Unfortunately, this also means that once we have the dev version of the repulsors running over water again, that pond won't cooperate. Someone should make an addon for Kerbal Konstructs to put a big slab of concrete over it or something just to show our disappointment.

We use staples. It reduces their life expectancy but it's rather effective.

well, the great news is that the steering wasn't really borked, just the appearance of steering. Anyway, I put the fixed DLL into my folder about 30 seconds before you posted here. No, I'm not stalking you though your Github... I'm just really good at showing up at the perfect moment. I'll give it all another try as soon as I get a moment to start KSP launching (I'm in a squirrel-server class right now.)

Holy kerbal dung! This is nuts... and I like it.

Well, guess we better do some re-borking so we can get back to an un-borked state. It makes sense if you stop trying to make sense of it.

I actually spent a few minutes looking at your changes to those files and while I know enough to be dangerous (I could break anything in seconds, I'm so dangerous) I don't know enough to make heads or tails of anything in there. So... I dunno. Could have to do with you deciding to reinvent the LookAt stuff maybe?

So...I had a run with the latest (as of last night) update to the dev stuff and... yeah... you borked it real good. So, the wheels work... sorta. Except for steering.... sorta. Lets see if I can explain it. The wheels turn at the expected angles, and the craft moves in the expected direction when that steering is applied, but the "animation" of the wheels turning in backwards. So, I'm getting that cool variable steering angles, and it's applying itself to the craft movement properly, but it all looks to be reversed. I can report that the appearance is the only thing that is broken. Suspension and steering calculations all seem to be fine, it just looks like physics got screwed over when the wheels turn left and your craft turns right. So yeah, maybe you mistyped a negative symbol somewhere in there, or forgot one?

You have two options: 1) Find a freeware command-line image converter and build a batch file to loop through all the textures and turn them into PNG. 2) Download the nVidia DDS tools and the DDS loader for KSP, then again build a batch file to convert and vertically flip all the textures into DDS. I suggest option #1 because it's a lot simpler and doesn't require a separate loader plugin. Alternatively you could just convert them with your favorite image editor one by one yourself. Just be sure to delete the extra TGA file to reduce conflicts.

Technically it's already out, since everything works still. (as far as I'm aware, which isn't very aware at all, but I've yet to get any errors.)

Bah, you can get healthy when you're dead! err... don't think about that one too much... could be unhealthy.

Hey, are any of these new innovations really, down at the very bottom, not just a form of "hacky" programming? A high-school teacher of mine used to say that there were no such things as features, only bugs. Bugs we like, and bugs we don't like.

Great, there goes all those long-undeveloped editor extensions that I've become so used to using. I sure hope those improvements will be a good replacement for those mods.

So... you should have that all wrapped up by... say... noon-ish tomorrow? Right then, carry on. Seriously though, sounds like it's coming together quite nicely.

Sounds like an overload caused by too many separate physical "crafts" being loaded into a small area at the same time. Try spawning 400 little probes above the KSC and letting them crash and go boom all at the same time. You'll get a similar result. EDIT: Not that I know of any way someone could "spawn" crafts like that... it's just an example.

well, there are a number of plugins which attempt to determine what a level position is relative to the body you are orbiting or landed on. Mechjeb itself will do that. Then add a bit of buffer space, similar to the height thingie in your repulsors, set that height value to the highest sample between the set of detectors, then you just gotta figure out how far it is to the ground at each landing leg's foot-position and attempt to lower the legs so that they keep the craft flat... within reason of course. Something like this can be done by hand with IR parts, but tweaking every little leg to the correct position is a serious pain. It would probably be a major undertaking to do anything like what I've described, but then you did manage to make a vehicle steer with every wheel attached to it with individual steering angles depending on their position on the craft while still allowing them all to have individual suspension and anti-rolling adjustments. That's pretty nuts as it is.

Hey, it was a quick and dirty batch file to see if I could do it easily. I look forward to anyone else making something easier and able to distinguish between file types. The alternative is converting the textures one by one since there's no standard naming convention. It sure was a lot easier dealing with textures in, say, the elder scrolls series. Normal maps always ended in _n and spec maps always ended in _s and so forth. You never had stuff with model000, model001, etc. with no indication of what type of file it is without looking at it closely both visually and code-wise. I did find most files got a little bigger than their PNG counterparts, even without mips, but not as large as a fully uncompressed PNG or larger format would produce. Now I can expand the batch process to check for properly named files (such as normal maps) before converting the rest in a "catch all" loop.

It's actually pretty simple. I use a "FOR" loop to go through all the files that I want to modify, then use a "CALL" command on the nVidia command-line tool for converting image types, then I use an "IF" command to see if the resulting filename with the new extension exists before deleting the unneeded file. Here's what I have, though the code I'm going to post is not ready to be used outside of my home system as of yet. ConvertoToDDS.bat @ECHO off :: Initialization of environment states and variables. SETLOCAL ENABLEDELAYEDEXPANSION SET localdir=%CD% SET DDSTool="C:\Program Files (x86)\NVIDIA Corporation\DDS Utilities\nvdxt.exe" FOR /R "%localdir%" %%F IN ("*.png") DO ( CALL %DDSTool% -dxt5 -outsamedir -quality_normal -nomipmap -flip -file "%%F" IF EXIST "%%~dpnF.dds" ( del "%%F" ) ) I put that batch file in a folder on my computer under "documents" that I call "MyTools" and reference this from a shortcut. I can put that shortcut into any sub-folder I want to start from (for instance, the "B9_Aerospace" folder) so that I do not convert everything in one go (I'm not done testing the effect on GUI elements or TextureReplacer elements at this time) and I simply change the "Start in:" field to match the folder that the shortcut resides in. Otherwise it will look in the "MyTools" folder for the images to convert, and successfully find nothing to do and quit without error. EDIT: Alternatively you could just copy the batch file to whatever folder you want to start recursively checking and it would work just fine out of the box. Also note, the new file will be placed in the same place as the input file and the batch file will recursively select any file in any sub-directory from the starting folder. As you can see from the code, I first set it to not bore me with echoing commands. I set a local variable that probably isn't needed here but helps if I ever need to expand a variable at a delay from the start of the script. Next I have the path to the tool I want to use, in quotes so that it does not choke on the spaces in the path. I also define the local "start in" folder to a variable just so that it isn't determining the local path every time I want to reference the default "%CD%" environment variable. Then I have the loop which places each PNG file in each loop into the variable defined as "%%F" which I can then reference with a variety of interpretations using the "~" operator where "~dF" gets the drive letter, "~pF" gets the path (minus the drive letter), and "~nF" gets the file name (minus the extension). Since I use "CALL" the batch will wait until the nVidia tool is finished before executing the next command. It then checks to see if the new file, at "%%~dpnF.dds" exists (the file drive, path, and name minus extension, with the new extension at the end) and if it does, it deletes the PNG file. Else, it leaves it alone. Note, the nVidia tool continues to output all sorts of crud to the screen despite the echo being turned off, but that can be fixed later if you care. And that's it. It's not even the most complicated batch file I've written. You should see the one that I use to detect and convert any image downloaded in a mod to the format that I prefer to use. That baby is massive, and makes heavy use of subroutines and the "EXIT /B" command, and even uses several different batch files to process the entire thing. I even implemented a basic progress meter and counter in the title bar. I'm quite pleased with it. EDIT: Note, I realise I'm using "-nomipmap" in my conversion command. It runs faster, and for testing I decided mips were not required.

Wow this thread is growing fast. Yes, all the textures that I converted (only the B9 stuff at the time) were upside down as far as I could tell, considering UV mapping makes it hard to tell sometimes. Last night I rearranged my batch file to also invert all the textures that I converted. the nVidia converter also failed on any texture that was not dimensioned on the "power of two" rule, so I made sure that those stuck around as PNG (which has given me the best performance when also using LoadOnDemand mod). Testing so far has shown that everything works as intended. On purpose I am not touching GUI buttons (toolbar, stock-toolbar, custom UI images) as of yet. These are so small anyway that it doesn't matter what format they use. One little error is with the B9 flat panels which appeared to have a quarter of the model (one triangle in the square shape) brighter colored than the rest. When switching the mesh to the open frame I got better results, but the interior of the frame was not consistently textures as they were supposed to be. My thought on this problem is that something funky has happened to the normal mapping, since the effect seems similar to when a normal map contains too many white edges and makes a model appear to be way too shiny at certain close angles in the VAB. My experiments continue...