Remove Signal count from the FSS

[iain666]

Resolving the number of signals, especially geological signals, on a planet seems to take significant time. If there are none at all this comes back pretty quickly.

Remove the count from the FSS, just give us a Geological Yes/No, Biological Yes/No in the FSS and System Map and leave the count until the body is mapped. The counting can happen in the background between resolving the body via FSS or fly past and by the time mapping is done it should be ready. If it's not then, and only then, give us the spinning disc with some kind of 'Processing probe data' message.

The count is part of the detailed info that should logically come from the mapping really, and it would make the FSS more user friendly if the waiting-for-signal-counting-spinning-disc was removed, a win all round IMO.

If a Major/Average/Minor indication of the range of the count can be quickly arrived at then that could be included in the FSS/System Map data.

 

[Micha]

+1; nothing much to add here really.

Except in general the FSS Scanning interface could do with a review. That big blue "Discovered Xyz" overlay banner needs to go, for example. Especially when scanning faster than it can display (which always happens with asteroid belts) it gets backlogged and prevents the actual body data from being displayed until it has caught up.

 

[BinakAlgo]

+1; nothing much to add here really.

Except in general the FSS Scanning interface could do with a review. That big blue "Discovered Xyz" overlay banner needs to go, for example. Especially when scanning faster than it can display (which always happens with asteroid belts) it gets backlogged and prevents the actual body data from being displayed until it has caught up.

I think it takes longer to load because it is getting "generated" when you scan a planet for the first time.

Maybe.

 

[Micha]

I think it takes longer to load because it is getting "generated" when you scan a planet for the first time.

Possibly; in which case the OP's suggestion to just say Bio:Yes/No Geo:Yes/No should improve the scanning speed; the actual POI generation can then run when/if you start mapping the body.

 

[sandkid]

Possibly; in which case the OP's suggestion to just say Bio:Yes/No Geo:Yes/No should improve the scanning speed; the actual POI generation can then run when/if you start mapping the body.

This.

From a logic standpoint, how does the FSS even know the counts? There hasn't been a surface scan which...I would think...dictates such information.

 

[m0rl0ck]

+1; nothing much to add here really.

Except in general the FSS Scanning interface could do with a review. That big blue "Discovered Xyz" overlay banner needs to go, for example. Especially when scanning faster than it can display (which always happens with asteroid belts) it gets backlogged and prevents the actual body data from being displayed until it has caught up.

Both excellent suggestions, this and the OP.

I especially dont need a count of geological signals, unless i want to map it. At this point geo sigs are beginning to smell of spam.

 

[BinakAlgo]

Possibly; in which case the OP's suggestion to just say Bio:Yes/No Geo:Yes/No should improve the scanning speed; the actual POI generation can then run when/if you start mapping the body.

True, it'll be better to have them generated with a DSS, not an FSS. If the FSS is really capable of such magic then I want my docking computer in my wristband clock, please.

 

[EWanderer]

aye I already made this point back in beta. they could still start showing the numbers once they are in, but a first have or not have would be a great time-saver.

 

[varonica]

I think it takes longer to load because it is getting "generated" when you scan a planet for the first time.

Maybe.

I suspect the numebrs and location are generated procedurally, so they are always in the same place for everyone and the time it takes is how long it takes for the data to download from the galaxy server because I have noticed my game gets laggy which wouldn't happen if it was generated locally but would if my conenction is getting flooded, it is a slow connection I do admit so it really feels it if I do things in the background.

And yes, ideally the FSS should just tell us whether a body has bio and/or geo (and other stuff of course like guardian/human) and give us numbers during probing, that makes sense both technically and practically.

 

[Factabulous]

Yes to all this, unsurprisingly not convinced the poi are coming over the network as increasing your frame rate seems to speed up the process... But we really only need a yes/no on each category.

 

[Riverside]

Yes I'd support this if it provides the benefit of making the reveal immediate or as near as makes no difference.

I suggest a simple summary of the presence of Geological (the existing level of info on type should be retained), Biological (a type description analogous to Geologocal POIs could be added) and Other (again a type could be added/retained).

 

[varonica]

Yes to all this, unsurprisingly not convinced the poi are coming over the network as increasing your frame rate seems to speed up the process... But we really only need a yes/no on each category.

That may be a different issue altogether though, increasing frame rate is a vid card bound process and calculating the locations of POI's if they are calculated locally should be a CPU bound process. The point being of course is that the procedural generation isn't done locally and extracting the data from the seed for such a small set should be almost instant if you were the only one playing and there was no server latency.

Possibly speeding up the process is caused by an animation setting that's bound by the refresh rate, does the little spinny thing go faster as you increase refresh rate? Although I suspect if that's the case it's only part of the problem.

 

[Riverside]

That may be a different issue altogether though, increasing frame rate is a vid card bound process and calculating the locations of POI's if they are calculated locally should be a CPU bound process. The point being of course is that the procedural generation isn't done locally and extracting the data from the seed for such a small set should be almost instant if you were the only one playing and there was no server latency.

Possibly speeding up the process is caused by an animation setting that's bound by the refresh rate, does the little spinny thing go faster as you increase refresh rate? Although I suspect if that's the case it's only part of the problem.

This little spinny thing does not go detectably faster

Geological POIs were the first to be introduced into the game and it may be that they were originally tied into terrain generation threads (ie GPU bound). Biological only bodies do not see the same delay, they are revealed virtually instantly every time ime. I haven't scanned enough 'other' bodies to state with confidence that they are never delayed.

There is a similar slow down when plotting routes on the galmap - if you are zoomed in close enough to see the individual stars the framerate plummets (with no apparent hardware resource bottleneck) and plotting a long route will progress slowly. Zoom out & the framerate, GPU & CPU activity return to normal and the route plot progresses noticeably more quickly.

 

[Factabulous]

That may be a different issue altogether though, increasing frame rate is a vid card bound process and calculating the locations of POI's if they are calculated locally should be a CPU bound process.

GPUs can be used not only for displays, but also for very fast parallel operations, say ... decoding something. So I think you're making some assumptions there Easy enough for you to test out - the game can lock the display to different refresh rates so you can check the difference. Anyway, this is very OT, but hopefully the devs will just assume its another agreeing vote

And while I'm OT: Riverside - not convinced Bio are faster, just there are often less of them - pretty sure I've seen slow Bio (advantages of a slow GPU ). But there are certainly far more Geo, so if you fix anything, fix them - as I'm waiting cumulative minutes on some systems.