Hi!
We are currently investigating this problem. Our current theory is that this could be related to the tactical overlay. It would be great to get confirmation that these problems only occur when the tactical overlay is enabled.
If it is unrelated to the tactical overlay, then it would be awesome, if you could try to capture such an incident with LogLite and then send the logfile to us with a bug report.
Kind Regards, CCP Habakuk
It is on HDD. But idk if there's a correlation there, since the game worked completely fine before the dx12 patch.
When I was playing around with seeing what I can do for performance the only thing that helped for some reason was verifying integrity of downloaded files and purging extra files (in the launcher). After I did that the game worked fine for about 3 days after which undocking became a massive problem again. Any attempt at verifying&purging after that didnt help at all anymore. Clearing cache didnt work either.
I should note that it is only a problem on the first undock, after that the game works fine. And that its an issue even if the system is empty.
Thanks for the description and that's a really odd issue. I checked with the relevant graphics programmer and he can also not explain this behavior.
It would be great, if you could try this on Singularity and see if it is improved there. Some of the file access should be reduced with our changes, so maybe you are lucky and this patch is indeed fixing / improving it. I will also keep my eyes open to see, if I can track anything down.
Yeah, I have had the same issues. Even in systems when no one else is even in local. Seems to be the worst with the first undock after logging in. Almost like the game still hasn't fully loaded into RAM.
Have you managed to figure out any details, like if it could be related to a slow disk?
Theres been a lot of threads on reddit since, a lot of my friends have the same issues, undocking has gotten so bad to the point that u get 1 frame every 5 sec, now obviously not everyone has this issue, but it is an existing issue for a lot of people
Edit: this started with dx12 update, and turning off dx12 doesnt help
https://www.reddit.com/r/Eve/comments/x56u60/is_anyone_else_experiencing_severe_lag_when/
One of the many threads since patch
Yeah, I have followed this thread and tried to reproduce this in-house, but without any real luck.
Did you manage to improve anything with it? Could it be related to disk speed? Is your EVE client on a SSD or HDD?
The real question is if this will fix the mega lag on undock problems since the dx12 update
Unfortunately I don't know, as I was not able to reproduce this mega lag. Some lag at undocking into a grid with many ships (like Jita undock) is expected, and this lag should be indeed reduced quite a bit by these changes.
EVE has sound?
I was already waiting for this one. :D
Hey!
We are planning a mass test on Singularity tomorrow, Tuesday, September 27th, at 17:00 UTC (= EVE time) to test several technical improvements to our audio and graphics engine, which should hopefully improve the performance in fleet fights significantly!
All the details on how to join and what we are testing can be found at https://forums.eveonline.com/t/mass-test-on-singularity-tuesday-september-27th-2022/377718
It would be great to see many of...
Read more External link →Ask the question 'will audio have ANY impact on performance in large scale fights?'
As long as the answer is yes (ANY impact), most people will turn it off.
All of these changes are frankly a waste of your entire team's time.
Every feature is having "some" performance impact, the question is just how much. Some players will disable audio anyway, and that's completely fine, but this change should help quite a bit for those players, who want to keep audio enabled in fights in general, but were afraid of the load. So maybe many fleets will still disable audio in real massive fights, but keep it on (with advanced settings) in more regular fights - and this would still be a massive improvement.
Our other performance optimizations in this release will help fleet fights very significantly on the graphics side, especially for loading grid and warping out, and the memory consumption of the client in fleet fights.
Does CCP collect stats for the amount of people that play with sound disabled? How about the number of people that play with everything but audio warnings turned off? If not, they should. “Eve has sound?” is a meme for a reason.
Yes, we collect stats for audio settings, although I can currently only see the stats for the checkboxes and not for the sliders.
Btw: The "Advanced Audio" settings are currently activated by a bit more than 13% of accounts, if I am reading the stats correctly, so this gives a hint.
Does photon still hide half your chat channels or does it actually resize the tabs yet?
I just checked this on Singularity and it resizes the chat tabs, but it activates the overflow menu slightly earlier than in the old UI, as the tabs need a bit more space (but there is not much difference). As far as I can remember this is now much better than earlier versions of PhotonUI - so it might be worth for you to check it out yourself.
Please don't include an Audio Enabled setting reset in the patch rollout. Some players prefer no sound, which is why we turned it off in 2004.
No worries. Audio settings are not touched with this patch. :)
Hey,
A late comment here, as I looked into the bug report from the OP.
Unfortunately I was not able to reproduce this problem in-house (at least by far not to this extent), although I tested on various machines (including on a slow HDD). According to the included logs in the bug report there were indeed warnings about it taking long to load files from disk. This could be due to either a very slow disk or also if the computer was completely lagged out already.
The June release has indeed increased the amount of data to be loaded from disk (like for example for the nebula and related to the LOD changes), although this should not have been as significant.
It would be great to get more details on this, if this is indeed caused by very slow HDDs. I assume switching to an SSD should indeed help quite a bit (as already mentioned in some comments). Otherwise it would be great to see how the CPU usage on the machine is during this. Is it completely maxed out?...
Read moreGreat that you could sort out your problems! There is some guidance also in https://forums.eveonline.com/t/test-server-singularity-faq-and-information/249925, but I'll see if we can improve the info somehow.
The next full sync (mirror) will probably happen in the middle of September.
From what the devs have said previously, the 1s server ticks are for physics stuff (entities moving) and some communication between the client and server, but not everything. Module activations in particular, as far as I know, are not bound to those ticks at all. So the HP just is tracked continually, guns subtracting from it each time they cycle and reps adding to it each time those cycle, both of those happening whenever their module cycle times dictate rather than being tied to ticks, and the ship just dies if the HP ever hits zero. Again, afaik.
Correct, as far as I can tell. The server tick does not affect this order. So in minorVulpes' specific case it depends just on the cycle duration - and to a small amount on the network latency to the server, as the module only starts as soon as the server received the command.
If the server is getting really busy then the server might take slightly longer to process the events, but the order should still be mostly intact. In the past (several years ago) the server prioritized under lag accidentally events, which were coming from clients over modules, which were already cycling. This caused FCs to tell fleet members under lag to use single activations of their weapons and avoid cycling - which then caused even more lag. This should no longer be the case now and all module events should be handled the same.
As far as I can tell all such effects from modules are being evaluated on whatever happens first (either is first in the reactivation queue, reaches the server first - at least as long as the server is not overloaded like in 10% TiDi, when it becomes a bit non-deterministic) and the ship dies whenever the health reaches 0. If the damage is first, then it dies, if the rep is first. then it lives. This calculation is not based on ticks, but some of the messages are only sent out to the clients together with the next destiny tick.
Read moreHey,
Yeah, having 2000 bookmarks active in a single system is indeed a bit much and this is known to cause performance issues. I investigated this a bit when working on shared bookmarks, and I think we also managed to include some improvements, but unfortunately we could not address more. Unfortunately the sensor overlay is just not made to handle as many objects - and the same thing would happen with a high amount of anomalies.
I'll try to see next week if I might find anything, which we could improve easily, but from past experience I am afraid that this would all require extensive code changes.
For workarounds: Would it be doable for you to split the bookmarks into several subfolders and only enable those on the sensor overlay, which you are currently working with? Yes, the action of enabling a (sub-)folder takes some time, but it might still be better than keeping them all enabled all the time.
A video should not be necessary here - I know wha...
Strike the 1000 in the last paragraph - I did some tests with the max amount for a shared folder (3000), as I was concerned that it could be abused for hostile purposes (link to a very heavy bookmark folder in local and hope that the other side gets lagged out).
Read moreExcuse me, but because I can ask you directly, I'm doing so. It's, I guess, tangentially related to the issue at hand.
I have 2000+ bookmarks in Hek. My fps is cut to a third, just because they exist. I don't even have to be on grid with them.
Turning them off and on depending on usage isn't an option, because it causes my client to freeze for longer than is acceptable. Jumping gates is especially painfull, but at least the invulnerability timer nowadays only starts when my pod's actually fully loaded.
Thank you for that, by the way.
I've discovered that the "mouse hover function", when hovering over space, causes the client's fps to go down. My fps go down over space, but they go up when I move the mouse over the overview or any other window. They don't go up to a value they should have, but not hovering space is beneficial for fps and reacting.
Can you please fix that? It's like the mouse-movement function checks every object for intersecti...
Hey,
Yeah, having 2000 bookmarks active in a single system is indeed a bit much and this is known to cause performance issues. I investigated this a bit when working on shared bookmarks, and I think we also managed to include some improvements, but unfortunately we could not address more. Unfortunately the sensor overlay is just not made to handle as many objects - and the same thing would happen with a high amount of anomalies.
I'll try to see next week if I might find anything, which we could improve easily, but from past experience I am afraid that this would all require extensive code changes.
For workarounds: Would it be doable for you to split the bookmarks into several subfolders and only enable those on the sensor overlay, which you are currently working with? Yes, the action of enabling a (sub-)folder takes some time, but it might still be better than keeping them all enabled all the time.
A video should not be necessary here - I know wha...
Read moreIndeed in heavy tidi fights the GPU barely needs to work. This is because the game gets highly CPU bound during such encounters. And the less frames your CPU can send out the less frames need to be rendered --> GPU usage drops to nearly nothing.
Most of EVE's application are single thread, so you should see a load of about 1/6 ~ 17% since you got a hexa core CPU. If the EVE process uses those 17% its most likely that one of your CPU cores is working at 100% capacity (this unfortunately is often not reflected in the task manager).
This explanation is pretty spot-on, at least as far as I understand things (and I have done quite a few measurements). Most of the game client logic is indeed single-threaded, with the exception of some parts of the engine.
As others here mentioned sound: On such a beefy machine sound should have quite little impact when running a single client. Nearly all of the audio load is actually in a separate thread, so it should be processed on a separate core and should normally not affect the fps of your client. This looks a bit different on old CPUs with less than 4 cores and when multi-boxing - then audio has much more of an impact on fps. But it is still a good idea to test it out yourself in your specific situation.
While brackets have been mentioned already, which have indeed a quite heavy impact, the overview can also slow down the client quite a bit, if it has many object listed. It can make sense to check this with a completely empty overview tab. I also recommend...
Read moreHey! I haven't filed a bug report myself but it's the same issue described here https://www.reddit.com/r/Eve/comments/wkev43/temporary_fix_for_something_unexpected_came_up/
Hey! A fix for this bug is also already incoming.
Hi!
I can confirm that we are aware of this bug and several bug reports are attached to the internal ticket about it. We are normally not replying, when attaching bug reports to an internal ticket, but I think that you should be able to see, that the bug report is attached (if it has been correctly handled).
devtrackers.gg