GarrettKajmowicz

Greetings! In a fit of stupidity, I accepted a contract which, among other things, requires taking pressure readings at the surface of Kerbin - over the ocean. In an attempt to do this in a resource-efficient manner, I have one of my non-space planes fly over the location and "bomb" it with an instrument package. The plane itself is fairly uninteresting, with a Mk2 cockpit and staffed with 2 kerbals, 1 of which is a pilot. The instrument package is an OKTO core with a barometer, Mk16 parachute, and a battery. They are attached together using a mini docking port on the plane as a retaining location. I have an action group set up which deploys the parachute and decouples the docking port. During my attempts, I'd fly over the location at ~700m. Once I enter the correct zone, I'd hit the action group, the probe would decouple with the parachute extended, and I'd put the plane into a gentle climb. Then I'd quicksave the game. If I kept focus on the plane, I can fly back, land, and recover without incident. However, I'm unable to switch to the probe (even through the tracking station) to finish that part of the contract. If I switch focus to the probe after detatching, the probe falls, gently lands in the ocean, and I'm able to grab the data I need. I can recover the probe. However, the tracking station doesn't show my plane. I can easily switch between the plane and the probe right up until the 2.5 km boundry is passed, at which point no luck. Is there any way to get both of these to persist?

KSP: 0.24.2 Linux 64-bit (32-bit also exhibits this issue) Problem: When I attempt to load a quicksave, my rovers will behave eratically. This usually comprises a rover exploding immediately, or being launched high into the air from which recovery is impossible, leading to explosions. Mods Installed: Toolbar-1.7.6 DistantObjectEnhancement-1.0.0.0 Engineer-Redux-0.6.2.10 KerbalAlarmClock-2.7.3.0 KineTechAnimation KSP-AVC - 1.1.4.2 KSPX-0.2.6 MechJeb2-2.3.1.0 DockingPortAlignment Reproduction Steps: Start the game. Load one of the save files provided. Camera should automatically switch to a rover which will then do something Unhelpful (explode or fall apart). Recent save file and associated logfile: http://filebin.ca/1cr236t3oH1m/Player.log http://filebin.ca/1cr6z5Fu0VZU/quicksave.sfs Please note that prior to this attempt I manually edited the save file in an attempt to lift the vessel 1m off the ground to avoid clipping, to identical results. The vessel in question is named "Muner Science Rover 2" Previous save file: http://filebin.ca/1cr7n2SUMgwG/quicksave.sfs.explode I think the vessel in this save file is "Muner Science Rover". In all cases, I've taken to coming to a complete stop, turning off SAS and turning on the breaks, and letting the rover sit for a few seconds before quicksaving. I don't think that any of the mods installed should have an impact on what's going on.

Given how many people are looking to automate some degree of complex logic, it may be worthwhile trying to implement a complete system for ladder logic: http://en.wikipedia.org/wiki/Ladder_logic It's vaguely like state-machine programming and is very well suited to dealing with binary conditions like a lot of comments here are bringing up. Granted, its a *lot* of work, but it would solve all of the issues in the abstract and provide those who want to automate all of the power to do so.

May I suggest having an ASCII-art front-end for this, then? The AA-project http://aa-project.sourceforge.net/index.html can do this automatically. It's silly/fun to watch DVDs across a telnet session with this.

I've started playing around with SSTO craft myself and I keep noticing a similar issue, too. I'd love to see this. Even if only at the main spaceport.

I'm running the 64-bit version under Linux and things mostly work fine. (There are a couple of odd quirks involving planets using the wrong-scale texture, though I don't know if that's specific to this version or not). OTOH, I'm still only running vanilla for now, so I'm not certain if the system is even able to use more than 4GB memory at the moment. To second what Monger mentioned, simply converting from 32-bit to 64-bit binaries typically increases the size of the executible by about 10%. Put another way, it adds about 10% more overhead. If you have more than 4GB of RAM in your system, the cost might be trivial if it allows you to address more overall. (Eg. if you have 8GB of memory, having your current KSP memory usage go from 4GB to 4.5GB is okay if you still manage to get another 2GB of free memory you can add on). That 10% number is an industry-standard average from a decade ago or so. Because KSP is very multimedia-extensive, it could be ~1%. I don't know.

I've been playing KSP for about a month now. I've recently started putting together a refuelling station in orbit and noticed a small set of parts which I think would get rid of a few frustrations I've had while not noticably altering the gameplay balance or mechanics. 1) A xenon tank similar in size to the FL-T200 Fuel Tank, with a capacity of ~8000 xenon. For a re-fuelling station, it's nice to have your fuel supply in as few containers as possible as it makes it easier to examine what you have and to perform fuel transfers. Instead of a handful of these I've attached 18 of the radial-mount ones to my space station. 2) Fuel/oxidizer canister of similar shape/size to the mystery-goo container or Stratus-V Cylindrified Monopropellant Tank. On occasion I'd like to be able to add a little bit extra fuel, though making the rocket taller isn't appropriate. Or I'd like to use it a tactically-placed counterweight for my SSTO refuelling plane. 3) Longer version of the Pegasus I Mobility Enhancer - perhaps 8 rungs worth. I like to run ladders along my space station to allow Kerbals to EVA with fuel. However, I have to put *lots* of these on to cover the length of my refuelling station. This is time consuming and leads to a lot of slightly-misaligned parts. Also, I've read that large numbers of parts on things can slow down the physics engine - this may be one way to reduce that. 4) Different-diameter versions of the Structural Fuselage. When trying to make an extended docking arm for my station I wanted a bit of clearance, so I used a stack of ~5 xenon canisters. One launch it bent like an accordion. Launch issues were addressed, though it would be nice to have a longer, ridged option for changing the lengths of things.

When I build multi-stage rockets, I'll frequently have RCS fuel attached to more than 1 stage. Obviously, I would like to burn the RCS fuel from the lower stages first. To do this, I disable the tanks of the higher stage. Once I've separated, I then enable the RCS tanks on the upper stage. When I have several tanks, I'd like to be able to switch them all on at one point. Unfortunately, it seems that I'm unable to bind an action group enabling or disabling RCS fuel tanks. Have I missed something? If not, would this please be added to a future release? - Garrett