ferram4

@narcilian: Can you post a copy of the plane with that problem? I don't use the advanced canard as much so I want to see what's going on. I've been working on something to figure out L/W, I just keep getting wrong numbers. When you build a plane, keep in mind that you can't fly with a large angle of attack without them stalling. @cardgame: Use the CoL and CoM markers in the editor. Try selecting the entire plane and pitching it up and down in-editor to see how things change. The CoL might be moving forward due to something stalling. Here are some examples for v0.4: http://www./download.php?9m6yy75d8xanif2

Look for a part folder named "Aileron." That's what corresponds to StandardctrlSurface. It might be that you have the part.cfg in there from the mod download, without any of the models that I expected to be there from the stock game (I didn't want to make the download larger than it had to be). Try re-downloading 0.17 or using the patcher since it seems like you're missing a part, which would be the source of the problem.

I've tried but am unable to reproduce the bug. Would you mind posting the craft that you had the problem with? It would be very helpful in finding out the source of the problem.

@Cardgame: What plugins are you using? If you're using something beyond Lazor System, MechJeb, or Protractor I haven't tested it out. Try running it on a clean install of 0.17 and see if that works. If it works, try adding plugins until it crashes. If you put up a list of plugins, I'll work on my end to find the error. @sproginator: Have you gone into the SPH and set the control axis for each of the control surfaces? By default, they don't do anything you don't tell them to do so they don't act at cross purposes during flight. If you're trying to fly a plane you already built, it may have slipped your mind. Although if you try to fly a plane that you already built, it might be unstable due to the change in lift models.

This is what you want to look at in the part.cfg: // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,0 Change the first 0 to a 1, and it should work.

V0.4 is up, get it now! Drag on airplane parts now behaves the way it should, mass isn't involved anymore. Also other goodies. But mostly the above.

Yep, the variable sweep parts from DA should work properly here. Granted, some testing will have to be done, since the stability of the plane will change a whole lot when you do that. So, as an update on progress, I've figured out a way to override the original drag model on fuel tanks and engines and so next update all remnants of the old drag model should be gone. (HOORAY!!!) It'll be up today or tomorrow, since I'm trying to balance the engines and drag to something reasonable. So far, I've got the TurboJet engine making ~50 kN thrust (as opposed to the 150 kN default) and two of them can sustain a plane at Mach 2.8. I need to work on the airflow values so it isn't overpowered at ground level. I also want to tune the Basic Jet Engine so it can break the sound barrier, but only if you design and fly your plane just right. I'm not even touching the rocket parts yet, since balancing that is another can of worms entirely. TL;DR: Next update is gonna be totally awesome!

Since this includes plugins, would you mind putting up my Ferram Aerospace Research plugin?

Okay, v0.3 is up. Bunch of bug fixes, some GUI work done. It should also play nice with Lazor System and MechJeb. Sorry Hyratel, saving placement will have to wait until the next version, but the GUI can be minimized. As always, bug reports are welcome, please give as much info as possible so I can find the problem. Edit: Didn't update download link. Is fixed now.

Mossman, you're mixing units. You're using a velocity of 3361m/s and an altitude of 670km. Further, μ is in km^3/s^2. So you need to run the calculations with v = 3.361 km/s to make it work. E = 0.37876 km^2/s^2 h = 2251.87 km^2/s e = 1.14375 θ = 29.0365 degrees Ejection Angle = 150.963 degrees. Hope that clears it up. Try carrying the units through the calculation next time and canceling them as you go. It will help you pick up common errors like this.

Well, I was able to confirm the Lazor-FAR problem Volt, and you're right: it is a GUI incompatibility. It's actually similar to a problem I ran into first adding the flight assistant window. I'll see what I can do with this but I don't think it'll be too difficult. As for the in-editor problem, I'll see about that, but I'm giving the GUI there a minor overhaul to make it more useful. Odds are I just forgot to make the entire window drag-able and the section that can be dragged is just a little too small. I should be able to have a new version up soon that fixes these.

Okay Volt, help me find this: Can you recreate it? If you can, would you post a copy of output_log.txt? (It's in KSP_Data if you don't already know) What other plugins were you using? The only time I've seen anything like that happen is when I'd get a part to throw a ton of NullReferenceExceptions (which was never the flight assistant stuff). When the flight assistant "spazzed" what did it do exactly? The only reason I ask is because if I can't recreate the bug on my end, I can't track down the problem and fix it.

