daemonengine / daemon Goto Github PK

View Code? Open in Web Editor NEW

293.0 19.0 58.0 26.03 MB

The Dæmon game engine. With some bits of ioq3 and XreaL.

Home Page: https://unvanquished.net

License: BSD 3-Clause "New" or "Revised" License

Shell 0.69% CMake 2.77% Python 0.24% C++ 73.76% C 17.89% GLSL 4.63% ShaderLab 0.02%

quake-engine c-plus-plus game-engine game-development opengl openal bsp glsl idtech3 xreal

daemon's Introduction

Dæmon

Dæmon is the standalone engine that powers the multiplayer first person shooter Unvanquished.

Windows	macOS	Linux

ℹ️ We provide ready-to-use downloads for the Unvanquished game on the Unvanquished download page, builds of the Dæmon engine are included.

ℹ️ The repository of the source code for the game logic of Unvanquished can be found there.

Workspace requirements

To fetch and build Dæmon, you'll need: git, cmake, and a C++14 compiler.

The following are actively supported: gcc ≥ 9, clang ≥ 11, Visual Studio/MSVC (at least Visual Studio 2019).

Dependencies

Required: zlib, libgmp, libnettle, libcurl, SDL2, GLEW, libpng, libjpeg ≥ 8, libwebp ≥ 0.2.0, Freetype, OpenAL, libogg, libvorbis, libopus, libopusfile.

Optional: ncurses.

MSYS2

MSYS2 is the recommended way to build using MinGW on a Windows host.

Required packages for 64-bit: mingw-w64-x86_64-gcc, mingw-w64-x86_64-cmake, make
Required packages for 32-bit: mingw-w64-i686-gcc, mingw-w64-i686-cmake, make

Downloading the sources for the game engine

Daemon requires several sub-repositories to be fetched before compilation. If you have not yet cloned this repository:

git clone --recurse-submodules https://github.com/DaemonEngine/Daemon.git

If you have already cloned:

cd Daemon/
git submodule update --init --recursive

ℹ️ If cmake complains about missing files in libs/crunch/ folder or similar issue then you have skipped this step.

Build Instructions

💡️ Instead of -j4 you can use -jN where N is your number of CPU cores to distribute compilation on them. Linux systems usually provide a handy nproc tool that tells the number of CPU core so you can just do -j$(nproc) to use all available cores.

Enter the directory before anything else:

cd Daemon/

Visual Studio

Run CMake.
Choose your compiler.
Open Daemon.sln and compile.

Linux, macOS, MSYS2

Produced files will be stored in a new directory named build.

cmake -H. -Bbuild
cmake --build build -- -j4

Linux cross-compile to Windows

💡️ For a 32-bit build use the cross-toolchain-mingw32.cmake toolchain file instead.

cmake -H. -Bbuild -DCMAKE_TOOLCHAIN_FILE=cmake/cross-toolchain-mingw64.cmake
cmake --build build -- -j4

Running a game

ℹ️ On Windows you'll have to use daemon.exe and daemonded.exe instead of ./daemon and ./daemonded, everything else will be the same.

To run a game you would need a pkg/ folder full of .dpk files provided by the Dæmon-based game you want to run. This pkg/ folder has to be stored next to the daemon binary.

You then run the game this way:

./daemon

If you want to run a dedicated server, you may want to use the non-graphical daemonded server binary and start a map this way:

./daemonded +map <mapname>

Map names and other options may be specific to the game.

daemon's People

Contributors

Stargazers

Watchers

daemon's Issues

predator cloak bug

During yesterday's community game, tvezet talked about a rendering bug he experienced (quotes from in-game talk):

illwieckz: hi tvezet :-)
tvezet: hi
tvezet: is it a known bug that entities as buildings or player arent shown correctly if there are flames or pulse rifle shots? it looks pretty much like the predator camouflage
illwieckz: that bug looks to nothing known
illwieckz: can you take screenshot of that?
tvezet: yes ill try
tvezet: did some screenshots of that
tvezet: combined with framerate dropping badly
tvezet: 11fps

tvezet taken some screenshots and reported the bug on forum:

After several failed attempts to run the game on debian wheezy i have finally installed an ubuntu 16.04 and now the game is running fine with more or less constant 60fps.
However sometimes it drops to about 20-30fps or even less and entities like players and buildings disappear leaving something looking like the emptiness outside the map. It often occurs when there is much stuff around and every time someone uses a flame thrower or pulse rifle.
Some sreenshots:

Any suggestions how to solve this?

Brightness adjustment broken on Intel Sandybridge on Linux

Currently cannot adjust the brightness/gamma of any openGL application (mostly games), such as Minecraft, Open Arena, CSS, Doom, etc.

R_LoadDDSImage: unsupported FOURCC 0x33545844

Dæmon fails to load some Xonotic textures, here is an example:

Warn: R_LoadDDSImage: unsupported FOURCC 0x33545844, "dds/models/desertfactory/textures/misc/grass01.dds"

You can find the file there: grass01.dds

Note that crunch is able to convert this dds file back to tga without complaining so perhaps we can rely on crnlib for dds files too?

weird lightmap pattern

Do you see that weird pattern on top of the crate on the right of this screenshot (latest master build)?

I noticed this pattern is also visible when all textures are missing except lightmap (this one is chasm):

When compiling some old random commit (like the 78db328 one), this is more obvious:

The bug seems to be related to lightmap rendering. Even if it's not very noticeable on current master it's still there. Of course it's not obvious like on the third screenshot but with special lighting condition and some view angle you can notice it.

Move some repositories from @Unvanquished.

Hello, if you did not see it already, please have a look at Unvanquished/Unvanquished/issues/837.

sv_privateclients does not require sv_privatePassword to be set

I just spawn a server with sv_maxclients set to 4 and sv_privateclients set to 2 and 4 non-private clients can join.

minimap bug

Formerly reported as Unvanquished/Unvanquished#1007

See this video, the minimap does not rotate properly.

The bug was introduced by commit 78db328

debug message about missing sound file not displayed

I noticed it while working on #165, it looks like there is code to display a debug message about missing sound file, but I see nothing displayed.

Daemon/src/engine/audio/SoundCodec.cpp

Line 105 in be89425

audioLogs.Debug("Sound file %s not found.", filename);

How to reproduce:

run engine this way: ./daemon -set logs.logLevel.default debug
play a non existent sound this way: /playSound meh

IPC: Unsound handling of bools

The IPC serialization code assumes that any POD type can be communicated by simply copying the memory. This is a problem if not every possible sequence of bytes represents a valid value.

In particular, the assumption opens the possibility of sending spooky bools which behave as true in some contexts and false in others, or have values other than 0 or 1 after an integer promotion.

Of course it's easy to make a specialization for bool itself, but bools in structs pose much more of a problem. There are various large structs which are serialized by copying, some of which contain bools. Maybe we would need some static analysis to prevent any bools from being added to them.

broken skybox when one of the face have a different size than the others

This a bug I first faced while porting maps from Tremulous for my InterstellarOasis initiative. At this time I workarounded the bug by modifying the skyboxes, but it's just a one-shot workaround and not a fix.

So, what's the issue? Sometime some skyboxes have one face with a different size than the others, usually the bottom one is smaller since it's unseen from the player point of view because of the floor of the map itself. Quake3 mods looked to rely on this trick to save file space (especially when pictures where shipped uncompressed and bandwith was low).

Have a look at the alamo skybox by Joe Kari from Smokin' Guns:

The skybox rendering is broken:

To reproduce the issue it's possible to download some preview dpks of Smokin' Guns assets this way:

wget -O- http://gg.illwieckz.net/dl/smokinguns/dev/SmokinGunsAssets.get | xargs wget

and load the dm-alamo map this way:

/set g_neverEnd 1
/devmap dm-alamo

There is no such issue in idtech3 derivated games like Tremulous or Smokin' Guns so this looks to be a regression (it can even predate Unvanquished if introduced by XreaL/ET:XreaL, I don't know).

Pixelated high contrast map lighting.

From Unvanquished/Unvanquished#1010:

Screenshots:

Here's map where it happens (I needed to put pk3 in another zip to stop github from complaining):

map-tremtest_1.0.pk3.zip

For me this bug happens on 0.50. @illwieckz says that he has this bug on master.

Crossposting it here since it looks like a postprocessing issue to me.

pure white line artifact on edges

This is a weird behavior we can see on some different use cases:

lines because two edges are rendered very near even if they are on different depth, note that in some condition (and angle) the lines can be red or other colors:

lines on surfaces junction:

LAN server not visible on Windows 10

Matias on Facebook told me he is not able to see his Unvanquished 0.50.0 LAN server while running Windows 10. This is what he did:

create a LAN server on computer0
start a client on computer1
go to the LAN browser in computer1: no server is displayed

He posted this video.

He said he both tried to run a sever from the client GUI and as dedicated one.

broken water translucency on station15 map

See the waterfall and the pond (two different shaders):

Note there is also a problem with depth:

This is a third and similarly broken translucent water shader:

engine is looking for irt_core-x86_64.nexe nacl_helper_bootstrap and nacl_loader in libpath

I noticed that the engine build system is building irt_core-x86_64.nexe, nacl_helper_bootstrap and nacl_loader in engine's build path, but the engine runtime is looking for them in libpath (i.e. the game's build path).

Basically, if you don't build the engine as a submodule (which is handy to not mess with it), you get this file layout:

Daemon/build/daemon
Daemon/build/nacl_loader
Daemon/build/nacl_helper_bootstrap
Daemon/build/irt_core-x86_64.nexe
Unvanquished/build/cgame-x86_64.nexe
Unvanquished/build/sgame-x86_64.nexe

But the game currently expects this layout to run properly:

Daemon/build/daemon
Unvanquished/build/nacl_loader
Unvanquished/build/nacl_helper_bootstrap
Unvanquished/build/irt_core-x86_64.nexe
Unvanquished/build/cgame-x86_64.nexe
Unvanquished/build/sgame-x86_64.nexe

Aren't engine things these nacl loader, helper and core nexe? Wouldn't makes more sense to have the engine looking for them in engine directory?

The issue does not occurs on default build scenario (engine as submodule) because the build directory is common, but it's a legit usage for an user to only build the engine (for example if he needs engine fixes only) to load a prebuilt vm, and in this case the user would have to copy the nacl/core nexe files from the engine build directory to the directory where he extracted the prebuilt vm (or the directory where the updater extracted the game). To me it looks better if the engine looks for those nacl loader, helper and core nexe in engine directory to not have to mess with game files.

depth sorting issue on lightmap renderer

there is a depth sort issue when rendering multiple translucent objects, the bug is related to lightmap since the textures are correctly sorted when lightmaps are not rendered, and incorrectly sorted when lightmaps are rendered.

without lightmaps:
with lightmaps:
without lightmaps:
with lightmaps:

crash once station15 map is loaded

