Mainly yes, except the EDDsicovery coordinates will probably come from EDSM and not EDDB because EDDB's coordinate data contains lots of errors.
EDDB syncs his coordinates with us. But I don't know if the correction are put also. I'll ask him
Mainly yes, except the EDDsicovery coordinates will probably come from EDSM and not EDDB because EDDB's coordinate data contains lots of errors.
Oops, this was there at the very beginning (old GUI), don't know when it disappeared. It was discussed earlier, and at least some CMDRs said the point is correct because of English notation, and English is the widely accepted language, and the comma may be a thousand's separator. But I asked who would care to enter a thousand's separator by hand...
Bug report: Inconsistent case when submitting and receiving from EDSM
I submitted a co-ord as "Nu Monocerotis". On restarting EDDiscovery I now have points for "Nu Monocerotis" and "NU Monocerotis". Yay, case management bug!![]()
Can you tell me the right one?
TGC AKA EDSC AKA The Great Collector AKA ED Star Coordinator. http://www.edstarcoordinator.com/ Was a project started by TornSoul about autumn 2013 IIRC. TornSoul disappeared, and his page & database was left unmaintained. The responsiveness of the API was goin up & down like a rollercoaster, I had to adjust the timeouts to 10 or 20 minutesI'm not sure what TGC is,
Woot, that's slow. The normal EDSM pages usually need less than 2 seconds. Things that may take more time, like coordinate calculation, are mainly put in the background so the page will be displayed but there's a little animation until the result of the calculation is displayed.but what's really slow with EDSM is the load times (typically about 25s per page). I have tabs open that haven't finished loading for several minutes; the cause could just be packet loss, but I rarely have such trouble with any other sites.
In EDDiscovery simply click "Sync with EDSM" from time to time, and restart it if you're still missing data. That's what I do. But if your copy of EDDiscovery can't parse the EDSM distance data, you're in trouble. Maybe Finwen can help here.Until a few minutes ago (when EDSM stopped reponding completely) I was entering data using EDDiscovery to trilaterate new systems then EDSM to add on a few distances to older blue systems (generally 10 of them, as that's the size of the forms EDSM presents). But it was all unidirectional as EDDiscovery would only know its own triangulated coordinates, not anything new from EDSM.
This should be sufficient. My notebook has 12GB and I don't run into memory trouble. Although I only have one ED instance.My PC has a large memory usage of 22% (7GB of 32GM used, certainly leaving enough for any 32-bit process) with a web browser, two Einstances, and a few other things running.
I have 5242 entries in EDSM on notebook and 5229 at EDSM, so olny13 missing. Will check my stationary PC later. But you wrote you have about 7k EDDiscovery entries, you're missing 2k.I've synced my travel logs, and I can't tell why EDSM would have fewer entries (it reports4889 systems for me, which is the right ballpark).
Yep, I saw this, too. I had to sync several times until no more data was transferred. Now, when I switch from notebook to stationary or back, I sync and within seconds the correct travel log is on screen, as far as I can tell.My recent visits should be in there, and typically when I hit the sync button EDDiscovery reports sending some dozens of entries.
A restart of EDDiscovery suggests that it does get systems directly from EDSM, but only on startup. It's the distance data it fails on.
I get an unhandled exception crash when minimizing the 3D star map:
Valije, that's essentially what I have been requesting... the special case for EDDiscovery would be that since these reference systems have no position, they cannot contribute to the trilateration. They're just distances to report into EDSM.
I had a quick look at the GetEDSMDistances source code and EDSM API. A possible workaround for my out of memory issue would be to add an enddatetime parameter to the EDSM distance request; this would limit the data size, allowing us to process it in acceptable chunks. It could then process chunks of a few months or so and finish after a handful of restarts instead of running out of memory every time.
Wow, just got back tot he bubble, and realised the there are actually still unlogged systems...
Guess I have work to do...
Noted an update dropped today, I'm very impressed at the amount of work going in to this project.
Z...
Wow, just got back to the bubble, and realized the there are actually still unlogged systems...
Guess I have work to do...
Noted an update dropped today, I'm very impressed at the amount of work going in to this project.
Z...