# Half-Life - In 4 easy steps



## kpedersen (May 12, 2021)

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.


```
# 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:




 

 



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.


----------



## shkhln (May 12, 2021)

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.


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!)


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.


----------



## kpedersen (May 12, 2021)

shkhln said:


> How accurate is Xash3D? I wonder if there is any kind of systemic approach to verifying game reimplementation accuracy in general.


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.


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.


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.)


----------



## shkhln (May 12, 2021)

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.



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.


(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.


Makes sense to me


----------



## kpedersen (May 12, 2021)

shkhln said:


> Maybe they don't care as well.


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.)


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



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.



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!"


----------



## zirias@ (May 13, 2021)

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


----------



## kpedersen (May 13, 2021)

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


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.


----------



## neel (May 17, 2021)

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.


----------



## kpedersen (May 17, 2021)

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).


----------



## Jose (May 17, 2021)

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.


----------



## kpedersen (May 17, 2021)

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.



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?


----------



## Jose (May 17, 2021)

kpedersen said:


> Is it all just async and autos hiding away absured template monstrocities now?


It's almost like you've seen the code!


----------



## vermaden (May 17, 2021)

kpedersen said:


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


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 (May 17, 2021)

Wow! Even multiplayer works and people really play that on the net now - I like how they imported some Counter-Strike maps


----------



## kpedersen (May 17, 2021)

vermaden said:


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


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.


----------



## eternal_noob (May 18, 2021)

Awesome!
Thank you!


----------



## rootbert (May 18, 2021)

hehe, cool, compilation took 2 minutes here and the game works! thanks!


----------



## zirias@ (May 18, 2021)

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.


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


----------



## zirias@ (Jun 6, 2021)

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"


----------



## Alain De Vos (Jun 6, 2021)

Will it become part of ports or packages in time ?


----------



## kpedersen (Jun 6, 2021)

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.


----------



## zirias@ (Jun 6, 2021)

Thanks for the insight! But I can't help to shudder about the last paragraph


----------



## kpedersen (Jun 6, 2021)

Zirias said:


> Thanks for the insight! But I can't help to shudder about the last paragraph


Heh, yeah, it is a little naff. Basically the first time a user starts the game, they will have a 10-20 minute loading screen XD


----------



## Alain De Vos (Jun 6, 2021)

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.


----------



## kpedersen (Jun 6, 2021)

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*


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).


----------



## robroy (Jun 6, 2021)

kpedersen, it worked very well for me on 12.2-RELEASE-p7 amd64; this is neat.


----------



## cabriofahrer (Jun 12, 2021)

kpedersen , first of all a big Thank you! I have tried this following your provided instructions and are having a lot of fun playing this again after so many years! Also enjoyed some multiplayer sessions already, although it seems that there is only people playing one map (anarchy).
But could you please explain how to install the whole content of "steaminstall_full.exe", which contains

"Compliments of VALVe, this Steam Installer includes all the files you'll need to play several VALVe titles: - Half-Life - Half-Life: Deathmatch Classic - Half-Life: Opposing Force - Half-Life: Team Fortress Classic - Half-Life: Counter-Strike - Half-Life: Day of Defeat - Ricochet"

I would really like to play Counterstrike as well.


----------



## kpedersen (Jun 12, 2021)

cabriofahrer said:


> I would really like to play Counterstrike as well.


Unfortunately we can only use the *data* from that installer. We can't use any of the program code. Instead the code we are using (to build on FreeBSD) is actually compiled from Valve's official Half-Life SDK. They basically open-sourced the game code (not the engine).

The guys behind Counter-strike never released their 1.6 source code even after all this time and frustratingly it never got leaked. However there is a reverse-engineering project (from the guys upstream at the Xash3D engine) that looks promising. Though admittedly it will not have a high player base due to binary incompatibility with the SteamDRM version.

Currently the only SDKs released by Valve are Half-Life, Opposing-Force and Blue-Shift (they all work on FreeBSD ). Valve released a public Opposing-Force installer (so I can add that to the bundle as steaminstall_opfor.exe). However they never released Blue-Shift game data publicly so we can't distribute that.

That said, these are all the options available to us in terms of mods that were open-sourced, leaked or reverse-engineered.

My personal want though is getting the Half-Life Decay (semi-official) going for a polished coop experience. Hosted here: http://half-lifecreations.com/


----------



## cabriofahrer (Jun 13, 2021)

But how Do I actually start Opposing Force? Is it even installed with your procedure?

And talking about Blue Shift: As far as I remember, it came with improved textures that applied to Half-Life and Opposing Force as well if you installed it, right? Well, I still have an old CD of that, so is there a way to extract the textures from there and use them after installing your project?


----------



## kpedersen (Jun 13, 2021)

You should see that the build also creates an opfor in the export/bin folder, next to the hl. You should be able to run this.

Then the only thing you need to do is instruct the build script to extract the opposing force data from the SteamDRM gcf file. This is done on line 94 of the build.sh, so just uncomment it.

As for Blue-Shift, the SDK is in place so you could probably copy the build instructions for HL or Opforce and they generally work. However I have not integrated anything for that yet until I can find evidence of some sort of public distribution of the game data.


----------



## Jose (Jun 13, 2021)

kpedersen said:


> My personal want though is getting the Half-Life Decay (semi-official) going for a polished coop experience. Hosted here: http://half-lifecreations.com/


I had never heard of that expansion! I am very interested in trying it out. All the links I find for it lead to a blank page, though.


----------



## kpedersen (Jun 13, 2021)

Jose said:


> I had never heard of that expansion! I am very interested in trying it out. All the links I find for it lead to a blank page, though.


Yeah its pretty cool. Possibly one of my favorites because of a slightly shorter Xen section! You play as one of the soldiers. What that mostly means during gameplay is that your hands look different and some security guards are fat 

You can download the game data files here: https://www.gamefront.com/games/half-life/file/opposing-force-steam-installer

I haven't added it to my github repo yet to save space but I probably will at some point.

You can find more info on the game from the SteamDRM website here.


----------



## cabriofahrer (Jun 18, 2021)

kpedersen said:


> Then the only thing you need to do is instruct the build script to extract the opposing force data from the SteamDRM gcf file. This is done on line 94 of the build.sh, so just uncomment it.


Thank you! But running the script again over an already existing installation does not work. I guess you would first need to remove everything first, fetch everything again, then edit the script and afterwards run it, because:


```
cd openhl/
$ sh build.sh
mkdir: /usr/home/werner/openhl/export: File exists
```

It does not overwrite or add.




kpedersen said:


> 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).



Why not? A port would be nice! And I thought that precisely with a port there would be no problem, as opposed to packages?


----------



## kpedersen (Jun 18, 2021)

cabriofahrer said:


> running the script again over an already existing installation does not work


Yep, thats true. Though I have been very careful to ensure everything is put in that export directory. So you can just delete that.

This is mainly a convenience. As for actually developing / improving the code you will still be using the upstream cmake and waf (hopefully not waf for too much longer to get rid of crappy Python as a dependency).

Would a port be worth it? It just means you will type make instead of `sh build.sh`. Yep, as you mentioned a package is a no go. I also need to push a few changes to enable saving of config files in $HOME rather than export/share.


----------



## Crivens (Jun 19, 2021)

Gnaa. I'm stuck in XEN. This bouncing bag thingy is stuck in that tunnel and won't come down. And noclip don't work so I can't wiggle out of it. 

So I need to try OF or something.


----------



## kpedersen (Jun 19, 2021)

Crivens said:


> Gnaa. I'm stuck in XEN.


Ugh, the worst place to be!

If you restart Half-Life and then bring up the console (before loading your game). Then type:
`sv_cheats 1`

Then load your game and `/noclip` should work.


----------



## Crivens (Jun 19, 2021)

Will try! Thank you.


----------



## Crivens (Jun 20, 2021)

Ok. That worked! And XEN is a fun place, imho


----------



## kpedersen (Jun 20, 2021)

Crivens said:


> And XEN is a fun place, imho


Well it is great to hear that the Xen map designer's efforts are appreciated by some! 

In all fairness, I really liked the Xen world section in Blue Shift. It was a smaller section but set up like an incomplete science experiment on a small off-world outpost that you had to finish off.


----------



## blind0ne (Jan 21, 2022)

What about hl2? Is it possible to run it on freebsd?


----------



## Alexander88207 (Jan 22, 2022)

blind0ne said:


> What about hl2? Is it possible to run it on freebsd?



Yes via linux-steam-utils or wine.


----------



## RoGeorge (Jan 28, 2022)

kpedersen said:


> If you are a fan of Half-Life



You have no idea how much that game meant to me, thank you a lot for making it available again.  

Installed, and it works great.  My understanding is this HL runs on a different and open source engine, which makes it all even more amazing.

Does the OpenHL has gamepad support?

Asking because I've plugged an USB gamepad, and couldn't find any settings to switch the controls from mouse+keyb to the gamepad.  My Open HL does not respond to any gamepad controls.  I'm new to FreeBSD, and don't know if my gamepad setup is incomplete, or maybe the game doesn't have gamepad support.

I've installed `# pkg install controllermap` and when I run `controllermap` from a terminal, all 16/12 buttons and the 2 analog thumb joysticks are functional and can be mapped.  However, my KDE Plasma does not show any gamepad/joystick in its settings GUI for input devices, Plasma only sees the keyboard and the mouse.

