Halflife: SV_ClipToLinks engine bug

[Stenudd]

Text original by theAsmodai, made some changes

When gamedll returns false in pfnShouldCollide (entities shouldn't collide), engine ignores collisions with all subsequent entities. This can lead to bugs in physics. The bug occurs because of a premature return from SV_ClipToLinks

    if (!gNewDLLFunctions.pfnShouldCollide(touch, clip->passedict))
        return;

It would be correct to continue the loop instead of return

Wasn't sure if this was ever fixed in the engine

[ghost]

Where's that code snippet from?

[Stenudd]

The earliest reference of this bug I found is from:
https://github.com/Rhoin/Xash3D-CrossPlatform-Port/blob/master/engine/server/sv_world.c#L1141

[Solokiller]

This bug was also fixed in SC, so the logic behind it makes sense. It's probably from Xash's source, it's very similar to the actual engine source code.

[ghost]

Someone better send the fix to people who have access to the engine code then :)

This repo is for the server/client code only........ and there isn't one for the engine.

[Solokiller]

You have to consider the possibility that fixing it might cause other bugs to appear. In a codebase so old, and with so many mods, there's no way to predict that.

[Stenudd]

@johnstt What makes you think its only for server / client? "Half-Life 1 engine based games"
"This is the README for the Half-Life 1 engine and its associated games."

No where it says this is for any client or server, even though this is the SDK for modders, I still believe this is the right place to report bugs in the engine as well. It have been done multiple times before, and those have been fixed by @alfred-valve, see for example https://github.com/ValveSoftware/halflife/issues/1200

And why are you referring your own issue which is completely irrelevant to this?

@SamVanheer This fix have been tested for both a very long time and by a lot of people for many mods. The effect is clear, easy to reproduce, its an easy fix which is also easy to test, which have also already been done by many people. I see no way this would interfere with anything actually. But correct me if I'm wrong.

[ghost]

What makes you think its only for server / client?

The fact that the code on this repo is only for the client and server?
The fact that the engine code isn't public?

I repeat: the Half-Life engine code is not open sourced or publicly available anywhere. The closest thing would be xash3d, which is not the engine code people run when they download Half-Life on Steam and play my mod. (My mod which uses the client/server SDK code from this repo!)

It's not hard to email Alfred or really anyone at Valve if you want to contribute a fix to the engine.

"Half-Life 1 engine based games"

If you want to play dumb and go by the name alone, the next step is to ask why the Counter-Strike source code isn't provided here.

And why are you referring your own issue which is completely irrelevant to this?

Because people from the rehlds/xash3d communities keep posting about their questionable source code on here and I'm discussing it in that thread.

I see no way this would interfere with anything actually. But correct me if I'm wrong.

How could I correct you when I don't have the engine code at my disposal?
Valve isn't responsible for xash3d, and I will not ask my players to use it since that's like stealing Half-Life.

[Stenudd]

for the Half-Life 1 engine and its associated games.

It still seems that they use this repo for issue tracking the engine as well, closing issues and milestone them, why does it matter if the repo includes the CODE or not? I'm aware what xash/rehlds is quite well..

I think opening an issue here or email them is having the same effect, since they probably have an internal issue tracker also. It ends up in their inbox any way.

Still has no relevance for this issue, and are you calling me "rehlds people"? Who said anything about that your players should use xash3d? I don't make my mod to only work on xash3d/rehlds either, thats stupid, I see no point in running them, my mod should work on original engine, its even possible to fix this issue by monkey patching it in RAM. Which have been done by the AMXX community. But it would be excellent if the Valve team could fix this and include it in a future milestone.

[ghost]

Okay, let's change the subject for a moment since I don't want to play forum posting with you for the next 2 weeks.

Do you think Valve could take the Half-Life developer community seriously when most of the active projects seem to be pirating/reversing closed source products sold on Steam?

Has anyone ever wondered why this repo has been abandoned? Could it be the multitude of threads asking for help building cheats or making abusive Counter-Strike server mods? Or maybe all the threads about competing products that miraculously haven't been told to cease and desist?

If you really care about improving the engine, ask Valve to open source it and work with the community to distribute patches. What makes you think that posting "I found a bug in this ripoff of your engine, and it might be in the real engine too!" is a good idea?

[Stenudd]

Do you think they abandoned HL1 because what people ask for here? I think they are more actively developing the newer HL2 and hopefully soon HL3 engine instead, fixing HL1 is not Valve highest priority. Has nothing to do with what some people are doing to the mod. And why would you think Valve would ever open source the engine? Would be awesome though.

I care about improving the engine, that's why I post the issue and the fix here. I never said I found a bug in some ripoff engine, I simply linked a source about when the bug was first discovered (at least known to google). If you run a disassembler on your own original engine, and understand assembly, you will see it contains the exact same issue, with the exact same fix. The bug have been long knowned by those people, but it never reached Valve since no one have reported it to them.

[Solokiller]

Maybe everybody that's still doing GoldSource modding should band together and ask Valve to open source the engine. With a bit of luck (and provided there are no legal issues standing in the way) it might actually happen.

[JoelTroch]

@Stenudd : Just for your information, some people are still waiting for updates by Valve in the Source SDK Base 2013 repository, I think they moved on to Steam, SteamOS, SteamVR, Source 2. Thanks for sharing the fix by the way.

@SamVanheer : This is something I doubt Valve would do, maybe as long as people still buy copies of Gold Source games, they won't do it. Or they will give the full source code to people that deserves it like you with Sven-Coop because it (re)defined Half-Life cooperative for more than 10 years and Team Psyskallar with Cry of Fear (because it has been Greenlit).

[ghost]

It's been more than 10 years since the Quake 3 code was open sourced. In fact, if you look here it's a pretty good example of how to release all the code for your games. The sky didn't fall as a result of this.

