Drag cubes... omg

[Fengist]

Ok, so I'm working on making arresting gear for my carriers.  So today, I decide to make an arresting hook.  So, I whip out Wings 3D, make me a nice model, unwrap it, paint it all up, load it into Unity, get my animation working, write the mbm and make up my nice little .cfg file.

And then, I load up KSP and I realize I seriously goofed.  Instead of being 1.5 meters long, it's 50 meters long.  Ok... so, back to Wings.  I scale it all down to 1.5 meters, reload the .obj exports into Unity and write a new part.  I reload the database and perfect.  It's just the size I want.  

So now I'm out flying around and I notice my plane is not performing very well.  Normally, my little test plane can hit 250 m/s + with no effort.  Now, it's barely doing 80.  And it gets even more strange.  When I raise my arresting hook, the plane flies slower?  Whut?  Ok, fine, I'll try to land on the carrier.  When I do, I hear this noise before I even get to the carrier.  And I know it's not my modding, I haven't even added in sounds to the arresting cables yet.  And then, the plane just dives into the ocean.  WHUT?  

So I spend 4 hours rearranging my code thinking it's activating before it should, I'm adding in log entries... I get it so screwed up, it's not even working half the way it was.  I'm re-exporting the model, re-doing the animation...  I'm going in complete circles trying to figure out why my plane is nose diving just before it gets to the arresting gear and flying like a slug.

And then... it hits me.  Drag cubes.  When I first put the model in KSP at 51 meters, it calculate the drag cube.  And kept it that way.  My little jet was shoving around an invisible 51 meter box surrounding a 1.5 meter part.

Why was my plane nose diving into the ocean?  The 51 meter drag cube was hitting the rear of the carrier long before I got there.

I deleted the drag cube entry, it got recalculated and now it works as it should.

Something needs to be done to... say in the debug console... recalculate all drag cubes.  Or even better, check the timestamp for the model to see if it's changed and if so... recalculate the drag cube.

God knows how many other parts I've done this to.

[SpannerMonkey(smce)]

On 16/07/2016 at 1:49 AM, Fengist said:

Ok, snip

God knows how many other parts I've done this to.

HI I  know you're not alone , it happened to me all the time when i returned to ksp modding, I could not work out why my changes weren't having any effect, it was then i discovered that from v1 onwards ksp keeps a part database that is written when you first load the part, and no matter what you alter or modify after that point,  the game always loads the part database info.

My easy solution these days is simply to delete the Part Database.cfg and all the MM cached info after every run. Now if you could write a little plugin to do that automatically on game close that would be perfect

Edited July 17, 2016 by SpannerMonkey(smce)

[Stone Blue]

43 minutes ago, SpannerMonkey(smce) said:

My easy solution these days is simply to delete the Part Database.cfg and all the MM cached info after every run. Now if you could write a little plugin to do that automatically on game close that would be perfect

I've been doing this also, after I realised awhile ago, that reloading the database using the debug menu, was not applying changes I was making...NOT just drag cubes... So I rarely use the debug menu anymore for reloading... I found after wasting time chasing my tail after figuring out why .mu/.cfg changes I was making werent showing after reloading, it was best just to shutdown and restart KSP altogether... ALONG with, deleteing the MM & part database .cfg like Spanner said above...

Just be careful, if you have Blizzy's Toolbar installed, not to accidentally grab the toolbar_settings.dat file along with the 4 MM files to delete... THAT will seriously mess your game up, and make you chase your tail for awhile...

NOT that "I", would have any intimate knowledge of such occurance...

Edited July 17, 2016 by Stone Blue

[Beale]

Some way to visualise drag cubes would be very useful. Is there any way to do it / plugin?

Edited July 21, 2016 by Beale

[NecroBones]

3 hours ago, Beale said:

Some way to visualise drag cubes would be very useful. Is there any way to do it / plugin?

 

Not that I'm aware of. It might be hard to make something that displays it meaningfully. The word "cube" is a little misleading, because it's not actually a "cube" in the normal sense. It's a set of drag coefficients and depths, from each of the six cardinal directions. So you can imagine a cube, where each face is a piece of paper with some numbers written on it.

 

 

[Fengist]

I read Nathan Kell's explanation of them.  I was better off not knowing anything about them.  However, when they begin to have the same effect as a collision mesh, have HUGE effects on buoyancy... and you can't replace what's already created so if your mod changes, it's screwed, I guess it's time to figure them out.

