Forum posts

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.

Did you assign a globalname to the changelevels? That might be causing the settings to carry over.

The original function is in the engine so you won't find that.

The engine hardcodes the names by default, but you can override it using an undocumented API:

struct TITLECOMMENT
{
    const char* pBSPName;
    const char* pTitleName;
};

TITLECOMMENT gTitleComments[] =
{
    {"c1a1", "#C1A1TITLE"},
    {"ba_yard", "#BA_YARDTITLE"}
    //More title entries here
};

extern "C" void DLLEXPORT SV_SaveGameComment(char* pszBuffer, int iSizeBuffer);

extern "C" void SV_SaveGameComment(char* pszBuffer, int iSizeBuffer)
{
    const char* mapName = STRING(gpGlobals->mapname);

    const char* titleName = nullptr;

    for (int i = 0; i < ARRAYSIZE(gTitleComments); ++i)
    {
        const size_t length = strlen(gTitleComments[i].pBSPName);

        if (!strnicmp(mapName, gTitleComments[i].pBSPName, length))
        {
            titleName = gTitleComments[i].pTitleName;

            if (titleName)
            {
                break;
            }
        }
    }

    if (!titleName)
    {
        titleName = mapName;

        if (!titleName || !(*titleName))
        {
            edict_t* world = ENT(0);

            //Use the full map name (e.g. "maps/c1a0.bsp").
            //The engine uses the value it sends to clients (aka a variable used by client code) but this should always be valid here
            //The engine sets the model field on worldspawn when it loads the map
            titleName = STRING(world->v.model);

            if (!strlen(titleName))
            {
                //The engine assigns mapName here again, but that's known to be either null or empty so to be sure this always assigns empty,
                //since strncpy has undefined behavior for null src pointers
                titleName = "";
            }
        }
    }

    strncpy(pszBuffer, titleName, iSizeBuffer - 1);
    pszBuffer[iSizeBuffer - 1] = '\0';
}

This is basically the same as the engine implementation. The function SV_SaveGameComment is exported and looked for by the engine. It passes in a buffer that is to be filled with a localizable string that will be looked up in the game's resource/<game>_<language>.txt file.

For Blue Shift they changed the map naming pattern so multiple maps can use the same entry. ba_yard for example is used for ba_yard1, ba_yard2, ba_yard3, ba_yard3a, ba_yard3b, ba_yard4, ba_yard4a, ba_yard5 and , ba_yard5a. You can use this pattern but it's unlikely to be very helpful for most custom maps.

For Half-Life's English localization that's resource/valve_english.txt.

The maximum number of bytes that such a comment string can have is 79, plus a null terminator at the end.

If you have the game's source code you can add it there, best put next to the other exported functions in cbase.h and cbase.cpp. It can be made more flexible so as to allow any map to specify a non-localized name, or to map the name to some localizable string.

Otherwise you could modify Metamod-P and add the exported function to that instead. As long as the server dll doesn't implement the function the one exported by Metamod-P will be used.

I did implement this entity a while back: https://github.com/Solokiller/czeror-sdk

You can see which changes need to be made by checking the last few commits: https://github.com/Solokiller/czeror-sdk/commits/master

Not all of the code i added is used since i only ported everything needed for the entity to work. Round restarts for instance aren't implemented.

The engine supports it, but it requires an entity to actually use it. It doesn't exist in the base version of Half-Life, so you'll need to add it yourself through code.

Player models have their origin in the middle instead of at their feet. If the entity is falling to the ground you can use an invisible brush or maybe a clip brush to prop it up.

How are you loading the maps?

So once again, opengl32.dll is part of the OS API for OpenGL. If you want improved performance you'll have to write custom graphics code using shaders. Just like every other program you do that by accessing the OpenGL API through opengl32.dll, without replacing it.

Using custom opengl32.dll files will not improve performance. Using custom graphics code will improve performance if written properly.

Don't use custom opengl32.dll files. All opengl32.dll does is provide an API to access OpenGL with. It supports the full OpenGL API up to whatever your OS, GPU and driver supports.

The actual driver is loaded by opengl32.dll and this process works with whatever your OS supports. You do not need a custom opengl32.dll. The only use of such files is to work around engine-level graphics code not doing what a mod wants it to do and to cheat.

As a modder you are unlikely to need it, and if you really need to override engine level graphics code there are better and safer ways (e.g. replacing the engine window with a custom one, redirecting engine functions so you handle it in client.dll, only when VAC is disabled of course just like when you use custom opengl32.dll files).

The vanilla engine deletes custom opengl32.dll files found in the game directory as part of basic anti-cheat (probably superseded by VAC but it was never changed).

See this for more information: https://www.khronos.org/opengl/wiki/FAQ#How_Does_It_Work_On_Windows.3F

@zooogor you clearly don't know how this works so please refrain from misleading others.

That's not the kind of random trigger he's looking for.

I wrote an implementation based on Source's logic_case:

const int MaxRandomTargets = 16;

const char TargetKeyValuePrefix[] = "target";

class CTriggerRandom : public CBaseDelay
{
public:
    void KeyValue(KeyValueData* pkvd);

    void Spawn();

    void EXPORT RandomUse(CBaseEntity* pActivator, CBaseEntity* pCaller, USE_TYPE useType, float value);

    int ObjectCaps() { return CBaseDelay::ObjectCaps() & ~FCAP_ACROSS_TRANSITION; }

    virtual int        Save(CSave& save);
    virtual int        Restore(CRestore& restore);

    static    TYPEDESCRIPTION m_SaveData[];

    string_t m_iszTargets[MaxRandomTargets];

private:
    int BuildMap(std::array<std::uint8_t, MaxRandomTargets>& map);
};

