Ghostbird

I could not find any notes on this. I searched the MJ and RC threads and Github issues. No mention of problems. I don't see any obvious reasons why they would interfere either. So far I have not had any issues since I deleted all unnecessary crafts.

I tried without add-ons as well, and the same bug occurred then. This save however has the issue with 100% reproduction rate over four tries, which is better than I managed to achieve without mods. What conflict exists between AR' MechJeb and RealChute? I have used both together since .22, without any obvious issues.

Of course I kept it for research! https://www.dropbox.com/s/lltirelreeuen1w/persistent.sfs.tar.gz

Uhm… This was a GPU crash as in: The thing is going down so hard there's nothing left to do but interrupt the power supply and reboot the system.¹ Of course there's no KSP log. On the other hand, I found that the bug was caused by something that wasn't very important in my savegame. I simply deleted every VESSEL in the FLIGHTSTATE except for my LKO asteroid space station / laboratory / gas station, and I can continue playing. 1) Thank goodness Linux uses journalling filesystems. With Windows' NTFS-3G I would've destroyed my system multiple times already.

KSP crashes my GPU Used to be sporadically when in orbit around Kerbin, now it's standard when I open the tracking station. I'm going to try to figure out what causes this. My system: GNU/Linux Mint 13 (Maya) with Cinnamon NVIDIA Quadro FX770M Driver: nvidia-331 KSP: Steam 0.23.5 Conclusions so far: Not mod related, the non-modded install had the same issue Occurs in both 32-bit and 64-bit versions. New game did not crash immediately upon opening the tracking station. Opened persistent.sfs, removed every VESSEL in FLIGHTSTATE except for my painstakingly crafted space station / science outpost / refuel station built on an LKO asteroid. Bug does not immediately reoccur. I am happy with this.

I have indeed been reducing my TWR a lot. Normally in KSP you'd need 2.2 TWR to get a rocket up, and I guess I'm too used to designing them that way. Most of my rockets now have 1.8 to 2.2 TWR. And I always build my rockets tall and skinny. I've seen a lot of awesome things at the forums, but the launch vehicles often look more like a hockey puck tan a rocket, and I can't really bring myself to build something that un-rocketlike. Anyway, I'm back here, since my DRE struck again. For unknown reasons the game doesn't run from terminal anymore, and the Steam version isn't working yet either. I didn't change anything since last time, so I'm a bit surprised. I have some ideas that may cause this problem, but no known way to verify or fix them.

I'm running FAR and DRE both happily. I guess my rocket designs just aren't that good, since they fly with FAR similarly to how I would fly them in Stock KSP. The main difference is that with FAR I need some winglets on the bottom sections of the launch stages to avoid tipping over the craft. Also I have to throttle down far more than I used to, and keep my ship at low speeds until I'm high up, otherwise it will destabilise horribly due to drag, and start to flip over. EDIT: But I have realised a bit of how the shrunk KSP solar system affects things, and I think that for .23 I'm going with the RSS in addition to DRE, FAR, and RealChute, and maybe some other realism mods.

Ah thanks, that is a patch for the binary. Is this the a.g.'s patch? It seems to change two highly specific code addresses in the binary. I'm always amazed that people manage to find such fixes. Alas as I feared (My stacktrace was quite different from that of people that needed the patch, and my KSP only has problems with DRE), this did not fix my problem. The good news is, my KSP runs fine (both x86 and x86_64) when I run it from terminal (no idea why, crashed before). However the crash is still persistent when I start the game trough steam. Which is kind of a shame, since I normally chronicle all my missions on my Steam profile screenshots. I've already tried restarting Steam, and adding different launch options in Steam, but that didn't help. Also it doesn't matter whether I launch x86 or x86_64 trough Steam. Both crash. No crash log is given, and the GDB stacktrace is the one I gave before. So on the positive side: I can happily play with DRE. Alas I cannot screenshot my magnificent craft explosions, nor my successful landings for my Steam profile. I'll happily run it from terminal though, since the new .23 is slated for the day after tomorrow, and I'll have to restart my save anyway most likely since it seems to be a significant overhaul.

Are you sure you understand orbital mechanics and you're not simply misunderstanding how the manoeuvre node works? I've never before heard of this error, and it seems strange to me. Could you post a screenshot showing a map view with both a manoeuvre node visible, and the navball showing the wrongly pointed vector indicator?

