This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
JohnnyX's profile picture

Real time player tracking system

Started by JohnnyX, 17 July 2013 - 01:29 AM
JohnnyX #1
Posted 17 July 2013 - 03:29 AM
I want to make a program that by using ccsensors it will print the location of players on a big monitor. I am using FTB ultimate so they are not included and I'm too lazy to add them so for now I am just asking if it is possible. I thought about placing many sensors and through rednet, the cords of the player and the player name would be sent to a computer and that computer would print them on a monitor. Now, I would like the monitor to show an aerial view of the area(real time updating image) and the coords would be noted with colors to show where on the area each player is. Could something like that be done? Can a monitor print an image and update it? My way of doing this: I would add an image on the computer and depending on the coords and the player name received it would print on a temp image (copy of the first) and that image would be projected since pixels cannot be drawn on a monitor. If not an image, maybe ASCII like dwarf fortress?
ZagKalidor #2
Posted 17 July 2013 - 08:40 AM
You can do that, but not with (what i understand what you mean with) images. You will have to get the sensors data with the x,y,z positions, and calculate them to a grid to show it on a monitor, or to put it into a table to send it to another computer where it is displayed. Note, that the proximity sensor card has a range of 28 blocks to all sides, (mark4 version) it gives you a field of 56 x 56 blocks with the sensor in the middle. Unfortunately this will just give a "look" at the nearby environment. Detecting a wider field of action, you would need an array of sensors, all connected to a computer, sending tables to the "master" computer and display it. You could check for "players" and locate them in several sectors. Due to minecraft ticks, it will maybe need more time to calculate all this array data, so it will be not that "realtime" as the word says. But thats a part that mike moo now whants to change, beeing independent to minecraft ticks.
ZagKalidor #3
Posted 17 July 2013 - 08:53 AM
You could also run into a limitation by monitor sizes. Depending on the size of your sensor array it may have less cursor positions than you need, but thats a matter of your math, displaying all the data. Worst case scenario for me would be, that every sensor in the area would have just one cursor position at your "big" host-monitor. But that will of course be sufficient for your task, it will show you, which players are in which sectors. But think of the size of that sensor array - it will be very enormous indeed. I think it will be a "the player was in that sector" because he is long gone…
ZagKalidor #4
Posted 17 July 2013 - 09:08 AM
Sorry but its me again, this issue makes me going with it a little.

Maybe it is not necessary to calculate this data onto a grid of positions. It would be enough to locate player-x at sensor-y. This would speed up the whole thing a litle due to reduced data. Next problem would be the limited rednet-send range that is again limited during a thunderstorm. This would take a lot of remote computers, just to bring the data along.

Maybe you better use the console chat "hey-where are you". Or you run into a lifetime project…
(That was a joke haha)
KaoS #5
Posted 17 July 2013 - 09:15 AM
Please avoid multiposting. Just edit your previous post.

I have already done this before, I used ccLights (the original one, not sure if ccLights2 is out yet). It is quite easy actually, updating the map every time you change your base is tedious though
JohnnyX #6
Posted 17 July 2013 - 09:23 AM
You can do that, but not with (what i understand what you mean with) images.
When I say images I mean the kind that in-game paint program produces, and It would work by having a basic image that is the aerial view of a certain grid and constantly updating it by adding pixels to where the players are. Would that specifically work?
EDIT: Also, by using the same pixel adding method, would I be able to add crosshais with the players' pixels on the middle. When I say crosshairs I mean something like this:

but of course on an aerial view.
ZagKalidor #7
Posted 17 July 2013 - 09:46 AM
My post was useless due to your edit

Never looked into the paint prog for much but i think it is nearly as pixeled as a standard monitor. So your crosshair would become a "blockhair".

But for overwriting an existing picture - dont know, im gonna try out.
ZagKalidor #8
Posted 17 July 2013 - 10:13 AM
tried out, it is possible to edit an existing paint picture, you just need to edit the picture like a text file, but as i said, there is no benefit to a standard monitor display. it is on the contrary just like the normal terminal display without a wrapped monitor. Using a wrapped monitor with a increased size gives you lot more opportunities. But you could write a file, that is adjusted to a big-wrapped monitor and then edit and redisplay it.

But i dont get the sense of that all

You'll have to:

get data
paint picture
read picture
display to monitor

you could just :