TYPEDESCRIPTION    CTriggerRandom::m_SaveData[] =
{
    DEFINE_ARRAY(CTriggerRandom, m_iszTargets, FIELD_STRING, MaxRandomTargets),
};

IMPLEMENT_SAVERESTORE(CTriggerRandom, CBaseDelay);

LINK_ENTITY_TO_CLASS(trigger_random, CTriggerRandom);

void CTriggerRandom::KeyValue(KeyValueData* pkvd)
{
    const size_t prefixLength = ARRAYSIZE(TargetKeyValuePrefix) - 1;

    if (!strncmp(TargetKeyValuePrefix, pkvd->szKeyName, prefixLength))
    {
        const char* indexString = pkvd->szKeyName + prefixLength;

        char* end;

        int index = strtol(indexString, &end, 10);

        //Must be a number and end after the number, e.g. "target1"
        //index is 1 based [1, MaxRandomTargets]
        if (end != indexString && *end == '\0')
        {
            --index;

            if (index >= 0 && index < MaxRandomTargets)
            {
                if (FStringNull(m_iszTargets[index]))
                {
                    m_iszTargets[index] = ALLOC_STRING(pkvd->szValue);
                }
                else
                {
                    ALERT(at_error, "CTriggerRandom::KeyValue: target \"%s\" already set to \"%s\"", pkvd->szKeyName, STRING(m_iszTargets[index]));
                }
            }
            else
            {
                ALERT(at_error, "CTriggerRandom::KeyValue: invalid target index \"%s\", must be in range [1, %d]", pkvd->szKeyName, MaxRandomTargets);
            }
        }
        else
        {
            ALERT(at_error, "CTriggerRandom::KeyValue: invalid target format \"%s\"", pkvd->szKeyName);
        }
    }
    else
    {
        CBaseDelay::KeyValue(pkvd);
    }
}

void CTriggerRandom::Spawn()
{
    SetUse(&CTriggerRandom::RandomUse);
}

void CTriggerRandom::RandomUse(CBaseEntity* pActivator, CBaseEntity* pCaller, USE_TYPE useType, float value)
{
    std::array<std::uint8_t, MaxRandomTargets> map;

    const int count = BuildMap(map);

    if (count > 0)
    {
        const int index = RANDOM_LONG(0, count - 1);

        const char* target = STRING(m_iszTargets[index]);

        FireTargets(target, pActivator, pCaller, useType, 0);
    }
}

int CTriggerRandom::BuildMap(std::array<std::uint8_t, MaxRandomTargets>& map)
{
    int targetCount = 0;

    for (int i = 0; i < MaxRandomTargets; ++i)
    {
        if (!FStringNull(m_iszTargets[i]))
        {
            ++targetCount;
            map[i] = i;
        }
    }

    return targetCount;
}

Add it to the bottom of triggers.cpp.

Also add this as the first include files:

#include <array>
#include <cstdint>

FGD entry:

@PointClass base(Targetname) = trigger_random : "Random Trigger"
[
    target1(target_destination) : "Target 1"
    target2(target_destination) : "Target 2"
    target3(target_destination) : "Target 3"
    target4(target_destination) : "Target 4"
    target5(target_destination) : "Target 5"
    target6(target_destination) : "Target 6"
    target7(target_destination) : "Target 7"
    target8(target_destination) : "Target 8"
    target9(target_destination) : "Target 9"
    target10(target_destination) : "Target 10"
    target11(target_destination) : "Target 11"
    target12(target_destination) : "Target 12"
    target13(target_destination) : "Target 13"
    target14(target_destination) : "Target 14"
    target15(target_destination) : "Target 15"
    target16(target_destination) : "Target 16"
]

I haven't tested it but it should work fine. It logs invalid keyvalue inputs and will treat the "target" keyvalue as an invalid input since it isn't meant to be used with this entity.

It works just like logic_case does when using the PickRandom input. All target keyvalues that have been set will be considered and one is randomly chosen. You can turn it into a random do/do nothing setup by setting targets that don't exist, e.g. "dummytarget".

What is the error exactly, and why are you trying to create pak files? They have nothing to offer that you can't accomplish by just putting files in the game or mod directory.

I've made the old SharpLife repositories private to avoid people trying to run it and running into various issues. I have a plan to make it easier to use but that will have to wait until HLMV is done.

offsets is a byte offset for each mipmap level: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/QW/client/model.c#L372-L381

paloffset is an index into a global array of palettes. The Software version uses it to render the images, the OpenGL version passes the palette data to glColorTableEXT.

The layout of texture_t in Software mode seems to be quite different from what's in the SDK, so i wouldn't rely on that type for anything. The type also differs between Software and OpenGL modes.

It's up to you to decide whether to use LD or HD models as a base. If you want to use both that's also up to you.

If you don't want the HD models to override yours you can put the models in Half-Life/<gamename>_hd as well so it use the same model in either case.

Model viewer and Hammer use the filename of the main model file (e.g. scientist.mdl) to load sequence files, whereas the game uses the filename specified in the sequence group data in the main model file. If you compiled the model as MyGrunt.mdl then the sequence filenames will be MyGrunt01.mdl, MyGrunt02.mdl, etc.

You should compile them as hgrunt.mdl to avoid this issue.

Edit: however this shouldn't affect scripted_sequence since the list of sequences exists in the main file. Are you sure you're using the exact sequence name?

They are planning to update the SDK at some point, yes.

It's probably hitting the first conditional constantly and keeps setting m_flFreeammotime to a time in the future. Try tracking whether that variable has been set, maybe add a condition m_flFreeammotime == 0 and then set it back to 0 when you've run the ammo reset code.

It looks like you're doing manually what the weapons code is doing automatically for reloads so maybe see if you can't just use that instead.