Valve disabled stencil shadows in the latest WON and steam HL releases for no apparent reason.
Stencil shadows was disabled in Xash3D too, because some mods inject GL_StudioDrawShadows function in game libraries.
An example:
https://github.com/nekonomicon/hlsdk-xash3d/blob/zombie-x/cl_dll/hud.cpp#L363
https://github.com/nekonomicon/hlsdk-xash3d/blob/zombie-x/cl_dll/StudioModelRenderer.cpp#L36
https://github.com/nekonomicon/hlsdk-xash3d/blob/zombie-x/cl_dll/StudioModelRenderer.cpp#L1754

But this hack will work only on x86 windows.
What about other platforms?

I tried to launch xash3d-fwgs engine on my router (latest commit, big endian), but it seems to be almost broken on this architecture.

Issues list:
map loading dosen't work (first, the engine says that map has invalid format, then it says that map dosen't have a valid spawn point, after commenting that checks, the engine crash at the map load)
wads loading dosen't work

The issues list is not full, because i still can't resolve the map loading issue

here's the terminal output, compiling on Ubuntu 16.04 amd64 with x86 support enabled, compiling for x86

(xenial)saiko@localhost:~/xash3d-fwgs$ ./waf configure --build-type=release --vgui=vgui-dev
Setting top to                           : /home/saiko/xash3d-fwgs 
Setting out to                           : /home/saiko/xash3d-fwgs/build 
Build type                               : release 
Checking for 'gcc' (C compiler)          : /usr/bin/gcc 
Checking for 'g++' (C++ compiler)        : /usr/bin/g++ 
Checking git hash                        : 245533d 
Checking if 'gcc' can target 32-bit      : no 
...trying with additional flags          : yes 
NOTE: will build engine for 32-bit target
Checking for library dl                  : yes 
Checking for library m                   : yes 
Checking for library pthread             : yes 
--> engine                               : in progress 
Checking for library SDL2                : yes 
Checking for library SDL2 sanity         : yes 
<-- engine                               : done 
--> game_launch                          : in progress 
<-- game_launch                          : done 
--> mainui                               : in progress 
Checking if 'gcc' supports C++11         : no 
...trying with additional flags          : no 
Checking for program 'pkg-config'        : /usr/bin/pkg-config 
Checking for 'freetype2'                 : yes 
Checking for 'fontconfig'                : yes 
<-- mainui                               : done 
--> vgui_support                         : in progress 
Configuring VGUI by provided path        : yes: [':vgui.so'], ['/home/saiko/xash3d-fwgs/vgui-dev/lib'], ['/home/saiko/xash3d-fwgs/vgui-dev/include'] 
Checking for library VGUI sanity         : no 
Can't compile simple program. Check your path to vgui-dev repository.
(complete log in /home/saiko/xash3d-fwgs/build/config.log)

Hey just a suggestion,
Opposed to using OpenVR which is limited to Steam VR supported headsets. It would probably be beneficial to support Open XR instead. Why I say this is that Xash could support a wider variety of VR headsets via this API.

More details here -> https://www.roadtovr.com/openxr-1-0-release-microsoft-hololens-vr-oculus-rift-quest/

Здравствуйте, возможно кто-то сталкивался с подобным или же алмины знают решение данной проблемы.
Поставил кеш, который использовался ранее без нареканий, скачал из маркета xash3d & cs16client, во время первой же игры заметил, что игра не воспринимает более 2 нажатий, при попытке превысить "лимит" нажатия полностью сбрасываются.
Для полного понимания проблемы просьба просмотреть прикреплённое видео(извиняюсь за качество, но суть видна).
vk.com/video209996335_456239331
Заранее спасибо!

Аппарат Redmi Note 3 Pro
Havoc 9.0

We need to check if client.dll actually have direct dependency on SDL2. If so, we can assume that this game uses HLSDK2.4 input code and we may enable SDL2 relative mouse mode.

Should we keep this feature?

Pros:

• Easy to revert settings in menu.
• Separated from everything else.
• ...?

Cons:

