Whovian

50% Industries: We've got that much fuel left after finishing our missions (Actually it's named after the casualty rate, but don't tell the public or my reputation's gonna take a big hit.) Welp, this is my first Mission Reports thread ever. I've decided to see what Better Than Starting Manned all about; I know practically zero things about it. After completely ignoring the warnings about BTSM not working well with other mods, I've installed a decently large modlist: Toolbar BTSM Chatterer DRE FAR In Flight Waypoints PreciseNode Jumbo 32 VOID Kerbal Alarm Clock Transfer Window Planner Ven's Stock Revamp (with appropriate MM patches I wrote for BTSM compatibility) I'm standing rather close to a tall cliff using Jumbo 32 and FAR with BTSM. VOID's there cos I like green numbers and HUDs. For reference, I'm using a DRE shockwave multiplier of 1.8 for now due to DRE nerfing itself in the presence of RSS. If this is a problem, I'll deal with it. I'm expecting to add to this thread progressively; it's not really a mission report yet, but it will be. - - - Updated - - - Since my first post, I have discovered three things: FAR makes things turn. Stayputniks don't have reaction wheels. Buffed DRE doesn't work well with FAR during the first launch with full thrust. This is gonna be fun.

Regarding the wheels, I can guess that it's because one of B9's dependencies (I'm not sure which one's used for the wheels) is outdated; try reinstalling and overwriting all your SmokeScreen, Firespitter, etc. folders. Regarding the textures, that usually happens when it tries to superimpose two identical models on top of one another. Can I ask what part that is so I can see if I can reproduce it? Also try making sure symmetry's off; I've gotten weird issues like that due to symmetry. I'm kind of new to this whole "trying to help with support" thing, so I have no idea if this advice will be helpful or not.

Anyone else having trouble with pingonaut's EVA suit textures working just fine the first time KSP loads and then everything being stock EVA suits every time thereafter? Pretty sure that, if anything, it's a Texture Replacer problem. EDIT: Even after turning reflections off, I'm still getting no cheeks on the biosuits. The "grey" biosuits are also giving me the same problem as pingonaut's suits. It would seem EVA suits hate me.

