[Backslash]

Yeah that was hard to title clearly.  Ok, look at objecttypes.tbl +Active Docks.  See that the second type is labeled "rearm".
Now look at the sample table, and find an entry that has an +Active docks.  Notice that the type is "support".  The example is straight from the globalincs\def_files.cpp .

ModelRead.cpp shows

Code: [Select]

flag_def_list Dock_type_names[] =
{
  { "cargo",    DOCK_TYPE_CARGO,   0 },
  { "rearm",    DOCK_TYPE_REARM,   0 },
  { "generic",   DOCK_TYPE_GENERIC,  0 }
};So, "support" vs. "rearm, which one is correct?  I'm pretty sure they are currently not working as planned.  Or am I overlooking something?

...also, there are a lot of case mismatches between the parse_ship_type in ship.cpp, vs. the default_shiptypes_table (or the wiki) ... for example "+Can form wing:" vs. "+Can Form Wing:".  Does it matter, or does the parsing compensate for this?

[WMCoolmon]

"rearm" is correct. I went back to the earliest revision of modelread.cpp and that's what was used, so it must've been one of those elaborate typos or a PEBKAC error.

[Wanderer]

Not sure if it actually even matters... models seem to get their dock's assigned during model load as well.

modelread.cpp line ~ 2777

Code: [Select]

// determine what this docking bay can be used for
if ( !strnicmp(bay->name, "cargo", 5) )
bay->type_flags = DOCK_TYPE_CARGO;
else
bay->type_flags = (DOCK_TYPE_REARM | DOCK_TYPE_GENERIC);
Also the 'optional strings' - like most of the parsing stuff - seem to be using strnicmp which should be case insensitive. So as long as you get the letters right the case shouldn't matter

[WMCoolmon]

It does for parsing the objecttypes.tbl stuff, as they seem to get their types from the flag_def_list, which doesn't have a "support" entry. Presumably it just ends up as -1 that way. Why that hasn't caused a problem yet I don't know - maybe the code uses the first dock it can find if there are no "rearm" docks.

[Wanderer]

I thought the code snippet i posted explained it... It seems to set the values for the docking points that seemingly override those found from the objecttypes.tbl.

[WMCoolmon]

It doesn't change the values set for ai_active_dock and ai_passive_dock, and those values don't have the original string equivalents stored after they're parsed. So there's no way for FS2Open to know if those docks are equivalent with anything else if they're set to 0 after parsing. Support ship code might ignore them entirely but they are used for other things.