Krupski

Here's the newest (and hopefully all correct now) utilities on GitHub LINK Be sure to read the "README.txt" file first (you can read it right from GitHub before you download the ZIP). There are four utilities: MBM -> PNG PNG -> MBM MBM -> TGA TGA -> MBM Give them a try, but be sure you make backups of your originals first - just in case. I would suggest doing some testing first to be sure it all works the way you want BEFORE doing all of the textures in bulk mode. Any problems or questions, let me know.

I took out all the verbose stuff. I initially had it in there for debugging purposes - so I could see what it was doing and when. Now that it accepts multiple files on standard input (and works with drag-n-drop), the utility is now little more than a "black box"... MBM in, PNG out, so who needs all the verbosity? The program still does all the checks that it did before and still will print a message for any ERROR, but if it's working right, it prints (almost) nothing. I did have to compromise a bit in the printing department. If someone at a command line simply typed "mbm2png", it would sit there waiting for a filename input. This might look like it locked up or crashed, so I made it prompt the user with "Enter filename: ". This, of course, caused another problem. When used in "pipe mode", it would just print "Enter filename: " over and over as it pulled in each filename from the pipe (which might be confusing). So.... I made it echo the filename. This way, it looks right when used in "pipe mode" and it doesn't appear to be locked up if a person types the command name without a filename. Now that it works, I'll finish the rest of the utilities and put them all up on my GitHub account. I've got 4 utils: (1) MBM to PNG (2) PNG to MBM (3) MBM to TGA (4) TGA to MBM ...plus the C source code for each (it's free open source). The XXX to MBM converters also scan the image data and correctly set the "compression type" flag (header offset 0x0C) to 0 or 1 as appropriate (huge thanks to NathanKell for that info!). These should be all anyone needs to edit and convert textures using Photoshop of Paintshop Pro or Gimp or whatever they prefer. BTW, thanks for telling me about the drag-n-drop thing. I never thought of that and I didn't even know it would work that way. It's amazing how much a simple suggestion or a simple idea helps with a project like this. I'll let you know when they are all done. -- Roger

Yeah, you won't save any in-game memory by using PNG. By the way, I REALLY like your idea of simply being able to shove filenames at the utility and process them, so I modified my utility to do it. I only did one so far, but if you want to try it and report back, I'd appreciate it. Here's the link: http://www.hobbytent.com/other/files/new_idea.zip Here's what's in the ZIP file: root@michael:~/c-progs/ksp_utils# unzip -l new_idea.zip Archive: new_idea.zip Length Date Time Name --------- ---------- ----- ---- 77824 2014-11-23 11:15 mbm2png.exe 5860 2014-11-23 11:15 mbm2png.c --------- ------- 83684 2 files The EXE is a Win32 executable, the C is of course the source. You can use it in 3 different ways: (1) dir *.mbm /b | mbm2png.exe (pipe all mbm files into mbm2png.exe) (2) mbm2png.exe (it will ask for a filename, convert it, then ask for another. a blank filename [i.e. just press enter] closes the program) (3) mbm2png.exe model000.mbm (will convert this one file and exit) You can also create a text file with all of the textures you want to convert (even in different subdirectories), then just do this: type filelist.txt | mbm2png.exe --or-- mbm2png.exe < filelist.txt Not sure if redirecting STDIN works in Windows, but I think it does. Try it! -- Roger

Interesting idea. The utilities do read the filename from standard input, but piping a bunch of filenames into it won't work because it only "runs through the loop" once. Also realize that a DOS "pipe" isn't a real pipe... it merely copies standard output to a temporary file then sends the data to the destination. You can't do multiple pipes in DOS (for example, dir | sort | lowercase | etc). I could, however, quite easily change it to accept as many filenames as are thrown at it (which would make it work the way you suggested). I'll look into it and incorporate the change if I can. Concerning PNG files, the only reason to convert a texture to PNG is to be able to edit it with a photo or image editor. Every image editor knows PNG, none know MBM. A PNG file is compressed and a lot smaller than an uncompressed MBM file, but doing that only saves you disk space. When KSP loads the textures, if they are PNG, it has to decompress them back into raw bitmaps. So this saves you nothing in memory usage while the game runs, AND it also greatly slows down loading because KSP has to decompress each one. Converting an MBM to TGA is a lot better, because the TGA is uncompressed (i.e. loads as fast as MBM) and it's a format editable by most image editors. I'm going to look into converting multiple files with your method. It might work!

Check out the stuff here: http://www.hobbytent.com/other/files/mbm_utils.zip It's the source and per-compiled executables for Windows and Linux. There is also a new utility called "fixbat.exe" which does what I mentioned in the previous post. You create your batch file by typing "dir *.mbm /b > convert.bat" (or whatever name you want - doesn't have to be "convert"). This gives you a list of every filename that ends in ".mbm" Now say you want to convert all of the files to PNG... of course you would want to use the "mbm2png.exe" utility. So you need to add it's name to each line in your new batch file. That's where "fixbat.exe" comes in. You type "fixbat" and it asks you "Enter the name of the batch file: ". You type "convert.bat". Next it asks you "Enter the name of the utility: " and you type "mbm2png.exe". The program reads in "convert.bat", then line by line adds the utility name to each line, then writes it back out. So, it your batch file had this in it: model000.mbm model001.mbm model002.mbm it will be transformed into this: mbm2png.exe model000.mbm mbm2png.exe model001.mbm mbm2png.exe model002.mbm ...which is now a usable batch file. All it does is automate the hand editing of the batch file. Now if only Windows properly supported wildcards, we wouldn't need all this baloney...

Well, I wrote these utilities in Linux and then cross-compiled them for Windows. The original versions (a year or so ago) did indeed do wildcards so all you had to do was something like: mbm2png model*.mbm and the wildcard would expand correctly and do all the files. Unfortunately, Windows didn't support the wildcards (which didn't surprise me one bit). So, to make the programs work uniformly between OS's, I made them all do single files. What you can do in Windows (console mode) is something like this: dir *.mbm /b > convert.bat This will get a listing of all files that end in ".mbm" and put them into a text (batch) file. Then you can use a text editor like notepad or something else and add the "mbm2xxx" command to each one, then finally run the batch file. It would go like this: (1) cd "\Program Files\KSP_win\GameData\Squad\Parts\Engine\liquidEngineSkipper" (this puts you in the folder for the "Skipper" engine) (2) dir *.mbm /b > convert.bat (this creates a batch file that looks something like this: ksp_l_midrangeEngine_diff.mbm ksp_l_midrangeEngine_emissive.mbm ksp_l_midrangeEngine_fairing_diff.mbm ksp_l_midrangeEngine_fairing_norm.mbm ksp_l_midrangeEngine_normal.mbm Now, open the file with an editor: (3) notepad convert.bat (4) Add "mbm2png.exe" to the beginning of each line so the file ends up looking like this: mbm2png.exe ksp_l_midrangeEngine_diff.mbm mbm2png.exe ksp_l_midrangeEngine_emissive.mbm mbm2png.exe ksp_l_midrangeEngine_fairing_diff.mbm mbm2png.exe ksp_l_midrangeEngine_fairing_norm.mbm mbm2png.exe ksp_l_midrangeEngine_normal.mbm Now, save the file. Lastly, run it: (5) call convert.bat It should convert all the files in one shot. If you want to do your ENTIRE KSP install at once, just use the dir command to send ALL the filenames to the batch file. First, go to the root of the KSP install directory, then type: dir *.mbm /b /s > convert.bat The /b switch means "display the filename bare (no size or date info)" and the /s switch means "do all the sub-directories too" Then add the appropriate utility filename to each line and let it rip. I should make a utility to process the batch files to add the filename to each line... maybe I will. Good luck. Any questions, let me know.

