Release Neutron Highway long range route planner

Spansh

S
athulin said:
Here's an observation and some questions.

I visit Pueliae MJ-H d10-1 (https://www.spansh.co.uk/system/48628829915), and from direct observation (FSS) I learn that AB 1a has 1 bio and 3 geo signals, and that there are no other bio signals in the system..

When I check that with Spansh, I see that the data updates almost immediately, and the relevant page gets a 'updated X minutes ago'.

But I also find that the AB 1b entry (https://www.spansh.co.uk/body/288230424780541659) says '5 bio signals', which is not matched by the game information. This data also appears to be several years old.

I've seen this before, but I've never been entirely certain of the details that involve my own actions. But it seems like old information that has been changed (i.e. game info is no longer the same as the data stored in the database) doesn't get updated. Some seems to change: the AB 1a entry is said to have been updated shortly after my FSS, but the AB 1b does not appear to have changed.

Question: Is this actual and permanent behaviour or is it just something that happens close to new info being provided. (I'm thinking: some info may be easy/cheap to update and is updated on the fly, while other is more expensive, and isn't changed until a later batch run.)

Question: Is this easily fixable? (I suppose it may be technically fixable, but old content would probably remain affected by it, so I suppose the answer is 'yes/no but ...'.)

Question: If this is already known, how great deal of data is affected? I suppose I'm asking if there are any known error rates. That is, if I tried to count the number of known Electricae Radielem is some part of the galaxy, any result would need to be stated as 'X bodies ± Y bodies', where Y is the estmated number of changes that didn't lead to a database modification.
Click to expand...
The main issue is that Frontier doesn't provide a way of scanning a body and generating a "zero signals" entry in the journal. Which means once a signal is attached to a body we have no way of removing it if that body changes to not have signals in the future.

You can as an alternative filter on signals_updated_at in the search and make sure the signals only come from the last few months, that should filter out any old data which we can't easily fix.
 

athulin

A
Spansh said:
The main issue is that Frontier doesn't provide a way of scanning a body and generating a "zero signals" entry in the journal. Which means once a signal is attached to a body we have no way of removing it if that body changes to not have signals in the future.
Click to expand...

I didn't think of that. It seems though that presence of a SAASignalsComplete for a body (which implies a DSS scan), but absense of a SAASignalsFound for the same body would be equivalent. However. that means that a multiple log entries needs to be examined, and it may not be possible to detect a missing SAASignalsFound until ... perhaps the next SAASignals record or Jump record appears. OK, I can see that needs more effort.
 

Halieutics

H
Someone has probably already suggested it, but would it be possible to add an end destination for the trade route planner?

With the new PP2.0 update I find myself trying to stay inside the bubble but keep on getting sent on quest's outside of it.
 

Spansh

S
Halieutics said:
Someone has probably already suggested it, but would it be possible to add an end destination for the trade route planner?

With the new PP2.0 update I find myself trying to stay inside the bubble but keep on getting sent on quest's outside of it.
Click to expand...
it's kind of on the list of things I've been developing on and off, got a bit disheartened though because after spending ages developing something I realised I was being completely boneheaded and it wasn't going to be as good as I thought it was.

I will probably revisit at some point but don't expect it soon.
 

Mastadon623

Mastadon623
I've noticed that ever since Powerplay 2 released neither Controlling Faction nor the Faction Presence filters in the System search page.
 

Spansh

S
Mastadon623 said:
I've noticed that ever since Powerplay 2 released neither Controlling Faction nor the Faction Presence filters in the System search page.
Click to expand...
That was an issue with my new fixes to the frontend, those should now work.
I have made a lot of changes this week to the frontend of the site to simplify how it works behind the scenes and show more fields to search. This should make any changes going forward substantially simpler. However these changes are quite large and whilst I have tested as thoroughly as I can, it's possible I missed some things. Please let me know if you find any issues.
hugh mungusss said:
hello

on the exobio page, what does the "count" column mean?
Click to expand...
The number of sites which have been record via the Canonn EDMC plugin (which is where I source my exobiology data).
 

Vinman

Vinman
Is anyone else having issues with Bodies Search and downloading CSV files? After performing a search, I can see the "Download as CSV" button, but nothing happens when I click it.

I’ve tried different browsers, as well as different computers at various locations, but still, nothing happens when I attempt to download the CSV files.
 

Spansh

S
Vinman said:
Is anyone else having issues with Bodies Search and downloading CSV files? After performing a search, I can see the "Download as CSV" button, but nothing happens when I click it.

I’ve tried different browsers, as well as different computers at various locations, but still, nothing happens when I attempt to download the CSV files.
Click to expand...
I'd introduced a bug when I upgraded some of the frontend. This should now be resolved. Thanks for letting me know.
 

DjVortex

DjVortex
This might have already been discussed (I haven't read all the 61 pages of discussion...), so I apologize if there is an answer to this already somewhere. Anyway...

The "galaxy plotter" seems to be designed so that when you need to refuel, it tries to find a system that has both a neutron star and a scoopable star. At first this sounds like a great idea: You don't need to spend time jumping to a system with a scoopable star when you have one right there! Continuous uninterrupted neutron boosting, with conveniently placed scoopable stars along the way.

However, I later realized that while this might minimize the number of jumps, it doesn't actually minimize the overall traveling time. In fact, it probably makes it only longer.

The problem with scooping from a secondary star in the same system as a neutron star is that the time you spend supercruising within the system to get to the other star is time you aren't spending traveling towards your destination. If you could make a maximal jump to a fuel star, and from there a maximal jump to a neutron star, that not only would probably be a bit faster, but in fact significantly contributes to your advancement towards your goal.

Let's say you have a ship with an 80 Ly jump range, and let's assume for simplicity the plotter finds optimal jumps for it.

Currently you would typically make a 320 Ly jump from a neutron to a neutron+scoopable, and then from there a 320 Ly to the next neutron.

However, more optimal would be if you could make a 320 Ly jump from a neutron to a scoopable, then an 80 Ly jump to a neutron, and then a 320 Ly to the next neutron.

In that first case you would have traveled 640 Ly, while in the second case you would have traveled 720 Ly, in the same time if not even a bit faster. That's quite significant! Every fuel stop would actually advance you towards your final destination by up to your ship's jump range. And since you don't need to do any in-system traveling, it's likely to be even faster.

Does the galaxy plotter already support this kind of plotting strategy? If not, I think it would be a good idea to try to implement it.
 

hugh mungusss

H
DjVortex said:
Does the galaxy plotter already support this kind of plotting strategy? If not, I think it would be a good idea to try to implement it.
Click to expand...
I think what you're looking for is "exclude secondary stars" checkbox
 

Attachments

  • Screenshot_20241115_180037_Chrome.jpg
    Screenshot_20241115_180037_Chrome.jpg
    103 KB · Views: 5

Spansh

S
DjVortex said:
This might have already been discussed (I haven't read all the 61 pages of discussion...), so I apologize if there is an answer to this already somewhere. Anyway...

The "galaxy plotter" seems to be designed so that when you need to refuel, it tries to find a system that has both a neutron star and a scoopable star. At first this sounds like a great idea: You don't need to spend time jumping to a system with a scoopable star when you have one right there! Continuous uninterrupted neutron boosting, with conveniently placed scoopable stars along the way.

However, I later realized that while this might minimize the number of jumps, it doesn't actually minimize the overall traveling time. In fact, it probably makes it only longer.

The problem with scooping from a secondary star in the same system as a neutron star is that the time you spend supercruising within the system to get to the other star is time you aren't spending traveling towards your destination. If you could make a maximal jump to a fuel star, and from there a maximal jump to a neutron star, that not only would probably be a bit faster, but in fact significantly contributes to your advancement towards your goal.

Let's say you have a ship with an 80 Ly jump range, and let's assume for simplicity the plotter finds optimal jumps for it.

Currently you would typically make a 320 Ly jump from a neutron to a neutron+scoopable, and then from there a 320 Ly to the next neutron.

However, more optimal would be if you could make a 320 Ly jump from a neutron to a scoopable, then an 80 Ly jump to a neutron, and then a 320 Ly to the next neutron.

In that first case you would have traveled 640 Ly, while in the second case you would have traveled 720 Ly, in the same time if not even a bit faster. That's quite significant! Every fuel stop would actually advance you towards your final destination by up to your ship's jump range. And since you don't need to do any in-system traveling, it's likely to be even faster.

Does the galaxy plotter already support this kind of plotting strategy? If not, I think it would be a good idea to try to implement it.
Click to expand...
We did explicitly test and in the tests we made so long as the secondary star was within 100-200ls or so then it was quicker to refuel in the system. The system has been designed to only include secondary stars which are within 100ls. However as has been noticed, if you don't agree you can exclude secondary stars with the option mentioned above.
 

hugh mungusss

H
Spansh said:
We did explicitly test and in the tests we made so long as the secondary star was within 100-200ls or so then it was quicker to refuel in the system. The system has been designed to only include secondary stars which are within 100ls. However as has been noticed, if you don't agree you can exclude secondary stars with the option mentioned above.
Click to expand...
It would be prudent to either make note of this or make an existing note more visible because the mention of secondaries in general just envisioned 100kls+ trips to secondary stars and I almost instinctively turned on the exclude secondaries. Limiting them to within 100ls indeed seems faster than a whole new system to jump to, esp with the current 1+ minute witchspace transit times
 
You must log in or register to reply here.
Back
Top Bottom