Ruedii

The reason we don't have true SSTO flights yet is simply because it's cheaper to risk damage to the recoverable stages than the cost of the added fuel to carry them to orbit.

Your computer should be fine, but you will need Proprietary drivers for your video card. As for screen recorders on Linux, I recommend Istanbul. I know it's a little old school, and can be clunky at times (lacking multithreading) but it's low overhead and runs nice. For a more advanced system use a system streamer to run to a remote server which then you can program to record said stream. (This has the lowest processor overhead, but does create a small amount of network overhead, but it's fine for games like KSP, even if that network overhead might cause problems for some fast-paced first person shooters.) To eliminate the network overhead, you can simply place it on a separate network card. However, that is an extreme solution for a minor overhead.

Try using Linux, the win64 version of KSP is broken, and the problem is upstream in the Unity Engine, so there is nothing Squad can do about it. If you want 64bit use Linux.

The fix to this is to make sure to use a full size flag template, even if the edges are transparent.

For virtual box, I would definately recommend using OpenGL to play games. It's OpenGL capabilities are far higher than it's Direct3D capabilities. However, you will still run into significant bottlenecks, including limits on the amount of video memory you can allocate and latencies when transferring things to and from video memory. This is not to the fact that the virtual video driver prevents the proper optimization of shaders for your bare-metal hardware. If you have two video cards you can set up a dedicated video card for your virtual box machine. This is faster, but difficult to set up. It still will have some latencies, but your guest OS will have direct access to the video card. As of VM-Ware, I recommend against using VM-Ware for gaming at all. (I generally recommend against using VMWare for anything but servers.)

Some antivirus software might cause problems when trying to run it from a flash drive, but those are rare cases. If this happens the solution is to just scan the drive manually then whitelist it to deal with the problem.

You can either move the nacelle or add a fuel line.

Are you using a 32bit Windows system, because if you are, KSP has to share it's memory space with all background programs and services. Close some of the background programs, and turn off some unnecessary services. You could also try loading up in OpenGL mode, because it seems to have a smaller memory profile.

Well, I did more research, the only way around Unity's default texture formats is to write your own texture handling shaders to real-time convert the shader to and from the desired format (i.e. convert from LA88 to RGBA888), in other words, Unity3D made life a POTA again for us because they can't keep up with the times and expose all the graphics capabilities of modern hardware! It probably isn't worth this hassle. Also, you don't want to be using ECRG format, because EC compression sucks. Fortunately, from what I can tell they might just be exposing ATITC capability on PC hardware. It's worth an attempt, as it would create a night and day difference in both rendering speed and quality. However, they have yet to expose the PC hardware capability of ASTC, which is an even better algorithm (i.e. it is currently the best algorithm out there.)

From what I can tell, Unity3D doesn't seem to expose that part of the function, so you'd have to bypass some of Unity's texture loading mechanisms, and that is never easy. (It's possible, but not easy.) That might be an issue. It's a real shame too. I also noticed that they no longer mark ATITC as mobile only. Could you create an experimental version that will check for that capability and use it if it's available? According to my research, ATITC is optional in Direct3D 9 and required in Direct3D 10. It's also handled differently in the two versions. Likewise it's optional in OpenGL 3.x and required in OpenGL 4.x. (Believe it or not it was nVidia who pushed to get it in OpenGL 4.x, which is why the nVidia variant with 4 different mappings is used, instead of the ATI version with only 2 mappings.)

BTW LA16 is also called LA-8:8, RA-8:8 or GA-8:8 and uses 16bpp/8bpc As opposed to the default of XGXA-8:8:8:8 which uses 32bpp/8bpc I'm basically saying you should pixel pack into a 2-channel 16bpp texture, instead of leaving filler in the ignored channels. The graphics card can be set up to automatically convert it by simply saying the L channel is monochrome and the A channel is alpha. The fill channels don't matter, so it doesn't matter that it will mirror into it. (Saves the other option which is to say it's palleted and use a lookup table.) Likewise you can also take the compressed and put it in a 2 channel 8bpp/4bpc texture by doing the same swiveling technique.

Yes, they expect GA, but they don't expect LA16, which is packed LA:LA:LA:LA instead of XGXA:XGXA:XGXA:XGXA (In other words, LA16 is fully packed, while RGBA32 has fill bytes.) Without the fill bytes, LA16 has half the required memory space.

