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]

The HUD uses sprites where scaling them up causing noticeable blurring issues. It's possible to add, but would require a fair amount of reworking code. It's also out of scope of this project, so it has to wait until the merger project.

[OpenRift412]

It's also out of scope of this project, so it has to wait until the merger project.

The merger project?

[SamVanheer]

The project i mentioned in SamVanheer/halflife-updated#9.

[Ronin4862]

The HUD uses sprites where scaling them up causing noticeable blurring issues. It's possible to add, but would require a fair amount of reworking code. It's also out of scope of this project, so it has to wait until the merger project.

Hello, I'm using the enlarged sprites (2x) in the "Better Scaling Hud" over at Gamebanana mentioned in the first post. The picked up ammo, as you know, is split in half in the lower right side of the screen. Can you kindly give me some pointers on where to look in the client.dll project to slightly move the picked-up ammo icons a little to the left? I have the halflife-master.zip SDK. I know it's possible. Check this out: https://twitter.com/Magic_Nipples/status/1290663259159367681 I contacted Magic_Nipples but he wouldn't reply. Thanks!

[SamVanheer]

The ammo history is drawn here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L121-L142

The ammo counter itself is drawn here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammo.cpp#L877-L942

[Ronin4862]

The ammo history is drawn here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L121-L142

The ammo counter itself is drawn here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammo.cpp#L877-L942

Awesome, Thank you!

[Ronin4862]

The HUD uses sprites where scaling them up causing noticeable blurring issues. It's possible to add, but would require a fair amount of reworking code. It's also out of scope of this project, so it has to wait until the merger project.

So, in order to accomodate super high resolutions like 4k or 8k without magnifying the low-res original sprites and making them even blurrier, Valve needs to either ditch the sprites+text files method entirely OR replace the original sprites with higher resolution ones, correct? Are you aware of custom spr files higher than 256x256 for the weapon selection menu and the rest of the HUD elements?

[SamVanheer]

Sprites are subject to the same texture size restrictions as everything else. That's 256x256 by default, and it can be raised to 512x512 at the most if i recall correctly using gl_max_size but only in OpenGL mode.

Valve isn't going to change how the hud is rendered, but modders can choose to implement something else. You could use VGUI1, VGUI2 or even a custom solution that renders using OpenGL directly, but then you'd have to drop Software mode support.

I've considered switching everything over to VGUI2 in the future, but i haven't done enough research on that to know how feasible it is.

[Ronin4862]

The ammo history is drawn here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L121-L142

The ammo counter itself is drawn here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammo.cpp#L877-L942

I managed to solve my issue with your help. Thank you again! One issue remains. The battery, health kit and jump pack overlap the secondary ammo of the mp5 and I can't find a way to move them on the y-axis (they differ from the regular picked-up ammo). Also, is it possible to increase the display time of ALL the picked-up items?

On a side note, I gave up on the original halflife-master.zip in favor of yours. The double sound crowbar swing, the double shell eject on the pistol and mp5, the energy cloud on the gluon gun and the trip mine zoom in after pickup issues have all been solved! Fantastic work! Wow! I noticed a few issues though: Shotgun: if you shoot all the 8 shells, the reload sequence begins but the second shell reload animation is not shown only heard. Gauss gun: the beam splits in two and leaves two hit marks after reflecting from the ground on a nearby wall instead of one beam and one hit mark. These two issues can be easily side-stepped with "cl_lw 0" but that ruins my mouse movement because I play with "m_rawinput 1". I noticed that if I load the game with cl_lw disabled, the mouse stutters. If I then enable cl_lw and immediately disable it the mouse is ok again which is weird. It would be nice if these two issues can be solved with "cl_lw 1" because I noticed a lot of mods react negatively with it disabled and also the gluon gun in Opposing Force if I remember correctly. Sorry for the long post and bringing this here, but since I caught your attention I figured I should ask this also.

[SamVanheer]

One issue remains. The battery, health kit and jump pack overlap the secondary ammo of the mp5 and I can't find a way to move them on the y-axis (they differ from the regular picked-up ammo).

The starting height is defined here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L32

It's hardcoded to a certain sprite size. iHistoryGap is calculated based on certain sprite sizes, but perhaps the item sprites aren't taken into consideration here.

I'll look into the issues you've mentioned.

[Ronin4862]

