badpandabear

The oldest I could find was from just after the ARM parts came out. On my first attempt to deflect an Asteroid I made my rendezvous too close to Kerbin and this happened.

It does work with 1.0.5 linux. I expect it'll work on windows but I haven't tested it. You'll need to get the old version from KerbalStuff and replace the DLL with the version from Taniwha's Github page. Note the manual install instructions on page 1 of this thread. Good luck!

I had a similar experience in Windows 7, it would crash whenever I tried to open it from the toolbar regardless of whether I had a joystick plugged in or not. This was with 1.0.2 and the updated dll from Taniwha. Since no one else had reported this I figured it was something weird with my hardware. Fortunately I play mostly on Linux. I tried to look into why it was crashing, but I'm not that experienced with Unity or Windows programming. It looked like it was crashing in Xinput code enumerating my controllers. I put my output_log.txt in dropbox if anyone with more Unity/Windows experience wants to take a look at it. https://dl.dropboxusercontent.com/u/25219148/output_log.txt

I was surprised that this worked. I had looked at the source earlier but I missed the section of code for calibration. Thanks! One point to clarify, setting to what the Controller Configuration showed as 0% didn't work for me. I had to move the throttle all the way down to the position I wanted to be 0%. This showed up as 1 until I hit calibrate.

If your throttle has half of its range negative like mine (a Logitech Extreme 3D Pro) then the AFBW calibration won't help. It won't shift the negative values to be positive values. If you have calibration software outside of KSP that can shift the values to be all positive then that might work.

The Linux version is working great taniwha. Thanks!

I was playing around with mapping joy stick controls and noticed that there are secondary bindings for various axes. I tried to use these, and all I got was one joystick axis controlling both yaw and roll, which wasn't very useful to me. So I'm curious, what are these secondary settings supposed to be used for?

I just made a pull request that fixes (at least for me ) the Hat button 0 defaults to true problem. Hopefully the mod author will reappear and release a new build. It was an SDL issue, so Windows users should be able to workaround it with XInput. Unless there's a different XInput bug I don't know about.

I can certainly understand the need to reduce "requirements creep". But if you do make a new mod it should be "KR", as "human" resources doesn't make sense. More seriously, I was thinking it should cost experience points if a kerbal is retrained to another profession. Since all of their experience in one profession might not apply to another (but some would). Or perhaps it should take some time to retrain a kerbal. I briefly looked at changing the kerbal's experience level in code but it was reset every time a mission was recovered. I think the game recalculates it based on the kerbal's flight log.

Basically I've been trying to directly set the Kerbal's profession whenever the game automatically resets it based on the name. I'm using a scenario module to persist the name/profession mapping to the saved game. The code looks like: // Note I hate the name FlexibleProfession [KSPScenario(ScenarioCreationOptions.AddToAllGames,new GameScenes[]{GameScenes.EDITOR,GameScenes.FLIGHT,GameScenes.SPACECENTER})] public class FlexibleProfessionScenario : ScenarioModule { //stuff public override void OnLoad(ConfigNode node) { foreach (ConfigNode child in node.GetNodes(FPConstants.KERBAL_SUBNODE)) { KerbalProfessionData loadedKerbal = new KerbalProfessionData(); loadedKerbal.Load(child); if (loadedKerbal.KerbalName != null) { KerbalRoster.SetExperienceTrait(crew, loadedKerbal.Title); // Other stuff to store loadedKerbal } } } //stuff }; In my testing I've found that calling "KerbalRoster.SetExperienceTrait( someProtoCrewMember )" will recompute the profession based on protoCrewMember's name. That should be easier for the append non-printable character approach. BTW The reason I'm trying something different is that I thought it might be cool to try making a new custom profession. When I try that it reshuffles all the professions for the non-orange suited Kerbals--which seems bad for an existing saved game. But I have another problem in that Vessels won't recognize my Pilots as being able to use SAS unless they EVA first. Edited: Now it's fixed! Time for bed

I was thinking about making a mod to allow renaming Kerbals without changing professions when I discovered this thread. In my testing I found that Kerbal professions reset when the "onGameStateLoad" event was triggered. So I tried setting the profession at that point and it seemed to persist across scene changes. Perhaps something similar would work for ShipManifest.

