damerell

The good news here is that if I reduce the buoyancy exponent to 0, so it is unchanged by resizes, parts float exactly as I hope. Unscaled craft: Scaled craft: I would lay very good odds now that that is the case. NathanKell literally wrote that the new (as of 1.0.5) buoyancy system "uses dragcubes for drag and to help compute volume", and beyond that dividing the mass of the part by the volume of the drag cube is a very obvious approach to take. Of course, the "buoyancy" parameter affects the outcome in a way we have less understanding of. Coldj's results mostly seem to pertain to changing it, but the bit above where they say "a very large wheel wouldn't sink even with 0 so I had to give it the drag cube of a smaller wheel" is entirely consistent with the idea that buoyancy is determined in this way. Smaller drag cube (and nothing else changes), higher mass/volume, part sinks. Again there's some confusion here. Of course I think changing some aspects of the drag cubes will change the flight behaviour. However, the code quoted changes three things about the drag cubes; the six faces' areas, the linear dimensions, and the "Size". It's not clear to me that changing _Size_ will affect the flight behaviour. I expect that changing the faces' areas will change the flight behaviour since it is those (and the faces' "pointyness") which is used in the drag calculation. I would take a craft that's mostly jet engines and TweakScaled tanks, turn on the Alt-F12 aero data, and zoom it down the runway and into the sea. I'd repeat that, same craft, with the modified DLL. (Actually, because I'm paranoid, I'd start with the tanks unscaled and rescale them twice, once with the original and once with the modified DLL). If the peak drag and the speed at critical points like when I leave the runway and when I land in the sea don't change, that strongly suggests the Size parameter doesn't affect aero drag; and if the debris floats with the waterline in the same place, it doesn't affect buoyancy. I don't see that; a buoyancy exponent of 1 will still double the buoyancy parameter if the part size doubles, and so although the mass/volume ratio is unchanged the part will still be floatier. I've seen NathanKell explain this; it is a heuristic for the shape of the part; if false, the game assumes the cross-sectional area of the part at the waterline doesn't change much as it sinks (appropriate for, say, a cylinder being lowered end-on into the sea); if true, the game assumes the part is fatter in the middle which means the waterline will be closer to the centre of mass (appropriate for, say, a cylinder being lowered side-on, like a fuel tank without anything else attached). Of course this is a bit of a bodge to make debris look right - it only works inasmuch as you're willing to assume the part isn't joined to other parts which hold it in an orientation it wouldn't adopt by itself. I think this explains why ColdJ's thin flat part was twitchier without it. It may also explain part of my query above - the Mk 2 fuselage doesn't have it and the visual discrepancy is much greater when you have its very pointy edge at the bottom. It floats as if it was a uniformly dense cuboid, but such a cuboid would displace much more water per unit distance lowered than a Mk2 fuselage edge-on.

This seems to be a reply explaining _why_ some parts want different exponents. I fear we are talking at cross purposes here; I know why some parts want different exponents. All I'm saying is that I can see why _if_ a part has different exponents, the buoyancy calculation is going to be hard - that crew cabin we scale up by a linear factor of 2 does want a drag cube with 8 times the volume for aero drag but then since the mass didn't increase by a factor of 8 it's going to get extra floaty - but _if_ a part doesn't, the drag cube getting 8x bigger along with the mass should work just fine for aero and buoyancy alike. I'm not trying to jump to conclusions but to propose a way to test the hypothesis I've suggested above. With that two-line change it will be very obvious if a scaled plane changes its flight behaviour (in which case I was wrong) or doesn't but sits lower in the water (in which case I was apparently right) or doesn't change at all (in which case I was also wrong, but I would then think those lines of code are harmless-but-redundant). I'm asking you to help with that test because to recompile TweakScale is something you're already in a position to do. Neither of us knows what (if anything) KSP does with the Size attribute on a drag cube and changing those lines would help to find out. On the other hand that is very interesting and I'll try it out later today.

I rather think it's the third - because of the issue I discuss above, the volume for buoyancy is scaled up by a factor of 16, not 8. Given I imagine you're already set up to build TweakScale, I don't suppose you'd be so kind as to comment out the two lines that do rebuild it, and send me the resulting DLL? I'll gladly do all the flying of planes into the sea to try it out. Uh, if the exponents change the part doesn't have simple square-cube scaling anymore, because (eg) mass no longer changes according to the cube of the factor by which linear dimension changes.