Running Dæmon's current for-0.51.0 branch and Unvanquiqhed's riprepeater branch (from Unvanquished/Unvanquished#1062) and latest packages I get a crash while loading station15 map.

If you want to reproduce you can get the latest paks this way (repeater was removed in those paks that's why it's better to use the riprepeater branch to not pollute the logs with unrelated errors):

wget -q -O- http://gg.illwieckz.net/dl/unvanquished/dev/UnvanquishedAssets.get | xargs wget

You can get a crashdump and some symbols there.

This is the backtrace:

Operating system: Linux
                  0.0.0 Linux 4.15.0-16.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 4.15-10.1~sid (2018-04-10) x86_64
CPU: amd64
     family 21 model 2 stepping 0
     1 CPU

Crash reason:  SIGSEGV
Crash address: 0x5553751bb170
Process uptime: not available

Thread 12 (crashed)
 0  cgame-native-dll.so!CM_TraceThroughLeaf [cm_trace.cpp : 1487 + 0xe]
    rax = 0xffffffff855d3278   rdx = 0x000055555fa6e790
    rcx = 0x0000000000000007   rbx = 0x00007fff77feed90
    rsi = 0x00007fff961a7990   rdi = 0x00007fff961a7984
    rbp = 0x00007fff7faa3780   rsp = 0x00007fff961a78a0
     r8 = 0x00007fff961a7afc    r9 = 0x0000000000000021
    r10 = 0x00007fff961a78e0   r11 = 0x00007fff961a78fc
    r12 = 0x00007fff75cf6b58   r13 = 0x00007fff961a78e0
    r14 = 0x0000000000000000   r15 = 0x0000000000000021
    rip = 0x00007fff7e40e93e
    Found by: given as instruction pointer in context
 1  cgame-native-dll.so!CM_Trace [cm_trace.cpp : 2297 + 0xc]
    rbx = 0x00007fff961a7ac4   rbp = 0x00007fff961a7b70
    rsp = 0x00007fff961a78d0   r12 = 0x00007fff961a7ab8
    r13 = 0x00007fff961a7ad0   r14 = 0x00007fff961a7af0
    r15 = 0x0000000000000021   rip = 0x00007fff7e410024
    Found by: call frame info
 2  cgame-native-dll.so!CM_TransformedBoxTrace [cm_trace.cpp : 2420 + 0x3d]
    rbx = 0x00007fff961a7af0   rbp = 0x00007fff7eb0a698
    rsp = 0x00007fff961a7a60   r12 = 0x00007fff961a7f44
    r13 = 0x00007fff961a7ac4   r14 = 0x00007fff961a7ab8
    r15 = 0x00007fff961a7cd0   rip = 0x00007fff7e410669
    Found by: call frame info
 3  cgame-native-dll.so!CG_ClipMoveToEntities [cg_predict.cpp : 204 + 0x37]
    rbx = 0x00007fff7e86f830   rbp = 0x0000000000000000
    rsp = 0x00007fff961a7bf0   r12 = 0x00007fff7f704e78
    r13 = 0x0000000000010001   r14 = 0x00007fff961a7da0
    r15 = 0x0000000000000001   rip = 0x00007fff7e313887
    Found by: call frame info
 4  cgame-native-dll.so!CG_Trace [cg_predict.cpp : 270 + 0x21]
    rbx = 0x00007fff7f705f7c   rbp = 0x00007fff7f705f88
    rsp = 0x00007fff961a7d50   r12 = 0x00007fff961a7f50
    r13 = 0x00007fff7eb0a698   r14 = 0x00007fff961a7f44
    r15 = 0x00007fff961a7da0   rip = 0x00007fff7e3139cf
    Found by: call frame info
 5  cgame-native-dll.so!PM_GroundTrace [bg_pmove.cpp : 3092 + 0x22]
    rbx = 0x00007fff961a7f50   rbp = 0x00007fff961a7f44
    rsp = 0x00007fff961a7e20   r12 = 0x00000000000005aa
    r13 = 0x00007fff7f703e58   r14 = 0x00007fff7eb0a220
    r15 = 0x0000000000000001   rip = 0x00007fff7e39e414
    Found by: call frame info
 6  cgame-native-dll.so!PmoveSingle [bg_pmove.cpp : 4948 + 0x5]
    rbx = 0x00007fff7f705ea0   rbp = 0x00007fff7faa1860
    rsp = 0x00007fff961a7fd0   r12 = 0x00000000000005aa
    r13 = 0x00007fff7f703e58   r14 = 0x00007fff7eb0a220
    r15 = 0x0000000000000001   rip = 0x00007fff7e3a0335
    Found by: call frame info
 7  cgame-native-dll.so!Pmove [bg_pmove.cpp : 5073 + 0x5]
    rbx = 0x00007fff7f705ea0   rbp = 0x0000000000000042
    rsp = 0x00007fff961a8060   r12 = 0x00000000000005aa
    r13 = 0x00007fff7f703e58   r14 = 0x00007fff7eb0a220
    r15 = 0x0000000000000001   rip = 0x00007fff7e3a1c7a
    Found by: call frame info
 8  cgame-native-dll.so!CG_PredictPlayerState [cg_predict.cpp : 982 + 0xc]
    rbx = 0x00007fff7f705eea   rbp = 0x0000000000000003
    rsp = 0x00007fff961a8080   r12 = 0x00007fff7eb0a220
    r13 = 0x00007fff7f703e58   r14 = 0x00007fff7eb0a220
    r15 = 0x0000000000000001   rip = 0x00007fff7e314814
    Found by: call frame info
 9  cgame-native-dll.so!CG_DrawActiveFrame [cg_view.cpp : 1895 + 0x5]
    rbx = 0x00007fff7faa3260   rbp = 0x00007fff961aaa10
    rsp = 0x00007fff961a8340   r12 = 0x0000000000000000
    r13 = 0x00007fff961aaa30   r14 = 0x00007fff7eb0a220
    r15 = 0x000000000000001a   rip = 0x00007fff7e348bf8
    Found by: call frame info
10  cgame-native-dll.so!VM::VMHandleSyscall [cg_api.cpp : 92 + 0x5]
    rbx = 0x00007fff7faa3260   rbp = 0x00007fff961aaa10
    rsp = 0x00007fff961a84e0   r12 = 0x0000000000000000
    r13 = 0x00007fff961aaa30   r14 = 0x0000000000000000
    r15 = 0x000000000000001a   rip = 0x00007fff7e2bdd08
    Found by: call frame info
11  cgame-native-dll.so!CommonInit [VMMain.cpp : 66 + 0x5]
    rbx = 0x00007fff961aaaa0   rbp = 0x00007fff961aab20
    rsp = 0x00007fff961aaa20   r12 = 0x00007fff7faa3260
    r13 = 0x00007fff961aaa30   r14 = 0x0000000000000000
    r15 = 0x000000000000001a   rip = 0x00007fff7e3e1eb7
    Found by: call frame info
12  cgame-native-dll.so!vmMain [VMMain.cpp : 104 + 0x5]
    rbx = 0x000055555cab3580   rbp = 0x0000000000000000
    rsp = 0x00007fff961aab30   r12 = 0x00007ffffffecdde
    r13 = 0x00007ffffffecddf   r14 = 0x00007fff961ab700
    r15 = 0x000000000000001a   rip = 0x00007fff7e3e214b
    Found by: call frame info
13  daemon!std::thread::_State_impl, Str::StringRef, VM::VMBase::InProcessInfo&):: > > >::_M_run [VirtualMachine.cpp : 352 + 0x6]
    rbx = 0x000055555cab3580   rbp = 0x0000000000000000
    rsp = 0x00007fff961aab90   r12 = 0x00007ffffffecdde
    r13 = 0x00007ffffffecddf   r14 = 0x00007fff961ab700
    r15 = 0x000000000000001a   rip = 0x00005555557c8f0f
    Found by: call frame info
14  libstdc++.so.6.0.24 + 0xbc0ff
    rbx = 0x000055555cab3580   rbp = 0x0000000000000000
    rsp = 0x00007fff961aabb0   r12 = 0x00007ffffffecdde
    r13 = 0x00007ffffffecddf   r14 = 0x00007fff961ab700
    r15 = 0x000000000000001a   rip = 0x00007ffff46010ff
    Found by: call frame info
15  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fff961aabd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
16  libc-2.26.so + 0x114b5f
    rsp = 0x00007fff961aac80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 0
 0  libpthread-2.26.so + 0x12e50
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dcbe50   rbx = 0x0000000000000016
    rsi = 0x00007fffffffd190   rdi = 0x0000000000000016
    rbp = 0x00007fffffffd190   rsp = 0x00007fffffffd160
     r8 = 0x0000000000000000    r9 = 0x0000000000000002
    r10 = 0xffffffffffffff88   r11 = 0x0000000000000293
    r12 = 0x0000000000000000   r13 = 0x00007fffffffdb90
    r14 = 0x0000000000000000   r15 = 0x0000000000000000
    rip = 0x00007ffff3dcbe50
    Found by: given as instruction pointer in context
 1  daemon!NaClReceiveDatagram [nacl_imc.cc : 168 + 0x8]
    rbp = 0x00007fffffffd190   rsp = 0x00007fffffffd190
    rip = 0x00005555558102b4
    Found by: stack scanning
 2  daemon!IPC::InternalRecvMsg [Primitives.cpp : 374 + 0x5]
    rbx = 0x0000000000000016   rbp = 0x00007fffffffd800
    rsp = 0x00007fffffffd230   r12 = 0x0000000000000006
    rip = 0x0000555555771426
    Found by: call frame info
 3  daemon!IPC::Socket::RecvMsg [Primitives.cpp : 457 + 0xb]
    rbx = 0x00007fffffffd8e0   rbp = 0x0000555555c38f40
    rsp = 0x00007fffffffd810   r12 = 0x0000000000000006
    r13 = 0x00007fffffffdb90   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x000055555577251b
    Found by: call frame info
 4  daemon!IPC::detail::SendMsg, int, bool> >; Args = {int&, bool&}]::&, IPC::Message, int, bool>, IPC::Reply<>, int&, bool&> [Channel.h : 111 + 0x5]
    rbx = 0x0000000000000000   rbp = 0x0000000000000000
    rsp = 0x00007fffffffd840   r12 = 0x0000000000000006
    r13 = 0x00007fffffffdb90   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x000055555562e543
    Found by: call frame info
 5  daemon!CL_CGameRendering [Channel.h : 234 + 0x21]
    rbx = 0x0000555555c38ec0   rbp = 0x0000000000000000
    rsp = 0x00007fffffffdb70   r12 = 0x0000000000000000
    r13 = 0x0000000000000000   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x000055555562302f
    Found by: call frame info
 6  daemon!SCR_DrawScreenField [cl_scrn.cpp : 291 + 0x5]
    rbx = 0x0000000000000033   rbp = 0x0000000000000000
    rsp = 0x00007fffffffdbb0   r12 = 0x0000000000000000
    r13 = 0x0000000000000000   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x000055555566a306
    Found by: call frame info
 7  daemon!SCR_UpdateScreen [cl_scrn.cpp : 343 + 0x5]
    rbx = 0x0000000000000033   rbp = 0x0000000000000000
    rsp = 0x00007fffffffdbc0   r12 = 0x0000000000000000
    r13 = 0x0000000000000000   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x000055555566a396
    Found by: call frame info
 8  daemon!CL_Frame [cl_main.cpp : 3014 + 0x5]
    rbx = 0x0000000000000033   rbp = 0x0000000000000000
    rsp = 0x00007fffffffdbd0   r12 = 0x0000000000000000
    r13 = 0x0000000000000000   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x000055555565a672
    Found by: call frame info
 9  daemon!Com_Frame [common.cpp : 1566 + 0x7]
    rbx = 0x0000000000000033   rbp = 0x0000000000000000
    rsp = 0x00007fffffffdc30   r12 = 0x0000000000000000
    r13 = 0x0000000000000000   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x0000555555599aea
    Found by: call frame info
10  daemon!main [System.cpp : 695 + 0x5]
    rbx = 0xffffffffffffffff   rbp = 0x0000555555813200
    rsp = 0x00007fffffffdcf0   r12 = 0x0000555555592760
    r13 = 0x00007fffffffde00   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x00005555555920ed
    Found by: call frame info
11  libc-2.26.so + 0x211c1
    rbx = 0x0000000000000000   rbp = 0x0000555555813200
    rsp = 0x00007fffffffdd30   r12 = 0x0000555555592760
    r13 = 0x00007fffffffde00   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x00007ffff39fa1c1
    Found by: call frame info
12  libpthread-2.26.so + 0x21a300
    rsp = 0x00007fffffffdd38   rip = 0x00007ffff3fd3300
    Found by: stack scanning
13  daemon + 0x3e0c0
    rsp = 0x00007fffffffdd50   rip = 0x00005555555920c0
    Found by: stack scanning
14  daemon + 0x3e760
    rsp = 0x00007fffffffdd68   rip = 0x0000555555592760
    Found by: stack scanning
15  ld-2.26.so + 0x10beb
    rsp = 0x00007fffffffddc0   rip = 0x00007ffff7de5beb
    Found by: stack scanning
16  daemon + 0x3e760
    rsp = 0x00007fffffffddd8   rip = 0x0000555555592760
    Found by: stack scanning
17  daemon!_start + 0x2a
    rsp = 0x00007fffffffddf0   rip = 0x000055555559278a
    Found by: stack scanning
18  0x7fffffffddf8
    rsp = 0x00007fffffffddf8   rip = 0x00007fffffffddf8
    Found by: call frame info

