For Quake 1, you need to keep in mind there are two completely different options, and mods have to be specifically designed around either of these options: NetQuake, and QuakeWorld.

NetQuake refers to the original netcode that Quake shipped with, it's client server, but there's absolutely NO client-side prediction. Everyone's client is a "dumb terminal", the server is in control of absolutely every aspect of the game state. This means that lag is immediately noticeable. The server doesn't send a whole lot of frames for the client to work with so on the clientside a type of linear interpolation is used to extrapolate these frames.

QuakeWorld which came out later, has a more "modern" kind of networking where clients are given the ability to perform some basic level of prediction by running some of the gamestate themselves, and the server corrects when things don't line up. A lot less bandwidth usage, a lot less lag perception. But due to how all that works any mods that were made for how things originally work have to be re-written/re-compiled for QuakeWorld.

If a Quake 1 mod only supports NetQuake then there will only be a "PROGS.DAT" in it's PAK or folder, but if it supports QuakeWorld, there will be a "QWPROGS.DAT" or something similiar in addition to a "PROGS.DAT", keep that in mind if you want to do QuakeWorld with any kind of mod.

For Unreal and Unreal Tournament, all you need to know about things security-wise is that the default IpDrv is very naive and will happily accept certain packets that really shouldn't have shown up in the first place, the so called "fake players" bug. There's a third party fix for that called "Nephthys" that will solve most of those security flaws. Port forwarding is also very simple, you only ever really need one port open for anybody to connect to, and if you planned on having the server able to be queried, you need to open the port for that as well. 7777 is the default port for player connections and 7778 is the default for queries. These ports can be changed in the Unreal.ini/UnrealTournament.ini files

I would honestly suggest Unreal 1 over UT because I absolutely, hate dealing with the netcode in Unreal Tournament, it's very very buggy more so than Unreal 1 running on the 225f patch. (Which by the way, anybody hosting a Unreal 1 server should ONLY USE the 225f patch)

I like the idea, wouldn't be a bad idea to make it a thing here on vogons, so you have a retro server with retro machines playing on it.

DracoNihil wrote on 2023-03-23, 14:56:

For Quake 1, you need to keep in mind there are two completely different options, and mods have to be specifically designed arou […]
Show full quote

For Quake 1, you need to keep in mind there are two completely different options, and mods have to be specifically designed around either of these options: NetQuake, and QuakeWorld.

NetQuake refers to the original netcode that Quake shipped with, it's client server, but there's absolutely NO client-side prediction. Everyone's client is a "dumb terminal", the server is in control of absolutely every aspect of the game state. This means that lag is immediately noticeable. The server doesn't send a whole lot of frames for the client to work with so on the clientside a type of linear interpolation is used to extrapolate these frames.

QuakeWorld which came out later, has a more "modern" kind of networking where clients are given the ability to perform some basic level of prediction by running some of the gamestate themselves, and the server corrects when things don't line up. A lot less bandwidth usage, a lot less lag perception. But due to how all that works any mods that were made for how things originally work have to be re-written/re-compiled for QuakeWorld.

If a Quake 1 mod only supports NetQuake then there will only be a "PROGS.DAT" in it's PAK or folder, but if it supports QuakeWorld, there will be a "QWPROGS.DAT" or something similiar in addition to a "PROGS.DAT", keep that in mind if you want to do QuakeWorld with any kind of mod.

For Unreal and Unreal Tournament, all you need to know about things security-wise is that the default IpDrv is very naive and will happily accept certain packets that really shouldn't have shown up in the first place, the so called "fake players" bug. There's a third party fix for that called "Nephthys" that will solve most of those security flaws. Port forwarding is also very simple, you only ever really need one port open for anybody to connect to, and if you planned on having the server able to be queried, you need to open the port for that as well. 7777 is the default port for player connections and 7778 is the default for queries. These ports can be changed in the Unreal.ini/UnrealTournament.ini files

I would honestly suggest Unreal 1 over UT because I absolutely, hate dealing with the netcode in Unreal Tournament, it's very very buggy more so than Unreal 1 running on the 225f patch. (Which by the way, anybody hosting a Unreal 1 server should ONLY USE the 225f patch)

What a lesson! 😁 I played very little QW and a lot of OG Quake back in the day, I didn't know how drastic was the difference at the networking logic level, maybe I will create both!

I will have to do some research on what mods to use in order to have some level of security or anti-cheat, but I will probably do this the same way I work projects in my professional life, deliver quick and increment often.

So I will probably get some servers up in the next couple of weekends to see how it goes and work from there, there is a lot of stuff to do before the server goes live.

