Starwaster

Ok, regarding MechJeb2 and landing predictions, I took my KSP back to stock except for leaving SDF installed. No Deadly Reentry, so I could use a stock lander all the way through reentry. No Real Solar System and no Real Chutes. So everything except drag is just the way MechJeb expects it. MJ2 was 46 meters off target and I'm going to lay that entirely on Mech Jeb because it knew it was off target. Its prediction for the final 2km was 46 meters and ~46 meters it was. (note the target marker says 51, but it's a few meters lower in elevation). So it gave an accurate prediction and decided on final approach to live with the results. (picture at bottom of post) So, the question is, how many people are using this with Real Solar System? Because that's the primary reason any of us really notice and want to do something about drag AFAIK. And MechJeb has certain codified perceptions regarding the atmosphere, which is that atmosphere cuts off after air pressure falls below 1e-6. That means that as far as MJ2 is concerned, a RSS sized Kerbin's atmosphere only extends out to.... I think it's 106km? I forget the exact altitude because it hasn't been true for a long time ever since we went to non-legacy atmosphere for Kerbin. The new atmospheric cut off is at 180 km which means MJ2 is ignoring 74km of atmosphere for braking purposes. A lot of that is negligible above 120km but that still leaves enough to throw off its calculations.

How are you checking for the TACLS resources? If you're looking at the RF configuration menu they won't show up there because they're not RF configurable. Did you try rightclicking the part? Or checking it 'in the field'? Edit: @Kitspace, re hypergolic consumption. Differing densities from stock would cause different consumption rates. how do they compare to monoprop in density?

I think that's it. Unless therre's more than one mod that does that

I'm not quite sure what's happening with terminal velocity. I need to do more in-game testing but it seems like terminal velocity is much higher than it should be. I did three tests: stock, FAR and SDF using a small 1.25 fuel tank and also consulted NASA's terminal velocity calculator and SDF just seems to be several times greater than it should be. There's a parameter in the settings file that can be used to tweak drag, and I haven't really tried any alternate values yet. The thing is, at its default setting, rockets are experiencing what seems to be the right amount of drag (experimentally). So I'm hesitant about changing the scale because it seems like it would have to be scaled too extremely. I haven't given consideration to altering lift at this point as it that involves a different set of parameters. However, there is a lifting surface module (ModuleAerodynamicLift that is currently unused in stock KSP. It was unveiled and discussed nearly two years back. But to this date it is unused even by Squad. Given the way it was talked about, it seemed like it was ready to go. Either that's not the case or Squad simply hasn't gotten around to migrating the Winglet parts over. Mu talked about it here and shared a good bit of the code behind it. It references velocity squared in its equations so it seems like they were taking realistic lift into account though I have't delved all the way through the math. If it's functional, it might be worth migrating some parts over and seeing how they perform. I hadn't considered that CoD might actually be affected though I did notice my test plane's stability affected when I jettisoned some drop tanks. No, definitely not to the extent FAR might have.... I seem to recall seeing somewhere that some (not all; the animated ones that extend) antenna can break if extended in the atmosphere with any serious speed. Edit: Yeah, just took a look at RT2's antenna code and it will snap under high dynamic pressure (exact threshold configurable per antenna). I don't know why you haven't seen that happen prior to trying this mod. Unless maybe it had something to do with FAR nullfying stock aerodynamics and you had previously used it under FAR. The RT2 forum thread also makes some mention in passing about making RT2 FAR compatible and I can't think what they might have referred to except the antenna... At any rate you should probably take it up with them, but it looks to me like it was performing as it should That's pretty much the norm for plugin mods. A mod would have to be specially designed to only apply to specific games. They need to store enabling configuration in the save file (probably via a SCENARIO{} node) and then implement enabling/disabling code based on that setting. I'm not sure any mods that are out there are set up to do that so it seems unfair to single out RT2.

