incoming sitrep fires outside detection range

Creation, discussion, and balancing of game content such as techs, buildings, ship parts.

Moderators: Oberlus, Committer

Post Reply
Message
Author
Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

incoming sitrep fires outside detection range

#1 Post by Ophiuchus »

Hi the incoming-enemies sitrep is also shown for ships that are not shown on the map.

I think this is because the monster in this case is not stealthed in relation to my detection (so i guess that is what visibleToEmpire checks), but my ships detection range is very small so it is outside detection range of empire.

I would expect VisibleToEmpire to handle this.

Any ideas how to fix this?
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

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

Re: incoming sitrep fires outside detection range

#2 Post by Geoff the Medio »

Please include a link to the relevant other discussion, or a copy of the modified scripts, for context.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: incoming sitrep fires outside detection range

#3 Post by Ophiuchus »

Geoff the Medio wrote:Please include a link to the relevant other discussion, or a copy of the modified scripts, for context.
Hm.. no i was talking about custom_sitreps.txt in master.. should i open a bug report instead?

Relevant piece of code:

Code: Select all

And [
        System
        // The following assets need protection
        Contains And [
            OwnedBy empire = Source.Owner
            Or [
                Planet
                Ship
            ]
        ]        // Only warn if enemies are incoming

        WithinDistance distance = 120 condition = And [
            Fleet
            Not Stationary
            Or [
                OwnedBy affiliation = EnemyOf empire = Source.Owner
                UnOwned
            ]
            VisibleToEmpire empire = Source.Owner
            Turn low = [[ETA_NEXT_TURN]] high = [[ETA_NEXT_TURN]]
            (RootCandidate.ID = LocalCandidate.NextSystemID)
        ]
(Looking again at the code i Probably need to tweak the withinDistance distance to the maximum of the ships'/planets' detection range... not sure how to do this)
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

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

Re: incoming sitrep fires outside detection range

#4 Post by Geoff the Medio »

Perhaps first post some screenshots illustrating this happening, and verify your theory about what's happening by reloading and revealing the map by converting a planet's population to super testers. Test save the reproduces the issue would also be helpful.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: incoming sitrep fires outside detection range

#5 Post by Dilvish »

Ophiuchus wrote:Looking again at the code i Probably need to tweak the withinDistance distance to the maximum of the ships'/planets' detection range... not sure how to do this
I don't think that's the right approach, because it would be fine if the incoming fleet were made visible to you by some other planet/ship.
Ophiuchus wrote:Hi the incoming-enemies sitrep is also shown for ships that are not shown on the map.

I think this is because the monster in this case is not stealthed in relation to my detection (so i guess that is what visibleToEmpire checks), but my ships detection range is very small so it is outside detection range of empire.

I would expect VisibleToEmpire to handle this.

Any ideas how to fix this?
VisibleToEmpire does indeed check actual visibility, not just if its stealth is less than your detection strength. Are you really sure you did not have visibility from some other source? Perhaps one of your other nearby ships stumbled upon a derelict that turn, exposing the incoming fleet?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: incoming sitrep fires outside detection range

#6 Post by Ophiuchus »

Dilvish wrote:VisibleToEmpire does indeed check actual visibility, not just if its stealth is less than your detection strength. Are you really sure you did not have visibility from some other source? Perhaps one of your other nearby ships stumbled upon a derelict that turn, exposing the incoming fleet?
Just had a look at the game. No derelict was discovered.

I think the reason could be an ion storm and timing issue.

The approaching krill swarm is outside my other detection facilities, but it probably would be visible for the ship which gets the incoming (krill speed 30, detection range 25), but the ship is in an ion storm (-40 detection range).

So i guess the ion storm effect gets added after visibility is checked(?). Both the ion storm and the custom sitrep not have explicit priority, so DEFAULT.

Putting the sitrep priority to END_CLEANUP_PRIORITY does hide the message, so i guess it works. Added a PR.
Last edited by Ophiuchus on Thu Feb 15, 2018 12:06 pm, edited 1 time in total.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: incoming sitrep fires outside detection range

#7 Post by Vezzra »

Ophiuchus wrote:The approaching krill swarm is outside my other detection facilities, but it probably would be visible for the ship which gets the incoming (krill speed 30, detection range 25), but the ship is in an ion storm (-40 detection range).
That could very well be the cause for the issue. The order in which things are processed during turn execution leads to issues with the effect fields like ion storms have on e.g. ships, because they happen kind of delayed.

For example, when you attack an enemy system currently covered by a molecular cloud, and your fleets jump in from outside the cloud, in the combat that takes place the effect of the molecular cloud (reduced shields) apply to the defenders (because they have already been in the cloud), but not to the attackers (because they just went into the cloud this turn, and the shield reducing effect is only applied after combat resolution).

We have already had discussions about that, but not reached a general consensus on what to do about it yet. IMO it needs to be fixed, because, as this discussion shows, the current behavior causes confusing issues for players.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: incoming sitrep fires outside detection range

#8 Post by Ophiuchus »

Vezzra wrote:We have already had discussions about that, but not reached a general consensus on what to do about it yet. IMO it needs to be fixed, because, as this discussion shows, the current behavior causes confusing issues for players.
As in this special case the effect is basically only "reading" state, so i put it to the very end priority, which should be fine.
Made a PR for this.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: incoming sitrep fires outside detection range

#9 Post by Ophiuchus »

Ophiuchus wrote:
Vezzra wrote:We have already had discussions about that, but not reached a general consensus on what to do about it yet. IMO it needs to be fixed, because, as this discussion shows, the current behavior causes confusing issues for players.
As in this special case the effect is basically only "reading" state, so i put it to the very end priority, which should be fine.
Made a PR for this.
This is embarassing :oops:

I just saw that the priorities macros include was missing and so the parsing failed and thats why the message didnt show up.
Fixed the import, had a look again... and :sigh: the message is there again.

Not sure how to proceed.


Game state from turn 32. So load the game and advance one turn. In turn 33, a warning about incoming ships occurs, but no ships are visible. In turn 34 a krill arrives:

[The extension sav has been deactivated and can no longer be displayed.]

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: incoming sitrep fires outside detection range

#10 Post by Dilvish »

Ophiuchus wrote:Game state from turn 32. So load the game and advance one turn. In turn 33, a warning about incoming ships occurs, but no ships are visible. In turn 34 a krill arrives
You seem convinced that you indeed should not have been able to see that incoming krill, but perhaps there might be more broadly something a bit funky going on with the new meter mechanics and visibility change timing. In a game yesterday, on turn N I got Radar, and on turn N+1 a floater appeared right next to my home system. It had not become visible to me on the turn I got Radar, which is when they used to become visible. This could possibly be a problem of the UI being out of sync with back-end changes, related to the CurrentMeter vs InitialMeter problem that made itself known via invasion trouble.

I'll keep my eyes out for what happens next time I get Radar. (And when I get a chance I will try to look at your savegame as well.)
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: incoming sitrep fires outside detection range

#11 Post by Geoff the Medio »

Dilvish wrote:It had not become visible to me on the turn I got Radar, which is when they used to become visible. This could possibly be a problem of the UI being out of sync with back-end changes, related to the CurrentMeter vs InitialMeter problem that made itself known via invasion trouble.

I'll keep my eyes out for what happens next time I get Radar. (And when I get a chance I will try to look at your savegame as well.)
At least for immobile systems, active radar appears to take effect the turn it is researched, for me...
effect accounting and sitrep
effect accounting and sitrep
active_radar_first_turn_accounting.png (57.67 KiB) Viewed 8023 times
map before researching active radar
map before researching active radar
before_active_radar.png (101.77 KiB) Viewed 8023 times
map after researching active radar
map after researching active radar
after_active_radar.png (107.53 KiB) Viewed 8023 times

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: incoming sitrep fires outside detection range

#12 Post by Dilvish »

Geoff the Medio wrote:At least for immobile systems, active radar appears to take effect the turn it is researched, for me...
Yes, and in the game I am referring to, as well, my system detection range meters (and their dispay in the UI) all increased on the turn I got Radar. But the floater, which had to have been in range for both turns, was not made visible in the UI until the next turn. I clicked on it to double check if it was a small krill that might have spontaneously just then, because it was surprising.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: incoming sitrep fires outside detection range

#13 Post by Ophiuchus »

Dilvish wrote:
Ophiuchus wrote:Game state from turn 32. So load the game and advance one turn. In turn 33, a warning about incoming ships occurs, but no ships are visible. In turn 34 a krill arrives
You seem convinced that you indeed should not have been able to see that incoming krill, but perhaps there might be more broadly something a bit funky going on with the new meter mechanics and visibility change timing. In a game yesterday, on turn N I got Radar, and on turn N+1 a floater appeared right next to my home system. It had not become visible to me on the turn I got Radar, which is when they used to become visible. This could possibly be a problem of the UI being out of sync with back-end changes, related to the CurrentMeter vs InitialMeter problem that made itself known via invasion trouble.

I'll keep my eyes out for what happens next time I get Radar. (And when I get a chance I will try to look at your savegame as well.)
Thats probably a different issue... i didnt research new detection tech around those turns.
Still looking for suggestions. Or is this so minor that we should forget about it until meters are more stabilized?
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: incoming sitrep fires outside detection range

#14 Post by Dilvish »

Ophiuchus wrote:Still looking for suggestions. Or is this so minor that we should forget about it until meters are more stabilized?
No, it's a good reminder, and I am suspecting this is an indication of another meter that needs adjustment. A quick scan through the Visibility code indicated that at least for fields we are still using the CurrentMeter value whereas I think we should be using the InitialMeter value:

Code: Select all

if (field->GetMeter(METER_STEALTH)->Current() > detection_strength)
I didn't have time at the moment to fully go through the Visibility code, but I expect that all the Visibility determinations are in need of that same update.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply