Hud Scaling Support?

[OpenRift412]

This would probably be more of a long-term thing, but it would be cool to see perhaps the ability to scale HUD icons as well. The main reason I bring this up is because the best current method to do this has some notable caveats, such as certain HUD elements being cut off on the edge of the screen regardless of how they're realigned in the HUD configuration files and some icons not even showing up at all in Blue Shift.

So that being said, would adding compatibility or implementing your own scaling method be doable?

[SamVanheer]

1. In the tram ride if you move around a lot the tram will get stuck and stop moving.

That's caused by the limited physics capabilities of the engine. Not really fixable unless you do what was done with Blue Shift which is to make the frame thicker with clip brushes.

2. If you shoot a rat it will loop its death sequence indefinitelly

The animation is set to loop, that's why it does that. I'll fix it later when i have time.

3. Sometimes the RPG will refuse to auto-reload after firing a grenade requiring you to disable the laser-tracking in order to do so.

I think i can see what's causing that, i'll try to fix it later when i have time.

4. In multiplayer, the gluon gun doesn't have an energy cloud

That's intentional. It only shows the cloud when it hits an entity it can damage.

[Ronin4862]

Thanks for the replies Sam!

[Ronin4862]

That's caused by the limited physics capabilities of the engine. Not really fixable unless you do what was done with Blue Shift which is to make the frame thicker with clip brushes.

Speaking of Blue Shift. After you as Barney get off the tram you see Gordon pass you in his tram ride. His model stutters while the tram passes you. Any idea what causes that? The train glides smoothly but the passager (Gordon) stutters inside.

[SamVanheer]

That's caused by the limited physics capabilities of the engine. Not really fixable unless you do what was done with Blue Shift which is to make the frame thicker with clip brushes.

Speaking of Blue Shift. After you as Barney get off the tram you see Gordon pass you in his tram ride. His model stutters while the tram passes you. Any idea what causes that? The train glides smoothly but the passager (Gordon) stutters inside.

That's already been fixed: https://github.com/ValveSoftware/halflife/issues/3228

[Ronin4862]

That's caused by the limited physics capabilities of the engine. Not really fixable unless you do what was done with Blue Shift which is to make the frame thicker with clip brushes.

Speaking of Blue Shift. After you as Barney get off the tram you see Gordon pass you in his tram ride. His model stutters while the tram passes you. Any idea what causes that? The train glides smoothly but the passager (Gordon) stutters inside.

That's already been fixed: ValveSoftware/halflife#3228

Awesome! I wasn't aware of that! You've got a new follower! 😆

[Ronin4862]

3. Sometimes the RPG will refuse to auto-reload after firing a grenade requiring you to disable the laser-tracking in order to do so.

I think i can see what's causing that, i'll try to fix it later when i have time.

The easiest way to test is in crossfire map. Fire the rpg at the sky and chances are it will not auto-reload.

[SamVanheer]

I've fixed the RPG issue: https://github.com/ValveSoftware/halflife/issues/3264

[Ronin4862]

I've fixed the RPG issue: ValveSoftware/halflife#3264

I can confirm that! Thanks Sam and excellent work!

[Ronin4862]

Hello Sam, There's a slight stutter each time you crouch. It's minor but the motion is not smooth all the way down. There's a small "hiccup" in the last part of the transition from up to down when you are near the floor.

[Ronin4862]

P.S. This is a statement of your work! I'm running out on finding bugs 😆😆

[SamVanheer]

Hello Sam, There's a slight stutter each time you crouch. It's minor but the motion is not smooth all the way down. There's a small "hiccup" in the last part of the transition from up to down when you are near the floor.

What framerate are you running the game at? Is it capped at a particular setting or running as fast as possible?

[Ronin4862]

Hello Sam, There's a slight stutter each time you crouch. It's minor but the motion is not smooth all the way down. There's a small "hiccup" in the last part of the transition from up to down when you are near the floor.

What framerate are you running the game at? Is it capped at a particular setting or running as fast as possible?

80 fps. fps_override 1 fps_max 999 Vsync off both from nvidia cpl and game settings. RTSS ScanlineSync to get vsync effect without input lag. Game runs like butter, extremely smooth and responsive. I game on a CRT (GDM-FW900) so that might enhance the perception of every small stutter or discontinuity in frame times due to lack of motion blur. To be fair, I notice this very small stutter while crouching only on the CRT. On my other display, an 144Hz "gaming" LCD, I don't notice anything at all as the motion is blurred by the display. I thought twice about asking you this because it is minor, but if there's a hack in the code related to crouching you were obviously the man to ask 🙂!

