If they are all in the same dialog then simply show/hide the dialog for the triggering player. Dialog Items show by default so when you show the dialog it will show all of its children dialog items.
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.
All aspect ratios except 5:4 share the same height of 1200 units in terms of UI screen resolution. This is not the player's resolution, but the main resolution of each aspect ratio. Look at this chart I created a while back:
As you can see, resolutions with aspect ratio 5:4 have a larger height of 80 units than the other non-5:4 resolutions. This is rather minute. Load up resolution 1280x1024 on the attached map and you will see that the dialog hides a little sooner than the rest of the resolutions, but not by much.
Since the Game UI's models, from left to right, have different heights (minimap is the tallest, command card is mid, console is shortest) and you would want to hide the dialog based on the horizontal position then you would have to know the UI screen resolution of the player. Then you would know precisely how far each model is from the camera target.
The only way I see of fixing this is by subtracting the target position of the camera and the position of the unit and then checking the distance. I made a rough example that seems to work across the resolutions. Check out the attachment.
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.
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:
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.
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.
That would be my last resort as it would flicker the whole Game UI.
I found by adding <AcceptsMouse val="false"/> to each panel in the layouts I get the desired effect I'm looking for, but that is permanent. Is there a way to accomplish this via catalogs so that I can turn the "AcceptsMouse" on and off via triggers?
Currently, if the player's mouse is over the game's UI console (minimap, command panel, etc) then any mouse move event triggers won't fire. Is there a way to temporarily disable this and allow mouse move events to fire when over the console? Even if it results in completely disables all of the console's functionality. It would only be for a brief period.
Anybody? All I need to know is does the mouse move event still limit itself to 1599 (max X UI coordinate) under resolution 2560x1600.
I'm assuming it still does but I just want to make sure. I'd greatly appreciate if anyone (who can run at 2560x1600) do a quick test and see. I've attached a simple MouseMove test map.
I was about to create a thread based on this issue but since it already exists I'll post here.
I found a way to fix this issue but it requires knowing the user's resolution. I tested it on my largest resolution of 1920x1080 and the test worked. I'm wondering if on larger resolutions (such as 2560x1600) the mouse X UI coordinate will still limit itself to 1599. If so that would mean 38% of the right side of the screen would be unobtainable to mouse move events regarding the X UI coordinates. No good.
Could somebody with a resolution of 2560x1600 (or at least larger than 1920x1080) test this issue and report back? I'd appreciate it.
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.
0
If they are all in the same dialog then simply show/hide the dialog for the triggering player. Dialog Items show by default so when you show the dialog it will show all of its children dialog items.
0
Updated the library.
0
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.
0
Strange that there isn't a function that would retrieve the scale values..
Would something like this work?
0
All aspect ratios except 5:4 share the same height of 1200 units in terms of UI screen resolution. This is not the player's resolution, but the main resolution of each aspect ratio. Look at this chart I created a while back:
As you can see, resolutions with aspect ratio 5:4 have a larger height of 80 units than the other non-5:4 resolutions. This is rather minute. Load up resolution 1280x1024 on the attached map and you will see that the dialog hides a little sooner than the rest of the resolutions, but not by much.
Since the Game UI's models, from left to right, have different heights (minimap is the tallest, command card is mid, console is shortest) and you would want to hide the dialog based on the horizontal position then you would have to know the UI screen resolution of the player. Then you would know precisely how far each model is from the camera target.
0
@Bibendus: Go
The only way I see of fixing this is by subtracting the target position of the camera and the position of the unit and then checking the distance. I made a rough example that seems to work across the resolutions. Check out the attachment.
0
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?
0
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:
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.
Also to take into consideration is if the player is in windowed mode. This will affect the player's resolution height.
0
@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.
0
That would be my last resort as it would flicker the whole Game UI.
I found by adding <AcceptsMouse val="false"/> to each panel in the layouts I get the desired effect I'm looking for, but that is permanent. Is there a way to accomplish this via catalogs so that I can turn the "AcceptsMouse" on and off via triggers?
Here is an example for the minimap:
If not is there a way to turn on/off custom layouts in-game?
0
Currently, if the player's mouse is over the game's UI console (minimap, command panel, etc) then any mouse move event triggers won't fire. Is there a way to temporarily disable this and allow mouse move events to fire when over the console? Even if it results in completely disables all of the console's functionality. It would only be for a brief period.
Thanks.
0
Please do me a favor and perform a mouse move test, I'd very much appreciate it.
http://www.sc2mapster.com/forums/development/map-development/20564-mouse-moved-ui-pos-x-limited/#p3
Thanks
0
Anybody? All I need to know is does the mouse move event still limit itself to 1599 (max X UI coordinate) under resolution 2560x1600.
I'm assuming it still does but I just want to make sure. I'd greatly appreciate if anyone (who can run at 2560x1600) do a quick test and see. I've attached a simple MouseMove test map.
Thanks.
0
I was about to create a thread based on this issue but since it already exists I'll post here.
I found a way to fix this issue but it requires knowing the user's resolution. I tested it on my largest resolution of 1920x1080 and the test worked. I'm wondering if on larger resolutions (such as 2560x1600) the mouse X UI coordinate will still limit itself to 1599. If so that would mean 38% of the right side of the screen would be unobtainable to mouse move events regarding the X UI coordinates. No good.
Could somebody with a resolution of 2560x1600 (or at least larger than 1920x1080) test this issue and report back? I'd appreciate it.
I created a simple mouse move map to test on.
Thanks.
0
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.