Core/Spells: Fixed work of sobering spells and other improvements for drunk system. #29745
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes proposed:
The first commit related to
SPELL_EFFECT_INEBRIATE
(100) effect. The problem is that there are not only inebriation but also sobering spells (with basepoint < 0). The current implementation uses an unsigned type, ignoring sobering spells. This leads to a uint8 underflow, resulting in the spell's behavior being completely unexpected: it can both inebriate and sober you up.Example:
.gobject add temp 185914
There is another problem: there are spells with an inebriate effect with basepoint values so large or small that it inevitably leads to uint8 overflow/underflow. For example,
29690
or46874
. As intended,29690
should make you extremely drunk, but in reality, the behavior can be unpredictable each time. If someone keeps casting this spell on you again and again, you will likely notice that sometimes you get drunk and sometimes you sober up.The first commit completely fixes this issues.
The second commit is related to the aura effect
SPELL_AURA_MOD_FAKE_INEBRIATE
(304). The main problem is that the handler of this effect ignores the value of player's actual inebriation. In any case, there was a lot of redundant (duplicate) code here. Now the logic for updating invisibility detect has been moved to a separate method, and all known issues have been fixed.Tests performed:
Builded and tested in-game.