Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs: Mention the "last received item index" paradigm in the network protocol docs #2989

Merged
merged 5 commits into from
Mar 28, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions docs/network protocol.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,9 @@ There are also a number of community-supported libraries available that implemen
| GameMaker: Studio 2.x+ | [see Discord](https://discord.com/channels/731205301247803413/1166418532519653396) | |

## Synchronizing Items
After a client connects, it will receive all previously collected items for its associated slot in a [ReceivedItems](#ReceivedItems) packet. This will include items the client may have already processed in a previous play session.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest it will receive all previously received items, instead of collected. It feels more intuitive to me, as collected seems to imply what the player actually did, so locations more than items.

Copy link
Collaborator

@agilbert1412 agilbert1412 Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I re-read this comment, I see it repeats the word "receive" twice.
Maybe It will be sent all previously received items [...] in a ReceivedItems packet?

Copy link
Member Author

@NewSoupVi NewSoupVi Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, so, the reason I went for "collected" instead of "received" here is that "received" might imply "received by the client", which is not true, it will just send everything that was found for that slot, which could include both "previously processed in the last play session" and "found while offline after the last play session" in one packet. Heck, start inventory as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe found? I'm not sure

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it's literally called a "ReceivedItems" packet, I personally still favor that word. In my mind, someone will have to understand what a received item is sooner or later anyway, so might as well rip the bandaid here.

To ensure the client is able to reject those items if it needs to, each item in the packet has an associated `index` argument. You will need to find a way to save the "last processed item index" to the player's local savegame, a local file, or something to that effect. Before connecting, you should load that "last processed item index" value and compare against it in your received items handling.

When the client receives a [ReceivedItems](#ReceivedItems) packet, if the `index` argument does not match the next index that the client expects then it is expected that the client will re-sync items with the server. This can be accomplished by sending the server a [Sync](#Sync) packet and then a [LocationChecks](#LocationChecks) packet.

Even if the client detects a desync, it can still accept the items provided in this packet to prevent gameplay interruption.
Expand Down