Feature/rb 118 system receive broadcast position relative

[Saverio976]

• Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• Norm of the code has been respected

• In what state is your pull request?

• Ready to merge / Waiting a reviwer to see my work.
• Work In Progress (WIP) / My work is not finish but i want daily reviews. (Draft)
• CI Review / I want to see what the CI thinks of my work.
• Need feedback / Just to have feedback on what i produced. (May not be merged)

• What kind of change does this PR introduce? (You can choose multiple)

• Bug fix
• Feature request
• New / Updated documentation
• Testing CI ( Make the pull request in draft mode)

• What is the current behavior? (link an issue based on the kind of change this pr introduce)

• What is the new behavior (if this is a feature change)?

• Other information:

Summary by CodeRabbit

• New Feature: Added a function to track and update the relative positions of other players, enhancing the multiplayer experience.
• New Feature: Introduced a function to send and receive new ally notifications, improving team coordination in multiplayer mode.
• Improvement: Enhanced server stability by adding exception handling in various functions, reducing the risk of unexpected crashes.
• Improvement: Optimized code by removing unused parameters and adding necessary logging statements for better debugging.
• New Feature: Added a function to check the running status of the server, providing better control over server operations.
• Refactor: Updated the structure of the msgNewAllie_s message for more efficient data handling.
• Improvement: Modified the main server loop to terminate if the server stops running, enhancing server management.

[coderabbitai]

Walkthrough

The changes primarily focus on enhancing the networking capabilities of the system. New functionalities have been added to handle relative positions and new allies in the game. Exception handling has been improved in the network processing functions, and a new function to check if the network is running has been introduced. The code has been made more robust and efficient with these changes.

Changes

File(s)	Summary
src/Client/Systems/Network/ClientNetwork.cpp src/Client/Systems/Network/ClientNetwork.hpp	Removed unused parameters from function signatures. Added new function receiveRelativePosition to handle relative positions of other players.
src/ECS/ECSCustomTypes.hpp src/ECS/Systems/Systems.cpp	Enhanced Position struct with an operator+= function. Added a new Types::PlayerAllies component to the registry.
src/Nitwork/ANitwork.cpp src/Nitwork/ANitwork.hpp src/Nitwork/INitwork.hpp	Added a new function isRunning() to check if the network is running. Improved exception handling in network processing functions.
src/Nitwork/Nitwork.h src/Nitwork/NitworkClient.hpp	Modified msgNewAllie_s struct. Introduced a new message type msgPositionRelativeBroadcast_s and added handling for it.
src/Nitwork/NitworkServer.cpp src/Nitwork/NitworkServer.hpp	Added new function sendNewAllie to send new ally packets. Modified handleInitMsg and handlePositionRelativeMsg functions.
src/main_server.cpp	Modified the while loop condition in the main function to check if the NitworkServer is running.

"In the land of code, where logic is king, 🤴
Changes were made, improvements they bring. 🚀
With allies new, and positions relative, 🎮
The game now runs, more interactive and creative. 🎉
Exception handling, robust and neat, 🛠️
Makes our code, hard to beat. 💪
So here's to the devs, their efforts we laud, 👏
For they've woven magic, with every line of code." 🧙‍♂️🎩✨

---

Tips

Chat with CodeRabbit Bot (@coderabbitai)

• Mention @coderabbitai in any review comment for bot assistance.
• Note: Review comments are made on code diffs or files, not on the PR overview.

Pause Incremental Reviews

• Insert @coderabbitai: ignore in the PR description to halt the bot's ongoing reviews. Remove the line to resume.
• Additionally, enter @coderabbitai pause to halt the bot's ongoing reviews as any issue or review comment. To
  resume reviews, enter @coderabbitai resume as any issue or review comment.

[coderabbitai]

Review Status

Actionable comments generated: 4

Details

Commits

Files that changed from the base of the PR and between 09df31e and 56cddf4.

Files selected for processing (12)

• src/Client/Systems/Network/ClientNetwork.cpp (6 hunks)
• src/Client/Systems/Network/ClientNetwork.hpp (1 hunks)
• src/ECS/ECSCustomTypes.hpp (1 hunks)
• src/ECS/Systems/Systems.cpp (1 hunks)
• src/Nitwork/ANitwork.cpp (6 hunks)
• src/Nitwork/ANitwork.hpp (1 hunks)
• src/Nitwork/INitwork.hpp (1 hunks)
• src/Nitwork/Nitwork.h (1 hunks)
• src/Nitwork/NitworkClient.hpp (1 hunks)
• src/Nitwork/NitworkServer.cpp (3 hunks)
• src/Nitwork/NitworkServer.hpp (3 hunks)
• src/main_server.cpp (1 hunks)

