Closed atomGit closed 4 months ago
I have shared my configs and systemd unit files for the test/development servers here: https://code.idtech.space/eukara/fhl-server-configs
The FreeCS specific server config is here: https://code.idtech.space/eukara/fhl-server-configs/src/branch/master/cstrike/server.cfg
The error you got is because no level to play on was specified. You can generally put the one the server should start on at the bottom of the config.
Once you have a custom server.cfg
, you can then launch fteqw-sv like this:
./fteqw-sv64 -halflife -game cstrike +exec customServer.cfg
Hope this helps, let me know if anything else is unclear!
thanks!
server appears to work, but i'm having trouble connecting
./fteqw64 -halflife -game cstrike +connect <ip:port>
freecs loads to a dark screen (with a background image) and then nothing
i didn't use the bootstrap script, nor the systemd configs - i just downloaded and extracted freehl, freecs and fteqw-sv64 onto the server using a non-root account
i think this is a firewall issue - both sides are firewalled (ufw) - on the client i'm not opening any ports and on the server side i'm opening only whatever port the server runs on, but if memory serves, isn't there a range of ports that have to be opened for the server?
i assumed the fte console output gave the correct port so i never biothered to check what port the server is actually running on, which brings up two questions:
sv_port
seems to have no effectss -lntu
says it's listening on 27500?when i open 27500 on the server side, the client output is a bit different - mainly "Game mismatch: This is a FTE-HalfLife server"
com_protocolname
reports nuclicide (i think - the font very small)
server command: ./fteqw-sv64 +sv_public 0 -halflife -game cstrike +exec server.cfg
client command: ./fteqw64 -halflife -game cstrike +connect <ip>:27500
Out of curiosity, will the server be public? FreeCS is cool but I ain't got no one to play it with, sadly.
hi @xplshn - i'm not sure whether it will be public or semi-private - for now i just want to see if it's a doable endeavor and try to see what the security implications are
that said, i'd be glad to accommodate you when (if?) i get this all working - i bookmarked your comment so i can remember to look you up
ELinks looks interesting - scarfed that from your neocities site
@xplshn - was reading your blog - seems we have a common opinion regarding what the interwebs has devolved into - get a hold of me at... [removed]
Got it, sent you an email, and also, thanks for reading my blog.
Hmm, have you tried to run it in a container? In order to isolate it from the rest of the server. It does not add any overhead to use Docker/Podman, etc.
March 3, 2024 at 12:58 AM, "atomGit" @.***> wrote:
hi @xplshn https://github.com/xplshn - i'm not sure whether it will be public or semi-private - for now i just want to see if it's a doable endeavor and try to see what the security implications are
that said, i'd be glad to accommodate you when (if?) i get this all working - i bookmarked your comment so i can remember to look you up
ELinks looks interesting - scarfed that from your neocities site
—
Reply to this email directly, view it on GitHub https://github.com/eukara/freecs/issues/36#issuecomment-1975012219 , or unsubscribe https://github.com/notifications/unsubscribe-auth/A3MRASS7XDR7CKA3S7565VTYWKNV3AVCNFSM6AAAAABEA7T6M6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGAYTEMRRHE .
You are receiving this because you were mentioned.
no matter what i try the client keeps responding...
Game mismatch: This is a FTE-HalfLife server
server file structure:
~/freehl
..crash.log
..default.fmf
..fteqw-sv64
..fullchain.pem
..privkey.pem
~/freehl/cstrike
../platform
..csprogs.dat
..ftesrv.cfg
..mapcycle.txt
..motd.txt
..pak0.pk3
..progs.dat
..server.cfg
..ssqccore.txt
..zpak001.pk3
~/freehl/valve
..csprogs.dat
..menu.dat
..platform.pk3
..progs.dat
..zpak001.pk3
server command:
$ ./fteqw-sv64 -halflife -game cstrike +sv_public 0 +set deathmatch 1 +exec server.cfg
client command:
$ ./fteqw64 -halflife -game cstrike +connect <ip>
server does not exec fteqw.cfg...
couldn't exec ftesrv.cfg
i tried putting the file in the root of the game dir along side fteqw-sv64, as well as in the cstrike folder - is this file needed and, if so, how to exec it?
also what about game.cfg? is it needed? what goes in it? where does it need to reside?
same questions for platform_default.cfg
Get rid of any FreeHL/FreeCS files (Including the default.fmf file). Some changes have happened recently to make installation a lot easier.
Newer release builds don't have it (like those on Frag-Net.com. Just grab the two .pk3 files for FreeHL and FreeCS, shove them into valve/
and cstrike/
respectively.
The -halflife
switch will also set com_protocolname
to FTE-HalfLife. A default.fmf will override that.
The bootstrap script basically just extracts the content, downloads the latest .pk3 files and moves them in the right place. If you have issues still, you can try that too.
I should also note that the sv_public 2
setting you may want to switch to 1. The value 2 will make it use frag-net.com's RTC broker (meaning no port forwarding) which is also the default when hosting games through the menu.
this is getting very confusing and i'm getting no where fast - again, i keep getting the same message with or without a default.fmf...
Game mismatch: This is a FTE-HalfLife server
imagine you want to set up a dedicated cs server and a client to connect to that server - you're starting with nothing...
Well, I have shared the bootstrap script for the server.
As for the client, without having to compile anything at all - no git, no building of any code (including QuakeC) you only need the following:
Half-Life/valve/package_valve.pk3
Half-Life/cstrike/package_cstrike.pk3
FTEQW should auto-detect it as Half-Life. It is programmed to look for valve/liblist.gam
, and if that exists launch with the -halflife
settings.
So even simply running fteqw
is supposed to launch at least Half-Life. At least if you're running a recent version.
Last resort for your current situation:
You can always override com_protocolname
if something, somehow is setting it to the wrong value. Do set com_protocolname FTE-HalfLife
in console before connecting and that should always work.
on Arch the bootstrap script dies when trying to compile rewise:
[$MAKETOOL CC=cc](freehlded-bootstrap.sh: line 107: CC=cc: command not found)
solved by compiling rewise locally and copying it to the server (i don't have the AUR enabled on the remote side)
update: this issue is solved in my next post, however the build logs don't look too healthy to me (see attached)
same issue: Game mismatch: This is a FTE-HalfLife server
here's what i did on the server side to get a cs dedicated server...
set sv_public 0
./fteqw-sv64 -halflife -game cstrike +sv_public 0 +set deathmatch 1 +set maxplayers 16 +map de_dust2
on the client side...
again, i didn't edit any of the files
build logs attached...
So you're still compiling FreeCS etc. yourself. While you don't have to do that, since the game-logic is architecture/platform independent, here's what you will have to do:
If you want to play with release builds, you can copy the csprogs.dat and progs.dat over into a non development directory, using the client instructions I stated above.
You could also change the default.fmf, which seems to still be present somewhere, to be FTE-HalfLife
instead of Nuclide. Or manually change it via the console as stated in my last post.
The git is for development, there's a few key differences between development builds of games (the platform directory does not exist). It's also why they're under a different protocol (Nuclide as opposed to FTE-HalfLife). Not every Nuclide game should be able to connect to a Half-Life game. Like The Wastes for example. Otherwise they will show up in each others server browsers. They also avoids some directory conflicts with other mods/games.
I will try to give the game specific Makefiles a bit more capability into building a proper release build. I expected most people to just download the release archives because bootstrapping a game-engine, plus compilers and game-logic just to play it is really a lot to ask.
And when you're building/modifying FreeHL/FreeCS code, the only artifacts of importance are valve/menu.dat
, valve/progs.dat
, valve/csprogs.dat
, cstrike/progs.dat
and cstrike/csprogs.dat
.
gamedir/zpak*.pk3dir
contains scripts and other assets that the .dat files need to run. That gets compressed into a pk3 (zip) file and attached to the release builds. In the development directory it's merely a directory (for obvious reasons) but that also means it cannot be checked for purity. Which is what some servers do (see the cvar sv_pure) to check if you're running an unmodified game. Which is also why development builds (even when forcing the protocol) won't be able to connect to some servers.
finally .... !!! SUCCESS !!!
set com_protocolname FTE-HalfLife
in console before connecting did the trick
why is that necessary though?
sorry, i didn't yet see your comment when i made my last post - i will look that over carefully
So you're still compiling FreeCS etc. yourself.
well, i wasn't, but i thought that might solve my 'game mismatch' issue - i found i also really like the clear and plain nuclide UI vs. the usual HL/CS UI
You could also change the default.fmf, which seems to still be present somewhere ...
yes, it is - perhaps in the hlserver4110.exe archive
so when you say it isn't necessary to build, you're talking strictly about the client, correct? running the server bootstrap script is still the best way to go on the server side, yes?
ps: can't hardly describe how cool it was when i finally connected to the server! awsome!
Technically all you would ever need to build is FTEQW. FreeCS and FreeHL are 100% QuakeC. The menu, the client and server logic is 100% platform independent and portable. Running solely through FTEQW's QCVM. Doesn't matter if client or server. This means if someone ported FTEQW by itself to some esoteric platform, like the PS Vita, all these games should just run as-is
default.fmf is in your latest freehl release: valve-04-18-2023.zip
just mentioning because you seemed to not be certain :)
update: given recent updates this post became obsolete
You could also change the default.fmf, which seems to still be present somewhere, to be FTE-HalfLife instead of Nuclide
that was the problem all along - with your release builds of hl/cs that fmf needs to be present and PROTOCOLNAME
set to "FTE-HalfLife"
if the file isn't there, Game mismatch: This is a FTE-HalfLife server
and of course the other option is to specify that in the game console before connect as you said
i'm working on a readme for all this
default.fmf is in your latest freehl release: valve-04-18-2023.zip
just mentioning because you seemed to not be certain :)
They're the latest release... on GitHub. I admit I have not been uploading new releases here due to a growing dislike of this platform. Edit: Went ahead and uploaded new builds on GH.
... due to a growing dislike of this platform
i hear ya, though in my case it's probably for a different reason (owned by microsuck)
@eukara - is there any ability to admin (rcon) a server (or 3rd party tool)?
ok, looks like rcon is available, but how is the password set?
also, can a password for the server be set? i tried set sv_password "<password>"
in cstrike/server.cfg but it doesn't seem to have an effect - i tried sending the password a bunch of different ways on the client side
freehlded-bootstrap.sh: line 116: CC=cc: command not found
as mentioned, i have the server working, however i'm trying to figure this out - i'm a dummy with compiling anything
$ command -v cc
/usr/bin/cc
$ command -v gcc
/usr/bin/gcc
so why then CC=cc: command not found
?
for $MAKETOOL CC=cc
i tried CC=gcc
, CC=/usr/bin/gcc
, CC=/usr/bin/cc
this is on Manjaro (Arch for dummies!)
Looks like MAKETOOL wasn't being checked right. Try now!
works like a champ!
is a dedicated server possible?
i'd like to install a dedicated server on an Arch VPS
i started playing around with this but there seems to be very little documentation on fteqw (
fteqw-sv64 -h/--help
for example simply tries to start the engine)setting
-basedir
to anything other than the current directory doesn't seem to work