stgatilov

I have deleted them in the core script recently. They were not used in any released mission. I have suggested a trivial replacement to the author in the beta thread.

I think you can find the breakpoint in the code and check the full path of the file. Probably this file exists somewhere. No, such a file does not exist in assets repo and in the mission repo.

There are weird black bars when starting the Download Missions screen on 21:9. They disappear when the list of missions show up. UPDATE: Fixed in svn rev 17575.

dev17570-11349 is available.

Recently @covert_caedes has ported an extension for GUI system from dhewm3, which allows to customize how GUIs are scaled depending on the window/screen aspect ratio. The newest dev build (dev17570-11349) already contains a lot of customizations, so you may notice differences with aspect ratios like 21:9 or 4:3.

Can't say anything certain. There is the well-known trigger that turns large shadow map lights into stencil shadows, in which case alpha-testing does not work. Aside from that, I don't think there is any special cases for alpha-tested shadows.

The same happens if you execute "kill Streetwalker", and will probably happen on any map for any AI that is completely removed from the game. Your threads holds entity reference and uses it all the time, and when the entity dies we get this warning.

Ultimately, it depends on how serious the necessary changes are.

dev17562-11331 is available.

I booted into Inn Business FM and got these warnings: WARNING:script\tdm_ai_head_tracking_humanoid.script(245): Thread 'ai_darkmod_base::updateHeadTrackLoop': Tried to call function on non-existent entity (#805) WARNING:script\tdm_ai_head_tracking_humanoid.script(246): Thread 'ai_darkmod_base::updateHeadTrackLoop': Tried to call function on non-existent entity (#805) WARNING:script\tdm_ai_head_tracking_humanoid.script(245): Thread 'ai_darkmod_base::updateHeadTrackLoop': Tried to call function on non-existent entity (#805) WARNING:script\tdm_ai_head_tracking_humanoid.script(246): Thread 'ai_darkmod_base::updateHeadTrackLoop': Tried to call function on non-existent entity (#805)

I recall that body awareness was considered at the very beginning, and was rejected. It feels like one of those cases where and idea might sounds cool, but doing it now would go against the original design of the game.

Don't remember. But yes, if these arms were working fine at some moment, then it's probably some of these "hacks" that are responsible.

It still can. If GPU driver (its user-side part) corrupts memory, I guess it can break memory allocation for the program.

CRawBuffer is a small class that I wrote as my first contribution to TheDarkMod around 15 years ago It is only used for saving/loading the game, so I assume you got the crash during that moment? But seriously speaking, I'm not very confident we can catch this. I had some sporadic crashed in memory allocation routines on my PC, but I never managed to track them down. If there is something wrong, it can crash / not crash depending on TDM version and maybe even Windows update... And somehow I doubt it has anything to do with GPU drivers, GPU is not used during game save/load. As a first step, you can try to record a crashdump. There is one detail though: since don't get a real crash. If you see the special blue screen, then you get a "fatal error". If you set cvar "com_error_crash 1" in game console, then all fatal errors would convert into instant crashes, and in this case you can record a proper crash dump. This cvar is internal, it does not persist on game restart. If you need some time to reproduce the bug, then you can add the line "com_error_crash 1" into autoexec.cfg in the directory with TheDarkMod.x64. You can execute "com_error_crash" in-game to check if it got the proper value.

A small comment from me. I used to run missions with "Very High" LOD setting, because architecture modules LOD switches in New Job look awful to me. I have not seen much FPS difference depending on LOD settings anyway, but maybe it exists on a few specific maps. Now that I have added "Full" LOD, I'll just run it Unless lower LOD is needed for testing.

Yes. Do you use executable from assets SVN or an executable built locally from source code? I usually don't commit newly built executables between dev builds. I'd say test maps look better inside "test" subdirectory, maybe delete the first one.

Yes, now it looks more like what a horse should see As a matter of fact, I have fixed the issue with animation stutter/jump in the latest SVN.

I have changed to exponential growth in svn rev 11323. You will still have these same stutters, but they will happen very rarely. In fact, increasingly rarely: the time between stutters doubles every time. So it won't bother you so much.

Okay, I think the reason is that the game saves the complete history of game console in memory r_showprimitives generates a lot of spam, basically 300 lines per second on 300 FPS. So after 5 minutes you have 90000 lines of text in memory. Also, the addition of the new line to the history uses the original method Append instead of the AddGrow I added. While AddGrow doubles array size on every reallocation, Append only adds constant granularity on every resize, which is in this case 1024. So e.g. every 3 seconds the history hits the new 1024N size and reallocates completely, having to copy the whole history again. And one of the reason why this history is saved is condump. So we can't just drop older lines...

I can finally reproduce it! It seems that printing to console generates some memory reallocations...

Could you explain how exactly do you start the map? I tried adding "map iris" in autoexec.cfg, it does not work for me.

Yes, I see that every second or so everything in the game stops by 15-30 ms.

I think yes. I tried to enabled r_showprimitives, it does not change anything. Maybe you can record your session in Tracy?

These are also pretty radical suggestions for weaker GPUs, I believe.

Some of the things you are suggesting are targeted at very weak GPUs, RX 6600 should have no problem at all with 64-bit colors, volumetrics, parallax, and I just set LOD to full with same GPU. But I suggest changing max FPS to something like 300. With Vsync on, it won't render faster than Vsync anyway. When you have max FPS = 60, the game forces 16.6666 ms waits between frames. Since timing are never exact, it means that you get missed frames occasionally.