Thread 1
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x000055555695e7b0
    rsi = 0x0000000000000080   rdi = 0x000055555695e7c8
    rbp = 0x000055555695e7c8   rsp = 0x00007fffe6354a40
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x000055555695e7a0   r13 = 0x00007fffe6354aa0
    r14 = 0x000055555695e778   r15 = 0x00000000000000f0
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffe6354aa8   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 2  radeonsi_dri.so + 0x35e24b
    rsp = 0x00007fffe6354b30   rip = 0x00007fffc4f5924b
    Found by: stack scanning
 3  radeonsi_dri.so + 0x84dea0
    rsp = 0x00007fffe6354b48   rip = 0x00007fffc5448ea0
    Found by: stack scanning
 4  radeonsi_dri.so + 0x35e1a0
    rsp = 0x00007fffe6354b80   rip = 0x00007fffc4f591a0
    Found by: stack scanning
 5  radeonsi_dri.so + 0x35df68
    rsp = 0x00007fffe6354bb0   rip = 0x00007fffc4f58f68
    Found by: stack scanning
 6  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffe6354bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 7  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffe6354c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 2
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x00005555569abf00
    rsi = 0x0000000000000080   rdi = 0x00005555569abf18
    rbp = 0x00005555569abf18   rsp = 0x00007fffe6e24a40
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x00005555569abef0   r13 = 0x00007fffe6e24aa0
    r14 = 0x00005555569abec8   r15 = 0x0000000000000000
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffe6e24aa8   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 2  radeonsi_dri.so + 0x35e24b
    rsp = 0x00007fffe6e24b30   rip = 0x00007fffc4f5924b
    Found by: stack scanning
 3  libc-2.26.so + 0x8f44e
    rsp = 0x00007fffe6e24b50   rip = 0x00007ffff3a6844e
    Found by: stack scanning
 4  radeonsi_dri.so + 0x35e1a0
    rsp = 0x00007fffe6e24b80   rip = 0x00007fffc4f591a0
    Found by: stack scanning
 5  radeonsi_dri.so + 0x35df68
    rsp = 0x00007fffe6e24bb0   rip = 0x00007fffc4f58f68
    Found by: stack scanning
 6  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffe6e24bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 7  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffe6e24c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 3
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x0000555556961a38
    rsi = 0x0000000000000080   rdi = 0x0000555556961a50
    rbp = 0x0000555556961a50   rsp = 0x00007fffbbcaba40
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x0000555556961a28   r13 = 0x00007fffbbcabaa0
    r14 = 0x0000555556961a00   r15 = 0x000000000000015e
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffbbcabaa8   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 2  radeonsi_dri.so + 0x35e24b
    rsp = 0x00007fffbbcabb30   rip = 0x00007fffc4f5924b
    Found by: stack scanning
 3  radeonsi_dri.so + 0x7b0760
    rsp = 0x00007fffbbcabb48   rip = 0x00007fffc53ab760
    Found by: stack scanning
 4  radeonsi_dri.so + 0x35e1a0
    rsp = 0x00007fffbbcabb80   rip = 0x00007fffc4f591a0
    Found by: stack scanning
 5  radeonsi_dri.so + 0x35df68
    rsp = 0x00007fffbbcabbb0   rip = 0x00007fffc4f58f68
    Found by: stack scanning
 6  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffbbcabbd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 7  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffbbcabc80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 4
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x0000555556961a38
    rsi = 0x0000000000000080   rdi = 0x0000555556961a50
    rbp = 0x0000555556961a50   rsp = 0x00007fffbb4aaa40
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x0000555556961a28   r13 = 0x00007fffbb4aaaa0
    r14 = 0x0000555556961a00   r15 = 0x000000000000015c
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffbb4aaaa8   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 2  radeonsi_dri.so + 0x35e24b
    rsp = 0x00007fffbb4aab30   rip = 0x00007fffc4f5924b
    Found by: stack scanning
 3  radeonsi_dri.so + 0x7b0760
    rsp = 0x00007fffbb4aab48   rip = 0x00007fffc53ab760
    Found by: stack scanning
 4  radeonsi_dri.so + 0x35e1a0
    rsp = 0x00007fffbb4aab80   rip = 0x00007fffc4f591a0
    Found by: stack scanning
 5  radeonsi_dri.so + 0x35df68
    rsp = 0x00007fffbb4aabb0   rip = 0x00007fffc4f58f68
    Found by: stack scanning
 6  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffbb4aabd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 7  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffbb4aac80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 5
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x0000555556961a38
    rsi = 0x0000000000000080   rdi = 0x0000555556961a50
    rbp = 0x0000555556961a50   rsp = 0x00007fffbaca9a40
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x0000555556961a28   r13 = 0x00007fffbaca9aa0
    r14 = 0x0000555556961a00   r15 = 0x000000000000015a
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffbaca9aa8   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 2  radeonsi_dri.so + 0x35e24b
    rsp = 0x00007fffbaca9b30   rip = 0x00007fffc4f5924b
    Found by: stack scanning
 3  radeonsi_dri.so + 0x7b0760
    rsp = 0x00007fffbaca9b48   rip = 0x00007fffc53ab760
    Found by: stack scanning
 4  radeonsi_dri.so + 0x35e1a0
    rsp = 0x00007fffbaca9b80   rip = 0x00007fffc4f591a0
    Found by: stack scanning
 5  radeonsi_dri.so + 0x35df68
    rsp = 0x00007fffbaca9bb0   rip = 0x00007fffc4f58f68
    Found by: stack scanning
 6  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffbaca9bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 7  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffbaca9c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 6
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x0000555556961b24
    rsi = 0x0000000000000080   rdi = 0x0000555556961b3c
    rbp = 0x0000555556961b3c   rsp = 0x00007fffba4a8a40
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x0000555556961b10   r13 = 0x00007fffba4a8aa0
    r14 = 0x0000555556961ae8   r15 = 0x0000000000000005
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  libc-2.26.so + 0x9082a
    rsp = 0x00007fffba4a8a80   rip = 0x00007ffff3a6982a
    Found by: stack scanning
 2  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffba4a8aa8   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 3  radeonsi_dri.so + 0x35e24b
    rsp = 0x00007fffba4a8b30   rip = 0x00007fffc4f5924b
    Found by: stack scanning
 4  radeonsi_dri.so + 0x7b0480
    rsp = 0x00007fffba4a8b48   rip = 0x00007fffc53ab480
    Found by: stack scanning
 5  radeonsi_dri.so + 0x35e1a0
    rsp = 0x00007fffba4a8b80   rip = 0x00007fffc4f591a0
    Found by: stack scanning
 6  radeonsi_dri.so + 0x35df68
    rsp = 0x00007fffba4a8bb0   rip = 0x00007fffc4f58f68
    Found by: stack scanning
 7  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffba4a8bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 8  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffba4a8c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 7
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x0000555556961b20
    rsi = 0x0000000000000080   rdi = 0x0000555556961b38
    rbp = 0x0000555556961b38   rsp = 0x00007fffb9ca7a40
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x0000555556961b10   r13 = 0x00007fffb9ca7aa0
    r14 = 0x0000555556961ae8   r15 = 0x0000000000000002
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffb9ca7aa8   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 2  radeonsi_dri.so + 0x35e24b
    rsp = 0x00007fffb9ca7b30   rip = 0x00007fffc4f5924b
    Found by: stack scanning
 3  libc-2.26.so + 0x8f44e
    rsp = 0x00007fffb9ca7b50   rip = 0x00007ffff3a6844e
    Found by: stack scanning
 4  radeonsi_dri.so + 0x35e1a0
    rsp = 0x00007fffb9ca7b80   rip = 0x00007fffc4f591a0
    Found by: stack scanning
 5  radeonsi_dri.so + 0x35df68
    rsp = 0x00007fffb9ca7bb0   rip = 0x00007fffc4f58f68
    Found by: stack scanning
 6  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffb9ca7bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 7  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffb9ca7c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 8
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x0000555556a7bdbc
    rsi = 0x0000000000000080   rdi = 0x0000555556a7bdd4
    rbp = 0x0000555556a7bdd4   rsp = 0x00007fffb94a6a40
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x0000555556a7bda8   r13 = 0x00007fffb94a6aa0
    r14 = 0x0000555556a7bd80   r15 = 0x00000000000000f7
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffb94a6aa8   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 2  radeonsi_dri.so + 0x35e24b
    rsp = 0x00007fffb94a6b30   rip = 0x00007fffc4f5924b
    Found by: stack scanning
 3  radeonsi_dri.so + 0x4e7ea0
    rsp = 0x00007fffb94a6b48   rip = 0x00007fffc50e2ea0
    Found by: stack scanning
 4  radeonsi_dri.so + 0x35e1a0
    rsp = 0x00007fffb94a6b80   rip = 0x00007fffc4f591a0
    Found by: stack scanning
 5  radeonsi_dri.so + 0x35df68
    rsp = 0x00007fffb94a6bb0   rip = 0x00007fffc4f58f68
    Found by: stack scanning
 6  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffb94a6bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 7  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffb94a6c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 9
 0  libc-2.26.so + 0x108951
    rax = 0xfffffffffffffdfc   rdx = 0x0000000000000486
    rcx = 0x00007ffff3ae1951   rbx = 0x00007fff90009d80
    rsi = 0x0000000000000003   rdi = 0x00007fff90009d80
    rbp = 0x0000000000000003   rsp = 0x00007fff980d4920
     r8 = 0x0000000000000000    r9 = 0x0000000000000000
    r10 = 0x0000000000000fc0   r11 = 0x0000000000000293
    r12 = 0x0000000000000486   r13 = 0x0000000000000486
    r14 = 0x00007fff980d5700   r15 = 0x000000000000001a
    rip = 0x00007ffff3ae1951
    Found by: given as instruction pointer in context
 1  libpulse.so.0.20.1 + 0x32451
    rsp = 0x00007fff980d4950   rip = 0x00007ffff1291451
    Found by: stack scanning
 2  libpulse.so.0.20.1 + 0x23e10
    rsp = 0x00007fff980d4980   rip = 0x00007ffff1282e10
    Found by: stack scanning
 3  libpulse.so.0.20.1 + 0x244a0
    rsp = 0x00007fff980d49b0   rip = 0x00007ffff12834a0
    Found by: stack scanning
 4  libpulse.so.0.20.1 + 0x24530
    rsp = 0x00007fff980d49d0   rip = 0x00007ffff1283530
    Found by: stack scanning
 5  libpulse.so.0.20.1 + 0x32399
    rsp = 0x00007fff980d49f0   rip = 0x00007ffff1291399
    Found by: stack scanning
 6  libc-2.26.so + 0x8f44e
    rsp = 0x00007fff980d4ac0   rip = 0x00007ffff3a6844e
    Found by: stack scanning
 7  libpulse.so.0.20.1 + 0x244ae
    rsp = 0x00007fff980d4b50   rip = 0x00007ffff12834ae
    Found by: stack scanning
 8  libpulsecommon-10.0.so + 0x51ed8
    rsp = 0x00007fff980d4bb0   rip = 0x00007fffee186ed8
    Found by: stack scanning
 9  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fff980d4bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
10  libc-2.26.so + 0x114b5f
    rsp = 0x00007fff980d4c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 10
 0  libpthread-2.26.so + 0xe072
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dc7072   rbx = 0x00007fff900085f4
    rsi = 0x0000000000000080   rdi = 0x00007fff9000860c
    rbp = 0x00007fff9000860c   rsp = 0x00007fffb8324a30
     r8 = 0x00000000000000ca    r9 = 0x0000000000000000
    r10 = 0x0000000000000000   r11 = 0x0000000000000246
    r12 = 0x00007fff900085e0   r13 = 0x00007fffb8324a90
    r14 = 0x00007fff90009c40   r15 = 0x0000000000000483
    rip = 0x00007ffff3dc7072
    Found by: given as instruction pointer in context
 1  memfd:pulseaudio (deleted) + 0xc1a0040
    rsp = 0x00007fffb8324a88   rip = 0x00007fff8c1a0040
    Found by: stack scanning
 2  libpthread-2.26.so + 0xde00
    rsp = 0x00007fffb8324a98   rip = 0x00007ffff3dc6e00
    Found by: stack scanning
 3  libpulsecommon-10.0.so + 0x51c60
    rsp = 0x00007fffb8324ae8   rip = 0x00007fffee186c60
    Found by: stack scanning
 4  libpulse.so.0.20.1 + 0x32a38
    rsp = 0x00007fffb8324b20   rip = 0x00007ffff1291a38
    Found by: stack scanning
 5  libopenal.so.1.17.2 + 0x45f99
    rsp = 0x00007fffb8324b30   rip = 0x00007ffff5d02f99
    Found by: stack scanning
 6  memfd:pulseaudio (deleted) + 0xc1a0040
    rsp = 0x00007fffb8324b68   rip = 0x00007fff8c1a0040
    Found by: stack scanning
 7  libopenal.so.1.17.2 + 0x45e30
    rsp = 0x00007fffb8324b80   rip = 0x00007ffff5d02e30
    Found by: stack scanning
 8  libopenal.so.1.17.2 + 0x4afe7
    rsp = 0x00007fffb8324bb0   rip = 0x00007ffff5d07fe7
    Found by: stack scanning
 9  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fffb8324bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
