This is awesome
I am going to update all my fave systems on here tomorrow, I can see they are lacking in data....
I am going to update all my fave systems on here tomorrow, I can see they are lacking in data....
It was a pleasure to serve you. Take my Rep for lightspeed fast taking care.
Regards,
Miklos
OK I have done my best to repair your edits, certainly most of the data seems back again. Apologies if any is still missing.It was a pleasure to serve you. Take my Rep for lightspeed fast taking care.
Regards,
Miklos
Hello again,
I'd like to inform you that you might have some kind of Typo in the map.
You announce as system near cd-35 9019 as IM-W C1-26 but in the navigation pane of my T6 its named EW-W C1-26.
So the conclusion is one of you is to be wrong.
In doubt I hold you responsible for the error in the first place and would like to ask you to fix it. If it isn't your fault
just let me know to ticket it.
Thanks and Regards,
Miklos
Hello All!
starchart is a great-looking tool, thanx!
Besides, I have a question - while trying to fill-up some system/station descriptions I've encountered numerous updates from someone called "Syncopation [EDDB+TradeDangerous+Maddavo]"
Looks like a good try to synchronize different db's available right now, surely using some kind of script, but is it really a good idea to populate _repeatedly_ starchart with erroneous system-description data? "Adelman Port" and "Kawanishi Station" are not present in Eta-2 Hydri. Worst, this script corrupts(heh, "corrects") existing data, like resetting all station distances and station types for one chosen (see "Karsuki Ti").
I don't see any good approach either. Two systems I've mentioned already.Unfortunately FD have completely confused everything by renaming over 100 systems' stations. I expect that is some of what is going on here. It is helpful if you point-out these errors so I can improve the script. If there is a value in Starchart it should be preserved unless it conflicts with multiple other sources. The more details you can give the better. I have a big list of mismatches but it takes a lot of time to go through them all.
I don't see any good approach either. Two systems I've mentioned already.
The only evident way I see is to manually control/edit data, and I don't see any programmatic way to distinguish any up-to-date user-approved data from obsolete, committed or erroneous. Question of confidence and, may be, some additional fields in db (ohh..), like manual/script data source flag (oh, game/map version?... no-no-no). While being also fan of scripting, in this particular case I see the best solution to limit script rights to adding omitted/not present data and restrict the possibility to correct already present data. So this will not work with Eta-2 Hydri, but can help with Karsuki Ti.
Anyway thankx for the efforts!
CMDR DJA
By some good coincidence i was in Karsuki Ti at the moment of writing this post. All corrections is up-to-date for now on starchart (there were also problems with starport types).I have had a look and can see no evidence that Karsuki Ti has had multiple overwrites, just a single update from EDDB which has incorrect distances (now corrected). I have an exclusion list in the script that I am slowly updating with issues like Eta-2 Hydri. If you see any more, let me know. Cheers!
Here is a web app that displays nearby systems.
https://dl.dropboxusercontent.com/u/276965/edstarchart.png
With route calculation in place, this part is not relevant anymore:
It is still in an early stage, and is quite useless for anything else other than virtual stargazing, but shows that even a 3D map can be displayed in 2D reasonably well. Currently it displays at most 60 stars within a 25 Ly radius. (Seems to work with Mozilla and Chrome) If there are many systems nearby, only the 60 closer ones are shown, to avoid overlap. For example around i Boötis only the stars within a 20.5 Ly radius are shown.
The maps are created using the X and Y coordinates of the stars. Then a simulation is performed, with all visible stars acting like having an electric charge, and pushing each other around until all names are visible.
Special thanks to forum members kfsone, Smacker, Codec and Chromatic for their work and inspiration for my project.
Re-Arm, Refuel and Repair is missing because of the following reasons:
1. These facilities seem to be always available, I have yet to see a station that does not allow it, even if said facility is not listed on the system map.
It is not clear how these are used, or how these would be useful for external tools.
2. Other data sources I'm aware of don't use or list these either.
3. Reduce clutter (TBH these were in for a short time, until we've realized points 1 and 2).
Distance has always been there in the data from the very beginning, either you remember incorrectly or the field was accidentally omitted from the output earlier.
Btw, sometimes I just make screenshot(s) of the LHS panel and enter the distance later. Or check the distance after docking. That is unusual, and I do it only if there is no distance data yet, because both for trading and route planning it might be useful to have one roughly correct distance than none, even if it is not precise.
I can tell you I have run across systems with only outposts where one had Repair/Refuel and the other had Repair/Re-Arm and had to fly back and forth between the two in order to full stock up. And that's well inside the bubble that I found this system (Was undermining when I found it). That system is MIRDI by the way, I'm sure there are others out there like that.
I'd like, at this point, to suggest you might copy this particular info along to JACKIE SILVER to see what she might make of it....This is one of the rare double named systems, I think it is an FD bug. I have entered a ticket. Actually this system is called both:
Hydrae Sector IM-W c1-26
and
Crucis Sector EW-W c1-26
it is very confusing!
I forgot to mention in my last post that of course anyone is very welcome to assist me with this project.
Frankly, most of my time is spent with the HTML/CSS of it: I wasted much more time adding a #%&^*% checkbox for the "save fuel" option than doing the server-side code. I could not figure out the CSS part at the end, so I added a dropdown list instead. I would not be surprised if most of the javascript code and therefore the HTML and CSS had to be refactored or rewritten.
If it's easier to do more in javascript, then the same data (coordinates for the graphic, routes etc) could be supplied via json, with minimal changes on the server code.