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...

What I would like is: (1) For the 64 bit Linux PNG bug to be fixed. I get tired of patching those two 0x01 bytes to 0x00 after each release. (2) Realistic engine exhaust plumes. A hydrogen/oxygen engine doesn't produce a narrow orange plume in a vacuum. Maybe something like this: (click pic for full res) ...or orange/white for lox/RP1... but please no "blowtorches" in a vacuum! (3) An exhaust plume that spreads out as the air pressure decreases would be neat.... smoke tapers off at altitude, why not animate an expanding exhaust plume as well? (4) Realistic engine throttling. Running a big liquid engine at 1% thrust to trim the apoapsis is not realistic. Throttle should go from 60% or so to 100 or 110% (if an engine supports throttling at ALL), and use RCS for trimming residuals. Also, thrust should tail off at shutdown, not snap off like a lightswitch. (5) Realistic structural strength. Why do I still need spiderwebs of struts to simply keep two stages from falling apart? Lastly, I'm glad that FINALLY gimbaled engines now also do the roll axis. That wasn't so hard now, was it?

Is this something new in v0.25? Because in the past I had to edit the texture filenames (usually located near the end of the model.mu file) and change the extension. I can't imagine how any code could open a file without a complete path name... I tested this quite some time ago. If I converted a model00x.mbm file to a PNG, then edited the PNG file (for example, change it's color - just so I could tell that it was the PNG and not the MBM), the old original texture would load. Then if I edited the MU file and changed the extension(s) to ".png", the part loaded, and with the edits that I made visible. I don't know the inner workings of the game, but maybe it uses a list of extensions and tries them in turn (maybe something like this - pseudo-code): FILE *fp = NULL; char namebuf[32]; int x; const char *exts[] = { "mbm", "png", "tga", "whatever" }; for (x = 0; x < (sizeof (exts) / sizeof (*exts)); x++) { sprintf (namebuf, "model000.%s", exts[x]); // build filename tp = fopen (namebuf, "rb"); if (tp) { // if open success, then break and continue break; } } If something like the above were being done, then I could see how the program would "favor" the MBM extension over PNG because it succeeds with MBM first. But, code like this would only load ONE texture (the first one it found), not every one. By the way, let me ask you this... if you know... in an MBM file there is the "magic number" (03KSP), the bitmap width, height, bit depth and "type" where "type" is either 0 or 1. It seems like only 32 bit textures MAY have the "type" field set to 1 (but not always). In the newest version of my MBM2PNG code, I embed the type (0 or 1) in the PNG file (appended after the last byte so as not to mess up the PNG checksum). The reason I do this is so that my PNG2MBM converter can properly restore that flag when it makes an MBM file. I don't know if this is NECESSARY, nor do I know what that flag means (I'm guessing it has something to do with the alpha channel)? Do you know what that flag means (btw, it's a 32 bit number at offset 0x0C in the MBM file - therefore located at 0x0C, 0x0D, 0x0E and 0x0F - little endian). If you (or anyone else) knows what this flag means, I would greatly appreciate knowing. Thanks! -- Roger

I have a program that does the reverse (PNG -> MBM). I just haven't uploaded it anywhere yet. Sorry I don't know anything about "xnconvert"... don't know if it would work or not. I do know that the one I wrote does work!

The converter is a console mode program (that is, it runs in a CMD window). To use it in Windows, do this: (1) Click START (2) Click RUN (3) Type in CMD.EXE, then click OK or press ENTER A screen with a black background and white letters appears. This is the "CMD prompt". Now, go to the directory (folder) that has the KSP texture(s) that you want to convert. The converter program (mbm2png.exe) should be in your executable path. If you don't know what that is, just copy or move it to your C:\Windows folder. Change directories by using the "cd" command, like this example: cd "c:\Program Files\KSP_win\GameData\Parts\Blah\Blah" Be sure you enclose the directory path in quotes if it contains a space (like "Program Files" does). Now, assume you want to convert a texture file named "model000.mbm" into a PNG file. Type this in the CMD prompt window: mbm2png model000.mbm The program will run, generate a new file named "model000.png" and print out a small status report. Convert any more files in the same manner. When done, type exit <enter> to close and get rid of the CMD prompt window. Note that the "mu" file (typically "model.mu") must also be edited in order to have KSP use the PNG file instead of the MBM file. Right near the end of the mu file is the name(s) of the texture files. In a hex editor, it looks like this: 0000F960 00 80 3F 00 00 80 3F 00 00 80 3F 18 00 00 00 08 ..?...?...?..... 0000F970 55 6E 74 61 67 67 65 64 00 00 00 00 01 00 00 00 Untagged........ 0000F980 01 00 00 00 0A 00 00 00 02 00 00 00 06 65 6E 67 .............eng 0000F990 69 6E 65 01 00 00 00 00 00 00 00 00 00 80 3F 00 ine...........?. 0000F9A0 00 80 3F 00 00 00 00 00 00 00 00 0F 67 6C 6F 77 ..?.........glow 0000F9B0 20 28 49 6E 73 74 61 6E 63 65 29 0D 00 00 00 00 (Instance)..... 0000F9C0 00 00 00 00 00 80 3F 00 00 80 3F 00 00 00 00 00 ......?...?..... 0000F9D0 00 00 00 F2 B1 00 3F 13 A3 66 3F 38 2F 7D 3F 00 ......?..f?8/}?. 0000F9E0 00 80 3F 0C 6D 6F 64 65 6C 30 30 30 2E 6D 62 6D ..?.model000.mbm 0000F9F0 00 00 00 00 You would need to change (hexedit) the string shown in red from "model000.mbm" to "model000.png". My other program (muedit.exe) does this for you automatically. I assume you also have that program? Hope this helps. -- Roger

The STS SRB is segmented because it's too large to cast as one piece. The field joint was redesigned, but the booster is still segmented.

Nice software, but doesn't handle MBM (at least not KSP's MBM).

I'm working on the reverse program. Wait a little while!

No, of course not. That's why real rockets with a single engine have vernier engines (like the old Atlas) or else the APS modules (Apollo third stage). However, multi engine vehicles (Titan first stage, Apollo first and second stage, Space Shuttle, etc) all implement roll control via engine gimballing. If I stick some small engines onto the side of a tank, the animation moves for pitch and yaw gimbal, and they have a steering effect. But roll does not move them and it should. By the way, the old A4 (V2) German rocket had only one engine, but it had roll control because (like you said) it had graphite vanes in the exhaust. These controlled all 3 axises.

Thank you!

(1) Did it work? LOL! (2) Can you tell me a link for that mod? Thanks!