Stock Mk3 values seem to be off

[linuxgurugamer]

I'm looking into some of the config files of the stock parts, using them as reference, and I noticed the following oddity:

In the Mk3 Shuttle parts, the maximum drag is set lower than the minimum drag.  This doesn't make sense, can someone explain this:

 

maximum_drag = 0.2
minimum_drag = 0.3

I need to know because the parts I'm updating are shuttle parts from another mod.

Thanks in advance, and, if this is in the wrong forum, please move it to the correct one.

 

[Shadowmage]

Those values are no longer used on parts that have drag-cubes, and are safe to ignore on most non-wing/non-control surface parts.

Sadly I'm unsure as to a 100% reliable method to tell which parts this applies to except to look inside the drag-cube database/cache file and check for an entry for a given part.

 

[linuxgurugamer]

Just now, Shadowmage said:

Those values are no longer used on parts that have drag-cubes, and are safe to ignore on most non-wing/non-control surface parts.

Sadly I'm unsure as to a 100% reliable method to tell which parts this applies to except to look inside the drag-cube database/cache file and check for an entry for a given part.

 

Drag cubes, would be specified in the config, right?  So if these old parts don't have drag cubes, I'll still need them?

[Shadowmage]

Just now, linuxgurugamer said:

Drag cubes, would be specified in the config, right?

They are not specified in the part config file, but a separate file in the root KSP directory (PartDatabase.cfg I think it is called).  (a few parts do have drag-cube overrides in the part.cfg file, but those are a separate deal than the automatically generated drag-cubes stored in the PartDatabase.cfg file)

The only parts that get excluded from drag-cube creation are those with a 'dragModel' set to something other than 'default'.  So if the part.cfg file has 'dragModel = default' or completely lacks a 'dragModel' entry, it should be safe to assume that it does use drag cubes and does not need the min/max drag config values.

 

3 minutes ago, linuxgurugamer said:

So if these old parts don't have drag cubes, I'll still need them?

If they are not wing/control surfaces, it is highly likely that they -do- have drag cubes generated by the KSP code.

Cockpit or fuselage parts should have drag cubes.  Wings, tails, and elevons likely do not.

[blowfish]

Drag cubes are generated automatically and saved to PartDatabase.cfg (I am not entirely sure of when this cache is invalidated).  The cases where drag cubes are specified on the part are those where the default procedural drag cubes don't work, mainly cargo bays.

[linuxgurugamer]

Just now, blowfish said:

Drag cubes are generated automatically and saved to PartDatabase.cfg (I am not entirely sure of when this cache is invalidated).  The cases where drag cubes are specified on the part are those where the default procedural drag cubes don't work, mainly cargo bays.

ok.  So one of the part is (surprise) a cargo bay.  How can I set up the drag cubes?

[linuxgurugamer]

I assume that if a drag cube is definied in a file (such as in the mk3CargoBay), it overrides the dragModelType?  Because in the mk3CargoBay, the dragModelType = default

one more question, I noticed that in the stock Mk3 parts, there is no ModuleLiftingSurface.  Is that taken care of by the default drag cubes?  Reason for this question is that the mod I'm trying to update has ModuleLiftinSurface modules in the cockpit and other parts which the stock equivilents don't.

Thanks in advance

[Shadowmage]

I'm not so sure on how the drag-cube overrides work with the cargo bays.  Its something I've never been able to get working when I tried to use similar systems.  For my own cargo-bay type parts, I just go with whatever the drag-cube system renders for them, but I've never tested how accurate it is compared to similar stock parts.

I think ModuleLiftingSurface might be okay to use with drag-cubes, pretty sure I'm using it myself on my shuttle body for body-lift, and that part certainly uses drag-cubes (and it has an integrated cargo bay!).  No overrides or anything funny.  Just let the stock system do its stuff.

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L354-L360

Note however that I had to specify the ' useInternalDragModel = False ' or it did mess with the rest of the drag system for that part.

 

The stock parts just use the body lift generated by the default drag cubes.  Which for general purposes is acceptable.  For lifting bodies, such as a full shuttle system, there probably should be added body-lift which the ModuleLiftingSurface can take care of.

[blowfish]

Regarding cargo bays -

The problem is that usually the models are hollow tubes, whereas when a cargo bay is closed you want it to have the same drag characteristics as a solid fuselage piece.  So the usual process is this:

• Have two parts, one of which is a cargo bay and one of which is a solid part with the same shape
• Run KSP
• Open PartDatabase.cfg
• Copy the drag cubes from the cargo bay and put them in the part's CFG
• Copy the drag cube from the solid part and replace the cargo bay's closed drag cube with that in the CFG

If the cargo bay doesn't have empty ends, none of this needs to happen.

Regarding dragModelType, there are only a few significant values: "SPHERICAL", "CYLINDRICAL", "CONIC", "OVERRIDE", and "NONE" (override and none are the same).  Everything else defaults to the default cube implementation.