* [Bots] Add valid state checks to ^clickitem
- Bots previously weren't checking if they were in a valid state or not before trying to click an item when told (in a death state, held, feared, silenced, in group/raid, etc.)
* Add error output on no bots selected.=
- [#4756](https://github.com/EQEmu/Server/pull/4756) changed the way overwriting worked for buffs. It allowed stronger spells to overwrite lesser spells if they were already on the target.
- However, this is a positive change but has its drawbacks with spells of similar value. It could cause an endless buff loop where they constantly replaced one another.
Overall, the con of endless buffing outweighs the benefit of automatic overwriting lesser spells and the control should be left to only spell lists via `^spells` for bot owners as it was before to determine which buffs bots will cast.
- Certain resist spells have a DS bonus on them and can be casted as a resist rather than a damage shield. This forces anything with a damage shield as a damage shield buff.
* SPA180 bypassed by field no_resist (field209)
SPA 180 SE_ResistSpellChance provides chance to resist spells outright. This should not be checked to resist a spell if spell has (field209 / no_resist) set to 1.
* Update spells.cpp
confirmed on live unresistable spells are not blocked by sanctification disc or related AA's
* SPA 378 update
Update to SPA 378
SE_SpellEffectResistChance provides chance to resist specific spell effects.
This updates allows support for multiple resistance checks against different effects in same spell.
Example. If a spell has a silence and a blind effect and the target has an AA that gives 10% chance to resist silence and 5% chance to resist blind. It will roll against effect respectively each giving a chance to resist the spell.
* Update spells.cpp
Unresistable spells (resisttype = 0) do not ever resist a spell even with SPA378
Example: Pheonix Charm in Plane of Fire, or Storm Comet in Bastion of Thunder. Parsed both and never got a resist despite having the AA that has effect specific resists which both those spells match.
* [Zone] Zone State Automated Testing and Improvements
* Spawn condition
* Update zone.cpp
* Remove redundant logic
* Update zone_state.cpp
* TestZLocationDrift
* Protect NPC resumed NPC's from being able to die
* [Bots] Line of Sight and Mez optimizations and cleanup
- Renames `Map:CheckForLoSCheat` to `Map:CheckForDoorLoSCheat` to better reflect what it does.
- Renames `Map:RangeCheckForLoSCheat` to `Map:RangeCheckForDoorLoSCheat` to better reflect what it does.
- Adds the rule `Pets:PetsRequireLoS` to determine whether or not commanded pet attacks require an addition layer of LoS checks for edge-cases.
- Adds the rule `Bots:BotsRequireLoS` to determine whether or not bots require LoS to `^attack`, `^pull` and `^precombat`.
- Adds the rule `Map:ZonesToCheckDoorCheat` to control what if any zones will be checked..
- Corrects, removes and adds LoS checks where necessary.
- Improves door checking logic for locked or triggered doors that could be blocking LoS.
- Cleans up false positives for door cheat checks.
- Adds `drawbox` option to `#door` command. This will spawn points at the center and each corner of the door's "box". It will also spawn points at your and your target's location.
- Improves Mez and AE Mez logic
- Adds more details to the rule `Bots:EpicPetSpellName`
* Remove leftover debugging
* Change return to continue for GetFirstIncomingMobToMez checks
* Move mez chance fail to beginning of cast process
- Non-taunting melee bots will now properly go behind their target when it is enraged.
- Reduces how often taunting bots adjust their positioning by removing unnecessary rules.
- Cleans up CombatPositioning a bit
* [Bots] Fix error copy/paste
Oops
* Eliminate false errors on empty rules and add more sanity checks
- `Bots:ZonesWithSpawnLimits` - This is to be used when zones will only allow up to x amount of bots. Example: A player can normally spawn 5 bots but a zone in this rule has a lower limit of up to 3, this rule would override their normal limit if their normal limit is above the listed zone's max in `Bots:ZoneSpawnLimits`.
- `Bots:ZonesWithForcedSpawnLimits` - Zones in this rule will override any spawn limits high or low and force it. If one player can normally spawn 2 and another player can spawn 10 but a zone listed forces a limit of 5, all players will be able to spawn 5. Follows the limits set in `Bots:ZoneForcedSpawnLimits`
* [Performance] Have World Send Smarter Guild Updates
* Updates to correct incorrect guild window details (permissions, etc) not being sent on guild creation.
---------
Co-authored-by: Mitch Freeman <65987027+neckkola@users.noreply.github.com>
* initial work, need to clean up gm commands still
* cleaned up command, works without kicking char select now
* remove thj-specific methods
* add script hooks
* actually clear flag
* rework questmgr::rename
* remove unnecessary logging
* revert
* added missing binding to perl api and updated some text
* don't return a value
* Fix some bad argument types.
* adjust case
* alpha order
* refactor some old string stuff
* don't quote integers, bob
---------
Co-authored-by: Zimp <zimp@zenryo.xyz>
Co-authored-by: Chris Miles <akkadius1@gmail.com>
- When bots would charm a pet, once they zoned or camped the pet would poof and not trigger a respawn so the NPC which was charmed would never respawn until the zone was shut down or server restarted.
When dynamic zones are cached on zone boot each dz requests member
statuses from world separately. This causes a lot of network traffic
between world and booted zones when there are a lot of active dzs.
This changes it to make a single request to world on zone boot and a
single bulk reply back.