One issue remains. The battery, health kit and jump pack overlap the secondary ammo of the mp5 and I can't find a way to move them on the y-axis (they differ from the regular picked-up ammo).

The starting height is defined here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L32

It's hardcoded to a certain sprite size. iHistoryGap is calculated based on certain sprite sizes, but perhaps the item sprites aren't taken into consideration here.

I'll look into the issues you've mentioned.

You're a genius my friend! I simply edited it like this:

define AMMO_PICKUP_PICK_HEIGHT (64 + (gHR.iHistoryGap * 2))

and voila:

In my opinion the HUD looks very nice now and is large enough even for 4k on a large TV. One more thing and put this to bed. Is it possible to increase the display time of ALL picked-up items?

[SamVanheer]

The history time defaults to this: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammo.cpp#L260

It initializes a cvar which is then queried to update this variable: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L36

Which is then used to set the display time: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L114

[Ronin4862]

The history time defaults to this: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammo.cpp#L260

It initializes a cvar which is then queried to update this variable: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L36

Which is then used to set the display time: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ammohistory.cpp#L114

Thanks man; solved with a value of 15 in the first two links. Damn, you really know your stuff 😆! If you come up with something for the shotgun and gauss issues, please let me know. In practice, the shotgun one is more distracting than the other because there is a pause after the first shell and before the third one is inserted.

[Ronin4862]

I'll look into the issues you've mentioned.

Is there anything I can do to help?

[Ronin4862]

I'll look into the issues you've mentioned.

Another bug that I found with the gauss gun is if you let it overcharge and then discharge and damage you, the charging sound continues after the charging animation has finished. To stop the charging sound you need to either change the weapon, primary or secondary fire.

So there are 3 in total: 1 with the shotgun (2nd shell reload animation missing), 1 with the gauss (split beam after reflecting from ground with double hit mark) -- these are present ONLY with "cl_lw 1". They don't manifest with "cl_lw 0" 1 with the gauss (overcharging sound persists after discharge) -- independent of "cl_lw"

Probably this should be made a separate thread...

[SamVanheer]

The Gauss sound bug was just fixed in HL Updated and is covered by this issue: https://github.com/ValveSoftware/halflife/issues/3188

The shotgun issue seems to happen only when there's lag, but animations not playing is a known issue with the game's prediction code. The prediction code is pretty glitchy and can't be fully fixed with just what we can change in the SDK. The more lag there is the more common the glitches get.

The Gauss firing twice is a timing issue, again the prediction code has problems there. The server's next attack time takes precedence over the client's, so sometimes the client will predict a shot and then gets told by the server to shoot again. It can't be fixed because the prediction code doesn't compensate for timing issues properly, which is an engine level bug (though more like a missing feature).

[Ronin4862]

The Gauss sound bug was just fixed in HL Updated and is covered by this issue: ValveSoftware/halflife#3188

Awesome. I can confirm this!

The shotgun issue seems to happen only when there's lag, but animations not playing is a known issue with the game's prediction code. The prediction code is pretty glitchy and can't be fully fixed with just what we can change in the SDK. The more lag there is the more common the glitches get.

The Gauss firing twice is a timing issue, again the prediction code has problems there. The server's next attack time takes precedence over the client's, so sometimes the client will predict a shot and then gets told by the server to shoot again. It can't be fixed because the prediction code doesn't compensate for timing issues properly, which is an engine level bug (though more like a missing feature).