So, @NecroBones.  You seem to have some grasp on how these things work.  Now I understand the first three pairs of three numbers represent the x+/x-, y+/y-, z+,z-.  The others I forget what they do.  But for the moment, let's assume my part has had it's drag cube calculated.  I know I can go grab a copy in the part database and shove that into my .cfg file.

So here's some things that I need to figure out with drag cube and you may be able to explain it.

First, I have one part that's entirely too tall., from the perspective of buoyancy.  How can I adjust that 'z' factor to make it appear shorter? (it goes below the surface of the water an causes my boats to roll over on their side)

Next, let's assume I want to decrease the drag that these parts suffer in water.  How?

Now let's assume I want to increase the buoyancy.  How?

Nathan is absolutely horrid at explaining things. I'm sure he knows what the hell he's talking about, I have no clue.  I'm hoping you can explain these things.

 

Thanks.

Edited July 22, 2016 by Fengist

[Shadowmage]

15 hours ago, Fengist said:

I read Nathan Kell's explanation of them.  I was better off not knowing anything about them.  However, when they begin to have the same effect as a collision mesh, have HUGE effects on buoyancy... and you can't replace what's already created so if your mod changes, it's screwed, I guess it's time to figure them out.

[snip]

 

Thanks.

Well, I might be able to answer one of your questions.

Drag cubes used for bouyancy can be overriden at the part config level by specifying a custom drag cube to use for the bouyancy calculations; this drag cube does not necessarily need to be used anywhere else on the part, and can (I believe) be specified as a drag-cube override in the part.

The field for the override is named 'buoyancyUseCubeNamed', it defaults to no override, but you can specify the name of any drag-cube that is in the PartDatabase.cfg for that part.  Example use: buoyancyUseCubeNamed = customWaterDragCube  (where customWaterDragCube refers to a custom drag cube that you have specified as a drag-cube override in the part config).

To add override drag-cubes to parts.. umm... I honestly don't remember the precise steps for it, but there are a few stock parts with examples (cargo bays I think); sorry, at work at the moment and don't have access to the SQUAD folder to lookup exactly what parts.

There are also the part fields of 'CenterOfBuoyancy' and 'CenterOfDisplacement' that might be easier alternatives to some of your problems;  I'm not overly familiar with them, so cannot offer any examples on their use.  I believe these can both be specified at the part config level, and should consist of a Vector3 (e.g. CenterOfBuoyancy = 0, 0.5, 0).

 

[Fengist]

19 hours ago, Shadowmage said:

Well, I might be able to answer one of your questions.

Drag cubes used for bouyancy can be overriden at the part config level by specifying a custom drag cube to use for the bouyancy calculations; this drag cube does not necessarily need to be used anywhere else on the part, and can (I believe) be specified as a drag-cube override in the part.

The field for the override is named 'buoyancyUseCubeNamed', it defaults to no override, but you can specify the name of any drag-cube that is in the PartDatabase.cfg for that part.  Example use: buoyancyUseCubeNamed = customWaterDragCube  (where customWaterDragCube refers to a custom drag cube that you have specified as a drag-cube override in the part config).

To add override drag-cubes to parts.. umm... I honestly don't remember the precise steps for it, but there are a few stock parts with examples (cargo bays I think); sorry, at work at the moment and don't have access to the SQUAD folder to lookup exactly what parts.

There are also the part fields of 'CenterOfBuoyancy' and 'CenterOfDisplacement' that might be easier alternatives to some of your problems;  I'm not overly familiar with them, so cannot offer any examples on their use.  I believe these can both be specified at the part config level, and should consist of a Vector3 (e.g. CenterOfBuoyancy = 0, 0.5, 0).

 

