I've been hard at work today to finish nQuakesv, but it's come to a halt due to lack of working binaries.

I thought I would share my progress with you here.

The setup asks you the following questions:

* Where do you want to install nQuakesv?
* How many ports do you want to run? (max 4)
* Enter a descriptive hostname.
* Do you want to run a qtv server?
* Do you want to run a qwfwd server?
* Who is the admin of the server?
* Rcon password?
* Master rcon password?
* Admin code?
* QTV password?
* Search for pak1.pak?

Then you get to choose a mirror from where you download the files.

When setup is complete, you get prompted to put the following line inside your crontab:

*/10 * * * * /home/<user>/nquakesv/servers.sh

After this, the server is installed. No more configuration needed.

Thoughts?

(Edited 2012-08-20, 21:39)

So basically the only thing missing now is some sort of universally working binaries for mvdsv, ktx, qtv and qwfwd.

It's going to be the hard part, since compilers on different systems make different builds that won't work everywhere (been there, seen that, unfortunately). So the lib hell exists even on linuxes, it's not just a windows problem.

And it's going to be even harder if you try to force 32bit builds on all systems, 64bit systems will require additional libs that allow them to run 32bit builds.

EDIT:

Something I noticed: qwfwd and qtv are not "servers", they are proxies.

Also you don't seem to specify sv_serverip ip:port anywhere, it's quite important variable especially if you want to have a "safe server" and working ip resolving (basically against cheaters).

"Admin code" is a remnant that shouldn't be used, VIP should be used instead on any modern server.

Do not set master_rcon, it allows commands to be executed locally in the shell, which is a security risk.

(Edited 2012-08-20, 21:52)

IP is automatically detected and added to config files.

I'll fix the rest of your suggestions, thanks.

(Edited 2012-08-20, 22:15)

If there's no way of compiling universal binaries, then I would still like to have some binaries to include. I can't find anything online.

I could let the user select what binaries he wants during the installation.

I am also including a script that will download newer binaries, replace the old (backing them up first, of course), and restart the servers, all automatically. Great stuff.

(Edited 2012-08-20, 23:23)

I don't think there would be much problem if you compiled one 32bit version and one 64bit version on a Debian Stable box. They should work pretty much everywhere.

Renzo: Unless you have incompatible dynamically linked libraries (I haven't checked), the 32bit application on 64bit should work fine. However you do need 32bit libs at compile time if cross-compile on a 64bit host, perhaps thats what you meant?

(Edited 2012-08-21, 07:10)

Exactly what Debian version should I install to compile both 32-bit and 64-bit binaries? I have a server with i7 quad core. But it's running on a virtual machine. I would like it to run on extremely low resources, because it's only going to compile binaries.

(Edited 2012-08-21, 07:24)

Added a CTF configuration to the pack, and a map update script.

I made a script that downloads the latest 64-bit and 32-bit binaries for mvdsv ktx qtv and qwfwd. This script runs on f.nu, which updates the main mirror with the new binaries. The script runs once every day. This way nQuakesv will always have the latest binaries.

The installer lets you choose what binaries to use. There is also a script that allows an admin to update his binaries using a simple script.

I successfully installed a server just now in <1 minute.

There. Done. Added to website.

Please download and give me input on the installer and the contents.

I'll be ready to fix stuff up for a few days, then it's a no-go.

Yeah, for 32bits compilation on 64bit system. There were some problems on builds compiled on 64bit system + ia32 libs running on another system, they were rounding up armor values incorrectly (can pickup ga when ga:100) at some point, so this is something that should be avoided.

(Edited 2012-08-21, 12:06)

These servers are now running nQuakesv. Took me two minutes to set up.

qw.fnu.nu:28501 ktx
qw.fnu.nu:28502 ktx
qw.fnu.nu:28503 ktx
qw.fnu.nu:28504 ktx
qw.fnu.nu:28000 qtv
qw.fnu.nu:30000 qwfwd

Empezar, thanks for working on this and a special thanks for incorporating CTF by default! A while ago I wrote http://bit.ly/qwctf to help configure CTF, since it wasn't enabled out of the box. Few comments:

1- Any chance you can include some CTF maps into the installer? I have a .rar with the common maps up on that site.

2- There is an issue where the ctf .ent files are getting loaded even when not in ctf mode. For example, check out dm4: the RA tele does not go where it's supposed to, and the low tele has a YA instead of a GA. You probably need this in the configs/usermodes/default.cfg

sv_loadentfiles 0 // do not load CTF-specific .ent files

and then this in configs/usermodes/ctf/default.cfg

sv_loadentfiles 1 // load CTF-specific .ent files for id maps

The proper test case is to connect to server, check that DM4 looks ok, then switch to /ctf, check that things moved around, and then go back to /2on2 or /4on4 and make sure they're back to normal.

3- (flamesuit on) QW CTF needs the hook and runes enabled by default (/nohook and /norunes to toggle). They were disabled for the #capture33 movement, but unfortunately the ability to toggle them was restricted to admins at the same time

Thanks!
BLooD_DoG

These servers are running nQuakesv:
feijoada.no-ip.org:27501 ktx
feijoada.no-ip.org:27502 ktx
feijoada.no-ip.org:30000 qwfwd

installation was a breeze.
im in love
=)

