Half-Life - In 4 easy steps

K

kpedersen

Hi all,

If you are a fan of Half-Life, you can now easily play this on FreeBSD. I have forked a number of projects in an attempt to make things easier to get up and running without relying on a port (which due to licensing is unlikely to be an option for binary distribution).

The following commands should fetch, build and run Half-Life. You may need to tweak the PYTHON environment variable to match the version installed.

Code: 
# pkg install xorg git sdl2 mono cmake pkgconf
$ git clone https://github.com/osen/openhl.git
$ PYTHON=python3.7 sh build.sh
$ export/bin/hl

It will take about 10-15 mins to build. The "export" folder is portable, so feel free to move this to /opt or anywhere else once it has built.

Some screenshots:

hlss1.png
hlss2.png
hlss3.png


Note: All the game data is included in the repo so you don't need to manually fetch anything from Valve's DRM system or Wine. The data was legitimately shared by Valve on mirrors like File Planet / AusGamers so is completely redistributable. The build script simply extracts it using tools from Valve's developer wiki. No piracy (or METIN2) involved.

There are some minor issues. Many I am fixing as I encounter them in my playthrough (I will finally complete this game!). Perhaps the biggest I have found so far is that the video GUI menu is quite broken. Changing the video.cfg is a temporary workaround.
 
How accurate is Xash3D? I wonder if there is any kind of systemic approach to verifying game reimplementation accuracy in general.

kpedersen said:
Note: All the game data is included in the repo so you don't need to manually fetch anything from Valve's DRM system or Wine. The data was legitimately shared by Valve on mirrors like File Planet / AusGamers so is completely redistributable.
Click to expand...
Ah, no, that alone doesn't make the data redistributable (by third parties). That should be explicitly stated somewhere. Not that I care, just a warning.

kpedersen said:
(I will finally complete this game!)
Click to expand...
Heh. I'm pretty sure I've seen all chapters, but not necessary in a proper playthrough (due to bugs and engine crashes). I'm not going for a yet another playthrough, since I'm already thoroughly sick of the game. Been for years.
 
shkhln said:
How accurate is Xash3D? I wonder if there is any kind of systemic approach to verifying game reimplementation accuracy in general.
Click to expand...
It has its quirks. For example holding down fire on the colt until you are out of bullets causes a strange flicker rather than reload. However so far it is looking very completable.

As for the code, I do recognise bits from Quake 2 primarily but I don't believe there is any from GoldSrc (or the leak). There is much more C in xash3d than those (they had a strange subset of C++). I do spot some bits from GtkRadiant however. Unfortunately, because I hate that codebase! Just following the basic image resource loading took me down a rats nest. Xash3D was no different with a recent fix I made. I can't quite get an exact statement on where all the code comes from. Bits and pieces stiched together (impressive though because it is a fairly big project).

shkhln said:
Ah, no, that alone doesn't make the data redistributable (by third parties). That should be explicitly stated somewhere. Not that I care, just a warning.
Click to expand...
Interesting. Is there a reason why File Planet or a random ftp such as this can redistribute it and not me / GitHub? If I recall at lan events, i.e i21 back then we were handed disks with these files on and it was shared on usb sticks too. It is to populate the Steam cache for those with weak internet back in the early 2000's. Valve were more than happy to share it to get people hooked. A quick scan through the legal text on the installer also doesn't exclude redistribution either.

This is partially an experiment to see if a DMCA takedown will happen. Its not like they can turn around and ask us all for the disks back and to delete the files.

I happen to just be mirroring on my GitHub, quite innocently, that steam cache from 2003, a personal 3D engine fork called xash3d and the public Half-Life SDKs for people to read through. As I said before, all these are mirrored separately by other people, so why can't I just happen to mirror them all in one place... right... ehem ;)

shkhln said:
Heh. I'm pretty sure I've seen all chapters, but not necessary in a proper playthrough (due to bugs and engine crashes). I'm not going for a yet another playthrough, since I'm already thoroughly sick of the game. Been for years.
Click to expand...
I stopped playing pretty much as soon as Steam came into the picture. Oddly enough, not necessarily just because of the DRM but because I started to find it more fun to reverse engineer Steam and its various protections rather than actually play the games. For that reason I never really spent much time with Half-Life 2. (Until the code got leaked. But then it became more of a porting challenge rather than playing the game haha.)
 
