Ruedii

Anyone tested this on 0.24? It worked on 0.23.5 without any changes? However, it may need price rebalancing now.

Could we get linkified mod names in this thread?

I personally think that the better aerodynamics in FAR should be stock. When this is done, we need some sort of fairings and/or cargo bays in stock. Other things that should be stock are the "grab" and "attach" functions of KAS. (I don't think the winches are necessarily needed.) Obviously some of the more tweakable mods should have their tweakable options added to stock. We always can use larger rocket parts, especially now that the rubber-rocket issue has been tamed. We also could use a bigger selection of probe engines. This is similar to the ones in RLA Stockalike. We also need bigger wings, control fins and jet engines. Also, high-bypass turbofan engines with lower fuel usage in exchange for requiring much more intake air. The current turbofan should be listed as a high-compression low-bypass turbofan, since it behaves like one anyway. As of parts that I don't know if any mods have not been built yet, realistic nuclear engines would be nice (ones that JUST use liquid fuel.)

You could simply debind the keys for loading quicksaves. Sure, it would be nice if once Squad has completely slain the Space Kracken if they could enable this from start to have some sort of pretty emblem on your safe file. Otherwise, I really don't see the point.

Personally I would like to see an extended area with "shortcut" physics that only simulate the center of mass and direction the item is facing. The other thing is if each craft is treated as it's own "physics layer" it would be far easier to simulate multiple craft for a longer distance, but disregard debris outside that range if physics start to slow down.

I definately would like such a thing "eventually" but I doubt it's that much of a priority. It obviously shouldn't be put in on career mode until you have gotten quite far.

I suspect that currently the issue is that they have a very solid roadmap for this part of the development, and that is why they haven't been taking too many community suggestions. They are currently so head-on focused on getting that carreer mode finished, they are neglecting anything else that doesn't involve getting a bunch of promotion for the game. I honestly don't blame them. Development goes in cycles like these, you have times you focus on a specific set of features, and then times you flush out the rest of the features. These are usually implemented in ticks and tocks, alternating, but I understand that Squad wanted to do a whole bunch of one type of release here so other than the big NASA pack release, that showed promise for adding to the future mission options, they decided to do a bunch of core-feature centric releases. As of when they get back to flushing things out I wish they could put in some more larger parts. I'd also like to see all the parts rebalanced and restyled soon to take advantage of the features of the latest unity release. As of some technical features, I'd like to see more advanced handling of terrains to take advantage of the features in modern computers. KSP is still using a basic height map for terrains, and loading them in big manually-managed blocks. By using a hybrid method with height maps, bump maps and parallax maps all in different LODs loaded via shaders in sparse texture mode, they could have it nearly completely handled GPU side. I'd also like to see better handling of texture memory. Additionally, I'd like to see all the parts made lower polygon count with nice parallax maps and normal maps to make up the difference. This would provide better performance on newer systems. After all, nobody is going to run KSP on a OpenGL 2.x system or a Direct X 8 system anymore unless they are turning down the graphic settings all the way, in which case it won't look much worse. As of gameplay, I'd like to see more planets have Biomes and more Biomes on the planets that already have them. I'd really like to see "Island" "Plateau" "Highland Plains" "Highland Hills" "Grassland Plains" and "Grassland Hills" on Kerbin, As well as things like "Beaches" and "Shoreline Cliffs" instead of just "Shores" and "Oceans" "Lakes" and "Rivers" instead of just "Water." There should probably also be a set of "wetlands" or "swamps" (which could have a thin layer of water over them.) Plus there are "Desert Plains" "Desert Dunes" and "Desert Hills." Particularly nice would be if many of the easter eggs had their own special biome in the immediate area. Using a 8bit palleted bitmap as a specifier, the biome system can use 256 different biomes per a planet.

I'm thinking I don't want weapons, but the devs already agree on that. There is room for that in mods. I personally don't want to have to worry about life support. Let's just presume that a sufficient life support system is built into the pod that will last nearly forever.

As an additional note, "binding" objects to each other unless the forces between them exceed a certain point would also improve the performance and reduce the kracken.

Object consolidation would greately reduce the kracken, but on most physics engines, nesting the point of origin would actually increase the kracken not decrease it, by creating two rounding errors instead of one, even if those two rounding errors are smaller. However, when you have two ships in the physics, treating them as separate physics layers until they are close enough to colide, would in fact reduce the kracken.

I would think that "free" should keep a fixed position for up and down for your kerbal. Orbit should be relative to your craft's orbit, and chase should move with the camera, sort of like a platformer. That's just my thought anyway.

I was thinking something along the same lines. It really would be cool to add a museum of recovered missions, along with mission stats for each one. This should obviously be a building in the KSC complex, as putting it in the outer complex, while really cool, would likely put a little too much load on people's computers. This could be done with a simple simplified snapshot model. edit: As an after thought, this shouldn't exactly be high priority. However, as a vanity feature, this would be a real plus.

Technically, you could mark retirement as an "assignment" in the KSP system. They would be assigned to a non-existent craft called "retirement" The other option is to mark them as "lost" because it is the "death" of their career. If KSP has a line for cause of death, just list "retired" and you can use it for a flag so you can initiate a rehire option.

Mind if I plus one that idea for the discription death of kerbals along with some additional tips: Also, stating where it happened and on what ship. (For instance, "lost in space on Deep Space one on escape velocity from the sun," "lost in collision with Mun pm Munar 1 Lander in the Mun's Highlands" or "lost in in collision on Kerbal Space Station Service Module 13 with Kerbal Fueling Station") You should also see about creating an object tree with information about all the kerbal's achievements so other mods can integrate.

NeatCrown sounds like possible out of program/data memory during loading (as opposed to texture memory). However, if you haven't, test in sandbox mode, in case some of those mods are not compatable with carreer mode, or require a particular part not available yet in a carreer mode game. First back up the saves you value (always do this, and you don't have to bother with the saves you don't value.) Next, download all the latest versions of all your mods. This will reduce any issues. Now, try to install mods one at a time. Start with Mechjeb and then toolbar, since Mechjeb is the one you are concerned about. Make sure to install the latest module manager when you encounter your first mod using it, and delete all older versions of module manager. Also, do not install versions of the toolbar api that ship with mods this causes version conflicts within the toolbar plugin. When you run into the problem again, remove the last mod, then install the Active Texture Management mod. (This will reduce the memory usage of texture intensive plugins) then reinstall the problem mod. If that works, continue reinstalling your mods. I repeat, back up your save before doing this, because if you accidentally load your game with a mod part missing, KSP will delete all active crafts that contain that part! So, if you care about the save file, back it up.

Is there a way that you could make a light version of KSC+ for those of us that don't want to install KerbTown or those of us who have too many mods installed, or whimpy computers that can't handle kerbtown? (I often have too many mods installed to load up Kerb Town, even if it's nothing to do with a crappy computer. I have 8GB of RAM and 1GB of Texture RAM)

I'm thinking that if the mechanism can be done in a manner that doesn't cause issues. Better isolation and abstraction sockets would be nice. They have almost no impact on newer versions of Unity. This would reduce issues with version compatability as well as reducing platform-specific bugs. Reporting problems with mods to the user with a popup and allowing the user to block future notices would be a nice feature. (Default notice should depend on mode. In strict mode, activated in the debug menu, the notice should trigger on the first non-fatal exception. In normal mode it should only be triggered on a string of 8 or more non-fatal exceptions or one fatal exception from the mod. This number, of course, doubles each time the notice is blocked.) Additionally on the topic of reducing impact of faults, in mods or otherwise, performance impact on logging repeat messages could be reduced by improved by combining repeat entries, options to select what to log (Fatal Errors, All Errors, Warnings, Debug or Trace) on each catigory of notice. Setting it to just log fatal errors could really improve performance while still providing the basic information needed to diagnose the problem. If you need more information about a problem, you can always increase it to warning or debug, depending on the issue. It is rare that you would need to set anything to trace, other than possibly VAB bugs. (Yeah we all know those!) Additionally, having an option to place a substantial (64KB-1MB) buffer the log file would allow you to reduce filesystem writes, while risking loss of log entries in the event of a crash. Such a buffer uses almost no memory and could greatly accelerate the game for normal play, and if you are trying to diagnose a crash, and aren't getting a full log, you should turn this off. Also I agree on the carreer mode. It's pretty good considering that it is incomplete. However, I look forward to having actual game assigned missions, instead of just trying to gather science.

I love the animated radial engines. Could you add an animated RCS port with 45 Degree thrust for radial and parallel to surface for forward backwards? This would make for a great arrangement for docking.

I understand the objections to Curses, and I understand there were plenty of problems with Kerbal Space Port For other hosting options, if your mods are open-source, there are plenty of sites that will host them for you. GIT-Hub is one of the best for such projects. I highly recommend it. A lot of mod developers are already using it. It's particularly good because it can provide diffs for changes in config files and such. The Interim B9 Aerospace project uses GIT-Hub as it's primary host right now, as does Procedural parts As of other sites that host projects, Google Code is also nice. While their Subversion interface isn't as nice, their Wiki and download interface is a little better.

I think a second smaller lab might be good for special science related to the mission system that will be set up later. It could be capable of this, as well as cleaning out experiments, but it's capability of processing experiments for transmission should be limited. (The best restriction could be on surface samples, because these can gain a lot of advantage by landing a ground base with a science module.)

When overclocking, make sure to use power-saving modes so that you aren't going into overclocked mode when idle. Modern processors have no performance penalty for doing this, and actually have performance gain because all computer components are cooler when you start actually using your processor. Also, while Kerbal Space Program is CPU intensive, it is actually more intensive on the CPU memory bus if your processor is over approximately 3.0Ghz, you are usually hitting this limitation, not the processor speed. You should overclock your memory timings and your in-CPU FSB speed to improve performance. (If you actually bothered to read AMD's overclock guide you would know this is probably a good idea to do first anyway.) If running at a lower core speed lets you use a higher FSB speed, go for it. That will actually be faster. I've actually boosted my L2 and L3 cache speed to over twice their stock speed by overclocking my CPU-side FSB. Finally, when overclocking memory, ALWAYS test it with MemTest86+ Just because it boots doesn't mean you aren't getting errors. Errors cause crashes. Also, remember, lower clock speed with faster timings is actually faster than higher clock speed with higher timings. Generally you can get about a 10% gain on timings by lowering the clock speed of your ram. Another 10% can be gotten by having a good motherboard. Don't over-voltage RAM without good RAM and a good motherboard. As of doing 64bit. The problem was that the 64bit version was very buggy until recently. It is still beta quality. This is the fault of Unity, not Squad. The Linux 64bit version is finally running well enough to be used full time. The Linux 64bit version has been included for some time, and works quite well.

If they want, I can test it on Wine. Wine's debugging system is downright awesome with full external call logging without even having to enter full debug mode. (Hence without interrupting the program.)

It would be a good improvement to do a multi-staged conversion of the clouds into a non-particle set: Really close: Particle grid. Close but not in the clouds: Terrain-like Height-Map Reasonable Distance: Parallax Map Further: Normal Map Even Further: Flat Generally I would recommend making sure you are a reasonable distance away before switching to parallax map. I would place this point around 43,000 because most people don't fly in that range for extended periods of time, thus you won't have z-fighting. The normal map change needs to be placed where there is no longer significant shift due to parallax mapping, and flat needs to be at minimum quality. I was thinking another texture enhancement technique that could be introduced would be to add parallax maps to the terrain at a distance to supplement for lower triangle map sizes. This could actually be used to dramatically speed things up by reducing triangle map detail in a lot of places. If you want, I can add these two suggestions over to GitHub. The second suggestion may work better on the Texture Compression mod, though.

Someone had mentioned a while back that there is a module manager file to add the ejection module to the command modules by default. Could someone provide a link to that?

Llorx, Mono is a cross-platform implementation of .Net. It's actually now quite superior to .Net although exhibits a few quirks on what bugs in code manifest into problems compared with .Net. It is used by the Unity game engine that KSP uses.