Multiplayer savegame #7047
Labels
No Label
Closed
Duplicate
Closed
Fixed
Closed
Invalid
Closed
Needs info
Closed
Won't fix
Closed
Works for me
Difficulty
Hard
Difficulty
Medium
Difficulty
Simple
Needed for Beta
Needs Design Input
Needs Info
Pathfinding
Priority
1: Release Blocker
Priority
2: Must Have
Priority
3: Should Have
Priority
4: Nice To Have
Priority
5: If Time Permits
Regression
Theme
AI
Theme
Art & Animation
Theme
Atlas editor
Theme
Build & Packages
Theme
Core engine
Theme
Documentation
Theme
Internationalization & Localization
Theme
Maps
Theme
Multiplayer Lobby
Theme
Music & Sound FX
Theme
Network
Theme
Non-game systems
Theme
Simulation
Theme
UI & Simulation
Theme
UI β Game setup
Theme
UI β In-game
Theme
UI β Miscellaneous
Theme
Website & Forum
Type
Defect
Type
Enhancement
Type
Task
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: 0ad/0ad#7047
Loadingβ¦
Reference in New Issue
Block a user
No description provided.
Delete Branch "phosit/0ad:mp-savegame"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR allows to save and later load multiplayer games.
This PR is also usefull rebalance after a client is kicked.
We might unfreze more settings (victory condition, player color...) in future PRs.
Continuation of https://code.wildfiregames.com/D4770
Compared to the phab version it uses the filetransferer, download is done when the loading screan is shown and an issue with player names is fixed.
mp-savegameto Multiplayer savegameThis is a great one, thank you!
Some suggestions come to mind:
For future patches:
@phosit let me know if you want to test this sometime.
I'd suggest that a super awesome addition could be a periodical autosave but that should be a separate PR.
That should be easy.
Do you mean adding a checksum to the saved game (on disk) or when transfereding it to the clients? In both cases it should be done in it's own commit.
There is already a warning when one loads an incompatible game. Same for joining games via Lobby.
Do you want to protect against a host loading a game where they have an advantage?
A protection would be to send the id (as chat message) when the host saves a game. And then show the id in the gamesetup. The clients could check that it's the same.
Don't know about security risks, rejoin-gamestate already would have the same risks.
The game starts when all clients have loaded the game. One would have to edit JS to bypass that. That's hard to prevent.
The game is already sending hashes of the game state on a regular basis to check for OOS. Assuming that that has complete coverage then a corrupted save game would be detected by the OOS system.
I consider security important. I think that this PR does not add any new potential security vulnerabilities, because it basically uses the existing join-in-progress feature to resume a saved state.
I think that more checks should be done, but in a separate PR. This PR has taken a long time to get to this point and we don't want to have mission creep.
If you are able to help with writing code that does security checks then it would be greatly appreciated.
05c0bb07d1
toed8ddc8398
m_SavedState is now cleared when it's no longer in use.
I hope it builds now with the rebase
ed8ddc8398
toa101db61e8
a101db61e8
to86d360a887
Seems
SYNCHRONIZE
got replaced by the precompiler.I won't fix the clang warning, because it gets fixed in #6996.
Warning has been fixed :)
Checkout
From your project repository, check out a new branch and test the changes.