Diche Bach

One thing I didn't get before reading this thread and the wiki on reaction wheels: sounds like there are actually four or more spinning thingies inside each of those cylinders we snap into place in the game called "reaction wheels." It seems less counter-intuitive when I consider that.

I'll read this as, "I'm a twit." Have a good one.

Make a mod that does what you want. Squad's design is fine for the stock game.

Great to know. Thanks Slashy: So for my next question: What is "Authority Limiter?" (which I'll abbreviate as AL) It had always made sense that these control how large of angle the control surface can flex into from its retracted state. So a pair of ailerons with AL = 150 will generally produce much more rapid and erratic roll than those set to 15 . . . but I'm now thinking it is more complicated than just that. I've been opening up and pinning the part config panes for all my control surfaces and tweaking them in flight to try to learn more. Of course, when I build a new design, I do this during the first few test takeoffs to determine values that suffice for takeoff. Generally for takeoff I plug in values about like this (for most aircraft): Ailerons: ~2 (1 if I can manage to hit that number on the slide bar) Flaps: ~40 (flaps only seem to function like flaps in certain instances though, so I rarely make much use of them these days) Rudder: ~2 Elevators: ~40 Observations: 1. Tweaking elevator's AL up during time warp can be used a bit like "trim" (and seems to actually work _better_ than the Alt-S or Alt-D key combo). Get to an altitude/speed/heading desired, pitch up a bit, and then enter time warp. As the ship pitches down, use small upticks in the elevator's AL to get it to keep at a reasonable upward or level pitch in flight. 2. Values of -100 on ailerons and rudder are viable, and in some instances I've found these to be preferable, though not always (the characteristics of the vehicle seem to change a lot depending on altitude, fuel expended, velocity, etc.). In one instance, I was able to get the ailerons to function about like I would expect them to (very smooth and gradual rolling) by setting them to around -100, but in other instances changing this value < 1 seems to cause problems. Rolling is my nemesis. I have a few designs that seem able to maintain a stable roll orientation (sometimes) but generally the ship always wants to pitch one way or another, until at least half its fuel is exhausted. Any tips in regards to that stuff?

@Papa_Joe any reason to fear that that update might break a save? I'd think not, but figured better to ask first before updating and ruining my save. Of course, I realize there is never any guarantee on such things, particularly with dozens of mods installed . . . Had some issues with the USI Survivability (formerly DERP) parts that RoverDude made. Specifically, the Derp Escape pod and service ring (basically looks like a little lander ring with a couple RCS thrusters and a beach ball with a Kerbal inside . . . inflatable, comes with some "supplies" and apparently made of inflammable materials [asbestos-permeated polyester?]). CLS wouldn't recognize these, so I couldn't transfer Kerbals from the space ship to these, and just reloaded and changed to "allow unlimited transfers" in the editor. Not something I'd necessarily expect you to address, as it would probably behoove RoverDude to make his parts CLS compatible not the other way round . . . but I thought I'd mention it. The "allow unlimited transfers" option is a fine solution for me.

So 0.6 on the dampers and max on the springs. Heh, that is more or less exactly the opposite of what I'd been trying (spring 0.3 or less; damper 1.5 or higher). Shame there is no documentation to clarify what these user-configurable parameters "do." "Spring strength" does that mean "how large of recoil the spring exerts when it undergoes acute increased compression?" or does it mean "how much compression the spring can resist before it undergoes acute compression?" Damper strength . . . damping of what exactly?

So I was fiddling with this: got a contract to haul 14 tourists and three crew up for a 40 day "Space Camp." I figured if I could manage to de-orbit and recover the tourists with these, then I'd have the beginning of Kerbal Space Station already up there when that mission comes along. However, not sure how to use it, or maybe it is just that a tourist cannot control it? I noticed as I was setting them up to operate, and transferred the tourists into them that the tooltip said 'Tourist onboard, No crew 0/1" or something along those lines. Guess I'll just have to go back to the pre-test save and deorbit the whole Space Camp vessel ADDIT: I did get it to work properly with a "crew" Kerbal. Pretty neat! Took me a second to realize the derp service ring's RCS is only in four directions, but pretty easy to turn it so one side faced retrograde and burn sidewise. I suppose it wouldn't be too much of a trick to change some values in a config file to make the derp pod function with a tourist? Or would that require changing the entire "tourist" class/attribute for the entire game file? I guess the "heat tolerance" values on these parts must be really high? I deployed the parachute before I decoupled the service ring (I had it attached to a part called "radial attachment" from some other mod, which seems to get recognized as "crew hatch") and left the values at the defaults (2500m and 0.0 pressure if memory serves). Was surprised when the chute went into partial deployment at about ~25,000m and the pod was still shrouded in some flames! Anyway, the Space Camp was a success, we just de-orbited the entire space craft, and one of the KSP Kerbal crew was kind enough to test the derp pod so I have a sense for how that works. Will definitely be putting these on all my future space stations and some ships too.

I do not recall for certain, but I believe you can adjust the proportion of build cost you retrieve from scrapping. I play on slightly modified "easy" (rates for everything except heat on "easy" level, heat and everything [the stuff on upper left of career game setup pane] else on "hard" level) and I still find that it is sufficiently challenging. My funds fluctuate between 2m and 20,000 as I go through cycles of upgrading/building/embarking on missions then repeat. Two other things to note about the science farming strategy you describe: 1. there are other faster ways to achieve this that do not involve KCT: certain scientific experiments are repeatable it seems (I had Jeb and Bob in a rover over in the desert by the Pyramids and as they were buzzing along at 10m/s I was literally clicking thermometer, barometer, for 5 and 12 science every minute or so, and then transferring the science from those instrument modules to Bob (the scientist) with Ship Manifest). 2. If you are constantly building then scrapping to farm science, then you are tying up a build queue, and making no progress on completing missions = stagnant funds and reputation, so even if your scrapping does yield 100% funds, you are still facing a certain kind of tradeoff. The mod is remarkably well balanced overall and really well done too. It almost turns KSP into a strategy game.

Cool. I was thinking "Kerbal Craft Comparator" doesn't sound too bad. Big words seems to be a Kerbal thing I will let ya'll know when I get it done and make it available, though it is likely to be very bare bones to start with. The C## redo will take a bit longer, but that can follow as time on C++ this fall allows. Long-term I think it could be a very intricate and detailed plugin, so it will have to grow gradually from basic functionality that covers a limited set of indices to more and more. Guess I better get crackin' on the pseudo-code tomorrow morning

Not unless you got most of your body burnt terribly in a magma accident, and breath heavily . . . Why did that "LaLa" brand yogurt smoothie say "Tropical Mango?" Is there a Temperate or Sub-Arctic variety of mango I haven't heard of?

Maybe post a few screen caps of your directory structure for those guys? Enough to show all the files relevant to the two or three mods in question? (FAR, SR, RSS, etc.). if they can see how your stuff is setup, and you confirm it functions without issue, that might be enough to help them to troubleshoot their install.

I have noticed similar things, and while I haven't analyzed as thoroughly as you have, your conclusions seem like they might be valid and I applaud you for the formula! I had a Minmus Lander probe that wound up orbiting the sun because he seems to have missed his burn or done it improperly or something. I atttibuted it to either me not understanding exactly how the RT flight computer works, else me failing to allow it to stop time warp, else attempting to stack maneuvers before and after an SOI change (which I'm still not sure if that is a generally bad idea in the game in general, or especially with remote control). I've found that: as long as I am there "watching it" in flight mode when it does its burn (and do not warp past the time for it to do its maneuver) everything works fine. Amazingly well in fact. So I'm a little bit skeptical that the problems you've encountered have to do with failing to account for mass change during the burn; if that were the case, then I would've expected to see poorly executed burns by the flight computer a lot more than I have. Instead, like I said, as long as I jump to the ship when it prompts me and slows down warp, and then do not warp past the burn, the flight computer seems to execute maneuvers setup in the flight planner perfectly, better than I do in fact. But these are just anecdotal observations of course.

