The aura that I use in the mod consist of cycling two EOCs together every X seconds
tl;dr:
eoc_1 checks for conditions and if true, runs eoc_2 (if false it stops), eoc_2 then checks for another set of
conditions and if true, queues eoc_1 after X seconds (if false it stops)
Separating each of these conditional sets allows handling independent things like low mana, low stamina,
not wearing an item , etc. simulaneously while having independent messages from each other
This is working properly at the player level (i.e. these stop where they should, they don't crash, they don't kill you, no lag is evident, they do what they're expected to do)
However, they do have an "under the hood" issue due how queue_eocs works. This is exemplified here:
When the aura is activated, it will add +1 to var_check. If the aura is activated again (to toggle it), it will set it to 2. Then, eoc_1 will be false and set var_check to 0. However, because there's already a queued eoc_1, and var_check is 0, this queued eoc_1 will always run eoc_2. The extra stop condition marked above then detects this (it will run ONLY if it's 1), and doesn't queue eoc_1 anymore, thus finally stopping the cycle.
While again, this works, it is annoying I have no standard for things like messages (some are printed from effects, other from the X_toggle EOC, sometimes I have no option and the STOP message runs twice, etc.) and I have the feeling this could break at any moment
The aura that I use in the mod consist of cycling two EOCs together every X seconds
This is working properly at the player level (i.e. these stop where they should, they don't crash, they don't kill you, no lag is evident, they do what they're expected to do)
However, they do have an "under the hood" issue due how
queue_eocs
works. This is exemplified here:When the aura is activated, it will add +1 to
var_check
. If the aura is activated again (to toggle it), it will set it to 2. Then,eoc_1
will be false and setvar_check
to 0. However, because there's already a queuedeoc_1
, andvar_check
is 0, this queuedeoc_1
will always runeoc_2
. The extra stop condition marked above then detects this (it will run ONLY if it's 1), and doesn't queueeoc_1
anymore, thus finally stopping the cycle.While again, this works, it is annoying I have no standard for things like messages (some are printed from
effect
s, other from theX_toggle
EOC, sometimes I have no option and the STOP message runs twice, etc.) and I have the feeling this could break at any moment