I recall Clamp being there, not sure about square root and trunc though, They seem to already be in the API docs so it might be possible they were already there, just that we overlooked them.
That does sound like it would work, but would I not need a periodic trigger in galaxy/gui to re-add the behavior each time? Is it possible to have a behavior with a periodic effect that occurs once every 0.01 seconds? If so, would this be a heavy load on the processor?
I currently have 2 triggers:
A: Unit Growth, Needs to grow from a scale of 100% to 7000% with increments of 100% (Currently uses a while loop, 70 iterations)
B: Hit Test
The issue faced is that the while loop in Trigger A seems to locks up the processor, preventing trigger B from performing it's actions until it's too late. The current workaround I have in mind is to have a behavior with a periodic effect (based off auto-turret) instead and to change Trigger A so it only scales once per periodic event firing off the behavior. Since the trigger would then only need to perform a few instructions (That is, scaling the unit up once), as opposed to an entire while loop, it should theoretically be much faster and still allow hit tests to fire on time.
Quote:
You can. My leveling system uses behaviors that have a 0 duration, and
are basically on the unit full time.
Almost forgot to ask, how did you accomplish this? Are you actually re-adding the behaviors? Or does it just somehow stay there and fire up whenever you check if the unit has a behavior?
That sound's like exactly what I'm looking for. Will test it out when i'm able.
Not quite what I'm looking for coronbale, but thats very informative, thanks for sharing that info.
What I actually intend to do is to have my unit grow in size whenever the effect occurs. Indefinitely until the unit is highlighted, then i remove the unit. Thus I need a behavior with a periodic effect. Can anyone tell me if I'm on the right track if i build my dummy behavior off auto-turret timed life? Because i'm not too sure if its possible to have timed life that never expires.
As some of you may be aware, the Auto Turret Timed Life behavior is able to fire periodic effects. I need to catch these events somehow and fire off a trigger.
I've searched the Wiki but maybe i overlooked something because I can't find such an event.
Either that or I would need to somehow catch the event that the timed life expires (but this would mean i have to keep readding the behavior which is really annoying.)
The question is, Is there a way to catch an event when a Unit comes under a specific effect?
If not, are there any workarounds to catching the event that a unit comes under a behavior or effect?
Even with top down, there is a problem with Z cylinder height messing up the calculations. So, it is certain that must be taken into consideration, After all, what good is a system if it can't be used for every application right? xD Do feel free to come up with your implementation too. I may take awhile to fix up. It took about 2 weeks and LOTS of trial and error just to reach the current point of development.
I attempted to use a set scale interval of about 100% X,Y,Z. It takes about 70 phases to cover my entire screen (At 1300+ x 768 resolution). Due to this, it would take 70*1/32 seconds to cover all bases with the smallest wait, which is too slow. The smaller the scale interval, the higher the precision.
Building on the concept of multi-core processors, we could try pipeline a few pings starting at phase 0,10,20,30,40,50,60 to have the screen covered entirely in about 1/3rd of a second. From here, we count the number of left and right hits, identifying which dummy units were hit. The lesser phases having priority over the higher ones.
So if both 0 and 10 detected a hit, We take the recording from 0. What do you think?
Also, I'm curious as to how to scale blending works. How do you do it?
Edit: Important. Hit units must be hidden immediately or overlap will prevent future correct hits. I'm recalling that even with 1/32 second, there may still be the problem where the hit test doesn't run it's action until the ping trigger completes it's run.
Thanks for the welcome :) I'll try play round with it too if I can find the time. I'm pretty noobish at it too. My proficiency lies mainly with galaxy @@. Hopefully I'll be able to churn up some results using the actor morph soon.
Currently I'm using triggers. 90 dummy units for each side, Since my previous scaling method failed. The units with a larger scale will always have the lowest Z height in hopes it will ensure correct hits. I'm not really sure how to use the actor morph, How would I go about doing that?
The morph rate needs to be quick enough to cover the entire screen within 0.5 seconds. If I were to morph from scale 1 to 100, I suppose a timer could be used to check how long it took for the morph to detect. Basically we start a timer when the morph begins, and we stop it, and reset the actor scale to normal when the hit is detected. Thus we can use time to calculate the radius =)
Thanks so much for the inspiration. It's always nice to share and discuss ideas with others.
Each ping has 90 phases (dummy units) with different scales. They are set with a height difference of 0.01 from each other. (Too big a gap causes inaccurate measurements) The dummy units are all spawned as hidden at map initialization and stored into an unit array. No units are attached to the mouse. You could say they are stored in the following manner:
These events are fired while the Ping trigger is in mid run, but their actions are NOT run until the ping trigger thread is terminated. (Because the Ping trigger has no waits). This way, with a single run of the ping trigger, a hit is registered for the left, and the right. Thus pinpointing the distance of the pings from the mouse.
When a hit occurs, EventUnit() is checked to find its index in the unit array, which is then used to calculate the scale of the hit unit and thus the cursors distance from the ping point. Once two hits are confirmed, The Cos Rule is Invoked and the point is Calculated.
Try to imagine it in just 1 dimension, say my cursor is at X = Center of the screen.
Quote:
A) ) ) ) ) ) ) X ( ( ( ( ( ( ( ( ( ( ( ( (B
The 7th ping on the left detects a hit, It's index is 6 in the unit array, So we can say index 6 gives a radius of 7.
The 13th ping on the right detects a hit, Thats index 12. The distance between A and B is roughly 20 ping Units.
So:
radiusA=7;radiusB=13;radiusC=20;
The unit (raven) is set to move with a speed gradient towards to calculated position of the mouse. This could be changed to an actor being ordered to move to the point. The raven in the image isn't attached to the cursor, It's attempting to follow it.
Edit:
Quote:
Let me take my guess, you get the ping unit grow in size and check whether it is highlighted ?
If that's actually the method, my suggestion would be to use data editor actor morph to make the unit bigger gradually and less cpu processes on the trigger side
Not exactly. But I did try growing unit size, It requires waits to capture the distance correctly, which make the method screw up. Without waits, it's too fast and the Hit trigger only performs its actions after the ping event completes its run, thus registering the maximum scale. (If I loop scale from 1 to 100, It always detects 100) I'm trying to avoid the data editor so it's easier to implement this without having to create too many abilities/actors etc to get this working.
Off topic: Do my assets disappear if I don't update them too long or something?.. Or if there is no attachment.
Sorry if it's not very clear, I'm pretty bad at explaining stuff. Will follow up.
*Reposted to allow easier discussion of the method here
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.
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.
0
@Ultimaswc3: Go
I recall Clamp being there, not sure about square root and trunc though, They seem to already be in the API docs so it might be possible they were already there, just that we overlooked them.
0
@RileyStarcraft: Go
I was wondering what those requirement types are. Which area of the editor does it concern? Triggers?
0
It's a shame theres still no function to return cursor position eh? =/
0
@progammer: Go
AW HELL YES!
"* Added a trigger event when an effect executes." I've been looking all over for this one. : )
0
@progammer: Go
Thanks for clearing that up. Coronbale's method makes sense to me now. Also, Thanks for all the feedback everyone. =)
0
@coronbale: Go
That does sound like it would work, but would I not need a periodic trigger in galaxy/gui to re-add the behavior each time? Is it possible to have a behavior with a periodic effect that occurs once every 0.01 seconds? If so, would this be a heavy load on the processor?
I currently have 2 triggers:
The issue faced is that the while loop in Trigger A seems to locks up the processor, preventing trigger B from performing it's actions until it's too late. The current workaround I have in mind is to have a behavior with a periodic effect (based off auto-turret) instead and to change Trigger A so it only scales once per periodic event firing off the behavior. Since the trigger would then only need to perform a few instructions (That is, scaling the unit up once), as opposed to an entire while loop, it should theoretically be much faster and still allow hit tests to fire on time.
Almost forgot to ask, how did you accomplish this? Are you actually re-adding the behaviors? Or does it just somehow stay there and fire up whenever you check if the unit has a behavior?
0
@s3rius: Go
That sound's like exactly what I'm looking for. Will test it out when i'm able.
Not quite what I'm looking for coronbale, but thats very informative, thanks for sharing that info.
What I actually intend to do is to have my unit grow in size whenever the effect occurs. Indefinitely until the unit is highlighted, then i remove the unit. Thus I need a behavior with a periodic effect. Can anyone tell me if I'm on the right track if i build my dummy behavior off auto-turret timed life? Because i'm not too sure if its possible to have timed life that never expires.
0
As some of you may be aware, the Auto Turret Timed Life behavior is able to fire periodic effects. I need to catch these events somehow and fire off a trigger. I've searched the Wiki but maybe i overlooked something because I can't find such an event.
Either that or I would need to somehow catch the event that the timed life expires (but this would mean i have to keep readding the behavior which is really annoying.)
The question is, Is there a way to catch an event when a Unit comes under a specific effect? If not, are there any workarounds to catching the event that a unit comes under a behavior or effect?
0
@progammer: Go
Even with top down, there is a problem with Z cylinder height messing up the calculations. So, it is certain that must be taken into consideration, After all, what good is a system if it can't be used for every application right? xD Do feel free to come up with your implementation too. I may take awhile to fix up. It took about 2 weeks and LOTS of trial and error just to reach the current point of development.
So Things to do:
PM Replied
0
@progammer: Go
I attempted to use a set scale interval of about 100% X,Y,Z. It takes about 70 phases to cover my entire screen (At 1300+ x 768 resolution). Due to this, it would take 70*1/32 seconds to cover all bases with the smallest wait, which is too slow. The smaller the scale interval, the higher the precision.
Building on the concept of multi-core processors, we could try pipeline a few pings starting at phase 0,10,20,30,40,50,60 to have the screen covered entirely in about 1/3rd of a second. From here, we count the number of left and right hits, identifying which dummy units were hit. The lesser phases having priority over the higher ones.
So if both 0 and 10 detected a hit, We take the recording from 0. What do you think?
Also, I'm curious as to how to scale blending works. How do you do it?
Edit: Important. Hit units must be hidden immediately or overlap will prevent future correct hits. I'm recalling that even with 1/32 second, there may still be the problem where the hit test doesn't run it's action until the ping trigger completes it's run.
0
@progammer: Go
Thanks for the welcome :) I'll try play round with it too if I can find the time. I'm pretty noobish at it too. My proficiency lies mainly with galaxy @@. Hopefully I'll be able to churn up some results using the actor morph soon.
0
@progammer: Go
Currently I'm using triggers. 90 dummy units for each side, Since my previous scaling method failed. The units with a larger scale will always have the lowest Z height in hopes it will ensure correct hits. I'm not really sure how to use the actor morph, How would I go about doing that?
The morph rate needs to be quick enough to cover the entire screen within 0.5 seconds. If I were to morph from scale 1 to 100, I suppose a timer could be used to check how long it took for the morph to detect. Basically we start a timer when the morph begins, and we stop it, and reset the actor scale to normal when the hit is detected. Thus we can use time to calculate the radius =)
Thanks so much for the inspiration. It's always nice to share and discuss ideas with others.
0
@progammer: Go
Each ping has 90 phases (dummy units) with different scales. They are set with a height difference of 0.01 from each other. (Too big a gap causes inaccurate measurements) The dummy units are all spawned as hidden at map initialization and stored into an unit array. No units are attached to the mouse. You could say they are stored in the following manner:
The Ping Trigger does the following whenever it is run.
The Hit Test Trigger captures 2 events
Try to imagine it in just 1 dimension, say my cursor is at X = Center of the screen.
The 7th ping on the left detects a hit, It's index is 6 in the unit array, So we can say index 6 gives a radius of 7. The 13th ping on the right detects a hit, Thats index 12. The distance between A and B is roughly 20 ping Units. So:
The unit (raven) is set to move with a speed gradient towards to calculated position of the mouse. This could be changed to an actor being ordered to move to the point. The raven in the image isn't attached to the cursor, It's attempting to follow it.
Edit:
Not exactly. But I did try growing unit size, It requires waits to capture the distance correctly, which make the method screw up. Without waits, it's too fast and the Hit trigger only performs its actions after the ping event completes its run, thus registering the maximum scale. (If I loop scale from 1 to 100, It always detects 100) I'm trying to avoid the data editor so it's easier to implement this without having to create too many abilities/actors etc to get this working.
Off topic: Do my assets disappear if I don't update them too long or something?.. Or if there is no attachment.
Sorry if it's not very clear, I'm pretty bad at explaining stuff. Will follow up.
0
*Reposted to allow easier discussion of the method here
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.
0
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.