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.

Sign up for GitHub

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

Jump to bottom

BUG: First Round Problems Mega-Issue #1360

Open
EntranceJew opened this issue Feb 4, 2024 · 11 comments
Open

BUG: First Round Problems Mega-Issue #1360

EntranceJew opened this issue Feb 4, 2024 · 11 comments
Labels
type/bug Something isn't working
Milestone
Bugfix Backlog

Comments

@EntranceJew
Copy link
Contributor

There are a slew of problems that occur exclusively on the first round, uncertain as to what the problem may be.

Door Linkage

A door, during its first round, will behave as expected when paired:
https://github.com/TTT-2/TTT2/assets/5711436/b7b01244-145d-450b-a3aa-e165a2e8af6c

A door, during later rounds, will behave erratically:
https://github.com/TTT-2/TTT2/assets/5711436/b353aa1d-468b-446d-8aed-8aeb722fe788

This may never occur if a door is broken off of its hinges, due to key values not being reset on round restart. Most notably, the stack trace changes to include a concommand even if the round concludes naturally:

first round:
Trace:
    1: Line 32    "Trace"        lua/includes/extensions/debug.lua
    2: Line 305    "SetUp"        addons/ttt2/lua/ttt2/libraries/door.lua
    3: Line 891    "nil"        addons/ttt2/gamemodes/terrortown/gamemode/server/sv_main.lua
    4: C function    "CleanUpMap"
    5: Line 895    "CleanUp"        addons/ttt2/gamemodes/terrortown/gamemode/server/sv_main.lua
    6: Line 974    "nil"        addons/ttt2/gamemodes/terrortown/gamemode/server/sv_main.lua

second round:
Trace:
    1: Line 32    "Trace"        lua/includes/extensions/debug.lua
    2: Line 305    "SetUp"        addons/ttt2/lua/ttt2/libraries/door.lua
    3: Line 891    "nil"        addons/ttt2/gamemodes/terrortown/gamemode/server/sv_main.lua
    4: C function    "CleanUpMap"
    5: Line 895    "CleanUp"        addons/ttt2/gamemodes/terrortown/gamemode/server/sv_main.lua
    6: Line 974    "PrepareRound"        addons/ttt2/gamemodes/terrortown/gamemode/server/sv_main.lua
    7: Line 1415    "nil"        addons/ttt2/gamemodes/terrortown/gamemode/server/sv_main.lua
    8: Line 54    "nil"        lua/includes/modules/concommand.lua

Long Load Dragging

If a server has been running for several rounds, a client which has been through several reconnects via mapchange will begin to experience an increasingly long join time to a server, and will frequently miss the first round post-mapchange and become a spectator.
image

Partially Unknown Roles

A player which followed a server through a mapchange yet did not connect until later on, may have been assigned a role -- and the game will progress normally with a few problems:

  • The scoreboard will trickle in drawing new player ID tags, as often as the scoreboard thinks to refresh, every 3 seconds.
  • The roles of many player roles will remain unknown throughout the entire round, even if their corpse has already been identified by a detective.