Well I'll have another look at the Linux compatibility thread. I read it before, but at that time I was just reading through, without looking for anything specific. KSP often crashes my graphics card, leaving me no choice but to switch of my machine's power and reboot, and often crashes when it has to spawn ghost copies while building something symmetrically, most often with air intakes I think. EDIT: I have found nothing definite on the Linux Compatibility Thread, but I'm going to try A.G.'s fix for the libpng miscompilation. Though I don't think that's the issue, since: It is only supposed to happen on the x86_64 version (for me it happens on both), and it should happen without DRE as well, yet for me DRE is the definite factor that causes the crash (removing DRE immediately solves the problem), also my stacktrace is different. EDIT: I found where KSP on Linux stores it's Player.log files, the bad news is, that there is still no data on the crash in there. EDIT: The forums will not allow me to view the thread for A.G.'s fix because I lack permissions. That's weird.

DRE segfaults my game during the black loading screen that occurs between the splash loading screen and the main menu. Any idea what can cause this? Oddly enough, the second time I tried to start KSP with DRE, it worked flawlessly. But the first time it segfaulted, and every time after the second time it segfaulted as well. That one time was running really well, and I managed to get a fairly heavy (15+ tons) lander into orbit and back on Kerbin safely, but when I circularised into orbit on a second test flight, the game crashed my graphics card, which is unrelated to DRE. Stock KSP .22 is simply ridiculously unstable. I'm running Steam KSP .22 on GNU/Linux Mint 13 with Cinnamon. I've tried: Running DRE with mods (FAR, RealChute, RemoteTech2, MechJeb2) Running DRE on stock KSP Running DRE alone (without Squad folder in GameData) All three methods yield the same crash. I've tried removing the GameData/DeadlyReentry folder and running KSP with the mods mentioned above, which works perfectly. (Still very unstable, but still but no segfault upon load.) Stacktrace from GDB¹: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7fcd780 (LWP 4893)] 0x0000000040272aee in ?? () (gdb) bt #0 0x0000000040272aee in ?? () #1 0x0000000000000594 in ?? () #2 0x00007fff8c871588 in ?? () #3 0x00007fff8c8715d8 in ?? () #4 0x00007ffff25b1fe0 in ?? () from /home/username/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Mono/x86_64/libmono.so #5 0x00007ffff6595720 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x000000001b6f9740 in ?? () #7 0x0000000000000018 in ?? () #8 0x0000000000000000 in ?? () [Thread 0x7ffff1eea700 (LWP 4894) exited] [Thread 0x7ffff1e59700 (LWP 4895) exited] [Thread 0x7ffff140e700 (LWP 4897) exited] [Thread 0x7ffff0c0d700 (LWP 4898) exited] [Thread 0x7fffebfff700 (LWP 4899) exited] [Thread 0x7fffd3ffe700 (LWP 4905) exited] [Thread 0x7fffd37fd700 (LWP 4906) exited] [Thread 0x7ffff019b700 (LWP 4907) exited] [Thread 0x7ffff03ff700 (LWP 4908) exited] [Thread 0x7ffff7fcd780 (LWP 4893) exited] Program terminated with signal SIGSEGV, Segmentation fault. I think KSP does not leave crashlogs or crashdumps, so I cannot tell what exactly is wrong. I read online that crashdumps e.a. should be created in the main KSP install directory, but my KSP never creates any such files. There are three reasons I can think of: KSP doesn't have a SIGSEGV eventhandler and does not nicely handle segfaults, it simply terminates immediately, which would be very strange, especially for a game still in development that is reliant on the players for bug reporting. Steam KSP doesn't have the debug facilities the normal version has. Yes I've run KSP directly and without launching it trough Steam, for debugging purposes, but it still is the binary packaged with Steam, which may or may not differ from the one from the KSP store. KSP for GNU/Linux has a bug that prevents correct SIGSEGV handling and/or crashdumps/reports. 1) The GNU Project Debugger, not to be confused in KSP context with the GDb (The KSP GameDatabase).

And I think I've found the reason: I did not download the ModuleManager file that was supplied in the first post, since I already had the latest version. However, I checked it just now, and I saw that it includes configuration files as well. Apparently KSP doesn't handle such missing files gracefully, and segfaults, instead of producing an error. As I said in my previous post, no crash files, nor output logs were written, which is fairly common when a segfault occurs, since the program is sent the SIGSEGV and is terminated immediately. Also I tried debugging the program with GDB (GDB: The GNU Project Debugger) and it couldn't get any stacktrace. I later realised that KSP may be written in C#.NET and that GDB has no support for that language. I'm loading KSP right now, and will try to see whether RealChutes works correctly. Then I guess I will run some tests before adding Deadly Re-entry. I think that's the last of the realism mods. EDIT: It turns out that the problem was caused by the missing configuration files. I'll be loading in my original mods again and test whether they all play nice together. EDIT: Everything is working fine now. You may want to add a notice that the modulemanager download also includes necessary configuration files though. Otherwise people who are sure they know-it-all and have the correct modulemanager.dll already may not download it and start whining about it. (Who, me? Surely not?) EDIT: Is there a part in the mod with both a drag chute and a main chute in one part? (I saw the stackable drag chute has two drag chutes.) Or do I have to write it myself if I want that? I'd love to have a nose cone with both drag and main parachutes.

