Has this every happened to anyone? I am not sure if it was an error on my behalf or some kind of bug, but I have had this happen to me a couple of times were my spell will be cast on my previous target even though spell queue is turned off. I would say that I noticed this happened between 4 and 6 times.
Spell hitting previous target /noqueue enabled
Started 30 Aug 2019
by
vxr
in
RvR
Sat 31 Aug 2019 8:20 AM
by
maxmad
I have that issue as well while buffing. Tbh I was blaming it on lag as it does not happen every time.
I also noticed that I am doublecasting spells. I press or click the button once, spell gets cast twice.
I also noticed that I am doublecasting spells. I press or click the button once, spell gets cast twice.
Mon 2 Sep 2019 10:29 AM
by
gruenesschaf
gruenesschaf
As dev I can say it shouldn't happen, as player I can say it never happened to me but 1 person in my group was complaining about it for a couple days but also added "uthgard had the same bug" which makes me believe the bug is in front of the monitor :p
Lag also shouldn't affect it as even if you're lagging, the packet order should be preserved (targeting something sends a packet, using an ability does too). While the entire server is now heavily multi threaded and actions from different clients / players even in the same region are processed concurrently (hello 2 players slamming each other at the same time), packets of a given client / player are still processed sequentially meaning it's not possible for the ordering to somehow change (ie client sends target change packet then ability, the server in that case will never process the ability packet before finishing the target packet)
Lag also shouldn't affect it as even if you're lagging, the packet order should be preserved (targeting something sends a packet, using an ability does too). While the entire server is now heavily multi threaded and actions from different clients / players even in the same region are processed concurrently (hello 2 players slamming each other at the same time), packets of a given client / player are still processed sequentially meaning it's not possible for the ordering to somehow change (ie client sends target change packet then ability, the server in that case will never process the ability packet before finishing the target packet)
Mon 2 Sep 2019 11:25 AM
by
majky666
I remember this bug from server, what don't exist anymore, Genesis, where i played mentalist.
Tue 3 Sep 2019 11:17 AM
by
Golota
happens very often to me too. have someone in the target, nuke on him, change the target, cast my bolts and the first bolt goes to the previous target. meanwhile, i always wait at least a second after changing the target until i cast my bolts. rather supoptimal.
Tue 3 Sep 2019 1:58 PM
by
gotwqqd
Maybe your network connection?
Tue 3 Sep 2019 2:21 PM
by
Liah
Try playing a Skald. It has happend to me many times. Id mezz a target, target the next, use my dd and hit the first target out of mezz. First few times i thought i may have not clicked the netxt target correctly but no ... i did change
Tue 3 Sep 2019 4:17 PM
by
chewchew
maybe the people who have this issue frequently can set up a game recording?
With a recording a reason on the players-side could be ruled out and maybe it could help the devs if there is an issue.
With a recording a reason on the players-side could be ruled out and maybe it could help the devs if there is an issue.
Tue 3 Sep 2019 7:37 PM
by
Freedomcall
Actually this happens not only on spell queue, but also on /stick.
I have multiple times changing target and /sticking right away, which resulted in sticking to previous target.
So, I also wait like a second before sticking/casting spells on new targets like someone mentioned above.
I have multiple times changing target and /sticking right away, which resulted in sticking to previous target.
So, I also wait like a second before sticking/casting spells on new targets like someone mentioned above.
Tue 3 Sep 2019 9:36 PM
by
RiffRaff
Can confirm, happens on my shaman quite a bit. Rather frustrating when i disease a tank then switch to a druid/bard/cleric/caster to root and my root lands on a det9 tank...
Wed 4 Sep 2019 12:22 AM
by
gruenesschaf
gruenesschaf
Please someone record it happening, bonus points if the combat log is included. Also interesting would be if it only happens when using f8, only mouse click or regardless of how the target was selected.
Wed 4 Sep 2019 12:29 AM
by
gotwqqd
Is it possible that some information packets get delayed in transit?
Target changed
Packet A sent with target switch.
1/2 second passes
Command to attack
Packet B is sent with attack command
Packet A is lost or delayed in transit and arrives after packet B
Target changed
Packet A sent with target switch.
1/2 second passes
Command to attack
Packet B is sent with attack command
Packet A is lost or delayed in transit and arrives after packet B
Mon 9 Sep 2019 1:32 PM
by
HibRanger
Countless mezzes gone to wrong target, countless assist gone to the wrong target. In my guild all know about this bug.
Had nice action in discord by times we did not knew about this and blamed on the mezzbrakers .)
On Uthgard didnt had this bug.
Cant confirm by the f8 targets, but by clickable targets it happens very often. Cant be the Lag issue since somtimes there like 1-2 seconds between those two clicks.
Had nice action in discord by times we did not knew about this and blamed on the mezzbrakers .)
On Uthgard didnt had this bug.
Cant confirm by the f8 targets, but by clickable targets it happens very often. Cant be the Lag issue since somtimes there like 1-2 seconds between those two clicks.
Mon 9 Sep 2019 11:19 PM
by
gruenesschaf
gruenesschaf
gotwqqd wrote: ↑Wed 4 Sep 2019 12:29 AMIs it possible that some information packets get delayed in transit?
Target changed
Packet A sent with target switch.
1/2 second passes
Command to attack
Packet B is sent with attack command
Packet A is lost or delayed in transit and arrives after packet B
Those are TCP packets and hence guaranteed delivery and guaranteed order as they were sent.
Tue 10 Sep 2019 5:55 PM
by
vxr
gruenesschaf wrote: ↑Wed 4 Sep 2019 12:22 AMPlease someone record it happening, bonus points if the combat log is included. Also interesting would be if it only happens when using f8, only mouse click or regardless of how the target was selected.
Just had it happen to me again. Reviewing the recording I see what happened. So I mezz an enchanter's pet and then I click on the enchanter, but my cast hits the chanter's pet. I had to watch it frame by frame to see why. I notice that even though my target box has "Lurikeen" the combat log does not register it as fast. I start casting my spell and then the combat log shows that the luri was targeted.
Please see screenshots.
First picture is frame 1 - I just switched to Luri target by clicking (not nearest target you can see my mouse hovered over the target), but the combat log does not show that the luri has been targeted.
Second picture is the following frame - Shows that I started to cast and then switched targets, but that is actually out of order.
Frame 1
Frame 2
Tue 10 Sep 2019 5:59 PM
by
chryso
I really like your compass.
Tue 17 Sep 2019 10:49 AM
by
Tritri
Thanks for that report, I also have had this issue
Thu 7 Nov 2019 6:34 PM
by
vxr
/bump
This happened to again yesterday and once a two weeks ago or so. It's frustrating because when this happens I usually get killed because I end up breaking my own mezz.
This happened to again yesterday and once a two weeks ago or so. It's frustrating because when this happens I usually get killed because I end up breaking my own mezz.
Fri 15 Nov 2019 10:57 PM
by
Liah
/bump happend to me today again 
Fri 15 Nov 2019 11:35 PM
by
gruenesschaf
gruenesschaf
If the occurrences are as in vxrs images, meaning the client shows the new target as selected but there is no target message until after the cast start, there isn't really a lot we can do as it looks like the client is literally sending the cast packet before the target packet which is at the very least unexpected. All packets sent by the client are processed sequentially therefore if the client actually sends the target change packet before the cast packet this would be impossible, out of order processing is also impossible as this is using the tcp protocol which guarantees that the receiver will see the packets in the same order they were sent in.
Just to emphasize, this is literally not fixable on the server, while we could do looking ahead in the pending packet queue and process target messages right away with some somewhat major technical difficulty, this would potentially cause issues the other way around while at the same time not even fixing this issue reliably as once we start processing the cast packet the cast basically immediately starts and even if we start processing the target packet a millisecond later the cast may already have started with the previous target, here it would be luck based what kind of timing you get.
The only possible work around on the server side would be to add some artificial delay before each and every style / cast packet which would however impact the responsiveness / feel and who knows what delay we need there.
Just to emphasize, this is literally not fixable on the server, while we could do looking ahead in the pending packet queue and process target messages right away with some somewhat major technical difficulty, this would potentially cause issues the other way around while at the same time not even fixing this issue reliably as once we start processing the cast packet the cast basically immediately starts and even if we start processing the target packet a millisecond later the cast may already have started with the previous target, here it would be luck based what kind of timing you get.
The only possible work around on the server side would be to add some artificial delay before each and every style / cast packet which would however impact the responsiveness / feel and who knows what delay we need there.
Sat 16 Nov 2019 12:03 AM
by
Liah
Hm, yeah i see the problem. Oh well, thanks for the reply though 
Mon 18 Nov 2019 7:08 PM
by
vxr
gruenesschaf wrote: ↑Fri 15 Nov 2019 11:35 PMIf the occurrences are as in vxrs images, meaning the client shows the new target as selected but there is no target message until after the cast start, there isn't really a lot we can do as it looks like the client is literally sending the cast packet before the target packet which is at the very least unexpected. All packets sent by the client are processed sequentially therefore if the client actually sends the target change packet before the cast packet this would be impossible, out of order processing is also impossible as this is using the tcp protocol which guarantees that the receiver will see the packets in the same order they were sent in.
Just to emphasize, this is literally not fixable on the server, while we could do looking ahead in the pending packet queue and process target messages right away with some somewhat major technical difficulty, this would potentially cause issues the other way around while at the same time not even fixing this issue reliably as once we start processing the cast packet the cast basically immediately starts and even if we start processing the target packet a millisecond later the cast may already have started with the previous target, here it would be luck based what kind of timing you get.
The only possible work around on the server side would be to add some artificial delay before each and every style / cast packet which would however impact the responsiveness / feel and who knows what delay we need there.
I appreciate your response. At least I know I should abandon this cause. Any idea why the client would send my actions out of sequence? Is their anything you can think of that I can do to prevent or reduce this from happening from my side? Other than waiting to see that the target has been changed in the combat logs.
Thank you
Tue 19 Nov 2019 8:30 AM
by
Siouxsie
gotwqqd wrote: ↑Wed 4 Sep 2019 12:29 AMIs it possible that some information packets get delayed in transit?
Target changed
Packet A sent with target switch.
1/2 second passes
Command to attack
Packet B is sent with attack command
Packet A is lost or delayed in transit and arrives after packet B
Well, DAoC uses tcp ports, so TCP packets will get retransmitted and reordered, but if your connection
is bad it may retransmit a few times, by that time the server will have been updated but your client will
not have gotten the packets yet.
It would be worse if the game used UDP, where packets can just get silently dropped.
(Most early games were UDP, like Doom, Quake, etc)
This topic is locked and you can't reply.
Return to RvR or the latest topics