I've formed a hypothesis. It will take me a little while to test it - I have to cycle home and dig out my KSP module building environment - so I'm writing it here in the hope that Lisias will know if it is or isn't plausible. PartDB13x/PartDB/StandardPartScaler.cs does (in two places): dragCube.Size *= factor.linear; for (int i = 0; i < dragCube.Area.Length; i++) dragCube.Area[i] *= factor.quadratic; for (int i = 0; i < dragCube.Depth.Length; i++) dragCube.Depth[i] *= factor.linear; I suspect that aero drag calculations use only dragCube.Area (and the "pointyness" but that isn't changed). It's all that's needed for KSP's stock aero model to do its thing. However, the buoyancy calculation uses dragCube.Depth (the linear dimensions) _and_ dragCube.Size, and the effect of that is that when a part is scaled up by a factor of 2, its buoyancy volume increases by a factor of 16, making it effectively half as dense. It would be easy to test this (if one already had a working build environment) by building a scaled-up plane, commenting out the two lines that multiply dragCube.Size, and flying the plane twice, once with the altered module. Into the sea. This logic has not changed since it was introduced in commit 3e80ec81eceede2e1fed2f0eed93a866ff1ddea5 in 2015.

I really still don't understand the problem here; everything you say appears to me to explain why a part which doesn't have a simple square-cube scaling might have problems, but that's not the kind of part I'm asking about. Here are some things I think are true: If I Tweakscale up a simple part like a fuel tank by a factor of (say) 2, its mass increases by a factor of 2^3, 8. Its drag cube also gets 2x as large in all three dimensions, so its volume increases by a factor of 8. Drag cubes aren't actually necessarily cubes. However, no matter what shape they are, their volume will increase by a factor of 8. KSP calculates buoyancy by dividing the mass by the volume of the drag cube in order to determine the approximate density of the part. Since both the mass and the volume increased by the same factor, the result there is unchanged. Clearly at least some of these things aren't true, but which? My observation is that the unscaled part floats with about the same apparent buoyancy no matter which way up it is. The scaled part's apparent buoyancy changes radically with orientation. This suggests scaling is involved, not just an inherent problem with KSP.

Yes, I read the material in the thread and the github issue. I understand that the drag cubes are scaled. I wrote "I see why the behaviour is confused for parts which don't have straight-up cubic scaling. However, I'd expect for a part that does if (say) you double the linear dimensions, the mass is 8x as large, the drag cube has 8x the volume, the part floats much the same". I still don't understand why that isn't the case, and I doubly don't understand why the buoyancy of those Mk2 hulls seems to vary based on which way up they are.

