[App] AndDiscovered - Android exploration tracking tool modeled after EDDiscovery

[Gen.Fussypants]

I have been running stress tests most of today on Edproxy. (If I keep this up I will be fired one day )

Without modifying my Operating System I can run 256 simultaneous connections on Edproxy. If I modify the OS to allow more open files (network sockets are treated the same) then I can easily handle 1024 connections. I stopped there as I didn't see a point in going any higher. Performance does get worse as I break the 512 connection mark. However, if there are 512 connections to Edproxy in one network environment then I may just join tfaddy and eat a sock....ok, not really. I hate the taste of socks....not that I have tried one...nope.

Since this is a hobby project, and pretty far from my expertise, I have been lax in my unit tests and fully system tests. All the normal things I would do professionally I have not been so adamant about here. However, this exercise has moved me to produce more of these stress tests. This has been good as I have found a couple minor issues in Edproxy, and one major bug in AndDiscovered. This bug has been addressed in 3.0.

I want to address AndDiscovered's use of EDSM and how that pertains to multiple clients. First each AndDiscovered client (on an individual Android device) is independent of another AndDiscovered client. They do NOT share data at this time. I have been trying to get others interested in a cloud base solution for the planet/star/notes/etc. information so I can sync across devices. However, as of now I have been unsuccessful with this. I use EDSM for two things: 1) getting known coordinates from known systems, and 2) getting known distances. I use this information to 1) help perform trilateration, and 2) to show a list of other systems around your current point with how far away they are. Each time I update the Play Store with a new version of AndDiscovered I also update the initial copy of the EDSM database. When you start AndDiscovered up the first time I pull all new information from EDSM. For some reason pulling the new information on the tablet is incredibly slow. It is not this slow on a PC in my tests. Different Android hardware seems to have a big impact on how fast this update may occur. On my slowest devices this first update can take upwards of 30 minutes. On my faster devices it is around 15 minutes. This process should not impact your use of AndDiscovered. It will impact trilateration attempts, and showing known coordinates on systems. Once the EDSM update is finished all screens will be automatically updated to reflect this new information.

 

[Bam]

I have been using this without a hitch for a few days now, both on my phone and tablet.
I am guessing the original problems I had were due to new installs and slow updates, the Hudl isn't the best tablet around ;-)
One thought that did enter my mind was that if the tablet went to sleep while it was doing the first update it might have caused the data to go missing? Its all there and up to date now since I have been using if for a few days.

Keep up the good work ;-)

 

[Gen.Fussypants]

I have been using this without a hitch for a few days now, both on my phone and tablet.
I am guessing the original problems I had were due to new installs and slow updates, the Hudl isn't the best tablet around ;-)
One thought that did enter my mind was that if the tablet went to sleep while it was doing the first update it might have caused the data to go missing? Its all there and up to date now since I have been using if for a few days.

Keep up the good work ;-)

Awesome that it is working properly for you now. My bet is the fresh install very long update time. If the device goes to sleep during the update process the last entry time is "recorded" so that when it comes back out of sleep it resumes updating where it left off. So you shouldn't have data go missing, but if it was taking a long time to update anyways then you will still experience that. I will focus on this update time after the 3.0 release.

 

[Bam]

You are going to grow to hate me and my 'feedback'....

I have noticed over the last two nights that I seem to have developed a lag between entering distances and them updating. I enter the distance to the next system and it can take 10-15 seconds to update the field, sometimes it doesn't update until after I have arrived in the next system, also the system change now seems to take a lot longer to register than a couple of days ago. This is the same on both my devices, I have 912 jumps in the db if that has anything to do with it.

I bet it me being a numptee, as nothing has changed with your app or relay other than me logging more jumps.

Finally, I promise ;-) a couple of feature requests mainly to do with the screenshot feature.

Would it be possible to have the converted images stored in a different folder and used from there, rather than having the default screenshot folder used to host the images for the server.
Also an option in the android app to save selected images locally, for 'offline' showing off.

*Edit*
It has got more responsive over the last half hour, deff something my end.

 

[Gen.Fussypants]

You are going to grow to hate me and my 'feedback'....

I have noticed over the last two nights that I seem to have developed a lag between entering distances and them updating. I enter the distance to the next system and it can take 10-15 seconds to update the field, sometimes it doesn't update until after I have arrived in the next system, also the system change now seems to take a lot longer to register than a couple of days ago. This is the same on both my devices, I have 912 jumps in the db if that has anything to do with it.

I bet it me being a numptee, as nothing has changed with your app or relay other than me logging more jumps.

Finally, I promise ;-) a couple of feature requests mainly to do with the screenshot feature.

Would it be possible to have the converted images stored in a different folder and used from there, rather than having the default screenshot folder used to host the images for the server.
Also an option in the android app to save selected images locally, for 'offline' showing off.

*Edit*
It has got more responsive over the last half hour, deff something my end.

I will never hate feedback. Good or bad it gives me some insight into what is going on in the field. I am the only tester. I have no communication with "customers" other than this forum. No one leaves defects or enhancements in Jira so feedback here becomes the most important place I have.

As for things getting slower. There are two things that I have experienced that make things slower.

1) Applications updating in the background.
2) EDSM updating in the background with lots of updates

#1 I cannot do anything about. This seems to have the most impact on older devices. If I was to guess it is due to NAND interaction.
#2 I will look at after 3.0 drops. This would explain why things sped back up after awhile. I really want to get 3.0 out first as it enables a lot of new data, and is well really a whole new application. Once it drops I will focus on performance optimizations. Then on new features again.

Would it be possible to have the converted images stored in a different folder and used from there, rather than having the default screenshot folder used to host the images for the server.
Also an option in the android app to save selected images locally, for 'offline' showing off.