I was thinking about Unreal as well since there is still UT servers online that everyone can play using Oldunreal, but there is not a lot of OG Unreal servers, I could create UT as well, with the hardware and bandwidth we have today we can run a lot of servers with no sweat.

Thanks a lot for all the info! I will def use it!

iraito wrote on 2023-03-23, 15:33:

I like the idea, wouldn't be a bad idea to make it a thing here on vogons, so you have a retro server with retro machines playing on it.

I will try, the greatest challenge is popularity I think, this will be worthless if no one uses it.
I will give it a try anyway, I have created some servers of games I played just for fun in the past (UT, 7DTD, Killing Floor 2), for me is like a therapy doing these things.
I will keep this updated, thanks for the support! 😁

jonesmacarrones wrote on 2023-03-23, 16:12:

I was thinking about Unreal as well since there is still UT servers online that everyone can play using Oldunreal, but there is not a lot of OG Unreal servers, I could create UT as well, with the hardware and bandwidth we have today we can run a lot of servers with no sweat.

Thanks a lot for all the info! I will def use it!

I've used to host my own Unreal 1 server many, many years ago. Mostly just as a exposition of the content I create for myself that only I enjoy myself but hosting a server generally meant somebody could join and atleast try to interact with me in some meaningful fashion or offer some kind of constructive criticism. One thing I can't stress enough about this, if you want to host a Unreal 1 server, you absolutely must use version 225f. This means you can't use a copy of Unreal Gold for this purpose, it has to be a original retail Unreal 1 CD as it was when it hit stores in 1998.

For Unreal Tournament, 436 is the only thing you need. You can very, very easily get a proper 436 setup because Epic released a installer for that patch that doesn't work via delta values and just has all the raw files of that version implicitly, they did this because of running into complaints of being unable to patch the game due to having OEM copies of the game that were pre-patched to some other release version, and thus the deltas were invalid. Nephthys exists for version 436 of Unreal Tournament as well so you don't have to worry about "fake players" and many other script kiddie DoS attacks.

I highly recommend not bothering with "227" or "469", both of those so-called fan patches have suffered greatly from out of control mission creep and bloat, and even include code of dubious legality. I pretty much had to get out of all related forums because I couldn't stand what was going on, and pretty much everybody alienated me anyways.

Unreal 1 can easily get running on modern systems simply by either, significantly limiting your GL_EXTENSIONS string so the original OpenGLDrv can function without a buffer overflow, or getting Chris' UTGLR compiled against the Unreal Gold 226 public headers. Retail Unreal patched to 225f can function just fine with most glide wrappers including zeckenzack's and nGlide. UTGLR can only be compiled against Unreal Gold or version 224, because the 225f public headers were "mistakenly lost" when Epic was trying to create the 226 version patch. I have never ran into any issues with NX bit/"Data Execution Prevention" with the Unreal Engine 1 games and I'm currently on a Core i7 Skylake. Really all one needs is to use a renderer that will cooperate and limit your framerate to 60 FPS. No other fix is necessary or dubious "third party patch project" is required for Unreal 1 or Unreal Tournament.

DracoNihil wrote on 2023-03-23, 17:09:

I've used to host my own Unreal 1 server many, many years ago. Mostly just as a exposition of the content I create for myself that only I enjoy myself but hosting a server generally meant somebody could join and atleast try to interact with me in some meaningful fashion or offer some kind of constructive criticism. One thing I can't stress enough about this, if you want to host a Unreal 1 server, you absolutely must use version 225f. This means you can't use a copy of Unreal Gold for this purpose, it has to be a original retail Unreal 1 CD as it was when it hit stores in 1998.

What's the reason gold/226 can't be used?

Oetker wrote on 2023-03-24, 09:47:

What's the reason gold/226 can't be used?

If someone has 226f installed instead of Unreal Gold, which is the case if someone patches retail Unreal 1 to 226f, then if that someone tries to connect to a Unreal Gold server, they will immediately crash with a assertion failed because of a name table incompatibility, the vice versa applies if a Unreal Gold user tries to connect to a server running 226f.

There's also general instability with the netcode itself, various stuff not replicating correctly no matter the correct replication statements in the actor itself and if you were to reconnect to such a server without opening a map locally in singleplayer and typing "OBJ GARBAGE" before connecting to the server again, every single actor in the map is ghosted on your client and you'll have doubles of everything. (This will stack for each additional reconnection)

224, and 225f don't have that name table incompatibility so it doesn't matter if someone with 226f or Unreal Gold tries to connect to such a server.

DracoNihil wrote on 2023-03-23, 17:09:

I highly recommend not bothering with "227" or "469", both of those so-called fan patches have suffered greatly from out of control mission creep and bloat, and even include code of dubious legality. I pretty much had to get out of all related forums because I couldn't stand what was going on, and pretty much everybody alienated me anyways.

