They do but are largely undocumented, the whole website uses them to work, so you can just watch in developer tools network tab as you use the site to see how they work (they should be fairly self explanatory). I do make a concerted effort not to change how they work for people who have tried to integrate with them
Found an error in the Fleet Carrier Route Plotter. @Spansh
Origin System: Dryio Flyuae NZ-N c7-70
Destination System: Boeph ZF-E d12-269
This jump is definitely not 499Ly.
This is a distance of 1998.77Ly
Wanting to let you know so you can take a look into this to see why this error may be occurring.
In-game screenshot included to verify correct systems for your reference.
Had to manually replot part of my route due to the error, not a big deal to me at this time, something to look into for future explorers.
Origin System: Dryio Flyuae NZ-N c7-70
Destination System: Boeph ZF-E d12-269
This jump is definitely not 499Ly.
This is a distance of 1998.77Ly
Wanting to let you know so you can take a look into this to see why this error may be occurring.
In-game screenshot included to verify correct systems for your reference.
Had to manually replot part of my route due to the error, not a big deal to me at this time, something to look into for future explorers.
Last edited:
Wow, that's something I've not seen myself. Turns out the coords for Boeph ZF-E d12-269 are wrong. I guess the OP will have an idea of how/why this can occur.
Essentially something submitted wrong coordinates to EDDN. I've had a brief look and I can't track down precisely what it was (or when). However a while ago I made some changes to reduce the number of times this happens. Anyways I've run some more recent EDDN data through this system and it's been updated correctly.
I went through the history, it was this specific message which set the coordinates wrongly.
JSON:
{"$schemaRef": "https://eddn.edcd.io/schemas/journal/1", "header": {"gatewayTimestamp": "2022-04-20T03:38:08.565148Z", "softwareName": "EDSM", "softwareVersion": "1.0.3", "uploaderID": "c8ed5596cecd285c382c3f769a02a16a35ac3f8f"}, "message": {"AbsoluteMagnitude": 3.770874, "Age_MY": 3142, "AxialTilt": 0, "BodyID": 1, "BodyName": "Boeph ZF-E d12-269 A", "DistanceFromArrivalLS": 0, "Eccentricity": 0.054133, "Luminosity": "VI", "OrbitalInclination": 25.85936, "OrbitalPeriod": 1467471599.578857, "Parents": [{"Null": 0}], "Periapsis": 163.492633, "Radius": 791903808, "RotationPeriod": 142204.455771, "ScanType": "AutoScan", "SemiMajorAxis": 749161571264.267, "StarPos": [-8672.46875, -828.5, 18005.21875], "StarSystem": "Boeph ZF-E d12-269", "StarType": "F", "StellarMass": 1.410156, "Subclass": 3, "SurfaceTemperature": 6910, "SystemAddress": 9251552333803, "WasDiscovered": true, "WasMapped": false, "event": "Scan", "timestamp": "2021-05-27T21:43:27Z"}}One of the changes I made a while ago was never to completely trust the coordinates of Scan. and Docked messages if I have other options. Anyway, this particular system has now been fixed.
Last edited:
Ahhh OK. Sounds like this is essentially down to a bug in the game then.
More a byproduct of how EDDN works to be honest
Hey @Spansh .. bit off topic but I've been using your body search page to try and find other moons similar to the "ice mordor" world and it seems like maybe the Earth Masses search slider isn't working correctly as any criteria I include seems to result in zero matches. Any chance there's a scaling error on that search option?
Got an example search URL I can look at?
Edit: The reason is that decimal places wasn't enabled on that particular field. If a field isn't showing with decimal places then it will truncate/round the values when you submit (so they were being sent as 0 in this case). I've put 2 decimal places on earth masses, solar radius and solar masses.
Last edited:
Ohh. In that case my ignorance runs deeper than I realised, because I had been assuming that the incorrect coords must have been "born" within ED itself before any helper app picked them up and sent them to EDDN.
Basically whichever software sent that message patched in coordinates from the wrong system when parsing the journal. It used to be a lot more common of a problem, but the makers of EDMC, EDD, EDDI (and a few of the other smaller senders) have spent along time working out exactly how to determine which system they are in correctly (and detecting when they have detected it wrongly as well) such that it's mostly an issue now with some lesser developed senders.
Arguably though it's the receivers fault for trusting that information so completely, as I said, for a brand new system I have to trust the data, but for existing ones I only update it based on original data (from FSDJump, NavRoute etc as Gazelle said)
@Spansh - nice site, I use both the route planners all the time, can't thank you enough.
One thing I noticed though is that your Carrier-Jump fuel-usage calculation appears to be a little off. I know that they have tweaked it repeatedly since the release, so it may just have fallen out of date. It's also possible I haven't been using your page correctly, but it is pretty straight forward. And to be fair, none of the other tools I tried were even close. (Obviously using a WAY outdated calculation or values).
In any case, I tracked a couple of recent journeys and used some equation I found in one of these threads (was it this site?) to come up with the constants below. So far they appear to be spot on (1.75 round trips to Colonia).
Here is the equation (I may have taken liberties in renaming some of the vars):
T = Round(P + (((TU * TC) + CO) * D), 0)
Where your Constants are :
P = 5 : Primer (overhead just for making the jump(?))
TU = 0.000005 (5E-6) : Tritium per Cargo-Unit per LY
CO = 0.125 : Tritium for Carrier per LY (Carrier Overhead)
And your Variables are :
TC = Total Cargo (hold + services + depot) (26000 max)
D = Jump Distance
"Thank you" to the forgotten soldier who first posted that equation. If I could remember where I found it I would give proper credit. All I did was calculate the new constants.
Just thought I'd share, and thank you again.
One thing I noticed though is that your Carrier-Jump fuel-usage calculation appears to be a little off. I know that they have tweaked it repeatedly since the release, so it may just have fallen out of date. It's also possible I haven't been using your page correctly, but it is pretty straight forward. And to be fair, none of the other tools I tried were even close. (Obviously using a WAY outdated calculation or values).
In any case, I tracked a couple of recent journeys and used some equation I found in one of these threads (was it this site?) to come up with the constants below. So far they appear to be spot on (1.75 round trips to Colonia).
Here is the equation (I may have taken liberties in renaming some of the vars):
T = Round(P + (((TU * TC) + CO) * D), 0)
Where your Constants are :
P = 5 : Primer (overhead just for making the jump(?))
TU = 0.000005 (5E-6) : Tritium per Cargo-Unit per LY
CO = 0.125 : Tritium for Carrier per LY (Carrier Overhead)
And your Variables are :
TC = Total Cargo (hold + services + depot) (26000 max)
D = Jump Distance
"Thank you" to the forgotten soldier who first posted that equation. If I could remember where I found it I would give proper credit. All I did was calculate the new constants.
Just thought I'd share, and thank you again.
The terms in the equation can be rearrranged in many ways, but personally I think it's more intuitive to treat the carrier overhead as an effective mass overhead (of 25000 units).
Meanwhile, when I last checked Spansh's calculation it matched the game perfectly (this was back in March so it's not impossible that the game changed since then).
I've seen that Eq (or very similar one) used before too, but with very different numbers that always calculated very very high estimates, which made me think it was from an early rendition (when fuel usage was WAY higher). That is a much simpler form that doesn't appear to need to separate the Carrier from the Cargo - I'm intrigued. I will plug that into my spreadsheet to see how it stacks up. Thank you very much for that.
And I guess I should have clarified that the predicted consumption would only differ from the actual-fuel-used after 10 or 15 jumps or so. It was only off by 1 or 2 on occasion to start, with the error gradually getting bigger and more frequent.
Cheers.
Well, I'm baffled by that. When I was testing it against the game, it was to verify if the game was using round() or ceil(), which meant that I was looking for precision - an exact match between the equation and the galmap fuel figure.
Given also that the game only ever seems to deduct an integer quantity of tritium (or at least it did behave that way), I am unable to understand how an error could build up.
I am a little baffled as well. I just went to document the error I was seeing, by plotting my current route again using FCR, but instead of the original problem, the calculated fuel is now off by 7~10 per jump, right off the bat. But don't take my word for it, plot the route and see.
Origin: Spoihaae YP-V d3-628
Destination : Sol
Hold : 5601 (1050 Services, 4092 Tritium, and 458 Misc items)
Depot : 916
Spoiler - Actual Fuel used for first 10 jumps was: 84, 84, 83, 83, 83, 83, 82, 82, 82, 82
My Eq calculates: 84, 84, 83, 83, 83, 83, 82, 82, 82, 82
Your Eq calculated (*): 84, 83, 83, 83, 83, 82, 82, 82, 82, 82
* requires your verification. In Excel I used: =ROUND(5 + (Distance * (Capacity+Depot+25000)) / 200000, 0)
Fleet Carrier Router
1) If you do as the page instructs, and only include 'Capacity' (5601), we get: 91, 91, 91, 90, 90, 90, 89, 89, 89, 89
2) If we include Depot as the Eq demands (6517), we get: 94, 93, 93, 93, 92, 92, 92, 92, 91, 92
I got 0 wrong, you were off by 1 twice, and the attempts using FCR got 0 correct, and averaged +7 and +10 respectively.
I still don't rule out user error though. I've done dumber things. But here is an easily documented example, and I can't have dorked all four of them up (I hope).
Lastly, I appreciate you entertaining me on this issue, and I look forward to your feedback once you've run your own numbers. If this turns out to be user error, I'll make a donation to the server, starting at $50 and going up from there based on how stupid my mistake was.
Cheers.
It's the same formula:
Code:
round(5 + (Distance * (Capacity+Depot+25000)) / 200000)
--> P == 5, Capacity+Depot == TC
P + D * (TC + 25000) / 200000
--> 1 / 200000 == 0.000005 == TU
P + D * (TC + 25000) * TU
P + D * (TC * TU + 25000 * TU)
--> 25000 * TU == 0.125 == CO
P + D * (TC * TU + CO)You can bring the 1/8 inside the parenthesis and you get
fuelscost = round(5 + distance * (1/8 + totalcargo / (8*25000)))
now, 1/8 = 0.125 and 8*25000 = 200000 and 1/200000 is 5e-6
and we will get your formula
fuelscost = round(5 + distance * (0.125 + totalcargo * 5e-6))
Last edited:
OK, this is not what I get when I run the FC router. I instead get numbers which match the list you referred to as my equation.
See pic below. Did you have different numbers in the left-hand panel? I guess you must have done, but I can't see why they should have differed.
Further, as @gazelle suggests above, I had believed that our two equations were identical. This means that either we're wrong about that or the two Excel implementations you created differ slightly by accident, and this is creating the off-by-1 on two of the jumps.
Meanwhile, to get an excess of 7 units per jump (making the first jump use 91) I need to boost the cargo by around 2800, which isn't making any sense either.
Probably best to stop here and let you tell me how my pic below differs from yours
FCR (Spoiler - the same): 84, 84, 83, 83, 83, 83, 82, 82, 82, 82
Last edited:
906 != 916