A great deal of these errors are obscured by the several times SendFullStateUpdate() are run through-out a round, even just within the BeginRound() function alone. More significantly, a number of significant round information factors such as corpse detection are not sent along-side a ``SendFullStateUpdate()`.

Weapon Slot Reassignments Failing To Take

image
image
image

floor-spawned weapons will fail to receive certain properties when the game loads, but on subsequent rounds they will be just fine:
image

this does not apply to equipment purchased from the traitor shop, it has its properties set accordingly
@EntranceJew
Copy link
Contributor Author

image
example of a player not having a role when late join occured

@TimGoll TimGoll added this to the v0.14.0b milestone Feb 12, 2024
@TimGoll
Copy link
Member

TimGoll commented Feb 12, 2024

floor-spawned weapons will fail to receive certain properties when the game loads, but on subsequent rounds they will be just fine

This is because the setting is only used on creation of the entity. For the setting to take effect, the entity has to be respawned. This is no issue with weapons in the shop because they are always spawned on buy.

A solution here would be to iterate over all existing entities on the map and update their values. I'm not 100% sure if that is worth it, but that would work!

@TimGoll
Copy link
Member

TimGoll commented Feb 12, 2024 •
edited

xample of a player not having a role when late join occured

I'm not sure I'm understanding your problem. What's wrong with being a spectator here? You'll spawn in during the next round

@EntranceJew
Copy link
Contributor Author

xample of a player not having a role when late join occured

I'm not sure I'm understanding your problem. What's wrong with being a spectator here? You'll spawn in during the next round

image
what role is this player

@EntranceJew
Copy link
Contributor Author

floor-spawned weapons will fail to receive certain properties when the game loads, but on subsequent rounds they will be just fine

This is because the setting is only used on creation of the entity. For the setting to take effect, the entity has to be respawned. This is no issue with weapons in the shop because they are always spawned on buy.

A solution here would be to iterate over all existing entities on the map and update their values. I'm not 100% sure if that is worth it, but that would work!

these are weapons that are being spawned via ttt_random_weapon and therefore aren't on the map when it loads, if we're calling the random spawn function on equipment and have entspawn.SpawnRandomWeapon and WEPS.GetWeaponsForSpawnTypes then we should have the settings ready, or wait until we do

@Histalek Histalek added type/bug Something isn't working and removed keepalive labels Feb 13, 2024
@EntranceJew
Copy link
Contributor Author

EntranceJew commented Feb 17, 2024 •
edited

image

spectator not acquiring the traitor role color, presumably from a late join

@EntranceJew
Copy link
Contributor Author

image
image

also they weren't even traitor that round?

@EntranceJew
Copy link
Contributor Author

Garry.s.Mod.x64.12472.2024-02-17.22-41-14.mp4

i joined and just knew everyone's roles

@EntranceJew
Copy link
Contributor Author

except the detective who drew as innocent? or was innocent but drew as the detective? (damph)

@EntranceJew
Copy link
Contributor Author

Garry.s.Mod.x64.7576.2024-02-23.21-09-55.mp4

scoreboard took a long time to fill out with players, was kinda slack in doing so

@EntranceJew EntranceJew mentioned this issue Feb 25, 2024
Open
@Histalek Histalek modified the milestones: v0.14.0b, Bugfix Backlog Mar 30, 2024
@TimGoll TimGoll mentioned this issue May 24, 2024
Merged
@TimGoll
Copy link
Member

TimGoll commented May 24, 2024

Some issues mentioned here might be fixed with #1532. It is hard to test for me, but I saw some parts in the code that could cause these reported issues.

TimGoll added a commit that referenced this issue May 30, 2024
@TimGoll @Histalek
Gameloop: Complete Restructure (#1532)
23f119d 
This pullrequest is quite large, all over the place, but *mostly* moved
code. I try to highlight the changes.

After Gathwar asked for a level reset button (resets the round time,
rounds played, karme, score etc) I started investigating this topic. The
current gameloop is a mess at best and bug ridden at worst. There are no
major bugs, but every now and then someone complains about syncing
errors, they are probably all caused by our current game loop. I
stumbled upon many bandaid fixes and tried to remove all of them. While
doing so I reduced the amount of timers by a lot, reduced the network
trafic and made the system more robust.

For some reason every round state change (`ROUND_PREP` etc) triggered a
full reset on the client:

![image](https://github.com/TTT-2/TTT2/assets/13639408/2024ada1-0d59-41ad-a728-a22cf2cc7687)
This might seem like a sane solution, but it actually caused issues
because it clashes with `SendFullStateUpdate`. Whoever wrote that part
of code was aware of it, but chose to fix it by adding two more syncs
triggered via timers:

![image](https://github.com/TTT-2/TTT2/assets/13639408/5b9e0764-4317-414b-aa09-2de61c8e98bd)
The first sync, called in `roleselection.SelectRoles()` is almost always
overwritten while the second one comes through. Since our networking
system only syncs differences, this can cause issues with players not
knowing about their team mates.

For late joiners I added this instead:

![image](https://github.com/TTT-2/TTT2/assets/13639408/8db73f75-489b-44f9-ae7b-1bda49abd93b)
It makes sure that the client is receiving the data they need.

Speaking of late joiners. This is some syncing that was done before: 

![image](https://github.com/TTT-2/TTT2/assets/13639408/06c0e015-5208-4775-996e-51b6b97c9a03)
Note here that players are not able to receive data when in
`PlayerInitialSpawn`. Therefore the one second timer. This probably
works in 99.5% of the cases. But sometimes it fails and the client
doesn't know about roles.

I also wrapped many `GlobalXX` variables inside descriptive functions.

Moreover I tried to clean up `sv_main`. I'm not yet done. And the mess
with the replicated convars (seriously, client checks in a server file?
:D) should be cleaned up as well.

This makes the changes in #1527 redundant and will probably fix some of
the issues from #1360

Relevant existing functions still have their alias, so it doesn't break
everything:

![image](https://github.com/TTT-2/TTT2/assets/13639408/5dbd3b6c-cc6c-400d-8b4b-cd03b2bbdd2f)

---------

Co-authored-by: Histalek <16392835+Histalek@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type/bug Something isn't working
Projects
None yet
Milestone
Bugfix Backlog
Development

No branches or pull requests
3 participants
@EntranceJew @TimGoll @Histalek