3
0
Fork 0
issues/Half-Life.md

307 lines
No EOL
16 KiB
Markdown

# Half-Life - Issues
Here's a list of things that we'd fix in Half-Life, given the opportunity.
Some minor attempts at prioritizing them. These all can be discovered by launching the game on Linux and playing a few rounds of multiplayer.
# 1/3 THE ONES WITH THE MOST IMPACT UPFRONT
**HOT! HOT! HOT!**
## Quality of Life: HUD scaling
We need this really bad. Anyone with 4K screens is having a hard time reading anything.
[You can see demand easily by looking at this addon.](https://gamebanana.com/mods/24741)
[This video shows how **tiny** the HUD is. It's really bad.](https://youtu.be/1mlcStqUhsw?t=220)
## Quality of Life: Different fov calculation modes
![Half-Life screenshot, 16:9 - default FOV](bad-fov.jpg) ![Half-Life screenshot, 4:3 - default FOV](right-fov.jpg)
> "Where is my gun? Oh. It's mostly off-screen."
The standard fov mode which highly detests widescreen resolutions. [People have made](https://gamebanana.com/mods/227021) entire modelpacks to [fix viewmodels to look right in widescreen](https://gamebanana.com/mods/232432) within GoldSrc games. **This is silly** and should be replaced by a FOV 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](https://code.idtech.space/fte/fteqw/src/commit/0eeb410ce074b19cffa70049820df14773d7ec5b/engine/client/view.c#L1259) (cvar: scr_fov_mode 4)
Support them all if you want, but mode 4 is the most desirable of them all. Nobody will complain I assure you.
Some comments on the addons, regarding their usefulness:
> Amazing, I can actually play now. Thanks x1000
> this is so cool dude
> nice, such fov should be default ones in wide resolutions
> Amazing!
> Very Nice
## Quality of Life: Restore pak0.pak
Half-Life 1 used to ship with a pak file containing the game data. This was seemingly deleted when GCFs were used to distrube the game data on Steam. Now that GCF and that distribution system have been retired, games like Half-Life 2 had their GCFs converted into VPKs. Half-Life 1 was just left as loose files and did not have its original pak file restored.
Steam Half-Life can still read pak files.
## Quality of Life: VPK/PK3 archive support
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.
Ever since 1999, with the release of [Quake III Arena, people just share glorified .zip files they plop into their game/mod directory](https://www.lvlworld.com/).
The gist: 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.
Installation **and** de-installation of maps, addons and mods would be a breeze.
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 (because SteamPipe).
## Inconsistency: HD Pack needs to be off by default.
An option to turn on the HD pack was introduced in the 2013 update with the HD pack being the default. This was not the intended way to play Half-Life. Additionally, the HD pack is missing various animations for models which could cause issues with mods.
## Quality of Life: Further Data content missing.
Further Data is a content addition disc for Half-Life 1 that contained additional maps, player models, and sprays for Half-Life. Some of the content was later provided in Half-Life patches, but not all of it.
## Bug: Fix the memory leaks
VGUI has plenty of documented memory leaks which especially affect Team Fortress Classic as well. [The issue tracker on ValveSoftware/halflife has plenty of examples.](https://github.com/ValveSoftware/halflife/issues?q=is%3Aissue+is%3Aopen+leak)
## Bug: Further video memory corruption issues
![test_renderamt - Windows](test_renderamt-win.jpg)
![test_renderamt - Linux](test_renderamt-lin.jpg)
You can cause video memory corruption on Microsoft Windows with certain rendermode configurations. [Check out this example level for compliance.](test_renderamt.bsp)
# 2/3 Other pressing issues
## GameUI: No check when returning back to Singleplayer from multiplayer
Multiplayer changes the player speed (and possibly other CVars) that do not get reset when a Singleplayer game is loaded after a Multiplayer game was started.
This is a check needed in GameUI. This was not something that impacted the disc release of Half-Life as the menu would restart the engine when going between SP and MP. GameUI doesn't restart the engine, so it has no chance to reset all of the CVars.
## Engine: Mapcycle woes
Stop sending WHOLE mapcycle.txt in svc_serverinfo message. It easily overflows the buffer and is **not** used on client side. It's fine to send empty string, so it doesn't break protocol.
## Engine: register hidden and working sys_timescale cvar
It is already used by mods, but right now forcefully registered through hacks. It's even synced over the protocol so prediction won't break.
## SDK: Merge this to aid modders
[Document stufftext filtering for modders.](https://github.com/ValveSoftware/halflife/pull/3160)
## Quality of Life: HUD aspect
Like with Half-Life 2, HUD aspect ratio would be well desired to have. Of course some screen effects need to keep taking up the whole screen.
## Quality of Life: Materials.txt alternatives
Materials are specified commonly via the file `sound/materials.txt`. This makes it **impossible for custom maps to define materials without breaking other maps**.
Mods have since the dawn of time added their [own ways](https://developer.vera-visions.com/de/d7c/md_Documentation_Materials_MatGoldSrc.html#autotoc_md825) of dealing with this.
Nuclide/FreeHL supports all of the above methods for compatibility.
# 3/3 More issues we'd fix, in no particular order:
## Bug: You can `+use` through walls.
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.
## Bug: Player firing animation for shotgun is missing
It exists in the player animations, but is never used.
## Bug: Snarks attack func_wall entities
Seen in rapidcore.bsp, what the heck? If they're trying to chew through entities, check for .takedamage being DAMAGE_NO first or whatever the Half-Life equivalent is!
## Bug: You can drop empty satchels.
Do this in multiplayer: Take up a Satchel Bag and place them all until you're at 0. Then die - and pick up your ammo canister. You'll receive the Satchel Bag in your inventory, but with 0 ammo.
## Linux: Underscores look like white space
In the console, all underscores look like whitespace. This makes choosing maps or using the auto-completion system in console rather annoying. The font needs to be closer to MS Sans Serif anyway.
## Linux: Mouse input breaks when loading a map from the command-line
In your Steam launch options, do the following for Half-Life:
`+map c1a0`
...and when trying to use the menu it becomes unusable.
The only solution is to open the console and to issue `quit`.
## Linux: Weird SDL input behaviour
Scroll wheel is really flaky and sometimes doesn't work. Using system version of SDL fixes it. Everything just feels really rough and messy.
## Linux: allow GameUI replacement
Current Linux build always loads GameUI.so from "../valve/cl_dlls/gameui.so" when the Windows build loads "cl_dlls\GameUI.dll". See, it allows providing replacement for mods in Windows version but not on Linux
## Proton: Filesystem issues
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.
Switching between Proton and Native in general is very finnicky and the user has to resort to manually deleting the game directories on their filesystem.
Will have to be fixed outside the engine obviously.
## Accessibility: Better Controller support
The menu is hard to use with a controller. It should really be a lot better for playing on Steam Deck.
## Accessibility: Don't do the Crouch+Jump timing thing for Longjump
Make it hold down crouch + tap space. Makes it easier for controller users to use and less of a worry for carpal tunnel syndrome.
## Accessibility cl_autojump 0/1
Accessibility feature, a way to jump repeatedly automatically. Supported by various third-party Quake engines as well.
## Accessibility: Closed Captioning
There's mods that tried doing this in the past. There's a need and there's a demand. There's more than just code work involved with this though. Should hook into the Sentences subsystem.
## SDK: Outdated code
The code at https://github.com/ValveSoftware/halflife seems to be outdated.
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.
Someone has already drafted a Pull Request for this years ago:
https://github.com/ValveSoftware/halflife/pull/1900
## SDK: Publish VGUI2 SDK
Used in Counter-Strike, Day of Defeat and Blue Shift of all things.
## SDK: Publish GameUI interface headers
Not even sources, I think community will figure out it themselves, but it needs VGUI2 SDK!
## SDK: Licensing ambiguity
The original Half-Life SDK license did not allow you to publish your source code changes. The GitHub doesn't state anything, but refers to the Source Engine SDK agreement - what is it Valve?
Perhaps just make the SDK + engine headers free software at this point? It's not going to hurt!
## Inconsistency: Check HQ 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: Teamplay really sucks
The whole model based approach isn't very good. Nobody enjoys this. At the very least employ a VGUI interface to let users choose the teams before spawning.
## Quality of Life: add `find` console command from Source
Or maybe just make the console nicer to use in general.
It's really not that great to use.
## 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.
## Quality of Life: Community features
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.
## Quality of Life: Better voice codec
Use Opus over CELT/SPEEX.
## Quality of Life: Extended limits
We'd probably please people by adding hot precaching, extending limits and other niceties from engines like Source to aid modders. There's a format called BSP2 that the Quake community uses - I don't like it very much. It'd probably be better to support Quake II's BSP format (which was the basis for Source BSP anyway) and the new extended version that landed in tyrutils-ericw for the Quake II re-release. Why? Because Hull Sizes suck, that's why. Half-Life can only run tracebox code for specific bounding box sizes, which has bitten modders in the ass plenty of times. A bit of a pipe dream, but I kept saying to myself when making FreeHL:
> If only Valve had used Quake II's BSP format.
## Bug: Gluon: There's supposed to be a sprite that hits the wall!
It never shows up - except when you're watching another player use it on a func_wall type surface - it's that broken.
This still works if you turn off prediction. This needs to be adjusted to work with the predicted code.
This never worked in MP, possibly to have one less thing to network?
## Bug: Gluon Secondary Attack will play a random idle when pressed.
It shouldn't do anything.
## Bug: Gauss: Beam colors were broken between 1.0 and 1.1
The colors of the Gauss beams became more bright when the prediction update was made.
## Fluff: Gauss: Doesn't use the dedicated decals.
They're in the decals.wad.
## Fluff: Bring back the GLQuake shadows
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.
## Fluff: The viewmodel bob is incorrect
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.
## Fluff: Bring the EAX audio back (s_eax in CD-ROM Half-Life)
Originally, Half-Life supported EAX audio. You can only really experience it these days with Wine-Staging and its EAX emulation with the original patched CD version.
OpenAL has the EFX extension set, which is compatible with this. This would enable Half-Life to get its original soundscape back.
## Fluff: Proper scoreboard, player name
Counter-Strike has a much nicer scoreboard than Half-Life does. We'd basically port that over.
It'd also be nice that if the player name was "Player" (the default in most games) would be replaced by the Steam user name. Although that might require UTF-8ifying more of the codebase in some parts? I have no insight on this within GoldSrc.
## Fluff: Support old backgrounds
Old mods ship with backgrounds for the original MFC version of the Half-Life menu. Check if a splash.bmp is in the current game dir depth and not one of the VGUI menu based .tga files. The video card requirements on Steam + Half-Life was raised high enough that no GPU that can only load 256px textures into video memory can run the engine anyway. Might as well store a non-power-of-two image like that in as a fallback if no VGUI menu files exist.
## Fluff: Visual artifacts
One example: Go into a multiplayer match, pick up the .357 Revolver. Then use the Quick-Switch key to switch between the 9mm Handgun and back to the Revolver. You'll be able to see the cut Silenced Glock for a split second. Tthe animation gets swapped before the model gets exchanged and the bodygroup swapped.
## Fluff: Mods Win32 DLL loading
Valve ships Proton. Make it so the native Linux version can load Win32 dlls. It's something we've talked about before and some people have successfully tested - it'd be interesting to pursue but kind of a pipe dream.
# Last but not least...
and as always, we'd look on the [official ValveSoftware/halflife issue tracker](https://github.com/ValveSoftware/halflife/issues) on GitHub.
**However, the above issues we mostly came across ourselves and always bothered us. They can also be replicated rather easily.**