• Isn't reverse-compatible to original Xash3D engine.
• May be not intuitive to old players, who knows that everything can be found in "config.cfg" always.

game_launch/game.cpp defines this:
#define GAME_PATH "valve" // default dir to start from
Can you make this a waf configure option so that users can build custom game launchers without editing the sources?

I've been trying to test a multiplayer map in my own fork, and was attempting to do this on my laptop without network connectivity. I only needed to run up a local server with me in it, so actual connectivity was not required.

If I go through the main menu to the multiplayer section and attempt to create a LAN game in this instance, I get the following error:

[17:51:01] Scanning for servers on the local network area...
[17:51:01] Host_Error: NET_SendPacket: Network is unreachable to 100.221.255.191:27015

Because of the host error, I then get taken back to the main menu and am unable to proceed in creating the local server. (Note that I'm running with -dev 5 - I dunno if the same would happen without that option).

My first thoughts on remedying this would be to allow an option to be passed to NET_SendPacket (and the other functions that the local server calls through to) to specify whether failures should be critical. Is this something that would be considered? I could put together a pull request for it if so.

As many players don't change their name in configurations, how about reading the current user name and use it as default?
For example,

BOOL GetUserNameA(LPSTR lpBuffer,LPDWORD pcbBuffer ); // for Windows
NSString * NSUserName(void); // for macOS

https://cdn.discordapp.com/attachments/471642430534582302/636632507504132137/2019-10-23_23-29-48.png

I moved compiled libserver.so to valve/dlls, but dlopen can't find and open libserver.so

I'm having issues running xash3d.exe when compiled on either of my Windows 10 machines, in either debug or release. When I run the executable I get the error:

Unable to load the xash.dll: The specified module could not be found.

I vaguely remember having issues with this before, so I tried to use Dependency Walker to see whether I could deduce what was wrong. Unfortunately when I try and profile the executable, Dependency Walker hangs (apparently indefinitely) after the implicit modules plus IMM32.dll have been loaded.

The engine build works as expected on my Ubuntu machine.

Subj.

I propose a new library naming scheme, which will allow to distribute mods and games in single archive to different operating systems and CPUs:

Legend:

• $os -- Q_buildos() return value, in lower case.
• $arch -- Q_buildarch() return value, in lower case.
• $ext -- OS-specific extension: dll, so, dylib, etc.

The scheme will be:

1. Client library:

• client.$ext for Win/Lin/Mac with x86.
• client_$arch.$ext for Win/Lin/Mac with NON-x86.
• client_$os_$arch.$ext for everything else.

2. Menu library:

• menu.$ext for Win/Lin/Mac with x86.
• menu_$arch.$ext for Win/Lin/Mac with NON-x86.
• menu_$os_$arch.$ext for everything else.

3. Server library:

• On Win/Lin/Mac with x86, it MUST use the raw gamedll name for corresponding OS field from gameinfo.txt.
• On Win/Lin/Mac with NON-x86, it MUST use the raw gamedll name for corresponding OS field from gameinfo.txt, but append _$arch before file extension. Like: hl_amd64.so or cs_e2k.so.
• On everything else, it must use gamedll name from gamedll_linux field, but append _$os_$arch before file extension. Like: hl_haiku_amd64.so or cs_freebsd_armhf.so.
  Why gamedll_linux and not gamedll? Because it looks more logic that way, most operating systems are *nix-like and share code with Linux, rather than Windows.

4. Refresh library: not needed, as RefAPI is not stable and it's not intended to distribute with mods.

For any libraries distributed with engine, naming scheme should be used more convenient for OS port.

Issue #0. Inconsistency between ABI and Q_buildarch.
Resolution: Change Q_buildarch return value to use Debian-styled architectures list: https://www.debian.org/ports/, which includes a special naming for big/little-endian and hard/soft-float ARM.

Issue #1: Build-system integration.
Resolution: extend MACRO_TO_DEST_CPU and MACRO_TO_DESTOS from Waf: https://gitlab.com/ita1024/waf/blob/master/waflib/Tools/c_config.py#L1002, if needed.

$subj.

I don't know how to connect them to custom renderers in client.dll: studio renderers, Paranoia-way or RenderAPI.

• For Paranoia-like or studio renderers we should restrict only for default renderer. The issue is in detecting when client.dll have custom renderer and when does not.
• For RenderAPI based we should:

1. Provide same functionality, so game creators can get custom renderer features just by copy-pasting DLL.
   1.1. How this must be compatible with original engine?
   1.2. How this can be compatible with already existing mods?
2. Or do nothing. Let them available only for default renderer, like for Paranoia-way.

P.S.

• Paranoia-way custom rendering is just to disable engine renderer with "clientonly" boolean in refdef and draw everything in HUD_DrawNormal/TransparentTriangles, maybe with opengl32.dll wrapper.
• StudioModelRenderer can override rendering studio models just by drawing them by client.dll and skipping some engine calls.

Дубль FWGS/xash3d#323
Общее:

• Не отображается Muzzleflash у Alien Grunt'ов(спрайт muz4.spr). Это немного затрудняет прохождение Afraid of Monsters: Director's Cut, так как в этом моде Alien Grunt'ы имеют прозрачные модели, а при стрельбе из hivehand должна отображаться улыбающаяся физиономия.(исправлено)
• Отображается Muzzleflash на Holster-анимации оружия.(Исправлено)
• Не работает на клиенте(с тач-управлением проблема не воспроизводится)(исправлено)
• Монстры не видят сквозь окна, вроде и не фатально, но ломает прохождение Azure Sheep на карте asmap04c(ученый не может открыть дверь, потому что не видит игрока).(исправлено)
• Монстров на движущихся платформах трясет во все стороны.
• Не отображаются прозрачные кастомные декали(Например из trusty pack или мода Echoes)(исправлено, но возможно проблема VBO)
• Не игнорируется bottom-left-ориентация tga-текстур.(исправлено)
• He отображается белый текст в меню в некоторых модах(только на Android).

Adrenaline Gamer:

• Красный флаг имеет синюю текстуру.
• Мерцание текстуры ctf_base на карте agctf_bootcamp под некоторым углом обзора.

Battlegrounds:

• Вылет

Big Scientists:

• Не отображаются большие модели под некоторым углом обзора.(Исправлено)

Deathmatch Classic:

• Неверный размер хуллов, из-за чего модели игроков проваливаются ногами в текстуры и возможны застревания на спауне.
• При падении в лаву игрок не получает урон, пока в ней не движется.(исправлено)
• Не отображается анимация lightninggun'а при cl_lw 1.(исправлено)
• Не отображается панель выбора оружия при cl_lw 0.(не баг)

Decay:

• Не отображаются анимации у лап вортигонта при cl_lw 1.

Echoes:

• Срабатывает assert на карте echoes21 при включеном VBO.(связан с VBO)

Sweet Half-Life:

• Вылет при стрельбе из плазмагана(в движке имеется assert для этого бага)(исправлено)

They Hunger:

• На загрузке сохранений глушитель у глока появляется не сразу(похоже GoldSrc имеет ту же проблему, но репредиктинг в оригинальном xash3d build 3598+ решает проблему)(возможно не баг)
• На загрузке сохранений пропадает зеленый фильтр у прицела снайперской винтовки.(возможно не баг)
• Не раскрывается пламя у огнемета(в оригинальном They Hunger и моем декомпиле, в версии от malortie оно реализано не через TE_PROJECTILE)(исправлено)
• На одной из карт поезд проходит сквозь цистерны
• На одной из последних карт вертолет, который должен обстреливать зомби, просто висит в воздухе.

ThreeWave CTF:

• Не отображается фон из fallback_dir(воспроизводится только на android)

Residual Life:

• Зависает скрипт в этом месте и охранник с зомби не двигаются пока игрок не убьет зомби.(исправлено)

Poke646 и Poke646: Vendetta:

• Из-за обнуления таймера глобального времени отрисовки HUD при смене карты, HUD может длительное время не отрисовываться.(не связано с движком)
• Не отображается прицел у арбалета( Не отрабатывает вызов HUD_DrawTransparentTriangles ).(не связано с движком)
• Заедание звука открытия двери на карте po_intro в Poke646.(исправлено)

Blue Shift:

• Баг с водой(связан с VBO)

Cleaner's Adventures:

• Баг с водой(связан с VBO)
• Отображение черно-розовых квадратов вместо текстур при частых загрузках сохранений(исправлено)

Top-Down:

• Вместо модели player в синглплеере используется модель gordon или любая другая модель, выбранная для мультиплеера.(воспроизводится только с включенным режимом разработчика)
• Не меняется body-модель у модели игрока(воспроизводится только с включенным режимом разработчика)

Opposing Force:

• Черный экран при переходе с карты of0a0 на карту of1a1

https://github.com/FWGS/xash3d-fwgs/blob/master/ref_gl/gl_rsurf.c#L2913

maps == MAX_LIGHTMAPS

В цикле идёт проверка на то что maps меньше MAXLIGHMAPS ( 4 )

for( maps = 0; maps < MAXLIGHTMAPS && fa->styles[maps] != 255; maps++ ) { if( tr.lightstylevalue[fa->styles[maps]] != fa->cached_light[maps] ) { is_dynamic = true; break; } }

maps == MAX_LIGHTMAPS будет не правдимым в любом случае, так как MAX_LIGHMAPS равен 256

• For modern Android we can use MediaCodec available in NDK since even 5.0. It provides low-level access to audio/video decoders/encoders and almost perfectly fits for our needs. OpenMAX AL is completely useless.
• For generic support we still should provide GStreamer or FFmpeg backend.
• And obviously stub for those who don't want a dependency.

I don't think we really need hardware decoder here, as playing just short intros and logos in menu isn't a complicated task for modern CPUs. One exception is videos in XashXT, but AFAIK nothing uses them, except demo.

Help is still needed here. :)

