Page 1 of 1

SitRep for enemy sensor tech advances?

Posted: Sun Dec 30, 2018 4:27 pm
by Telos
This is a simple feature request: could we make the game generate a SitRep whenever an enemy improves their sensor technology (e.g., radar, neutron, sensors, omni)? This information is highly relevant to strategies that use stealth to hide ships or planets, like the new Sly species.

This information is, in theory, already available to players in at least three ways: (1) the sensor circles around enemy systems become larger (but that's easy to miss noticing), (2) motion paths for your no-longer-invisible ships across enemy military vessels now have Red X's meaning they'll get intercepted rather than yellow X's meaning they only have to slow to sneak by (but you have to click on your ships to see those, and have to notice and understand the difference in X color), and (3) you can pull up the Empires overview table and widen it to see everyone's detection strengths including unmet civs (but that clutters limited screen real estate with a lot of irrelevant info, scrolling it in many-civ games is a pain, and it's often easy to overlook changes when different civs have different tech levels). It would be a significant quality of life improvement to just generate a SitRep when this happens rather than forcing us to watch for it ourselves.

Side question: are SitRep's generated by FOCS scripting (if so, I could probably write a quick fix), or do they require changes in the game's code itself?

Re: SitRep for enemy sensor tech advances?

Posted: Sun Dec 30, 2018 8:09 pm
by Vezzra
Telos wrote:
Sun Dec 30, 2018 4:27 pm
are SitRep's generated by FOCS scripting
Yes.
or do they require changes in the game's code itself?
Depends on what you want to do. The question is if the current capabilities of FOCS provide the means to trigger the desired sitrep for the desired purpose, or if we need to extend FOCS to make it possible.

Re: SitRep for enemy sensor tech advances?

Posted: Sun Dec 30, 2018 11:46 pm
by Dilvish
I think there is enough support for at least a version of this, but with current scripting it is seeming tricky to me to avoid spamming the message unless you have seen the enemy capital and can use that as an anchor to limit the sitrep to one per empire. The key comparison would be something like

Code: Select all

((CurrentTurn == TurnTechResearched empire=<some_empire_reference> name = <some_tech_name>)
And I forget just when you get the info on enemies researching tech, vs when the sitreps are generated, it's conceivable you might need to add a +1 to that left hand side. And it seems to me you'd need a separate Effect for each respective tech (though I suppose you could make a more generic message that doesn't identify the specific tech and just tells you they upgraded their detection range last turn). Depending on where/how you do the comparison the empire reference might be LocalCandidate.Owner or Target.Owner

Re: SitRep for enemy sensor tech advances?

Posted: Thu Jan 03, 2019 3:35 pm
by Ophiuchus
Just saying ive got a kind-of working implementation SitRep_Sensor_Upgrades branch.

TurnTechResearched does not seem to be available for tech researched in the current turn (?)
and also if not researched it returns 0, which is probably wrong.

Re: SitRep for enemy sensor tech advances?

Posted: Thu Jan 03, 2019 8:56 pm
by o01eg
Will it work if server won't send research of other empires?

Re: SitRep for enemy sensor tech advances?

Posted: Thu Jan 03, 2019 10:03 pm
by Ophiuchus
Note that maybe due to a current pecularity of how effects application works (see TurnTechResearched not working the first turn) the current implementation is one turn too late.
I am looking at the following workarounds:
  • let the detection effect start one turn later
  • instead of activating the sitrep when the new tech is researched, activate it when the detection doesnt match the predecessor detection tech anymore (would also be activated one turn late)
o01eg wrote:
Thu Jan 03, 2019 8:56 pm
Will it work if server won't send research of other empires?
Not sure how the client/server and effect calculation works. In my understanding the sitrep gets generated by the server which has all information(?)

edit1: add TurnTechResearched problem info

Re: SitRep for enemy sensor tech advances?

Posted: Sun Jan 06, 2019 3:18 pm
by Ophiuchus
As having the sitrep one turn late does not offer any benefit, i had to shift the application of detection tech to one turn after the tech was researched. See PR-2344

Re: SitRep for enemy sensor tech advances?

Posted: Wed Jan 09, 2019 12:30 pm
by Ophiuchus
Dilvish wrote:I am not a fan of delaying the benefit of a researched tech by a turn just to support a convenience sitrep for the other players. If we really did take that route, then yes, some very clear Pedia documentation of such would be absolutely needed.
I think the desire for clear documentation is mostly due to what current users are used to in FO-i think the current way things work is as well not documented.

Actually i dont think the current system is so great either from UI perspective. You research a tech and suddenly your values are "silently" different. Compared to that if the tech unlocks something you get a note about that.
Sometimes effects happen immediately and sometimes they take a turn for no apparent reason.

Maybe the researching empire should also get a "Your empire upgraded its intergalactic sensor arrays, increasing detection to [DETECTION_METER]" when the effect applies.

This may be only a "convenience", but maybe its better UI.

Re: SitRep for enemy sensor tech advances?

Posted: Wed Jan 09, 2019 12:41 pm
by Oberlus
Woldn't the better be to "fix" the code so that the FOCS TurnTechResearched condition works on the turn it should?

Re: SitRep for enemy sensor tech advances?

Posted: Wed Jan 09, 2019 9:45 pm
by Ophiuchus
Oberlus wrote:
Wed Jan 09, 2019 12:41 pm
Woldn't the better be to "fix" the code so that the FOCS TurnTechResearched condition works on the turn it should?
i started the discussion in TurnTechResearched not working the first turn on how to fix the underlying problem, but it is not so easy and i am not sure if this will be fixed.