Nexuiz startup vs network stability

[tundramagi]

?
Perhaps add a new variable: ultra_net_covert, where , if set to 1, nexuiz doesn't check the master servers, only searches for lan server. If set to 2, nexuiz doesn't search out any servers (it, ofcourse, would accept that a server exists on the lan if the server is broadcasting that), If set to 3, nexuiz won't accept anything other than localhost servers (127.0.0.* (yes it can be anything in the 127.0.0.x net). AND IF 4, oh boy, then Nexuiz doesn't even accept localhost! (So one can only browse the menus, not play a game ). Maybe also cache the last known good IPs of both the DNS master servers and the list of servers: this way if DNS fails you can still connect to master servers, if master servers fail you can still connect to regular servers?

Ultra_net_covert shouldn't be able to be "pushed" by servers, only the user shouldbeable to set it.

?

[divVerent]

sv_masterextra1 ""
sv_masterextra2 ""
sv_masterextra3 ""
sv_masterextra4 ""

Then the DNS resolving should be gone.

To turn off networking completely, use:

cl_netport 445

or any other port number already used on your system (445 is always in use on Windows, and allowed to root only on Linux and Mac, so this one should always work for this purpose). Then ONLY local connections will work.

[divVerent]

Anyway, the big issue isn't that these queries are done. They should be done.

The only issue we have is that DNS resolving blocks the game until it's done. This is by design of the DNS resolve functions in the least common denonimator of all operating systems. Fixing this would mean writing lots of OS specific code for it, and also rewriting functions like connect to queue up the connection, wait for the result, and connect then.

A library for this already exists, but it's on unix only - it is libadns. The Windows port of it apparently is very outdated and unmaintained.

[alpha]

Alright, so to fix this problem, we have 3 options:

1. "Download server list" button aka warsow style
2. Download server list on "multiplayer" window click ([-z-]'s idea)
3. Manually mess with autoexec config and play with console on every game launch

How about we don't enforce a use of solution #3 ?

[divVerent]

1. sucks totally, extra waiting time for anyone except you
2. still sucks, as the list then does not fill. It is an important part of the UI design that the list DOES fill, so you know there's the server list. Really makes it more intuitive. And still, much more waiting time for most people.
3. only in your specific case

For most players, the current solution is just perfect. You are the exception here.

So I propose:

4. do resolving in a separate thread (should certainly be done in the future)

This could e.g. be some task for the C coders who join this forum and ask what to do.

Also, maybe this is simpler:

5. do a one second timeout for DNS resolving

This is simple on Unix systems (the common denominator is fork(), do gethostbyname() in the child, send it over a pipe, and from the parent process, read the pipe with a timeout, then kill the child process), but I know that fork() does not exist on Windows, so I won't implement it simply as I don't know how.

[GreEn`mArine]

why not add a cvar "cl_me_has_crappy_net_connection_so_please_do_not_use_any_internet_features_kthxbye", defaults to 0 and when set to 1 no internet connectivity is used. Of course I do not know at how many places that "if" would have to be placed in the DP code.

OTOH, I think that setting the master-server to "" is a fairly easy solution for you alpha, you can simply create two launch configurations (on windows: 2 launch shortcuts), where one sets the master servers to "" and one to their original value. That's quickly done for setup and very easy when starting the game, too.

[divVerent]

why not add a cvar "cl_me_has_crappy_net_connection_so_please_do_not_use_any_internet_features_kthxbye", defaults to 0 and when set to 1 no internet connectivity is used. Of course I do not know at how many places that "if" would have to be placed in the DP code.

cl_netport 445

does exactly that already

[alpha]

Somehow I don't think I am the only one who is affected.

[divVerent]

Let's say you're apparently the first to notice it since Nexuiz 1.0.

So this is certainly not critical for the next release.

This can wait till someone of the people who always complain about parts of Nexuiz being written in QuakeC notice that the engine is actually written in C, and that they could help by implementing a background DNS resolve feature.

[sev]

Somehow I don't think I am the only one who is affected.

Since I updated from openSUSE 10.3 to 11 I have the same problem, and it can be quite annoying when working on maps and changing between Radiant and Nexuiz.

BUT, I simply avoid launching Nexuiz when offline; problem solved. (That's the lazy way, but since this started with the OS update, I knew that I was the one who needs to resolve this, not Nexuiz)

Something I noticed is that when pressing a bind to open a map on startup, the freeze time decreases from about 90 to about 15 seconds.