Edit: And on a quick check, you couldn't, for instance, force perl to use only single-precision floating point to get answers matching the in-game ones. You're stuck with double-precision. I suspect java, javascript, c#, php, python etc are going to face the same issue, being higher level languages.
That is a good point, but if the language in question can load a DLL dynamically (at least Python does) then it could perhaps use the 32-bit precision sqrtf in msvcrtXX.dll.
Searched my bookmarks, emails - not funny. This is what I could find wrt tools that use star system coordinates. If you know of more tools please let me know. I'm SURE there are others but I don't know them or didn't bookmarked them. Beneath is what is shown inside the spoiler tag "List of third party tools using star systems (coordinates)." on the OP.
The tools are listed by commander name - in alphabetic order.
RedWizzard. Web based. Runs locally in your browser. Complete overview of star system data, which can be viewed/sorted in different ways.Github url. Download as zip.
Tried to use your API. Can't get it to work. What am I doing wrong.
To keep things easy and to exclude coding errors I used "Hurl.it — Make HTTP Requests"
Have tried hurlit again. Unfortunately for the same input I'm getting the same error. Could you perhaps check out http://www.hurl.it/ yourself. Tbh I was only 1 out of 3 commanders who tested and reported it...
I have some catching up to do with your suggestions. But would it not mean every cube is very small. In your example each cube has an average of 6.33? But perhaps that IS the whole point. RTFA wolverine RTFA.
Have tried hurlit again. Unfortunately for the same input I'm getting the same error. Could you perhaps check out http://www.hurl.it/ yourself. Tbh I was only 1 out of 3 commanders who tested and reported it...
This is what hurlit shows after the request has been made. I entered for date "2014-09-18 12:34:56'' - without the double quotes ofc. Can you please try if its works for you?
Thanks for the explanation! I still don't yet know the point of a 1/8192 Ly grid JesusFreke mentioned.
Anyway for my method I plan to use 64-bit integers only (coords multiplied by 32) using just addition and multiplication, so all floating point errors can be ruled out.
The 1/8192 grid was purely for that display only. That just happened to be a reasonable precision to show the candidate region at. I wasn't suggesting that might be the size the game uses, but rather using the smaller size to get an idea of the size/shape of the candidate region. Because otherwise, if you try to view the candidate region at 1/32 precision.. it's just a single point. Not very informative
This is what hurlit shows after the request has been made. I entered for date "2014-09-18 12:34:56'' - without the double quotes ofc. Can you please try if its works for you?
i.e. 131.337 when rounded. Thus I'd conclude that this could be what the game is doing and the 'incorrect' rounding is an artifact of using purely 32 bit floats and what goes on with those inside sqrt() and pow() functions.
My basic point is that you can't confirm/deny things like this unless you're using the same format to store and operate on the numbers, and possibly the same exact methods to operate on them (I now need to look at the disassembly to see what instructions ended up being used).
Using perl, python, php, c# ... could just mean you're using a different data type and different functions and thus any number representation and rounding will be different. I think we can assume the game is using whatever Visual Studio provides for C++.
Edit: For example if I use 'bc' (an arbitrary precision calculator), I get:
Edit2: Further testing shows that the discrepancy likely creeps in only at the last stage of calling sqrtf(). Indeed if I call sqrt() instead, which returns a double, I get "131.3364967959" as the answer. Maybe we've found something that FD could fix/change in their code ?
My basic point is that you can't confirm/deny things like this unless you're using the same format to store and operate on the numbers, and possibly the same exact methods to operate on them (I now need to look at the disassembly to see what instructions ended up being used).
This is what hurlit shows after the request has been made. I entered for date "2014-09-18 12:34:56'' - without the double quotes ofc. Can you please try if its works for you?
Try this to be convinced it's hurl.it and not the API:
Start up EDSC in your browser - Hit f12 (developer mode), and copy paste the example JavaScript below (slightly modified code from the api.html page to output something to the console) into the console, then call the code with "getSystemData()" (name of the function in the example JavaScript)
In your console you should shortly see "Success" - as proof that the server has returned a valid result.
Code inside
Code:
function getSystemData(){
var data = {data: {ver:1, cr:5, date:"2014-09-18 12:34:56"}};
//var data = {data: {ver:1}}; //Just one required parameter - Simplest possible
$.ajax({
type: 'POST',
contentType: 'application/json; charset=utf-8',
url: 'http://edstarcoordinator.com/api.asmx/GetSystems',
data: JSON.stringify(data),
dataType: 'json',
success:
function(data){
submitsuccess(data.d);
},
error: submiterror
});
};
function submitsuccess(data) {
//Check msg to determine if data was stored to server (was valid)
if (data.status.err == 0) {
console.log(data.status.msg);
}
else {
console.log(data.status.msg);
}
}
function submiterror(d, a) {
console.log(d);
}
If someone could figure out why hurl.it seems to choke on this, that would be cool - As it seems many are using hurl.it to test...
But apparently there is something in the way I've formatted the output coming back from the server that these services (hurl.it /curl) have problems with.
I'd love to find out what - and perhaps change the output so those services know how to work with it as well.
Try this to be convinced it's hurl.it and not the API:
Start up EDSC in your browser - Hit f12 (developer mode), and copy paste the example JavaScript below (slightly modified code from the api.html page to output something to the console) into the console, then call the code with "getSystemData()" (name of the function in the example JavaScript)
In your console you should shortly see "Success" - as proof that the server has returned a valid result.
Code inside
Code:
function getSystemData(){
var data = {data: {ver:1, cr:5, date:"2014-09-18 12:34:56"}};
//var data = {data: {ver:1}}; //Just one required parameter - Simplest possible
$.ajax({
type: 'POST',
contentType: 'application/json; charset=utf-8',
url: 'http://edstarcoordinator.com/api.asmx/GetSystems',
data: JSON.stringify(data),
dataType: 'json',
success:
function(data){
submitsuccess(data.d);
},
error: submiterror
});
};
function submitsuccess(data) {
//Check msg to determine if data was stored to server (was valid)
if (data.status.err == 0) {
console.log(data.status.msg);
}
else {
console.log(data.status.msg);
}
}
function submiterror(d, a) {
console.log(d);
}
If someone could figure out why hurl.it seems to choke on this, that would be cool - As it seems many are using hurl.it to test...
I'm getting this as an error:
TypeError: $.ajax is not a function
But that was to be expected because iirc you API page said it needs jquery installed - which I have NOT.
That was the reason for my suggestion if perhaps you could include a simple downloadable examples. Something like RW has done with his tool - but then barebone. This would allow commanders to have a working example on which they can build.
Yes the API *is* working.
But apparently there is something in the way I've formatted the output coming back from the server that these services (hurl.it /curl) have problems with.
I'd love to find out what - and perhaps change the output so those services know how to work with it as well.
I believe you, I do.
Btw curl is not a service, its just a command line tool which sends something to a server (with these parametes a POST request) and then prints the output to stdout. There is NO interpreting of output. Just plain simple dumb to stdout. If I had time I would install wireshark so I could see EXACTLY what is being sent and was is being received, which I could present here....
I finally finished my coordinate verifier tool (visit link to see how it works), and it also thinks that some coordinates are invalid:
LDS 1503
LHS 3297
WREDGUIA WH-Q B46-2
The tool thinks there is no valid coordinate for these systems, in other words, one or more of the distances must be incorrect. All other systems seems to be valid. I used this source.
So either the reported coordinates are incorrect (typo or rounding error), or there is something I didn't think of, and therefore not covered with a unit test in my tool.
Edit: Btw, I used just the date part, hence no space in my query, but didn't check what the exact POST data was. I assumed Google knows how to encode form values better than me, using the 3rd example from the docs.