1.7.10: Player name tags show as MISSING

[iceiix]

// src/server/mod.rs
        let entity = entity::player::create_remote(&mut self.entities, 
self.players.get(&uuid).map_or("MISSING", |v| &v.name));

Broken in 1.7.10, works in 1.8.9+

[iceiix]

self.players on empty when accessed in on_player_spawn, expected to be populated with on_player_info but it is different for 1.7, this bug corresponds to this comment:

    fn on_player_info_string(&mut self, _player_info: packet::play::clientbound::PlayerInfo_String) {
          // TODO: support PlayerInfo_String for 1.7
      }
  
      fn on_player_info(&mut self, player_info: packet::play::clientbound::PlayerInfo) {

https://wiki.vg/index.php?title=Protocol&oldid=6003#Player_List_Item

            packet PlayerInfo_String {
                field name: String =,
                field online: bool =,
                field ping: u16 =,
            }

translates to online=false Remove, ping=UpdateLatency, but what about uuid? It is not in this packet, only the player name.

[iceiix]

Something broke? Testing on 1.7.10 with master branch 56f9c0e (56f9c0e), I only see a disembodied head, no name tag not even MISSING:

There were changes to src/render: https://github.com/iceiix/stevenarella/commits/master/src/render

Reverting back to 710a773 (Tue Nov 24 19:35:55 2020), the full model appears (with MISSING name tag, as expected due to this bug).

Testing on 0aa062f (Fri Dec 25 10:00:22 2020), which is the commit that introduced the port to glow, this disembodiment problem does reproduce. Was it introduced with #262?

Reverting to the previous commit before glow, 9700ffe (Sun Dec 20 16:21:02 2020), the player model is intact. So it does look like #262 broke it.

Maybe set_float_multi_raw() The change to this call was sketchy. Commenting it out, no model shown at all, not even the player head.

Aha, the wrong length is passed to from_raw_parts(). It should be times 4 * 4, for the matrix size. This works:

    #[allow(clippy::missing_safety_doc)]
    pub unsafe fn set_float_multi_raw(&self, data: *const f32, len: usize) {
        glow_context().uniform_4_f32_slice(Some(&self.0), std::slice::from_raw_parts(data, len * 4 * 4));

[iceiix]

Back to the original issue of the MISSING name tag, here is the problem. In 1.7.10:

• PlayerInfo_String (https://wiki.vg/index.php?title=Protocol&oldid=6003#Player_List_Item) doesn't have the UUID, only: player name string, online bool, and ping short
• SpawnPlayer_i32_HeldItem_String (https://wiki.vg/index.php?title=Protocol&oldid=6003#Spawn_Player) does have the UUID, but it looks up self.players which is keyed by uuid

post-1.7.10:

• PlayerInfo (https://wiki.vg/Protocol#Player_Info) has the UUID, so it populates self.players, by uuid
• SpawnPlayer* (https://wiki.vg/Protocol#Spawn_Player) looks up by uuid

both PlayerInfo packets are meant to "update the user list (<tab> in the client).", and both SpawnPlayers packets are for creating the client-side entity for the player when they come in range.

We keep track of players in the Server struct, field players: HashMap<protocol::UUID, PlayerInfo.... PlayerInfo is defined thusly:

pub struct PlayerInfo {
    name: String,
    uuid: protocol::UUID,
    skin_url: Option<String>,

    display_name: Option<format::Component>,
    ping: i32,
    gamemode: Gamemode,
}

Is this players list supposed to be the player entities in range, or all the players on the server?

We don't have the <tab> online player list yet, but if we did, on 1.7.10 it couldn't use: uuid, skin_url, display_name, or gamemode because these fields aren't available in the PlayerInfo_String packet. And we can't even set or get from self.players because the hash map is keyed by the uuid.

Perhaps the solution is to have a separate self.online_players list, with only player names and pings, for the tab list, and use self.players for 1) nearby players, 1.7.10, and 2) all players, >1.7.10. Post-1.7.10, populate both lists. In on_player_spawn_i32_helditem_string(), populate self.players before calling the generic on_player_spawn() handler (which calls entity::player::create_remote with PlayerInfo looked by uuid).

Thinking through other alternatives: change most of the fields of self.player PlayerInfo to be Options, and PlayerInfo_String would leave most of them None, then SpawnPlayer_i32_HeldItem_String updates them. To allow this, would have to change self.players from a HashMap to a Vec, then iterate to lookup by UUID or name: slower, but shouldn't be that much slower given the number of players.