People still buy Quake 3 - in fact it's still sold on Steam for a whopping $22 CAD. Imagine if there was something like ioquake3 but for the Half-Life client, engine and server code. Wouldn't that be better than throwing our hands in the air and saying "well, I guess I just can't have good netcode in my game" ?

Quakeworld in particular has benefitted tremendously from the open source code released by id. The client, server, mods and, well, everything about the game is still being maintained. But you still need to buy Quake and have the .pak files containing art assets in order to play legally. Everyone wins: hobbyist developers get to improve the game, players get a better game to play, publishing companies get to keep making money on 20 year old abandoned products.

Here's a funny recent anecdote: I wanted to change something about messagemode/messagemode2, but I can't because it's on the wrong side of the arbitrary line between the open and closed code.

[Solokiller]

You're completely right, but good luck convincing Valve.

Regarding messagemode, Natural Selection implemented their own version and replaced the commands. The engine's commands are simply not used. See here for how they implemented it: https://github.com/unknownworlds/NS/blob/master/main/source/cl_dll/vgui_TeamFortressViewport.cpp#L2380

[JoelTroch]

@johnstt : With further thinking, I'm starting to doubt if releasing the whole Gold Source code would be a benefit for the community , here are my arguments :

• Some players are still using the WON version (and/or projects like WON2), they will likely change the whole source code to look similar to Half-Life 1.1.1.0, this means implementing the old menus, the crowbar damage fix and remove everything Steam related like the bunnyhop cap, detail textures...
• On the opposite side, we have the ones that are happy with everything Steam added (even the bugs), those ones will likely fix all the bugs/exploits and that's all. Furthermore, even if there are some bits of Steam code in this repository, I doubt Valve would give access to the whole Steamworks source code (achievements, server browser...) so we would end up with a Half-Life Steam version but stripped from Steam (quite similar to a Non-Steam version)
• We also have the guys that "engine is only what matters". Let me get this clear : yes, one of the mods I'm working on has an updated PARANOIA renderer with SSAO (Screen Space Ambient Occlusion), GLSL (OpenGL Shading Language) shaders, particle systems (from Trinity engine) and insert other fancy good looking stuff here. But A) we still have limits that we can't bypass and B) you can insert whatever good/fancy pleases in Gold Source, it will NEVER match a game/mod that is running Source (even the 2004 version), Unreal Engine 3/4 or CryENGINE. What I wanted to say is that some people are going to start implementing OpenGL 3/4, DirectX 11/12, NVIDIA PhysX, SpeedTree and/or insert technology name here to have a mod like Sikkmod (id Tech 4 - DOOM 3).
• And the most important reason of all is "mod support", this repository don't work on Xash3D, you have to fallback to the standard 2.3 SDK or use their SDK, I'm not saying that their project is bad. I'm just saying that now modders have to support either the standard Gold Source or Xash3D. If they want to support both, programmers have to deal with 2 source codes. So imagine if everybody start working on it's fork, we will end up with 10/20/30 different forks that modders will have to support (unless the fork's author has a clever "mod compatibility system").

And I think this is why ioquake3 can easily do their job of updating id Tech 3 and Quake III Arena as well, because according to this changelog, there wasn't major gameplay changes between patches and nobody was like "Oh, I don't like that change, I'm gonna downgrade". Something which deserves a note, ioquake3 has a "Design decisions" page on it's wiki describing what is it's main purpose and a not TODO page.

Of course, if the whole Gold Source community agrees to develop a single fork or update the base engine (this will involve a lot of planning and managing stuff), everything I said above about the problems won't apply and we could do the same as ioquake3 but for Gold Source.

[ghost]

That all makes sense. The best way is to have "the community" (HL modders, Xash developers, rehlds developers etc) come together and work on one project. This could be the version of Half-Life that gets shipped on Steam. In fact, this is what happened before this repository was abandoned: fixes from the community were applied to the 2013-era Half-Life updates on Steam.

People are already split between different versions as you say (Steam HL, Xash etc) but at least we could have 'the main one' benefitting from the people who want to develop it. The other projects could go on as forks too, but Steam can still be the way that players get access to the stable version.

[Solokiller]

If anybody's interested we could always submit a formal request as a group to Valve to provide access to the engine for community based engine upgrades.

[tschumann]

How would we go about that?
Definitely a good idea though as at least a couple of bugs have been pointed out here.

[Solokiller]

I would make our case as a single group so Valve can see that it's not just one or two persons asking for it. The more people are involved, the more likely it is that Valve would grant access.

I know from experience that several engine issues can be solved easily if access to its source is provided. The only reason that Valve isn't fixing them, aside from it being an old engine, is that it would risk breaking mods. If a community driven upgrade were provided, mod authors could choose to use that engine instead, without having to deal with the risks involved with updating the main engine version.

It would also be possible to provide certain features that have been limited to Valve games in the past, like VGUI2 and the GameUI dll to all mods. There is much potential there, limited only by access to the engine.

[ghost]

I would be willing to throw my name into the pile and help explain how community access can be valuable. Is there a good site for creating a petition? Or maybe we can just email someone and point at a thread on here..

[Solokiller]

Valve's website has an email address listed for the SDK: [email protected]

That's probably the best way to get in contact with them.

[Stenudd]

Sign me up as well!

But can we please stop using this thread for discussing everything that has nothing to do with the bug itself, it doesn't help valve to fix the bug reports if they are filled up with irrelevant information.

Start a new issue where you can discuss that, and give me a link to it :)

[CecilHarvey]

I confirm this bug still exist in the latest version of GoldSrc. See attached picture

[mikela-valve]

Hi all, this should be fixed in the current HL1/OpFor/TFC/CS betas.

[mikela-valve]

Closing this as fixed.