SC2Mapster

Updated to v1.10!

Enjoy.

Any plans to update this in near future? I love this library!

EDIT: What I really meant - not requiring mouse click (Although it appears you use mouse's position to calculate the resolution).

Quote from deathreaper945: Go

Any plans to update this in near future? I love this library!

EDIT: What I really meant - not requiring mouse click (Although it appears you use mouse's position to calculate the resolution).

Yes, I plan to update this library but it may still require a mouse click from the player. However, It is too early to say. I am currently experimenting with a method that, at the moment, is showing potential to not requiring the player to click their mouse. This would also alleviate the issue of the "Validation" camera "flip."

Bugs that I found:

• If the player's mouse is at the center of the screen, this will fail the validation check. This is due to the Screen/World angles not matching.
• If the player's mouse is over the Game UI, the validation fails because the mouse coordinates return (0,0). By hiding and then reshowing the Game UI, it will cause it to flicker which is something I do not want. Only other thing I can think of is to wait for the mouse coordinates to be greater than (0,0) before initiating the validation trigger.
• I have noticed on resolution 1680x1050 (my monitor's highest resolution), that the "Mouse X position in the UI" cannot exceed X coordinate 1599. This means if the player's mouse position is any value above >1599, it will fail the validation check. This is a bug with the game. If anybody with a bigger monitor could test the higher resolutions (above 1680x1050) and report back, I'd greatly appreciate it.

I have noticed the first two bugs. I thought about modifying your code a little so it'll return a boolean value (I haven't looked fully at the code yet) indicating it's validated so the player can continue. About the second bug, does it affect with Hide Game UI? Few times, whenever I click in the area where game ui would be, it won't get validated.

Quote from deathreaper945: Go

I have noticed the first two bugs. I thought about modifying your code a little so it'll return a boolean value (I haven't looked fully at the code yet) indicating it's validated so the player can continue. About the second bug, does it affect with Hide Game UI? Few times, whenever I click in the area where game ui would be, it won't get validated.

Yes it will work if the Game UI is hidden. When the player clicks the mouse, it snaps the mouse to the center of the screen, gets the coordinates, and then returns to it's original position. This will work if Game UI is shown or hidden. The Game UI, however, must be hidden during validation since the mouse cursor could be at any position on the screen.

If the validation is still failing, it must be that the camera-target to mouse and screen-center to mouse angles are not matching. Since Starcraft 2 can be very inaccurate with its math, try increasing the "padding" on the if statement.

if ((lv_screenCenterToMouseAngle < (lv_cameraToMouseAngle + 1.4)) && (lv_screenCenterToMouseAngle > (lv_cameraToMouseAngle - 1.4)))

The '1.4' value is what I used, try increasing it.

EDIT: By the way, that's under the getResolution_MouseCoords trigger.

I hope that helps.

This might be what you wanted (PMs don't allow attachments). It is not perfect, but I think the results are close enough most of the time.

@SexLethal: Go

Actually PMs do allow for attachments, if you attach the file after sending the message.

Any updates?

Whats the optimal angle to have when the player clicks? It doesn't seem to work very well on my terrain because its bumpy... :(

Just out of curiousity, I'm not sure if it has been mentioned as I just skimmed this thread, but what is the principle of how this works?

Does it somehow use mouse click position to calculate the screen resolution?

Edit: Sorry about the epic necro...

It uses the fact that when you enter relative mode, your cursor is moved to the center of your screen.

So when the user clicks the mouse down, it enters relative mode, and when he releases it, the script exits relative mode, fetches the mouse coordinates and multiplies them by two.
And then it does a bunch of stuff to check if it's windowed and such.

Anyway, as a result of that - for online use, the player should be asked to hold down the mouse for a sec or two.. (because of BNet lag).
Also, the user can still move the mouse a bit while in relative mode (it will be moved back to center at certain intervals). As a result, the measured resolution can be wrong, if he doesn't keep his mouse still.

@SBeier: Go

That's a pretty good workaround. Thanks for the explanation :) and of course, thanks to desiderius1 for sharing this.

Glad to see people are still interested.

While messing with the 1.4 Public Test editor, I've found a way to find the UI screen size, scale value, and resolution of the player without requiring a mouse click. This is possible by the use of a new trigger event "Mouse Enter for the Dialog Item is Used." The system still uses mouse relative mode but only for a split second, the only thing you notice is that your mouse blinks.

@desiderius1: Go

This doesn't work in multiplayer maps ;x

EDIT: was half dead when I typed that... What I meant was - it does not work on battle.net, at least in PTR 1.4. The current system that is.

@Enexy: Go

Due to the laggy nature of battle.net, you have to hold down the mouse button for at least a second, when clicking, before releasing. If you simply click it will return completely inaccurate numbers.

I am working on a different system which requires no mouse clicks and doesn't use mouse relative mode. So far, I have it able to capture the UI Screen resolution of the player without the player even noticing. There are certain "verification" checks that avoid the system from returning false numbers. I tested it on battle.net and it works. But due to battle.net lag, it takes about a second to capture the width/height of the screen. That's the only downside.

My next step is to get the Scale Value which will in turn get the resolution of the player and make it possible to create dialogs relative to the player's resolution on the player's screen (i.e. a dialog at the mouse cursor). This however, I need the player's mouse coordinates. This isn't a problem unless the player's mouse is over the game's UI console or is at the top left corner of the screen, which returns (0,0) for the mouse coordinates. A fix for the Game UI console issue it to simply hide it if the mouse returns (0,0).

These will be two separate functions also which you can assign it to a variable.

Please finish up your new system, the current one is close to completely useless when it doesn't work online.

@JakeCake26: Go

Yeah, although what you said remedies the multiplayer issue - by holding down the mouse, it'd be hard to instruct players to do so. Because not only must they click, they must hold it down, AND they must not move the mouse. Might sound simple to us - but difficult to others. Believe it or not...

@desiderius1: Go

I am also interested in this.... as i am trying to nest dialog button into the standard UI.

I will take up experimenting with ways to determine screen resolutions as well.

Would like to know how your currently handling calculating this?

So for my test.....

• create Dialog
• set last created dialog fullscreen true
• pick each player
  • text message integer( width of dialog for (convert player to player group(picked Player)) to debug

this did not give the actual width of the dialog

You cannot retrieve in-game values of dialog sizes/positions. So when you use the "width of dialog" function, it will return the width you specified in the editor.

As for the math..

There are three values we need to know and how they are calculated:

• UI Screen Resolution Width/Height = (Player Resolution Width/Height / Scale Value)
• Player Resolution Width/Height = (UI Screen Resolution Width/Height * Scale Value)
• Scale Value = (Player Resolution Width/Height / UI Screen Resolution Width/Height)

The UI Screen Resolution is created based on the aspect ratio of the player's resolution. This is the resolution dialogs use for their sizing/positioning by default. The scale value allows you to size/position dialogs relative to the player's resolution.

Aspect Ratio = (Player Resolution Width / Player Resolution Height)

if ( Aspect Ratio <= (5 / 4) )
    UI Screen Resolution Width = 1600
    UI Screen Resolution Height = (1 / (Aspect Ratio * 1600))
else
    UI Screen Resolution Width = (Aspect Ratio * 1200)
    UI Screen Resolution Height = 1200

Also to take into consideration is if the player is in windowed mode. This will affect the player's resolution height.

if (WindowedMode = true)
    Player Resolution Height = ((CenterY * 2) + 19)
else
    Player Resolution Height = (CenterY * 2)

@JakeCake26: Go

For what you said jake - why not just then move the dialog item to the world pos mouse move X?

EDIT: I see why, n/m. Guess I won't be needing the getres thing now either.