10  libc-2.26.so + 0x114b5f
    rsp = 0x00007fffb8324c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Thread 11
 0  libpthread-2.26.so + 0x12e50
    rax = 0xfffffffffffffe00   rdx = 0x0000000000000000
    rcx = 0x00007ffff3dcbe50   rbx = 0x000000000000001f
    rsi = 0x00007fff978d3370   rdi = 0x000000000000001f
    rbp = 0x00007fff978d3370   rsp = 0x00007fff978d3340
     r8 = 0x0000000000000000    r9 = 0x0000000000000002
    r10 = 0xffffffffffffff88   r11 = 0x0000000000000293
    r12 = 0x0000000000000000   r13 = 0x00007fff978d3a30
    r14 = 0x0000000000000000   r15 = 0x00007fff978d49c0
    rip = 0x00007ffff3dcbe50
    Found by: given as instruction pointer in context
 1  sgame-native-dll.so!NaClReceiveDatagram [nacl_imc.cc : 168 + 0x8]
    rbp = 0x00007fff978d3370   rsp = 0x00007fff978d3370
    rip = 0x00007fff98fa1194
    Found by: stack scanning
 2  sgame-native-dll.so!IPC::InternalRecvMsg [Primitives.cpp : 374 + 0x5]
    rbx = 0x000000000000001f   rbp = 0x00007fff978d39f0
    rsp = 0x00007fff978d3410   r12 = 0x00007fff9927a6a0
    rip = 0x00007fff98f7b926
    Found by: call frame info
 3  sgame-native-dll.so!IPC::Socket::RecvMsg [Primitives.cpp : 457 + 0xb]
    rbx = 0x00007fff978d3a60   rbp = 0x00007fff9927a6a0
    rsp = 0x00007fff978d3a00   r12 = 0x00007fff9927a6a0
    r13 = 0x00007fff978d3a30   r14 = 0x0000000000000000
    r15 = 0x00007fff978d49c0   rip = 0x00007fff98f7ca8b
    Found by: call frame info
 4  sgame-native-dll.so!CommonInit [Channel.h : 111 + 0x16]
    rbx = 0x00007fff978d3aa0   rbp = 0x00007fff978d3b20
    rsp = 0x00007fff978d3a20   r12 = 0x00007fff9927a6a0
    r13 = 0x00007fff978d3a30   r14 = 0x0000000000000000
    r15 = 0x00007fff978d49c0   rip = 0x00007fff98f6253f
    Found by: call frame info
 5  sgame-native-dll.so!vmMain [VMMain.cpp : 104 + 0x5]
    rbx = 0x000055555dd47540   rbp = 0x0000000000000000
    rsp = 0x00007fff978d3b30   r12 = 0x00007fffffffd15e
    r13 = 0x00007fffffffd15f   r14 = 0x00007fff978d4700
    r15 = 0x00007fff978d49c0   rip = 0x00007fff98f6289b
    Found by: call frame info
 6  daemon!std::thread::_State_impl, Str::StringRef, VM::VMBase::InProcessInfo&):: > > >::_M_run [VirtualMachine.cpp : 352 + 0x6]
    rbx = 0x000055555dd47540   rbp = 0x0000000000000000
    rsp = 0x00007fff978d3b90   r12 = 0x00007fffffffd15e
    r13 = 0x00007fffffffd15f   r14 = 0x00007fff978d4700
    r15 = 0x00007fff978d49c0   rip = 0x00005555557c8f0f
    Found by: call frame info
 7  libstdc++.so.6.0.24 + 0xbc0ff
    rbx = 0x000055555dd47540   rbp = 0x0000000000000000
    rsp = 0x00007fff978d3bb0   r12 = 0x00007fffffffd15e
    r13 = 0x00007fffffffd15f   r14 = 0x00007fff978d4700
    r15 = 0x00007fff978d49c0   rip = 0x00007ffff46010ff
    Found by: call frame info
 8  libpthread-2.26.so + 0x77fc
    rsp = 0x00007fff978d3bd0   rip = 0x00007ffff3dc07fc
    Found by: stack scanning
 9  libc-2.26.so + 0x114b5f
    rsp = 0x00007fff978d3c80   rip = 0x00007ffff3aedb5f
    Found by: stack scanning

Loaded modules:
0x555555554000 - 0x5555558cefff  daemon  ???  (main)
0x7fff7e285000 - 0x7fff7e7e7fff  cgame-native-dll.so  ???
0x7fff80000000 - 0x7fff8fffffff  memfd:pulseaudio (deleted)  ???  (WARNING: No symbols, memfd:pulseaudio (deleted), 000000000000000000000000000000000)
0x7fff9838d000 - 0x7fff9874cfff  google-nacl-shm--1787.3 (deleted)  ???
0x7fff98a69000 - 0x7fff98e28fff  google-nacl-shm--1787.3 (deleted)  ???
0x7fff98e29000 - 0x7fff991fdfff  sgame-native-dll.so  ???
0x7fff99a31000 - 0x7fff99c30fff  google-nacl-shm--1787.4 (deleted)  ???
0x7fff99c31000 - 0x7fff99e68fff  liblua5.3.so.0.0.0  ???
0x7fffb8025000 - 0x7fffb8224fff  google-nacl-shm--1787.4 (deleted)  ???
0x7fffb83a7000 - 0x7fffb85edfff  libjack.so.0.1.0  ???
0x7fffb8a8a000 - 0x7fffb8ca7fff  libudev.so.1.6.6  ???
0x7fffbbcad000 - 0x7fffbbdedfff  index  ???
0x7fffbbdee000 - 0x7fffbbff9fff  libnss_files-2.26.so  ???
0x7fffc0001000 - 0x7fffc020cfff  libnss_nis-2.26.so  ???
0x7fffc020d000 - 0x7fffc0415fff  libnss_compat-2.26.so  ???
0x7fffc0416000 - 0x7fffc0648fff  libedit.so.2.0.56  ???
0x7fffc064d000 - 0x7fffc4154fff  libLLVM-7.so.1  ???
0x7fffc41b4000 - 0x7fffc43cdfff  libelf-0.170.so  ???
0x7fffc43ce000 - 0x7fffc45d7fff  libdrm_amdgpu.so.1.0.0  ???
0x7fffc45d8000 - 0x7fffc47e3fff  libdrm_radeon.so.1.0.1  ???
0x7fffc47e4000 - 0x7fffc49ebfff  libdrm_nouveau.so.2.0.0  ???
0x7fffc49ec000 - 0x7fffc4bfafff  libsensors.so.4.4.0  ???
0x7fffc4bfb000 - 0x7fffc595afff  radeonsi_dri.so  ???  (WARNING: No symbols, radeonsi_dri.so, 2BD6943D49A6F3B7087E8586BF1ECD980)
0x7fffe6356000 - 0x7fffe6624fff  locale-archive  ???
0x7fffe7e27000 - 0x7fffe8098fff  libpcre.so.3.13.3  ???
0x7fffe8099000 - 0x7fffe82adfff  libgpg-error.so.0.22.0  ???
0x7fffe82ae000 - 0x7fffe84b7fff  libcrypt-2.26.so  ???
0x7fffe84e6000 - 0x7fffe87ecfff  libsqlite3.so.0.8.6  ???
0x7fffe87ee000 - 0x7fffe8a36fff  libhx509.so.5.0.0  ???
0x7fffe8a38000 - 0x7fffe8c46fff  libheimbase.so.1.0.0  ???
0x7fffe8c47000 - 0x7fffe8e6ffff  libwind.so.0.0.0  ???
0x7fffe8e70000 - 0x7fffe9118fff  libvorbisenc.so.2.0.11  ???
0x7fffe9119000 - 0x7fffe938ffff  libFLAC.so.8.3.0  ???
0x7fffe9390000 - 0x7fffe95a7fff  libnsl-2.26.so  ???
0x7fffe95aa000 - 0x7fffe97cffff  libselinux.so.1  ???
0x7fffe97d2000 - 0x7fffe99e9fff  liblz4.so.1.7.1  ???
0x7fffe99ea000 - 0x7fffe9c0ffff  liblzma.so.5.2.2  ???
0x7fffe9c10000 - 0x7fffe9f1cfff  libgcrypt.so.20.1.8  ???
0x7fffe9f1e000 - 0x7fffea133fff  libroken.so.18.1.0  ???
0x7fffea134000 - 0x7fffea368fff  libhcrypto.so.4.1.0  ???
0x7fffea36a000 - 0x7fffea60bfff  libasn1.so.8.0.0  ???
0x7fffea60c000 - 0x7fffea896fff  libkrb5.so.26.0.0  ???
0x7fffea898000 - 0x7fffeaaa0fff  libheimntlm.so.0.1.0  ???
0x7fffeaaa1000 - 0x7fffeaca4fff  libkeyutils.so.1.5  ???
0x7fffeaca5000 - 0x7fffeaeaafff  libasyncns.so.0.3.1  ???
0x7fffeaeab000 - 0x7fffeb121fff  libsndfile.so.1.0.28  ???
0x7fffeb124000 - 0x7fffeb32dfff  libwrap.so.0.7.6  ???
0x7fffeb32e000 - 0x7fffeb5b1fff  libsystemd.so.0.19.0  ???
0x7fffeb5b3000 - 0x7fffeb7f2fff  libgssapi.so.3.0.0  ???
0x7fffeb7f4000 - 0x7fffeba0efff  libsasl2.so.2.0.25  ???
0x7fffeba0f000 - 0x7fffebc26fff  libresolv-2.26.so  ???
0x7fffebc29000 - 0x7fffebe33fff  libkrb5support.so.0.1  ???
0x7fffebe34000 - 0x7fffec037fff  libcom_err.so.2.1  ???
0x7fffec038000 - 0x7fffec268fff  libk5crypto.so.3.1  ???
0x7fffec26a000 - 0x7fffec53cfff  libkrb5.so.3.3  ???
0x7fffec53d000 - 0x7fffec74ffff  libtasn1.so.6.5.4  ???
0x7fffec750000 - 0x7fffec982fff  libidn.so.11.6.16  ???
0x7fffec983000 - 0x7fffeccb1fff  libp11-kit.so.0.3.0  ???
0x7fffeccb3000 - 0x7fffecfc7fff  libunistring.so.0.1.2  ???
0x7fffecfc9000 - 0x7fffed1d5fff  libxcb-render.so.0.0.0  ???
0x7fffed1d6000 - 0x7fffed3d8fff  libxcb-shm.so.0.0.0  ???
0x7fffed3d9000 - 0x7fffed61bfff  libfontconfig.so.1.9.0  ???
0x7fffed61c000 - 0x7fffed8c1fff  libpixman-1.so.0.34.0  ???
0x7fffed8c2000 - 0x7fffedac9fff  libffi.so.6.0.4  ???
0x7fffedaca000 - 0x7fffedcd3fff  libXrender.so.1.3.0  ???
0x7fffedcd4000 - 0x7fffedee7fff  libbsd.so.0.8.6  ???
0x7fffedee9000 - 0x7fffee134fff  libdbus-1.so.3.14.13  ???
0x7fffee135000 - 0x7fffee3b2fff  libpulsecommon-10.0.so  ???  (WARNING: No symbols, libpulsecommon-10.0.so, 5F151704255CB8CCA007D84C71F020C70)
0x7fffee3b3000 - 0x7fffee5b8fff  libXdmcp.so.6.0.0  ???
0x7fffee5b9000 - 0x7fffee7bcfff  libXau.so.6.0.0  ???
0x7fffee7bd000 - 0x7fffee9cafff  liblber-2.4.so.2.10.8  ???
0x7fffee9cb000 - 0x7fffeec1afff  libldap_r-2.4.so.2.10.8  ???
0x7fffeec1d000 - 0x7fffeee66fff  libgssapi_krb5.so.2.2  ???
0x7fffeee67000 - 0x7fffef1f7fff  libgnutls.so.30.13.1  ???
0x7fffef1f9000 - 0x7fffef406fff  libpsl.so.5.1.2  ???
0x7fffef407000 - 0x7fffef622fff  librtmp.so.1  ???
0x7fffef623000 - 0x7fffef86ffff  libidn2.so.0.3.1  ???
0x7fffef870000 - 0x7fffefb7efff  libcairo.so.2.11400.10  ???
0x7fffefb81000 - 0x7fffefdcafff  libopus.so.0.5.2  ???
0x7fffefdcb000 - 0x7ffff0009fff  libxkbcommon.so.0.0.0  ???
0x7ffff000a000 - 0x7ffff0211fff  libwayland-cursor.so.0.0.0  ???
0x7ffff0212000 - 0x7ffff0420fff  libwayland-client.so.0.3.0  ???
0x7ffff0421000 - 0x7ffff0622fff  libwayland-egl.so.1.0.0  ???
0x7ffff0623000 - 0x7ffff0826fff  libXss.so.1.0.0  ???
0x7ffff0827000 - 0x7ffff0a31fff  libXrandr.so.2.2.0  ???
0x7ffff0a32000 - 0x7ffff0c41fff  libXi.so.6.1.0  ???
0x7ffff0c42000 - 0x7ffff0e44fff  libXinerama.so.1.0.0  ???
0x7ffff0e45000 - 0x7ffff104efff  libXcursor.so.1.0.2  ???
0x7ffff104f000 - 0x7ffff125cfff  libsndio.so.6.1  ???
0x7ffff125f000 - 0x7ffff14aefff  libpulse.so.0.20.1  ???  (WARNING: No symbols, libpulse.so.0.20.1, 368575DB8D17A56E6662046D5CC9BE450)
0x7ffff14af000 - 0x7ffff17b6fff  libasound.so.2.0.0  ???
0x7ffff17b7000 - 0x7ffff19c7fff  libdrm.so.2.4.0  ???
0x7ffff19c8000 - 0x7ffff1bcdfff  libXxf86vm.so.1.0.0  ???
0x7ffff1bce000 - 0x7ffff1dd2fff  libxcb-dri2.so.0.0.0  ???
0x7ffff1dd3000 - 0x7ffff1fedfff  libxcb-glx.so.0.0.0  ???
0x7ffff1fee000 - 0x7ffff2215fff  libxcb.so.1.1.0  ???
0x7ffff2216000 - 0x7ffff254efff  libX11.so.6.3.0  ???
0x7ffff254f000 - 0x7ffff2750fff  libX11-xcb.so.1.0.0  ???
0x7ffff2751000 - 0x7ffff2956fff  libXfixes.so.3.1.0  ???
0x7ffff2957000 - 0x7ffff2b59fff  libXdamage.so.1.1.0  ???
0x7ffff2b5a000 - 0x7ffff2d6bfff  libXext.so.6.4.0  ???
0x7ffff2d6c000 - 0x7ffff2f9bfff  libglapi.so.0.0.0  ???
0x7ffff2f9d000 - 0x7ffff319ffff  libxshmfence.so.1.0.0  ???
0x7ffff31a0000 - 0x7ffff33a6fff  libxcb-sync.so.1.0.0  ???
0x7ffff33a7000 - 0x7ffff35a9fff  libxcb-present.so.0.0.0  ???
0x7ffff35aa000 - 0x7ffff37adfff  libxcb-dri3.so.0.0.0  ???
0x7ffff37ae000 - 0x7ffff39d8fff  libexpat.so.1.6.5  ???
0x7ffff39d9000 - 0x7ffff3db4fff  libc-2.26.so  ???  (WARNING: No symbols, libc-2.26.so, 1213CCDDDB2D5EFE5EF77D4EBE66D1240)
0x7ffff3db9000 - 0x7ffff3fd3fff  libpthread-2.26.so  ???  (WARNING: No symbols, libpthread-2.26.so, 6ECB5EB940CE8170730183E686FF6CF20)
0x7ffff3fd8000 - 0x7ffff41eefff  libgcc_s.so.1  ???
0x7ffff41ef000 - 0x7ffff4544fff  libm-2.26.so  ???
0x7ffff4545000 - 0x7ffff48c7fff  libstdc++.so.6.0.24  ???  (WARNING: No symbols, libstdc++.so.6.0.24, 1A85EC7817925CD660DA3BAA07772F380)
0x7ffff48cb000 - 0x7ffff4af3fff  libtinfo.so.5.9  ???
0x7ffff4af4000 - 0x7ffff4d22fff  libncursesw.so.5.9  ???
0x7ffff4d23000 - 0x7ffff4f26fff  libdl-2.26.so  ???
0x7ffff4f27000 - 0x7ffff512efff  librt-2.26.so  ???
0x7ffff512f000 - 0x7ffff53aefff  libgmp.so.10.3.2  ???
0x7ffff53af000 - 0x7ffff55e1fff  libhogweed.so.4.3  ???
0x7ffff55e2000 - 0x7ffff5816fff  libnettle.so.6.3  ???
0x7ffff5817000 - 0x7ffff5a4afff  libGeoIP.so.1.6.11  ???
0x7ffff5a4b000 - 0x7ffff5cbcfff  libcurl-gnutls.so.4.4.0  ???
0x7ffff5cbd000 - 0x7ffff5f39fff  libopenal.so.1.17.2  ???  (WARNING: No symbols, libopenal.so.1.17.2, 556B9EF00EDC3C92A7C3A4687C4F8E520)
0x7ffff5f5b000 - 0x7ffff61eafff  libGLEW.so.2.0.0  ???
0x7ffff61f0000 - 0x7ffff64a2fff  libfreetype.so.6.14.0  ???
0x7ffff64a3000 - 0x7ffff66bffff  libz.so.1.2.11  ???
0x7ffff66c0000 - 0x7ffff68f1fff  libpng16.so.16.34.0  ???
0x7ffff68f2000 - 0x7ffff6b59fff  libjpeg.so.8.1.2  ???
0x7ffff6b5a000 - 0x7ffff6dbefff  libwebp.so.6.0.1  ???
0x7ffff6dc1000 - 0x7ffff7012fff  libtheora.so.0.3.10  ???
0x7ffff7013000 - 0x7ffff721efff  libopusfile.so.0.4.1  ???
0x7ffff721f000 - 0x7ffff7449fff  libvorbis.so.0.4.8  ???
0x7ffff744a000 - 0x7ffff7651fff  libvorbisfile.so.3.3.7  ???
0x7ffff7652000 - 0x7ffff785afff  libogg.so.0.8.2  ???
0x7ffff785b000 - 0x7ffff7b5ffff  libSDL2-2.0.so.0.6.0  ???
0x7ffff7b63000 - 0x7ffff7dd4fff  libGL.so.1.2.0  ???
0x7ffff7dd5000 - 0x7ffff7dfbfff  ld-2.26.so  ???  (WARNING: No symbols, ld-2.26.so, 1C502A0624243D93B1423223D1316D900)
0x7ffff7ee3000 - 0x7ffff7ee3fff  memfd:xshmfence (deleted)  ???
0x7ffff7fbf000 - 0x7ffff7fc5fff  gconv-modules.cache  ???
0x7ffff7fc6000 - 0x7ffff7ff6fff  LC_CTYPE  ???
0x7ffff7ffa000 - 0x7ffff7ffbfff  linux-gate.so  ???

