When a pet ability was cast, PetHandler reset all CharmInfo flags before
calling PetAI methods, setting the attack flag to true every time.
This commands the pet to go and chase the target which is not correct
when the state is COMMAND_STAY.
PetAI already handles the scenario, it just wasn't getting the actual
pet attack state.
* move several enum definitions in a new files
* move more things
* remove the include comment
* move the related code to CharmInfo in this own file
*original idea of Ovahlord
Co-Authored-By: Ovahlord <18347559+Ovahlord@users.noreply.github.com>
* fix clang build errors and few blank lines
* missing forward declaration
* new tentative to fix gcc/clang build
* add several include could be necessary for gcc/clang compilation
* .
* revert some include since the last AC update
* fix some loop inconsistencies
* align all enums in UnitDefine.h
---------
Co-authored-by: Ovahlord <18347559+Ovahlord@users.noreply.github.com>
* refactor(Core/World): Move SendGMText to WorldSession and allow `fmt`
- Move SendGMText from World to WorldSession
- Make SendGMText use fmt
- Make SendGMText parse acore_string entries
* Update cs_message.cpp
* tokenize the string only once
* Move to chathandler
* Update WorldSession.cpp
* make sure we have a session
* feat(Core/Chat): Provide a fully-formed protocol for addons to interact with GM commands
* Send success/fail state, allow interleaving, and indicate end of output. Add framework for supporting non-human-readable output in commands.
* cherry-pick commit (508c9d2fc1)
This PR implements a well-formed protocol for addons to communicate with the server, outlined below:
- All communication happens over the addon channel (`LANG_ADDON` in terms of the core, `CHAT_MSG_ADDON`/`SendAddonMessage` for the client). The prefix used for all messages is `AzerothCore` (in client terms - in core terms, every message starts with `AzerothCore\t`).
- In each message, the first character is the opcode. The following four characters are a unique identifier for the invocation in question, and will be echoed back by the server in every message related to that invocation. Following is the message body, if any.
- The following opcodes are supported:
- Client to server:
- `p` - Ping request. The core will always respond by ACKing with the passed identifier. No body.
- `i` or `h` - Command invocation. The message body is the command text without prefix. `i` requests machine-readable output, `h` requests human-readable.
- Server to client:
- `a` - ACK. The first message sent in response to any invocation (before any output). No body.
- `m` - Message. Sent once per line of output the server generates. Body = output line.
- `o` - OK. Indicates that the command finished processing with no errors. No body.
- `f` - Failed. Indicates that command processing is done, but there was an error. No body.
Expected overhead is minimal, and this integrates seamlessly with existing command scripts (no changes necessary).
PS: There's also a client-side addon library that exposes this protocol in a developer-friendly way over at https://github.com/azerothcore/LibAzerothCore-1.0
---------
Co-authored-by: Treeston <14020072+Treeston@users.noreply.github.com>
* refactor(Core/ObjectMgr): Handle Profanity & Reserved Names in load
* closes https://github.com/azerothcore/azerothcore-wotlk/issues/18556
* Update ObjectMgr.cpp
* Update ObjectMgr.cpp
* I swear I am not drunk
* We already check all of these
* fix build
* Forgot we dont send the responsecode in senderrormessage
* last commit I swear
fix(Core): Prevent gift wrapping of items with duration
- remaining duration is not beeing stored in character_gifts
- gift wrapping of items with duration preserved
them infinitely
* Class Comparison Logic Encapsulation - Parity
* Add Context to IsClass
* Add Unit IsClass script hook
* Replace additional getClass with IsClass
* Update CanUseItem to replace getClass with IsClass
* Add separate context for pet vs ability
* Change Create to Init since not all referenced contexts are creation
* Align spacing in ClassContext
* Drop context on LFGManager max power
* Update IsClass context that wraps around Missle Barrage
* Rename context for swapping weapons
* Be more specific than CLASS_CONTEXT_TALENT
* Remove duplicate context
* Moved IsClass Hook to Player
* Removed unused parameter in virtual base function
* Added maybe_unused to IsClass virtual in order to compile
To match the override signature, the virtual base needs to include the parameter in question, so using [maybe_unused] to signal to the compiler to allow it
* Remove extra blank line
* Add ABILITY_REACTIVE context
* Add context for PET_CHARM
* Remove explicit nullopt check per review
* Code Readability - Change if to if else in pet
Due to the return pattern, this doesn't change functionality in any way
* Add OnPlayer to disambiguate
---------
Co-authored-by: NathanHandley <nathanhandley@protonmail.com>
* Fix(Core/CharacterHandler): Incorrect behavior using an equipment set if it will result in a full inventory.
* Fixing the error message to -Equiment swap failed - inventory is full- like the Blizzlike error message
* Bug fixes
- Corrected std::chrono from seconds to milliseconds
- Got rid of leftover code that caused objects to not show up on time
* Removed logic to set gameobject as active
- More alignement with TC.
- Reduces CPU usage drastically
* Revert back to using time_t instead of std chrono
* Invoke SetNoCreate() method to reduce CPU usage drastically
* Remove setActive from static and motion transports
* Fix performance issues
* Added SetFarVisible to WG and some dungeon scripts
- Also removed setActive(true) from creatures in Wintergrasp. As for gameobjects they are set to active upon being damaged/destroyed and removed from active on rebuild (reset)
* Removed comments related to VISIBILITY_COMPENSATION
* Fix log
* Deleted unused files + corrected a check
* Added missing header
* Removed unused parameter
* Removed another unsued parameter
* Changed vector to set for i_visibleNow
- Changed vector to set for i_visibleNow in VisibleNotifer
- Adjusted HaveAtClient to accept Object*
- Adjusted SendUpdateToPlayer to send createobject packet only if not known to client
This situation occurs when, during a fight, a pet receives a command to apply a positive spell to an ally and then resume attacking its previous target.