When I move a RealChute fitted vessel to the launch platform, the game segfaults during loading. Any idea what can cause this? KSP isn't really made for debugging it seems, since nothing was logged, the command line just says segfault, and even gdb cannot extract a stacktrace. I'm running: The steam version 0.22 On Linux Mint 13 with Cinnamon Using these plugins: RealChute RemoteTech2 Mechjeb FAR EDIT: Confirmed that it happens with just RealChute, no other mods. Confirmed that it does not happen on a craft without RealChute parts.

Lvl flight assistance actually works for you? I thought it didn't work at all. I didn't notice any difference between using it and not using it. Then again, I don't use Mechjeb, since I can do the important manoeuvres better myself. Which probably just means that my vehicles are too weird for Mechjeb and FAR auto-pilots to handle. I must say though. FAR finally makes planes handle-able. In stock KSP my planes would nearly always have crazy behaviour, and crash. Of course I managed that in FAR too, but it took me three revisions. I still suck at landing my planes though. Therefore I attached sepratrons and parachutes to the cockpit, and I can shoot it away from the plane. Then I found out that with KAS (Kerbal Attachment System) installed, my Kerbals can carry radial mount parachutes. Even if those parachutes have been deployed, but not yet activated because of too low atmospheric density. From there I repurposed the plane to a STOL that flies to 25km on it's jets, then fires the liquid fuel rockets, then ejects the cockpit upwards. Before it reaches 90km apoapsis, I'll deploy the parachutes, the pilot will go on EVA, and grab one of the deployed parachutes. From there he goes skydiving. And lands safely.

How do I make flaps? Do I simply add control surfaces to the front of the wings/top of the wings and configure them as flaps? Or do I need a mod for that? If so, what mods would you recommend?

At the moment my KSP crashes very frequently when I move parts over other parts in an assembly building, and symmetry is enabled. Also the game ALWAYS crashes when I hit "C" while my Kerbal is in an external seat.

How did you bend the 1×6 Solar panels? Or is that a mod part?

I think I figured out what I misunderstood: The Kerbal insurance cost. It is first deducted when the Kerbals are loaded (before launch already), and returned upon vehicle recovery. Thinking more about my problems, I realised that I may have been unfair in my disappointment with the mod, since it exponentially increased the difficulty for me. I later realised that this applies to my install more since I have Deadly Re-entry and RemoteTech mods installed. - The deadly re-entry gives slight additional difficulty, since I have a slightly higher starting cost for my vehicles (heat shields) and I have to plan re-entry and aero-braking manoeuvres far more carefully to avoid burning up in the atmosphere. This gives my rockets generally a higher ÃŽâ€v requirement for atmospheric insertion manoeuvres. This can be anything from 30 to 600 m/s ÃŽâ€v. - RemoteTechy makes the mission pack unsuitable. Any unmanned mission going outside the line-of-sight of, or more than 10 Mm away from, the KSC will become non-functional. To be able to do most missions unmanned, I first must place a few satellites that can cover any angle, and greater distances from the KSC. Since the standard mission pack doesn't give me enough of a budget to do extra launches for this purpose, the latter missions must be manned. This however makes the missions harder since landing back on Kerbin becomes mandatory. I managed to figure out several ways¹ to do most of them, but it definitely increases costs. I'll look at the other mission packs I have, to see whether there's a mission pack that has missions that allow me to place a relay of satellites in KEO as part of a mission. I'll probably blow quite a chunk in my budget by adding communication antennae from the RemoteTech parts. The basic antennae are ridiculously expensive compared to the stock Commutron 16s, but the Commutron 16s break away from the craft when deployed in atmosphere. In the end, I think this mod makes a valuable addition to the game, and stresses the importance of a good career mode, since a limited budget adds another dimension to the rocket building process. One last thing: Since the Mission Controller Extended state doesn't synchronise with the game saves, it is possible to gain a lot of money by saving before landing, recovering the craft, reloading and repeating the cycle. Every repetition you'll not only recover the craft, but you will receive the Kerbal Insurance as well. If you don't realise this, and you do this accidentally with a 3 Kerbal craft it's a strangely huge increase in budget since you'll get 85% of the landing vehicle cost + 165kK. 1. There are two options: - Move a three Kerbal crewed craft with Remote Command module and antennae close to the target and launch an unmanned probe (with antennae) from it. The three crew members and Remote Command module will allow it to remotely control a probe that has radio contact. You don't need to relay it back to the KSC for contact. Requires a far larger launch vehicle. Return home to Kerbin with the crewed craft after the mission goals have been achieved. - Place a single Kerbal crewed craft on course with the target (for example the Kerbolo and Minmus I missions) and detach a small probe from it. Return to Kerbin with the crewed craft while the probe is flown (albeit uncontrollably) to complete the mission. This method is cheaper than the above-mentioned method, but requires more timing, and cannot be used on missions where the probe has to be controlled after being detached.