LTO generates position-depended code and fails to link without -fPIC in linker

I'm probably going to swap my own fork from the original Xash3D engine to this one, so that I have the opportunity of adding stuff upstream that would be more useful here than in the other engine.

My first question is: would a cross-platform set of compilation tools be considered valuable? I've found a set of the ZHLT compile tools that compiles successfully for me on Linux: https://github.com/tyabus/zhlt-linux

I'm probably going to be adding these to my own fork because, in my seemingly eternal pursuit of importing Nightfire maps, it's proving a better course of action to recompile existing maps with a slightly modified textures lump than to attempt to convert compiled BSPs to be compatible with Half-Life. I wanted to check here first, in case they'd be a useful addition upstream. It would require me learning how to use Waf, though.

Hi, I cant make xash3d to make even run!!

ive put all the libs and the executable on the same folder and with

LD_LIBRARY_PATH=. ./xash3d
or
LD_LIBRARY_PATH=. ./xash3d --help

it doesnt output anything at all!
hope you could give me a clue

pi@raspberrypi:~/Desktop/xash3d-fwgs $ ./waf configure -T release --prefix=/home/pi/Desktop/xash3d-fwgs/build
Setting top to                           : /home/pi/Desktop/xash3d-fwgs 
Setting out to                           : /home/pi/Desktop/xash3d-fwgs/build 
Build type                               : release 
Checking for 'gcc' (C compiler)          : /usr/bin/gcc 
Target OS                                : linux 
Target CPU                               : arm 
Target binfmt                            : elf 
Checking for 'g++' (C++ compiler)        : /usr/bin/g++ 
Target OS                                : linux 
Target CPU                               : arm 
Target binfmt                            : elf 
Checking git hash                        : 8f47596 
Checking for program 'strip'             : /usr/bin/strip 
Checking if 'gcc' can target 32-bit      : yes 
Checking for library SDL2                : yes 
Checking for library SDL2 sanity         : yes 
Checking for library dl                  : yes 
Checking for library m                   : yes 
Checking for library pthread             : yes 
--> public                               : in progress 
<-- public                               : done 
--> game_launch                          : in progress 
<-- game_launch                          : done 
--> ref_gl                               : in progress 
<-- ref_gl                               : done 
--> mainui                               : in progress 
Checking if 'gcc' supports C++11         : yes 
Checking for program 'pkg-config'        : /usr/bin/pkg-config 
Checking for 'freetype2'                 : yes 
Checking for 'fontconfig'                : yes 
<-- mainui                               : done 
--> vgui_support                         : in progress 
Does this architecture support VGUI?     : no 
vgui is not supported on this CPU: arm
<-- vgui_support                         : done 
--> engine                               : in progress 
Checking for library SDL2                : yes 
Checking for library SDL2 sanity         : yes 
<-- engine                               : done 
'configure' finished successfully (1.626s)

