By knowing the resolution information of the player you then have absolute control of all sizing/positioning of dialogs/UI elements for that player's screen. I tested the attach dialog to unit and noticed it bugs out when the mouse enters a deep elevation in terrain, but other than that seems to work fine.
I've come down to two solutions for an update to this library.
1. Continue with the mouse click (this is the most accurate) to retrieve the resolution information. I fixed three major issues with the current library.
The player does not have to mouse click, hold, and then unclick any longer. A simple click will do.
Moving the mouse erratically when clicking will not be valid thus will not return erratic numbers. Mouse Click UP can only occur at the dead center of the screen.
Screen Flips due to validation checks no longer occur. A simple hidden dialog (mouse coords / scale value) will work to see if the player has changed resolution since the system has initiated.
And as a bonus: the library would be smaller in size.
2. Do not force the player to mouse click and obtain the resolution information based on their mouse position on the screen.
This can be slightly inaccurate due to the inaccuracy of Starcraft's fixed integers (reals) variables.
The system can not work if the mouse is located in the top left or top right (if resolution is greater than 1600 width) corners of the screen. It will pause and await for the mouse to come out of these areas. If the mouse is over the game UI, hide it. Look at the following image:
http://img217.imageshack.us/img217/4092/getresolutionmousecoord.jpg
Coats the screen in hidden dialog buttons (534 currently) to get the mouse position relative to the screen resolution.
Well, the most practical solution is to continue with the mouse click approach. It's the most accurate and doesn't require the tons of coding/dialog items of the second approach that I listed.
This is great! I was so upset about the lack of ui scaling.
I've read over this forum quickly, am I to understand there's no way of NOT demanding a click without it messing up? I'd like to keep my map as seamless as possible. The game I had in mind will use a fully custom ui [if I can ever figure out how to get rid of that black background my console left behind :P]
00:00:11.00 Running gt_ExampleDialogs_Func (Event: Timer (0.5, Periodic: 1))
00:00:11.06 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.13 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.19 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.25 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.31 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.38 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.44 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.50 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
Running on window mode. I downloaded the map from this thread. Which should be the latest version right?
@JakeCake26: Go
You can position a dialog according to the UI coordinates.
http://www.sc2mapster.com/forums/development/gui/24076-placing-dialogs-at-mouse-click-position
That might give you a more elegant solution.
@SBeier: Go
Attaching it to a dialog is far more "elegant". It's simpler. It's easier. And it's less code.
If you actually read the prior posts, there's a reason why he's avoiding the getResolution. Because it's hard to use in Battle.net.
It works fine on battle.net - I use it myself.. Just ask people to hold down their mouse for a sec to account for the lag.
By knowing the resolution information of the player you then have absolute control of all sizing/positioning of dialogs/UI elements for that player's screen. I tested the attach dialog to unit and noticed it bugs out when the mouse enters a deep elevation in terrain, but other than that seems to work fine.
I've come down to two solutions for an update to this library.
So out of the two, which would you prefer?
No replies? :/
Well, the most practical solution is to continue with the mouse click approach. It's the most accurate and doesn't require the tons of coding/dialog items of the second approach that I listed.
In my opinion, I would prefer a reliable solution over a transparent solution that doesn't always return the right value.
But, for my current needs, the library is fine as it is, so I wouldn't update to the newest version anyway.
Updated the library.
This is great! I was so upset about the lack of ui scaling. I've read over this forum quickly, am I to understand there's no way of NOT demanding a click without it messing up? I'd like to keep my map as seamless as possible. The game I had in mind will use a fully custom ui [if I can ever figure out how to get rid of that black background my console left behind :P]
I'm getting this error:
00:00:11.00 Running gt_ExampleDialogs_Func (Event: Timer (0.5, Periodic: 1))
00:00:11.06 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.13 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.19 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.25 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.31 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.38 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.44 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
00:00:11.50 Trigger Error in 'lib774C730C_gt_MouseMove_Func': Divide by zero
Running on window mode. I downloaded the map from this thread. Which should be the latest version right?
I've got this working in a project right now. Good stuff, thank you.