Is it possible to synchronise with the save/reload system of KSP? I know it makes cheating out of a doomed flight really easy, but because it isn't synched, I keep encountering weirdness that arises from the de-synchronisation. So far I have raised my budget to 200k, but of that I probably netted 100k from missions, lost 150k due to weirdness and gained 200k due to weirdness. It gives me the feeling that how much budget I get is not related to how well I plan and evaluate, but whether I'm lucky with glitches or unlucky. I guess the feeling will disappear when I start to understand what causes these discrepancies, and how I can avoid them, but for a beginning user it makes the mod feel pointless. A loss example: I create a craft and launch it. The cost is deducted from my budget upon going to the launchpad, but may be deducted again upon lift-off. It is not refunded upon returning to the VAB either. (maybe deduct partial fuel loss from the de-fuelling process, but not everything). A gain example: I create a craft and launch it. Spent stages are de-orbited on parachutes and are recycled. I complete the mission and land the craft. I go to the tracking station and recover the craft. The recovery money is close to the entire cost of the craft including fuel (and the stages that were already recycled.)

Well, this sucks. I've been unable to replicate the effect as of yet. However when it occurred I could disable and enable the effect by toggling the leading edges of the wings. I'll keep an eye out on the effect, but for now I'm unable to give more test data.

Note: I haven't managed to test yet, I'll try it tomorrow, but I'm on GMT+2 time, so it's late at night/early morning here. Actually my initial point wasn't about the drag. I think drag is constant in KSP parts. I had two problems: 1. The (toggled) leading edge apparently affects the speed directly. This instead of modifying a physical property, which would make the wing behave differently in the physics simulation (affecting speed indirectly). 2. The leading edge apparently affects the speed of the vehicle instead of the velocity. The effect is completely independent upon direction, and only affected by the raw speed. I first noticed this effect in KEO, and it slowed my vehicle down to exactly 11.7m/s. The speed at which the scalar multiplication of the "leading edge effect" and the gravitational acceleration on the vehicle balanced when my velocity was aimed straight at the centre of Kerbin.

Hang on, there's something really weird going on with the plane. The effect disappeared before hitting the atmosphere, I read my altimeter wrong. I'm not sure what happens. I'll revert and relaunch to check what's happening. I can with certainty say that the effect doesn't exist when the leading edge is not deployed, or when the ship is "on rails".

I've found a really weird glitch in Firespitter with the Jet wings with "toggle leading edge" functionality. I used these wings to create a space shuttle-esque system. I found however that the toggled leading edges apply a constant deceleration, applied to the speed as a scalar. Thus I now have a space shuttle in Equatorial NORBIT (non-orbit). The plane is actually nearly suspended against the force of gravity by the power of "leading edge". The power of the leading edge is a scalar, and thus dependent on the speed of the vehicle. At this height, the acceleration of gravity and the scalar deceleration of the "leading edge" cancel each other out at 11.7 m/s. Thus my plane is now moving in a straight line trough space, towards Kerbin at a steady rate of 11.7 m/s. This kind of maglev (that's magical levitation, not magnetic levitation) is kind of game breaking. Could you please revisit the fighter wings? I thought this was what they intended to do: Increase lift, at the cost of more drag (as in real-world aeroplanes) I think this can be implemented fairly simply and effectively by making the toggle change both lift and drag parameters of the part (increasing both). EDIT: It may be that the wings have been correctly implemented for atmospheric conditions and that the glitch arises from unforeseen effects in vacuum. The effect disappears instantly when officially entering atmosphere, even if at this point the atmosphere is so thin that no sudden transition from vacuum ought to be observed.

Dear mod developer, could you take a look at this thread, especially the referenced post? It is a savegame corrupting error that stems from referencing the array of Kerbals starting at 1 instead of 0. I personally suspect your mod, though I love the functionality it adds. Could you check whether there is a chance that you, for example, accidentally increment the crew index before reading/writing it? From personal experience, a misplaced ++var instead of var++ can make all the difference in the world when it comes to array boundaries. Sincerely, Ghostbird