SC2Mapster

*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.

@FuzzYD: Go

Know the method but still dont get how can you pinpoint whether or not the ping reach the mouse, or how far it is from the mouse ? Even more confused with the left/ right. Are u using an unit that supposedly attach to the mouse ?

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

@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:

unit[90] u_leftArray;
unit[0] = Ping with Scale 1
unit[1] = Ping with Scale 2
and so on

The Ping Trigger does the following whenever it is run.

If ( Left Ping Shown ){
Hide all left pings, Show right pings
}
else{
Hide all right pings, Show left pings
}

• This is done with no waits to ensure no delay

The Hit Test Trigger captures 2 events

• Unit Highlighted
• Unit UnHighligted
• 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:

radius A = 7;
radius B = 13;
radius C = 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.

@FuzzYD: Go

Its all clear now, i knew the gps method (though 2d technically cant be called gps :P), just want to make sure if that's the highlighted event or not.

So which method did you use to phase unit through 90 phase ? trigger or actor ? I'm suggesting the use of actor for a fluent morph. There might be workaround that dont need the wait method, smt to do with behavior

( Seems like you're all pre-placed them and show/hide)

Quote from FuzzYD: Go

Off topic: Do my assets disappear if I don't update them too long or something?.. Or if there is no attachment.

I believe its a bug, it wont disappear, i got that once, all of them is not listed under my name. Took a while and it suddenly came back

@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.

@FuzzYD: Go

Np, i'm here to tackling such problem, its nice to have some new idea around (actually its really clever to think of it)

Actually i'm noobish with data editing so will get back to you after i did some testing.

Also welcome to mapster, be sure to join the irc for some fun sometime.

http://wiki.sc2mapster.com/irc-information/

(off topic: your asset managed to find its way get back to you now )

@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.

@FuzzYD: Go

Actually morph dont scale the actor gradually, I tried with set scale blend and it works pretty good

This could turn out good. However the smallest interval trigger can detect is 1/32s so inaccuracies may occur. Good luck (i'm trying myself too)

@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.

@FuzzYD: Go

Quote from FuzzYD: Go

@progammer: Go Also, I'm curious as to how to scale blending works. How do you do it?

Not sharing :P

Jk, Its one of the actor message, set scale to a new scale with blending time. Seems like you're good with calculation, I will let finish the work. 1 suggestion: Never ever scale the Z axis. Even better, fixed the beacon z scale to 0.1 before doing anything, this is to make sure a 3d cylinder highlight wont mess with your calculation. Also the height difference can be up to 0.01 each, so to make sure it does not create significant changes in height that mess with calculation

(this is assuming for a total 3d system, not directly top down)

And scale interval with actor is as smooth as the game can get you :)

Check your pm

@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:

• Attempt this with actor scaling :)

PM Replied