Macro's actions: back to the previous state - IDEAS FOR RYZOM

buscar | Iniciar sesión Foros | Nueva publicación | Últimas 24h


	IDEAS FOR RYZOM

Foros » IDEAS FOR RYZOM » Macro's actions: back to the previous state

#1 Añadido por Elweit(arispotle) 1 década hace [en]

{translate}

One of the (not so heavy but annoying and, possibly, dangerous) behaviour I saw using macros to start actions from actionbars is that one can never "get back to the previous" actionbar he was when started the action, at a certain point or just when the macro ends.

E.g. if I've all my Fight actions grouped into actionbar 2 and I start a macro which uses an action/button which is in actionbar 1, I can't get back to actionbar 2 when the macro stop working or when I need it.

macro "heal me"
* Actions: Select shortcut bar 1
* Actions: Run shortcut 2 (e.g. heal self)
end of macro: I'm still into actionbar 1 (which, for example, can have Magic actions)

Suggestion #1: add an action to "temporary select" of an actionbar, valid for the next action only, which switches you back when the action ends:

macro "heal me"
* Actions: TempSelect shortcut bar 1
* Actions: Run shortcut 2 (e.g. heal self)
end of macro: I'm back into actionbar 2

Suggestion #2: add a "Previous" parameter to the "Select shortcut bar" action, which must be executed after the actions of the switched-to actionbar took place:

macro "heal me"
* Actions: Select shortcut bar 1
* Actions: Run shortcut 2 (e.g. heal self)
* Actions: Select shortcut bar prev
end of macro: I'm back into actionbar 2

If the macro's actions can be executed in sequence, both solutions can be viable. If the execution is not serialized (even if I have difficult to think why), only the first suggestion can help.

To avoid confusion: I used the words "back" and "previous" for a precise reason: starting a macro I just can't be sure of which actionbar I'm in at the moment so, to avoid making TEN macros (get back to actionbar 1, get back to actionbar 2, ..., get back to actionbar 10), is preferable to "get back to the previous" one.

#2 Añadido por Ulykus 1 década hace [en]

{translate}

Would be a nice addition, but i think you can do what you want using action bar #2?

#3 Añadido por Elweit(arispotle) 1 década hace [en]

{translate}

Ulykus

Would be a nice addition, but i think you can do what you want using action bar #2?

Never tried, as I'm pretty new to the game: just had the problem, tried to find some solution (which didn't come to me) read the forum to find if the proposal was already done, and made this one.
I'll try to follow your suggestion and, if it will be a viable solution, will ask to close this thread too.
Thanks :)

#4 Añadido por Vourac(arispotle) 1 década hace [en]

{translate}

Elweit

If the macro's actions can be executed in sequence, both solutions can be viable. If the execution is not serialized (even if I have difficult to think why), only the first suggestion can help.

macro actions are not all serial

try this when you fight beast - use macro to 1) target friend, 2) heal, 3) retarget beast. middle step will fail saying cannot heal beast i believe :(

instead you must do 1 and 2 with one macro then 3 with another macro (or manual)

#5 Añadido por Elweit(arispotle) 1 década hace [en]

{translate}

I noticed too they're not serial (which poses great doubts when programming them) so only the first suggestion can work.

e.g. I tried that macro:
1) show/hide the interface
2) screenshot JPG
3) show/hide the interface

it didn't work, as screenshots was taken with the interface visible -__-"
No logic I can figure to not having serial execution of the steps (and their effects, obviously)

Should be
action 1
-> effect 1
action 2
-> effect 2
... and so on

but it seems to me it was
action 1
action 2
action N
-> effect 1
-> effect 2
-> effect N

:-/

At least one should choose if to parallelize or serialize the execution ç_ç

#6 Añadido por Aeralin 1 década hace [en]

{translate}

When using macros, it's difficult to flip between Action Bars, as, once you land on a given bar, there is no flip back option short mousing or keying back. The smartest way to handle them is to build your macros and place the needed actions directly below the Macros on the bar itself.

Example: Slot 1: Macro: Target <name of player/mob needed>
Run Shortcut 11 (heal/magic attack/melee attack)
Slot 11: Skill needed to perform the above action. (heal/magic attack/melee attack)

By building a bar with just your macros, you can perform many more actions smoothly without having to flip bars constantly. This means you don't always get the neat organization you might be looking for, but it makes macro implementation much easier. I, personally, kept all of my Foraging, Melee and Magic on separate bars, in addition to building special bars for things like NPC boss hunting and running Occupations. NPC hunting and Occ running require multiple skills that would be otherwise segregated to be at my fingertips, so I built those bars with everything I needed in one place.
I realize that this doesn't really solve the problem you're suggesting a fix for, but it's a work around til your idea is implemented.

Hope this helps. :D

Última edición por Aeralin (1 década hace)

#7 Añadido por Bitttymacod 1 década hace [en]

{translate}

If my results on trying serial stuff in macros is true, then certain things are apparently serial and some are not.

However, I think that actions are done serially...BUT the macro does not wait until the completion of the action to do the next step. Things like say>around>text or /tar or bar #3>action #11 are done in order, but the results aren't waited for.

As a result I can say three or four lines in succession and they always come out in succession because the saying is essentially instantaneous. However, the return on /tar is not quite instantaneous. So for my boss macro I will often see the "target not found" message many times and then the two Nameds in the area at the bottom of the list, even though the /tar commands are not even close together in the list nor anywhere near the bottom.

---

Remembering Tyneetryk
Phaedreas Tears - 15 years old and first(*) of true neutral guilds in Atys.
(*) This statement is contested, but we are certainly the longest lasting.
<clowns | me & you | jokers>

#8 Añadido por Elweit(arispotle) 1 década hace [en]

{translate}

Having actions done in parallel is usually good, in a game, so that you haven't to wait for one completion (which can even delay, depending on server's load or lag) to take profit of the next action.
But can be a nightmare when you try to do some things in sequence and the next closely depends on the previous -__-"
(btw: no way to insert a delay too, for the same reason)

I bet to modify the actual execution engine (to permit serial execution also, when requested) can be difficult, so I renew the request to have some "relative" actions, which won't have to wait for the execution's end, but which are temporary also, so that one haven't to call in a next one to restore a previous state (which, btw, will be executed before needed for sure).

e.g. (on my previous examples)
macro "heal me"
* Actions: TempSelect shortcut bar 1
* Actions: Run shortcut 2 (e.g. heal self)
end of macro: I'm back into actionbar 2

logic: as I called in a "temp" action, the execution of the next one will trigger the end of the action (Select shortcut bar, in the example) and revert to the previous state (previous shortcut bar which we started from, internally (temporary) saved by TempSelect).
This way, the TempSelect haven't to wait for the (next) action (heal) completion, but can revert the actionbar just after starting it.

And now... some little (ASCIIart) timeline simulation :D

actual behaviour

.-- Select shortcut bar 1 <=== the macro starts
! (the shortcut bar 1 is selected, as the switch is immediate)
'-- (the Select shortcut bar ends)
.-- Run shortcut 2
!.-- (the shortcut 2 starts)
'!- (the Run shortcut action ends) <=== the macro ends
.!
...
.!
.! (the heal action is still executing)
.!
...
.!
.'- (the heal action ends)
(you 're still into shortcut bar 1)

wanted behaviour

.-- TempSelect shortcut bar 1 <=== the macro starts
! (the shortcut bar 1 is selected, as the switch is immediate)
!.-- Run shortcut 2
!!.-- (the shortcut 2 starts)
!'!-- (the Run shortcut action ends)
!-!-- (the TempSelect auto-restores the previous actionbar)
'-!-- (the TempSelect shortcut bar ends) <=== the macro ends
..!
...
..!
..! (the heal action still is executing)
..!
...
..!
..'- (the heal action ends)
(you 're now into shortcut bar you started with)

#9 Añadido por Vourac(arispotle) 1 década hace [en]

{translate}

+1 good ideas <3

please by same logic add TEMPtarget command

#10 Añadido por Bitttymacod 1 década hace [en]

{translate}

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.

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.

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.

-- With respect,

---

#11 Añadido por Elweit(arispotle) 1 década hace [en]

{translate}

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

-- With respect,

--Every time with respect

#12 Añadido por Maeilye(arispotle) 1 década hace [en]

{translate}

The CAPTCHA mechanism is the single most annoying feature I have seen ever. Period. It is a pain to type in, and I don't feel like I should -ever- have to prove I am not a bot by typing in a silly code, its bad enough on website confirmations. It also cheapens the feel of a game... "wow bottings a big enough problem in this game there is a CAPTCHA mechanism, should i even continue to play??"

There are many ways to avoid that evil mechanism through coding and other methods, that to use this is plain silly. If it means no pause, tempselect, whatever in macros -ever- so be it, much better then a CAPTCHA mechanism.

#13 Añadido por Jarnys 1 década hace [en]

{translate}

I don't see the switching of bars as a problem, but the TEMP select (of team member only) sounds interesting though. (Emergency back heal from melee to caster)

The sticky extra bar should be enough to accommodate for the emergency actions (is it possible to use these in a macro? If not adding this feature would be the best option in my opinion)

---

Btw. I myself have never really needed the extra sticky bar (never activated it) and don't even need macros that change the bar somehow. My concept is like this:
Bar x = healing actions (incl. self heal)
Bar x+1 = melee actions (+ self heal and auras)
Bar x+2 = special melee actions (used only in very few situations)
Bar x-1 = ele actions (+ self heal and auras)

Bar Y = harvest actions (+self heal and auras)
Bar Y+1 = crafting actions + special harvest actions
Bar Y-1 = some old heal actions mixed with random stuff

The other 4 bars have just some random stuff (could be cleared out fully with no further problem) and this setup has allowed me to change to a special or shortly needed action with just a small flick of the scroll wheel, click on it and scroll back.

---

#14 Añadido por Bitttymacod 1 década hace [en]

{translate}

Maeilye

The CAPTCHA mechanism is the single most annoying feature I have seen ever. Period. It is a pain to type in, and I don't feel like I should -ever- have to prove I am not a bot by typing in a silly code, its bad enough on website confirmations. It also cheapens the feel of a game... "wow bottings a big enough problem in this game there is a CAPTCHA mechanism, should i even continue to play??"

There are many ways to avoid that evil mechanism through coding and other methods, that to use this is plain silly. If it means no pause, tempselect, whatever in macros -ever- so be it, much better then a CAPTCHA mechanism.

Amen!

I play a browser game with Captcha. ACK!

In fact as currently coded, Ryzom has a very low incidence of botting because it takes a lot of effort to bot, and there isn't much to gain by it.

---

#15 Añadido por Elweit(arispotle) 1 década hace [en]

{translate}

Well... you told about the problem ("it *might* make macros *too* powerful and subject to abuse/botting") and I suggested a possible solution... *IF* it's a real and so big problem. ;)
I don't like CAPTCHAs too. :D

Last visit sábado 30 noviembre 21:15:37 UTC

P_:G_:PLAYER