Update 5/15/2023 - New Bugs Only

Have you tested the system yet? Assuming it spawns with an invulnerable flag and not a "cannot cast on this" flag like a PoK mob it would not be reaction based, and more based upon who made the correct assumption.

Additionally for stuff like autoattack, since you CAN turn that on an Invuln or "cannot cast" - it would be completely serverside for the determination.

I basically explained it already but for more detail, the way I see race scenarios is that the most likely case is that both people will basically be on top of the mob and the instant the mob appears they will both be spamming some spell or insta-clicky they have for just this occasion. The timer after the mob spawns until it becomes vulnerable will likely be more than virtually anyone's ping so those pre unlock clicks or whatever will be registering at various times just before or just after the unlock. Attacks that hit BEFORE the mob unlocks won't count so it will be more down to which attack registers first or which person standing on the mob the mob notices first. Ping is rarely going to play a role. The only scenario where it could is for a cheater who knows the timer and has the attack automated. That's assuming the unlock point doesn't have a ~500ms or so random element.

Auto attack? I'm just assuming that everyone is spamming their insta-click items like Staff of Temperate Flux.

If ten wizards are spamming their staff, the one with the lowest ping will win.

You're never going to win a tag race by using auto-attack when everyone is spamming their insta-click items.

Yeah, you're right.

Autoattack is determined serverside not client side - ping is 100% irrelevant for those pre-targeted and autoattacking.

I was just going to let them both dig deeper and they didnt disappoint.

I've been coding IP apps at the socket level since I was but a wee pup. You seem unable to understand simple logic and causality so I feel I'm wasting my time, but, I'll give it one last go -->>> As long as all competitors for the tag have packets arriving at the server before the FTE unlock happens, ping will not matter. So, because there is a delay before FTE unlock, after visibility, the first packets will start arriving at the server from ALL contenders BEFORE the FTE unlock happens, that's the only thing that matters. I dunno, maybe you missed the announcement that mobs won't become attackable for a moment after they become visible? When they become visible everyone will start sending packets, because they will almost certainly be visible for more than this hypothetical 350ms before the unlock occurs, ping will not matter. Are you getting this now? If not, sorry I can't help you.

Well, New Ui went to live, having an issue with how they grab to other windows in some cases ( IE. Quantity window goes to grab window edges ( windowed mode) and it's fine. However goes to grab inventory window and maintains a space between the two that you can easily see through).
Now Might not be for everyone, however I try to minimize those spaces as much as possible to give myself more viewing area. Even if a smaller window and a temp one. I use 11 Hotbars and keep a lot of other windows up. Space is valuable hehe. Plus trying to lock say the inventory window and each time I hit lock, it moves a little, keeping it out of alignment.
On another avenue. This is happening to me and some guildies and friends: Opening and closing bags keeps flickering the screen.
Seems the font is a bit different, honestly looks a little sloppy compared to before. It's just off enough to be noticeable, But some letters / numbers can look bold at times as compared to others, while Dex's E looks crunched, in fact many look squished a bit. in all honesty this looks... not to criticize, just sayin' ... sloppy. Tried the UI scaling thing in display tab as well. Doesn't help with these issues.

Bug: The new UI, just simply the entire thing.

Why would you decide to push this mess to the live servers when it simply DOES NOT WORK ?

And that useless LayoutConverter ? What is the point of that ? It can't even convert your own default UI!

There's going to be a bit of randomness to which packet wins for aggro. Packets will be streaming in from both clients while the mob's lock is ticking down. The winner would be which packet came in first after the unlock. Even if one client has the faster ping, that doesn't necessarily mean that their ping will always win. A packet from the slower client may be the one which happens to land right after the unlock. Chances are the faster packets will win in the long run because there will be more of them getting to the server in a given time, but it doesn't necessarily guarantee that they will always win.

Yeah, you're right. I was being dumb.

If everyone is spamming at the same frequency and the mob is up for more than 350-500ms or so before being unlocked, everyone will have a more or less equal chance at getting the tag.

My apologies. You were correct.

Yeah I had to apologize to Zrender because I was being dumb lol.

You are both correct and I was just being a dummy.

No worries, mate. To be fair, it's not something that's immediately obvious. The delay after visibility is what likely balances it. We'd have to know more about the EQ protocol and how player actions are queued (client or server) to really know all the exact effects of 2 players with different pings spamming actions.

You can search online for documentation and repositories of early versions of their 'event driven' network architecture. It's the basis for some popular emulation servers. I'd reckon Live EverQuest and say p99 are probably not too far apart these days, but the repos should give plenty of insights.

Yeah, I recall browsing through the code back in the day. Probably totally different now. Not sure if it's anything like live though. I know one of the SWG emus (controversially) actually uses what was live SWG code that got into the wild somehow but I don't recall anything like that happening to EQ. The main question would be if the player actions are queued client or server. They're probably queued somewhere because if your connection drops for a few seconds you're still able to do some things that happen all at once when the connection is restored. If the queue is on the client then low ping would have an advantage in spamming actions, if it's on the server then ping would probably only effect the first action (which is negated by the fte unlock delay).

I'd say server-side in some sort of messaging bus.

How the servers determines which messages to process first is a mystery though, but probably some hybrid First-In, First-Out way. I wouldn't be surprised if they had logic to process messages in fast batches in an asynchronous fashion.

Even if there's no ping-related bias, is contesting spawns by having one person spamming a clicky on a mob any better than dps racing with a group? The cost to entry seems to be less under the encounter locking system.

Considering it encourages people of higher levels to grief lower level camps. And stack DPS to intentionally KS others etc.

I used to challenge myself to solo difficult named as a cleric back in the day (long before TLPs even existed - GoD era or so) - and it was annoying as hell when someone would roll up and KS something from me that I was actively challenging myself with the terrible DPS my melee and nukes did during those pre-VoV times.

Almost every class gets some sort of instant/near instant pretty early on - most with short range (i.e. taunt/kick) and most others with something quick (like tash) with range. And of course bows/throwing.

Frankly, I could see the mechanic making throwing for those that are vying for competed for camps more used on casters and such than ever before.