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

[1.4.7][CC 1.481] Monitor text coords don't match monitor_touch

Started by Pyrodogg, 01 February 2013 - 02:12 PM
Pyrodogg #1
Posted 01 February 2013 - 03:12 PM
I have a program, basically Direwolf20's recent 'button' code. It types out a few characters with a background colors in a partial grid pattern on an advanced monitor. The computer then waits for monitor_touch events and prints the coordinates of the touch to the monitor on the left.

http://pasteboard.co/2Jj5NA2g.png

In the photo, the crosshair on the "5" is exactly where I clicked. The "5" was printed using m.setCursorPos(2,2) m.write("5") with the default text scale.

The touch coordinates of this click are reported as 1,2 even though the touch is well over 30% into the second text column.

Based on the information in the wiki, the monitor_touch event is supposed to report the coords in "screen characters".

This mismatch is very frustrating when trying to generate an interactive button display. If I print a character at 2,2 I would expect the entire position that character takes up to report the same coordinate system from monitor_touch. As it is right now, that click wouldn't activate my "5" button since it's only supposed to exist in 2,2. And I can't have it listen for 1,2 because that's supposed to be empty (it also overlaps the bottom of the "1" box).

This expectation is based on the information on the ComputerCraft wiki (as official as documentation gets) so I'm assuming it's an error. If so, please fix. If not, please add significant clarification to what "screen characters" are for a coordinate system reported by monitor_touch.
theoriginalbit #2
Posted 01 February 2013 - 03:24 PM
I have never had any issues with monitor_touch events… clearly your running the Direwolf20 mod pack. Whats the code your using? This is the code I would use


local mon = peripheral.wrap("left")
term.redirect(mon)

while true do
  local event, side, x, y = os.pullEvent()
  if event == "monitor_touch" then
    term.setCursorPos(1,1)
    term.clear()
    print(x..":"..y)
  end
end

This for me in the dw20 pack when clicking on 2,2 yields 2,2
Edited on 01 February 2013 - 02:29 PM
Pyrodogg #3
Posted 01 February 2013 - 03:29 PM
Yes, DW20 pack 5.0.1 Worked with it for a couple hours last night and got nowhere, It was driving me crazy. Here's the code, http://pastebin.com/Du05YaTy
theoriginalbit #4
Posted 01 February 2013 - 03:31 PM
man Direwolf over complicates things sometimes……….

EDIT: That code runs perfectly fine for me… no problems…
Pyrodogg #5
Posted 01 February 2013 - 03:33 PM
At one point I had also done a one off with the lua interpreter and got similar results.

m.setCursorPos(2,2)
m.write("5")
e,s,x,y = os.pullEvent("monitor_touch")
print(x..":"..y)
theoriginalbit #6
Posted 01 February 2013 - 03:36 PM
maybe try reinstalling the DW20 pack… just make a world backup…
Pyrodogg #7
Posted 01 February 2013 - 04:12 PM
Reinstalled client and loaded up a creative world. looks like it's working…. I forgot to mention that the original issue was in SMP. Currently in the process of reinstalling the server pack. Will report back, to confirm but already feeling a bit foolish
Pyrodogg #8
Posted 01 February 2013 - 04:39 PM
It does work in singleplayer.

Reinstalled the server, mods, config and all (from the DW20 modpack). Still happening on SMP, even when I'm using the exact same computercraft.zip (from working client) on server and client.

Chance that it's an SMP only issue?
Cranium #9
Posted 01 February 2013 - 06:38 PM
I have never had any issues with the monitor events.

Found your issue:

function main()
  mon.setTextColor(colors.white)
  mon.setBackgroundColor(colors.black)
  fillTable()
  while true do
	mon.clear()
	screen()
	local e,side,x,y = os.pullEvent("monitor_touch") --you are filtering out the first event being returned.
	print(x..":"..y)
	disp.clear()
	disp.setCursorPos(1,1)
	disp.write(x..":"..y)
	checkxy(x,y)
	sleep(.1)
  end