I've been using the formulas on this thread: http://forum.kerbalspaceprogram.com/threads/30311-Calculating-Re-entry-Angle-from-Orbit IIRC the radius for stock Kerbin the radius is 600000 m + 70000 m for the atmosphere. The other parameters I get from Kerbal Engineer.

So I was playing with the Deadly Reentry inflatable shield... Note to self: put the shield *below* things it is supposed to protect.

I've been testing the 6.5 beta using Linux 64bit KSP, Module Manager 2.5.8, and no other mods. What I'm seeing seems odd. Using a Mk 1 Pod with only a parachute attached, I tried to deorbit from a 110km circular orbit above Kerbin. I tried a periapsis at 0, 5k, 10k, 20k 30k, and 40k. On normal my Pod exploded at 20k and above. At 10k it had 0 ablation left. At 5k it had about 4 left, and at 0k it had about 9 left. On Hard difficulty, it always survived with just a few ablation units used up. I then tried the same set of tests using a Mk 1-2 Pod with heat shield, a docking port and parachutes. On normal difficulty the ablation shield was used up quickly and the pod exploded on every reentry. I had to go to a suborbial trajectory (1600m/s when hitting the atmosphere) before it would survive. On Hard difficulty, it again always survived. On every test I make sure alternate density is turned off and the alternate heating model turned on. So is it simply that Normal and Hard difficulty are reversed? Or am I doing something wrong? Here is my custom.cfg if it helps. I can also generate logs if you want but not tonight because I'm tired of doing reentries. @REENTRY_EFFECTS[Easy]:AFTER[DeadlyReentry] { @shockwaveExponent = 1 @shockwaveMultiplier = 1 @heatMultiplier = 25 @startThermal = 750 @fullThermal = 1150 @afxDensityExponent = 0.9 @temperatureExponent = 1 @densityExponent = 0.9 @gToleranceMult = 6 @parachuteTempMult = 0.5 @crewGKillChance = 0.01 @crewGClamp = 10 @crewGPower = 4 @crewGMin = 10 @crewGWarn = 450000 @crewGLimit = 900000 @legacyAero = False @dissipationCap = True @useAlternateDensity = False @useAlternateHeatModel = True } @REENTRY_EFFECTS[Default]:AFTER[DeadlyReentry] { @shockwaveExponent = 1 @shockwaveMultiplier = 1 @heatMultiplier = 20 @startThermal = 750 @fullThermal = 1150 @afxDensityExponent = 0.8 @temperatureExponent = 1 @densityExponent = 0.8 @gToleranceMult = 6 @parachuteTempMult = 0.25 @crewGKillChance = 0.01 @crewGClamp = 30 @crewGPower = 4 @crewGMin = 5 @crewGWarn = 450000 @crewGLimit = 900000 @legacyAero = False @dissipationCap = True @useAlternateDensity = False @useAlternateHeatModel = True } @REENTRY_EFFECTS[Hard]:AFTER[DeadlyReentry] { @shockwaveExponent = 1 @shockwaveMultiplier = 1 @heatMultiplier = 1 @startThermal = 750 @fullThermal = 3000 @afxDensityExponent = 0.6 @temperatureExponent = 1.55 @densityExponent = 0.6 @gToleranceMult = 6 @parachuteTempMult = 0.25 @crewGKillChance = 0.01 @crewGClamp = 30 @crewGPower = 4 @crewGMin = 5 @crewGWarn = 225000 @crewGLimit = 450000 @legacyAero = False @dissipationCap = True @useAlternateDensity = False @useAlternateHeatModel = True }

First I was just copying real world designs like the Titan, Atlas and Saturn V. Copying the Gemini and Apollo missions was a good way to learn how to dock. But now I've moved onto using a spreadsheet to calculate delta-v for my ships. First I design the payload, then either use an existing lifter or design a new one based on the delta-v needed to get to orbit. I tend to build interplanetary ships by docking the pieces together in orbit.

I'm exactly the same way. I always say "meh-thane" but for some reason it doesn't sound right to say "keh-thane". I also pronounce ethane as "ee-thane" for some reason. Perhaps I'm just dumb.

1) Struts 2) Mainsails 3) More struts

