Client updates nearby clients more often because they will disappear after 10 seconds without a position update to the client
This results in a massive reduction in unnecessary traffic as we only update clients of their relevance around them
This also resembles live-like packet sending behavior of positions
- Before when reverse aggro checks were done (client to NPC), checks would happen every 750 millseconds where a client would
check an entire entity list with distance calcs and other checks for aggro, with many clients in a zone and many NPC's this would
add a lot of unecessary overhead. A temporary adjustment on 3/25 was made and upped the check to 6 seconds.
- Now, there is a new methodology to scanning. The client will build a cache list of NPC's within close range as defined in new rule:
RULE_INT(Range, ClientNPCScan, 300) and will also get any NPC that has an aggro range beyond that defined range to use in
the frequent checks for aggro, the result is far less overhead
- Client scanning changes when moving versus not moving, the client will scan aggro every 500 milliseconds while moving, and
3000 millseconds aggro check when not moving, with a 6000ms re-fetch for close NPC's
- A demo of these changes can be found here:
https://youtu.be/aGroiwLSTVU
This should cause the auto haters to be shared with other toons who might be
interested (group/raid) like live.
There maybe some bugs since there is a lot of complex interactions here.
Added better netcode support for handling out of order acks, to preclude excessive resending of same packets.
Changed how timeout checks are performing on individual packets, for re-sends, so they do not happen more often than the client can respond.
Improved how the data rate limit for throttling packets for compressed stream, so the size reduction in packets are accounted for better.
- When a zone boots, it will spawn an invisible npc by the name of zone_controller
- Lua and Perl scripts can be represented with this npc as zone_controller.pl/lua
- This NPC's ID is ruled be define ZONE_CONTROLLER_NPC_ID 10
- Two EVENT's uniquely are handled with this NPC/controller (They only work with the zone_controller NPC)
- EVENT_SPAWN_ZONE :: All NPC spawns in the zone trigger the controller and pass the following variables:
$spawned_entity_id
$spawned_npc_id
- EVENT_DEATH_ZONE :: All NPC deaths in the zone trigger the controller event and pass the following variables:
$killer_id
$killer_damage
$killer_spell
$killer_skill
$killed_npc_id
various situations.
First, the set function for mob _appearance optimized sending a message
if the new appearance was equal to the old. This cann't be done, as
the 1st time the zone runs there is no client when the set function is
called. If we're combining set/send, as we are, better to always do both. This fixes several of the cases.
Repop also did not work, as no code was being called reliably to set
appearance and update the client based on code path and various flags. This is also fixed.
when the spawn vie gm command or normally with loot tables that equip.
Refined previous changes that fixed the issue with zoning in and not seeing
previosuly spawned armor by sharing the same module.
and NPCs wearing gear in non-weapon slots.
The illusion thing: Not sure why, but te opcode for BulkZoneSpawn doesn't
display the tree/object illusions. I did notice that even OP_Illusion gets
rejected by the client if sent before Client_Ready. Maybe that is why. The
BULKSpawns cannot be sent that late, I tried moving it in the sequence but
it never did the illusions correctly, at any point. So, we new new the
single spawn OP code for PCs with those illusions. This works.
The NPC gear thing. Same story with BulkZoneSpawn, Not sure why. The data
is sent correctly. So now we update the client zoning in (only them) with
what the NPCs are wearing. Every othe client already is up to date.
