Forum posts

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.

I've been mostly focusing on Half-Life maintenance on Github and working on Model Viewer (which helps get the shaders and shader invocation code finished). Nothing i can show right now, but i should have something to share soon.

Here's some more information: https://www.gog.com/forum/general/old_games_not_launching_and_eating_100_of_the_cpu_on_windows_7/post1

Seems that Game Explorer is having issues because they shut down a server that the dll is trying to communicate with. They really should've updated it to not phone home.

There have been a number of recent reports about Game Explorer interfering with Half-Life: https://github.com/ValveSoftware/halflife/issues/2543

I've created a branch off this repository that makes adding weapons easier: https://github.com/SamVanheer/half-life-better-weapons

I've reworked the code that precaches weapons and the code that handles prediction so when adding new weapons you only need to replace the LINK_ENTITY_TO_CLASS macro with LINK_WEAPON_TO_CLASS. It is no longer necessary to hook in the weapon in the client side prediction code, which is completely automatic now. Just make sure the source file is included in the client project and you're set.

You will still need to assign a weapon id manually as before.

Note that the impulse 101 command does not learn weapon names automatically, but that's pretty easy to add.
I can automate ammo types as well if the manual precaching is a problem.

More details here: https://github.com/SamVanheer/half-life-better-weapons/blob/1bfb94b43c7a8069bae51690a260adf1135d6743/dlls/weapons.h#L459-L467

The last one, for real this time: https://github.com/SamVanheer/HL_Tools/releases/tag/V2.8

• Properly open the save file dialog for screenshots, provide different extensions and a default filename
• Infer screenshot extension from selected filename. Supported extensions are listed here: https://docs.wxwidgets.org/3.0/classwx_image.html#a9416097f955a828243cba8431e7044d4
• Default file format for screenshots is now PNG
• Use OpenGL viewport size to read & save screenshots
• Set pack alignment to 1 to prevent padding from skewing screenshot result
• Enable scrollbars in control panels when part of the control panel cannot be seen
• Changed checkbox layout for the Model Display panel to avoid creating a vertical scrollbar when there would otherwise be enough space
• Set correct OpenGL options when drawing axes
• Add check to prevent crash if framebuffer creation is not supported
• Rework UV render to texture code to eliminate need to use framebuffer

One last update: https://github.com/SamVanheer/HL_Tools/releases/tag/V2.7

• Fixed Test Origins values not applying to correct axes (thanks Marphy Black)
• Fixed viewmodel origin being off by 1 unit in the Z axis (thanks Marphy Black)

I've released an update: https://github.com/SamVanheer/HL_Tools/releases/tag/V2.6

• Added readonly field to display pev->body value

@MrMystery I hope the WPF based version won't have that, when it's done you'll need to try it out. I can't say when that will be though, only that NET Core 3 will release in September.

You can make those cubes using func_wall_toggle to turn them on, and render mode color with a render color set to have a single uniform color.

It's used in c1a4g, the map after you kill the tentacles. That's the body the tentacles were attached to.

The latest VS 2019 preview added support for XAML Designer for NET Core, so i ported my prototype for HLMV:This is just an early mockup but it's working so far, so i can start working on the new version now.

None yet, Mike from Valve said he was looking into it and will create a new issue if more information becomes available.

If textureindex is 0 then the engine assumes there's a T.mdl.

Note that it's only loaded by clients, the server never loads it.

Regardless the texture data is stored off in the model_t texinfo member which you can't get to from game code so you can't access it either way.

If anyone has any requests for HLMV, i'm going to make one more update to the current version to add a read-only field that displays the pev->body value for a given combination of submodels.

After that the next version will the WPF based version so that could be a while.

Good thing Valve doesn't just blindly do whatever they're asked.

Letting it charge for too long is a feature, the radius damage is more accidental since it can happen if the conditions are met at any range.

I never said it would or should be fixed, i'm just trying to find out what his problem is.

This is probably caused by the Gauss's radius damage. Can you reliably reproduce this issue so it can be tested?

Edit: it might be this bug: https://github.com/ValveSoftware/halflife/issues/1545

Does the description match what you're experiencing?

It's a custom engine, but it's still loaded as a mod to remain compliant with the SDK license. It uses code from the SDK, but no engine code was given by Valve.

Mike from Valve did say he was looking into open sourcing so maybe we'll get something soon.

Some of them, some are just based on user experience.

Posting this here for future reference: https://github.com/antlr/antlr4

Antlr is a library that can be used to parse structured text, like console input and the various text files used by the game.
Could be really useful for when all those files need to be loaded/converted.

Also, Valve is fixing stuff and interacting with us on the Half-Life Github tracker for the moment, so some stuff is getting done.

Maybe.

I've found that some versions of Hammer will now crash when previously they ran just fine. Maybe some driver update is breaking it.

Thanks

So i've been tinkering with WPF a bit to make a mockup of what an IDE for Half-Life modding could look like:Nothing functional, but the idea is to have a program that can manage all the assets in a mod, and access the tools for each one. It would provide shortcuts for doing things like making various assets, checking if you missed anything or if you did it the wrong way, previewing the results, etc.