kpedersen said:
Interesting. Is there a reason why File Planet or a random ftp such as this can redistribute it and not me / GitHub? If I recall at lan events, i.e i21 back then we were handed disks with these files on and it was shared on usb sticks too. It is to populate the Steam cache for those with weak internet back in the early 2000's. Valve were more than happy to share it to get people hooked. A quick scan through the legal text on the installer also doesn't exclude redistribution either.
Click to expand...

Maybe they don't care as well. The current EULA says:
G. Restrictions on Use of Content and Services

You may not use the Content and Services for any purpose other than the permitted access to Steam and your Subscriptions, and to make personal, non-commercial use of your Subscriptions, except as otherwise permitted by this Agreement or applicable Subscription Terms. Except as otherwise permitted under this Agreement (including any Subscription Terms or Rules of Use), or under applicable law notwithstanding these restrictions, you may not, in whole or in part, copy, photocopy, reproduce, publish, distribute, translate, reverse engineer, derive source code from, modify, disassemble, decompile, create derivative works based on, or remove any proprietary notices or labels from the Content and Services or any software accessed via Steam without the prior consent, in writing, of Valve.
Click to expand...
(I have no idea what 2004 EULA permitted.)

This is sufficiently wide to cover all the bases.

kpedersen said:
Oddly enough, not necessarily just because of the DRM but because I started to find it more fun to reverse engineer Steam and its various protections rather than actually play the games.
Click to expand...
Makes sense to me :)
 
shkhln said:
Maybe they don't care as well.
Click to expand...
Likely this is the case. Especially for the communities that might be sharing these files are not exactly large (FreeBSD forums and r/openbsd_gaming) ;)

shkhln said:
The current EULA says:

(I have no idea what 2004 EULA permitted.)
Click to expand...
It didn't have this following section (which is why I am quite keen to support this older version of the data):
you may not, in whole or in part, copy, photocopy, reproduce, publish, distribute, translate
Click to expand...

This part here is I think the crux of it:
You may not use the Content and Services for any purpose other than the permitted access to Steam and your Subscriptions.
Click to expand...

So I am not "using" it at all. The steam installer is simply being mirrored on my repo. It isn't like if I shared the Quake III game data which would explicitly be sharing their IP usually only accessible via paying.

Either way, I think prisons in the UK allow internet access, so if I do get taken down, I can keep you all updated and tell you "I was wrong!" ;)
 
This looks pretty cool, I'm seriously considering to replace my current installation (from a very old CDROM) in a wine prefix ;) It's working fine, but "native" is tempting ;)
 
Zirias said:
This looks pretty cool, I'm seriously considering to replace my current installation (from a very old CDROM) in a wine prefix ;) It's working fine, but "native" is tempting ;)
Click to expand...
Nice :)

If you do, I don't suppose you could also let me know if any save games work across between versions? My assumption is there will be issues due to the binary serialization but I have never quite tried it and havn't looked too deeply at the save system yet.
 
Not Half-Life (and definitely not METIN2), but I have gotten Toontown Rewritten working on FreeBSD via Wine ( i386-wine-devel), but you have to run Wine as root (insecure, but that's the only way it will work sadly). It's very playable, but (unsurprisingly) framerates a tiny bit worse than Windows 10 on the same system (but works even on an old Intel iGPU). In the past, TTR ran poorly and for a while not at all, but that was then and this is now.

TTR Linux even could work (at least back in November) under the Linuxulator with Ubuntu (with some bugs), but I haven't gotten it to work with Nvidia, only Intel.

Toontown Rewritten is a fan-made revival of Disney's Toontown Online and technically a "private server", but based off a clean-room implementation on the client and server (as opposed to leaked code a la METIN2) only copying the artwork and using the same game engine as the original Toontown (Panda3D). There are other servers, but Toontown is inherently centralized when compared to say Minecraft, so everyone uses the most two popular servers (TTR and some using "Corporate Clash", which isn't exactly 1:1).

TTR is technically in a legal gray area, but since Disney is more focused on movies and Disney+ than gaming nowadays (even the former CEO admits), they haven't bothered taken TTR offline, especially since unlike Club Penguin, Toontown servers remained SFW. Disney is probably more worried about Fortnite than TTR, even if the former carries no Disney IP.
 
