Coders of the Carribean - Bugs

Agade told me that there was something weird with the collisions:

if your ship does a rotation and collides with another ship that wasn’t rotating, both ships are stopped (speed=0). It’s a bit weird that a ship that didn’t rotate is stopped.

What I could do is adding the line if (ship.newOrientation != ship.orientation) { at line 1042 (https://github.com/CodinGame/coders-of-the-caribbean/blob/master/Referee.java#L1042). This way, if your ship goes straight, it wouldn’t be stopped by a rotating ship.

Same thing L995.

My question is: should we change this behavior or let it as it currently is?

I think you should make the change.

This is still early in the contest AND you’re being very open about changes made on the referee. I think all top players will be able to find the information. And the behavior will feel much more natural.

3 Likes

I don’t think it’s necessary L995 ?

1 Like

Some of these “bug” fixes also influence the strategies that can be used by bots, and whether it’s a bug or not is a matter of perspective. I think it adds depth to the game to have better ways to stop a ship. And for instance a bot could exploit this movement “bug” to gain an advantage.

Personally I am against making further changes at this point if they are not game breaking or unquestionably wrong.

4 Likes

My question is: should we change this behavior or let it as it currently is?

My answer: Change this behavior because it would be more “real world logical”.
Currently, when ship A sailing at full speed is in the course of hitting ship B on the side, ship B is not stopped in spite of the potential impact.
Rotating ship A is a softer maneuver, it’s not logical that it has the capacity to stop ship B just by gently touching it (“gently” compared to previous case).

Unless I fool myself, I think that I’ve spotted a bug systematically disadvantaging the ship with lowest index when the case appears (rather rare but not impossible).

In #moveShips and #rotateShips we have:

for (Ship ship : this.ships) {checkCollisions(ship);}

So the first ship in “ships” calls #checkCollisions, in which it drinks any barrel it touches, then all mines explode.
Then the other ships call #checkCollisions, in which they just drink their barrels (the mines have already exploded).
Consequently, the first ship in “ships” (the one with lowest index I guess?) drinks its barrels then takes damage from mines (touching or touched by another ship), while the other ships take damage from mines then drink their barrels.

Most of the time the order has no importance, except when ships’ health are very low or very high, because of HP cap.
For numerical example, say a ship drinks one barrel at HP=10 and that one mine is directly touched (-25 HP) (possible when rotating).

Case 1 with HP=99 (very high):

  • first ship HPs: 99 -> 109 (barrel) -> 100 (cap) -> 75 (mine),
  • other ships HPs: 99 -> 74 (mine) -> 84 (barrel).

Case 2 with HP=1 (very low):

  • first ship HPs: 1 -> 11 (barrel) -> -14 (mine) -> 0 (cap) -> dead,
  • other ships HPs: 1 -> -24 (mine) -> 0 (cap) -> 10 (barrel) -> alive.

In both cases, the first ship in “ships” is thus disadvantaged.

Suggested correction: replace “for (Ship ship : this.ships) {checkCollisions(ship);}” with:

for (Ship ship : this.ships) {checkBarrelCollisions(ship);}
checkMineCollisions();

with #checkBarrelCollisions grouping current L927–938 and #checkMineCollisions grouping current L940–949.

3 Likes

I agree, I’ve updated the referee as suggested: the rum is collected first for all the ships, then we resolve the mines. Thank you.

I submitted 6 hours ago, and finished about 130th/200 in Gold.
When I submitted the same code again now, it says I automatically lose all of the first 10 battles because of timeout in turn 3. However battles 11+ are fine. Also when I run them in the IDE it never times out. (running Python)
Now every time I submit I automatically lose the first 10 battles, and even if I win most of the rest I still only get matched to bottom AIs, so get a low rank.
Has there recently been a change to how the first 10 battles are processed? Or are the servers overloaded and treat the first 10 differently?

Sorry, I tried to optimize the workflow and broke the submit for the 10 first battles. That’s fixed now.

1 Like

I confirm that it’s not necessary at L995 (L1012 now) but fine at L1042 (L1056 now).

This seems to be the most reasonable choice. We won’t change the behavior of the ship now for this particular issue. That’s weird but not unfair.

Hi, I have an issue where I get hit by a cannonball although I don’t think I should be.
It is a one-on-one game and I in the last turn this is the situation (the logging is done right after I read the input):

Standard Output Stream:
WAIT
Standard Error Stream:
My ship: pos=(2, 13), heading=5, speed=2, rum=12
CANNONBALL: pos=(0, 5), turns=0
CANNONBALL: pos=(3, 14), turns=1
CANNONBALL: pos=(8, 18), turns=4
Standard Output Stream:
FASTER

Game Summary:
End reached
My ship is at (2,13) with speed 2 and heading 5. Given the order FASTER I should end up pos (4,16) with my stern in (3,15). The cannonball aimed at (3,14) hits me though and finishes the game. There are no mines nearby and the enemy ship is 10 hexes away. The cannonball shouldn’t hit me until I have move fully, right? Looking at the animation it looks like I only move two hexes forward despite the FASTER command.

Any idea what is wrong?

Replay: https://www.codingame.com/replay/210210396

0 ≤ shipSpeed ≤ 2

in your case FASTER has the same effect as WAIT.

Sorry, for some reason I thought speed could be up to 4 when using manual control. my bad

https://www.codingame.com/replay/210584619
step 57.
My opponent (orange) moves all the time and has speed 1, but it’s written, that his speed is 0 in one monet (without real stop).
Why is it happens?

Your opponent wants to rotate, thus blocking (12/2)
I can’t see your output (I assume WAIT). You would probably also reach (12/2). that isn’t possible, both speeds are set to 0.

Hi,

I am getting Segmentation faults while running my code. No other errors - program stops but it is possible to rewind the battle to the future steps. What could be the cause of the problem?

Hi. I’d like to notice not real programming bug, but syntax mistake: in the “Manuel steering of a ship” section of rules there is written “Exemple :” instead on “Example :”.
Sorry, I’m grammar nazi :slight_smile: .

1 Like

Hi, I’m coding in JavaScript in coder of carribeans challenge and it seems like there are some bugs with the print function. It doesn’t always print what it should, maybe I’m missing something but here is an example:

else if (toGo.x < ship.x && toGo.y > ship.y){
        
        printErr('Im in this case', ship.sens);
        switch(ship.sens){
            case 0: printErr('Im I here?'); ship.speed !== 0 && toGo.dist===ship.speed ? print('SLOWER') :print('STARBOARD'); break;
            case 1: ship.speed !== 0 && toGo.dist===ship.speed ? print('SLOWER') :print('PORT');break;
            case 2: ship.speed !== 0 && toGo.dist===ship.speed ? print('SLOWER') :print('PORT');break;
            case 3: ship.speed !== 0 && toGo.dist===ship.speed ? print('SLOWER') :print('PORT') ;break;
            case 4: printErr('should print FASTER'); print('FASTER');break;
            case 5: ship.speed !== 0 && toGo.dist===ship.speed ? print('SLOWER') :printErr('should print starboard');print('STARBOARD');break;
        }
    }

In this sample of code, I printErr what should be outputed, but as you will se in the logs, the print outputs something totally different:

speed 2
dist 2
Im in this case 4
should print FASTER
Standard Output Stream:
STARBOARD

Same thing in another case:

speed 1
dist 2
Im in this case 5
should print starboard
Standard Output Stream:
FASTER

Unfortunately I’m a new user so I can’t upload images. Does anybody knows what’s happening here?

I suspect that the problem is linked to the fact that it’s not always obvious to match the current frame with the output…

I believe things would be clearer if we only had the output for the currently displayed frame instead of that scrolling output frame which is often misleading to me, despite the printed corresponding frame ‘somewhere’ on the side of the output.