get data
display to monitor
KaoS #9
Posted 17 July 2013 - 10:16 AM
Easier still is to just use my Layer API (it's on my utils post in my sig). Open the paint program on one layer and just generate a crosshair on a higher layer. That way you can do whatever you want to your crosshair without causing any damage to the paint image
ZagKalidor #10
Posted 17 July 2013 - 10:26 AM
ok that would be

get data
get picture
make layer
overlay layer to picture
display picture with layer

instead of

get data
show data
ZagKalidor #11
Posted 17 July 2013 - 10:33 AM
question to JonnyX,

is the task here to overwrite a paint picture and to bring the data to a monitor, or is it to sensor players and to display them???

I could fly to new york, charter a plane, take a picture of the skyline in aerial view, fly home, take the picture, and look at it
or I could use google earth…
KaoS #12
Posted 17 July 2013 - 10:37 AM
he wants to map his base and create a paint image of it, then sense players and show their positions on the map with a monitor.

Please stop with the double posts
JohnnyX #13
Posted 17 July 2013 - 10:53 AM
question to JonnyX,

is the task here to overwrite a paint picture and to bring the data to a monitor, or is it to sensor players and to display them???
I would prefer to use 2 pics where the first one is the area displayed as in an in-game map and the second one would be a temporary copy of the first with the players and the crosshair on it. I just want the original one for reference.
KaoS #14
Posted 17 July 2013 - 10:55 AM
re-creating the entire image every time you update it will be very inefficient. Please consider just drawing the image and then drawing the players over it
ZagKalidor #15
Posted 17 July 2013 - 10:58 AM
ok ok, its possible, but you dont need the paint program for that.

B.t.w. if i edit an older post, that is read by everyone and i come to a new thougth and edit it into an older post, no one will read it because no one reads older posts in case it could be edited. So i make a new post, that comes to the end of that list and everybody will read it then. What is so bad with double posts? I thought this is a forum, where posts are welcome.
theoriginalbit #16
Posted 17 July 2013 - 11:00 AM
B.t.w. if i edit an older post, that is read by everyone and i come to a new thougth and edit it into an older post, no one will read it because no one reads older posts in case it could be edited.
The thread is shown to them as unread (blue). So when you're the last poster and you edit, they will clearly see your edit. especially if you mark it with EDIT:
KaoS #17
Posted 17 July 2013 - 11:02 AM
Thank you for the reply. When I say double posting I mean entering more than one post before anyone else has replied to the thread, you could edit your last post and it will still be at the bottom where it will be read (it is hard to miss as it is just above the reply box). This is common forum courtesy. posts are of course welcome, just avoid taking up more space if possible please
JohnnyX #18
Posted 17 July 2013 - 11:04 AM
re-creating the entire image every time you update it will be very inefficient. Please consider just drawing the image and then drawing the players over it

Yeah but If a player moves then the machine will have to recreate the image of the crosshair with the pixel in the middle because if that does not happen it will leave a trail.
KaoS #19
Posted 17 July 2013 - 11:06 AM
not if you use my layer API :)/> it has an entirely separate term for each layer. You can clear/change individual layers without effecting the others at all
JohnnyX #20
Posted 17 July 2013 - 11:09 AM
not if you use my layer API :)/> it has an entirely separate term for each layer. You can clear/change individual layers without effecting the others at all
I do not like installing more API's. But oh well, if it does the job more efficiently then I guess I will give it a go. I just dont like to use other people's stuff since I like making my own programs :)/>
KaoS #21
Posted 17 July 2013 - 11:14 AM
If you use my API I do not require credit or anything so don't stress. However if you would prefer to do things your way I can help you to code it so it renders the original image, then renders the players and every time the players move it re-renders the part of the image that they used to be at. I have never used nPaint before but I'm happy to learn it's file format
ZagKalidor #22
Posted 17 July 2013 - 11:20 AM
put your picture inside a table. Every entry inside the table contains just the colordata of the pixel. Next colordata means next pixel. Maybe you paint it with the paint prog and then read the data into that table.

tablepicture = {1, 2, 3, 2, 2, 2, 2, 2, 2, 1, 5, 5, 5 and so on

loop
display table
display sensor data
fine
KaoS #23
Posted 17 July 2013 - 11:24 AM
lol that isn't a double post. That is just a post. I was referring to when you had 2-3 posts in a row. This is fine
JohnnyX #24
Posted 17 July 2013 - 11:36 AM
If you use my API I do not require credit or anything so don't stress. However if you would prefer to do things your way I can help you to code it so it renders the original image, then renders the players and every time the players move it re-renders the part of the image that they used to be at. I have never used nPaint before but I'm happy to learn it's file format
If so then when FTB gets updated to 1.6 i'll ask you :)/>
P.S. Any idea when it is comming out?
ZagKalidor #25
Posted 17 July 2013 - 11:41 AM
using layers would be more efficient, you just have to display the picture once, not again everytime inside the sensor-data loop to avoid the trails…

but its also possible without a 3rd party prog.
KaoS #26
Posted 17 July 2013 - 12:11 PM
If so then when FTB gets updated to 1.6 i'll tell ask you :)/>
P.S. Any idea when it is comming out?
I don't FTB anymore so unfortunately no. I hope they get to 1.6 soon though

but its also possible without a 3rd party prog.
very true