Okay, I just tried messing with the standard canard, standard control surface and small control surface on a standard install and they worked fine. Were you using a joystick when that happened? Can you post a craft file that had this problem, since I don't think it's with my code (at least I can't replicate it from the description). Also, if you don't have any of the autopilots selected (so that they show the k values) then they're off. It is possible you're talking about the 1/4 second it takes the control surfaces to fully deflect, which I'm starting to think is a little to much. (Maybe 1/10 of a second? 1/15? *shrug*) It's supposed to be a smoother change in angle of attack for the control surface, more like a real plane, but I might have overdone it. And finally, what other plugins do you have installed? And I'll fix that error about "plugin" instead of "Plugins."

Version 0.2 released! Lots of new goodies for all of you, and 0.17 compatibility!

Klopchuck, that math would be good if not for the fact that lift in 0.16 goes with velocity instead of velocity squared, as well as mass erroneously appearing in the drag equation, so the range and endurance equations there won't work. As to your earlier point about the efficiency, I think that that is the percentage of maximum thrust that the engine is putting out, and I believe fuel consumption is constant for a throttle setting. Which means that you want to go as fast as possible at full throttle, regardless of efficiency and altitude. As for design ideas, I'd suggest these: Start with only two engines. More engines suffer from diminishing returns, since you double fuel consumption but only increase velocity by a factor of 1.4. Use more wing than you think. That helps in keeping a low angle of attack at cruise, which makes designing the engine attach angle easier. Angle the engines so that they are horizontal in cruise. Any thrust pointing down doesn't increase speed, and the wings should be keeping the plane up. With good design, you should be able to make it to the North Pole on ~6 Mk2 fuselage tanks and at ~450 - 500 m/s. Climb fast up to ~8k-10k, then reduce your climb rate and make sure that your engines don't asphyxiate up there. Hope this helps, good luck with your design!

Random, I'm currently working on something to fix that, in the mean time, you can switch the axis before physics starts, since you're just waiting there for a few seconds anyway. I agree, it's annoying, but it's currently a means to an end.

Update to version 0.15.9.1 "Liepmann", now with voxel-model based aerodynamics! ALL USERS: NO LOGS OR REPRODUCTION STEPS = NO SUPPORT CKAN USERS: PLEASE READ THIS FIRST Users who put issues on Github are awesome. Please consider being awesome. Original Review: Aerodynamic Failures: Building a spaceplane and talking about editor GUI stuff: Features Shape-Based, Vessel-Centered, Aerodynamics - Long, thin shapes drag less than wide, flat shapes, and smooth changes in body width reduce drag. The shape of the vessel as a whole, not individual parts, controls drag, so shape the vessel as you see fit. Emergent Fairings and Cargo Bays - The voxel model method FAR uses allows for the actual shape of the vehicle to play a role in how lift and drag are applied. Build a hollow shell, and close it up, and everything inside it will be protected from the airflow as it should. Wing Effects - Realistically adjusts lift based on wing position and configuration: wingtips lift less and drag more than wing roots. Stall - Passing the critical angle of attack suddenly reduces lift and greatly increases drag. Can put planes into tailspins, flat spins, and cause crashes. Mach Effects and Area Ruling - Lift and drag will vary as expected with Mach number. Supersonic planes will need to properly area rule themselves for optimum flight characteristics. Body lift - All parts lift: a fast enough brick will fly, if not that well. Download: Get v0.15.9.1 "Liepmann" from SpaceDock! Get v0.15.9.1 "Liepmann" from Github! Official FAR Craft Sharing Thread Post your crafts there, not here, please. Violators will have their posts moved by moderators, and will have everyone very annoyed with the additional workload for both moderators and me. The FAR wiki at GitHub The source at GitHub Shader and art assets licensed All Rights Reserved Source code and binaries licensed under GNU GPL v3 Part.cfg changes powered by sarbian & ialdabaoth's ModuleManager plugin. Interface with stock heating system and other mods interacting with the physics system powered by sarbian, Starwaster and myself's ModularFlightIntegrator Toolbar powered by blizzy78's Toolbar plugin. Installation: Copy the GameData and Ships folders into the KSP root directory and merge them with the existing GameData and Ships folders. Make sure that you copy over everything in the GameData folder. Serious issues will occur unless this is done. Changelog: FAQ - Common Questions and Solutions to Common Problems What does this mod do that stock KSP doesn't? Stock KSP calculates drag as a linear combination of the drag properties of a vehicle's parts, with some interaction changes to handle some of the most obvious aerodynamic interaction effects. FAR instead calculates the drag from the vessel shape as a whole, resulting in a more realistic model of aerodynamic drag and body lift. In addition, FAR accounts for wing shape, rather than just overall area like stock KSP. Finally, thanks to the overall vessel model, FAR can account for things like area ruling, where the vehicle's area cross-section must vary properly in order to fly at supersonic speeds (well, without MOAR BOOSTERS, in any case). I don't like my rocket coming apart under heavy aerodynamic loads; how can I turn it off? In the Space Center scene FAR has a debug menu that can be accessed to mess with a large number of the parameters. Under the "cheats" section of the first tab there is an option to disable aerodynamic failure. Does this plugin work properly with other mods / part packs? Sure; FAR figures out what the properties of the part should be based on its dimensions and some basic aerodynamic assumptions. If you use a mod and suspect that it causes unrealistic behavior, search the thread to see if it has been brought up / addressed by the latest release; if it hasn't, feel free to bring it to my attention. The only exception is with wing parts, which are more complicated and currently must have their properties specified manually. Does this plugin make payload fairings and cargo bays work properly? Yes, it will support any and all fairings and cargo bays. Even those that you make out of completely unrelated parts, so long as you close up the shape. In fact, to FAR, there is little difference between the inside of a closed fairing and the inside of a fuel tank part; they're both just as internal to it. I can't seem to turn off the Flight Assistance Systems... what's going on? In the Flight Assistance GUI every button that is pressed activates a control system; when none are pushed down no control systems are active. I suspect that you've actually created a poorly designed craft and that you're attributing aerodynamic forces that you're not used to dealing with to non-existent control inputs. Do I need ModuleManager and/or ModularFlightIntegrator? Yes; they are used to properly apply aerodynamic properties to stock wing parts and to interface properly with the game's physics system. Not using them will cause FAR to not function. I'm using the win64 KSP build and I am still too outraged to read the topic title or changelog, please mock me. Very well, I shall. Haha, silly person. Anyway, win64 is now unlocked for the foreseeable future. If it turns back into the crashtastic support-heavy nightmare it was, the lock may return, but I do not anticipate the need to do that.

Kerbtrek, I think you've just provided absolute proof that you are taking advantage of the fuel bug. That rocket should have the same delta-v no matter what throttle you use. Form wikipedia: where V_exh = Isp/9.81 m/s^2. Your argument boils down to "Isp increases to infinity at low throttle" which is only possible using the fuel bug. Try using the Hacky Fuel Consumption Fix:http://kerbalspaceprogram.com/forum/showthread.php/16439-0-16-0-Hacky-Fuel-Consumption-Bug-Fix plugin and redo that test. I think you'll get a different answer. ------------------------------------------ On topic, I like Mechjeb for testing rocket designs or launching massive, lag-tastic space stations. Otherwise, I prefer manual control, since it can be more efficient, since Mechjeb doesn't do proper ascent or descent optimization, and because it's more fun to lithobrake anyway.

Even though I have an Aerospace degree, I\'ve never actually done any math for KSP, I\'ve always just eyeballed my planes. As to your questions: 1) There is no reason that your horizontal force should be equal to your vertical force if constant stable flight is your goal. If you could elaborate it would be much better. 2) If you think your aircraft is too touchy, then it probably is. If you\'re placing the number of control surfaces based on what is necessary to get the plane to pitch up and take off, odds are there are too many. Try moving the main landing gear more rearwards and angle up some of the forward lifting surfaces, whether they are control surfaces or simple wings (use shift-WSADQE to do this, if you don\'t know how ) 3) Nacelles and intakes are aesthetic, so far. All the code is based in the engine nozzles. Efficiency seems to be based not only on airflow, but on velocity, since it diminishes as velocity increases. I think that efficiency is current thrust divided by maximum thrust, though I haven\'t looked at the code. 4) Yes, if you fly at a very low angle of attack, that will happen, since no wing part generates lift at zero angle of attack, but I believe they do create drag. 5) You can kind of do that, but it requires angling every wing part. It\'s honestly better to design your plane to fly at ~3.5 degrees and angle the engines on the body. Hope that helps. I haven\'t looked into the math of the aero stuff in the game, since the aerodynamics are wrong (drag force based on mass, lift proportional to velocity instead of velocity squared.)

Here\'s an example of a (fairly large) plane I made that works, since seeing might help: By 'permanent loop' do you mean that it just backflips when it gets into the air, or that it starts to do a loop that you can\'t pitch down out of? If it\'s the former, the plane is unstable and you need to move the wings further back. If the latter, you need more control surfaces at the front/back of the plane. For engine placement, yeah kind of like that. The engines don\'t have to be too far below, but it helps a lot pitch wise. What I mean by the WASDQE keys is that if you have a part selected in the SPH (guess I should have been clearer ) before you place it you can change its orientation using those keys. If you don\'t hold shift it varies by 90 degree increments, if you do hold shift it varies orientation by 5 degree increments. Very good for innovative designs. Based on the picture you posted, I\'d guess that the plane can\'t fly until it goes off the edge of the runway. You have a little too much fuel up front. Makes it a lot nose-heavier than I thought it was. Move them back a little. If those vertical surfaces near the front are completely vertical, get rid of them. They make the plane more yaw unstable and more likely to spin out. It also looks like you have a little too much wing near the front. Makes me think it\'s unstable. The picture was taken with SAS on, correct?

I believe that Vanamonde is referring to the fact that when the center of gravity is put further forward, the plane can\'t pitch up as much. And while he\'s right, it can\'t pitch up as much with a far-forward center of gravity, it makes the plane much more stable in pitch, so long as the center of gravity isn\'t too far forward. Vanamonde, try placing the engines on your plane below the main fuselage and the center of gravity. The way you have them now, the engine thrust makes the plane want to pitch downwards, whereas if they are below they will give it more of a pitch up tendency. As it happens, they also tend to be good places to put the main landing gear, since it should give the plane a lot of room to pitch up on the runway. If that doesn\'t help pitch the plane upwards, you can try using shift-WASDQE keys in the SPH to angle your lifting surfaces to try and give it more of a pitch up tendency. And as a final thing, if you still have problems with the tail crashing into the runway, put a single landing gear on it. It doesn\'t need to actually support the plane at rest, just keep the tail from exploding. Hope this helps.

At the very beginning of reentry, radiation will play an important contribution simply because the temperature difference is large and radiation heat transfer goes with T^4. Since most of the heated layer will be very close to the spacecraft, I\'d say that assuming the system can be modeled as a pair of infinite parallel plates wouldn\'t be too far off. That would make this equation work for radiative heat transfer: I suspect that adding this into the calculations would bring the peak ship temperature above 2000K and at a higher altitude. I don\'t think adding this bit would be difficult at all. Very nice work PakledHostage! I hope your work goes to good use.

Go to the map view and bring up the navball there so you can control the ship from the map. Then during launch, do your gravity turn normally but watch your apoapsis on the map view; cut your engine when apoapsis reaches the altitude you want. At that point, wait until you get to apoapsis and start your circularization burn facing prograde a few seconds before you reach it. If the apoapsis starts to run away from you, stop the burn, warp to catch up to apoapsis, and burn again. Repeat until the orbit is as circular as you desire. Remember to look at the map view religiously, it tells you everything you really need to know about your orbit.

The gravity turn is only the optimal ascent profile if there is no atmosphere, though in a dense atmosphere the gravity turn makes sure there are no side forces on the rocket, since IRL rockets aren\'t built to handle shear stresses (but apparently Kerbal rockets can handle falling sideways at 150 m/s *shrug*). I think that the optimal trajectory actually depends greatly on how much control authority the rocket has at any given stage; if it has a great deal of control authority, than going straight up until ~10k and pitching over sharply is efficient, since it trades air drag losses for smaller steering losses. If the rocket is more of a giant space station carrying behemoth, pitching over earlier (~5k) and taking a smoother trajectory is better, just because it becomes easier to control. I tend to pitch over between 5 and 10k, depending on the rocket and I try to smoothly pitch until I\'m matching the orbital prograde marker at ~60k. I tend to try pitching over faster when it feels like the rocket is high enough that the air doesn\'t matter too much anymore and picking up speed is more important. You should probably mention to beginners that 3 fuel tanks per large LFE results in a TWR of ~2 (not counting a command pod, decoupler or parachute ), just as a rule of thumb.

@DonLorenzo: I\'ll accept it, but I\'d like it if you can tell us about what altitude you took control and how you piloted it. That ascent is really, really good. Rules have been updated slightly to cover manual piloting. @togfox: I\'ve put you on the leaderboard, but I\'d prefer a screenshot of the finished ascent. It allows a comparison of the path profile selected, which I think is where most of the change in dV comes from.