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

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

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

Was just an idea. Actually I have to try spriter.

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)

Yes I mean "pin to image point" - I guess, it will be simple way of creating a rag doll like behavior without physics

This one will be also very useful - e.g. for simple ragdolls.

rexrainbow

Would be cool to include all pinning options like rope style and bar style.

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

Cool!

Hello there,

Ashley

I don't know what is the correct way to solve the following problem:

• A multiplayer game, where 2 players battle against each other taking turns (like in FF) = room peer limit 2
• 3rd (and so forth) player joins the room, but it's already full
• a new room is created and the player waits for a next opponent to join
• next opponent joins the newly created room
• and so on

Here how I solved the problem:

• Room_Name is a global variable (not constant) which holds a number 1 on default
• The first and the second player joins the room 1
• Third player tries to join the room 1, but it's full (onErrorMessage "room is full")
• Third player iterates the variable Room_Name+1 and joins the newly created room
• Fourth player does the same

So far it works, but I don't know if it's healthy for a signalling server. May be there's a better way to do it? And what will happen, if like 100 players use this auto join logic?

rexrainbow

Thank you very much

Yes, I noticed that syncing multiple units which represent a peer could get tricky, especially if you use local input prediction. There's a strange movement artefact, like units are slowly moving to their destination places.