[Ronin4862]

Hello Sam, Found a bug in the cowering animation of a scientist when you shoot a friendly NPC. Sorry for the quality, used my phone. Simetimes the scientist cowers properly but most of the time he's stuck in a loop. https://we.tl/t-GF9KOMqv7E

Another thing I wish to ask you is if it is possible to increase the lifetime of temporary entities like broken glass, ejected soda cans and debris from broken walls or doors. Thanks!

[Ronin4862]

Any ideas Sam? Thanks

[SamVanheer]

Hello Sam, There's a slight stutter each time you crouch. It's minor but the motion is not smooth all the way down. There's a small "hiccup" in the last part of the transition from up to down when you are near the floor.

What framerate are you running the game at? Is it capped at a particular setting or running as fast as possible?

80 fps. fps_override 1 fps_max 999 Vsync off both from nvidia cpl and game settings. RTSS ScanlineSync to get vsync effect without input lag. Game runs like butter, extremely smooth and responsive. I game on a CRT (GDM-FW900) so that might enhance the perception of every small stutter or discontinuity in frame times due to lack of motion blur. To be fair, I notice this very small stutter while crouching only on the CRT. On my other display, an 144Hz "gaming" LCD, I don't notice anything at all as the motion is blurred by the display. I thought twice about asking you this because it is minor, but if there's a hack in the code related to crouching you were obviously the man to ask 🙂!

If simply changing monitors fixes it then it's probably the monitor at fault.

Found a bug in the cowering animation of a scientist when you shoot a friendly NPC. Sorry for the quality, used my phone. Simetimes the scientist cowers properly but most of the time he's stuck in a loop.

Looks like this is caused by the Scientist code falling back to the default Alert Stand schedule which switches the monster activity to idle. Once the schedule has finished the Scientist AI switches back to the excited activity which causes the cowering.

There should probably be a case handled in there for cowering in specific situations.

Another thing I wish to ask you is if it is possible to increase the lifetime of temporary entities like broken glass, ejected soda cans and debris from broken walls or doors.

Soda cans aren't temporary entities, they're server side entities and their lifetime is defined by the env_shooter and gibshooter entities.

The rest are all func_breakable. Lifetime is controlled by this parameter: https://github.com/SamVanheer/halflife-updated/blob/2c41a96c8f27d83110c8eb70aeca58225264be07/dlls/func_break.cpp#L730

Because it's a byte the maximum lifetime is 25.5 seconds.

You could get around that by adding a custom user message that calls gEngfuncs.pEfxAPI->R_BreakModel on the client side.

[Ronin4862]

You could get around that by adding a custom user message that calls gEngfuncs.pEfxAPI->R_BreakModel on the client side.

Do you mean I should call gEngfuncs.pEfxAPI->R_BreakModel function instead of the Die function? Can you please provide a more detailed explanation? I couldn't import cl_enginefunc_t into func_break.cpp.

[Ronin4862]

Can you please help me out here Sam? I'm no programmer and I have zero experience in coding, unfortunately.

[SamVanheer]

gEngfuncs is the client side engine API; you can't use that in the server dll.

What you want to do is re-implement the TE_BREAKMODEL message in the client dll.

This page goes into detail about what user messages are and how they work: https://www.gvme.org/4197

func_breakable's code should look like this:

MESSAGE_BEGIN(MSG_PVS, gmsgBreakModel, vecSpot);
// position
WRITE_COORD(vecSpot.x);
WRITE_COORD(vecSpot.y);
WRITE_COORD(vecSpot.z);

// size
WRITE_COORD(pev->size.x);
WRITE_COORD(pev->size.y);
WRITE_COORD(pev->size.z);

// velocity
WRITE_COORD(vecVelocity.x);
WRITE_COORD(vecVelocity.y);
WRITE_COORD(vecVelocity.z);

// randomization
WRITE_BYTE(10);

// Model
WRITE_SHORT(m_idShard); //model id#

// # of shards
WRITE_BYTE(0); // let client decide

// duration
//This is now writing a short instead of a byte
WRITE_SHORT(25); // 2.5 seconds

// flags
WRITE_BYTE(cFlag);
MESSAGE_END();

The client's code should look like this:

