hmm - One quick thought about the new coordinate system (galaxy coordinates - instead of sol coordinates)
With the much higher numbers - The distances could be even more inaccurate (due to the float32 "overrun" when squaring).
Ofc with just 2dp we probably won't notice.
Donning tinfoil hat: Maybe that's why they changed it
Removing tinfoil hat: More likely some UI/UX dude that didn't like all those digits
Heh - I think you are making it much more difficult than it is in your mind.
I simply assumed that they hadn't discarded the 1/32 system.
Look at the new numbers - You won't see anyone ending in
xxxxx.01
xxxxx.02
xxxxx.04
xxxxx.05
xxxxx.07
xxxxx.08
xxxxx.10
xxxxx.11
xxxxx.12
etc
Notice the gabs?
That's because for no value of x will x/32 produce any of those numbers (after rounding to 2dp)
As such it's easy enough to work backwards.
If something ends with xxx.03 - It's xxxx.03125 (1/32) rounded to two decimals
liekwise xxxx.44 is xxxxx.4375 (14/32) rounded to 2dp
---------
Reminds me... Something we need to check (once we have enough new distances)
Are they now (for some bizarre reason) calculating the distances on the GM with those 2dp numbers (instead of the 1/32 numbers).
This would give even more inaccurate distance readings.....
I very much doubt this is the case - And think it's simply the output (of the 1/32 math) that's been rounded.
But.. needs to be verified at some point.
Instead of using RMS to pick the best candidate from the cubesearch - I'm going to do the reverse distance check instead.
I'm going to record how many coords in the cube will pass that reverse distance check (I expect multiple often will - due to only 2dp).
I'll then use RMS to pick one p0 among just those that pass the reverse distance check - and then check to see if that value is indeed correct.
I honestly don't expect to see much of a difference in the results (error percentage) - But I'm kinda interested in seeing just how many candidates in a cube search will actually pass the reverse distance check.
Which will put some kind of number on how impossible (literally) it will be for some sets of distances to determine the correct p0.
OK - Done that for 5 reference systems and a cube with radius 8 (that takes awhile to run )
And.... It's a total bust.
Zero improvements on the set of incorrect values.
Reason being that there are waaaaaaaaaaaaaaaay too many candidates that pass the reverse distance check.
So when doing the final RMS selection on those - it simply picks the same one again.
To give an idea just HOW many candidates pass the reverse distance check (with 2dp)
For the 17^3 cube (radius 8 +1) - total points : 4913
In one case 288!!! of those passed the reverse distance check.
That's an outlier of course.
Interestingly enough there seems to be two ranges it clusters around: 95-100 and 119-123 (ish..)
Ie. most often you'll get 97 or 121 candidates that pass the reverse distance check (on *all* the distances)
Which is just insane - I did expect multiple hits, but by far not that many.
The low ball outlier: Never did I get less than 51 candidates that passed the reverse distance check (on *all* distances)
So.. With just 2dp, reverse distance checking isn't worth much.
From the numbers of just the 5 ref / 8 radius test, I see no point in pursuing this with further tests (more ref systems, different radius)
For the high radius test, I expect it to return exactly the same results - The low radius ones, might introduce a bit of noise (as not as many candidates will be found), but that's all.
So in my book reverse distance checking is out the window with regards to determining p0.
It can of course still be used to rule out very wrong distances (due to typoes etc)
Forgive me if I've missed an important point in this very long thread that would negate what I am about to say, but is there a reason why 3D coordinates are a necessity? If route planning is the ultimate objective, then constructing a weighted undirected graph should suffice. Each edge would be the distance in light years between stars and fuel costs for any given trip would be a function of fuel tank capacity and drive efficiency. That would mean the only input required would be the distance between stars which is something the galactic map already provides. As Chromatix suggested earlier, there are already algorithms that can utilize this data to calculate routes such as Dijkstra's, Floyd–Warshall's, and others.
The jump cost depends on the 3D distance, FSD parameters, and the total mass being used. It's not linear, so you'd have to generate a new graph for each ship. I believe it's just easier to calculate then use the coordinates using an octree and A*. I use them in this way in my route planner lib behind my starchart. (With fuel use/refuel points taken into account, also whether there is a system in the station, how big your fuel tank is, and the option to save fuel or time along the route). I learnt that even two stars very close to each other can yield different routes, the one farther away requiring many jumps to not have to refuel in between (which is considered time expensive), while the one closer could be reached with a much shorter path.
But for every star you would have to gather the distances to all other stars within a range equal to the max range of any ship (ever) in order to have the full and complete graph.
That means a lot more data points to gather for each system (as so many stars will be within range).
To get the coordinates we (currently) need minimum 5, but preferably 6-7 distances and it's done.
And also - having the coordinates better allow you to make maps etc. (not impossible to do without them - Just harder)
I'm sure there are other things I haven't thought off
The jump cost depends on the 3D distance, FSD parameters, and the total mass being used. It's not linear, so you'd have to generate a new graph for each ship.
I was under the impression that distance was only 2D. Are you saying that a Z coordinate affects the resulting distance between stars? As for the other components in the calculation you mentioned, I agree - I wasn't trying to imply that distance was the only factor to consider which is why I made passing reference to fuel tank capacity, etc. I was just trying to see if I could propose something that would help you guys out considering the problems encountered of late. Evidently it appears you have it all well in hand.
But for every star you would have to gather the distances to all other stars within a range equal to the max range of any ship (ever) in order to have the full and complete graph.
That's true. As I said a minute ago, I was just trying to see if I could offer a suggestion that would help in those instances where the best data is not yet available. I certainly didn't mean to say that what you guys are doing is anything less than awesome.
The whole idea of trade calculators, route planners, et al is something I think the game really needs and I applaud your efforts. It's strange, but today I can get on Google Maps and plot a course anywhere on the planet with ease. I can also log onto Amazon.com and prices for any product being sold from multiple vendors. Why there isn't such a capability in Elite Dangerous is interesting because the setting is in the distant future - one would expect to see more advanced technology, not less.
Re Galaxy coords vs SOL coords. As long as the in game map is SOL centered, TGC should work on SOL coords too.
Now, here is a little something for free use:
Code:
<body>
<span id="firsttext">First upload the grid view:</span>
<input name="uploadgrid" type="file" id="uploadgrid" />
<br />
<div id="firstid">[ START ] first click the 4 edges, then click center of orange dot<br />
</div>
<span id="secondtext" style="display: none;">Now upload side shot of star: </span>
<input name="uploadside" type="file" id="uploadside" style="display: none;" />
<div id="secondid" style="display: none;">[ START ] first click on horizon, then click on star.</div>
</body>
Oh, and of course the javascript to go with it:
Code:
$(document).ready(function(){
if(window.FileReader){
console.log("file reader support");
}
else{
alert("This will not work")
}
$(":file").on("change", function(e){
handleFile((this).id, e);
});
});
var points = new Array();
var firstfile = null;
var firstimg = null;
var secondfile = null;
var secondimg = null;
var storesize = 0;
var offx = 0;
var offy = 0;
function handleFile(id, e){
if(id == "uploadgrid"){
var file = document.getElementById(id).files[0];
firstfile = file;
var img = new Image();
firstimg = img;
img.onload = function(){
$("#firstsrc").remove();
var canv = document.createElement("canvas");
canv.width = this.width;
canv.height = this.height;
canv.id = "firstsrc";
document.getElementById("firstid").appendChild(canv);
var c = canv.getContext("2d");
c.drawImage(this, 0, 0);
$("#firstsrc").on("click", function(e){
points.push(new Array(e.offsetX, e.offsetY));
if(points.length == 4){
redrawFirstImage();
}
if(points.length == 5){
calculateFromCenter();
}
});
}
}
else if(id == "uploadside"){
var file = document.getElementById(id).files[0];
secondfile = file;
var img = new Image();
secondimg = img;
points = new Array();
img.onload = function(){
$("#firstsrc").remove();
var canv = document.createElement("canvas");
canv.width = this.width;
canv.height = this.height;
canv.id = "secondsrc";
document.getElementById("secondid").appendChild(canv);
var c = canv.getContext("2d");
c.drawImage(this, 0, 0);
$("#secondsrc").on("click", function(e){
points.push(new Array(e.offsetX, e.offsetY));
if(points.length == 2){
calculateLastOffset();
}
});
}
}
img.src = URL.createObjectURL(file);
}
function calculateLastOffset(){
offz = Math.round((((points[0][1] - points[1][1])*4)/storesize)*1000)/1000;
document.getElementById("firstid").innerHTML = "Offset X: <b>"+offx+"</b> Offset Y: <b>"+offy+"</b> Offset Z: <b>"+offz+"</b><br />";
$("#uploadside").hide();
$("#secondid").hide();
$("#secondtext").hide();
document.getElementById("firsttext").innerHTML = "<b>We now have X, Y and Z offset.</b>Exercise done.<br />";
}
function calculateFromCenter(){
var can = document.getElementById("firstsrc");
var w = can.width;
var h = can.height;
offx = Math.round(((w - points[4][0]) / w)*1000)/1000;
offy = Math.round(((h - points[4][1]) / h)*1000)/1000;
storesize = (w + h) / 2;
document.getElementById("firstid").innerHTML = "Offset X: <b>"+offx+"</b> Offset Y: <b>"+offy+"</b><br />";
$("#uploadgrid").hide();
$("#uploadside").show();
$("#secondid").show();
$("#secondtext").show();
document.getElementById("firsttext").innerHTML = "We now have X and Y offset, continue to Z...<br />";
}
function redrawFirstImage(){
var can = document.getElementById("firstsrc");
var w = can.width;
var h = can.height;
var c = can.getContext("2d");
c.clearRect(0,0,w,h);
var mm = findminmax(points);
w = mm[1] - mm[0];
h = mm[3] - mm[2];
can.width = c.width = w*4;
can.height = c.height = h*4;
//c.drawImage(firstimg, 0, 0, w, h, mm[0], mm[2], w, h);
c.drawImage(firstimg, mm[0], mm[2], w, h, 0, 0, w*4, h*4);
}
function findminmax(pa){
var minx = 99999;
var maxx = -1;
var miny = 99999;
var maxy = -1;
var n = pa.length;
for(var i = 0; i < n; i++){
if(pa[i][0] < minx){
minx = pa[i][0];
}
if(pa[i][0] > maxx){
maxx = pa[i][0];
}
if(pa[i][1] < miny){
miny = pa[i][1];
}
if(pa[i][1] > maxy){
maxy = pa[i][1];
}
}
return new Array(minx, maxx, miny, maxy);
}
Code is fast and dirty, formating of html not a priority.
In short, it takes two screenshots. Zoom in on selected star, try to get as much top down and as little rotation as possible, F10, rotate to side view, still zoomed in, try to get a background with good contrast to make it easier for yourself and F10.
Select first screenshot (everything happens client side, no upload). Image loads, click on the 4 bounding borders around star, image zooms, click on center of orange circle (not star, thats "off" from what I see). Voila you should have x and y offset more then good enough to snap on a 1/32 grid.
Next select second screenshot, click on horizon grid, click on main star (the one with all the lines going from it...), and there is z offset that also should be precise enough to snap on grid.
Then count the grid to get the main coords (and since it is in game, it is SOL centered).
Code only tested on Opala, getting good enough results.
No error checking included.
Process could of course be optimized a lot. one could be to click all 4 corners instead of borders. Then rotate and counter the slight perspective. Maybe have 4 corners you could drag to fit the grid. Then a circle that you could change size of and align to the blue or orange circle. That would be more accurate.
Please feel free to loan and change code if you want to include in your tools. Personally I will finetune it a bit for my "works-for-me" tools. Its faster and less error prone then writing down a lot of distances.
I was under the impression that distance was only 2D. Are you saying that a Z coordinate affects the resulting distance between stars? As for the other components in the calculation you mentioned, I agree - I wasn't trying to imply that distance was the only factor to consider which is why I made passing reference to fuel tank capacity, etc. I was just trying to see if I could propose something that would help you guys out considering the problems encountered of late. Evidently it appears you have it all well in hand.
Distances are based on the 3-d coordinates of a star, so yes, the "Z" coordinate does affect the distance.
Consider, for example, one star that is at the top of the pill, and the other star that is at the bottom of the pill, but at nearly the same x,y coordinates. If what you said was true, then you could make that jump, because the x/y distance would be very small. But in fact, the distance would actually be on the order of 74 LY (iirc, based on the 37LY pill radius mentioned in the announcement).
I was under the impression that distance was only 2D. Are you saying that a Z coordinate affects the resulting distance between stars? As for the other components in the calculation you mentioned, I agree - I wasn't trying to imply that distance was the only factor to consider which is why I made passing reference to fuel tank capacity, etc. I was just trying to see if I could propose something that would help you guys out considering the problems encountered of late. Evidently it appears you have it all well in hand.
Distance is a scalar, so it is technically 1D. Or you mean only the 2D (eg. X/Y) coordinates should be used? That would make no sense, because if two systems happened to be on the same line, parallel to the cardinal axis you are leaving out (in your case Z) their distance would be zero.
I don't know if you saw my map, but it can be misleading in this case, as it shows a bubble of certain radius on the 2D plane, and still everything is visible, so one could get the false impression that Z is unnecessary. But my route planner really works in 3D, with the actual coordinates. Only map displays the stars using a physics simulation, forcing all systems and names visible. I will make it work for the complete Beta 3 pill, too (not just individual bubbles). Actually, with just 2500ish stars it will be easy, I prepared my simulation code for many more. I just need to wait a bit until the nice fellows in this thread collects the distance values, and do the hard part of this job.
Now that we have a partial list of 755 systems (minus a few like no star system, outside the pill/sausage) could perhaps a tool cmdr check if the coordinates of the SB2 systems are the same as in SB3. Which stars have been removed (outside pill) etc. As the coords are no longer based on SOL doing this manually is a PITA. I get the feeling that some cmdrs have tools ready to check this - or after tweaking theirs a bit. Would be good to know what has changed. Would be very much appreciated.
Re Galaxy coords vs SOL coords. As long as the in game map is SOL centered, TGC should work on SOL coords too.
Now, here is a little something for free use:
Code:
<body>
<span id="firsttext">First upload the grid view:</span>
<input name="uploadgrid" type="file" id="uploadgrid" />
<br />
<div id="firstid">[ START ] first click the 4 edges, then click center of orange dot<br />
</div>
<span id="secondtext" style="display: none;">Now upload side shot of star: </span>
<input name="uploadside" type="file" id="uploadside" style="display: none;" />
<div id="secondid" style="display: none;">[ START ] first click on horizon, then click on star.</div>
</body>
Oh, and of course the javascript to go with it:
Code:
$(document).ready(function(){
if(window.FileReader){
console.log("file reader support");
}
else{
alert("This will not work")
}
$(":file").on("change", function(e){
handleFile((this).id, e);
});
});
var points = new Array();
var firstfile = null;
var firstimg = null;
var secondfile = null;
var secondimg = null;
var storesize = 0;
var offx = 0;
var offy = 0;
function handleFile(id, e){
if(id == "uploadgrid"){
var file = document.getElementById(id).files[0];
firstfile = file;
var img = new Image();
firstimg = img;
img.onload = function(){
$("#firstsrc").remove();
var canv = document.createElement("canvas");
canv.width = this.width;
canv.height = this.height;
canv.id = "firstsrc";
document.getElementById("firstid").appendChild(canv);
var c = canv.getContext("2d");
c.drawImage(this, 0, 0);
$("#firstsrc").on("click", function(e){
points.push(new Array(e.offsetX, e.offsetY));
if(points.length == 4){
redrawFirstImage();
}
if(points.length == 5){
calculateFromCenter();
}
});
}
}
else if(id == "uploadside"){
var file = document.getElementById(id).files[0];
secondfile = file;
var img = new Image();
secondimg = img;
points = new Array();
img.onload = function(){
$("#firstsrc").remove();
var canv = document.createElement("canvas");
canv.width = this.width;
canv.height = this.height;
canv.id = "secondsrc";
document.getElementById("secondid").appendChild(canv);
var c = canv.getContext("2d");
c.drawImage(this, 0, 0);
$("#secondsrc").on("click", function(e){
points.push(new Array(e.offsetX, e.offsetY));
if(points.length == 2){
calculateLastOffset();
}
});
}
}
img.src = URL.createObjectURL(file);
}
function calculateLastOffset(){
offz = Math.round((((points[0][1] - points[1][1])*4)/storesize)*1000)/1000;
document.getElementById("firstid").innerHTML = "Offset X: <b>"+offx+"</b> Offset Y: <b>"+offy+"</b> Offset Z: <b>"+offz+"</b><br />";
$("#uploadside").hide();
$("#secondid").hide();
$("#secondtext").hide();
document.getElementById("firsttext").innerHTML = "<b>We now have X, Y and Z offset.</b>Exercise done.<br />";
}
function calculateFromCenter(){
var can = document.getElementById("firstsrc");
var w = can.width;
var h = can.height;
offx = Math.round(((w - points[4][0]) / w)*1000)/1000;
offy = Math.round(((h - points[4][1]) / h)*1000)/1000;
storesize = (w + h) / 2;
document.getElementById("firstid").innerHTML = "Offset X: <b>"+offx+"</b> Offset Y: <b>"+offy+"</b><br />";
$("#uploadgrid").hide();
$("#uploadside").show();
$("#secondid").show();
$("#secondtext").show();
document.getElementById("firsttext").innerHTML = "We now have X and Y offset, continue to Z...<br />";
}
function redrawFirstImage(){
var can = document.getElementById("firstsrc");
var w = can.width;
var h = can.height;
var c = can.getContext("2d");
c.clearRect(0,0,w,h);
var mm = findminmax(points);
w = mm[1] - mm[0];
h = mm[3] - mm[2];
can.width = c.width = w*4;
can.height = c.height = h*4;
//c.drawImage(firstimg, 0, 0, w, h, mm[0], mm[2], w, h);
c.drawImage(firstimg, mm[0], mm[2], w, h, 0, 0, w*4, h*4);
}
function findminmax(pa){
var minx = 99999;
var maxx = -1;
var miny = 99999;
var maxy = -1;
var n = pa.length;
for(var i = 0; i < n; i++){
if(pa[i][0] < minx){
minx = pa[i][0];
}
if(pa[i][0] > maxx){
maxx = pa[i][0];
}
if(pa[i][1] < miny){
miny = pa[i][1];
}
if(pa[i][1] > maxy){
maxy = pa[i][1];
}
}
return new Array(minx, maxx, miny, maxy);
}
Code is fast and dirty, formating of html not a priority.
In short, it takes two screenshots. Zoom in on selected star, try to get as much top down and as little rotation as possible, F10, rotate to side view, still zoomed in, try to get a background with good contrast to make it easier for yourself and F10.
Select first screenshot (everything happens client side, no upload). Image loads, click on the 4 bounding borders around star, image zooms, click on center of orange circle (not star, thats "off" from what I see). Voila you should have x and y offset more then good enough to snap on a 1/32 grid.
Next select second screenshot, click on horizon grid, click on main star (the one with all the lines going from it...), and there is z offset that also should be precise enough to snap on grid.
Then count the grid to get the main coords (and since it is in game, it is SOL centered).
Code only tested on Opala, getting good enough results.
No error checking included.
Process could of course be optimized a lot. one could be to click all 4 corners instead of borders. Then rotate and counter the slight perspective. Maybe have 4 corners you could drag to fit the grid. Then a circle that you could change size of and align to the blue or orange circle. That would be more accurate.
Please feel free to loan and change code if you want to include in your tools. Personally I will finetune it a bit for my "works-for-me" tools. Its faster and less error prone then writing down a lot of distances.
One suggestion - I find it's much more accurate measuring the distance horizontally. So ideally, you would want to do 3 screenshots, such that you can do the 2 "in-plane" coordinates using a horizontal measument, instead of doing a horizontal and vertical measurement with a single screenshot.
Although, if the vertical measurement is still accurate enough to give the correct grid point, then I guess it doesn't really matter.
I don't know if you saw my map, but it can be misleading in this case, as it shows a bubble of certain radius on the 2D plane, and still everything is visible, so one could get the false impression that Z is unnecessary. But my route planner really works in 3D, with the actual coordinates. Only map displays the stars using a physics simulation, forcing all systems and names visible. I will make it work for the complete Beta 3 pill, too (not just individual bubbles). Actually, with just 2500ish stars it will be easy, I prepared my simulation code for many more. I just need to wait a bit until the nice fellows in this thread collects the distance values, and do the hard part of this job.
This is what I get for trying to multitask at work. I understand that in 3D space you need two sets of X,Y,Z coordinates to calculate distance between two points. My own inaccurate wording in my previous post is what I think caused my confusion. In short I wanted to be sure that the game wasn't doing anything strange with respect to a distance of 1 light year in two specific cases: one in which the Z coordinate is the same, one in which it is different. To put it more succinctly, I was trying to determine if there was a penalty for going "uphill" or a boost for going "downhill". I know that's not the way it works in real space, but I figured it wasn't a bad idea to double-check.
You are absolutely correct. For some reason my tired brain was not operating in a strict Euclidean sense and I attributed the thickness of the line being drawn as the 2nd dimension. Ugh! I'm going to blame my less than impressive showing in this thread today on late nights playing Elite Dangerous and low blood sugar. My apologies for the noise, my friend.
Now that we have a partial list of 755 systems (minus a few like no star system, outside the pill/sausage) could perhaps a tool cmdr check if the coordinates of the SB2 systems are the same as in SB3. Which stars have been removed (outside pill) etc. As the coords are no longer based on SOL doing this manually is a PITA. I get the feeling that some cmdrs have tools ready to check this - or after tweaking theirs a bit. Would be good to know what has changed. Would be very much appreciated.
I'd start by assuming Eranin hasn't moved, use that to give the conversion offsets, and then check they give the same answer for other probably-not-moved systems. I wouldn't simply check the distance between pairs of systems as that still allows for things to have been shifted wholesale. I really don't expect the 100% authored systems to have moved at all though.
