The results you are getting was due to the version numbering errors before “Release 2.0.2”, therefore the runner used the older version of the game-engine to calculate these.
So the calculateMissileMovement() function aims to move every missile one cell forward, then repeats this and moves them one cell forward again, but only the missiles that still have movement distance to cover.
So the only oddness in this method is that if 2 missiles occupy the same cell, there would be no way to know which one will hit the building first…this doesn’t matter though as the only difference at that point is the missile id (used by the visualizers)
@wjb I stand corrected, the release for 1.1.3 (the one the tournament ran on) has these missile fixes, so every release after that (2.0.0; 2.0.1; 2.0.2) will have at least those missile fixes in place.
@Andre
Can you please show an example where the single cell movement method can get affected by missile list ordering? The resulting console map is intended to be identical, no matter the ordering of the missile list
Thank you Pierre , reason for the question were that my first bot was sort of a probe , by checking up on the first tournament standings i could determine what the bots that won/lost did different , and i am developing my strategy accordingly , so ,glad to hear i am not building it up towards a possible false impression ,got a little worried there for a moment
Sorry Pierre… I created test bots and ran the test on 2.0.2 and the missile hits are perfectly right… sorry if I caused anyone to panic or gave them extra work… I should have run this test before asking about it…
I must say it would be nice to have a guide explaining this for people doing this for the first time.
With a few FAQ documented example:
1.Where do i upload my bot:
2.Is there a way i can confirm that the bot I uploaded is going to be used for the next round:
3.I have uploaded 2 bots now , which one is going to be used for the competition
4.What happens when bots fail to run on tournament day but it worked during match upload testing.
I see there is some confusion regarding the uploads. Let me try to clarify some points.
When you upload a bot, you upload it for the main challenge. The tournaments throughout the year aren’t separate competitions, but rather just milestones for big changes in the game rules. This also gives people incentive to keep working on their bots throughout the year rather than working for a week at the start and then forgetting about it.
We don’t let people submit for a specific tournament, mainly because they are not required to take part in the first two tournaments in order to take part in the main challenge. Don’t look at it as that you are entering for the Operation Firestorm tournament, look at it as that you are entering for the main challenge just in time take part in the next phase of the build-up for the challenge.
With that said, there is only one place where bots are uploaded and that is on the player portal under the main challenge page. We will always take the last bot you uploaded that built and successfully ran the reference match. If you look at your submission history, the topmost one with all three green bars will be chosen. For example in the image below, out of the three latest submissions, submission 19 will be picked because it was uploaded after submission 18 and submission 20 failed its reference match.
As for whether or not your bot will run on tournament day. That is why we run the reference match each time you upload so that we are (and you can be) sure that your bot is able to run on our environment and doesn’t have any critical errors. Please note that after each tournament the game rules are upgraded which means that if your bot doesn’t read the input files in a way that allows for change, it could cause unexpected behavior.
If anything is still not clear, feel free to inquire further.
The gamestate JSON de-serialization has changed with the addition of the Tesla towers, that means that the match simulation will fail for bots that have not been uploaded since the addition of the towers, while showing green under match status.
Something should be done to warn people that have not submitted for this round.
– Invalid question – thanks @Leon for pointing out that there isn’t enough energy to fire. –
Hi Pierre (@pierre.roux ),
I have found a potential problem…
When my bot plays against an almost identical version of itself and late in the match one of the two bots introduces a TESLA tower, the tower doesn’t seem to fire…
as you can see from the image: the Tesla is fully built (at round 277) on the boundary between the two players and neither player has been damaged… (this runs for a while and by round 296 still neither player is damaged…)
I have no problem with this…
and I don’t want the match to be delayed for engine fixes…
I just thought people should be cautioned…
and maybe someone could help verify if they are getting the same bug…
I’m using:
starter-pack-2-0-3
and
an engine from git updated to most recent
and both seem to be giving this issue…
@critic Yes I agree. We try to keep the parsing of the state file as close to the previous phase as possible. In theory you could parse the first phase’s state file in a way that allows for change and then it should work throughout the challenge (just not necessarily using new features).
We have put a little thought into finding a way to indicate whether or not a bot coded with the previous rules will still work on the new rules, but it’s not realistic to rerun the reference matches for all the submissions. We will let you know if we find something that could help you out here.
The C# JSON parser throws an exception by default when using the previous class structure. That’s why I thought that you would clear the uploads after each round, then a mandatory upload needs to take place followed by verification.
Anyway, it’s not an issue for me, just think that you might have a few bots that will fail to run in the next phase.
?
Better to be safe than sorry