I've been looking at this for the last couple of days but haven't had any success in tracking down the cause yet, so I thought I'd put some details down here in case they're helpful for diagnosis.

The Windows build looks very washed-out: https://media.discordapp.net/attachments/548621970187616268/589464898925232128/windows.png?width=1896&height=1133

Compare this to the Linux build, where the brightness seems more correct: https://media.discordapp.net/attachments/548621970187616268/589464938913988618/linux.png?width=2002&height=1133

I've determined that this is not due to the brightness/gamma settings tied to the console variables in the engine - they use the built gamma table, and if I set this to identity values or bypass it completely, there is still no change at all on Windows. With the table active, I can change the gamma and brightness and they do seem to affect the on-screen picture, but they only seem to be able to make it more washed-out, and never less so than in the above screenshot.

As an aside, the gamma table is currently being built every frame when running the main menu, because R_BeginFrame checks if FCVAR_CHANGED is set on the gamma and brightness cvars, but doesn't reset this flag once the table has been rebuilt. This doesn't fix the washed-out issue, but it's worth noting nonetheless.

I've also tried running with various video modes and OpenGL modes on Windows, but none of these has made any difference.

Just quickly noting this down before I forget, as I'm in the middle of other things.

I discovered today that I was forgetting to precache a model in some of my own game code, but only after having stepped through pfnSetModel in the debugger. Specifically, the following code seems to be to be incorrect:

