fleet display bug and persistent sitrep

Describe your experience with the latest version of FreeOrion to help us improve it.

Moderator: Oberlus

Forum rules
Always mention the exact version of FreeOrion you are testing.

When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.
Post Reply
Message
Author
User avatar
stpa
Space Kraken
Posts: 157
Joined: Mon Mar 12, 2018 1:08 pm

fleet display bug and persistent sitrep

#1 Post by stpa »

i have been seeing an occasional bug lately in current master* where marching orders are given to fleets but do not properly show up on the map. expected behaviour: fleet icon moves from upper right to upper left to indicate its on the move, dotted line to target on the map, target scan circle, ETA shows up in fleet window, actual movement next turn. actual behaviour missing: fleet icon does not move from stationary to on the move position, dotted line to target is missing, but the order is executed next turn and ETA shows up in fleet window. the log output looks normal and does not tell me much.

Code: Select all

09:39:15.476376 {...} [debug] client : Order.cpp:336 : FleetMoveOrder removing fleet 81953 current system location 35904 from shortest path to system 35920
09:39:15.476438 {...} [debug] client : Order.cpp:409 : FleetMoveOrder::ExecuteImpl Setting route of fleet 81953 at system 35904 to:  35920
09:39:25.399936 {...} [debug] client : MapWnd.cpp:5534 : PlotFleetMovement  execute
09:39:25.400297 {...} [debug] client : Order.cpp:336 : FleetMoveOrder removing fleet 41712 current system location 28760 from shortest path to system 28744
09:39:25.400379 {...} [debug] client : Order.cpp:409 : FleetMoveOrder::ExecuteImpl Setting route of fleet 41712 at system 28760 to:  36720 28744
09:39:34.720734 {...} [debug] client : MapWnd.cpp:5534 : PlotFleetMovement  execute
09:39:34.721102 {...} [debug] client : Order.cpp:336 : FleetMoveOrder removing fleet 41696 current system location 28312 from shortest path to system 28296
09:39:34.721294 {...} [debug] client : Order.cpp:409 : FleetMoveOrder::ExecuteImpl Setting route of fleet 41696 at system 28312 to:  28296
09:39:37.458698 {...} [debug] client : MapWnd.cpp:5534 : PlotFleetMovement  execute
09:39:37.458879 {...} [debug] client : Order.cpp:336 : FleetMoveOrder removing fleet 41696 current system location 28312 from shortest path to system 28296
09:39:37.458925 {...} [debug] client : Order.cpp:409 : FleetMoveOrder::ExecuteImpl Setting route of fleet 41696 at system 28312 to:  28296
09:39:38.442967 {...} [debug] client : MapWnd.cpp:5534 : PlotFleetMovement  execute
09:39:38.443186 {...} [debug] client : Order.cpp:336 : FleetMoveOrder removing fleet 41696 current system location 28312 from shortest path to system 28296
09:39:38.443239 {...} [debug] client : Order.cpp:409 : FleetMoveOrder::ExecuteImpl Setting route of fleet 41696 at system 28312 to:  28296
09:39:43.709009 {...} [debug] client : MapWnd.cpp:5534 : PlotFleetMovement  execute
09:39:43.709232 {...} [debug] client : Order.cpp:336 : FleetMoveOrder removing fleet 41696 current system location 28312 from shortest path to system 28296
09:39:43.709285 {...} [debug] client : Order.cpp:409 : FleetMoveOrder::ExecuteImpl Setting route of fleet 41696 at system 28312 to:  28296
that last move order was given multiple times because it shows the bug where it does not show up properly on the map.

*: master without any of the as of yet unapproved pr's, so the actual current master branch.

also, i have been seeing some cases where the SITREP_POP_THRESHOLD kept on showing up in every following sitrep instead of only once.

anyone else noticed that? i am not sure how to go about debugging such things
Attachments
after giving marching orders that do not show up properly.png
after giving marching orders that do not show up properly.png (740.75 KiB) Viewed 1203 times

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13603
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: fleet display bug and persistent sitrep

#2 Post by Geoff the Medio »

I've been reworking how UniverseObjects get created, in particular how their StateChangedSignals get integrated with the Universe's flag to inhibit those signals, which broke some of those signal connections. Should be fixed in https://github.com/freeorion/freeorion/ ... al_getters and master soon.

SITREP_POP_THRESHOLD issues are probably unrelated.

Post Reply