Hard Light Productions Forums
General FreeSpace => Multiplayer => Topic started by: AdmiralRalwood on February 18, 2016, 03:17:36 pm
-
So it's common knowledge that FSO multiplayer is generally not considered playable. As somebody who has actually attempted it (as recently as today, in fact), I feel like I can safely say that common knowledge in this regard is correct: in both PVP and PVE, any latency greater than that of a LAN connection is basically untenable; there's a lot of shooting of empty space in order to deal damage involved, the UX is lousy (can't look at the server list without disconnecting yourself from chat because...?), and it's just generally the least-upgraded portion of a codebase that's otherwise been seeing lots of incremental improvements over the past decade-and-change.
However, it's undeniable that there used to be people who played multiplayer with retail FS2. This led to a question: does retail actually behave differently than FSO in multiplayer, on a fundamental level?
Having recently done a direct IP game as both host and client with the retail executable, I feel that I can confidently state that it does not.
Which leads to other question questions, like: did people tolerate lag more back in the 90s, or were they just generally playing with lower pings?
Another possibility is that, since retail locked multiplayer difficulty but FSO does not (and it's therefore possible, although not recommended, to play multi on Insane with FSO), do difficulty level changes simply make the problems of latency more pronounced (e.g. AI ships maneuvering more, players running out of energy faster and making misses more costly, etc.)?
If anyone who used to play multiplayer back in the day is still around, I'd love to hear some firsthand experiences, especially if you can compare it to a recent build of FSO. If anyone would like to get a multiplayer game going for the purposes of testing or comparison, I'd be happy to assist there as well.
Finally, if anyone has any ideas for simple changes for how multiplayer could be made more user-friendly (assuming that anybody who had ideas for improving the notcode itself would've already spoken up by now, but hey, if you have ideas there, I'd love to hear them, too), I'm all ears.
-
Likely, people have tolerated lag since it was more consistent than today's connections, in particular on home networks that use a wireless router or any ISP that has a wireless link somewhere. Higher traffic on the servers might also be to blame.
Client side, the hitboxes of the weapon projectiles might have been larger than they are now. A larger hitbox means it's easier to score a hit against a target, but also means "narrow miss" don't happen.
I seem to remember some visual aids in the multiplayer code that are supposed to help visualize how the engine handles the physics and positioning. Something about B-splines and maybe cones of uncertainty?
-
At least some of it, I suspect, has to do with the variety of connection speeds now as opposed to when the game was designed. People's level of lag and desync can vary much more wildly.
Desync was pretty much expected for a period of time encompassing about FS2 multi to MechWarrior 3 multi; nobody would be where they actually appeared to be in a match and people didn't like it but they got used to it. People hadn't tolerated that before, though, with Duke Nukem 3D's or Doom's multi communities doing all they could to fight this sort of issue, and after FS2 people stopped tolerating it again pretty quickly with games like Battlefield 1942. Today that sort of thing can sink a game. FS2 existed in a brief space of time where having netcode that did that sort of thing was considered "okay".
-
Well if the problem isn't bugs so much as the fundamental design of multiplayer, that means that a refactor is needed. Which is going to be difficult given that none of the coders on here play multi that much.
-
Client side, the hitboxes of the weapon projectiles might have been larger than they are now. A larger hitbox means it's easier to score a hit against a target, but also means "narrow miss" don't happen.
I can assure you that the experience with the retail executable and FSO running retail data is exactly the same; it's no easier nor harder to score hits in retail multiplayer.
-
Well if the problem isn't bugs so much as the fundamental design of multiplayer, that means that a refactor is needed. Which is going to be difficult given that none of the coders on here play multi that much.
As some of you know (especially in SCP), I am interested in improving the netcode and have been taking steps in that direction, such as removing outdated code (IPX support) and switching to cross-platform networking technology (Boost Asio).
However, as many of you also know, I am legally blind now and can no longer play FS2 or other FSO-based games. Thus I'm concerned that I'm eventually going to hit a wall where I can't contribute any further because I just don't see well enough to debug an issue.
Well actually, I can complete FS2 Training Mission 3 where you shoot the drones, although it takes a little while. If I can do that, maybe my vision is good enough to do this? EDIT: It'd help if there were no nebula images and just a plain black starfield. Larger HUD gauges wouldn't hurt either.
In short, I'd like to give it a shot. :) But I can't promise how far I'll be able to take it.
-
Well I've managed to get time to start FREDding and coding again so my offer to help still stands. I managed to get FS2_Open to compile and run on my Banana Pi so I can once again run a standalone for testing too.
-
Well actually, I can complete FS2 Training Mission 3 where you shoot the drones, although it takes a little while. If I can do that, maybe my vision is good enough to do this? EDIT: It'd help if there were no nebula images and just a plain black starfield. Larger HUD gauges wouldn't hurt either.
In short, I'd like to give it a shot. :) But I can't promise how far I'll be able to take it.
I know the HUD gauge scaling can be tweaked via tables, and I'm sure someone could whip up some high-contrast textures if it'd help you out. :)
-
Well I've managed to get time to start FREDding and coding again so my offer to help still stands. I managed to get FS2_Open to compile and run on my Banana Pi so I can once again run a standalone for testing too.
Cool. The first step IMO is to gain a deep understanding of how the existing netcode works through documenting it. We'll continue the discussion elsewhere to avoid derailing this thread.
I know the HUD gauge scaling can be tweaked via tables, and I'm sure someone could whip up some high-contrast textures if it'd help you out. :)
Cool. Changes like these aren't pressing since they probably wouldn't be needed for quite a while, but it's good to know that they are possible.
-
It's good to have it confirmed that retail was just as difficult to score hits. It means we haven't drifted multiplayer to being worse via expanded packets sizes or less efficient handling or something. But it does indicate that not just a refactor, but probably an entirely new multiplayer model would be required to gain significant improvement, unless there's things in the existing multiplayer code that upon analysis are found to be obviously wrong and inefficient. It's happened with the engine's performance multiple times over, so maybe it could happen with the multiplayer code.
-
However, as many of you also know, I am legally blind now and can no longer play FS2 or other FSO-based games. Thus I'm concerned that I'm eventually going to hit a wall where I can't contribute any further because I just don't see well enough to debug an issue.
Well actually, I can complete FS2 Training Mission 3 where you shoot the drones, although it takes a little while. If I can do that, maybe my vision is good enough to do this? EDIT: It'd help if there were no nebula images and just a plain black starfield. Larger HUD gauges wouldn't hurt either.
In short, I'd like to give it a shot. :) But I can't promise how far I'll be able to take it.
This is terrible, I'm so sorry. I would definitely be willing to help you out per Mongoose's suggestion. Assuming you're willing to play with just retail data and not MediaVPs, I can create an alternate set of high-contrast maps, effects, and backgrounds for you in a couple hours. (Note to coders: this could be fun to use with a cel shader.)
In the meantime if you increase your gamma and/or the ambient lighting settings, that should help with the contrast issue. For the HUD, you could try playing at a lower resolution; all the interface art would be proportionately sized up.
Finally, if you haven't yet, you may find yourself able to play Windmills (http://www.hard-light.net/forums/index.php/topic,62062.0.html) without much trouble. :)
-
As Mongoose said, you can just enable HUD scaling in a table instead of playing at a lower resolution.
-
Thanks, guys! :) High-contrast artwork for retail assets would likely help, although I'm not totally sure what they'd look like. Being able to turn off the background (nebula images would help a lot, and I can try increasing the gamma and making the HUD gauges larger. Granted, I still won't be able to play it as an actual player (other than Windmills apparently?), but for the purposes of multi testing, those changes would likely help a lot.
Anyway, back to the OP:
The issue of multi being unplayable today while playable in the past has been bugging me. It doesn't make sense. Connection speeds are much faster since the late 90's/early 00's, with higher bandwidth and probably lower latencies (or at least not higher), and the Internet is likely at least as reliable as it was then if not more so, meaning there shouldn't be issues with more packets getting dropped and having to be retransmitted. So why was it playable then and then totally unplayable now?
One thing that probably has changed, however, is how people configure the game. Because connections were slower (lower bandwidth), people probably had lower (less demanding) settings for the multi/network options. I bet people nowadays use very high network settings. Maybe that's part of the problem? The options control how many objects are included in object updates, probably other stuff too.
Looking at the retail FS2 launcher's network options, I see the labels are very different from wxL's. I revised those labels in wxL which were based on 5.5g's a while back with help from KyadCK, but maybe we chose the wrong labels, given however the engine uses those settings.
I'm going to do some code reading and look more carefully at what factors the multi/network options, both in-game and in the launcher, control, then report back with some settings values I'd like people to try.
In the meantime, if people want to experiment with those settings, go right ahead. I'd suggest trying both a recent build of FSO and FS2 retail. Don't forget about the multi in-game options in addition to the launcher options.
Note that the code "assumes *nix (OS X/Linux/*BSD/etc.) players are on a broadband/LAN connection :wtf: so for players on those platforms, changing the connection type in the launcher actually does nothing, and the value listed in the launcher for connection type is meaningless. No idea why it was written that way. :nono:
EDIT: Correction.
-
Haven't had as much of a chance as I'd like to look into the code on this, but I had another thought:
You know how when emulators for old games like DOSBox run too fast, the game can get jerky or otherwise have poor performance? I wonder if something like that could be going on here. Computers are surely much faster than they were in 1999. With the standalone, you can set a frame cap, and it defaults to 30. Maybe that's the rate at which the server was intended to run?
I don't think there's a way to cap the frame rate when you're hosting the game on your own machine, but as mentioned, with the standalone you can cap the frame rate. You can either try chief's Unix standalone (ask him for login credentials) or I can set up a Windows standalone on my desktop for you to play on, provided you can find one more person to test, since I don't think I can play if I'm running the standalone. I live in U.S. Pacific Time. Windows standalone might be better since I don't know how well the Unix one works with setting frame cap and displaying FPS.
The idea is to try moving the frame cap up and down and see if there's a point where the game becomes more playable.
Mind you, the frame rate calculations use the same inaccurate 32-bit floating point math that was causing the supr high server pings, dunno if that'll be an issue. Probably should use builds with the ping fix that I've been working on so that you have accurate ping values.
Also, I'd suggest going into the in-game multi options menu and if your object update is set to LAN, reduce it to high. IIRC the LAN setting removes all limits on object update rate, so likely only usable if you actually are playing on a LAN. Reminds me of a label in wxL that should probably be fixed...
-
I don't think there's a way to cap the frame rate when you're hosting the game on your own machine
You can use the "MaxFPS" configuration value (that's in the registry on Windows, or the config file otherwise) to specify an FPS cap between 16 and 120 FPS (anything outside that range will result in the default of 120, although vsync and performance will of course determine whether or not you actually get 120 FPS).
-
I don't think there's a way to cap the frame rate when you're hosting the game on your own machine
You can use the "MaxFPS" configuration value (that's in the registry on Windows, or the config file otherwise) to specify an FPS cap between 16 and 120 FPS (anything outside that range will result in the default of 120, although vsync and performance will of course determine whether or not you actually get 120 FPS).
Good to know, thanks. The advantage of the standalone is that you can adjust the frame cap on the fly through the standalone GUI, whereas if you're hosting the game, you'd have to shut down the game, adjust the frame cap, and restart it.
-
The more I study the netcode, the more I think capping the frame rate is worth a try. It's not a long-term solution, but it'll tell us if higher frame rates are part of the problem.
I'd try capping the frame rate at 30 or perhaps a bit higher like 35 or 40. Set it for all clients and the server and see if the game becomes any more playable.
Might even be worth trying a bit below 30 like 25 although the game itself is probably less playable at that frame rate.
Also try varying the object update level specified in the in-game multi options menu. I wouldn't set it any higher than "High" (that is, not LAN).
-
JG18, I've made good on my promise and put together a high-contrast set of textures and backgrounds for you. I played a few missions, both open space and nebula, without my glasses, and managed pretty well; the main difficulty was in weapons and target management due to the HUD illegibility.
Hope this helps. (https://drive.google.com/file/d/0BwhLOWpTEeADR25Fb2s0X3FaWGM/view?usp=sharing)
-
I started playing this game a few months after it was released. I think the major internet access back then was dial-up 56k, T1, ADSL, DSL, and cable. So long as I played with somebody hosting on a cable modem, I did not see any noticeable lag. T1 was moderate lag from time to time, ADSL moderate lag on a more consistent basis, and DSL had slight lag.
I think lag now is more noticeable because of the faster connection speeds. We might have seen lag back in 2000, but recognized it as normal game play. In any case, I still can't get multiplayer to work on FSO and it's extremely complicated compared to retailer online :)
-
Please, please, yes, please. I've spent hours trying to get a LAN game set up which isn't helped by the wikis not matching the actual settings. The multi log says it's not actually detecting the IP address.
When I did get the game running in MP last year (almost the same setup, what gives?!) there was a noticeable shudder to the gameplay. Is it because the ships get put in places based upon just the delivered information, and the game does no guessing of where people would be? I've not seen any rubber-banding so that's what I'd suspect.
-
Throwing an observation and a thought out there.
1. Observation - With FringeSpace and StellarAssault, and to a large extent BTRL/Diaspora, what we experenced was equatable to clients not receiving hit data from the server.
IE if you were the host, you could play with other people and almost have a semi reasonable feeling game. If you were a client, nothing you fired had any affect on the target.
In SA we could literally park 3 clients and the host, and have clients shoot the host with very rapid fire weapons, and only one hit in dozens if not hundreds would register.
In FringeSpace we found roids had a significant impact on performance, particularly moving roids, but a similar result as to primary fired weapons, lead everyone to use missiles to deal any damage.
In Diaspora with the Raider, I can remember doing a deathmatch or survival in a hosted server from myself, and getting over a hundred kills easy. When we switched host, I had 8.
Now with that said, these observations were all on SCP builds going back about 5-6 years ago. I dropped experimenting on it since we had other problems come up.
I realize over the years various improvements were made here and there, as Fringe has been watching with anticipation for multi to work again.
My point being, that the core issue of hits not registering, seems to have remained the same over time.
2. Is there a way to test with the original PXO code still in place? See if that made a difference?
Alternatively, you mentioned jg18 that you removed IPX support. However, did anyone try IPX versus TCP/UDP to see if there was any difference?
There is a IPX wrapper that does work by translating the packets to UDP, and you can use it in conjunction with the Tunngle service to play over the net with any recent Windows edition.
We do this now for Tachyon, since it is in a similar situation, we can't use the internet lobby, and have to make do with a virtual LAN.
-
2. Is there a way to test with the original PXO code still in place? See if that made a difference?
PXO and FS2NetD should behave identically: namely, by helping the executables make a connection, but no impact on on in-game performance whatsoever.
-
You could give the icculus.org version a try in your testing too (the git version, not the svn one). There are a lot of fixes and optimizations but it's basically just a cross-platform, up-to-date, retail port. It's fully network and data compatible with the retail version. It also has full PXO compatibility with the retail version, minus one stats saving bug. And I can give you limited/private access to the PXO server for testing purposes if you want to try that out. My connection is pretty bandwidth limited so more than 2-3 connections will mess up your results. Works far better with Linux builds at the moment, but I can make some Windows builds available (with the odd hiccup or two) or you can just build them from source.
-
You could give the icculus.org version a try in your testing too (the git version, not the svn one). There are a lot of fixes and optimizations but it's basically just a cross-platform, up-to-date, retail port. It's fully network and data compatible with the retail version.
That makes testing it not terribly useful, because I've tested the actual retail executable, and it has exactly the same networking problems as FSO does.
-
You could give the icculus.org version a try in your testing too (the git version, not the svn one). There are a lot of fixes and optimizations but it's basically just a cross-platform, up-to-date, retail port. It's fully network and data compatible with the retail version. It also has full PXO compatibility with the retail version, minus one stats saving bug. And I can give you limited/private access to the PXO server for testing purposes if you want to try that out. My connection is pretty bandwidth limited so more than 2-3 connections will mess up your results. Works far better with Linux builds at the moment, but I can make some Windows builds available (with the odd hiccup or two) or you can just build them from source.
Hi Taylor!
-
I've been following this thread and started work on a reply, but unfortunately RL has been slowing me down/wearing me out. I'll try to finish it this weekend. As I mentioned earlier in the thread, I am interested in working on the netcode and have made a little progress in that direction. Unfortunately I've been dealing with RL lately and that's been slowing me down.
Replying to taylor is easy enough though:
You could give the icculus.org version a try in your testing too (the git version, not the svn one). There are a lot of fixes and optimizations but it's basically just a cross-platform, up-to-date, retail port. It's fully network and data compatible with the retail version. It also has full PXO compatibility with the retail version, minus one stats saving bug. And I can give you limited/private access to the PXO server for testing purposes if you want to try that out. My connection is pretty bandwidth limited so more than 2-3 connections will mess up your results. Works far better with Linux builds at the moment, but I can make some Windows builds available (with the odd hiccup or two) or you can just build them from source.
Interesting, perhaps we can port over to FSO some of your netcode fixes/improvements in the icculus.org version. I'd also be interested in your general thoughts on the netcode and how it could be made better, but that's probably better suited for another thread or PMs/e-mail.
EDIT: In case it would help with understanding the icculus.org version, I recently got Ubuntu 14.04 set up on my desktop and can use that for testing, even if I can no longer play FS2.
-
You could give the icculus.org version a try in your testing too (the git version, not the svn one). There are a lot of fixes and optimizations but it's basically just a cross-platform, up-to-date, retail port. It's fully network and data compatible with the retail version.
That makes testing it not terribly useful, because I've tested the actual retail executable, and it has exactly the same networking problems as FSO does.
If the lag problem is purely an implementation issue then no, it isn't going to be any use. If there are build/optimization/bug factors contributing then it might be something worth trying out. I honestly haven't tested netplay enough to say whether it has a bad lag problem or not. But I definitely haven't noticed anything like what I had the last time I was testing FSO netplay issues.
Interesting, perhaps we can port over to FSO some of your netcode fixes/improvements in the icculus.org version. I'd also be interested in your general thoughts on the netcode and how it could be made better, but that's probably better suited for another thread or PMs/e-mail.
EDIT: In case it would help with understanding the icculus.org version, I recently got Ubuntu 14.04 set up on my desktop and can use that for testing, even if I can no longer play FS2.
Anything that you can use, feel free.
Git repo is here: http://git.icculus.org/?p=taylor/freespace2.git;a=summary
You'll need CMake 2.8+, SDL 2.0.2+, wxWidgets 2.8+, openal-soft 1.15+, and libwebsockets 0.6+. A recent Linux distro should have all of that, just install the dev packages and you should be good. For reference, I'm using Debian Stretch as my dev platform.
And my email is my username at icculus.org if you want to contact me that way. PM is fine too, but I don't come around here very much anymore so responses may be a little slow.
-
You could give the icculus.org version a try in your testing too (the git version, not the svn one). There are a lot of fixes and optimizations but it's basically just a cross-platform, up-to-date, retail port. It's fully network and data compatible with the retail version.
That makes testing it not terribly useful, because I've tested the actual retail executable, and it has exactly the same networking problems as FSO does.
If the lag problem is purely an implementation issue then no, it isn't going to be any use. If there are build/optimization/bug factors contributing then it might be something worth trying out. I honestly haven't tested netplay enough to say whether it has a bad lag problem or not. But I definitely haven't noticed anything like what I had the last time I was testing FSO netplay issues.
Well, MatthTheGeek and I tested FSO and Retail multiplayer in the same missions with the same settings and got identical (and terrible) behavior, so I considered it to pretty conclusively point towards the implementation itself being the problem, but I readily admit I am no expert when it comes to netplay from any perspective (design, coding, or even as a user), so I could definitely be wrong.
-
Well, MatthTheGeek and I tested FSO and Retail multiplayer in the same missions with the same settings and got identical (and terrible) behavior, so I considered it to pretty conclusively point towards the implementation itself being the problem, but I readily admit I am no expert when it comes to netplay from any perspective (design, coding, or even as a user), so I could definitely be wrong.
You could be right too though. :) The code I can handle, but I rarely try multi-player except to fix a bug. How it works is one thing but how it actually plays isn't an answer that I'm well suited to give.
Either way the icculus.org code is there if anyone wants to give it a try. There is 14 years worth of fixes, optimizations, and cleanup in there. On the off-chance that it's any better you'll know that it's something that can be fixed. And if not then it's probably something that most likely needs to be replaced.
-
I mentioned this on another thread, but this seems a better place for it. Has anyone thought about trying FS2 Multi over a virtual LAN service? Evolve seems a good one. Used it for some multi for Starfleet Command 2 community edition.
-
I mentioned this on another thread, but this seems a better place for it. Has anyone thought about trying FS2 Multi over a virtual LAN service? Evolve seems a good one. Used it for some multi for Starfleet Command 2 community edition.
At best, this would be equivalent to using fs2netd: it would help you make a connection to another player, but you'd still have to deal with the exact same level of latency.
-
Well, it does solve the issues with NAT.
-
Well, it does solve the issues with NAT.
I suppose, although that should become a moot point with UPnP, shouldn't it?
-
Not really. Even with UPnP, you're still dealing with Network Address Translation. It's an extra layer to go through. Call Evolve a gaming VPN service. Everyone in a party is on the same virtual private LAN with no NAT at all.
-
:confused: My understanding & experience with uPNP is that it creates NATs dynamically. If the "gaming VPN service" is creating a virtual LAN then it's dealing with the NAT's itself somehow,
sure TCP/IP outbound connections generally don't need inbound NATs because of the stateful nature of the protocol, but UDP will always require a NAT, even for outbound connections (unless you're running an advanced router/firewall, not one that I'd typically expect to be handed out by your average ISP)
edit. actually, I think I was smoking something there, normal routers must be able to create inbound NATs for UDP return packets otherwise DNS lookup wouldn't work.... I guess FSO is running peer to peer which is why the inbound NATs are required... that could also be solved by moving to a client-server model (HA! like that's easy to do)
-
Evolve actually creates a virtual LAN with its own virtual network adapter. Like I said, it's sort of a gamers' VPN service. However, it can create these virtual networks on the fly by a user creating what they call a party and inviting other users to it.
-
Not really. Even with UPnP, you're still dealing with Network Address Translation. It's an extra layer to go through.
https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal
-
It's an extra layer to go through
oops, missed this the 1st time around. Any VPN will add extra layers of processing to each packet, and I'd be confident that the overhead from a VPN is higher than the overhead from NAT (which is essentially changing a couple of fields in the packet headers, as opposed to VPNs which wrap every packet in encryption (maybe?) & other headers! :))
IOW, there's no such thing as a free lunch :D
-
Well, MatthTheGeek and I tested FSO and Retail multiplayer in the same missions with the same settings and got identical (and terrible) behavior, so I considered it to pretty conclusively point towards the implementation itself being the problem, but I readily admit I am no expert when it comes to netplay from any perspective (design, coding, or even as a user), so I could definitely be wrong.
You could be right too though. :) The code I can handle, but I rarely try multi-player except to fix a bug. How it works is one thing but how it actually plays isn't an answer that I'm well suited to give.
I played multi quite a bit during the good old times with an ISDN connection (64k). If more than 2 or 3 players wanted to play the host had to have a cable connection. Host used update on high and everyone else on low cause the game seemed to be unable to cope with higher update settings without producing horrible lag for everyone.
I do remember these coop missions where a cap warps in and jumps forward in ~0.5 s intervals which was normal. As the usual difficulty setting was insane you ended up spamming missiles to destroy anything and rearmed or died to repeat. Scoring hits with the primaries was rather hard and didn't do much damage due to the difficulty setting.
PvP was similar in that you were mostly trying to get missile lock. That's where the "no fish" and similar rules came from. Sitting in a bomber (for durability) and spamming Piranhas was annoying as hell for everyone and got you kills cause some missiles will hit. Many people used a Morning Star on one primary bank cause if it hits the opponent has a hard time moving properly making it so much easier to continue hitting with all the lag.
So yeah, people were much more resistant to lag back then and learned to adapt.
-
Well, it does solve the issues with NAT.
I suppose, although that should become a moot point with UPnP, shouldn't it?
Adding UPnP support probably wouldn't fix all NAT problems because some routers don't support it or it is disabled for security reasons. For those cases an alternative solution would be needed which could be done my using the ICE (https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment) protocol family. Using STUN would solve a lot of problems where a client needs to determine its external address. If required, TURN could be used if the client hosting the game was unable to determine its external address. I have considered implementing it in my Node.js reimplementation of fs2netd but I current don't have the time to work on that.
-
Another issue would be that FS2NetD's DNS seems to have disappeared. If I set it in my hosts file the site loads fine but otherwise it's not resolving for anyone now.
-
FS2NetD seems dead since few days. It's permanent shutdown or it's just temporary issue?
-
FS2NetD seems dead since few days. It's permanent shutdown or it's just temporary issue?
Another issue would be that FS2NetD's DNS seems to have disappeared. If I set it in my hosts file the site loads fine but otherwise it's not resolving for anyone now.
That means that the FS2NetD server is still running but for some reason the domain name is not resolved correctly which means that if you use the IP address instead of the domain name you should be able to reach the server. However, without DNS it's pretty hard to actually get the IP address :nervous:
-
Hmm.... FS2NetD (http://fs2netd.game-warden.com/) was hosted at Game Warden? So maybe the A record was lost in their migration from vBulletin to SMF (http://game-warden.com/forum/index.php?topic=22535.0), but at least the game-warden.com domain still works. So could maybe be simply solved with a PM to MatthewPapa? Assuming someone here knows what the hosted-server IP is?
-
Yes, looks like I forgot the A record. I apologize! We are currently in the process of migrating stuff to a new server.
Just fixed it. Hopefully it will begin resolving as of right now.
Sorry for the inconvenience. Done hesitate to let me know if there is any other disruption.
-
Well, it does solve the issues with NAT.
I suppose, although that should become a moot point with UPnP, shouldn't it?
Adding UPnP support probably wouldn't fix all NAT problems because some routers don't support it or it is disabled for security reasons. For those cases an alternative solution would be needed which could be done my using the ICE (https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment) protocol family. Using STUN would solve a lot of problems where a client needs to determine its external address. If required, TURN could be used if the client hosting the game was unable to determine its external address. I have considered implementing it in my Node.js reimplementation of fs2netd but I current don't have the time to work on that.
I'm pretty sure that's how mumble does it. Or maybe it was a mumble plugin. Either way, probably the best direction to go besides switching to client/server model. Personally my vote would be for client/server, but I realize the difficulty in that sort of change.
Although...just thinking out loud here.
- Modify FSO to run headless
- Merge WebUI Standalone
- Add current (average?) latency to server in the client calculation for the aiming pip and/or autoaim.
- I don't know what else would be required to make this work. Probably a lot.
-
Webui standalone is already merged and runs headless (or at least in a terminal). Had to fix some issues with that after the sdl merge but it'll be working the same as in 3.7.4 soon enough.