That is ridiculous. SC2 already collects mouse data for various things. Just take CameraForceMouseRelative as an example... this makes it so that the camera motion is inherently linked to mouse motion. The EXACT same thing could be done, except instead of moving the camera upon mouse motion, the game could fire some trigger and update some mouse position values. Blizzard is just being really lame by not including this...
No I don't think you understood my point, the problem isn't that mouse position can't be collected, it's that input latency means the odds of the mouse cursor being in the place the variables say it is are extremely unlikely, so the cached information would not be very useful.
1 QoL improvement: whenever you're editing search/target filters, a "use default" filters button. Really getting tired of manually excluding dead, hidden, invulnerable, missile, stasis again and again and again.
Also, please have MouseGetX/MouseGetY functions, I don't want to have to create another program that runs behind SC2 that just clicks the mouse for me...
There are no mousex/mousey functions due to the network architecture. The server can't know the mouse position of the client without asking for it and due to network latency the mouse position is likely very different by the time the trigger runs to when the client sees the response.
The basic issue is the lack of a "client-side" trigger which is not synced across the network. That would be a non-trivial addition to the engine though and would probably be massively complicated as there would be a very strict set of rules as to what could and couldn't be done in such triggers, and you'd need to marshal data (local vs. synced), etc. So it's not going to happen.
However, making it so the client sends the mouse cursor position when certain other events occur - like keypresses - is entirely possible and hopefully is added.
Every single thing in the data editor needs a short description of what it is when you hover over it. A lot of elements already have this but there are a TON of data fields without this. Look at the mover field for instance. It is insanely difficult to make the mover you want because people have no idea what many of the fields do. Giving everything a short description will make it much easier for newer users to get started and make it easier for advanced users to create the complex data functions they want without having to spend 30 minutes doing trial and error on an obscure function.
A lot of them have hilariously non-descript tooltips, too. For example, if you're editing a Mover and you mouse over the Polarity field under Motion Overlay, it gives you the wonderful description "The Polarity of the Mover." Thanks, I'd have never figured that one out on my own.
When creating/moving UI elements like dialogs, portraits, etc. the coordinates you specify are not actual screen coordinates in pixels, they're translated into some other coordinate space. But the "Mouse Clicked UI Position X/Y" functions return the mouse position in actual pixels - which is completely useless information. There are no functions to translate coordinates between the two systems.
Filtering by object source when selecting objects for a field entry. (I.e. when you need to select an effect in the field, and the full list of 50000 effects comes up, you should be able to filter out anything not from my map. Right now I add an editor prefix that starts with a "[" character to make all my stuff at the top of the list.)
Fix the damn bug where sometimes when you dupe an object, the duplicate's identifier cannot be edited (introduced in patch 16, IIRC.)
Make duping more consistent. Behavior shouldn't be different when you right click->Duplicate versus copy & paste.
When you first start the editor there's a web link to a Blizzard editor wiki, which is just a 404 right now.
I guess these are all mostly bug fixes and not feature requests. I've found very few things that I flat out can't do with the editor, but there's a lot of things that could (should) be made MUCH more convenient.
edit: Add a "Custom Map" object family so that sorting mechanism is useful. Add a bunch more Behavior Categories, as 3 is NOT enough. Add more attributes or let us add them ourselves.
AND LET US OVERRIDE THE GOD DAMN BASE UI, this is clearly the #1 thing missing from the editor right now.
No I don't think you understood my point, the problem isn't that mouse position can't be collected, it's that input latency means the odds of the mouse cursor being in the place the variables say it is are extremely unlikely, so the cached information would not be very useful.
There are no mousex/mousey functions due to the network architecture. The server can't know the mouse position of the client without asking for it and due to network latency the mouse position is likely very different by the time the trigger runs to when the client sees the response.
The basic issue is the lack of a "client-side" trigger which is not synced across the network. That would be a non-trivial addition to the engine though and would probably be massively complicated as there would be a very strict set of rules as to what could and couldn't be done in such triggers, and you'd need to marshal data (local vs. synced), etc. So it's not going to happen.
However, making it so the client sends the mouse cursor position when certain other events occur - like keypresses - is entirely possible and hopefully is added.
A lot of them have hilariously non-descript tooltips, too. For example, if you're editing a Mover and you mouse over the Polarity field under Motion Overlay, it gives you the wonderful description "The Polarity of the Mover." Thanks, I'd have never figured that one out on my own.
When creating/moving UI elements like dialogs, portraits, etc. the coordinates you specify are not actual screen coordinates in pixels, they're translated into some other coordinate space. But the "Mouse Clicked UI Position X/Y" functions return the mouse position in actual pixels - which is completely useless information. There are no functions to translate coordinates between the two systems.
WYSYWIG text editing.
Filtering by object source when selecting objects for a field entry. (I.e. when you need to select an effect in the field, and the full list of 50000 effects comes up, you should be able to filter out anything not from my map. Right now I add an editor prefix that starts with a "[" character to make all my stuff at the top of the list.)
Fix the damn bug where sometimes when you dupe an object, the duplicate's identifier cannot be edited (introduced in patch 16, IIRC.)
Make duping more consistent. Behavior shouldn't be different when you right click->Duplicate versus copy & paste.
When you first start the editor there's a web link to a Blizzard editor wiki, which is just a 404 right now.
I guess these are all mostly bug fixes and not feature requests. I've found very few things that I flat out can't do with the editor, but there's a lot of things that could (should) be made MUCH more convenient.
edit: Add a "Custom Map" object family so that sorting mechanism is useful. Add a bunch more Behavior Categories, as 3 is NOT enough. Add more attributes or let us add them ourselves.
AND LET US OVERRIDE THE GOD DAMN BASE UI, this is clearly the #1 thing missing from the editor right now.