bool CHud::MsgFunc_BreakModel(const char* pszName, int iSize, void* pbuf)
{
    BEGIN_READ(pbuf, iSize);

    Vector origin;
    origin.x = READ_COORD();
    origin.y = READ_COORD();
    origin.z = READ_COORD();

    Vector size;
    size.x = READ_COORD();
    size.y = READ_COORD();
    size.z = READ_COORD();

    Vector dir;
    dir.x = READ_COORD();
    dir.y = READ_COORD();
    dir.z = READ_COORD();

    const float random = READ_BYTE() * 10.f;

    const int modelId = READ_SHORT();

    const int numberOfShards = READ_BYTE();

    const float duration = READ_SHORT() * 0.1f;

    const int flags = READ_BYTE();

    gEngfuncs.pEfxAPI->R_BreakModel(origin, size, dir, random, duration, numberOfShards, modelId, flags);

    return true;
}

(untested, but should work)

You can then pass longer durations.

Note that the temporary entity code can destroy the effects sooner than that if it deems this necessary. The engine also can't render too many entities at once, so if you create too many of these at once they won't all render and may blink in and out of existence when you move and/or look around.

I would advise learning the basics of programming, C++ and concepts like remote procedure calls (that's what user messages basically are) before trying to make a mod. I can't keep doing the work for you, that wouldn't be fair to you. You're missing out on all of the experience that comes with figuring this out on your own.

[Ronin4862]

Hello Sam,

First, I would like to thank you for your effort in explaining these to me and apologise for the inconvenience...I didn't think that something so simple as changing the lifetime of a breakable could turn into something so complex.

Secondly, after reading the material you gave me, I did the following in order to rebuild the project without errors:

1. I declared gmsgBreakModel into UserMessages.h by adding the line: inline int gmsgBreakModel = 0; after modifying the func_break.cpp's code as you instructed.
2. I then registered it in UserMessages.cpp by adding the line gmsgBreakModel = REG_USER_MSG("BreakModel", -1); I noticed the game instantly crashes when I shoot a window or break a crate if I set something different than -1 or 25.
3. Finally I defined gmsgBreakModel by adding #include "UserMessages.h" in func_break.cpp
4. After that I added your code: bool CHud::MsgFunc_BreakModel(const char *pszName, int iSize, void *pbuf) {BEGIN_READ(pbuf, iSize); etc... into hud_msg.cpp as I saw a lot of the type bool CHud::MsgFunc_ enumerated there.
5. Finally, I added the user message: bool MsgFunc_BreakModel(const char* pszName, int iSize, void* pbuf); into hud.h.

The project builds succesfully but whenever I break a wooden crate or a glass window they simply disappear without giving any glass shards or wood splinters.

[SamVanheer]

Sounds like you didn't declare and hook the message on the client side. Double check the article to make sure you've followed all of the steps.

[Ronin4862]

Yes...I figured as much but I got a little confused by the _DECLARE_MESSAGE( mScoreboard, ScoreInfo ); example from the tutorial. What I really needed to do was to implement: int __MsgFunc_BreakModel(const char* pszName, int iSize, void* pbuf) { return static_cast<int>(gHUD.MsgFunc_BreakModel(pszName, iSize, pbuf)); } into hud.cpp I hooked the message also in hud.cpp: void CHud::Init() { . . . HOOK_MESSAGE(BreakModel); and success!

By the way, I made the soda cans stay by commenting out this line: https://github.com/SamVanheer/halflife-updated/blob/2c41a96c8f27d83110c8eb70aeca58225264be07/dlls/combat.cpp#L653 My mod is complete and together with shells stay, gibs stay and soda cans stay I think it looks beautiful. Yes, I did notice that if I leave the area and return later some breakables disappear but only a few; probably the engine can't deal with too many.

[Ronin4862]

Hey Sam, I tested it some more and everything is fine. I didn't notice any blinking in and out of existence, only that some breakables disappear after you move out of the area and then return. The good part about Half-Life gameplay is it's quite linear, you keep moving from one area to another and rarely return and as long as you stay in one place the breakables never fade away; so all is good. Do you think this modification is worth including in your master HL updated code? Afterall, we didn't change anything, only the way we say the same thing. You can keep the default 2.5s duration but if someone like me wants to increase this, he/she will only have to change one parameter and not go through all the hoops I did. It's your call, I'm only suggesting. Thanks once again for your support and I will only bother you with the Half-Life bugs that I find, which at the moment are just two:

1. Rat death sequence is looping.
2. Scientist cowering animation resetting after you attack another scientist (we talked about that in a previous post).

Regards!

[SamVanheer]

By the way, I made the soda cans stay by commenting out this line:

If you do that you'll eventually run out of entities. The game will shut down with a fatal error. I suggest increasing the fade out time, but still having them fade to free up the entity.

Do you think this modification is worth including in your master HL updated code?

No, because the other engine limits make such a change too unreliable to use. Even the vanilla version can break down if enough effects are going on at the same time, this would make it worse.

I'll see what i can do about the other issues.

[Ronin4862]

Hey Sam! Found a new bug in c1a4 (Blast Pit) near the huge fan. When you open the door it slides all the way to the right and after that it returns to its original position. Until now I encountered only one fatal crash but was not repeatable: ED _Alloc: no free edicts. Can this be related to the breakables stay mod you helped me out with? Oddly, it happened in an area where there were no breakables... Thanks!

[Ronin4862]

I've also noticed sparks happening in mid-air with no apparent reason throughout the game (over NPCs heads, middle of the room, etc). I'm not sure if this has always been the case and I'm just noticing it just now. Most of the time is just the falling, droplets-like sparks, not the big, yellow flash-like one in the center.

[SamVanheer]

Are you using the development builds for testing or are you building your own ones?

I can't reproduce the door issue, My guess is the door pos2 origin is calculated incorrectly or not being set: https://github.com/SamVanheer/halflife-unified-sdk/blob/9284512bf67b8b635f1f57ed2690b7d4572f8ffa/src/game/server/entities/doors.cpp#L304

The out of edicts error might be because of the breakable wooden planks at the top of the fan silo. You may be spawning so many of them that you're running out of edicts there.

In debug builds NPCs will show sparks over their heads when their schedule fails: https://github.com/SamVanheer/halflife-unified-sdk/blob/9284512bf67b8b635f1f57ed2690b7d4572f8ffa/src/game/server/entities/NPCs/schedule.cpp#L176-L186

There is another bug that can cause random sparks to show up, and i have noticed it in the same location as you have before: https://github.com/ValveSoftware/halflife/issues/3270 https://github.com/ValveSoftware/halflife/issues/3269

These two bugs combine to cause sparks to appear in seemingly random locations. It should be fixed already in the latest version, so you might be using an outdated codebase.

[Ronin4862]

Are you using the development builds for testing or are you building your own ones?

This is what I'm using. It was updated by you 11 days ago: https://github.com/SamVanheer/halflife-updated

The out of edicts error might be because of the breakable wooden planks at the top of the fan silo. You may be spawning so many of them that you're running out of edicts there.

No. That fatal error didn't happen there. It happened on a random corridor after I shot a headcrab zombie. I'm not sure it is related to the modifications I did for breakables as when I run out of edicts they usually don't render anymore and the game doesn't crash. For instance if I break a lot of crates and produce tons of splinters, at some point the splinters don't show anymore and the crate just disappears after being hit by the crowbar. Have you ever encountered that error while playing the game without doing anything special to the source code?

These two bugs combine to cause sparks to appear in seemingly random locations. It should be fixed already in the latest version, so you might be using an outdated codebase.

What version should I be using then?

[Ronin4862]

And yes, I apply the breakables stay modifications to your latest master zip and then build client.dll and hl.dll

[SamVanheer]

No. That fatal error didn't happen there. It happened on a random corridor after I shot a headcrab zombie. I'm not sure it is related to the modifications I did for breakables as when I run out of edicts they usually don't render anymore and the game doesn't crash. For instance if I break a lot of crates and produce tons of splinters, at some point the splinters don't show anymore and the crate just disappears after being hit by the crowbar.

They stop rendering because you can only have 255 entities sent to the client at any time. They're still there, they just aren't visible anymore. Unless the entity is destroyed it will continue to use the edict slot, eventually leading to the out of edicts error.

Have you ever encountered that error while playing the game without doing anything special to the source code?

Not without spamming entities in some manner. During normal gameplay it should be a very rare occurrence.

What version should I be using then?

If you're using the latest version then there might be another cause of that bug. I'll see if i can find out what's happening. Do double check to make sure you're not using outdated dlls or code.

[Ronin4862]

Not without spamming entities in some manner. During normal gameplay it should be a very rare occurrence.

Yes. As I said it happened only once in more than 3 weeks of testing. If I create an obscene amount of debris, the new entities aren't visible any more but the engine never crashed before besides that one time. If I move to another area, like just around a corner and then immediately come back, some older breakables are removed by the engine and the new ones are visible again. I know what I'm doing is a trick but the game immersion is unbelievable! There was one scene where some grunts were both firing and throwing grenades at me while I had some crates behind me. The moment they exploded, wooden shards and the contents flew all around me and then landed around just like the lobby scene of The Matrix. It was fantastic, the engine physics effects really look nice with exploding stuff. It's hard to describe in words, you have to try it yourself :)

Do double check to make sure you're not using outdated dlls or code.

I never use the beta versions (i.e. HLU-V1.0.0-beta011). I always follow your latest master zip and read what you are changing. At this moment I use the zip that addressed "Fix off by one bug in SENTENCEG_Init" 11 days ago. After that I apply my breakables stay mod and some other small tweaks to the HUD elements position and duration I learned from you a long time ago and then build the two dlls. That's it!

I can't reproduce the door issue, My guess is the door pos2 origin is calculated incorrectly or not being set.

Have you tried opening the door from within the big chamber where the giant fan is located? Like in my picture? In my case it's always repeatable. Even if I exit the game or load a game. For example, I have a saved game in the control room where you fire the rocket engine and burn the tentacle monster to a crisp and then travel to that door. It always happens that way. I'll check later if this is also the case with the default game dlls.

[SamVanheer]

Yes. As I said it happened only once in more than 3 weeks of testing. If I create an obscene amount of debris, the new entities aren't visible any more but the engine never crashed before besides that one time. If I move to another area, like just around a corner and then immediately come back, some older breakables are removed by the engine and the new ones are visible again. I know what I'm doing is a trick but the game immersion is unbelievable!

Sounds like you're getting lucky with the number of entities that are being created.

Have you tried opening the door from within the big chamber where the giant fan is located? Like in my picture? In my case it's always repeatable. Even if I exit the game or load a game. For example, I have a saved game in the control room where you fire the rocket engine and burn the tentacle monster to a crisp and then travel to that door. It always happens that way. I'll check later if this is also the case with the default game dlls.

Can you give steps to reproduce this with a fresh game setup? E.g. if you load the map directly using map c1a4e does it happen? Do you first have to save and load before it starts happening, etc.

It looks like the door is using the position value from another map. This door exists in multiple maps and is synced with a global name, so it's possible that the value is getting modified incorrectly after passing through level changes.

[Ronin4862]

Sounds like you're getting lucky with the number of entities that are being created.

You earlier said that a maximum of 255 entities can be sent at any time to the client. Can this limit be increased like we did with the duration when we changed WRITE_BYTE to WRITE_SHORT or is this a hard limit of the engine?

Can you give steps to reproduce this with a fresh game setup? E.g. if you load the map directly using map c1a4e does it happen? Do you first have to save and load before it starts happening, etc.

If I load map c1a4e directly in the console, the door slides to the left and everything is ok. If I load a saved game it slides to the right and keeps on going :)))))) I attached two videos showing this. I also attached two saved games. One with this exact issue and the other one in the chamber where you first encounter the Gargantua. I've made the save just in front of the mid-air spark.