I've got some buoyancy issues. Reading upthread I see why the behaviour is confused for parts which don't have straight-up cubic scaling. However, I'd expect for a part that does if (say) you double the linear dimensions, the mass is 8x as large, the drag cube has 8x the volume, the part floats much the same. http://www.chiark.greenend.org.uk/~damerell/games/floaty.craft is a stock craft which doesn't exhibit this behaviour. As is, it floats with the waterline just under halfway up the tanks, as I might expect. (It's mostly easily got in the sea by using the Mod+F12 menu to move it to longitude -70 with pitch -90). Scale up the tanks by 2x (not touching the panels), and the waterline is far lower down the tanks. (Of course, the panels should weigh about 7 tonnes more if the whole thing was scaled but sticking a bit of extra mass on top makes no difference). Even more oddly, if I take a single Mk2 LF tank and scale it up even to 10m scale and drop that in the sea, it floats with the water about halfway up it. Zoomed out it isn't really distinguishable from the same tank at normal scale. So why does turning them edge-down make all the difference? (The KSP install I tried was unmodded other than TweakScale, KSP Recall, and Module Manager.)

That's a weird coincidence; I was just having a play around with this as a break from Dres. One question - why go East? It seems like if you set off at midday and go West you might enjoy sunshine for the entire trip at these kinds of speeds. ETA: indeed it turns out my impressive 200 m/s jet-powered boat just reflects what seems to be problematic buoyancy with Tweakscaled parts. Back, as they say, to the drawing board.

Little to write about these, but I am plugging on. I'm glad to have the BTDT track again.

Finally off on Dres. With the Scansat BTDT once again able to track our progress, and with a rover I can dismount from to plant flags without the ladders exploding, I think I can cut down on the sheer tide of screenshots just to document progress. I was clearly lucky in my choice of landing spot because by 102W flat terrain had been largely replaced by awkward ridges. One or two spins, but the anti-roll beam and Rover Stability Control are doing a good job keeping us right way up. Here's a flag at 120W. I was clearly roving into the sunset (and can move faster than the circa 25 m/s it moves at on Dres), so shut down for a day to set off once dawn had caught up. I overshot this a bit and it's now pretty dark a lot of the time, but I'll gradually get back under Kerbol. 150W:

Another session full of pushing probes around (and discovering the Jool probes have no battery, which apparently means the electrical equipment on them can't run off the RTG; a fresh set launched), but now almost all probe work is done. Here we are circularising at Dres; I presume to some degree the belly of the Hangarmoth must also be coated in steel and ablative oil. And down on Dres - at sunrise, good timing, and in a spot with at least some Ore, MetallicOre, and uranium ore. Almost perfectly sunrise - the "mast" is in sunlight but not the main hull. This crew have only done Gilly so far, so I'm sure they are eager to rove around somewhere they can have their wheels on the ground.

The Eeloo rover delivery mission just doesn't exist. One thing (maybe fixed later) I dislike about Kerbal Alarm Clock is deleting a vessel doesn't delete the alarms for its maneuvers, so you think it still exists. I bet NASA doesn't just lose probes down the back of the sofa. I launched a replacement. The Laythe vehicles, having dropped the big tank and engine, settle in for a long LV-N burn to Jool. The Hangarmoth embarks on a short and probably extremely noisy burn to Dres. A big Hangar full of Jool probes circularising. The probes out. They lack a RemoteTech connection - this is because (at least with the 1.9 mod versions I am using) there is no way I can find to launch a vessel from a Hangar with an antenna active, to run a kOS script immediately, to have a Smart Part trigger (which would then toggle an action group to activate an antenna), etc. I am going to shamelessly edit the save file to turn the antennae on, since this just seems like a bug. The first of the Jool rover delivery vehicles has circularised around Jool, a welcome development. I have only one rover with me now so it is good to know there is at least one more waiting - and some more LFO and MP to loot.

Another thing I've learned is to think about the conversion rates - I want big refined metal tanks, not metallic ore, and big enriched uranium tanks. I suspect by the time I'm done here I'll know everything about a thing I'll never do in KSP again.

IRL I have not been in a motor car for 15 years, and I've never had a driving licence, so... not as such, no. In vexing news the Dres rover delivery lacks, even remotely, the dV to stop at Dres. I have one rover on the Hangarmoth, and more rovers coming to Jool, so perhaps I am not yet in unavoidable trouble; but I think I must reconsider matters.

The cursed rover had a last gasp of cursedness when, as engineer Arald was roving it away from the Hangarmoth after having docked and undocked it to recover its supplies, it spontaneously flew into several pieces. Kind of moot since we're about to blast it with two nuclear devices, but Arald was still a bit taken aback. (What really happened is I'd put the suspension all the way down in an effort to jiggle it into the Hangar's vehicle acceptance zone and then the batteries bottomed out on the landing legs, but it sure came as a surprise). Liftoff was uneventful: The QA in sight: took us a few days to get here because we had left it in a very high orbit around Duna: And docked - a very undramatic docking thanks, I hope, to me getting better at it and not just blind luck. With the transfer window a year and a half away, I hope the kerbals will enjoy looking at Duna - and I have more to do (including getting the Dres rover delivery into orbit, which isn't vital but I would certainly like to steal its leftover MP and LFO) before the window.

100W: 110W: 120W, but somewhere here the game slowed to a crawl (about 50% realtime), resulting in an agonising slog to the Hangarmoth. First sight of the Hangarmoth. And we're back. Ike took a while for so small a world.

I am home on Ike; screenshots to follow, but I am home. ETA: screenies up, and en route to Dres.

Sure it's not just Advanced Tweakables?

To 40 and 30 East: A little jump at 20E, getting alarming as it gets darker, but the terrain had been easy and I'd kept going: I'd seen one more glimpse of Duna on a big jump before this, but this is the first time I hit F1 - I was distracted the last time by it being too big a jump, which bottomed out the suspension and destroyed the ventral KIS locker. (Don't put them on the bottom of your rover.) Duna rises, or possibly we rove under it: Duna from the top-deck seats in the cab, which do exist! Around here I'd thought, no, it's just getting stupidly dark, so I shut down for a few hours while Kerbol returned. Almost the first thing that happened when roving in the light was a huge prang, knocking off a chunk of the rollcage, both the MTS headlights (still, I plan to finish before sunset), and a solar panel. I found on Kerbin I seemed to be a worse driver when I could see where I was going, and the same thing has happened on Ike. Odd. I'd skirt this huge elevated area on the left to rove along flatter ground. Here the terrain flattens out again: Here I am allegedly in the Central Mountain Range, but it's not very mountainous: Finally I've turned towards the Hangarmoth, whose target marker is now on the HUD. 80 West, and then "not far" at 90W, alhough looking back I still have 30 degrees longitude to cover.

130 East. These mountains would rapidly become quite unpleasant terrain. At 120 East I am mostly done with them, but this slope down got pretty unpleasant. The topographical map looks very odd here (top right monitor). Easier full-speed roving here, even as we get into the Western Mountain Ridge, but it's getting dark - we are outroving the dawn. I stopped here having done a full 90 degrees longitude and wondering if I should rove into the night or shut down. I discovered if you extract from a Hangar a rover with a Scansat BTDT running, you need to turn the BTDT off and on again - hence the rather short BTDT track on the map here, but at least that'll provide a bit more documentation of the expedition.

170 East: 160 East: A strangely pointy mountain: More ugly Z-fighting at 150E: 140E: Easy roving this time, but not much to write about it.

More Laythe problems: the Laythe jet balances out but the Laytheboat is just too unbalanced for the long transfer burn. Still, I've got time in hand since the Queen Agaster will have to visit Dres before it gets anywhere near Jool so can terminate, redesign, take the next transfer window in 72 days. It struck me that if the problem is that the jet is a heavy winged object that wants to hang off one side of its rocket, and the Laytheboat is a similar-weight wing-shaped object that wants to hang off one side of its rocket, sending them off separately was entirely pointless, and so this monstrosity was born: A kOS script written for the Laytheboat balances everything out; it doesn't touch LFO tanks, and the jet is slightly heavier than the boat and full of LF where the boat's pontoons are empty LF tanks, so it can do its job right from launch. After dropping the boosters and the first main stage we have this even more absurd contraption: Seriously, it's like a plane with the world's most ridiculous undercarriage. Eventually the nose and central engine will pop off when dry, leaving the two Laythe vehicles docked to the giant RCS tank which also has those four quad-LVNs and tanks on booms. This will also make for a bit of excitement when we get to Laythe since we'll have to lower Pe to dip into atmosphere, cut the Laytheboat loose, raise Pe again, see where the Laytheboat comes down (having an approximate idea of how much longitude it covers so it drops somewhere near land), and then lower Pe again to try and drop the jet somewhere nearby, making sure to get all the LF where it's needed after each part of the operation. Meanwhile, Ike, which started by... both ladders exploding unexpectedly when kerbals boarded: What the kerb? I'm planning to ditch this rover here since I have a replacement coming to Dres, but I guess I won't be dropping flags on Ike. I could suit-RCS out in Ike's gravity, but I'm lazy. 140 degrees West: 150 degrees West: 160 degrees West. Not much to write about these; the terrain is easy and Ike is small. 180 degrees West (what happened to 170? I don't know): And a shot of the rover, where I also have strange stuff going on with one of the crew portraits. Perhaps this rover is cursed and it's just as well I'm leaving it behind.

The USI mod constellation includes Enriched Uranium and Depleted Uranium tanks, and even if you don't want to bring all that in, it's easy enough to swipe one or two parts from a mod. https://forum.kerbalspaceprogram.com/index.php?/topic/192855-18x-111x-stockish-project-orion-v182-update-12292020/ includes some _great big_ ones, too. I would expect that the Uraninite->EnUr process enormously reduces the mass making bringing Uraninite horrendously mass-inefficient - as in "maybe bringing a spare reactor would be less mass-inefficient".

Nor do KSPWheel (Kerbal Foundries) wheels - and, to be fair, this is one of the few respects in which the stock wheels behave as one might realistically expect. :-)

Set off for Ike. I expected to have a tangle with the Laythe transfer windows, but Ike is really close to Duna and the whole business of taking off and getting over there could be easily accomplished in time. I did wonder if Duna's atmosphere would be a nuisance on takeoff, but I didn't try to get too fancy with ascent profile and up I went without trouble. I really needed a landing spot with Uranite if possible - the limiting factor on me producing Orion pulse units is not metallic ore, but uranium - and did a bit more work on the kOS landing script and with careful consideration of the ScanSAT map came down somewhere reasonable. The trouble with a good landing script on an airless world is, of course, you spend more of the descent thinking "oh kerb, light the engines, there's no time!". I'm even down in the daylight, so I could just set off, but I think the rover speed control script needs more work. (This is not entirely a joke about avoiding the actual roving; a problem on low-g worlds is braking when only your front wheels are touching the ground, which does tend to flip you. The script could detect if the rear wheels are off the ground and if so turn off the brakes no matter what.)