Ruedii

I haven't had any issues, of course I followed the standard 0.23 update method for all my plugins. This means if they include external libraries (in this case KineTech and FireSplitter) update them. I also have the memory reducer mod installed, which fixes many issues.

drtedastro, you should be able to find a utility online to convert PNG to CSV format. Even simply, convert PNG to XBM format, which is a C-Format human readable code.

RealChute support isn't so much about the better auto-deployment system, so much as the more realistic deployment, plus the improved parachute sounds and graphic options. (Animated deployment with cool sound.) However, building in a built in emergency auto-deploy for when Jeb gets too daring playing chicken with Kerbin's surface (or Duna, Eve and Laythe's surface for that matter) wouldn't be a bad idea. Real life parachutes have those for if the person passes out during the freefall. RealChutes also gives you the ability to anchor two chutes in the parachute bag. Supposedly it gives a lot of hidden attaches and libraries for parachute developers too.

OpenGL currently supports multiple texture compression codecs, including several newer low-loss codecs, other than the popular early varieties S3TC (DXT1/DXT2) This is without considering the option of creating shaders to handle compression. According to my research, switching to the 3Dc (a.k.a. DXN, BC5, ATI2, RGTC2, LATC2) or 3Dc+ (a.k.a. BC4) would provide much better quality, and allow the compression of normal maps with minimal loss and fewer artifacts. In OpenGL 3Dc and 3Dc+ are implemented through the RGTC2 algorithm or LATC2 algorithms. BPTC is probably superior for regular textures, however only the latest cards will handle it, but LATC2 and RGTC2 are probably still superior for normals. Additionally, all three of these compression formats are open standards, and thus better supported by Open Source drivers on Linux, which currently take a bad quality hit in S3TC type compression, by using the S2TC algorithm that is significantly lower quality, even though it is a little faster and open-standard. Because the best texture formats are only available in newer cards I would recommend setting a list of fallbacks for compression algorithms for each purpose, with the option of changing them for specific textures. (For instance, you may want to use the high-compression list for some textures and the low-compression list for others.) If you would like I can repost this on the dev page for this plugin, or file it is a feature request in your Github page.

Is there a way to add a panel with all ribbons awarded overall?

Might it be better to use a standard C-Like config, like most KSP config files, and support indexed PNG formats by index value: Example Below (Ranges expressed as comma sepearted values) Planet("PlanetName1"){ Bitmap = "Filename1.png" Biome ("BiomeName1") { Type = "RGBA" Alpha = (0, 255) Red = (0, 255) Green = (0, 15) Blue = (0, 15) } Biome("BiomeName2"){ Alpha = (0, 255) Red = (0, 255) Green = (16, 255) Blue = (16, 255) } } Planet(Planet2){ Bitmap = "Filename2.png" Color = "8BitIndexed" Biome("BiomeName1"){ Index = (0,127) } Biome("BiomeName2"){ Index = (128,255) } }

It would be cool to use the new tweakables to handle colors, if that's possible. I'd recommend using either 0-15 (12 bit color), and have a fourth scaler for intensity. This is simply because using full 24 bit color, would be impracticle. You could also have a quick button to rotate between popular colors (Red, Green, Blue, White and Amber) By having the color and brightness adjustable, this would further reduce the number of different parts needed, thus reducing the size of the mod, while increasing the mod's functionality.

I know the FAR plugin is WIP, and probably not ready to be added to the main MechJeb modules, but is there any way you can get the toolbar support added to the main mechjeb system, and even allow it to hide the main window completely?

If you are looking for a neat ship to create a KSP version of, the Firefly cargo transport from Firefly/Serenity would be a great ship.

Any chance of making a patch to make this use the RealChute parachute routines if RealChute is installed?

Is there a way you could get this compatable with Vanguard EVA Parachutes? Just curious. Don't make it higher priority than other issues.

Is there a way to make the alpha-dropping selective in future versions so it can be re-included in the aggressive version?

I'm having an unusual issue that if I save a game in the 32 bit binary and load it in the 64 bit binary I get an issue where it claims parts are missing on all the crafts, but the parts in question are there in VAB mode. Does anyone know how to prevent this other than just using the 32 bit binary, as 64 bit mode would be very useful when I install more mods. Another question, are there any plans to make the 32bit binary enhanced for x32 mode (x64 Long-short mode) and thus able to use the 64bit registers, and a full 4GB per an allocated page. Also, are there plans to use multiple pages of memory in the 32bit binary? I know multiple pages are a total pain in Windows, but this isn't the case in Linux or OS X. Just moving the binary/data, the terrain models/textures/shaders, and the part models/textures/shaders to separate pages would really improve the memory capability. Splitting the parts over several pages would improve the part capability even more. Finally, are there plans to make the Kerbalizer launch in the NativeClient based Unity Web Plugin so that we can use it on Linux (and any other obscure platform that supports Chrome/Chromium browsers.)

I'm going to try to install B9 with 0.23. I suspect I just need the updated firesplitter.dll, which I got with another mod.

Is this compatible with non-Windows platforms?

The whole RLA line has a lot of good probe parts. KSPX includes quite a few small parts as well. There is one really good small booster rocket in NovaPunch. I will have to check out AIES. As a note, you rarely have to install all the parts for a part-pack mod. Usually you can just delete the parts you don't use from your folders, or never copy them in the first place.

Well, on memory 64bit would allow for more than 4GB per a segment. This makes programming large memory use a lot easier, as no segmentation would be necessary. This added space would allow for allocation of all data into virtual memory, whether or not it is loaded, so it would reduce constant allocation and deallocation of data objects. (For example texture maps of all the planets.) Second, it would greatly improve performance of integer operations, and large memory transfers. Integer operations, especially 64bit ones, are significantly slower on 32bit platforms because of fewer available registers.

The estimates of the absolute minimum needed to get reasonable performance and graphics on KSP is: 1.6Ghz dual core or 2.0Ghz single core. Shader Model 2 graphics chip. 1GB of free memory. To get full gameplay capability: 2.0Ghz Dual core or 2.4Ghz single core Shader Model 3 Graphics chip with 512MB memory 2GB of free memory For best performance: 3Ghz Dual core or better Shader Model 3 Graphics Card with 1-2GB of high speed video memory 4GB of RAM While KSP itself isn't heavily multithreaded, a dual core processor allows the GPU, sound chip and OS processor usage to be offloaded onto the second CPU, dramatically improving performance. I used to run KSP on an AMD A4 Series APU Desktop just fine. I even could get full resolution and reasonable effects. Of course, this system did have some killer RAM in it, and the biggest bottleneck in the A4 is actually the RAM, due to the A4's lack of cache.

First, for asparagus staging. These huge pancake shaped ships are what doesn't work. Obviously, you only want a couple side stages, instead of dozens of them. Second, as of getting large interplanetary tankers, I recommend building them and/or filling them in orbit. It doesn't hurt to empty them on the way up if you bring up loads of fuel to fill them. Furthermore, rather than landing your entire ship on a planet or moon, just bring down a lander module, then have it dock back up with the mother-ship in orbit. This way the module doesn't need enough fuel to return to Kerbin, just to return to orbit. You can even carry multiple lander modules if you like.

Kerbal Engineer or MechJeb are your best solutions for calculations. Mechjeb's interface is nicer, and it has more features, but some players think it has too many features and can take the fun out of the game. You can always turn off the visibility of the features with the advanced settings. (For instance you can remove the execute maneuver buttons from the maneuver planner, and remove the autopilot enable button from the ascent guidance panel.)

This is great. It serves one of the two things I use MechJeb for when I'm not using auto-pilot. (Stats and calculations.) I'm just curious, is there a way to lay out the in-flight window into two columns instead of one, and to reduce the font size? The window sometimes gets too large for my screen on rockets that contain a lot of stages.

Since you are using GitHub, do you think you could see about integrating it with Enchanced NavBall, at least as a fork at first until you and kitoban can iron out the details of getting it into the main mod?

To be specific on the cause of the number 666666 is approximately 2/3s of 1 million. Continual 6s to pop up quite a bit in computations for this reason. (Take 2 times any power of ten then divide by 3, and you get a sequence of 6s). Of course, most of you don't need a lesson in math.

AncientGammonerm, About memory and the 64bit version, the 32bit Linux version can handle a LOT more memory than then 32bit Windows version. This is so in both 32bit under 64bit Linux and 32bit Linux. 32bit Linux runs in PXE mode, and under 64bit Linux memory segmentation is handled a lot better. 32bit Linux programs support 4GB per a program segment and programs can have multiple segments up to several terabytes of physical and/or virtual memory, meanwhile 32bit Windows supports 3GB physical memory on the entire system, and many 32bit programs are restricted to 2GB of memory. Technically, under 32bit Linux most users could run a program that maps their entire hard drive to virtual memory address space without hitting the limit. Notably, under 64bit Linux this could be done in one data segment, though. I am not sure if KSP uses multiple data segments, so I'm not sure

Generally on Space Stations, I tend to not use key bindings because I only deploy the parts once. I tend to turn everything on and leave them. This prevents me from accidentally turning them off. Because of this I use the right click menu. Some players like to retract their solar panels when docking, to prevent accidental breakage. Also, since antennas only extend once binding them to a key could be useful, especially if you attach lots of pretty panels. As of remote-tech, I don't think it does anything to interfere with key bindings. The only thing is that in general, probe cores use more electricity. Additionally, they are completely dead if they run out. The only way to recover is to go send up a ship with a Kerbal to extend the panels, or do whatever needs to be done.