Authentic Handling of Mission-Related Barker Messages

[FinnHornhoover]

This PR addresses two issues with the current implementation:

• The NPC IDs sent by the client in a sP_CL2FE_REQ_BARKER object are usually fixed within chunks. Meaning, the ID of the first available "mission barker" NPC is fixed, even if the player exits and reenters the chunk. This seems to be unlike the original game, and the client logic in this issue seems to have stayed constant through all the standard builds. Ergo, there is a need to decide the "mission barker" NPC on the server side (which appears to be chosen randomly within nearby NPCs in the original game's recordings).
• All NPCs have a field called m_iBarkerType, that controls which element of the m_iHBarkerTextID array (of the mission task that is selected by the client) gets to be the barker string that is sent back to the client. NPCs without a m_iBarkerType value between 1 and 4 (inclusive) cannot output mission-related barker text. In all recordings of the original game reviewed thus far, the game seems to respect which NPC can say which lines, which is unlike the current behavior where we randomize between the 4 barker type options. Therefore, the randomization is removed in favor of the authentic behavior observed.

The revised behavior is as follows:

• Ensure the mission task sent by the client exists, and figure out its m_iHBarkerTextID array.
• Figure out the player from the socket, and traverse all entities within its viewable chunks.
• When an entitiy is found that leads to a valid barker text ID within the m_iHBarkerTextID array; it is added to a list.
• Among the entries found, a random one is selected. Using the random NPC and its valid barker text ID, a reply packet is constructed and sent, causing the client to display a mission-related random barker text bubble.
• If no entry is found, no reply packet is sent.