Ruedii

I'd need to see the mount of the wheel to see what's going on.

Thanks for the great plugin. I hope you get it working with other gimble plugins, as I love Tweakable Gimble, but I'd rather have this. Finally, I don't have to line my engines perfectly center, and my plane will still work! Finally, I can make more conventional jet designs! BTW, could you make an even better version that adds drag compensation? (You'd have to use a different module version for FAR/NEAR than stock for this, but it's doable.) For now SAS should work for most conventional designs on this.

I have a list of nice additions that could make it really good design: Throttle controlled monoprop thrusters for helping reentry (shares with translate forward ports.) Additional battery life and monoprop compared to stock pod. Built in heat shielding for DRE users (I'm not one of them, but I know that there are plenty of DRE users that would like the feature.) Alternate IVA layout for RasterProp users. As of providing landing engines, it would be best to add a paired service module that would contain more standard dual-fuel engines, fuel, additional monoprop, additional battery life and a set of integrated RCS thrusters.

Double check that you are installing correctly. The GameData folder in the pack is improperly capitalized as "Gamedata" which causes problems on case sensitive systems (Mac, Linux and some non-standard Windows setups.) Just move the contests of Gamedata to GameData and you should be good.

I've lately found that making the first stage solid rockets is often the most cost effective. Can you modify the script to handle that (with both types of boosters, of course.)

It seems you have the "GameData" directory capitalized wrong. This will cause problems for Mac and Linux users, and possibly cause problems for future versions of Windows (according to Microsoft for the past 14 years, hasn't happened yet.) One question too: Which parts require the CRP/ORSX plugins? I'm removing the DERP pod, so do I still need those. I'm just trying to keep my modlist lean.

We all love the mod makers, even if we occasionally express it wrong and misdirect our frustrations about upgrade incompatibilities. I appologize if I'm ever rude to mod makers in my manner of suggesting an update, and stress that it's not intentional, and cannot repeat enough that I am eternally grateful to the mod makers!

I know that B9 Aerospace contains an updated version of the dll. Is there a way you can get an updated version up soon? It just needs it's version file updated. (I presume 0.25.* should work)

I'm glad to see you trying to work out the win64 bugs. I'd advise you to try to coordinate with the plugin authors best you can, keep your forks up to date, and submit pull requests with patches for the ultra-low-priority "support win64" bug for each win64 bug you find. I personally recommend you currently set Win64 as a separate buildarch for some of the more hackish workarounds. Any workaround that actually benefits other platforms (e.g. abstracting the memory location type to allow it to be 64bit or 32bit without affecting the plugin), such as x86-64 Linux, should probably be submitted for the main tree. However, other workarounds will have negative impact, so I would use compiler preprocessor scripts to enable them for now until better solutions can be found, either way they probably won't make it into the main tree for a while, because they might not be necessary in future versions of KSP. All in all, I strongly support what you are trying to do, and I understand if you couldn't get a hold of the plugin authors as fast as you needed to for making this available.

There is Ambient Light Level, which can allow you to fine-tune the ambient light level. This is probably your best option if you want very low ambient light, but not none.

In my opinion, when forking a project you should attempt to contact the owner about how to mitigate confusion and compatability issues. This is a general sign of respect in the Open Source community. While it is not necessary, it falls under the "it's a good idea" matter. This of course, does not apply to a personal fork. If someone knows enough to track down your personal fork on GitHub, they should also be smart enough not to bug the original author about bugs relating to the fork. However, if you actively publish your fork, such as on a forum, it is generally respectful to ask what you need to do to prevent issues. Often the author is grateful that you are willing to take on certain bugs or features that they aren't, so long as you are willing to play nice. This comes under no obligation, so third parties shouldn't complain unless the person is directly violating the license, for instance by not releasing their own code, or claiming it is the original. However, as I repeated many times, it's the respectful thing to do.

I thought it would be nice to have 0.3125 m parts as well. This would be for both aircraft drones, and space probes.

There is certainly a limitation on how big you can make solar panels. If you are willing to use non-fixed solar panels, and build a rig to hold them elevated, there are some great giant solar panels in Near Future Solar. Of course if you are making a giant base over the entire surface of Gilly, you only really need two solar farms, one on each side, to provide a constant flow of electricity. Three of four solar farms may be more ideal, though. The absolute most power you need is the amount necessary to turn all on the lights on and be running your science lab(s) and transmitter(s) beyond that is just waste. You probably will be wanting to use Kerbal Attachment System (KAS) to attach the various parts of the base together. However, I think you may hit the limits of KSP preventing you from covering the entire surface of Gilly. There is a mod to expand that limit, but at the cost of performance and tempting the Kracken.

I'm running into a weird issue on the archive. Take a look here: Might I recommend using 7zip to create your archives. It tends to have the best compression of any archiver, and makes far more reliable archives. For Linux there is a command line version used by most of the current archive management utilities, and on Windows and Mac they ship a full GUI.

I think this could (mostly) be fixed by having each wing type be an ever so slightly different thicknesses.

Two things: 1. Angle of attack has greater impact on speed than anything else: simply turn the engines down/off and slowly pull up your angle of attack until you are going slowly on your glide slope. Just be careful not to stall. 2. Use pairs of wheels for your rear gear: If you place 2 wheels next to each other, where you would normally place each rear landing gear, they can take a lot more abuse. 3. Use flaps. This is self explanatory. If you want a plane that normally can't fly slow to fly slow for landing, add flap functionality! 4. Learn to flair: Flaring to the point of a partial stall right before touchdown can really slow you down. 5. If this isn't obvious, you can always use parachutes to assist in landing. Deploy them right before touchdown and you can make your landings much faster without wrecking, or make your plane land with parachutes. It's your choice. Don't say it's cheating to make planes land with parachutes, NASA and the Military do that all the time. Most drones land using parachutes, because it's simply easier. The only reason most radio control planes use runway landings is because it's more fun.

I hate to state the obvious when everyone else recommends a mod: To exclude engines from the center of thrust just use the tweekables to turn their thrust to zero.

There are two ways to reduce lander tipping. I recommend using both: 1. Make your lander wider: A lander that has a wider base is going to have the center of gravity over the base for a wider angle. A good way to do this is to attach a side stage that is discarded on launch. 2. Land vertically: I can't stress this enough. Sideways momentum will tip your lander. Seriously, your lander is not an airplane, and unless it has wheels pointed in the direction of horizontal momentum, landing sideways will make it tip! 3. You can always use wheels: Wheels aren't just for space planes and rovers, and making your lander double as a rover is great. Rover wheels do absorb a lot of shock, and if you don't mind repairing them they tolerate even more shock! Keep your brakes off and you can roll on landing, and this will allow you to have more horizontal velocity without tipping!

Seriously is this a joke? First thing, by the time you are in orbit you should be down to a small high-efficiency rocket. Remember, you can build stuff in space to make bigger ships. However, sometimes smaller is better. You should bring the minimum you need with you on interplanetary missions. You also should refuel larger ships in orbit, so you can bring up the fuel separately on a specialty ship. Smaller is better if you want cost-effective rockets. I cannot stress this enough. Send the smallest ship that will complete the mission. As of how to get more bang for your buck (hopefully in the figurative sense) I have a few tips. I highly recommend use of lots of solid boosters in initial takeoff, as even without recovering them they are far more cost-effective. This is not to mention the punch they pack. The LFBx2 is also a very nice way to asparagus in more takeoff power. Ideally you want to break atmosphere as fast as possible without exceeding the terminal velocity for your craft. This usually means having a thrust to weight ration of 2-3. You may want to configure your ship that you have to initially throttle down a little to maintain this, so you can punch it once in the upper atmosphere. Remember, you can refuel your ship once it's in orbit if you are launching bigger interplanetary vessels. This is important, because there is a limit to the maximum cost-effective weight, and using your final stage tanks twice can really save on weight. Finally, while making massive launch platforms SSTO is a real pain, it's quite easy to send up fuel in an SSTO or an SSTO with boosters. This can save you LOTS of money. You already discovered that fins aren't necessary, so that's good. Fins are only necessary if you have no other means of control. Gimbling with works fine so long as you turn on SAS and don't do anything stupid. Fins are really just added drag and weight after that.

Don't forget, use more landing gear. Many of my larger planes have at least 6 landing gear (3 pairs), if not 10 (5 pairs). This also makes landings much easier. Unfortunately, more landing gear means more friction on the runway, but we all know how to work around that. (Moar engines!)

Does it have built in Kerbal Engineer and Mechjeb support or do we have to mod the config files for that? Also, it would be nice to have it a little smaller. I know lots of people like the parts bigger so they can grab them easily in the VAB, but I prefer them smaller.

Android is a really great platform for phones, tablets and other "smart devices." (Smart device is marketing lingo for a device with basic computing functionality. It comes from the term "Smart Terminal.") My favorite Android products are the Nexus lines because they are designed to be able to be unlocked easily, and updates are released for far longer.

It would be nice if you could actually modify the popup to have a "Don't show again for these mods" checkbox, and it won't show again unless a new version-mismatched mod is installed.

The parts look awesome, but the cockpit really could use bigger windows. Why should you be stuck looking out such a tiny window Honestly, a cockpit of that size should hold two or three Kerbals with two of them sitting next to each other.

Is there a way you could make this do things on timers or triggers configured by the config file. For instance causing something to occur automatically every 5 minutes of gameplay. Another idea is one that can attach a behavior of a part to any routine in the game, for instance a light that changes color when the craft changes state to touched down. To be able to do this from config files would be an incredibly powerful tool.