tmyqlfpir
commented
1 month ago Hi, thanks for reaching out with the issue.
I know you said the browser it's rarely ever used, but I think there's a reason that was the case: people still have to port forward, and that's inconvenient enough to deter players from hosting on it. Correct me if I'm wrong, but you were working on implementing some ZeroTier code at some point to negate the need to do port forward, right?
I addressed some of this in the issue #52, quoted below for reference.
After spending many months on this, and making little progress - here are the problems I faced:
- On two different installs of Windows 10, CMake refuses to compile libzt (no idea why, every other package compiled and I followed the build guide), forcing me to use MinGW
- Libzt is unstable and will crash randomly when compiled into NotBlood, even though the same code as a standalone app is stable (LMK if there is any good debuggers for GCC on Windows)
- Drop outs while connected to routes on a stable connection (most likely my own fault, but didn't get far enough to confirm)
With university starting shortly for me, I simply don't have the free time to dedicate to rewriting the entire network stack, even though the current enet implementation is good enough for multiplayer.
I'm sorry that I led a few folks excited about the possible feature of libzt's inclusion - hopefully someone upstream with eduke takes on this challenge.
This is pretty much a 'skill issue' for myself, I've never had CMake work with zerotier, and it's at odds with the current makefile build process of Eduke32, which I greatly prefer. Even if I did get this CMake solution to play nice with NotBlood, there is still the implementation of rewriting all of the enet functions with libzt equivalent, then further testing to ensure that it works across linux and windows environments.
I simply don't have the time to focus on a major feature like this with my studying schedule.
If that's the case, then let me propose this: once NotBlood has network code that doesn't require hosts to port forward or use a VPN or whatever, then the server browser should be reimplemented. Word will get around about this, and more people will use the server browser.
If someone wishes to do the hard work and get it to parity and stability of enet, sure.
"Just use NukemNet" is a very band-aid solution, and lots of new users aren't going be very happy about downloading even more software just to play multiplayer. Using an external netplay guider is really more befitting of playing the original versions of games in multiplayer, not so much a modern source port.
I agree, and while an external solution is not elegant in any ways, it is the most viable way to play with a functional lobby system until something proper has been implemented.
Hope this answers your questions. If this is all you have to ask please close the issue, thank you.
OpenRift412
I know you said the browser it's rarely ever used, but I think there's a reason that was the case: people still have to port forward, and that's inconvenient enough to deter players from hosting on it. Correct me if I'm wrong, but you were working on implementing some ZeroTier code at some point to negate the need to do port forward, right?
If that's the case, then let me propose this: once NotBlood has network code that doesn't require hosts to port forward or use a VPN or whatever, then the server browser should be reimplemented. Word will get around about this, and more people will use the server browser.
"Just use NukemNet" is a very band-aid solution, and lots of new users aren't going be very happy about downloading even more software just to play multiplayer. Using an external netplay guider is really more befitting of playing the original versions of games in multiplayer, not so much a modern source port.