So, the logic solution is to use "cl_lw 0". The problem is I get this if I start Half-Life with "cl_lw 0": The mouse cursor is stuck on the screen and the mouse motion is jittery (it stutters when I move the mouse camera). If I type "cl_lw 1" in the console, everything is fine again. I play with "m_rawinput 1" (without it the mouse is even worse). Oddly enough, if I start Blue-Shift (Valve's Steampipe beta) with "cl_lw 0" I don't have this issue at all. Everything is nice and smooth. Can it be something related to "m_mousethread_sleep"? Blue-Shift doesn't have this. Disabling it in Half-Life by removing "-mousethread" from "Launch options" in Steam doesn't fix the problem though... I've attached the Half-Life *.cfg files I use...maybe they can help... configs.zip

[SamVanheer]

Are you running Half-Life or Half-Life Updated?

I can't reproduce this issue in either version, but there are known issues with mouse support because the SDL2 library used to handle mouse input hasn't been updated to include Windows 10 support. The engine also treats official games a bit differently than mods so there could be a problem there.

Valve said they were going to update the SDL2 library but that never ended up happening. I doubt there's anything i can do about it.

I don't know why the mouse cursor would be showing up if you disable weapon prediction. None of the code that deals with cl_lw changes mouse cursor behavior. It's possible that it's actually a side-effect that causes the operating system to display it instead, but it's hard to tell.

If switching to an engine beta fixes it then the problem is likely in the engine, which means i probably can't fix it.

[Ronin4862]

Are you running Half-Life or Half-Life Updated?

I can't reproduce this issue in either version, but there are known issues with mouse support because the SDL2 library used to handle mouse input hasn't been updated to include Windows 10 support. The engine also treats official games a bit differently than mods so there could be a problem there.

Valve said they were going to update the SDL2 library but that never ended up happening. I doubt there's anything i can do about it.

I don't know why the mouse cursor would be showing up if you disable weapon prediction. None of the code that deals with cl_lw changes mouse cursor behavior. It's possible that it's actually a side-effect that causes the operating system to display it instead, but it's hard to tell.

If switching to an engine beta fixes it then the problem is likely in the engine, which means i probably can't fix it.

Half-Life Updated. I've just built client.dll and hl.dll from the SDK you've just updated yesterday with the gauss sound fix. Have you tried my autoexec.cfg and config.cfg from the previous post? Also, my Steam "Launch options" are: -nofbo -mousethread

Just start the "Hazard Course". You should see the mouse cursor in the middle of the screen and choppy mouse movement. Then type "cl_lw 1" in the console and everything should be great again. Thanks!

[SamVanheer]

I ran the game with your configs and launch options. The bug doesn't occur here.

The engine is responsible for showing and hiding the mouse cursor so if it's not working then it's probably a bug in there somewhere.

Does this also happen with Steam Half-Life or only Updated?

[Ronin4862]

With the default dlls the mouse is not stuck on the screen but the mouse movement is extremely slow (like sensitivity is set to 0.1 or something). In both cases (your dlls and valve's) if I type "cl_lw 1" everything is great. What's even more weird is if I then type "cl_lw 0" the mouse glitch does not re-appear. The same is true if I load a game. Everything works after that. It all has to do with the first time I load the game engine. Hmmm...there's one thing I didn't consider and I'll check when I get home. I play the game with RivaTuner's Scanline Sync (vsync off with one tear line) although I ran Blue-Shift (steampipe beta) with the same settings and I didn't have this issue.

[SamVanheer]

The original games all have different mouse behavior that causes the slowdown. This SDK has a workaround that alters mouse movement speed.

It's possible that some external program is interfering but there's no way to be certain without analyzing every change made to cursors which you might be able to do with one of Microsoft's tools, but i've never done that before.

[Ronin4862]

Don't worry, it's not a big deal after all. I've set my config.cfg to "read only". In it I've put "cl_lw 1" and binded "PageDown" to "cl_lw 0". This way, whenever I start a game I press the PageDown button once and cl_lw will stay off until I exit the game. I see you are very commited to Half-Life. Blue-Shift Updated has the same treatment as Half-Life Updated! Very nice ! Don't forget to update the gauss sound fix to that package also. Unfortunately Opposing Force was a no go: https://github.com/SamVanheer/halflife-op4-updated

First of all, the solution contains a hl.dll instead of opfor.dll I've built the solution successfully in VS 2019 then renamed to opfor.dll but the game crashes instantly when launching either "Boot Camp" or a new game. I even tried installing V1.0.0 beta 004 via InstallOp4.ps1 script method. I can see Opposing Force Updated in Steam, launch it, but again crashes with the client.dll and hl.dll files provided whenever I try to start a game. If I delete the client.dll it reverts to the gearbox folder and everything works but it also reverts to the Steampipe version of Opposing Force. What's going on?

[SamVanheer]

There's a bug related to the work being done to get the CTF gamemode working. I'll fix that just as soon as i'm done fixing the remaining weapon bugs in HL itself.

You shouldn't be renaming the dlls. These projects are not replacements for the original games and are not compatible with those installations. You can only run them as mods. I'm going to add links to the About page that explains this when i'm done fixing stuff.

[Ronin4862]

Well, I don't think there are any notable weapon bugs left. You did a pretty good job :)

[SamVanheer]

I've fixed the crashing issue. I've also merged all changes into the Blue Shift project.

[Ronin4862]

I've fixed the crashing issue. I've also merged all changes into the Blue Shift project.

Awesome job Sam! Everything is working properly! Probably you are aware of this (is in the vanilla Opposing Force as well). 3 grey rectangles appear on the shockrifle after firing.

[SamVanheer]

I can't reproduce that issue. I suggest checking your OpenGL settings to see if anything is misconfigured.

[Ronin4862]

Try positioning yourself like I did. I found out that it's scene dependent. You don't need to shoot the weapon either. Start "Boot Camp", go to the corridor on your right, turn left and head to the area with the tables and suspended clock on the left wall. Look up like I did and move the mouse slowly.

[SamVanheer]

I'm still unable to reproduce the issue. I walked around with the Shock Rifle equipped and it never did that.

[SamVanheer]

I fixed a couple bugs with how the mouse input code deals with raw input. One of those bugs involved cl_lw. Can you test again to see if your problem still occurs?

[Ronin4862]

I fixed a couple bugs with how the mouse input code deals with raw input. One of those bugs involved cl_lw. Can you test again to see if your problem still occurs?

Hello Sam, Yes, the initial mouse stutter when a game is first loaded with "cl_lw 0" is now gone! The stuck mouse in the middle of the screen is also gone now. Unfortunatelly, the game crashes instantly when I fire the following weapons:

1. 9mm handgun
2. 357
3. MP5
4. Shotgun
5. Gauss

So, if I start the game engine with "cl_lw 0", to prevent the crashing, I need to "cl_lw 1" and then back to "cl_lw 0" and everything is fine.

[SamVanheer]

That should be fixed now.

[Ronin4862]

That should be fixed now.

You the man Sam, wow! If you don't mind my asking, what exactly did you change (in both fixes)? You're a genius all right, but some of us here are trying to learn from you aswell :))