P.S. Sorry for the video quality https://we.tl/t-OmWVpM2hw1 saves.zip

[Ronin4862]

I can confirm that both issues (door sliding to the right and sparks in mid-air) are present with the default Half-Life dlls also.

[Ronin4862]

I finally managed to get my sh*t together and make some proper videos. I can confirm that the sparks over NPCs heads aren't present in the original dlls and If I remember correctly they weren't in your earlier builds as well, so there's gotta be something you've changed along the way. https://we.tl/t-NvbpfGam3K

[Ronin4862]

I can confirm that both issues (door sliding to the right and sparks in mid-air) are present with the default Half-Life dlls also.

To be more clear. If I use either the default dlls or your dlls, and then load the "Power Up" saved game, the CONTINUOUS spark is still present. If I type "map c2a1" the continuous spark is nowhere to be seen with either dlls, so this means it was triggered by something along the way. To be honest I don't remember if this was present when I made a playthrough with the original dlls...

The other situation where we have TEMPORARY sparks above NPCs heads it doesn't matter if I load a saved game or type that map in the console. The sparks are present with your dlls, absent with the default ones. Hope this clears things a bit...

[SamVanheer]

You earlier said that a maximum of 255 entities can be sent at any time to the client. Can this limit be increased like we did with the duration when we changed WRITE_BYTE to WRITE_SHORT or is this a hard limit of the engine?