For instance creating a sky amounts to taking 6 images with specific names, specific dimensions and file formats. This IDE could verify that it's all correct while you're creating it, and preview the skybox in a 3D window to see the orientation.

I was thinking of making this a single instance app with a system tray icon to allow it to run in the background, with a custom protocol to launch various tools, for example: sleditor://run/modelviewer/C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\models\barney.mdl

This would launch the model viewer tool, passing the given filename along to view it. You'd then have a shell command registered that will execute that for any *.mdl file.

Since everything would be part of this single program they can share resources and keep resources loaded so it doesn't have to reload everything when you close the window. It would keep track of your current settings so if you changed your current mod, every active tool instantly knows and adapts.

Tools could hook into a global "check for problems" to see if anything is wrong with a mod's assets to find any problems that need fixing, e.g. models that have incorrect sequence filenames embedded in the main model.

The design for the program would be a small core program + extensions for each tool. An extension would work like Visual Studio extensions, which can add new commands that operate on specific file types and the like. That way it doesn't tie the tools in too closely with the IDE (and avoids requiring the SDK license on the entire codebase) and new tools can be added easily. Ideally they'd all be written in C# to directly interface with things like the filesystem, but extensions could just be wrappers around external tools or command line programs.

Once this is set up each tool can be written, designed to be both standalone and integrated with the same code to back both up.
I'd like to make this separate from SharpLife as much as possible, so i'd prefer a standalone BSP viewer that can do map editing much like what the object editor does right now. That way it will work for every mod.

It would still use the same code for that (engine renderer) but since it would be an extension, the licensing for the IDE wouldn't be affected.

The mockup uses WPF for NET framework, so until WPF Core is ready i can't start work on this. But if anybody has any ideas or feedback for such a program i'd love to hear it.

https://github.com/SamVanheer/HL_Tools/releases/tag/v2.5

People asked about the PS2 .dol format again, so i implemented support for it.

When loading a model you can change the filter to PS2 or All Files, then open a dol file. HLMV will convert the format and load it as usual.

You can then save the model as .mdl using the File->Save Model As... option.

The only difference between .mdl and .dol is the texture data storage.

.mdl stores it as an array of palette indices for each pixel, then an RGB palette.

.dol stores it as a 32 byte texture name (filename without extension), an RGBA palette, and then an array of palette indices for each pixel.

Conversion is automatic but does leave a trace, namely the leftover memory that comes after the palette. 256 bytes are left for each texture because the palette is converted from RGBA to RGB. It's a minor thing that you probably won't ever notice, but i can't fix that easily. It won't cause any problems though.

The SharpLife version of model viewer won't have this problem.

I just updated it with this:

• Added a new option to disable rescaling textures to power of 2

Try this: https://github.com/SamVanheer/HL_Tools/releases/tag/v2.4

I fixed an issue with large models not displaying correctly. Natural Selection has a couple with a bounding box measuring in millions of units.

If this doesn't work, you can download the older version from the Github releases page.

V2.3 update: https://github.com/SamVanheer/HL_Tools/releases/tag/v2.3

Increased maximum texture dimensions to 4096. Some models made for Sven Co-op go up to 2048 so this should more than suffice.

I've released a minor update for Half-Life Model Viewer: https://github.com/SamVanheer/HL_Tools/releases/tag/v2.2

I think the best way to define grindable rails is point entities that define the rails like path_track does. When a player comes close enough you snap them to the rail and move them relative to the lines between points.

I've completed the engine redesign. Here's a list of what's changed:

• The engine is now designed to use a shared codebase for client and server. Instead of separate types and assemblies everything is together to make it easier to write and use code that needs to be used on both client and server.

• Model formats are now mostly encapsulated by a single interface called IModelFormatProvider. This interface allows a loader and renderer to be provided for a particular format. This design will need some reworking later on to support renderers that don't use a specific format (i.e. beams).

• Maps are now represented in-engine as a scene, divided into the entities and graphical parts.

• Model loading has been greatly simplified. Loading is now done by using the ModelManager instance for a given scene, and graphics resources are loaded and uploaded to the GPU as needed. Models loaded at runtime load just fine. For studio models the error model will be used, but support for the error model for brush and sprite models does not currently work. The concept of a model index has been completely removed, as is the concept of precaching models.

• World state has been centralized in a WorldState class to make access easier. The renderer can be accessed from here as well, and for server code a dummy renderer will exist to make writing code easier.

• The old inheritance based entity system has been replaced with a component based system. Entities are now comprised out of zero or more components. Functionality like position, angles and velocity is now contained in the Transform component, models are subclasses of the RenderableComponent component, physics is handled by the Collider component.

Specific functionality is being reworked as discrete components to reduce complexity and make code reusable. For example, func_door's movement logic (inherited from CBaseToggle in the original SDK) is now its own component called LinearMovementLocomotor. Code specific to func_door (automatic return, touch, etc) is contained in the LinearDoor component.

