The client's TacArcBehavior::Cast (0x00fb2d10) sorts the targets in the arc nearest first, or by weight when
distance_weight or angle_weight is set (sortWithWeights, 0x00f58cd0: distance_weight * (max range - distance) /
max range + angle_weight * (180 - angle) / 180, heaviest first). With use_attack_priority, SortByAttackPriority
(0x00f72900) then buckets them by GetAttackPriority, lowest first, keeping that order inside each bucket; only the
DestroyableComponent answers it, and an object without one counts as 1. DoHit keeps the first max targets.
Nothing else ranks targets: enemies are taken over nearer smashables only because their attack_priority (1) is
lower than most smashables' (10). use_attack_priority is off when a behavior does not set it (TacArcBehavior::
Initialize, 0x00f9b980), as before.
The server sorted by distance only and ignored the flag, so a one-target swing hit the nearest crate instead of the
enemy behind it. OrderTargets now does the client's ordering, with equal targets in ascending id order (the order
the client's id set hands them over in); the chosen targets are still written in ascending id order (issue 1045).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The client's TacArcBehavior::DoHit (0x00fb10c0) writes the closest max-targets ids from a set, so ascending and
each once, then the action data per id in that same order; DoUnserializeBS (0x00fb26a0) reads them the same way and
skips empty ids. The server handled the targets in list order and skipped ids whose object it could not find
without reading their action data, so every later target read the wrong bits (several pirates under a Doom Slicer).
Handle now reads the action for every listed id in ascending order, and the server's own casts write ids and actions
in ascending order after picking the closest targets.
TacArcBehavior::Cast (0x00fb2d10): a picked target that passes the filter gets the action with no TacArc data (the
server's own cast now calculates that action instead of handling it); otherwise the target is dropped, and an arc
measured from the target's position writes nothing.
Check in game: Doom Slicer and multi-target katanas on groups of pirates/admirals damage each of them; apes still
take damage during their stun; enemies with arc attacks (apes, Maelstrom horsemen) still hit players.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Logger: Rename logger to Logger from dLogger
* Logger: Add compile time filename
Fix include issues
Add writers
Add macros
Add macro to force compilation
* Logger: Replace calls with macros
Allows for filename and line number to be logged
* Logger: Add comments
and remove extra define
Logger: Replace with unique_ptr
also flush console at exit. regular file writer should be flushed on file close.
Logger: Remove constexpr on variable
* Logger: Simplify code
* Update Logger.cpp
* Re-write AOE behavior for new filter targets
Update Tacarc to use new filter targets
Added dev commands for skill and attack debugging
* Get all entities by detroyable
rather than controllable physics
Since destroyables are what can be hit
* Re-work filter targets to be 100% live accurate
reduce memory usage by only using one vector and removing invalid entries
get entities in the proximity rather than all entities with des comps in the instance, as was done in live
* remove debuging longs and remove oopsie
* address feedback
* make log more useful
* make filter more flat
* Add some more checks to filter targets
add pvp checks to isenemy
* fix typing
* Add filter target to TacArc and update filter target
* fix double declaration
* Some debugging logs
* Update TacArc reading
* make log clearer
* logs
* Update TacArcBehavior.cpp
* banana
* fix max targets
* remove extreanous parenthesesuuesdsds
* make behavior slot use a real type
---------
Co-authored-by: David Markowitz <EmosewaMC@gmail.com>
* Move EntityManager to Game namespace
* move initialization to later
Need to wait for dZoneManager to be initialized.
* Fix bugs
- Cannot delete from a RandomAccessIterator while in a range based for loop.
Touchup zone manager initialize
replace magic numbers with better named constants
replace magic zonecontrol id with a more readable hex alternative
condense stack variables
move initializers closer to their use
initialize entity manager with zone control
change initialize timings
If zone is not zero we expect to initialize the entity manager during zone manager initialization
Add constexpr for zone control LOT
* Add proper error handling
* revert vanity changes
* Update WorldServer.cpp
* Update dZoneManager.cpp
* Add failArmor server side
Address out of bounds reading in behavior
Address the basicAttackBehavior reading out of bounds memory and reading bits that didnt exist, which occasionally caused crashes and also caused the behavior to do undefined behavior due to the bad reads.
Tested that attacking a wall anywhere with a projectile now does not crash the game. Tested with logs that the behavior correctly returned when there were no allocated bits or returned when other states were met.
Add back logs and add fail handle
Remove comment block
Revert "Add back logs and add fail handle"
This reverts commit db19be0906fc8bf35bf89037e2bfba39f5ef9c0c.
Split out checks
* Cleanup Behavior streams