During career play, I've found that I frequently have need of something that (as far as I know) does not yet exist for the game: a pane which summarizes ships according to parameters specified by the user. For example, in my last career play (now archived) I had about 8 or 10 different "ships" (some of which shared significant portions of their launch components) which I'd created during the course of 2 years of in game, in order to explore different stuff, and also to fit the needs of particular missions. In future, I probably won't built quite so many different models, but even so, the general principle applies: one tends to build slightly different models which have strengths and shortcomings in different areas. Lets say I wanted to know: which ships do I have in my directory which can carry at least 5 passengers, and have dV > = 5,000, and include a docking port . . . Ah I see, I have two different models that fit these specifications the Wildcat and the Zenith, but the Wildcat is 15,000 funds cheaper while the Zenith has slightly higher TWR at most stages . . . An initial prototype would barely scratch the surface of all the possible comparative indices, but as long as the initial design was coherent, it would seem that with enough typing, pretty much any and all characteristics could be incorporated, allowing a user to compare any two or more ships on virtually any attribute that is present in the game. An in-game screen which allowed the user to compare and contrast ships based on whatever set of parameters he/she wished to compare would seem to be the ideal with an app that accessed the files, but did not run through the game screen would be useful but less than ideal. So, orthogonal consideration: I'm presently finishing up a Java III course, and I have until Aug 31 to apply what I've learned in a small capstone project. Originally I was working on a checkers game application, but I found this to be so dreadfully boring and relatively non-instructive (not to mention NOT useful) I've asked and received permission to do something else: A Kerbal Ship Summarizer Screen. Given that the craft files are basically just txt files with special post-script file type, I think it shouldn't be too much trouble to get Java to read them, and make use of the fields in them in order to present the information there to the user in a set of dialog boxes and tables (which along with exception handling are the main things it needs to do to fulfill the course requirements). Yes, I know the game is C## based, and I have some C++ skills (doing an apprenticeship in data structures and AI design in C++ this fall), but this course is in Java, and I reckon whatever one can do with Java source code one can do with C## (more or less), so . . . if I keep it very simple, just enough functionality to fulfill the course requirements, then rewriting it into C## this fall and expanding it into a true mod would seem to be tenable. What would be neat is if I could provide it to the Kerbal X guy, and/or run it on the web. So the prototype will be in Java, and if there is not much interest in such a thing, then it might just stay that way. But I will strive not to make it so complex and fully functional that using it as an exercise to learn how C## works is too difficult; thus if there IS any interest in such a plugin, and people tell me, then I'll have synergistic motives to do it up properly so it can run as an in-game plugin, and also as a web-based program (e.g., for Kerbal X, etc.). Any suggestions or feedback on these ideas? Obviously, I'm GOING to do this first incarnation in Java, because I don't want to fail the fricking course! So feedback or not, I'm going for it. But if anyone has any good suggestions that can put it into the right direction(s) for longer-term development/expansion, much appreciated. Suggestions on the name for the mod are particularly welcome, as "Ship Summarizer Screen" just doesn't have much cache.