One thing to be aware of in 64 bit Linux is that KSP (STILL!) has a bug where it sometimes crashes while loading PNG textures. I don't recall the details, but it's got something to do with a piece of 32 bit code left over in the main executable. Anyway, to fix it, you need to patch two locations from 0x01 to 0x00 (note the red arrows I added): root@michael:/usr/share/KSP_linux# fcmp KSP.x86_64_original KSP.x86_64 Reading KSP.x86_64_original (20207816 bytes) Reading KSP.x86_64 (20207816 bytes) Comparing KSP.x86_64_original with KSP.x86_64 0099F587: 01 00 <------ 0099F58C: 01 00 <------ fcmp: 2 mismatches encountered This patch is ONLY for KSP v0.25 and ONLY for the 64 bit Linux version. Older versions of 64 bit Linux KSP also need the patch, but in a different location. Use a hex editor to make the patch... if you are not able to do it, let me know and I'll PM or email you the patched executable. -- Roger

Be careful! If you are trying to use what's on my GitHub page, be aware that it does several things wrong that I am currently fixing (thanks to SUPER helpful info from NathanKell). You are welcomed to try the current code, but please make backup copies of your originals first (or wait a few days until I finish updating the utilities) since it may not work exactly as you expect. Thanks. -- Roger

Thanks so much for the info. I've been looking for this for a long time. I wasn't aware that there was a bug loading TGA files. I do know that there is a problem with 64 bit Linux concerning loading PNG files which requires patching 2 bytes in KSP.x86_64 to prevent (seemingly) random crashes when loading PNG textures. If you're interested, this is the patch data for KSP_linux 64 bit version 0.25 (readers do not apply this patch to any other version - if you need the address for other versions let me know and I'll post them): root@michael:/usr/share/KSP_linux# fcmp KSP.x86_64_original KSP.x86_64 Reading KSP.x86_64_original (20207816 bytes) Reading KSP.x86_64 (20207816 bytes) Comparing KSP.x86_64_original with KSP.x86_64 0099F587: 01 00 0099F58C: 01 00 fcmp: 2 mismatches encountered The "crash while loading PNG files" problem is discussed here: http://bugs.kerbalspaceprogram.com/issues/752 Oh well, thanks again for the texture loading info! -- Roger

