Forum posts

Just like they did with Half-Life 1's 25th anniversary, they have created a special website for HL2's 20th:

https://www.half-life.com/en/halflife2/20th

Personally, HL2 is not my favorite game of the saga, but it's still a decent FPS. Hope you all enjoy the occasion!

That one seems to not have been updated since 2017, right? Probably not fully compatible with the HL25 update.

Look at the several .txt files inside valve/sprites/ and you'll see that there are several resources defined according to the rendering resolution. There used to be only the "320" and "640" categories, but now you can also find "1280" and "2560" ones. In order for your mod to properly work at all resolutions (low and high), you'll have to create 4 sets of sprite resources (though I really doubt anybody is still playing at 320x240 these days...).

So I was reading the HL Unified SDK changelog and found this:

Added support for custom hull sizes to all entities. This setting should be used only with entities that use Studio models (files with .mdl extension)

But a quick inspection of the source code determined that it's just a way for the mapper to specify the values passed to UTIL_SetSize() from the entity properties window in the level editor (a new keyvalue), instead of having them hardcoded in C++. So not actually the hull size, just the bounding box

Definitely will have to implement this myself, as I couldn't find a way to force HL to use hull #0 for entity-to-world collisions.

When you talk about "regular HL code" do you mean the compiled Valve SDK from https://github.com/ValveSoftware/halflife ? Or just the vanilla game install. Are you using the latest HL25 update? Because that one changed several things related to resource files, HUD, etc (to better support higher resolutions). The HL Updated project has implemented those changes too, so you'll have to provide both SD and HD resolution for your sprites (can't find a proper tutorial right now).

I see at least 3 different fonts in that image. You must use a font identifier service (there are several free or freemium online). You will have to upload the individual textures at their original resolution for the best results (extract them from the .wad), and perhaps crop them.

Ok, I just discovered the reason. It's so stupid, and at the same time it was the only possible explanation, so it makes sense.

If you pay attention, you'll hear that when the crossbow is fired in vanilla HL, those two sounds are indeed played. First the "xbow_fire1.wav", and then the "xbow_reload1.wav". And this happens because the crossbow is a manually-operated weapon and Gordon must draw the string again after every shot. Valve just reused the same sound for the full reload animation (a bit cheap on their part).

Oops, looks like we've got ourselves a bot here, gentlemen! I'm gonna submit a status report to the administrator today.

Maybe the sounds are being played in code?

https://github.com/ValveSoftware/halflife/blob/master/dlls/crossbow.cpp

Also, do you mean that when shooting the crossbow in your mod, the "reload" sound plays instead? Or that both the "shoot" and the "reload" sounds play? It would help if you shared those sound files with us so we could test it ourselves.

I would suggest you try to investigate further instead of implementing that sloppy fix. Believe me, those hacks are never sustainable in the long term

Perhaps nomodels?

https://developer.valvesoftware.com/wiki/Liblist.gam#Options

https://twhl.info/wiki/page/liblist.gam#Key/value_pairs_that_work_on_Steam_GoldSrc_only

This is interesting, it seems that changing the Hull size (size) property of a func_pushable makes no difference at all, because it never gets passed to the CPushable::KeyValue() method. So, the following code never gets to run:

switch (bbox)
{
case 0: // Point
    UTIL_SetSize(pev, Vector(-8, -8, -8), Vector(8, 8, 8));
    break;

case 2: // Big Hull!?!?    !!!BUGBUG Figure out what this hull really is
    UTIL_SetSize(pev, VEC_DUCK_HULL_MIN * 2, VEC_DUCK_HULL_MAX * 2);
    break;

case 3: // Player duck
    UTIL_SetSize(pev, VEC_DUCK_HULL_MIN, VEC_DUCK_HULL_MAX);
    break;

default:
case 1: // Player
    UTIL_SetSize(pev, VEC_HULL_MIN, VEC_HULL_MAX);
    break;
}

Perhaps size is one of those special properties, like friction, that are handled automatically by the engine?

Plus, even if that code got to run, the call to SET_MODEL() inside the CPushable::Spawn() method, which is run later, sets the size also, so pev->mins and pev->maxs would be overwritten (not 100% sure of this). This must be why the func_pushable ends up with an accurate bounding box, same size as the brush.