// check to see if model was properly precached
for( i = 1; i < MAX_MODELS && sv.model_precache[i][0]; i++ )
{
    if( !Q_stricmp( sv.model_precache[i], name ))
        break;
}

if( i == MAX_MODELS )
{
    Con_Printf( S_ERROR "no precache: %s\n", name );
        return;
}

i incremented past the last precached model (which in my case was index 100), so the model returned was null. Instead of hitting the error log and returning, it silently set a blank model on my entity because i was still within the entire list bounds.

If there's a count for how many models have been precached in sv.model_precache, I think checking against this instead of MAX_MODELS would fix the issue.

We won't support OSX/iOS anymore because of destructive decisions Apple make.

Yesterday they removed 32-bit and ok, it's was kinda understandable.
Today they will remove OpenGL for no reason.
Tomorrow they will remove possibility of running native code.

Originally, OSX/iOS support was added because it was easy to maintain, but when it rеquires more action from us, I don't think we can support it without a dedicated maintainer for this platforms.

Platform code will not be removed, so someone can take it and continue support but I will remove OSX/iOS ports from autobuilds, will not provide them in releases, close all rеlated issues as WONTFIX and finally remove it from list of supported ports.

So, Apple, f*ck you.

I understand that the multiplayer mode is still largely untested and a bit buggy, so I was hoping to find out some more information about the following:

Some of my weapon sounds, when tested in multiplayer, ended up being completely different sound files to what was expected. I've narrowed it down to the fact that S_FreeSound is being called prematurely on the list of sounds created on precache, so sounds that are loaded in later take the place of the precached sounds in the s_knownSfx list.

The reason that sounds are being freed is that S_BeginRegistration/S_EndRegistration are being called more than once. Each time begin is called, s_registration_sequence is incremented. When end is called, any sounds whose sequence number doesn't match the current s_registration_sequence are freed. This seems to be what happens to all of my precached sounds.

