Jump to content

Biocrystal

Member
  • Posts

    2
  • Joined

  • Last visited

Reputation

2 Neutral

Personal Information

  • Pronouns
    he/him

Recent Profile Visitors

98 profile views
  1. Hey all, Update on the player visibility issue - got it working finally! Figured I'd share what fixed it in case anyone else runs into the same problem. Turns out our MsgPlayer packet structure was way off. After digging through COPS v6's code, I realized the packet layout was completely different from what we had. The X/Y coordinates were in the wrong place, we were missing equipment slots, and the field order was all messed up. The main fix was restructuring MsgPlayer to match COPS v6 exactly: - X/Y coordinates moved from offset 24-28 (as uint32) to offset 52-54 (as UInt16) - Added equipment slots at offset 24-47 (24 bytes) - Fixed all field positions and types to match But the real game changer was adding MsgUserAttrib.SizeAdd to the visibility sequence. We were sending MsgPlayer → MsgName, but without that SizeAdd packet in between, the client gets all the data but just doesn't render the player. That was the main blocker. So the working sequence is: - MsgPlayer → MsgUserAttrib.SizeAdd → MsgName When a player logs in, we send LoginSpawn to their own client, then for other players on the same map within 18 tiles we send those three packets in that order. Also fixed direction handling - client expects directions inverted, so using (8 - direction) % 8 when sending in MsgPlayer fixed the facing direction issues. For animations, we broadcast the raw MsgWalk packet to other players (like COPS v6 does with Screen.Move). For jumps, we broadcast the original MapJump packet directly - no separate MsgPlayer for short jumps. This lets the animation play instead of just teleporting. Tried a bunch of stuff that didn't work: - Sending LoginSpawn for other players (caused coordinate swaps) - Sending MsgUserInfo for other players (character swap bug) - Different unknown field values - Various packet sequences While we were at it, also fixed the chat system to use screen distance (18 tiles) instead of broadcasting to the entire map. The key was matching COPS v6's packet structure exactly. Once we got that right, everything started working. Hope this helps if anyone else is stuck on the same thing!
  2. Hi everyone, I'm working on a Conquer Online 4343 server using the Comet emulator, and I'm having trouble getting players to see each other. Despite sending what appears to be the correct packets, players remain invisible to each other. ### Current Situation **Server:** Comet (4343 branch) **Client:** Patch 4343 **Issue:** Players cannot see each other, even when on the same map and within screen distance (18 tiles) ### What We're Sending When a player logs in, we send visibility packets in this sequence: 1. **LoginSpawn** (MsgAction, Action 74) - Position initialization - CharacterID: Player's CharacterID - Command: MapID (4343 format) - Arguments: [X, Y] coordinates (ushort array) - Direction: 0 - Timestamp: Current Unix timestamp 2. **MsgPlayer** (Packet 1014/0x03F6) - Appearance data - CharacterID: Player's CharacterID - Mesh: `(Mesh + Avatar * 10000)` (matching MsgUserInfo encoding) - X: uint32 at offset 24 - Y: uint32 at offset 28 - HP/MP: ushort at offsets 44/46 - Level: byte at offset 51 - Name: length-prefixed string 3. **MsgName** (Packet 1015/0x03F7) - Name information - CharacterID: Player's CharacterID - Name: Player's name **Packet Sequence:** - LoginSpawn → MsgPlayer → MsgName (10ms delay between each) ### Implementation Details **Visibility Logic:** - Only sends to players on the same map - Checks Chebyshev distance (max of X/Y differences) <= 18 tiles - Sends both ways: new player sees others, others see new player - Coordinates are read once and used for both LoginSpawn and MsgPlayer to ensure consistency **Code Location:** `MsgAction.cs`, `LoginSpawn` handler ### What We've Tried 1. Sending LoginSpawn + MsgPlayer (both packets) 2. Ensuring packet order: LoginSpawn first, then MsgPlayer 3. Screen distance check (18 tiles, Chebyshev distance) 4. Coordinate synchronization (same coordinates for both packets) 5. Adding MsgName proactively (client requests it) 6. Verifying packet structure against reverse-engineered code 7. Ensuring MsgUserInfo is NOT sent for other players (causes character swap bug) 8. Using 4343 format: MapID in Command field (not Direction) ### Current Symptoms 1. **Players Not Visible:** Players cannot see each other, even when standing next to each other 2. **Coordinate Swapping:** Players sometimes display at each other's coordinates (though this has improved with recent fixes) 3. **Client Requests:** Client sends MsgName requests with CharacterID 0 (internal IDs 269, 270) - we respond but it doesn't help ### Packet Hex Dumps (from server logs) **LoginSpawn for greg (CharacterID 1000006):** ``` 00 00 F2 03 BB D9 29 69 46 42 0F 00 EA 03 00 00 B5 01 79 01 00 00 4A 00 ``` - CharacterID: 0x000F4246 (1000006) - Command: 0x000003EA (1002 - MapID) - Args: [0x0179, 0x01B5] = [377, 437] **MsgPlayer for greg:** ``` 00 00 F6 03 46 42 0F 00 EC 56 07 00 00 00 00 00 00 00 00 00 00 00 00 00 B5 01 00 00 79 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5D 00 00 00 C8 02 00 01 0A 04 67 72 65 67 ``` - CharacterID: 0x000F4246 (1000006) - Mesh: 0x000756EC (481004) - X: 0x000001B5 (437) at offset 24 - Y: 0x00000179 (377) at offset 28 - Name: "greg" (length-prefixed) ### Client Behavior - Client receives packets (confirmed via Wireshark - encrypted but data is flowing) - Client sends MsgName requests after receiving visibility packets - No client errors in debug logs (no ASSERT failures) - Players simply don't appear on screen ### Questions 1. **Is the packet sequence correct?** LoginSpawn → MsgPlayer → MsgName? 2. **Are we missing a required packet?** Should we send something else? 3. **Is the timing correct?** Should there be longer delays between packets? 4. **Is the MsgPlayer structure correct for 4343?** We're using uint32 for X/Y at offsets 24/28 5. **Should MsgName be sent proactively or only in response to requests?** 6. **Are there any 4343-specific requirements we're missing?** ### Additional Context - We've verified against reverse-engineered client code (Ghidra exports) - We've checked the Conquer Online wiki - We've reviewed forum posts about visibility - Our MsgUserInfo works correctly (players see themselves) - Chat broadcasting works (players can communicate) ### What We Need Any guidance on: - Correct packet sequence for 4343 - Required fields we might be missing - Timing/delay requirements - Common pitfalls for player visibility in 4343 Thanks in advance for any help!
×
×
  • Create New...