The bug seems to occurs in CM_TraceThroughLeaf from src/common/cm/cm_trace.cpp file around line 1487, there:

Daemon/src/common/cm/cm_trace.cpp

Lines 1484 to 1492 in f63af26

 // trace line against all surfaces in the leaf 

 for ( k = 0; k < leaf->numLeafSurfaces; k++ ) 

 { 

 surface = cm.surfaces[ cm.leafsurfaces[ leaf->firstLeafSurface + k ] ]; 

 if ( !surface ) 

 { 

 continue; 

 }

x86 WebP DLL wrongly assumes stack alignment

The libwebp-5.dll shipped in the msvc32-4 external_deps seems to be actually incompatible with MSVC. On the x86 Windows platform, only 4-byte stack alignment is guaranteed. But the code in this DLL apparently assumes that the stack will be 16-byte aligned when using SSE instructions on stack argument (causing it to crash).

I tried to find a compile switch or attribute to force 16-byte stack alignment, but no luck.

Where does this code come from anyway? Is it built by us or from a binary release?

parallax mapping bugs

I noticed yesterday that XreaL had working parallax mapping, I know Darkplaces (used by Xonotic) has it too. What's missing to have that effect in our maps?

ship height maps
automatically discover height map in normal map alpha channel
fix the reversed height map bug
support parallax offset

surfaceflags are defined in engine code, not in game code

See: src/engine/qcommon/surfaceflags.h

They contains Unvanquished-specific code like CONTENTS_NOALIENBUILD. Those flags are game-specific, for example the value for Unvanquished's nobuild surfaceflag is known to be the value for the Urban Terror metalstep surface.

broken `Forwarding commands to existing instance` feature

the “Existing instance found / Forwarding commands to existing instance” feature looks to be broken on for-0.51.0 branch.

Renderer breakage on resolution change

I've been getting renderer issues on the for-0.51.0 branch when I change resolutions. I have a Radeon R7 200 on Windows 7. Usually I switch between a windowed configuration which sets "r_mode -1; r_customwidth 900; r_customheight 700; r_fullscreen 0;vid_restart" and a full-screen which sets "r_customwidth 1920; r_customheight 1080; r_fullscreen 1; vid_restart".

These work fine on a client compiled some time after 0.50, but one or the other of the resolutions is usually broken on the 0.51 branch. Usually the windowed one is the one that has distortion and a strange perspective. This is what it looks like in third-person mode:

But I also got this situation, where windowed was normal, but full screen looks like this:

breakpad: error: field ‘context’ has incomplete type ‘google_breakpad::ucontext’ struct ucontext context;

I got that while trying to build Daemon and Unvanquished on Ubuntu 17.10:

[  9%] Building CXX object CMakeFiles/srclibs-breakpad.dir/libs/breakpad/src/client/linux/crash_generation/crash_generation_server.cc.o
In file included from /home/illwieckz/dev/buildme-unvanquished/Daemon/libs/breakpad/src/client/linux/crash_generation/crash_generation_server.cc:46:0:
/home/illwieckz/dev/buildme-unvanquished/Daemon/libs/breakpad/src/client/linux/handler/exception_handler.h:194:21: error: field ‘context’ has incomplete type ‘google_breakpad::ucontext’
     struct ucontext context;
                     ^~~~~~~
/home/illwieckz/dev/buildme-unvanquished/Daemon/libs/breakpad/src/client/linux/handler/exception_handler.h:194:12: note: forward declaration of ‘struct google_breakpad::ucontext’
     struct ucontext context;
            ^~~~~~~~

Fix continuous integration

See https://travis-ci.org/DaemonEngine/Daemon it seems it has some wrong set up or they changed something in their vms.

impact marks on doors and moveables

Currently in Unvanquished when people hit a door or an elevator with bullets and other projectiles (or dragoon/granger/trapper spit) there is no impact mark (neither creep) on them.

The spearmint engine by @zturtleman has support for “bullet marks on doors and moving platforms” according to its official page. It would be cool to have this feature too because the lack of such feature is the kind of thing that makes Unvanquished still looking a bit like Quake 3 from the last millennium.

Define supported compiler versions

We should define which minimum compiler versions are supported, so we know which workarounds for old compilers can be removed.

With GCC, the engine still has to build with version 4.8 because it's the one we are using on Travis. If it weren't for that we would surely want to choose something newer.

Regarding MSVC, I can say that the code currently builds in Visual Studio 2015, but doesn't build in VS 2013. VS 2017 is the latest version.

I don't know much about the versions of Clang. Perhaps the version shipped by NaCl would be the constraint here.

Drop VM file handle support?

There is code that allows the VMs to open an FS::File that is backed by a real Unix file descriptor, which can be directly operated on by the gamelogic. It works, but is used by nobody (all VM code is using the older API where each operation is an engine call operating on the table in src/engine/qcommon/files.cpp).

Reasons to delete it other than being unused:

Potential difficulty in porting if we move off of NaCl.
Sketchy or at least difficult to understand from a security point of view.

The main reason to keep it would be if we expected to have a use case for high-volume file I/O inside the gamelogic.

engine code requires some shaders and assets currently shipped as game assets

There are 3 shaders in engine code that are sets from game assets

Daemon/src/engine/client/cl_main.cpp:	cls.charSetShader = re.RegisterShader( "gfx/2d/bigchars", RSF_DEFAULT );
Daemon/src/engine/client/cl_main.cpp:	cls.whiteShader = re.RegisterShader( "white", RSF_NOMIP );
Daemon/src/engine/client/cl_main.cpp:	cls.consoleShader = re.RegisterShader( "console", RSF_DEFAULT );

The first one gfx/2d/bigchars looks to be a fallback if the ttf font is not found. Do we have to keep that? If the ttf found is not found it means both system font and game pack are missing, and if game pack is missing, the fallback will never be found. So, can we get rid of that?

Daemon/src/engine/client/cl_main.cpp

Lines 3054 to 3069 in 8c1c497

 // load character sets 

 cls.charSetShader = re.RegisterShader( "gfx/2d/bigchars", RSF_DEFAULT ); 

 cls.useLegacyConsoleFont = cls.useLegacyConsoleFace = true; 

 // Register console font specified by cl_consoleFont, if any 

 // filehandle is unused but forces FS_FOpenFileRead() to heed purecheck because it does not when filehandle is nullptr 

 if ( cl_consoleFont->string[0] ) 

 { 

 if ( FS_FOpenFileRead( cl_consoleFont->string, &f, false ) >= 0 ) 

 { 

 re.RegisterFont( cl_consoleFont->string, nullptr, cl_consoleFontSize->integer, &cls.consoleFont ); 

 cls.useLegacyConsoleFont = false; 

 } 

 FS_FCloseFile( f ); 

 }

The other ones are just shaders for pure white and pure black shaders:

https://github.com/UnvanquishedAssets/unvanquished_src.dpkdir/blob/8bd935eca289ab3e55ef21d6122eab884378fd6d/scripts/misc.shader#L106-L114

white
{
	cull none
	{
		map *white
		blendfunc	GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbgen vertex
	}
}

https://github.com/UnvanquishedAssets/unvanquished_src.dpkdir/blob/8bd935eca289ab3e55ef21d6122eab884378fd6d/scripts/misc.shader#L38-L45

console
{
	nopicmip
	nomipmaps
	{
		map gfx/colors/black
	}
}

The white one only relies on pure text, it can be embedded. The console one (black one) relies on a pure black textures, it can probably be generated at run time or we can probably embed a 1×1px xpm or something like that (it's currently a pure black 8×8 jpg)…

Note that both white and console shaders are redefined by the game code itself and game packages so they basically are fallbacks for when game code does not define them and when game packages are not there, so the purpose of fallback is entirely defeated: the fallback for missing game requires game packs (!!!).

pitch black unrealarena maps (nolightmap issue)

reported by @maek on #unrealarena channel on QuakeNet, their campgrounds map is displayed pitch black when loaded by master or for-0.51.0 channel.

Must display:

Display instead:

@gimhael has a work in progress fix there: https://github.com/gimhael/Daemon/compare/fixnolightmap

But that “fix” also introduces bugs, it breaks models:

That “fix” also messes with nolightmapped models (I really don't know how are usually lit nolightmapped model but…):

before:

after:

VFS case sensitivity

It looks like VFS case sensitive while loading dpkdir, but case insensitive while loading dpk. Historic behavior for pk3 seems to be case insensitive, do pk3dir/dpkdir have to be case insensitive too?

We can also decide to keep the case sensitivity behavior of pk3dir/dpkdir to force mapper to fixes their names. ( ͡° ͜ʖ ͡°)

We can also decide that pk3 zip is case insensitive because of legacy stuff but dpk is sensitive for newer stuff (has to be implemented) and in this case there is no big need to take care of pk3dir case insensitivity since it's stupid to do legacy pk3dir when you can do a clean and modern dpkdir yourself.

autodownload broken if pak name larger than 64 bytes

I noticed that the feature of loading an extrapak in a subdirectory now breaks the autodownload mechanism, basically the pak name does not look complete.

We were able to do before:

./daemon -set fs_extrapaks dev/backport

We are only able to do now:

./daemon -set fs_extrapaks backport

It may have been broken in #14 (effort to rewrite the TimePath's original effort to support legacy pk3).

Design for game-specific customization and mods

We have not yet decided how game-specific customization for the engine is going to work. One attempt was #16, but people found some problems with it. It is important to realize that there are some game-specific things in the engine that are more complicated than just replacing a string, such as:

List of teams for team-specific key binds (1) (2)
Differing meaning of surface flags in maps: #107

One question is: Should one be able to run any Daemon game using the same Daemon binary, or should game details be baked into the engine's executable? Some people think that it is desirable to be able to use the same Daemon executable, but personally I don't see any tangible benefit from this. To share the same engine binary between installations of multiple games seems to be an obviously bad idea for many reasons (ping me if you disagree), so I am assuming that each game installation will have its own copy of daemon. Given that, game-independence has no benefit to the user or even to developers that I can see. Nevertheless, I am not opposed to loading configuration at runtime if it actually works the best from a technical point of view.

The obvious alternative that I see would be to have a configuration header file defined by each game, which is included into the engine when building it. This header would contain the definitions like #define PRODUCT_NAME "Xonotic" or const char* const bindTeams[] = {"spectators", "humans", "aliens"};. There could be a default definitions file for building daemon by itself for CI or whatever. Not a particularly pretty solution, but neither is having to write a parser for various types of constants.

Mods

It would be good idea to think about the design for mods too, since we might be able to reuse some configuration mechanisms between games and mods within a game. Some of the issues a mod system needs to address:

Ensure that files downloaded by mods can never affect the main game.
Decide which parts of the user's configuration (key bindings, cvars...) should have per-mod instances, versus be shared among all mods. In the case of key bindings, a mod may need its own configuration if it defines many new commands. On the other hand, if a mod uses exactly the same controls but mod-specific configuration is used (assumed to be generated on the first play by copying the base game's bindings), it would be annoying that a stale copy of the keybindings is used every time after the first time it is played.
Be robust against mod developer cluelessness. Imagine a mod system where a mod identifies itself by simply declaring its name. And then mod "foo" is allowed to write packages in the "mods/foo" directory. But you know that some guy who wants to create a mod completely unrelated to the foo mod is going to start out by copying the foo source tree, modifying a lot, but neglecting to ever change the name of the mod. Then if the user visits servers hosting both kinds of "foo" mod, both mods are broken afterwards.

sgame support for the new Cmd System

The new Cmd System doesn't allow to pass clientNum to its commands in the sgame

https://github.com/Unvanquished/Unvanquished/blob/e2966661aea62a4b86a4dd7b099b7ce261fcaf17/src/sgame/sg_api.cpp#L119-L124

As a result the sgame has no convenient way to know who called the command, which is required for many of them.

A simple StaticCmd registration (sgame namspace) also seems not yet to work as expected.

Proposal: Log spam suppression

This is a proposed mechanism to avoid the console being swamped by spammy log messages (for example if one starts printing every frame). The idea is that a log message be suppressed if it uses a format string used more than (approximately) Q times in the last T milliseconds.

Log filtering is done at the module level (i.e. one each for engine, cgame, sgame). A buffer contains records of the N (say 50) most recent unique format strings used for log messages. Besides the format string, the record contains an initial time (for the T ms period), a most recently seen time, number of times seen, and whether the message has been disabled. When a log message is received, the record for it is updated if it exists; otherwise the least recently seen message is removed. When updating a record, if T milliseconds have passed since the initial time, the initial time and count are reset. If the count reaches Q, then the message is disabled, and remains disabled until it drops out of the cache. A message like "Suppressing further messages of this type" is printed.

Naturally, there will be a cvar to disable log suppression (if you really want to see that debug message printed every frame). Log suppression should not used for messages printed by commands as they often print lengthy lists, and are usually triggered by the user's request. For messages that are known to legitimately print a lot of times, such as the list of loaded paks, there can be an API to log while bypassing the filter.

Can't change console size without quitting the engine first

This is something I discovered while working on #161.

To change console size, people have to tweak cl_consoleFontSize then to quit the engine entirely before starting it again. Doing vid_restart is not enough.

It means people have to quit the currently played game to resize the console font.

I don't know if it's a bug or if it's a design issue. It may be a design issue since the console is probably one of the earliest things that is spawned but I hope it's not and I hope a fix can be easily implemented.

symbolic links unsupported in archives

It looks like the engine does not support symbolic links in archives, Xonotic makes use of that, for example:

Warn: R_LoadDDSImage: invalid dds header "dds/textures/trak5x/floor/floor_floor2a.dds" 
Warn: R_FindImageFile could not find image 'textures/trak5x/floor/floor_floor2a.tga' in shader 'textures/trak5x/floor-floor2a'

The dds/textures/trak5x/floor/floor_floor2a.dds is in fact a symbolic link to a file named floor_floor2a_gloss.dds in the same directory.

Cross-compilation is broken

Hi guys,

I might have found a bug in the new include-bin generator process for glsl when cross-compiling:
basically, since the tool is cross-compiled you cannot run it on the host during the build process and that makes CMake complaining about missing binary and it doesn't generate the glsl include files.

From a quick search on the internet it seems there is not an easy solutinon to this (they suggest a 2-pass build).

R_LoadDDSImage: compressed texture images must be power of two

Dæmon fails to load some Xonotic textures, here is an example:

Warn: R_LoadDDSImage: compressed texture images must be power of two "dds/textures/map_xoylent/border_big.dds" 
Warn: R_FindImageFile could not find image 'textures/map_xoylent/border_big.tga' in shader 'textures/map_xoylent/border_big' 
Warn: Shader textures/map_xoylent/border_big has a colormap stage with no image

You can find the file there: border_big.dds

Note that crunch is able to convert this dds file back to tga without complaining.

adaptative lighting

I just noticed yesterday that XreaL had adaptative lighting (sometime called HDR), and gh's wip tremulous has it too. That's something I would like to see in Unvanquished since ages but I didn't know the code was already there somewhere. What is preventing us to get that effect in Dæmon?

Organization name change.

@DaemonDevelopers/owners, what's your thoughts on renaming this organization to DaemonEngine? It's shorter, which is nice because the current name is too long to fully display inside "Repositories you contribute to", and it's also more descriptive, showing that this organization hosts a (game) engine and its tools. (Unfortunately, just Daemon is taken by a GitHub user.)

Right now it's easy to make such a rename as the engine wasn't fully outsourced from Unvanquished just yet, but this is bound to happen very soon.

missing cvar to disable deluxeMap rendering

There is currently no cvar to disable deluxeMap rendering. Being able to switch deluxeMap on and off is useful to check if a bug is related to deluxeMap or not.

[duplicate] bad translucent texture depth on rsmse map

This is an issue similar to #120 (broken water translucency on station15 map) except the translucency is not faulty opaque, only the depth issue is visible. It also occurs on translucent textures too.

If I remember correctly the depth is correct when normalmaps are disabled.

suprising md3 loading behavior (trying to load <basename>_[123].md3)

All these models are there, and it looks like they are correctly displayed in-game (hence correctly loaded).

Debug: Failed to open 'models/fx/metal_gibs/m_gib8_3.md3' for reading: No such file or directory 
Debug: Failed to open 'models/fx/metal_gibs/m_gib8_2.md3' for reading: No such file or directory 
Debug: Failed to open 'models/fx/metal_gibs/m_gib8_1.md3' for reading: No such file or directory 
Debug: Failed to open 'models/fx/alien_gibs/a_gib4_3.md3' for reading: No such file or directory 
Debug: Failed to open 'models/fx/alien_gibs/a_gib4_2.md3' for reading: No such file or directory 
Debug: Failed to open 'models/fx/alien_gibs/a_gib4_1.md3' for reading: No such file or directory

Any md3 laying in package raises this error:

Debug: Failed to open 'models/generic/sphere_3.md3' for reading: No such file or directory 
Debug: Failed to open 'models/generic/sphere_2.md3' for reading: No such file or directory 
Debug: Failed to open 'models/generic/sphere_1.md3' for reading: No such file or directory 
Debug: Failed to open 'models/generic/sphericalCone64_3.md3' for reading: No such file or directory 
Debug: Failed to open 'models/generic/sphericalCone64_2.md3' for reading: No such file or directory 
Debug: Failed to open 'models/generic/sphericalCone64_1.md3' for reading: No such file or directory 
Debug: Failed to open 'models/generic/sphericalCone240_3.md3' for reading: No such file or directory 
Debug: Failed to open 'models/generic/sphericalCone240_2.md3' for reading: No such file or directory

It does not prevent the game to be played though.

The error is displayed while using set logs.logLevel.default debug.

partial void effect on station15 tree model

See that weird void effect at the tip of the conifer branch:

It must look like this:

Note that the bug seems to occur on the collision with the plant leaf model. For information, there is also an alphagen brush in source map at this place:

This bug looks somewhat related to that bug noticed in wolf:et map (at least for the tree):
Unvanquished/Unvanquished#799 (comment)

weird patterns on translucent textures

This bug affects the for-0.51.0 branch, I cannot reproduce with a 0.50.0 build and I haven't tried master.

Look at these screenshots of the hangar28 maps by tvezet and the thunder one by EmperorJack:

The translucency looks obviously wrong. That's not a compression fault (I have not recompressed the thunder's textures and it's rendered right on 0.50.0 but rendered wrong on for-0.51.0).

These is the two related shaders:

The one used in thunder map, from map-thunder package:

textures/thunder/nexusglass
{
	qer_editorimage textures/thunder/nexusglass
	qer_trans .40
	surfaceparm trans
	cull none
	{
		map textures/thunder/nexusglass
		blendfunc add
		rgbGen const ( 0.01 0.01 0.01 )
	}
	{
		map $lightmap 
		blendfunc gl_dst_color gl_src_alpha
		rgbGen identity
		tcGen lightmap 
	}
}

The one used in hangar28 from tex-trak5 package:

textures/shared_trak5/glass
{
	qer_editorImage     textures/shared_trak5_src/glass_p
	qer_trans           0.30

	cull                none
	surfaceparm         trans

	{
		map       textures/shared_trak5_src/glass_d
		stage     diffuseMap
		blend     blend
	}
}

GitHub organization structure.

Right now we have

a set of owners,
a team of developers who can write to all repositories (@DaemonDevelopers/developers), and
teams for both Unvanquished and Xonotic.

I added the latter two teams so that both Unvanquished and Xonotic admins can add developers without the other side wondering who this new person is and where they come from. (For instance, I just added @illwieckz who is already an Unvanquished developer.) These teams do not come with any additional permissions. We can add more such teams (e.g. Independent) when the need arises.

I think we do not need the Developers team, as we can just give write access to all repositories to every organization member, without also requiring them to be on any team. What do you think?

Error compiling Crypto.cpp: invalid conversion from ‘unsigned char’ to ‘char’

On Arch Linux 4.13.12 using gcc-multilib 7.2.0:

…/daemon/src/engine/framework/Crypto.cpp: In function ‘Crypto::Data Crypto::Encoding::Base64Encode(const Data&)’:
…/daemon/src/engine/framework/Crypto.cpp:165:26: error: invalid conversion from ‘unsigned char*’ to ‘char*’ [-fpermissive]
	 &ctx, output.data(), input.size(), input.data()
	       ~~~~~~~~~~~^~
In file included from …/daemon/src/engine/framework/Crypto.cpp:34:0:
/usr/include/nettle/base64.h:98:1: note:   initializing argument 2 of ‘size_t nettle_base64_encode_update(base64_encode_ctx*, char*, size_t, const uint8_t*)’
 base64_encode_update(struct base64_encode_ctx *ctx,
 ^
…/daemon/src/engine/framework/Crypto.cpp:167:70: error: invalid conversion from ‘unsigned char*’ to ‘char*’ [-fpermissive]
     encoded_bytes += nettle_base64_encode_final( &ctx, output.data() + encoded_bytes );
	                                                ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
In file included from …/daemon/src/engine/framework/Crypto.cpp:34:0:
/usr/include/nettle/base64.h:106:1: note:   initializing argument 2 of ‘size_t nettle_base64_encode_final(base64_encode_ctx*, char*)’
 base64_encode_final(struct base64_encode_ctx *ctx,
 ^
…/daemon/src/engine/framework/Crypto.cpp: In function ‘bool Crypto::Encoding::Base64Decode(const Data&, Crypto::Data&)’:
…/daemon/src/engine/framework/Crypto.cpp:187:64: error: invalid conversion from ‘const unsigned char*’ to ‘const char*’ [-fpermissive]
	                                input.size(), input.data() ) )
	                                              ~~~~~~~~~~^~
In file included from …/daemon/src/engine/framework/Crypto.cpp:34:0:
/usr/include/nettle/base64.h:158:1: note:   initializing argument 5 of ‘int nettle_base64_decode_update(base64_decode_ctx*, size_t*, uint8_t*, size_t, const char*)’
 base64_decode_update(struct base64_decode_ctx *ctx,
 ^
make[2]: *** [daemon_build/CMakeFiles/engine-lib.dir/build.make:879: daemon_build/CMakeFiles/engine-lib.dir/src/engine/framework/Crypto.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:516: daemon_build/CMakeFiles/engine-lib.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

void speed bug

When you move fast (like a goon can), the skybox sometime fills itself with pure white color as if it was void. It's very easy to reproduce on atcshd map:

random segfault on map change

we still suffer from random crashes on map change, I got it logged on gdb:

Thread 31 "daemon" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff95140700 (LWP 29722)]
0x00007fff9d89fb25 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0

Thread 31 (Thread 0x7fff95140700 (LWP 29722)):
#0  0x00007fff9d89fb25 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#1  0x00007fff6a454095 in Rocket::Core::Lua::LuaEventListener::ProcessEvent (this=0x7fff6ce62020, event=...)
    at ./Unvanquished/libs/libRocket/Source/Core/Lua/LuaEventListener.cpp:128
#2  0x00007fff6a35de88 in Rocket::Core::EventDispatcher::TriggerEvents (this=0x7fff6cee2e70, event=0x7fff6f818390)
    at ./Unvanquished/libs/libRocket/Source/Core/EventDispatcher.cpp:182
#3  0x00007fff6a35dc2f in Rocket::Core::EventDispatcher::DispatchEvent (this=0x7fff6cee2e70, target_element=0x7fff6cd0ffa0, name=..., parameters=..., 
    interruptible=false) at ./Unvanquished/libs/libRocket/Source/Core/EventDispatcher.cpp:146
#4  0x00007fff6a329115 in Rocket::Core::Element::DispatchEvent (this=0x7fff6cd0ffa0, event=..., parameters=..., interruptible=false)
    at ./Unvanquished/libs/libRocket/Source/Core/Element.cpp:1053
#5  0x00007fff6a31b7ea in Rocket::Core::RKTEventFunctor::operator() (this=0x7fff9513ea40, element=...)
    at ./Unvanquished/libs/libRocket/Source/Core/EventIterators.h:55
#6  0x00007fff6a31cbbe in std::for_each<__gnu_cxx::__normal_iterator<Rocket::Core::ElementReference*, std::vector<Rocket::Core::ElementReference, std::allocator<Rocket::Core::ElementReference> > >, Rocket::Core::RKTEventFunctor> (__first={element = 0x7fff6cd0ffa0}, __last={element = 0x7fff6fddf3f0}, __f=...)
    at /usr/include/c++/7/bits/stl_algo.h:3884
#7  0x00007fff6a31b593 in Rocket::Core::Context::SendEvents (old_items=std::set with 3 elements = {...}, new_items=std::set with 0 elements, event=..., 
    parameters=..., interruptible=false) at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:1221
#8  0x00007fff6a319c42 in Rocket::Core::Context::OnFocusChange (this=0x7fff7d2319a0, new_focus=0x7fff6cd0ffa0)
    at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:913
#9  0x00007fff6a328f3a in Rocket::Core::Element::Focus (this=0x7fff6cd0ffa0)
    at ./Unvanquished/libs/libRocket/Source/Core/Element.cpp:991
#10 0x00007fff6a31725d in Rocket::Core::Context::UnloadDocument (this=0x7fff7d2319a0, _document=0x7fff7d6ebe10)
    at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:309
#11 0x00007fff6a317430 in Rocket::Core::Context::UnloadAllDocuments (this=0x7fff7d2319a0)
    at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:327
#12 0x00007fff6a3162fc in Rocket::Core::Context::~Context (this=0x7fff7d2319a0, __in_chrg=<optimized out>)
    at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:82
#13 0x00007fff6a316508 in Rocket::Core::Context::~Context (this=0x7fff7d2319a0, __in_chrg=<optimized out>)
    at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:98
#14 0x00007fff6a427cea in Rocket::Core::ContextInstancerDefault::ReleaseContext (this=0x7fff7d838750, context=0x7fff7d2319a0)
    at ./Unvanquished/libs/libRocket/Source/Core/ContextInstancerDefault.cpp:52
#15 0x00007fff6a31b655 in Rocket::Core::Context::OnReferenceDeactivate (this=0x7fff7d2319a0)
    at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:1228
#16 0x00007fff6a396b13 in Rocket::Core::ReferenceCountable::RemoveReference (this=0x7fff7d2319a0)
    at ./Unvanquished/libs/libRocket/Source/Core/ReferenceCountable.cpp:73
#17 0x00007fff6a1ff1f8 in Rocket_Shutdown () at ./Unvanquished/src/cgame/rocket/rocket.cpp:403
#18 0x00007fff6a182461 in CG_Shutdown () at ./Unvanquished/src/cgame/cg_main.cpp:1611
#19 0x00007fff6a15280b in VM::<lambda()>::operator()(void) const (__closure=0x7fff9513f897)
    at ./Unvanquished/src/cgame/cg_api.cpp:73
#20 0x00007fff6a155836 in Util::apply_impl<VM::VMHandleSyscall(uint32_t, Util::Reader)::<lambda()>, std::tuple<> >(VM::<lambda()> &&, std::tuple<> &&, Util::seq<>) (func=..., tuple=...) at ./Daemon/src/common/Util.h:138
#21 0x00007fff6a1551f4 in Util::apply<VM::VMHandleSyscall(uint32_t, Util::Reader)::<lambda()>, std::tuple<> >(VM::<lambda()> &&, std::tuple<> &&) (func=..., 
    tuple=...) at ./Daemon/src/common/Util.h:143