No, this limit is in the engine so it can't be changed.

I can confirm that both issues (door sliding to the right and sparks in mid-air) are present with the default Half-Life dlls also.

Can you give a minimal steps to reproduce for the door issue? E.g. do you have to play through the entire Blast Pit chapter first, do you have to turn on the power first and then turn on the fan, etc. Every bit of information helps.

The spark bug is caused by an env_spark from c1a4j (last Blast Pit map) being carried over to the Power Up map. When you play through the maps the position apparently shifts until it ends up in the location you see in the video.

There are 3 parts to that bug:

1. The maps lack a transition volume to restrict which entities are moved over (all transitionable entities in the map are transitioned as a result)
2. env_spark entities are allowed to transition (they shouldn't, and Source makes sure they don't so this needs fixing)
3. The spark origin changes incorrectly during level transitions

Fixing 2 fixes this bug. 3 is probably caused by a limitation in the save game system. The entity originates from c1a4j but during transitions it's probably being moved relative to the wrong landmark. I don't know if it can be fixed since part of this is in the engine.

I can confirm that the sparks over NPCs heads aren't present in the original dlls and If I remember correctly they weren't in your earlier builds as well, so there's gotta be something you've changed along the way.

Turns out this is caused by me not doing a full rebuild. I usually do that when making release builds but i apparently forgot to do it this time so the debug version of schedule.cpp was used which enables the spark debug feature.