The first time begin is called is on receipt of an svc_resourcelist message:

libxash.dylib!S_BeginRegistration (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/s_load.c:293)
libxash.dylib!CL_PrecacheResources (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_main.c:3161)
libxash.dylib!CL_BatchResourceRequest (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_parse.c:543)
libxash.dylib!CL_StartResourceDownloading (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_parse.c:632)
libxash.dylib!CL_ParseResourceList (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_parse.c:1682)
libxash.dylib!CL_ParseServerMessage (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_parse.c:2274)
libxash.dylib!CL_ReadNetMessage (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_main.c:2766)
libxash.dylib!CL_ReadPackets (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_main.c:2802)
libxash.dylib!Host_ClientFrame (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_main.c:3524)
libxash.dylib!Host_Frame (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/common/host.c:544)
libxash.dylib!Host_RunFrame (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/common/host_state.c:144)
libxash.dylib!COM_Frame (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/common/host_state.c:194)
libxash.dylib!Host_Main (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/common/host.c:1034)
bond!Sys_Start() (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/game_launch/game.cpp:134)
bond!main (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/game_launch/game.cpp:146)

And the second time appears to be because of the condition cls.signon == SIGNONS && cl.lastresourcecheck < host.realtime in CL_ReadPackets:

libxash.dylib!S_BeginRegistration (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/s_load.c:293)
libxash.dylib!CL_PrecacheResources (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_main.c:3161)
libxash.dylib!CL_BatchResourceRequest (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_parse.c:543)
libxash.dylib!CL_ReadPackets (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_main.c:2819)
libxash.dylib!Host_ClientFrame (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/client/cl_main.c:3524)
libxash.dylib!Host_Frame (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/common/host.c:544)
libxash.dylib!Host_RunFrame (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/common/host_state.c:144)
libxash.dylib!COM_Frame (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/common/host_state.c:194)
libxash.dylib!Host_Main (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/engine/common/host.c:1034)
bond!Sys_Start() (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/game_launch/game.cpp:134)
bond!main (/Users/vesper/Documents/afterburner-game/dependencies/afterburner-engine/game_launch/game.cpp:146)

Is there a reason that sound registration should be performed more than once, or is this incorrect behaviour?

[17:20:55] map: crossfire [17:20:55] num score ping name lastmsg address [17:20:55] —- —-— —---— —-----------— —---— —-----------------— —---- [17:20:55] 0 [17:20:55] 0 [17:20:55] Connect[17:20:55] Mr0maks[17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] 57.1995 [17:20:55] ip_here[17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] [17:20:55] 28683[17:20:55] [17:20:55]

The crash occurs in NET_Config, net_ws.c:1599. The socket is number 2168 on my machine, which doesn't look like an invalid value, but the stack trace shows that _invalid_parameter_noinfo is called by the close function.

System: Deepin (debian)

I have installed libsdl2-dev libsdl2-2.0 via apt, then also tried compiling SDL2 from source, but still missing SDL2.

I have searched what is SDL2 sanity but nothing found.

Here is the output:

$ ./waf configure --build-type=release --vgui=vgui-dev
Setting top to                           : /home/mr/Workspace/xash3d-fwgs 
Setting out to                           : /home/mr/Workspace/xash3d-fwgs/build 
Build type                               : release 
Checking for 'gcc' (C compiler)          : /usr/bin/gcc 
Checking for 'g++' (C++ compiler)        : /usr/bin/g++ 
Checking git hash                        : f2c9279 
WARNING: will build engine for 32-bit target
Checking if 'gcc' can target 32-bit      : no 
...trying with additional flags          : yes 
Checking for library SDL2                : yes 
Checking for library SDL2 sanity         : no 
Checking for library dl                  : yes 
Checking for library m                   : yes 
Checking for library pthread             : yes 
--> public                               : in progress 
<-- public                               : done 
--> engine                               : in progress 
Checking for library SDL2                : yes 
Checking for library SDL2 sanity         : no 
SDL2 not availiable! If you want to build dedicated server, specify --dedicated
(complete log in /home/mr/Workspace/xash3d-fwgs/build/config.log)

