Half-Life Updated (custom SDK) Created 1 year ago2021-01-13 21:05:33 UTC by Solokiller Solokiller

Created 1 year ago2021-01-13 21:05:33 UTC by Solokiller Solokiller

Posted 3 months ago2021-10-21 12:49:45 UTC Post #345987
Yeah but they haven't been active for a while.
Posted 2 months ago2021-11-14 18:52:17 UTC Post #346059
I've been working to add a few new systems to the Unified SDK to make modding easier to do through configuration files instead of relying on hard-coded settings so much.

Here are most of them in action:
User posted image
These are all of the systems i've added, though some are not entirely finished:

String pool

This replaces the engine's ALLOC_STRING engine function, and changes behavior to allocate memory once per string, so calling it multiple times with the same string doesn't allocate more memory. Very efficient, this change also frees up a little memory in the engine's available memory pool.

It also no longer performs escape character parsing which required game_text to be changed to perform this parsing by itself. This behavior was inconsistent and could cause difficult to debug problems otherwise.

Better support for writing code that works on both client and server

The server's engine functions interface now has better support on the client which makes it easier to write code that works on both sides.

This also includes helper functions like Con_Printf which will unconditionally print to the console, and supports all of printf's format options (the engine's version is limited to C89 printf options).

Access to the engine's filesystem

The engine has a filesystem interface used to load files from game and mod directories. I've provided access to it, as well as a couple helper functions to easily load files without the risk of leaking memory.

You can use this to load files from the mod directory only if needed, for example server configuration files should never load from other directories to prevent custom and downloaded content from overriding it. Conversely you can also load files from all of those directories if needed, such as map configuration files.

Support for creating console variables and commands using unified syntax on client and server

The server requires you to create cvars whereas the client has the engine create them for you; i've created an abstraction that does this for you. This abstraction also prepends an sv_ or cl_ prefix automatically so you can have the same variables and commands on both sides.

You can set variables created this way using the new command line syntax :command_name command_value or :(sv_|cl_)command_name command_value.
If specified without the prefix it will apply to both the server and client versions. This also works properly for server variables which the engine will not initialize from the command line if you launch a listen server manually through the main menu.

Command functions can also be object methods by using a lambda to wrap it:
g_ConCommands.CreateCommand("my_command", [this](const auto& args) { MyCommandHandler(args); });

void MyClass::MyCommandHandler(const CCommandArgs& args)
    Con_Printf("%d arguments:\n", args.Count());

    for (int i = 0; i < args.Count(); ++i)
        Con_Printf("d\n", args.Argument(i)));
CCommandArgs is a thin wrapper around engine functions that makes it easier to work with commands by indicating which functions are available in all libraries.

Improved logging

I've added the spdlog library and set up the functionality to create loggers for subsystems. This allows you to log output with more control over how much is visible and what kind of output it is. As you can see in the screenshot above you can easily distinguish which system is logging something, and what kind of information it is.

This system loads settings from a configuration file. You can specify default logger settings so you can enable more debug output for all loggers, or even disable them all. You can also configure each logger individually.

There are console commands to list all of the loggers that exist, as well as to manually change the log level at runtime.

Angelscript-based scripting functionality

