TheXRuler

I don't know a solution that will work for sure, but you could try to find out how squad did it with the asteroids. Just go to gamedata --> nasa mission --> parts --> potatoroid. They are treated by the game as ship parts, are however not listed in the VAB/SPH. Edit: damn spelling

Coudl someone give me an estimate of memory usage?

I second this. I mean SQUAD has every right to do what they want with their parts and all but tweakables would really usefull. And I'm sure one of the mod developers would be ahppy to help out making the code, even maintain it.

Cool could you tell me what exactly you did? I seem to be a little too dense to understand the process of adding exceptions for ATM.

Not sure :/ I tried, but I have so much pratice docking stuff that I just let it go, if you do find a fix let me know, it was a really nice feature, especially the precision readouts. - - - Updated - - - Might be worth asking in either the the lazor system thread or the ATM thread.

Sorry to hear your having this issue. It's weird, on of the few things I have not heard of before Oo While I am afraid I cannot help you I'm reasonably sure that anyone capable of helping you will need your output.log from when this happens. Try reproducing it and then get the log file, upload it somewhere and then link it here. Originally posted by Claw: When KSP crashes it will general a folder with files with details surrounding the crash. Usually a window will pop up ingame asking you to send this information to the developers, along with the name of the folder. You can find this folder in the KSP install directory. If KSP doesn't crash, start KSP and cause the problem. Quit KSP and find the output_log.txt (not the KSP.log) at the location below: Windows: KSP_win\KSP_Data\output_log.txt -OR- KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used) - In case you installed KSP into a Windows protected directory (C:\Users, C:\Program Files or C:\Windows\ and their subfolders) the output log file may be stored in the folder called C:\Users\[username]\Appdata, this folder is usually hidden so you should enable the view hidden folders option (more information). Note that for the demo you should find the output_log.txt file located in the KSP_Data folder. - Steam users should right click KSP in Steam, click on Properties, then in the Properties box, click Local Files, then Browse Local Files. Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: The log is written to /home/user/.config/unity3d/Squad/Kerbal Space Program/Player.log You can upload these files to any file sharing site (such as Dropbox, Mediafire or File2web). These sites will give you a link you can include in your posts to share your files. The output and crash logs are useful because they help us understand exactly what you were doing when the issue happened by providing a "play-by-play reenactment" (in text form) of your KSP session. Anything out of the ordinary will often show up in the log files, and it gives us a good idea of where to start looking for solutions.

The mod you are looking for is Laz0r Docking Cam. I used to use this mod, however ATM broke it for me.

Always happy to help Also, this is one of the things that is used for gravity assists. If you pass before the body it will decelerate you, if you pass behind it will accelarate you. Similarily if you pass above or below it will change your inclination. Of course you might know all this, I just thought it's kinda relevant since it ties into your question.

If I understand you correctly then you are right. If you overshoot the transfer a little your trajectory might go through the body and out the other side. This will put you on either a pro or a retrograde orbit. I reccommend just setting up a regular LKO and then hohmann transfer to the mun. As you edit the manouvre no you will notice that you can either come in on the Kerbin side of the mun, or on the "outer side". This is what makes the difference.

KSP uses patched conics to project future trajetories and encounters. I don't know the math or whatever behind it but one problem with this system is that the further you go into the future, the less precise it becomes. In the settings.cfg file in your ksp root directory there are two lines reading Conic_Patch_Draw_Mode and Conic_Patch_Limit. If you wish to "see further into the future you iwll have to play around with these settings. To edit your settings.cfg simply open the file in notepad or notepad ++. The conic patch limit determines how many SOI changes will be displayed, the draw mode changes how they are drawn, just experiment with it a little.