[Ronin4862]

No, this limit is in the engine so it can't be changed.

Yeah, I thought as much...

Can you give a minimal steps to reproduce for the door issue? E.g. do you have to play through the entire Blast Pit chapter first, do you have to turn on the power first and then turn on the fan, etc. Every bit of information helps.

I can never reproduce the issue if I load maps from Blast Pit via console. It only happens while actually playing the game. The order that I always do is turn on the fan after entering the problematic door from the inside and shooting the two zombies; fly up then turn the fuel and oxygen, then power and then fry the tentacle monster. The thing is, at some point, I returned to the little room behind the problematic door as I ran out of grenades. In the space between the door and the room there's a loading point. If I go in one direction I can see the corpses and decals on the walls I left behind, if I go from the other I don't see them, so things must've been screwed at that transition point when the loading occurs...

Turns out this is caused by me not doing a full rebuild. I usually do that when making release builds but i apparently forgot to do it this time so the debug version of schedule.cpp was used which enables the spark debug feature.

You can always count on me on finding things that don't work :))))

So what should I use? This? https://github.com/SamVanheer/halflife-updated

Or this? https://github.com/SamVanheer/halflife-updated/releases/tag/HLU-V1.0.0-beta011

[SamVanheer]

I'll make a new beta build soon, you can use that one when it's out.

I was able to reproduce the door bug. It happens if you go through the level change at the top of the fan and then come back. The door destination position isn't adjusted on the way out, but on the way in it gets adjusted to be relative to the landmark origin which changes the door destination.

Every round trip you make adds more distance to the destination position, so the door will move further and further away each time.

Basically on the way out it saves the destination as absolute coordinates, on the way in it treats that as coordinates relative to the landmark and adds the landmark origin to create the absolute coordinates.

Unfortunately as i said part of this code is in the engine, and it looks like that's where the bug originates. Being able to enter a map from multiple directions causes this to break. This save game system was designed around strictly linear progression through a set of maps, not two maps having multiple changelevels to each-other.

Fortunately this only happens if you go back to an area you're unlikely to visit again, and it doesn't block your progress so the bug isn't that bad.

The env_spark bug has been reported here: https://github.com/ValveSoftware/halflife/issues/3280

And has been fixed.

[Ronin4862]

Fortunately this only happens if you go back to an area you're unlikely to visit again, and it doesn't block your progress so the bug isn't that bad.

Yeah, I had to return to that area because I needed the grenades in the small room.

The env_spark bug has been reported here: ValveSoftware/halflife#3280

And has been fixed.

Great job Sam! As usual 😀! I'll keep an eye out for when you release something new.

P.S. Wow, it's already out! Downloading now, testing tomorrow! 👍

[Ronin4862]

Hey Sam! I don't understand. I downloaded your latest update "[Fix env_spark transitioning to other maps when it shouldn't]" and I still get sparks over NPCs heads... Am I missing something here?

[Ronin4862]

In the mean time I've found two new bugs:

1. Walls texture missing in "Black Mesa Inbound" if I load a saved game or just type in "map c0a0e". If I take the tram ride first everything is fine afterwards (see the 2 videos).
2. Audio CD stuttering; If you play with the original CD (loaded via Daemon Tools Lite and included in the download links), sometimes after one audio track is triggered, the second one stutters (see attached vid).

