Prior to this update, if you spammed an on-gcd ability while combat assist is running, you'd 'override' the ability that combat assist would have chosen. IE if you spam Fire III while the CA routine wants to cast Fire I, you'll cast Fire III. However that no longer seems to be the case, and now while CA is running it locks your other gcd abilities. I'm wondering if this was an intentional change or a byproduct of something else, as its can be pretty annoying. There's a couple of spells that I prefer to manually use, like bard songs, and now I have to detarget everything in order to do so, or more importantly, turn songs off. In fact if you're in the middle of a cast and then target something, the CA will interrupt your cast to use its own ability. If it comes down to it I'll edit the routine to add in hotkeys for the songs, but I wanted to ask about the purpose of this change first and if it can be reverted. Also seems to be harder to place waymarks while CA is running.
Yeah it was pretty much intentional. Mastahg talks about it in the release update thread and I have to admit I'm not a huge fan either. Technically it should result in a dps increase, but in practice the difference is basically nothing. It would be much nicer if cancast returned false if you already queued an ability like for the example you stated where you want to use a song where the cr would not. Maybe I will make a thread somewhere more appropriate like the dev forum to discuss ways around it.
Yeah I guess I was looking it it the wrong way and never really bothered to learn how the queuing system works until a couple minutes ago. Can we somehow lower the cancast cooldown timer from 500ms to something shorter like maybe 50ms? With it set how it is now it's basically impossible to cast anything other than what the combat routine might do next since once an ability is queued there's nothing you can do to override it, and there's no window to queue something manually before a combat routine can. Having it at 500ms rather than something shorter poses no benefit but presents a big disadvantage.
Sorry, I'm a little confused as to how this helps us. Can using cancast return the previous functionality? Are we supposed to add cancast as a conditional to every spell now? If the change is in cancast, then why is it affecting the routine when I'm not using cancast? Sorry if those seem like dumb questions; I read the release thread and still don't really get it, and I'm not really sure I see the purpose either. It seemed to be casting fast enough before anyways.
This was an intentional change to allow sequences to be used to allow buffs then directly after a damage spell. The previous functionality will not be returning. If your using kupo then cancast has been used forever.
Couple other things; certain abilities that have a long animation and take time to register, can get double cast because the second one is queue'd up before the first one finishes. This does require a significant amount of skill speed, but its really obvious as a Monk, using Dragon Kick with GL3. In that instance it happens most of the time, depending on latency and idk what else. It happens with Demolish too, although since you can't normally double cast Demolish its only an issue if you have PB up. Also, Limit Break seems to always get interrupted by the routine now, so I have pause it in order to LB. Didn't buffs and other off-gcd abilities already get used after damage spells before? I don't really see any dps increase compared to before this change, and if that was the reason it doesn't seem at all worth the half dozen other, significant things it breaks.
We don't just insert things into ff14s queue, we use the same function as if you pressed your keys. If spells are going off then youll need to adjust the code or start posting some logs. QQ No, theyd wait 1.5 seconds.
What Combat Routine are you using? Kupo/Magitek are supposed to have built-in "Double Cast Protection" (I believe it has something to do with the system clock and waiting a maximum of 3 seconds or something like that). It's optional (at least in Magitek it is) so it may need to be enabled for the skills you're experiencing issues with. For MoreDots I've been having to put in manual waits such as "await Coroutine.Wait(5000, () => Core.Player.CurrentTarget.HasAura("Thunder", true, 3300));" which forces the CR to wait a maximum of 5 seconds before attempting to cast that spell again (in reality it waits a couple seconds until the aura "Thunder" appears and moves on).
I'm not talking about the queues, and I don't think the code's the problem since it worked fine before. The difference is that since the CA now decides the next ability much earlier, sometimes it does so before the current one finishes and is registered, so the routine picks the wrong next ability. I've never noticed them waiting that long. Using Magitek I'd get off 2-3 off-gcd abilities between my regular attacks, and there certainly wasn't a 1.5 second delay. I guess maybe Kupo was different, but idk its good design to ignore the routine that everyone uses to help the one that's honestly kind of a joke. Sure, you can just go 'qq', but the fact is that when you create a paid product, your customers will expect a certain level of quality and performance. I respect all the work that you've put into this solo project, but when there's a design decision that doesn't make sense to the end-user, there's going to be legitimate concern. I'm not really a coder, so maybe more knowledgeable people can see benefits to the change that outweigh what it broke. The issue highlighted is indeed small, and perhaps there's something that I'm doing wrong on my end, but it does stack with all the other problems. Dismissing it out of hand, to me, is a very unprofessional way to run a business. I tested it in both Magitek and Kupo. In Magitek I did fix it by turning on the double cast prevention argument, but then it just did Bootshine after DK instead. I'm not really sure what to do next, if there's some way to tie the two spells together in the DCP system. I wasn't aware that Kupo had that system, and if its built-in and non-optional, then its certainly not working.
Ok, here's a clean log. Idk how much it helps; just lists the spells used. View attachment 444 2014-10-03 01.44.txt Its ok before GL3, after it'll double cast DK maybe 30% of the time. I'd imagine it can be higher or lower depending on my skill speed, buffs, and latency.
Hrm interesting. Monk is going to require a little bit extra logic because they are the only class that doesn't use combos. Time to power level a monk I guess.
Here's the thing.....Mastahg doesn't give a shit if his latest CanCast changes breaks other Combat Routines. The Buddy Company paid LastCoder to come "Revamp" Kupo. I'm sure that this change was due to a request by LastCoder for something he's trying to implement in his rework. Mastahg has made it very clear that 3rd party Combat Routines are not supported, so why would he care if he breaks one. His "QQ" attitude towards his customers is why he is perceived to have such a "holier than thou" attitude by most of the 3rd party developers that actually make things for this bot. It's really no use arguing with him any further as he's already stated . I'm not sure on all the classes as I've only had time to try my Summoner, but I know it broke my Summoner Rotation with this change. We'll see how long it takes to finish after I finish refactoring the code to make MoreDots handle class changes without having to restart RebornBuddy.
Monk isn't the only class that doesn't use Combos, BRD doesn't either. Though monk is the only Melee class that doesn't.
I care quite a bit about 3rd party developers, infact thats how I started with the buddyteam, writing a custom class for honorbuddy then questbehaviors and now my own bot. I've gone through great efforts when writing the api to provide things in a simple efficient matter. I didn't think that the changes to cancast would break anything as I failed to take into account monks and bards. So I am reverting the change until I can get monk leveled so that I can do testing with it.
Wouldn't it be a lot easier for you and more beneficial to everyone to just add an argument to whatever to enable/disable queuing so that situations like what you mentioned can use it and situations like what we have brought up don't have to?