#22 0x00007fff6a153f29 in IPC::detail::HandleMsg<VM::VMHandleSyscall(uint32_t, Util::Reader)::<lambda()>, IPC::Message<IPC::Id<0, 2> >, IPC::Reply<> >(IPC::Channel &, IPC::SyncMessage<IPC::Message<IPC::Id<0, 2> >, IPC::Reply<> >, Util::Reader, VM::<lambda()> &&) (channel=..., reader=..., func=...)
    at ./Daemon/src/common/IPC/Channel.h:217
#23 0x00007fff6a1532ae in IPC::HandleMsg<IPC::SyncMessage<IPC::Message<IPC::Id<0, 2> > >, VM::VMHandleSyscall(uint32_t, Util::Reader)::<lambda()> >(IPC::Channel &, Util::Reader, VM::<lambda()> &&) (channel=..., reader=..., func=...) at ./Daemon/src/common/IPC/Channel.h:241
#24 0x00007fff6a152ba9 in VM::VMHandleSyscall (id=2, reader=...) at ./Unvanquished/src/cgame/cg_api.cpp:72
#25 0x00007fff6a2b749a in CommonInit (rootSocket=22) at ./Daemon/src/shared/VMMain.cpp:66
#26 0x00007fff6a2b75fe in vmMain (rootSocket=22) at ./Daemon/src/shared/VMMain.cpp:104
#27 0x00005555559316cd in VM::<lambda()>::operator()(void) const (__closure=0x55555e5b6008)
    at ./Daemon/src/engine/framework/VirtualMachine.cpp:352