Sorry for bothering you.

I've always preferred the Software mode style liquid effect to the hardware accelerated D3D/OpenGl texture warping liquid effect. I think it would be nice to have a CVar to toggle the default OpenGL liquid effect with the Software mode one. Something like: "gl_software_liquid" as the toggle, for example.

Example of the Software liquid effect: https://www.youtube.com/watch?v=DHgtWODyUUo

hud_scale result in crosshair draw in wrong position

I hate to raise another issue, but I've been attempting to solve this for most of the day and haven't been able to get anywhere.

When I launch a debug build of the engine in the VS Code debugger, breakpoints are ignored and the stack frames are listed with "unknown source". The only way I've been able to debug on Windows is by using waf msdev and opening a full Visual Studio project, which isn't ideal as I have VS Code all set up on my own fork for various tasks.

My configure call is:

python waf configure --build-type=debug --prefix=build/install --sdl2=C:\Users\Vesper\Documents\SDL2-2.0.9 --vgui=C:\Users\Vesper\Documents\GitHub\vgui-dev

When I run waf build install, the compile calls then look like:

[128/231] Compiling game_launch\game.cpp
07:26:59 runner ['C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\HostX86\x86\CL.exe', '/nologo', '/nologo', '/nologo', '/D_USING_V110_SDK71_', '/Zi', '/FS', '/Od', '/Igame_launch', '/I..\game_launch', '/Icommon', '/I..\common', '/I..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\ATLMFC\include', '/I..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include', '/I..\..\..\..\..\..\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um', '/I..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt', '/I..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared', '/I..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um', '/I..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt', '/I..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\cppwinrt', '/DXASH_BUILD_COMMIT="37181e4-dirty"', '..\game_launch\game.cpp', '/FC', '/c', '/FoC:\Users\Vesper\Documents\GitHub\xash3d-fwgs\build\game_launch\game.cpp.1.o']

And the link calls look like:

[143/231] Linking build\game_launch\xash3d.exe
07:27:01 runner ['C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\HostX86\x86\LINK.exe', '/nologo', '/MANIFEST', '/nologo', '/MANIFEST', '/nologo', '/MANIFEST', '/DEBUG', '/subsystem:WINDOWS,5.01', 'game_launch\game.cpp.1.o', 'game_launch\game.res', '/OUT:C:\Users\Vesper\Documents\GitHub\xash3d-fwgs\build\game_launch\xash3d.exe', '/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\ATLMFC\lib\x86', '/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\lib\x86', '/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86', '/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x86', '/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x86', '/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\ATLMFC\lib\x86', '/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\lib\x86', '/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\lib\x86\store\references', '/LIBPATH:C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.18362.0', '/LIBPATH:C:\Program Files (x86)\Windows Kits\10\References\10.0.18362.0', '/LIBPATH:C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319', 'user32.lib', 'shell32.lib']

However, when linking I get a lot of suspect spam about PDB files (one message per object, in all sub-projects):

game.cpp.1.o : warning LNK4099: PDB '' was not found with 'game.cpp.1.o' or at ''; linking object as if no debug info

I suspect this is related, but I'm not sure what in the build process would cause the PDB path to show up as blank like this.

I know that my version of VS Code is capable of debugging applications because I've done so with other projects - one that I know works uses compile flags /MDd /EHsc /ZI /FS and link flags /DEBUG:FASTLINK /MACHINE:X64. I've tried swapping some of the compile flags in the Xash build script to see what would happen (for example, adding /MDd and removing /O1), but nothing has succeeded so far.

Is there any reason that this may be happening?

1. The "disconnect" button works as a restart.
2. Water bug on both gles renderers like there
   
3. Black screen after minimizing engine
4. Black bars instead of text in the console when playing hazard course (64bit version only)
   

I suggest moving to C99 standard.
We actually never supported old compilers, so it shouldn't be a problem.

