2,102 Commits over 518 Days - 0.17cph!
Update: adding a TODO to enable minor logic caching
Tests: none, trivial change
Merge: from triggerparentdelayedexit_optim
- Bugfix: added missing check in tickmode 1
- Bugfix: fixed TriggerParentDelayedExit cleanup logic disabling it's effects
- New: paste_line command
Tests: built a wonky ship with tickmode 1, jumped over it's gaps
Update: TriggerParentDelayedExit cleanup logic only runs when trigger is disabled
We always ran cleanup when OnEmpty got invoked, even if decided to delay the exit, which disabled delay functionality
Tests: built a wonky ship and jumped around gaps - parenting was in effect long enough
Bugfix: TickMode 1 - add missing overrideOtherTriggers check
Tests: none, trivial change
Update: remove dead vars and cache == null check
Tests: none, trivial change
Update: add paste_line <name> [count = 1] [offset = 1] - will spawn the clipboard in a line using player's facing with offset-sized spacing
- also if pasting players, make sure they run their ForceTriggerUpdate
- codegen
Tests: spawned a 100 boats in a line
Bugfix: TriggerParentDelayedExit::SupportsTickSkipping was always evaluating to false
- switched it to be off by default, as it was likely off during my earlier testing
Tests: none, trivial change
Merge: from triggerparentdelayedexit_teleport_fix
- Bugfix: teleporting from a player boat should no longer cause weird parenting issues
Tests: built a boat, teleported away - no weird movement afterwards
Bugfix: don't try to delay unparenting when teleporting away from the boat
Tests: built a small boat, spawned a player on it, turned on the engine, teleported away - didn't have the weird extra movement
Merge: from analytics_std_dev_fix
- Bugfix: fix for invalid std_dev calculation
Tests: none, trivial change
Update: always record high and low percentile telemetry for non-game mode
It's a smidge more data, but makes building dashboards easier
Tests: none, trivial change
Bugfix: fix std_dev that could generate NaNs via sqrt of a negative number
Tests: none, trivial change
Merge: from triggerparentdelayedexit_optim
- Bugfix: shooting a weapon can cause NREs on the client
Tests: shot in the sky with a bunch of bursts - no NREs
Bugfix: VerifyRays - avoid trying to read hit array outside of working area
I asssumed we always call it with tightly-sized arrays, but it's not the case on client
Tests: shot in the sky with a couple bursts - no NREs
Merge: from triggerparentdelayedexit_optim
- Optim: improve performance of GamePhysics.TraceRays family of queries
- Optim: TickMode 1 - add UsePlayerUpdateJobs2 related shortcuts to TriggerParent
Tests: built a boat with tickmode 1, spawned npc player on it, jumped on and off, flew in it's vicinity - no issues.
Optim: TraceRaysUnordered - optimize collider validation using burst jobs
- added UtilityJobs.FlipBoolJob and ScatterToJob<T>
This brings costs down across the board:
* 128 rays - 0.37ms -> 0.25ms, 33% improvement (serial was 0.49ms, 49%)
* 1k rays - 2.59ms -> 1ms, 61% (serial was 4.33ms, 77%)
* 8k rays - 18.9ms -> 6.26ms, 67% (serial was 34.79ms, 82%)
Tests: unit tests
Optim: TraceRaysUnordered - run water traces in parallel to raycasts
Not the best impl, but shows improvement for smaller ray counts (where we're not dominated by Verify):
* TraceRaysUnordered - 128rays: 0.44ms -> 0.37ms, 1k+ rays same
* TraceRays - 128rays: 0.56ms -> 0.50ms, 1k+ rays same
Can apply the same to sphere casts as well.
Tests: unit tests
Optim: TriggerParent.TickMode 1 - use cached water and ladder results in UsePlayerUpdateJobs 2 env
- codegen
This should allow us to skip ~30% of the overall runtime. Can be disabled via TriggerParent.UsePlayerV2Shortcuts 0 (defaults to 1)
Tests: none, will check tomorrow once brain is fresh
Optim: TriggerParent.TickMode 1 - avoid unnecessary entity lookups in RunClippingChecks
Microoptim, but why not
Tests: none, trivial change
Optim: TriggerParent.TickMode 1 - skip RunClippingChecks for entities that failed RunCheckForObjUnderFeet
Tests: none, trivial change
Clean: remove a couple TODOs
Was worried about a bug, but deeper scrutiny think the code is correct
Tests: none, trivial change
Clean: refactor TriggerParent.ShouldParentEntitiesJobs
- Added profiling scopes
No functional changes. This makes data flow easier to track and manage, and helps visualizing stages in perf snapshots.
Tests: built a long-boat in tickmode 1, spawend 6 players on it, went to edit mode and back, jumped on-and-off as it was moving
Bugfix: Add missing Native collection disposal in GamePhysics
Audited all of GamePhysics, looks to be the only cases that slipped in
Tests: unit tests + built a boat with tickmode 1
Optim: use persistent buffers for TriggerParent::RunCustomJobsQueue
- codegen
Tests: with tickmode 1 - built a boat, jumped on-off
Clean: rip out tickmode 1 and 2, rename Jobs mode as tickmode 1
- codegen
Out of all versions it's fastest, so only going to continue with it vs baseline 0
Tests: compiles
Merge: from triggerparentdelayedexit_optim
- Bugfix: properly cleanup TriggerParent and TriggerParentDelayedExit to avoid invalid invokes running
Tests: built & finished a boat, jumped around while moving, put it into edit, finished, jumped around - no errors, no extra invokes
Bugfix: properly clean-up TriggerParent and TriggerParentDelayedExit when it gets disabled
Reimplements intents of `139965`.
Tests: built & finished a boat, jumped around while moving, put it into edit, finished, jumped around - no errors, no extra invokes
Merge: from triggerparentdelayedexit_optim
- Bugfix: mitigate double trigger exit call on TriggerParent
- Bugfix: TriggerParentDelayedExit leaving invalid invokes when editing already existing boat
Tests: built a boat, spawned a player on it, edited - no more errors, no extra invokes running
Undo of Undo:
139927 (merge: from triggerparentdelayedexit_optim)
Will apply the fixes on top with merge
Bugfix: TriggerParentDelayedExit - skip entity-delay logic when trigger gets disabled
This left invalid invokes running when editing existing player boat, inflating the perf cost
Tests: edited existing boat, checked profiler - saw no perf samples gor persistent queue
Bugfix: early out when double-remove happens
Not sure why yet, but saw the same with double-add before, so going to replicate. Also noticed that we can be tracked, but have null-entitycontents, which leads to wasted Invokes, adding overhead - checking
Tests: built boat, spawned npc, went to edit mode - no more errors
Undo: `139927` (merge: from triggerparentdelayedexit_optim)
Merge: from triggerparentdelayedexit_optim
- Optim: triggerparent.tickmode 0-3 (0 default) - various implementations for TriggerParent.OnTick execution, can be switched at runtime.
Tests: unit tests + building a boat, jumping around on it, trying going under it and climbing ladders and stairs.
Update: Codegen
Tests: ran "check compile errors"
Optim: in tickmode 3, run OverlapOBB and TraceRealm queries in parallel
Should help in many-boats-players scenarios, in theory
Tests: built a boat and jumped around as it was moving
Bugfix: SelectNearestNHitsJob - ensure we emit an end if we couldn't select requested number of hits
- Added couple early returns to avoid div by 0 issues
Tests: rode a boat with tickmode 3
Update: initial full version of TriggerParent.ShouldParentEntitiesJobs
inlines ToClipping so that we can batch OverlapOBB, but doesn't batch expensive-but-rare checks - need to see if we need this during playtest
Tests: built a boat, finished it, enabled tickmode 3, tried jumping on/off the boat
Update: Added GamePhysics.OverlapOBBs
- added basic consistency unit test: TestOverlapOBBsConsistency
Tests: ran unit test
Bugfix: GamePhysics.TraceRealmRays now considers non-entity hits as valid
- fix build failures in CLIENT only mode
- also added option to specify whether to run water query or not
Tests: ran unit tests(C+S and C separately) - they pass
Tests: rework GamePhysicsTests.TraceRealms to work in C+S and C modes
No longer permitting running S realm tests in C editor (as that created impossible spawn scenarios)
Tests: ran unit test in both modes
Tests: add TestTraceRealmRays unit test
Shows that there's a bug with TraceRealmRays - will submit next
Tests: ran unit tests
Optim: Use burst to generate sort jobs
Despite replacing previous optim, saves us another 0.1ms on top of it (4.25ms -> 4.15ms avg for 2k rays). Left a comment that we need alloc-free tasks to optim further(scheduling sort jobs is expensive, but thread safe).
Tests: ran unit tests
Optim: manually kick off sort jobs to worker threads when enough is accumulated
On a 2k TestTraceRays gives us 0.15ms (4.25ms -> 4.4ms). Building jobs using burst might be faster though, gonna try that next.
Tests: ran unit tests
Bugfix: ensure we free counts array only after all sorting jobs are done
Tests: ran unit tests (though they didn't catch it before)
