search

luxtorpeda-dev / packages

Package build scripts and support for luxtorpeda client
https://luxtorpeda.org
zlib License
37 stars 28 forks source link

ETe for Wolfenstein: Enemy Territory #679

Closed ensiform closed 2 years ago

ensiform commented 2 years ago

Project Link

https://github.com/etfdevs/ETe

Project License

GPLv3+

Steam App Ids

https://steamdb.info/app/1873030/

Additional Context

This game was recently released on Steam when Bethesda Launcher was decomissioned. My engine fork is similar to the Quake3e Project but for W:ET which already has an entry for Q3A (https://github.com/luxtorpeda-dev/packages/tree/master/engines/quake3e)

There is also a more well known ET fork, ET:Legacy, which has stable releases instead of just snapshot builds.

ensiform commented 2 years ago

Forgot to mention that may need to support x86 and x86_64 because unlike Q3A, and also like RTCW and JK2/JKA the games only support native mod binaries (.so/.dll/.dylib) instead of QVM bytecode. And the majority of older existing mods besides ET:Legacy only support x86. But both ETe and ET:Legacy have options to build x64 versions of the bins for respective mods.

d10sfan commented 2 years ago

@ensiform

Thanks for the package suggestion and the engine! I've got et:legacy available as an option and I can add this one as well.

I had a few questions to make sure I understand building it and the usage:

ensiform commented 2 years ago

@ensiform

Thanks for the package suggestion and the engine! I've got et:legacy available as an option and I can add this one as well.

I had a few questions to make sure I understand building it and the usage:

  • It looks like it is expected to be built in 32-bit mode correct? From reading https://github.com/etfdevs/ETe/blob/master/src/linux_build.sh#L45
  • For building in 64-bit mode, is it as simple as removing the toolchain line that forces it to 32-bit? Or should 32-bit be built only for now? referencing the "64-bit (x86_64) platforms are unstable currently with bugs that do not exist under 32-bit platforms."
  • Does the build process create the files in the ete-etmain-mod-replacement-allplatform.zip zip, and what is the directory structure expected to be? Should those files be directly in the installation directory, or in etmain, or somewhere else? I was able to use the built release by putting it into etmain and that appeared to work, just wanted to confirm.

linux_build.sh can be used but it is outdated and was created for personal use by another developer. The github workflow does all of the work for latest releases without using that script. It also does the copying and generating of ete-etmain-mod-replacement-allplatform.zip

At the moment I am not sure what the best case scenario would be here. Seems like source building would be easier. As the prebuilt snapshot Linux packages do not have self contained libraries and may not work on all systems.

This is what I had come up with but have not tested anything so far and do not have docker installed currently:

#!/bin/bash

# CLONE PHASE
git clone https://github.com/etfdevs/ETe.git source
pushd source
git checkout latest
popd

# BUILD PHASE
mkdir -p tmp
pushd "source"
mkdir build
cd build
cmake \
    -DUSE_SDL2=ON \
    -DCMAKE_INSTALL_PREFIX=../../tmp \
    -DCMAKE_BUILD_TYPE=Release \
    ..
make -j "$(nproc)"
make install
popd

# COPY PHASE
cp -rfv tmp/ete-ded.x86_64 "$diststart/1873030/dist/"
cp -rfv tmp/ete.x86_64 "$diststart/1873030/dist/"
cp -rfv tmp/cgame.mp.x86_64.so "$diststart/1873030/dist/etmain"
cp -rfv tmp/qagame.mp.x86_64.so "$diststart/1873030/dist/etmain"
cp -rfv tmp/ui.mp.x86_64.so "$diststart/1873030/dist/etmain"

cgame & ui would need to also be located within a new pk3 residing in etmain such as the ete-etmain-mod-replacement-allplatform.zip contains a mp_bina.pk3 with all of the OS' in it but it doesn't necessarily have to contain all of them since most people will not be using such mod.

The mod code is optional though and not really recommended except for x64 because there is no x64 on original game of course.

d10sfan commented 2 years ago

@ensiform

Thanks for the information! I created a starting point for it, let me know what you think: https://github.com/luxtorpeda-dev/packages/pull/680

This builds just 32-bit for now, let me know if it makes sense to also do 64-bit. I also added the etmain mod building, to provide the cgame, qagame, and ui. Let me know if that makes sense for this case, or if there's something else I should do. In the original steam version, we don't get the linux libraries, so it probably makes sense to use your etmain libraries.

d10sfan commented 2 years ago

dist.zip

Also, if you'd like to look at the built result, I've attached it above.

ensiform commented 2 years ago

@ensiform

Thanks for the information! I created a starting point for it, let me know what you think: https://github.com/luxtorpeda-dev/packages/pull/680

This builds just 32-bit for now, let me know if it makes sense to also do 64-bit. I also added the etmain mod building, to provide the cgame, qagame, and ui. Let me know if that makes sense for this case, or if there's something else I should do. In the original steam version, we don't get the linux libraries, so it probably makes sense to use your etmain libraries.

Hi! Looking good so far. But why is it using LD_PRELOAD="" and linking the pak files? If this can dump the ete.x86/ete-ded.x86 in the main steam folder for the game that is all you should really need. As it should know how to run from the core assets similar to most idtech3 games normally anyway.

Also, since you are looking at the 32 bit build I would recommend avoiding the build etmain mod option all together, as it provides no benefits to the game experience and also overrides the shipped game version. It merely is designed for some minor fixes and provide 64 bit mod to start with so that game runs in 64 bit.

d10sfan commented 2 years ago

@ensiform

The LD_PRELOAD="" is a way to avoid the steam overlay trying to inject into the commands. When this happens, it slows things down. I usually try to keep multiple engines each in their own folders, to avoid collisions, since in this case, there's three possible engines (et legacy, et legacy 64-bit, and this one). That's why it's going into its own folder and linking into a new etmain.

The steam release of the game does not provide the linux libraries, only windows dlls. Are you recommending that the original Linux version (https://cdn.splashdamage.com/downloads/games/wet/et260b.x86_full.zip) be used instead of the one that you provide? Just to make sure we're on the same page.

Thanks!

ensiform commented 2 years ago

The steam release does provide the 32-bit linux versions of the client and ui modules (inside etmain/mp_bin.pk3 and will be extracted to homepath when launched) but you are correct, the qagame (server side) is missing. If its possible to pull the qagame.mp.i386.so from that zip easily I guess that would work too and be most ideal. Just so players don't mistake that something changed in the game itself without knowing and for most compatibility.

Technically there shouldn't be any issue with engine collisions per-se (though legacy doesn't have separate binary filenames like ete and ete-x86.x64 (yet?). Legacy uses its own homepath for writing configs etc (~/.legacy), and ete shares the original linux ~/.etwolf

ETe will actually mount the steam path ~/.steam/steam/steamapps/common/Wolfenstein Enemy Territory so the linking may be unnecessary if the ete folder just contains the ete and ete-ded binary.

Personally had no issue with steam overlay injection when using other methods to brute force load ETe from steam. echo %command%; /home/user/Games/ete/ete.x86_64 for example

d10sfan commented 2 years ago

@ensiform

I've run into the steam overlay issue in the past with long running processes, especially related to logging from what I remember, and it made a difference. For this, it probably isn't needed, but it's good to keep it the same as the rest. It's not related to running the engine directly.

What I could do for the linux version is extract the entire thing into a directory on the person's computer and then copy that one file. I wouldn't want to re-host it, so that'd be the best option. I can look into that in a bit.

ensiform commented 2 years ago

Found it on etlegacy's mirror hosting by itself: https://mirror.etlegacy.com/etmain/qagame.mp.i386.so

d10sfan commented 2 years ago

@ensiform

Ah ok thanks, I'll try that.

d10sfan commented 2 years ago

@ensiform Thanks for the help on this! I've made the change to use that library and I've merged the PR and it's now available. I was able to join a server and play for a bit. Let me know if you run into any issues or have any further suggestions.

Here's the commit if you're interested: https://github.com/luxtorpeda-dev/packages/commit/f46b8d04582f1d0b7e6268c07b4b8f6b3a6f772b

ensiform commented 2 years ago

Was there a reason why the etlegacy repo is checked out for build stage?

d10sfan commented 2 years ago

@ensiform Since we are using their mirror/library, I wanted to add the license file from that project in additon to the ete license.

ensiform commented 2 years ago

It's just a mirror of the file which comes from the 2.60 Linux vET install however. But I guess that's fine.