This bar is drawn manually by the health hud: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/health.cpp#L225-L227

You can't modify any data structure that's shared with the engine. weapon_data_t is one of those, along with every other structure referenced in delta.lst and others.

If you need to send data to the client you need to use the existing variables. If you run out then you'll need to send data using user messages. If that's not a solution for your problem then there's nothing more you can do.

Also note that data in weapon_data_t is only sent to clients if weapon prediction is enabled. Given that you're trying to send data related to the use key i don't think sending it as part of weapon data is the correct solution. The server is responsible for processing use inputs anyway, so it may not even be necessary to send this data to the client.

Barney's one of the oldest NPCs and doesn't use the game's body group APIs, instead it directly modifies the pev->body variable so it doesn't respect the state of body groups.

To fix this in code you should use GetBodygroup and SetBodygroup instead.

You can see how that's done here: https://github.com/SamVanheer/halflife-unified-sdk/commit/2f27727b42a9f4ab7e104d178771b006df572f71#diff-c961f346030c270f9dc49f497b12c437c8a08940336ddad837d025428dc6b526R326-R338

Note that there are other places in the code where these changes are needed.

I'd suggest checking the latest version of that code to see what needs to be changed: https://github.com/SamVanheer/halflife-unified-sdk/blob/master/src/game/server/entities/NPCs/blackmesa/barney.cpp

Remaining work for Half-Life Unified SDK V1.0.0

• Replacing sounds (for footstep sounds which differ in Opposing Force), requires client side support which is difficult to provide since it involves the client loading replacement map files
• Replacing HUD sprites (for Opposing Force which uses a digital-like effect on sprites), requires client side support, could hit engine HUD sprite limit. Might need to be delayed until the UI can be reworked to no longer depend on sprites
• Replacing the engine's music playback system with one that won't stop playing after level changes. Could be complicated to implement properly since there's no easy way to tell when the client disconnects from a server

I'm considering leaving these features for V2.0.0 so as to focus on stabilizing V1.0.0 and getting it released. V2.0.0 would then be released as soon as it's done so there might be a small amount of time in-between, it's impossible to predict.

Other work that's needed for V1.0.0:

• Get the assets repository up and running, include all versions of the install scripts in it (add, commit, remove so it's in the history). This repo will contain all of the map, model, etc sources as well as any script code used in the game. A script or tool to copy the scripts from the assets repo to the game installation will be needed to streamline the development process (possibly a filesystem watcher that auto-copies files)
• Integrate malortie's work into the game installation
• Update packing script to use a timestamp-based naming scheme (PackageName-YYYY-MM-DD-Revision.zip where Revision is the N'th package that's been made) to make it easier to distribute

I've considered putting the game installation in version control but the available options are bad at storing binary data. For example HLEnhanced has 133 commits and has a size of over 1 GB. The Unified SDK's binaries are twice the size of HLEnhanced so the repository would quickly grow in size to eat up a lot of disk space. Git wasn't made for this, and you can't really bend it to work that way without using risky Git commands. And even if you do that you won't be able to pull changes if you wipe the history (Git will see it as essentially an unrelated branch).

Git LFS isn't an option either. Github's data limits for free accounts is 1 GB storage and 1 GB download bandwidth per month. This project alone would quickly use up the storage space and a single multiplayer playtest could use up that bandwidth as well.

Perforce is stated as being able to do this, but as i understand it it works pretty much like Git LFS and there is no free hosting option for any kind of version control that will host files of this size.

So instead i've opted to use a strategy similar to what i've done with the Half-Life Updated projects: package the installation and upload it on the releases page. Old dev releases will be pruned regularly, full releases will stay. It might be possible to automate this so that executing a script packages the installation and auto-uploads it to Github but i haven't looked into that yet.

I would also like to reiterate that this SDK is not ready for development use yet. Once V1.0.0 has been released i will be switching the repository's setup a bit so the master branch tracks full releases so that it always represents the latest stable build, with an unstable dev branch and feature branches that branch off from the dev branch. This will make it easier to make mods with this SDK without accidentally cloning an unstable version.

Note that because some work involves making breaking changes future updates are unlikely to be easy to merge in. It's unlikely that you'll be able to pull V2.0.0 on top of a modified V1.0.0 and expect everything to work. Unfortunately this is the difficulty in making an SDK that is available early while also solving big problems. The alternative is keeping it private or labeling it unstable the entire time which only complicates things.

I'd like to thank malortie for updating all of the models to work with this SDK. He's been doing a lot of good work and this SDK would not be complete without him.

I'd also like to thank Penguinboy for fixing a performance issue with the skill name regular expression which dramatically slowed down map loading. This fix really helped.

Progress on Half-Life Unified SDK

A fair amount of work has been done in recent weeks. These are the highlights:

• Simplified the logging system to remove the need to create loggers in PostInitialize in some game systems
• Added file logging with configuration support in logging.json
• Added IGameSystem interface to help simplify how various systems are initialized and shut down
• Bunch of code cleanup including removal of redundant forward declarations and extern keyword, removing duplicated code and more
• Added IMPLEMENT_CUSTOM_SCHEDULES and DECLARE_COMMAND macros to Visual Studio hint file so Intellisense stops showing green squiggles under usages
• Reworked how client commands are handled on the server side to use a map of commands. Commands can be registered and unregistered at any time, this is done for gamemode-specific commands to simplify command handling
• Changed how weapon selection is handled to use a proper named client command (previously any weapon_* command was interpreted as a weapon selection command)
• Added virtual destructor to CGameRules so the destructor runs properly
• Re-implemented the spectator client command to function outside of the CTF gamemode. This command was made unavailable due to Opposing Force using an older version of the SDK as a base which didn't support spectator mode in all game modes. Opposing Force Updated does this for consistency with the original game, the Unified SDK allows the use of this mode in all game modes just like the Half-Life SDK does (even in singleplayer)
• The hud color is now saved and restored, allowing it to persist between levels
• Fixed some Opposing Force code sending ScoreInfo messages with incorrect contents causing a fatal error (Opposing Force doesn't send the player class and team index values because it uses a different method of team-based gameplay)
• Reworked how the health and model values are set to allow mappers to set custom values for both. Entities now initialize these in OnCreate, if a mapper-provided value exists it will be overridden in DispatchKeyValue. All code uses pev->model now to support custom models, although some edge cases may exist
• Removed NPC voice pitch restore hack (initial pitch value is set in OnCreate now)
• Added global model replacement support. This feature lets you globally change references to a model to use another model instead. This does not apply to models used by the engine since those references cannot be changed
• The PRECACHE_SOUND macro has been removed, either CBaseEntity::PrecacheSound (for entities) or UTIL_PrecacheSound (for global precaching) should be used instead, or g_engfuncs.PfnPrecacheSound if you need to precache a sound unaffected by global model replacement
• The SET_MODEL macro has been removed, CBaseEntity::SetModel should be used instead
• Weapons store off the world, view and player models they use to properly precache and restore these models as well as to adjust the active weapon model when changing levels (not intended for use outside of these use cases, but can be made more robust if necessary)
• Fixed weapon_eagle saving and restoring booleans as integers
• The player's hud color and suit light type (flashlight or nightvision) can be configured from a configuration file now as well as through an entity and the console
• Simplified how game configurations are loaded by merging the data apply step into the parse step (more efficient, easier to use, less confusing)

The work that's been done brings us much closer to allowing one to play all 3 games without requiring either code changes or swapping out files.

I've recorded a short video that shows the Half-Life => Opposing Force => Blue Shift transition when changing maps:The first map has this configuration file:

{
    "Sections": [
        {
            "Name": "HudColor",
            "Color": "255 160 0"
        },
        {
            "Name": "SuitLightType",
            "Type": "flashlight"
        }
    ]
}

These are the default values as well.

The second map has this:

{
    "Sections": [
        {
            "Name": "HudColor",
            "Color": "0 160 0"
        },
        {
            "Name": "SuitLightType",
            "Type": "nightvision"
        },
        {
            "Name": "GlobalModelReplacement",
            "FileName": "cfg/maps/Op4ModelReplacement.json"
        }
    ]
}

This configures the HUD color to Opposing Force green, the suit light type to night vision and it uses the Opposing Force model replacement file, which looks like this:

{
    "models/v_9mmar.mdl": "models/op4/v_9mmar.mdl",
    "models/v_9mmhandgun.mdl": "models/op4/v_9mmhandgun.mdl",
    "models/v_357.mdl": "models/op4/v_357.mdl",
    "models/v_chub.mdl": "models/op4/v_chub.mdl",
    "models/v_crossbow.mdl": "models/op4/v_crossbow.mdl",
    "models/v_crowbar.mdl": "models/op4/v_crowbar.mdl",
    "models/v_desert_eagle.mdl": "models/op4/v_desert_eagle.mdl",
    "models/v_displacer.mdl": "models/op4/v_displacer.mdl",
    "models/v_egon.mdl": "models/op4/v_egon.mdl",
    "models/v_gauss.mdl": "models/op4/v_gauss.mdl",
    "models/v_grenade.mdl": "models/op4/v_grenade.mdl",
    "models/v_hgun.mdl": "models/op4/v_hgun.mdl",
    "models/v_knife.mdl": "models/op4/v_knife.mdl",
    "models/v_m40a1.mdl": "models/op4/v_m40a1.mdl",
    "models/v_penguin.mdl": "models/op4/v_penguin.mdl",
    "models/v_pipe_wrench.mdl": "models/op4/v_pipe_wrench.mdl",
    "models/v_rpg.mdl": "models/op4/v_rpg.mdl",
    "models/v_satchel.mdl": "models/op4/v_satchel.mdl",
    "models/v_satchel_radio.mdl": "models/op4/v_satchel_radio.mdl",
    "models/v_saw.mdl": "models/op4/v_saw.mdl",
    "models/v_shock.mdl": "models/op4/v_shock.mdl",
    "models/v_shotgun.mdl": "models/op4/v_shotgun.mdl",
    "models/v_spore_launcher.mdl": "models/op4/v_spore_launcher.mdl",
    "models/v_squeak.mdl": "models/op4/v_squeak.mdl",
    "models/v_tripmine.mdl": "models/op4/v_tripmine.mdl"
}

The third map uses this:

{
    "Sections": [
        {
            "Name": "HudColor",
            "Color": "95 95 255"
        },
        {
            "Name": "SuitLightType",
            "Type": "flashlight"
        },
        {
            "Name": "GlobalModelReplacement",
            "FileName": "cfg/maps/BlueShiftModelReplacement.json"
        }
    ]
}

Same thing as Opposing Force.

Config files can be included in other config files so a single file can be used to configure entire map packs pretty easily. The server config file can also do all of this so you can use that to configure a mod's default values.

The CTF game mode is the big exception since that still uses hard-coded values. Ideally those will also be configurable at some point.

Half-Life: Opposing Force Updated beta released

A Half-Life: Opposing Force Updated beta has been released: https://github.com/SamVanheer/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0-beta008

Changes:

• Fixed typo in shephard player model name
• Fixed clients not getting ScoreInfo message for new players immediately in CTF
• Fixed crashes when GetClientColor returns null in CTF

Thanks to Shepard for helping test this and uncovering these issues.

Half-Life Updated betas released

Half-Life Updated, Half-Life: Opposing Force Updated and Half-Life: Blue Shift Updated betas have been released:
Half-Life Updated: https://github.com/SamVanheer/halflife-updated/releases/tag/HLU-V1.0.0-beta011
Half-Life: Opposing Force Updated: https://github.com/SamVanheer/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0-beta007
Half-Life: Blue Shift Updated: https://github.com/SamVanheer/halflife-bs-updated/releases/tag/HLBSU-V1.0.0-beta008

Changes for all games:

• Fixed node graphs being loaded from search paths other than GAMECONFIG path (properly this time)
• Fixed node graphs being loaded with a null byte appended
• Fixed "fullupdate" call making a HUD disappear
• Fixed STL Algorithm Header Errors When Included with Platform.h

Changes for Opposing Force:

• Fixed not being able to open team menu after a full CTF round has been played
• Fixed npc_gonome trying to play non-existent sounds
• Fixed monster_tentacle missing spawnflag 64 (different model option)

I've tested Opposing Force CTF using multiple clients on a LAN. Everything seems to be working fine, so i'm fairly certain that this will be the last beta release before the full release.

That error means your computer doesn't support the version of OpenGL that's needed to run the program.

The planned changes for 2.0.0 might solve this problem for you and a few others that have had this error, but i can't guarantee that. I can't give an ETA on when the next version will be out, but i'll try to get this done soon.

Because the game uses the custom TGA loading code it's had since before the switch to SDL2.

Skill2Json tool release

I've released a beta version of a new tool called Skill2Json. This tool converts original Half-Life skill.cfg files to the Unified SDK's skill.json format.

Download here: https://github.com/SamVanheer/HalfLife.UnifiedSdk-CSharp/releases/tag/Tools-v0.1.0

See the readme for more information: https://github.com/SamVanheer/HalfLife.UnifiedSdk-CSharp#halflife-unified-sdk-csharp-tools

HalfLife.UnifiedSdk.Utilities

This library now has a Tokenizer struct that can extract tokens out of text just like the game's COM_Parse function. I haven't published a new version on Nuget yet since i'm probably adding more to the library soon.

Small addendum for the new skill system

I've removed the sk_ prefix from all skill variables. This prefix was only needed because the values were stored in cvars. Removing this removes the visual noise and repetition, and also reduces memory usage a bit (not by any significant amount). Variables that now start with a number have been renamed, in all cases this meant swapping the words in the name from numbermm_bullet to bullet_numbermm.

Only the value for the current skill level is now stored in-memory. The skill file is reloaded on map start anyway and the skill level cannot be changed without restarting the map (or using sk_reload after changing the skill level) so storing this information was pointless and wasteful.

The sk_set command no longer takes a skill level parameter and the sk_find command now prints the value for each variable it finds.

And finally variable names are now parsed using the same regular expression used by the JSON schema to validate the input so the behavior is consistent with validation on and off. This also simplifies the logic for parsing names.

I think that's just about everything needed for skill variables for now.

New JSON-based skill configuration system

I've implemented the JSON-based skill configuration system i've talked about before.

This replaces skill.cfg entirely and removes the hard-coded values used in multiplayer. It eliminates the need to define, register and synchronize cvars and variables in the skilldata_t struct while also allowing you to change the values in real-time (except in those cases where the values are cached, like an NPC's health for example).

Support for conditional values is present to allow for multiplayer-only values.

See the documentation page for more information and a comparison between the old and new systems: https://github.com/SamVanheer/halflife-unified-sdk/wiki/Skill-configuration-system

Yes, the same code is used in singleplayer and multiplayer.

But there are other places were sounds are played, like studio event 5004:
https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/entity.cpp#L369-L372

But the bullet hit flesh sound doesn't play either way, it's never called, so if you call TEXTURETYPE_PlaySound it will play the correct flesh hit sound?

The client is playing a sound, it's just not the flesh sound. If it can't identify the surface type it defaults to concrete:
https://github.com/SamVanheer/Half-Life-Tools-Backup/blob/10b7ac15af91e50dad170af48bf77dcdf18dadf6/src/cl_dll/ev_hldm.cpp#L155-L160

I did see that it was a pointer, and so then if it correctly does the traceresult, you can call TEXTURETYPE_PlaySound(&tr, vecSrc, vecEnd, iBulletType); inside the switch statement, no? All the appropriate variables are needed for the call, the traceresult knows the entity that was hit

You can, but the client is playing sounds as well so you'll end up playing them twice.

I know there's something I'm not understanding about how this engine works... is EV_HLDM.CPP where client processing happens? Why is it called HLDM if so?

It's called that because the client side code was added for multiplayer. It was originally server only, but to compensate for lag it was moved to the client. Half-Life multiplayer is Half-Life Deathmatch, hence HLDM.

What happens with the traceresult at this line https://github.com/SamVanheer/Half-Life-Tools-Backup/blame/10b7ac15af91e50dad170af48bf77dcdf18dadf6/src/dlls/combat.cpp#L1534 ? That doesn't figure out what was hit? Does it not modify the tr variable?

The function does modify the trace result. The last parameter passed in is a pointer to the result variable which the trace result is stored in. It's used to determine which entity to deal damage to.

iDamage is used to pass a custom damage value to FireBulletsPlayer. None of the weapons do that, so that code never gets executed. As for why it plays sounds, that's probably a leftover because nobody realized it was still there. Since nothing actually causes that code to execute nobody noticed.

There are several cases of unfinished pieces of code, leftover stuff and simple mistakes all made during the SDK 2.0 period, so this is just another one of those.

I've updated the project descriptions, wikis and releases for Half-Life Updated, Half-Life: Opposing Force Updated and Half-Life: Blue Shift Updated to include links to the main wiki page, as well as a sidebar and footer, both of which contain navigation links for all three projects.
Redundant pages have been removed from the wiki and the About page has been moved to the Home page (default page).

Each wiki has the same sidebar, so you'll jump around these wikis when clicking on the project-specific links.

I hope all of this will make it easier for people to see what these projects are about and what you can and cannot do with them.

This page is now your starting point to learn about these projects: https://github.com/SamVanheer/halflife-updated/wiki

Note that once these projects are finished and the repositories are read-only i'll be making a version of this page on the Unified SDK wiki that will become the new hub for that project. It'll refer back to these projects, but won't have navigation going back because it'll have everything these projects have.

Some old links will no longer work but you should be automatically redirected to the Home page.

Also note that for older releases the instructions are no longer correct. Due to the switch first to PowerShell and then to C# the instructions are not correct for those releases. Since the changes only deal with running install scripts to copy maps this isn't important enough to keep old versions available for.

I've also added tags to all 3 projects to make them easier to find them when searching Github by topic.

This seems to be caused by differences in how the sprite texture is blended before being uploaded. If you switch to the D3D renderer in WON it'll do the same thing.

And so for the sound then it would require a big rework or something. I wonder how Sven Coop achieved this. I'm just looking for the most nostalgia way to play half life for myself lol

They probably added the hit sound on the server sound, or they added a new variable sent to the client to let it pick the right sound (they have engine access, so they can do that).

In WON, there was a hit sound when you shoot humans / aliens with a bullet, but in steam that is no longer there. Sven Coop actually added this back. Is this something you've added in this unified SDK? If not, do you know anything about it?

In SDK 2.2 the code to handle bullets was split into a monster-only and a player-only version. The monster-only version still has the hit sound code:
https://github.com/SamVanheer/Half-Life-Tools-Backup/blame/10b7ac15af91e50dad170af48bf77dcdf18dadf6/src/dlls/combat.cpp#L1456

The player-only one does not:
https://github.com/SamVanheer/Half-Life-Tools-Backup/blame/10b7ac15af91e50dad170af48bf77dcdf18dadf6/src/dlls/combat.cpp#L1551-L1553

The sounds are played on the client side for players:
https://github.com/SamVanheer/Half-Life-Tools-Backup/blob/10b7ac15af91e50dad170af48bf77dcdf18dadf6/src/cl_dll/ev_hldm.cpp#L413-L418

But since the client doesn't know what exactly is getting hit it can only handle sounds properly for players and the world:
https://github.com/SamVanheer/Half-Life-Tools-Backup/blob/10b7ac15af91e50dad170af48bf77dcdf18dadf6/src/cl_dll/ev_hldm.cpp#L115-L151

For reference, the server's version:
https://github.com/SamVanheer/Half-Life-Tools-Backup/blob/10b7ac15af91e50dad170af48bf77dcdf18dadf6/src/dlls/sound.cpp#L1646-L1651

Fixing this properly is impossible since the client can't just ask the entity like the server does. You could send the relevant information to clients using user variables (iuser) but there are only so many of those.

As well as making the crosshair similar to the WON crosshairs?

What's different about the crosshairs? Are you talking about sv_aim or something else?

Half-Life Updated betas released

Half-Life Updated, Half-Life: Opposing Force Updated and Half-Life: Blue Shift Updated betas have been released:
Half-Life Updated: https://github.com/SamVanheer/halflife-updated/releases/tag/HLU-V1.0.0-beta010
Half-Life: Opposing Force Updated: https://github.com/SamVanheer/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0-beta006
Half-Life: Blue Shift Updated: https://github.com/SamVanheer/halflife-bs-updated/releases/tag/HLBSU-V1.0.0-beta007

Notable changes for all games:

• Fixed (Black Ops) Osprey crashing if it has no valid target
• Fixed (Black Ops) Osprey teleporting to world origin if it isn't moving at all
• Fixed (Black Ops) Osprey and (Black Ops) Apache not firing trigger targets
• Fixed (Black Ops) Osprey engine damage effects showing on wrong engine
• Pass director stufftext commands to filtered client command function
• Fixed RPG sometimes getting stuck unable to reload
• Fixed Tentacle not interpolating
• Fixed node graphs being loaded from search paths other than GAME path (caused the wrong graph from vanilla HL to load sometimes)
• Fixed momentary_door restarting movement sound repeatedly when moving back to starting position
• Deleted Makefiles and libraries for MacOS X (Half-Life 1 is 32 bit, no longer supported by MacOS)

Notable changes for Opposing Force:

• Fixed Otis Using Barney Voice Lines

This beta will be used to test multiplayer functionality, after which a full release of V1.0.0 will be made available.

Please take a moment to read the About page if are thinking of copying dlls around manually.

I've also added a new page to each repository's wiki containing a full changelog of all changes that have been made, excluding changes that involve bugs introduced in alpha and beta builds of these projects. These changelogs represent all changes from the original games to V1.0.0.

I'm going to tidy up the wiki a bit by adding links to the pages to more easily navigate everywhere, and add additional links to releases and project descriptions so people can find this information more easily.

Utility projects

The SDK's utility projects have been upgraded to compile with Visual Studio 2019. All projects with the exception of smdlexp (3DS Max plugin) compile and - with the exception of the procinfo library - run now, although some aren't very useful.

All projects are now 100% compiled as C++ which helps catch some problems that are permitted in C. I've also refactored the code a bit to eliminate redundant code.

The CMake version has more work done to eliminate redundant code.

Thanks to fel1x-developer for helping with this.

Progress on Half-Life Unified SDK

I've reworked the JSON loading code a bit so user code doesn't need to manage the creation of JSON validators anymore. This simplifies the code a bit and delegates the responsibility to the JSON system. Validators are only created if validation is enabled, which helps to cut down on memory usage and startup time cost.

More work is planned for the JSON system to eliminate differences between validation enabled and disabled modes.

@BAJIET

You're welcome

@SourceSkyBoxer

Glad to see you were able to solve your problems.

I've written an article that covers the basics of creating a bot that can spawn, stand and be attacked: https://twhl.info/wiki/page/Bot_Programming_-_Getting_Started

For AI programming you'll need to look at RCBot and other bot plugins.

Not unless you add support for it yourself. You can take the Makefiles from Half-Life Updated to use as a base, but the code isn't updated to compile on Linux so i can't say if it'll work without modifications.

VS 2022 should work fine. Just open the solution in it, it'll automatically upgrade it.

But do note that you should only use this if you're making mods for WON. For Steam you're better off with newer SDKs.

I've updated the Half-Life Singleplayer SDK 2.3 to compile with Visual Studio 2019: https://github.com/SamVanheer/halflife-2_3

I've also fixed all warnings.

Basic testing done with WON version 1.1.0.8 and Steam Half-Life. No further support will be provided, but if you're interested in working with this SDK version or if you need guidance on fixing up old SDKs you can use this as a reference. See the commits for how to fix issues encountered when upgrading to a newer version of Visual Studio.

Half-Life Updated betas released

Half-Life Updated, Half-Life: Opposing Force Updated and Half-Life: Blue Shift Updated betas have been released:
Half-Life Updated: https://github.com/SamVanheer/halflife-updated/releases/tag/HLU-V1.0.0-beta009
Half-Life: Opposing Force Updated: https://github.com/SamVanheer/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0-beta005
Half-Life: Blue Shift Updated: https://github.com/SamVanheer/halflife-bs-updated/releases/tag/HLBSU-V1.0.0-beta006

Notable changes for all games:

• Fixed chainsaw hornetgun sounds and mostly fixed hornetgun not playing firing animation
• Fixed Gauss charge sound not always being reset
• Show pickup icons in HUD for all weapons (except when spawning with weapons)
• Fixed picking up weapons that give free/regenerating ammo sometimes showing weapon icon as red
• Fixed hand grenades staying primed when switching away or dropping the weapon
• Fixed event code crashing if weapon prediction is disabled
• Automatically switch away from exhaustible weapons that have no ammo left (even in singleplayer)
• Fixed controlling a func_tank with empty weapon deploying invisible weapon when stopping control (now switches to next best weapon)
• Fixed m_rawinput changes not taking effect if a new map has started and less time has passed than on any previous map or if weapon prediction is disabled
• Fixed Osprey not interpolating
• Rewrote the installation and packing scripts to use C#

Notable changes for Opposing Force:

• Fixed game crashing when loading map due to null scoreboard pointer
• Fixed pipe wrench big swing attack not cancelling when the wrench is unequipped
• Fixed player saytext color being incorrect in deathmatch games
• Fixed TeamInfo message being sent to wrong player when initializing player hud in CTF gamemode

This beta will be used to test multiplayer functionality, after which a full release of V1.0.0 will be made available.

Please take a moment to read the About page if are thinking of copying dlls around manually.

This is the first release to use the C# install scripts. I have tested the scripts on a new Windows 10 installation, so i'm fairly confident that the instructions cover all of the required dependencies and steps needed to run them. If you encounter any issues please don't hesitate to let me know.

The install scripts are a bit different from previous ones: all singleplayer and training maps are now copied, maps that require Ripent patching are automatically updated. Blue Shift maps are converted automatically.

Node graph files in the mod directory for official maps copied to the mod are deleted if they exist to avoid problems with incorrect node graph files and to force them to regenerate. this was done as an installation step rather than a node graph version change because the node graph code itself has not changed and thus should not require a version change.

The packing script will automatically pack the contents of modname_hd, modname_lv and modname_language directories if they exist (where language is a language listed here in the API language code column, except for english since that's the default).

For more information on editing, running and debugging C# scripts, see this wiki page: https://github.com/SamVanheer/halflife-unified-sdk/wiki/Setting-up-and-using-dotnet-script

HalfLife.UnifiedSdk.Utilities updates

I've updated the C# utility library to include the latest version of the Sledge.Formats.Bsp library, as well as made sure all maps are written in the standard BSP format rather than the Blue Shift BSP format. I've also added utility functionality to get the list of languages supported by Steam for use in automating the management of language-specific mod directories, as well as constants to manage content directories such as modname_hd.

@SourceSkyBoxer Thanks, you stay healthy too!

Continued from previous post <---

Progress on Half-Life Updated

The previous test we did showed some more problems with the weapon prediction code. I've fixed as many issues as i can there, unless the next test shows more issues that can be fixed in a reasonable amount of time i'd consider that done.

I've also fixed some other issues such as hand grenades remaining primed when unequipped or dropped, and Opposing Force crashing on map load. I think this fixes an issue that prevented the CTF test from continuing, but i'm going to run some more tests to be sure about that.

Once i'm satisfied with those tests i'll schedule another beta test. Hopefully this'll be the last one.

Many thanks to malortie and Shepard for helping with the previous test.

Progress on Half-Life Unified SDK

malortie has continued working on updating the models and has made good progress streamlining the assets and asset sources. This will make it easier to make maps that use models and animations specific to one of the Half-Life 1 games without having to use model replacement.

I've also added a Visual Studio hint file to stop Intellisense from giving false positives about some macros used in code: https://github.com/SamVanheer/halflife-unified-sdk/commit/5a101fea5d3415b7a04b52d0ac9c90461d0e4948

This eliminates the green squiggles seen under code like LINK_ENTITY_TO_CLASS and allows you to use Go to Definition on Save and Restore methods and gets rid of the visual noise those warnings show in the editor, making it easier to find code that is actually in need of attention.

I'll be done with the tests for Half-Life Updated pretty soon, once that's done i'll get to work completing some tasks for the Unified SDK. Things should start progressing faster now that all of this work has been done, so hopefully i can start setting up dev builds and stuff soon.

That's all for now, i'd like to thank everybody who has been helping to test and fix Half-Life Updated and get the Unified SDK off the ground. I really appreciate it.

Progress update for 06/3/2022

I've released a beta version of a C# library meant to aid in the writing of the install scripts as well as other tasks that will come up during the Unified SDK's development: https://github.com/SamVanheer/HalfLife.UnifiedSdk-CSharp

The HalfLife.UnifiedSdk.Utilities library contains utility functionality for opening, analyzing, modifying, converting and upgrading Half-Life 1 maps made for the GoldSource engine.

This library uses the Sledge.Formats.Bsp and Sledge.Formats.Map libraries to load .rmf, .map, .bsp and .ent files. Many thanks to Penguinboy for creating these libraries and updating them to support the loading of Blue Shift BSP files.

Note that Sven Co-op uses a modified BSP format. Trying to use this library with those files might not work and could cause crashes and data corruption.

The provided functionality replaces the BlueShiftBSPConverter and ripent tools currently used to install content. Along with the standard ZipFile API provided as part of the .NET runtime replacing the use of the 7zip tool this eliminates the use of platform-specific tools in all scripts.

In theory this will allow the scripts to run on Windows 7 SP1 and newer, modern Linux distributions and macOS 10.15 and newer. They will work on both 32 and 64 bit platforms since there are no architecture-specific dependencies.

Consult the .NET 6 supported operating systems documentation for more information about which platforms are supported: https://github.com/dotnet/core/blob/main/release-notes/6.0/supported-os.md

In short, this library allows you to manipulate the entity data contained in maps and map source files. You can search through maps for occurrences of entities, keyvalues, entity setups ranging anywhere from a simple trigger to complex setups involving hundreds or even thousands of entities, anything you can think of and more.

You can also modify the entity data. You can add, remove and modify keyvalues and add and remove entities programmatically.

This library is powerful enough to write scripts that can convert maps from one GoldSource engine game to another, for example you could convert a Day of Defeat map to Counter-Strike with this.

Also provided with the library is a tool to help automate the upgrading of maps from an older version of a game to a newer version. This tool is intended to be used to upgrade original Half-Life 1, Opposing Force and Blue Shift maps to the Unified SDK, and then upgrade all maps automatically to newer versions of the SDK whenever breaking changes are made.

This upgrade process should hopefully work on both BSP files as well as map source files. There is currently no support for modifying .jmf files (J.A.C.K. map source files) but hopefully full support can be added to Sledge.Formats.Map someday.

Unfortunately there is no cross-platform means of locating Half-Life installations programmatically. On Windows you can use this helper function:

var halfLifeDirectory = SteamUtilities.TryGetModInstallPath() ?? throw new InvalidOperationException("Steam or Half-Life isn't installed");

On Windows Steam writes a few registry keys, one of which contains the install location of Half-Life. On Linux it's up to the user to provide the location, so the install scripts will use the script's location as a starting point.

Here are some examples of scripts i've written to test the library. These scripts are executed using dotnet script.

This script counts the number of human grunts that exist in Half-Life games:

#r "nuget: HalfLife.UnifiedSdk.Utilities, 0.1.0"

#nullable enable

using HalfLife.UnifiedSdk.Utilities.Entities;
using HalfLife.UnifiedSdk.Utilities.Games;
using HalfLife.UnifiedSdk.Utilities.Maps;
using HalfLife.UnifiedSdk.Utilities.Tools;

var counts = MapFormats.EnumerateMapsWithExtension("bsp",
    "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/valve/maps",
    "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/gearbox/maps",
    "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/bshift/maps")
    .WhereIsCampaignMap()
    .GroupBy(m => m.FileName, m => m.Entities.OfClass("monster_human_grunt").Count()
        + m.Entities
            .OfClass("monstermaker")
            .WhereString("monstertype", "monster_human_grunt")
            .Select(e => e.GetInteger("monstercount"))
            .Sum())
    .ToList();

var countsByGame = counts.GroupBy(c => Path.GetFileName(Path.GetDirectoryName(Path.GetDirectoryName(c.Key))));

foreach (var game in countsByGame)
{
    Console.WriteLine("{0} human grunts in {1}", game.Sum(g => g.Sum()), game.Key);
}

Output:

174 human grunts in valve
0 human grunts in gearbox
81 human grunts in bshift

This script counts both the actual grunt entities as well as monstermaker entities that spawn them, and counts the number of them it spawns. It doesn't account for infinitely spawning makers, but that's an easy thing to add. (Opposing Force has none because it uses a different entity)

Here's an example of how a map can be upgraded:

static void ReplaceWorldItems(Map map, Entity entity)
{
    //Convert world_items entities to their respective entities
    if (entity.ClassName == "world_items")
    {
        switch (entity.GetInteger("type"))
        {
        case 42:
            entity.ClassName = "item_antidote";
            entity.Remove("type");
            break;

        case 43:
            //Remove security items (no purpose, and has been removed from the codebase)
            map.Entities.Remove(entity);
            break;

        case 44:
            entity.ClassName = "item_battery";
            entity.Remove("type");
            break;

        case 45:
            entity.ClassName = "item_suit";
            entity.Remove("type");
            break;
        }
    }
}

static void UpgradeWorldItems(MapUpgradeContext context)
{
    foreach (var entity in context.Map.Entities)
    {
        ReplaceWorldItems(context.Map, entity);
    }
}

static readonly string BaseDirectory = "./upgrade";

var unifiedSdk100UpgradeAction = new MapUpgradeAction(new SemVersion(1, 0, 0));
unifiedSdk100UpgradeAction.Upgrading += UpgradeWorldItems;

var upgradeTool = new MapUpgradeTool(unifiedSdk100UpgradeAction);

var map = MapFormats.Deserialize(Path.Combine(BaseDirectory, "c1a0d.bsp"));

upgradeTool.Upgrade(new MapUpgrade(map));

Console.WriteLine($"Upgraded map to {upgradeTool.GetVersion(map)}");

using (var file = File.Open(Path.Combine(BaseDirectory, "c1a0d_new.bsp"), FileMode.Create, FileAccess.Write))
{
    map.Serialize(file);
}

This will upgrade maps to replace world_items with the entity it normally spawns, while removing item_security altogether since it's an obsolete entity.

You can also get a list of Valve games running on the GoldSource engine and the official maps they have to help automate certain tasks.

Here's a script to get a list of all mods installed in the Half-Life directory:

foreach (var modDirectory in ModUtilities.EnumerateMods(HalfLifeDirectory).Except(ValveGames.GoldSourceGames.Select(g => g.ModDirectory)))
{
    Console.WriteLine($"Found mod {modDirectory}");

    if (ModUtilities.TryLoadLiblist(HalfLifeDirectory, modDirectory) is { } liblist)
    {
        Console.WriteLine($"Mod is called {liblist.Game ?? "not listed"}");
    }
}

In my case it outputs this:

Found mod czeror-sdk
Mod is called Condition-Zero: Deleted Scenes SDK
Found mod ehl
Mod is called Enhanced Half-Life
Found mod halflife-pr
Mod is called Half-Life PR
Found mod halflife-updated-cmake
Mod is called Half-Life Updated CMake
Found mod halflife_bs_updated
Mod is called Half-Life: Blue Shift Updated
Found mod halflife_op4_updated
Mod is called Half-Life: Opposing Force Updated
Found mod halflife_updated
Mod is called Half-Life Updated
Found mod hlenhanced
Mod is called Half-Life Enhanced
Found mod hlu
Mod is called Half-Life Unified SDK
Found mod scriptablemod
Mod is called Half-Life Scriptable Mod

Continued in next post --->

The executable to use for compiling is whatever studiomdl.exe you want to use. This tutorial covers everything about compiling including the studiomdl to use: https://www.the303.org/tutorials/gold_mdl.htm

The default textures thing is a feature in studiomdl that lets you replace textures specified in the mesh smd, you can ignore that if you don't need it. I doubt anybody ever actually uses that feature anyway (it's also buggy).

I'd recommend using Crowbar if you want a proper GUI for compiling models. The GUI i made is a thin wrapper around vanilla studiomdl provided so people can use it through this tool if needed. Crowbar on the other hand is a purpose-built tool made to compile models and do all sorts of stuff.

Here's the website for Crowbar: https://steamcommunity.com/groups/CrowbarTool

You can find more tutorials on that website as well.

I'll probably expand on the compiler front-end at some point, but since Crowbar already does everything very well there's no pressing need right now.

I will be hosting a listen server to test first Half-Life Updated multiplayer (deathmatch and teamplay), and then Opposing Force Updated multiplayer (deathmatch, teamplay and capture the flag). We'll switch mods to test Opposing Force.

The goal is to make sure that there are no game-breaking bugs, no egregious visual and/or sound bugs like infinitely looping animations and sounds and that all game mode work as intended.

To participate in this test you'll need to install Half-Life Updated and Half-Life: Opposing Force Updated in the directories specified in the installation instructions for both mods.

Note that there might be problems with the PowerShell scripts used to install game content. You don't need that content to participate in the tests, so you can skip running the scripts.

I will be replacing those scripts with C# scripts as i initially wanted to which should fix those problems. A separate beta will be released for that later on, which will include any other fixes if today's test shows there is a need.

The IP for the server is <server no longer up>. I'll be putting the server up a bit before the test starts. The server will need to be restarted to test Opposing Force.

The test will start at 4 PM GMT +1 (UTC +1). That's in 2 hours and 50 minutes.

Half-Life Updated betas released

Half-Life Updated, Half-Life: Opposing Force Updated and Half-Life: Blue Shift Updated betas have been released:
Half-Life Updated: https://github.com/SamVanheer/halflife-updated/releases/tag/HLU-V1.0.0-beta008
Half-Life: Opposing Force Updated: https://github.com/SamVanheer/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0-beta004
Half-Life: Blue Shift Updated: https://github.com/SamVanheer/halflife-bs-updated/releases/tag/HLBSU-V1.0.0-beta005

Notable changes for all games:

• Fixed some weapon prediction bugs
• Fixed chat text sometimes using the wrong color
• Fixed explosions going through walls sometimes
• Fixed tripmine beams showing up in the wrong position sometimes and duplicating after level changes

Notable changes for Opposing Force:

• Finished implementing Capture The Flag gamemode
• Fixed player info bar in CTF gamemode showing incorrect health for dead players

This beta will be used to test multiplayer functionality, after which a full release of V1.0.0 will be made available. This will be the last update released for the Updated projects, after which development will shift to the Half-Life Unified SDK.

@fresco Thanks for the compliments

@tschumann As Admer said it's in that commit.

I think i'm just about done with fixing Opposing Force CTF issues. A lot of problems with Half-Life multiplayer have also been fixed, in addition to a couple nice-to-have issues. I've got a couple more things to check out, but i think it's almost time to run another test.

Progress update for 31/01/2022

Shepard and I did a multiplayer test last week and found a number of issues. Most of them are related to weapon prediction but there are also a few other issues that still need looking into. Opposing Force CTF has a number of bugs that still need to be fixed but it's going pretty well.

I'm confident that the next multiplayer test will show that all games are ready for a full release, but we'll have to wait and see.

malortie has been creating updated models that include animations from all 3 games to ensure that scripted sequences work properly across all games using the same model files. This will make it easier to make mods that reference animations specific to individual games.

Half-Life Unified SDK progress

Shepard and I have fine-tuned the Continuous Integration configuration to speed up automated builds as much as possible. I've added precompiled headers to the client and server projects to dramatically speed up the build times for both projects.

The entire Unified SDK solution builds in 30 seconds on my machine now, whereas before it took 2 minutes when nothing else is using the computer's resources. When you're doing things in the background it could easily take 5-10 minutes before whereas now it isn't impacted nearly as much since Visual Studio uses fewer CPU cores to compile everything.

Github CI builds meanwhile are nearly twice as fast as before, from ~9 minutes to ~5.

These are full builds, not partial builds which you'll be doing most often during development. Partial builds are faster than full builds so this makes it much easier to iterate on your code's design.

I've also cleaned up commonly used headers to simplify header inclusions a bit. You no longer need to include extdll.h and util.h before including cbase.h and many other common headers are also included in cbase.h which means you'll get access to common entity classes like CSprite right off the bat.

I've also added a new debug-only feature to help diagnose incorrect usage of SetThink, SetUse, SetTouch and SetBlocked. If you try to set one of these to a function pointer that does not belong to the class hierarchy of the entity that you're setting the function on you'll get an error message in the console warning you about it. Setting a function incorrectly can cause strange bugs and crashes so this will help a lot.

The continued focus on code cleanup and speeding up build times should make for a better SDK to work with that hopefully takes up less disk space as well (Visual Studio Intellisense generates database files with sizes measured in gigabytes). In the past i've noticed that precompiled headers cut down on the amount of disk space used by Intellisense so that should help.

I've also configured the third party library Git submodules to be included using shallow clones which should reduce the amount of bandwidth and disk space required to download and store those dependencies.

Also note that work that was added to projects like HLEnhanced will mostly be integrated into this one at some point. This also includes the work i've previously mentioned for Enhanced Half-Life, but like all things it will take time to do so. Some of these features are breaking changes, and i want to set up proper procedures for handling those before i start changing things. I will go into more detail on the plans for that later on.

Until the Updated projects are complete there won't be much progress on the Unified SDK. With the way things are going right now it'll probably take another week or 2 to finish those up. Once that's all done we can look at where to go next.

That's all for now. I'd like to thank everybody that's been helping out on these projects, and hopefully we can put the Updated projects to bed sooner rather than later.

Half-Life Updated betas released

Half-Life Updated, Half-Life: Opposing Force Updated and Half-Life: Blue Shift Updated betas have been released:
Half-Life Updated: https://github.com/SamVanheer/halflife-updated/releases/tag/HLU-V1.0.0-beta007
Half-Life: Opposing Force Updated: https://github.com/SamVanheer/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0-beta003
Half-Life: Blue Shift Updated: https://github.com/SamVanheer/halflife-bs-updated/releases/tag/HLBSU-V1.0.0-beta004

Notable changes:

• Fixed models stuttering due to client side interpolation
• Rewrote installation scripts to use PowerShell
• Added support for adding 64 weapons
• Removed VS2017 projects
• Cleaned up the codebase to remove unused code
• Enabled clang-tidy code analysis rules
• Added clang-format configuration file to share code formatting settings with other developers
• Formatted the codebase to use a consistent style (easier to read and search in)
• See the full changelog for 100+ changes

This beta will be used to test multiplayer functionality, after which a full release of V1.0.0 will be made available. This will be the last update released for the Updated projects, after which development will shift to the Half-Life Unified SDK.

Progress update for 11/01/2022

All changes have been merged into Half-Life Updated CMake and the Unified SDK, and all problems preventing compilation on Linux have been resolved.

Shepard has set up Continuous Integration to automatically build the SDK on Windows and Linux. This is currently used only to automatically determine if the SDK successfully builds on both platforms, but in the future it could be used to automatically provide the latest versions of both the client and server libraries on both platforms.

You can see the CI builds in action here: https://github.com/SamVanheer/halflife-unified-sdk/actions

A badge has been added to the readme to show if builds are succeeding or failing.

All pending pull requests have been merged in on all repositories and all issues have either been resolved, transferred to the Unified SDK repository or closed with the sole exception of an issue tracking a problem with the Half-Life Updated game package which i'll be putting up soon.

I've rewritten the scripts used to create those game packages as well as the game install scripts to use PowerShell instead of batch scripts. PoiwerShell syntax is easier to work with, common commands are easier to recognize and use and most importantly it's cross-platform.

These scripts should work on Linux which will make it easier to create Linux versions of game packages and to install content from other games. Unfortunately PowerShell 7 - which is the cross-platform version - isn't available on Windows 7 which is still supported by this SDK so the scripts are required to work in both PowerShell 5.1 (Windows only) and PowerShell 7. This isn't a problem since the scripts don't rely on any features exclusive to either version but some script code is a bit more verbose as a result (mostly Join-Path usages).

To make the scripts easier to work with the boilerplate logic is separate from game-specific parts, this makes it easier to tell which parts require modifying. It's also been redesigned to support copying content from multiple games which the Unified SDK requires.

malortie has been hard at work creating updated models for the Unified SDK. Low definition and high definition versions of each view model for each set of hands (HEV, PCV and guard) will be included to support using all weapons in any mod. Additionally a third person player model ("player.mdl", used to trace attacks directed at players) for Barney has also been created to match the models used in Half-Life and Opposing Force.

Right now i need to test Half-Life Updated, Opposing Force Updated and Blue Shift Updated's singleplayer campaigns to see if anything is broken. Any issues that crop up that didn't already exist will be fixed to ensure that these repositories contain a relatively stable codebase.

Once that's done i'll put together beta packages for each of the 3 repositories. I'd like to run some tests in multiplayer to make sure nothing is broken there (e.g. broken game mode or friendly fire issues) so if anybody's interested we can organize some tests. I'm going to add basic bot support (bots that just stand in place, no AI) to run some tests in isolation but some game modes require more than that.

Only Half-Life and Opposing Force Updated need multiplayer testing since Blue Shift multiplayer is identical to Half-Life (and the game isn't meant to be played in multiplayer), and Opposing Force multiplayer differs mainly in the existence of the Capture The Flag game mode, so ideally multiplayer testing involves first testing Half-Life deathmatch, teamplay and then the Opposing Force versions before testing CTF.

Once this is all done and all issues have been resolved then a full 1.0.0 release will be done for each Updated repository and each repository will then be archived. The Half-Life Updated CMake repository will be removed entirely after this, since it's no longer useful at that point.

This entire process will probably take a week or 2 to complete depending on whether any bugs crop up.

For now i'd like to thank everybody who contributed to the development of these projects and getting the Unified SDK up and running, and i hope to have a first version of the SDK available for use soon, but we'll see about that after this work is all done.

I doubt the updated SDK is at fault here. Just tell us what you did so we can see what's causing the problem.

Which changes did you make?

This happens because of a problem in older versions of the STL included with Visual Studio. It was removed at some point: https://github.com/microsoft/STL/issues/717

Make sure you're using Visual Studio 2019 or newer with the v141 toolset or newer, make sure it's not the XP toolset and make sure Visual Studio is up-to-date. Run the Visual Studio Installer and install any updates you get for Visual Studio.

If the problem persists, let me know which version of Windows you're using and which version of Visual Studio you're using (the exact version number, like 16.11.8).

i use an older version of halflife-updated because the solution won't compile on vs2019 and it constantly errors on some std::atomic thingy

What is the error you're getting related to std::atomic?

What is the error you're getting?

Progress update

The VS 2017 project files have been removed from all repositories.

I've fixed a few more bugs that slipped in during some of the overhauls. One of the biggest is a change to the Vector type that changed how the GCC compiler optimized passing vectors by value. This change broke compatibility with the particle manager library, which ships as part of the game.

To fix the issue i've re-implemented the library in the client library. I've also fixed a couple bugs in it, such as memory leaks and a use-after-free issue. Because it's now implemented in the client it is no longer possible for players to cheat by deleting the particleman library.

All changes have been merged into the following repositories:

• Half-Life: Opposing Force Updated
• Half-Life: Blue Shift Updated
• Condition Zero Deleted Scenes SDK

The Deleted Scenes SDK also received an implementation of the material system used by that game. Nothing is actually using the material system, but the implementation is now available for use if anybody wants it. It's unlikely that it will work without further modifications. I plan to implement a new material system in the Unified SDK at some point that will provide this functionality in a better way.

This system was partially implemented already (i needed parts of it for something years back), so i've finished it to get the work out of the way.

I've also fixed a mistake i made in the DS SDK where CTriggerChangeKeyValue didn't increment a variable used to keep track of how many keyvalues had been initialized already.

The DS SDK will be archived along with the others when the Unified SDK is set to become the new default SDK for use.

I forgot about the halflife-fog repository, which will also be integrated into the Unified SDK. It implements OpenGL-based fog effects. Deleted Scenes also has fog so whichever implementation of those two and any alternates provided by the community is best will be used.

Most of the changes made to Half-Life Updated have been merged into Half-Life Updated CMake. A few changes remain, then i can focus on merging the changes into the Unified SDK.

I'd also like to thank suXinjke, vasiavasiavasia95, malortie and Shepard for helping to get everything ready.

Discord channel

The TWHL server channel #sharplife has been renamed to #unified-sdk. It serves as a channel to discuss anything related to Half-Life Updated, Half-Life Unified SDK and Half-Life Asset Manager.

Status of SharpLife

Several people have asked about SharpLife, what its status is.

This project is on indefinite hold since its scope is much, much bigger than anything else i'm working on right now.

Whereas these SDKs are about improving game code, re-implementing some engine functionality and improving the quality of the code, SharpLife is about making a whole new engine. Such an endeavor is much more difficult and requires more time and experience to accomplish.

At this time i'd like to focus on improving these SDKs and finishing Half-Life Asset Manager. Perhaps after that i might work on SharpLife again, or attempt a C++-based version of the concept, but that's not something i'd like to decide right now. It's likely that this won't even be possible for several years given the amount of work that's left to be done for current projects.

The goal behind using C# was to make it easier to use for modders with little (C++) programming experience, but if an Angelscript-based scripting system can be used to handle game code (entities et al) then this isn't really necessary. The performance-critical parts can be implemented in C++ and the rest in Angelscript, or C# if such a combination is feasible.

The two languages are fairly similar to one another so it will likely come down to how easy they are to use in such a situation. That's not to say that i've done any research on the feasibility of using either, it's nothing more than an idea at this time. Perhaps with the right abstractions the language used can be swapped out much like Source's scripting system supports multiple implementations, but that would require a fair amount of work either way.

I'd advise against getting hyped up for any of this stuff since it's years away from even starting development, assuming such a thing will ever be done at all.

Immediate future of Unified SDK

As i said in the previous post, once work on the now-obsolete repositories is done the Unified SDK will get some cleanup work done. There are a lot of things i'd like to do but i don't want to make any promises before i know what's actually possible (both technically and legally). There is a list of planned upgrades on the repository you can check to see what's going to be done sooner or later: https://github.com/SamVanheer/halflife-unified-sdk/projects/3

Most planned upgrades concern improving boilerplate code that involve supporting multiple games within a single codebase. The goal is to allow you to play any Half-Life 1 PC game's campaign through the Unified SDK without having to make code changes. To make this work, some features like global model replacement are needed. Those features in turn need models to support this, namely viewmodels for each game's hand models. I haven't had time to check for the existence of such models though i have seen some used.

If anybody knows of viewmodels for the Opposing Force-exclusive weapons that use HEV and security guard hands, that would be a big help. Ideally both low definition and high definition versions should be used for consistency with the HD models setting, but i'll take what i can get.

It's important to remember that such models must be available under a license that allows redistribution with mods. This is to avoid scenarios where mods based on the Unified SDK suddenly need to remove files due to a copyright claim.

Right now i need to do a lot of merging of code into the Unified SDK, so it'll be some time before everything is synchronized. Once it's done i'll make another post to announce the archiving of all obsolete repositories. All remaining open issues will be moved to the Unified SDK repository at that time.

That should be just about everything for now.

That flag only works in Sven Co-op. It's not implemented in vanilla Half-Life.

You need to change the code for the entity to change the model. Most entities in Half-Life don't support custom models, so the model listed in the fgd will only show up in the map editor.

The project changes have been discussed in a few places the past few days, you can see some of these discussions here:
https://knockout.chat/thread/30908/1#post-1091521 (next page has the replies)

More discussions also took place on the TWHL and Half-Life Creations Discord servers.

The feedback has universally shown that nobody uses the VS 2017 projects anymore, so i'm going to remove those from all repositories.

Once the Unified SDK has been released i'm going to archive Half-Life Updated, Half-Life Opposing Force: Updated, Half-Life: Blue Shift Updated and Half-Life Updated CMake.

Projects made using these repositories will still work as before and will still be able to pull all changes made. Archiving a repository makes it read-only and adds a banner informing visitors that's it's been archived. No new issues or pull requests can be made and you will no longer be able comment on anything.

The Unified SDK provides all of the functionality that these projects have all in one SDK with a better workflow. It also solves some common tasks like changing HUD colors (easily done programmatically and through map entities, and will also be possible through configuration files and scripting) and integrating Opposing Force weapons and NPCs so there is no reason to continue using the other projects.

It does require knowledge of CMake but that's not a terribly difficult thing to learn. The project uses modern CMake so it's not an overly complicated thing to learn and use, and most of the time you're only going to be adding new headers and source files which is trivially easy to do.

Existing Github issues will be transferred to the Unified SDK repository to continue work on them there.

The first order of business now is merging all changes into the other repositories and fixing any issues that crop up. Once that's done i can get the Unified SDK to a releasable state. A final release of all of the Updated projects will be done to ensure that changes made to configuration files are available for use, and then the repositories will be archived and will direct users to the Unified SDK repository instead through the description. Further development will be done with that repository the same way it's been done before.

After that's all done i'd like to merge as many of the improvements i made to Enhanced Half-Life into this project as well, as well as the improved weapon class management from the better weapons repository (which will also be archived and eventually removed). I'm also going to review the changes i made to HLEnhanced to see what i can merge from that.

I'm also going to look at integrating an improved version of Condition Zero: Deleted Scenes' trigger_sequence entity. If Angelscript by itself is not good enough to manage such scripting functionality then providing a means of doing so through both entity and scripting means would be useful. It is likely that scripting will be sufficient given how the entity is implemented: https://github.com/SamVanheer/czeror-sdk/blob/1e732141e5823fa69596de388a269c1ba34a33b7/dlls/CTriggerSequence.cpp#L270-L371

This will allow the archiving of the Deleted Scenes SDK which only contains this entity and nothing else from Deleted Scenes. A full Deleted Scenes SDK would take a fair bit of work and i'm not so sure about making that. I'd prefer to add it to the Unified SDK instead as an optional component to make it easier to work with, but that's something i'm going to wait to decide on until after work on Half-Life campaign support is complete.

All in all, this will see the merging of these projects into a single project:

• Half-Life Updated
• Half-Life: Opposing Force Updated
• Half-Life: Blue Shift Updated
• Half-Life Updated CMake
• HLEnhanced
• Enhanced Half-Life
• Half-Life Better Weapons
• Condition Zero: Deleted Scenes SDK

After this point the goal will be to continue fixing compiler warnings, enabling and fixing clang-tidy warnings, cleaning up code, fixing bugs and improving SDK functionality.

I would like to ask that all contributors hold off on making more pull requests for now until i can get this all sorted out. I'm not certain how long it will take to complete the remaining work, but hopefully it should be done in a few weeks time at the most.

I've made the Half-Life Unified SDK repository visible. If needed pull requests can be made on that repository instead.

Note that this is a work in progress project, i haven't yet had the chance to review the requirements for a clean git clone and CMake setup. While everything should work fine there may be problems i'm not aware of right now. Once the work on the to-be-archived repositories is complete i can focus on finishing the first release of this project.

That's all for now, i'd like to thank everybody that gave feedback and to those contributing to development. Hopefully we can get a first version of the Unified SDK released before the end of the year. I'm very interested to hear what people have to say about it.

I've got a question for anybody using Half-Life Updated: does anybody still use the Visual Studio 2017 project files?

The system requirements for Visual Studio 2019 are almost identical to that of 2017, mainly differing in the minimum version of Windows 10 required and the recommended amount of RAM:
https://docs.microsoft.com/en-us/visualstudio/releases/2017/vs2017-system-requirements-vs
https://docs.microsoft.com/en-us/visualstudio/releases/2019/system-requirements

VS 2019 is also more flexible in how much disk space is required due to its different approach to installing it, but that's about it.

If nobody has need for it then i'll remove the 2017 project files. This will simplify development a bit and allows certain newer features to be used (like C++20).

The VS 2019 project files should work out of the box with VS 2022 (it will upgrade the files on first open), so there is no need to maintain a separate set of files for now.

In the long run once the Half-Life Unified SDK has been released it might be easier to use that as a base instead since it will encompass Half-Life Updated, Half-Life Opposing Force: Updated and Half-Life: Blue Shift Updated. At that point i'd prefer to archive the older repositories to focus on developing that version of the SDK instead.

It uses CMake so there is no problem with supporting different versions of Visual Studio, although this does require users to learn to use CMake. I can cover the basics in a tutorial which should get people going, but it does add an additional barrier to new modders.

On the flip side it does automate things that have to be done manually, like setting up the copying of game libraries to the mod directory so there are benefits to using it.

On that note: to use the CMake version of Half-Life Updated you currently have to build the INSTALL target to deploy the libraries, which might be a bit cumbersome and annoying. Visual Studio won't build this target if you try to run a project that needs to be rebuilt and instead launches an older version.

I can change this to instead deploy them when building the projects themselves, if this is something that's considered preferable i'll make it do that.

Some people have asked to make certain new features in the Unified SDK optional, like Angelscript for example. I've been pondering how feasible this is and i think i can make it work, although certain features that depend on such features will not work as well if it's disabled (e.g. conditional cfg files wouldn't work).

I'd like to get people's opinions on the matter before i make any decisions.

Don't use the change game dialog, that's obsolete and not guaranteed to work properly. The correct way to launch mods under Steam is to launch it directly through Steam or launching Half-Life with the -game parameter.

If your mod isn't loading then there might be a problem with your client.dll file. Follow this tutorial to figure out what's wrong: https://twhl.info/wiki/page/Half-Life_Programming_-_Debugging#h6017c5e17e73f

Regarding the work being done on Half-Life Updated at the moment: i'd like to thank malortie for helping to clean things up and fix bugs, it's really helping to make the SDK better.

I've completely eliminated the use of Windows headers in game code now, only 2 files still use it: inputw32.cpp (for raw input and mouse threading, which i'd like to convert to std::thread and related types) and interface.cpp (for loading dlls at runtime).

This has cut down on compile time some more. I've also reworked a ton of code to properly convert between bool and other types which should make it easier to tell when something's a true/false value or not.

I've switched the C++ language version from C++14 to C++17 which provides some useful additions like inline global variables.

I've enabled clang-tidy as part of the code analysis feature in Visual Studio, so you'll get more warnings now. A fair number of warnings are being shown because of the SDK's tendency to include headers only in source files so there are false positives, i'm going to try to fix those as much as i can.

Clang-tidy is configured through a configuration file in the root of the repository, i'm going to systematically enable more of those as i work through the remaining warnings.

I've also added a clang-format configuration file to the root of the repository which Visual Studio uses to format files. This ensures that formatting files is done consistently rather than depending on individual developers' text editor settings, but i'm still working out the kinks in the settings. The issue for this change provides more information on how it works, and how to mass-format all files: https://github.com/SamVanheer/halflife-updated/issues/84

I've been doing lots of code cleanup as well, removing duplicate forward declarations, using inline to avoid the need to declare globals as extern separately and otherwise improving the quality of the code.

The long-term goal is to have 0 warnings at the highest warning settings with as many clang-tidy warnings enabled as possible to enforce stricter and more correct code.

Note that due to recent changes existing save games will not work with newer updated builds. If you update your fork to include these changes, or if you use the next pre-built libraries you'll need to delete the save games to prevent problems from cropping up.