userDaniel Pcancel

2,178 Commits over 549 Days - 0.17cph!

9 Minutes Ago
Tests: OcclusionGroupTests - update expectations of all tests around newLogic and Asleep players This is currently catching a bug, so will need to fix later, after I sort the oldLogic failures next Tests: ran all unit tests, 22/226 failing
44 Minutes Ago
Bugfix: OcclusionGroupTests - hookup serverMgr to Network.Server - clarified expectatios for TestVisibilityNear, will need to do more of it for sleepers They were unlinked, sso player's weren't fully transitioning to the sleeper state (no subscriber, no connection), letting more tests pass than expected Tests: ran unit tests, 23/226 fails, old logic started to fail as well
1 Hour Ago
Tests: OcclusionGroupTests - Asleep players are now disconnected-asleep (no subscriber, no connection) Tests: ran unit tests, this fails 11/226 cases, all on new logic side
2 Hours Ago
Tests: OcclusionGroupTests - new TestVisibilityAfterMovingToOutside (32) All simple cases covered, except for using actual sleepers. Next change will likely break a bunch of tests Tests: ran unit tests
Today
Tests: OcclusionGroupTests - add TestVisibilityAfterMovingToFarRange (32) - added a couple TODOs Tests: ran new unit tests, all's gud
Today
Tests: OcclusionGroupTests - add move to near range visibility test (32) Tests: ran new tests, all pass
Today
Tests: OcclusionGroupTests - add test validating moving from outside net range to same cell (32 tests) Need to add 2 more variations (move to near and far range), then can start moving to esoteric scenarios Tests: ran new tests, all pass
Today
Bugfix: OcclusionGroupTests - fixup invalid expectation of newlogic groups in TestVisibilityAfterMovementAway We succesfully enforce newlogic's rule that networkable should always be in a local occlusion group Tests: ran all unit tests, all green
Today
Bugfix: OcclusionGroup - prevent unsubbing from own group Can happen when player is dead/in limbo Tests: ran unit tests, fixed TestUpdateSubs(newLogic, dead), but TestVisibilityAfterMovementAway(newLogic, dead, *) still fail, albeit for new reason
Today
Tests: OcclusionGroupTests - add simple tests verifying group and sub updates Need them to validate that new logic can unsub from group it's in (which is illegal) Tests: ran new 24 tests, TestUpdateSubs(true, dead) failed as expected
Today
Bugfix: OcclusionGroupTests - fix TestVisibilityAfterMovementAway(oldLogic, Dead) tests Updating subs when in limbo unsubs you from limbo group (funky, but legal). Old logic ends up with empty groups (okay for it), but new logic ends up with an invalid occl group Tests: ran unit tests, 4 failures left
Today
Bugfix: OcclusionGroupTests - fix TestVisibilityAfterMovementAway(*, OutsideCell) tests - Handle the fact that new occlusion group logic eagerly cleans up occlusion groups when moving out of range, even before subscription tick - Fix invalid assertion for old logic when p2 moves, before subscription tick Tests: ran tests, now 8 failing (all related to Dead players)
Today
Tests: OcclusionGroupTests - add TestVisibilityAfterMovementAway tests (32) Tests: ran new unit tests, 14 fail
Today
Tests: OcclusionGroupTests - Visibility tests now update network groups and update subscriptions This validates that subscription mechanism works on a basic level Tests: all 42 unit tests pass
Today
Bugfix: OcclusionGroupTests - use AreEquivalent instead of AreEqual when comparing occlusion groups Old logic and new logic end up with differently ordered occlusion groups - but in real world we don't care about order Tests: all 42 unit tests pass
Today
Bugfix: Eagerly initialize occlusion groups when player spawns When player's network group switches on spawn, it's treated as a bot, so doesn't create an occlusion group, but it might be awhile till next group switch, so player might have uninitialized occlusion group for a bit. Tests: unit tests - 42/45 pass
Today
Bugfix: OcclusionGroupTests - handle dead players in limbo All TestVisibility* tests pass for old logic Tests: ran unit tests
Today
Bugfix: OcclusionGroupTests - use RespawnAt to be put in the right position for RespawnFromDead players This makes 3 unit tests pass Tests: ran unit tests
Today
Bugfix: PlayerInventory - make GiveDefaultItems safe, report errors instead of NREing - GameManager.InUnitTest is now available outside of UNITY_EDITOR as always-false const Tests: more unit tests related to RespawnFromDead pass
Today
Update: OcclusionGroupTests - introduce another player spawn state, RespawnFromDead - setup default itemList for ItemManager when running unit tests, as it's assumed to always be there Another assumption that I had proved wrong - when players are spawned, they can stay dead (for example, game mode can prohibit spawning for a time) Tests: ran unit tests, more borkage
Yesterday
Bugfix: OcclusionGroupTests - setup valid world bounds for unit tests - added netgroup visibility precondition testing, if that fails, then the test setup is wrong Empty bounds were causing group layers to sometimes become TutorialIsland, which break visibility Tests: ran unit tests, more pass
Yesterday
Bugfix: OcclusionGroupTests - correct expectations of visibility Tests: ran unit tests, more pass, but still mostly borked
Yesterday
Tests: OcclusionGroupTests - add players that spawn as sleepers or dead I assumed newly connected players always spawn as sleepers, but that's wrong - could explain an active NRE. Tests: ran unit tests (most still borked)
Yesterday
Tests: add basic OcclusionGroup tests - covers both old and new logic Tests: ran unit tests, most fail, only trivial passes. Will resolve tomorrow.
2 Days Ago
Merge: from useplayertasks_removegroupocludee_nre - Update: hide new server occlusion group logic behind -enable-new-server-occlusion-groups command line arg (disabled by default) Tests: 2p on Craggy - moved, teleported, reconnected, checked server occlusion still works
2 Days Ago
Update: merge old OcclusionGroup code and put it behind DisableNewOcclusionGroups switch - make DisableNewOcclusionGroups true by default, can be turned off with -enable-new-server-occlusion-groups command line arg Tests: 2p on Craggy - moved, teleported, reconnected, checked server occlusion still works
2 Days Ago
Update: declare a boot time switch to disable new server occlusion groups Need to bring back old logic for it, that'll be next. Tests: none, trivial change
2 Days Ago
Merge: from main
2 Days Ago
Merge: from useplayertasks_removegroupocludee_nre - Bugfix: a series of bugfixes and extra error logs to ensure occlusion groups are valid and consistent Tests: 2p on Craggy - ran around host, flew away and back, teleported away and back, tested sleepers, disconnects, and general occlusion
2 Days Ago
Merge: from main
2 Days Ago
Clean: move OcclusionValidateGroups servervar to ServerOcclusion - codegen Tests: server compiles
2 Days Ago
Clean: GetOccludees => OcclusionGroup getter Tests: server compiles
3 Days Ago
Clean: OcclusionGroups - define bespoke ServerOcclusion.Group - updated code references Tests: all modes compile in editor
3 Days Ago
Clean: OcclusionGroup - lower core of logic from BasePlayer to BaseNetworkable - also move cached subscribers cleanup to BasePlayer.OnServerDestroy - split off server occlusion logic into it's own BaseNetworkable potion Tests: all platforms compile in editor
3 Days Ago
Bugfix: ServerOcclusion - clean up external references when BaseNetworkable is destoyed Dobbie's free, this is the last bug I could theorycraft. There's a small window before occlusion would update and unsubscribe where a teleport then destroy could leave a dangling set of references, but this doesn't happen because of unnecessary SetParent being called when BaseEntity is destroyed on the server(but this should be fixed separately) Tests: not testable
3 Days Ago
Update: OcclusionGroup - tracked down another false-positive error - left a comment explaining why check was removed Whena player reconnects and reclaims a sleeper with a player in proximity, the eventual network group subscription will try to append to the occlusion group that already contains the reconnected player. Tests: reconnected with a player in vicinity
3 Days Ago
Bugfix: ServerOcclusion - clean up occlusion group refs when retiring groups Fixes false-positive error logs Tests: 2p, 2nd player disconnects while 1st player is in vicinity - afterwards first player walks out then back into to original network cell
3 Days Ago
Update: Update: OcclusionGroups - each members tracks which group refers to it Needed for an upcomign bugfix in OnDestroy and helps detect issues Tests: 2p on Craggy - tested players close, flying far away, teleporting, disconnect-reconnect - logged an extra problem to address
3 Days Ago
Clean: refactored out OcclusionOnDestroy, as it was getitng messy - also added a null check to avoid pooling issues Tests: none, trivial changes
3 Days Ago
Bugfix: OcclusionGroups - ensure sleepers are tracked when player transitions to a different occlusiongroup This is an edge case when being in subscription range of a sleeper - sleeper's group would contain it and player, but player's group would have sleeper missing Tests: moved around in the vicinity of sleeper, checked internal state
3 Days Ago
Bugfix: OcclusionGroups - fix NRE when moving out of group with a sleeper - replaced with a IsVisibleFromFar check - also reworked teleportation logic via IsVisibleFromFar, as that's more correct - also IsVisibleFrom range check was wrong, so fixed that Previous code relied on subscriber to check if move-out-of-bounds occurred, but sleepers don't have a subscriber, so it NREed Tests: moved away from a cell with a sleeper, checked internal state
3 Days Ago
Update: NetworkVisibilityGrid gains IsVisibleFromNear/Far(Group from, Group to) - expose via provider interface Needed for occlusion groups case of moving sleepers (as I can't rely on subscriber check) Tests: testted as part of followup bugfix
3 Days Ago
Merge: from main
3 Days Ago
Bugfix: OcclusionGroups - eagerly clean up occlusion group when teleporting - consolidated occlusion-group leaving logic Caught the bastard - due to over-time nature of subscription updating, there was a window in which the player could teleport and disconnect, leading to a leak of occlusion group and a null participant. Tests: on client, teleport2marker;kill, then separatelly disconnect; then on server run OcclusionValidateGroupson - all's gud
3 Days Ago
Update: minor changes - comment explaining why occlusion group isn't retired - error log for cases where we're unsubscribing from network group but we're not in it's occlusion group - TODO comment outlining a desync between group transitions on the border of subscription range and networkable destruction Tests: none, trivial changes
3 Days Ago
Bugfix: check if occlusion group participant is null when cleaning up occlusion groups Should not be needed, but until I track down where nulls are happening this can prevent other issues Tests: none, trivial change
4 Days Ago
Update: PersistentObjectWorkQueue now gathers a bit more telemetry - also fixes a potential bug with stale data uploading to our backend (another case in ObjectQueue) There's a bug with it being desynced with the rest of the data (it's called last, but in reality is current), will fix later Tests: none, not done yet
4 Days Ago
Update: runtime_profiler - track pre_lateupdate times It's a category with a bunch of unity internal work that can take a non-trivial amount of time. Should make it easier to identify source of degradation. Tests: dryrun of analytics in editor with runtime_profiling 1
4 Days Ago
Merge: from useplayertasks_removegroupoccludee_nre - Bugfix: patch exception from double add of occlusion group member. OcclusionValidateGroups to validate if groups are correct Tests: various 2p scenarios - being close, far, outside of range, teleports
4 Days Ago
Update: add OcclusionValidateGroups servervar - also replaced the conditional log with a logerror, to make sure we spot it - codegen Couldn't reproduce the issue locally, so I'm missing something, including whether it was a false-positive or not. This should help check every bad case and confirm whether the issue is legit or not Tests: used the command in a couple scenarios - players close, players far, players outside of network range, with invis on/off