Dear Spike, gamers, programmers and Quake fans. Could any of you lend any knowledge about multiplayer capabilities for FitzQuake Mark V? Does one need to setup static ip, forward ports and establish DMZ for good old coop with a friend over the internet (local server)?
I found Mark V enging is very good and i love it. But Quake without coop is not complete. 

As far as I know you simply have one player start the game as a host and the other type in the IP address of the host in the join menu, same as usual. 192.168.whatever.whatever.

On Windows you can do Winkey, type run, hit enter, type ipconfig, hit enter then look for ipv4 address. 

You're assuming a LAN game tho. Cadaver747 sounds like probably he's talking about co-oping over the internet?

Baker would of course be the best guy to ask about Mark V's port usage. I'm pretty sure I recall that he's included some of the fixes done in a few modern NetQuake engines so that it only requires its single listen port (26000?) to be forwarded. 

for engines using a single server port, just reconfigure your router to forward that sepecific port (26000 for nq servers, 27500 for qw servers) to your machine, then eg google for 'ip' and give that to your friend to connect to (don't depend upon windows - it'll show you addresses that are only valid on your lan, which is not what you want).

for other engines, you'll need to set up dmz stuff crippling your router's nat+firewall stuff, as get your friend to do the same.

all quakeworld servers+fte+dp+qss+markv use a single port for connections. the rest all suck big hairy donkey balls (including quakespasm) at least for internet coop.
this is not the only reason that most people favour quakeworld for online play, prediction is another significant factor...

sidenote: with the exception of non-fte quakeworld, the above engines all also support ipv6. assuming your isp isn't dragging their heals and generally being lame then ipv6 makes things cleaner by removing the need for NATs. You'll still be firewalled by any good router though.

lazy people: if your router follows certain ICE-friendly rules (eg most home routers but few business ones), you may find that just setting sv_public 1 on your server is enough (the heartbeats should automatically open your firewall/nat).
the other person can then use their client's menus to find your server according to its hostname cvar - if they can spot it. This should be true of FTE+DP+QSS, but I don't think markv supports any real master server protocol so good luck with that.
probably the server listed by the master will appear to use a different ip+port, that's just the nature of NATs, but means they can't use a direct connect command.
But again, this depends on the server's router, so it might not work. Setting up explicit port forwarding on your router should fix it for any other routers.

do not use 192.168.x.x over the internet. it will not work. 169.254.x.x won't leave your lan. 10.x.x.x is another unroutable one, 127.x.x.x is also not going to work, 172.16.x.x/12 isn't going to go far either , and 100.64.x.x/10 means you're fucked and need to get a new ISP (carrier-grade NAT - this would only be between you and your isp, so you're likely to be screwed without otherwise noticing it) - ipv6 is your only real choice when it comes to CGNAT, or just get the other person to host. 

Thank you Spike! I tested Mark V 1.36 and 1.60 (beta) for coop with my friend over the internet today. It works like a charm, just a simple port forwarding from my external ip 77.50.xx.xxx to internal 192.168.x.xxx (for port 26000) and that's it!
You wouldn't believe what i tried to do to play Quakespasm online. Mark V rules!

Too bad not all maps from Arcane Dimensions currently supported by it. But i'm sure that'll be fixed in time. 

Cadaver747, you and your friend could also try connecting to FvF, which is almost always in co-op mode. Then you don't have to mess with running your own server (though it sounds like Mark V made that easy for you anyway). Other people might connect to FvF and join you as well. It's... different than standard Quake, with lots of cool options and enhancements.

connect fvf.servequake.com

www.fvfonline.com 

Correction, only 1 map doesn't work, it's ad_sepulcher (The Forgotten Sepulcher).
Host_Error: ModLoadLeafs: 74168 leafs exceeds limit of 65535 

Thank you Gunter, but unfortunately your server is not meant to connect from my country (Russia), ping is almost 150. The idea of implementing RPG elements in Quake is quite interesting though. 

ad_sepulcher needs a bit more than just the standard "big map" support.

It's also the case that there are a handful of big static arrays scattered about the engine for which, by the time you move to supporting ad_sepulcher sized maps, you really need to move to dynamic allocation.

Finally, ad_sepulcher is going to run like shit in the GL version of MarkV because it still uses glBegin/glEnd code. It will run fine, but still far more poorly than it should, in the D3D9 version because it's transferring a lot of vertexes that don't even change to the GPU each frame. The particle system may however kill it with draw call counts; IIRC there's some very sub-optimal state change stuff hanging over from the original GLQuake still in the sprite code, and that's going to prevent the D3D wrapper from being able to batch things up. 