P.S. Good job on the env_spark bug! As you briefly see behind the Gargantua there's no spark! And I made a playthrough to that point!

https://we.tl/t-xg2wj81464 https://we.tl/t-Km4uDDeTAo https://we.tl/t-6gmR9K2hy2

[SamVanheer]

Hey Sam! I don't understand. I downloaded your latest update "[Fix env_spark transitioning to other maps when it shouldn't]" and I still get sparks over NPCs heads... Am I missing something here?

i haven't released a new beta yet, so i'm assuming you made a new build yourself.

You need to make a Release build, otherwise the debug spark code gets turned on. See this for more information on build configurations: https://docs.microsoft.com/en-us/visualstudio/ide/understanding-build-configurations?view=vs-2022

Make sure to do a full rebuild so the debug spark code doesn't accidentally get compiled in.

In the mean time I've found two new bugs:

1. Walls texture missing in "Black Mesa Inbound" if I load a saved game or just type in "map c0a0e". If I take the tram ride first everything is fine afterwards (see the 2 videos).

c0a0e has a different texture wadincluded in the bsp file. When you load the map directly that texture gets used. When you load it by transitioning from the previous map it continues to use the texture that was already loaded. The textures have the same name, and since the name is what's used to identify which previously loaded textures to reuse it works properly on level change.

I can't change this behavior through code, and modifying the bsp file to not include that texture using the existing scripting API is not a simple matter. Since i can't redistribute official bsp files this isn't feasible to fix. It's hardly ever going to be noticeable to players so i don't think it matters much anyway.

2. Audio CD stuttering; If you play with the original CD (loaded via Daemon Tools Lite and included in the download links), sometimes after one audio track is triggered, the second one stutters (see attached vid).

Looks like you're playing Half-Life Updated which uses the engine's music playback system. It allows the use of CDs so there's probably a bug in Miles Sound System (used for music playback).

I can't fix that in the engine, but the Half-Life Unified SDK uses its own music playback system that doesn't try to use CDs so it shouldn't be a problem there.

[Ronin4862]

i haven't released a new beta yet, so i'm assuming you made a new build yourself.

As I said previously, I always use halflife-updated-master.zip (not the beta releases); I apply my modifications then build client.dll and hl.dll

You need to make a Release build, otherwise the debug spark code gets turned on