Bare bones Angelscript support has been added. The creation of script engines, contexts and modules is provided with error reporting for failure, as well as engine message logging, exception logging and proper handling for C++ exceptions including problematic behavior regarding longjmp (essentially C's version of exceptions), which could put the game engine or the script engine in an invalid state otherwise (note that longjmp does not seem to be caught by catch-all statements in VS2019, this used to happen in VS2012 but fail-safe logic should prevent the problem from occurring).

There is currently no scripting support for plugins and map scripts, but it's something i'd like to add if there's interest.

JSON-based configuration files

I've added support for loading JSON configuration files and parsing them. Error handling is done for you so if there's invalid JSON it'll be reported automatically.

I've also added JSON Schema-based extended error reporting for debugging purposes. This provides additional information when needed to indicate which part of the given JSON is invalid. It's only enabled with a debug cvar since it adds a lot of overhead.

Here's an example of the errors it will log (given an array instead of an object):
[startup] [error] Error validating JSON "/Defaults" with value "[{"LogLevel":"trace"}]": unexpected instance type
The JSON schemas can also be written to a file and used as input to tools that can generate JSON editors. This makes it easier to edit JSON and shows what kind of options you have.

I've also allowed the use of comments in JSON. This is a non-standard extension to the format, but is supported in most JSON libraries and the benefits are too good to ignore.

Game configuration files

Building on JSON support, there is a system for loading game configuration files. These are files that contain configuration data that needs to be applied every time a new map is loaded. This replaces server.cfg, listenserver.cfg and map change cfg files, which are mostly handled by the engine.

Additionally maps can have a config file as well. A file called cfg/maps/<mapname>.json will be loaded if the map with that name is started.

Here's an example of such a file used to configure the server for a new map:
    "Includes": [
    "Sections": [
            "Name": "Echo",
            "Message": "Hello World!"
            //Commands to configure multiplayer server
            "Name": "Commands",
            "Condition": "Multiplayer",
            "Commands": [
                "echo Hello World from command!",
                // disable autoaim
                "sv_aim 0",
                // player bounding boxes (collisions, not clipping)
                "sv_clienttrace 3.5",
                // disable clients' ability to pause the server
                "pausable 0",
                // maximum client movement speed
                "sv_maxspeed 270",
                // load ban files"
                "exec listip.cfg",
                "exec banned.cfg"
The Includes value is a list of files to include before the current one, and makes sharing settings between servers and maps very easy. You could for instance make a map series where each map includes a file that contains the shared configuration before changing some for specific maps.

Here are the contents of the included file:
    "Sections": [
            "Name": "Echo",
            "Message": "Hello World from shared.json!"
The Sections value is a list of section objects that apply to the game. Each section can have a condition associated with it evaluated at load time to determine whether the section should be used or not.

This condition is evaluated using Angelscript by wrapping it in a function:
bool Evaluate()
    return condition;
To prevent abuse this evaluation will time out after 1 second, so the server won't lock up due to some clever infinite loop trick.

There are currently only two conditions to check: Singleplayer and Multiplayer. I plan to expand on this with gamemode detection (deathmatch, coop, teamplay, etc) as well as checking the map name and the value of cvars.

The Echo section simply prints the message to the console, useful for debugging to see if your file is getting loaded properly.

The Commands section provides the same functionality as the cfg files this system replaces. It lets you provide a list of console commands to execute.
For security purposes map config files are checked against a whitelist to limit the commands that can be executed. This prevents maps from doing things like changing the RCON password or the listen server host's name.

This whitelist is loaded from another JSON file:
So server operators can manage this whitelist themselves if needed.

Though the configuration files for servers, maps and map changes are currently identical they are actually defined separately. Some will get sections exclusive to one or two of them in which case trying to use them in a format that doesn't have them will cause an error to be logged the console, but otherwise it will continue loading the file.
With this stuff implemented i can get to work implementing skill.json functionality and its map-specific equivalent. There are also a few changes needed to support things like Xen aliens fighting with Race X aliens (they're treated as allies by the game's code). Black ops have the same problem when it comes to fighting human military types (also allies).

I've also been updating the other SDKs to include bug fixes and improvements. There are some mistakes i made in Opposing Force that should be merged into any other projects that use that code.

There isn't much more work to do before a first release can happen. Since this is a lot of work i'll be doing an alpha release first to get some feedback, then at least one beta before a full release can be done.

That's all for now, feedback and suggestions are always welcome.
Posted 2 months ago2021-11-28 20:14:56 UTC Post #346079

In regards to scripting, and assuming scripting allows for creating custom monsters and entities, I believe this could definitely be a plus.

For example, Garry's mod provides a Lua API which allows clients to override the game's default behavior. This mainly has the following advantages for clients:
  • Hide internal game code complexity
  • Reuse custom entities in multiple projects (No need to recompile)
  • Easier way to manage modularity (Depends on script language used)
  • Abstraction over game update (No need to recompile or merge changes in code base)
  • Write minimal code
In addition, this would probably encourage more people to contribute to a common SDK rather than maintaining a fork separately.

On developer side, the following must be taken in consideration:
  • Maintenance of script library (Additional work)
  • Ensure scripted language updates do not break client scripts (Unit tests)
  • Require to manage a wiki for clients and update documentation
Posted 2 months ago2021-11-29 12:45:42 UTC Post #346080
In regards to scripting, and assuming scripting allows for creating custom monsters and entities, I believe this could definitely be a plus.
Yeah that's certainly a possibility. I implemented custom entity/NPC/weapon support in Sven Co-op using Angelscript before.

I worked out some of the details for a scripting system last week. Since this is derived from Sven Co-op's scripting system (aka "previous system") i'll be comparing it to that. Note that this is all conceptual, i haven't written any code for this yet so it could change if it's not feasible.

Plugins and map scripts are virtually identical, unlike the previous system (somebody should update that page though, custom entities have been allowed in plugins for a long time now). The only difference is how long scripts stay loaded for.
Plugins normally get loaded on server startup and stay loaded until the server shuts down, unless the scripts are explicitly unloaded or reloaded.

Map scripts are loaded when a map references them, and are unloaded if the next map does not reference it. Some option to keep a script loaded regardless by extending its lifetime is required so you can have for example a script that runs in the background of every map, like a stat tracker or something.

The simplest way to do this is to use the configuration file system to list a script for use in multiple maps, or every map by listing it in the server config file. Then it'd just be a plugin loaded as a map script, with the option to conditionally include it using the Condition key.

One of the problems that popped up was that multiple scripts would be written to be the main script, with initialization code in the automatically called functions MapInit, MapActivate, MapStart and PluginInit. So if you then included multiple scripts those functions would conflict with each-other.

To solve this problem each script listed in the config file, and each script referenced by trigger_script would be loaded into its own Angelscript module. A module is basically a C++ library in terms of scope, so these API functions wouldn't conflict unless you mark them as shared.

In the previous system shared entities weren't allowed because it could interfere with the reloading of plugins. If you have a script that defines something as shared, include it in 2 or more plugins, change the shared code and then reload one of the plugins it'll fail to load because the shared code is now different.

I'd flip this behavior on its head now. Allow shared stuff, even between plugins and map scripts, but disallow making API functions shared to prevent one script from monopolizing them.

This approach makes it much easier to design things like AFB, which is a plugin manager written in Angelscript. To work around the lack of shared entities you have to add your script to a function to initialize the system: https://github.com/Zode/AFBase/blob/acd7ba7e1248538d9b660638915dc91a7da59deb/scripts/plugins/AFBaseExpansions.as

With shared entities each plugin can be its own module, referencing a shared Plugin class. Plugins then need only register their plugin class, which the plugin manager can query from the shared code to manage each plugin instance.

Such registration can be automated to this point:
AFBRegister register(@MyAFBPluginClass());
The AFBRegister class registers the plugin in its constructor and unregisters it in its destructor, thus tying the plugin lifetime to that of its containing module. You won't even need to write a PluginInit function anymore. AFBRegister would be a shared class.

The API functions should also be improved, there are too many of them. Each module should get exactly 2 of them: an init and shutdown function. Everything else should be event-driven:
void ScriptInit()
    //Called when the script is first loaded.
    //Subscribe to the MapInit event. All events define a unique event type associated with it, even if they don't have any data or methods.

void ScriptShutdown()
    //Called when the script is about to be discarded/unloaded.
    //Don't need to manually free event handlers because they'll be removed automatically, but it can be done manually like this.

//All event handlers follow the same structure: void return type, one parameter taking the event by handle.
void MapInit(MapInitEvent@ event)
    //Called when the map is starting for any reason, map scripts could be in the process of being loaded right now, so inter-module communication isn't advised at this time.

    //Equivalent to Source's logic_auto outputs: https://developer.valvesoftware.com/wiki/Logic_auto
    switch (event.InitType)
    case MapInitType::NewGame:
        //The map is being loaded for the first time, like when the map or changelevel console commands are used.
    case MapInitType::LoadGame:
        //The map is being loaded from a save game, which means the player is loading a save game or a map is being returned to through a trigger_changelevel.
    case MapInitType::NewRound:
        //For game modes that use round-based gameplay, a new round is starting.

    //More types if needed.
The event system replaces hooks and allows for compile-time compatibility checking of events. The previous system had to rely on variable parameters because hooks could have any number of parameters, so you could technically pass in an integer into a function that's expecting a function handle. You'd get an error at runtime, so it's not as obvious that you've made a mistake.

On the C++ side you'd publish events like this:
This would then internally create the event object:
//Curiously Recurring Template Pattern-based base class
template<typename TEvent>
class Event
    //Reference counting code omitted for brevity.

    template<typename... Args>
    void Publish(Args&&... args)
        //Event is created with reference count 1, ownership transferred to smart pointer.
        //Event constructor is invoked with template parameters.
        as::SmartPtr event{new TEvent{std::forward<Args>(args)...}};

        //Event handlers are tracked by the Events global and will invoke all handlers.

        //Smart pointer releases event, usually destroys it if no script holds on to it.

class EventSystem
    template<typename TEvent>
    void PublishEvent(TEvent* event)
        //Probably a std::unordered_map<std::reference_wrapper<type_info>, as::SmartPtr<asITypeInfo>>.
        asITypeInfo* type = GetScriptTypeFromCppType<TEvent>();

        if (!type)

        auto context = ...;

        //Finds or creates the list of handlers for this event type.
        const std::vector<as::SmartPtr<asIScriptFunction>>& handlers = GetEventHandlersForType(type);

        for (const auto& function : handlers)
            //Context setup and error handling omitted for brevity.
            context->SetArgObject(0, event);
Custom entities require a fair bit of work to support. You need to expose the class you want custom entities to inherit from, expose the API to call base class implementations (e.g. calling CBaseMonster::Killed from your NPC's Killed method) and you need to write a wrapper that forwards calls to the script for any virtual functions it has.

The C++ side also needs to support custom entity creation by implementing the custom function. I haven't quite figured out how to save and load them since the save game system doesn't use custom. I could hack it by saving custom entities to have the custom class, and then saving the actual classname separately. That solves the problem, but there is still the issue of scripts changing the custom entity implementation.

One map could have a script A.as that defines a custom entity foo, and the next map could have a script B.as that also defines a custom entity foo. When such an entity is transitioned between maps its composition can change dramatically, including changing base classes.

Custom weapons could be restored as an NPC for example, and the pointer to the weapon would now be invalid since CBasePlayerWeapon* isn't compatible with CBaseMonster*. There are no safeguards in the save game system against this and it would take some doing to support it, so the initial version of the scripting system wouldn't be able to support it.

Custom entity support thus needs to be disabled in singleplayer with an error message in the console if you try to register them anyway (since saving the game and loading it would make it disappear).

I'll work this out more once i've completed work on the first version of the unified SDK. There's still a lot of work left to be done in all of the existing repositories to clean things up.
Posted 1 month ago2021-11-29 12:58:16 UTC Post #346081
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.
Posted 1 month ago2021-12-01 16:53:01 UTC Post #346091
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:

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.
Posted 1 month ago2021-12-01 18:52:39 UTC Post #346092

Personally, I've already removed VS17 projects from my Spirinity fork. I've got about 4 friends using my repo and they are all working on VS19, and I'm working on VS22 preview.

I'm not that sure about the removal/replacement of v141_xp tools but VS17 project files are probably lying there, unused.

About the CMake, using it could maybe add an additional barrier, but it could also encourage people to learn using CMake, so they could use this "skill" in other projects, too. Apart from that; it would also help to maintain cross-platforming and save from adding new files and build settings into particular projects one by one. So I'd personally side with CMake.

Lastly, making features optional generally give good results bacause some people want lightweight mod without the new asthethisc and concepts. So I'd say It'd be neat to give it a try.
FranticDreamer FranticDreamerR.I.P. Benny Harvey. Miss you big man. Gone but not forgotten.
Posted 1 month ago2021-12-01 19:29:43 UTC Post #346093
I stopped using the VS2017 project files last year. I haven't seen anybody use them lately.
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.
Not a problem for me, though I imagine it'd be a bit confusing/frustrating to beginners.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2021-12-01 21:22:30 UTC Post #346094
For me, personally, the most important thing is to have something that's as close to the original, unmodified Half-Life SDK code as possible, while still being usable with VS 2019 or later. Whether that be through a VS 2019 project file or CMake doesn't really matter to me.
Dr. Orange Dr. OrangeSource good.
Posted 1 month ago2021-12-02 06:32:45 UTC Post #346097
I also only use vs2019+
The vs2017 can be removed.

Thanks Solo, you are doing a great job.
Posted 1 month ago2021-12-04 20:33:23 UTC Post #346105
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.
Posted 1 month ago2021-12-25 19:26:20 UTC Post #346160

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.
Posted 2 weeks ago2022-01-11 19:17:53 UTC Post #346194

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.
Posted 1 week ago2022-01-21 18:46:35 UTC Post #346215

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.
You must be logged in to post a response.