iortcw / iortcw Goto Github PK

The whole build is full of the same error :
make: "/home/Adrien2002/iortcw-1.42d/SP/Makefile" line 2849: Missing dependency operator
make: "/home/Adrien2002/iortcw-1.42d/SP/Makefile" line 2851: Need an operator

I just download the sources, entered in SP folder and wrote "make" as described in the README. Maybe the NetBSD part in the Makefile is not compatible anymore with how NetBSD is nowadays, I'm not an expert at all about it. If we success to build it, I'll port it to pkgsrc.

Is there a specific reason why so many libraries are included in the repo instead of compiling using system libs like most other idtech source ports? Due to the SP/MP split all are included twice, in fact.

On OSX this is creating a conflict with user installed openal-soft that results in a crash on iortcw startup unless it is uninstalled or USE_OPENAL_DLOPEN is set to 0 in the makefile.

Compiling with USE_LOCAL_HEADERS=0 is also broken due to the header path being wrong (does not include "SDL2/"). It only disables SDL2 and OpenAL local headers too, libcurl libogg libvorbis opus libjpeg etc are all still internal.

I have created a fork and will work on removing all 3rd party libs/headers from the repo. Once I am done I will create a pull request.

Going into Options\System\Graphics and changing the Graphics preset produces a yellow error box with the following messages (depends on the preset):

Error: Restricted source tried to set "cl_renderer" to "rend2"
Error: Restricted source tried to set "cl_renderer" to "opengl1"

Does not crash the game, just returns to the main menu. I can set the renderer manually via console, just the settings don't really work as intended. :-(

iortcw 1.51b-SP win_mingw64-x64 Aug 16 2017
SSE instruction set enabled
----- FS_Startup -----
Current search path:
C:\Users\upton\Documents\RTCW\main
D:\SteamLibrary\steamapps\common\Return to Castle Wolfenstein\main\sp_rend2_shaders0.pk3 (5 files)
D:\SteamLibrary\steamapps\common\Return to Castle Wolfenstein\main\sp_pak4.pk3 (21 files)
D:\SteamLibrary\steamapps\common\Return to Castle Wolfenstein\main\sp_pak3.pk3 (14 files)
D:\SteamLibrary\steamapps\common\Return to Castle Wolfenstein\main\sp_pak2.pk3 (232 files)
D:\SteamLibrary\steamapps\common\Return to Castle Wolfenstein\main\sp_pak1.pk3 (1342 files)
D:\SteamLibrary\steamapps\common\Return to Castle Wolfenstein\main\pak0.pk3 (4775 files)
D:\SteamLibrary\steamapps\common\Return to Castle Wolfenstein\main
c:/program files (x86)/steam\SteamApps\common\Return To Castle Wolfenstein\main

6389 files in pk3 files

WARNING: main/pak0.pk3 is present but its checksum (1349421837)
is not correct. Please re-copy pak0.pk3 from your
legitimate RTCW CDROM.

The normal exe works fine.

Pressing alt-tab sometimes creates a vid_restart loop. It keeps going until game is shut down with either quit or task manager shutdown. Then Documents\RTCW\wolfconfig_mp.cfg must be deleted to prevent the same upon startup. There are no differences between new good and old bad wolfconfig_mp.cfg except
cg_selectedPlayer
cg_selectedPlayerName
variables , which should not matter

I don't know how high this is on the TODO list as I noticed this is present from the very first version of iortcw released so you are probably aware of that.

When using map command to start map, the jerky movement at the start is not present, but when using spmap, it is.

I don't know what causes it, it happens only for short period of time, but is still quite annoying.
Like the SP server was "lagging" after giving player the control.

I couldn't find the cause of it unfortunately.

This issue is present on two of my machines and occures on both on Windows 10 64-bit and ArchLinux 64-bit.
I'm compiling from latest sources, 64-bit binaries.

Not a real "issue" but a simple question: what is this package? :|

Hello,

it is possible to launch iortcw and specify the path of the game in the config file or in the command line instead of copy iortcw files and folder in the game folder?

So, I installed this source port, and been playing it a bit. Works great, much better than the original game, but I ran into an issue where if I load a saved game (whether it be through quick load or the load game menu in the pause menu) the ESC key doesn't work anymore, nor does the Quick Load key. As a result, I have to ALT-F4 (Since I can't press ESC to get to the quit game menu) and then relaunch the game to load my saves from the main menu. Any insight on this? Hopefully I have provided enough information to explain the problem. Thank you.

P.S. I used one of the "releases" versions, because I am not proficient enough to compile it myself.

