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.
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.
Really? Can you suggest how to get the mouse UI coordinates when I am using a mouse move event? I must be missing something, I couldn't find anything built in for this.
All I want to do is move a dialogue around attached to the mouse cursor while the mouse move event is active,
Here is how you get the UI coordinates from the mouse moved event. To move the dialog to the exact cursor's position, you need to know the player's resolution. Simply using the Mouse UI coordinates will not work because dialogs are scaled down in-game depending on the player's resolution and aspect ratio.
this doesnt seems right, when I was using on my map: Variable - Set Player-Example_DialogWidth[(Picked player)] = ((Real(Example_DialogWidth)) * getResolution_PlayerUIScaleValue[(Picked player)])
I was just showing how dialogs are scaled down depending on the resolution set and demonstrated it in trigger form. If you want to set a dialog to be a specific size on a specific resolution, then the way you are doing it is correct.
Yes, in windowed mode it does require the player to select their resolution from a list whereas in fullscreen and windowed(fullscreen) they do not but only have to to click their mouse.
I am working on an update that will grab the player's resolution as soon as the system is initiated. No mouse clicks required (fullscreen). I'm also working on getting the system to work for windowed mode players so they do not have to pick from a list but may have to click their mouse.
@desiderius1: Go
Without that I would have to make dialog and dialog item for every player, which in my case would took lots of time for me to do and would take lots size from my map. I think I will just wait that blizz make some kind of fix.
It's hard to help when I do not know what you are trying to accomplish. If you want you can send me a PM regarding the details. But, have you looked at what I posted above and my idea? With that you would only have to create the dialog in question once as well as all of it's contents only once. You would not have to create a dialog/dialog contents for every player.
The main intention of this library is to find the value being multiplied to all dialog dimensions on a player's screen for scaling. The scaling is to keep a dialog's size consistent from resolution to resolution.
This is very useful information when designing, for example, a custom minimap. If you do not know the minimap's dialog dimensions on a player's screen and want to implement the functionality of being able to pan to a certain place in the world by clicking on the minimap then it would not be possible to achieve. Yes, this was my personal dilemma and thus the creation of the library :).
So, how do you use this library? If you created a dialog of size 512x256 and a player's resolution is set to 1440x900 then the dialog's size for that player would be 384x192 because the value being multiplied to the dialog's dimensions is .75.
...for example we can only change dialogs size with custom script for each player without making a dialog for every player?
If you are asking if we are able to change a dialog's size for each player, then the answer is no. Changing a dialog's size would reflect the change for all of the players. You would have to create a dialog for each player to do what you want (or see my idea below). But, why would you would to do this? It would cause inconsistency in the scaling as it would make the dialog small on one resolution and large on another.
Let's compare with a dialog of absolute size 512x256 on resolutions 1024x768 and 1920x1200.
If however, you still want to do this, then I have a way to achieve it. The only negative about it is that you won't be able to use a dialog background which isn't that bad considering you can just make one with a dialog item (image). The idea summed up is you would have to create the dialog according to the resolution 1280x720 as this has the smallest scale value of all of the resolutions (.6). This would make the dialog perfectly sized for that resolution while larger for the other resolutions, depending on their scale values, but never smaller. After that, you simply add "padding" to the dialog with math when creating or manipulating dialog items. The dialog contents would be aligned and sized with the set dimensions you would provide across all resolutions; they would not be scaled down. Just let me know if you, or anyone else, is interested in this feature and I will implement it.
Well I narrowed it down. The M3 Plugin is either not importing or exporting the "Physics bodies" of the model. Inside the editor, in the model previewer, there is a folder called "Physics bodies" which has all the collision information for the model. Take a look at these images:
This is the Original model, untouched as it appears in the editor:
Here is the exact same model, imported and exported through max via M3 Plugins then imported into the sc2 editor.
So I guess my question would be is, How do I add a "Physic body" to a model?
How can you add collision to a custom model bridge so that units are able to walk on it? I do not think it has to do with pathing in the editor but something with the model itself. I took the 'Mara Sara - bridge' doodad and simply changed the model to custom one. After doing so, the doodad lost it's collision. So, I figured it must be with the model it is obtaining it's collision information, but unsure how. I exported the 'Mara Sara - bridge' model and imported it into max with the m3 plugin and noticed it has 1 bone and 4 attachments. What are these being used for? As a test, I simply exported what I just imported to see it would still have it's collision in SC2. It did not. I then noticed the two files were different in size; the original bridge file being 180KB and the exported bridge file being 147KB. So, what is not being exported?
As soon as I moved the mouse, the trigger starts and loops indefinitely even if you stop moving the mouse. So, I think the event is messed up. Perhaps try coupling this with a periodic event.
0
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.
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.
0
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:
0
@SexLethal: Go
Really cool library SexLethal, great job. This has a lot of potential.
Here is how you get the UI coordinates from the mouse moved event. To move the dialog to the exact cursor's position, you need to know the player's resolution. Simply using the Mouse UI coordinates will not work because dialogs are scaled down in-game depending on the player's resolution and aspect ratio.
0
Updated to v1.10!
Enjoy.
0
Click again, a list should appear with either standard or widescreen resolutions.
I was just showing how dialogs are scaled down depending on the resolution set and demonstrated it in trigger form. If you want to set a dialog to be a specific size on a specific resolution, then the way you are doing it is correct.
0
@OneTwoSC: Go
Yes, in windowed mode it does require the player to select their resolution from a list whereas in fullscreen and windowed(fullscreen) they do not but only have to to click their mouse.
I am working on an update that will grab the player's resolution as soon as the system is initiated. No mouse clicks required (fullscreen). I'm also working on getting the system to work for windowed mode players so they do not have to pick from a list but may have to click their mouse.
0
0
Here is the function and its parameters in galaxy.
There is no parameter to specify a particular playergroup or player when setting a dialog size.
It's hard to help when I do not know what you are trying to accomplish. If you want you can send me a PM regarding the details. But, have you looked at what I posted above and my idea? With that you would only have to create the dialog in question once as well as all of it's contents only once. You would not have to create a dialog/dialog contents for every player.
0
@Hookah604: Go
The main intention of this library is to find the value being multiplied to all dialog dimensions on a player's screen for scaling. The scaling is to keep a dialog's size consistent from resolution to resolution.
This is very useful information when designing, for example, a custom minimap. If you do not know the minimap's dialog dimensions on a player's screen and want to implement the functionality of being able to pan to a certain place in the world by clicking on the minimap then it would not be possible to achieve. Yes, this was my personal dilemma and thus the creation of the library :).
So, how do you use this library? If you created a dialog of size 512x256 and a player's resolution is set to 1440x900 then the dialog's size for that player would be 384x192 because the value being multiplied to the dialog's dimensions is .75.
The math in trigger form:
If you are asking if we are able to change a dialog's size for each player, then the answer is no. Changing a dialog's size would reflect the change for all of the players. You would have to create a dialog for each player to do what you want (or see my idea below). But, why would you would to do this? It would cause inconsistency in the scaling as it would make the dialog small on one resolution and large on another.
Let's compare with a dialog of absolute size 512x256 on resolutions 1024x768 and 1920x1200.
Quite a difference.
If however, you still want to do this, then I have a way to achieve it. The only negative about it is that you won't be able to use a dialog background which isn't that bad considering you can just make one with a dialog item (image). The idea summed up is you would have to create the dialog according to the resolution 1280x720 as this has the smallest scale value of all of the resolutions (.6). This would make the dialog perfectly sized for that resolution while larger for the other resolutions, depending on their scale values, but never smaller. After that, you simply add "padding" to the dialog with math when creating or manipulating dialog items. The dialog contents would be aligned and sized with the set dimensions you would provide across all resolutions; they would not be scaled down. Just let me know if you, or anyone else, is interested in this feature and I will implement it.
Hope that helps.
0
Well I narrowed it down. The M3 Plugin is either not importing or exporting the "Physics bodies" of the model. Inside the editor, in the model previewer, there is a folder called "Physics bodies" which has all the collision information for the model. Take a look at these images:
This is the Original model, untouched as it appears in the editor:
Here is the exact same model, imported and exported through max via M3 Plugins then imported into the sc2 editor.
So I guess my question would be is, How do I add a "Physic body" to a model?
0
How can you add collision to a custom model bridge so that units are able to walk on it? I do not think it has to do with pathing in the editor but something with the model itself. I took the 'Mara Sara - bridge' doodad and simply changed the model to custom one. After doing so, the doodad lost it's collision. So, I figured it must be with the model it is obtaining it's collision information, but unsure how. I exported the 'Mara Sara - bridge' model and imported it into max with the m3 plugin and noticed it has 1 bone and 4 attachments. What are these being used for? As a test, I simply exported what I just imported to see it would still have it's collision in SC2. It did not. I then noticed the two files were different in size; the original bridge file being 180KB and the exported bridge file being 147KB. So, what is not being exported?
'Mar Sara - Bridge' model in max
M3 Import/Export Settings
Thanks.
0
@FuzzYD: Go
Just posting to confirm that this is also happening to me, so you're not alone.
0
@SouLCarveRR: Go
I tested it and all of the Unit selection events: highlight, select, clicked work for me in relative camera mode. Mouse Click event also works.
0
@Kanaru: Go
Go to 'Data' -> 'Units' -> 'NAME OF UNIT' -> 'Unit - Flags' -> and un-check "Cannot be Highlighted" & "Cannot be Clicked"
0
@Tradnan: Go
I tested it with this trigger:
As soon as I moved the mouse, the trigger starts and loops indefinitely even if you stop moving the mouse. So, I think the event is messed up. Perhaps try coupling this with a periodic event.