(...)
Regarding comms, that tutorial is missing a vital bit of information - I guess I wrote it back when we were working on UE
. At the time, we weren't really implementing any normal pilot comms, only replacing Casey and adding special scripted dialogue lines, so we didn't encounter any issues related to random comms. What I found afterwards, when working on Standoff, was that when we added multiple comms of the same type for our new pilots, they usually didn't work (although sometimes they did... which remains a mystery). But WCP/SO does include multiple comms of the same type for many pilots, and they certainly are used in the game (play WCP, and you'll see that the generic Nephilim comms you mention do all get used). So, I investigated the issue, and what I found was that the original comm files included additional comm chunks numbered -1, which seemed to make the randomness work properly. So, for example a pilot with two death comms would include the following three chunks in the comm file:
Code:
CHUNK "MOBJ"
{
long 1
long -1
long 250
float 0.5
long 4
long 5
long 0
long 0
}
CHUNK "MOBJ"
{
long 1
long 0
long 250
float 2.0
long 4
long 5
long 0
long 0
}
CHUNK "MOBJ"
{
long 1
long 1
long 250
float 2.0
long 4
long 5
long 0
long 0
}
As you can see from above, the first chunk is a death comm (hence the number 5 in the third value from the bottom), but in the place where you would ordinarily have the line number (second value from the top), you have -1. Similarly, after the chunks quoted above, there begins a set of kill messages (40 - reporting the death of a small target), and again the first one is numbered -1, followed then by chunks numbered 2, 3, and 4.
As long as you take care of that detail, the comms should be properly drawn at random for the given pilot. However, now that I think about it, we also did eventually figure out what the meaning of the third value from the top was (the tutorial lists it as unknown), namely, priority. I think priority mainly refers to the comms queue (because WCP has so many comms being sent out, priority is used to determine where new comms get added into the queue, and presumably also to determine how long a comm should stay in the queue before being wiped, to avoid the player having to deal with too many old messages), but it may also somehow influence the random choice of comms. It may be that if you have multiple comms of the same type, but one has a higher priority than the others, then the random choice mechanism will be disrupted. In fact, given that not all comm files have that -1 thing I mentioned, it may well be that that's the real trick to randomness, and the -1 thing is just something that accidentally fixed the problem somehow
.
By the way, there is also a lot of valuable information to be found in the WCP and SO dev backup CDs that the CIC hosts (or hosted...?). In those, you can find the source for many of the IFFs, often will comments. So, for example, the comm chunks that I discuss above actually have the following info in the SO backup CD:
Code:
CHUNK MOBJ
{
long COMM_TYPE_HELMETED
long AAce7Comm_DEATH_1 // long Communication ID
long 260 // long Priority (1=lowest, 2000000=highest)
float 2.0 // float Transmission Time (in seconds -- currently meaningless)
long BROADCAST // long Category Mask (see comms.def) -- who this can be sent to
long Comm_DEATH // long Content (see comms.def)
long 0 // long Type: Used for matching object type (for Category mask)
long 0 // long Distance: Used for matching object distance (also for CM)
}
...With the above info, I still have no idea what the last two values do, and quite possibly they do nothing because I haven't seen them used. The fifth value from the top is a useful one, although somehow we got through Standoff without ever understanding it
. Here's the values it takes:
Code:
// ~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (items below this line are ORs)
// 1 = Wing Leaders
// 2 = Anyone on my current wing
// 4 = Broadcast to EVERYONE
// 8 = Targetted object
// 16 = Your wing leader (if wingman)
// ~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (items below this line are ANDs)
// 32 = Any object matching TYPE
// 64 = Any object within DISTANCE
// 128 = Any object which is friendly to sender
// --- = More to come as necessary
enum CommCategories
{
med_work_around_this_sucks, // med requires a ZERO valued first entry, regardless of what you set it to
WING_LEADERS = 1, // = BINARY3(0000,0000,0001);
CURRENT_WINGMEN = 2, // = BINARY3(0000,0000,0010);
BROADCAST = 4, // = BINARY3(0000,0000,0100);
TARGETED_OBJECT = 8, // = BINARY3(0000,0000,1000);
CURRENT_WINGLEADER = 16, // = BINARY3(0000,0001,0000);
MATCH_TYPE = 32, // = BINARY3(0000,0010,0000);
WITHIN_DISTANCE = 64, // = BINARY3(0000,0100,0000);
FRIENDLY_OBJECTS = 128, // = BINARY3(0000,1000,0000);
TARGET_WATCHER = 256