How/what to set in order to play OpenHL with a gamepad?

My setup:
THRUSTMASTER Firestorm Dual Power 3 Gamepad (USB)
FreeBSD bsd 13.0-RELEASE-p4
X11 + KDE Plasma 5.23

```
# dmesg | grep uhid
    uhid0 on uhub4
    uhid0: <THRUSTMASTER FireStorm Dual Power 2, class 0/0, rev 1.10/1.00, addr 9> on usbus0

ls -l /dev/uhid0
    crw-rw----  1 root  operator  0xf3 Jan 28 03:09 /dev/uhid0

groups
    aaaa wheel operator video vboxusers
```


----------



## kpedersen (Jan 29, 2022)

RoGeorge said:


> Installed, and it works great.  My understanding is this HL runs on a different and open source engine, which makes it all even more amazing.


Yes, it is an engine called "Flying with Gauss" (formerly xash). I believe it has slightly dubious origin with some leaked code but I could be wrong. When going through the code, it just looks like a typical open-source project.



RoGeorge said:


> Does the OpenHL has gamepad support?


Hmm, actually I am not sure. The upstream developers have a heavy focus on Android (which is why I forked the project because Android support is a messy dead end time suck . It could well be that gamepad support is not in there unless it comes for free (i.e with SDL). I will check the code when I get back.


----------



## RoGeorge (Jan 29, 2022)

Meanwhile I've found out that:

- it should be a checkbox in the HL advance settings menu (in HL GUI) but I don't see any in my OpenHL, to enable the Joystick from the game's advance settings menu.  Given the fact that my KDE Plasma is not aware about the gamepad either, probably my setup gamepad is incomplete

- if I export the gamepad settings given by `controllermap` into the system variable then start the openhl in the same line, with `&&` and it didn't work, something like this:

```
$ export SDL_GAMECONTROLLERCONFIG="030000008f0e00000300000010010000,GreenAsia Inc. USB Joystick ,platform:Linux,x:b3,a:b2,b:b1,y:b0,back:b8,start:b9,dpleft:h0.8,dpdown:h0.0,dpdown:h0.4,dpright:h0.0,dpright:h0.2,dpup:h0.0,dpup:h0.1,leftshoulder:h0.0,leftshoulder:b6,lefttrigger:b4,rightshoulder:b7,righttrigger:b5,leftstick:b10,rightstick:b11,leftx:a0,lefty:a1,rightx:a3,righty:a2," && hl
```
(got this idea from an Arch Linux wiki:  https://wiki.archlinux.org/title/Gamepad)

- it is very hard to aim with a gamepad, close to impossible even when the auto-aim is enabled, so I gave up playing a FPS game with a gamepad

Please don't spend time looking for gamepad support in sources, I've tried on an WinXP32 laptop with the original HL game and the same gamepad.  It's impossible to aim properly with my gamepad.


----------



## kpedersen (Jan 29, 2022)

RoGeorge said:


> Please don't spend time looking for gamepad support in sources, I've tried on an WinXP32 laptop with the original HL game and the same gamepad.  It's impossible to aim properly with my gamepad.


OK sure. Yes I was thinking the same. It isn't like Doom, Duke3D or Blood where you are effectively playing on a 2D plane even though it looks 3D. Awkward with gamepad.

If you do want to try out Half-Life with a gamepad. I do recommend the PS2 port (Half-Life: Decay). Comes with a nifty Co-op mode too.


----------



## RoGeorge (Feb 3, 2022)

Just FIY, it compiles and runs in Linux, too, tested in 4k on an Ubuntu 20.04 LTS + KDE Plasma, i7/nVidia:  

```
sudo apt install xorg git libfreetype-dev libfontconfig1-dev libsdl2-dev mono-complete cmake pkgconf

        # - in Debian, csc is known as mono-csc, a symlink to /usr/bin/msc
        #   the 'csc' name might conflict with another package, 'chicken-bin'
        #   usually, 'chicken-bin' is not preinstalled
        # - create a 'csc' symlink to the '/usr/bin/msc', so to keep the same build.sh
        cd /usr/bin
        sudo cp -s /usr/bin/mcs csc
             
        cd ~
        git clone https://github.com/osen/openhl.git
        cd openhl
     
        PYTHON=python3 sh build.sh
        # if the compilation fails, fix the errors, delete the 'export' directory
        #   then run only this line again.  Do not start anew and do not git clone again,
        #   because that is not necessary and the repository is very big (~300MB)
     
        # for Linux, the .so names has to be changed from libclient/libserver to client/hl
        sed -i 's/libclient\.so/client\.so/' export/bin/hl
        sed -i 's/libserver\.so/hl\.so/' export/bin/hl

        sed -i 's/libclient\.so/client64\.so/' export/bin/opfor
        sed -i 's/libserver\.so/hl64\.so/' export/bin/opfor

        # to run the Half-Life game
        export/bin/hl
     
        # to run Half-Life: Opposing Force
        export/bin/opfor
```

I have a question about the Opposing Forces, shouldn't that be a different game?

When I run `export/bin/opfor` I see the same game as when I run `export/bin/hl`, and the saves I see inside `opfor` are the ones I've made while playing `hl`.  This happens in FreeBSD (and in Linux, too).

My understanding is that both games are there, and that `hl` and `opfor` games have different maps and different story.  Apparently, `export/bin/opfor` starts the same Half-Life, so how do I start Opposing Force (asking for the FreeBSD version, of course)?


----------



## kpedersen (Feb 3, 2022)

RoGeorge said:


> My understanding is that both games are there, and that `hl` and `opfor` games have different maps and different story.  Apparently, `export/bin/opfor` starts the same Half-Life, so how do I start Opposing Force (asking for the FreeBSD version, of course)?


Opposing Force uses the same Half-Life engine. Support is there in the code and it works fairly well, you just need to extract the files from the Steam pre-cache installer into the correct place. The script doesn't do this by default (they are commented out) and I haven't uploaded that installer to GitHub (to avoid long download times during a clone).

The following lines in the script should be fairly self-explanatory how to do it.

https://github.com/osen/openhl/blob/main/build.sh#L87
https://github.com/osen/openhl/blob/main/build.sh#L94

For the data, you can do a google search for steaminstall_opfor.exe which will end up with a public mirror such as this.


----------



## zirias@ (Feb 23, 2022)

Hello kpedersen, I finally got around trying this, and the first thing I did is create a port, just because I hate cluttering my systems with build-time deps (they should stay in temporary poudriere jails) and I also hate having stuff installed that isn't under pkg's control...

But I'm hitting a wall right now, seeing this when I try to start the game:





As I assume you had quite a deeper look at the code: where does it try to write stuff, can you think of a way to teach it to use something below $HOME instead?

My WIP port is here: https://github.com/Zirias/zfbsd-ports/tree/local/games/openhl


----------



## kpedersen (Feb 23, 2022)

Zirias said:


> As I assume you had quite a deeper look at the code: where does it try to write stuff, can you think of a way to teach it to use something below $HOME instead?


It should be here in the code (*FS_WriteGameInfo*):

https://github.com/osen/openhl/blob/main/src/engine/engine/common/filesystem.c#L1439

It uses in places a virtual filesystem (a throwback to the Quake pak stuff). I never got round to doing it but I believe that a modification to *FS_Open* would be the place to start in terms of creating an overlay of writable files in your $HOME in a generic manner. I did similar for GtkRadiant (The Quake / Half-Life level editor) which follows a fairly similar design in terms of filesystem.


----------



## zirias@ (Feb 24, 2022)

kpedersen, finding the code that throws the error wasn't a problem, but understanding how to change the behavior 

I guess I found a somewhat nice solution now (port works!): https://github.com/Zirias/zfbsd-por...s/patch-src_engine_engine_common_filesystem.c

(edit: I have a little suggestion, you could add an `exec` in your scripts... )


----------



## kpedersen (Feb 24, 2022)

Zirias said:


> I guess I found a somewhat nice solution now (port works!)


Nice work. *FS_NOWRITE_PATH *makes it write in user's directory instead (I have yet to follow the code path and understand how it works)? I didn't know that the engine already had that functionality and something like this was going to need to be added myself.


Zirias said:


> (edit: I have a little suggestion, you could add an `exec` in your scripts... )


As in:

```
LD_LIBRARY_PATH="$XASH_BIN_PATH:$LD_LIBRARY_PATH" exec "$XASH_BIN_PATH/xash3d" \
  -clientlib "$HL_CLIENT_LIB" -dll "$HL_SERVER_LIB" -console "$@"
```

I can do. Also tempted to merge your patch (unless you noticed any potential issues in your testing?)


----------



## zirias@ (Feb 24, 2022)

kpedersen said:


> *FS_NOWRITE_PATH *makes it write in user's directory instead (I have yet to follow the code path and understand how it works)?


There's an internal static var `fs_writepath` that's used for every write operation. The flag prohibits setting this static var when adding the path. So, adding _another_ (dummy) path below `$HOME` seems to solve the issue.


kpedersen said:


> Also tempted to merge your patch (unless you noticed any potential issues in your testing?)


Currently only did some "smoke testing", menus work, I can play the intro and control the player ...

Will need to do a lot more testing to be sure!


----------



## zirias@ (Feb 24, 2022)

Ok, doesn't really work with that patch, it can't save games and bugs on automatic map changes (probably related to the problem with saving games)...

So, maybe the order of registering the "overlayed" paths is relevant? Will do more testing


----------



## zirias@ (Feb 24, 2022)

Got it, no need to patch the code at all, it already does the "nowrite magic" when invoked with an `rodir` 

So, here's a little "pull request" (should apply with `git am`):

```
From 48454727693a255e827f83ff2393f3211e8f2a0d Mon Sep 17 00:00:00 2001
From: Felix Palmen <felix@palmen-it.de>
Date: Thu, 24 Feb 2022 13:45:51 +0100
Subject: [PATCH] Separate write location in $HOME/.openhl/

---
 system/bin/hl    | 6 ++++--
 system/bin/opfor | 6 ++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/system/bin/hl b/system/bin/hl
index a7f0e92..7adfd4e 100644
--- a/system/bin/hl
+++ b/system/bin/hl
@@ -3,13 +3,15 @@
 PREFIX="$(cd "$(dirname "$(which "$0")")" && cd .. && pwd)"
 
 if [ -z "$XASH3D_BASEDIR" ]; then
- export XASH3D_BASEDIR="$PREFIX/share/xash3d/"
+ export XASH3D_BASEDIR="$HOME/.openhl/"
 fi
 
 XASH_BIN_PATH="$PREFIX/lib/xash3d"
 HL_CLIENT_LIB="$PREFIX/lib/xash3d/valve/libclient.so"
 HL_SERVER_LIB="$PREFIX/lib/xash3d/valve/libserver.so"
 
-LD_LIBRARY_PATH="$XASH_BIN_PATH:$LD_LIBRARY_PATH" "$XASH_BIN_PATH/xash3d" \
+mkdir -p "$XASH3D_BASEDIR"
+LD_LIBRARY_PATH="$XASH_BIN_PATH:$LD_LIBRARY_PATH" exec \
+ "$XASH_BIN_PATH/xash3d" -rodir "$PREFIX/share/xash3d/" \
  -clientlib "$HL_CLIENT_LIB" -dll "$HL_SERVER_LIB" -console "$@"
 
diff --git a/system/bin/opfor b/system/bin/opfor
index 28d6c3f..73cc74b 100644
--- a/system/bin/opfor
+++ b/system/bin/opfor
@@ -3,13 +3,15 @@
 PREFIX="$(cd "$(dirname "$(which "$0")")" && cd .. && pwd)"
 
 if [ -z "$XASH3D_BASEDIR" ]; then
- export XASH3D_BASEDIR="$PREFIX/share/xash3d/"
+ export XASH3D_BASEDIR="$HOME/.openhl/"
 fi
 
 XASH_BIN_PATH="$PREFIX/lib/xash3d"
 HL_CLIENT_LIB="$PREFIX/lib/xash3d/gearbox/libclient.so"
 HL_SERVER_LIB="$PREFIX/lib/xash3d/gearbox/libserver.so"
 
-LD_LIBRARY_PATH="$XASH_BIN_PATH:$LD_LIBRARY_PATH" "$XASH_BIN_PATH/xash3d" \
+mkdir -p "$XASH3D_BASEDIR"
+LD_LIBRARY_PATH="$XASH_BIN_PATH:$LD_LIBRARY_PATH" exec \
+ "$XASH_BIN_PATH/xash3d" -rodir "$PREFIX/share/xash3d/" \
  -clientlib "$HL_CLIENT_LIB" -dll "$HL_SERVER_LIB" -console "$@"
 
--
2.35.1
```

Will update the port now


----------



## kpedersen (Feb 24, 2022)

Zirias said:


> Got it, no need to patch the code at all, it already does the "nowrite magic" when invoked with an `rodir`


Very nice find. This way we can also keep a little closer to upstream (in src/engine) without hacking too much at their code.


----------



## zirias@ (Feb 24, 2022)

Yes, pretty nice this "just works"  Port is now fixed as well, builds and runs fine!

There's a little glitch, during loading, it briefly shows some picture from an earlier scene ...


----------



## zirias@ (Feb 24, 2022)

kpedersen said:


> If you do, I don't suppose you could also let me know if any save games work across between versions?


Finally, an answer ... they work!  You have to copy them preserving timestamps:
`cp -p <wineprefix>/drive_c/Programme/Half-Life/valve/SAVE/* ~/.openhl/valve/save`
Only little glitch: screenshot pics are missing.


----------



## kpedersen (Feb 24, 2022)

Zirias said:


> Finally, an answer ... they work!


Heh, great to hear. Why is preserving the timestamps important out of interest?


----------



## zirias@ (Feb 24, 2022)

kpedersen it seems they are used as the actual timestamps for the games saved (displayed in the list, used for sorting...)


----------

