Replies: 1 comment
-
How about add an action called <Attack_Unit_then_Move(tag, screen)> as {'name': 'Attack_Unit_then_Move', 'arg': ['tag', 'screen'], 'func': [(12, F.Attack_screen, ('now', 'screen_tag')), (0, F.no_op, ()), (331, F.Move_screen, ('now', 'screen'))]}? This action may be useful for scenarios with high requirements for micro operations like SMAC tasks. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In version 0.1, we set the action <Attack_Unit(tag)> as {'name': 'Attack_Unit', 'arg': ['tag'], 'func': [(12, F.Attack_screen, ('queued', 'screen_tag'))]}, which directly call pysc2 function Attack_screen.
However, the pysc2 function Attack_screen('queued', 'screen') acts like a "right-click" on an enemy unit. Unless the target unit is dead, your unit will not use next queued actions, leading to difficulties in implementing micro-operations for Attack-Move-Attack-Move.
We initiate this discussion to see if everyone has suggestions for the Attack action design.
Beta Was this translation helpful? Give feedback.
All reactions