entelectchallenge / 2024-sproutopia Goto Github PK

Hi there

Problem:

I noticed that when the number of players is greater than 1, sometimes RunnerHub drops player commands. It appears as though when multiple commands are received at roughly the same time, not all of them are processed.

I say that because I noticed SignalR logs indicate that a player command was received but RunnerHub.SendPlayerCommand is not executed.

SignalR logs:

2024-04-06T17:49:48.3372874+00:00 Debug Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher - Received hub invocation: "InvocationMessage { InvocationId: \"\", Target: \"SendPlayerCommand\", Arguments: [ Domain.Models.BotCommand ], StreamIds: [ ] }".

I added custom logging on the first line of RunnerHub.SendPlayerCommand to confirm it isn't executed at all.

This was happening roughly every 20 ticks in my local games. I initially noticed when replaying games that some commands weren't processed.

Solution:

I noticed the last years engine didn't register RunnerHub as a singleton. When I removed it as a singleton, all works as expected.

Line to remove:

Hope this helps

When trying to execute the run.sh or run.cmd you will receive the following error "ERROR: failed to solve: failed to read dockerfile". This is raised in the docker build as this command expects either the Dockerfile to be referenced or for there to be a Dockerfile in the directory root.

Heyo, looking forward to the EC for this year! I've started playing around with the engine, and I've noticed that log files are currently written to a hardcoded path:

This path 1. literally creates a file named 'logs\engGame.json' on Linux (doesn't nest it in a logs directory) and 2. will get overwritten on each game. Can this please be updated to use a timestamp as the filename so that logs don't overwrite each other?

I've noticed an issue when I intentionally run into my own trail to trigger the protection.
It correctly places me at the start of the trail, however the trail I had made was not wiped out (at least on the heroWindow).
I hadn't tested if I could run into this remnant trail and prune myself but will do later and update this issue.

Naturally if this trail can get you pruned it will leave you incredibly vulnerable until you capture the area around it in order to convert the territory to your own.

Hi there, claiming seems to to behave a bit ambiguous when your garden becomes a bit hole-y. See below:

To be honest, I don't even know what the right behaviour should be in this case? 🤔 Not pictured here was another hole in the garden (not connected to this one) which was also claimed.

Not sure what's the case for holy gardens, haven't tested there yet 🤷

When a bot gets pruned and gets respawned, it's new territory is initialised here:

While this does create the new bot's territory/garden, it doesn't remove the new territory from other bots' gardens. This means that when the opposing bot (which originally owned the respawn point) claims another piece of territory, and it recalculates/joins the polygons, it ends up overwriting the bot's respawn territory. This can lead to very weird states where a bot has no territory and only a trail 😅

Attached video shows red getting respawned, then brown claims a new, unrelated piece of territory (not even linked to the blob in which red is) and then red's original territory disappears

Not a huge issue, but a needless thing to run into when coding things.
Can we correct these typos?

botPostions - > botPositions (*this is really the only thing I actually tripped over)
opposingBotPosistions -> opposingBotPositions
_staticTeture -> _staticTexture

Currently, from what I can tell, the player index (i.e. the bot's numeric ordering [0,1,2,3], which is used in the cell types) can be inferred from the leaderboard key in the state update. The ordering of this key however is not guaranteed, as it's making use of the normal Dictionary which may or may not preserve insertion order. Can this please be updated to make use of an OrderedDictionary, so that the order of the keys are guaranteed to match up with the player indices? Thanks!

Hey there, I think I've found an edge case in the claiming logic which causes an engine crash due to a null dereference

In the following video, player 1 = blue territory and player 2 = red territory.

The problematic line is here:

territoryStart never gets set (because the trail start is no longer in player 1's garden), and that causes the following error to get raised:

2024-04-13T09:44:25.1945076+00:00 Error  - Game failed with exception: Object reference not set to an instance of an object.

This should probably handled similarly to how split territories are handled, where the trail simply gets converted -> claimed land.