Holomatch version 1.2 - Suggestions

[Chomenor]

First, thank you for including my cMod engine modification in your release! If anybody has any questions, issues, or bug reports regarding it let me know.

I noticed a few things with the release that I thought I might be able to help clarify and some suggestions that could be considered for future releases, especially regarding the included autoexec.cfg file.

- Most settings in your autoexec.cfg file are currently ignored by cmod. The setting "cmod_restrict_autoexec" needs to be set to 0 in cmod.cfg to enable fully loading autoexec.cfg files. This behavior is mentioned under Settings Handling in the readme. Many of the lines in the autoexec.cfg file are probably not necessary anyway, since they are effectively equivalent to what the cMod defaults already provide.

- The method of writing an autoexec.cfg file during install might not be the best way to confer default settings in general. Since it gets executed whenever the game is started it prevents the user from changing settings normally. For example your autoexec.cfg file sets cg_fov to 90, which is a reasonable default, but it also means that if a user sets it to 80 or 100 in the console it will get reset to 90 every time the game starts.

- Also if a user has customized their own autoexec.cfg file and runs the TLO installer to the same directory their autoexec.cfg file may be overwritten and lost.

- The setting of com_maxFPS 240 is probably not best for EF holomatch. In regular EF (not necessarily mods; RPG-X might be different) the framerate affects movement physics. A setting of com_maxFPS 240 can impair strafe jumping and have other physics effects compared to the standard value of 125.

- The setting of cl_allowDownload 0 is questionable because most servers, especially the gladiator mod servers that tend to account for the most player activity on EF, need custom map downloads in order to play. Probably most games with active players would not be joinable without cl_allowDownload 1 (or other means of getting maps).

If you want to include custom settings in your release with cMod, here are some possible alternatives to using autoexec.cfg:
- Save a different config file name, like tlo_defaults.cfg, and include instructions for how to optionally execute it on the download page or such.
- Include your own cMod fork/custom build with the default settings modified. Default settings can be changed or added in this area (I can help if interested):
https://github.com/Chomenor/ioef-cmod/blob/b8bc81e3e9da47ff67d1117ce72a7b358c2628fd/code/cmod/cmod_cvar.c#L1054
This should correctly change the default, but still allow the user to override, and avoid any of the other issues associated with changing autoexec.cfg.

I hope this is helpful!

[Serris]

First, thank you for including my cMod engine modification in your release! If anybody has any questions, issues, or bug reports regarding it let me know.

Thank you for your contribution! This literally wouldn't be possible without you.

I noticed a few things with the release that I thought I might be able to help clarify and some suggestions that could be considered for future releases, especially regarding the included autoexec.cfg file.

- Most settings in your autoexec.cfg file are currently ignored by cmod. The setting "cmod_restrict_autoexec" needs to be set to 0 in cmod.cfg to enable fully loading autoexec.cfg files. This behavior is mentioned under Settings Handling in the readme. Many of the lines in the autoexec.cfg file are probably not necessary anyway, since they are effectively equivalent to what the cMod defaults already provide.

- The method of writing an autoexec.cfg file during install might not be the best way to confer default settings in general. Since it gets executed whenever the game is started it prevents the user from changing settings normally. For example your autoexec.cfg file sets cg_fov to 90, which is a reasonable default, but it also means that if a user sets it to 80 or 100 in the console it will get reset to 90 every time the game starts.

Since you mentioned this, I've combed over the source code and noticed that many of the defaults are the same. I've made a fork on GitHub with our suggested changes.

Also if a user has customized their own autoexec.cfg file and runs the TLO installer to the same directory their autoexec.cfg file may be overwritten and lost.

This is why we recommend uninstalling existing clients on the release page. Fortunately, this won't be a problem with a minor code fix.

- The setting of com_maxFPS 240 is probably not best for EF holomatch. In regular EF (not necessarily mods; RPG-X might be different) the framerate affects movement physics. A setting of com_maxFPS 240 can impair strafe jumping and have other physics effects compared to the standard value of 125.

It was increased to support displays with higher refresh rates. 1920x1080 240 Hz panels are becoming increasingly common among PC enthusiasts and high-end gaming laptop manufacturers.