Instead we get:

• possibility to define variables not only at start of the block.
• VA_ARGS(supported in msvc, but support is still partial and may be buggy)
• better inline
• stdint.h
• restrict keyword
• compound literals(msvc sucks here)
• designated initializers.
• more UB
• ...

Yes, it's hard to implement C99 fully in compilers, but standards are theoretical(especially C99) and anyway we can still use implemented subset of C99.

Subj.

The custom.hpk was generated by GoldSource previously and when it put to Xash3D, bah, it crashes on validating resources(don't have backtrace).

Reference file. Rename custom.hpk.zip back to custom.hpk. GitHub limitations. 🤷‍♂️
custom.hpk.zip

Long-pressing arrow keys does not repeating field cursor movement

Please upload binaries to GitHub Releases:
https://github.com/FWGS/xash3d-fwgs/releases

The original Xash3DS was available for the 3DS, is that planned here?

Tested with latest binary release and macOS 10.14.2
Where can I get the required 32-bit SDL2?
I can't build 32-bit SDL2 with current Xcode because i386 arch is deprecated now by Apple.

In my standalone mod based on XashXT 0.81, the main asset directory is base, and localised assets are in mw_en (for English) and mw_ru (for Russian). In base/gameinfo.txt, gamedir is set to "mw_en".
Both mw_en and mw_ru contain a titles.txt file, and there is no titles.txt in base.
When I launch the game without the -game parameter, env_message entities don't show any text. However, when I launch it with -game mw_ru, the messages work fine.
With the original Xash3D, they work as expected in both cases.

I really do like the idea of a GPL gldsrc clone, however after some research I've discovered a bit of an issue.

The engine is somewhat notorious for making use of leaked source code, and indeed Valve as supposedly remarked that the engine as it stands is illegal (though I have yet to personally corroborate that.) This is troublesome because I want to use xash3D for a commercial project, so as it currently stands that dream is unworkable. But what if it wasn't?

I turned to the codebase and I've picked out all the obvious files that violate Valve's copyright:

• common/weaponinfo.h
• common/beamdef.h
• common/entity_state.h
• common/net_api.h
• common/r_studioint.h
• common/demo_api.h
• common/r_efx.h
• common/kbutton.h
• common/const.h
• common/netadr.h
• common/con_nprint.h
• common/usercmd.h
• common/studio_event.h
• common/pmtrace.h
• common/cvardef.h
• common/ref_params.h
• common/wadfile.h
• common/screenfade.h
• common/event_args.h
• common/mathlib.h
• common/qfont.h
• common/triangleapi.h
• common/cl_entity.h
• common/event_flags.h
• common/event_api.h
• common/dlight.h
• common/hltv.h
• common/particledef.h
• common/entity_types.h
• common/ivoicetweak.h
• engine/alias.h
• engine/studio.h
• engine/keydefs.h
• engine/customentity.h
• engine/anorms.h
• engine/custom.h
• engine/edict.h
• engine/cdll_int.h
• engine/progdefs.h
• engine/shake.h
• engine/sprite.h
• engine/eiface.h
• pm_shared/pm_defs.h
• pm_shared/pm_movevars.h
• pm_shared/pm_info.h

I'm not sure about any snippets of code that might violate Valve's copyright, so I'll perform a more indepth analysis to check if any exist. I doubt much if any such snippets exist, so barring that; If we rewrite these headers, the legal and licensing issues associated with this project should be resolved and full GPL compliance will be achieved.

I noticed that when running the Mac version of the engine, the call to Mod_LoadModel when loading a map crashes when returning from the Mem_Free call at the end of the function. The debugger reports a 0x0 address access, but it's not immediately clear where (or why) this actually happens.

I've narrowed the issue down to being introduced in commit 741fcfb202f81b1468403ad6cf4b70c10d2ce2d2, which modifies the compiler flags. The only real relevant difference is that the optimisation flag -O0 get changed to -O1 for clang. If I change this back to -O0, the crash disappears.

I'm not sure how to go about solving this.