Glorious HIPs - 3306

A new spreadsheet .... here.

So, following up on the work done by Cmdr OrangeOrange, I have examined the original HIP catalogues and found that the parallax values in the OP sheet were taken from an old catalogue.

I have now pasted the corrected parallax values into a copy of the original ss, and this has made a huge difference.
This new spreadsheet has finally got all the estimated coordinates from the catalogue data, which, by and large, match the ED coordinates to within a few percentage points.

Because the parallax is still only to 2dp, there is a larger discepancy in the stars furthest away from Sol, but they are still usable numbers.
I have added a couple of new columns :
1) showing the slice numbers where these were used. These only appear beyond about row 90,000
2) An offset value showing by how many LYs the known ED coordinates differ from those calculated from the catalogue data.

Now that we have good estimates of the positions of alll HIP stars I am thinking of using this data to calculate optimum routes to the outstanding HIP stars. Watch this space.

Also interesting is the correlation between very small parallax values and "not found" or unreachable stars. It can be seen that when FD imported the HIP catalogue many stars did not fit into the defined size limits of the galaxy. So it is now not too difficult to predict which stars are either not found or unreachable.

Some more news ...
There is currently an error in the new spreadsheet. The formula used for the apxED Z coordinate is referencing the wrong cell, and so is unreliable.

I am goimg to correct this of course, but I am also going to change the SS layout so that the unexplored stars in each slice come first.
This should make it easier to extract the stars which need to be visited.

Secondly, because there is now a more accurate calculation of the distance from sol, I have identified most, if not all, of the stars in the bubble which have not yet matched.
The majority (250) of them are named stars, and some not found stars. I will add these to my lists and re-run the merge program.

I will then be able to redo the layout of the new spreadsheet. This should be completed by the end of today (in BST).
 
Roger that; filter shows only 137 not in EDSM but I'll visit 'em all anyway...

Just going to blow another 500m credits refulling the FC and I'll be off...

@Jackie Silver
Slice currently allocated to you - let me know if you'd prefer to complete yourself?

Just for reference here, I am currently working through an issue with EDSM stars with Orvidius, there are a large number of systems in EDSM database that don't actually have any data recorded for them. Orvidius has kindly produced a list that has some millions of entries, maybe 20m plus in fact, so even though the star may be in EDSM database, there may still be no recorded information about them.


It's looks like the HD entries alone comes to just over 3,000 stars with no recorded main star and probably zero data!

For instance this one;


Got a first visit but no bodies or stars. That probably applies to many HIP stars also.
 
Just for reference here, I am currently working through an issue with EDSM stars with Orvidius, there are a large number of systems in EDSM database that don't actually have any data recorded for them. Orvidius has kindly produced a list that has some millions of entries, maybe 20m plus in fact, so even though the star may be in EDSM database, there may still be no recorded information about them.


It's looks like the HD entries alone comes to just over 3,000 stars with no recorded main star and probably zero data!

For instance this one;


Got a first visit but no bodies or stars. That probably applies to many HIP stars also.
Thanks Cmdr; I'll visit all reachable inSlice 17 so that should populate EDSM with full data
 
Just for reference here, I am currently working through an issue with EDSM stars with Orvidius, there are a large number of systems in EDSM database that don't actually have any data recorded for them. Orvidius has kindly produced a list that has some millions of entries, maybe 20m plus in fact, so even though the star may be in EDSM database, there may still be no recorded information about them.


It's looks like the HD entries alone comes to just over 3,000 stars with no recorded main star and probably zero data!

For instance this one;


Got a first visit but no bodies or stars. That probably applies to many HIP stars also.


As you may remember, I mostly use the Spansh db for the merge, because the Spansh holds quite a few more records than EDSM.
Though I just discovered that there may be duplicates in there (not yet proved).

However , there are many records with zero body counts, ie no star data or bodies/ Just star names and coordinates.
And these are still being added currently. It is not an issue of past records or just using the ADS.
eg "Phaa Chroa AA-A h12","coords":{"x":6051.8125,"y":249.59375,"z":33522.28125},"date":"2021-07-31 18:38:36+00","bodies":[]

I would also be interested to know how this happens.
Most of them are now far across the galaxy.
Perhaps Fleet Carriers jumping through systems without scanning ?
 
As you may remember, I mostly use the Spansh db for the merge, because the Spansh holds quite a few more records than EDSM.
Though I just discovered that there may be duplicates in there (not yet proved).

However , there are many records with zero body counts, ie no star data or bodies/ Just star names and coordinates.
And these are still being added currently. It is not an issue of past records or just using the ADS.
eg "Phaa Chroa AA-A h12","coords":{"x":6051.8125,"y":249.59375,"z":33522.28125},"date":"2021-07-31 18:38:36+00","bodies":[]

I would also be interested to know how this happens.
Most of them are now far across the galaxy.
Perhaps Fleet Carriers jumping through systems without scanning ?
Just came across this data in the latest Spansh db, consective rows with zero bodies :
The last two data columns are distance from the previous row, and the time difference.

"name":"Phaa Chroa AA-A h7" ,{"x":5543.9375 ,"y":716.6875, "z":34476.09375},"date":"2021-07-31 04:50:36+00","bodies":[],
"name":"Phaa Chroa AA-A h10" ,{"x":5157.96875,"y":1216.03125,"z":34339.90625},"date":"2021-07-31 05:03:24+00","bodies":[], 645 ly 13 minutes
"name":"Phaa Chroa AA-A h8" ,{"x":6014.4375 ,"y":467.5, "z":34163.4375}, "date":"2021-07-31 18:18:20+00","bodies":[], 1150ly 13 hours
"name":"Phaa Chroa AA-A h12",{"x":6051.8125 ,"y":249.59375, "z":33522.28125},"date":"2021-07-31 18:38:36+00","bodies":[], 678 ly 20 minutes
"name":"Phaa Chroa AA-A h11",{"x":5933.96875,"y":836.96875, "z":33718.5625}, "date":"2021-07-31 19:02:00+00","bodies":[], 630 ly 24 minutes
"name":"Phaa Chroa AA-A h10",{"x":5920.34375,"y":1243.90625,"z":33840.25}, "date":"2021-07-31 19:13:58+00","bodies":[], 425 ly 12 minutes

If I didn't know that it takes 15 minutes to do a 500 max ly jump, I would say these are FC jumps.
These stars are also in EDSM with zero body data. Courtesy of Cmdr Arcminute

edit: According to the Inara records, Cmdr Arcminute does not own a Fleet Carrier !
 
Last edited:
I have now corrected the error in the . new spreadsheet. Although it has not yet been merged with the latest lists of named and not found stars.

Also created a spreadsheet for unexplored stars by slice, Which helps identify oustanding HIP stars. (In theory)

The unexplored stars spreadsheet shows there are 221 stars to be visited iin slice 17.
 
Last edited:
I would also be interested to know how this happens.
Most of them are now far across the galaxy.
Perhaps Fleet Carriers jumping through systems without scanning ?

A lot of them are "old data" from before the FSS and you had to target the main star or it didn't get tagged, so CMDRS in a hurry just honking the system but not targetting the main star, these have "first visited by" tags but no data. Another issue we have come across is that some systems have star and body data in Orvidius's download but don't actually have any in the current EDSM database so it looks like at some stage the data has been purged from EDSM for some reason.

It's annoying to say the least!

Yes Fleet Carriers maybe, but unless there's a CMDR on board they shouldn't get reported at all? I expect they are only a tiny proportion of the cases anyway. My own carrier jumps without me being on board a lot, but if I am I get out to scan the local system before jumping to the next one!
 
Just tested, a Fleet Carrier with no CMDR on board won't report anything to EDSM, that's exactly what I expected but best to check anyway. I will be back at my FC later today and will do a jump and without leaving the FC I will check to see what data is reported to EDSM.
 
Last edited:
Ok done, a FC with a CMDR on board will report the stars and a first visited tag to EDSM, so FC's can't be the source of systems with no data, they should at least have the star data and first visited tag.
 