So technically, if you execute your gravity turn by yawing to starboard, it _is_ yaw, but it is called "pitch" to keep it more confusing/consistent I'll have to create a Kerbal Engineer template that includes all the pitch/roll/yaw output that are there for aircraft and use those when I launch a rocket and see what it looks like. I also enjoy how the space ship in orbit will whip around 180-degrees at some particular point in its orbit (only for certain types of high-inclination orbits I think) while on 50x warp speed First time I saw that I was all stressed out . . . then I realized it was just buzzing right along fine and did it again next lap! Using stuff like this, someone could do a pretty hilarious montage video with Yakkity Sax as the theme song.

Observed something last time I had the game running that I think is indicative of why the game makes getting the hang of "flying" a rocket relatively easier than flying a plane. Jeb and Bob were in a rover I built: totally basic frame of girders, two command seats on the top, one quadcore (from universal storage) with an alkaline fuel cell [generates electricity] and three Science Jr. (Uni Storages compact "hex" version of the materials science lab) towrad the front. Tier 1 ladder on one side (with small girder and additional ladder to allow the kerbal to make it over the lip of the climb), four of the Tier 1 rover wheels, two Mk1 command pots attached to the back with cheapo sepratrons. Even with the pods still attached, a nice balanced design that suffers little to no tendency to roll or topple in any particular direction. Launched it, Jeb EVAed and managed to hop from the Mk 1 hatch ladder and get into his command chair . . . Bob EVAed but stumbled and fell on the ground, his head very close to the right rear wheel (maybe even clipping into it a bit even). When Bob got up he tipped the whole damn thing over! In sum, the physics are a bit whacked out here and there, and I think this is why airplanes have to be "juussst right" or they act like boomerangs/bolos/catapults. The physics probably reflect what is necessary to get rockets with their respective mass, dimensions, thrust, etc. to behave in ways that can pass (more-or-less) as "normal," but the unfortunate side effect is that, many of these same algorithms applied to aircraft (or kerbals and rovers) are hair-trigger and produce ridiculous effects like a dude stands up and tips over an entire car with the force of raising his head.