I'm torn between the need to deride and revile this as an abomination and the desire to see this at the top of a giant Kerbal robot..... Perhaps as part of a 5 vehicle combinable robot. "And I'll form... the head!" Also... have you seen that plugin that lets you see the interior (IVA) through the portholes???

If you're wondering how they eat and breathe, and other science facts, just repeat to yourself, "It's just a game, I really should try to relax!" (apologies to MST3K)

This. So much this. Holy crap, how the hell did I not think of that? I hate you

As long as you're still able to unzip it, yes. I have no idea what that is. I dont even have a PC I can test on atm. I was hoping to have a new PC by now but I dont think that's going to happen for a long while if ever so I'm stuck on an aging macbook that I installed Monodevelop on folder/file structure of what you want to go in Gamedata is: StockDragFix/Readme.txt StockDragFix/SDF_Settings.cfg StockDragFix/Plugins/StockDragFix.dll Edit: Found a way to strip out metadata; reuploading. Should fix the encryption message too.

Put StockDragFix in GameData. Ignore the other; I'm not sure what it is, I dont see it when I redownload even. I am on a mac but I assume it's invisible to me. It must be a hidden folder that crept in when I zipped it up. I'll look into eliminating it.

Never? I pretty routinely bring my crew and equipment down in one piece, except for accidental suborbitals.... Spaceplanes are problematic in that my favorite design is hard to get on the runway in one piece because its swan neck design typically results in the crew smacking into the pavement. The rest of the plane then proceeds to a picture perfect landing (unmanned no less)

One thing though, the mass issue isn't an issue if you're dealing with stock drag; drag will slow you down the same no matter how much mass you have.

If that's the case he's still exhausted because he had to make more trips for the H2:P

Of course!

No, he'd be collapsed from exhaustion near the bottom of the rocket, unable to move as it ignites and incinerates him to a crisp

There's nothing to update, it's just a parts pack and it uses the PART{} node system so it's already compatible. There's no plugins with it either.