#28 0x0000555555932c13 in std::__invoke_impl<void, VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> >(std::__invoke_other, VM::<lambda()> &&) (__f=...) at /usr/include/c++/7/bits/invoke.h:60
#29 0x00005555559329ba in std::__invoke<VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> >(VM::<lambda()> &&) (__fn=...) at /usr/include/c++/7/bits/invoke.h:95
#30 0x0000555555932e90 in std::thread::_Invoker<std::tuple<VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x55555e5b6008) at /usr/include/c++/7/thread:234
#31 0x0000555555932e4c in std::thread::_Invoker<std::tuple<VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> > >::operator()(void) (this=0x55555e5b6008) at /usr/include/c++/7/thread:243
#32 0x0000555555932e1c in std::thread::_State_impl<std::thread::_Invoker<std::tuple<VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> > > >::_M_run(void) (this=0x55555e5b6000) at /usr/include/c++/7/thread:186
#33 0x00007ffff46000ff in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#34 0x00007ffff3dbf7fc in start_thread (arg=0x7fff95140700) at pthread_create.c:465
#35 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 18 (Thread 0x7fff9c223700 (LWP 27265)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fff9000864c)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x7fff90009c10, cond=0x7fff90008620) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x7fff90008620, mutex=0x7fff90009c10) at pthread_cond_wait.c:655
#3  0x00007ffff1290a38 in pa_threaded_mainloop_wait () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#4  0x00007ffff5d01f99 in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#5  0x00007ffff5d06fe7 in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#6  0x00007ffff3dbf7fc in start_thread (arg=0x7fff9c223700) at pthread_create.c:465
#7  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 17 (Thread 0x7fff9706a700 (LWP 27264)):
#0  0x00007ffff3ae0951 in __GI___poll (fds=0x7fff9000ca60, nfds=3, timeout=381) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff1290451 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x00007ffff1281e10 in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x00007ffff12824a0 in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#4  0x00007ffff1282530 in pa_mainloop_run () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#5  0x00007ffff1290399 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#6  0x00007fffee185ed8 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-10.0.so
#7  0x00007ffff3dbf7fc in start_thread (arg=0x7fff9706a700) at pthread_create.c:465
#8  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 14 (Thread 0x7fff9ffff700 (LWP 27257)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556b4cb24)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556b4cad0, cond=0x555556b4caf8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556b4caf8, mutex=0x555556b4cad0) at pthread_cond_wait.c:655
#3  0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007ffff3dbf7fc in start_thread (arg=0x7fff9ffff700) at pthread_create.c:465
#6  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 10 (Thread 0x7fffbcb48700 (LWP 27252)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba18d8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba1888, cond=0x555556ba18b0) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556ba18b0, mutex=0x555556ba1888) at pthread_cond_wait.c:655
#3  0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007ffff3dbf7fc in start_thread (arg=0x7fffbcb48700) at pthread_create.c:465
#6  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 9 (Thread 0x7fffbd349700 (LWP 27251)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba18d8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba1888, cond=0x555556ba18b0) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556ba18b0, mutex=0x555556ba1888) at pthread_cond_wait.c:655
#3  0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007ffff3dbf7fc in start_thread (arg=0x7fffbd349700) at pthread_create.c:465
#6  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 8 (Thread 0x7fffbdb4a700 (LWP 27250)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba17f4)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba17a0, cond=0x555556ba17c8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556ba17c8, mutex=0x555556ba17a0) at pthread_cond_wait.c:655
#3  0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007ffff3dbf7fc in start_thread (arg=0x7fffbdb4a700) at pthread_create.c:465
#6  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7fffbe34b700 (LWP 27249)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba17f4)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba17a0, cond=0x555556ba17c8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556ba17c8, mutex=0x555556ba17a0) at pthread_cond_wait.c:655
#3  0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007ffff3dbf7fc in start_thread (arg=0x7fffbe34b700) at pthread_create.c:465
#6  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 6 (Thread 0x7fffbeb4c700 (LWP 27248)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba17f4)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba17a0, cond=0x555556ba17c8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556ba17c8, mutex=0x555556ba17a0) at pthread_cond_wait.c:655
#3  0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007ffff3dbf7fc in start_thread (arg=0x7fffbeb4c700) at pthread_create.c:465
#6  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7fffbf34d700 (LWP 27247)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556bebc98)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556bebc48, cond=0x555556bebc70) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556bebc70, mutex=0x555556bebc48) at pthread_cond_wait.c:655
#3  0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007ffff3dbf7fc in start_thread (arg=0x7fffbf34d700) at pthread_create.c:465
#6  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7fffc02b6700 (LWP 27246)):
#0  0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556b9e3ac)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556b9e358, cond=0x555556b9e380) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556b9e380, mutex=0x555556b9e358) at pthread_cond_wait.c:655
#3  0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007ffff3dbf7fc in start_thread (arg=0x7fffc02b6700) at pthread_create.c:465
#6  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffe6354700 (LWP 27243)):
#0  0x00007ffff3dca060 in __libc_accept (fd=4, addr=..., len=0x0) at ../sysdeps/unix/sysv/linux/accept.c:26
#1  0x000055555592c1b9 in Sys::ReadSingletonSocket () at ./Daemon/src/engine/framework/System.cpp:242
#2  0x000055555592f09e in std::__invoke_impl<void, void (*)()> (__f=@0x5555569e7fd8: 0x55555592c18b <Sys::ReadSingletonSocket()>)
    at /usr/include/c++/7/bits/invoke.h:60
