I've tested a similar method I'm using in my current project and so far from testing, using particular unit parameters allows the system to function very well even on bnet with multiple users (only tested up to 4, and we all have high performance towers).
I can't share the method or map files as of yet because they are a core component of our "game." But I can tell you that you should take another pass at the type of unit and its highlight-able area.
Sorry I can't be of more use to this concept at this time, but if you can't improve your system more by the time our map is ready for beta-release I'll try to release more details of the system were using.
Note, we had the units move instantly to a new position determined by our current camera position as in yours but with different parameters and an additional trigger to determine if a unit could not move to a particular area and if it was returned true, it would delete that unit and attempt to create an additional unit at its missing point in a 1s time interval.
Either way, this is the best workaround I've seen besides our own and would actually work with a better precision than ours on its higher settings, but it is rather performance intensive as is on bnet, but perfect for single play.
By all means use a square unit or such, if you're advanced enough, it can be easily changed in the library. (only the radius or z scale need to be touched. I dont want it to overwhelm newbie users. Also, i'm working on another ways of mouse detection so i'll leave it at that.
Ahhh. I apologize, I did not realize this system was intended for newer users. Anyway, this setup will still produce a very nice system and if it performs anything like the one we are currently using there should be very minimal lag in game and on bnet.
I plugged this into my map and it's working very well, even on bnet, although it's still testing.
One problem I had was, using big zones with on enter/on exit events can create too many threads if the camera is jumped into the middle of the zone, e.g., clicking on the mini-map. Even checking for a player-owned unit in the event condition didn't solve it. It still appears to be creating a thread for all the invisible units. You can deal with this by using the larger (less accurate) scale or make smaller zones.
Could you specify the problem ? new version no longer spawn by zone, but instead around a player's camera, 8 player looking at a same place can cause problem, but this could be fixed with some checking of camera target and remove unnecessary unit. Other than that, it works perfectly, changing camera position like clicking the minimap will cause unit to update their position
Guess I didn't explain that very well. When you move the camera into a region that has an on-enter event, the game starts a thread for each of the dummy units that get moved into the region. If too many get moved into the region at once, such as clicking in the center of a large region, you will quickly hit the thread limit.
I tried adding a condition to the on-enter event for the region to only check for units that are owned by a player, but it still had the error. Using fewer/smaller regions with the on-enter event solved the issue for me.
Oh thanks for the explain. Events any unit enter region. I'm thinking the maximum thread is about 240. so low precision work fine, but yeah using unit will have such limitation, I will think about using actor if highlight event support actor, make sure your enter region does not have wait and filter them correctly might help
Hey programmer would it be possible to make your DUMMIES UNITS into "missiles" Generally most people are going to be filtering out missiles anyways..... That or they're just stupid.
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
Hey programmer would it be possible to make your DUMMIES UNITS into "missiles" Generally most people are going to be filtering out missiles anyways..... That or they're just stupid.
Feel free to set the dummy unit type to missile, it will still works but does nothing to improve performance.
Would it be possible to have 3 huge cubes follow the camera... when you highlight the one, it is moved away and 3 smaller ones exactly 1/3 its size move into its space? If one of those is highlighted, 3 smaller cube move into that one's space... 3 or 4 iterations would be very precise, but would it actually be easier on performance than just using tons of tiny cubes?
EDIT: Make that 4 cubes. Divide each cube in half on each (XY) axis. If you went for 5 levels of division, you could get precision equal to a 32x32 grid of (1024) cubes per player, but with 20 cubes per player instead.
Would it be possible to have 3 huge cubes follow the camera... when you highlight the one, it is moved away and 3 smaller ones exactly 1/3 its size move into its space? If one of those is highlighted, 3 smaller cube move into that one's space... 3 or 4 iterations would be very precise, but would it actually be easier on performance than just using tons of tiny cubes?
EDIT: Make that 4 cubes. Divide each cube in half on each (XY) axis. If you went for 5 levels of division, you could get precision equal to a 32x32 grid of (1024) cubes per player, but with 20 cubes per player instead.
This is a really smart idea IMO and would definitely reduce the lag of this library by a huge amount.
Not sure how that would work out, do you want to iterate 5 times per seconds or per 0.1s ? But anyway I would wait for blizzard's official support around Dec
Yeah, when you move into a new huge cube area the highlight event fires 5 times at once. Here's hoping for low network latency on Blizzard's implementation.
Progammer, I have found a problem. It seems that it will not work over empty space (fully lowered terrain.) I am working on a solution now so hopefully I will have something soon. I will post what I find.
Progammer, I have found a problem. It seems that it will not work over empty space (fully lowered terrain.) I am working on a solution now so hopefully I will have something soon. I will post what I find.
Why would you use this after Blizzard added the mouse moved event?
Why would you use this after Blizzard added the mouse moved event?
The mouse moved event creates undesirable network lag. Returning the mouse position using Blizzard's triggers also creates network lag. I need something to return a mouse position without causing this lag.
As to what I've found so far: The units do move correctly but for some reason they cannot be highlighted over space terrain. There is also a problem that happens because of collision that causes the units to shift their position when passing over a cliff. Additionally, if the coordinate system is initialized while the camera is near the edge of the map, some units will simply not be created, causing a gap.
Clever solution, thanks for sharing it with us in a such a pedagogical way :)
I've tested a similar method I'm using in my current project and so far from testing, using particular unit parameters allows the system to function very well even on bnet with multiple users (only tested up to 4, and we all have high performance towers).
I can't share the method or map files as of yet because they are a core component of our "game." But I can tell you that you should take another pass at the type of unit and its highlight-able area.
Sorry I can't be of more use to this concept at this time, but if you can't improve your system more by the time our map is ready for beta-release I'll try to release more details of the system were using.
Note, we had the units move instantly to a new position determined by our current camera position as in yours but with different parameters and an additional trigger to determine if a unit could not move to a particular area and if it was returned true, it would delete that unit and attempt to create an additional unit at its missing point in a 1s time interval.
Either way, this is the best workaround I've seen besides our own and would actually work with a better precision than ours on its higher settings, but it is rather performance intensive as is on bnet, but perfect for single play.
@GaelicGamer: Go
By all means use a square unit or such, if you're advanced enough, it can be easily changed in the library. (only the radius or z scale need to be touched. I dont want it to overwhelm newbie users. Also, i'm working on another ways of mouse detection so i'll leave it at that.
@progammer: Go
Ahhh. I apologize, I did not realize this system was intended for newer users. Anyway, this setup will still produce a very nice system and if it performs anything like the one we are currently using there should be very minimal lag in game and on bnet.
I plugged this into my map and it's working very well, even on bnet, although it's still testing.
One problem I had was, using big zones with on enter/on exit events can create too many threads if the camera is jumped into the middle of the zone, e.g., clicking on the mini-map. Even checking for a player-owned unit in the event condition didn't solve it. It still appears to be creating a thread for all the invisible units. You can deal with this by using the larger (less accurate) scale or make smaller zones.
@Magi66: Go
Could you specify the problem ? new version no longer spawn by zone, but instead around a player's camera, 8 player looking at a same place can cause problem, but this could be fixed with some checking of camera target and remove unnecessary unit. Other than that, it works perfectly, changing camera position like clicking the minimap will cause unit to update their position
@progammer: Go
Guess I didn't explain that very well. When you move the camera into a region that has an on-enter event, the game starts a thread for each of the dummy units that get moved into the region. If too many get moved into the region at once, such as clicking in the center of a large region, you will quickly hit the thread limit.
I tried adding a condition to the on-enter event for the region to only check for units that are owned by a player, but it still had the error. Using fewer/smaller regions with the on-enter event solved the issue for me.
@Magi66: Go
Oh thanks for the explain. Events any unit enter region. I'm thinking the maximum thread is about 240. so low precision work fine, but yeah using unit will have such limitation, I will think about using actor if highlight event support actor, make sure your enter region does not have wait and filter them correctly might help
@progammer: Go
Hey programmer would it be possible to make your DUMMIES UNITS into "missiles" Generally most people are going to be filtering out missiles anyways..... That or they're just stupid.
Check the first posts for update
Updates v1.2 :
- Used a square unit instead of circular. (more precise)
- Step 2 modified, no need to make new model, change Shadow Radius of ShapeCube to 0.0
- Model Name parameter removed. It is now the cube.
Feel free to set the dummy unit type to missile, it will still works but does nothing to improve performance.
Would it be possible to have 3 huge cubes follow the camera... when you highlight the one, it is moved away and 3 smaller ones exactly 1/3 its size move into its space? If one of those is highlighted, 3 smaller cube move into that one's space... 3 or 4 iterations would be very precise, but would it actually be easier on performance than just using tons of tiny cubes?
EDIT: Make that 4 cubes. Divide each cube in half on each (XY) axis. If you went for 5 levels of division, you could get precision equal to a 32x32 grid of (1024) cubes per player, but with 20 cubes per player instead.
This is a really smart idea IMO and would definitely reduce the lag of this library by a huge amount.
Not sure how that would work out, do you want to iterate 5 times per seconds or per 0.1s ? But anyway I would wait for blizzard's official support around Dec
Yeah, when you move into a new huge cube area the highlight event fires 5 times at once. Here's hoping for low network latency on Blizzard's implementation.
Progammer, I have found a problem. It seems that it will not work over empty space (fully lowered terrain.) I am working on a solution now so hopefully I will have something soon. I will post what I find.
Why would you use this after Blizzard added the mouse moved event?
The mouse moved event creates undesirable network lag. Returning the mouse position using Blizzard's triggers also creates network lag. I need something to return a mouse position without causing this lag.
As to what I've found so far: The units do move correctly but for some reason they cannot be highlighted over space terrain. There is also a problem that happens because of collision that causes the units to shift their position when passing over a cliff. Additionally, if the coordinate system is initialized while the camera is near the edge of the map, some units will simply not be created, causing a gap.