[SamVanheer]

For the crash you experienced firing weapons i moved the code to initialize the weapon prediction globals: https://github.com/SamVanheer/halflife-updated/commit/0dde83b620a94f8aadb73e38e180cbf4363e6b57

I previously changed some client code so the client and server codebases can be used together, which changed how some code accesses cvars. CVAR_GET_FLOAT now goes through g_engfuncs (server interface) instead of gEngfuncs (client interface). If weapon prediction is disabled then that global isn't initialized so when the client event code tries to check for r_decals it tries to dereference a null pointer and crashes: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ev_hldm.cpp#L273

For the mouse pointer issues i first changed how the mouse input code checks the current time: https://github.com/SamVanheer/halflife-updated/commit/dc30c4b8a2ebcfe6fbaf4de3ca3c08d92a118315

gpGlobals is also part of the server interface. Valve put that there to keep the amount of cvar queries down but used the wrong API to do it, so when weapon prediction is disabled gpGlobals->time is always 0. Changing m_rawinput would only affect the engine and not client code. The difference in behavior between the two was likely causing the engine to set the cursor as visible all the time.

I then reworked how m_rawinput is checked to get the cvar value directly all the time without making an expensive query call: https://github.com/SamVanheer/halflife-updated/commit/fb040c5fe2c74bde7bbb2c51c3335f2dc4fd8a84

This eliminates the need to keep track of time altogether and simplifies the logic some more. This fixes a bug where the value of m_rawinput isn't cached by client code in some cases which could also cause the cursor bug.

I did make a mistake in how i updated some of the code so i had to back and fix this: https://github.com/SamVanheer/halflife-updated/commit/db182c66b63795918fd1fb8003d74af85e5229b9

I reported the raw input issues on the Half-Life issue tracker: https://github.com/ValveSoftware/halflife/issues/3254 https://github.com/ValveSoftware/halflife/issues/3255

These issues contain more information about the problems. I didn't report the other issue because it doesn't affect vanilla code.

[Ronin4862]

I previously changed some client code so the client and server codebases can be used together, which changed how some code accesses cvars. CVAR_GET_FLOAT now goes through g_engfuncs (server interface) instead of gEngfuncs (client interface). If weapon prediction is disabled then that global isn't initialized so when the client event code tries to check for r_decals it tries to dereference a null pointer and crashes: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/ev_hldm.cpp#L273

So basically the game crashed not when I fired those weapons but when the engine looked for decals made by those weapons. That's why all the other weapons that don't leave decals upon direct fire didn't crash the game engine.