Erty said:
Maybe you could force it to use the pointhull, and do your own collision checks using its bounding box. The performance won't be as good as with cliphull-based collisions, of course.

Do you mean implementing my own collision system inside the entity code, using tracelines or something?

Thanks for the tip. Tried it, but no luck, the collisions stay the same. For reference, these are the possible values:

// edict->movetype values
#define MOVETYPE_NONE 0 // never moves
//#define    MOVETYPE_ANGLENOCLIP    1
//#define    MOVETYPE_ANGLECLIP        2
#define MOVETYPE_WALK 3           // Player only - moving on the ground
#define MOVETYPE_STEP 4           // gravity, special edge handling -- monsters use this
#define MOVETYPE_FLY 5            // No gravity, but still collides with stuff
#define MOVETYPE_TOSS 6           // gravity/collisions
#define MOVETYPE_PUSH 7           // no clip to world, push and crush
#define MOVETYPE_NOCLIP 8         // No gravity, no collisions, still do velocity/avelocity
#define MOVETYPE_FLYMISSILE 9     // extra size to monsters
#define MOVETYPE_BOUNCE 10        // Just like Toss, but reflect velocity when contacting surfaces
#define MOVETYPE_BOUNCEMISSILE 11 // bounce w/o gravity
#define MOVETYPE_FOLLOW 12        // track movement of aiment
#define MOVETYPE_PUSHSTEP 13      // BSP model that needs physics/world collisions (uses nearest hull for world collision)

// edict->solid values
// NOTE: Some movetypes will cause collisions independent of SOLID_NOT/SOLID_TRIGGER when the entity moves
// SOLID only effects OTHER entities colliding with this one when they move - UGH!
#define SOLID_NOT 0      // no interaction with other objects
#define SOLID_TRIGGER 1  // touch on edge, but not blocking
#define SOLID_BBOX 2     // touch on edge, block
#define SOLID_SLIDEBOX 3 // touch on edge, but not an onground
#define SOLID_BSP 4      // bsp clip, touch on edge, block

I've tried several combinations (some like TOSS and BOUNCE are very funny to watch), but it seems HL will always use hull-based collisions when it comes to entity vs. world. The code that decides this must be probably in that one part we can't touch (the engine).

As you all probably know, the physics of a func_pushable in HL1 are pretty janky, the collisions being specially bad. The correct brush size can make a difference.

I did some tests and found out that the only XY (length/widht, will not consider height here) sizes that seem to work well are 32x32 and 64x64 units. I guess this has to do with the sizes of hulls #1 to 3 (see here). With brushes of those exact sizes, a func_pushable works and looks alright. With other sizes, HL will try to use the next biggest hull:

• A brush smaller than 32x32 will act like it was 32x32. So it will collide will walls too "soon", leaving a visible gap. So for example a 24x24 brush will leave a gap of 8 units of empty space on both sides between the wall and itself.
• Brushes larger than 32x32 but smaller than 64x64 will behave as the latter. A 48x48 brush will leave a gap of 16 units on each side. BUT this will only happen if both dimensions are larger than 32x32 (otherwise 32x32 will be used). So for example a 32x256 brush will stick 224 units into the wall in the Y dimension.
• A brush larger than 64x64 will act like it was 64x64. So it will partially stick into walls. A 96x96 brush will stick 32 units into the wall on both sides.

Strangely enough, when I render the entity's bounding box everything seems to be right, it's the same size as the brush. I don't know why the engine doesn't use that for collision testing.

Changing the "size" property (point, player, big, duck) makes absolutely no difference. When I look at the source code it's not clear what it does...

Is there any way to improve this? (Apart from switching to HL2, that is).

I don't know if any of you have had any luck using AIs (like Stable Diffusion) to generate textures. I've tried it but sometimes getting what I want takes a lot of time. I'm kinda clumsy using those tools, truth be told.

SD has an option you can enable to produce tileable images in case you're interested.

There's also this online tool to make an already existing texture seamless.

I will edit the bookcase prefab so remove all unneeded detail and leave it bare bones, then replace the existing ones.

Thanks, this is exactly what I need for a map! Damn ancient engine...