This is exactly the answer to question right here. I don't think the difference in game has anything to do with "properly reflecting" the real world difference in how challenging it is to fly (or design) an aircraft vs a rocket ship. The game was initially designed as a rocketship game and it works great for that. It works adequately for aircraft too. Indeed, when combined with the fact that one can design one's own aircraft, and that there are plenty of ways to work around the problems inherent to the game design, one might even say that: planes are not harder, they just have a more advanced learning curve. I think the mistake Squad has made so far is to fail to provide _really_ good stock models for people to play with. I flew a couple of those, and glanced at the rest and frankly they all stink. Perhaps they were not so bad several iterations ago when they were first added to the game, but assigning one or two of their best aircraft design staff members to: (a) design three to seven (one total beginner plane, that uses the lowest tier techs; one intermediate, one advanced, additional at each level and/or a spaceplane). (b) do a Youtube or three in which they walk the viewer through how these models are designed and why, basically use them as an example of how to effectively design a really good basic plane.

Thanks guys, I didn't know that Alt-tabbing out had a negative impact on memory usage. To be honest, I guess I've been spoiled by recent games like Stellaris and Fallout 4 where one nearly has to try hard to cause the game to perform badly, and even then crashes, lag and rendering glitches are rare. Is this just a consequence of using C## as the basis for the source code (instead of C++)?

LOL, I think the game was designed to be a rocket game, thus the learning curve tailors to that. Having played a few other flight sims, I think the way the physics engine works for airplanes is "not quite right" . . . or at least, it makes it more difficult to get it "just right." The gear, the balance, the angles . . . on a plane it all needs to be within a narrow margin of error for the plane to fly easily, but it can be done. The stuff some of these guys taught me in this thread helped me a crap ton. I went from a plane that was a constant struggle, to ones that fly damn well. Including a big ass liner that could make it half way around Kerbin with 5 passengers, and which was so stable, I literally just got it into the air, put it on 4x time warp and walked away. It just kept on doing its thing! (will have to post that craft file one of these days). But lets keep in mind here: what we are doing in KSP is a lot different than any other flight sim of which I'm aware: DESIGNING planes, then flying them, versus just flying them. Constrast this with a rocket in KSP: yeah, its difficult. But the margin of error just seems less. MOAR boosters can solve a lot of problems, though more refined techniques are generally better at it. Not so with planes: brute force generally is not an option (though the guy above mentioned setting up a plane with a TWR > 1 and yeah, that does seem to make it a lot easier doesn't it).