Files skipped from review due to trivial changes (1)

• src/Nitwork/NitworkClient.hpp

Additional comments (Suppressed): 23

src/Client/Systems/Network/ClientNetwork.hpp (1)

• 16-16: A new function receiveRelativePosition is introduced. Ensure that this function is implemented correctly and is called in the appropriate places in the codebase.

src/Nitwork/INitwork.hpp (1)

• 92-92: The addition of isRunning() function is a good practice as it allows to check the running status of the Nitwork server. Ensure that this function is implemented correctly in the derived classes and returns the accurate status.

src/Nitwork/Nitwork.h (1)

• 191-194: The player_infos_s data field has been replaced with n_id_t playerId. Ensure that all uses of this struct in the codebase have been updated to reflect this change. Also, verify that the new playerId field is being correctly populated and used where this struct is utilized.

src/ECS/ECSCustomTypes.hpp (1)

• 42-46: The operator+= overload for the Position struct is a good addition for convenience. It allows for easy addition of two Position objects. However, it's important to ensure that this operator is used correctly throughout the codebase to avoid any unintended side effects.

src/Nitwork/ANitwork.hpp (1)

• 28-31: The isRunning() function has been added. This function is likely used to check the running status of the network server. Ensure that this function is implemented correctly and returns the expected result. Also, verify that it is used appropriately throughout the codebase.

src/main_server.cpp (1)

• 62-62: The main loop now also checks if the NitworkServer is running. This is a good addition as it ensures that the server is operational before updating the systems. However, please verify that the isRunning() function in NitworkServer is thread-safe and does not introduce race conditions.

src/Nitwork/NitworkServer.hpp (3)

• 74-76: The new method sendNewAllie is introduced. Ensure that it is used correctly throughout the codebase and that the playerId, packetMsgNewAllie, and endpoint parameters are properly validated before use. Also, consider renaming the butNoOne parameter to something more descriptive to improve code readability.

• 107-116: The new message type POSITION_RELATIVE is introduced and handled by handleRelativePositionMsg. Ensure that this message type is correctly implemented and handled throughout the codebase.

• 172-181: The new message types NEW_ALLIE and POSITION_RELATIVE_BROADCAST are introduced and handled by sendData. Ensure that these message types are correctly implemented and handled throughout the codebase.

src/Nitwork/NitworkServer.cpp (3)

• 111-126: The sendNewAllie function has been added. It prepares a packet with the packetNewAllie_s structure and sends it to all clients or adds it to the send queue. The function takes a playerId, a packetNewAllie_s structure, an endpoint, and a boolean butNoOne as parameters. If butNoOne is true, the packet is sent to all clients except the one at the provided endpoint. Otherwise, the packet is added to the send queue. The function modifies the playerId field of the packetNewAllie_s structure before sending it.

• 138-159: The handleInitMsg function has been modified. It now sends a packetNewAllie_s packet to all clients when a new player is initialized. The function first adds the player's endpoint to the _endpoints vector and assigns the player an ID. It then prepares a packetNewAllie_s packet and sends it to all clients. The function also calls Systems::initPlayer to initialize the player in the Systems namespace. The function logs before and after sending the packetNewAllie_s packet and in each iteration of the loop that sends the packet to all other players.

• 181-186: The handlePositionRelativeMsg function has been modified. It now casts the msg parameter to a msgPositionRelative_s structure instead of a position_relative_s structure. The function then assigns the pos field of the msgPositionRelative_s structure to the pos variable.

src/Nitwork/ANitwork.cpp (5)

• 108-111: The isRunning function is a good addition to the ANitwork class. It allows other parts of the code to check if the network is running before performing operations that require the network.

• 215-219: The addition of exception handling in the action execution loop is a good practice. It prevents one faulty action from stopping the execution of subsequent actions.

• 226-228: The change to set _isRunning to false when an exception is caught is a good practice. It ensures that the network stops running when a fatal error occurs.

• 242-245: The addition of exception handling around the action execution is a good practice. It prevents a faulty action from stopping the execution of subsequent actions.

• 267-270: The change to set _isRunning to false when an exception is caught is a good practice. It ensures that the network stops running when a fatal error occurs.

src/Client/Systems/Network/ClientNetwork.cpp (5)

• 30-33: The function signature has been updated to include a comment indicating that the second parameter is unused. This is a good practice as it makes the code more readable and understandable.

