The Last Outpost

Member Services => Engineering => Feature Requests => Topic started by: Chomenor on April 19, 2020, 02:40:54 PM

Title: Holomatch version 1.2 - Suggestions
Post by: Chomenor on April 19, 2020, 02:40:54 PM
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!
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on April 19, 2020, 03:56:41 PM
Quote from: Chomenor on April 19, 2020, 02:40:54 PMFirst, 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.

Quote from: Chomenor on April 19, 2020, 02:40:54 PMI 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 (https://github.com/PresidentMagikarp/ioef-cmod) with our suggested changes.

Quote from: Chomenor on April 19, 2020, 02:40:54 PMAlso 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.

Quote from: Chomenor on April 19, 2020, 02:40:54 PM- 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.

Quote from: Chomenor on April 19, 2020, 02:40:54 PM- 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.

Quote from: Chomenor on April 19, 2020, 02:40:54 PMIf 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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on April 19, 2020, 07:43:27 PM
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.

Quote from: Serris on April 19, 2020, 03:56:41 PM
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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on April 21, 2020, 05:03:22 PM
Quote from: Chomenor on April 19, 2020, 07:43:27 PM
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.

Quote from: Chomenor on April 19, 2020, 07:43:27 PMIf 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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on April 21, 2020, 09:02:10 PM
Quote from: Serris on April 21, 2020, 05:03:22 PM
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.

Quote from: Serris on April 21, 2020, 05:03:22 PM
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?
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on April 22, 2020, 06:13:47 PM
Quote from: Chomenor on April 21, 2020, 09:02:10 PMSDL 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.

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.

Quote from: Chomenor on April 21, 2020, 09:02:10 PMSorry, 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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on April 22, 2020, 08:30:03 PM
Quote from: Serris on April 22, 2020, 06:13:47 PM
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 (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.

Quote from: Serris on April 22, 2020, 06:13:47 PM
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.

Quote from: Serris on April 22, 2020, 06:13:47 PM
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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on May 03, 2020, 04:35:42 PM
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?
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on May 04, 2020, 05:47:45 PM
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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on May 04, 2020, 06:01:36 PM
Okay, thanks. I guess I may as well add that as a backup master as long as it is online and working.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on May 21, 2020, 07:43:49 PM
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?
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on May 21, 2020, 09:35:30 PM
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).
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on May 22, 2020, 09:38:05 PM
It would appear that someone has already worked on a project like that. I found the GitHub repository (https://github.com/kugelrund/Elite-Reinforce) 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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on May 22, 2020, 09:53:06 PM
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 (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?
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on May 22, 2020, 10:08:48 PM
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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on May 22, 2020, 10:53:50 PM
Unfortunately, we haven't been able to get a hold of the source code for the campaign. We're going to explore our avenues of communication, but adapting the JKA2 code is probably the best option at this point in time.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on July 12, 2020, 09:48:38 AM
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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: criminula on July 12, 2020, 01:21:57 PM
I can reproduce the desktop shortcut problem. It created a file (simply called 'Star Trek', IIRC, or something similar. Certainly looked like the name had been cut short) that did not function as a link.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Callum603 on July 13, 2020, 01:12:59 AM
Quote from: Chomenor on July 12, 2020, 09:48:38 AM
- 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.

Hi,

The 403 error was a token/cookie issue as we transitioned over to the second mirror for bandwidth management. I fixed it as soon as I noticed it.  My apologies about that, it was an avoidable mistake I didn't spot in time.

The reason the downloads page says it's a .zip and google an exe is from the previous downloads system (only rebuilt a couple of days ago ready for the campaign), it used to break EXE files, but that has now been resolved, downloads on our own servers are yet to be restored to normal EXE files where necessary.  That will be done at some point in the near future.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on July 29, 2020, 11:54:21 AM
Sorry for the belated response, I've been a bit busy, but now I'm on vacation.

Regarding the R_Gamma default, 1.4 is far too high for some modern gaming monitors with the way they're calibrated out of the box. My MSI Optix MPG341CQRV, for example, looks just fine at 1.0, whereas my MSI Optix MPG27C benefited from being set to 1.4. I genuinely believe the best compromise in this situation would be to bring back the brightness screen on first start-up and allow users to set it themselves.

With regards to the file extension confusion, all future releases will be .exe files on both platforms now that Callum has fixed the problems with our download manager. Previously, it was converting .exe file extensions to .zip, so my solution was to store the .exe in a .zip, which added something like 24 KB to the total file size. That way, users wouldn't have to rename the file extension in order for the installer to work, they could just extract it and run it.

Would it be possible to adapt some code from rpgxEF to allow the menus to scale better with aspect ratio? As it is now, everything stretches from 4:3 and it is not pleasant to look at.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on July 30, 2020, 02:30:37 AM
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.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Serris on July 30, 2020, 09:41:35 AM
While we're on the topic of engine quirks, I've noticed that hat the engine is overwriting the new default CG_FoV value of 90 from CVAR.c to the original game's value of 80 whenever the game loads, but setting it back to 90 in-game makes the setting stick. Is there a command that processes during client initialization that could explain this? The console returns the default as 90 like it's supposed to.
Title: Re: Holomatch version 1.2 - Suggestions
Post by: Chomenor on July 30, 2020, 02:41:05 PM
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 (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.