Balto-the-Wolf-Dog

Pic dump to follow. ^A good illustration of how the vectoring works. I've found the thrust of sabres does actually appear to originate from the visual quadrant of thrusters. The geometry of the elevators allows me to alternately block the top or the bottom pair but never both, shifting my thrust line. Basically the wing structure is a pair of big stock wings, the first clipped forward into the fuselage to produce a big swept wing instead of a broad airliner wing and a second positioned on the base of the first and angled to produce a forked tail. Another, smaller design that does use procedural wings: A third design, since I mentioned boxwings. This one a large boxwing that uses pieced together procedural wings. Great lifting capacity, decent range, solid stability.

Honestly in my case it's more of a geometry thing. I have a habit of building unconventional wing structures that don't always work out in a reasonable way to stack. I'm a big fan of boxwings, among other things, and recently forked tails. Turns out that design produces great area ruling for the size and is extremely stable. Elevator design also provides for the alternate blocking of the upper or lower thrusters on the central sabre engines, a kind of crude thrust vectoring system. I love the performance I've gotten out of it, I just wish I could use procedural wings to avoid the ugly overlap midships. Any advice on how to put that together with what we have?

Is there any chance of an opt out on the sixteen size limit? It's really a bit too small for some scales, and I generally use this kind of thing to avoid high part counts. Otherwise I much prefer this to the other procedural wing system.

I would similarly appreciate that. B9 procedural wings are frusteratingly limited in scale

I haven't had too much trouble with stock trajectories and FAR. Usually just deorbit so my stock trajectory is aimed on top of my target. The glide ratio and drag application tend to balance out nicely as long as I modulate with angle of attack

If the issue is aerodynamic failure the first question is if you're using FAR. Regardless it's probably because your entry profile is wrong or something is fundamentally flawed in your designs such that they fail under high dynamic pressure (mostly if its a "yes" to the FAR question) In the first case come in shallower than you are. It doesn't take much, the drag will do the work for you. If you're coming back from a moon or extrakerbin planet try to aerocapture. You don't need to land in a hurry; get yourself a shallow periapsis around 30km or so and be patient. Aerobraking with literal airbrakes/high angles of attack is advisable at those altitudes, though usually difficult to maintain stably in denser air. You can bleed a lot of speed that way without much heat buildup and hold off your descent while you're at it, preventing further heat build up. If you're patient with it you should be able to avoid overstressing the airframe, though a well designed one, even in the case of very heavy spaceplanes, can be good for in excess if ten g's per my experimentation if applied somewhat gradually. If it's an airframe issue, it could be as simple as needing more struts. The more parts you square off to other parts the better you're going to do. I haven't found intentional flex very helpful in KSP. If not simple strutting it could be poor transonic design resulting in extreme drag when coming in fast (another FAR thing) in which case try to build more gradual curves. If its pretty, FAR will probably like it. Similarly loss of pitch control (FAR or otherwise) usually results in very high angles of attack and as such high instantaneous g-force. That would be due to poor center of lift/center of drag/center of pressure location vs center of mass, possibly the result of burnt fuel in space (only jets burn evenly in most cases). As long as your weight is forward your balance ought to be manageable.

Do flaps under FAR actually do a chord change calculation? News to me.

Drag-rudders. The b2 is a heavily automated aircraft. Essentially there are speed brakes on both wingtips that open more or less than one another to instigate yaw by way of differential drag. Unfortunately I haven't really found a way to get KSP to do that. If control surfaces were bound by the player rather than automated it could probably be done with KoS (along with a lot of other cool things) but alas. As to the lift issue, I never experienced it, so I think that's a farrem/lack of farrem thing.

After some inspection I honestly can't say it makes much sense to me. That said, my hypothesis appears to have been partially correct as, at least with Ferram, the fault was with both the v-tail and the boomed conventional tail. I reverted all the way back to the original B2 design (without canards etc) and everything preformed correctly at all airspeeds including high mach. I replaced the V-tail structure with stock ailerons inverted and built into the engine nacelles to provide the vertical drag of stabilizers. I don't consider it cheating because KSP fails to simulate the washout that allows wings to not skid as much as they logically should and also lacks the computation to employ drag-rudders to compensate for what skid there is. The present aircraft can be found here: https://dl.dropboxusercontent.com/u/61950362/SPIRIT%20MK2-2.craft ^the hidden "vertical stabilizers" That works, at least with Farrem.