Sorry off topic but, how do you get a 6.4x Kerbin? I really would love to do that. Is it a mod? Thanks! -- Roger

Not quite sure what you mean. The flag I'm referring to is either 0x00 or 0x01. Does that mean that 0x00 == DXT1 and 0x01 == DXT5? If so, then I have another question... if the texture is a Targa (TGA) file instead of MBM, it doesn't have that flag. How does KSP know what to do regarding DXT1/5? I just finished writing a little utility that does MBM -> TGA conversion which is a lot simpler than PNG. All it does is verify that the magic number is 3KSP, then it grabs the width, height and bit depth of the MBM file, swaps RGB to BGR (and copies the alpha channel if the MBM is 32 bit), then writes a TGA header and the bitmap. Presto! It works like a charm. It doesn't slow down loads like PNG does (because TGA isn't compressed) and I don't have to flip the bitmap upside down like MBM -> PNG requires. I've already tested it by taking all of my MBM files converting them all to .TGA, then deleting the .MBM files. KSP loads and runs just fine, and I can easily edit any TGA file in Photoshop, Paintshop Pro or Gimp (linux). It seems to be working just fine. Yes I know that. After I converted my MBM files to TGA, I removed them from where they were and archived them in another directory (just in case). BTW, I just tried to upload my utility to Curse and now I know why it's called "Curse"... because that's what I did after spending 1/2 an hour creating an account, making a "required screenshot" for a console mode utility and then discovering that they don't accept pre-compiled code (wonder what they think DLL files are?). I've got a GitHub account where all my other code is... I suppose I could put it up there. Argh.....

Do you mean the blue hydrogen/oxygen flame? I did that myself in Photoshop. I screenshot the booster in a parking orbit and edited in the glow later. Used an illumination effect (i.e. placed a glow coming from inside the engine, colored blue/cyan... 0% red, 50% green and 100% blue). Then applied a little blur and did a little "push" here and there to get the streaking effect inside the nozzle. I've also edited other screenshots to have the large grey/black sooty streaked "ring" around the engine that you usually see just before a first stage MECO where the plume is already well expanded and there's not enough air to afterburn the residual fuel. If only the game did that....... it would look SO cool!

I always use properly placed Sepratrons to pull away things like an expended SRB from the launch vehicle. Due to the limited range that a part can snap onto another part, merely using a decoupler will almost always result in a "push" well below the center of mass, causing the top of the SRB to swing inward and hit the launch vehicle. Real boosters always use small solid rockets to push an SRB away properly.

Here's a nice model to use: (click image for full res)

How does fixing a bug and adding a few visual effects make the game "too hard for a lot of people to play"? The only thing I could imagine (from my list) that may make game play a tiny bit more difficult is realistic engine function (limited throttle range and thrust tail-off at MECO). And, this effect could probably be turned on and off via the "difficulty" options panel. Another idea that I had was to let players load their own propellant. They would need to choose the appropriate tanks, then load their own fuel and ox at the proper ratio. Getting the ratio wrong would realistically result in wasted propellant and decreased performance.... (which then would result in someone writing a mod to do a PU shift for the stage!). Also, DIFFERENT propellant combinations with realistic performance specs would be nice. How about doing away with the red hot glowing engine bells? Most engines are regeneratively cooled and don't glow, and those that do glow brightest at the throat, not the end of the nozzle where the flow is coolest. I already edit the texture masks used for engine glow to remove it for engines that are cooled and to glow brightest at the throat for those that are uncooled or ablative (or is that "abalative"?) One more thing I would really like is the ability to do internal vehicle-to-vehicle transfers (i.e. a real IVA). Needing to do an EVA and bouncing off the spacecraft, spinning into oblivion is not realistic (or fun) A tether for EVA would be nice too... although I don't know how a realistic looking tether would be done. A straight line that changes in length would look corny. Maybe use random arcs or beziers to dynamically generate the proper length of tether as the astronaut moves? I'd even be happy with magnetic boots! Anyway, the mere existence of so many mods shows that at least some people really do want more realism and more features above and beyond stock. And as I said, everyone could have the option to use or not use any feature. Lastly, I noticed that your signline advertises RCS parts and improvements. Do those include RCS sound? I know there is already an RCS sound mod (that I use), but of course I hacked it for more realism. RCS outside the vehicle would not be heard. Inside all that's heard is a bang which is the sound of the solenoid valves opening and the onset of thrust. So I recorded the sound of rapping my knuckle on an empty paint can for the start transient, a low, quiet constant "rushing" sound for propellant flow and combustion noise and a sharper "click-bang" for RCS off. The engine running sound I made by taking pure random data as a WAV file (which is white noise), then bandpass filtered it between 30 and 150 Hz. It sounds great! Oh well, enough for now...