Conversation
Register remote players in the client's IQNet array when their AddPlayerPacket arrives, so they appear in the Tab player list. Previously only the host and local player were registered. Also filter the dedicated server's phantom host entry (slot 0, empty gamertag) from the UI, fix tick() to update entries by smallId instead of sequential index, and fix player removal to use gamertag matching since XUIDs are 0 on dedicated servers.
The tab player list and teleport menu now show the correct map marker color for each player. The icon is computed using the same hash as the map renderer (getRandomPlayerMapIcon) and stored by player name, bypassing the unreliable small-ID lookup that produced wrong colors on dedicated servers.
… on disconnect Players now appear in each other's Tab list immediately on join, regardless of render distance. Previously, players only appeared when they entered entity tracking range because AddPlayerPacket was only sent through the TrackedEntity system. On disconnect, a RemoveEntitiesPacket is broadcast to all clients so players added via the join broadcast are properly cleaned up, not just those within tracking range.
| unsigned int seed = static_cast<unsigned int>(entityId); | ||
| seed ^= static_cast<unsigned int>(playerIndex * 0x9E3779B9u); | ||
| seed ^= (seed >> 16); | ||
| seed *= 0x7FEB352Du; |
There was a problem hiding this comment.
where do these magic numbers come from? why is it done like this?
There was a problem hiding this comment.
i think these magic numbers should be documented
There was a problem hiding this comment.
It's not my code, it is currently being used upstream in y'alls MapItemSavedData.cpp:
static char getRandomPlayerMapIcon(const shared_ptr<Player>& player)
{
// use seed bit shift random
unsigned int seed = static_cast<unsigned int>(player->entityId);
seed ^= static_cast<unsigned int>(player->getPlayerIndex() * 0x9E3779B9u);
seed ^= (seed >> 16);
seed *= 0x7FEB352Du;
seed ^= (seed >> 15);
seed *= 0x846CA68Bu;
seed ^= (seed >> 16);
return PLAYER_MAP_ICON_SLOTS[seed % (sizeof(PLAYER_MAP_ICON_SLOTS) / sizeof(PLAYER_MAP_ICON_SLOTS[0]))];
}
It picks a random color for each player's map icon, but it has to be the same color everytime for the same player. So instead of actual randomness, it scramble the player's ID into a number between 0-7 (8 available colors)
There was a problem hiding this comment.
interesting, i never saw this. i just thought it was weird you were using some random seed lol. then again i havent really messed with map stuff
|
players outside of render distance do not show up in the playerlist. |
3 participants
Description
Changes
Previous Behavior
Root Cause
AddPlayerPacketarrived. Only the host and local player had IQNet entries, so the UI had no knowledge of other players.GetPlayerColour(), which searchesm_playerColours[]by small ID. On dedicated servers, the small IDs used by the player list UI (client-side IQNet slot IDs) don't match the IDs stored byUpdatePlayerInfo(server-side network IDs), so the lookup always failed and returned the default color. Additionally, the Iggy/SWF UI system (not the XUI system) controls the actual icon rendering, so the original XUI timeline code had no visible effect.Fix Implementation
handleAddPlayernow registers remote players in the client's IQNet array so they appear in the Tab player list. The dedicated server's phantom host entry (slot 0, empty gamertag) is filtered from the UI. Player removal uses gamertag matching since XUIDs are not available on dedicated server clients.getRandomPlayerMapIcon), stored by player name for reliable lookup. The player list and teleport menu UIs (UIScene_InGameInfoMenu,UIScene_TeleportMenu) read the icon viaGetPlayerMapIconByName()instead of the broken small-ID lookup. AmapIconToFrame()conversion translates map icon slots (0,1,2,3,8,9,10,11) to the Iggy/SWF frame indices (0-7) that the player list animation expects.AI Use Disclosure
Related Issues