Jacke

I agree. But when it's just stated as loss of pressurization, I think the difference needs to be emphasized. Losing pressurization with minimal other effects is survivable. Damage affecting the aerodynamics and/or allowing hot reentry gases into the airframe are almost always going to result in LOCV. I think the F-15 had a few things in its favour. One, the ruggedness of a military airframe also with a greater range of thrust and control. Two, the amount of body lift meant even after losing a wing, restoring lift sufficiently was within the range of thrust. And three, a design close to neutral stability (like all military jets) meant that the remaining control surfaces had enough authority to maneuver sufficiently. Still, an awesome display of piloting.

If there are no other major failures, losing pressure during reentry is likely survivable as all crew and passengers will at least have sufficient gear to provide breathing gas down to landing. The failure of Soyuz 11 saw to that.

Because the tanks are disabled (the red circle with slash). Click on those red circle icons to enable the tanks.

Be sure you verify your files through Steam. Log on Windows is located here now in KSP 1.8: C:\Users\<username>\AppData\LocalLow\Squad\Kerbal Space Program\Player.log

Because there's not been a KSP 1.8 version of Firespitter released. The KSP 1.7.3 to 1.8 transition is such that most mods *need* to be recompiled and often rebuilt. @RoverDude said he'd get to it this week.

Good to know. Also, don't think we'll hear from @Jake any time soon.

You should upload *all* of the log file to a file sharing site then provide that link. The reason there's a lot of information in a log file is often a lot of information has to be checked to use that log file to track down the cause of the issue. You don't know what parts @sarbian will need, so provide him with all of it.

I believe @linuxgurugamer is referring to the stock ability to edit craft in either SPH or VAB and then load the craft in the other editor. Then invoke KCT build.

Unless it uses only well-behaved KSP-only methods, there could be problems that just haven't given strong signs. I switched to using TextureReplacer to change the NavBall texture (don't know if it can do the emissive change). TextureReplacer hasn't been upgraded to KSP 1.8, but I expect it to be.

Like Jeb, he can walk that off, as can Natasha.

I played games on something similar. The computer was in the machine room somewhere in the basement. I played on either CRT terminals or Decwriter II paper printer terminals. And later on, I wrote a simple lunar lander game. I didn't have one, but some of my friends had programmable calculators. One TI model even could write and read little magnetic cards.

...then traded them to the Greys in Area 51 for some 100+ year old German Rocket Scientists who recently returned from the National Socialist German Workers' Party Base on the far side of the Moon. [snip]

What about people not using CKAN? And so much of this needs to be done as and after KSP tries to load .dll's and other things from GameData. It would require all that code to be duplicated in CKAN. And if the CKAN checker says "OK!" but it fails in KSP? The people working on this know what they're doing.

I think I remember the last Gemini, 12, vaguely. Seeing the reentry simulation graphic. I definitely remember watching Apollo 11. Seeing the B&W feed from the Moon, at first upside down.

Are you running a pre-KSP 1.8 version of Scatterer in KSP 1.8? If so, all bets are off and not working is what should be expected. With the Unity and other changes in the KSP 1.7.3 to 1.8 transition, .dll's for one have to be assumed not to work in the other unless they did all their external accesses via KSP methods that didn't change over the transition. For something as complex as Scatterer, I'm assuming it's not true. So you need a KSP 1.8 Scatterer (which we don't have yet) before there's any hope of it working.

Because KSP 1.8 changed to a newer Unity, the log file changed. Only Player.log is used under KSP 1.8.

The previous version of KSP was 1.7.3. And I disagree it was a bad move. KSP will have settled into an improved and modded version in about a month. KSP 2 is about 6 months away. And for KSP 2 to properly compare to modded KSP will likely take 2 or more months after it's released for it to acquire its own mods.

You're using a demand for a fully general file system solution for a context that doesn't need it. For a game that is in the large part all installed in one file system already mounted at the time the main program is launched. If all of the subdirectories *aren't* mounted when KSP is launched, that's a problem of the operating system install and configuration, because it breaks a requirement of KSP. And it should be obvious from the number of "file not found" errors it will produce.

The GPL says nothing explicitly about that. It allows the forking and modifying of code if the user wishes. This isn't about this. This is about having a mod's code check if it's in the correct location so it can work correctly. Which isn't in the GPL.

The CKAN metadata for your recent release still has KSP version range 1.4.0 to 1.4.3.

Wait patiently as it takes a while for changes to propagate through CKAN.

What has this to do with the GPL ?!? KSP expects its mods to be placed in GameData and only looks for them there. By convention, mods live in separate subdirectories under GameData. And like @linuxgurugamer says, a *very* common player mistake is to place mods in the wrong file system location, causing all sorts of issues. Sure, the GPL allows you to fork code. And even modify the code wrong so that it fails, sometimes silently. But that has nothing to do with what's happening here. This is about coding courtesy and user privacy, due to the code investigating the file system. But if done correctly, it can be effective and courteous and respect privacy. Considering that @linuxgurugamer will be publishing the code, that can be checked too. And considering @linuxgurugamer's dedication to KSP modding done over the many years in an outstanding manner, I would expect the code to comply to be courteous and to respect privacy.

You need to upload and provide the link to the whole log file as it's needed to do proper debugging. And post this in the MechJeb topic so @sarbian will be notified.

Well...technically 0. The first Atlas to launch actually did fly, although it had an early flight failure. In fact, all 8 of the Atlas A flight articles flew, with 4 of them having some sort of flight failure cutting the burn time short. https://en.wikipedia.org/wiki/SM-65A_Atlas

There's a KSP version field in KerbalX's search. But even looking at the few .craft I've uploaded, it doesn't show that field. However, it must have it as the data field is in the .craft files.