- The setting of cl_allowDownload 0 is questionable because most servers, especially the gladiator mod servers that tend to account for the most player activity on EF, need custom map downloads in order to play. Probably most games with active players would not be joinable without cl_allowDownload 1 (or other means of getting maps).

There's also the potential for mods being downloaded that may corrupt the BaseEF folder, similar to how the RPG-X closed beta leak did back in 2003. For client safety and security, this will remain disabled by default.

If you want to include custom settings in your release with cMod, here are some possible alternatives to using autoexec.cfg:
- Save a different config file name, like tlo_defaults.cfg, and include instructions for how to optionally execute it on the download page or such.
- Include your own cMod fork/custom build with the default settings modified. Default settings can be changed or added in this area (I can help if interested):
https://github.com/Chomenor/ioef-cmod/blob/b8bc81e3e9da47ff67d1117ce72a7b358c2628fd/code/cmod/cmod_cvar.c#L1054
This should correctly change the default, but still allow the user to override, and avoid any of the other issues associated with changing autoexec.cfg.

I hope this is helpful!

It was indeed helpful. Unfortunately, I don't currently have access to an Ubuntu VM to compile the new branch. Any chance you could potentially assist us with that and provide us with pre-compiled binaries for Windows and Linux? It would make uploading hotfixed clients much faster.

[Chomenor]

I can try to compile the binaries, although it would probably be good if you were able to do it in future to accommodate updates and such. The Windows binaries are relatively straightforward, but I'm not really sure what the best way to compile for Linux is. I know it can be hit or miss and it is often recommended for Linux users to build their own binaries locally.

If I do compile for Linux I think maybe I try to set up an older Ubuntu version like 14. I think then users of both older and newer versions of Linux would have the best chance of compatibility the way dependencies like glibc work. I'm not an expert with Linux but that's my best assumption. At any rate I need to set up some kind of new build environment since the last time I compiled cMod for linux it was on a laptop that is broken now.

There's also the potential for mods being downloaded that may corrupt the BaseEF folder, similar to how the RPG-X closed beta leak did back in 2003. For client safety and security, this will remain disabled by default.

This is actually unlikely to happen with cMod. I put a LOT of effort into improving the stability and security of cMod with downloaded pk3s, which is part of the filesystem project that I did which also works for Quake 3. Essentially in cMod the official Raven pk3s are prioritized over other pk3s in baseEF, and many complications are fixed so that this priority holds correctly even dealing with complex shader issues and such. Even if any RPG mod pk3s from any version were downloaded to baseEF it probably would not have any effect on cMod.

If you still don't want to enable downloads, perhaps it would be a good idea to at least include a message on the download page explaining the option. Since the majority of maps and active servers require downloads enabled, and there is currently not a clear error message when a server connection fails due to lack of download support.

[Serris]

I can try to compile the binaries, although it would probably be good if you were able to do it in future to accommodate updates and such. The Windows binaries are relatively straightforward, but I'm not really sure what the best way to compile for Linux is. I know it can be hit or miss and it is often recommended for Linux users to build their own binaries locally.

I've got an Xubuntu 14.04 VM set up for compiling the binaries, but it aborts with Error 2 because SDL_version.h isn't found. I assume I have to compile the SDL library, but I'm not sure which one to build, and the link to the ioQuake3 Wiki that you included in the readme doesn't work.

If you still don't want to enable downloads, perhaps it would be a good idea to at least include a message on the download page explaining the option. Since the majority of maps and active servers require downloads enabled, and there is currently not a clear error message when a server connection fails due to lack of download support.

There already is a message in the Known Issues section.

[Chomenor]

I've got an Xubuntu 14.04 VM set up for compiling the binaries, but it aborts with Error 2 because SDL_version.h isn't found. I assume I have to compile the SDL library, but I'm not sure which one to build, and the link to the ioQuake3 Wiki that you included in the readme doesn't work.

SDL for ioquake3 engine is dynamically linked. I don't think there is any easy way to statically link it. I believe to compile on Ubuntu you need the "libsdl2-dev" package installed for header purposes.

There already is a message in the Known Issues section.

