Jump to content

Server Troubleshooting

Recommended Posts

I have changed SERVER4 to a console server in order to remotely research the on-going persistent hyperspace issue. Some have reported that this issue is on SERVER4 only. Thats rubbish. The only difference between that server and 2&3 is that it has AG turned on. And that has nothing to do with the hyperspace timer.

And SERVER3 (graphics mode) now also has AG turned on.

So, thats two servers with AG turned on. One graphics and one console.

So far, I can't reproduce it reliably, which leads me to my original and current conclusion : If you are sent a hyperspace packet which hasn't finished for the object - and you get another - it will reset it. This will happen usually with 56K connections, since you are on a slow connection.

So, now that S4 is a console server, I'd like some reports from EXPERIENCED AND REGULAR MP PLAYERS ONLY - WHO HAVE PLAYED MP SINCE v2.00.00 AND REGULARLY. This way I can at least isolate the problem and rule out the graphics server from being the problem.

If you even THINK of posting in this thread - and I check my server logs and you haven't spent enough time to warrant the status in bold above, you will be banned from posting. NO EXCEPTIONS. I don't mind banning everyone who doesn't follow my rules, from this forum. If nothing else, it will reduce my bandwidth. So please, try me.

[ 06-10-2004, 11:45 AM: Message edited by: Supreme Cmdr ]

Link to comment
Share on other sites

If you are interested in helping out with researching a reported issue which I can't seem to be able to reproduce, read this.


It has come to my attention that some anomaly may have cropped up in the 2.00.09 build of the mp server and I am trying to track it down via remote debugging because I cannot reproduce it back here in my lab (using LAN or Net connection).


SERVER3 is now running a debug server build and I have it running via remote debugger here in my office.

I need all interested parties to do the following.

  1. Download this
    2.00.09 debug executable

  2. Rename the existing ucmp.exe file to ucmp.bak

  3. Extract the debug executable into the game folder

  4. Connect to SERVER3 as normal

If and when the server crashes, I will know about it because the debugger will trap it.

All clients connected to the server need to capture the crash screen (if any) and post the results here so that Remo or Marvin can filter through them and relay relevant - and properly formated data - back to me at Area 51 (as I don't want to keep checking two forums).

Other clients not running the non-debug build can still connect to SERVER3, but they will not get any debug info if their client does crash.

This debug build is slower than the normal build. So don't be surprised by this.

WARNING: If the server crashes, it will NOT restart because it will be stuck in the debugger until I inspect the code. So, once it goes down, you have to find another server to play on until I am done check why the server crashed.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now

  • Create New...