Mysterious combat at a system

[defaultuser]

FreeOrion_BR_BR_0221_20180601_000151.sav:

[Oberlus]

I've noticed now the version is one year old. Last (non-test) release I guess.
That bug may have been solved long time ago.
Download and try latest test version or wait for incoming 0.4.8 release.

[defaultuser]

If it's a known bug, then there should be some record.

[Oberlus]

Best course of action is playing up to date version and forget it until (if) it happens again.
But if you are interested on digging into the issue, have you tried browsing the open and closed issues in the FreeOrion Github to find out if something like this was reported?

[Dilvish]

Thanks for posting that savegame file. I built that version of FO, turned on the trace logging options for combat and combat log, loaded your save file, and proceeded to capture Zora Alpha as it appeared you had done in that screenshot. For a couple turns after that I did get the same kind of weird combat log. Looking at the server log, it indicated that Conglomerate had an aggressive fleet there still that was triggering combat, but I am guessing that somehow it is empty of ships, because the status listing only lists ships from empire 1. And that shipless fleet would have the default Fleet stealth, which is like 2000, undetectable (the only way to detect a fleet you don't own is to detect a ship in it, or via an Effect like Derelict Scout).

Here is some of the relevant portion of that log:

Code: Select all

00:59:41.659275 [debug] combat : ServerApp.cpp:1863 : CombatConditionsInSystem() for system (1506) Zora α
00:59:41.659286 [debug] combat : ServerApp.cpp:1877 : 	 Empire 1 has at least one aggressive fleet present
00:59:41.659294 [debug] combat : ServerApp.cpp:1877 : 	 Empire 5 has at least one aggressive fleet present
00:59:41.659307 [trace] combat : ServerApp.cpp:1801 : 	** GetPlanetsVisibleToEmpire 1 at system Zora α
00:59:41.659320 [trace] combat : ServerApp.cpp:1807 : 		planet (1512) has visibility rank VIS_FULL_VISIBILITY
00:59:41.659367 [trace] combat : ServerApp.cpp:1807 : 		planet (1518) has visibility rank VIS_FULL_VISIBILITY
00:59:41.659376 [trace] combat : ServerApp.cpp:1801 : 	** GetPlanetsVisibleToEmpire 5 at system Zora α
00:59:41.659386 [trace] combat : ServerApp.cpp:1807 : 		planet (1512) has visibility rank VIS_PARTIAL_VISIBILITY
00:59:41.659397 [trace] combat : ServerApp.cpp:1807 : 		planet (1518) has visibility rank VIS_PARTIAL_VISIBILITY
00:59:41.659405 [debug] combat : ServerApp.cpp:1945 : 	 Empire 5 sees target planet Zora α I
00:59:41.659606 [info] log : Logger.cpp:203 : Added logger named "combat"
00:59:41.659632 [info] log : Logger.cpp:335 : Setting "combat" logger threshold to "trace".
00:59:41.659642 [debug] log : LoggerWithOptionsDB.cpp:105 : Configure log source "combat" from optionsDB using threshold trace
00:59:41.659654 [debug] combat : CombatSystem.cpp:105 : At Zora α Ship 7725 owned by empire 1 visible to empires: 1, 
00:59:41.659673 [debug] combat : CombatSystem.cpp:105 : At Zora α Ship 14192 owned by empire 1 visible to empires: 1, 
00:59:41.659686 [debug] combat : CombatSystem.cpp:105 : At Zora α Ship 14330 owned by empire 1 visible to empires: 1, 
00:59:41.659699 [debug] combat : CombatSystem.cpp:105 : At Zora α Ship 14654 owned by empire 1 visible to empires: 1, 
...
00:59:41.660367 [debug] combat : CombatSystem.cpp:105 : At Zora α Ship 33902 owned by empire 1 visible to empires: 1, 
00:59:41.660383 [debug] combat : CombatSystem.cpp:122 : At Zora α Planet 1512 owned by empire 1 visible to empires: 1, 
00:59:41.660399 [debug] combat : CombatSystem.cpp:122 : At Zora α Planet 1518 owned by empire 1 visible to empires: 1, 
00:59:41.660464 [debug] server : CombatSystem.cpp:1649 : AutoResolveCombat at Zora α
00:59:41.660477 [debug] combat : CombatSystem.cpp:1651 : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
00:59:41.664325 [debug] combat : CombatSystem.cpp:1679 : No empire has valid targets and something to attack with; combat over.

So, it does seem like it would be possible to tinker here more, figure out if that shipless Congolmerate fleet came into being with the attacks between turns 221 and 229, in which case we'd have a chance to identify the causal bug; if the shipless fleet was already preexisting at that the time of the provided savegame file, then identifying the cause would be much trickier

Although I'm tempted to say this is probably just a weird fluke and perhaps not worth following up on, I suspect that it is worth following up on. I suspect that the UI by default might suppress display of fleets that have no ships (if you owned that fleet it would be visible to you even without ships), and if a player modified their UI to be able to see such fleets then they could perhaps be used as an indestructible way to continually trigger combat at an enemy system, stalling their ship repair.

I don't see any sitreps about ships being lost due to psychic effects but has there been any of that in the game? That might be a way for a fleet t lose its last ship without the fleet getting properly retired/destroyed itself.

[defaultuser]

So, it does seem like it would be possible to tinker here more, figure out if that shipless Congolmerate fleet came into being with the attacks between turns 221 and 229, in which case we'd have a chance to identify the causal bug; if the shipless fleet was already preexisting at that the time of the provided savegame file, then identifying the cause would be much trickier

Unfortunately, I don't have any more save games than the one I provided, so it's not possible to get a fleet ID from turns prior to the attack.

I don't see any sitreps about ships being lost due to psychic effects but has there been any of that in the game? That might be a way for a fleet t lose its last ship without the fleet getting properly retired/destroyed itself.

No, my fleets didn't have any capability like that. I can't think of any effects with my fleets that would destroy ships. As far as I know all destruction was done the old-fashioned way, with guns and fighters. Is there any possibility that the fighters could cause this? Those are a newer addition to the game.

I've been playing this version since December/January timeframe. It's the first one that I had that didn't have the "flicker" problem.

I hadn't noticed any instances prior to now, but I wasn't looking for them either. You need to have the right circumstances: a fleet that just completed takeover of a system, is substantially damaged, but held up there by enemy forces at the next target system. Then notice that repair is not proceeding.

[Dilvish]

OK, well I'll note some additional interesting logging:

Code: Select all

14:48:24.724106 [debug] combat : CombatSystem.cpp:122 : At Zora α Ship 3504 owned by empire 5 visible to empires: 1, 5, 
14:48:24.724130 [debug] combat : CombatSystem.cpp:122 : At Zora α Ship 14257 owned by empire 5 visible to empires: 1, 5, 
14:48:24.724141 [error] server : CombatSystem.cpp:102 : CombatInfo::CombatInfo couldn't get fleet with id 34075 in system Zora α (1506) for Ship 14708 owned by empire 5
14:48:24.724160 [debug] combat : CombatSystem.cpp:122 : At Zora α Ship 15026 owned by empire 5 visible to empires: 1, 5, 
14:48:24.724171 [error] server : CombatSystem.cpp:102 : CombatInfo::CombatInfo couldn't get fleet with id 34087 in system Zora α (1506) for Ship 15107 owned by empire 5
14:48:24.724182 [error] server : CombatSystem.cpp:102 : CombatInfo::CombatInfo couldn't get fleet with id 34093 in system Zora α (1506) for Ship 16956 owned by empire 5
14:48:24.724192 [error] server : CombatSystem.cpp:102 : CombatInfo::CombatInfo couldn't get fleet with id 34099 in system Zora α (1506) for Ship 17224 owned by empire 5

In particular, note that this is on the server, yet it is somehow having ships reporting themselves as being part of fleets that the server cannot retrieve.

There was a bugfix merged for the IDAllocator system about a week or so after the date of this version you are playing. That kind of bug seems like a highly likely candidate for causing the kind of trouble encountered here. Please try using a version on or after 780be244484a42b8371533c29a9438815fa967bc

And then report back if you ever encounter this kind of problem again.

[defaultuser]

Interesting. I'll look into it.