Why is there no Star Type filter?

veryDead

veryDead
We have all the star class and type information already included for every star in the galaxy map. We should be able to filter by star type, not just star class.

I want to do a systematic star type analysis, and only want to visit specific star types. I only want to see one type at a time... For example I want to filter for Class A, Type 5 VB, and ONLY see those stars on the galaxy map so that I can quickly compile a list of A5 VB stars to visit.

This is a basic feature that should be there. Why isn't it?

Or am I just missing something obvious as usual?
 

Allitnil

Allitnil
veryDead said:
We have all the star class and type information already included for every star in the galaxy map. We should be able to filter by star type, not just star class.

I want to do a systematic star type analysis, and only want to visit specific star types. I only want to see one type at a time... For example I want to filter for Class A, Type 5 VB, and ONLY see those stars on the galaxy map so that I can quickly compile a list of A5 VB stars to visit.

This is a basic feature that should be there. Why isn't it?

Or am I just missing something obvious as usual?
Click to expand...
Well, it's not really a "basic feature" is it? It's something that only explorers would ever be interested in (which automatically places it way down the priority list) and even then it's at the niche end of the spectrum. It's also pretty much useless as a filter for route plotting since even with fairly high jump ranges it would only work in the very densest of regions.

All in all, it is a "nice to have" option that would suit some of us some of the time. If available, I would certainly use it. But not very often. And I strongly suspect that I would use it far more often than most.

From a purely practical POV, how do you envisage the UI working to allow such a specific filter without it being overly complicated for the average CMDR? Try and devise a workable UI for it, that's generally a good test for whether an option is worth including or not.
 

veryDead

veryDead
Allitnil said:
Well, it's not really a "basic feature" is it?
Click to expand...
It is a very basic feature. Any consumer database software currently in use in 2019 has this capability by default. Same for all spreadsheet software. I find it hard to believe that a galactic database 1000 years in the future would not have the ability to search/filter each field/record in its database. Even if we just go by 2019 database standards, it should absolutely be searchable across all fields. If it's in the database, it should be something I can filter for/against.

Allitnil said:
It's something that only explorers would ever be interested in (which automatically places it way down the priority list) and even then it's at the niche end of the spectrum. It's also pretty much useless as a filter for route plotting since even with fairly high jump ranges it would only work in the very densest of regions.
Click to expand...

Anybody interested in learning about how things work in the Elite galaxy, becoming more efficient/skilled at playing would benefit from the ability to drill down into the galaxy map. Mining, Engineering, Exploration, Thargoids, all of these scenarios would benefit from extended galaxy map filtering based on data that is already available but not searchable.


Allitnil said:
All in all, it is a "nice to have" option that would suit some of us some of the time. If available, I would certainly use it. But not very often. And I strongly suspect that I would use it far more often than most.
Click to expand...

This is not only a "nice to have" option. It is the most basic feature of a database. Really the purpose of a database. The Galaxy map is just a graphical interface to a database of stars and planets. Being able to filter the fields means easier access to masses of data so that you can make sense of it, use it, manipulate it, change your work habits based on what you find, give you a deeper understanding of what is going on.


Allitnil said:
From a purely practical POV, how do you envisage the UI working to allow such a specific filter without it being overly complicated for the average CMDR? Try and devise a workable UI for it, that's generally a good test for whether an option is worth including or not.
Click to expand...

This is so easy. The same Star Class filter. Then below it, a Type filter box that modifies the Class filter. So in class, you tick the A Star box to limit the view to Class A stars. Then in the Type filter box you check which subtypes to filter for or uncheck all to show all.

It's no more complicated than the current filter system. It uses the same input method of checkboxes. It just adds a Type box below the Class box.
 

Ian Doncaster

