[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[Lisias]

1 hour ago, FullOfStars said:

Okay, I have -partial- success with Tweakscale and Recall now!!
It was indeed the duplicate DLLs and Patchmanager interferring.

Good! PatchManager (and, most of the time, everybody else) was probably just the trigger. If you really want to use it, I suggest to temporarily uninstall MJ2 (so the diagnosing is easier), install PatchManager, make it work and then install MJ2 back.

It's how I managed to diagnose weird things when MJ2 is installed (again, not because MJ2 is the troublemaker, but because somehow I changes how things are logged and this affects negatively my diagnosing).

 

1 hour ago, FullOfStars said:

I am noticing that it is very selective on which parts have Tweakscale enabled, but, this could just be because I do not understand enough about how Tweakscale works. Maybe there are some configs that need tweaking to enable all parts? A little explanation on how a part is actually tweakscale enabled could be beneficial por please. 

Well… This is another long story.

Spoiler

One thing that you will eventually note if you are on the modding side of the Force is that since 1.4.0 the PartModule's life cycle was being screwed up by some 3rd parties that decided not to initialise some internal data, what - as people that handle systems integration knows - is not exactly the most productive way to keep things working tight.

So some 3rd parties decided to redefine how the PartModule should be initialised, and TweakScale had to try to cope with each one of them, and then something that fixes a problem on an add'on ended up screwing over the other…. In another time the author completely renamed all his PartModules and then blamed TweakScale when scaling ceased to work! By some weird reason, his add'ons had only part of the patches needed to make things work, while TS had the ScaleTypes internally - exactly what he should have updated when he renamed the PartModules…. 

Well, I think you already got it.  

So I had had these terrible experiences in the past on support some 3rd parties, with TweakScale being blamed for problems and changes on the 3rd parties themselves (I'm not implying I didn't had my own share of problems to fix) and so I found myself just patching holes instead of doing things the right way (or the less wrong possible).

Or being responsible to test my AddOns on every new release of their add'ons "to be sure not to cause any trouble". Frankly, sir… Not the best way to burn some free time on a late Friday.

So I had to cut off 3rd parties support from the main TweakScale distribution and start to publish "Companions" where support for 3rd Parties are implemented. Worst case scenario, the heat is confined into the Companion and do not splash on TweakScale - saving me the trouble to eternally having to prove that TweakScale was not the one screwing up thing (most of the time ) .

But please note that besides being deprecated, every patch that was part of TweakScale in the 1.3 era are still there (save the ones that were internalised by the Add'On itself, as KAX). Chances are that they are not working anymore, but some of them still works because I updated the ScaleTypes (that are shared to everybody).

 

So TweakScale now only officially supports Stock and (most of) Expansions. Everything else is now (or hopefully will be Soon® ), officially, on a Companion.

You will find the current ones here: https://github.com/net-lisias-ksp/TweakScaleCompanion

Currently, only manual installation.

 

1 hour ago, FullOfStars said:

If I remember, I did it once with the LLL parts. I had to like, put a line of code in the part config itself and then a line in like a Tweakscale list or something. Was a few years ago.

Add'Ons that rely purely on stock PartModules will work fine with a few lines of code on a MM Patch. The hard part is doing things in a way that make sense and it's useful - just shoving type = free on everything is a useful hack most of the time, but having proper ScaleTypes that makes sense does a better user experience, so it worths the trouble to make good patches.

Please check the Companions, I like to think I did a good job on the Patches for the SCME one by way.

In the mean time, All Tweak is a nice workaround while I don't provide the patches you want for the add'ons you use.

And a new bonus on the more recent TweakScale releases is that I finally understood where KSP had changed on some primordial levels and could resurrect some very nice features that you probably had used on 1.3.x era, but I had to deactivate since 1.4.x - and this includes the ability to seamlessly adapt the scaling if a part when you change the patches. So using All Tweak is not only a convenient workaround, but also safe nowadays (some time ago I had to tell people using All Tweak that they could not install new patches on ongoing savegames - pretty annoying).

Check all the Companions and install the ones that provides the support you need. And you can file suggestions on this link:

https://github.com/net-lisias-ksp/TweakScaleCompanion/issues

Don't bother trying to guess in which Companion you should file the suggestion - I will sort it out later this year when I will have another time window for coding on KSP again!

 

1 hour ago, FullOfStars said:

Is there any specific way to have this applicable across all parts in an easy way?

Easy, yes. Convenient and useful, not always. Try All Tweak above for parts relying solely on Stock PartModules (or PartModules that I have already wrote a ScaleType) - don't use it on add'ons with custom PartModules (or without proper ScaleTypes), they will not scale correctly and sometimes will even break.

On the bright side, once proper TweakScale support is added, AllTweak automatically steps aside for the new patch and things will usually work fine with the resurrected patch migration - at least, I didn't found any problem with it yet. 

There're some Stock Parts that I'm struggling to support due a lot of bugs they have - Robotics, to be more specific. The Serenity's Robotics are very nice parts, but unfortunately they are pretty buggy too. But you can try your luck with the TweakScale Beta and, if you are really, really brave , you can activate the Experimental patches on Beta by creating a Directory called "TweakScaleExperimental" on GameData.

I don't know how Infernal Robotics are behaving nowadays - proceed with caution. I know that without Breaking Ground the IR/Next fork worked fine some few KSP versions ago. You will probably want to check KerbalJointReinforcement/Next too.

Let me know if you need any assistance. Jumping from KSP 1.3 to 1.12.3 is a hell of a Endeavour , and since I still do support everything down to KSP 1.3.1 (and one or two things even on KSP 1.2.2!!!) I'm pretty sure I can be of some help on this Enterprise  .

(late night, infamous jokes can't be contained anymore!!)

Cheers!

Edited October 25, 2022 by Lisias
tyop! Surprised?

[FullOfStars]

2 hours ago, Lisias said:

Good! PatchManager (and, most of the time, everybody else) was probably just the trigger. If you really want to use it, I suggest to temporarily uninstall MJ2 (so the diagnosing is easier), install PatchManager, make it work and then install MJ2 back.

---

Cheers!

Thank you again so much for being so helpful and dedicated to support on this. I will give alltweak a try and see where that gets me. Honestly, capsules, wings, gear, and tanks/structural are about all I really need them for. I could see the robotics areas being a super pain, but luckily I find that they are pretty robust just as they are and can work around that. I knew when going to 1.12 that I would have to give up some features (Goodbye awesome B9 landing gear and maybe some other parts ), but so far, I find that it looks and runs better and it was needed with what I do.

Now that tweakscale has been at least rudimentary solved to the point of acceptable, on to my next challenge... joint reinforcement lol. I installed that and it 100% makes my main menu entirely unclickable, and, sadly that is another experience breaking mod (I think the last one other than Krag and Kopernicus) on what I use. I have got to sort it out cause the first rocket I built sagged so bad it just kept exploding on the pad. It looks like they locked the forum though. I realize you have nothing to do with that, but I'd be very appreciative of any advice in a PM to not derail this thread if you wouldn't mind. 

OPT seems to be, just not working or showing up. There are a few wing parts from another mod I gotta see where those came from cause they are pretty crucial to my needs and builds. But there is already so many other cool functions and features as well that I'm enjoying it. I can run my EVE a little higher without a bad performance drop like 1.3 and the transitions are a lot nicer in build mode to pad and all. I'm still finding it very very odd to not have the Delta V stats in Mechjeb and it being displayed near the staging, but I suspect I'll get used to it. Also keep clicking the wrong button trying to go to the crew facility from VAB lol. 

Again, thank you so much, cannot be more appreciative. KSP really helps me unwind as an Engineering student and right now we're on a 1-2 week downtime before final season begins. I am so pumped to get 1.12 up to full speed so I can just boot up and play without issue eventually like I had 1.3 at one point. 

[damerell]

15 hours ago, Lisias said:

Buoyancy apparently was an afterthought on KSP, as the drag cubes were used to simulate it.

Problem: I need to scale the drag cubes, otherwise the parts will have a very unfair drag, so it's a catch22 situation for now.

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.

[Lisias]

24 minutes ago, damerell said:

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.

Because Buoyancy is related to density, not volume. And the drag curves are scaled as the volume scales.

For example, 1m³ of wood will float but 1cm³ of lead will sink.

However, on KSP, there's no density on the parts - just the drag curves being reused to define how the part will float over water (and only over water - different liquids would give you different buoyancy for the same part, but on KSP we are all locked into water to handle Buoyancy).

Since TweskScale needs to scale the drag cubes, otherwise you would have drones with the drag of a Boeing, and Jumbos with the drag of a Cesna, the currently unavoidable side effect is the buoyancy being completely screwed up as the video I post demonstrates.

I need to find a way to compensate the Buoyancy as the part is scaled up and down in order to keep the same Buoyancy of the default part as the part scales. So I need to understand how the drag cubes feeds the Buoyancy calculation so I can compensate it on the other side - and using the weight is not an option.

[ColdJ]

16 minutes ago, damerell said:

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.

When you rescale a part it doesn't get scaled in one dimension, it gets rescaled in three. You are adding or subtracting, Height, width and length, which just in a cube increases the volume greatly, so imagine for more complex shapes. The game calculates the drag cube based on the meshes dimensions, not on its colliders, so even if you just had a big box collider around the whole model, it wouldn't affect the drag cube.

So say you took a simple cube and made it longer in just 1 plane, you are still increasing the volume across the whole 3 dimensions. Now I don't know the exact formula the game uses but basically small increases require much greater masses to balance them out. As such you end up having to have a huge amount of mass to counter the increase in volume. This becomes impractical in a game where you use rockets with limited thrust to weight and finite fuel.

As to the cross section of the MK2 hull, the game is imperfect in it's calculations. and so something you wouldn't expect in the real world happens in game.

I have 3d modeled many boats and ships for KSP and unless you make them extremely heavy they will sit balanced on their keel on top of the water. my solution to that is to make a copy of my model and remove the lower half at the level I want it to sit in the water. I load that model up and then go get its drag cube, I place its drag cube in my config for the full model and then it sits in the water at the realistic height.

It is just the way the game is programmed.

 

[Lisias]

I could not explain it better!

14 minutes ago, ColdJ said:

I have 3d modeled many boats and ships for KSP and unless you make them extremely heavy they will sit balanced on their keel on top of the water. my solution to that is to make a copy of my model and remove the lower half at the level I want it to sit in the water. I load that model up and then go get its drag cube, I place its drag cube in my config for the full model and then it sits in the water at the realistic height.

That's the thing: there's a value on the PartModule that I found but didn't understood yet, "buoyancy". I hope it is used somehow together the drag curves to calculate the buoyancy - but I need time to do some R&R, I mean, R&D  on the matter.

The time we realise how (or if) this "buoyancy" thingy works, will the time (assuming it works…) we  will be able to do proper ship parts - and to scale parts without messing up the buoyancy!!!

[damerell]

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?

3 hours ago, ColdJ said:

As to the cross section of the MK2 hull, the game is imperfect in it's calculations. and so something you wouldn't expect in the real world happens in game.

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.

Edited October 25, 2022 by damerell

[damerell]

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.

Edited October 25, 2022 by damerell

[Lisias]

1 hour ago, damerell said:

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.

All parts are scaled the same. What changes are the exponent (**3, **2, **1.5 - yes, you are not limited to 2 or 3!).

 

1 hour ago, damerell said:

• 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.

The 4th item appears to be the faulty one. There's also this buoyancy attribute on the PartModule (not sure since when), but I don't know anything about it - not even if it really works.

You may also be interested in seeing how Firespitter implemented buoyancy to see how it was implemented,  it virtually destroyed the stock Buoyancy in order to do its business.

You may also want to see this thread:

In special the quote below:

On 7/13/2017 at 8:27 PM, NathanKell said:

EDIT ok actually there was a reason--KSP parts can be *insanely* heavy for their volume. Part of the whole scaled-down universe thing. Not as dense as the planets, but denser than real life for sure. You can make a plane that looks like it would mass 5 tonnes in real life and it could easily be 25 in KSP. People just don't realize it. So in order to make water landings non-sinking affairs, we scaled up water density.

 

[damerell]

35 minutes ago, Lisias said:

The 4th item appears to be the faulty one.

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

1 hour ago, damerell said:

 dragCube.Size *= factor.linear;

rebuild it, and send me the resulting DLL? I'll gladly do all the flying of planes into the sea to try it out.

35 minutes ago, Lisias said:

All parts are scaled the same. What changes are the exponent

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.

Edited October 25, 2022 by damerell

[Lisias]

20 minutes ago, damerell said:

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.

We are not scaling blocks of concrete. We are scaling Parts, complex things with many different components with different "densities" (in quotes, as this is not really how KSP works). We don't take a part half-wood and half-iron and scale it as it was made only on iron. The way you can simulate such scalings are by (ab)using the Scale Exponents. KSP doesn't simulate the (hypothetical) internal components of a part, anyway.

Take a Crew Cabin: it have lots os empty spaces, some seats, a bit of glass, lots of structs made of light material, etc. So we can't just scale everything up to the power of 3 and have something that could be used to build things more or less similar to something on real life. The same for engines: an airplane cabin does not have the same average density as a turbo-fan engine (besides both of them floating on KSP - with or without TweakScale).

So we use a 2.5 Exponent to engines and a 2 Exponent for crewed parts and call it a day. The values are approximations far from the real life, but they are good enough for the purposes of this game.

So the Exponents are used to scale the part's characteristics in order to have some resemblance with the real life counterparts. For simplicity, we have essentially free, free_square, stack and stack_square scale types with predefined Exponents. The *_square ones use a 2 Exponent, the other ones use a 3. Scale Behaviours are used to force a different exponent when applicable (as engines that are scaled on a 2.5 Exponent).  Please note that the Exponent used to scale mass don't need to be the same one used to scale thrust, or ISP, or even toughness. You can tinker with different exponents on different attributes to make scaling relevant and challenging - you earn something but also lose something by scaling, what would be the best compromise for a given design? Way more challenging that just dumbly scale everything up or down using the same factor - life doesn't works this way.

And there's nothing blocking you from toying with different ones to see what you get, as 3.5 or 1.75 - including values under 1.0 (but always above 0). You will have some fun toying these values - I surely did!  

On the stock patches, Aero parts and Cabins are usually scaled with the 2 Exponent because it was found that using 3 made the parts (excessively) unrealistic heavy (let's ignore the whole game physics is anything by realistic!  ). Same for engines, that as I said are scaled by a 2.5 Exponent. Science also have a specific Scale Behaviour for them, as well Resource Converters and Decouplers.

You may want to toy with the ScaleExponents instead of compiling TweakScale to meet your needs, you can toy this file https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/patches/020_ScaleExponents.cfg

You will find some needed information on the files on this directory:

https://github.com/net-lisias-ksp/TweakScale/tree/master/GameData/TweakScale/Docs

 

7 hours ago, damerell said:

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 think it's too soon to jump into conclusions, you merely scratched the surface of the problem. There's a lot of scale factors to toy with before breaking scalings by removing code. See the links I posted above. I also ask to pay some attention to the thread I linked on my previous post, this is hot information from the game developers themselves, it may be of use while wondering why things works the way they works.

In fact, while inspecting the files in order to suggest something to you, I think I had may found why you concluded that the buoyancy is being scaled to a factor of 16! Try the following patch and see if things change to you:

@TWEAKSCALEEXPONENTS[Part]
{
	%buoyancy = 1
}

If it works the way I think it works, we may have found the problem for the crazy buoyancy on TweakScale!

You may also want to try something pretty near 0 on it (something like 0.0001) to see what happens.

I found that the buoyancy's exponent was set to 3 on a pretty anciant commit, from 2014 (0.23.5!!) and was never touched again since then...

Well, you may had leaded me to the right path after all!

I have a proposal for you: toy with the exponents I explained above (and with the buoyancy one above all) and see how things behave for you. I will do it from my side as time allows.

In the weekend we try to find a way to chat about our findings and see if mangling with the drag scaling is really needed - I'm suspecting it is not, but if I'm wrong, I will cook a specific exponent to be applied to the drag cubes and so people can make their own choices about it.

[damerell]

2 hours ago, Lisias said:

We are not scaling blocks of concrete. We are scaling Parts, complex things with many different components with different "densities" (in quotes, as this is not really how KSP works).

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.

2 hours ago, Lisias said:

I think it's too soon to jump into conclusions, you merely scratched the surface of the problem. There's a lot of scale factors to toy with before breaking scalings by removing code.

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.

2 hours ago, Lisias said:

I found that the buoyancy's exponent was set to 3 on a pretty anciant commit, from 2014 (0.23.5!!) and was never touched again since then...

On the other hand that is very interesting and I'll try it out later today.

[ColdJ]

@Lisias

Hi the buoyancy parameter does cause differences but it is inconsistant between sizes, or that is how it appears.

I have seen it work between 0 and 1.5. It may go higher but I don't think you would notice by then.

I have had to use the parameter in a few mods.

For Stockalike Aircraft Carrier Decks, after experimenting I had to set it like this.

    buoyancy = 0.1
    buoyancyUseSine = False

Without the parameter or greater than 0.1, then when I spawned a deck into the water it would jump about violently and never settle. If I set it at 0 then it would sink. For a couple of decks I also had to use the drag cube of 1 that that was stable at 0.1, yet there was another one that when I used that very drag cube on it, was unstable, but its real one worked, now that will give you a headache. These single parts are very large and so there is a lot of volume.

I have also set my Cyber truck to 0 so that it would drive into the water to launch the jet ski.

As far as I know, negative numbers don't do anything better than 0.

A very large wheel wouldn't sink even with 0 so I had to give it the drag cube of a smaller wheel, and then it would.

So that is the maze of logic you would be delving into.

If you ever find a logical answer, could you please explain it in terms that someone who glazes over when looking at algebra can understand?

 

[Lisias]

3 hours ago, ColdJ said:

Hi the buoyancy parameter does cause differences but it is inconsistant between sizes, or that is how it appears.

Hummm… Interesting. Thanks for the trials!

 

3 hours ago, ColdJ said:

For Stockalike Aircraft Carrier Decks, after experimenting I had to set it like this.

    buoyancy = 0.1
    buoyancyUseSine = False

Hum… now you caught me with my pants down. What's `buoyancyUseSine` ? 

 

3 hours ago, ColdJ said:

Without the parameter or greater than 0.1, then when I spawned a deck into the water it would jump about violently and never settle. If I set it at 0 then it would sink. For a couple of decks I also had to use the drag cube of 1 that that was stable at 0.1, yet there was another one that when I used that very drag cube on it, was unstable, but its real one worked, now that will give you a headache. These single parts are very large and so there is a lot of volume.

Sinking while setting it to zero makes sense, anything elevated to the 0 power is 1.0 and this is too low for the part.

Setting it to 0.1 , on the other hand, surprised me. That part must be really huge to such a difference in the behaviour.

 

3 hours ago, ColdJ said:

I have also set my Cyber truck to 0 so that it would drive into the water to launch the jet ski.

As far as I know, negative numbers don't do anything better than 0.

Humm.. They should, as negative exponents are, in effect, roots. x**-2 is the same as the sqrt(x) .  As a general rule I tell people to avoid negative exponents because small enough numbers can lead to a 0 after rounding, and you don't want it on calculating mass, for example! (been there, done that!! ), but in some other atributes is can make sense.

 

3 hours ago, ColdJ said:

A very large wheel wouldn't sink even with 0 so I had to give it the drag cube of a smaller wheel, and then it would.

So @damerell appears to have a point! Thanks!

 

3 hours ago, ColdJ said:

So that is the maze of logic you would be delving into.

If you ever find a logical answer, could you please explain it in terms that someone who glazes over when looking at algebra can understand?

As soon as I have one, you will be one of the first to know!  

 

9 hours ago, damerell said:

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.

Hummm, ok. I had misunderstood you. Sorry for that.

 

9 hours ago, damerell said:

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 think I'm seeing your point, but your point assumes that buoyancy is related to volume, and we don't have evidences that this is how KSP works. The @ColdJexperiments appears to suggest that, in fact, it's not.

 

9 hours ago, damerell said:

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).

Jumping into conclusions is not something we want to do, it's something we unattendedly do sometimes. Kraken knows how many times I had done it on TweakScale in the past! I'm not trying to dismiss you, I'm trying to alert you from doing the same mistakes I did in the past!  

But you are not wrong, anyway. Changing the drag cubes will affect the flight behaviour for sure. You can hit F-12 to show you the force vectors then you can check the red vectors comparing  between scaled and uscaled parts! Blue vectors will show you the lift. Yellow will show you the control surfaces forces (you will find that some parts don't give you lift, only "control surface forces").

I wish I had hit F-12 when I made this test, so I could better demonstrate the feature to you!

 

9 hours ago, damerell said:

 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.

Sure thing! But first I will need to know if you will be able to interpret the results, because otherwise I would be digging deeper the hole instead of working to fix it.

There're a lot of experiments I think you need to do in order to be able to compare the results later, otherwise you would be too much prone into jumping into conclusions without being aware of that. As i did in the past.  

 

9 hours ago, damerell said:

On the other hand that is very interesting and I'll try it out later today.

To tell you the true, I had completely missed this one. Really, I never really noticed this exponent before - I'm usually chasing game breaking problems, and these small details usually pass trough. It's the reason I usually try to reserve some quality free time to be pure R&D, without worrying about bugs or anything else - of course, always pending RealLife™ agreement.  

Anyway, @ColdJdid some pretty interesting test in advance, and they appears to suggest the buoyancy is not related to volume - things would not had gone south otherwise when using a buoyancy exponent 1 (or just removing it from the ScaleExponent). 

An interesting information is wheels floating even when using a 0 on the exponent (what would force the buoyancy to 1.0), so there's something else being used to calculate the "effective buoyancy", and you may have a point on suspecting the dragCubes.

But even by being right, we need to balance the consequences. DragCubes are pivotal on atmospheric flights, and we may screw things badly by trying to mangle them to force a behaviour on a secondary feature.

In the end, I really think the best approach is indeed took by Firespitter - just get rid of stock buoyancy and apply your own solution - that will work perfectly fine with TweakScale by installing TweakScale Companion for Firespitter.

Edited October 26, 2022 by Lisias
tyops as usulla...

[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:

1 hour ago, Lisias said:

I think I'm seeing your point, but your point assumes that buoyancy is related to volume, and we don't have evidences that this is how KSP works.

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.

1 hour ago, Lisias said:

Changing the drag cubes will affect the flight behaviour for sure.

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.

1 hour ago, Lisias said:

But first I will need to know if you will be able to interpret the results.

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.

1 hour ago, Lisias said:

Anyway, @ColdJdid some pretty interesting test in advance, and they appears to suggest the buoyancy is not related to volume - things would not had gone south otherwise when using a buoyancy exponent of 1.

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.

1 hour ago, Lisias said:

Hum… now you caught me with my pants down. What's `buoyancyUseSine` ? 

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.

Edited October 26, 2022 by damerell

[Gotmachine]

Part.buoyancy is essentially a corrective factor applied over the part default buoyancy derived from the part estimated volume (itself derived from the drag cube) and mass.
Said otherwise, it's a factor to do an arbitrary final adjustment of the part density in the context of the buoyancy formula, which mean it doesn't make any sense to scale it when a part is rescaled.

[damerell]

1 hour ago, Gotmachine said:

Part.buoyancy is essentially a corrective factor applied over the part default buoyancy derived from the part estimated volume (itself derived from the drag cube) and mass.
Said otherwise, it's a factor to do an arbitrary final adjustment of the part density in the context of the buoyancy formula, which mean it doesn't make any sense to scale it when a part is rescaled.

That's how I think it works, but I'm not sure from what you write if you somehow know that that definitely is the case.

[Lisias]

16 hours ago, damerell said:

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.

Setting the buoyancy to 0 is the same as removing the buoyancy from the ScaleExponent.

Once I confirm the information from my side, the fix appears to be pretty obvious - don't touch the thing!

 

16 hours ago, damerell said:

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.

Exactly. The dragcubes is used to help infer approximated volume, not the buoyancy value! Thus buoyancy thing plays a role, but not on volume!

I think we are clashing on nomenclatures!  I will try to graphically differentiate the real life concept "buoyancy" from the PartModule's buoyancy atribute from now on.

Anyway, by mangling the dragcubes, we will be mangling the volume of the scaled part - something that by all effects, appears to be being done right.

One way to confirm this is to brute force scale a part into a new part by hand, and let KSP automatically compute the dragcubes of that part, then scale the original part the same using TweakScale, and then launch a craft with both parts and compare the dragcubes. I think ObjectInspector may be of help on this task.

Whatever KSP does to compute the dragcubes of the handmade part, TweakScale needs to follows suit on the scaled part. Point. Doing it differently will make the part misbehave once scaled.

— — — 

I'm not dismissing the remaining of your post, I just don't have time right now to further explore it - so I rushed some thoughts that I wanted to highlight in advance in the hopes of saving some time in the mean time.

Cheers!

[ColdJ]

15 hours ago, Gotmachine said:

Part.buoyancy is essentially a corrective factor applied over the part default buoyancy derived from the part estimated volume (itself derived from the drag cube) and mass.
Said otherwise, it's a factor to do an arbitrary final adjustment of the part density in the context of the buoyancy formula, which mean it doesn't make any sense to scale it when a part is rescaled.

Would certainly like to hear more.

16 hours ago, damerell said:

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).

Very interesting. I have never tried to set it to true. I just use it because the stock parts do. I think I got it from a Mk1 command pod config.

@Lisias Now something jogged in my brain but I can't remember if you had mentioned it or I read it somewhere else. You can have more than one drag cube, one for flight and one for water. They have unique names for each, but I cannot remember where I read it or the exact labels to give them.

[Lisias]

10 minutes ago, ColdJ said:

@Lisias Now something jogged in my brain but I can't remember if you had mentioned it or I read it somewhere else. You can have more than one drag cube, one for flight and one for water. They have unique names for each, but I cannot remember where I read it or the exact labels to give them.

I will try to find it out. TweakScale only mangles the PartModule's "this.part.DragCubes.Cubes" thingy, if there's more to be scaled, I need to know!

(not, it was not me - or I need to see a geriatrician!  ).

Cheers!

[Gotmachine]

1 hour ago, ColdJ said:

Would certainly like to hear more.

It's quite simple. Part.buoyancy is the per-part equivalent of PhysicsGlobal.BuoyancyScalar (which you can tweak in Physics.cfg).
In short, the formula for the magnitude of the force applied on a part by water is (physically "accurate" result derived from the drag cube and part mass) * PhysicsGlobal.BuoyancyScalar * Part.buoyancy.
Default value for PhysicsGlobal.BuoyancyScalar is 1.2 (to account for the fact that stock parts are way too dense).
Part.buoyancy default value is 1, and is sometimes tweaked up or down on stock parts to account for even sillier densities.

In the context of rescaling a part, assuming both the drag cube and mass scaling are accurate, density is staying equal and nothing else is needed. Messing with Part.buoyancy mean that you're altering the part density, which is obviously wrong.

I haven't read the whole convo in detail, but part.buoyancy set aside, if as @damerell suggested TS is only scaling the drag cube area and depth (and not size), it's no surprise that effective buoyancy results are inaccurate, as the formula make extensive use of the drag cube size.

EDIT : to ensure a scaled part is keeping the same density, one can check the Part.partBuoyancy.displacement value.
This is the intermediate result of the drag cube/mass computations before any "cheat" is applied (BuoyancyScalar/buoyancy), aka the "physically accurate" density of the part. Ideally, it should stay the same no matter the part scale.

Edited October 27, 2022 by Gotmachine

[damerell]

3 hours ago, Lisias said:

I think we are clashing on nomenclatures!  I will try to graphically differentiate the real life concept "buoyancy" from the PartModule's buoyancy atribute from now on.

Ah. That makes more sense of some of the things you have written.

However, I think it's moot now you have suggested a fix which seems to work perfectly; I can only distinguish the 2x scale craft above because it floats with the root part 2m above sea level. I still suspect some of what TweakScale changes about the dragcube is redundant, but if it ain't broke, don't fix it, I guess.

@Gotmachine- you're making some very definitive statements and I'd still be interested to know if you have a source for these. Apologies if it's common knowledge to everyone but me that you used to be a KSP developer, or something.

[Lisias]

21 hours ago, damerell said:

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.

Got a little break while paying some bills, and made a quick test.

It's still too premature to be absolutely sure, but apparently the error on TweakScale is mangling the buoyancy attribute from PartModule.

So, my previous statement are still valid: TweakScale is scaling the dragCubes the right way, and mangling with them in order to force a desired behaviour will mostly certainly screw up something else.

What doesn't means that we should not toy with the idea. While thinking in what you had proposed, I came to the conclusion that even by not pushing it into the mainstream, there's no reason to do not allow a configuration to change the scaling of the dragCubes in the same way there's a configuration option to mangle the buoyancy.  It's a mistake to use it if you want stock like behaviour, but hell - why prevent people from doing crazy things if this is what they would want? @ColdJ add'ons may be directly beneficed by it, as it appears.

humm… I just called @ColdJcrazy!!!  It was not my intention… This time.  

 

21 hours ago, damerell said:

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 understood. My point is that without knowing exactly how all the aspects of the DragCubes affect the game's physics engine, mangling them to induce a behaviour will fatally create undesired side effects somewhere else, usually on something you will not detect immediately.

Been there, done that - and not only on TweakScale (I'm not new on this modding thingy). I have a Beta version of TweakScale running for two years exactly because of that - most features on Beta I wrote 1 year ago is only now reaching mainstream.

It's perfectly possible that you are not wrong on assuming you can mangle the two or single dimensional attributes from the DragCube in order to induce a new behaviour - and, in fact, this idea appears to be too damn good to let it pass without a try first on the Beta program. But I'm extremely reluctant on shove this thing into mainstream without a lot of testings - and, most of all, will not do it as a regular feature on the standard patches without an absolutely compelling reason (like someone pointing a gun on my head).

 

21 hours ago, damerell said:

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 stand corrected at the same time I still withhold what I said.

For @ColdJ I think things would not gone south that way under a buoyancy equal to 1.

See the exponent as the how many dimensions you want to scale: 0 = No Scaleing, 1 = Linear Scaling, 2 = Quadratic Scaling, 3 = Cubic Scaling, anything else = going extraterrestrial, metaphysical or doing a Leap of Faith without a hailstack downthere.

But you are also correct : an exponent == 0 will effectively disable scaling the attribute, and this is apparently the correct way of fixing the buoyancy of the scaled parts!

 

21 hours ago, damerell said:

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 have no problem on doing crazy (and sometimes stupid) things. I'm only reticent on pushing them into mainstream without some time on QAS first - and even by doing that, I got bitten in the SAS more than once.

The idea of mangling the dragcubes by TweakScale is not bad, not bad at all. Using it to solve a problem that I think should be fixed in an orthodox way is the problem on my book.

 

21 hours ago, damerell said:

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.

I think @ColdJ was bitten in the SAS due the way he mangles the dragcubes on the new parts - in order to force the buoyancy he needs, he gone the dragCube way. Since he is going nautical and/or subnautic (is there such world in English?), the stunt worked fine for him - and nobody is going to make a flying Titanic anyw…

Hummm… belay that, this is KSP, of course someone will try to make a flying Titanic, Doctor Who style!!!

Allons-y, Alonzo!!!

Spoiler

 

 

1 hour ago, damerell said:

However, I think it's moot now you have suggested a fix which seems to work perfectly; I can only distinguish the 2x scale craft above because it floats with the root part 2m above sea level. I still suspect some of what TweakScale changes about the dragcube is redundant, but if it ain't broke, don't fix it, I guess.

Ahhh, that's the point!!

I wasn't willing to use your idea to fix the part's buoyancy (unless not other alternative was possible), but I liked the idea of allowing users to mess with the dragcubes scalings!

I just will not use it on the standard patches but, hell, someone will have fun mangling them once I implement it somehow, I'm absolutely sure!

In a way or another:

https://github.com/net-lisias-ksp/TweakScale/issues/267

https://github.com/net-lisias-ksp/TweakScale/issues/252

Cheers!

[Gotmachine]

2 hours ago, damerell said:

you're making some very definitive statements and I'd still be interested to know if you have a source for these. Apologies if it's common knowledge to everyone but me that you used to be a KSP developer, or something.

I'm just another modder. Lets just say that we have ways to see what is happening exactly under the hood.

[Lisias]

6 hours ago, Gotmachine said:

I'm just another modder. Lets just say that we have ways to see what is happening exactly under the hood.

I would like to have any potentially prone to litigation technics away from this thread.

We already had this discussion before. I would prefer you would talk about these matter in PVT messages or other threads, please.

Edited October 27, 2022 by Lisias
damn grammars.