• For backwards compatibility components can specify the original keyvalue name to use for a public member, as well as a custom converter should that be necessary. Converters handle conversion between string and the keyvalue type, with support for common types provided already.

In similar fashion spawnflags can be automatically converted to booleans. The SpawnFlag attribute allows you to specify which bit maps to a boolean.

• Game code is now reduced to just actual game logic. The renderer as well as physics code has been moved into the engine. It is expected that modders modify the engine itself as needed to suit their needs, although the game API should allow for most basic tasks.

• The game assembly is loaded dynamically as before in order to make it easier to work with plugins. The game assembly is listed in the engine configuration file as a plugin, and treated as such. This means plugins will be able to do everything that game code can do. Due to how these assemblies are loaded, plugins can override entity factories defined in the game assembly, allowing you to replace entities.

Since the component based design removes the use of specific entity classes this is no longer a serious problem and potential crash issue, but game code that works with classnames (should be nothing beyond logging) might not work as expected.

Plugins can be server, client or both client and server, although i don't plan to allow downloading of plugins. I do plan to support the use of CSharpScript scripts loaded at map start time, which can do server-only tasks like defining non-networked components, new entity factories and replacing existing factories. At present, plugins are loaded at startup time only, to allow all data related to them to be made immutable.

• The event system has been redesigned to simplify it and make it easier to use. It is no longer necessary to define events ahead of time, it is no longer required to inherit from the EventData class when defining custom event data, and all system operations will work even when in an event dispatch. As such the workaround for this, post dispatch callbacks, have been removed. To avoid state corruption any operations executed while in an event dispatch are queued up for execution after the dispatch has completed.

The event system is more memory and CPU efficient as a result.

• The object editor has been updated to support editing component based entities.

Some examples of the new stuff:
Defining a component with keyvalue name changes, spawnflags:

/// <summary>
/// A door that uses a <see cref="LinearMovementLocomotor"/> to move
/// </summary>
public sealed class LinearDoor : Component
{
    private LinearMovementLocomotor _locomotor;

    private ToggleState _toggleState = ToggleState.AtBottom;

    private Collider Activator;

    public Vector3 Position1;
    public Vector3 Position2;

    [KeyValue(Name = "wait")]
    public float Wait;

    [KeyValue(Name = "lip")]
    public float Lip;

    [SpawnFlag(1 << 0)]
    public bool StartsOpen;

    [SpawnFlag(1 << 3)]
    public bool Passable;

    [SpawnFlag(1 << 5)]
    public bool NoAutoReturn;

    [SpawnFlag(1 << 8)]
    public bool UseOnly;

    [SpawnFlag(1U << 31)]
    public bool Silent;
}

A basic light entity factory:

/// <summary>
/// Non-displayed light.
/// Default light value is 300
/// Default style is 0
/// If targeted, it will toggle between on or off.
/// </summary>
[LinkEntityToFactory(ClassName = "light")]
[LinkEntityToFactory(ClassName = "light_spot")]
public class LightFactory : EntityFactory
{
    protected override void GetComponentTypes(ImmutableHashSet<Type>.Builder types)
    {
        types.Add(typeof(Transform));
        types.Add(typeof(Light));
    }

    public override bool Initialize(EntityCreator creator, Entity entity, IReadOnlyList<KeyValuePair<string, string>> keyValues)
    {
        if (!creator.InitializeComponent(entity.GetComponent<Transform>(), keyValues))
        {
            return false;
        }

        if (!creator.InitializeComponent(entity.GetComponent<Light>(), keyValues))
        {
            return false;
        }

        return true;
    }
}

Defining a keyvalue converter for ints:

[KeyValueConverter(typeof(int))]
public sealed class IntConverter : IKeyValueConverter
{
    public object FromString(Type destinationType, string key, string value) => KeyValueUtils.ParseInt(value);
}

The next task is once again to get player physics working so interaction in the world is possible.

Visual Studio 2017 Community is free: https://visualstudio.microsoft.com/downloads/

It's part of the Half-Life SDK.

If you're willing to make a custom mod you could make an entity that can set the movedir value for the conveyor.

Changing the angles will physically rotate the entire conveyor, but changing only the texture rotation is not possible.

Note that func_conveyor converts the angles value to the appropriate movedir setting, so changing the angles of the entity will not update the conveyor direction. Changing angles will change the physical orientation of the entity.

See https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/bmodels.cpp#L156

SetMoveDir converts the angles.

Valve released an update that fixes this issue. Update your game installation to get the fix.

I found the cause: https://github.com/ValveSoftware/halflife/issues/2109#issuecomment-475634759

As a workaround you can rename the files to use a 3 letter extension, like .esc (Event SCript) for instance (.scr is a known extension so don't use that one).

Make sure to update your game code as well. I hope Valve will push a fix soon.

Are there errors like this in your console: Invalid file type...skipping download of events/powerup.sc

They fixed exploits that could be used to download malware to clients.

There was an engine update a few days ago, but i don't know what exactly was changed.

Are the cl_lc and cl_lw cvars set to 1?