Ian Doncaster
veryDead said:
It is a very basic feature. Any consumer database software currently in use in 2019 has this capability by default. Same for all spreadsheet software. I find it hard to believe that a galactic database 1000 years in the future would not have the ability to search/filter each field/record in its database. Even if we just go by 2019 database standards, it should absolutely be searchable across all fields. If it's in the database, it should be something I can filter for/against.
Click to expand...
There are some things to remember.

1) You can search any field in a consumer database. You can't *efficiently* search any field in a consumer database for arbitrary parameters. When there are 400 billion records, "efficient" is a major consideration. An inefficient query - and an arbitrary query the database hasn't been optimised for is usually inefficient - can run into slowdowns at tens of thousands of records.

2) The galaxy map as seen in game is not actually a database - it just simulates one. And that means that things which a "real" database could do might not be practical in the simulation. (Storing the stars as a real database would take tens of terabytes at least - probably up to petabytes depending on how much information you wanted to searchably store - so they can't just implement it as an actual local database, and there are good cost and performance reasons not to implement it as a server-side database either)

3) Consumer databases do not usually have an interface requirement that you must be able to set up queries with a joystick from VR. Yes, you could add a "type" filter below the class filter and it would probably be manageable. That approach will not scale to tens of searchable properties, however, especially if the majority of those properties are irrelevant to most people.

4) "SELECT systems.name FROM systems INNER JOIN system_contents WHERE system_contents.description LIKE '%raxxla%';". There may be good gameplay reasons not to allow us to carry out arbitrary searches on the galaxy database. Implementing a security model on top of it would require expensive cross-queries against other tables to determine which information is accessible to each commander.
 

Pirin

Pirin
Another reason is that the most interesting systems, like supergiants or O III stars for example, will be too easy to find and most of them will be tagged within a month. Not a good idea, IMO.
 

thundernuns

thundernuns
Yeah I think like previously mentioned, this isn't exactly a feature many people would use, and the Galaxy map's primary function is navigation not a database.
 

iain666

iain666
Ian Doncaster said:
(Storing the stars as a real database would take tens of terabytes at least - probably up to petabytes depending on how much information you wanted to searchably store - so they can't just implement it as an actual local database, and there are good cost and performance reasons not to implement it as a server-side database either)
Click to expand...

The local copy of EDSM data that ED Discovery stores in a sqlite database is up to about 7.4GB for everything now - that that's still only ~0.0078% of the galaxy with just system names, coordinates and some ids stored.
 

Jackie Silver

Jackie Silver
We know that the galaxy map display already pulls sufficient information to display the colour and type (at least to within giant/not-giant/remnant) of stars, so a filter on the display which only draws stars matching certain parameters should not require any significant additional overhead.

The answer to the question, though, is "because the people who make the game don't, by and large, care for such things any more."
 

veryDead

veryDead
Everyone’s replies are appreciated. I’m unconvinced by the counter arguments but I appreciate your thoughts on the matter.

I feel taunted by information that is shown to me but is essentially useless. It may as well not be there. I am convinced the game would be much more immersive and satisfying if this information was actually useful in exploration.

Ultimately, I am still a huge fan of Elite Dangerous, and I will continue to explore and simultaneously lament the primitive state of the future’s database technology.
 

Rooster Podunk

Rooster Podunk
veryDead said:
Everyone’s replies are appreciated. I’m unconvinced by the counter arguments but I appreciate your thoughts on the matter.

I feel taunted by information that is shown to me but is essentially useless. It may as well not be there. I am convinced the game would be much more immersive and satisfying if this information was actually useful in exploration.

Ultimately, I am still a huge fan of Elite Dangerous, and I will continue to explore and simultaneously lament the primitive state of the future’s database technology.
Click to expand...

I'd welcome such a feature. This all started with me when I stumbled across two very odd systems around feeble G9 stars and would love to see more but the needle in a haystack search is maddening. The info is right there in the database. I see no reason there is no search feature for narrowing star type from class.
 

Deleted member 38366

D
How about this :

- the ability to combine Filters

Just with two, you already could
- show me all Class A Stars I've already visited
- plot a course through all Class F Stars I haven't visited
- show me all inhabited Systems with a White Dwarf
- plot through Systems that contain both a Class A and a Class B star

Other than that, I'd sure like the Star Filter to be far more detailed indeed. Just Proto Stars includes a whole bunch, would like to filter for Herbig but ignore Tauri Proto ones for example.
Ideally, I'd like to filter in the same granular level as the Codex offers.

From the Codex, I'd love to filter from my personal Exploration Database for queries.
- Codex, show me the nearest 10 discovered Water Giants, Filtered for G Class Stars
- Codex, show me the list of discovered Metal-Rich Planets, Filtered for Surface Temperature between 600K and 900K and existence of Silicate Magma
- Codex, show me an overview of all Stellar Phenomena I've scanned within {n}LY of {System or Present Position}
 
Last edited by a moderator:

Spaceman Si

Spaceman Si
Ian Doncaster said:
4) "SELECT systems.name FROM systems INNER JOIN system_contents WHERE system_contents.description LIKE '%raxxla%';". There may be good gameplay reasons not to allow us to carry out arbitrary searches on the galaxy database. Implementing a security model on top of it would require expensive cross-queries against other tables to determine which information is accessible to each commander.
Click to expand...

A full table-scan of 400 billion records, nice :) ;) Add in multiple users trying to execute concurrent queries, and it's easy to see why this isn't possible / allowed. Using a key-value pair database and only allowing lookup on the key for a specific value is really the only way out, unless they want to implement an Enterprise db like Oracle to do the job, which might "cost a bit" ;)

I would actually use the OPs suggestion, but more for the purposes that FalconFly detailed, i.e looking for systems with multiple stars of different spectra. The fact that the different luminosity classes of each spectral type actually look different is a marvellous thing, which I enjoy immensely; this must have been something that was built in during the early days of design when the Stellar Forge was developed.

I should also like to have waypoints for route plotting, but I suspect that isn't going to happen either.

Sadly, I think Jackie is right - adding features for exploration doesn't seem to be high on the agenda.
 

Rooster Podunk

Rooster Podunk
Spaceman Si said:
A full table-scan of 400 billion records, nice :) ;) Add in multiple users trying to execute concurrent queries, and it's easy to see why this isn't possible / allowed. Using a key-value pair database and only allowing lookup on the key for a specific value is really the only way out, unless they want to implement an Enterprise db like Oracle to do the job, which might "cost a bit" ;)

I would actually use the OPs suggestion, but more for the purposes that FalconFly detailed, i.e looking for systems with multiple stars of different spectra. The fact that the different luminosity classes of each spectral type actually look different is a marvellous thing, which I enjoy immensely; this must have been something that was built in during the early days of design when the Stellar Forge was developed.

I should also like to have waypoints for route plotting, but I suspect that isn't going to happen either.

Sadly, I think Jackie is right - adding features for exploration doesn't seem to be high on the agenda.
Click to expand...

Waypoints! Now that is something to make this old man smile.
 

Ian Doncaster

Ian Doncaster
Amargosa said:
I want a filter which can show stars by partial name, like "*Aqua*" or "HIP*".
Click to expand...
This is probably efficiency again.

A "start of string" search is very easy and can be very fast when done on an indexed field. There's also - because of how procedural star names are constructed - some nice optimisations possible for those: once you've checked that no sector names match, you don't need to search the stars list at all - conversely, if a sector name does match, the scope of the rest of the query is significantly smaller.

Free text searches are considerably slower - especially once the procedural stars are taken into account: a free text search for "LW-L" would return a *lot* of stars from all over the galaxy, for example.

Free text, but only over the non-procedural names ... it's a small enough dataset that it would probably be acceptably fast, but then Frontier would have people asking why a search for "Aqua" worked but a search for "LW-L" didn't.
 
You must log in or register to reply here.
Back
Top Bottom