Both of these are valid feature requests. I will look at doing them after 3.0. My original intention was to have them copied. Then I noticed the size of the "high resolution" images and felt that was a little large for most tablets. This is why there is an option in settings that is disabled by default. I will modify this to have Images always enabled, but as URLs, and then a flag to enable local storage. Either that or the user must "mark" an image for local storage.

 

[Bam]

Looking forward to any updates, its definitely my app of choice for EDSM data. I only use EDDiscovery for trilateration now, simply because I can copy'n'paste to the game.

*Edit*
I have between 0.5 and 2 sec delay tonight in updating things on the App.

 

[Matt L. Icious]

What's wrong with me/for me?

Hi there,

I've got a question that might fall into the PBCAK category:
After a long time traveling using AndDiscovered as my companion, I checked my EDSM account via the website. I usually travel honk-scan/scoop-check/screenshot system map-check galmap for next system (scoopable? binary?)-start jump-enter 'next system' distance in AndDiscovered while the FSD spools up.
So I expected to see a lot of distances committed to EDSM - but there were none.

My assumption was that AndDiscovered - given that I entered the 'next system' distance - commits the figure to EDSM once a jump is complete (and it knows start and destination system of the distance).
Looks like it does not - at least in my case.

Was this just wistful thinking and not a feature, or is my configuration messed up? Do I have to do something with EDproxy to get there (EDSM plugin configured with CMDR and API key)? Do I understand EDSM wrong, i.e. will it only accept distances from fully triangulated systems or something?

Any hints appreciated - fly safe CMDRs.

 

[AnthorNet]

Hi there,

I've got a question that might fall into the PBCAK category:
After a long time traveling using AndDiscovered as my companion, I checked my EDSM account via the website. I usually travel honk-scan/scoop-check/screenshot system map-check galmap for next system (scoopable? binary?)-start jump-enter 'next system' distance in AndDiscovered while the FSD spools up.
So I expected to see a lot of distances committed to EDSM - but there were none.

My assumption was that AndDiscovered - given that I entered the 'next system' distance - commits the figure to EDSM once a jump is complete (and it knows start and destination system of the distance).
Looks like it does not - at least in my case.

Was this just wistful thinking and not a feature, or is my configuration messed up? Do I have to do something with EDproxy to get there (EDSM plugin configured with CMDR and API key)? Do I understand EDSM wrong, i.e. will it only accept distances from fully triangulated systems or something?

Any hints appreciated - fly safe CMDRs.

For EDSM to link distances to your account you will need to use your commander name.
For the flight logs you will need you API key too.

 

[Gen.Fussypants]

Hi there,

I've got a question that might fall into the PBCAK category:
After a long time traveling using AndDiscovered as my companion, I checked my EDSM account via the website. I usually travel honk-scan/scoop-check/screenshot system map-check galmap for next system (scoopable? binary?)-start jump-enter 'next system' distance in AndDiscovered while the FSD spools up.
So I expected to see a lot of distances committed to EDSM - but there were none.

My assumption was that AndDiscovered - given that I entered the 'next system' distance - commits the figure to EDSM once a jump is complete (and it knows start and destination system of the distance).
Looks like it does not - at least in my case.

Was this just wistful thinking and not a feature, or is my configuration messed up? Do I have to do something with EDproxy to get there (EDSM plugin configured with CMDR and API key)? Do I understand EDSM wrong, i.e. will it only accept distances from fully triangulated systems or something?

Any hints appreciated - fly safe CMDRs.

The Edproxy sends the system you have entered to EDSM given the key. It does not transmit the distances.

AndDiscovered is supposed to transmit any system<->system distances you have entered. It does this every 15 minutes or on first launch of AndDiscovered.

 

[Matt L. Icious]

Thanks for the help, CMDRs!

For EDSM to link distances to your account you will need to use your commander name.
For the flight logs you will need you API key too.

I entered my commander name and API key into EDProxy/EDSM plugin (got an update to 2.2.0 tonight). The flight log seems to be transmitted fine, as it shows up on my EDSM account.

The Edproxy sends the system you have entered to EDSM given the key. It does not transmit the distances.

AndDiscovered is supposed to transmit any system<->system distances you have entered. It does this every 15 minutes or on first launch of AndDiscovered.

Hmm, AndDiscovered has my commander name, and I just double-checked for typos - looks OK. I can't see any way to supply the API key; I assume it is not required.
EDSM does not show any distances in the flight log or accumulated as 'distances entered'.
Not a single one, only the distance I manually entered via the web interface or EDDiscovery. Given that I run the App for hours, I doubt it's a timing issue of missing the update intervals.

So it's a configuration issue on my side. Android security stuff? Firewall/Router thing? Though AndDiscovered gets EDSM data just fine.
Might see if I can sniff some traffic to/from EDSM to see if I can spot any issues, but any other hints/ideas are welcome.

 

[Gen.Fussypants]

Matt L. Icious issue with AndDiscovered has been discovered. There is an error when transmitting to EDSM if you are in a locale that uses a comma for decimal representation. This has been updated in AndDiscovered 3.0 (Pathfinder) beta which will hopefully be deployed within the next week or so.

 

[Matt L. Icious]

Matt L. Icious issue with AndDiscovered has been discovered.

...and my forgetful self missed to say 'thank you' in public.
So there you go: Thank you, CMDR Duck Rodgers.
The issue has been solved through very friendly, competent, and swift private communications. It ended with me getting new beta versions faster than I could put them on my device.

Great work you're doing there; your tool is an integral part of my E-D exploration game play.

 

[Gen.Fussypants]

AndDiscovered is now Pathfinder! Please find the new forum page here: https://forums.frontier.co.uk/showthread.php?t=252224

This page will no longer be maintained.