I then reworked how m_rawinput is checked to get the cvar value directly all the time without making an expensive query call: https://github.com/SamVanheer/halflife-updated/commit/fb040c5fe2c74bde7bbb2c51c3335f2dc4fd8a84

Isn't _m_mousethreadsleep somewhat redundant? I know it sets the mouse polling rate but m_rawinput 1 does the same thing as it reads it directly from the mouse itself.

On another note; I always wondered why there's no gauss idle animation. I looked up gauss.cpp and found that if you comment out this line, Gordon will spin the particle accelerator chamber of the gun which is very very nice. Probably the coolest idle animation. I know it's only intended for Half-Life and not BS and OF, but did you ignore it on purpose?

https://github.com/SamVanheer/halflife-updated/blob/db182c66b63795918fd1fb8003d74af85e5229b9/dlls/gauss.cpp#L566

[SamVanheer]

The mouse thread code predates raw input by a decade and a half. It's there to provide the original behavior.

I didn't want to change any idle animations to maintain the original behavior. The idea is that you can make mods that behave like the Steam version does, and then modify it as you see fit.

[Ronin4862]

The mouse thread code predates raw input by a decade and a half. It's there to provide the original behavior.

Is there any benefit in using both m_rawinput and -mousethread at the same time?

I didn't want to change any idle animations to maintain the original behavior. The idea is that you can make mods that behave like the Steam version does, and then modify it as you see fit.

About mods. It such a shame that your modifications to the source code cannot be used to all mods. There are two types:

1. Mods that do not provide their own dlls thus revert to client.dll and hl.dll from the valve folder. This is the fortunate scenario as they can benefit from everything you've changed so far. AND
2. More "sophisticated" mods (i.e. Reissues, Echoes, Decay for PC, etc) that come with their own game dlls (spirit.dll, echoes.dll, decay.dll and so on). Deleting these and directing the mod to use client.dll and hl.dll from the valve folder either breaks the game logic or the mod entirely. Is there a workaround for this? Can we make these mods benefit from all the work done here without the chore of finding each mod's SDK and implementing every modification done so far to the Half-Life SDK, one by one, for each and every mod?

[SamVanheer]

Is there any benefit in using both m_rawinput and -mousethread at the same time?

No, raw input doesn't use threaded mouse input data. You'd just be wasting CPU time and system resources on a thread and system calls.

Mods that do not provide their own dlls thus revert to client.dll and hl.dll from the valve folder. This is the fortunate scenario as they can benefit from everything you've changed so far.

You can use fallback_dir to make one mod depend on another. You can also copy paste the HL Updated dlls in the mod directory and set up liblist.gam to use them.

Is there a workaround for this?

No. Mods don't work that way, you'd need to merge the changes into the mod's code for it to benefit from everything that's been done.

The Unified SDK is supposed to be merger of a bunch of stuff, so it's possible that (with some modifications) existing maps can be made to run under it. I doubt it'll be that easy though.

[Ronin4862]

The Unified SDK is supposed to be merger of a bunch of stuff, so it's possible that (with some modifications) existing maps can be made to run under it. I doubt it'll be that easy though.

So, as a starting point, this Unified SDK will offer the same improvements to all three games (HL, BS, OP) frome the same client.dll and hl.dll? Sounds cool but I doubt a mod like Reissues would be compatible. Delete its spirit.dll or point its liblist.gam to use hl.dll from /dlls/valve folder and the intro will not even run.

Excuse my chaotic manner but there's something I would like to ask. I wanted to increase the lifetime of the ejected shells to increase realism but ran into a problem:

https://github.com/SamVanheer/halflife-updated/blob/7d849068617d200c779ae4186db25838acdb2cfe/cl_dll/ev_common.cpp#L140

I modified 2.5 to 99. Everything is ok except when a shell lands on an incline or, for the lack of a better word, wants to keep falling, it loops its "soundtype" until 99 seconds expire which is very annoying. If the shell falls on a level ground it "sounds" until the shell stops moving, which is about a second and everything is fine. Think of it as when you threw a grenade into a tight spot and the grenade made a jittering sound until it exploded. This wasn't an issues as it soon exploded or in the case of the shells, they disappeared anyway after 2.5 seconds. Any ideas?

[SamVanheer]

Sounds cool but I doubt a mod like Reissues would be compatible. Delete its spirit.dll or point its liblist.gam to use hl.dll from /dlls/valve folder and the intro will not even run.

