Ruedii

Yes, it would be nice for the launcher not to require running as administrator other than to "fix permissions." There should be a fix permission routine to deal with this, which will automatically be run (prompting for administrator authority to do so) if it runs into permissions issues. This routine should do the following: 1. Change the Saves directory structure to be writable by all non-guest users. 2. Change the main settings file to be writable by all non-guest users. 3. Change the entire KSP directory tree to be owned by the current user. 4. Change the entire KSP directory tree to allow deletion and overwrite by the current user. 5. Change all directories (not files) in the KSP directory tree to be writable by the current user. This should allow the update routine to function without administrator permission, as well as allow all game functions to run without administrator permission. For the sake of allowing flexibility, especially with mods which use settings files stored in .\GameData, write access should not be taken away during this process, only given.

Just curious, is there a way you could make animated cargo bay doors on the HX modules?

You can also stick a probe core on the inside of one of the HX Sized hollow parts. If you are building a cargo bay into your part, a good place to put it is between the in-cargo-bay docking port and the wall. I understand building it into an SAS under the thought that the vast majority of it is the SAS wheel, but I agree that there is no reason to do this.

Try changing the user that owns the KSP install. That way the launcher won't need administrative privileges. Also make sure that the "run as administrator" flag isn't set on any of the binaries (Launcher or the main binary.) Obviously, if the launcher is set to run as administrator, because your install is administrator, any child program of the launcher will be run as administrator as well.

I've noticed the big bottleneck on KSP is between the CPU and the RAM. I see no difference in lag between running my CPU at 2.5Ghz and it's peak 3.6Ghz speed. Unity couldn't optimize data usage if it's life depended on it, and this results in extreme slow down when the CPU is trying to process the data. Add the lack of threading on to this, and you've got a disaster. Your best bet if you are getting more RAM is to get faster RAM. Remember, higher Mhz speed does not mean faster RAM, faster timings means faster RAM. Currently the optimal speed for DDR3 memory is between PC1333, and PC1866 configurations, usually getting the best timings around PC1600. You should be able to get high-grade low-latency memory at 10-11ns stock, and down to 8-9ns when overclocked. Make sure to test memory on MemTest86+ when overclocking memory. Just because it boots, doesn't mean it is not getting errors, and bad things happen from RAM errors, such as crashing, or even data corruption.

Yeah, ext4 is the file-system type. Also, I see you are running the steam version (this could have been helpful information).

There is one functionality that I wanted to see added to the antennas, and I think it could be implemented in this mod. Is there a way to prevent the antennas from retracting when they are done transmitting. (Basically "lock" them extended.) This is nice for making spacecraft with both form and function. It would also be nice, if you could also prevent an antenna from being used, so it would use a different antenna by default (or complain about no functioning com devices on your ship if you have no other working antenna.)