Hi everyone,

I have had much success setting up an ioquake3 dedicated server on my Mac Mini Server...not so much with iortcw. Q3 starts up no issue and works fine, but I am getting some sort of error with RTCW. I will include the Terminal text from when the server starts up and automatically shuts down. Hopefully someone can give me some insight into what the issue is.

Terminal Saved Output 2.txt

.pk3dir support is in iortcw MP. It should be able to be merged into SP.

On 64-bit Windows build, when I open console, iortcw tries to load OpenAl32.dll, but there's none in the game folder so it loads the one stored in System32.

Renaming OpenAl64.dll in game folder to OpenAl32.dll seems to do the work for now but it should definitely be dealt with somehow.

I see two solutions:

• renaming OpenAl64.dll to OpenAl32.dll inside libs
• do some checking inside code

The DO_REF_STR in your Makefile looks like this

define DO_REF_STR
$(echo_cmd) "REF_STR $<"
$(Q)rm -f $@
$(Q)echo "const char *fallbackShader_$(notdir $(basename $<)) =" >> $@
$(Q)cat $< | sed -e 's/^/\"/;s/$$/\\n\"/' | tr -d '\r' >> $@
$(Q)echo ";" >> $@
endef

On my system, this puts literal newline character before end quote, resulting to corrupted .c files being generated.
My solution to this issue was to modify the part with sed to
$(Q)cat $< | sed -e 's/^/\"/;s/$$/\\\n\"/' | tr -d '\r' >> $@

Also, you could rewrite your sed expression as a whole to
$(Q)cat $< | sed 's/.*/"&\\\n"/' | tr -d '\r' >> $@

It's shorter and (at least to my eyes) more elegant, but that's up for you.

Hi,

I've located the Spanish dub, which trigger this warning, like the french one:

**************************************************
WARNING: main/sp_pak1.pk3 is present but its checksum (652879493)
is not correct. Please re-copy sp_pak1.pk3 from your
legitimate RTCW CDROM.
**************************************************

file main/sp_pak1.pk3?es
255164624 bytes
md5= 99a26bcd4b8511f8f43576a37a7ccbdb

The game works perfectly, even when I didn't bother to recode scrips/translastions.cfg
from a CRLF fila to a unixy one.

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/commit/?id=06c54202670aae47a23ab97edc6df0c6458542f5

Hello, game Works pretty great with iortcw besides one gripe.
When loading a new mission the arrow that is supposed to pop in at the lower corner is missing so i have to click bllindly hoping to hit it. This does not allways Work however.
It only seems to happen when using rend2.

I have cg_autoactivate set to "0" but it's not working (items are gathered automatically)

I don't know why and how OpenAL causes this exactly, but whenever I press G key (kicking) I can't kick.

This issue was not present in 1.51 and when I tried to track it down in latest source here, I found out there is something wrong with updated OpenAL library, as when I replaced new OpenAL DLL in my build folder with the old one from 1.51, I was suddenly able to kick!

I tried it many times, it is easily reproducible.

NOTE: It could be caused by some GCC optimization, as I found out the bug is not present at all when using Debug build instead of Release one. But it is still somehow tied up to OpenAL, as I tried to build the working version 1.51 myself (to see if it is not some issue with the compiler...) and everything works fine even with all optimizations.

I'm using MSYS2's MinGW32 32bit compiler with COMPILE_ARCH=x86 to generate 32bit executables.

The file writing checks you merged recently appear to be a security fix, so it would be a good idea to do a 1.51 release with them, either from master or by backporting them onto a branch starting at 1.5a.

(Backporting them into Debian now.)

https://github.com/iortcw/iortcw/blob/master/MP/code/cgame/cg_draw.c

ab6ca55#diff-4786a6184d5e18fe119c9917c381718eR3517

Line 3517 has a colon (:) instead of a semicolon (;)

Change/Revert

CG_FillRect( 0, 0, 640, 480, color ):

to

CG_FillRect( 0, 0, 640, 480, color );

This allows it to compile correctly. I was able to compile the game w/o any issues before the current commit as well.

To play online some servers require to have a CD-Key set.
I tried to enter mine in the Settings but it cannot be entered.
The cursor just keeps blinking while typing.

System Info:
Arch Linux
Gnome Shell
Nvidia GTX 660 (Driver 375.20)

On the mac version i am unable to enter the cd key for some reason.

I can reasign mapped keys under keyboard config fine, type in console, enter letters in the very last box of key and even tab between the boxes but for some reason it doesnt register any keys in the first 4 boxes

This is on a macbook pro