Man, I would have killed for a 150 ping 15 years ago when I was still using dialup and playing lots of Quake, and still kicking butt in deathmatch :D

But these days people think a 150 ping is unplayable, even in coop! ;) 

ad_sepulcher doesn't run reliably in QS either. It crashed from time to time while I played, which forced me to quicksave often.

Making an engine that runs it reliably seems to be one of the ultimate challenges in Quake engine coding. 

That's interesting; I would have thought that QS was the target engine when the map was being built, and would have received the most testing through all iterations of the build. 

 

Well, my laptop has an Intel HD Graphics 3000 GPU and 6 GB of RAM, running Windows 7 64-bit. And the crashes happens after exploring the map for a while. First the engine starts stuttering and the hard drive starts making noise like crazy, and then the engine crashes. 

...the hard drive starts making noise like crazy...

Sounds like something else wrong with your machine that's only manifesting when it's under a particular load. There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory. 

Baker I'm 99% done adding ogg/mp3 to Qrack using fmod.
It's *way* simplier than you might think. Only thing i have to do is add a cvar to init/uninit the fmod instead of using a command-line parm.
I can shoot you a copy of my fmod.c file. There are other entry points where it plays cd tracks but they all points to functions contained in that one fmod.c file.

It's so simple i was kicking myself for not adding it sooner; not until i read here people yelling "OGG SUPPORT!" did i even pursue it. Know you use fmod, i thought i'd pass it along. 

I'm not sure if there is anything special about ad_sepulcher that makes it difficult to run - it has careful visblocking and with the fixes to func_detail in qbsp I made, the PVS is good quality. I'd expect it to have similar fps to other large maps in AD (and it does in my experience).

(The exception is if the engine supports the fancy particle extensions, i.e. QSS. Particle effects for all torches in the map render every frame without regards to the pvs. Also, various particle effects cause tracelines to run. This applies to all of AD, though it probably has the biggest hit on sepulcher due to probably having the most torches.)

Sorry to hear it crashed for you mankrip. The only thing I know that could cause disk thrashing is Quakespasm uses the original Cache_* code, which, if the cache is too small, will cause it to read MDL's off disk every frame. This is something I want to fix and I know of mh's tutorial on insideqc about it. Do you remember if you used an explicit size with the -cache command-line argument? 

There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.

Windows automatically stores RAM contents in the swap file, you know. And it also happened without anything else running, right after I had to reboot because the whole OS got unresponsive.

I might run it again later and take a look at the RAM/CPU/etc usage in the task manager. 

Do you remember if you used an explicit size with the -cache command-line argument?

IIRC I've only used the parameters recommended in the readme file. I may look into it after going back home. 

There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.

If the quake cache is too small, quake will keep unloading models to make room for new models. A bigger heapsize solves this I think. (in engines with standard quake caching/memory logic.) 

Yeah, the caching system is really the only thing, other than some kind of hardware failure, that could cause this.

It's worth observing that if one is using a replacement/"improved" MDL pack, they're going to consume more cache space and therefore have a higher likelihood of triggering this kind of behaviour. 

This seems to have gotten lost in the noise.

From the description it seems that MarkV doesn't have the robust SV_TouchLinks fix. Some discussion: http://forums.insideqc.com/viewtopic.php?f=3&t=1431 

Just had a look at the MarkV SV_TouchLinks fix. It's, umm... unusual...

My recollection is that QSS has a sensible fix that's absolutely trivial to lift over to any engine, so that should be the way to go. 

An interesting observation about MDL caching.

It's possible for 2 or more MDL files to only differ in terms of the skins they use; otherwise they have identical geometry (vertices, frames, triangles, stverts).

You'd think this would be a theoretical possibility at best, but it actually happens in ID1: progs/spike.mdl and progs/s_spike.mdl are identical aside from skins.

Load up ad_sepulcher and there are about 30 MDLs where this happens.

So to save memory with MDL caching, and also potentially save memory with VBOs if you use them, this is something you could check for, without being too disruptive to the rest of your code. 

I don't know if the SV_TouchLinks thing is similar to the old engine-crashing teleporters without proper destinations bug, but a QuakeC fix is mentioned here: https://www.quake-info-pool.net/q1/qcwa.htm#trigger_teleport