#3  0x000055555592eb55 in std::__invoke<void (*)()> (__fn=@0x5555569e7fd8: 0x55555592c18b <Sys::ReadSingletonSocket()>) at /usr/include/c++/7/bits/invoke.h:95
#4  0x000055555592feb2 in std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul> (this=0x5555569e7fd8) at /usr/include/c++/7/thread:234
#5  0x000055555592fe6e in std::thread::_Invoker<std::tuple<void (*)()> >::operator() (this=0x5555569e7fd8) at /usr/include/c++/7/thread:243
#6  0x000055555592fe3e in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run (this=0x5555569e7fd0)
    at /usr/include/c++/7/thread:186
#7  0x00007ffff46000ff in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007ffff3dbf7fc in start_thread (arg=0x7fffe6354700) at pthread_create.c:465
#9  0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fffe6e24700 (LWP 27242)):
#0  0x00007ffff3ab0bf8 in __GI___nanosleep (requested_time=requested_time@entry=0x7fffe6e23920, remaining=remaining@entry=0x7fffe6e23920)
    at ../sysdeps/unix/sysv/linux/nanosleep.c:27
#1  0x00007ffff3ab0aea in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#2  0x000055555592c987 in Sys::SignalThread () at ./Daemon/src/engine/framework/System.cpp:373
#3  0x000055555592f09e in std::__invoke_impl<void, void (*)()> (__f=@0x5555569e7998: 0x55555592c864 <Sys::SignalThread()>)
    at /usr/include/c++/7/bits/invoke.h:60
#4  0x000055555592eb55 in std::__invoke<void (*)()> (__fn=@0x5555569e7998: 0x55555592c864 <Sys::SignalThread()>) at /usr/include/c++/7/bits/invoke.h:95
#5  0x000055555592feb2 in std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul> (this=0x5555569e7998) at /usr/include/c++/7/thread:234
#6  0x000055555592fe6e in std::thread::_Invoker<std::tuple<void (*)()> >::operator() (this=0x5555569e7998) at /usr/include/c++/7/thread:243
#7  0x000055555592fe3e in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run (this=0x5555569e7990)
    at /usr/include/c++/7/thread:186
#8  0x00007ffff46000ff in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x00007ffff3dbf7fc in start_thread (arg=0x7fffe6e24700) at pthread_create.c:465
#10 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7ffff7f66a80 (LWP 27233)):
#0  0x00007ffff3dcae50 in __libc_recvmsg (fd=21, msg=0x7ffffffeced0, flags=0) at ../sysdeps/unix/sysv/linux/recvmsg.c:28
#1  0x000055555598edcd in NaClReceiveDatagram (handle=21, message=0x7ffffffecfd0, flags=0)
    at ./Daemon/libs/nacl/native_client/src/shared/imc/linux/nacl_imc.cc:168
#2  0x00005555558bec1b in IPC::InternalRecvMsg (handle=21, reader=...) at ./Daemon/src/common/IPC/Primitives.cpp:374
#3  0x00005555558bf232 in IPC::Socket::RecvMsg (this=0x555556234d80 <cgvm+128>)
    at ./Daemon/src/common/IPC/Primitives.cpp:457
#4  0x00005555556c6f7c in IPC::Channel::RecvMsg (this=0x555556234d80 <cgvm+128>)
    at ./Daemon/src/common/IPC/Channel.h:111
#5  0x00005555556c6ff7 in IPC::Channel::RecvReplyMsg (this=0x555556234d80 <cgvm+128>)
    at ./Daemon/src/common/IPC/Channel.h:121
#6  0x0000555555711cbd in IPC::detail::SendMsg<void VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>()::{lambda(unsigned int, Util::Reader)#1}&, IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<>>(IPC::Channel&, void VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>()::{lambda(unsigned int, Util::Reader)#1}&, IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >) (channel=..., messageHandler=...)
    at ./Daemon/src/common/IPC/Channel.h:168
#7  0x000055555570e31a in IPC::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >, void VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>()::{lambda(unsigned int, Util::Reader)#1}>(IPC::Channel&, void VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>()::{lambda(unsigned int, Util::Reader)#1}&&) (
    channel=..., messageHandler=...) at ./Daemon/src/common/IPC/Channel.h:234
#8  0x000055555570bf94 in VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>() (
    this=0x555556234d00 <cgvm>) at ./Daemon/src/engine/framework/VirtualMachine.h:136
#9  0x00005555556f420c in CGameVM::CGameShutdown (this=0x555556234d00 <cgvm>)
    at ./Daemon/src/engine/client/cl_cgame.cpp:1092
#10 0x00005555556f2c8d in CL_ShutdownCGame () at ./Daemon/src/engine/client/cl_cgame.cpp:324
#11 0x0000555555752c8c in CL_ShutdownAll () at ./Daemon/src/engine/client/cl_main.cpp:719
#12 0x0000555555752d09 in CL_FlushMemory () at ./Daemon/src/engine/client/cl_main.cpp:755
#13 0x0000555555754d56 in CL_DownloadsComplete () at ./Daemon/src/engine/client/cl_main.cpp:1854
#14 0x0000555555755142 in CL_InitDownloads () at ./Daemon/src/engine/client/cl_main.cpp:1996
#15 0x0000555555768181 in CL_ParseGamestate (msg=0x7ffffffedb20) at ./Daemon/src/engine/client/cl_parse.cpp:466
#16 0x0000555555768bd8 in CL_ParseServerMessage (msg=0x7ffffffedb20) at ./Daemon/src/engine/client/cl_parse.cpp:780
#17 0x0000555555757776 in CL_PacketEvent (from=..., msg=0x7ffffffedb20) at ./Daemon/src/engine/client/cl_main.cpp:2756
#18 0x0000555555663525 in HandlePacketEvent (event=...) at ./Daemon/src/engine/qcommon/common.cpp:925
#19 0x000055555566389d in Com_EventLoop () at ./Daemon/src/engine/qcommon/common.cpp:1024
#20 0x000055555566451f in Com_Frame () at ./Daemon/src/engine/qcommon/common.cpp:1518
#21 0x000055555576cd5b in Application::ClientApplication::Frame (this=0x55555625a020 <Application::GetApp()::app>)
    at ./Daemon/src/engine/client/ClientApplication.cpp:80
#22 0x00005555558f467c in Application::Frame () at ./Daemon/src/engine/framework/Application.cpp:75
#23 0x000055555592df75 in main (argc=24, argv=0x7fffffffde88) at ./Daemon/src/engine/framework/System.cpp:695

broken rotating texture

See these two videos: 1, 2, two fans are rotating wrongly in parpax map, while the others are rotating as expected. For example in the ventilation hall, the one near the tank room is wrong, but not the other one in the same hall.

There is one crazy fan in ventilation hall (near tank room):

And one in ventilation (near alien base):

These fans look to just be spinning textures. I noticed similar rotating fan bug in some other maps like the metro map by KOsAD. The same map has correct rotating fan while loaded on Tremulous and has crazy fan while loaded on Unvanquished. That's why I think it's a renderer bug.

Parpax used to have more broken fans but these fan were removed once some geometry was redone. This bug is very old (I always seen it).

	// trace line against all surfaces in the leaf
	for ( k = 0; k < leaf->numLeafSurfaces; k++ )
	{
	surface = cm.surfaces[ cm.leafsurfaces[ leaf->firstLeafSurface + k ] ];

	if ( !surface )
	{
	continue;
	}

	// load character sets
	cls.charSetShader = re.RegisterShader( "gfx/2d/bigchars", RSF_DEFAULT );
	cls.useLegacyConsoleFont = cls.useLegacyConsoleFace = true;

	// Register console font specified by cl_consoleFont, if any
	// filehandle is unused but forces FS_FOpenFileRead() to heed purecheck because it does not when filehandle is nullptr
	if ( cl_consoleFont->string[0] )
	{
	if ( FS_FOpenFileRead( cl_consoleFont->string, &f, false ) >= 0 )
	{
	re.RegisterFont( cl_consoleFont->string, nullptr, cl_consoleFontSize->integer, &cls.consoleFont );
	cls.useLegacyConsoleFont = false;
	}

	FS_FCloseFile( f );
	}