• 46-49: The function signature has been updated to include a comment indicating that the second parameter is unused. This is a good practice as it makes the code more readable and understandable.

• 57-60: The function signature has been updated to include a comment indicating that the second parameter is unused. This is a good practice as it makes the code more readable and understandable.

• 66-69: The function signature has been updated to include a comment indicating that the second parameter is unused. This is a good practice as it makes the code more readable and understandable.

• 90-109: The function receiveRelativePosition has been updated to handle the new message type msgPositionRelativeBroadcast_s. The logic seems to be correct, but it's important to ensure that the new message type is handled correctly in all parts of the codebase where it's used.

src/ECS/Systems/Systems.cpp (1)

• 434-438: The new hunk introduces a Types::PlayerAllies component for otherPlayer. Ensure that this component is properly used and updated in the rest of the codebase. Also, verify that the allie object is correctly initialized before being inserted into the registry.

[coderabbitai]

Review Status

Actionable comments generated: 7

Details

Commits

Files that changed from the base of the PR and between 09df31e and 56cddf4.

Files selected for processing (12)

• src/Client/Systems/Network/ClientNetwork.cpp (6 hunks)
• src/Client/Systems/Network/ClientNetwork.hpp (1 hunks)
• src/ECS/ECSCustomTypes.hpp (1 hunks)
• src/ECS/Systems/Systems.cpp (1 hunks)
• src/Nitwork/ANitwork.cpp (6 hunks)
• src/Nitwork/ANitwork.hpp (1 hunks)
• src/Nitwork/INitwork.hpp (1 hunks)
• src/Nitwork/Nitwork.h (1 hunks)
• src/Nitwork/NitworkClient.hpp (1 hunks)
• src/Nitwork/NitworkServer.cpp (3 hunks)
• src/Nitwork/NitworkServer.hpp (3 hunks)
• src/main_server.cpp (1 hunks)

Files skipped from review due to trivial changes (1)

• src/Nitwork/NitworkClient.hpp

Additional comments (Suppressed): 16

src/Client/Systems/Network/ClientNetwork.hpp (1)

• 16-16: A new function receiveRelativePosition has been added. Ensure that this function is implemented correctly in the corresponding .cpp file and that it is used appropriately throughout the codebase. Also, verify that the function is handling the received data correctly and safely.

src/Nitwork/INitwork.hpp (1)

• 92-92: The addition of isRunning() function is a good practice as it allows to check the running status of the Nitwork server. Ensure that this function is implemented correctly in the derived classes and returns the accurate status.

src/main_server.cpp (1)

• 62-62: The main loop condition has been updated to also check if the NitworkServer is running. This is a good practice as it ensures that the server is operational before executing the loop's logic. However, ensure that the isRunning() function in NitworkServer is thread-safe and does not introduce race conditions.

src/ECS/ECSCustomTypes.hpp (1)

• 42-46: The addition of the operator+= function to the Position struct is a good practice as it simplifies the process of adding two Position objects together. However, it's important to ensure that this operator is used correctly throughout the codebase to avoid any unintended side effects.

Position &operator+=(const Position &pos) {
    x += pos.x;
    y += pos.y;
    return (*this);
}

src/Nitwork/Nitwork.h (1)

• 191-194: The msgNewAllie_s struct has been modified to replace player_infos_s data with n_id_t playerId. Ensure that all instances where this struct is used have been updated to reflect this change. This includes both the creation and usage of this struct. Also, verify that the playerId provides enough information for the use cases where player_infos_s data was previously used.

src/Nitwork/ANitwork.hpp (1)

• 28-31: The isRunning() function has been added. This function is likely used to check the running status of the network server. Ensure that this function is implemented correctly and returns the expected result. Also, verify that it is used appropriately throughout the codebase.

src/ECS/Systems/Systems.cpp (1)

• 434-438: The new hunk introduces a PlayerAllies component that is added to the registry when otherPlayer is true. Ensure that this new component is properly handled in the rest of the codebase, especially in systems that interact with player entities. Also, consider initializing PlayerAllies with some data if necessary.

src/Nitwork/NitworkServer.hpp (3)

• 74-76: The new method sendNewAllie has been added. Ensure that this method is used correctly throughout the codebase. Also, the butNoOne parameter name is not clear. Consider renaming it to improve code readability.

• 107-116: A new message type POSITION_RELATIVE has been added to the message handling map. Ensure that the handleRelativePositionMsg function correctly handles this new message type.

