re-working the Macro plugin to be even better and more useful

[allanon]

Pros of Macros vs Plugins

• Delayed execution: running each line on different AI cycles, without losing context.

Pros of Plugins vs Macros

• Multiple concurrent code sequences (generally triggered by commands and hooks) working together to achieve a common goal.

Adding delayed execution to plugins might be possible with something like Coro or a source filter, but such things are likely to break as the language evolves.

Adding concurrent code sequences (ie, the ability to run another macro while a macro is running) should be totally doable.

Suggestion

• Move all macro plugin globals into the AI sequence, so multiple macros can be executed without destroying each others' state.
• Possibly provide a way to wake up a paused macro via another macro command, so that a macro can wait for a hook.
• Possibly provide a direct way for a macro to wait for a hook to be called (but I worry that doing so would add a lot of conditional code into the main execution path of the macro).
• Allow macros to run without an AI sequence. (Or maybe a "hidden" AI sequence?)

Open Questions

• Should macros share any state? Eg, what about variables? Should there be a new syntax for "global" variables? Or a new syntax for "local" variables?

Example

macro quest_killcount {
  $quest_id = $.param1
  $quest_map = $.param2
  $quest_monster = $.param3

  # Go to the given map and kill the given monster.
  do conf lockMap $quest_map
  do conf attackAuto 2
  do mconf $quest_monster 1

  # Hide our AI sequence so that the normal AI will take over.
  # The macro must keep running in the background, even though the AI sequence is gone.
  hide_ai_sequence

  $complete = 0
  while ($complete = 0) {
    wait_for_hook quest_update_mission_hunt
    $complete = @eval( quest_complete($quest_id) )
  }

  # Take over the AI again.
  show_ai_sequence
}

sub quest_complete {
    my @questIds = @_;
    my $ncomplete = 0;
    foreach my $questId ( @questIds ) {
        my $quest = $questList->{$questId};
        next if !$quest;
        next if !$quest->{active};
        my $complete   = 0;
        my $incomplete = 0;
        foreach ( values %{ $quest->{missions} } ) {
            next if !$_->{goal};
            $_->{count} >= $_->{goal} ? $complete++ : $incomplete++;
        }
        $complete++ if $quest->{time} && time >= $quest->{time};
        $ncomplete++ if $complete && !$incomplete;
    }
    return $ncomplete;
}

[Henrybk]

Well, I'll try to list some problems of macro plugin and try to propose solutions to them.

1- It rechecks all automacro keywords each cycle, which is tremendously cpu intensive.
proposed solution: Get totally rid of 'AI_Pre' hook in automacro checking, instead hook everything else that would change something we want to know of. Example of an automacro and it's hooks below.
automacro equipStuffForBradeGrounds { quest 7122 inactive inventory 13040 = 1 equipped rightHand not 13040 location new_1-3, new_2-3, new_3-3, new_4-3, new_5-3 call TalkAgainToBrade }
Hooks: inventory_item_added, inventory_item_removed, quest_added, quest_removed, item_equipped, item_unequipped, map_loaded.
(Hook names not right, just wrote them out of memory)

2- Macros are not parsed until execution, which, again, is tremendously cpu intensive and makes debugging REALLY hard.
proposed solution: Parse all macro lines in the files loading, and if any erros are found, kill the instance, we don't want to have something ad important as macros running with erros.

3- We don't have support for global | local variables, all we have is globals.
proposed solution: Add support for it (lol)

4- We list support we have in macros is (really) bad, and hash support is even worse (varvar?).
proposed solution: Add perl-like support for arrays and hashes.

5- We have lots of functions in macro which are almost equal to checkSelfCondition
proposed solution: Find a way to integrate checkSelfCondition on macro plugin.

6- The support for loops is not really good, it exists though.
proposed solution: Add support for perl-like loops (while and for?, continue, next and last also)

7- There's no way of pausing a macro without totally interrupting it

8- There's no support for everlasting variables (continue existing after instance is closed, should we have it?)

9- There's no support for concurrent macros.

10- The parsing of automacros is really bad, there's no error message on duplicate keywords and duplicate names.

11- There is no separation between automacro 'conditions' like job, location, and automacro 'parameters', like exclusive and run-once.

12- We have support of if, elsif and else, but also to goto and label, isn't this unnecessary?

Also, our sintax is not really good, should we use semicolon or something else and make the parsing character wise instead of line wise?

[kaliwanagan]

I'm all for this. What do we need to do to get this rolling?

[Nipodemos]

I guess that with eventMacro we can close this issue... right? ( although there is a few things that werent implemented yet )

[Fadreus]

guess that with eventMacro we can close this issue... right?

No love for old macros.
Sob sob..
Welp, the only reason I stick to macro is because of condition console .
Too lazy to write long script, console is my love 😄

[Nipodemos]

No love for old macros.
Sob sob..
Welp, the only reason I stick to macro is because of condition console .
Too lazy to write long script, console is my love

hahahahahahah
i also have this lazyness but i still love eventMacro even whithout console condition

[Nipodemos]

closing since we have now eventMacro