implementing action processor

[Nostrademous]

This is a start of implementing a system for easier addition of various commands and the ability to send multiple commands to a bot.

Currently supports same code as before (plus some more if the messages are sent).

[TimZaman]

Related to #39

Some stuff:

• Multiple actions
  Entirely ok with me, as the proto supports it:, eg
  repeated .CMsgBotWorldState.Action actions = 2;
• Speed
  It's a tad more overhead but I don't see any red flags really.
• Structure
  Looks excellent as you've made it.

The only thing I wonder, is how we can make the debugging of things prettier. Currently, the debug visuals are written on 1 tick. It would be really awesome if we could make them persist until the next debug frame. I am worried the proposed structure could make this more complicated. See what I mean? Suggestions?
Other than that, great pr.

[Nostrademous]

Related to #39

Some stuff:

• Multiple actions
  Entirely ok with me, as the proto supports it:, eg
  repeated .CMsgBotWorldState.Action actions = 2;

Yeah, I thought the same thing.

• Speed
  It's a tad more overhead but I don't see any red flags really.

I haven't noticed any speed degradation running locally honestly. In reality, I think I noticed a slight speedup when I switched to my dotaworld module inside the agent, but that's a whole separate thing.

• Structure
  Looks excellent as you've made it.

I would have preferred not having to transforming protobufs to Lua nested tables to make the action processor be argument count based (meaning this stuff here: https://github.com/TimZaman/dotaservice/pull/40/files#diff-1dc9657ec8a150b40c6d3350a3b2e7c9R15) but I think it's okay.

The only thing I wonder, is how we can make the debugging of things prettier. Currently, the debug visuals are written on 1 tick. It would be really awesome if we could make them persist until the next debug frame. I am worried the proposed structure could make this more complicated. See what I mean? Suggestions?

Would have to implement our own debug draw class that re-draws every frame until a new draw event comes in.

Other than that, great pr.

Thanks

[Nostrademous]

By the way, it is worth pointing out that under-the-hood my implementation works a tiny bit different than how yours worked.

Example:
in your code the "DOTA_UNIT_ORDER_ATTACK_TARGET" would check for attack distance range and only do the action if within range. In my code, we do the action regardless of if we are in range or not. In the Dota2 world - you can right-click attack a target across the entire map and it is valid... just under the hood the behavior is "move into attack range, then attack" - which is what I'm allowing now.

[TimZaman]

The massive problem with that is that the bots will not learn to do anything else than walking up to creeps. There isn't any incentive for them them to use proper movement.

…

On Wed, Jan 16, 2019 at 9:35 AM Nostrademous ***@***.***> wrote: By the way, it is worth pointing out that under-the-hood my implementation works a tiny bit different than how yours worked. Example: in your code the "DOTA_UNIT_ORDER_ATTACK_TARGET" would check for attack distance range and only do the action if within range. In my code, we do the action regardless of if we are in range or not. In the Dota2 world - you can right-click attack a target across the entire map and it is valid... just under the hood the behavior is "move into attack range, then attack" - which is what I'm allowing now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHXSRO3Tpm_KISrF1vEtadGCuS7yWjtwks5vD2LHgaJpZM4aCYJj> .

[Nostrademous]

Implemented "DOTA_UNIT_ORDER_BUYBACK" and "DOTA_UNIT_ORDER_STOP"; bumped version to 0.3.4; removed a DebugPause() I had in there since we would never want to do that in a distributed env; actually wrote pass-through code into generic_bot.lua for allowing all the new DOTA_UNIT_ORDER functions.

Something on the agent-side just has to send them now.

[TimZaman]

Feel free to make any more updates you want until tonight (PST), i'll review, test and merge the bunch then. Nice stuff.

…

On Wed, Jan 16, 2019 at 12:33 PM Nostrademous ***@***.***> wrote: Implemented "DOTA_UNIT_ORDER_BUYBACK" and "DOTA_UNIT_ORDER_STOP"; bumped version to 0.3.4; removed a DebugPause() I had in there since we would never want to do that in a distributed env; actually wrote pass-through code into generic_bot.lua for allowing all the new DOTA_UNIT_ORDER functions. Something on the agent-side just has to send them now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHXSRIuj84oHrgPilOG1HG_3faT4lyXbks5vD4yIgaJpZM4aCYJj> .

[Nostrademous]

Okay, I added ability use functions for targeting of "entities, locations, trees".

We really should only allow legal actions by the agent though.

[Nostrademous]

okay, added UseAbility and ToggleAbility actions - that should cover all the action types.

need to test them now by having agent some of them over to see that they work (after we level the ability)

[TimZaman]

🎉

[TimZaman]

Removed some of your debugging printing. Going to slap a few commits on top