Huh, still being added with no bodies? The only thing I can think of is if commanders are jumping in at a point far enough from the star that the auto-scan doesn't happen (but does that actually happen?), not even bothering to do a honk, and then moving on. I suppose this could also happen if they came in on a carrier, and the carrier appeared too far from the star for the passive/auto scan to tag the star. That's actually more likely than them jumping in with their own ship. I've seen the carrier occasionally jump in several hundred light seconds away from the actual entry point. That's all I can really think of for new cases of this.
 
Huh, still being added with no bodies? The only thing I can think of is if commanders are jumping in at a point far enough from the star that the auto-scan doesn't happen (but does that actually happen?), not even bothering to do a honk, and then moving on. I suppose this could also happen if they came in on a carrier, and the carrier appeared too far from the star for the passive/auto scan to tag the star. That's actually more likely than them jumping in with their own ship. I've seen the carrier occasionally jump in several hundred light seconds away from the actual entry point. That's all I can really think of for new cases of this.

The systems reference by Iron Body as being found by Arcminute do actually have body data in EDSM so there's something strange going on with that search I think here is the star for one of them registered to Arcminute;


I suspect it's because there are ONLY stars in those systems and the search is falling over there!
 
Huh, still being added with no bodies? The only thing I can think of is if commanders are jumping in at a point far enough from the star that the auto-scan doesn't happen (but does that actually happen?), not even bothering to do a honk, and then moving on. I suppose this could also happen if they came in on a carrier, and the carrier appeared too far from the star for the passive/auto scan to tag the star. That's actually more likely than them jumping in with their own ship. I've seen the carrier occasionally jump in several hundred light seconds away from the actual entry point. That's all I can really think of for new cases of this.
I've never seen a hyperjump land me more than single-digit ls from the main star, so short of manually turning off sensors I don't know how you'd avoid scanning the star. I wonder if there are any niche EDDN clients that send jump reports but not scan data?

A carrier can arrive out of scan range of any body. The main reason seems to be when there's a wide asteroid belt that extends too close to the star for the FC to fit in between, so the FC is placed beyond the outer belt radius.
 
The systems reference by Iron Body as being found by Arcminute do actually have body data in EDSM so there's something strange going on with that search I think here is the star for one of them registered to Arcminute;


I suspect it's because there are ONLY stars in those systems and the search is falling over there!

Don't forget that the list of referenced stars came from a Spansh update file, not edsm.
 
Huh, still being added with no bodies? The only thing I can think of is if commanders are jumping in at a point far enough from the star that the auto-scan doesn't happen (but does that actually happen?), not even bothering to do a honk, and then moving on. I suppose this could also happen if they came in on a carrier, and the carrier appeared too far from the star for the passive/auto scan to tag the star. That's actually more likely than them jumping in with their own ship. I've seen the carrier occasionally jump in several hundred light seconds away from the actual entry point. That's all I can really think of for new cases of this.

There was an issue back when FCs launched when ocasionally the carrier was placed extremely far away from the main star when jumping in. Like 300-600kls far. It had something to do with the game miscalculating orbits or lagrange points in multiple star systems and was eventually fixed, but it still persisted for a good few months.
 
Huh, still being added with no bodies? The only thing I can think of is if commanders are jumping in at a point far enough from the star that the auto-scan doesn't happen (but does that actually happen?),
I have on several occasions carrier jumped into a system got out to scan and when activating the scan it has had 0% detected before honking, so no main star auto-detected by either carrier or ship.
 
I wonder if there are any niche EDDN clients that send jump reports but not scan data?

That might be possible. If the commander wanted to save scan data for later, after selling their in-game data. But you would think they'd hold back everything, and not have the jump reports passed to EDDN either. Hmm. I wonder if any of the commonly used clients will do that.
 
Don't forget that the list of referenced stars came from a Spansh update file, not edsm.

True that.
That might be possible. If the commander wanted to save scan data for later, after selling their in-game data. But you would think they'd hold back everything, and not have the jump reports passed to EDDN either. Hmm. I wonder if any of the commonly used clients will do that.

It's interesting that EDSM is getting the body data but not Spansh since Iron Body is reporting that Spansh has no body data but when I check EDSM does. I thought that all clients were updated from EDDN so they should be the same, unless the data is changed after the fact.
 
Back
Top Bottom