not disagreeing with this, but to be fair it needs to be pointed out that one of the last 469 builds has finally fixed UT's issues when running above 100 FPS or so and that's a pretty big deal for anything newer than pentium iii era machines. this is also network compatible with 436 clients so there's no need to even install anything as long as the server is running 469.

auron wrote on 2023-03-28, 21:41:

not disagreeing with this, but to be fair it needs to be pointed out that one of the last 469 builds has finally fixed UT's issues when running above 100 FPS

This can be fixed with a hex edit in Engine.dll, it was documented in a Steam Community post for Deus Ex 1 but the instructions are easily adaptable even though the bytes you have to change are in a completely different spot.

Even still, because of how Fire.dll textures work and since "MaxFramerate" is not set in Texture's defaultproperties to atleast 60, any of those will animate way faster than intended. Console commands can easily fix this however. I don't know how those textures will look on high refreshrate monitors but they've never been intended to animate any faster than 60 FPS, some of those don't even look good animating any faster than 25 FPS.

if the framerate issues can really be fixed with a hexedit that's good to know, never caught that info before. does this even work as a clientside fix when connecting to pre-469 servers? i was aware of the animated textures running fast but never perceived it as distractingly jarring at 200 fps, this is probably a similar matter to the GOTY S3TC replacement textures where i'm sure some people perceive them as clashing with the remaining stock textures while others are fine with them, and then there's the old single-pass vs. multi-pass texturing differences that a lot of people probably aren't even aware of.

the key aspect for me is that sub-100 (though you really needed to set 90 max due to the imprecise cap) FPS just looks very choppy on 60 hz monitors, and vsync is not an acceptable option in a fast game like this.

auron wrote on 2023-03-29, 02:24:

if the framerate issues can really be fixed with a hexedit that's good to know, never caught that info before. does this even work as a clientside fix when connecting to pre-469 servers?

The way the netcode works you're forced to a specific locked FPS depending on your NETSPEED and the server processes everything on a fixed framerate as defined by the "NetTickRate" variable.

I'm pretty sure server owners would need to do the same Engine.dll hex edit for tick rates greater than 119 to work properly but you generally do not want to run a server with a massive tick rate as the networking code has a hardcoded upper bandwidth limit and cannot keep up with fast tick rate settings when enough people are connected at once. (You can't use a NETSPEED greater than 25000 even if the server puts something higher than that)

jonesmacarrones wrote on 2023-03-22, 19:42:

Also I am interested to hear if this is a terrible idea, even from a security standpoint, I am thinking about using VMs, preferably isolated from my main network, but I don't know a lot about security other than the basics.

Yes, I'd definitely do those sorts of things! Possibly even use a physical machine so there's no question of someone breaking out of the VM.

I always imagined that for something like this it might be useful to have a system of some sort where people can register their interest for particular games and what days/times they're generally available to play, then try to schedule times when the most people are available, a bit like shared calendars in Outlook. Of course that is more work, but I would worry that if not for that, there wouldn't be enough people so we'd all just join the servers occasionally and find nobody else there.

I'm sort of interested myself, but I imagine that I might not ever get around to actually joining anyway 🙁

I would suggest running some ipxbox instances.

You can connect to ipxbox with DOSBox or real hardware using the dali utility.

What would be cool is if we had some kind of frontend to manage these instances. A DOS utility to browse servers, show number of connected parties, and automatically run dali to connect.

there is also ipxgw, and strangely enough another ipxbox that predates the aforementioned one. but from what i understand all of these have in common that they need to be compiled and only target linux, so that would leave a lot of users out. however, recently a serial generator has been added to the official kali website: https://sites.google.com/kali.net/kalinet/home

i haven't tested whether the serials work in the DOS version, and the download is probably just the windows version, but kali seems like a good option to connect dosbox with real PCs.

keenmaster486 wrote on 2023-04-04, 02:04:

I would suggest running some ipxbox instances.

You can connect to ipxbox with DOSBox or real hardware using the dali utility.

What would be cool is if we had some kind of frontend to manage these instances. A DOS utility to browse servers, show number of connected parties, and automatically run dali to connect.

Yeah, that'd be really nice to have. Proper IPX tunneling that both DOSBox people and real hardware people can use over the internet for all these games stuck using IPX. I have to wonder if the reason why Microsoft Hellbender had such laggy multiplayer despite running TCP/IP direct connection on a LAN was because I wasn't doing local area network via IPX instead.

Then again the netcode in Terminal Velocity wasn't much better either and as far as I know is the same kind of netcode being used in Hellbender, except via DirectPlay.

