I am not using the dll patch ATM and it works great.
Good point on the shared hosting issue and CPU/IO anomalies, although I believe that it is not the hardware performance that is causing this issue. If my suggestion counts, I would consider to investigate the following scenario:
There are usually complex firewall settings on every IPs they provide in order to limit bots and minimize other malevolent network activities. So they limit hit rates, use QoS on the inbound traffic and sometimes the outgoing traffic as well. The latter can be a problem. Unfortunately these settings are generalized to average usage characteristics, and not prepared for irregular activities. For example, if an RVS server is trying to pester an external URL but it doesn't respond, it may reach the limit of the hoster's FW which disables that IP/port for a period. (Check out our firewall settings that I posted above. You can see there is a 10 hit/min on every inbound ports, which serves the same purpose. When the connection attempts reach that, I drop every packet for 2 minutes from that source.) Now, when the above scenario continues and reaches RVS, which is infamous about being very poorly programmed and have performance, resource management, thread separation, etc. issues. I wouldn't be surprised if it does not even use a separate thread for the TCP socket to reach UBI's server list server, and when the program flow enters a "waiting for connection" loop, due to the hit rate limit and lack of thread separation it does not switch to other contexts. Therefore, the program flow just permanently cycles in the TCP socket's loop and never leaves it until the socket finally times out. In this case, every other activities will freeze.
So I can assure you that there is no extreme performance needed for reaching a remote host, it is just due to a poor program implementation technique. On the other hand, what might have happened after you patched it, that now the program flow never enters the badly written subroutine.
I have uploaded your patcher to rvsgaming.org though.
BTW, did you ever manage to compile anything with the RVS C++ SDK library. I've got that package but it has missing files. I was trying to fix it by using files form other UE2 projects but I gave up at some point. I might give it another try some other time, but it is not priority right now. If I could manage to compile that, I could rewrite the R6GameServices.dll without all the junk. Of course, only if there is no other way to fix it.
AFAIK, it is FollowTheLead, at least he could restart servers when I once played on that server. I can send him a message to hop in this forum.But I dont know who the Admin of the Coop Swe 1.6 server is? Does anyone?
Yes, we are using a private server and we have no performance issues.But Tony I was told you run your SMC servers privately, as in not on a commercial game hosting site.. is that true?
My apologies if I didn't respond to everyone. If I missed out any salient points, please give me a heads up.
I have updated the website with some info. I am behind the schedule with the portal, but this is due to the fact that I want to make it bullet proof. Twilight is working on the next release of OpenRVS and hopefully I can also finish my side of the work, so we will have a nice self-registering server list as before, but more reliable and will have lot more features. You'll just start your server and it will appear in the server list. You will also see them on rvsgaming.org with info such as who is online on which server, etc. Clans can also insert the up-to-date server list to their own website. And of course later we can do more fancy things, such as game statistics and whatever you guys want...