Spirit has a ton of stuff that's not in these projects, so of course mods made with that won't work.

Any ideas?

The code to play those sounds is here: https://github.com/SamVanheer/halflife-updated/blob/db182c66b63795918fd1fb8003d74af85e5229b9/cl_dll/entity.cpp#L655

So you could modify the logic to handle inclines a bit better.

[Ronin4862]

The code to play those sounds is here: https://github.com/SamVanheer/halflife-updated/blob/db182c66b63795918fd1fb8003d74af85e5229b9/cl_dll/entity.cpp#L655

So you could modify the logic to handle inclines a bit better.

I've modified this https://github.com/SamVanheer/halflife-updated/blob/db182c66b63795918fd1fb8003d74af85e5229b9/cl_dll/entity.cpp#L630-L656 to look like this:

            if (traceFraction != 1) // Decent collision now, and damping works
            {
                float proj, damp;

                // Place at contact point
                VectorMA(pTemp->entity.prevstate.origin, traceFraction * frametime, pTemp->entity.baseline.origin, pTemp->entity.origin);
                // Damp velocity
                damp = pTemp->bounceFactor;
                if ((pTemp->flags & (FTENT_GRAVITY | FTENT_SLOWGRAVITY)) != 0)
                {
                    damp *= 0.5;
                    if (traceNormal[2] > 0.9) // Hit floor?
                    {
                        if ((pTemp->hitSound) != 0)
                        {
                            Callback_TempEntPlaySound(pTemp, damp);
                        }
                        if (pTemp->entity.baseline.origin[2] <= 0 && pTemp->entity.baseline.origin[2] >= gravity * 3)
                        {
                            damp = 0; // Stop
                            pTemp->flags &= ~(FTENT_ROTATE | FTENT_GRAVITY | FTENT_SLOWGRAVITY | FTENT_COLLIDEWORLD | FTENT_SMOKETRAIL);
                            pTemp->entity.angles[0] = 0;
                            pTemp->entity.angles[2] = 0;
                        }
                    }
                }

Now, whenever a shell lands on an incline, it will be considered as still falling (still in the air) and will not play its "hit the floor sound", thus avoiding the annoying sound loop.

[Ronin4862]

The Unified SDK is supposed to be merger of a bunch of stuff, so it's possible that (with some modifications) existing maps can be made to run under it. I doubt it'll be that easy though.

Hello Sam! I noticed something interesting while playing HL mods that come with their own game dll (decay.dll, spirit.dll, echoes.dll, rl.dll. etc). Most of the improvements and fixes you did for Half-Life Updated can be brought to these mods if you force them to use client.dll from Half-Life Updated instead of their own client.dll. Unfortunatelly the HUD and weapon selection menu is not visible in any mod and you can't switch between weapons. If I use the vanilla client.dll from default Half-LIfe the HUD and weapons menu are all available. I believe that if this issue can be fixed then ALMOST EVERY mod out there will be compatible with most of the improvements you brought to Half-Life. Yes, you will lose the custom color of the HUD the mappers did for their mods as it will be reverted to the default orange one but this is a very small price to pay in comparison to all the fixes done here.

[SamVanheer]

Most of the fixes are actually server side so you won't get them. The dlls aren't compatible so if there are any problems i can't help with them.

[Ronin4862]

But why if I use the default client.dll from Half-Life with any mod I can see the HUD but not with the client.dll from Unified?

[SamVanheer]

Probably because of changes to the networking code that changed how some flags and stuff get sent to the client. I changed how the game tracks whether you have the HEV suit equipped as part of the 64 weapons support feature, so using incompatible server dlls means that data never gets received by the client.

This is what i mean when i say the dlls are compatible.

[Ronin4862]

Ok. I understand. And I meant Updated not Unfied, as in this: https://github.com/SamVanheer/halflife-updated Sorry

[Ronin4862]

Hello Sam, I noticed some minor bugs while playing Half-Life:

1. In the tram ride if you move around a lot the tram will get stuck and stop moving.
2. If you shoot a rat it will loop its death sequence indefinitelly
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.
4. In multiplayer, the gluon gun doesn't have an energy cloud

[OpenRift412]

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

That's a pretty well known bug if I recall.

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

That was always like that, I think, even in the original CD release.

[Ronin4862]

Hello Sam,

Did you get the chance to take a look at the bugs I mentioned?