auron wrote on 2023-04-07, 02:50:

there is also ipxgw, and strangely enough another ipxbox that predates the aforementioned one. but from what i understand all of these have in common that they need to be compiled and only target linux, so that would leave a lot of users out.

Maybe if they're run in a virtual machine which has interface(s) bridged to physical interface(s) on the host, non-Linux users could use it? Of course then there's still the problem that someone who isn't familiar with Linux needs to learn how to install Linux, build and configure the gateway, etc. Perhaps someone could make a virtual appliance: a packaged VM image (e.g. an .ova file) where the user just has to set up some bridged interface(s), then when the VM powers up it has a pre-compiled copy of one of these tools start up automatically. It could potentially even have a basic configuration interface which runs under Linux and launches on the console without requiring login. I've seen this kind of thing done with commercial virtual appliances but I've never tried using them with the sort of hypervisors that home users use. I'd like to think that these tools are simple enough that it shouldn't be too hard to do. I'd be happy to answer questions if someone else wanted to try to make something like this.

jonesmacarrones wrote on 2023-03-22, 19:42:

Hi all. […]
Show full quote

Hi all.

I am considering spinning up some servers to play on original hardware, I have the hardware and bandwidth to do it.
I would find amazing if I could play a deathmatch in Quake using my retro machine in a populated server.

Would that interest you? Would you use such servers? Would you pwn the noobz like is 1997? 😜

Also I am interested to hear if this is a terrible idea, even from a security standpoint, I am thinking about using VMs, preferably isolated from my main network, but I don't know a lot about security other than the basics.

Thanks!

I would love it 😍

I made some tests about this, both with UDP and IPX over Internet:

• UDP multiplayer
  Recently I tested Quake II coop with a friend of mine, as I wrote in this thread.
  I used an AWS EC2 (the free tier) in which I installed a Quake II server trough game-data-packager and quake2-server (I had to copy a zip of the game files from my local machine to the EC2 through scp).
  I experienced severe lag on my PII build, but I think it is caused by the ISA ethernet card, which cannot keep up with modern Mac Internet speed. Maybe there will not be lag if all clients are retro PC.
• IPX over Internet multiplayer
  I used the already mentioned ipxbox in a Linux machine, connected to my local LAN, and a virtual LAN (ZeroTier One) to play The Ultimate DOOM between my retro Pentium MMX PC and my friend's DosBox, where the latter would connect to ipxbox through the virtual LAN.
  Unfortunately, the lag (experienced both by me and my friend) made the game unplayable. Don't know if it's a limit of the IPX protocol (made for local networks) or of my retro build NIC.

Demetrio wrote on 2023-04-10, 07:31:

I made some tests about this, both with UDP and IPX over Internet: […]
Show full quote

I made some tests about this, both with UDP and IPX over Internet:

• UDP multiplayer
  Recently I tested Quake II coop with a friend of mine, as I wrote in this thread.
  I used an AWS EC2 (the free tier) in which I installed a Quake II server trough game-data-packager and quake2-server (I had to copy a zip of the game files from my local machine to the EC2 through scp).
  I experienced severe lag on my PII build, but I think it is caused by the ISA ethernet card, which cannot keep up with modern Mac Internet speed. Maybe there will not be lag if all clients are retro PC.
• IPX over Internet multiplayer
  I used the already mentioned ipxbox in a Linux machine, connected to my local LAN, and a virtual LAN (ZeroTier One) to play The Ultimate DOOM between my retro Pentium MMX PC and my friend's DosBox, where the latter would connect to ipxbox through the virtual LAN.
  Unfortunately, the lag (experienced both by me and my friend) made the game unplayable. Don't know if it's a limit of the IPX protocol (made for local networks) or of my retro build NIC.

I see two problems here:
1. Using AWS
2. Using "ZeroTier One"

Try those servers first using local play, then normal port forwarding on your router, with both parties having good broadband connections, without any third party services, before you draw any conclusions.

It sounds like ZeroTier One does involve a direct connection rather than routing packets via a third party?

I can't imagine Doom's network code dealing too well with the latency - and the variations in latency - of the Internet, when it was designed to work on a LAN. Maybe the Internet performs so well these days that the latency through it (at least for average cases) isn't significantly different from that of a slow 486 PC with an ISA NIC? But if you're actually using an old PC you're adding somewhat contemporary LAN latency together with Internet latency.

And no matter how much faster our PCs, network devices and network links are than they used to be 30 years ago, the speed of light still factors in: if you're talking about long distances (e.g. your friend is on the other side of the world) we can't get any better than hundreds of milliseconds, which I presume would be considered very slow even for 30 year old LANs.