How the "lag" looks like. On the image below, we have a LS raid encounter. Xtended target has boss and adds. They are slowly going down in percentage. When they die on my screen, experience is granted. Problem is that the event is already over, and Boss + adds are dead. Loot is being distributed via chat channel. The staggered event goes on for another 5-10 minutes until I finally catch up. I had 2 clients in the event (mage + SHM) and I only experienced the lag with the mage. Next event, logged the SHM and still had the issues with the Mage. Used a VPN, got disconnected. Reconnected and Lag was gone. If i hit a spell gem, its greyed out for a couple of minutes. No apparent delay in global chat channel (se image), but /GU, /tell and /group /achievements etc corresponds with event percentages and is lagged. My system : Processor 13th Gen Intel(R) Core(TM) i5-13600K, 3500 Mhz, 14 Core(s), 20 Logical Processor(s) BaseBoard ProductPRIME B760M-A WIFI Installed Physical Memory (RAM)32.0 GB NVIDIA GeForce RTX 4060 Ti Game is unplayable. Please fix. P
Have same issue here. Turning off log caught me up and seemed to fix it for me, but this fix does not work for everyone.
really insane lag moors of nokk: what is it for? i5-12400 cpu 16GB DDR4 AMD RX 6700 XT GPU B660M DS3H AX DDR4 motherboard EQ installed on SSD /log off did not fix edit: on our 2nd try I did not click epic, and I had zero lag. Night and day difference
13th Gen I9-13900KF 3.00 GHz 32 GB ram Nvidia RTX 4080 16 GB Vram Only thing in the machine is an SSD /log off stopped the ridiculous lag, but that's not tenable. As an aside, blaming the users system, when what I see from most of these posts are decent machines isn't it.... No problem playing much newer games with more intense graphic demands, BG3, Harry Potter, Elden Ring, etc zero issues. EQ since the hotfix, devastating terrible gameplay experience.
After making a number of settings changes recommended by various folks and turning off logging of anything that wasn't necessary for raiding my lag problem appears to be fixed.
Thanks for your efforts getting this fixed! It's been a bit of a bumpy road ever since the DX11 update. But you've always been on top of making changes quickly and responding to feedback. Raid tonight ran smooth as butter - no lag or spell gem lockouts, no stuttering when adds spawned. Good job
Came to report the same as Xyroff. Raided on Vox last night, T1 and T2 raids ran smooth in LS. We will run T3 on Sunday and hoping it runs smooth as well. We also tested out Myconid Mutiny in NoS and all the npc spawn hitching/lag was gone. We were able to do the Crystal Crusher achievement for the first time since the DX11 update. Thank you for your diligent work!
I would like to give a useful answer to this question, so let's cut to the chase. This topic is about game client processing throughput. Let's leave hardware bandwidth and Windows OS aside, as I only want to make a couple of recommendations about eqclient.ini settings that players can change that would be beneficial in most circumstances. ClientCore# - Change all instances of this variable to "-1" to use all CPU cores. It's okay if you don't have any of these lines in your eqclient.ini file too. The reason is because a positive value can reduce performance by restricting available CPU. Lowering performance like that can increase lag. You don't want that. For example: ClientCore0=-1 ClientCore1=-1 ClientCore2=-1 ClientCore3=-1 MaxBGFPS - This value should be lower than MaxFPS. The default value is "9" and it's fine if you're playing a single client. However, this impacts players who are boxing multiple game clients and using ALT+TAB to switch between windows. The client(s) that are in the background are allowed to run as slowly as this value (e.g. 9Hz). Many players are aware of this settings as it impacts (lags out) the pathing of the /follow command. For this topic, a low value here means that the background clients get less processing time and lag out more than the foreground client. If you're multi-boxing, increase the value of this variable to "59" or "32". For example: MaxFPS=150 MaxBGFPS=59 MaxFPS - This value needs to be higher than MaxBGFPS. The default value is "150", meaning unlimited and that let's the client run as fast as it can. There's not much need to change this value (see above). If you're boxing you might have set a lower value of e.g. "60" (60Hz) for each client. For example, a multi-boxer might have these settings for each client to target 60Hz frame rate and insure that there's minimal lag and your boxed characters follow better: MaxFPS=60 MaxBGFPS=59 I hope this information is helpful even beyond the subject of this topic.
Cairbrae, Thank you for the information. I do have some thoughts. I'm sure you are aware that having players edit text files on their computers is not the optimal way to have them make adjustments. However, until/unless in-game options exist, this is far better than nothing. Your answer seems to be it is best to have nothing here as the default takes care of it. If people want something, they can put -1 for as many cores as they want but really, just put nothing. If for some strange reason they want to have clients go to specific cores, they can but you don't recommend it. MaxBGFPS = Maximum BackGround Frames Per Second. If you go into the game itself (even though this is about editing eqclient.ini) under Options > Display > Advanced this option exists as Max. Background FPS. A slider there goes from Min. CPU to Unlimited, with numbers between. I'm going to assume this is exactly the same as the eqclient.ini setting, in that changing this slider in-game will change the numbers for the eqclient.ini. I'm also guessing that "Min. CPU" in-game equals 9 in the eqclient.ini file. MaxFPS - Maximum Frames Per Second. Again, in-game Options > Display > Advanced under Max. Frames Per Second. This slider moves between 10 and Unlimited. I would guess that Unlimited = 150 in eqclient.ini. Your answer is leave this at unlimited unless boxing (optional). I hope so also. I'll try to update my https://everquest.fanra.info/wiki/Graphics_and_performance_settings_guide as best I can. Thank you.
Yes. The default value is "150", meaning unlimited I wouldnt word it as "unless boxing (optional)", rather "if boxing and have reduced performance" else it may be interpreted as being mandatory when boxing.
Thanks for adding clarifications. Here's an example of bad 2-box settings that would be impactful to this topic: ClientCore0=0 ClientCore1=2 MaxFPS=150 MaxBGFPS=9 These settings limit the number of CPUs available to each client and allow the background client to run as slowly as 9Hz. This setup is probably going to experience more lag then it would otherwise. Please consider ClientCore a legacy setting that had its place prior to Windows 10 or DirectX 11. It could be deprecated, or revamped again, in the future.
I think it's worth adding context in support of Cairbrae's incredible efforts behind the scenes, having worked with him in providing a lot of scenario testing and feedback and seeing things get done. Cairbrae's goal in his response here is to provide tangible adjustments that end users can actually make in the interim, that are likely critical to the crux of substantial problems some are having. Him providing .ini adjustments does not mean developer(s) are suggesting it should only be up to end users to make their own adjustments. It also does not mean they aren't making substantial improvements in the backend code. It's just simply a speed-to-market response in providing tangible adjustments that will help some people out in the interim, or with ini-based issues that are not easily solvable through other means in the near future. Cairbrae/dev team have made substantial DX11 code improvements that directly improved NPC load-in hitching--a very fundamental aspect of the game impacting raiders, casuals, and people PLing in Frontier Mountains with 100 mobs spawning every 2 minutes (imagine the lag previously). The impact is monumental across everyone playing the game. They have also made significant improvements to baseline hitching through the memory.ini file and advanced in-game settings that drives it.
The proper implementation of multithreading and/or hyperthreading would absolutely relate to reducing bottlenecking on NPC spawn-in hitching. Less capable PCs would be further exacerbated if all cores aren't being utilized properly. Cairbrae is providing simple, tangible, speed-to-market-oriented suggestions for anyone who is still having substantial hitching that shouldn't be. There is a scenario in which user(s) could still have .ini's with improper settings, and are overlooking the most obvious settings. Again, this does not mean that Cairbrae and the devs aren't making substantial improvements to backend DX11 code over the last two months (which they have), or are suggesting that the only option are for customers to edit file settings themselves.
As a person who can operate their pc and can trouble shoot and use in internet to help fix stuff but still doesn't have a good grasp on code and how stuff all ties together, Cairbrae's post was super helpful in helping me at least make sure my stuff was set correctly and hadn't been changed when trying to make changes in settings to try and fix all these issues through the game. It was nice to see all the settings the devs have listed how they should be set for optimal playing have been set correctly already. Letting me know at least it shouldn't be issues on my end.
I think the main problem is that many people did not realize that when they artificially cap the FPS, that the game processes messages slower. So when they're alt-tabbing to another everquest that the super low background fps option makes their game fall behind. Could you please give us an extra option/toggle to multiply the messages per frame to process the same as 60 FPS (or 120 FPS?), when we set the FPS Cap Lower? I think this would fix a lot of the issues people are having. Most people use the FPS cap so the GPU does not get tied up, but most people have extremely powerful enough CPUs where extra message processing likely does not matter.
Not likely, its been said they originally tied the client clock to the frame rate. Its why you fall faster with a lower frame rate. Changing this would likely be a huge rewrite.
What setting causes 3 minute tell lag after completing a raid while the achievements and raid currency are awarded? Because that is most definitely not on the client side.
Feedback after the fix - raids on sunday were back to minimal levels of lag and working as expected! thanks again.
