Network play in version 20180907-1.exe

Found a bug in R'n'D? Report it here!

Moderators: Zomis, Flumminator

Post Reply
BrownSky
Posts: 19
Joined: Mon Sep 24, 2018 4:04 am

Network play in version 20180907-1.exe

Post by BrownSky » Mon Sep 24, 2018 4:35 am

Hi, this is my first post on the forum so apologies if I make some mistakes.

I was able to run rnd 4.1.0.0 in network multiplayer mode with computer "A" as the server and computer "B" as the client, and vice versa.

I ran rocksndiamonds-20180907-1.exe on computer "A" (first) and computer "B" (second), but the computer "B" version could not find the computer "A" version. Tried the other direction - same.

Note that to play rocksndiamonds-20180907-1.exe, all I did was drop it into the rnd folder, and run it (initially I renamed it, but on a second try I didn't rename it - both times the networking didn't work). So if there are some other steps I need to do to make rocksndiamonds-20180907-1.exe behave properly, I haven't done them.

User avatar
Holger
Site Admin
Posts: 3231
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Network play in version 20180907-1.exe

Post by Holger » Thu Sep 27, 2018 9:22 am

First of all, welcome to the R'n'D forum, BrownSky! :D

As far as I can see, you did everything correctly (and there shouldn't be too much that can go wrong), so I have no idea why it did not work at the moment.

The main reason why it does not work out of the box could be the following: Computer "A" and computer "B" are not in the same subnet -- in this case, they do not "see" each others using UDP broadcasting. But I assume that your two test computers are close to each others in the same subnet?

If they really are in different subnets, auto-detecting the network server via UDP broadcast does indeed not work; in this case, the first computer ("A) won't detect any R'n'D network server (which is OK, because it is the first one), but the second computer ("B") won't see the now existing R'n'D network server because it cannot reach it via UDP broadcasting. In this case, computer "B" would have to directly connect to "A" by explicitly specifying the hostname or IP address of computer "A". This, however, currently only works on the command line -- this is the last part of the networking stuff that has to be migrated from the command line to the GUI (setup menu).

There was somebody who successfully did this (connecting to the network server) on Windows without the command line, by creating an alias and adding the command line parameter to connect to the network server in the "properties" of the alias (if I understood that correctly -- never tried this by myself).

But I will add this functionality (enter the hostname or IP of the network server) to the setup menu very soon.

User avatar
Holger
Site Admin
Posts: 3231
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Network play in version 20180907-1.exe

Post by Holger » Sat Sep 29, 2018 8:01 am

As far as I can see, you did everything correctly (and there shouldn't be too much that can go wrong), so I have no idea why it did not work at the moment.
OK, after some tests, I found out that auto-detecting the network server using UDP broadcasting works on all platforms except Windows. :(

I did these tests with Linux, Mac and Windows 7 and 10, with the following results:
  • Using Linux or Mac as the network server:
    => Linux, Mac and Windows can all auto-connect via UDP broadcasting.
  • Using Windows as the network server:
    => Linux and Mac can only connect by explicitly specifying the server's IP address.
So it seems like Windows has a problem with incoming UDP broadcasting packets for whatever reason. (I even tried completely disabling the WIndows Defender firewall on Windows 10, but this did not change anything. Maybe somebody else has an idea what to do to make UDP broadcasting work on Windows, too.)

So, to use network games between two Windows PCs, you have to specify the hostname or IP address of the PC that is the network server (usually the PC that started R'n'D networking first) on the PC that is the network client. (If you configure the hostname or IP address of each other's PC, it should not make a difference which PC started R'n'D first.)
There was somebody who successfully did this (connecting to the network server) on Windows without the command line, by creating an alias and adding the command line parameter to connect to the network server in the "properties" of the alias (if I understood that correctly -- never tried this by myself).
Hey, now I know that was you! :D
But I will add this functionality (enter the hostname or IP of the network server) to the setup menu very soon.
It's available now in the latest test executable for Windows.

BrownSky
Posts: 19
Joined: Mon Sep 24, 2018 4:04 am

Re: Network play in version 20180907-1.exe

Post by BrownSky » Mon Oct 15, 2018 12:44 am

Hi, I was away and only found out about the new release of R'n'D yesterday, which was a very welcome surprise!

Networked multiplayer games are working for me now - I have tried with three different PCs (Windows 10), one acting as the server and the other two as clients, but only two PCs at a time. I will test this afternoon with three PCs at once.

This is fantastic - both the fact that networking multiplayer now works and that the level is sent by the server to the clients - thanks so much Holger.

What follows is some not so important detail.

When I began testing, I did so without specifying an IP address, and at first I thought that the UDP broadcasting was working, as the second instance of R'n'D said that it had found a network server - I can't remember the exact detail, whether it was the second or third attempt that succeeded. But when I started a game on the server it didn't start a game on the client. It had been so long since I had played networking multiplayer that I got confused and wasn't sure how networking multiplayer games were meant to start, do I searched the forum - which only found two matches, one of which was this thread.

Once I specified the IP4 address of the server, it worked. I note too that the client can trigger a game for it and the server, using a level on the client (not the server). Obviously this wouldn't work for other clients of the server. I guess that UDP broadcasting would mean that the server-client dichotomy disappears, and any computer can send a level to all the other computers? (if it were working)

One problem is that if R'n'D is in networking multiplayer mode, and you design a level and click Test, the game locks up - it doesn't seem to handle well a situation where singleplayer mode is necessary. You have to exit the level creator and play the level using 'Start Game'.

Overall I am super-happy with this release as it means now that my boys, and sometimes their friends, can play without all trying to use one keyboard and screen and getting stuck at the edges of the screen, and coming to blows over the keyboard!

BrownSky
Posts: 19
Joined: Mon Sep 24, 2018 4:04 am

Re: Network play in version 20180907-1.exe

Post by BrownSky » Mon Oct 15, 2018 1:03 am

One further thing is that when the instances of the game on different computers are in networked multiplayer mode, starting a level on one computer (either the server or a client) starts the level on the other computer, even if it is a level that does not have more than one player in it.

When the level started on the server, it worked on both PCs - that is I could move Rockford about. But when I started a different level on the client, it again started on both PCs, but Rockford was frozen. This was a blank/new level, just Rockford, dirt and an exit - I don't know if this affected things; the server level was one of the Contributions levels.

I can't quite think what I think ought to happen. I suppose if the computers are networked, and you play a cave with only one character, you want the players at the other computers to be able to watch what happens in the game on the first computer? But certainly I think there should never be a frozen level.

- actually I tried again and it wasn't that the level was frozen, but that the player was controlled by the server, even though the level was on the client...

Post Reply