Yep, I've played with copying the drag cube over to the .cfg and playing with it. But honestly, since I have to do that to every single part, I have no idea whether it's having any effect... or what I'm even doing for that matter.  The whole drag cube makes no sense.  I don't even know if those triplet numbers represent a point or an area (one of the stupid things about Unity using vector 3's, you never know which it is).  I'm sure it all makes sense to Nathan, but he's not normal.  Just read some of his 'explanations' of how things work and you'll soon realize that.

Don't get me started on the center of things...  as far as I'm concerned, center of buoyancy should be right there in the API just like CoM.  I should not have to iterate through every single part on the vessel and come up with some crazy euler quaternization vector math to figure out where CoB is.  Individual part center of buoyancy, makes little difference unless your vessel explodes on the water and then, other game physics are so screwed up it looks like you dropped a bag of ping pong balls in the middle of a parking lot.

No, here's my problem with drag cubes.

Let's say my 'submarine' comes in at 100 tons (Yea, right now I have to put 40 tons of mass onto it to make it sink).  I need an engine with TWO HUNDRED FIFTY thrust to even make the thing move and that's a 2.5 meter part.  I just now finished testing a 2.5 meter submarine that had to weigh in at 100 tons to submerge.  100 thrust barely moved it under water (1.4 m/s).  I realize density has an effect on things, but my god. I didn't have half these problems before the 'buoyancy fix.' Before this, I had to think of my parts as Styrofoam to make them float. Making them sink was pretty easy.  Now, to keep them from bouncing around on the surface of the water I've had to massively increase the mass.  Increased mass = increased drag.  Increased drag -> more thrust.  Don't even try to sink a Mk3 part.  Even Firespitter's buoyancy is screwed to the point of being mostly useless.  The only thing I can imagine having these kinds of effects are drag cubes.  My screw up in the OP clued me into to that.

I simply don't know what I'm looking at in order to 'fix' my parts.

Yea, I know... buoyancy is designed so you can land aircraft on water.  It's a game about aircraft and rockets.

My response... don't give me a freaking sandbox and then tell me I'm limited to what toys I can play with.

Edited July 23, 2016 by Fengist

[Fengist]

And it just happened again:

I'm creating some parts that I'm needing to scale up in Unity to 1.25.  At some point it appears I scaled the part to 1.25 and had the collision mesh as a separate object and scaled it to 1.25 as well.  Then I guess I moved the collision mesh to be a child of the main object and forgot to scale it back to 1.

So, my part was scaled to 1.25 and my collision mesh was further scaled to 1.25.

KSP made the drag cube.

I realized my mistake and scaled the collision mesh back to 1.

KSP kept the drag cube at the size of the freaking collision mesh.

I'm about to create a damned batch file so that every single time I run KSP in 'dev' mode it deletes that stupid part database.

I'm coming to the realization that if you're going to mod for KSP, you better put a drag cube in every single part .cfg and hope that it overrides whatever it automatically creates.  God forbid you should release a part that's the wrong size and then release a fix.  Your end users wouldn't know to delete that stupid part database.

Edited July 23, 2016 by Fengist

[Shadowmage]

Here is a bit of info that I've put together on what the numbers in the drag cubes represent, mostly from info that NK posted in one thread or another, hopefully it can help shed a bit of light on what those values actually represent (though I've not been able to make much use out of it even after I knew what they meant).

Drag Cubes

• x+ area, drag, depth  (first triplet)
• x- area, drag, depth  (second triplet)
• y+ area, drag, depth (third triplet)
• y- area, drag, depth (fourth triplet)
• z+ area, drag, depth (fifth triplet)
• z- area, drag, depth (sixth triplet)
• bounds center  (seventh triplet)
• bounds extent  (eighth triplet)
• The first six triplets are the six faces of the cube, with the first value being the area, the second the drag coefficient, and the third it's depth.  Mind you, the drag cubes do not represent an actual shape or object.
• The next triplet is the bounds center, the final is the bounds extents (these two roughly form the bounding box of the objects rendered mesh).

 

