Ron

A lot of bad logic.*

Networking sync problems. Probably not much you can do about it with CCR files.

Devcorp has a guard for 2.1.5 only, no 2.1.6 guards.

It appears to be a 010 editor script. 010 has a built-in template and scripting system to modify binary files. It's a very powerful hex editor.

Unfortunately as others have mentioned, this is hard coded in to the client BIN and is not able to be easily modified. You'd need to reverse engineer the client BIN in IDA to change this. The items load automatically by item type. You cannot modify this algorithm easily without source code. I'll go ahead and lock this thread since recent replies are off-topic anyway. There isn't anything else useful to gain from this topic anyway. Disassembling the client is something no one has done due to lack of client-side PDB files.

It is just something CCR left over in the official server files. It's not really an exploit as much as it is a feature. No, they aren't very smart at all. For some time this trick worked on official (with the same password!) but it's since been patched.

Congrats. I'm glad to hear it's working now. Yeah, the process isn't exactly straightforward. I have some ideas to address this but my free time is limited lately. We'll have updates soon.

Sorry about that. I thought you were trying to connect to the server running in a guest. You shouldn't need to modify the nation codes, just the server IPs. I had this same problem last year when I last looked at these files. I don't remember the exact fix but I did work around this. If I need to configure the files again to figure it out I don't mind doing so. I need to revise the files for this post anyway as they have a lot of easy issues that can be fixed out of the box. Are you on discord? If so, send me a PM there and we can discuss more.

You'll need to set up a virtual network and make sure each system has its own VMware LAN IP assigned. You wont' be able to connect to 127.0.0.1 from your local PC to a service on the VMware OS. Configuring a network is required to talk from your local OS to the guest OS. https://kb.vmware.com/s/article/2043160 I have successfully configured RF in a guest OS on VirtualBox a few times. I've used VMware but never for RF. Either way, you'll need to configure the virtual network then test that each OS can talk to each other with a ping test. Once that's working set all server-side IPs to the IP of the guest OS. Set the guest OS IP in your client and you should then be able to connect. However, this will only allow connections from systems configured on the virtual network. As far as allowing public network connections to access the server on the guest OS, you'll need to get in to some tricky network routing settings. It is significantly easier to host on a server where the public WAN IP is bound directly to the system (WAN IP showing in `ipconfig`), and not behind a LAN. The easiest way is to share the connection from the host OS to the guest OS, forward the ports to your host OS LAN IP, then set which guest OS to forward each port to in your virtualization settings. Other players will be able to connect, but the problem is you will not be able to connect from the host OS to the server on the guest OS (explained in my other posts).

Thank you for following up with the solution. =)

Thanks for following up to confirm the fix. -thread closed-

The issue with tcpview showing 204.204.204.204 is common when attempting to allow WAN connections from a server configured on LAN. The loginserver returns this IP when it is unable to connect to the zoneserver IP (WAN IP). This is caused by your local system not being able to connect to your WAN IP (loopback connections not working). Please check my post here to see if this applies to you.

Could be the update emulator. Its tricky to get working right. You can also try my developer launcher. It has a few bugs remaining but doesn't require an updater to be in place. Try it for testing purposes. If you're not familiar with compiling I can build a launcher for your IP when I'm back at my pc. Just let me know.

WorldInfo IP needs to be 192.168.2.3 and not 192.168.2.1. All IPs need to be the server LAN IP if running over local network.

Have you tried to configure the server on 127.0.0.1 first? If not, configure all IPs to 127.0.0.1 and try to connect from the same machine as the server. Get it all working with 127.0.0.1 to confirm if the IP configuration is related to the zoneserver error or not. Once the services are working, update your IPs on the server side to your LAN IP and then verify the servers still start. Once the server is up, telnet from your laptop or any other machine on the network, to the server machine. Command Prompt: telnet 192.168.2.3 27780 The screen should turn black and then some characters may appear. This indicates the zoneserver accepted the connection. You can verify by checking if the user count on the zoneserver increased. If you get a timeout there is some connection issue between the systems. You should be able to at least telnet to the zoneserver port from another machine. If that's not working, review your firewall rules. As a test if your router supports it, enable DMZ for 192.168.2.3, disable Windows Firewall on the server, then try the telnet again.