That could have something to do with how KSP is trying to map your control surfaces. Your aft vertical stab is going to create quite a big of lateral drag back there and the engines have little arm on the center of mass by comparison. That may be causing a bit of cross control with the engines trying to force the tail around and the tail pushing back, but I wouldn't expect that to create the effect you're describing. It sounds much more like the engines have some how ventured ahead of the center of mass, which, looking at your design, it looks like they may have. That would explain the counter control and the takeoff spin you're encountering as the elevators try to fight a counteracting thrust vector right where they're applying their torque. Generally KSP corrects for this automatically (reorienting the thruster control mapping to reflect leading thrusters) but this might fail if the CT is very close to the CM in general. It should also be noted that if the CT is very close to the CM then the thrust vectoring is pretty much just generating up force or down force along the vertical vector rather than pitch torque. I haven't tested it yet but I will. In my case this will be with FAR. More editing: That vertical force thing applies laterally too and can cause the same effect without your engines mismapping. If your engines vector to the right for what would conventionally be a yaw to the right but are right on top of the CM or near it, the whole aircraft will be forced left by the resultant vector. Because there is little arm between the engines and the CM there is little to no rotational force and this is more akin to a skid. Your vertical stab will then catch a drag force out of that leftward slew/skid and instigate a resulting yaw to the left though you ordered one to the right. If you throw a paper airplane or model airplane or whatever to the left rather than forward or forward and left, (as your engines would apply a force when vectoring right you'll notice the air frame naturally enters a leftward yaw and ultimately bank. A good way to picture what your engines are doing (or what I think they're doing) is to push a pencil about by the eraser and notice how changing the angle at which you push turns the pencil dramatically. This is how vectored thrust is supposed to work, but this happens when you apply the force from a tip and not near the center. If you try the same thing several times, each moving your finger further towards the center of the pencil, you'll notice the turning becoming increasingly less responsive and the pencil doing increasingly more sliding.

Is that running with or without Farrem?

That's exceedingly impressive and I'd love to attempt a replication. Are there any mods besides infernal robotics involved and if not how did you achieve the stability and seemingly automated reciprocation in flapping?

I've been working with this concept for the majority of the last ten hours or so with varying success. So far I've minimized (though not eliminated) directional noise from the thrust and managed to get it relatively consistent, but I haven't fixed the reliability issue. My present design looks much like the one attached to the car and, on its own, happily generates about fifteen g's of acceleration. When mounted to anything much larger than a pod, however, the landing struts like to fail into the stuck down mode. Any advice? The largest vessel I've been successful with is the following, and even then the gear fail occasionally: I built a multi-nacelle vessel prior on an older engine design. That was similarly quick to accelerate and managed a larger payload, but at the expense of extreme directional tendencies.

I'm on the fence about plenty possibilities for this game, but when it comes to basic mechanics and behavior I am distinctly hopeful for proper aerodynamic simulation and effective reentry heat risk. KSP is, at its heart, a building game, and what parts of it aren't are space flight simulator. These attributes are what set the driving mechanic of the game: tasking the player with solving problems. Getting to the mun is one such problem. The player places his or her own goal there, then sets out to solve the problem with creative engineering and creative flying. What this means is that nearly all of the "game" part of KSP is derived from problem solving; so, simply, more problems = more game. Reentry heat is an additional problem to engineer a solution to, and what separates it from the whole "random failures" frame of mind is that it is also a fair problem. I don't see how it could be any less an acceptable manner of challenging players to build better rockets than simply trying to get places. That said, I see no reason why such specifics of realism shouldn't be optional. As far as aerodynamics are concerned, when it comes to vertically launched systems, its another avenue of challenging players to build better, more aerodynamic rockets. For aircraft, however, the issue is a little more fundamental. Vanilla KSP aerodynamics aren't even remotely realistic. I was able to push an engine-less craft from the surface to kerbin ejection with nothing but creative control surface placement and without part clipping. Disregarding obvious glitches, even reasonable aircraft preform more like shoddily constructed paper airplanes than aircraft with lifting surfaces. As a real-world aviator I can say with some credibility that Farrem is a decent approximation of how things should preform. Imperfect, but reasonably close, especially for an engine allowing you to cobble together your aircraft out of junkyard parts and others found laying on the side of the road. I would be satisfied with an official implementation of an equivalent system. Until then, I shall continue to hold myself over with Farrem.

Perhaps I'm missing something, but I can't bring myself to understand the position of those who are both anti-extrasolar and anti-colonization. Such a position severely limits KSP to being, well, basically what it is right now. Sure, the economy and science mechanics can be expanded upon, but ultimately progression is capped by the thorough exploration of the Kerbol system, which isn't actually that hard to do. There's always the option of more planets, but just how crowded do we plan on making this system ultimately? Just proper colonization could add a considerable amount to what we already have and the future Jovian planets planned, especially if the "no aliens" rule isn't take to mean "all of space is entirely dead" and is instead taken to mean "You won't run into any advanced civilizations that turn KSP into a combat game". The search for some form of life is and has been a major motivator in our own space programs and there's little reason to believe it shouldn't be similarly paramount for the Kerbals. A lot could be added to both spaceflight and surface operations if you went to another celestial body with the intent of looking for something, regardless of it's being bacteria, a certain kind of mineral, or whatever; as opposed to planting a flag and leaving, or sitting there for all eternity as warm memories of Kerbin fade into distant images and are ultimately forgotten. It seems to me that the primary point in colonization would be, thus, to look for things. I do support mining and the synthesis of fuel, as industrializing space is a very real concept as well, but I am of the opinion that the primary purpose of colonies should be to bring us something we don't already have, even if it's just a new type of fuel or something. If I had my way it would ultimately provide a means of synthesizing alcubierre warp technology to continue research on the interstellar scale, but as I understand such concepts have been officially dismissed despite their mathematical viability. As for this method of colonization, it seems to me it cuts some corners around what colonies in KSP could really be. To date, KSP has been about building rockets, and I see little reason why it shouldn't also be about building colonies, but player involvement is key to that. I would favor a method that involved delivering specific components as payloads that may then be assembled on the surface in EVA, each having varying purposes such as habitation, life support, food provision, research, etc. Naturally these elements would be relatively heavy and bulky, making them difficult to launch, transfer, and land safely, and thus providing the game with a naturally occurring phenomenon akin to a difficulty curve without any hard-coded RPG elements like leveling.

Unfortunately just "letting them" would wind up worming its way out to the rest of us through general operations unless it was a very slow cline. A mission out to Jool takes around two years round trip usually, I think I'd find it pretty anticlimactic to go off on a giant science escapade to the far planets and return to discover my LKO station had generated as much or more science in the mean time, a condition that would be difficult to avoid. I am of the mindset that the lab module should be a receptacle for experiments as suggested earlier, as in you launch experiments designed for it (like a tank with that octopus thing in it) to see how they react to conditions in space over a long period of time. Yes, time is then involved, but its still on a per-experiment basis and requires launches to facilitate it like a lot of research aboard ISS. There's also the matter of resupplying the station that could be added to bring in balance, something that would come accompanying life support mechanics, obviously.

I've wanted something exactly like this for quite a while. A full on calculator (possibly associated with the planned observatory) would be wonderful and probably appropriate for the game. Using third party software is obnoxious and I doubt having users guess their phase angles could be considered a picture of realism. Presently mechjeb will give you the phase angles in degrees (I have a window devoted to it), but it really strikes me as something too fundamental too be third party. Frankly I wouldn't mind something as detailed as Orbiter's TransX serving as an MFD based alternative to maneuver nodes, but TransX, while capible of being extraordinarily accurate in transfer plotting, is pretty complicated.

While I've not much involved myself in the forums I've been playing KSP for quite a long while and put my first aircraft on laythe back in 0.17, making routine milk runs henceforth. This is great, except it makes for a lot of switching over to a distantly orbiting buoy to wait on phase angles before ejection due to the altitude limits on time compression. All in all the system works, but it's terribly inconvenient and makes it easy to overshoot your ejection window. In my mind the ideal solution to the issue would be to allow instant warping to a particular date like one might set a clock ahead. Given that all entities not being directly interacted with are on rails, this should be no less doable than conventional time warp. It is worthy of note that this may be done in Orbiter through the editing of save files without fault, though orbiter also lacks an actual implemented tool for doing it to my knowledge. As far as balance is concerned, I don't see how it would be any different than standard time compression.