Not to be mean. Consider this a challenge rather then a insult.
Assume you have a 300kb file (~3/10ths) of a MB. With values being streamed into via a streamwriter from a program in the background. This file is constantly edited (hundreds of times per second). And is then in turn uploaded (takes time) to a central server. Viewed (takes time). Sent (Takes time), and downloaded (takes time) via an Android Phone (kindle in his case).
Still, one might think that this will only take around 1-2 seconds to occur. Now take this into account. (I'm sure the OP has already, just informing people that think this may be an easy job for him)
But isn't this literally a CSharp or C++ program (not sure which you are using) that does everything that a normal ESP/RADAR does and reads the memory. Then sends all this information to a server. Players, coordinates, etc, map coords. Then you just draw that to a picture box on your android phone created via ECLIPSE IDE.
This would be very very very very ineffcient and slow.
There are elements that have to be considered here that are some very out of your control which would make this crash. No offense. It is possible. But, it is highly unlikely that it would be successful.
If you've ever worked with a client server architecture in CSharp slash C++ you'd know that it approximately takes a good few seconds (if you have really good internet) for the ftp connection to establish a "proper" connection with the server host (this really depends on your location, wifi strength, and upload speed, and the servers download, and upload speed).
Assuming that it does make this connection successfully, you cannot multi-thread this into a mass connection. It'd lag the clients internet, connection, and with so many connections going out would cause both the server (depending on its stability) and the client to most likely crash before the 200th connection is sent out.
Assuming you will update this at least one time per second (Or it is kinda rendered useless) Who likes a skippy radar.
Even if you wanted to update once per 5 seconds. The server and the client (assuming they can keep up at this rate) would sustain more latency when the server attempts to send this connection (packet) back to the client (android phone), this is totally dependent on the client (So Woodhouse would not have control over this) producing even possibly more latency (most likely 1second+) for the droid to open up a ftp connection, and the server to send this to the phone. The file downloaded. (take note after uploaded from computer client) And to put the file to use :
This is the easy part.
But it could take up to +1 second to render each player on a map.
Take note, the phone is already being bombarded by ftp connections from the server, which is in turn getting bombarded by the client.
I attatched a drawing of this system in action (as I perceive it)
Overall. This is unreliable. And too much work to even be useful. The amount of successful connections that will make it through the whole chain is kinda very unstable.
For instance only about 1 in 3 connections sent will most likely go through completely successfully depending on the client (android phone)'s speed and internet connection.
It'd basically be a dumb way to produce a radar. Why not just grab the information from your PC and put them on a winform. It's the same concept but not on mobile.
Why go through the trouble of sending it through a mass stream of client server client architecture when you can do it all on a winform..
Take note people this will not change the ban rate. There is still a program in the background reading from the game (hacking) and can be sigged. Banning you as easily as the average public hack.
This is my take on this discussion. I love your idea. It is fantastic, and I'd love to see it. But I'd like to see it done rather then use it myself. As this would be pretty freaking cool to see stability across the line that wide.
All wrapped up :
Constantly sending, receiving, and reading is
LAGGY
If this was to come into success. This would be your DayZ experience :
You are in Elektro. You start this program. Immidiatley your PC will start to lag a bit (the initial FTP connections are beginning to open and connect to the server). But it's not very noticeable if even noticeable at all. You get the first pictures to your Android Phone within per say 3 seconds. You see there is a guy in the firestation base in Elektro. You're in the church. 3 Seconds later and a framerate drop of at least 10 frames. (10 more if your using fraps to record a trailer for this). You receive your second picture. He is now moved 15 meters out of it towards the church. You are blindsided because the next image has not synced yet. This one does not make it. You receive your next image 6 seconds later due to a dropped packet by the server being bombarded still by client connections. He has spotted you. And you don't know where you are, you're just sitting there, one arm on the keyboard, pinky on the mouse. Right hand in the air holding your phone to the sky hoping to receive the next image on your phone. Bikes flying in every direction. A sniper 600 meters away about to fire a shot. Little did he know you already knew he's there, well, at-least 6 seconds ago. Guy running from the firestation towards you. Framerate drop. Freshspawn. Rick Roll music starts to play from a naked man running wild. Forearm now taking control of the keyboard, both hands to the air, stretching as far as you can to the sky. You hear a sound, a glimmer of hope. You look to your phone.
Boom. You get it.
Not the image.
A bullet to your head. 
Originally Posted by Woodhouse
