Holomatch version 1.2 - Suggestions

[Serris]

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.

[Chomenor]

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.

[criminula]

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.

[Callum603]

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

[Serris]

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.

[Chomenor]

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.

[Serris]

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.

[Chomenor]

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.