Sorry, I missed that. I was thinking more like a warning in red print at the top of the page to explain that you won't be able to join the majority of online games unless you change the setting. Also the message can be updated to reflect that with the new update the option can be configured through configure->game options->auto downloading in the game menu.

If you don't mind me asking, I was wondering if you can explain more why you are so opposed to cl_allowDownload 1 as the default. It has been the default since EF was released, almost all active players use it, and very few have has issues with it. The kind of issue you gave as an example would AFAIK not apply to cMod. Do you have any other specific concerns I am not aware of?

[Serris]

SDL for ioquake3 engine is dynamically linked. I don't think there is any easy way to statically link it. I believe to compile on Ubuntu you need the "libsdl2-dev" package installed for header purposes.

I've gotten that far, compiled Linux binaries, and a dedicated server executable for 32 and 64-bit Windows. However, I'm running into a wall with libcurl.a that's preventing me from successfully compiling a 32 or 64-bit Windows local client executable.

Code Select Expand

LD build/release-mingw32-x86_64/ioEF-cMod.x86_64.exe
code/libs/win64/libcurl.a(libcurl_la-netrc.o):netrc.c:(.text+0dx2): undefined reference to `strtok_r'
code/libs/win64/libcurl.a(libcurl_la-netrc.o):netrc.c:(.text+0x11d): undefined reference to `strtok_r'
/usr/bin/x86_64-w64-mingw32-ld: code/libs/win64/libcurl.a(libcurl_la-netrc.o): bad reloc address 0x0 in section `pdata'
collect2: error: ld returned 1 exit status
make[2]: *** [build/release/mingw32-x86_64/ioEF-cMod.x86_64.exe] Error 1
make[2]: Leaving directory `/home/osboxes/Desktop/stvoyHM/ioef-cmod-master'
make[1]: *** [targets] Error 2
make[1]: Leaving directory `/home/osboxes/Desktop/stvoyHM/ioef-cmod-master'
make: *** [release] Error 2

If I had to guess, the version of the mingw64 compiler I'm using doesn't support the operation, but I'm not exactly sure what to do about it. Which packages did you apt-get and install in order to get this to work? I'm going to install the libcurl dev packages for Ubuntu and hope that solves the problem.

EDIT: It didn't solve anything, but I was able to compile them natively on Windows.

Sorry, I missed that. I was thinking more like a warning in red print at the top of the page to explain that you won't be able to join the majority of online games unless you change the setting. Also the message can be updated to reflect that with the new update the option can be configured through configure->game options->auto downloading in the game menu.

The hotfix build will restore the original game behavior and allow server file downloads. Frankly, I don't want to deal with any support requests related to third-party files that aren't included with the installer causing problems, but I suppose it's inevitable.

[Chomenor]

I've gotten that far, compiled Linux binaries, and a dedicated server executable for 32 and 64-bit Windows. However, I'm running into a wall with libcurl.a that's preventing me from successfully compiling a 32 or 64-bit Windows local client executable.

Personally I've always used Cygwin on Windows to compile the Windows binaries. The official ioquake3 build instructions can be found here: https://web.archive.org/web/20190506050817/http://wiki.ioquake3.org/Building_ioQuake3

In theory cross compiling on Linux should work, but unlike Linux builds where there is the consideration to compile on a somewhat out of date version (like Ubuntu 14 or 16), for Windows you should probably just use the latest stable version (such as Ubuntu 18 currently). That might fix the problem since the newer Ubuntu version will receive newer mingw packages etc. by default. You might need to keep 2 separate VMs for compiling Linux and Windows.

Until the hotfix build is in production, changing the parameter in the autoexec before start-up should be sufficient. The text will be adjusted once the new binaries are released.

Well, with the current release I think the default is effectively cl_allowDownload 1 anyway due to the cMod autoexec.cfg restrictions.

Frankly, I don't want to deal with any support requests related to third-party files that aren't included with the installer causing problems. By making the user have to opt in, this absolves us of any responsibility for fixing it.

Hmm. Perhaps an opt out could be sufficient to address that responsibility as well. For example a message in the download page stating "In game downloads are enabled by default. We are not responsible for any problems caused by files downloaded from third-part servers. If you wish to disable in game downloads, it can be done in the game menu at configure -> game options -> auto downloading."

In the case of cMod I think it is pretty unlikely that downloads actually will cause problems. It is well hardened against that and regularly tested and used with thousands of pk3s installed with no problems. Although many problems can come up with cMod or any other EF client, for cMod it is unlikely to be caused by downloaded pk3s, unlike earlier clients.

There are also some features that can be enabled in cMod for additional hardening. For example fs_saveto_dlfolder could be enabled by default alongside cl_allowDownload 1. This causes incoming downloads to be saved in the "downloads" folder, e.g. baseEF/downloads. There are a few potential benefits:
1) Additional hardening because the download folder is deprioritized versus all non-download pk3 in baseEF or mod directories
2) Troubleshooting benefit due to the ability to delete/rename the download folder to remove downloaded pk3s only
3) Since only cMod will access the download folder it prevents downloaded pk3s from affecting other clients that may hypothetically be installed in the same directory

For me the benefits are significant to having cl_allowDownload as the default in some form. In my experience many players will use default settings without any research, and if they can't play on many servers due to not having cl_allowDownload, they are liable to quit EF before they figure out the problem. Disabling downloads is also detrimental to the ability of server admins to use the full range of maps available in EF without worrying about whether it will exclude players using the TLO client release.

If you did consider letting cl_allowDownload 1 be the default for now, you could always change it in a future release if there are problems.

[Chomenor]

I've made a few updates to cMod in my repository, in particular I've added a new setting called "cmod_anti_burnin" which attempts to fade just the HUD elements to reduce possible OLED burn-on. It's a bit hacky and currently affects some non-static elements like the scoreboard, but otherwise seems to work reasonably well.

@Serris, perhaps you could use this setting in future releases instead of lowering r_gamma? I think r_gamma 1 is too dark for most maps. If you set the cmod_anti_burnin default to something like 0.25 or 0.5, and r_gamma back to 1.4, this should be at least as effective at reducing burnin with less graphical impact (since it generally only affects the HUD rather than the entire screen).

Also I noticed you added another master server, "master.stef1.daggolin.de". I'm not familiar with it. Is it run by a TLO member? Do you know if it would be okay if I added it to the master server list in my cMod repository / releases?

[Serris]

I'm definitely going to be restoring the original r_gamma default you'd set and including the OLED burn-in settings as default on the next update, it'll just have to wait until I've curated some additional mods to throw in.

As for the master server, it's not owned by anyone here, but you won't have any resistance to having it on by default.

[Chomenor]

Okay, thanks. I guess I may as well add that as a backup master as long as it is online and working.

[Serris]

Hey, I'm not sure if you're still following this topic, but would it be feasible to tweak the engine you've created to create a single player campaign executable?

[Chomenor]

No, I don't think so. Creating a single player engine may be possible, through a process of reverse engineering and combining code from existing releases, but as far as I know it would require a relatively considerable project rather than just a tweak (unless somebody has/can get access to the original Raven engine source code).

[Serris]

It would appear that someone has already worked on a project like that. I found the GitHub repository today. I wonder if it would be possible to retrofit some of cMod's quality of life features into it, like the OLED burn-in reduction and r_fullscreenmode? Being able to re-release the entire game for free with those changes would be huge, but I have virtually no experience doing this sort of thing.

[Chomenor]

Unfortunately I think that is only a derivative of the Raven "game" source release which doesn't include the engine. I don't have much experience in this area, but it appears you still need the original SP engine executable to run mods compiled with that (see https://github.com/kugelrund/Elite-Reinforce/blob/d17fbe46a152d7a7351df9fc2fb28e4b6fe2165a/ReadMe.txt#L19)

If you have permission to distribute the single player game, is there any chance you have a contact with the rights holders that might be able to get you the engine source code as well?

[Chomenor]

It is worth noting that Raven did release the full source code for games such as Jedi Knight 2, which is similar to Elite Force. Potentially this could be adapted to work with the existing EF game code and create a full engine implementation, if somebody wanted to work on such a project.

Of course, it would be easier if it were possible to get the original EF code directly.