Server/DB queries can only happen as fast as the game engine can make them. Where do you think the cache would obtain its queries come from?? Lol.
If the server hardware is already 64 bit; 32 bit instructions are emulated, which causes a small slowdown. https://docs.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications https://stackoverflow.com/questions...t-or-is-that-something-handled-in-gli/1504345 so it should help a little to have true native executables.
I'm sort of suspecting that lag increased when they changed their backend systems a few months back. It's also not just on raids. I've noticed that when I finish casting a dot there's a small but noticeable time before the DoT icon appears on the mob in the target window. There are similar issues related to the displayed "Con" color in the target, or extended target (I can't recall which or if both) windows when a target is newly acquired. The name of the mob updates but there's lag between the correct Con color updating.
Please educate me how a database can send the data the game engine needs without queries. I'd LOVE to know, and so would every cloud provider on the planet.
Color me confused. It seems to be that the game server should be the only thing accessing the DB. The client should be talking to the server and the server talks to the database on behalf of the client.
It should also be obvious that the game engine is the weakest link between the database and endpoint. It's also obvious you would rather argue point-counterpoint than discuss the question. Incredibly, I fell for it once again.
If it was the game engine (aka client) then it would always be the same, not varying week by week. When everyone gets lag one week, and the next week no one does that indicates the server not the client. edit: unless by game engine you meant the servers then you would be right. Its them.
The game engine is being pushed harder than it ever has before. Not saying the Game Engine is the only bottleneck here, but it's a mighty large bottleneck. I see what you're saying regarding consistency. Database, Servers, and Game Engine all work together to make the game happen. You're right, there are more variables than just the GE to blame here.
"Game engine" does not generally mean game client. That's why in a client/server architecture we use the terms "client" and "server" to clearly state what we're talking about.
If you're going to tell us "thats not what it means" then why dont you tell us what it does mean? What does "game engine" mean to you?
Game engine means a variety of things to a variety of people. Given that, it's a rather useless term in and of itself. You could say that Unity is a game engine and be right. I could say it's the protocols between client and server, the database, the server AI, and the rendering system, and be right.
I was going by the apparent definition in the post that I was replying to. We can quibble about what terms he used, but he seemed (in his post and his followup) to be distinguishing between our side and their side - client and server.
What's there to discuss? EQ is very simple and they've already tweaked the data and limited the engine to unreasonable levels. That's why there's buff limits and and throttling of client requests, and proc nerfs, etc. They've specifically said they want to implement caching and that they narrowed performance issues down to things like those complicated procs that require a dumb amount of spell data lookups. It's not like the calculations don't happen instantly but overly complicated data structures would sure cause issues when dealing with an RDBMS and you can't blame the game engine for that. We know zone loading times are crazy slow cause of how they read character data excessively. Then you have things like how instances are loaded and managed. You get crazy amounts of lag in one instance and then zero if you get another. I guess some people equate game engine to mean all the softwares related to the game but that's silly.
Yesterday's Cleric: One CH every 13-30 seconds Yesterday's Rogue: One backstab every 4-5 seconds etc... Today's (insert class here) 4-12 multibinds every 1-5ms.
So spell lookups, buff limits, and proc data have nothing to do with the game engine. Perfect. Glad you cleared that up....silly talk, indeed.
Is the raid lag being discussed in any way shape or form related to the lag I see in some instances or places, like the group end of empire mission or the dragon caves in COV western wastes? Anyway back the topic, I am hopeful the 64 client will help, but I dont have much insight. I am a sw performance person among other things, however in any reasonably complicated system, there are numerous places where there can be bottlenecks, but to optimize all the pieces (each line of code...) is a recipe to make ROM code (read only code, write it once, cant change it later...). So the goal to improve performance should be to make the whole system as clear as possible - clean, clear logic, and then find the first performance bottlenecks (do performance analysis) and then optimize the things that will make the most difference (and are possible to be done). So where are the critical bottlenecks that people suspect that are causing the lag? DB? Server cpu? Server Memory? Client memory - this seems to what the 64 bit client would certainly help with, and this could be used to cache more information that would be going to/from the server. Perhaps server calls and client requests to the server could be sent in larger batches if the caches were bigger. Is part of the lag the display engine? (I believe this is part of what is being referred to as the game engine) and could caching more graphical textures, and data help? network bandwidth to/from client? Slow code execution due to large dated code base? Other ideas?
