* Added ability to use normalized XP per AA (based on # of kills per AA per white con NPC -- TSS era change)
* Added ability to use accelerated AA gain between a defined range (based on live, 0 - 4000 AA, linearly decreasing)
Added column triggered_number. If this is set, then the trap will despawn after it has been triggered this number of times. If 0, the trap will never despawn on its own.
Added group column. This allows developers to group traps together in a similar way as spawngroups for NPCs. When a trap that is grouped is despawned in anyway, a random trap in the group will take its place. Grouped traps do not have to be at the same coords or have the same type. This can allow for some spawning diversity if so required. If set to 0, the trap is not grouped and will always respawn.
Added column despawn_when_triggered. If set to 1, then a trap will despawn when a player triggers it. If 0, then there will be a 5 second reset time and then the same trap will again be active. (Assuming triggered_number has not been reached.) The player that triggered the trap will not re-trigger it until they have left and re-enetered the trap's radius.
Traps will no longer trigger on players that are currently zoning. This fixes some weirdness and at least one crash. The trap can trigger however after the connection is been completed. If a player camped out in a trap radius they can potentially still be hit.
Alarm type traps were not using effectvalue2 to determine who should be aggroed. This is now fixed.
Traps will no longer be broken by #repop, #depopzone, or #reloadworld. All 3 commands will now have the same effect on traps as they do for NPCs.
Added command #reloadtraps. This reloads all of the traps in the zone.
Added command #trapinfo. This gives some information about the traps currently spawned in the zone.
Added Traps logsys category
Required SQL:
utils/sql/git/required/2017_10_26_traps.sql
Currently the names only show for inspecting via Target Window because
we send buff packets in the wrong order and there is a dependency on
them being correct for self that isn't present for target window.
Mods properly calculated
Stages should be put in place if not already:
https://wiki.project1999.com/Food_and_drink#Stages_of_Hunger_and_Thirst
Values stored in the database are 0-6000, previously we capped it at 6000 but previous math would have normal values in the 60k+ range in order for food to be consumed at a reasonable rate. We are now using more native logic where 1 = 1 minute, following logic:
(Minutes)
0 - 5 - This is a snack.
6 - 20 - This is a meal.
21 - 30 - This is a hearty meal.
31 - 40 - This is a banquet size meal.
41 - 50 - This meal is a feast!
51 - 60 - This is an enduring meal!
61 - X - This is a miraculous meal!
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
- HP Updates now only send to others when HP percentage changes (0-100%)
- HP Updates were sending excessively even during idle zones when HP wasn't changing at all
- Attack animations now only send once per second versus up to a hundred times a second per Mob/Client
- 17,000 OP_ClientUpdate packets per second have been observed in combat scenarios, some of the major culprits have been
throttled without affecting what the client should see
- Before and After packet differences under similar load/tests (Packets per second)
- 7,000 - 8,000 OP_Animation pps After: 600-800 pps
- 13,0000 - 17,000 OP_MobHealth pps After: 1-10 pps
- 15,0000 - 20,000 OP_ClientUpdate pps After: 500-1,000 pps
- Packet reports from a 46 client test here:
https://gist.github.com/Akkadius/28b7ad2fdd82bdd15ea737c68f404346
- Servers who use Marquee HP updates will also recieve far less packet spam as they will only be sent when HP changes