Yes, you are correct. VS2019 came with Debug mode by default. I changed to Release and rebuilt. The sparks overhead behavior is gone (I previously disabled that debug section you pointed to me earlier that calls for UTIL_Sparks(tmp) so it's a non-issue anyway). I did notice that the dlls are significantly smaller with Release but the performance (frames per second) is exactly the same as with Debug mode. Except those sparks everything is exactly the same.

Looks like you're playing Half-Life Updated which uses the engine's music playback system. It allows the use of CDs so there's probably a bug in Miles Sound System (used for music playback).

I can't fix that in the engine, but the Half-Life Unified SDK uses its own music playback system that doesn't try to use CDs so it shouldn't be a problem there.

I played with this Unified version for about an hour. I downloaded a beta release (dev-2022-06-07-11-31-40) and started it as a MOD in Steam. Excuse my ignorance but what exactly is to be gained by playing Half-Life 1 this way? The HUD is different, when you pick up the HEV suit there's a different sound, no suit voice monolog, credits at the beginning of the game were labeled CRxx, etc... As for music, it neither recognizes that an Audio CD is inserted nor it sees the crappy compressed mp3s "media" folder that came with the Steam version of HL either. There's simply no music. Anyway, is Unified at least able to play lossles formats such as uncompressed WAVs or FLACs? Because the point of using the original CD is to have better quality music.

Thanks!

[SamVanheer]

I did notice that the dlls are significantly smaller with Release but the performance (frames per second) is exactly the same as with Debug mode. Except those sparks everything is exactly the same.

Yes that's normal. Debug builds are unoptimized and have extra debug info in them so they're larger. Performance doesn't really differ because it's an old game that doesn't tax modern systems enough for a debug build to lower performance.

I played with this Unified version for about an hour. I downloaded a beta release (dev-2022-06-07-11-31-40) and started it as a MOD in Steam. Excuse my ignorance but what exactly is to be gained by playing Half-Life 1 this way? The HUD is different, when you pick up the HEV suit there's a different sound, no suit voice monolog, credits at the beginning of the game were labeled CRxx, etc...

It's a development build, not a beta release. Development builds are alpha-tier builds.

The purpose of this SDK, just like Half-Life Updated, is to allow modders to make a Half-Life mod with bug fixes and improvements. The Unified SDK differs in that it also combines Half-Life, Opposing Force and Blue Shift to allow modders to create mods based on any of these games without having to replace game assets in their mod.

The use of these SDKs as regular mods to play the original games is more of a secondary goal.

Like i said, this is an alpha build. V1.0.0 is still in development and is missing features. Since this SDK is based on Opposing Force (it has more weapons, so the assets for those are used here) it looks and feels like that game instead of Half-Life.

Everything you've listed is still in development. It also sounds like you didn't follow the installation instructions, because the credit text names were changed and are updated by the installer tool.

I realize that the dev builds don't link to the install instructions, but that's because these dev builds were made mostly for internal use and one-off tests, not public use. I've been writing documentation and setting up the development framework so i haven't had the chance to do that yet.

See the wiki for more information.

As for music, it neither recognizes that an Audio CD is inserted nor it sees the crappy compressed mp3s "media" folder that came with the Steam version of HL either. There's simply no music. Anyway, is Unified at least able to play lossles formats such as uncompressed WAVs or FLACs? Because the point of using the original CD is to have better quality music.

Again, you didn't follow the installation instructions so the maps weren't updated to use the new ambient_music entity. The old music entities no longer exist so music playback using the engine's music player no longer works.

The new music system supports the formats listed here: https://github.com/ddiakopoulos/libnyquist#format-support

Though i've only tested mp3 the rest should work.

CD audio playback is not supported. It relies on track ids instead of filenames, uses platform-specific APIs and the engine's version is exploitable by providing a command to open the CD drive.

If you want to use your own music you can put it in hlu_addon/media and give it the same name and extension as the original file. I'd recommend using the same file format as well. Although the format should be auto-detected based on the file contents it's still safer to use the correct format and extension combo.

Note that the installer tool copies and renames the soundtracks from Opposing Force and Blue Shift to the mod directory to be used side by side with the original Half-Life soundtrack. If you want to replace those you'll need to use the correct filename.

[Ronin4862]

Thank you for the detailed explanation Sam!

The new music system supports the formats listed here: https://github.com/ddiakopoulos/libnyquist#format-support

Though i've only tested mp3 the rest should work.

Can't this be implemented for Updated as well?

[SamVanheer]

Can't this be implemented for Updated as well?

No, this feature has several third party dependencies that are difficult to set up without CMake. It's also out of scope for that project.

[Ronin4862]

Looks like you're playing Half-Life Updated which uses the engine's music playback system. It allows the use of CDs so there's probably a bug in Miles Sound System (used for music playback).

Hey Sam! I may have found an explanation for the audio stuttering bug. In my videos the stuttering occured AFTER playing Track 28 which is the last in the CD list (Gargantua electrocution death scene). You can simply test this by typing "cd play 28" in the console with an audio CD image loaded (I uploaded that earlier). AFTER that type any other track (i.e "cd play 18") and it WILL stutter. So it has something to do with the fact the engine's music playback system doesn't buffer properly after the last track on the CD is played. Is there anything you can do about this? Thanks!

[SamVanheer]

Is there anything you can do about this?

No. Music playback is handled by Miles Sound System, a proprietary third party library. If there's a bug in there it's not getting fixed.

[Ronin4862]

Hey Sam! I managed to get rid off the CD stuttering thing. The Half-Life Audio CD has 28 tracks. After the last one has played every other track will stutter, so the solution is to never get the last track to play. I extracted the tracks from the CD and created my own with 30 tracks (28 + 2 dummy ones). Why? Because, the engine expects 29 tracks and will loop the 29th one if present (type "cd info" in the console and it will report 29 tracks no matter if you have a CD loaded or not). If I had made 28 + 1 empty track, the 29th one would have started playing as soon as I started the game engine, thus starting the stuttering because it is the last track on the CD. With 30 tracks, the 30th track will never get triggered thus stuttering will never occur. For BS and OF there are 20 tracks (same tracks but arranged in a different order). I simply made an additional dummy (empty) track for a total of 21 tracks.

[Ronin4862]

After loading a saved game, the Ichthyosaur's death scene repeats (sometimes with sound).

https://we.tl/t-qJmEK12n8h https://we.tl/t-zoKZzNQMvM