Server-side changes for Xmas event #130
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
XmasClient sends event state to player when they enter a relevant stage (only Square for now) XmasClient tells XmasService to collect gifts Json serialization to read/write event state to/from disk Add XmasClientModifyEventState which can be used by SlopBrew game clients to modify event configuration
… members can ignore gift cooldown from debug UI
NotNite
approved these changes
Dec 19, 2023
| @@ -1,16 +1,21 @@ | |||
| | |||
| Microsoft Visual Studio Solution File, Format Version 12.00 | |||
| Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "SlopCrew.Plugin", "SlopCrew.Plugin\SlopCrew.Plugin.csproj", "{C33DD7D1-D576-42DC-849A-A67937645689}" | |||
| # Visual Studio Version 17 | |||
There was a problem hiding this comment.
All of the project GUIDs seem to have been reset in the solution - unsure what could have caused this but I don't think it'll impact anything.
|
please don't bring down prod 🙏 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@LazyDuchess @NotNite
These are the server-side code changes for the upcoming Xmas event.
Highlights
Adds
SlopCrew.Server.XmasEvent.Commonassembly which is shared with our Xmas plugin code. It contains the shared packet structures and serialization/deserialization logic.Adds
XmasClient: eachNetworkClientalso gets anXmasClientwhich handles all Xmas-specific custom packets from that player.Added
XmasServiceto update event state, broadcast it to players, and read/write it to disk.State writes to
xmas-event-state.json. I wasn't sure if logic was necessary to generate an absolute path, but I didn't see that for the database path. Should I also add explicit config to the docker-compose.yml config to put it in./docker/slop/?Due to time pressure, the
XmasServerEventStatePacketserves double-duty. It is also used to store event state and is serialized/deserialized to a.jsonfile on disk. So every time gifts are collected, we mutate the packet and re-send it to all clients.xmasClient.IsSlopBrewchecks an include-list of SlopBrew people. These people have "admin" power for the Xmas event, but not to the SlopCrew server. They can only rewrite Xmas event state w/XmasClientModifyEventStatePacketand can ignore the gift cooldown when testing.Packets have a
Describemethod used for debug logging in our plugin, not used server-side.Event State
Event state is a list of "phases." When players collect gifts, this increments the gift total for the active phase(s). Technically we could have multiple active phases, gifts would count towards all of them, this was a half-baked idea that I thought might be useful. Now I'm not sure.
When a phase reaches its gift target, it can auto-activates the next phase automatically. This is configurable in case we decide last-minute to trigger phases manually. If we disable auto-activate, the same phase will continue to accumulate gifts above and beyond it's goal.
The server-side is hardcoded to 7 phases though we will only use 4 or 5. I wanted wiggle-room for last-minute plugin changes without a SlopCrew change.
There's a cooldown on collecting gifts.
AcceptandRejectresponse packets tell the client if it's hitting the cooldown.