I strongly recommend to use following settings:
k_extralog 0
sv_demoUseCache 1
fs_cache 0

Helps to remove PL on weak servers and cheap VPS.

very nice, I have installed this on my servers:

quakeworld.chickenkiller.com:28501 ktx
quakeworld.chickenkiller.com:28502 ktx
quakeworld.chickenkiller.com:30000 qwfwd

Blaze: implemented before you even wrote it, I believe.

How important is it that sv_serverip matches your external IP?

Can it be set to e.g. fnu.nu if the host has dynamic IP? Can it be left blank?

I'm wondering because if it has to be an IP number, nQuakesv can't be installed on dynamic IP hosts.

I have plans on adding an "install_fortress.sh" script to nQuake that installs a TF port.

And a "install_ffa.sh" that creates an ffa server like xs4all.

(Edited 2012-08-26, 09:29)

I've finished the Team Fortress addon for nQuakesv.

However, it's not working as it should.

VM_Load: "qwprogs"
Sending heartbeat to 188.40.112.251:27000
Sending heartbeat to 194.48.213.72:27000
ERROR: SV_Error: PR_ExecuteProgram: NULL function

Anyone know how to fix this error?

You can try the addon by editing the "install_fortress.sh" file in the addon/ directory. Remove the lines stopping the script at the top. Then run the script.

(Edited 2012-08-26, 16:26)

It's very important that the IP matches to the ip-address to be connected from the internet. Also the port needs to be configured properly. If you fail to configure the sv_serverip properly, the server will not be connectable.

You can always turn off sv_getrealip (from 2 to 1 or 0) but this is a "security risk" in a way that you can't see the players ip in certain situations (proxies, hacked clients) and you can't do anything to abusers who connect through proxies.

Ah. I understand.

So it needs to be an actual IP, not a dns like fnu.nu? Because fnu.nu will resolve to the internet IP in my example.

Yeah, it has to be the ip-address people use to connect to the server from the internet (= external address if you are behind a NAT).

I get the same error with Clan Arena.

ERROR: SV_Error: PR_ExecuteProgram: NULL function

If nobody can figure this error message out, the Clan Arena and Team Fortress addons for nQuake won't be happening.

This is the only error message that I need to fix to release them.

The thing they both have in common are .dat qwprogs. However, I'm using the sv_progtype 0 variable to fix that.

(Edited 2012-08-29, 17:56)

Couple of things:

1- You put the CTF .ent files in nquakesv/ctf/maps/*.ent, but they aren't properly loaded from there. You need to put them in nquakesv/qw/maps/ctf

2- I tried TF and CA and had the same error as you. For fun, I started to debug mvdsv even though I know nothing about it. I got fed up and just asked Rusty who runs a CA server if he knew what to do. He said he had the same issue at first, and the fix is to run the 32-bit MVDSV, even if on a 64-bit machine.

01:25:12] <@Rusty`> 00[04:19:10] (Rusty`) i still seem to be getting the same message with 0.30 however when trying to run CACE (if anyone has any idea)
[01:25:12] <@Rusty`> 00[04:19:18] (Rusty`) VM_Load: "qwprogs"
[01:25:12] <@Rusty`> 00[04:19:18] (Rusty`) SV_Error: PR_ExecuteProgram: NULL function
[01:25:35] <@Rusty`> duerk bisected it
[01:25:38] <@Rusty`> and i think they fixed my error
[01:25:39] <@Rusty`> sec
[01:25:40] <@Rusty`> reading the log
[01:28:07] <@Rusty`> okay
[01:28:11] <@Rusty`> it doesnt run 64 bit
[01:28:13] <@Rusty`> thats the problem
[01:28:34] <@Rusty`> the mvsdv needs to be compiled as 32 bit
[01:28:38] <@Rusty`> even on a 64 bit system
[01:28:57] <@Rusty`> something went wonky with extending CACE to accept 0.30+ in 64 bit
[01:29:16] <@Rusty`> duerk said
[01:29:21] <@Rusty`> when compiling, use "make FORCE32BITFLAGS=-m32"
[01:29:24] <@Rusty`> instead of just make

I compiled mvdsv with that flag and confirmed that both CA and TF run fine... Don't know what the downside is of a 32-bit MVDSV on a 64-bit machine. You may want to consider using the 64-bit MVDSV for all ktx modes, and a 32-bit version with a different name that gets executed for CA and TF.

(Edited 2012-08-30, 05:51)

That's really bad news.

I can't even run the 32-bit mvdsv binary that comes with nQuake on my 64-bit system.

Is there any simple way of downloading sources to let the user just issue 1 command to compile his own 32-bit mvdsv binary?

I will fix the ctf thing tonight.

(Edited 2012-08-30, 06:17)

I've made a compilation script for this.

Sadly, mvdsv won't compile.



This is what "make" gets me:



(Edited 2012-08-30, 11:05)

Todo:

* Better integration of addons.
* Possibility to have more than one port of addons.
* Possibility to add ports after installation (add_ports.sh).

You need gcc-4.X-multilib and later on probably other 32bit libraries too.

However compiling 32bit binaries for all architectures is just an ugly workaround, would be better if the devs could actually fix their problems.

(Edited 2012-08-30, 13:54)