This is similar to a mod I was thinking of writing. Basically there would be three types of failures. Minor failures might include lights getting stuck on/off or a probe going into safe mode. These could be fixed via a menu click. Major errors would be less frequent but more dangerous. Like a fuel tank leaking, a solar panel producing less energy, or a command pod losing torque. These could be fixed by a Kerbal on EVA but could be serious if they happened during a critical phase of the mission. Catastrophic failures would generally involve explosions or things not working at all. These would be irreparable and the only way to deal with them would be redundancy (like extra parachutes) or rescue missions. What I wasn't sure about was how to handle the probabilities of a part failing. A simple way would be to assign a probability/unit time for each severity of failure, compute when the next failure will happen, and then when that time comes around randomly pick a part to fail. These probabilities would decrease when certain technologies are unlocked simulating the Kerbals getting better at testing and manufacturing. A more complex way would be to assign a probability to each part. A newly unlocked part would be more likely to fail as the Kerbals would have less experience with it. (I think I got this idea from a recent Scott Manley video). As above certain technologies would cause a overall lowering of failure rates as the space program matures. This would tend to discourage more complex shops with new parts early in the game, which might be more realistic but could be annoying.

I only use the T45/T30's as lower stage engines on smaller rockets. For upper stages/landers I prefer the higher ISPs of the poodle. But of course the LV-909 is a better option. The only time I use the Poodle is for my Saturn V- like rocket; where the 3rd stage and service module each should only have one engine.

From a poorly planned Mun mission I had Jeb stuck on the Mun's North Pole, and Bob and Bill stuck in very different elliptical orbits. I managed to get Jeb back despite loosing 4 of the 8 engines on my poorly designed Lander. Next it was time for Bob and Bill. I figured I had just enough for two plane change manuevers to reach them. I had the orbit aligned perfectly, a 1 km intercept, and then I realized...I was going the wrong way! Bob's orbit was retrograde relative to the rescue ship, and there was no way I could reverse my orbit to save Bob and then reverse my orbit again to save Bill . So I decided to save Bill. But don't worry Bob, we'll come back for you!

Every single time I design a new lander for the Mun, just as I'm descending to land...WTH? Why am I out of fuel? *facepalm* I forgot the fuel lines. Time to fire up the ascent engine...

On Kerbin's North Pole: "Jeb said Kerbal Klaus lived up here. But there's nothing here. Why would he lie to me like that! Whyyyy!?" After my first v.20 landing on the Mun: "First landing of Kerbal-kind on another world. In memory of Jebediah Kerman, and Bob Kerman who died so that others may triumph. And also Ansel Kerman who died stupidly trying to plant a flag for Jeb and Bob." And a Futurama reference: "We're whalers on Minmuuus!"

I'm having some gamepad issues and I'm wondering if anyone has a better workaround. I'm running Linux Mint 14 on a laptop using via KVM switch connected to an external monitor and USB keyboard. I'm also using a USB game pad. The problem was that the buttons on the game pad seemed to "bounce". For example, the button I used to activate the Map view would quickly bring up the Map view and then switch back to the staging view. If I hold the button, it would continuously switch back and forth. When KSP started, it would show this: ... /dev/input/js0: driver version: 2.1.0 (20100) /dev/input/js0: fd 3, buttons 13, axes 6, name Nostromo Nostromo n45 Dual Analog Gamepad /dev/input/js0: axis 0: raw 0, mapped 0.000000 /dev/input/js0: axis 1: raw 0, mapped 0.000000 /dev/input/js0: axis 2: raw 0, mapped 0.000000 /dev/input/js0: axis 3: raw 0, mapped 0.000000 /dev/input/js0: axis 4: raw 0, mapped 0.000000 /dev/input/js0: axis 5: raw 0, mapped 0.000000 /dev/input/js1: driver version: 2.1.0 (20100) : Too many buttons; using buttons 0 - 19 and ignoring buttons 20 - 65 /dev/input/js1: fd 4, buttons 20, axes 0, name Logitech Logitech USB Keyboard It seemed that KSP was recognizing both my keyboard and my gamepad as a joystick device. Using "evtest" I found out that this was a linux thing, my keyboard created two input devices one of which was being used by fancy buttons and was being interpreted as a joystick. As a workaround I can simply unplug the USB KVM before starting KSP and then plug it back in once KSP is running. But that's a bit awkard and wouldn't work for someone without a seperate laptop keyboard. Is there an easier way to stop KSP from using this keyboard as a joystick device?