Context
Some of us have helped with bug/issue resolution in the past, for example personally, helping identify a potential source of the Trident SLF overheat issue.
Having looked at the Geological POI scan times issue quite a bit, it seems fairly evident what the cause is is.
Further, on reddit, someone shared a response they'd had from support indicating that the issue was being looked at and confirming at least
where the cause is was as suspected.
The nature of the matter
The problem isn't a bug, it's inherent in the current design of the process - it's a bottleneck in the current process flow.
Changing the actual part of the process which results in the bottleneck is likely to be a major endeavour with knock on consequences.
So the solution is to change the process flow so that the bottleneck doesn't occur.
The bottleneck
Zooming in on a body invokes the planet generation system. The generation of Geological POIs requires the planet generation system to have progressed to a certain point, which takes a fair amount of time (and is GPU performance dependent).
Why fixing the bottleneck itself isn't an option
Because geological POIs are generated as part of the planet generation, which was revised in 3.0, decoupling it is probably non-viable, and if it was viable would likely change the Geological POIs on every planet across the entire game.
The partial workaround which anyone can currently use
Whether a body has vulcanism is confirmed almost instantly. Only bodies with vulcanism have geological POIs. A few bodies with vulcanism don't have geological POIs but these are very rare (estimate - 1 in 1,000). Therefore if a body has vulcanism it can be treated as having geological POIs, flown to, and the DSS used to reveal the POIs.
The core of the issue
The issue is not so much with the Geological POIs themselves, as if someone is specifically interested in them, the workaround tackles that fine.
The issue is that the scan time for Geological POIs prevents all other types of POI being shown until it's complete.
There are huge numbers of bodies with Geological POIs, and after a few, they're unlikely to each warrant travelling to and DSS scanning.
The result is that there is a massively decreased possibility of non-geological POIs being found on/around planets with vulcanism compared to planets without vulcanism. Also it means anyone looking for the non-Geological POIs faces a massively increased time when bodies with vulcanism are involved compared to then they aren't.
The proposed solution
Part A
The proposed solution is to:
1. have the FSS return only the presence of POIs, not the number
2. de-couple the generation of the geological POIs from the FSS
3. use whether a planet has vulcanism or not as the single determinant of whether geological POIs are present.
Specifically, this change (in pseudo-code):
As-Is:
On FSS_Zoom (call Planet_Generation_System:
(
Return visuals;
On Geological_Site_Location_Generation complete, Return number_of_Geological-POIs;
)
Determine numbers of other POIs
)
To-Be:
On FSS_Zoom (if planet.has_vulcanism set Geological_Signals_Detected = yes
call Planet_Generation_System:
(
Return visuals;
)
Determine presence of other POIs
)
Part B (Lower priority)
Add the results of whether POIs have been detected by the FSS to the detailed body information on the System Map.
Assumptions
1. That other POI types can be treated in the same way as the Geological ones, and their presence generated/determined without needing the planet generation system to get to the point needed to determine the number of Geological sites.
Solution development time, costs and resource needs
<Section added for completeness, can't be completed external to FD. Would estimate these are all low in the scale of things though.>
Dis-benefits of solution
| Number | Description | Likely Impact | Mitigation | Likely impact with mitigation | Estimated cost of mitigation |
| 1 | A very small number of bodies which will be reported as having Geological signals will if DSS probed, not return any POIs. When encountered this may result in some annoyance, bug reports and complaints. | Very low. | Pre-emptive comms to playerbase to explain why this has may result, focussing on the much larger benefit provided by having this situaiton. | Very very low. | Very low*. |
*Just a personal guess based purely on other experience.
Solution rollout issues
| Number | Type | Description | Mitigation/Action | Estimated Cost |
| 1 | Change | For players there will be a change from the FSS showing numbers of POIs to just whether signals have been detected. Where players are unaware why this has been done, this will result in some confusion, and may result in some resistance and/or complaints. | Comms to playerbase explaining why the change is being made and the benefits that players will get from it. (Including info related to mitigation of Dis-benefit 1) | Very low. |
| | | | |
Solution rollout risks
(Note, 1&2 are just what I would anticipate to be standard known risks for any update FD does. They're there for completeness. Any risks specific to this particular solution will be added.)
| Number | Description | Probability | Impact | Mitigation options | Mitigation Costs |
| 1 | Solution doesn't work when pushed to live clients | Should be low (in principle) | Medium | TBC | TBC |
| 2 | Packaging and deployment results in issues with unrelated areas | Medium | Highly dependent on effected area(s). Could be very low. Could be very high. | TBC | TBC |
S