NathanKell

Ditto. FAR is utterly experience-changing, and I can't give kudos enough. Needs to be repeated at least once a page.

ferram, any thoughts on the parachutes? I'm not sure what else I can try to eliminate the extra drag... Also, while I'm asking: Any chance of your revisiting your position on the area rule?

I've landed with three radials (=1.5x a single XL) and nothing ripped off.

Here's the two source files that were changed and compiled DLLs for both 20 and 21 (the latter using malkuth's fix). https://dl.dropboxusercontent.com/u/59341658/MC10_NKcostedit.zip

So, while I love this mod, I had real trouble with the cost balancing. Trusses shouldn't cost 10x as much as probe cores, for instance. Further, heavier items that do the same thing should cost _less_ than lighter ones in many cases, for example five Z100s vs a single Z500. The energy density is higher so the cost should be too. Finally, in the real world the payload makes up the majority of the cost of the mission. Satellite example: $100m for the payload, $40m for the LV. So I went ahead and rewrote the cost function to (1) consider part category and (2) consider part modules, and in doing so tried to make particularly command, utility, and science items cost far more, and structural far less. For most parts (3) I consider mass-efficiency: Reactors (treated as big RTGs) will be per-unit-of-generated-electricity more expensive since they're more efficient than the stock RTG. Same goes for fuel tanks, solar panels, batteries, etc. This means, most importantly, that mods that add overpowered components (compared to stock) will have those components cost way _more_, not way _less_ as it stands now. I did keep some cost for mass (i.e. construction labor and structural parts) but that is under different multipliers for different kinds of parts. I tweaked nobody's formula for engines so that gimbal and atmo Isp are taken into account and so that mass-efficiency plays a role: the more mass efficient an engine is for its performance, the more expensive it will be--so if a mod adds an LVT-45-alike that masses only 1 ton, it will be more expensive, not the same cost (MC's current engine formula) or _less_ expensive (MC's engine formula + MC's mass formula). Jets (and the Kethane turbine) are also now included, at at 1/20 price ratio. That works out, because high-performance jets are actually more expensive than rocket engines, IIRC. Example costs: Octo2: 2000 Small stack probe: 1200 Mk1 pod (with DRE ablative coating): 7000 Mk1-2 pod (with DRE heat shield): 29000 Science sensor: 250 Antenna: 150 Comm Dish: 750 RemoteTech SatDish 9000: 30,000 + 700 construction LVT-45: 4000 + 100 in construction costs SLS Bearcat (NovaPunch; 240 thrust, extra gimballing, similar Isp, still 1.5t): 5400 + 100 construction costs. DSM Nuclear Reactor: 601,000 + 50,000 or so in construction costs Structural parts: a few K here and there! A couple example pictures (note that I've doubled costs for batteries and panels since then, so increase Utility by x2)--note that the total costs should be broadly comparable to where they are in stock MC. EDIT: Pics fixed. I _believe_ the license allows me to upload these changes compiled; I can certainly upload the code. (Unless, nobody, you'd rather I not, in which case I absolutely will not!) Note that I'm still running .20, so malkuth, you'd have to merge the changes in to your .21-fixes branch for .21 compatibility. So...is anyone interested?

Thanks, Cilph. So yeah, I could probably hand-edit my sfs files, but likely not worth the trouble.

Hi Cilph, sorry to bother you about this, but I wondered if you could tell us _what_ breaks the compatibility. Craft won't work, from changed partnames? (And thus sfs file will be auto-cleaned)? Or are you actually adding stuff that will only get written to SFS or plugindata on starting a new game? I'm perfectly happy to hand-edit my sfs file if necessary.