• 168-181: Two new message types NEW_ALLIE and POSITION_RELATIVE_BROADCAST have been added to the message sending map. Ensure that the sendData function correctly sends these new message types.

src/Nitwork/NitworkServer.cpp (3)

• 111-126: The sendNewAllie function has been added to send a new ally packet to all clients or all clients except one. The function takes a playerId, a packetNewAllie_s struct, an endpoint, and a butNoOne boolean. If butNoOne is true, the function sends the packet to all clients except the one at the specified endpoint. Otherwise, it sends the packet to all clients. The function uses the sendToAllClientsButNotOne and addPacketToSend methods to send the packets. This function seems to be well implemented and follows the existing code structure and style. However, it would be beneficial to verify that the sendToAllClientsButNotOne and addPacketToSend methods are correctly implemented and handle all edge cases.

• 138-159: The handleInitMsg function has been updated to handle the initialization of a new player. The function now creates a packetNewAllie_s struct and sends it to all clients using the sendNewAllie function. It also initializes the player using the Systems::initPlayer method. The function then loops through all the players and sends a new ally packet to each one. This function seems to be well implemented and follows the existing code structure and style. However, it would be beneficial to verify that the Systems::initPlayer method is correctly implemented and handles all edge cases. Also, ensure that the loop correctly sends a new ally packet to each player and handles any exceptions that may occur.

• 181-188: The handlePositionRelativeMsg function has been updated to handle a relative position message. The function now extracts the position from the message data using std::any_cast. This is a change from the previous implementation, which directly cast the message to a position_relative_s struct. This change seems to be an improvement, as it makes the code more robust and less prone to errors. However, it would be beneficial to verify that the std::any_cast function is correctly implemented and handles all edge cases.

src/Client/Systems/Network/ClientNetwork.cpp (1)

• 90-109: The new function receiveRelativePosition is introduced to handle received position updates. It seems to be correctly implemented with proper error handling and thread safety. However, it's important to ensure that the msgPositionRelativeBroadcast_s message type is correctly handled in all relevant parts of the codebase.

src/Nitwork/ANitwork.cpp (2)

• 108-111: The isRunning function is a good addition to the ANitwork class. It allows other parts of the code to check if the network is running before performing network-related operations, which can help prevent errors.

• 238-245: The addition of exception handling when executing actions in the output thread is a good practice. It prevents the entire thread from crashing when an exception is thrown during the execution of an action.

[coderabbitai]

Review Status

Actionable comments generated: 4

Details

Commits

Files that changed from the base of the PR and between 56cddf4 and bb063d1.

Files selected for processing (6)

• src/Client/Systems/Network/ClientNetwork.cpp (6 hunks)
• src/ECS/ECSCustomTypes.hpp (1 hunks)
• src/Nitwork/ANitwork.cpp (6 hunks)
• src/Nitwork/ANitwork.hpp (1 hunks)
• src/Nitwork/NitworkServer.cpp (3 hunks)
• src/Nitwork/NitworkServer.hpp (3 hunks)

Additional comments (Suppressed): 15

src/Nitwork/ANitwork.hpp (1)

• 28-31: The isRunning function has been added to check if the network server is running. Ensure that this function is used appropriately throughout the codebase to check the server status before performing operations that require the server to be running.

src/ECS/ECSCustomTypes.hpp (1)

• 42-47: The addition of the operator+= function to the Position struct is a good practice as it simplifies the process of adding two Position objects together. However, it's important to ensure that this operator is used correctly throughout the codebase to avoid any unintended side effects.

Position &operator+=(const Position &pos)
{
    x += pos.x;
    y += pos.y;
    return (*this);
}

src/Nitwork/NitworkServer.hpp (3)

• 76-80: The sendNewAllie function has been added. Ensure that it is being used correctly throughout the codebase. Also, the butNoOne parameter is not clear from the context. Consider renaming it or adding a comment to explain its purpose.

• 111-120: The handling of POSITION_RELATIVE messages has been added. Ensure that the handleRelativePositionMsg function correctly processes the relative position messages.

• 172-182: The handling of NEW_ALLIE and POSITION_RELATIVE_BROADCAST messages has been added. Ensure that these new message types are correctly processed and sent.

src/Nitwork/ANitwork.cpp (6)

• 108-111: The isRunning function is a good addition for checking the running status of the network. It enhances the modularity and readability of the code.

• 115-115: Ensure that the startReceiveHandler function is not called when the network is not running. This could lead to unexpected behavior or errors.