Some feedback: Make sure there is an area along the base to attach things to radially mirrored at 4x. This is a common method for radial attaching rocket nacelles to landers, as well as attaching various other things. Also make sure your two side positions are also equal distance from each other. This will make the part more useful, while maintaining your nice space-styling aesthetics.

Is there a way you could set it up so that 2-channel normal maps are stored in either RG-16 format or color-swiveled LA-16 format? This would cut the memory footprint of normal maps in half, and the later option, would allow for the use of DXT-5 texture compression without significant distortion. (Although a color space conversion shader may be necessary for compression/decompression and hence reading and writing. Either all three color parts can be mirrored from the "L" channel or the G and the B can be zero-filled it doesn't matter. It might actually be faster to simply use a greyscale to color conversion, hence mirroring out the "L" channel into RGB, because there is a driver routine to do that, and there is no zero-fill routine, so you'll need a custom shader for that, or use the more advanced color-space conversion routine.)

I didn't mention before, but your best stock rocket engine for space planes is the aerospike. You can use your rocket to improve takeoff thrust as well, and then turn it off once you are off the ground.

A couple cool things to have are as follows: Some brown dwarfs, black dwarfs and other "dark stars". (A brown giant or black giant would be downright awesome!) Some rogue planets, some of which have moons. I would love to see a few multi-star systems. Including your basic binary system, where the two stars orbit their mutual center of gravity, as well as ones where massive giant stars are orbited by dwarf stars. As of planets on these, wikipedia has a good list of theoretical planetoid types, but of the ones listed, the items I'd like to see the most are carbon planets, cannonball dwarf planets, and ocean planets. If someone wants to come up with names and details for these things, be sure to. Just remember to adjust the scalings to KSP universe (a.k.a. 0.5 length measurement with the same mass)

You can use the KAS strut attachment points. Of course you have to go on a space walk to make the attachments, but that's not a big deal. Another, slightly more difficult option is to actually use multiple docking ports. You can place two or more docking ports in an arrangement to greatly reduce bending. (Two reduces bending in one direction, which is great for radial mounting nacelles, three or more reduces bending in all directions.) You can actually get away with the clamp-o-tron jr on this method.

A KSP.log file too would be nice. It's in your KSP directory. Anyway according to the log you provided it looks like a texture heap overflow from running out of memory. You have three options: 1. Remove some of the parts and/or mods you don't use 2. Install Active Texture Management and/or decrease it's quality settings. (Read the README on it if you want to know how to reduce quality settings) 3. Do both (recommended.)

It looks like you just have too many mods. When KSP jumps scenes it suddenly inflates it's memory profile for a short period of time, this can cause segmentation faults in the heap if there is not enough memory to meet this memory profile. B9 and KW are particularly bad at eating up resources. You could either remove the parts you don't use, Install Active Texture Management, or do both. (I recommmend both.)

Looks like texture memory corruption. Either your video card is overheating or you are running out of video memory. Try turning off overclocking and/or cutting down your mod count. It might also be related to a win64 bug corrupting texture memory. In that case, try Win32 binaries, or use Linux.

Something could have changed on your system that reduced the memory or video memory available to the game. Did you try removing one or two mods, or try using Active Texture Management (ATM) or reduce your ATM quality settings to save RAM? However, if the log is correct, it seems it's failing early in the loading process, possibly before loading the first Mod. You might to make a fresh install then move over all your mods one by one, then finally your saves. Could you upload the other log? (KSP.log in the KSP home directory) Some things load with more detail in one log, some in the other.

I was wondering, is there a way you could make yaw and pitch control be to attempt to move the nose to a point, based on controls, relative to the direction of airflow? I know this is a complex system, and might be beyond the scope of this mode, so if you don't want to do that, I'll make a suggestion for a mod request instead.

If you need to you can undo the FAR stock rearrange of the stock engine power. I personally prefer the B9 setting set, although I still think they could use adjustment. Personally, I'm thinking of making my own module manager files for jet engines.

Looks like you've got a problem with TextureReplacer. Try running without that mod in particular. The other mods will likely work. Remember, in Linux you should use the x86-32 version of mods even with the x86-64 binary, because Linux doesn't go and change stuff around in x86-64 mode the way Windows does.

I tend to send Jeb on important and exciting missions. I especially like sending him to fly missions that have a lot of hands-on piloting, because I like his facial expressions.