end
Since you are using a filter, it only returns the remaining events after it checks for that specific event of "monitor_touch". If you change it to not filter events out, then you don't have that same issue.

If you remove the filter, you get the correct result. No bug, just a missed event.

EDIT: Strike that. Did not do full testing. I did put the filter back in, and it still worked. But I still got the same result.
Edited on 01 February 2013 - 05:41 PM
Pyrodogg #10
Posted 02 February 2013 - 05:03 AM
Tonight I'll set up a separate server with only the latest CC mod and see what happens.
Pyrodogg #11
Posted 02 February 2013 - 05:52 PM
Brand new Forge server. New client instance generated with MultiMC.

MC 1.4.7
MinecraftForge v6.6.0.497 (Current Recommended build) triple checked same version on client and server.
CC 1.481
No additional mods

Server and client running on local machine. Started server, spawned computer and monitor, "pastebin get" previous code. Error still persists on server.

Monitor_touch event still reporting significant offset coordinates, not matching character grid at all.

Disconnect from server, start single player creative world. Same code, works as expected in singleplayer.

Here are the logs if they help.
Server: http://pastebin.com/6dRDrB2M
Client: http://pastebin.com/4XTecynu

If you want a zip of my test server or client instances they can also be provided.

PS Thanks to everyone who's been looking into this. I know the pain of errors not easily reproduced.
PixelToast #12
Posted 05 February 2013 - 04:53 AM
i havent noticed monitors returning all wrong coords
all i noticed was it being stingy when trying to press specific chars

it must be your code
Pyrodogg #13
Posted 05 February 2013 - 12:56 PM
The same code was tested in SSP, where it works, and in SMP where it doesn't.

How stingy is the behavior you're experiencing? You might be experiencing the same issue i'm reporting. If you right-click clearly within the bounding box of a single character does it report the correct position? I'm asserting that it is not in SMP.

In single player I can get as close as possible to the character bounding box on all sides and it reports the correct position. In SMP, it's reporting click positions well into 30% of the second column, as being in the first column. It's a significant difference from the experience in single player.
PixelToast #14
Posted 05 February 2013 - 01:24 PM
its only 1 char off vertically sometimes
Pyrodogg #15
Posted 05 February 2013 - 05:19 PM
Off by a character? So basically the same thing I'm talking about. Being off by a character makes single character buttons basically useless, frustrating at minimum. Especially when it works fine in SSP but not SMP.
tdawlings #16
Posted 05 February 2013 - 07:12 PM
I've had this problem as well. I made a key code script. Each button is three wide and three tall. Sometimes, when clicking on the outside ring of the buttons, I get this same problem. I haven't been able to fix it, but I had hypothesised that it could be a bug related to the text scale.
Skullblade #17
Posted 06 February 2013 - 12:54 AM
I have had a problem like this on the CCU with my monitor lock but I though that it was just my code…
Cloudy #18
Posted 06 February 2013 - 12:55 AM
Sample code would be great.
PixelToast #19
Posted 06 February 2013 - 02:34 AM
Off by a character? So basically the same thing I'm talking about. Being off by a character makes single character buttons basically useless, frustrating at minimum. Especially when it works fine in SSP but not SMP.
im talking about from 3-2 blocks away, when you get 0.5 blocks away its perfect
and you need to give us the code your using because its most likely a error in that code
Cranium #20
Posted 06 February 2013 - 03:46 AM
Sample code would be great.
The sample code was posted in post #3, Cloudy….
PixelToast #21
Posted 06 February 2013 - 06:26 AM
your using a weird method of detecting what buttons are pressed
>_>
i wouldnt do that
UltraHex #22
Posted 09 February 2013 - 05:04 PM
im talking about from 3-2 blocks away, when you get 0.5 blocks away its perfect
so perhaps when CC does it's math to figure out where you clicked, based on player position, rotation and look angle, the variables aren't accurate enough to produce the right result.