sw_vers
ProductName: Mac OS X
ProductVersion: 10.11.4
BuildVersion: 15E65

It looks as though the iortcw version numbers are intended to be treated like decimal floating-point: 1.4 < 1.41 < 1.5. However, version numbers are usually sorted as though they were vectors of integers: for example, Linux 3.2, 3.9, 3.10, 3.11 were released in that order. Package management tools like dpkg and RPM assume the vector-of-integers interpretation.

Please could you use versions like 1.50b, 1.51a or 1.60a for future releases, so that both interpretations lead to the version numbers being sorted in the same order?

(For now, I'm going to prepare Debian packages for 1.5a as though it had been versioned 1.50a.)

I noticed many of my shots didn't connect when they clearly should. Also, physics behaved weirdly, mouse felt more stuttery,...
I found these issues was not present in the Debug build.

Looking at the Makefile -ffast-math is enabled in Release. Removing this and recompiling fixed the issues so this can clearly be attributed to this compiler flag.

-ffast-math
Sets the options -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans, -fcx-limited-range and -fexcess-precision=fast.
This option causes the preprocessor macro FAST_MATH to be defined.
This option is not turned on by any -O option besides -Ofast since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.

I think it should be removed.
I didn't experience any perceptual drop in performance without it so it just adds salt into injury without helping curing it in any mandatory way.

Also another issue I noticed a long time ago is fading in general.

Audio functions for sound related fading are all stubs, so that is kind of expected (should be implemented though somehow...).
Scene fading has some problem too.
It seems to be problem when engine tells the game to fade, but than comes startCamera with startBlack parameter set. If scene fading was caused by the engine (for example by pressing ESC during cutscene) and StartCamera is called, the value is overwritten by it, effectively starting fadein/fadeout when it shouldn't.

This can be seen nicely in the very first cutscene when you try to for example skip it.
Audio is not faded (for obvious reasons) and scene just fades out and than back in after startCam is called.

This is not behaviour with the original engine.
This issue is present at least on 64-bit linux and windows builds. I'm compiling from latest sources here.

Hello,

I upgraded to ubuntu 16.10 and when I compile iortcw, I can no more launch it directly from the explorer files (Nautilus), only from a terminal like this:
$ ./iortcw64
Do you think it is related to this:
https://wiki.ubuntu.com/SecurityTeam/PIE ?
Is iortcw compiled by default with pie on or off?

Iortcw is not the only open source software concerned by this Ubuntu change:
I had the same bug with Dolphin-emu (https://bugs.dolphin-emu.org/issues/9853), mame or nuke32.

Thank you for your help.

LGDN

I recorded it here so you can see what I mean...
https://www.youtube.com/watch?v=GlXHlE80SQI

It happens when I load a game and quickly press ESC to open ingame menu.
I would fix it myself but I don't really know where to look at (just getting familiarized with the source...)

I'm suspecting some buffer not getting cleared properly.

It happens with both renderering backends, opengl1 and rend2.

NOTE: I would suggest blocking opening of ingame menu during load, as it seems kind of 'not efficient' to do so anyway, and it would also get rid of a bug in a way too. But it is just a suggestion.

Like how vkquake does it. a simple .sln file we have to double click, clean, select version and build it.

I already have visual studio and cmake. I would have to have to download another application for one file build.

The readme file states of a wolf.sln that dosen't exist btw.

The Readme files in both the SP and MP folder reference COPYING.txt, but it doesn't seem to be included.

*r_swapinterval 1 -> CL_Initgame=1 minute (!)
*max anisotropy autoset to 2 (instead of 16) with a GeForce GTX 1050 Ti, lastest drivers

I have US and other (russian) layouts selected from windows settings. Most common way of switching keyboards is ALT+SHIFT which can be pressed a lot during gameplay and keyboard flips EN-RU-EN all the time.

The issue with iortcw is the cl_consoleKeys functionality breaks the 100% responsiveness to tilde key.

Console appears fine if the KB layout happens to be EN (50% of the time)
The other 50% nothing happens when i press tilde, so i have to switch layout first.

I figure this is a breaking change following the iortcw philosophy of only introducing optional changes switched off by default.

When my KB layout is different i get char ъ , which is hex 0x3f
When i type this key in console i get J (latin capital j) - which is also different from rtcw. Hex - 0x4a

So i thought implementing this would work

seta cl_consoleKeys "~ ` 0x7e 0x60 0x3f J 0x4a"

But nothing happens.

I think the priority should be given to original code of TILDE key and then cl_consoleKeys logic.

PS: as mentioned above, non-US keyboard input produces garbage. It always did, but it produces different garbage than before. I would be a nice feature if iortcw recognized the keystrokes and
either

1. translated them from RU back to basic EN automatically to avoid errors (best)
   OR
2. Like Quake live allowed unicode characters (latin and others) (no point really)

i have russian pack of game with addons:
Return To Castle Wolfenstein (just original game with russian lang)
game/tye/sp_pak8.pk3 4361abed69e586e055c48d15fe4655445870cd76 SHA1
game/main/pak0.pk3 069fa3c0476402452d8b639af6e5eb10d2368df0 SHA1
Operation Trondheim 1 - Special Forces
game/trond/sp_pak8.pk3 5ec44a614662618e67fd8f28deb3cc315dc41edf SHA1
Operation Trondheim 2 - Red Alert
game/redalert/sp_pak8.pk3 0a2e6cf7daea7d46dde6675eeac6a173d37504e4 SHA1
Operation Trondheim 3 - Iron Cross
game/ironcross/sp_pak8.pk3 cb736368de51b13f4b769e703594496260e643b5 SHA1
Return To Castle Wolfenstein - Project 51
game/p51/sp_pak8.pk3 caafaa78b9daade64aa8ba052483d4bce2d02cec SHA1
Return To Castle Wolfenstein - Time Gate
game/gate/sp_pak8.pk3 e942a54bdedb7d751cfcce2d8432fa417f8c42ce SHA1
Return To Castle Wolfenstein - Stalingrad
game/stalingrad/sp_pak8.pk3 900398d91dfc9f117a5aace96b6a35eaed1f282c SHA1

Return To Castle Wolfenstein - Saboteur
game/main/pak0.pk3 153f5afe2641960b8c76463dbddb95765bb088d3 SHA1

Return To Castle Wolfenstein - The Curse of the Pharaohs

and cant run any of this becouse iortcw want only original english version
how to torn off checksum?

Hi, i have:
Ryzen 2400G
Kubuntu 18.04 with Kernel 4.18.8
2560x1440 monitor

and i have low 30 - 50 FPS. Half Life 2 runs with 60fps flat in that resolution, everything on highest.

none of the usual fixes help, r_primitives "2" does nothing.

CPU is bored to death for the most part, i cant even see a difference between running the game or not running it.

i don't know what to do next.

Version: iortcw master(133cb06)
System: Mac
Message: Unpure client detected invalid pk3 files referenced.
When: Trying to join a mp server

pk3s
MD5 (main/mp_bin.pk3) = 7651d02fe51fc8a949536f3e0cfa8dd6
MD5 (main/mp_pak0.pk3) = 62641cffd9a8ad0f62cc1cca867d51f8
MD5 (main/mp_pak1.pk3) = 22b972974f499a237c96a2200b0d019e
MD5 (main/mp_pak2.pk3) = 30f29ffa81748a957e0441af8c14cb56
MD5 (main/mp_pak3.pk3) = fdc00dfd72b888e92a4387e1933826e4
MD5 (main/mp_pak4.pk3) = c5f76bbde262eba577a00bebe9cd4f8f
MD5 (main/mp_pak5.pk3) = d17df62d6c71078ed137aefc69d80f30
MD5 (main/mp_pakmaps0.pk3) = f2d361a0082ed9bc1e26d2327b4f22db
MD5 (main/mp_pakmaps1.pk3) = d1856aa9bc62f719a400428b9ec27ebb
MD5 (main/mp_pakmaps2.pk3) = a0ee8714c6f7ee72680293778c22d6ee
MD5 (main/mp_pakmaps3.pk3) = 01bb7c4fb3b11273d75ae658fb4de0cc
MD5 (main/mp_pakmaps4.pk3) = a39525809f7a0780f5546063dad1e5d1
MD5 (main/mp_pakmaps5.pk3) = bb24fb011b0f4b84335c66a869d1ab1c
MD5 (main/mp_pakmaps6.pk3) = 397e0b48673a1a8e0ec25eb0f3ccae9d
MD5 (main/pak0.pk3) = ce92b11df889cb0a045762bb5fd7cde5
MD5 (main/sp_pak1.pk3) = a0d3fe956f85f40c8efd6babe0d09832
MD5 (main/sp_pak2.pk3) = 330b272d5261fe19fcf3c3fbc943c7f3
MD5 (main/sp_pak3.pk3) = cf25d6731ed29c80303febbb177aa585
MD5 (main/sp_pak4.pk3) = 4223cc6588594ec0ceee186f0e73a6e9

try run build at lubuntu 18.04.
log https://paste.ubuntu.com/p/j6q9mDPBKT/

but i can run the same files set with https://github.com/id-Software/RTCW-SP (if I do not confuse) at lubuntu 14.04. The same hardware.

Hello,

Building iortcw 1.5a from source on linux (slackware 14.1/14.2) fails with error :

make[2]: *** No rule to make target '../.git/index', needed by 'build/release-linux-x86_64/client/cl_console.o'. Stop.

I checked the Makefile and found that error is due to the line #2661 which makes reference to file ../.git/index that is not part of source archive. Since line #2662 and #2663 make reference to this file as well, I removed these lines and compilation went well this time.

It seems that issue comes from commit d6094c

--
SeB

Hi I have purchased the most recent version of RTCW from GOG and installed it in a windows 7 VM.
I've downloaded the latest release of IORTCW for 64bit linux and copied over the Main directory from the the installed RTCW to the IORTCW directory.

Upon executing ./iowolfsp.x86_64 I get the following in the crashlog.

am@seattle:~/Downloads/iortcw-1.51b-linux-x86_64$ cat /home/am/.wolf/main/crashlog.txt
iortcw 1.51b-SP linux-x86_64 Aug 16 2017
SSE instruction set enabled
----- FS_Startup -----
Current search path:
/home/am/.wolf/main
./main/sp_pak4.pk3 (21 files)
./main/sp_pak3.pk3 (14 files)
./main/sp_pak2.pk3 (232 files)
./main/sp_pak1.pk3 (1342 files)
./main/pak0.pk3 (4775 files)
./main

---

6384 files in pk3 files
execing default.cfg
execing wolfconfig.cfg
execing autoexec.cfg
Minimum com_hunkMegs is 128, allocating 128 megs.
Hunk_Clear: reset the hunk ok
Bypassing CD checks
----- Client Initialization -----
Couldn't read rtcwhistory.
Cmd_AddCommand: map_restart already defined
----- Initializing Renderer ----
Trying to load "renderer_sp_opengl1_x86_64.so" from "."...
---- Renderer Initialization Complete ----
RTCWKEY found.
----- Client Initialization Complete -----
----- R_Init -----
SDL using driver "x11"
Initializing OpenGL display
Display aspect: 1.778
...setting mode 3: 640 480
Using 24 color bits, 24 depth, 8 stencil display.
Available modes: '1920x1080 720x400 1280x800 1440x900 640x480 800x600 1024x768 1152x864 1280x1024'
GL_RENDERER: Mesa DRI Intel(R) Ivybridge Desktop
Initializing OpenGL extensions
...using GL_EXT_texture_compression_s3tc
...using GL_EXT_texture_env_add
...using GL_ARB_multitexture
...using GL_EXT_compiled_vertex_array
...ignoring GL_EXT_texture_filter_anisotropic
Initializing Shaders
^3WARNING: In shader file scripts/common.shader...Shader "textures/sfx/portal3a_back2" on line 822 is missing closing brace^3.
^3WARNING: In shader file scripts/ui_wolf.shader...Invalid shader name "}" on line 1849.
----- finished R_Init -----
------ Initializing Sound ------
Trying to load "libopenal.so.1"...
Allocated 128 sources.
OpenAL default capture device is 'Built-in Audio Analogue Stereo'
OpenAL capture device opened.
OpenAL info:
Vendor: OpenAL Community
Version: 1.1 ALSOFT 1.16.0
Renderer: OpenAL Soft
AL Extensions: AL_EXT_ALAW AL_EXT_DOUBLE AL_EXT_EXPONENT_DISTANCE AL_EXT_FLOAT32 AL_EXT_IMA4 AL_EXT_LINEAR_DISTANCE AL_EXT_MCFORMATS AL_EXT_MULAW AL_EXT_MULAW_MCFORMATS AL_EXT_OFFSET AL_EXT_source_distance_model AL_LOKI_quadriphonic AL_SOFT_block_alignment AL_SOFT_buffer_samples AL_SOFT_buffer_sub_data AL_SOFT_deferred_updates AL_SOFT_direct_channels AL_SOFT_loop_points AL_SOFT_MSADPCM AL_SOFT_source_latency AL_SOFT_source_length
ALC Extensions: ALC_ENUMERATE_ALL_EXT ALC_ENUMERATION_EXT ALC_EXT_CAPTURE ALC_EXT_DEDICATED ALC_EXT_disconnect ALC_EXT_EFX ALC_EXT_thread_local_context ALC_SOFTX_device_clock ALC_SOFTX_HRTF ALC_SOFT_loopback ALC_SOFTX_midi_interface ALC_SOFT_pause_device
Device: Built-in Audio Analogue Stereo
Available Devices:
Built-in Audio Analogue Stereo
Input Device: Built-in Audio Analogue Stereo
Available Input Devices:
Built-in Audio Analogue Stereo
Monitor of Built-in Audio Analogue Stereo
Sound initialization successful.

----- Client Shutdown (Client fatal crashed: VM_Create on UI failed) -----
RE_Shutdown( 1 )
Hunk_Clear: reset the hunk ok
OpenAL capture device closed.

VM_Create on UI failed

Can you please advise me on how I can debug this further.

thanks in advance

Launching the game on an Ubuntu 14.04.3 (64bit) or 15.04 (64bit) causes the game to reboot itself in an endless loop. I tried this both with the Open Source (default) driver and also the closed sourced Nvidia one - same result.

On Xubuntu 14.04.3 and Linux Mint 17 (both Ubuntu variants) this issue is not present, which leads me to suspect that this could be a conflict with the Unity Desktop Environment?

System Specs:

Intel i5-2400
8GB DDR3 1333MHZ
Geforce GTX 760 2GB

compilation terminated.
Makefile:2556: recipe for target 'build/release-linux-arm/renderer/tr_animation.o' failed
make[2]: *** [build/release-linux-arm/renderer/tr_animation.o] Error 1
make[2]: Leaving directory '/home/sem/iortcw/SP'
Makefile:1303: recipe for target 'targets' failed
make[1]: *** [targets] Error 2
make[1]: Leaving directory '/home/sem/iortcw/SP'
Makefile:1254: recipe for target 'release' failed
make: *** [release] Error 2

There are a couple of related issues in how iortcw deals with cgame/ui code in PK3 files, which I don't think can be fixed without breaking game mods designed for retail RTCW (although they can be mitigated).

I'm currently trying to get iortcw packages into Debian's contrib repository, so I'm looking for the least-bad trade-off that makes it secure while removing as little functionality as possible.

Vulnerability 1. Unpacking native code from PK3s

If an active PK3 file contains an appropriate native-code DLL for the platform and CPU, it will be unpacked into the filesystem and loaded as a module (library). If I understand correctly, in retail RTCW this was the only way to get a mod's executable code to be run by the engine, because retail RTCW didn't have the QVM bytecode interpreter. In iortcw it is still a desired feature, to be able to run mods that were designed to be compatible with retail RTCW, or join "pure servers" that are not running iortcw.

Because clients can be configured to auto-download PK3s for mods and other resources from servers, this means the server (or a man in the middle) can make the client run arbitrary native code of its choice, with the user's full privileges.

Vulnerability 2. Escaping from the QVM interpreter sandbox by creating native code

This is basically CVE-2011-3012: in retail Quake III Arena, QVM bytecode could open any file in the engine's data directory for writing, including native DLL files. QVM-based mods are meant to have limited access to the filesystem, because the interpreter acts as a (fairly weak) sandbox, but in this case they could escalate their privileges by writing out native DLLs of their choice, which would be loaded and executed with the user's full privileges next time the engine starts in the appropriate mode.

iortcw has most of the checks that were introduced to fix CVE-2011-3012 checks, but some of them were disabled in r133 because they broke the ability to unpack DLLs from PK3s. Again, auto-downloading is what makes this a plausible remote attack.

Possible solution 1. Disabling auto-downloading

If clients refuse to auto-download from servers, then servers cannot carry out this attack. cl_allowDownload is currently on-by-default in iortcw and off-by-default in ioquake3; the setting can be changed from its default in the GUI of each game.

Disabling auto-downloading - either by changing the default, or by forcibly disabling it such that it cannot be enabled - would prevent these attacks, but is a functionality loss. In particular, it has the collateral damage of removing the ability to auto-download non-executable content (maps), which is believed to be safe.

If the option remains present, it might also be useful to alter the UI so that toggling the option has a confirmation prompt, like I did for Debian's version of OpenArena: https://sources.debian.net/src/openarena/0.8.8-14/debian/patches/Request-confirmation-if-a-user-enables-auto-download.patch/

Possible solution 2. Disabling DLL unpacking and reinstating the CVE-2011-3012 checks

If DLL unpacking was disabled and the CVE-2011-3012 checks were brought back, then auto-downloading would be as safe as it is in ioquake3 (which is still not particularly safe, since I suspect a determined attacker can break out of the QVM sandbox, but it's better than nothing). However, this breaks existing mods, which are documented to be installed by simply dropping the PK3 file into the appropriate place; it's a trade-off.

One possibility would be to have a compile-time or runtime option that chooses between the two non-ideal situations: "safe, but mods don't work" and "unsafe for auto-downloading, but mods work"...

Possible solution 3. Distinguishing between auto-downloaded and manually-installed PK3s

I've opened ioquake/ioq3#130 to discuss long-term ways to solve this with less collateral damage.

I just tried building iortcw from source on Linux (Debian testing), and it works quite well. I only noticed that it uses $HOME/.iortcw for storing saves and settings. I patched the game to use $XDG_DATA_HOME/return-to-castle-wolfenstein (or $HOME/.local/share/return-to-castle-wolfenstein if $XDG_DATA_HOME is undefined). This makes it compliant with XDG base directory spec and stores data neatly without cluttering $HOME.

Are you interested in that patch? It involves changing mostly code/sys/sys_unix.c
Is that something that you regularly pull from upstream, or you can accept patches specific to your codebase in it? I made a merge request here: #12

Let me know if it's OK or needs any adjustments / changes to approach.

*ioRTCW 1.42d
*Deleted every config file in the RTCW folders

Can't set resolution via in-game option/menu, only with r_mode "-1" and custom values. AMD&Nvidia GPUs (Win7/Win10)
What is "r_custompixelaspect" (not "cg_fixedAspect ") variable and how to set it properly?

OS: Ubuntu 18.04
GPU: AMD 280x OpenGL version string: 3.1 Mesa 18.2.0-devel
iortcw version: 1.51c-SP (compiled from source today and previous version I downloaded elsewhere, forgot where exactly)
Relevant error in console: Error: UI/hud.menu. line (multiple line numbers here): unknown menu item keyword (multiple lines with "bottomright" and "scralign"). Relevant pic.

On the menu before game, the system menu just doesn't show and takes me back to the main screen. Apparently someone else had the issue also.

How can I properly set a custom FOV value in single-player?

Firstly, I use cg_fixedAspect "2" to play in widescreen.

Secondly, I tried using seta cg_fov "120" in the configuration file. FOV stays locked at 90(?). I entered cg_fov 120 in the console. Does nothing. Actually all cvars I enter in the console seems to do nothing.

I think you should be allowed to increase the FOV while still getting proper scaling provided by the fixedAspect (unless there's another way to do it). I appreciate any support.

I am trying to play rtcw in 1080 and running into an issue with display scaling. It seems no matter what settings I tweak either in my video card or in the game massive amounts of the screen bleed out of the boundaries of my monitor. I have an ASUS gaming laptop with a GeForce 960m.

Hello,

I just compiled lastest iortcw version from git and I can not set correctly my resolution:
even if I choose 1920x1080 fullscreen (my desktop resolution), it stays in an inferior resolution.
In the window mode the resolution seems buggy too.
How do I can help you for debugging this?

Thank you for your help.

LGDN
config:
Ubuntu 16.10 64 bits
NVIDIA GeForce GTX 770
official Ubuntu Nvidia drivers 367.57 - 1920x1080

Hi, my savegames i created on the steam version are apparently not compatible with iortcw, i get the error message:

The console output is:

sv_maxclients will be changed upon restarting.
------ Server Initialization ------
Server: forest
RE_Shutdown( 0 )
------- FBO_Shutdown -------
------- R_ShutdownVaos -------
------- GLSL_ShutdownGPUShaders -------
Hunk_Clear: reset the hunk ok
----- FS_Startup -----
Current search path:
/home/blabla/.wolf/main/toak_marketgarden.pk3 (98 files)
/home/blabla/.wolf/main/Final_DeathWish.pk3 (34 files)
/home/blabla/.wolf/main/denoflions_dual.pk3 (84 files)
/home/blabla/.wolf/main
./main/sp_rend2_shaders0.pk3 (5 files)
./main/sp_pak4.pk3 (21 files)
./main/sp_pak3.pk3 (14 files)
./main/sp_pak2.pk3 (232 files)
./main/sp_pak1.pk3 (1342 files)
./main/pak0.pk3 (4775 files)
./main
    
----------------------
6605 files in pk3 files
Gametype changed, clearing session data.
------- BotLib Initialization -------
------------ Map Loading ------------
trying to load maps/forest_b0.aas
loaded maps/forest_b0.aas
trying to load maps/forest_b1.aas
loaded maps/forest_b1.aas
-------------------------------------
AAS initialized.
AAS initialized.
-----------------------------------
RE_Shutdown( 0 )
----- R_Init -----
------- FBO_Init -------
------- GLSL_InitGPUShaders -------
loaded 276 GLSL shaders (192 gen 42 light 42 etc) in  0.07 seconds
------- R_InitVaos -------
Initializing Shaders
^3WARNING: In shader file scripts/common.shader...Shader "textures/sfx/portal3a_back2" on line 822 is missing closing brace^3.
^3WARNING: In shader file scripts/ui_wolf.shader...Invalid shader name "}" on line 1849.
----- finished R_Init -----
LOADING... collision map
LOADING... sounds
    
.........................
Initializing Sound Scripts
...loading 'sound/scripts/cutscene1.sounds'
...loading 'sound/scripts/cutscene6.sounds'
...loading 'sound/scripts/cutscene9.sounds'
...loading 'sound/scripts/cutscene11.sounds'
...loading 'sound/scripts/cutscene14.sounds'
...loading 'sound/scripts/cutscene19.sounds'
...loading 'sound/scripts/escape1.sounds'
...loading 'sound/scripts/escape2.sounds'
...loading 'sound/scripts/tram.sounds'
...loading 'sound/scripts/village1.sounds'
...loading 'sound/scripts/crypt1.sounds'
...loading 'sound/scripts/crypt2.sounds'
...loading 'sound/scripts/church.sounds'
...loading 'sound/scripts/boss1.sounds'
...loading 'sound/scripts/forest.sounds'
...loading 'sound/scripts/rocket.sounds'
...loading 'sound/scripts/assault.sounds'
...loading 'sound/scripts/sfm.sounds'
...loading 'sound/scripts/factory.sounds'
...loading 'sound/scripts/trainyard.sounds'
...loading 'sound/scripts/swf.sounds'
...loading 'sound/scripts/norway.sounds'
...loading 'sound/scripts/xlabs.sounds'
...loading 'sound/scripts/boss2.sounds'
...loading 'sound/scripts/dam.sounds'
...loading 'sound/scripts/village2.sounds'
...loading 'sound/scripts/chateau.sounds'
...loading 'sound/scripts/dark.sounds'
...loading 'sound/scripts/castle.sounds'
...loading 'sound/scripts/end.sounds'
...loading 'sound/scripts/ai.sounds'
...loading 'sound/scripts/general.sounds'
...loading 'sound/scripts/combat.sounds'
...loading 'sound/scripts/movers.sounds'
done.
LOADING... graphics
LOADING... maps/forest.bsp
stitched 8 LoD cracks
...loaded 6004 faces, 24 meshes, 343 trisurfs, 8 flares
LOADING... game media
LOADING...  - textures
LOADING...  - models
LOADING...  - weapons
LOADING...  - items
LOADING...  - inline models
LOADING...  - server models
LOADING...  - particles
LOADING...  - game media done
LOADING... flamechunks
LOADING... clients
LOADING... WolfPlayer
UI menu load time = 1 milli seconds
CL_InitCGame:  1.42 seconds
95 msec to draw all images
Com_TouchMemory: 0 msec
********************
ERROR: ReadField: function name is greater than buffer (512 chars)
********************
----- Server Shutdown (Server crashed: ReadField: function name is greater than buffer (512 chars)) -----
AAS shutdown.
forcefully unloading qagame vm
---------------------------
RE_Shutdown( 0 )
------- FBO_Shutdown -------
------- R_ShutdownVaos -------
------- GLSL_ShutdownGPUShaders -------
Hunk_Clear: reset the hunk ok
----- R_Init -----
------- FBO_Init -------
------- GLSL_InitGPUShaders -------
loaded 276 GLSL shaders (192 gen 42 light 42 etc) in  0.07 seconds
------- R_InitVaos -------
Initializing Shaders
^3WARNING: In shader file scripts/common.shader...Shader "textures/sfx/portal3a_back2" on line 822 is missing closing brace^3.
^3WARNING: In shader file scripts/ui_wolf.shader...Invalid shader name "}" on line 1849.
----- finished R_Init -----

It happens on all old savegames i tested.

There's very noticeable mouselook microstutter during movement. It's not present in vanilla game or knightmare.
Any ideas how to fix it? I'm on Win10 x64.

I've found various guides for fixing the Punk Buster issue, but the problem is I'm on Mac and all the guides are for Windows. The best example for this I have is this: http://steamcommunity.com/app/9010/discussions/0/846960628224537824/
Does ioRtCW work around this issue or does it require PB?

Also, in an unrelated request, do you think you could add support for the standalone multiplayer expansion, Enemy Territory? It's a bit of a pain to switch between what is essentially the same game.