DayZ: Fixing 'Same UID' Disconnects With MapLink & Expansion AI

Are you encountering a frustrating "Same UID" or forced disconnect issue when running a DayZ cluster with MapLink, UniversalAPI, and DayZ Expansion AI? You're not alone! This article dives deep into the problem, offering insights and potential solutions to get your server running smoothly again.

Understanding the Problem: A Deep Dive

The core issue revolves around a conflict arising from the interaction between MapLink, UniversalAPI, and DayZ Expansion AI on a DayZ cluster environment. Specifically, this problem manifests when a player dies, especially at the hands of Expansion AI, and attempts to respawn. This can lead to the dreaded “Same UID” error, kicking the player from the server and disrupting gameplay. Understanding the root cause is crucial for implementing effective fixes.

The Setup: Cluster Configuration

Typically, the setup involves a cluster with multiple servers, such as:

• Sakhal (custom map)
• Livonia (Enoch)

With the following relevant mods in use:

• MapLink: Facilitates seamless player transitions between servers.
• UniversalAPI: Provides a universal interface for data sharing.
• DayZ Expansion (including Expansion AI): Enhances the game with AI elements and expanded features.

MapLink is configured to share player data via UniversalAPI, which is where the complexity and potential for conflicts increase.

The Problem in Detail

The "Same UID" issue primarily occurs in these scenarios:

1. Death by Expansion AI: When a player is killed by Expansion AI and immediately attempts to respawn.
2. Normal Death and Reconnect: A player dies (e.g., from a fall or suicide), successfully respawns, disconnects, and then encounters the error upon trying to reconnect.

In both cases, the underlying problem seems to stem from how the server handles player data during the respawn process, particularly when Expansion AI is involved.

Log Analysis: Unraveling the Mystery

Analyzing the logs from AdminLog, server console, and MapLink provides valuable clues. Here's what the logs typically reveal:

• UniversalAPI Interaction: Upon reconnect, UniversalAPI returns the player's last state with critical information such as Health = 0, the last Server they were on (e.g., Sakhal), and an empty TransferPoint.
• MapLink's Role: MapLink logs show the process of requesting player data from the database using a unique GUID. It successfully loads the player data but recognizes that the player is dead (Health: 0). This triggers MapLink to initiate a fresh spawn.
• UApiOnClientNewEvent: This event fires, and MapLink correctly detects that the player is dead, leading it to spawn a new character. This event returns false, allowing the game engine to create a standard fresh respawn on the same server.
• The Disconnect Conundrum: Approximately 15 seconds later, MapLink logs an OnDisconnect event, but it identifies the player as NULL (NULL), even though it's the same freshly spawned character. This discrepancy is a key point of failure.
• AdminLog Insights: Simultaneously, the AdminLog and console show that the original connection (identified by a unique dpnid) is still in the login state machine. A second connection, with the same GUID and SteamID, attempts to join, causing the server to kick the first connection due to inactivity (“No packets from …”) and then kick the second with the “Same UID” error.

From the server's perspective, it appears as if there are two overlapping connections with the same UID during the Expansion AI death and respawn sequence when MapLink is enabled.

Key Observations

• Disabling MapLink/UniversalAPI: Disabling MapLink and UniversalAPI resolves the issue, indicating that the problem lies within their interaction with the Expansion AI death and respawn flow.
• Specific Death Scenarios: The issue doesn't occur when a player dies from a simple fall or suicide and remains in the same session. The problem is specific to deaths caused by Expansion AI or when a player disconnects after respawning from any death.

Proposed Solutions and Troubleshooting Steps

Given the complexity of the issue, several approaches can be taken to mitigate or resolve the “Same UID” disconnects.

Scripting Attempts and Their Limitations

Attempts have been made to address the problem by modifying the missionserver.c file (MapLink's modded MissionServer). This involved:

• Helper Function: Adding a function to find an existing PlayerBase by PlayerIdentity.
• UApiOnClientNewEvent Logic: When playerdata.IsAlive() == false OR playerdata.IsUnconscious() == true, the script searches for an existing PlayerBase with that identity. If found, it attempts to kill/delete it before returning false, allowing a fresh spawn without leftover instances.

However, these attempts have been unsuccessful because, during problematic respawns, no existing PlayerBase with that identity is found in the world when UApiOnClientNewEvent fires. This suggests the issue is happening at a lower level, possibly within the login/network layer (dpnid) rather than due to duplicate PlayerBase entities.

Potential Solutions

1. Review MapLink/UniversalAPI Handling of Player State:

   • Carefully examine how MapLink and UniversalAPI manage player state updates upon death and respawn, especially in the context of Expansion AI. Ensure that the IsAlive and IsUnconscious flags are being updated correctly and promptly.

2. Investigate OnDisconnect and Fresh Spawn Logic:

   • Focus on the OnDisconnect event and the “fresh spawn” cleanup process, where the log shows OnDisconnect Player: NULL (NULL) they are fresh spawn. This indicates a potential issue in identifying and properly cleaning up the player's data upon disconnection.

3. Explicitly Clear Player State:

   • Consider explicitly clearing or updating the saved player state in UniversalAPI before allowing a fresh spawn on the same server. This could prevent the transient “duplicate UID” condition by ensuring that the old player session is fully terminated before a new one is initiated.

4. Synchronization Issues:

   • There may be some sort of a synchronization issue with Expansion AI. You could try to modify the timing of when the player data is saved or cleared to see if that resolves the issue. This would require a more advanced understanding of the code.

5. Examine Expansion AI Respawn Mechanics:

   • Scrutinize how Expansion AI handles the respawn process. It's possible that Expansion AI is triggering the respawn in a way that conflicts with MapLink and UniversalAPI.

6. Database Optimization:

   • Ensure that the database used by UniversalAPI is properly optimized. Slow database queries could contribute to timing issues and exacerbate the problem.

Implementing the Solutions

To implement these solutions, you'll need to:

1. Access Server Files: Gain access to the server files, including the mission files and mod files.
2. Modify Scripts: Edit the relevant scripts (e.g., missionserver.c, MapLink scripts, UniversalAPI scripts) to implement the proposed changes.
3. Test Thoroughly: After making changes, thoroughly test the server in a controlled environment to ensure the issue is resolved and no new problems are introduced.
4. Monitor Logs: Continuously monitor the server logs to identify any recurring issues or new errors.

Conclusion: A Path to Resolution

The “Same UID” disconnect issue in DayZ clusters with MapLink, UniversalAPI, and Expansion AI is a complex problem that requires a multifaceted approach. By understanding the interactions between these components, analyzing logs, and systematically implementing potential solutions, you can work towards a stable and enjoyable gaming experience for your community. Remember to thoroughly test any changes and monitor your server for recurring issues.

For further information and community support, consider visiting the DayZ community forums to discuss the problem with other server owners and mod developers. They may have additional insights or solutions to share. You can also check out the official DayZ documentation for more information on server configuration and modding.

By carefully examining the death and respawn flows, updating player states, and addressing potential synchronization issues, you can eliminate the persistent