Reduce time needed for STUN #6953
No reviewers
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
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: 0ad/0ad#6953
Loadingβ¦
Reference in New Issue
Block a user
No description provided.
Delete Branch "Dunedan/0ad:reduce-time-for-stun"
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?
In my tests this reduced the time necessary for starting to host a game
or joining a hosted game by ~180ms.
Continuation of https://code.wildfiregames.com/D5321
5e5187f6f4
to5609ec878c
Looks alright to me. Maybe num_msg could not be abbreviated also max_tries sounds like it should be camelCase. Any way to test this on a bad network?
You can post a message on that diff, such as "Continuation over at #6953", and close the diff.
IMO
number_of_messages
would sound pretty strange.In the C++ code I assume, because in the config file Snake Case seems to be common?
I haven't tested it with bad network, but as this PR is just changing the frequency of checking for responses, without changing the overall time, I don't expect any negative impact, no matter how good or bad network connectivity is.
Maybe
message_count
Yeah I meant camelCase for C++
I updated the variable names to use camel case. As for the abbreviations, I believe they are fine as they are.
I don't really have any more objections.
Stan referenced this pull request2024-08-23 13:45:36 +02:00
1f42adee75
to8519eb9b86
Merged as
8519eb9b86
Pull request closed