Closed dgets closed 5 years ago
Checked the first conditional and, while there were some bugs to find that have increased bot efficiency, and logging improvements to be had, this does not seem to be the primary source of the problem.
I have managed to identify one case as where the bots slip into the WTF code. It looks like, if their halite_amount >= 900
, and the current cell has no halite available, that was happening. So I've got that fixed, and will be pushing it shortly. NOTE: It seems that this has eliminated the WTF entries in the log file of a full, 400 turn game.
I'm thinking that there may, indeed, be something wrong in seek_n_nav.Nav.scoot()
, as you can see in the following log snippet that, before scooting is supposed to be completed, after turn 004 the ShipHistory
conditional tests and/or cell's halite_amount
cause it to qualify to fall into randomly wandering in turn 005. It then returns to scooting in turn 6...
Applicable log snippet:
INFO:root:=============== TURN 003 ================ DEBUG:root: - me.get_ships() dump: [Ship(id=0, Position(22, 16), cargo=0 halite )] DEBUG:root: Making sure turn (2 <= 318) INFO:root: - processing ship.id: 0 DEBUG:root: - ship.id 0 in primary mining conditional INFO:root: - ship.id: 0 scooting to Position(24, 19) DEBUG:root:Killing from history for reassignment: [] DEBUG:root:Killing from history due to ship 8-x: [] INFO:root: - updating frame INFO:root:=============== TURN 004 ================ DEBUG:root: - me.get_ships() dump: [Ship(id=0, Position(22, 16), cargo=5 halite )] DEBUG:root: Making sure turn (3 <= 318) INFO:root: - processing ship.id: 0 DEBUG:root: - ship.id 0 in primary mining conditional INFO:root: - ship.id: 0 scooting to Position(24, 19) DEBUG:root:Killing from history for reassignment: [] DEBUG:root:Killing from history due to ship 8-x: [] INFO:root: - updating frame INFO:root:=============== TURN 005 ================ DEBUG:root: - me.get_ships() dump: [Ship(id=0, Position(23, 16), cargo=0 halite )] DEBUG:root: Making sure turn (4 <= 318) INFO:root: - processing ship.id: 0 DEBUG:root: - ship.id 0 in primary mining conditional INFO:root: - ship.id: 0 randomly wandering DEBUG:root: - ship.id: 0 ShipHistory-->ship ID: 0, location: Position(23, 16), destination: Position(24, 19), turnstamp set: 1, secondarymission: Missions.in transit, primary_mission: Missions.mining DEBUG:root: - ship.id: 0 ShipHistory after processing-->ship ID: 0, location: P osition(23, 16), destination: Position(24, 16), turnstamp set: 4, secondary_miss ion: Missions.in_transit, primary_mission: Missions.mining INFO:root: - ship.id: 0 one step at a time... DEBUG:root:Killing from history for reassignment: [] DEBUG:root:Killing from history due to ship 8-x: [] INFO:root: - updating frame INFO:root:=============== TURN 006 ================ DEBUG:root: -* me.get_ships() dump: [Ship(id=0, Position(23, 17), cargo=0 halite )] DEBUG:root: Making sure turn (5 <= 318) INFO:root: - processing ship.id: 0 DEBUG:root: - ship.id 0 in primary mining conditional INFO:root: - ship.id: 0 scooting to Position(24, 16) DEBUG:root: - spawning ship DEBUG:root:Killing from history for reassignment: [] DEBUG:root:Killing from history due to ship 8-x: [] INFO:root: - updating frame
This game is definitely going to need some more in-depth analysis. It would probably help to add debugging output for the MapCell
's current halite_amount
, since that's used in the applicable conditionals as well.
After a bit of log analysis, it doesn't seem to matter what the primary mission is before it starts randomly wandering. In the log there is a transition from scooting to this state, as well as mining. It would really help to have a script to parse the logs for these transitions.
I believe it's pretty imperative at this point to add the contents of the MapCell
to the debug output.
There is also an issue in seek_n_nav.StartUp.get_initial_minimum_distance()
that is causing some issues here. IE destination
is not properly set, nor was the profitable direction utilized before. Fixing those issues now.
Ships are wandering far too much after they've gotten their initial distance, and still have halite available on the cell that they're currently occupying. This is burning unnecessary halite in a few different ways. I'm currently handling log analysis. However, before that's completed, here are a few of the different areas that may be applicable in
core_processing.Core.primary_mission_mining()
:mining.Mine.low_cargo_and_no_immediate_halite()
, and its associated (1st) conditional (NOTE: adding aprimary_mission
check to the conditional did not help the wandering at all-- double check to verify that this check hasn't already been handled in themining.Mine
code, which may mean that my addition of the check here could've made things worse)seek_n_nav.Nav.scoot()
, and its associated (2nd) conditionalmining.Mine.done_with_transit_now_mine()
, and its associated (3rd) conditional (NOTE: should there be a check to see if the destination matches up here, or is that handled in themining.Mine
code?)seek_n_nav.Nav.return_halite_to_shipyard()
, and the 4th conditional (doubtful that issues lay here, log analysis will help)else
clause, which ships are still ending up in at times