That's pretty cool. So I guess it is similar in idea to MaNGOS (World of Warcraft server). These cleanroom servers do sound really fun to reverse engineer the protocols etc.

In the past I had a fiddle with Panda3D (Carnegie Mellon University has some cool stuff in general). It was C++ but had very substantial Python bindings. Any way that the Toontown client could run natively on FreeBSD? Or is most of it using C++.

Also, how come Wine needed to be run as root? Was it trying to use some raw hardware interface? I have not encountered that before (that said, my usage of Wine is usually just to extract things).
 
I looked at the MaNGOS source a bit when I was between jobs a couple of years ago. Unfortunately, the netcode was very "modern" C++ and therefore very hard to follow. I found a pretty significant bug in it, but was unable to fix it, which was very frustrating.
 
Jose said:
Unfortunately, the netcode was very "modern" C++ and therefore very hard to follow. I found a pretty significant bug in it, but was unable to fix it, which was very frustrating.
Click to expand...

That is actually a very good point. In the old days, it was very manageable. However in recent years it is likely that "students" have inherited it and they have a compulsion to overly consumer every C++ feature in existence.

Is it all just async and autos hiding away absured template monstrocities now? ;)
 
kpedersen said:
Code: 
# pkg install xorg git sdl2 mono cmake pkgconf
$ git clone https://github.com/osen/openhl.git
$ PYTHON=python3.7 sh build.sh
$ export/bin/hl
Click to expand...
Thanks for great guide.

You may want to add git-lite instead of git - less dependencies.

I also used newer Python version but it also worked well - PYTHON=python3.8 sh build.sh

Regards.
 
vermaden said:
You may want to add git-lite instead of git - less dependencies.
Click to expand...
Ah good point. Reducing deps is always a goal :)

Yes, it does work really well online. I was considering hacking at the server list code to utilize an IRC channel (for a slightly cheeky free "hosting") but since it works so well with the current list server I am likely to leave it.
 
kpedersen said:
Nice :)

If you do, I don't suppose you could also let me know if any save games work across between versions? My assumption is there will be issues due to the binary serialization but I have never quite tried it and havn't looked too deeply at the save system yet.
Click to expand...
I will do that some day, and as I do have some saved games in my wine installation, I will check ;) Just can't say when I will find the time for "gaming" again ;)
 
I finally had a quick look in your repo :)

Will try it out soon, but my first reflex: couldn't this be made in a port (or maybe a few ports)? Probably, redistributing the game data packaged wouldn't be an option, so you'd need some scripting foo to fetch and install it locally?

Of course, providing a "portable" installation (as you did) is the "next best thing" ;)
 
So far I have maintained ports for archivers/hlextract and games/hllib. These are needed for the main extraction of the game data. I also have made a port for Valve's net/gamenetworkingsockets.

I do plan to ultimately make a port for Half-Life (and the Xash3D engine). I am fairly sure that a binary package will never be a possibility. However the issue isn't with the game data. That is freely distributable. The issue is that the HLSDK explicitly forbids linking against 3rd party engines.

Currently a slight technical issue is also that it doesn't store data at $HOME/.hl or something like that. It is basically written in true 90's Win32 fashion where it just stores all the crap in the Program Files folder (i.e /usr/local). I am currently modifying the project to store in the correct location instead. Things like this are the main reason I made a hard fork instead.

Looking towards a feasible binary package. I have never seen this done before but perhaps a port could be made that for each user, on first run compiles / links the game. A nifty front-end could be made do this outside of the command line. We wouldn't really need to fetch the data either, all of this can be distributed. I am also keeping dependencies to very little outside base+x11.
 
In the hlsdk legal notice i read :
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work.
 
It is this one I think is the problem:
You may, free of charge, download and use the SDK to develop a modified Valve game running on the Half-Life engine
Click to expand...
https://github.com/alliedmodders/hlsdk

The engine that I am using is not the Half-Life engine. Mainly because that is *still* closed source.

There is a similar license here which states that I can use it with Valve's Source engine. This is mostly withheld-source too (even though there are a few leaks floating about).
 
You must log in or register to reply here.
Back
Top