Forum posts

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 that size. 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.
• A brush larger than 64x64 will partially stick into walls. A 96x96 brush will stick 32 units into the wall on both sides.
• 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. So for example a 32x256 brush will stick 224 units into the wall in the Y dimension...

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...