[behavior] rex_bCmdqueue (command queue)

rex_bCmdqueue - command queue

For example, "action:set target XY" in moveTo behavior will set the target position by latest action. User could pend target position by this command queue behavior, to assign next target position while "condition: on hit target".

Command queue with ping-pong repeating

Add "Expression:CmdToString", "Action:Load JSON commands", "Action:Load CSV commands". See document for more detail, sample capx files are included.

Queues - wow, that plugin will be super useful when ready.

xoros

It is almost ready. I am waiting for suggestion.

rexrainbow

just tested your plugin and it's great as it is, but as for suggestions:

1. A new repeat mode: Random. So it jumps through the queue positions randomly (for some unpredictability)

2. Action: insert. So it will be possible to add a parameter at any position of a queue (Another question is how to determine this position? May be with position index)

xoros

Thanks for these suggestions.

I had added somethings in this behavior,

"Action:Insert at": Insert command at specific index.

"Action:Set next index": Set next index for "action:Next". Input a random number to start at random position.

See the document for more detail.

User might want to have a single command handler for all rex_bCmdqueue behaviors if there has more then one rex_bCmdqueue behavior.

So it might be better to have a standalone command handler behavior (or said function behavior). I will try it.

Or using official function plugin, but shift all parameters down, and assign param(0) to be UID.

For example , passing param(0)= 3, param(1)= 10 to function object, the received parameters will be (UID, 3 , 10).

Hum... it might be better I guess.

Great. This will be a killer plugin. I'll tinker with it some more and may be come up with something.

xoros

Okey, I had added this feature into this behavior called "global command handler".

This is a sample capx. See the document for more detail.

In mutli- command queues case,

The firing of command handler is done by "global command handler".

The next question is - which command queue should be poped (get next)? Hah...

rexrainbow

May be it will be better to introduce a unique identifier for each queue.

On default the identifier is not specified and it will trigger all objects and instances with that behavior (as it was in the first version).

Set Parameter - make an option: "make queue unique" and it will use UID of the object/instance as an identifier.

Action:next/pop can use object's uid for that speciafic object or use default value for all queues

xoros

It means that a behavior supports multi queue, more complex for operating, I might not try it, even it is a good solution. Another stupid solution is using variable to identify the queues.

Yes, I think the behavior is already very good as it is. I will be using it a lot.