Krupski

Hi all, MBM texture files contain several fields in the header, each one being 4 bytes (32 bits) in size, little-endian. [B][FONT=lucida console]hex addr 00000000 [COLOR=#b22222]03 4B 53 50[/COLOR] [COLOR=#008000]00 02 00 00[/COLOR] [COLOR=#0000ff]00 04 00 00[/COLOR] [COLOR=#008080]01 00 00 00[/COLOR] [COLOR=#8b4513]20 00 00 00[/COLOR][/FONT][/B] The first is the "Magic Number" (0x034B5350) or "3KSP". The second is the texture bitmap width, in pixels. For example, 512 pixels is 0x00020000. The third is the texture bitmap height, in pixels. For example, 1024 pixels is 0x00040000. The fifth is the texture bitmap color depth, usually 24 or 32 (i.e. 0x18000000 or 0x20000000). The FOURTH field is either a 0 or a 1. It seems as thought this field is a "1" in 32 bit color depth bitmaps and a "0" in 24 bit color depth bitmaps, but NOT ALWAYS. Once in a while, a 32 bit texture will have a "0" in this field. Can anyone tell me what this field represents? Does it maybe mean "alpha layer yes/no"? I currently have written an "MBM to PNG" file converter to allow easy editing of textures, but I also wish to write a companion "PNG to MBM" converter. The PNG to MBM converter is easy to do... all I need to do is correctly set the value of the "mystery field" correctly... but of course I need to know what it does in order to set it properly. Using MBM files is much better because they are uncompressed and load fast. If all the game textures are converted to PNG files, the game loads a LOT slower because each PNG has to be decompressed at load time (this is why I want the companion PNG to MBM converter). Anyone have any idea what field #4 is for? Thanks! -- Roger

Hi all, a few suggestions for future KSP versions: Gimballed engines should also control roll. Currently, pitch and yaw are affected by engine gimballing, but not roll. The ability to record a session and play it back would be nice. Not a video recording, but a data file recording of components, positions, velocities, etc... that could be "played back" using the game engine to that a previous mission could be re-viewed. Of course, this would require that all the parts used on the mission still exist (i.e. a person could not be able to play back someone else's mission unless they had ALL the same parts in THEIR KSP). The ability to focus on a body WHERE IT WILL BE would be nice. For example, if I want to setup a free return trajectory to the Mun (the Apollo style Figure-8), I can focus on Kerbin or the Mun (where it IS) and editing a maneuver shows a shadow of where the Mun WILL BE, but I can't FOCUS on the Mun "where it will be" in order to closely, clearly see the exact trajectory line. Last one: PLEASE FIX THE "PNG BUG" IN THE 64 BIT LINUX VERSION! It's only 2 bytes......

What did I do in KSP today? I downloaded version 0.23 and (again) had to patch it so it would load PNG textures without crashing. Note this is only for 64 bit Linux version........ and the location of the bytes to patch has moved. Lots of fun trying to find them (but I did!)

Thanks! Yes I'm going to update the program here as well. I still need to add the README files to the zip archive, as well as edit them to reflect the changes. Good luck, and if there's anything else I can do for you, let me know. -- Roger

OK, I found out what the problem was (and why your path appeared in the filename string). The buffers that hold the various filenames I allocated with a size of "BUFSIZ" which, in C, is a size that's "optimal for disk I/O in the OS". In Linux (the OS I use), "BUFSIZ" is 8K (8192 bytes). On a hunch, I checked what the definition of "BUFSIZ" was in DOS/Windows. Well, it's only 512 bytes (1/2 K) !!!!!!!! That's why the program messed up for you. When you passed those long path names to MUEDIT in your batch file, your buffer overflowed and whatever was in ram right after the buffer became part of your filename! So, I fixed that and use 8192 rather than "BUFSIZ". Please discard any copies of MBM2PNG and MUEDIT that you have and download this one: http://www.hobbytent.com/other/files/png_package.zip Both MBM2PNG and MUEDIT are in the ZIP package (as well as the source code for both). The files you have now may be working, but it's just random luck. Sooner or later you will run into the problem again. So, scrap those files and use these new fixed ones. -- Roger

I'm glad it works... and I'm perplexed why this one works and the old one doesn't. All the new code does basically is add a few more options. The basic "guts" of the program are the same. One thing that I did (and this may be the key), I strip out path names before displaying them. That is, if your input filename is: C:\Program Files\KSP_win\GameData\Squad\Parts\Engine\liquidEngine1-2\model.mu The path ("C:\Program Files\KSP_win\GameData\Squad\Parts\Engine\liquidEngine1-2\") is stripped out and only "model.mu" displayed. This is only for the status and error message displays - internally the full string is used. In older versions, I only looked for the forward slash "/" (like what Linux and Mac use). Windows would not match a forward slash, so the path would not be stripped. The newest version looks for "/" OR "\" so that paths are stripped the same for any platform. This is the changed code: Old while (ofs--) { if (argv[0][ofs] == '/') { ofs++; break; } } New while (ofs--) { if ( (argv[0][ofs] == '/') [COLOR=#0000ff][B]|| (argv[0][ofs] == '\\')[/B][/COLOR]) { ofs++; break; } } I seriously doubt that this is the reason it now works....... regardless I'm glad it DOES work, and if there's anything else I can do for you, please let me know. -- Roger

If you want, I've got a newer version of MUEDIT. It does the same as the "old" one, but now you can optionally specify the "find" and "replace" strings on the command line. Grab it here: http://www.hobbytent.com/other/files/muedit.zip The default is "find .mbm, change to .png", but you can change either one or both. For example, if you wanted to use TARGA textures instead, you could type: muedit model.mu .mbm .tga Or to change the PNG back to MBM without a hex editor: muedit model.mu .png .mbm There is also the option to override the signature check and the "backup already exists" check, in case you know that you want to replace a backup.

I unwrapped the text to see it more clearly. Notice that the second command (as seen in "result") does not have the filename in quotes. It seems like you have both filenames in quotes in the BAT file, but it's not coming through when you run the program. The second line (the one which is a mess) looks to me like a PATH (because it's separated with semicolons) is appended to the desired filename. The filename is the bold part, the extra junk (path maybe?) is the blue part. I'm not sure why this is happening, but I don't think it's a problem with MUEDIT. For some reason, your computer is passing a bad string (as a filename) to MUEDIT and of course MUEDIT is choking on it. Try these things: (1) In a command window, type "path" and see if your path resembles (or is equal to) the text shown in blue. (2) Try having a blank line between commands. That is, instead of this: muedit "file1.mu" muedit "file2.mu" Try: muedit "file1.mu" (blank line) muedit "file2.mu" (blank line) (3) Try forcing Windows to create a separate process each time it runs muedit. In the BAT file, instead of simply muedit "filename.mu", try call muedit "filename.mu". (4) Maybe the "pause" command in your batch file is messing things up. Try two or three file conversions WITHOUT "pause". Try these things and let me know how it works. -- Roger (edit to add): This is strange... I noticed in the quote that the word "Parts" is split. On my end it looks like "Pa rts". Is there maybe an extraneous character in that filename?

Be sure to put quotes around the filenames. Windows gets all confused with spaces. For example: C:\Program Files\KSP_win\GameData.... will be seen as: C:\Program Files\KSP_win\GameData Because the space between "Program" and "Files" is seen as a delimiter. But if you do this: "C:\Program Files\KSP_win\GameData...." (note the quotes surrounding the string) Then the OS will know that the string is all one line (i.e. one filename). When you say you get "errors", what exactly is the error? If you can tell me the text of the error, I will (probably) be able to figure out what's causing it. -- Roger

Thank you! This is actually better than what I was looking for. With those hinges and other parts, I can make anything. Awesome! Thanks again! -- Roger

Hi all, Is there any sort of mod that provides a SMALL robotic arm that things can be attached to? I know there are a few mods of the American and Russian space station manipulator arms, but what I want is something much more simple. Imagine something like a single landing leg where I could attach the leg to a ship (as usual), but attach something else (maybe a camera) to the "footpad" so that the camera (or whatever was attached) could be folded up and stowed, but then "deployed" (imagine lowering the single landing gear so that the camera swings out). Anything like that? Thanks. -- Roger

Converting an MBM texture to PNG saves DISK space, but in the game the texture bitmap is exactly the same size. A PNG file is decompressed into it's full size while an MBM file is already full size and loaded as-is. Well, the original version of the code I wrote allowed using wildcards, but then I discovered that the Windows version failed if a wildcard was used. For example, typing mbm2png *.mbm in Linux worked just fine. In Windows it failed. It's a problem with Windows, not the program. So, I just removed the wildcard code and made it convert only one file. To do a bunch via a batch file, you could probably use at the command prompt: C:\> dir *.mbm /s /b > all.bat ...to generate a listing of all the files ending in .MBM, then edit "all.bat" by adding the "mbm2png" command to each line, then finally run the batch file. For example, when you generate the batch file, it may look like this: c:\program files\KSP_win\GameData\Squad\Parts\Engine\liquidEngine1-2\model000.mbm c:\program files\KSP_win\GameData\Squad\Parts\Engine\liquidEngine1-2\model001.mbm c:\program files\KSP_win\GameData\Squad\Parts\Engine\liquidEngine1-2\model002.mbm ........ etc..... then open the file in Notepad and add the mbm2png command to each line, so it ends up looking like this: mbm2png "c:\program files\KSP_win\GameData\Squad\Parts\Engine\liquidEngine1-2\model000.mbm" mbm2png "c:\program files\KSP_win\GameData\Squad\Parts\Engine\liquidEngine1-2\model001.mbm" mbm2png "c:\program files\KSP_win\GameData\Squad\Parts\Engine\liquidEngine1-2\model002.mbm" ........ etc..... Then just type "all.bat" (or whatever you named it). Hope this helps. -- Roger

A little off topic... but this may be of help to you. If you run 64 bit Linux and 64 bit KSP, you must patch the 64 bit KSP executable, otherwise it will randomly crash if you load any .PNG textures (i.e. textures from a mod or textures you converted from MBM to PNG for editing purposes). If you run 64 bit Linux and KSP, PM me for the patch info. -- Roger

Sorry. I looked at "General Discussion", "Gameplay Questions", "Challenges", "Spacecraft Exchange" and "Fan Works". I thought GD ("...on topics that do not fit the forums below") was the best choice. I missed seeing "General Add-on affairs". I'm a noob here. I'll get the hang of it. I think though that stating "repeated offences may lead to infractions" is a bit harsh for a simple and honest mistake. Things like that, when unwarranted, may lead to a member saying "forget this" and leaving. Just sayin.....

Hi all, Sorry if this is in the wrong forum... wasn't sure where to ask. Anyway, I'm using Romfarer's "Lazor Cam" (love it). The video window has two size options, microscopic and small. The Lazor docking cam has a wider range of screen sizes (and it's written by the same guy) so obviously the Lazor CAM could have a larger screen and/or more size selections other than two. The question is, is this possible with the CURRENT release of the camera? Is there a config setting to do this? Is there a simple and well known "hack" to change this? Or do I need to ask the author? I looked at the .CFG file and didn't see anything obvious, so I'm guessing the needed change is inside a binary file. Any help or info will be appreciated. Thanks! -- Roger

