Messages

Hello,

You can set a custom resolution in the game through the console. Open the console using ~ or Shift + ESC, and run these commands:

/r_fullscreenMode -1
/r_mode -1
/r_customWidth 1920
/r_customHeight 1080
/vid_restart

Where 1920 and 1080 are replaced by the actual resolution you wish to set. This should have the game try to use this resolution in both windowed and full screen modes.

It needs a CVAR_IGNORE_VM_DEFAULT flag. I already fixed this in my repository here: https://github.com/Chomenor/ioef-cmod/blob/574527fda96372147119af932a049b5b0fd6d69e/code/cmod/cmod_cvar.c#L1098

Otherwise the engine default defers to the mod Cvar_Register default. This is kind of a safety feature for mod compatibility to avoid forcing a default when it isn't necessary. For example a mod could change a default by a factor of 10, like setting cg_fov to 800, and forcing the default to 90 would cause problems. It's probably not an issue with cg_fov specifically though so I just add the ignore_vm_default flag.

I think a lot of monitors are just too bright in general the way they're calibrated out of the box. I wonder if the brightness on that monitor might be set too high on the monitor itself. Do any other applications besides EF seem too bright on that monitor?

If you wish to restore the brightness prompt, that can be done by changing the "ui_initialsetup" default from 1 to 0 in cmod_cvar.c. Make sure you merge the latest updates from my repository though. Otherwise you might be missing a CVAR_IGNORE_VM_DEFAULT flag which would cause the prompt to get stuck.

The menu scaling would be nice as a future feature, but given my limited time for EF development and various other work to be done, I'm not sure how soon I might be able to get around to it. Perhaps if somebody else wanted to assist with that project it could be done sooner.

I was doing a bit of testing on the Holomatch release on holomat.ch, and I have some feedback and possible bugs to report:

- I'm getting a "403 Forbidden" error using the "DOWNLOAD FROM THE LAST OUTPOST" links. The "DOWNLOAD FROM GOOGLE DRIVE" version works. For Windows I get a .exe file, but the link page suggests the filename is "stvoyHM_setup.zip", so I'm not sure if I am getting the correct version.
EDIT: The links seem to be working now. The last outpost link does provide a zip file, but when extracted it is identical to the exe from the google drive link.

- When I tested the installer, the desktop icon it created was invalid, and it didn't seem to create any start menu icon. I had to navigate to the install directory to run the application. This was on a Windows 10 clean install VM. I don't know how reproducible this is on other systems.

I also don't like the r_gamma default which still appears to be 1.0. This makes the game very dark and new players might not realize to change it as the setting is somewhat buried in the menu.

For context, the original game featured an "adjust slider until symbol can barely be seen" prompt on initial startup. Normally this results in a setting in the range of around 1.3 - 1.5, maybe less if you are especially strict about the meaning of "barely". In cMod I opted to remove this prompt, on the basis that a fixed default of 1.4 was sufficient on modern monitors and simpler for users.

The TLO default of 1.0 is problematic because this low setting combined with the removal of the brightness prompt in cMod leads to the game running much darker than originally intended. You can even see this with the holomat.ch graphics; the "Welcome to Dangercity" sign is too dark and the lower half of the rota3dm3 scene is also too dark. You can tell from the blue sky above it's not meant to be such a dark scene.

Based on a bit of research, it doesn't seem like OLED burn in should be a significant problem without thousands of hours of playing time. Usually that is more of a concern for things like OS UI elements that are on the screen permanently. Apparently there is also a thing called "image retention" that OLED monitors experience but that is a short term effect and only temporary. My impression is that restoring r_gamma 1.4 as the default should be safe enough even for OLED monitors under normal playing conditions.

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.

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?

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).

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

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?

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.

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?

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.

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!