• 215-219: Good addition of exception handling within the action execution loop. This prevents one faulty action from stopping the entire network.

• 224-228: The addition of setting _isRunning to false when an exception is caught is a good practice. It ensures that the network stops running when a critical error occurs.

• 242-245: Good addition of exception handling for action execution. This prevents a faulty action from stopping the entire output loop.

• 267-271: The addition of setting _isRunning to false when an exception is caught is a good practice. It ensures that the network stops running when a critical error occurs.

src/Client/Systems/Network/ClientNetwork.cpp (1)

• 91-109: The new function receiveRelativePosition updates the position of other players based on received messages. It's good to see that you're using a lock to ensure thread safety when accessing the shared Registry object. However, it's important to verify that the operator+= function for the Position struct handles edge cases correctly, such as overflow or underflow.

src/Nitwork/NitworkServer.cpp (3)

• 111-130: The sendNewAllie function has been added to send new ally packets to clients. It takes a playerId, a packetNewAllie_s struct, an endpoint, and a boolean butNoOne. The function sets the playerId in the packet, creates a new Packet object with the packet data, and sends it to all clients except one if butNoOne is true, or adds it to the send queue otherwise. This function seems to be well implemented and follows the existing code structure and style. However, the butNoOne parameter name is not very descriptive and could be improved for better readability.

-    void NitworkServer::sendNewAllie(
-        n_id_t playerId,
-        struct packetNewAllie_s packetMsgNewAllie,
-        boost::asio::ip::udp::endpoint &endpoint,
-        bool butNoOne)
+    void NitworkServer::sendNewAllie(
+        n_id_t playerId,
+        struct packetNewAllie_s packetMsgNewAllie,
+        boost::asio::ip::udp::endpoint &endpoint,
+        bool excludeEndpoint)

• 142-163: The handleInitMsg function has been updated to use the new sendNewAllie function. It creates a new packetNewAllie_s struct, initializes a new player with the initPlayer function, and sends a new ally packet to all other clients. The function then loops through all player IDs and sends a new ally packet to each one, excluding the current player. This function seems to be well implemented and follows the existing code structure and style.

• 185-192: The handlePositionRelativeMsg function has been updated to extract position data from messages. It casts the message to a msgPositionRelative_s struct and extracts the position data. It then creates a new packetPositionRelativeBroadcast_s struct with the position data. This function seems to be well implemented and follows the existing code structure and style.

[coderabbitai]

Review Status

Actionable comments generated: 1

Details

Commits

Files that changed from the base of the PR and between bb063d1 and 240b31e.

Files selected for processing (3)

• src/Client/Systems/Network/ClientNetwork.cpp (6 hunks)
• src/Nitwork/ANitwork.cpp (6 hunks)
• src/Nitwork/NitworkServer.cpp (3 hunks)

Additional comments (Suppressed): 11

src/Client/Systems/Network/ClientNetwork.cpp (3)

• 81-88: The function receiveNewAllie has been updated to log the creation of a new ally and initialize the player. Ensure that the initPlayer function can handle the new parameters and that the logging does not introduce performance issues.

• 90-109: A new function receiveRelativePosition has been added. This function updates the position of other players based on received messages. It uses a mutex lock to ensure thread safety. However, consider using a more granular locking mechanism if possible to reduce contention.

• 137-143: The sendPositionRelative function has been updated to include logging. Ensure that the logging does not introduce performance issues, especially since this function might be called frequently.

src/Nitwork/ANitwork.cpp (5)

• 108-111: The isRunning function is a good addition for checking the running status of the network. It improves the modularity of the code.

• 126-130: The callReceiveHandler function now starts the receive handler without logging an error message. Ensure that this change does not affect the debugging process or the understanding of the system's behavior.

• 237-244: The addition of exception handling when executing an action in the output processing is a good practice. It prevents the entire output processing from stopping if an exception occurs in one action.

• 264-270: The addition of unlocking the _outputQueueMutex before setting _isRunning to false and logging the error is a good practice. It prevents potential deadlocks if an exception is thrown.

• 334-339: The log level for adding a packet to send has been changed from info to trace. Ensure that this change aligns with the logging strategy and that important information is not lost in production logs.

src/Nitwork/NitworkServer.cpp (3)

• 111-130: The sendNewAllie function has been added. It prepares a packet with the new ally's information and sends it to all clients or all clients except one. The function uses the sendToAllClientsButNotOne and addPacketToSend methods for sending packets. Ensure that these methods are thread-safe if they can be accessed from multiple threads simultaneously. Also, consider renaming the butNoOne parameter to something more descriptive, like excludeEndpoint, for better readability.