On my end ModuleManager auto-deletes the PartDatabase.cfg whenever it detects config-level changes (though I don't think it monitors model files), so I've never had too much of a problem with out-of-date drag cubes as the database is being rebuilt nearly every time I relaunch the game.

While you are in KSP you can also tell MM to force-rebuild the drag-cube cache; there is a 'Reload Database' and 'Reload Database (quick)' -- the quick method skips drag cube updates; the regular one will re-render all drag-cubes/rebuild the database.

 

I fully understand your frustration; drag-cubes have been nothing but a headache for me and have outright broken several part concepts (due to conflicts of modules' that manage drag cubes; e.g. no parachutes on animated parts). 

I know this info doesn't fully answer your questions, but hopefully it can be of some use to you.

[Fengist]

I read a book by Michio Kaku, the theoretical physicist.  In it, he stated that some cultures believe you achieve nirvana if you can mentally visualize a hypercube (also know as a tesseract), a 4 dimensional cube, being rotated in 3 dimensional space.  You sir, just described a facet of some peoples lives that make them think they have become one with the universe..

And we're suppose to make sense of this mess?

This is a 4 dimensional tesseract being rotated in 3 dimensions.

This is an exploded three dimensional view of a 4 dimensional tesseract.

And this...is just 6 of the 8 triplets you described. Looks strangely familiar...

I can think of one quote that so utterly sums this up: "The more they overthink the plumbing, the easier it is to stop up the drain." -  James Doohan, The Search for Spock.  Ok, I can handle multi-dimensional arrays.  It's a letter on a line on a page in a book on a shelf in a library... etc.  There's got to be some way to 'fix' this fubar.

If I read you correctly... in order for me to change the drag on the part, I need to change 6 numbers? The middle number in all 6 triplets????  Or more??? 

And I don't typically keep MM installed in my stripped down build so...

 

[Fengist]

Ok, Experimentation time:

Experiment 1:  Does a .cfg drag cube override the PartDatabase.cfg.

The answer is:  YES.

I have a part that's rather large.  So large in fact that when I put 70 TONS of my resource (Compressed Water) directly in the part, it refuses to sink.  Here's the drag cube that KSP calculated.

Drag cube in the PartDatabase.cfg:

    DRAG_CUBE

    {
        cube = Default, 29.21,0.7414,4.811, 29.21,0.7458,4.811, 36.08,0.6391,5.828, 36.08,0.5645,2.854, 29.42,0.7434,4.811, 29.42,0.7456,4.811, 0,3.73,0, 7.236,7.46,7.236
    }

I copied that from the PartDatabase.cfg and placed it in the part.cfg.  I then changed the values of the first number in each of the 6 triplets (the area).  All of the 29's and 36's were changed to 5.  Here's what I put in the part.cfg.

            DRAG_CUBE
            {
                cube = Default, 5.21,0.7414,4.811, 5.21,0.7458,4.811, 5.08,0.6391,5.828, 5.08,0.5645,2.854, 5.42,0.7434,4.811, 5.42,0.7456,4.811, 0,3.73,0, 7.236,7.46,7.236
            }
 

Deleted the PartDatabase.cfg and reloaded the database from F12 and....

The part sank like a rock without any added ballast.  So, that 'Area' number DEFINITELY affects buoyancy.

 

Edited July 24, 2016 by Fengist

[Fengist]

Experiment 2:  Does the 'Area' number in the drag cube affect drag?

Using the same part on the same vessel as in expriment 1 I deleted the PartDatabase.cfg and removed the drag cube from the part.cfg so that KSP would rebuild the drag cube from what I thought the part should be.

I then fired up this water-bourne vessel's engines.  Max speed, 20.1 m/s with the 'fat' drag cube.

I then took the 'Area' number and divided that by 2 for each of the 6 triplets and added that to the part.cfg.

Original

   DRAG_CUBE

    {
        cube = Default, 29.21,0.7414,4.811, 29.21,0.7458,4.811, 36.08,0.6391,5.828, 36.08,0.5645,2.854, 29.42,0.7434,4.811, 29.42,0.7456,4.811, 0,3.73,0, 7.236,7.46,7.236
    }

Updated

    DRAG_CUBE
    {
        cube = Default, 14.61,0.7414,4.811, 14.61,0.7458,4.811, 18.04,0.6391,5.828, 18.04,0.5645,2.854, 14.71,0.7434,4.811, 14.71,0.7456,4.811, 0,3.73,0, 7.236,7.46,7.236
    }

Vessel's max speed:

22.4 m/s

So yes, it does have some effect on drag.

Next experiment, changing the drag coefficents.

[Fengist]

Yea, I got tired of playing this game real quick.  So, I reduced the drag coefficient by 50% for that ONE part, out of 26...  The vessel's speed in water incresed by 30% and didn't affect buoyancy.

So, now I'm looking at manually tweaking drag cubes for some 70+ parts?

Ohhhh no.

Experiment away.

Thanks @Shadowmage.  You gave me the exact information I needed to tackle this problem.  AND, unlike NK, it was in ENGLISH and not gobbeldeygook techno... whutever.

I hope you find this little calculator useful.  You, and my migraine, inspired it.

Edited July 24, 2016 by Fengist