1,999 Commits over 488 Days - 0.17cph!
Merge: from main
- Bugfix: Removes client-side network group setting when updating parents - fixes phantom entities on cargoship and other global network entities
Tests: flew around craggy, was able to pick up items, chop trees, kill animals. spawned cargoship and dropped items on it, spawned dressed player & killed him, then deleted them using console cmd - they got cleaned up as expected
Update: BaseEntity.UpdateParenting no longer tries to update network group
- When client receives an entity snapshot, allow it to update the network group if it's out of sync
We already get network group change messages - there's no need to try to "guess" on the client and potentially desync.
Tests: flew around craggy, was able to pick up items, chop trees, kill animals. spawned cargoship and dropped items on it, spawned dressed player & killed him, then deleted them using console cmd - they got cleaned up as expected
Bugfix: Run same network-group-inheritance checks on client when recieving snapshots
This resovles a scenario where dropped items/players on a cargoship/crane/etc have local net group, but client resolves global net group.
Tests: Spawned cargo ship, spawned NPC, player - killed both. dropped items. flew away, destroyed them via console, flew back - they were gone
Bugfix: handle spawn groups on non-baseentity gameobjects
Tests: procgen 2.5k in editor
Merge: from navmeshsurface_optim
- Optim: Ghostships now use a static, detached navmesh, saving us on navmesh re-integration every physics step
- New scientists adapted to work with detached navmesh
- In C+S editor, we now automatically exclude client-scene entities from dynamic navmesh gen
Tests: spawned all ghost ships, observed scientists patrolling, dogfighting, sprinting
Clean: remove obsolete TODOs
Tests: none, trivial change
Clean: remove test code that offset the baked navmesh
Prepping to merge back
Tests: spawned all variations of ghostship, engaged scientists - didn't spot any weirdness
Bugfix: LimitedTurnNavAgent - when path following, ensure facing direction is applied in world space
Previously it was done in navmesh space, causing scientists to look in the sky during dogfight
Tests: observed scientists dogfighting and chasing behaviors - they either looked in direction of run or me
Bugfix: Ensure NavAgent properly initialzied when trying to spawn on a detached navmesh
Tests: spawned ghost ship, AI started patrolling and running around to shoot me when spotted
Bugfix: SpawnGroup now applies entitie's world<->navmesh transformations when picking a spawn point
Tests: Spawned ghostship - all NPCs spawned, but not moving (likely my other experimental code borks it)
Update: DynamicNavMesh allows to exclude specific navmesh source roots
- Ghostships register to be excluded, since they have their own baked navmesh
- [editor-only] Added logic to exclude all roots from the client scene
This CL also has some temp ghostship debug code (offsets navmesh to validate it)
Tests: in water world spawned a GhostShip and enabled AI - only backed navmesh popped into existence. AI didn't spawn - need to investigate next
Merge: from hackweek_jit_explorer
- Buildfix for missing type definitions
Tests: built scripts in all editor modes
Buildfix: move type declarations to JITViewer
Tests: compiled scripts in all editor build modes
Merge: from hackweek_jit_explorer
- New(editor): Tools/Engine/Jit Viewer that allows to inspect native instruction output from JIT compiling managed methods
Tests: used Jit Viewer to inspect BasePlayer::ServerUpdate. Ran perfsnapshot in C+S editor
Update: consolidate various editor tools in Tools/Engine
Tools top menu still doesn't fit on my 1080p screen .-.
Tests: checked the Tool menu
Update: Update ServerProfiler.Core binaries to release
- built from 6737a87e
Tests: perfsnapshot in editor, used jit viewer
Update: apped hex prefix when emitting native method address
Tests: none, trivial change
Update: emit address of native function
Trying to chase up why sometimes names missmatch with what VS disassembly window shows
Tests: viewed BasePlayer::BoxTest
Bugfix: use mnemonics instead of bytes when checking if decoding should finish
My initial attempt to inpsect raw opcode didn't work in all cases, leading to false-positive parsing aborts.
Tests: viewed BasePlayer::ServerUpdate and BasePlayer::BoxTest
Update: better detection when to stop decoding stream
- now tracks max referenced jump address and stops on last ret or jmp -offset
Tests: viewed nested call in BasePlayer::BoxTest
Bugfix: ensure instruction pointer gets saved to list only if we stopped parsing teh stream
Previously we could add the ip to the list before we decided to stop decoding, leading to out of sync issues
Tests: viewed BasePlayer::BoxTest
Update: change asm text color if it's a potential address
Tests: viewed BasePlayer::BoxTest
Bugfix: avoid double-draw
Tests: viewed BasePlayer::BoxTest
Update: Add relative jump arrows
This was much more painful than expected, but a bit of hodge-podge and it's gud
Tests: viewed BasePlayer::BoxTest
Update: hook up native symbol resolution
- ServerProfiler.Core built from 0b3b7d86
This gets us various mono_... calls, but still missing some function names - guessing those are mono-related but not part of mono dll itself
Tests: Viewed BasePlayer::BoxTest and stepped through nested calls
Update: separate out JITViewer logic from ServerProfiler
- ServerProfiler.Core built from 1074407d
- also contains native symbol resolving logic, but not plugged in yet
JITViewer functionality is now editor only(dll won't ship with builds).
Tests: viewed BasePlayerr::BoxTest
Update: couple improvements to JIT viewer display
- relative jumps are shown as "signed hex" offsets, to avoid jnz 0xffffffffffffffe cases
- avoid duplication of address when we have a method name for a jitted address
Tests: viewed BasePlayer::BoxTest and BasePlayer::ServerUpdateParallel
Clean: get rid of debug logs
Tests: none, trivial change
Update: remember selecter row index between dissasm states
Tests: viewed BasePlayer::BoxTest
Update: use consecutive int3s to stop decoding
Doesn't always apply, but when it does saves a lot
Tests: viewed BasePlayer::BoxTest
Update: allow inspecting instructions at address-like values
Need to improve stream decoding in those cases, as it can run away to 12k lines of assembly even though the method was over on line 10.
Tests: viewed BasePlayer::BoxTest
Clean: logic refactor in prep for multiple view support
Tests: viewed BasePlayer::BoxTest
Update: resolve addresses to methods/trampolines where possible
- ServerPorfiler built from 18130132
A bit ugly, but don't care for now
Tests: viewed BasePlayer::ServerUpdateParallel
Bugfix: jump addresses are now valid
- Also added ability to show opcode bytes
- ServerProfiler built from 95cd43f7
Was due to invalid use of library API (I should've RTFMd)
Tests: viewed BasePlayer::ServerUpdateParallel
Clean: remove binary dumping debug code
Mystery byte was caused by fopen using "w" mode isntead of "wb", which allows windows to handle special characters. In our case it was injecting an extra byte that was screwing over jumps. But it was all debug code anyway.
Tests: none, trivial change
Bugfix: treat instruction stream as 64bit, not 32bit
- ServerProfiler built from 6c5c94dd
Got mislead by Unity's mono --version reporting it as x86. Last bug left - an unexpected byte appearing mid instruction stream when copying from unmanaged, but missing on managed side
Tests: viewed BasePlayer::ServerUpdateParallel
Bugfix: use ListView+labels intead of multiline TextField
Fixes weird disappearing text and gets rid of the vertex limit for text
Tests: viewed BasePlayer.ServerUpdateParallel
Update: display 32-bit disassembled instruction stream in editor window
- ServerProfiler built from 5bff6c48
Couple weird issues - textfield goes invisible half-way through (but can copy the text out of it and goes back visible before end), binary stream differs between managed and unmanaged sides. Will chase up next
Tests: viewed BasePlayer::ServerUpdateParallel
New: ServerProfiler can now dump raw binary of a managed method after JIT
- using debug binary built from facc83cb
Baby steps. No idea how to read it yet, and will need to explore how to control optimization levels.
Tests: Exported Assembly-CSharp!BasePlayer::ServerUpdateParallel
Merge: from spectate_related_cmd_fixes
- sleeping-/usersinrange commands now run from spectated player's position, if spectating
Tests: used commands when spectating
Update: when running sleeping-/usersinrange, prefer to query from spectating target position
Tests: used the commands while spectating
Merge: from spectate_command_fix
- Bugfix for spectate doing nothing when spectating far-away player
- Bugfix for error on respawn after spectate if previously didn't have a spectate target
Tests: used spectate out of network range 10 times in a row, used keybind to spectate twice in a row - no issues
Bugfix: Spectating - when no valid spectator found when starting to spectate, ensure we still set the right SubStrategy
- If no spectate targets were found, chat message now contains the used filter
Could easily happen for people using keybinds, as keybind sends "spectate True"
Tests: using keybind, spectated other player twice in a row - no more errors
Bugfix: Spectating - ensure Spectating flag always gets sent to the owner
Fallout from the queue skipping optimization
Tests: Went outside of network range, waited for subscription to unsub and and started spectating on a 2p server. Did it 10 times - no failures
Update: Adopt Scientist2FSM to be aware of ghostship navmesh
Need to double check aiming logic (sometiems they aim at the sky), and investigate how initial on-navmesh spawning is done. Also need to convert variant FSMs
Tests: spawned ship navmesh offset and with a rotation. Ran around into different areas of the ship and rooms - they pursued
Update: serverocclusiondebug - clarify what invalid grid means
Now explicitly saying that server occlusion treats path with one or more invalid grid positions as unblocked
Tests: none, trivial change
