TheNomadMan
New member
- Joined
- Feb 8, 2014
- RedCents
- 451¢
As far as I can tell; Kissassist is attempting to cast multiple DPS spells (including GoM spells) without waiting for the 1.5 sec recovery period to expire.
This causes DPSOn=2 to cast out of order:
This will also cause the GoM spell to misfire, despite detection, and cause DPSOn=1 to skip spells it otherwise would have cast, at a given time.
Heal spells have a separate array of condition checks and are not affected by this issue. However; should a DPS spell attempt to follow a heal, the DPS spell fails and is skipped.
Locally, I have had the issue confirmed by two (2) other kissassist users. Furthermore; I have confirmed the issue, myself, on three (3) different machines in two (2) different locations. All three (3) of these machines have completely different hardware specs, all three (3) were running fresh EQ and MQ2 installs, and one (1) of them had a fresh win7 install. The tests were preformed with six (6) different characters (not including the other two previously mentioned user's chars) arrayed in a number of different configurations (tank, hunter, pullertank, assist, 2 chars, 3 chars, 3 chars w/ mercs) and were tested with several different ini's. The ini's were made by myself, by two (2) other kissassist users I know, and I tried a few ini's that had been posted to this board. I even used four (4) different versions of kissassist (7.2, 7.0.2, 7.0.1, and 6.8.8).
Results were the same every time:
I believe the problem lies here:
The following code appears to tell KA what to do "If the spell is ready and I am not a bard" as well what to do "If I am a bard" and then returns a result of CAST_SUCCESS or the previously /varset CAST_FAIL. But there is nothing to tell KA what to do "If the spell is not ready". Why KA is moving to CastWhat for spell casting during the recovery period, in the first place, may be more the issue here. I'm not experienced enough to say.
So: I injected a "If spell is not ready" help more clearly distinguish when KA is attempting to cast during the recovery period.
Here are the results:
This is true in every test I've run, on every machine I've run it on, and was confirmed by two other kissassist users.
No special circumstances are required to replicate this issue. Simply /debug with kissassist running and look for "CAST_FAIL" to occur more often than "CAST_SUCCESS", when attempting to cast DPS spells.
I don't know what else I can do to prove the existence of this bug or disprove the existence of a one-off configuration. If you can think any tests that I, or others, can run please let me know. I'll do my best to see to it.
In the mean time; please post here if you're seeing the same behavior I am.
This causes DPSOn=2 to cast out of order:
Rich (BB code):
[DPS]
DPSOn=2
DPSSkip=10
DPSInterval=2
DPS1=Sunbeam Blessing|99|MA
DPS2=Clutch of Ro|98|Once
DPS3=Surge of Spineburrs|97|MA
DPS4=Nature's Withering Wrath|96
DPS5=Summer Suncrest|95This will also cause the GoM spell to misfire, despite detection, and cause DPSOn=1 to skip spells it otherwise would have cast, at a given time.
Heal spells have a separate array of condition checks and are not affected by this issue. However; should a DPS spell attempt to follow a heal, the DPS spell fails and is skipped.
Locally, I have had the issue confirmed by two (2) other kissassist users. Furthermore; I have confirmed the issue, myself, on three (3) different machines in two (2) different locations. All three (3) of these machines have completely different hardware specs, all three (3) were running fresh EQ and MQ2 installs, and one (1) of them had a fresh win7 install. The tests were preformed with six (6) different characters (not including the other two previously mentioned user's chars) arrayed in a number of different configurations (tank, hunter, pullertank, assist, 2 chars, 3 chars, 3 chars w/ mercs) and were tested with several different ini's. The ini's were made by myself, by two (2) other kissassist users I know, and I tried a few ini's that had been posted to this board. I even used four (4) different versions of kissassist (7.2, 7.0.2, 7.0.1, and 6.8.8).
Results were the same every time:
I believe the problem lies here:
The following code appears to tell KA what to do "If the spell is ready and I am not a bard" as well what to do "If I am a bard" and then returns a result of CAST_SUCCESS or the previously /varset CAST_FAIL. But there is nothing to tell KA what to do "If the spell is not ready". Why KA is moving to CastWhat for spell casting during the recovery period, in the first place, may be more the issue here. I'm not experienced enough to say.
Rich (BB code):
/target id ${castTargetID}
/delay 10 ${Target.ID}==${castTargetID}
/if (${Cast.Ready[${castWhat}]} && !${IAmABard}) {
/casting "${castWhat}" -maxtries|2
| /call cast "${castWhat}" gem8 3s
/doevents
/varset CastResult ${Cast.Result}
/call CheckCasting 30
}
/if (${IAmABard}) {
/squelch /twist once ${castWhat}
/varset CastResult CAST_SUCCESS
}
}
/if (${WasTwisting} && !${Twist}) /squelch /twist
/if (${Debug}) /echo ${CastResult}
/return ${CastResult}So: I injected a "If spell is not ready" help more clearly distinguish when KA is attempting to cast during the recovery period.
Rich (BB code):
/target id ${castTargetID}
/delay 10 ${Target.ID}==${castTargetID}
/if (!${Cast.Ready[${castWhat}]}) {
/varset CastResult I_WASNT_READY
}
/if (${Cast.Ready[${castWhat}]} && !${IAmABard}) {
/casting "${castWhat}" -maxtries|2
| /call cast "${castWhat}" gem8 3s
/doevents
/varset CastResult ${Cast.Result}
/call CheckCasting 30
}
/if (${IAmABard}) {
/squelch /twist once ${castWhat}
/varset CastResult CAST_SUCCESS
}
}
/if (${WasTwisting} && !${Twist}) /squelch /twist
/if (${Debug}) /echo ${CastResult}
/return ${CastResult}Here are the results:
This is true in every test I've run, on every machine I've run it on, and was confirmed by two other kissassist users.
No special circumstances are required to replicate this issue. Simply /debug with kissassist running and look for "CAST_FAIL" to occur more often than "CAST_SUCCESS", when attempting to cast DPS spells.
I don't know what else I can do to prove the existence of this bug or disprove the existence of a one-off configuration. If you can think any tests that I, or others, can run please let me know. I'll do my best to see to it.
In the mean time; please post here if you're seeing the same behavior I am.
Last edited by a moderator:
