Bitttymacod
A potential problem I see with this is that it *might* make macros *too* powerful and subject to abuse/botting. We already have occasional problems with people using keystroke emulators to manage alts. I, for one, don't want to see alt management made any more easy than it already is.
I greatly understand it as I played in games where even the simple AFK was forbidden (for very good reasons): the task was accomplished inserting random popups which must be manually confirmed, an automated bot can't do.
Here the things 're a little more tricky, as AFK is legal but, as (obviously) bots can be used for "batch works" only (e.g. harvesting and/or crafting), Devs can insert random timed popups (like CAPTCHA mechanism) which requires manual confirmation when "not AFK and doing harvest/craft action" only, to be sure a human is at the keyboard, not a bot.
Bitttymacod
Also if you have TEMPtarget and TEMPSelect, which one ends an action and returns you to status quo ante?
These are not simple things that are being asked for, nor are they without potentially undesirable consequences.
Well... I gave 2 samples only, but we can investigate the things better too.
One thing which should be placed in a rule (macro editor rule) is "a TEMP{action} can't be placed directly after another TEMP{action}".
e.g.
TEMPselect
run shortcut N
TEMPtarget
target a teammate 1
is legal, while
TEMPselect
TEMPtarget
run shortcut N
target a teammate 1
is not
On the same rule: "a TEMP{action} is used for the next one only" (so there is not a "TEMPend")
This should cope with the most of the problems, I bet (but I'm not a Ryzom Dev so...)
Bitttymacod
Aeralin has pointed out one way of handling the problem. Another would be to make a bar that had natural followups for macroed actions that did not end up on the same bar.
For instance, my "oh, s**t" macro, which has a very convenient key assigned to it, does change bar, do self-heal and MPA, and leaves me on a bar with both speed and invul and also my higher level ele and heal.
The problem behind the "temp" is that you can't know where do you come from (which bar was active, which target was selected): only the Action can know where it was started from.
Maybe it can wait "until the next action was started" (not "completed": only started) to restore IT's "status quo ante".
If you loose which the "previous point" is, after the action execution, you just can't restore it.
Bitttymacod
--Every time with respect -- With respect,