• 142-160: The handleInitMsg function has been updated. It now sends a new ally packet to all other clients when a new client connects. The function uses the sendNewAllie method for sending new ally packets. Ensure that the sendNewAllie method is thread-safe if it can be accessed from multiple threads simultaneously. Also, consider adding error handling for the Systems::initPlayer call.

• 185-187: The msgPositionRelative_s struct is now used instead of the position_relative_s struct. Ensure that all references to the position_relative_s struct have been updated accordingly.

[coderabbitai]

Review Status

Actionable comments generated: 0

Details

Commits

Files that changed from the base of the PR and between 240b31e and 53a556e.

Files selected for processing (3)

• src/Client/Systems/Network/ClientNetwork.cpp (6 hunks)
• src/ECS/ECSCustomTypes.hpp (1 hunks)
• src/ECS/Systems/Systems.cpp (1 hunks)

Additional comments (Suppressed): 9

src/ECS/ECSCustomTypes.hpp (1)

• 42-47: The addition of the operator+= function to the Position struct is a good enhancement. It allows for easy addition of two Position objects. However, it's important to ensure that this operator is used correctly throughout the codebase. Misuse could lead to unexpected behavior or bugs.

src/Client/Systems/Network/ClientNetwork.cpp (7)

• 30-33: The function signature has been updated to include a comment for the unused parameter. This is a good practice as it makes the code more readable and understandable.

• 46-49: The function signature has been updated to include a comment for the unused parameter. This is a good practice as it makes the code more readable and understandable.

• 57-60: The function signature has been updated to include a comment for the unused parameter. This is a good practice as it makes the code more readable and understandable.

• 66-69: The function signature has been updated to include a comment for the unused parameter. This is a good practice as it makes the code more readable and understandable.

• 81-88: The function signature has been updated to include a comment for the unused parameter. This is a good practice as it makes the code more readable and understandable. Also, a log message has been added to indicate the creation of a new ally, which can be useful for debugging.

• 90-109: The new function receiveRelativePosition is introduced to handle the reception of relative position messages and update the position of other players accordingly. It uses a mutex lock to ensure thread safety when accessing the shared Registry object. The function also includes error handling to return early if the player is not found in the registry. This is a good practice as it prevents potential runtime errors.

• 137-143: A log message has been added to trace the relative position being sent. This can be useful for debugging. The rest of the code remains unchanged.

src/ECS/Systems/Systems.cpp (1)

• 444-448: The new hunk introduces a PlayerAllies component for otherPlayer. Ensure that this component is properly handled in the rest of the codebase, and that its introduction doesn't break existing functionality. Also, the allie object is created but not initialized with any data. If this is intentional, consider adding a comment to clarify.

         if (otherPlayer) {
             Types::OtherPlayer otherPlayerComp(constId);
             Registry::getInstance().getComponents<Types::OtherPlayer>().insertBack(otherPlayerComp);
            Types::PlayerAllies allie;
+               // Initialize allie with necessary data here, if needed
            Registry::getInstance().getComponents<Types::PlayerAllies>().insertBack(allie);
         } else {
             Types::Player playerComp = {constId};
             Registry::getInstance().getComponents<Types::Player>().insertBack(playerComp);

[coderabbitai]

Review Status

Actionable comments generated: 0

Details

Commits

Files that changed from the base of the PR and between 53a556e and 77cd037.

Files selected for processing (1)

• src/Client/Systems/Network/ClientNetwork.cpp (6 hunks)

Additional comments (Suppressed): 3

src/Client/Systems/Network/ClientNetwork.cpp (3)

• 81-88: The receiveNewAllie function has been modified to log the creation of a new ally and call the initPlayer function with a different argument. Ensure that this change does not affect other parts of the code that rely on the original behavior of this function. Also, verify that the initPlayer function can handle the new argument correctly.

• 90-111: A new function receiveRelativePosition has been added. This function updates the position of other players based on received messages. It uses a mutex to ensure thread safety when accessing the shared Registry instance. The function appears to be well-structured and follows good practices for thread safety and exception handling. However, it's important to ensure that the msgPositionRelativeBroadcast_s message type is correctly handled in all relevant parts of the code.

• 139-146: The sendPositionRelative function has been modified to include a logging statement. This change seems to be for debugging purposes and should not affect the functionality of the function. However, ensure that the logging level is appropriate for the frequency of these messages and that it won't flood the logs in a production environment.