The problem sounds like a stock KSP problem. In stock chutes are cut away as soon as you touch the ground. To prevent this happening you would have to either deploy the chutes while flaring (pull up very hard just before touchdown so that the increased angle of attack let's you glide for a longer period while the chutes are braking you. However this generally leads to disaster in my experience so I'd reccommend using RATOL style solid rockets (sepatrons can do the job nicely) or get the Real Chutes Mod, this adds chutes which can fullfill the role you need (I have been told, I do not use the mod myself. Edit: Note to self: Read the second page before making an ass out of yourself

I forgot to mention in my first post, the main reason for having docking tugs is when you are using a cargo SSTO to get things to orbit, since it is possible, but rather impractical, very slow and maddeningly fiddly to try docking a 330 ton spaceplane with a 60 ton payload. Also the wings/nose/tailfinns tend to get in the way and since your the payload is inside the cargo bay it would be necessary to devise some system of getting the payload out of the cargo bay without decoupling it from the spaceplane, ince sticking monoprop tanks, a probe and RCS thrusters on every payload means wasted payload capacity and more parts (at least 10 per payload, not counting batteries and solar panels). In general a disposable system is perfectly fine. Also, don't use monoprop to go interplanetary, it is horiffically inefficient (low ISP). Use it to build multiple launch interplanetary ships if anything. Edit: I just realized you probably already know this, since you have been to most bodies.

What I do to circumvent the issue of balance is to design the payload so that the CoM is roughly in the middle, then attach one tug to each end. That way you have equal RCS force on both ends and balance is no longer an issue. Barring that possibility I will pump fuel from one tug to the other in an attempt to better compensate for the unbalanced payload (remember to balance out fuel levels before disconnecting the tugs!!!). Another possibility is to disable one set of thrusters on one of the tugs (the one further away from the CoM) and balance RCS force that way. Since each tug has not only eight RSC thrusters but also a reaction wheel the control authority is usually enough to compensate a slightly offset CoM, providing you use precision controls for translation (enabled by pressing caps lock).

Generally what I do is build my launcher with a returnable and recoverable second stage (use chutes and landing legs) bring the payload close to the station and then dock it with my docking tugs, pictures coming up in a second. Sorry it took so long I'm not at my main rig so loading KSP took... "a while" -.- I used to do things the same way as you do, however when I engaged in the Grand Orbital Space Station Challenge I faced a completely new problem. Launch weight was going to be subtracted from the score, so basically using a spaceplane was the way to go, since recovered weight would be subtracted from the original launch weight. So I came up with a new way to do things, I built docking tugs, solely for the purpose of docking the various modules to the station. Anyways this is what my docking tugs look like. I had two main criteria for them to fullfill. 1. Longterm autonomous operation (solar panels, batteries, a probe core [hidden inside the 1.25m -> 2.5m Adapter] and tons of RCS to keep the number of refueling runs to a minimum. 2. Low part count. I am using them to build a truly huge station and can't afford to waste any parts. Kept it down to 16 apiece The tugs each hold 2400 units of monoprop and have a lot of torque due to the large SAS module. I also use two of them together, since many of my payloads are very long and very heavy making one tug on one end completely impractical. I dock one tug to each side and then monouvre the payload into position in front of the designated docking port, kill all relative velocity and then slide the tug which is in the way out of the way and just push forward gently :3

Still nice to have my statements backed up by some good sources

First of all, welcome to the forums. Second your information on the Kaspian Sea Monster is thus far correct (according to my knowledge). I find it to be a very impressive vehicle Thirdly, this effect is definetly not modeled in stock KSP. And as far as I know neither KSP 1.0, nor FAR/NEAR cover this either.

@streetwind Oh, colour me surprised. Well I guess we never stop learning do we? Thanks for clearing that up. It makes sense I guess, I often did wonder wether there should not be a more efficient way of landing by removing the need to thrust upward to keep from getting smeared all over the surface. Could it be agreed then that doing it that way is simply the safest way to land?

Basically the flatter the trajetory the better, as going high means fighting gravity, wich means gravity losses. By going low and fast you will get a sub orbital trajectory which means your speed will fight gravity for you (very roughly explained). Landing from the lowest possible orbit is best, for multiple reasons, including the oberth effect and gravity losses. Basically the lower you are when you brake, the smaller the time gravity has to accellerate you wich means less gravity losses. The best way to land is using the method detailed in this video, it is more efficient than putting your Pe in the body and then suicide burning. If you do not like this method, then one long suicide burn is better. I have a Munar science vehicle wich uses kethane to refuel and then hops around the Mun on dual LV-N's, it has ~5600 m/s dV so I don't have to worry to much about efficiency, but I pride myself in being as efficient as I am capable of, so I have some experience with sub orbital hops.

Raise your periapsis to a few kilometers and Land using technique shown in the attached video, it is by far the easiest (won't smash you into the ground) and the most efficient also. Edit: No need to have a circular orbit beforehand, except that it makes things a little easier.

Sadly I don't have a lot of time on my hands atm, however I will just quote myself and link you to [thread=114501]this Thread[/thread]. The biggest problem with D-Class Potatoes is that they are very heavy, meaning they will reduce a ship with say 4000 m/s dV to a few hundred at best.

If you are looking for a stock option, struts are pretty much the only way to go. If however you are prepared to use mods you might want to look into either the classic [thread=29862]Procedural Wings Mod[/thread] or the imho far superior and more customizable [thread=104966]Procedural Wing Mod by bac9[/thread]. For larger SSTO's I also strongly recommend using FAR, since it vastly improves on Stock Aerodynamics.

Editing your craft after launch is a kind of cheating If you want to do it legitly you will have to send a rescue mission, depends on your dedication I guess. Oh, I'm not sure but I think ladders can be moved from IVA using [thread=92514]Kerbal Attachment System[/thread]. In stock, as in real life, there is no way to edit your vessel once you have launched. You could of course try launching very gently and hope he clings on. Tipp: Dunno if you did this, but it is possible to extend ladders in the VAB, maybe preventing this problem in the future.

If you're okay with craft editing, why not just use LALT+F12 to open the debug menu and turn off gravity for a few seconds? I would personally not recommend craft editing. Save file editing in and of itself is risky enough. Craft editing however has always lead to "rapid unplanned disassembly" for me. If you really want to try I suggest giving your ship a unique name (otherwise it can be hard to find in the save fail) then quicksave and switch to desktop. Find your KSP directory and BACKUP YOUR SAVE FOLDER. I cannot emphasize this enough as lack of doing so has ruined multiple savegames for me. Now, goto gamedata-->Squad-->Parts and then look for the ladder since you need to know the name by wich the game references it. When you have that, open your quicksave file and search for the unique name. Then search for the ladder on that craft and change one of the positional values. Save changes and go back to KSP, reload and wonder why things are, or are not, exploding. Alternatively you could use a method I came up to help someone else with, detailed [thread=115059]in this thread[/thread]. Hope I could help, all the best -TXR

Sorry Alchemist, the post at the top of the previous page had led me to believe that xannari was working with the save file atm. I will gladly take my turn if it's not to late. Also I was unsure of the permitted duration so I just pu a question mark behind the finish time. I think the Jool Club could be rather interesting, however I am unsure as to wether I will be able to participate this turn. -TXR

If you use atm and use KSP settings to only load half res textures you can easily get a modcount akin to what I have (click the Spoiler). Although then of course loading the game can become quite a strain ^^