No game assumes that this behaviour is accurate. In fact, in certain mods (such as The Specialists, where the role-play map fiskcity comes to mind) it can be used to escape the bank vault when you're trapped within. This is not by design.
People will want to play Half-Life mods. Many of those are only for Win32.
Using Proton after installing the Linux version will create a lower case titled version of the game directory and it results in namespace conflict related bugs. The game might not launch anymore, etc.
Will have to be fixed outside the engine obviously.
If you [manage to fix up and compile the code](https://github.com/ValveSoftware/halflife/issues/3133) (newer toolchain/buildsystem would be appreciated) under Linux, you'll notice how the mouse input code within cl_dll/in_camera.cpp will need to be updated quite heavily in order for mouse input to work properly.
## Inconsistency: Check HD multiplayer models by default
The 'Use high quality models' options under the multiplayer menu is never checked by default. If you're going to make the HD models the default, then the higher quality body groups for the multiplayer player models should be used as well.
## Quality of Life: add `find` console command from Source
Or maybe just make the console nicer to use in general.
The menu is hard to use with a controller. It should really be a lot better for playing on Steam Deck.
## Quality of Life: Different fov calculation modes
The standard fov mode which highly detests widescreen resolutions. People have made entire modelpacks to fix viewmodels to look right in widescreen. This is silly and should be replaced by a calculation that is based around a 4:3 horizontal axis projection with padding. You'll find those in custom Quake engines like QuakeSpasm and FTEQW (cvar: scr_fov_mode)
For over 2 decades, people have been sharing maps, mods and addons in a variety of frustrating ways. Install an addon and you're the janitor - cleaning up the base install of Half-Life is so annoying you better just remove the game and re-install it.
Add support for pak style loading of zip files (also commonly seen in id Tech games with the extension of .pk3 and .pk4 (indicating compressed zips)) within the game directory and people can finally delete a map by issuing a command as simple as:
```
rm map-JohnDoe-dm_partybus.pk3
```
...and that would take care of it all. The directory structure within the .zip should be as if you could run `unzip` on the file and it'd organize itself inside the game directory.
Choosing zip and recognizing the .pk3 and .pk4 extensions would make it easier for people to package the files for the virtual filesystem. Valve may choose to also use their own .vpk format if it would benefit things like Workshop support.
## Quality of Life: Workshop support
With once major websites having been shut down over the years, there is a need for Valve to help in preserving maps and addons by making them discoverable through the addition of a Steam Workshop.
VPK/PK3 archive support within the virtual filesystem would need to be completed first, then the workshop integration would be rather straightforward.
## Quality of Life: Rich Presence
While you can join games, it's not easy to see who is playing actively on a multiplayer game. It'd be very beneficial if we could see which game mode they're playing ([the gameAPI exposes this to the engine](https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/engine/eiface.h#L462)) and which map they're playing on.
Valve has created some high quality artwork for Half-Life's Steam Community thing. Like wallpapers, emotes and stuff - the trading card shenanigans. It should probably be used.
Some mods like to use them. [They also were used in advertising for the game](https://combineoverwiki.net/images/a/ac/Houndeye_video.png) so it would be appreciated to bring them back.
Half-Life had added a slight roll to the viewmodel from the bob calculation. When Half-Life SDK 2.0 came out this broke as a result changes that were intended for Team Fortress Classic, since the client shared code between the two games at one point.
The logic that needs to be restored is along the lines of:
```
viewmodel.angles[ROLL] += bob
```
Noting that the model tilts to the left, which means you may have to reverse the direction of the applied bob depending on how the engine interprets angles.