Transparent pod OMG!!!! SHUT UP AND TAKE MY MONEY!!!! (well, it's theoretical money, so good luck spending it...) Uhm please don't do this. Or if you must, replace it with the windowless variety (edit: by this I mean keep change the model so the part / name are still intact) but don't remove it. That will break craft. Although, unless it looks visually unpleasing, I'd say leave it as is no matter if Kerbals are ever seen it it or not. Here's a thought... hatches / IACBM docking ports with windows. I'm not clear on exactly what has to be done to make that happen as I'm not at all familiar with the plugin. It just seems kinda cool and I thought I'd throw it out on the porch and see if the cat licks it up.

By the way, I'm going to need some kind of repro information here besides 'someone stole my antenna' or 'try it and see if it happens to you' I need to know exactly what happened to the antenna and how you got to where the antenna detached itself.

It doesn't affect the atmosphere, it only affects how objects interact with it. It means that if you take two identical parts, one with fuel and one without, they will both experience the same amount of drag. In stock KSP, a full fuel tank experiences more drag. A rocket will have to expend more delta-V to get get to orbit, two falling tanks fall at the same rate (because the increased drag in the full part exactly offsets the increased inertia) With this plugin, a rocket experiences the same amount of drag full or empty, which is as it should be. Rockets can get to orbit easier, especially in Real Solar System, where Kerbin (Earth)'s atmosphere extends to 180km instead of 70. It is a stock-alike solution to a stock problem.

Cartman...what the hell are you talking about??? I just downloaded from both locations and I see no Mac files, unless they're invisible to me. Or unless you downloaded from Github and are confusing some of the source project files for something Mac-specific. It's highly unlikely that the mod is doing anything to RemoteTech 2 parts, but I will look into it. I'll uninstall SDF, install RT2, make an RT2 specific save game, launch some stuff then come back and reinstall SDF. Quite often over the past few months I've seen references to 'FAR lite', either with regards to something that was planned or contemplated by Ferram or requested by people that didn't like some aspect or other of FAR. This isn't 'FAR lite'. But it is a lightweight solution that approaches the drag problem from an alternate perspective. It tampers with as little of the stock system as possible so that anything that relies on stock behavior will not have its functioning impaired. (much). Things like stock SAS and MechJeb 2. It doesn't try to be realistic though it is 'more realistic' than current stock behavior. Which is something that I've perceived a need for based on some of the complaints I've seen leveled against FAR over the past year or so. What it doesn't do (that FAR does)(not a complete list and provided as neutrally as possible. Not pros/cons, etc) Replace mass value with cross sectional value. (probably not likely to change) Alter drag with orientation (which can change the amount of cross sectional presented) (not likely to change in future releases) Alter drag coefficients across subsonic, transonic, supersonic or hypersonic regimes. (might change in future releases) Rip your rocket apart due to aerodynamic stresses that might or might not be accurately modeled. (incredibly unlikely to change in future releases) Provide benefit to Procedural (and other) fairings. (will probably change but requires a lot of coding. But definitely this is doable) Require you to analyze your spaceplane in the SPH with graphs and simulations before you can take your spaceplane out there and actually play the game. (Never going to change. Especially not ever) Be a simulation. (Never going to change. Especially not ever) So basically, this gives those who want a more realistic drag system a lightweight alternative to what's been available now. It gives them an improved drag system that fits in with stock behavior instead of simulating everything. It's been said that stock drag is based entirely on mass, which is not an accurate statement at all. Stock drag is actually based on the same thing FAR is, which real life drag calculations are based on: Velocity. The faster you're going, the more resistance you meet with from the medium you're traveling through. It uses the same computation but substitutes mass for cross section. Almost certainly to simplify things. The problem as I saw it wasn't that it was using mass (which is certainly wrong, but acceptable from a game design standpoint) but that they were using wet mass. In other words... it's actually ok to use mass. It's just a number. It might not be the right one but it still results in somewhat accurate behavior. As long as it's not wet mass. In stock KSP, if you take a full fuel tank and an empty fuel tank and drop them from the same height, the full fuel tank should hit the ground first. Its increased mass should give it inertia that overcomes drag more than the empty tank does. But by using wet mass, the full tank receives increased drag exactly enough to offset its inertia and they both hit the ground at the same time (more or less). It also means that engines have to work harder to overcome drag than they should. This makes it harder to get to orbit in Real Solar System than they should. Experimental data is that I can get to orbit in RSS now with pretty close to the same delta-V that I would expend if I were using FAR. Ok, so in summary (the tl;dr), (I'm rambling a bit because I was up late last night and am still a bit sleepy) The key differences are that FAR gives you a simulation of aerodynamics, with all the good and bad that may bring and Stock Drag Fixer only attempts to fix a problem with stock drag. If you want reality (or as close an approximation to it as FAR can give) then you shouldn't use this. You should stick with FAR. If you just want a better drag model that doesn't bring 'soup' to the table, then Stock Drag Fixer will do that for you with its simple, one assed schematic. (Southpark reference. don't read anything into to it. I'm tired, want to go back to bed and can't and I have no idea what that even means... I just liked the sound of it) Edit: Just re-read that soup thing. Not implying that FAR brought the soup because FAR took it OFF the table. But now, so does SDF. KSO users would definitely benefit from this over FAR. I tried literally for days to land a single KSO25 shuttle (F5-F9) and even surviving the reentry the KSO25 would go into a nose dive as it slowed to subsonic that was only correctable by shifting its CoM farther back than it should be to be even at all recoverable. (IRL, the space shuttle would go into a 20 degree dive and then flare up at the end, so it's not like there's no precedent in reality, but in the end, I think it was just too complex a shape to be modelled accurately)

Did you configure the toolbar and enable the MJ options you want to appear?

Look at the map and guess it. Get out a protractor maybe.... but I just eyeball t

sorry, yes it is

Change Log Version 1.0 - Release Version 1.1 - Recompiled for KSP 0.90 - Optimization changes: - Removed unnecessary checks and computations - Moved dragScale sanity check to main SDF class. (one time execution) - Fed some turkey sammich to Cleopatra, The Feral Cat

Stock Drag Fix is a simple fix for KSP's aerodynamics problem that also preserves KSP's stock feel. It does not try to be a simulation of real life aerodynamics. In short, it is a 'stock-alike' solution to the drag problem. (there, that puts the tl;dr up front) As the name says, this fixes a problem with KSP's aerodynamic model. To recap, KSP uses mass to approximate cross sectional area. While this may not be the correct way to implement drag, the premise of this mod is that KSP's drag system is an abstraction of a complex problem and while not accurate is acceptable enough from a game design point of view. Actually, it is not really mass based after all. SDF still produces the desired results but for different reasons than I thought.... However, KSP's drag model uses resource mass as well, producing incorrect behavior. Propellant laden rockets have excessive amounts of drag. For stock Kerbin this isn't so much a problem, but for Real Solar System, it makes getting to orbit much harder because stock KSP applies too much drag, making it seem (as others have put it) that Kerbin is surrounded by soup instead of air. Also wrong..... Freefalling objects in KSP also always fall at the same rate because more massive objects have more drag which exactly counteracts their increased inertia (more drag; more inertia) whereas in reality their inertia should cause them to decelerate less than a less massive object. (same drag; more inertia) This plugin neutralizes resource mass while continuing to allow stock aerodynamics to function rather than replacing it. Because of this, other stock game functions continue to interact appropriately. For instance, SAS works properly. MechJeb will also mostly function properly with this plugin in effect. Its handling of rockets and spaceplanes will not be impaired. It may have some problems with reentry accuracy but I haven't tested that enough. With this mod, you can reach orbit around Real Solar System sized Kerbin with realistic amounts of delta V. Download: Source code! New 1.2 Beta Download! Stock Drag Fix version 1.2 (EXPERIMENTAL) maximum_drag and minimum_drag are now modified based on part diameter and/or length. unused drag models in stock KSP are now put to use. (CONIC and CYLINDRICAL) Nose cones, some crew capsules are set to CONIC. Any non-CONIC part that can have its length clearly determined via Module Manager config is set to CYLINDRICAL Mass compensation mechanism changed. Part mass is discarded in favor of total vehicle mass. Vehicle mass is cached and recalculated each physics frame. Drag now changes based on vehicle orientation. This WILL break MechJeb landing calculations for the same reasons that FAR breaks them. Mach drag modifier in. (using static SL speed of sound. Yes I know this is wrong) Stock cargo bays (Mk2, Mk3) and KW Rocketry's petal adapter now shield parts contained from drag. This will also affect Deadly Reentry: Parts thus shielded will be recognized as shielded by DRE. KSO cargo bays and other will be added later where possible. https://github.com/Starwaster/StockDragFix/releases/tag/1.2 Concerning FAR: You should not use this together with FAR. At best they would be ineffectual together. At worst they would conflict with each other as SDF actively seeks to modify fields that FAR depends on being zeroed out so that the stock aerodynamics system is disabled. Also, you probably either don't need this because you have FAR or you want a simpler drag system or find FAR too hard. In either case you definitely need to choose between one or the other and do not try to run with both installed. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

I've found the source of the bug; there's null ref errors being generated when Ioncross tries to create and move resources to the EVAing Kerbal. Since it's never successful, it keeps on trying. It's like he's standing there with the hose gushing O2 into space while he vapidly stares into the middle distance, forgetting to attach the hose to his backpack. The thing that worries me is that I might have introduced this bug with my refactoring because I don't remember it happening before. Or if it was, nobody ever mentioned it So when I get a chance I'm going to load up with the original version and if I can't reproduce then I'll just rollback. Unfortunately then I'll have to go back and re-fix the bugs that I fixed before. But that's the problem with trying to pick up other people's code