Heavy slowdown at the Water Production zone on Kodiak map
rkfg
Russia Join Date: 2013-09-03 Member: 187744Members, Reinforced - Supporter, Reinforced - Silver, Reinforced - Gold, Reinforced - Diamond, Reinforced - Shadow
Russia Join Date: 2013-09-03 Member: 187744Members, Reinforced - Supporter, Reinforced - Silver, Reinforced - Gold, Reinforced - Diamond, Reinforced - Shadow
I recorded two plogs there: first and second. Both seem to be wasting time at FileSystem::OpenFile for some reason. When there are many players at that zone, the game becomes unplayable. It's not a caching issue since it happens every time I get there, not just the first time. There are places where lags don't occur, but they happen at the res point when you look at the marine base entrance.
Comments
For me to track this issue down for you by looking at the level files I will need screen shots with r_stats active, please take them when looking in the direction where its bad etc.
IF you can recreate this issue on a private server then I would turn cheats on and type r_wireframe, and again take some screen shots, this will allow me to work out what is being rendered etc
It would also be useful to know your system specs and the graphics settings you use to play the game. In addition to this, is it specific servers that cause this or all ? The more information the better it will help me.
I will also ask that one of our programmers have a look. However this is not a promise as they are very busy.
Summon me back with @Loki when you got your info as I often dont check the tech forums
1) The screenshots. 60+ FPS is ok, 20-25 is bad and laggy as hell, I've captured both situations at the same location, sometimes looking just a bit to the side makes FPS much better. The slowdown is stable (i.e. not random and tied to the position and look direction) if I look back at the same direction as before, it drops just like it did before.
2) My specs are in the signature: Intel Core i7-2600, 32Gb RAM, NVIDIA GeForce 770 GTX driver v340.46, Debian Jessie GNU/Linux amd64, Awesome WM 3.4.15, kernel v3.17
3) Graphic settings are on the minimum, except textures which are on High and Reflections turned on. Texture handling is on 1.5 Gb. I don't have FPS issues on other maps and at other areas on Kodiak.
4) This happens on any server I've played. These particular shots were done on a local sandbox server.
Thanks for your help!
I imagine this can only be fixed with code
I could not replicate the file opens in that location, but I'm on a Windows x64 system, which may be the difference here... my guess, considering that the same number of files are being opened all the time, is that there are one or more model files that fails to load on linux. Shader incompatibility, most probably... in which case it will be easy to fix once we know the name of the files being loaded.
1) the command is probably just f_critlog, if I add anything as a parameter it answers "Critical thread file logging disabled". If I enter it without parameters, it says "Critical thread file logging enabled".
2) Either way I have nothing about files in the log. I enabled this command after getting to the problematic zone. I've tried p_logall but there's also nothing about files there.
BTW, there's a big hole in that area, it was passable in the first map release and then was patched. However, I can see through it as a skulk: http://imgur.com/a/n5M0z FPS drops when that hole is near the screen center but it's not directly connected. When it's on the side of view (but still visible) FPS may be nice. I suspect some geometry can't be rendered but why the FPS drop gets away when I see it but not look at it directly?
Also could you snag a profiler screenshot in that same location you were getting 50 ms wait times? (the first screen)
Thanks
I did it for both aliens and marines to rule out the possibility that it only happens to aliens. Nope, looks identical.
On a side note, forum image uploading sucks, it doesn't show thumbnails and inserts images with HTML tags instead of BBCode. I have to convert them with
Mmm... I misremebered how the f_critlog behaves ... simpler to just turn on complete filesystem logging.
Try "f_log" instead. "f_log" to turn on, "f_log off" to turn off.
Some holiday/workshop files are constantly opening when looking there.
It's interesting because without mods the slowdown is almost negligible but it's still there, and there's nothing in the f_log at that time. There are, of course, many other file access lines when the map is being loaded and a bit after the game start and the first evolving. It looks like precaching doesn't cache really everything, so a couple of hitches right after the start is explainable. But when I have FPS drop there's nothing in the console and the log file. The OpenFile call in the render thread is still there though. So, why mods make it this heavy? Mu guess is because of the virtual filesystem the game builds in the runtime. It mounts mods directories over each other and hence when it tries to open that mysterious unknown file it has to traverse not only the main data directory but also all the mods ones. I noticed that logic is now put into a zip file so this should be much faster than reading the native FS due to keeping the zip dir structure in the memory completely. Here's the screenshot of the profiler running without any mods:
I'm also attaching the log file. I went to the WP Zone with and without mods turning them on and off, so there are several sessions in one file.
As it shows, the problematic file is (drumroll!) /seasonal/holiday2012/models/xmas_rock_mid_str_128.model.
Which is missing. I have no idea what that file should do at that place, probably cork that nasty hole. Now the strange part: the file actually exists and looks well BUT strace shows that the filename has a redundant period in the end. And probably that's it. That dot should be removed wherever it's referenced in the map and things should go well after that.
PS: opening files in the render thread is a bad idea anyway, spare our framerates, please!
But because it fails to load it then, it will then try to load it when it is needed - ie, on every frame when you are looking in the wrong direction. Which is kinda silly, but then, files should not fail to load. And when they do fail to load, they should say so at least once. You would think... :-(
@matso I understand this logic but unfortunately (and I've learned this the hard way being a programmer myself) assuming that something "should not happen" often result in the most cryptic bugs. Because it, well, happens. Probably it should drop a big fat warning to the log that some resource wasn't found (it's a critical thing I suppose that may allow to use wallhacks or other cheats) and mark it as unavailable somewhere in a hash table. If a file isn't found now it's not gonna be found later I suppose. Even better to somehow include this situation into the consistency check procedure to catch these errors early so that the player or mapper would verify their game cache or fix the error in their map. I mean, if the resource file should be there but was not found, the game should not allow me to play, right?
I printed the model and origin of every model on load and it is where the tunnel is apparently, which is nowhere near water production,
On Linux, however, there are no such restrictions except that you're not allowed to have 0x00 char and '/' (slash) in the filename (true for Windows as well). Everything else is allowed until it fits in the max filename length.
Probably, Windows just drops the period in the end of the filename as it looks like an empty extension. I've tried this on a virtual machine and it seems to be true. Try it yourself: notepad c:\autoexec.bat — opens that file. Then try notepad c:\autoexec.bat. and get the same file opened. So while the filenames are indeed completely different from the technical point of view, some OSes silently modify them to their liking. I personally very against this as it leads to sorts of hidden bugs like this one and while it doesn't reveal itself on Windows, it's still a bug. Like, if you write a crossplatform software and add the time to some filenames like cache in the form of "HH:mm:ss" and colons are prohibited on Windows so your cache doesn't actually work there (and causes slowdowns) but works on Mac/Linux. A clumsy example, yea, but it shows what can happen.
I think that it acts that way to simplify modding. The game can apply changes to some resources on the fly.
is...actually at -6201.18; 105.89; 535.66. (Didn't think to consider the meter>inch conversion).
But as expected... the model path for the model in the editor is "seasonal/holiday2012/models/xmas_rock_mid_str_128.model."
this fix will be in 272