The MBM2PNG tool already exists: http://kerbalspaceprogram.com/mbm-to-png-file-converter/ It's the PNG to MBM converter that I need to write! As for your question, I honestly don't know what would happen if you downsized a texture. The game may wrap the texture properly (albeit with less detail) or it may only cover part of the mesh. Never tried it, so I don't know. Why not try it? Convert a texture to a PNG, resize it and save it. You also will have to edit the "model.mu" file to use the PNG file instead of the MBM file (that utility is also in my package). If it works, cool. If not, restore from your backup.

Hi all, I've written a small utility called "mbm2png" that converts MBM texture files to PNG. I wish to write the reverse utility also. I've got one small question that I need to figure out first... In the MBM file header are five 32 bit little-endian dwords that describe, in order: Offset 0x00: 3KSP (i.e. a "magic number") Offset 0x04: Bitmap WIDTH (i.e. 0x00020000 == 512 pixels wide) Offset 0x08: Bitmap HEIGHT (i.e. 0x00020000 == 512 pixels tall) Offset 0x0C: UNKNOWN (0x00000000 or 0x01000000 == 0 or 1) Offset 0x10: Bit (color) depth (0x18000000 == 24 bits, 0x20000000 == 32 bits) Offset 0x14: Texture data begins Here's an example from a typical file: ------------------------------------------------------------------------- 00000000 03 4B 53 50 00 02 00 00 00 02 00 00 00 00 00 00 .KSP............ 00000010 18 00 00 00 75 75 75 75 75 75 75 75 75 75 75 75 ....uuuuuuuuuuuu 00000020 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 uuuuuuuuuuuuuuuu 00000030 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 uuuuuuuuuuuuuuuu 00000040 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 uuuuuuuuuuuuuuuu ------------------------------------------------------------------------- The one shown as "unknown" is the one I need to know about. It's USUALLY a zero for 24 bit textures and a one for 32 bit textures (making me think it flags "transparency" or something)... but once in a while there is a 32 bit color depth file that has this word set to "zero". It doesn't seem to matter when converting an MBM file to PNG, but I am assuming it's important the other way around (else it wouldn't be there - right?). So, if anyone can tell me what this flag means so I can set it correctly in my "PNG2MBM" program, I will greatly appreciate it. Thanks! -- Roger

Not really. If you convert a texture to a PNG, it's compressed and takes up less space ON DISK, but when KSP loads it, it's decompressed back into a bitmap. Not only does this take more time (load times get longer), but also no IN MEMORY (IN GAME) savings are achieved. The point of converting to PNG is to be able to easily edit a texture with almost any graphics editor program. Ideally, you would convert a texture from .MBM to .PNG, edit it, then convert it back to .MBM (in fact, I plan to write a companion program for MBM2PNG called, of course, PNG2MBM which does this very thing). Another obscure problem is a bug in 64 bit Linux (and POSSIBLY MacOS - not sure here). If you have PNG textures in KSP 64 bit linux, there is a bug in the program that can cause a texture to cross a memory boundary during decompression back into a bitmap and this results in a processor exception (a core dump and crash). The fix is to patch two bytes in KSP.x86_64 (and ONLY that file). The thing is these crashes are random. If a bitmap decompression doesn't happen to cross a memory boundary, KSP will load just fine. Also, depending on the order modules are loaded, KSP may or may not crash during PNG loads. Here's the patch data (again, ONLY for Linux and ONLY on the file KSP.x86_64). BE SURE TO MAKE A BACKUP FIRST!!! root@michael:/usr/share/KSP_linux# fcmp KSP.x86_64 KSP.x86_64_Patched Reading KSP.x86_64 (17930928 of 17930928 bytes) Reading KSP.x86_64_Patched (17930928 of 17930928 bytes) 007CEBC7: 01 00 007CEBCC: 01 00 fcmp: 2 mismatches encountered In case the above is confusing, it means: Change the byte at address 0x007CEBC7 from one to zero and also change the byte at address 0x007CEBCC from one to zero. BTW, these addresses are valid for KSP 0.21.1 and 0.22.0 (not sure about older versions). Here's a copy of "fcmp" (with a README file, C source code and pre-compiled executables for Windows and Linux) if you wish to use it: DOWNLOAD LINK Again, please be sure to make a backup copy of any file before editing it! Lastly, here's the link to the original info about the bug: http://bugs.kerbalspaceprogram.com/issues/752 -- Roger

When I de-orbit a Kerbal, they end up dead, I assure you.

Hi all, Sorry if this is a stupid question, but I've seen a lot of YouTube videos of KSP showing multiple Kerbals outside a craft and I wonder how that's done? All I know of is to click "EVA" and then ONE Kerbal is outside. At this point I cannot do anything else other than maneuver the Kerbal. If, by chance, I'm on orbit and the EVA goes bad (i.e. I lose control and the ship drifts away), my only recourse to keep playing is to turn on infinite fuel, deorbit the Kerbal (!!), then go to the tracking station and "fly" the craft (minus one occupant of course). Is there some trick I'm missing, or is there an official documentation file that I can RTFM? (Yes I have searched Google BTW). Thank you. -- Roger

You know, that sounds exactly what I did. I've looked into the "persistent.sfs" file and found an option called something like "missing crew respawn" with a "true" or "false" attribute (set to "true"). Maybe editing it to "false" would work? I'll try it and post my findings. -- Roger

Long before I ever heard of MechJeb, I've flown missions to the Mun, landed and returned all manually. I've also played with the Apollo style "free return" flightpath and purposely skipped the Mun orbital insertion burn and flipped back home (albeit with a small TCM required) just to see if ti would work. As far as using MechJeb, I don't have the one with the module integrated into the command pods... I use the "stick on" version (the "AR202"). That way, I can use it or not at will, and on any command pod (stock or add-on).

Yes actually there was. I didn't post the pic because it wasn't all that great. Unfortunately, the chute deployed itself before I could wait until a low enough altitude and velocity and it tore off. The CM hit the ground pretty hard and blew up. All three crew were in the CM, the LM was SUPPOSED to be empty, but somehow Jebediah stowed away (which would have made the Minimus landing mission a bit complicated). Oh well... crash and learn.

Come to think of it... you're right. It's obvious now in screenshot #3... the thrust vector is more or less pointed AT the Mun when it should have been more or less 180 the other way. I thought "OK, service module engine is firing... we're going the right way". Then when I saw the Mun encounter on the map, I thought the problem was a computational confusion due to the gravity influence the Mun would have when I passed by. I guess that's why NASA didn't hire me......

I know I parked somewhere near here..........