I can't actually get my characters to move at *all*, except by clicking on an item that is too far away for them to reach from where they are standing. If I click somewhere I just get the mouse cursor changing into some sort of "can't click there" symbol - VERY frustrating.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On investigation, the problem seems to be in src/render/map.cpp, method "getMapXYZAtScreenXY()". It's always setting cursorMapX/Y/Z to 601/601/0 respectively unless I'm clicking on an object. I guess this means it's not detecting collision with the ground? Will investigate further.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That method returns 601/601/0 if it can't find an xyz location. (601 is outside the map size, this is an error condition.) I think the reason for this, is that the opengl call used is not supported by the video card. :-(
If you can figure out another way to do this, I'd be happy to include it!
Thanks,
--Gabor
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I was slightly mistaken about what was going wrong. I have a (very new) intel G33 graphics chipset and was using a Mesa snapshot in order to be able to use it. That method does return 601/601/0 but the code in scourgehandler.cpp adjusts for that by calling map->getCursorFlatMapX() and Y() - it was these which was really going wrong. I eventually tracked it down to render/Map.cpp which uses getMapXYAtScreenXY() to set cursorFlatMapX and cursorFlatMapY values after drawing. Looking at the code for that, I couldn't see anything wrong, but the result of the glUnProject call was bizarre. It turns out it was a Mesa problem; I pulled the latest Mesa from their git tree and now it all works fine.
So, probably just a problem with ATI cards / OpenGL implementation.
Sorry for the false info,
Davin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1404243
Same problem with me.
Logged In: YES
user_id=264806
Originator: NO
I was finally able to reproduce this on an ati card. I'll see what I can do...
Logged In: NO
I can't actually get my characters to move at *all*, except by clicking on an item that is too far away for them to reach from where they are standing. If I click somewhere I just get the mouse cursor changing into some sort of "can't click there" symbol - VERY frustrating.
Logged In: YES
user_id=1892044
Originator: NO
On investigation, the problem seems to be in src/render/map.cpp, method "getMapXYZAtScreenXY()". It's always setting cursorMapX/Y/Z to 601/601/0 respectively unless I'm clicking on an object. I guess this means it's not detecting collision with the ground? Will investigate further.
Logged In: YES
user_id=264806
Originator: NO
That method returns 601/601/0 if it can't find an xyz location. (601 is outside the map size, this is an error condition.) I think the reason for this, is that the opengl call used is not supported by the video card. :-(
If you can figure out another way to do this, I'd be happy to include it!
Thanks,
--Gabor
Logged In: YES
user_id=1892044
Originator: NO
Ok, I was slightly mistaken about what was going wrong. I have a (very new) intel G33 graphics chipset and was using a Mesa snapshot in order to be able to use it. That method does return 601/601/0 but the code in scourgehandler.cpp adjusts for that by calling map->getCursorFlatMapX() and Y() - it was these which was really going wrong. I eventually tracked it down to render/Map.cpp which uses getMapXYAtScreenXY() to set cursorFlatMapX and cursorFlatMapY values after drawing. Looking at the code for that, I couldn't see anything wrong, but the result of the glUnProject call was bizarre. It turns out it was a Mesa problem; I pulled the latest Mesa from their git tree and now it all works fine.
So, probably just a problem with ATI cards / OpenGL implementation.
Sorry for the false info,
Davin
Logged In: NO
Great thanks, it's good to know there's a solution to this problem.