Server Authoritative Loot Functionality and Additions. - #4
Conversation
These items should facilitate Server-Authoritative functionality in GC2 Arawn Extensions. Tested and utilized in PurrNet with Edgegap. Primary changes are 1) NetworkWorldObject - Facilitates server control of the existence of an item that can be interacted with. 2) NetworkLootContainer - “This object is allowed to generate loot, using this server-side loot table.” 3) InstructionNetworkPickupRequest - Submits server request to pick up an item and move it to a GC2 Inventory Bag 4) InstructionNetworkLootRequest - “Player interacted with this lootable object, ask the server to generate loot.” This is my first pull request to a real repo. Feedback appreciated. Much of what I accomplish is via GPT.
…-Auth-Patch Server-Authoritative contributions.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d0905cfe46
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| using System.Threading.Tasks; | ||
| using UnityEngine; | ||
| using GameCreator.Runtime.Common; | ||
| using GameCreator.Runtime.Inventory; |
There was a problem hiding this comment.
Place the new sources in the Inventory assembly
When GC2_INVENTORY is enabled by Editor/DefineSymbols/GC2NetworkingDefineSymbols.cs, these root-level scripts compile into Arawn.GameCreator2.Networking.asmdef, which does not reference GameCreator.Runtime.Inventory; this using therefore fails compilation, and the files also redeclare types already present in the Inventory assembly. These changes need to be merged into the existing Inventory/ sources rather than added beside the root asmdef.
Useful? React with 👍 / 👎.
| public void SendLootRequest(NetworkLootRequest request) | ||
| { | ||
| Debug.Log( | ||
| $"[NetworkInventoryLootDebug][Manager] send loot request req={request.RequestId} actor={request.ActorNetworkId} container={request.ContainerBagNetworkId}"); | ||
| OnSendLootRequest?.Invoke(request); |
There was a problem hiding this comment.
Wire loot requests into the transport
For a non-host client, RequestLootGeneration reaches this event and stops: the inspected PurrNet bridge bind/unbind sections and packet handlers wire pickup, transfer, and the other inventory operations, but contain no OnSendLootRequest, OnSendLootResponse, or loot packet handling. Consequently the server never receives a remote client's loot request and the new instruction only works on the server/host path.
Useful? React with 👍 / 👎.
| return; | ||
| } | ||
|
|
||
| if (!ValidateTargetOwnership(senderClientId, request.ActorNetworkId, request.ActorNetworkId, nameof(NetworkLootRequest))) |
There was a problem hiding this comment.
Validate access to the requested loot container
For any client that owns its actor, this validates the actor bag against itself rather than validating access to ContainerBagNetworkId; ProcessLootRequest then runs the container's loot table without any actor-to-container distance or access check. A client that knows a world-container ID can therefore remotely roll a generate-once container before reaching it, so the server must validate proximity/access to the actual container before generating loot.
Useful? React with 👍 / 👎.
| return true; | ||
| } | ||
|
|
||
| worldObject.MarkPickedUp(); |
There was a problem hiding this comment.
Replicate world-object consumption to clients
On a dedicated server this only disables or destroys the server's local scene object. The new protocol has no consumed-object broadcast, and ReceivePickupResponse merely logs the response, so requesting and observing clients retain an enabled copy of the pickup and can continue interacting with it after the authoritative object has been consumed. Broadcast the consumed state (or use the existing pickup-state replication path) so every client removes the object.
Useful? React with 👍 / 👎.
|
Hi @dragonzero39 — first of all, thank you for taking the time to build this and for opening your first public pull request. The motivation to add server-authoritative loot is absolutely appreciated, and running the GC2 Please do not be discouraged by the automated You do not need to close this PR or create another one. Any additional commits you push to the same The easiest path forward is to make this a smaller, focused server-authoritative loot contribution:
A good first revision does not need to solve every possible world-object interaction. A clean, tested loot-container addition on top of the current Inventory Authority v3 code would already be a meaningful contribution. When you have pushed the next commits, leave a short comment such as “Ready for another review” and we will take another look. If any Git/GitHub step or the folder mapping is unclear, ask here—we are happy to guide you through it. Your authorship will remain attached to the contribution when a corrected version is merged. |
Server-Authoritative contributions.
These items should facilitate Server-Authoritative functionality in GC2 Arawn Extensions. Tested and utilized in PurrNet with Edgegap.
Primary changes are
This is my first pull request to a real repo. Feedback appreciated. Much of what I accomplish is via GPT.