Is there a way to make a macro cast an ability at your current mouseover target, like you can do in other games' macro systems? Is there a way to make a macro choose a different ability based on whether your target is hostile or friendly? For context, there's 2 things I can do in WoW / Rift which most MMOs rarely let me do, and always cause me immense frustration / QQ as a result: Save bind space by making 1 button shoot a healing spell if I'm targeting an ally, and shoot a damage spell if I'm targeting an enemy. Save endless redundant click-retargeting time by letting me cast abilities on whatever my cursor is hovering over, while maintaining the same constant hard-target (eg usually the boss). I can't find a way to do this from going over EQ2 macro guides, so, it's probably just QQ-ville for me like LOTRO, SWTOR, GW2 etc etc etc etc. But I won't give up without asking first!
Ooooooooookay. Well... EQ2 devs, if you're reading this and somehow find a magical artifact that adds an extra 72 hours to each workday, it'd be awesome if this game ever had additional aliases that can be added to macro target blanks, such as: hostile / friendly group / raid mouseover (although this might cause EQ2 to outright immediately explode or something, so let's not go crazy here) ... rather than just literal player names. I mean I play a lot of games fine that give you way less customization than EQ2 does (like SWTOR for example, which doesn't even let you have macros... or UI mods... or... anything), so this is kind-of nitpicking. But my OCD need to keep everything as smooth and efficient as possible would be happy.
The game sort of handles this already. If you have a boss targeted and click a damaging ability it will hit the boss. If you cast a heal spell with the boss targeted, it will heal whoever the boss has targeted, no need to swap targets to heal. So, you could set s macro with an attack and a heal. Target a boss, click macro, the attack will hit the boss and the heal will hit the current target of the boss.
There are things like /useabilityonplayer for macroing things to friendlies, but he wants to hit one button and it do damage or heal depending on what is targeted. Implied targeting doesn't exactly do that. It works if you have 2 buttons, one for heals and one for damage and you hit the right button depending on what you want to do. With the useabilityonplayer, there are default targets like G1, G2, G3, etc to hit whatever person is in those slots. There are some good write-ups on this around if you do a little googling. A few games do what the OP described where you can bind multiple things to one key and depending on if the mouse over target is hostile, nuetral, friendly, or empty, the macro does a different action. I think this type of thing is far more common in live action combat systems. It might be nice in PVP in EQ2, but it is probably much to ask for at this stage.
Yeah, implied targeting is OK but it doesn't help if Invincible Zerker is at 100% but Clueless Brigand is standing in a puddle of bad and needs an ST. Overall it's not a big deal, I'm used to adapting to each game's quirks. I'm just super-fussy about my control systems and try to get them as precise / efficient as possible because I have MMOCD.
You may try to use aliases. something like : Put in a target definition macro /alias supernasty target %T Target your main target and use the target definition macro.... and then in another /supernasty. I use two such alias to define my MT/OT in raids, handy in group too. Last time i tried to do a macro for Bolgain targeting (we always to it ignoring the script, so at the end we have a hord of gobleins) and /target bolgain did not work.
As someone who struggles to live without it, I actually do plan on adding mouseover macro support sometime after the expansion. It will only support UI elements at first, though (no mousing over a character model in the world for example).
What can be some of the applications? Can you or lovestar give some examples? Dont need to waste time if the use is very limited and risk breaking things.
Please do not. There are a lot of us out here that use other UI's DrumsUi for example, imposing a load on them to support something that I have only seen asked for once, twice if you count yourself seems to be a little out of kilter with rational setting of priorities.
I'm not sure why you think this would require additional support on the part of custom UI modders, nor would that play a role in determining whether or not it gets implemented.
I like this reply. If anything instead of asking for feature not to be added to the default UI because custom mods I would like to see features from custom mods added to the default UI. I think long term finding ways to support more features by default would be an excellent use of dev time.
So I take it from this that you have issued an unconditional guarantee that it will not break the custom UIs out there at the moment? Oh, that is right you said that: "nor would that play a role in determining whether or not it gets implemented". So you are prepared to break those custom UIs to implement something that few players have asked for.
Why would you like it? Rather than offering to incorporate features from custom mods he expressed complete indifference as to whether or not they got broke in the process of adding "mouse over" support to the UI.
Sorry, I didn't interpret your initial post as "is this going to break custom UIs" but rather "will custom UI modders have to do work to have this be usable in custom UIs." This shouldn't break custom UIs, nor should it require any work on their part to support.
I would like it because it is a nice feature to have and currently it cannot be done, even with custom UIs. I am a fan of DrumsUI and used it for many years. Despite that I would still rather see useful features added to the default UI than not. As far as expressing complete indifference to weather or not it would break custom UIs, that has always been the case. Consideration has never been given for custom UIs when deciding what changes to make to the UI. I personally know the pain and aggravation of having my favorite UI broken by changes and updates but that is what you deal with when dealing with a custom UI. It is pretty standard in MMOs. The best MMO developers however take popular features from custom UIs and add them to the default and that is what should happen in EQ2. To my knowledge very few features have been implemented based on custom UI mods. Click to cure and the auto attack timer are the only two I can think of. Other than custom UI developers having to add support for default features (and we don't know that would be the case) why wouldn't you like it?
Thank you for the clarification. Although I would prefer it if instead of "shouldn't break custom UIs" you had sad "we will take care to avoid breaking existing functionality in Custom UIs". Adding additional functionality that mod developers may choose to support is a whole different beast. Although I still do not see the benefit and therefore would prefer time spent doing other things for which a case has already been made. I would offer specific examples but I am ignorance of the scope of your remit.
In this era of constrained resources, and when Kander has a bucket full of awesome waiting for development effort this one is not on my needs list at all. It is not on my wants list either. For me this one should be in a different bucket, along with the 64 bit client, a full redrawing of all graphics assets, redoing the architecture to sport a single mega server and a number of other items that have been requested but cannot be delivered due to real world resource constraints. Not that this is of the same scale as those I mention just that from my view the need is so low and there are so many other things that could be done instead.
