search

ValveSoftware / halflife

Half-Life 1 engine based games
Other
3.72k stars 625 forks source link

25th anniversary Makefiles don't build #3804

Open SamVanheer opened 2 months ago

SamVanheer commented 2 months ago

Trying to build the 25th anniversary versions of the Makefiles fails due to a couple of problems:

This was tested with a freshly cloned copy of the latest commit in Ubuntu 22.04 64 bit.

JoelTroch commented 2 months ago

Makefile.hl_cdll references a non-existent file called common/validator.cpp (line 117). Is this file missing or should it be removed from the Makefile?

Worth mentioning this file is not present on Visual Studio projects (both VS2010 and VS2019).

SmileyAG commented 2 months ago

common/validator.cpp has been used to build the client module since at least from the steam_legacy version of Half-Life, so this file was clearly forgotten to be included in the HLSDK.

But at first glance it looks like it contains nothing but the placeholder function (void ValidatorStub()) and the pointer to it (pfnValidatorStub). Of course, it is always possible that its logic can only be compiled for binaries from platforms like _WIN32, but I doubt that this is the case here. No references from other functions to it as well.

validatorstub

Here is the version of the compiler that is listed in the .comment section from the official binaries of latest version of Half-Life:

String dump of section '.comment':
  [     0]  GCC: (SteamRT 5.4.0-7.really.6+steamrt1.2+srt2) 5.4.1 20160803
SamVanheer commented 2 months ago

The first two problems should be fixed when following the instructions added to the readme:

Linux binaries are built using Makefiles found in the linux folder, and are expected to be built / run in the Steam Runtime "scout" environment. You will need to set the environment variables VALVE_NO_AUTO_P4=1 and USE_STEAM_RUNTIME=1 while building.

Though i question why the Makefile doesn't default to the correct behavior. This is probably because the files were taken directly from the internal versions but for mods this will cause problems.

shawns-valve commented 2 months ago

I tried to clean some of this up, though my Linux knowledge is limited, so I may have missed some things.

FWIW, if anyone in the community has improved makefiles and wants to submit a pull request, I'll take a look at it; the current files were really made for our internal build environment and just slightly tweaked to get them working for the SDK.

APGRoboCop commented 2 months ago

I've used Linux Makefiles for over 12 years, even though I also had to learn to use CMake as well as AlliedMod's AMBuild.

SamVanheer commented 2 months ago

I built the SDK with the latest changes and it's pretty straightforward now, though i suspect beginners will get tripped up on the chmod error messages with CREATE_OUTPUT_DIRS=1 because it looks like something went wrong when it still works as intended.

Building in a container isn't the easiest thing to do when you've never done anything like that before, but simply removing the version number from the compiler name uses the currently installed version which is enough to build it without a container.

People will probably use community-maintained SDKs even now so i doubt it will come up often.

I'll also point out that people have tried to use community-created updated dlls as replacements for the original game dlls which can get them VAC banned. Using the original game directory names in the output paths might give people the idea that this is something they can do. While it doesn't look like VAC is actually banning people for this right now i'm concerned it might change later on and get them banned.

I implemented a check in halflife-updated that shuts the game down when the dlls are used to replace any of Valve's game dlls, but that can easily be disabled by changing the source code.

I don't know if this is an issue that needs addressing here but i'll mention it just in case.

APGRoboCop commented 2 months ago

Well...I've not been using the HLSDK 25th Anniv apart for RCBot, but I think using those headers seems pointless. Also, I do get worried or concerned if I recompiled the cl_dlls for DMQ2 with HLSDK 25th if it will trigger VAC ban false positives... But with the new DMQ2 as well as the DMC Pro versions recompiled for the server /dlls seems fine. And I've had no reports of VAC bans so far.

https://apg-clan.org/vbdownloads.php?do=download&downloadid=1331

I also did the same for VadaVaka's Ricochet Community Patch, but didn't use HLSDK 25th.

0Ky commented 2 months ago

@SamVanheer The issue of players replacing the original game's client dll is already being tracked in issue #1210.

Unfortunately, I don't think VAC flags modification or replacement of the game's client dll for Half-Life. I've contacted Valve support not long ago regarding this issue and they were unable to confirm or deny for obvious reasons related to protecting the integrity of their anti-cheat system. Although, with certainty I can say that players have been exploiting this for well over a decade or two without any reports of VAC bans. They either use outdated versions of the game's client dll to exploit bugs patched in newer versions or use open-source projects like BugfixedHL, BugfixedHL-Rebased, Adrenaline Gamer and OpenAG to enhance the gameplay and provide features not capable with the original game client, such as automated bunny-hopping, perfect frame duck tapping, reintroducing patched bugs like _special, force-replacing player models in-game and programming custom automations directly into the official game by replacing its client dll rather than using it as a mod.

tschumann commented 1 month ago

I've pushed https://github.com/ValveSoftware/halflife/pull/3848 as a fix - looks like after https://github.com/ValveSoftware/halflife/pull/3807 it was fine, it just needed gcc to be called gcc/g++. Tested with gcc 9.4.0