Hey All, I'd just like to share my attempt as well. However, I do not wish to release my work yet as I feel it is of inadequate quality. Hopefully someone can find a way to improve on it. I'm not sure how it would fare against a movement grid, as it uses the Cosine Rule to calculate position. Please note this method was designed for intended use for top down shooters.
It's set up as follows:
1) 2 Pings (Dummy units using protoss beacon model) with multiple phases (90) are shown/hidden in an alternating manner from the bottom left (Point A) and bottom right (Point B) corners of the map.
2) Depending on the phase that hits the cursor on the left and right, We get a measurement, The radius from the bottom left/right of the map.
If not for problem 1, The system seems to be able to pinpoint position quite accurately. I've attached a few supportive screenshots if anyone is interested to grasp an idea of how this method is used.
3) The distance between the points can be found through in game measurements by checking how many phases it takes to hit the bottom right from the bottom left.
Knowing the radius of A and B to the cursor, and C the distance in between points in 'phase' units. Position can be calculated with the Cos Rule.
Important Triggers/Functions:
1) Show/Hide Pings</n>
2) Cursor Hit test to detect if a ping is hit.</n>
3) Call Function to calculate position.</n>
4) Periodic trigger that moves unit to position of cursor.</n>
Few issues I'm currently facing is:
1) Code is too fast: The radius overshoots before it detects as the cursor gets further away from the ping(?)
2) Code too slow with Waits inside it: Calculations need to be done at at least 30-60 times a second to ensure the game always knows the position of the mouse.
If not for problem 1, The system seems to be able to pinpoint position very accurately. I've attached a few supportive screenshots if anyone is interested to grasp an idea of how this method is used.
A few things I've tried and don't work.</n>
1) Having only 1 ping unit at each point and having it grow. It simply grows too fast and the radius is always detected as its maximum possible value.
2) Having waits. Even a 0.0 second wait translates to 1/32 * 90 Iterations, which is a noticable delay, So waits had to be avoided overall.
3) I wanted to try multithreading to ensure the hit event fires properly, but couldn't find a way to do it, with either galaxy or GUI.
4) Leaving the dummy units shown all the time. Well, they overlap.. so whats underneath can't be hit.
IMHO:
Pros of this method:
Would probably allow perfect pinpointing of cursor regardless of it's position (Rather than constraining it to a grid)
Easier to move dummy units around as they are all cluttered at the same point (Rather than having to recalculate new points every time the player moves their camera) Thus making it less intensive on processor calculation.
Able to track fast mouse movement.
Cons of this method:
Currently coded with a locked screen, Didn't want to try movement until i perfected it with a locked screen.
Dummy unit overlapping issues
Accuracy drops as distance increases from pings.
I'll post a video of this in action when I find the time. For now the images below are the best I have to demonstrate this. Pictures 1 and 2 were able to calculate properly, Picture 3 was not (Look at highlight circles, it gives an idea of where the cursor is)
If anyone would like to know more about this method, feel free to contact me.
With regards to zoning, I believe there is a function which returns the point that the players camera is facing. I had the idea of using a timed event that locates this point every 0.0x seconds then use it to ensure the dummy units are always in the zone that the cursor is in. I'm currently working with a locked camera though while calibrating parameters. Will try to have an alpha version of my tracking method up soon. It might spark some inspiration and ideas to how we might be able to reliably track our mouse cursor.
Regarding your method, Rather than recreating units whenever the player moves the screen, any idea if moving the units would work better instead? As you scroll to the right, the leftmost column shifts to the right and so on. Either that or a moving matrix of invisible units, that centers about the point of the players camera.
3. Make a ring of 15-20 dummy units around your mouse cursor (or a unit
directly under the mouse cursor for initialization) but make sure you
calculate how many dummy units you need to make such that there is no
gaps in the ring. rememeber circle geometry from high school, lol.
I must share that I've tried this before (wasted a few days on it), The highlight event doesn't trigger fast enough if your mouse sensitivity is too high, regardless of whether there are gaps. What happens is that before the second ring can form around the highlighted unit, your cursor would already way out of range for a hit test around the new ring. Whatever the solution is, we apparently require something that at least covers up the entire screen at the location a player is looking at. This way it will still be able to catch the cursor if it moves out of range.
The points that it will be able to track are also quite limited if the circle is too big, and it will oscillate like mad if the circle is too small (because the hit test keeps detecting as the circles move back and forth)
It's not very clear to me in the videos, Are clicks required to detect the position? or is the hover position returned immediately when my mouse hovers over it?
I'm actually working on a mouse tracking system too, but with a distinct method from this one. Unfortunately it's not working out too well right at the moment. I was reluctant to code a tracking system via this method due to concerns that it would perform poorly with lower end pc specs due to the large number of dummy units required, but thats just me.
Either ways, good job getting this asset up and running. I'm sure it'll be a useful tool for many modders. If all else fails in my attempt, at least I know theres somewhere to fall back to.
Hey All, I'd just like to share my attempt as well. However, I do not wish to release my work yet as I feel it is of inadequate quality. Hopefully someone can find a way to improve on it. I'm not sure how it would fare against a movement grid, as it uses the Cosine Rule to calculate position. Please note this method was designed for intended use for top down shooters.
It's set up as follows:
Knowing the radius of A and B to the cursor, and C the distance in between points in 'phase' units. Position can be calculated with the Cos Rule.
Important Triggers/Functions:
Few issues I'm currently facing is:
If not for problem 1, The system seems to be able to pinpoint position very accurately. I've attached a few supportive screenshots if anyone is interested to grasp an idea of how this method is used.
A few things I've tried and don't work.</n>
IMHO: Pros of this method:
Cons of this method:
I'll post a video of this in action when I find the time. For now the images below are the best I have to demonstrate this. Pictures 1 and 2 were able to calculate properly, Picture 3 was not (Look at highlight circles, it gives an idea of where the cursor is)
If anyone would like to know more about this method, feel free to contact me.
@Skittles17: Go
I don't mean to be a killjoy.. but http://forums.sc2mapster.com/resources/trigger-libraries/11481-library-realtime-mouse-tracking-system/?page=2#p24 But I've tried and tested that before, and it doesn't work well. For the reasons stated in the linked post.
@OneTwoSC: Go
With regards to zoning, I believe there is a function which returns the point that the players camera is facing. I had the idea of using a timed event that locates this point every 0.0x seconds then use it to ensure the dummy units are always in the zone that the cursor is in. I'm currently working with a locked camera though while calibrating parameters. Will try to have an alpha version of my tracking method up soon. It might spark some inspiration and ideas to how we might be able to reliably track our mouse cursor.
Regarding your method, Rather than recreating units whenever the player moves the screen, any idea if moving the units would work better instead? As you scroll to the right, the leftmost column shifts to the right and so on. Either that or a moving matrix of invisible units, that centers about the point of the players camera.
I must share that I've tried this before (wasted a few days on it), The highlight event doesn't trigger fast enough if your mouse sensitivity is too high, regardless of whether there are gaps. What happens is that before the second ring can form around the highlighted unit, your cursor would already way out of range for a hit test around the new ring. Whatever the solution is, we apparently require something that at least covers up the entire screen at the location a player is looking at. This way it will still be able to catch the cursor if it moves out of range.
The points that it will be able to track are also quite limited if the circle is too big, and it will oscillate like mad if the circle is too small (because the hit test keeps detecting as the circles move back and forth)
It's not very clear to me in the videos, Are clicks required to detect the position? or is the hover position returned immediately when my mouse hovers over it?
I'm actually working on a mouse tracking system too, but with a distinct method from this one. Unfortunately it's not working out too well right at the moment. I was reluctant to code a tracking system via this method due to concerns that it would perform poorly with lower end pc specs due to the large number of dummy units required, but thats just me.
Either ways, good job getting this asset up and running. I'm sure it'll be a useful tool for many modders. If all else fails in my attempt, at least I know theres somewhere to fall back to.