Krupski

OK, I built a pretty nice CSM and LM, got them into orbit, docked and at the last minute decided to fly to Minimus instead of the Mun. So (I'm a cheater) I setup MechJeb to do a transfer from Kerbin orbit to Minimus. As my usually bad luck would have it, my flight path took me right through the Mun's gravitational influence. The result was that MechJeb got confused and demanded an over 4000 m/s delta-V. So (once again) I cheated and turned on infinite fuel to see if I could make it past. (edit): My mistake. MechJeb wasn't confused... I was. I had "control from here" set to the LM instead of the CSM. Therefore, the guidance was coming from the LM but the propulsion from the CSM (i.e. backwards). My ship was trying to do a super retrograde burn to REVERSE it's orbit and then add MORE to do the Hohmann transfer to Minimus. In the process of the Kerbin orbital velocity going down, through zero(!!!) and then back up the other way, gravity did it's thing and that's why we crashed. All looked fine until I realized that my new orbital path (the Hohmann transfer orbit to Minimus) passed THROUGH Kerbin! There was nothing left to do except notify the families of the three brave Kerbonauts and await the inevitable. Here's how it went....... Jettisoned the third stage - Yippee!!!! We're in orbit! Extended the landing gear. Purty ship - sorta looks like an Apollo LM and CSM The TMI (Trans Minimus Injection) Burn - Glow of the atmosphere... Mun in the background - beautiful! Uh-oh this doesn't look good...... Not good at all.... Look at the velocity going down, altitude going down and required delta-V going up!!!!!!!! We WERE at 200Km - Doomed! I knew it would end this way. There goes the service module... Not much to say here except "goodbye". Why is Jeb SMILING at a time like this??? And where did he come from?? He wasn't on the crew! At least it was quick...... ...and painless. I didn't even think to quicksave it.

LOR is the most efficient way to do it, which is why Apollo used it. Mass is used, then discarded. Nothing "excess" is carried along as dead weight. If they could successfully pull off LOR back then, with electronics in it's infancy, they can certainly do it now. Funny thing is, everyone who tries to design something "better" for a manned lunar mission always seems to end up coming back to the "Apollo" method (a testament to how good the original engineering was).

Well, the idea of computing "power" really doesn't figure into a comparison like that. The AGC was more of a microcontroller than a computer. Think of, say, a university student robot project. The robot may have motors for movement (analogous to rocket engines), steering servos to control direction (like RCS), optical or ultrasonic sensors to detect obstacles and steer around them (CM rendezvous radar or LM landing radar), a gyro or GPS for position knowledge (inertial platform), etc... To build a robot like that, you wouldn't want or use a "powerful PC", you would use a relatively simple microcontroller board like an Arduino or PIC or Motorola EVBU, wire up all the sensors, motors, etc... and then write simple, custom software to read sensors, control motors, decide when to drive, where to steer, etc... A little microcontroller (like an Arduino) could have probably run the LM and CM quite nicely, but alas they didn't have those back then. Another REALLY great innovation in the AGC software was the priority interrupt driven executive. As an "OS", it puts even Windows, MacOS or Linux to shame. Various tasks were given different priorities, and if the computer got overloaded, it delayed running low priority routines. For example, the code to read the inertial platform and calculate range, range rate, velocity, etc and control RCS and DPS (in the LM during landing) was a LOT more important than, say, updating the DSKY display to tell how fast they were going. That was the famous "1201" and "1202" program alarms. There was no software error. The computer simply said "I'm a bit busy here, I'm not going to update the Delta-H display right now, sorry". And the reason for those errors is terribly mis-documented in most literature. Some sources say "The rendezvous radar was mistakenly left on". Wrong, It was supposed to be on. Since it used a vacuum tube to generate the radar, it needed to be warmed up in case of an abort. Others say it was because the computer was too slow. Wrong again. The real reason was that the LM ran on 400 hz, 3 phase AC power. The inverters were supposed to be frequency locked (they were), but also PHASE locked (they weren't). So the resolvers in the rendezvous radar dish actuators produced random antenna position data instead of clean data and that caused the routine which locked the radar on the CSM to go wild searching for a target that SEEMED to be jumping all over the sky. This sucked up about 15% of the total computer time and the executive said "forget this, I have to watch the LANDING radar" and issued the 1201 and 1202 overflow errors. The problem was never caught in ground sims because thay all ran on one power supply (which was obviously phase locked to itself). So, the AGC didn't fail. Instead, it did PRECISELY what it was supposed to do and it saved the Apollo 11 landing from an abort. Thank God they weren't running Windorw!!! Can you imagine a blue screen crash 1500 feet above the lunar surface??? We owe a big thanks to the Apollo program for all the goodies of technology we have today (like monolithic integrated circuits that make up the CPU and every other chip in our PC's)... those were invented by Dr. Robert Noyce and first mass produced by Fairchild Semiconductor for use in the Apollo AGC. Our super-duper Core-whatever processors are just improved versions of the first "chips".

I thought about it more and now I think THIS would happen: Going clockwise, I think the ship would stretch more and more, then finally snap, 1/2 being pulled into the black hole and the other half zipping away. (the circle is the orbital path of the sphere). My brain is beginning to hurt again.

Gosh you are right. Need to finish my coffee before I post! Thinking about it though, ANY place at the proper altitude for the orbital velocity the craft has would be the "zero G" point. So wouldn't the craft be PULLED into a thin "wire" (ultimately becoming a semi or complete RING) orbiting the black hole?

Although a spacecraft theoretically could orbit a black hole, in reality only the exact center of mass of the vehicle would "feel" zero G. Any other area would feel a positive or negative gravity gradient due to being located elsewhere than the center of mass. That's why NASA now uses the term "microgravity" for vehicles on orbit. First of all, the orbiting vehicle is perturbed away from a "perfect" orbit by solar wind, atmospheric drag, astronauts moving around, etc... but also only the exact center of mass feels "zero G". Because gravity decreases with distance from the body, objects inside, say, the Space Shuttle, might feel +0.0001 G in one area of the spacecraft and -0.0001G somewhere else. That difference is the gravity gradient. Now imagine orbiting a black hole. The gravity gradient might be something like +1000 G in one spot and -1000 G in a different spot. That gradient would certainly kill any living occupant orbiting a black hole, and would probably crush the spacecraft into a very small sphere (all points trying to get to the center of mass). Crazy stuff....

Getting into a higher orbit requires MORE energy. ANY contact with the atmosphere DRAGS AWAY energy. Therefore, the answer is "no, you cannot get stuck in a higher orbit". On actual manned missions (i.e. Apollo) the danger was hitting the entry corridor too shallow and not burning off enough velocity to be "captured" by Earth (i.e. slow down below orbital velocity). Of course, hitting it too steep was equally bad since the crushed astronaut bodies would be incinerated by the excessive heat. If that happened, the CM (minus the SM and it's life support!!) would zing through the upper fringes of the atmosphere, loop around the Earth and head back towards the Moon (albeit with a much lower apogee than the mission itself used). By the time the astronauts came back around for the next try, they would be long dead from lack of life support (no O2, no electrical power, no water, probably terrible buildup of CO2 due to the LiOH being used up, etc...). A re-entry profile COULD, if necessary, do a "small skip" where they would climb up to the upper fringes of the atmosphere, fly further, then roll back into a "lift down" orientation and enter later (to change splashdown location). To think we use quad core or better computers with gigabytes of ram to run KSP and MechJeb... Apollo did it for real and did it right with a computer built from a bunch of NOR gates, 2K of "RAM" and 38K of "ROM" made of wires laced through little ferrite cores! I get shivers every time I think of what the Apollo program accomplished...

<ComplaintText> At least Orbiter has decent graphics.......... </ComplaintText> Real spacecraft How the MOON should look How a typical GAS GIANT should look (those little dots are MOONS!) The beauty of Orbiter with the simplicity of KSP would be the ULTIMATE package!

My biggest (and recurring) problem is accidentally bumping the spacebar and staging away my last fuel and engine, left to drift forever with the rest of the discarded space junk.....

If the escape velocity at the event horizon of a black hole is C, then further in it must be higher than C. Yes? Or, if NOTHING can be faster than C, and if density goes up to infinity at C, then a black hole must be a zero thickness, infinite density shell surrounding.... what? It boggles the mind!

OK, I went to launch my latest beast and, of course, it's dark. It's night. It's ALWAYS night. No, wait... the sun is shining... it's just got a HOLE in it! Are you KIDDING ME??? An ECLIPSE? Yes, it was an eclipse! So, here we go with the screenshots! First stage Second stage On orbit View out the window of the lander Neat, huh?

MBM files should load quicker because they don't need to be decompressed.

I already wrote my own MBM to PNG converter program. To create KSP mods, I'm using Blender to create .DAE files and using .PNG for the textures. As far as taking stock KSP textures and converting them to PNG, what one can do here is modify a texture and improve (or just change) how a part looks. See this post: http://forum.kerbalspaceprogram.com/threads/36302-Editing-textures-when-they-are-MBM-files?p=658039&viewfull=1#post658039

Just D/L'd this package. LMAO at the corned beef sandwich in the cabin!

Here's a screenshot of the Neil A. Armstrong Memorial site... in 3D. The picture is called an "anaglyph" (you who have been following Mars Pathfinder, Spirit & Opportunity and Curiosity have seen anaglyphs). Use red/blue glasses, red lens on the left eye.

You know... recording a mission should be EASY. All that needs to be saved is a timeline, coordinates vs time and the parts that make up the vehicle. It would be easy to "play back" that data into the game engine and replay what had already been done. I'm sure it would even be easy to watch a recorded mission from another location (like watching a launch from the ground or seeing a lander coming in for a landing while watching from the destination planet). That's the same thing that's done for multiplayer. Every player's coordinates are sent over the network and each client renders the remote players at their coordinates. Shooter games also send weapon and projectile vector data so that shots, hits and misses can be rendered on all clients. Only problem with multiplayer is that each client would need the same setup (or be able to download parts and textures for missing parts). Hacked parts (like fuel tanks with double the fuel) would need to some how be prevented (or replicated to all players). Also, more realistic mass and fuel loads would be nice. Big solid boosters for manned vehicles don't burn out in 20 seconds, for example......

Random generated celestial bodies make no sense since they would be there one time but not the next. And if they were generated each time the game was started and saved, the universe would clutter up with planets! It would also be impossible for anyone else to fly a mission to the same planet that you did (because only you have it). However, a lot more "permanent" bodies like comets and asteroids would be nice. I don't know what impact that would have on game speed (since the game would need to keep track of where they all were, do all the orbital calculations, etc..). As it is, there's enough "space junk" up there already. I once got into a 200km circular orbit using MechJeb, then left it there (forgot about it). Later I sent up another vehicle into the same orbit and while doing a rendezvous, all of a sudden my ship blew up! I said "WTF???" then looked at the log. I collided with a decoupler from an old mission!!! I wish I had that one quicksaved... it would have been neat to see the ring of death coming...... On another note.... something that should be easy... stick on decals. For example, you could grab a national flag as a "part" (with zero mass and drag), and stick it onto your booster. Other decorations too... Roman numerals (like on the quadrants of a Saturn S1-C), GSE umbilical ports (non functional, just for looks), maybe even a customizable decal (type in something like "Danger Toxic Fumes" and add from a selection of clipart - maybe a skull and crossbones) and stick them near RCS quads.... or choose the text (vertical or horizontal and the color) and stick a nice vertical "United States" in red on the side of a fuel tank (again, like a Saturn booster). Little bits like that would not use up any more processing power (i.e. wouldn't slow down the game) and would go a long way toward making the vehicle look "really neat".

You found it. I wrote it! Seriously though, thank you for pointing it out for me! -- Roger

Don't know if this has been posted before, but gimbaled engines (2 or more obviously) should be able to control ROLL as well as pitch and yaw.

I assume this utility needs Unity to run? Is there any way to use it "stand alone"?

Glad you can use it! Please check to see if you have the latest version: I uploaded one one update since the original. http://kerbalspaceprogram.com/mbm-to-png-file-converter And, if you find any bug(s) (which of course there aren't! LOL) please let me know. -- Roger (edit to add): I updated the upload. It now contains two utilities... the original "mbm2png" converter and a new one "muedit". What "muedit" does is change the filename extensions inside "model.mu" files from ".mbm" to ".png" (the thing that had to be done before with a hex editor). Also, "muedit" makes a backup copy of the original file (just in case!), it checks for a valid signature (won't edit the wrong files) and will refuse to overwrite an existing backup (prevents trashing an original backup with a modified one). Of course, full documentation and C source code are included. Enjoy! Hope this is of some use to someone!

Here's an example of what can be done. First I went into the directory "KSP_xxx/GameData/Squad/Parts/Engine/liquidEngine1-2" (the Rockomax "Mainsail" engine). Then I converted all the modelxxx.mbm files to PNG files. I edited "model002.png" which is the texture for the exterior of the engine. Here's what I did to it in Photoshop: Notice the nozzle now has regenerative cooling tubes rather than being plain grey and has stiffening bands. I also did the inside of the nozzle to show the tubing, erosion streaks from firing and the injector plate in the center. Lastly I made a new logo for the engine "Rockets R-Us" Using a hex editor, I edited the file "model.mu" and near the bottom, changed all the texture filenames from "modelxxx.mbm" to "modelxxx.png". Here's what the text editor looks like after the edit: 0002B7F0 00 08 66 61 69 72 69 6E 67 31 03 00 00 00 00 00 ..fairing1...... 0002B800 00 00 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 .....?...?...... 0002B810 00 00 01 00 00 00 00 00 80 3F 00 00 80 3F 00 00 .........?...?.. 0002B820 00 00 00 00 00 00 06 65 6E 67 69 6E 65 07 00 00 .......engine... 0002B830 00 02 00 00 00 00 00 80 3F 00 00 80 3F 00 00 00 ........?...?... 0002B840 00 00 00 00 00 03 00 00 00 00 00 80 3F 00 00 80 ............?... 0002B850 3F 00 00 00 00 00 00 00 00 C0 AF C6 3D C0 AF C6 ?...........=... 0002B860 3D C0 AF C6 3D 00 00 80 3F BF CC EB 3E 04 00 00 =...=...?...>... 0002B870 00 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 ....?...?....... 0002B880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 ................ 0002B890 3F 0C 00 00 00 05 00 00 00 0C 6D 6F 64 65 6C 30 ?.........model0 0002B8A0 30 30 2E 70 6E 67 00 00 00 00 0C 6D 6F 64 65 6C 00.png.....model 0002B8B0 30 30 31 2E 70 6E 67 01 00 00 00 0C 6D 6F 64 65 001.png.....mode 0002B8C0 6C 30 30 32 2E 70 6E 67 00 00 00 00 0C 6D 6F 64 l002.png.....mod 0002B8D0 65 6C 30 30 33 2E 70 6E 67 01 00 00 00 0C 6D 6F el003.png.....mo 0002B8E0 64 65 6C 30 30 34 2E 70 6E 67 00 00 00 00 del004.png.... 0002B8F0 --- model.mu --0x2B780/0x2B8EE------------------------------------------ So how did it turn out? Here's a few screenshots from the game with the edited texture: (do not stand here when engine is running!) BTW, the original image I used for the nozzle interior is a picture of the XLR-99 engine used in the X-15 project. This image: http://airpigz.com/storage/hi-res/2012/North-American-X-15-66671-Air-Force-Museum-Looking-Inside-Exhaust.jpg A quick online search yields all kinds of great stuff to use in editing your textures. For example, you can make the FL-T800 fuel tank look very much like a Saturn S1-C simply by adding a few decals... like these: http://www.ninfinger.org/models/vault/est2001sw.jpg Neat, huh?

Are you trying to click on it from Windows explorer? If so, what you are doing is just running the program with no filenames to convert and it gives you a brief message, then quits. Instead, do it this way: (1) Go to START button (2) Click "RUN" (3) Type in "cmd.exe" (no quotes, just cmd.exe) (4) A black window with white text will appear. (5) Find the utility, then type in the command to convert an MBM file: C:\> mbm2png model000.mbm (press enter) The program should run and show you what it did. You should also have one new file named "model000.png". Of course, you need to be in the proper directory (that is, where the game texture files are). Typically "KSP_win/GameData/Squad/Parts/(whatever part)". When finished, you can either type the command "exit" (again, without quotes) to close the black CMD window. Like this: C:\> exit (press enter) The CMD window closes. Hope this helps.

Yup. I discovered a bug in the Windows version... the wildcards don't expand properly. I'll fix that and upload it. Don't worry though, the converted PNG images are OK... it's just the wildcards that fail in Windows. Sorry. I'll also fix the README file. I did all this work in Linux and as you (may) know, Linux/Unix uses a LF for line endings. Windows uses CR/LF, so the readme file might look like gibberish in a Windows text editor. I'll convert the README to use Windows style line endings (since Linux doesn't care about that.... much).

Hi all, I've had lots of fun modifying some of the part textures in KSP and I found that the biggest "pain" was converting the MBM files into PNG files. So I wrote a little utility to do it. Check it out: http://kerbalspaceprogram.com/mbm-to-png-file-converter Hope this is of some use to someone....... -- Roger