Right, 27 words of advice: I only recommend reading this if you're up for a long, probably controversial post regarding mathematical philosophy and philosophical mathematics and their relation to theories of everything. Definition: A theory of everything is a system consisting of a finite of true statements, rules of statement and deduction included, in which any conceivable meaningful physical law can be stated, from which any true ones can be proven via the rules of deduction, and in which no meaningless physical laws can be stated. Purely mathematical statements like "1+1=2" are not considered physical laws, and as such the final condition does not exclude the possibility of us being able to state them. I'll be assuming throughout this post that the Universe is consistent; i.e. there are no meaningful physical propositions which are both true and false. (I'll admit I'm hand-waving a bit here by not properly defining meaningful; to be frank, I haven't a satisfactory definition. We can use "observationally falsifiable" for now, but it's not clear that a theory of everything won't be able to result in observationally unfalsifiable statements. For example, metaphysical questions like "what came before the Universe" would not be considered meaningful.) In this case, we can try to invoke Gödel's first incompleteness theorem on our theory of everything. To my understanding the theorem can be stated as follows: Any formal axiomatic system which can describe basic arithmetic, if it is consistent, must also be incomplete (meaning we can construct "undecidable" statements which cannot be formally proven nor disproven.) The given definition of a theory of everything was meant to conform with the definition of "formal axiomatic system" (or whatever phrase mathematicians are using nowadays.) Therefore we can try to apply the first incompleteness theorem to our theory of everything, which presents three possibilities: You don't need to know arithmetic to be a physicist. There is no theory of everything; we can construct meaningful statements which cannot be decided in any candidate for a theory of everything. In order to conform to the definition of "theory of everything" given, we need to include any and all necessary mathematical prerequisites; the incompleteness could be in the mathematical prerequisites rather than the physically meaningful questions. I'll have to grudge my way through Science Without Numbers, ignoring as best as I can that Hartry Field is a bit of a jerk, to see if this possibility can be excluded. Anyways, I feel like this post, especially the definition of "theory of everything," is becoming a bit of a mess. I wanted to open up discussion on this idea; feel free to criticize my reasoning (I tried conforming as best I could to mere first-order logic for my deductions,) my definition of "theory of everything," or anything else about this post. I'm frankly just a mathematician who dabbles occasionally in philosophy, so I'm not too familiar with philosophical conventions. Notes regarding various philosophies of mathematics: For accessibility, I'm presupposing the existence of a "real world" independent of mathematics. This may bug mathematical monists. I'm also presupposing, as the Platonist I am, the absolute truth of mathematics; this may bug others. I have attempted to construct this post in a manner which does not assume that the philosophy being used is correct or justifiable, but only that it's valid and consistent. I am, however, also assuming that any conceivable theory of everything can be described mathematically, but it may be arguable that the mathematics required is not abstract, and is as such ontologically uncontroversial. If you have no idea what any of this paragraph means, don't worry; it's pretty much a fairly unimportant side note. Finally, I do apologize for any and all offense to philosophical beliefs I may cause. EDIT: I should note that these in no way reflect the views of the mathematical community and I doubt I'm a typical mathematician when it comes to my philosophy, but it's too late to change the title now.

*Lands on Duna with a lander with full fuel (I got to the surface with a stage that wasn't originally intended to be the lander)* "I've got PLENTY of fuel left!" (Cue fiddling around for 30 min while trying to find a Kerbin encounter within my Delta-v and life support budget.) When I finally got an encounter, I ran out of fuel while setting up the aerobrake (this was when I was too stupid to realize that burning radial - would be more efficient than burning retrograde) and, while I did dip into atmo, I ended up on a really steep impact trajectory. I had initially imagined that the single parachute would be enough for the decently heavy ship, but figured it wouldn't be on such a steep aerobrake. I ended up launching another ship to rendezvous and attach about 8 radial parachutes with KAS.

Ah. That problem. I ran into it during Eve tests; basically, you need to turn your ship in order to keep the prograde marker as close to straight up as possible. Don't rely on your pilot to do this; their AI generally isn't enough to handle FAR. Instead, use the WASD keys and think of your "direction you're pointing" marker as "pulling" your velocity prograde marker towards it; try to keep it close to being straight up, but on the opposite side from your velocity prograde in order to keep your velocity prograde up. Once you get to 100 m/s or so, you should be pretty good.

SAS with a fair amount of thrust vectoring should be more than enough to stay on course. If you're using FAR and the tipping's happening during your gravity turn, that's expected behavior; start your turn shortly after leaving the launchpad (70 m/s or so, though it depends on the rocket; try starting at different times) and do it gradually. Otherwise, it sounds like a bug. EDIT: Ninja'd. Indeed the problem's FAR; basically, NEVER tip more than 10 degrees or so (probably depends on the rocket) from your surface velocity vector in reasonably thick atmosphere. You're probably free to turn any which way you want when the navball switches from surface velocity to orbital.

Hell Krakens. Lots of them. I also tried the "infinite fuel with lots of the O-10s" thing that Scott Manley showcased. To keep it from flipping over due to FAR, I tried adding winglets to it. Bad idea. Next thing I knew, I was speeding out of the solar system with 40-digit velocity numbers on my navball. I think I ended up at a few hundred yottameters.

No, but realism in aesthetics is a much different matter from realism in physics. KSP is meant to simulate rockets well within reasonable deviation (as it doesn't have n-body simulation, general relativistic orbits, or the slight deviation from spherehood planets tend to have); a quick look at most of KSP will inform one that aesthetics are not, in fact, a large portion of the game. I wouldn't mind some overhaul to the aesthetics, specifically the pre-ARM parts' appearance, and in fact would rather like such an overhaul. I wouldn't object to modifying the exhaust effects as described either, though I don't have any preference on this bit personally. Do keep in mind, however, that aesthetics aren't the focus of the game, and the devs will focus on what they consider to be the most-needed modifications to the game.

Huh. That's an interesting idea for bugfixing; make temperature scans always possible but only make them give you science in some situations? The only potential problem I can think of is that's much different from the way other scientific instruments in KSP work, so the "0 science" bit might confuse some people.

Actually, you can see orbits with an unupgraded tracking station, it's just that the orbit's grey, targeting stuff can only be done in the staging/docking view by clicking on the target symbol thing, the conics aren't patched, and you don't have access to maneuver nodes. (You can't track asteroids either.) Firstly, to clear up confusion, can you offer a better image of what's going on? The only thing I can think of that could be causing this is CONIC_PATCH_DRAW_MODE in your settings.cfg file, but it shouldn't remove orbits completely, and reinstalling should overwrite your settings.cfg file. Otherwise, perhaps a graphical bug? Also, have you seen correctly drawn trajectories before (that is, is this not your first time playing?) If so, when did this start?

Since I was a hardcore PlanetFactory junkie back in 0.23-0.24 and the new release of PFCE is too RAM-intensive for my heavily modded install, I'm deciding to give these packs another try (I abandoned my initial attempt due to issues with ATM.) I'll report anything I manage to find.

Does Hyperediting into orbit and then landing on it count?

Dammit; I was unable to reproduce it. Tried with this rocket and attached nosecones with symmetry. I had no problem whatsoever. Tried it again in 0.25 ... no problem again. JmoolZZ, can you post your Player.log directly after a nosecone-related crash? You should be able to find it by opening Console.app (in utilities) and going under ~/Library/Logs/Unity/Player.log (or just directly opening ~/Library/Logs/Unity/Player.log.)

I can confirm that I've been having this problem since 0.23 and have encountered it on completely stock installs. I usually just use the KW Rocketry nosecones since I haven't had problems with those. The crash happens specifically when attaching the nose cones with symmetry; if I attach them individually to every fuel tank everything's fine. Unfortunately I don't have a Player.log with the crash ATM, but I should be able to get one fairly easily tomorrow.

We'll probably need to hear for sure, but from the 10-ish words I've read about quaternions and orbital mechanics, they aren't very relevant for patched conics. Therefore it's probably not a patched conics issue, though it's probably Tracking-station-related somehow.

Sounds like the Hell Kraken, though I've never heard of it being triggered by anything other than hitting the ground weirdly. Strange.

I think I'm going to jump on the aero bandwagon; I'm fine with everything else.

Since I'm playing in 0.90, I suppose I'll have to use Boris's .dlls; I'll therefore definitely be using a hodgepodge of the two versions. In MM'ing this to work with other mods, I have a couple questions: 1. How do the Hydrogen tank's power requirements scale with volume? A bit of graphing based on Tweak_Near_Future_Tanks.cfg indicates that after about 10-14k of Hydrogen storage, they're about linear with volume; is this a reasonable approximation to what you used? 2. For usage with mods such as KSPX or Novapunch which add new nuclear engines, what values should I scale in Tweak_Nuclear_Engines.cfg to make them work roughly the same as your tweaked version of the standard NERVA with appropriately adjusted parameters?

Question. Are ElectricPropellants.cfg and EnginePropellants.cfg still read from if they exist, or are the fuel types hardcoded into the mod? Or are they just still there, but hidden away in some dark corner of the file hierarchy somewhere? EDIT: Derp, I somehow missed the Resources folder or dismissed it as technical files.

Downloading right now; I'll need to cut a few things (mostly the tech tree) due to the lack of Near Future Electrical 0.90. I'll report any problems or suggestions I find. For reference, I'm copying all .cfg files in the /WarpPlugin folder, along with the NF_KSPI folder (with Tree_Interstellar_NF_Integration.cfg, Tweak_Near_Future_Radiators.cfg, and Tweak_Near_Future_Reactors.cfg deleted due to the lack of NF Electrical) over a "stock" KSPI install and Boris_Barboris's fix. EDIT: *Slaps head* there's a new version of Boris's fix which isn't a mere fix but a full DL. Using that one instead. EDIT 2: Trying to find a way to edit the propellants in Boris's version; hoping they're not hardcoded.

Also, especially with Remotetech, there's the possibility that you're getting power, but you're draining your batteries more quickly than you're filling them.

If you insist on bringing two Kerbals, go ahead, but I'd recommend using a single Mk1 command pod (the black one) as it's lighter and generally better for space purposes than the cockpit-looking ones. You could also try stacking two of those on one another, though it would look horrible. It looks like you're using Skippers, 909s, and 48-7Ss. Skippers are amazing for everything, and the 909s are good where TWR isn't the limiting factor; the 48-7Ss have only the benefit of being very, very light and have fairly low isp. A Materials Bay and a Mk1 command pod are heavy enough that the 48-7S won't offer much benefit, so I'd recommend a 909 on the final stage. (I'm not 100% sure about this, though.) You might want to use something like your cockpits and science with a relatively small tank and a 909 underneath them, with 3-4 radially attached larger tanks with 909s. Decouple the outer tanks before activating the center engine; with decent piloting, this should make a nice Munar lander. Put a transfer stage beneath it to get it to the Mun after getting into orbit, and some sort of launch stage (the Skippers you're using, with Asparagus staging, should be enough, or you can activate the outer engines first and then decouple them and activate the inner engine.) The "activate the inner engine first" philosophy is equivalent to onion staging with a bit less thrust; it lets you burn off and decouple the outer tanks so the inner engine doesn't have to haul them around. While it's a matter of personal preference, I generally use a mod such as Mechjeb, Kerbal Engineer, or VOID for ship design, as you'll get delta-v readouts from them. A Mun landing takes about 5.5 km/s on the launchpad, whereas a Mun landing-and-return takes about 7-8 km/s, with good piloting. (These numbers could be off, and as a suggestion, most people who aren't named Scott Manley would give themselves a bit of extra delta-v in case of imperfect piloting.) Don't forget power. Either use solar panels or plenty of batteries. Also have a parachute if you're planning a return mission. (It seems like something one wouldn't forget, but believe me, it is.) Alright, that's the end of the design bit; now for the piloting. Practice with the Navball controls in test flights; you'll want to get the hang of them first. Turn on stability assist and you should be able to turn whichever way you like without resorting to the Pilot's abilities. Try to get into an initially equatorial orbit by turning East; this can usually be accomplished by using primarily D to turn. Switch the Navball to "Orbit" mode temporarily and turn towards the prograde if you're not sure which way to turn. Burn to put your apoapsis on roughly the same orbit as the Mun without raising your periapsis. If you don't have maneuver nodes or patched conics yet, burn just as the moon's showing up on the horizon from your ship's point of view; this should get you a Mun encounter, and then you can get into Mun orbit just fine. If you miss, don't worry; keep time warping until you get an encounter. The mun has a decently large sphere of influence, so the chances of a chance encounter are decent. Make sure to slow down the time warp near apoapsis so that if you do and you end up on a collision course, you have time to react. During the landing, be fairly reckless high up and start being more cautious lower down (that is, start being more careful to slow down lower down; be really conservative with fuel high up.) Use the Navball's retrograde marker to touch down with next to no horizontal velocity and maybe a recommended 3 m/s of vertical. Try not to tip over. This paragraph is if you want to do a return mission; if you have no problem stranding Kerbals on Mun, don't read this. During liftoff, you can start your gravity turn immediately as there's no atmosphere; just remember to burn up enough to keep from crashing into any mountains. Burn prograde until you're on an escape trajectory, and then, when you're in Kerbin orbit, bring your periapsis into Kerbin's atmosphere (I'd recommend 20 km.) You should be able to aerobrake without using any more fuel. Finally, quicksave liberally. EDIT: Don't forget to somehow get science back from orbit and the surface, as per the contract requirements. If you're not doing a return mission, you can just use an antenna.

Whenever I try to load any planet packs with this, the game hangs when the loading screen gets to the Kopernicus textures. There's no indication in KSP.log or Player.log that anything went wrong; it just hangs. It's probably not a memory issue, as Player.log usually mentions something about malloc and being unable to allocate region when that happens. The only other theory I could plausibly see is that it's ATM, but it hangs for 5 minutes on a single texture, which sounds a bit extreme, even for ATM. I'm not expecting anyone to have a magic solution to this problem, and I'll be working to try to figure out the relevant conflict, but before I do, does this sound like anything that's come up before? EDIT: Also, how's StarSystems compatibility? I heard there were problems, but it seems someone's getting them to work together.

See this post for an unofficial patch to make Kethane work for 0.90. You also might want to take a look at Karbonite for a potential "mod that works better;" they're both pretty much equal (though IMHO Karbonite+ is rather overpowered) but rather different. I personally prefer Karbonite but have nothing against Kethane.