NathanKell

To calculate displacement, you need an object's drag cube. That's either in PartDatabase.cfg or the part's cfg, or it's generated during the game (procedural). In the cube, there will be eight triplets of numbers. The first six triplets are the X+/X-, Y+/Y-, and Z+/Z- faces of the cube, the next triplet is the centroid, and the final triplet is the sizes (in x,y,z). areas[n] refers to the first number in the nth of the first six triplets, where n starts at 0 and ends at 5 (0 = the X+ face, 1 = X- face, and so forth). size.x or y or z refers to the first/second/third number in the final triplet. Displacement is found by: First, naively compute displament as size.x * size.y * size.z Next calculate xPortion = areas[0] / (size.y * size.z) yPortion = areas[2] / (size.x * size.z) zPortion = areas[4] / (size.x * size.y) if none of those numbers are 0 or divide-by-zero, then we recalculate displacement, first calculating an xzPortion as (Min(xPortion, zPortion) + 2 * (xPortion * zPortion)) * 1/3 Finally displacement = original displacement * xzPortion * yPortion

It's a physics setting because that's where I stuck it. And as this thread shows, physics settings are patchable by ModuleManager, whereas game settings are not.

If you have real-scale parts and give them real stats using RF, you've...basically set them up for Realism Overhaul anyway. :) Your best bet would be to come by the [url=http://webchat.esper.net/?channels=RO]RO channel on espernet[/url] to get realtime help; most RO (and indeed RF) configuring is applied via MM patches, rather than in an 'original' config. That mostly involves just not using the MM operators, though. At the simplest, you'd just be adding a ModuleFuelTanks module to your tank part(s) with the appropriate type and the volume (in liters). For the engine, you'd set it up with the correct thrust, throttling (if any), propellant use, and number of ignitions. That can all be done in the ModuleEnginesRF module or, if you want to represent multiple possible engine configurations (like LR79-NA-11, LR79-NA-13, etc) you'd add an additional ModuleEngineConfigs to handle the switching.

Nope, it never was AFAIK. Try making a new issue on the netkan repo?

Yeah, was looking at the Whiplash in particular since the other (well, non-RAPIER) jets are already real in 1.0x, they just have only .65-.75x the mass-per-thrust of their real counterpart, and 2x the Isp (although in real life Isp varies by velocity as well, so...). But I noticed you were giving some crazy-high increases in thrust at altitude, which don't comport at all with my research. For the record: the Juno is a J85 (upsized to produce 20kN not 13-14kN), the Panther is an F404 (although upsized to F100 size thrust), the Wheesley is a JT8D-219 (slightly upthrusted, again), the Goliath is a CF6 (ditto). The Whiplash is inspired by a J58 although a lot of guesswork is involved, and the RAPIER moreso. Feel free to crosscheck in AJE or something. :)

Mods that aren't updated for 1.0.5 will...presumably need to be updated for 1.0.5. :)

You recall correctly. :) And yep, that's why the center of buoyancy (force) is placed high for the capsule. The CoD is placed low because most of the displacing volume of a cone is near the base. The sine curve is turned off because of the conic shape, too (though the sine curve would be correct if the capsule were submerged with the conic axis parallel to the ocean surface, that's not usually how it will be submerged).

Uh...you seem to have made the jets _less_ realistic? :]

look at the Squad Mk1 pod's part cfg for how to increase buoyancy artificially.

CoM = CoL = CoP = Center of displacement (i.e. how we know how much is submerged) = center of buoyancy (where the buoyancy force is applied) = part origin, [B]unless[/B] overridden (only a few parts override one or more of those). There's also a buoyancy scalar--again, only a few parts set it to something other than 1.0. To better simulate the usual condition where a fuel tank or other cylindrical part is in the water, buoyancy defaults to using a sine curve when calculating how much of a part is submerged. The first step is always to calculate maximum depth, calculate minimum depth (negative since above water), calculate depth at center of displacement, then calculate submerged portion lerping between max depth to CoD to min depth. Then, if the sine curve is used (default: true), feed that number into a sine function to get a nice curved, rather than linear, result (think of a cylinder hitting the water side-on, at first submerged volume increases slowly, then fast, then slowly again).

Since KSP wings do stall now, that trick will indeed work.

I'd say that 400 K (260 F, rather hotter than boiling water) is a fairly reasonable temperature for an unpressurized, light-metal WW2 cockpit. Those pressurized cockpits designed for supersonic flight, well, makes sense for them to have higher max temps.

Wait, why me? All I did was create an issue on the CKAN repo asking them to retarget here, just as anyone can do. :]

It's listed as L+ presumably because that's its role in KSP. As of 1.0, KSP engines generally fall into one of four categories 1. Vernier 2. Booster (first stage engine) 3. Sustainer (core engine, or second stage) 4. Upper/vacuum engine So for size 0, the LV-1R is a vernier, the Spark is a booster, and the LV-1 is an upper. Size 1, the engines are 24-77, LV-T30, LV-T45, LV-909 respectively. Etc.

PSA That error occurs if you never updated KSP due to the silent patch. Redownload KSP fresh to get on build 1028, not 1024.

because fullyDeployedDrag does nothing. :D It's for the old drag system, but the chute doesn't use the old drag system.

You heard incorrectly. 1.0.4 saves are compatible. If it's a career save (RP-0) don't upgrade yet, though, that's not out. There were some metadata issues regarding 1.0.4/5 and RO mods, which should now be corrected. Do try removing (and then manually cleaning), and then reinstalling the 1.0.4 mods, if you want to play on 1.0.4.

Grem, the [url=http://forum.kerbalspaceprogram.com/threads/139820-Crossfeed?p=2301941&viewfull=1#post2301941]third post in this very thread[/url] explains what's going on. :)

Flapp: There appears to be a version mismatch between your KSP, Solver Engines, and Real Fuels. Please ensure you are indeed on version 1028 or above of KSP 1.0.5 (look in buildID.txt in your KSP folder). Then delete the RealFuels and SolverEngines folders in GameData and replace them with fresh downloads from their repositories [url]https://github.com/NathanKell/ModularFuelSystem/releases/download/rf-v10.8.1/RealFuels_v10.8.1.zip[/url] [url]https://github.com/KSP-RO/SolverEngines/releases/download/v1.13/SolverEngines_v1.13.zip[/url]

Just merged a fix into CKAN, from Olympic1, that should fix that issue. :)

There are still some parts that need new colliders, as I understand it.

Don't recall offhand what the clamp does. The drag modifiers are because the visual parachutes are hilariously tiny compared to the drag they "should" be producing. To increase the drag, they either need the canopies remade to sane size, or drag modifiers. The Mk2 radial has the largest drag modifiers because it has the tiniest canopy, far too tiny for the drag it needs to be producing.

Please post any RO issues on the RO thread folks. :) [B]Also, [I]post logs![/I][/b] We can't telepathically discern errors...

The Not working pending rework part? Yes it did. :P That is to say neither stock nor, despite its name, ModuleRCSFX, support custom fx.

Yep. That. Eve Aero capture at high speed uses all and more.