Yup. My drag losses are ~150 (calculated by Mechjeb's ascent stats, compare expended delta-V to current velocity, gravity, and steering losses (the way mentioned upthread to calculate drag losses). Then the parachute--with stowedDrag set to 0!--gives me another 50+ m/s losses. Note that it _does_ do something--it lowers stockdrag losses a lot. Just nowhere near zero. Try it yourself--launch a simple rocket, even with stowedDrag set to 0, and see what you get. (And if you get something different, I must have a weird interaction issue?)

@ferram, ah, I see. Yeah, it would be wonderful if you could fix that. I can't be the only person getting into Mission Controller and wanting to _safely_ deorbit spent stages! One other thing, while I'm asking. Parachutes. I know you're leaving them alone for now, and that's fine...while they're extended. But adding a single Mk16 (that is to say, launching a one-kerbal pod) to a rocket will triple its drag losses. I even went ahead and set stowedDrag to 0 for all parachutes, and I'm _still_ getting 50+ m/s drag from a single undeployed chute on ascent. Can you kill stock drag for parachutes but only when undeployed, or something?

Hi ferram, thanks! Regarding the rocket-ends question, I mean if the rear of the rocket is pointed into the airstream, it has a lower Cd than if the nose is (seems to be because engines, especially those, produce very little drag; fuel tanks produce only a little, even at their blunt end; and tapered sections, like the nosecone adapter, produce tons--it's better to have a 1.25m tank straight flush against a 0.625m tank than to use the adapter.)

Still on .20.2, and creating a standardized set of FAR-compatible launchers. But I'm encountering some issues. I.e. this drag...it does not seem right. In fact it's worse than it appears, because there's more drag from the _front_ of the rocket than if it's retrograde. (I have a 0.625m procedural fairing over the payload that's been decoupled in the picture; it doesn't get more than 0.7m wide). Also, the drag gets worse if I use a tapered adapter from the fairing to the tank; it's better to just have the toroidal tanks right in the airstream. Further, I went and increased the bottom node size on those engines from 0 to 1, and it made no difference (and I checked node position vs CoM, too.) Another weird issue with drag I've found--and note, this may be working as designed, I don't know aeronautics--is that adding some fins can drastically increase drag, but only sometimes. The Cd more than doubles, but the Cd of the winglets is very low. Example: Before: After: Have I mentioned how great the debug info is!? It's great. Please leave it as an option!

Not FAR, KSP/Plugins. When you switched to the new DRE, you had to remove EVERY file from the old DRE, no matter where they got put. Remember I said to do the search? Note that if you have anything below the heat shield, drag will not work properly and you may over-G.

birrhan, make sure there's nothing in your root_ksp_folder\Parts folder. That's where all the old DRE parts would be. If necessary, open your main KSP folder and do a search for "deadly" and make sure that the only files/folders that show up are under ksp\GameData\DeadlyReentry (and verify that the files and folders in ksp\GameData\DeadlyReentry are exactly what's in the DRE 2.3 zip you downloaded). What are you using to, like, stop? In the pics I see only docking port, ASAS, pod, and (messed up) shield. You said you were doing a powered descent--where do you have the tank and engine stashed? There should be _nothing_ below the heat shield...

birrhan, pics or craft file? I've been able to deorbit even before the fix, and am fine afterwards--right up to Mun->Kerbin direct descents. But first, try a steeper descent--you may be spending too much time in the upper atmosphere, where the heat:drag ratio is too much heat--you don't bleed off enough speed so eventually you overheat. You want peak drag Gs of at least 3.0 or so, which means a PE of 0--everything on your pod should be able to take that (I hope, unless you have some really impact-intolerant parts!) Or is your problem already explosion from overG vs explosion from heat?

Trying again--last time I posted this it didn't show up (crossposted to the DRE thread) First, I'm absolutely loving FAR, thank you so much! I flew a plane like...a plane, and it was a revelation. Plugged in my HOTAS setup and had a ball. Having a few issues that I'll ask about in a later post or two, because they seem to be bugs (adding four fins changes the Cd of a rocket from 0.02 to 1.5!?) but for now, DRE integration. I've found and fixed the problem with the heatshields and FAR. FAR applies open-node drag by first raycasting from CoM to node to find where the node is; on the 2.5m heatshield, for example, both top and bottom nodes are above CoM so there's no open bottom node, and thus very little drag (Cd of 0.05 vs 0.6 for unshielded Mk1-2 pod). If you move the node below the CoM (and move the model too, so no visual changes) then all's well--you get a Cd of like .4 or so, which makes sense for a rounder, smoother, more aerodynamic bottom. Changes: replace asset params and node defs with this: // --- asset parameters --- //mesh = model.mu MODEL { model=DeadlyReentry/Parts/deadlyReentry_2.5Heatshield/model position = 0.0, -0.1, 0.0 // bnode of shield was at 0.05*1.3=0.065 // tnode of shield was at 0.145*1.3=.1885 scale = 1.3, 1.3, 1.3 rotation = 0, 0, 0 } scale = 1 rescaleFactor = 1.0 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z //node_stack_bottom = 0.0, 0.05, 0.0, 0.0, 1.0, 0.0, 2 //node_stack_top = 0.0, 0.145, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -0.035, 0.0, 0.0, 1.0, 0.0, 2 node_stack_top = 0.0, 0.0885, 0.0, 0.0, 1.0, 0.0, 2 You can do the same thing for the other shields with this issue: replace mesh= with a MODEL{} block, move the model and both nodes down by the same amount. I chose to bake in rescaleFactor because I didn't know how rescaleFactor played with MODEL{} blocks but you might be all right otherwise.

(crossposted to the FAR thread) Hey, great mod--I love that I actually have to plan my reentries and design well. I've found and fixed the problem with the heatshields and FAR. FAR applies open-node drag by first raycasting from CoM to node to find where the node is; on the 2.5m heatshield, for example, both top and bottom nodes are above CoM so there's no open bottom node, and thus very little drag (Cd of 0.05 vs 0.6 for unshielded Mk1-2 pod). If you move the node below the CoM (and move the model too, so no visual changes) then all's well--you get a Cd of like .4 or so, which makes sense for a rounder, smoother, more aerodynamic bottom. Changes: replace asset params and node defs with this: // --- asset parameters --- //mesh = model.mu MODEL { model=DeadlyReentry/Parts/deadlyReentry_2.5Heatshield/model position = 0.0, -0.1, 0.0 // bnode of shield was at 0.05*1.3=0.065 // tnode of shield was at 0.145*1.3=.1885 scale = 1.3, 1.3, 1.3 rotation = 0, 0, 0 } scale = 1 rescaleFactor = 1.0 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z //node_stack_bottom = 0.0, 0.05, 0.0, 0.0, 1.0, 0.0, 2 //node_stack_top = 0.0, 0.145, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -0.035, 0.0, 0.0, 1.0, 0.0, 2 node_stack_top = 0.0, 0.0885, 0.0, 0.0, 1.0, 0.0, 2 You can do the same thing for the other shields with this issue: replace mesh= with a MODEL{} block, move the model and both nodes down by the same amount. I chose to bake in rescaleFactor because I didn't know how rescaleFactor played with MODEL{} blocks but you might be all right otherwise. **** On another note, regarding G-limits. Would you mind terribly exporting your coefficients to the CFG so they can be user-tweaked? Even if not all of them used in the calculation, just a linear "gscale" scalar applied to all? I'd really like to be able to pull 7G turns in aircraft that should be able to do so (and, y'know, replicate Mercury reentries, let alone Apollo). I'm planning to go ahead and tweak and recompile from source for personal use when I finally get around to installing VC# or Mono, but having them exposed in CFG would be so much easier.