GameStartedEventForBot not received in v0.24.0

[SirStone]

Describe the bug My NIM API are not receiving the GameStartedEventForBot message and so is not possible to send the BotReady in order to join the match but the match starts despite not all bots are ready. This is not happening in version 0.23.2 This looks like is not a problem for the official Sample bots, I"m not sure if these are receiving the Event or not but these can join the match unaffected.

To Reproduce

1. Download the 0.24.0 version of the GUI and Sample bots
2. Boot the GUI
3. Add the bots directory for the sample bots
4. start a battle booting any sample bot you want, for example "Walls"
5. start your bot manually from a terminal and wait for it to join
6. add both bots to the battle and press "Start Battle"
7. You will notice that the sample bot will be alone in the battlefield and your bot is not

Counter Test Repeat all the steps from 1 to 6 of the section To Reproduce but use the GUI and bots from version 0.23.2 at point 7 your bots has joined (and received the GameStartedEventForBot) as normal

observation Actually I'm not sure if the problem is limited to the GameStartedEventForBot not received or if all messages after the handshakes are not sent/received correctly anymore. A graphical clue cloud be this Why there"s the forward slash in the line of my bot? Maybe the server is now changing something in the address of the bot after the handshakes?

[flemming-n-larsen]

@SirStone Thank you for reporting. I fixed an issue with GameEndedEvent, so perhaps this is related to this issue. I will have a look into it.

[flemming-n-larsen]

@SirStone

I have added some print-lines to the Java Bot API to see, if the GameStartedEvent are fired and received.

It is definitely send by the server and also received in the API:

Server

Target bot (Java):

I recommend that you insert a print-line or similar in your code to print out all the Event.type field to see if the event is received with your API or not.

[flemming-n-larsen]

@SirStone

Regarding your observation with the trailing backslash in the end of SittinDuck 1.3.0 (localhost:57568) /

This is due to this line of code:

text = "$displayText (${host(host)}:$port)" + (teamName?.let { " / $teamName $teamVersion" } ?: "")

Source: https://github.com/robocode-dev/tank-royale/blob/main/gui-app/src/main/kotlin/dev/robocode/tankroyale/gui/ui/newbattle/BotInfoListCellRenderer.kt#L10

So if the teamName is not null (null -> missing) it will print the backslash. I guess it could be due to an empty string or similar with the teamName.

The teamName?.let checks if the name exists (is not null). If so, it add this part " / $teamName $teamVersion" otherwise (?:) is adds the empty string as we cannot add a team name.

[SirStone]

Hi

I've found what I think is the cause of the issue. I resumed my alternative GUI in order to have a Controller connected and see extra messages, I was looking for the BotListUpdate message and as soon as I've got it I saw this:

As you can see there are 3 bots in the list, first 2 are your sample bots, the third one is my bot; the host value is, what I believe, in IPV6 format and probably the server is unable to send messages to it after this value was set.

I was connecting using ws://localhost:PORT

If I connect with ws://127.0.0.1:PORT the BotListUpdate shows and my bot now works correcctly.

I think this issue is connected to the other opened issue: Starting battle on LAN Websocket address #96

edit: I've disabled IPV6 in my linux machine, and now even if I use ws://localhost:PORT the bot ends up translated to "127.0.0.1" Now I don´t know if is my system causing the issue with connecting with the local address in IPV6 or the server not handling IPV6 addresses after the connection is established (ServerHandShake and BotHandShake are working wihtout any issue here).

Why the sample bots are not affected? Is because of Java? Looks like these are connecting with "ws://localhost:PORT" and the server doesn´t receive anything different.

As mentioned before, with version 0.23.2 this is not an issue this is the BotListUpdate with version 0.23.2 and IPV6 enabled Similar to the version 0.24.0 but the sample bots are translated to "127.0.0.1" and my, in IPV6, keeps receiving the events as normal.

[flemming-n-larsen]

@SirStone Thank you for the update.

I am going to release version 0.24.1 with the fix for #96. Let us see, if this fixes this issue or we need to do more magic to fix it. 😊

[flemming-n-larsen]

Just released 0.24.1 with the #96 fix:

[SirStone]

As this looks like is only related to machine settings and so I don´t think a fix is required anymore, still I want share what is happening with my machine that resolves localhost to ::1 first and 127.0.0.1 after

Using new Version 0.24.1

ws://0.0.0.0:PORT -> WORKING

ws://127.0.0.1:PORT -> WORKING

ws://localhost:PORT -> NOT WORKING

the bot that is not changing is a SampleBot the one that is changing is my bot connecting with the written url

[flemming-n-larsen]

@SirStone Is the ws://localhost:PORT -> NOT WORKING a bug with Robocode? I guess it could be the web socket framework code, which might translate localhost into the IPv6 address 0:0:0:0:0:0:0:1 (same as ::1)?

Should we close this issue, or do you thing we need to change something with Robocode?

Robocode uses the hostString of the remoteSocketAddress of the web socket connection as-is. So I guess it comes from whatever the "bot framework" sends to the server?

Here is the line in the code: https://github.com/robocode-dev/tank-royale/blob/main/server/src/main/kotlin/dev/robocode/tankroyale/server/core/GameServer.kt#L550

[SirStone]

@flemming-n-larsen Is my machine that translates from localhost to ::1 that I believe is the short equivalent for 0:0:0:0:0:0:0:1. For example, if I do ping localhost I see these messages:

❯ ping localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.053 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.106 ms
64 bytes from localhost (::1): icmp_seq=4 ttl=64 time=0.126 ms
^C

I don't think anymore that is a bug from RTR, maybe itś just a missing feature for the future when the game will require to support IPV6 web-sockets and the provider libraries will handle IPV6 autocatically.

I'm going to close this issue with this comment.

[flemming-n-larsen]

@SirStone: Thank you for the clarification. 👍

You are right that RTR does not support IPv6 currently. But I think we could add this as a Feature Request and see if it can be supported. 😊