Really awesome design, but could you make a version with more stock-like colors and textures. (Textures are already quite stock-like, but the colors aren't.)

I had noticed some issues with the costs being a little high compared to equivalent stock parts. Is this intentional? If so, why?

I'm really looking forward to this release.

I hate to plus one, but I'd like to see airplane/space-plane (plane would be fine) added as well. Additionally having unmanned planes separate might be good as well. I also like the idea of being able to mod vessel classifications.

I recommend doing polar orbits a few degrees off of 90 degrees anyway. Running them straight over the pole creates an inefficiency in scanning. If you are using something like ScanSat, you want the orbit inclination to be a little over 90-(FOV/2)

I'm certainly thinking there should be a threshold of gravitational forces below which they shouldn't count. I don't think the planets pass close enough to each other to create enough force to pass this threshold. In fact, I don't think the pull of Minmus even passes this threshold when you are in orbit of the Mun. In my opinion, each object should have a range of gravity but those ranges should overlap. I would generally also put a cap on even considering the possibility of 8 objects of influence at a time, since it's very unlikely that you would enter the field of 8 objects, and putting a cap on it would greatly simplify things.

Additional good missions include: Probe impacting, Asteroid retrieval to ground. (This probably shouldn't be done for planets without an atmosphere.) Retrieving a particular piece of debris (either one you left in space or one that is spawned in space.) For the debris retrieval here are some good examples of text. you should be able to see where you can convert what items into random phrases. 1. Shortly after you launched Elloo Explorer 13, one of our engineers, Dimble Kerman, realized he had dropped the keys to his wife's rocket scooter in an access panel to a part we repaired for you. Now he needs the keys back before his wife discovers that he borrowed her scooter without asking. We believe it is in a Toroidal Aerospike engine on one of the pieces of debris from the flight. We are greatly concerned for our coworker's ability to go out to the next fireworks show, so in return we began to wonder how to solve this issue. After careful consideration we were stumped and decided to ask someone else. That's where you come in. 2. About the time you entered orbit of Duna with Red Rover, we discovered an unusual weight discrepancy in the telemetry results for the most recent staging. It turns out our janitor, Pantoro Kerbin had accidentally switched a stack of paper wrappings with his Master's thesis on rocket explosions in low gravity environments. Fortunately for Pantoro, the dean of his college was injured in a rocket-assisted para-gliding accident, and was given 4 extra years to get his paper ready. Unfortunately, the section used to line the Rockomax Jumbo-64 Fuel Tank, seemed to contain vital research information that cannot be replicated. We were initially unsure if it was worth the effort, but Pantoro has reassured us that the data included some nice pictures, not just confusing numbers. With the distance to Duna we thought this undertaking should be refereed to experts, and in the absence of that we chose to just call you. So, this puts it in your hands.

I was just thinking about this more, and it would be cool if the "transmit" option on any antenna brought up a "Transmit" menu where you could select each piece of data, or data that can be immediately gathered (e.g. crew report or temperature scan.) If you have a processing lab on your ship, it should have a box to process the data first. (Otherwise it should be greyed out.) Additionally, it should have a slider for "packet burst size" that is limited by the total electrical capacity of your ship. This would prevent you from losing science points to rounding errors when transmitted in single packet bursts due to low battery. This slider should also be accessible from the right click menu as well.

The simplest mods are modulemanager config file mods. Examples of what you can do with these is create a 2.5m version and a 0.625m version of a 1.25m part. You of course need to learn how to calculate out appropraitely balanced values for everything, but it works pretty well.

The other thought is that if there is a precision issue, you should get 100% when the data is processed in the mobile science lab. In fact, changing the amount of improvement for science lab processing to be different based on the type of item, would be a very nice additional feature. Also, it would be nice if the science lab could produce "Preliminary data" without destroying a sample, hence allowing you to send the sample back to Kerbin for the rest of the science points. Furthermore, it would be really great if the science lab could allow "packaging" of samples and data so more can be shipped in a single capsule.

I definitely like the idea of having reputation for each Kerbal as well as the whole space program. As of nuclear engines only being available when you have high reputation, that just doesn't match up to the reckless nature of Kerbals in my opinion. As much as that would apply on earth, this is Kerbin, where space travel doesn't take any safety precautions.

Is there a way we could get this updated to function as a drawer in the standard KSP toolbar that was released in 0.24.x (Obviously this could require some work and should probably wait until the next major release, as not to interfere with bug-fixes.)

I would say the original Kracken is 99.99% fixed. It only happens in extreme situations. It also sometimes likes to play with ships in the distance, sending them spinning or smashing crashed-landed fuel tanks against the planet's surface. I think this could be fixed with a second pass of krackenbane that puts each major object that is more than 10m from any other object on it's own physics layer, with it's own kerckenbane reference. Furthermore, by placing each non-associating object on it's own physics layer with it's own krackenbane base reference, the maximum distance for physics simulation could be greatly increased, allowing players to finally have their released stages properly parachute to the surface.

I personally prefer throwing all the mod data into an external heap, and only pulling it into the main memory when needed. This allows the external heap to be in a separate segment of memory, beyond the 4GB barrier of the game, or even swapped out to disk. Win32 has a nasty problem with such heaps not being allowed to execute code, even that from Mono or .Net, so there may be some issues to work through there. However, it's probably best to keep all executable code in the same base segment. Furthermore, by using page-flipping (where you change the physical address of a virtual page) and duplicate mapping (where you map in-memory pages to both the heap and the game page) you could really boost loading speeds of these segments over doing page-copies, while still allowing the OS to swap out the heap to virtual memory. Finally, using one heap for texture memory, and one heap for everything else, would dramatically improve video performance by allowing and encouraging the video driver to map all the texture memory to single block of physical memory, if that is at all possible. The addressing of texture memory could also be improved with the use of large page address mode, if it is available. (Linux, OS X and Windows allow this, however Windows can be difficult to configure non-administrator programs to allow this, and some Linux distros don't set this up by default to be accessible from desktop users, I am not sure of the OS X technicalities on this other than the fact that Apple says it's supported.)

We need something like a Kuiper belt with at least one binary dwarf planetoid system like Pluto and Charon. The orbit of this binary dwarf system should be around where Elloo's orbit is now, with at least two other Kuiper Belt Dwarf Planets in resonant orbits, just like Earth's Kuiper Belt. I'd also like to see another set of dwarf planets with even more elongated orbits, similar to that of Eris on Earth. Additionally, I'd like to see one or more additional tiny, abnormal shaped, moons around Duna. These obviously shouldn't be tidally locked the way Dres is. Finally, I would like to see small rocks in the rings of some of the gas giants. They should be engulfed in a dusty fog, making them hard to see, but if you grab them, you should be able to drag them wherever you like.

The SAS isn't that bad. However, it would be nice to have a "Trajectory lock" mode as well as a "Dampening" mode, and a way to switch between them on your active command module. In fact it would be nice to have the following: Trajectory Lock Angle Lock Dampen As well as relative modes of: Surface Surface Trajectory Orbit Orbit Trajectory Craft (A.K.A. Static) This basically would make SAS be a basic "hold" autopilot system with several modes. It might be a good idea to have Trajectory lock, and every relative mode (except craft/static) require at least one ASAS unit, while when only having SAS units and/or the in-command-module SAS you could just switch between Angle-Lock and Dampen mode. Exceptions could be made for some of the more advanced items (like the large probe cores, the airplane cockpits and the cupola unit.) This would give the ASAS more advantages over the SAS.

I wonder if KSP is transitioning to Unity 5.x anytime soon? I know Unity 5.x isn't even out, but it would be nice to know. So long as Unity doesn't support a Mac 64bit build, I doubt it will be supported by KSP. (Too buggy, like the Win64 build.) However, I would like the see the results of the hack mentioned above. As of breaking the 4GB barrier on 32bit processes (multi-pages), due to the way Unity is coded, placing data and code together, it makes this impossible to do on Windows. Hence, this would reduce the benefit for doing this on Linux and Mac. The only items it could be considered worth doing this on is specifically textures, shaders and models. Squad may want to consider this, as it could also speed things up by moving system-side textures, shaders and models into their own memory segment, due to not having a smaller segment used exclusively for things the video card has to interact with, thus speeding up the ability of the video card to move this information into it's local peripheral-side memory. This goes beyond the ability to place it on a different memory segment, hence allowing it to have it's own 4GB (still a cap but 4GB for just textures is a lot better, and could allow keeping all of the planet texture data in memory, or at least virtual memory depending on if the user has enough physical memory.)

You must have a serious budgeting issue if you can't manage a surplus. A couple tricks: Place a space station in orbit of every planetoid or moon you have "explored" in order to retrieve science on demand. Believe it or not a trivial "cool video of an experiment" is a common thing NASA is paid to do, right up there with interviews on the Space Station. ("Perform interview" should probably should be added somehow in future versions. Might be a good way to require the higher-end antennas.) For a cool video they just have the astronauts repeat one of their favorite goof-off experiments like lighting a candle in space or playing with their food in Zero-G. The public really eats those up (pardon the pun.) The idea is that this sort of thing helps build public interest in space travel, hence improving their chances of getting to do real science.