Forum posts

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?

They do, they use the follower behavior from that class. That's why i said to use breakpoints in the FollowerUse method, to see what it does.

Studiomdl allocates a fixed size buffer 16Mb in size to write each file. It's possible that file write operations can fail if they exceed the total size though.

Breakpoints are not something you add to a function. Read this: https://docs.microsoft.com/en-us/visualstudio/debugger/using-breakpoints?view=vs-2017

The method is in talkmonster.cpp.

Put breakpoints in the CTalkMonster::FollowerUse method and see what it's doing, if anything.

The engine has a limit to the number of mp3 files it can play. It internally assigns an id to each one and there are a maximum of 200, which includes the files in /media. FMOD doesn't have that limit.

I've reworked the command system:

• Any number of contexts can be shared with any number of other contexts, but circular dependencies are not possible. The internal command context created by the command system is implicitly shared with all contexts (provides the "wait" command), all other contexts must be specified when creating contexts
• The command system and contexts now implement the Dispose pattern
• Variable change event handlers can now veto the change
• Filters are now implemented by aggregating all filters under a change event handler that is always handled first
• Variables can be made read-only
• Variables are now strongly typed, and conversion between string and the type is handled by a type proxy object that provides conversion functionality. The command system constructor takes a format provider used to controlling the formatting of numbers (e.g. 123.45 or 123,45 depending on culture settings). Variables can have custom type proxies specified on a per-variable basis, proxy commands can have custom type proxies specified on a per-parameter basis
• Variables can be virtual (existing version) or proxies to real fields or properties. Fields and properties can be read-only (or have a non-public setter) to implicitly be made read-only)
• Commands can be proxies to methods that take parameters. Command input will be converted to the target types. Methods can have default values to allow for optional command arguments
• Added the find command to search for commands using a keyword, potentially containing wildcards
• Added the help command to display the help info for a named command

Some examples:

//Virtual variable
private readonly IVariable<uint> _fpsMax;

//Creates a modifiable variable, constrained to the range [0, MaximumFPS] (uint does not allow negative values)
_fpsMax = EngineContext.RegisterVariable(
    new VirtualVariableInfo<uint>("fps_max", DefaultFPS)
    .WithHelpInfo("Sets the maximum frames per second")
    .WithChangeHandler((ref VariableChangeEvent<uint> @event) =>
    {
        @event.Value = Math.Min(@event.Value, MaximumFPS);

        var desiredFPS = @event.Value;

        if (desiredFPS == 0)
        {
            desiredFPS = MaximumFPS;
        }

        _desiredFrameLengthSeconds = 1.0 / desiredFPS;
    }));

//Proxy variable
public DateTimeOffset BuildDate { get; }

//Creates a read-only proxy variable of type DateTimeOffset
//Type is printed as 03/08/2019 17:21:41 +01:00
EngineContext.RegisterVariable("engine_builddate", () => BuildDate, "The engine's build date");

//Command
commandContext.RegisterCommand(new CommandInfo("echo", arguments => logger.Information(arguments.ArgumentsString))
                .WithHelpInfo("Echoes the arguments to the console"));

//Proxy command
private sealed class FindCommands
{
    private readonly ICommandContext _context;
    private readonly ILogger _logger;

    public FindCommands(ICommandContext context, ILogger logger)
    {
        _context = context ?? throw new ArgumentNullException(nameof(context));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    public void Find(string keyword, bool searchInHelpInfo = false, bool searchInValue = false)
    {
        var builder = new StringBuilder();

        builder.AppendLine("Find results:");

        var flags = FindCommandFlag.None;

        if (searchInHelpInfo)
        {
            flags |= FindCommandFlag.SearchInHelpInfo;
        }

        if (searchInValue)
        {
            flags |= FindCommandFlag.SearchInValue;
        }

        foreach (var command in _context.FindCommands(keyword, flags))
        {
            command.WriteCommandInfo(builder);
            builder.AppendLine();
        }

        _logger.Information(builder.ToString());
    }
}

commandContext.RegisterCommand(new ProxyCommandInfo<Action<string, bool, bool>>("find", new FindCommands(commandContext, logger).Find)
    .WithHelpInfo("Finds commands and variables"));

The find command is a proxy command with optional arguments, it can be used with just a keyword or with the additional arguments. Finding out which arguments there are is straightforward, using the help command will show you:

help find
find: Proxy command find(String keyword, Boolean searchInHelpInfo = False, Boolean searchInValue = False)
Finds commands and variables

Find works much like help does but can find do partial searches, show multiple commands and perform wildcard searches:

find e*
Command exec
Executes a file containing commands
Command echo
Echoes the arguments to the console
Read Only Proxy Variable DateTimeOffset engine_builddate = 03/09/2019 17:09:58 +01:00
The engine's build date

find * will return all commands.

I'm still reworking the engine so it'll be a while before it gets back to where it was before. I decided to rework the command system now since most of the code that uses it was removed for the redesign.

I've merged the client and server assemblies into single larger assemblies.

SharpLife.Engine.Client & SharpLife.Engine.Server have been merged into SharpLife.Engine.
SharpLife.Game.Client, SharpLife.Game.Client.Renderer.Shared, SharpLife.Game.Server, SharpLife.Game.Shared have been merged into SharpLife.Game.

I've also updated dependencies to the newest version. Nothing worth mentioning.

I'll probably also merge the model format assemblies into a single assembly.

As far as the rest go, i'm thinking about merging a bunch of assemblies into a SharpLife.Core assembly containing SharpLife.Utility, SharpLife.Engine.API and some parts of SharpLife.Game.

SharpLife.Networking.Shared should be merged in as well, but i'll probably remove all networking code first and add it back later once i've redone the engine and game code structure. Otherwise it'll turn into a mess.

I went into your base but i didn't find any skeletons, they've probably despawned on their own.

You shouldn't copy the content, just add this to liblist.gam:
fallback_dir "bshift"

This will let you use Blue Shift content in your mod.

The mouse input issues are a known bug in the SDK code. There is a fix available as a pull request but Valve never merged it.