Need to run a delayed drag cube update for root parts; delay until ???

How do you even tell that the drag cube is wrong?

Lots of debug spam :)

Originally I had a craft I was using that had a 0.625m tank at the top for a probe, which was the root part for the vessel; whenever I turned on the aero overlay to investigate the craft flipping problems, I could see that this tiny little tank had about 3-4x as much drag as the 1.25m (much larger) tank below it. But when I changed the root part to be the nosecone (or any other part), this drag disparity vanished.

This is because during loading, stock code will reload the drag cube for the root part from the part database (reloading drag cube for zeroed cube root part; or somesuch message). This causes problems with the modular parts as the drag cube in the partDatabase is simply incorrect for most cases (it is for a 2.5m x 7.5m tank).

However when I went to look into this and 'fix' it yesterday it looked like my drag cube updates were already happening after the stock drag-cube-reload-from-config;

In the end I'm going to have to dig in a bit deeper and do more debugging and checking on when/where these drag cubes are getting out of whack.

--- I also have a debug rendering module that will render a procedural mesh for the current bounds of the parts' drag cube. Haven't yet tested this debug/module out, but it will likely come in use when debugging drag-cube problems if it functions at all like I intended it to.