I don't care what anyone else does with their KSP install. Mod in dragons and power your space ships with unicorn farts, if you enjoy it, that is great. It's a single player, game so my mentioning of "exploit" as merely meant to refer to a personal decision about whether I'd consider it in my own install and I make no presumptions about judging anyone else's playstyle, or specific permutation of mods/add-ons. Like I said, " I'd be interested in that too, though I'd have to think on it whether I'd consider it an "exploit" or not."

So it seems to me the solution to the space plane paradox: behave like a plane until that is no longer tenable, then behave like a rocket, i.e., go totally radial (or nearly so) and kick in the rocket engines. I suppose the limitation here in real life is: getting enough fuel / big enough rocket engine up that high? Chemistry of explosives would thus seem to be the real limiter for space planes?

This may be a stupid question but . . . why don't rockets melt then? They have to accelerate through the atmosphere too, eh?

So here is a question: why does Kerbal Engineer considering turning a craft which is pointing straight up (radial) toward the east using the "yaw to starboard" key (D) to be "pitch" and not "yaw?" Is this technically correct? Technically, shouldn't "pitch" be the angle of the spacecraft relative to normal/anti-normal? And why does it consider the "belly" to be indicative of the heading at least until after one has pitched/yawed a bit away from a perfectly radial angle? Obviously it doesn't baffle me so much I am unable to cope, but those discrepancies just don't make sense to me.

I've found that the joystick is a mixed bag. My work/play station is a lazy boy with a large screen at my feet (when the leg rest is raised). Wireless keyboard and mouse on plywood lapboard. So where do I put the joystick in this arrangement (and it applies to a more traditional computer work station sitting at a desk chair with screen in front of face keyboard on desk and mouse to side: where to put the joystick?). Yes, you can put it over on one side . . . I have a piece of plexiglass strapped to my lapboard so that the suction cups of the Saitek will stick to it (somewhat). But this is less than ideal. The joystick should be in your crotch, else if it were a "steering wheel" design: in front of you. One day, when I'm rich and famous, I'm going to invest in a flight sim build that essentially mimics a real cockpit, but short of that, I find using keyboard for control of in flight sims actually BETTER than using a joystick slapped on the same surface as my keyboard mouse. Certainly cheaper, less risky, and less hassle than going for an actual flight license . . .

Downside = funds. Of course, you can adjust that too, but inherently building ships costs funds, so unless you are building craft that complete missions which yield funds (or have other sources of funds) then the finite availability of funds will act as a deterrent on spam building otherwise useless craft for science farming. Re: several recent posts that have observed apparently buggy behavior (KCT seemingly disappearing, but a couple of the other ones too). I don't think I've observed KCT disappearing, but I have observed weird things like: click the science tab in Space Center, screen flashes, and I'm now "in" the science section, but the screen does not change to science pane, it stays in the Space Center. Moving the mouse around causes the tech nodes of the science pane to flicker in and out but not enough to manipulate it. Similar thing in VAB, sometimes (for reasons that remain cryptic) the menu bar, the parts tab, etc., will just flicker out ("disappear" from view). Moving mouse causes them to come back, and it is workable but not ideal. A reboot of the game (from launcher not from main menu) "fixes" this. I do not know that this is an issue with KCT, but it seems like a possibility and it is remotely similar to some of the other issues described. Given KCT "exerts control" over the appearance of the Launchpad pane (and the behavior with the things flickering in and out closely resembles that which occurs when one clicks on the Launchpad tab, it flickers briefly into existence, and then the KCT control panel appears) it seems that some of the code in KCT might be underlying this transient bug. I have not found it to be game breaking, and a reboot always fixes it, so I've been lazy on trying to debug it.

By this you mean: add data transmission and "active connection" functionality to things like the "Little Brother signals intelligence" telescope, etc.? Sorry, cannot help, but I'd be interested in that too, though I'd have to think on it whether I'd consider it an "exploit" or not.