Skip to content

Comments

Update README.md#4

Open
Muz-dev wants to merge 52 commits intoIstador:json-apifrom
Muz-dev:json-api
Open

Update README.md#4
Muz-dev wants to merge 52 commits intoIstador:json-apifrom
Muz-dev:json-api

Conversation

@Muz-dev
Copy link

@Muz-dev Muz-dev commented Dec 26, 2024

Typo

TheUbMunster and others added 30 commits December 21, 2022 17:42
By not detecting new saves correctly before, players were sent all moons while still being in cap kingdom.
Having those moons made the game crash if the cutscenes from cap to cascade were skipped.

Changes:
- Rename: `speedrun => `disableShineSync`.
- Correctly detect new saves by scenario 1 instead of 0.
- Let all stages that are not cap in scenario 1 enable shine sync again (e.g. for switching back to an older save).
- Only disable shine sync once and not on every stage change (e.g. when entering cap overworld again and again).
- Disable shine bag clearing by default, option to enable it again via `Shines/ClearOnNewSaves` (for speedruns).
- Persist shines after clearing (otherwise a server crash/restart might load old moons from a previous run and sync them).
- Clear only once per player till reaching cascade (otherwise collected moons might be cleared mid-run).
- Reduce delay from 15s to 2s (even w/o a delay I couldn't reproduce a crash, but keeping it feels safer).
- Only enable shine sync again after the delay, the delay was circumvented before by other tasks triggering shine sync earlier.
Because the tag packet received from the client could have an UpdateType that isn't both State and Time.
(Though currently the client always updates both together.)
To exclude specific shines to be synced to other clients.

Pre-initialized with shine 496 (Moon Shards in the Sand) that causes people to get stuck in front of the inverted pyramid.

This commit fixes issue Sanae6#31
Conflicts:
	Server/Settings.cs

Resolution:
Accept both, Excluded before ClearOnNewSaves.
Conflicts:
	Server/Client.cs
	Server/Server.cs
	Server/Settings.cs
Istador and others added 22 commits May 4, 2024 14:32
Seconds are only one byte big and not two, so the Minutes start at byte 3 and not 4.
Broadcast() with a sender never sends the packet to the sender.
Therefore only other players got informed about the new role.
But never the actual player that is supposed to change to that role.
WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 4)
WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 37)
WARN: FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" (line 4)
Freeze-Tag uses the same `UpdateType` flags for some of its `TagPacket`s as H&S and Sardines do.
But Freeze-Tag has another packet data structure that isn't matching IsIt, Seconds and Minutes.
Therefore the server wrongly interprets Freeze-Tag packets and updates its "seeking" and "time" metadata wrongly.
(These metadata fields are used to resend the `TagPacket` to later joining clients.)

This commit does the following changes:
- add: game mode detection in the first 4 bit of the `TagPacket.UpdateType`
- change: parse the `TagPacket` for the metadata iff it is clearly for H&S or Sardines
- change: only resend `TagPacket` to new clients for H&S or Sardines
Conflicts:
	Server/Program.cs
	Shared/Packet/Packets/TagPacket.cs
disable the discord table by default

Co-authored-by: Robin C. Ladiges <Istador@users.noreply.github.com>
remove redundant warnings messages

Co-authored-by: Robin C. Ladiges <Istador@users.noreply.github.com>
allow one repetition within 20 seconds.

b/c of rate limits imposed by the new API
@Istador Istador force-pushed the json-api branch 2 times, most recently from 8aee4b4 to 2cde356 Compare February 10, 2025 08:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants