I've released the source code for 4 prototypes originally developed for Half-Life Asset Manager: https://github.com/twhl-community/HLAM-prototypes

Half-Life Asset Manager V3 Released

Half-Life Asset Manager V3 has been released: https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V3.0.0

This is the final update, the program is no longer in development and the repository has been archived.

This problem was solved in the Discord server. The cause was the entity was outside the maximum map bounds (±4096 units from origin) so the entity's position as sent over the network was thrown out of whack.

Half-Life Asset Manager V3.0.0 Beta 1 Released

Half-Life Asset Manager V3.0.0 Beta 1 has been released. For more information and a download link see this page: https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V3.0.0-beta001

The Valve Developer Community already has articles on Source 2 development: https://developer.valvesoftware.com/wiki/Source_2/Docs

That's the place to be for that engine.

Your map has a leak, but due to how the compiler works it's not reporting this.

Your map needs at least one solid brush not tied to any entities to properly compile. You tied all sky brushes to func_water_analog which causes the compiler to skip trying to build brushes, so it also skips over the usual leak detection.

Sky brushes must never be tied to an entity. Brushes used to seal the map must never be tied to an entity either. Once you've changed the sky brushes back to regular brushes it should compile properly.

You didn't show your compile settings.

Also, can you provide the vmf file you're trying to compile?

I doubt that has anything to do with BSP files not being created. Looking at the source code that error only relates to the use of func_instance entities and is not a fatal error.

Is the compile log you provided the entire log? Can you show your Hammer configuration (build programs and all that) and the compile settings?

So, from now on it's up to TWHL to keep updating the projects, right? Do they have plans to implement the fixes to the updated SDK that Valve is supposed to release some day?

I created issues to track this work:
https://github.com/twhl-community/halflife-updated/issues/233
https://github.com/twhl-community/halflife-unified-sdk/issues/543

If and when Valve releases the update anyone can integrate the changes and make a pull request to merge the changes.

Will you contribute further, or have you become tired of developing this project? (I guess I would, it's a lot of work what you did).

I've more than accomplished my goals with the work i've done, it's time to let others manage things. There are other SDKs that also offer improvements and features, so there's no shortage of people to make something like this.

The problem in CMake preventing the project from extracting vcpkg dependencies has been fixed. Version 3.28.2 will work properly and should release in a week or two.

I've updated the documentation to warn about the affected versions, and i've also made it clearer that the project requires certain knowledge to get started: https://github.com/twhl-community/halflife-unified-sdk#half-life-unified-sdk

You can make maps for it just like you can for any Half-Life mod. You'll want to make a copy of the mod directory with a name for your own mod to do that though since the default isn't really meant to be used for such a purpose. That will allow you to make changes to game assets as needed.

I looked into the problem where CMake 3.28 (latest version at this time) can't generate project files. It appeared to be a problem with vcpkg at first but it turns out to be a problem with CMake itself. I've reported the problem and i'm working with them to get this fixed ASAP.

So essentially the USDK bundles the fixes of the base game plus the expansions in one solution in case someone wants to make a mod that uses e.g. stuff from vanilla HL and Opposing Force at the same time, right? Plus CMake support.

Yes, but it also adds a couple new features like a new sound system with increased limits. It's basically an expert SDK for when you want to go beyond some of the engine's limits but it'll require a good understanding of C++ to deal with any potential problems.

For most people i'd expect it to be a toolbox they can take things from for their own needs.

The engine will load config.cfg by searching through path IDs in this order:

• GAMECONFIG
• GAME
• nullptr (all path IDs are checked)

This means that if your mod directory does not contain a config.cfg file it will load one from another location, usually the one in Half-Life/valve. The engine does not use default.cfg (there is a commented out line in valve.rc that does) but you can try executing a config file that sets defaults in the client dll's Initialize function. Note that config.cfg will override any keybinds you've set.

Unfortunately there is no simple mechanism for defaulting keybinds in a sensible manner.

Thank you for all the updates youve done so far!

You're very welcome.

I don't fully understand the unified SDK, is it just a compilation of the fixes of all other 3 repos (HL, OF, BS) in one, or is it something entirely different?

Which one should we be using for modding?

The project readme explains what it is: https://github.com/twhl-community/halflife-unified-sdk#half-life-unified-sdk

As for which SDK to use, that's entirely up to you to decide. This SDK has a bunch of features added to allow playing all 3 games in the same mod so if you have need of those features you can use this SDK. Given the complexity of some of these features it's recommended to have a good understanding of C++ and software development if you intend to make a mod with it.

Half-Life Asset Manager V2.1.0 Released

Half-Life Asset Manager V2.1.0 has been released. For more information and a download link see this page: https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V2.1.0

Map Decompiler V1 released

Map Decompiler version 1 has been released: https://github.com/twhl-community/HalfLife.UnifiedSdk.MapDecompiler/releases/tag/V1.0.0.0

Changes since RC1:

• Added check to detect when bsp files are actually XML files
• Print first 64 bytes converted to UTF-8 when file type is not supported
• Added changelog

Version 1 is the full and stable release of the map decompiler. Just like Half-Life Updated and the Unified SDK this project has been handed to the community to manage from now on.

Half-Life Updated and Unified SDK released

Half-Life Updated, Half-Life: Opposing Force Updated, Half-Life: Blue Shift Updated and the Half-Life Unified SDK have been released:
Half-Life Updated: https://github.com/twhl-community/halflife-updated/releases/tag/HLU-V1.0.0
Half-Life: Opposing Force Updated: https://github.com/twhl-community/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0
Half-Life: Blue Shift Updated: https://github.com/twhl-community/halflife-bs-updated/releases/tag/HLBSU-V1.0.0
Half-Life Unified SDK: https://github.com/twhl-community/halflife-unified-sdk/releases/tag/UNIFIED-V1.0.0

Notable changes for all games:

• Updated build and installation instructions
• Disabled GCC optimization that prevents mod dlls from unloading after engine calls dlclose on Linux
• Implemented Valve game directory detection check to prevent incorrect use of mod dlls
• Fixed third party libraries possibly not being linked to when building Linux server dll

Notable changes for the Unified SDK:

• Updated nonfunctional scripting system and networking system branches to a more recent version of the SDK
• Added note about adding HL Uplink maps to packages
• Reverted "Boost volume to match original engine" change to fix audio problems related to volume being too high
• Updated documentation to explain FastDL behavior

Valve game directory detection

Mods made with these SDKs will no longer run when used to replace the game dlls of Valve games. This check was added for a couple of reasons:

• VAC may detect the modified dlls and ban you
• Players might think Half-Life Updated refers to an updated version of the game that can replace original dlls (it can't, it's an updated SDK and is not compatible with original game dlls at the network protocol level)

I wanted to add a check to detect the use of incompatible server and client dlls to prevent cases where this happens by accident. There have been cases where people tried to make a mod and accidentally combined an updated server dll with the original Half-Life client dll which won't work.

Unfortunately there is no way to properly add compatibility checking that has no edge cases. It should really be implemented in the engine with a way to report which mod a dll belongs to and which version it is, which is a fairly complicated thing to implement.

VAC currently does not appear to ban players using modified dlls but that can always change in the future. I'm accounting for the possibility that VAC is made stricter for Valve games only and not mods and thus preventing players from getting VAC banned in error.

The check is easily disabled in code so there is nothing that can be done to prevent people from making custom builds but you are doing so at your own risk.

FastDL behavior when using the Unified SDK

I tested what happens when FastDL (HTTP downloads using the sv_downloadurl cvar) is used with the Unified SDK. Since the Unified SDK generates and precaches a JSON file every time a map is loaded it's required to download this file every time.

I assumed this would require special handling on the web server side but it turns out the engine's behavior and the code written for the JSON file is already working perfectly fine.

The client will download the file when it reconnects to the game server after downloading all files from the FastDL server. To avoid a bogus error message printed in the console the web server should have a dummy file which the client will download but the file is ignored and deleted automatically by the client when it reconnects.

Notably clients will only ever use FastDL to download files once per map per server per session. This means that if you launch the game, connect to a server using FastDL running, say, crossfire with custom content you'll download that content with FastDL, but if the server then changes which custom content it uses for that map and reloads the map you'll download that content from the game server directly instead.

This continues to be the case until you either restart the game or use the httpstop console command to clear the list of maps which have been downloaded using FastDL.

The documentation has been updated to clarify this behavior.

Licensing information

I've sorted out the project licenses as best I can.

The main repository continues to use only the HL SDK license since the MIT license permits sale of work which isn't really compatible there. It's hard to separate the parts that fall under the MIT license since pretty much all of it is specific to this engine so i've left it as-is to keep it simple.

The assets repository uses both the MIT and HL SDK licenses, with the readme specifying which directories fall under the HL SDK license based on whether they contain anything originally made by Valve.

The C# tools repository is all MIT licensed since it doesn't contain Valve's code. The Map Decompiler is GPL V2-only licensed since it's based on the Quake 3 SDK which also has that license.

In effect this means you can use all 4 projects to make your own mods, use the assets in your mod and distribute them. As long as you abide by the Half-Life SDK license you're fine.

Remaining work to be done

• MIT license all community-written Updated & Unified SDK code (done)
• Move projects to twhl-community organization (done)
• Add any required documentation on development process that is currently missing (done)

And that's it! All work for V1.0.0 is done.

I stated before that I was going to wait until Valve updated the SDK to integrate their changes. I decided to go ahead with V1.0.0's release because it looks like Valve will take a while to continue their work on Half-Life 1.

There has been no visible progress on any Half-Life 1 games since December 22. I assume this is because of the holidays and because they're working to update all games at the same time and avoid destabilizing the public versions, but this is based purely on assumptions.

There are still work-in-progress changes in the public build such as missing localization changes and of course the SDK update which they announced so I'd expect to see some updates at some point in the future. It would be helpful to know what's going on but I don't know where we can ask for information about this so that's all I can say.

Even without the SDK update these SDKs will work with the anniversary version. You won't get the changes and fixes that need to be made in the SDK itself but you can run mods just like you can under the steam_legacy branch.

I've made Github issues tracking work that needs doing to integrate the SDK update as well as adapt the Unified SDK to work with the anniversary version (the map upgrades need reviewing since some maps were changed). Hopefully Valve released the SDK update soon so this process can be completed.

I've also added a list of contributors to the project README files. If you contributed to these projects and your name isn't listed (or is using the wrong name) then be sure to let us know so we can correct that.

With the release of V1.0.0 all 5 projects (including the Map Decompiler) have been moved to the twhl-community Github organization. It is now up to the community to continue the development of these projects. I've provided as much information as I can in the documentation and issues to help with this process. I hope that people can integrate the SDK update when it arrives and continue to update the projects as needed.

In the Unified SDK's case V1.0.0 is more of an initial version to start with; I fully expect people to continue expanding on it and change things as needed.

Special thanks to malortie for helping to develop the Unified SDK. Your help has been invaluable.

That just about wraps up everything. Thanks to everybody who helped make these projects a reality, and I hope people make awesome mods with them!

Only the client that ships with Half-Life itself is compatible with servers running Steam Half-Life. Any other client will have varying levels of compatibility, ranging from crashing on connect to strange bugs due to network protocol changes that causes the client to misinterpret information it receives from the server.

So if you're playing on Steam Half-Life servers, use the Steam Half-Life client only. The same goes for any other game or mod by the way, i've seen people try to mix HL updated dlls with vanilla HL which also doesn't work.

It works quite well BUT it seems to only work in a multiplayer session. Where would one make weapon function differently independently of multiplayer or not? The files are satchel.cpp

Weapon logic runs on both the client and server. Adding a cvar that only works on the client side will cause inconsistencies.

You can do per-player settings by marking the client cvar with FCVAR_USERINFO. This is how the model cvar syncs with the server (see CHalfLifeTeamplay::ClientUserInfoChanged for an example). You can then check the userinfo buffer on the server side and the cvar on the client side to make it behave as desired. But while it will work the user info buffer is pretty small and a long cvar name like cl_satchelanniversary is expensive to put in there.

The simplest way to implement such a setting would be to put it in each player's physics info string just like the long jump module does it, and then checking that on both sides. Of course that would then be a server setting, not a client setting.

The difficulty in having per-player settings in this engine is why changing that was a bad idea to begin with.

I'm trying to re-introduce the chainsaw crowbar bug as a toggle-able feature as well (sv_turbobar)
Though when turned on it's chainsawing EVERYTHING, not just corpses as I want it to do. But it's pretty damn funny.

Making the crowbar only chainsaw corpses requires the bugged logic to be added back exactly as it was before. The Unified SDK already has this as an option so you can see how it was done there.

You can probably sidestep the problem altogether by making it configurable. You can add cvars to the Multiplayer Advanced dialog, a simple list setting a resolution index should do the trick.

Sounds like maybe ScreenWidth is a larger value than expected? This is why it's better to wait for the SDK update, the anniversary update is essentially an open alpha test at this point. Without that updated code it's a guessing game.

You'll need updated config files in the sprites directory as well, and there are probably other code changes required to account for the increased sprite size.

You're probably better off waiting for them to release the updated SDK. Stick with steam_legacy until then.

Half-Life Asset Manager V2.0.0 Released

Half-Life Asset Manager V2.0.0 has been released. For more information and a download link see this page: https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V2.0.0

You can load a map of your choice by adding a button to GameMenu.res.

This is how the Unified SDK does it to load the campaign selection menu:

"3"
{
    "label" "#GameUI_CampaignSelect"
    "command" "engine disconnect; maxplayers 1; map hlu_campaignselect"
}

Map Decompiler RC 1 released

Map Decompiler RC 1 has been released. See this thread for more information: https://twhl.info/thread/view/20625?page=1#post-348130

Further updates will be posted there from now on.

The Half-Life Unified SDK Map Decompiler is a cross-platform map decompiler based on Quake 3's BSPC map decompiler tool.

Designed to decompile Half-Life 1 maps only (including Half-Life Alpha maps) this decompiler fixes bugs, adds support for maps produced by the latest compilers and introduces new features to produce the most accurate decompiled map sources possible.

Note that decompilers cannot produce perfectly accurate map sources due to limitations involving the Half-Life 1 BSP format. You will always need to fix up decompiled maps to get them working properly.

Release Candidate 1 is now available: https://github.com/SamVanheer/HalfLife.UnifiedSdk.MapDecompiler/releases/tag/V1.0.0.0-RC001

Changes in Release Candidate 1:

• Fixed description text color not updating when changing the theme between Light and Dark
• Reworked command line interface to use verbs to select the decompiler strategy instead of an option to make it easier to see which options apply to which strategy. See README.md for more information
• Added more information about some features to README.md

---

I tried to add support for decompiling clip brushes but it seems to be impossible due to how clip brushes are handled by the compiler:

// clip brushes don't stay in the drawing hull
if (contents == CONTENTS_CLIP)
{
    b->hulls[0].faces = NULL;
    b->contents = CONTENTS_SOLID;
}

This makes clip brushes invisible but also removes them from the point hull, used for things like hitscan ray traces which is why you can shoot through them.

The tree-based algorithm uses the point hull so clip brushes can't be reconstructed by that, and the face-to-brush algorithm uses the visual mesh (aka drawing hull) so they don't exist there either.

---

This release will also be the full release if there are no problems. That will have to wait until the SDK projects have been moved so as to ensure the links contained in this project are updated to point to the twhl-community organization on Github.

There is no Linux version yet, but you can try to build it yourself by using the Continuous Integration configuration as a starting point:
https://github.com/SamVanheer/HalfLifeAssetManager/blob/b6999b647c9439a2e8e2481c9672d9b6442fee2e/.github/workflows/ci-cd.yml#L19-L43

Some of these steps are only for CI, just make sure to clone the repository using recursive clone so vcpkg is also cloned. You'll need to set up CMake to use the toolchain file provided by vcpkg as shown in the CI configuration.

You'll need to install these packages as well:

• libopenal1
• qtbase5-dev

Run CMake to set up the Makefiles, then make and make install to install the resulting executable. Note that i haven't set up the install rules for Linux yet, the Windows version includes some third party libraries so it will probably be incorrect.

You can also download Linux artifacts produced by the CI pipeline on Github by going to the Actions tab and then the latest successful run, like this one: https://github.com/SamVanheer/HalfLifeAssetManager/actions/runs/6997951607

CI builds are release builds and are almost identical to release builds made using the above steps.

My goal is to get the Linux version fully operational for version 3 including proper installation rules and a simple guide for compiling, but that's not going to happen for a while.

Half-Life Asset Manager V2 Release Candidate 1 released

Half-Life Asset Manager V2 Release Candidate 1 has been released: https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V2.0.0-RC001

Changes:

• Added OpenGL debug logging (debug builds only)
• Removed obsolete sequence group filename correction and saving behavior (no longer used)
• Replaced stringstream uses with fmtlib
• Updated vcpkg to latest version, updated dependencies to latest versions:
  • fmtlib: 9.0.0 => 10.1.1
  • spdlog: 1.11.0 => 1.12.0
  • OpenAL-Soft: 1.22.2 => 1.23.1
• Reworked filesystem absolute path resolution to no longer search relative to the program install location
• Implemented case-insensitive filesystem lookup to allow files to be loaded even if the filename case differs on Linux
• Rewrote model loading to make error messages more accurate
• Added option to mute program when it is in the background
• Fixed minor issue in Options dialog page remembering behavior
• Moved Take Screenshot action to Video menu, now usable using F10 shortcut
• Reworked fullscreen mode to use the main window instead of a separate window
• Ensured keyboard shortcuts still work in fullscreen mode
• Escape no longer closes fullscreen mode, F11 now toggles the mode

This adds all features that were planned for V3 aside from the graphics overhaul. The Linux version is working pretty well aside from the graphical issue mentioned in a previous update so once V3's graphics overhaul is complete the Linux version should also work properly.

Seems to be working fine for me. Maybe a config file is overriding the setting?

Does this happen with the latest update? It looks like they've disabled asserts so this shouldn't happen anymore.

Regardless, the probable reason for this is the secure client code: https://github.com/ValveSoftware/halflife/issues/1893

Secure clients were once encrypted blobs which is why the error mentions LoadBlob.cpp. If they get rid of the redundant load calls this problem should be solved altogether, but it appears the asserts are already disabled so it shouldn't happen anymore.

Today's update fixes the problems that broke Half-Life Updated and mods derived from it. I'm going to wait until they've released an SDK update before i touch anything since it'll be a while to stabilize everything.

There's a test branch for Opposing Force which means it'll receive an update soon as well. Expect the same for all GoldSource engine games to fix issues with the new engine update. I'd expect the SDK update to come after all games have been updated and fixed so it'll probably be a few weeks.

Until then use the steam_legacy branch to develop, test and play mods.

In case i don't have time to deal with the SDK update, here's the procedure for merging changes into Half-Life Updated:
1. Fork the newest version of the Half-Life 1 SDK
2. Make sure all files use UTF8 encoding (should hopefully be done by Valve already, but check first) and commit any encoding changes
3. add the .clang-format file from Half-Life Updated and format all files (script in the Unified SDK or a Visual Studio extension can do this among other tools). Needed to avoid massive amounts of merge conflicts caused by whitespace and newline changes
4. Commit formatted files
5. Add fork as remote to Half-Life Updated
6. Use git fetch to update remote info
7. Merge the commit that formatted files
8. Resolve merge conflicts; there will likely be many. Some changes are technically out of scope for the project like the game balance changes, i'd exclude those changes or make them conditional based on cvars (the Unified SDK uses configuration files for those changes so it'll need to be updated there instead)
9. Commit merge and push

That should cover it. I'd recommend using a separate copy of the source code to avoid messing up the one people normally use for development. Use a Git GUI like SourceTree, it makes things a lot easier.

Yeah, they used the solution i mentioned to someone a while back. I never got around to applying it myself but it'll be merged in once the SDK update rolls around.

I do wish they'd make the anniversary edition a separate game as that would've avoided all of the problems. No need to switch branches, no broken games and mods and each game can be ported one at a time. And then a separate game/tool/app on Steam for mods to use to decouple game fixes from the mod version of the engine.

There must be a reason why they did it this way but it's causing a lot of headaches.

Half-Life 25th anniversary version released

Valve has released the 25th anniversary version of Half-Life which has slight changes in how the filesystem interface works which causes all mods based on recent versions of Half-Life Updated to crash. I've identified the problem and i've pushed a fix to a separate branch: https://github.com/SamVanheer/halflife-updated/tree/dev-anniversary

Until Valve releases a new SDK all projects will remain as-is. Use the steam_legacy branch to run mods. You can access it by right-clicking Half-Life in Steam, opening Properties and going to the Betas tab: Make sure to change Half-Life's branch even if you're trying to run another game like Counter-Strike because all GoldSource engine games and mods use Half-Life's engine files. Once you've switched it make sure Half-Life is up-to-date (you may need to launch it or press the Update button) and then you should be able to run other games/mods.

Once the SDK has been released i'll update the SDKs to work with the new version.

Note that there are some bugs in the new version. There is a noticeable (half second) delay in sound playback so they'll probably be fixing bugs before any SDK updates can be expected.

Please don't report mod crashes as bugs on the Half-Life Updated issue tracker because it's currently out of our hands. Check the Half-Life issue tracker and search before you post.

Half-Life Asset Manager V2 Beta 12 released

Half-life Asset Manager V2 Beta 12 has been released: https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V2.0.0-beta012

Changes:

• Removed dot in file extension to fix file associations not working when installed using offline installer

Ambiguous leafnode content errors happen when different faces on the same brush have a different type, like one having a water texture and another having a normal one. This can happen due to bad texture application but also when the compiler splits brushes and applies the wrong texture.

You can use func_detail to help avoid this or rework the geometry a bit but sometimes it's unavoidable.

Yeah we really need better beginner tutorials, the problem is that nobody has time to write all of that down. And any tutorial that explains everything people need to know will end up being very long due to how many terms there are, the amount of history, etc.

I thought about making pages that list every kind of fatal error the engine can produce along with an explanation (easy enough to find by searching for Sys_Error calls and Host_Error calls using a disassembler) but that also takes time.

Also needed is a page containing all of the old update notes from the pre-Steam HL website and the old Steampowered news site before they switched to Steampipe since that's all lost now outside of archive.org, but again that takes time to dig through and assemble. There's also information in the old mailing lists that isn't documented anywhere else.

It shouldn't make any difference performance-wise, but you can always fix them if you're worried about it.

It shouldn't cause water sounds to play.

The Half-Life Programming - Getting Started tutorial has been updated to streamline the tutorial and remove obsolete information.

References to Mac development have been removed. Half-Life Updated no longer supports Mac builds and only the Steam version of Half-Life has a Mac version.

Steam will drop support for the last 32 bit Mac OS version in a few years, they dropped support for Mac OS 10.12 this last september and the last 32 bit version is MacOS Mojave (10.14). This is in response to Chromium dropping support for those versions since Steam uses Chromium for its user interface.

Chromium is dropping support for MacOS Mojave in their latest versions, as noted in this issue which tracks removal of code used to support older MacOS versions.

Chromium version M117 released a few months ago. Steam usually trails behind Chromium updates and will be updating to a version that no longer supports Windows 7 and 8.1 at the start of next year. Chromium M110 was the first version to drop support for those and released about a year ago.

Given the rate at which Steam updates its Chromium dependency it will likely drop support within 1-2 years.

<== Continued from previous post

A new UI

I've looked into integrating RmlUi to determine which challenges are ahead in that area. I've experimented with replicating the look of the HUD in HTML, but so far i haven't been able to reproduce the exact method used which involves using a grayscale image colored with a specific value and whose alpha value is affected by the saturation of the color.

All of my findings are included in the Github issue: https://github.com/SamVanheer/halflife-unified-sdk/issues/453

If there is a way to replicate the HUD's exact appearance in HTML then it probably won't work in RmlUi since it will likely depend on CSS features that RmlUi doesn't (yet) implement.

Until it's possible to render the HUD in RmlUi it isn't worth trying to integrate it into a mod.

I've also done some investigation work into how modern engines handle UIs to see if any of them provide their UI toolkits as standalone options that can be integrated into an engine this old.

My findings are as follows (not an exhaustive list):

• Unreal engine: Uses Unreal Motion Graphics, a tightly integrated toolkit that depends on other Unreal features like blueprints to function.
• Unity engine: Uses UGUI, a GameObject-based toolkit. Totally dependent on the engine to function and written in C#.
• Godot engine: Uses Godot UI, a tightly integrated toolkit that builds on Godot's class hierarchy.
• Source and Source 2 engines: Use Panorama, a tightly integrated toolkit that uses a web-like development stack using XML, CSS and Javascript. It integrates with the engine to allow features like particle systems and model rendering to be embedded in the UI itself. Panorama's XML is not strictly HTML; it's very similar but is an evolved form of VGUI (it uses `Panel`s just like all VGUI versions).

Panorama is the closest to RmlUi in functionality but like all toolkits listed is tightly integrated into the engine.

This integration allows engine functionality to be used in the UI but precludes integration into other engines. None of these toolkits are available for standalone use, and even if they were they all use modern graphics APIs which makes integration even harder.

All of these toolkits are optimized for use in games, which means they update and render once a frame.

Another alternative is Chromium Embedded Framework 3 (CEF3), used to implement the UI in various desktop applications like Steam, Discord and Visual Studio Code (using Electron, a desktop application framework built on top of Chromium).

Chromium is designed to power web browsers; its architecture is designed around this use case. In practical terms this means Chromium uses subprocesses to perform tasks to prevent a browser tab from freezing the entire application, to prevent one tab from using exploits to read another tab's memory and other security and performance-related issues.

In part because of the use of subprocesses Chromium uses a lot more memory. Steam for instance uses around 470 MB of memory when running idle in the background. Discord uses 315 MB. It's possible for Chromium to use more memory then the rest of the game combined.

Chromium renders frames on its own, out of sync with the application. It's possible for Chromium to render more frames than your application needs, but also less, and probably lagging behind which can be a problem in a real-time environment like a game.

Additionally since pages are handled by subprocesses exposing Javascript APIs to UI logic isn't as cheap as it is with toolkits like RmlUi and Panorama. Half-Life's UI code accesses game state and in some cases modifies it as well which is complicated by the need to also communicate with the main game process.

GoldSource uses CEF1, an older single-process version of Chromium to render the HTML-based message of the day in Counter-Strike and Day of Defeat. It's been out of support for 10 years and can't even display the official Counter-Strike website due to a lack of support for modern secure connection technology. This integration is limited to rendering frames for display in VGUI2; it can't allow interaction between a website's Javascript and the game itself.

There aren't many cases of games using Chromium for their in-game UI. Here are some articles and discussions that covers the subject in more detail:

• https://coherent-labs.com/posts/what-developers-should-consider-when-using-chromium-embedded-framework-cef-in-their-games/ (biased since the authors have their own HTML toolkit, no longer in development)
• https://www.guildwars2.com/en/news/inside-arenanet-chromium-embedded-framework-in-guild-wars-2/ (replacing the above CoherentUI toolkit with CEF to provide in-game website rendering, not general UI development)
• https://github.com/libgdx/libgdx/issues/7088
• https://old.reddit.com/r/gamedev/comments/50j40h/htmlcss_gui_system_for_c_game_engine_openglvulkan/ (Note: EAWebKit is mentioned here; it doesn't work on Linux)

I couldn't find any references to games that actually use Chromium but i have seen discussions about it in passing before.

A couple mod teams have attempted to integrate Chromium into mods before (GoldSource and Source) but it has always led to failure due to the problems listed above and overall technical challenges involved with such a complex framework. If you really want to use it, you'd better prove it can be done properly first.

Based on my findings i'd say trying to integrate a new UI toolkit is a waste of time unless you can guarantee these things:
1. You can replicate the UI in HTML exactly as in the original without performance issues
2. The toolkit of choice can be integrated into a mod and works properly on Windows and Linux and when using the OpenGL and Software renderers (Software mode support can be dropped if needed, but for the Unified SDK in particular it's not an option without a major version change)
3. The implementation runs well in general and on older systems in particular. Given that Steam is dropping support for older platforms due to CEF as well this isn't a major challenge but Half-Life players tend to use older systems

Remaining work to be done

• MIT license all community-written Updated & Unified SDK code
• Move projects to twhl-community organization
• Add any required documentation on development process that is currently missing

I've run through all of the games again to test for any remaining issues. A handful were found and fixed and are listed above alongside fixes found by others.

This just about wraps up all work for V1.0.0. Everything that can be done in a reasonable timeframe has been done, all major issues have been dealt with and the last full test shows the games are working as expected. Once the remaining work listed above has been completed all projects are ready for a V1.0.0 release.

However, the full release of V1.0.0 will have to wait until after Valve has finished what they're working on to avoid having to release a patch in case there are any problems. People have noticed activity in a new password-protected branch that indicates the games are being updated with better controller and Steam Deck support.

No details are available so to avoid potential problems V1.0.0's full release has been delayed until these changes have been released by Valve. Given that controller support is implemented in the client dll which is part of the SDK this will likely mean mods will have to update to get the same changes.

That's probably meant to release on the 25th anniversary which is a week from now, so it shouldn't be a very long delay.

Once all of that stuff is sorted out all three of the Updated projects and the Unified SDK will be part of the twhl-community Github organization and will be maintained by the community.

The map decompiler will also be moved over after i've double-checked all of its features and the text color bug in Avalonia has been fixed.

Half-Life Asset Manager V2.0.0 will also receive a full release shortly once all of the above has been dealt with after which i will begin working on V3.0.0 which aims to replace the graphics code with modern OpenGL and to hopefully provide a fully functional Linux version.

I'd like to thank everybody for helping to develop and test these projects and hopefully they'll be fully released soon for everybody to try out and play with!

<== Continued from previous post

Progress on the Unified SDK

Release candidate 3 is now available: https://github.com/SamVanheer/halflife-unified-sdk/releases/tag/UNIFIED-V1.0.0-RC003

SDK Changes

• Reworked tripmine entities to use separate world model
• Don't allow executing sv_addbot with no parameters
• Added ITEM_FLAG_SELECTONEMPTY flag to weapons that regenerate ammo to always be selectable and never show as red in hud history
• Truncate yaw using cast to int instead of floor to match engine behavior (fixes NPC navigation in some maps)
• Fixed ambient_music not being triggerable in radius mode
• Added keyvalues to set barney & otis corpse bodygroups
• Fixed code analysis warnings when combining format result with string_view in ternary
• Speed up sv_load_all_maps, automatically load first map & print more info, more consistent and robust behavior and added stop_loading_all_maps command to stop this process
• Build portable binaries and workaround gcc bug to allow the Linux version to run on architectures that are missing the C++ runtime version used by the game and to avoid problems with std::regex
• Additional fix for op4loader sound looping bug to stop looping when the NPC is removed
• Boosted volume to match original engine by multiplying by **8**

C# Changes

• Adjusted MaxRange (far Z clipping plane) in c2a2a to fix graphical issues
• Fixed Alien Slaves in ba_canal1 waiting for 5 seconds before attacking
• Added upgrades to fix issues with barney, otis & scientists in specific levels (skin color & equipped weapons and items)
• Don't delete node graphs, update timestamps instead so graphs will be loaded from disk
• Updated third party dependencies and updated BSPToObj to account for changes in the vertex order used by Sledge library
• Add upgrade for bell1.wav sound and pitch so the bell sound sounds like it does in the original game

Asset Changes

• Added separate tripmine world model
• Added scientist_cower models
• Reverted changes made to viewmodel animations to match the original games
• Updated test maps to account for code changes
• Fixed HEV suit sentences playing in Opposing Force and Blue Shift
• Changed event id for sounds played by scientists that shouldn't affect the mouth so scientists don't "talk" when a beep sound plays
• Add polygons to loader accordion spine
• Added hlu_technology_demonstration map (unfinished, only contains a zoo of various NPCs and NPC models at this time)

Framerate issues in the GoldSource engine

Some people have reported issues that occur when playing at high framerates (100+ FPS) or when using cvars like host_framerate to manipulate the framerate to run very high.

This game was developed on machines that ran the game at about 20-30 FPS and everything was designed around that. The engine doesn't compensate for high framerates correctly in some cases and some game code also lacks proper compensation. Some of these issues have been fixed but the game will never work properly at high framerates because the render framerate is tied to the simulation framerate.

The engine was also designed to run at a maximum of 72 FPS, as seen in Quake 1's source code: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/host.c#L494-L522

GoldSource lacks this limiter but it still won't work properly. The recommended framerate is either 30 or 60 FPS. 100 FPS generally works but in specific cases like elevators there might be glitches like NPCs taking damage, dying or getting gibbed due to getting stuck. Higher framerates will be more prone to glitches.

Modern engines typically lock framerates or decouple the simulation framerate from the render framerate to avoid these issues, unfortunately this can't be fixed in a mod without re-implementing the entire physics engine.

NPC navigation issues

Users reported NPCs having problems navigating in specific areas. Known occurences include We've Got Hostiles in the area after the first elevator and a soft-lock that sometimes occurs in Lambda Core level A, where the scientist holding the shotgun fails to move to the button to open the door.

This was caused by an engine function that was re-implemented in game code to allow for better optimizations.

The faulty code looked like this:

float VectorToYaw(const Vector& forward)
{
    if (forward[1] == 0 && forward[0] == 0)
    {
        return 0;
    }

    float yaw = atan2(forward[1], forward[0]) * 180 / PI;

    if (yaw < 0)
    {
        yaw += 360;
    }

    return yaw;
}

The fixed code looks like this:

float VectorToYaw(const Vector& forward)
{
    if (forward[1] == 0 && forward[0] == 0)
    {
        return 0;
    }

    float yaw = static_cast<int>(atan2(forward[1], forward[0]) * 180 / PI);

    if (yaw < 0)
    {
        yaw += 360;
    }

    return yaw;
}

The lack of a cast to int caused yaw angles to be calculated slightly differently compared to the engine.

Casting to int and then back to float causes the value to be rounded. The exact behavior is compiler-specific, in Microsoft's case this is equivalent to calling std::round: https://learn.microsoft.com/en-us/cpp/c-language/conversions-from-floating-point-types?view=msvc-170

Without the cast no rounding is performed and yaw angles will be slightly off, in some edge cases like those mentioned above this can cause NPCs to get stuck.

Finding the cause of this is 99% finding a reproducible case of the problem happening. The Lambda Core occurrence didn't always happen, but the We've Got Hostiles one did.

Once that was found it was a simple matter of using version control to pinpoint which change introduced the problem and then finding the exact line of code. Comparing against the engine's version showed the missing cast.

This bug highlights the importance of being precise when recreating existing functionality, as well as making good use of version control. Without version control finding the cause would've been a lot harder.

sv_load_all_maps command

The sv_load_all_maps command has been modified a bit to deal with an engine bug that causes the game to crash or shutdown partway through loading all maps.

This command is mainly intended to be used to automate generation of node graphs but it can be used to gather error logs for each maps as well, or to automate testing of scripting systems using map-specific scripts if your mod has that.

A related command called sv_stop_loading_all_maps has been added to stop this process if necessary.

Node graphs

Node graphs are now bundled with mod installations instead of requiring them to be generated when a map is first loaded. This should make the first-time experience a lot smoother.

New repositories in the TWHL Community Github organization

A few new repositories have been added:

• HalfLifeSDKHistory: Contains each Half-Life 1 SDK release's source code as individual commits to allow viewing changes made in each update. There are also branches for the multiplayer version (lacks AI code) and a branch showing the difference between the singleplayer and multiplayer versions
• OldValveReleases: Contains modding files released by Valve, mostly old SDKs
• SlackillerDownloads: Contains files hosted on the old Slackiller modding website
• VHLT-V34: Contains the source code for VHLT V34 along with branches that remove disabled code paths for easier viewing. Also includes a copy of the VHLT V34 tools for completeness sake

Continued in next post ==>

Half-Life Updated release candidates released

Half-Life Updated, Half-Life: Opposing Force Updated and Half-Life: Blue Shift Updated release candidates have been released:

Half-Life Updated: https://github.com/SamVanheer/halflife-updated/releases/tag/HLU-V1.0.0-RC003
Half-Life: Opposing Force Updated: https://github.com/SamVanheer/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0-RC003
Half-Life: Blue Shift Updated: https://github.com/SamVanheer/halflife-bs-updated/releases/tag/HLBSU-V1.0.0-RC003 Notable changes for all games:

• Fixed save game system not saving arrays of EHANDLEs if the first half of the array contains null handles (mainly affected Nihilanth's spheres)
• Fixed player gaining health when drowning with god mode enabled and recovering health after surfacing
• Fixed human grunts continuing to fire for a few seconds after killing the last enemy in an area
• Fixed crash when +USEing NPCs that have just exited a scripted sequence
• Fixed talk monsters resetting other talk monsters' dying schedule if they are both killed at the same time
• Fixed RPG laser turning on when reloading immediately after equipping the weapon
• Reverted weapon selection using weapon IDs to prevent the game from malfunctioning when delta.lst is missing
• Added sv_load_all_maps & sv_stop_loading_all_maps to help automate node graph generation

Notable changes for Opposing Force:

• Fixed Male Assassin Snipers not tracking their last shot time properly causing them to fire the Sniper Rifle as if using full auto
• Fixed torch and medic grunts, male assassins and shock troopers continuing to fire for a few seconds after killing the last enemy in an area
• Fixed Gonome crashing the game if the player dies while being damaged by Gonome's chest mouth
• Save and restore allied grunt repel entities to ensure spawned NPCs have correct properties
• Fixed Desert Eagle laser turning on when reloading immediately after equipping the weapon

Continued in next post ==>

Without a 64 bit executable to launch it those binaries are rather useless. From what i can find online it seems that there was once a 64 bit version around 2004-2006 but i don't see any way to run it now.

The game has had Linux server support since long before the client was ported to Linux, that's why there are only 64 bit server files and not client files.

The -skyclip command line parameter explicitly enables sky clipping, -noskyclip disables it.

The info_compile_parameters entity can also change this setting using the noskyclip keyvalue.

If items still pass through it then you can work around the issue by making the sky brushes as thin as possible.

You should use VHLT instead of ZHLT: https://twhl.info/wiki/page/Tools_and_Resources#Compile_Tools

There are command line options and info_compile_parameters settings to control sky clipping behavior so make sure you're not changing the setting.

Older map compilers didn't make the skybox solid so the skybox brush volumes act like water.

Entities will also make water sounds when they move in or out of certain contents types, as you can see here in code from Quake 1: https://github.com/defunkt/quake/blob/63e82d566a86d0380803189a53d48af42413ea42/WinQuake/sv_phys.c#L1198-L1236

A map can have multiple level changes to the same level. In this case both the previous and next map are the same and you enter through a different level change. Your code needs to account for that.

Half-Life Asset Manager V2 Beta 11 released

Half-life Asset Manager V2 Beta 11 has been released: https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V2.0.0-beta011

Changes:

• Converted source files to UTF8, use correct copyright character
• Use different filter for executable filenames on non-Windows systems
• Added OpenAL Soft version to About dialog
• Github Actions now provides Linux artifacts for testing
• Removed progress dialogs when opening and closing files to avoid interfering with dialogs asking for user input
• Allow users to load Xash models in program, add warning about potential loss of data
• Fixed typo in settings category

It's now possible to load Xash models again. Users can choose how Xash models are loaded (in HLAM or in another program) and can choose the default action (always/never load in HLAM, or always ask first).

The Linux version has been tested. It's mostly functional but there are some bugs left. Current known issues are:

• Filesystem access is case sensitive and can't find some files the engine is able to find under the same conditions
• Some graphical options draw whatever is behind the program window (e.g. if you have a text file open it'll show that file)

Filesystem access needs reworking to follow the same rules as the engine. That's not terribly difficult but it's a bit of work.

The graphical issues are caused by the method used to implement transparent screenshots (the OpenGL window has an alpha channel which is uncommon). That will be fixed automatically when the graphics code gets rewritten for 3.0.0 and screenshots are handled using a different approach that also fixes the background color affecting transparent screenshots.

Since the program won't work properly until version 3.0.0 the Linux version will also be delayed until that time. 3.0.0 is intended to update the graphics code and fix graphical issues and not much else so hopefully that shouldn't take long after 2.0.0's release.

2.0.0 is now pretty much complete so this should be the last beta. Once Half-Life Updated and the Unified SDK have shipped V1.0.0 Asset Manager V2.0.0 will also be shipped and i'll start working on 3.0.0.

Map Decompiler beta 13 released

Map Decompiler beta 13 has been released: https://github.com/SamVanheer/HalfLife.UnifiedSdk.MapDecompiler/releases/tag/V0.13.0.0-beta013

Changes:

• Fixed not being able to decompile HL Alpha maps

You forgot to create and register the cvar: https://twhl.info/wiki/page/VERC%3A_Adding_New_skill.cfg_Entries

The link is inaccessible because you need to share access.

Just post the code directly using code blocks.