Forum posts

I've removed the source code and projects for DMC and Ricochet from the Half-Life Updated repository since neither of them were able to compile.

I've instead made separate repositories for updated projects that compile under VS2017 and VS2019:
https://github.com/Solokiller/dmc-updated
https://github.com/Solokiller/ricochet-updated

No further development or support will be provided.

See this page for more information: https://github.com/Solokiller/halflife-updated/wiki/About

Somebody on Knockout requested this:

New keyvalues:

fire_on_recharge(target_destination) : "Fire on recharge"
fire_on_empty(target_destination) : "Fire on empty"

spawnflags(flags) =
[
    1 : "Fire on spawn" : 0 //If set, fire_on_recharge or fire_on_empty will be triggered on map spawn depending on initial capacity
]

I made it so "fire_on_recharge" sends a USE_ON and "fire_on_empty" sends a USE_OFF so you can directly enable and disable the sprite just by triggering it. Otherwise you can use a relay or multi_manager to handle it. The spawnflag is used to have the appropriate target triggered when the map starts. I made it opt-in so you don't have entities getting triggered by default, and you may want to set things up manually. But for simple cases this automates the work.

Provide access to UI interfaces: IBaseUI, IGameUI, IGameUIFuncs, IGameConsole, IEngineVGui, etc. (an ability to manipulate the UI without accessing the engine / GameUI).

Those are engine interfaces. They're also part of the VGUI2 API.

Add missing interfaces inside server dll: NEW_DLL_FUNCTIONS / SV_SAVEGAMECOMMENT.

Yeah i'll get to those sooner or later.

Make a new generic mathlib that can suit all solution projects. You mentioned adding vgui2 support to client.dll, which is great. But putting it all in there is a pain in the ass. For example vgui2_controls.lib uses mathlib.h from Source SDK which also includes its own vector.h header file, for client and server we already have vector.h and util_vector.h and they will all hate each other. This could also be related to the tier0's platform.h, which will conflict with Platform.h from vanilla SDK. Creating common header files will not confuse people and take the project one step further.

I know there will be conflicts, i'll be merging that stuff in as needed when i get to it. I've already cleaned up most of the duplicate stuff in the Half-Life SDK so the Source SDK won't be too much trouble when i get to it. I've even gotten rid of the Windows.h dependency messing up every file, it's only used in a few files now.

Are you going to provide the ability to have these extra features toggle-able through preprocessor defines (like HLEnhanced's USE_OPFOR) or separate repositories (like Half-Life Updated) to get a "HL SDK but just cleaned up"? I know this would require a lot of work but that would be nice for total conversions which do not rely or very little on existing entities.

Most of the stuff unique to Op4 and Blue Shift is opt-in for level designers and useful regardless so i don't see much point in making them conditionally included. On the programming side of things you can usually exclude these by removing the files from the CMakeLists files. I'm hoping to decouple the code so there aren't any hardcoded references to other entities like Op4's code currently does (e.g. player TakeDamage references allied grunts). Only the weapons have always-precached assets so maybe a way to eliminate that overhead is better than conditional inclusion.

By "the UI should be replaced entirely with a VGUI2 version", I'm guessing you are talking about all the existing VGUI elements (class menu, team menu, scoreboard, observer's control panel...) or are you extending this to other UI stuff (HUD based menu, ammo, crosshair, health...)?

Well i've tossed the class and team menus out of the codebase since they're TFC-specific, but i want to implement VGUI2-based versions of all of them. Ideally even the Hud should be VGUI2, that means converting the hud sprites to TGA which i call an improvement (no blurring when upscaling i hope).

Having only one UI for everything makes it easier to make new content for things. No more "is it a hud sprite, a VGUI1 TGA or a VGUI2 TGA?".

I was wondering if it would be possible to simplify all of these tedious things by having some kind of CSkillCvar class that would create the appropriate number of cvar_t, register them automatically?

Yeah i was thinking about that too. I'm thinking i'll just chuck skill.cfg out the window and use an XML file:

<Skill>
    <SkillValue name="sk_9mmAR_bullet" level="2" value="4"/>
</Skill>

No more cvars, just strings:

pEntity->TraceAttack(pevAttacker, SkillValue("sk_9mmAR_bullet"), vecDir, &tr, DMG_BULLET);

And then all of the variables are handled like so (pseudocode):

struct SkillValues
{
    std::array<std::optional<float>, SkillLevelCount> Values;
};

class SkillData
{
public:
    void LoadFromFile(const char* fileName)
    {
        auto xml = LoadXML(fileName);

        for (auto skillValue : xml.SkillValues)
        {
            auto it = _skillValues.find(skillValue.Name);

            if (it == _skillValues.end())
            {
                it = _skillValues.emplace(skillValue.Name).first;
            }

            it->Values[skillValue.Level] = atof(skillValue.Value);
        }
    }

    float GetSkillValue(std::string_view name, float defaultValue = 0) const
    {
        if (auto it = _skillValues.find(name); it != _skillValues.end())
        {
            return it->second.Values[_level].value_or(defaultValue);
        }

        return defaultValue;
    }

private:
    std::unordered_map<std::string, SkillValues> _skillValues;
    SkillLevel _level;
};

(That's actually most of the code needed for this)

Just have a CBaseEntity member to forward to the global and you're done.

This scales with any number of skill levels (just update the SkillLevelCount constant), any new skill values are automagically loaded in. There is still the skill level clamping being done but it's trivial to update that. The biggest problem is the hardcoded "new game" dialog, but i'm sure there are ways around that too.

Enhanced Half-Life is a custom SDK/mod designed to replace my old Half-Life Enhanced SDK/mod.

It's not ready for a public release and the code is still in flux (400+ commits of refactoring and cleanup on top of Half-Life Updated) so i'm keeping that private for now.

The purpose of EHL is to do the following:

• Provide an updated SDK that uses modern source control principles, including a proper directory structure and use of CMake to generate the project files
• Third party dependencies are included instead of requiring manual setup by programmers (i'm looking at you, HLE's XercesC dependency)
• Ease of use: can make a new mod in ~5 minutes by cloning the repository, configuring the CMake project to install to a mod directory, generating the files and building the INSTALL target. Also installs liblist.gam and delta.lst (part of the source code repository) to ensure smooth setup
• Uses C++20, requires Visual Studio 2019 or newer. No Windows XP support.
• Cleaned up codebase to ensure source code is the highest quality:
  • Obsolete files and APIs have been removed
  • Documentation has been upgraded to use Doxygen style annotations
  • Include guards have been converted to #pragma once and headers now always use #pragma once unless they need to be included multiple times
  • #define has been mostly replaced with constexpr constants
  • Global variables removed whenever possible
  • Duplicate code merged
  • Cleaned up C-style code to use C++ style, use const correctness, Vector instead of float[3]
  • Fixed old hacks needed because of backwards compatibility
  • Routed all filesystem access through IFileSystem, all references to the game directory name removed
  • Safer strings functions used to avoid buffer overflows
  • string_view used to make for better code (works well with non-terminated strings and substrings)
  • Defined constants for many magic numbers
  • Converted many constants to enum class which helps to catch invalid conversions
  • Lots of other stuff that's still in progress
• The overall goal is to make the smallest SDK possible while maintaining full functionality, and even expanding on features by using newer language/library features, and using code generation to help eliminate redundancy in things like save game code
• All of HLEnhanced features should eventually be re-implemented in this project, along with merging the unique features from Opposing Force Updated (weapons, NPCs, game modes) and Blue Shift Updated (handful of entities). This should make EHL the one-stop-shop for making a mod that mimics any of these 3 games, aside from the issue of Op4 weapons having grunt hands only
• The UI should be replaced entirely with a VGUI2 version. The code for that exists in HLEnhanced and will be ported over later on when i tackle that task. Eliminating the use of VGUI1 entirely will help to simplify things.
• All files loaded by the game codebase are to be converted to XML for consistency and to eliminate issues with invalid parsing, error handling, memory leaks, etc. I considered a few different formats (INI, TOML, JSON, and others) but XML is the format that provides everything needed, though i haven't yet started upgrading the codebase to use it yet. I'm planning to use RapidXML for parsing so the heavyweight XercesC dependency won't be a problem this time
• Backwards compatibility with existing maps/models will likely be broken to improve entity keyvalue APIs and internal logic. For example some models made for barney and scientist NPCs will likely break due to changes in how submodels are changed (now done correctly). This will help to remove some of the cruft from the codebase that was needed due to Half-Life's maps having older keyvalues still in use. Breaking compatibility now in a big way can help avoid breaking changes later on

So far 53 files have been removed (not counting Ricochet and DMC files which have also been removed) and every file has been moved at least once. Engine headers have had internal engine stuff removed, lots of legacy stuff has been tossed out like the old security module stuff that the client used to have.
Compare this: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/engine/APIProxy.h
To this: https://i.imgur.com/FVeCt0n.png

(that header was split in 2 so the client API part is only included by files that need to know about it)

I'd like to show something i finished up today. I improved the health and hev chargers:Features:

• Fixed dmdelay keyvalue not working and renamed it to recharge_delay, and allowed the use of floating point values
• Allows instant recharging (warning: sound spam)
• Allows mappers to control initial capacity, total capacity, charge per use and sounds to play
• Allows chargers to start out of charge (initial capacity of 0)
• Allows infinite capacity (initial/total capacity of -1)
• Allows changing charge interval(time between charge uses, basically how quickly it gives you health or armor)
• Prevents chargers from jamming up if they are constantly +used while recharging
• Custom sounds
• Sound to play on recharge (similar to sound played when items respawn in multiplayer)
• Custom sound pitch setting (100 == default, 0 == minimum, 255 == maximum)

Keyvalues:

recharge_delay(string) : "Recharge delay"
charge_per_use(integer) : "Charge per use"
charge_interval(string) : "Interval between charges"
initial_capacity(integer) : "Initial charger capacity (-1 == unlimited)"
total_capacity(integer) : "Total charger capacity (-1 == unlimited)"
sound_pitch(integer) : "Sound pitch"
charge_on_sound(sound) : "Charge start sound"
charge_loop_sound(sound) : "Charge loop sound"
refuse_charge_sound(sound) : "Charge refuse sound"
recharge_sound(sound) : "Recharge sound"


Potential uses:
Making chargers that never run out and/or give tons of health/armor in an instant. Useful for co-op spawn areas, bunkers, etc.
Making chargers that start off empty but recharge after a long time to have some charge (or unlimited).
Making chargers that have little charge, but recharge quickly.
Chargers that look and sound alien.
Silent chargers (use common/null.wav).
Making chargers that give players their entire charge at once, or however much the player can take (health always expends charge_per_use, armor is conservative and only gives what the player can take). Like Condition Zero Deleted Scenes health stations.
Making chargers that charge really slowly, but charge a lot (forces player to expose themselves).

I'm still working on code cleanup so new features are few and far between. I decided to update the chargers because i was merging the code for both and i wound up adding a bunch of stuff.

Feedback and ideas are always welcome.

Sure if you use a library that does HTTP queries or whatever. But that's way out of scope for this project.

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

Notable changes:

• Fixed Gargantua stomp attack being framerate-dependent (halflife issue #2876)
• Fixed trigger_camera rotation speed being framerate-dependent (halflife issue #2924)
• Fixed flashlight icon not restoring properly on save game load (halflife issue #388)
• Fixed gauss gun beams going in the wrong direction when player is viewing themselves through a camera (halflife issue #1744)
• Fixed local player model using wrong pitch angles when seen through another entity (halflife issue #3075)
• Fixed buttons not sparking in multiplayer (halflife issue #1681)
• Fixed Half-Life HD and Opposing Force and Blue Shift LD and HD Revolver models not playing the reload sound (halflife issue 2351)
• Whole bunch of code cleanup, removal of unused code, refactoring of duplicate code and constants, properly defining magic numbers
• Fixed script in ba_yard4a that relied on a bug to break frozen Alien Slaves out of their frozen animation (halflife issue #3061)

Half-Life Asset Manager V1.1.0 has been released: https://github.com/Solokiller/HL_Tools/releases/tag/HLAM-V1.1.0
Notable changes:

• Implemented Bounding Box and Clipping Box modification support
• Implemented option to switch to Counter-Strike style sequence animation blending
• Studio model data is now converted to a format that can be easily edited (note: data not part of the studiomodel format and data in the format not used by vanilla Half-Life is not saved and will be lost on save)
• Sequence groups and textures are now automatically merged into the main model file on save
• Imported textures can now have dimensions that differ from the original texture. ST coordinates will be rescaled to match the new size, but this may result in slight offsets in the coordinates in some cases (note: undo/redo requires a fair amount of memory to support this (4 bytes per vertex in every mesh that uses the texture), can easily get out of control)
• Implemented support for addition and removal of sequence events (Events are now sorted when saved to ensure that the game's event code finds newly added events properly)

Half-Life Asset Manager V1.1.0 Beta 001 has been released: https://github.com/Solokiller/HL_Tools/releases/tag/HLAM-V1.1.0-beta001
Changes:

• Fixed attachments and hitboxes panels causing invalid access if there are no attachments/hitboxes and a bone is renamed
• Added dialog shown when a non-existent file is opened (e.g. deleted asset listed in recent files list)
• Enabled backface culling when drawing floor quad used to limit mirrored model draw region (prevents drawing the mirrored model underneath the floor)
• Saved & restored state of cull face when drawing mirrored floor to prevent model from drawing on top of player hitbox model
• Imported textures can now have dimensions that differ from the original texture. ST coordinates will be rescaled to match the new size, but this may result in slight offsets in the coordinates in some cases (note: undo/redo requires a fair amount of memory to support this (4 bytes per vertex in every mesh that uses the texture), can easily get out of control)
• Reworked Sequences panel UI to limit maximum width
• Implemented support for addition and removal of sequence events
  • Events are now sorted when saved to ensure that the game's event code finds newly added events properly
• Reworked Model Data panel UI to limit maximum width
• Added Git information to the About dialog

On the server side CBaseAnimating::GetAttachment should work. On the client side it's complicated because attachment positions are cached in cl_entity_t::attachments and get updated once per frame at a specific time. Depending on when you access that the values will either be outdated, set to the viewmodel origin or to their correct values.

I've got a new alpha build for HLAM: https://github.com/Solokiller/HL_Tools/releases/tag/HLAM-V1.1.0-alpha005
Changes:

• Studio model data is now converted to a format that can be easily edited (note: data not part of the studiomodel format and data in the format not used by vanilla Half-Life is not saved and will be lost on save)
• Sequence groups and textures are now automatically merged into the main model file on save
• Fixed StudioModelEntity::SetMouth not checking if a mouth controller actually exists
• Improved UI functionality for changing which bone and axis a bone controller is attached to. Changing the settings now automatically detaches any controllers attached to target bone and axis
• Added controls to the Bones panel to view and change the bone controllers attached to a bone

The purpose of this alpha is to verify that everything's still working properly. Once i'm sure i can start adding new features like add/remove events, import textures with different dimensions, etc.

Further discussion should be directed to https://twhl.info/thread/view/20055

Further discussion should be directed to https://twhl.info/thread/view/20055

I've created a wiki page explaining what the 3 Updated repositories are about and what can and cannot be done with them: https://github.com/Solokiller/halflife-updated/wiki/About

I'm still working on each repository, there are a lot of fixes in already and more on the way.

I'm also currently working on Half-Life Asset Manager 1.1.0 to add in the features needed to fix some of the asset issues in Opposing Force (missing 357 reload sound, etc).

You probably didn't add the skill cvars and code to sync the cvars to the variables in gSkillData.

What exactly are you doing? What's your map setup, when and how are you initiating a changelevel?

That message means you're trying to execute a changelevel while there is no map loaded. If you're getting it when you're playing a map and hitting a trigger_changelevel then something is seriously wrong.

Note that if you're connected to a server (one your client isn't hosting) you need to execute changelevel using rcon.

Half-Life: Blue Shift Updated Beta 1 is out: https://github.com/Solokiller/halflife-bs-updated/releases/tag/HLBSU-V1.0.0-beta001
Changes:

• Added tool to convert Blue Shift BSP files to standard Half-Life BSP format
• Fixed game potentially crashing when saving and/or loading the game in ba_outro

I'll get a ModDB page going once Blue Shift Updated is up and running. Which it already is, but i have to run through the campaign to verify everything's working first.

Half-Life: Opposing Force Updated Alpha 1 is out: https://github.com/Solokiller/halflife-op4-updated/releases/tag/HLOP4U-V1.0.0.alpha001
Notable changes:

• Includes all fixes made to Half-Life Updated
• Implemented Opposing Force weapons, monsters and entities
• Implemented Opposing Force CTF gamemode
• Fixed many bugs in weapons, monsters and CTF code

This is only an alpha version, bugs are expected. Report all bugs on the Github issue tracker (not Valve's official tracker!).

Half-Life Updated Beta 4 is out: https://github.com/Solokiller/halflife-updated/releases/tag/HLU-V1.0.0-beta004
Changes:

• Added the option to change the default field of view to the Multiplayer Advanced dialog
• Changed game directory name to halflife_updated
• Updated delta.lst to use latest one from vanilla Half-Life (includes spectator variables)
• Use correct number of bits for iuser2 to ensure spectating player with index 32 works correctly
• Fixed sprite attachment bug causing sprites to appear in seemingly random locations
• Fixed monsters being resurrected if triggered while dying
• Made default_fov cvar archived
• Fixed Tripmine & Python having wrong bodies sometimes when weapon prediction is enabled
• Reset flashlight HUD status on save game load
• Fixed ammo HUD drawing last weapon ammo if player has all weapons stripped
• Fixed train HUD not restoring

Half-Life Updated Beta 3 is out: https://github.com/Solokiller/halflife-updated/releases/tag/HLU-V1.0.0-beta003
Notable changes:

• Made scientists aware of carcasses, meat and garbage so they can comment on it (Thanks NongBenz)
• Fixed Human Grunt shotgun damage not using correct skill values
• Fixed bugs causing incorrect field of view when loading save games/changing levels while zoomed in
• Made cheat protected commands give, fov and impulse check the value of sv_cheats on demand instead of caching the value, enabling the use of these cheats without having to restart the map
• Added new engine functions added in the latest engine updates

You shouldn't modify the existing wad files, it can easily cause problems. Make new wad files.

It shows up just fine for me in both HLMV 2 and HLAM. It doesn't load in Jed's model viewer though.

Thanks, i've added the information to the report and i've fixed it in Half-Life Updated.

Yeah half-life updated is the main one. HLEnhanced is deprecated.

I don't think you need to make a new entity for that. A func_button combined with game_text can do that. Unless you need a lot of text.

Yeah that's kinda the purpose of this thing.

You're supposed to replace attachmentIndex with the number matching the attachment.

To attach it to an attachment you need to pass the attachment index along like this:

WRITE_SHORT(entindex() + (attachmentIndex << 12));

Where attachmentIndex is the attachment index + 1 (0 means use entity origin).

I've already gone through everything in that video. Everything that can be fixed has been fixed. The 357 and MP5 seem to be fine already, corpse sounds can't be fixed because the data needed doesn't exist in the client side.

I tried to fix the egon gun beam issue but it's a real pain in the ass. The attachment offset isn't calculated properly for view models and the workaround is pretty ugly. I'm not sure if it will even work.

Half-Life Updated Beta 2 is out: https://github.com/Solokiller/halflife-updated/releases/tag/V1.0.0-beta002
Changes:

• Re-implemented view roll
• Re-implemented view model tilt
• Fixed Egon gun beam colors being too bright

See the full changelog for more info

Are there any other bugs or features missing from WON that anybody wants dealt with? I've re-implemented view roll as well so once all other stuff is taken care of i can release a second beta.

For those that want to play Half-Life with these fixes, i've provided a beta version: https://github.com/Solokiller/halflife-updated/releases/tag/V1.0.0-beta001

I've implemented a couple more fixes. This should now make halflife-updated up-to-date with all fixes that were added to the game but not the SDK.

I've fixed a bunch more issues.

Half-Life Asset Manager V1.0.0 has been released: https://github.com/Solokiller/HL_Tools/releases/tag/HLAM-V1.0.0

Half-Life Asset Manager is a replacement for Half-Life Model Viewer that allows you to open Half-Life 1 studio models and view them. Many properties of models can be edited, including textures, bone controllers, events and much more.

The changelog is far too big to list here, so just check the wiki page linked in the releases page.

Half-Life Model Viewer 2.10 has also been released: https://github.com/Solokiller/HL_Tools/releases/tag/HLMV-V2.10
Changes:

• Fix bodyparts submodel defaulting to first submodel when changing selected body part instead of using the current submodel for that part
• Add check to prevent models with invalid length value from crashing the program
• Use higher resolution program icon (128x128 instead of 32x32)

This is likely the last release for Half-Life Model Viewer. It has been superseded by Half-Life Asset Manager and is only supported for those who cannot use HLAM.

You can open PSD files in GIMP.

I'd suggest reading the VDC article on this: https://developer.valvesoftware.com/wiki/Response_System

It's incomplete but it should get you started at least.

Based on your description i think you're missing the scripts used to actually implement the responses. I've never used it myself so i don't know how it works exactly.

If you want Blue Shift features you will have to do that. I don't know if those dlls work when used in a mod, otherwise you'll need to use a custom built version of Blue Shift. I don't know if there is one available at the moment.

There are probably ways to fake Blue Shift features in vanilla HL but that's a bit of work to set up.

The fgd file only lists the entities for use in map editors; the actual logic behind them resides in a game's server dll. Using the blue shift fgd by itself won't add the entities.

There are multiple versions of fgd files out there. Some of them include editor properties that allow the rendering of models and sprites, others do not.

Blue Shift implements armor by giving the player the HEV suit, which enables the HUD and sets a flag used to indicate that the player has it.

The sounds are silenced by setting the sentences to an empty sound file in sound/sentences.txt:

HEV_AAx common/null
HEV_A0 common/null

It can be changed in the source code by removing the lines that play it: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/dlls/items.cpp#L191-L194

@Cabo Fiambre
You're welcome, good to hear it's working.

@Unq
Guess you prefer chainsaws over crowbars eh

I've added two new fixes: the raw mouse input fix from Half-Nuked and the shotgun pump sound fix. Thanks jay! for letting me know about these.

It looks like that's the same bug. The fix i posted earlier doesn't seem to work for the glock so i'll have to look into that.

You have permission to use my work for your project.

EDIT: i've fixed the prediction sync issues entirely. It's consistent now, at least as far as ballistic weapons go.

I've added the crowbar and the weapon timing fixes.

I think i found the cause of it, i've provided an explanation and the fix here: https://github.com/ValveSoftware/halflife/issues/1621#issuecomment-760270846

I've fixed the crowbar issue using the fix i suggested on Github a while back, it'll be pushed soon.

I'm looking into the double shot issue. So far i've determined that the issue is caused by the client prediction code firing off a shot locally when the server isn't, which results in a simulated shot that never happens on the server side.

See this console output. There are 3 log calls, 2 of them are the client and server versions of the mp5's attack code, right below the event playback call, the other is in the event callback:

cl:  client fired mp5 1 times
server fired mp5 1 times
client event fired mp5 1 times

cl:  client fired mp5 2 times
server fired mp5 2 times
client event fired mp5 2 times

cl:  client fired mp5 3 times
client event fired mp5 3 times

cl:  client fired mp5 4 times
server fired mp5 3 times
client event fired mp5 4 times

The third shot only happens on the client due to prediction code running it, but never on the server side. I ended up with 4 shots too many after a full 50 rounds fired.

I think this is just a timing issue in the prediction code, so i'll see if i can isolate the cause, and perhaps find a way to make it run on the same timing logic as the server.

This is really interesting stuff! Does this fix the fast crowbar gib bug and the double shot bug from the glock's secondary fire?

I can fix the crowbar bug, but what's the double shot bug exactly? Just so i know what to look for.

Half-Life Updated is an updated version of the Half-Life SDK that can be used with newer versions of Visual Studio and that includes both bug fixes added to the game but not the official SDK, and bug fixes not yet added to the game.

You can find the changelog here.

You can find the Updated source code here: https://github.com/Solokiller/halflife-updated
There is also a version that uses CMake, which additionally configures the project to deploy dlls to the mod directory and sets up debugging parameters: https://github.com/Solokiller/halflife-updated-cmake

The old thread about this lists other changes: https://twhl.info/thread/view/19592

Well, that's not exactly how FMOD is supposed to be used but if it works it works. Do you still need me to upgrade it to FMOD Studio?

I know the guy.. He helped me with my own code till we both discovered Solokillers work. Then he ceased development. The public code is even less sophisticated than the private one I own and even that it a total dev build. For instance many NPC actions spawn a spark on top their heads for verification that things worked as intended coding wise. Unfortunately I'm to stupid and limited in time to figure things out myself.

If you got the coding know how let me know and I'll send you that internal code. He fixed dozens of spirit related bugs and cleaned up the whole code of it big time. At least so he claimed but I believe that he did.

HLEnhanced was never really planned that well which is why i ceased development. I am planning to make a successor that does stuff properly (and with a unique name so it doesn't get confused for another mod).

That spark issue is actually vanilla HL behavior that happens in debug builds: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/dlls/schedule.cpp#L184-L194

If you're looking for any functionality in particular you can always make a list and i'll see what i can do. The planned mod might be enough for your needs, but Asset Manager V1 has to be released first before i can work on that. That project is going into beta soon, once i get a few remaining features implemented and the installer setup done.

Another guess is CMake and dependencies. You need to build the XercesC library, and use CMake to generate project files for Visual Studio, if I recall correctly. That probably pushes away many people, especially beginners. But then again, it's 2021, programmers are supposed to be familiar with at least one or two build systems. :/

Yeah Xerces was a bad choice. There are XML parsing libraries that are lightweight, header only and don't have the separate dependency requirement. The only downside is they don't support the full XML spec, but i doubt anybody would ever use namespaces, entities and doctypes.

I can update HLEnhanced to replace the XML library, but it's still advised to not use it. I already have a library in mind for the replacement project so i can just update HLE first.

As far the FMOD Ex issues go, the library can no longer be downloaded from the official website so getting a compatible version is going to be difficult. For some reason the library was never included in Spirit installations so i don't know if you can find a compatible version anywhere. The web archive lists old download links but none of them work and the archived copy doesn't have the files either.

You might be able to get a copy if you can find a mod that uses that particular version of fmod, but it seems that the library was only renamed to fmodex.dll relatively shortly before being discontinued so that might not be possible. I do have an old version of it in an old HLMV installation, version 4.44.61 but i don't know if it's compatible or if it's even a release version.

You may be better off just upgrading the codebase to FMOD Studio instead. If you encounter issues with GetProcAddress calls you may be better off just using the import library and using delay loading to load it from cl_dlls.

The process for delay loading is described here: https://docs.microsoft.com/en-us/cpp/build/reference/linker-support-for-delay-loaded-dlls?view=msvc-160

But it's a bit verbose. The gist of it is that you need to handle loading yourself and can load from a different location on disk:
https://github.com/Solokiller/HLEnhanced/blob/master/game/shared/DelayLoad.h
https://github.com/Solokiller/HLEnhanced/blob/master/game/shared/DelayLoad.cpp

You also need to specify the library to be delay loaded in the linker settings for client.dll. In HLE this is done in the CMakeLists file, but for regular Visual Studio projects it's done through VS's properties dialog for client.dll.

You also need to link with the delayimp.lib library for this to work.

The library will be loaded when you first invoke any function imported from the library, so you need to make sure the client dll has at the very least received the engine pointers before it will work. Otherwise it will crash when trying to get the mod name from the engine.

If this is all too confusing i can take a look at the project and upgrade it to FMOD Studio along with delay loading support.

A targetname is used to reference entities in a single map, usually to trigger them or to do things like set up scripted events.
A globalname is used to synchronize entities between maps. The global state is copied and stored in save games, usually to do things like opening doors and triggering scripted events when a player goes to another map.

You should never have to use a globalname on a changelevel.