SUGGESTION: 2.2's Visited System - Have a dedicated Menu option to get/download all visited systems

[NeilF]

Unfortunately I doubt that will ever be the case. for Example:

Look at how the System map works currently: Open system map - wait for it to load - wait - wait - system map open. Close it and open it again - the whole load process starts anew.

Well, we'd need FD to comment on that.

The key indication for me was the old API was dishing this list out with every call so clearly that wasn't immediately an issue. They later removed it, and quite rightly TBH, as what's the point in dishing out an ever increating list of thousands of (visited) systems over and over typically minutes apart?

But the fact they once showed they could seemingly easily render a visited list to me would imply they could again, albeit via an alternative call that could be as restrictive as you like. eg: Only one call per day/week etc...

And let's be honest, most CMDRs will never use it. And the majority of those that do, will probably use it once or twice ever!


ps: A retrieve of a CMDRs visited list is quite probably going to take a fraction of second (unless their's some bizarre DB reason), and result in the construction of a list comparable in size (probably smaller) to the size of the HTML that's be constructed to show this very web page you're now reading. And it's quite possible, that more IO and processing indeed went on to render this page than it would to give you back your list of visited systems

 

[Alec Turner]

Unfortunately I doubt that will ever be the case. for Example:

Look at how the System map works currently: Open system map - wait for it to load - wait - wait - system map open. Close it and open it again - the whole load process starts anew.

That is the game actively requesting the system details from the database - everytime you open the map. The request isn't even commander specific. (and yes, the constant loading drives me nuts)

Actually it's not. Took me a while to get my head around this but THERE IS NO DATABASE (which kind of makes sense when you think about it ... a database of 400 BILLION systems! that's not practical). Everything is procedurally generated, from a "seed" number that's little more than the system's galactic co-ordinates. Even the name of the system is generated (see the beautiful work of Cmdrs Alot and Jacki Silver for details - https://forums.frontier.co.uk/showthread.php/196297-RV-Sonnenkreis-Decoding-Universal-Cartographics). What's taking the time when you open the system map is your PC running the "Stellar Forge" system generation code (which uses rules covering everything from astrophysics to plate tectonics) to turn that seed number into a system of astronomical bodies. It's incredible really and quite quite beautiful.

 

[JYD75]

Actually it's not. Took me a while to get my head around this but THERE IS NO DATABASE (which kind of makes sense when you think about it ... a database of 400 BILLION systems! that's not practical). Everything is procedurally generated, from a "seed" number that's little more than the system's galactic co-ordinates. Even the name of the system is generated (see the beautiful work of Cmdrs Alot and Jacki Silver for details - https://forums.frontier.co.uk/showthread.php/196297-RV-Sonnenkreis-Decoding-Universal-Cartographics). What's taking the time when you open the system map is your PC running the "Stellar Forge" system generation code (which uses rules covering everything from astrophysics to plate tectonics) to turn that seed number into a system of astronomical bodies. It's incredible really and quite quite beautiful.

Hmm, ok, if the system has never been discovered before I understand that, but if 1 single person discovered the system already it makes little sense. If it ran the stellar forge for each and every system every time to generate the system would we then not get different systems on different PC's at the same location?

Whatever it is, it needs some optimisation, basically I feel that if it has run once, the data is there and that should mean it does not need to run again.

And they do need to save the names of the first discoveries somewhere, hence there is at least a database with that information that is being queried at that time aswell.

Well, we'd need FD to comment on that.

The key indication for me was the old API was dishing this list out with every call so clearly that wasn't immediately an issue. They later removed it, and quite rightly TBH, as what's the point in dishing out an ever increating list of thousands of (visited) systems over and over typically minutes apart?

But the fact they once showed they could seemingly easily render a visited list to me would imply they could again, albeit via an alternative call that could be as restrictive as you like. eg: Only one call per day/week etc...

And let's be honest, most CMDRs will never use it. And the majority of those that do, will probably use it once or twice ever!


ps: A retrieve of a CMDRs visited list is quite probably going to take a fraction of second (unless their's some bizarre DB reason), and result in the construction of a list comparable in size (probably smaller) to the size of the HTML that's be constructed to show this very web page you're now reading. And it's quite possible, that more IO and processing indeed went on to render this page than it would to give you back your list of visited systems

Hmm, ok, I was a bit late to the party so I missed that bit where the API actually did deliver the info every time.
Maybe the elegant solution would be to add that function to the options menu so it would only be called when it was really needed?

Would be really great if FD would give input on this

 

[NeilF]

Hmm, ok, I was a bit late to the party so I missed that bit where the API actually did deliver the info every time.
Maybe the elegant solution would be to add that function to the options menu so it would only be called when it was really needed

Well, news that the old API dished out this visited data was mentioned after I created this thread. I then just seemed the major pieces of the puzzle just dropped into place. ie: The Import was already there... and now is seems an export may not be too hard to produce!

Would be really great if FD would give input on this

Agreed... If only to give us an indication of if we're even just wasting our time and efforts discussing it, or if it's now on a list for example for some attention over the next year!?

 

[Alec Turner]

Hmm, ok, if the system has never been discovered before I understand that, but if 1 single person discovered the system already it makes little sense. If it ran the stellar forge for each and every system every time to generate the system would we then not get different systems on different PC's at the same location?

Nope, that's the beauty of procedural generation. Same "seed" + same algorithm produces the same system every time you run it.

Whatever it is, it needs some optimisation, basically I feel that if it has run once, the data is there and that should mean it does not need to run again.

Yup, you're right here. I guess it can't cache the systems you've visited permanently in case they want to tweak the algorithm in the future but I think it could certainly cache the results from your current session.

I should add that what I've described provides the essence of the undiscovered base galaxy. Obviously on top of that you've got the commander tags for first discovery (which must come from a "database" of some sort) as well as information about the current BGS state and information about the various ports in the system (some of which seem to be hand placed seeing as how they're constantly adding new stations). There must also be a smaller (well, compared to 400 billion) database of backer/player named systems and the like.

 

[NeilF]

Michael commented on the possibility of getting a download of Visited Systems from FD. While it's no suprise such a feature will not be in 2.2, at least the comment implies it might be on a list for the future.

There won't be a mechanism for this as part of the 2.2 release. We appreciate the desire for it, so it will be looked at in the future, but I have no time scale for that at the moment.

Hopefully, along side a "Discoverd By" filter and download

 

[Ralph Vargr]

I mean, yeah, great, but why would this data even exist? Why would the game have been tracking every system we visited to date?

If I'm wrong, cool, but I highly doubt its possibility.

I sold all my exploration data, and the transactions were recorded by Frontier.

- - - - - Additional Content Posted / Auto Merge - - - - -

I all about for stuff that do not need access the servers for improving performance on the client side. Hell, if we need to have 1GB of data in our hardrives to reduce server access and make the game perform better then "make it so".

Also known as Offline Mode.

 

[NW3]

I personally would use it so that I could filter my visited system out and get the route plotter to plot a course not using systems I had visited before = more exploration.

At least, that is my personal take away and hope from this function.

Exactly! To see where you've been and minimize visiting "seen" systems along a frequented route, perhaps to/from Jaques for example.

Unfortunately I doubt that will ever be the case. for Example:

Look at how the System map works currently: Open system map - wait for it to load - wait - wait - system map open. Close it and open it again - the whole load process starts anew.

That is the game actively requesting the system details from the database - everytime you open the map. The request isn't even commander specific. (and yes, the constant loading drives me nuts)

With Database queries, the more you filter the slower it gets on returning data (very, very generalised, I know).

A Query like "Get systeminfo for sol" returns data faster than a query like "get systemname where visitor=cmdrname" especially if the table or source queried has to filter through rows and rows of data with the same system name coupled with different commander names.

Kinda like this

System Visited by Visited on

Sol CMDR A xxx.xxx.xxx
Sol CMDR B xxx.xxx.xxx
Sol CMDR C xxx.xxx.xxx
Sol CMDR D xxx.xxx.xxx
Sol CMDR A xxx.xxx.xxx
Sol CMDR A xxx.xxx.xxx
Sol CMDR B xxx.xxx.xxx
Sol CMDR X xxx.xxx.xxx

The query would go through each row and check "are you sol?" = yes ok then "are you CMDR x?" = no at which point it would hop to the next line and repeat the process.

This is assuming that FD have a database record of every single system a commander has visited (system name, Commander name) and not just a system database with an added first discovery field where the commanders name is entered into upon selling the exploration data.

I'm really sorry that I can't explain it properly, but knowing databases like I do, this does sound like a bit of a nightmare and could very well lead to performance issues. Yes, the data returned is minimal in size, getting that filtered data is a whole different story. Also imagine if 10000 clients send that request to the Database server at the same/simmilar times, you can literally bring the server to a standstill that way (I've seen it happen with bad queries before)

If they do have a Database tracking each and every system each and every commander has visited it must be huge by now which makes the whole process even worse.

That said, if they give me the Database (or a small export of it) I would not mind looking into doing an export for commanders that want the data. I just kinda doubt they would want to pass out that data.

They might, especially if we were willing to pay for it. I was envisioning a weekly run once through all visited stars, planets, and moons, appending info to each CMDR in a relatively short list (although it wouldn't be that hard to handle everyone or everyone who's been active in the last week). Heck, if they'd just publish the list of who found what, I'm sure the community would take it from there. Still, my preference would be to somehow get the data into the galactic map.

 

[Ralph Vargr]

According to FD's stats on my stats panel (yesterday), I've visited 7676 unique systems, and made 13,740 jumps.

EDSM says I've seen 11,073

And been first to 2,547 systems.

That's only since I turned VerboseLogging on, in April 2015.

Both EDD and CL agree that I've made about 11,000 jumps since April 2015.