Make comm order types modder-configurable, and add separate types for fighters and bombers

[Kestrellius]

Comm order types (that is, the list of things that can be messaged -- ships, wings, reinforcements, etc.) are now no longer a fixed list. Of the eight possible types, the modder may specify an arbitrary list in arbitrary order, with text specified in the table.

This was to facilitate the addition of two new types, All Fighters and All Bombers -- as distinct from the retail type typically called All Fighters, which is really "all fighters and bombers". (All player-facing retail naming remains as default.) My experience as a player suggests that these new options will be extremely useful.

[wookieejedi]

I think this should be for (auto &item : MsgItems) similar to how the traitor check right above this uses for (auto &item : MsgItems)

[wookieejedi]

I reckon the config mode section shown on the HUD Config screen also be updated to reflect these changes so that players/mods get shown an accurate representation of what the comms menu will look like.

[wookieejedi]

This should possibly be guarded by the !config flag? IE since the default config screen may have a different number that could end up being out of bounds

[wookieejedi]

Original logic was (Player_ship != NULL) && !hud_squadmsg_reinforcements_available(Player_ship->team) -> 0 so looks like we need to remove the ! here for the hud_squadmsg_reinforcements_available function.

Also, C++ should be smart enough to realize the returned bools are 0 or 1 but would it make sense to clearly stated it with ? 0 :1?

[wookieejedi]

Old code overwrote a fixed array while the new one emplace_backs, so you may consider adding a clear() for extra safety

[wookieejedi]

Minor, but may not need the 'breakif you are already usingreturn`

[wookieejedi]

Minor, but extra whitespace. May be on purpose though?

[wookieejedi]

Very useful feature to have! Added some in-line comments and here are four more general ones:

1. Order flavor is lost for multiplayer clients (see around multimsgs.cpp:4553)

hud_squadmsg_send_to_all_fighters() short-circuits for MULTIPLAYER_CLIENT into send_player_order_packet(SQUAD_MSG_ALL, 0, command) (hudsquadmsg.cpp:1027), which does not have the new small flavor aspect in the packet. As such, the server-side handler calls hud_squadmsg_send_to_all_fighters(command, player_num), defaulting to ALL_FIGHTERS_AND_BOMBERS. As a result, a client choosing "All Bombers" orders every fighter and bomber. To fix this the packet needs a flavor field (note, this will also result in a multiplayer version version bump, which is fine since we can merge this the same day the other multiplayer version bump PRs for 26.2 are needed).

2. FS2_VOICER builds break (see around voicerec.cpp:80)

Local declaration extern void hud_squadmsg_msg_all_fighters(); has it no longer match the definition, which gained a non-defaulted SmallCraftFlavor parameter (has a link error at the call on line 500). Separately, line 128's Msg_instance == MESSAGE_ALL_FIGHTERS || Squad_msg_mode == SM_MODE_ALL_FIGHTERS silently changed meaning: those now denote fighters-only, so voice recognition no longer recognizes the fighters+bombers mode. I reckon both need MESSAGE_ALL_FIGHTERS_BOMBERS / SM_MODE_ALL_FIGHTERS_BOMBERS added.

3. Mixed wings are classified by the leader alone (see around hudsquadmsg.cpp:1074)

hud_squadmsg_send_to_all_fighters() tests wings via Wings[i].special_ship_ship_info_index, and the loose-ship loop below skips anything with wingnum != -1. So for a fighter/bomber mixed wing:

"All Bombers" on a fighter-led wing = the wing's bombers get nothing, and they're unreachable by the second loop too.
"All Fighters" on a fighter-led wing = the wing's bombers get the order anyway.

This was harmless when the only flavor was fighters-or-bombers, though now with the split it gets tricky. As an added complication, the greying-out check in hud_squadmsg_ship_command() (line 2178) iterates ships individually, so the menu enables an order based on per-ship class while the send filters by wing leader. Note sure the best way to handle this. It might be that just keeping the wingleader as what the wing is useful, but that of course does not work for mixed wings (such as those with 2 bomber and 2 fighters).

4. Order history can't distinguish the three flavors (see around hudsquadmsg.cpp:1086, 1124)

All three flavors call hud_add_issued_order("All Fighters", command), which maps to at line 2613. A mission using the query-orders SEXP will see an "all bombers" order as satisfying , and can't detect the new flavors at all.

[wookieejedi]

The old dispatch code compared k (index), which was correct; this PR switches to comparing instance, which Lua items leave at 0. As such, Lua category items are pushed with instance = 0, which is now CommOrderType::MSG_SHIPS. Dispatch at line 1861 tests MsgItems[k].instance == CommOrderType::MSG_SHIPS first, so selecting any Lua category opens the ship-select menu instead of SM_MODE_GENERAL: the k >= Comm_order_types.size() branch at 1877 is unreachable. Same problem in the switch at 1805: Lua items get active = hud_squadmsg_count_ships(0).

I think the best way to fix this would be to give them a sentinel instance (MAX_COMM_ORDER_TYPES, or a dedicated LUA_GENERAL value) and run the logic on that.