it didnt say anything at all, it didnt time out, it seems like it hit a unit cap. Thats when i decided to try buildings, and it got about 2x as far as the units, but only filled up about 20 colums. And no i did not try with any lower precision due to it not being effective for the purpose i was using it for. I managed to get it to work by spawning units in a region and having the units do the same commands as my initial unit (that has the diablo type movement). Only problem im running into is if i try and go in a straight line, the cursor stays with the unit that is moving, thus the unit stops moving until i move my cursor over to another unit. Have any ideas to fix it? I was thinking about putting in some triggers to change the speeds of the units. Going from like 1 speed for 1 second, and then 2 speed for 1 second, and 1 speed for 1 second. And then setting the main unit speed at 1.5. Or something like that, i havnt tested it yet though.
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)
Ideal: zoning your map and tracking which zone a player is in and creating drones in all neighbouring zones and the current zone (with a small delay between each create unit so that you dont make 500 units at once; rather, 1 every 0.01 sec or something).
It still sucks for now. 1.0 precision is still good enough for things like diablo movement. Its the best robust way to have all unit ready than creating/destroy or hide/unhide them. They always take time so it will lag (not even talking about abrupt camera position change). Better precision can be achieved with un-traditional map llike minigames using mouse where camera is locked or the trackable region is limited. This is still very useful. I honestly understand why blizzard dont want to track mouse position in the first place. Even the camera position is delayed by a good second
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 did a test attaching a region to my unit and creating/killing the units in it to move with in that region, but sadly its true it takes a way bigger toll on performance i even did the math on how many units it would take to fill my region and putting the max amount of units for player X and set it to 1.5 that ammount being the max amount of units on screen. so even with it only having to maintain 45(i used supply depots lowered) inside my region while killing the others outside of it, the lag was still terrible. i think maybe even zoning them might cause problems but i do think it would be better than doing the attached region trick, and i hopefully still get to make my rpg as big as i really want it. hopefully someone comes up with a fix for it =D
just so everyone knows it DOES spawn enough to fill 256x256 no lag but ofcourse it was bare map but using drones or supplys lowerd made the trigger fail so..
you may should use a square with the z scale 0 or something very low
in wc3 the selection/collision box or whatever is also scaled and you'll select allways the right unit no matter what the camera settings are
you may should use a square with the z scale 0 or something very low in wc3 the selection/collision box or whatever is also scaled and you'll select allways the right unit no matter what the camera settings are
If someone in modeling could make 1 simple model for that, i would glad to use, just simple place them in the model (part 2) of my guide, scaling may have to be manually changed however. For now its the simplest model that can be found for the game's assets.
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 could try this, however as I said before, even the function return camera position is delayed by a good second, not really viable when camera is abruptly changed
Hey, I was just thinking about my top down shooter and remember seeing this yesterday... and well, why don't you just make 8 boxes per player? Mouse enters one of the boxes and the other boxes move around where that box was. So the boxes constantly move around the mouse. Get what I'm saying? That would greatly reduce any lag issues this may have.
Gawd, you're such a kill joy. Xd lol, least I didn't waste my time with it. Thanks. (coming from someone who is using a mouse that still uses a ball. lol)
Hopefully Blizzard will add a MouseGetX(int player) function in some later release. There is absolutely no reason why this should not be added. Stuff like CameraForceMouseRelative already causes the mouse position to be tracked, the only problem is that the camera moves too. The best solution I have found so far is to set the mouse sensitivity very low so that the camera doesn't move much after using CameraForceMouseRelative. Then, I manually recenter the camera and use how much the camera move to compute the mouse movement. This is works okay at low speeds, but if your centered position moves quickly, then performance degrades. Honestly, it would be so simple to have a trigger do the exact same thing as CameraForceMouseRelative, just not have the camera move and update some value instead.
Hey, I was just thinking about my top down shooter and remember seeing this yesterday... and well, why don't you just make 8 boxes per player? Mouse enters one of the boxes and the other boxes move around where that box was. So the boxes constantly move around the mouse. Get what I'm saying? That would greatly reduce any lag issues this may have.
A solution like that would fail as soon as there was a discontinuity in mouse movement (e.g. the field of view changes abruptly or even slowly with the mouse over a UI element that prevents highlighting). If your map is constrained such that these events can't happen, then certainly it seems like it would be better to employ a strategy like that.
I thought I'd throw in what I learned from having created a system like this before (Although I didn't realize it was a large enough solution of bother releasing here). I used cubes with a low Z scale for my highlight event units and set their transparency. In a Diablo style game the camera will be locked onto a unit which we can track the x,y of, so as long as the number of players does not become too large it would be entirely possible to only create enough boxes to fill the player's screen and to move them as the main character moves. Then again, I've mostly been coding for single player where the number of cubes needed is only enough for the one player.
New version of the system is up. Now it will firstly spawn unit at camera position and move it when camera moves. Guaranteed to reduce lag and available on 256x256 map
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.
I was doing some tests inspired by the highlight system for a project of my own and discovered that creating the detection units first in a corner, then moving them dynamically as the function calls to the camera position, was better on performance then creating/destroying the units. Not sure which method you use, but thought you might want to know.
EDIT: What I did was use the square shape model, give it a 1x1 placement footprint, and place in a X by Y grid around the camera target, after converting the XY coords of the camera target to nearest integer, so the grid would always be formed perfectly without overlap issues.
it didnt say anything at all, it didnt time out, it seems like it hit a unit cap. Thats when i decided to try buildings, and it got about 2x as far as the units, but only filled up about 20 colums. And no i did not try with any lower precision due to it not being effective for the purpose i was using it for. I managed to get it to work by spawning units in a region and having the units do the same commands as my initial unit (that has the diablo type movement). Only problem im running into is if i try and go in a straight line, the cursor stays with the unit that is moving, thus the unit stops moving until i move my cursor over to another unit. Have any ideas to fix it? I was thinking about putting in some triggers to change the speeds of the units. Going from like 1 speed for 1 second, and then 2 speed for 1 second, and 1 speed for 1 second. And then setting the main unit speed at 1.5. Or something like that, i havnt tested it yet though.
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)
@FuzzYD: Go
Ideal: zoning your map and tracking which zone a player is in and creating drones in all neighbouring zones and the current zone (with a small delay between each create unit so that you dont make 500 units at once; rather, 1 every 0.01 sec or something).
@OneTwoSC: Go
It still sucks for now. 1.0 precision is still good enough for things like diablo movement. Its the best robust way to have all unit ready than creating/destroy or hide/unhide them. They always take time so it will lag (not even talking about abrupt camera position change). Better precision can be achieved with un-traditional map llike minigames using mouse where camera is locked or the trackable region is limited. This is still very useful. I honestly understand why blizzard dont want to track mouse position in the first place. Even the camera position is delayed by a good second
@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.
@FuzzYD: Go
I guess there's multiple ways... got to see what works and what doesn't lag :D
i did a test attaching a region to my unit and creating/killing the units in it to move with in that region, but sadly its true it takes a way bigger toll on performance i even did the math on how many units it would take to fill my region and putting the max amount of units for player X and set it to 1.5 that ammount being the max amount of units on screen. so even with it only having to maintain 45(i used supply depots lowered) inside my region while killing the others outside of it, the lag was still terrible. i think maybe even zoning them might cause problems but i do think it would be better than doing the attached region trick, and i hopefully still get to make my rpg as big as i really want it. hopefully someone comes up with a fix for it =D
just so everyone knows it DOES spawn enough to fill 256x256 no lag but ofcourse it was bare map but using drones or supplys lowerd made the trigger fail so..
@johney7289: Go
Try using show/hide instead of create/remove.
(Let the init trigger fill the map and hide units in the "unused" zones.)
you may should use a square with the z scale 0 or something very low in wc3 the selection/collision box or whatever is also scaled and you'll select allways the right unit no matter what the camera settings are
If someone in modeling could make 1 simple model for that, i would glad to use, just simple place them in the model (part 2) of my guide, scaling may have to be manually changed however. For now its the simplest model that can be found for the game's assets.
I could try this, however as I said before, even the function return camera position is delayed by a good second, not really viable when camera is abruptly changed
@progammer: Go
Hey, I was just thinking about my top down shooter and remember seeing this yesterday... and well, why don't you just make 8 boxes per player? Mouse enters one of the boxes and the other boxes move around where that box was. So the boxes constantly move around the mouse. Get what I'm saying? That would greatly reduce any lag issues this may have.
@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.
@FuzzYD: Go
Gawd, you're such a kill joy. Xd lol, least I didn't waste my time with it. Thanks. (coming from someone who is using a mouse that still uses a ball. lol)
Hopefully Blizzard will add a MouseGetX(int player) function in some later release. There is absolutely no reason why this should not be added. Stuff like CameraForceMouseRelative already causes the mouse position to be tracked, the only problem is that the camera moves too. The best solution I have found so far is to set the mouse sensitivity very low so that the camera doesn't move much after using CameraForceMouseRelative. Then, I manually recenter the camera and use how much the camera move to compute the mouse movement. This is works okay at low speeds, but if your centered position moves quickly, then performance degrades. Honestly, it would be so simple to have a trigger do the exact same thing as CameraForceMouseRelative, just not have the camera move and update some value instead.
A solution like that would fail as soon as there was a discontinuity in mouse movement (e.g. the field of view changes abruptly or even slowly with the mouse over a UI element that prevents highlighting). If your map is constrained such that these events can't happen, then certainly it seems like it would be better to employ a strategy like that.
I thought I'd throw in what I learned from having created a system like this before (Although I didn't realize it was a large enough solution of bother releasing here). I used cubes with a low Z scale for my highlight event units and set their transparency. In a Diablo style game the camera will be locked onto a unit which we can track the x,y of, so as long as the number of players does not become too large it would be entirely possible to only create enough boxes to fill the player's screen and to move them as the main character moves. Then again, I've mostly been coding for single player where the number of cubes needed is only enough for the one player.
Just my 2 cents.
New version of the system is up. Now it will firstly spawn unit at camera position and move it when camera moves. Guaranteed to reduce lag and available on 256x256 map
Check the 1st post for any info
http://forums.sc2mapster.com/resources/trigger-libraries/11481-library-realtime-mouse-tracking-system/?post=1
Need testing on battlenet/ multiple player/ camera
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.
Progammer,
I was doing some tests inspired by the highlight system for a project of my own and discovered that creating the detection units first in a corner, then moving them dynamically as the function calls to the camera position, was better on performance then creating/destroying the units. Not sure which method you use, but thought you might want to know.
EDIT: What I did was use the square shape model, give it a 1x1 placement footprint, and place in a X by Y grid around the camera target, after converting the XY coords of the camera target to nearest integer, so the grid would always be formed perfectly without overlap issues.