While I appreciate your reply, I think you misunderstood some aspects and your patronizing tone is less than helpful.
[quote:2vngnzy1]* You can get a Room list already.
Where? I see actions and values for INSTANCE lists, but nothing regarding rooms. If i've missed an available action I would love a pointer in the right direction on that as there isn't a manual entry yet and I see no mention of it in the 3 tutorials provided...
[quote:2vngnzy1]* PeerID are synced between player connections.
What does that mean? I know all clients are aware of all PeerID's as well as which are there own, but that doesn't help my situation.
To better illustrate WHY I wanted that feature let me explain the sitation:
1) A player places a booby trap on the host (via input sending of the Z key). To make sure the player can see that trap, the booby trap object is set to sync position so it will be auto-created on all clients.
2) Only the player who placed the trap should see it, but it needs to also exist on the host so the host can detect player collisions with it authoritatively. If the trap had a synced PeerID instance variable on it, it would be very easy to determine which trap objects should be visible or not.
I ended up working around this by sending a multiplayer message to the specific player client to place a trap object at his location. This presents a new problem as when the host destroys the trap via triggering it, how do I reliably tell the client who placed it to destroy that specific object instance? I can't use object UID's as those differ between host and client.
[quote:2vngnzy1]* Vars don't need auto syncing.
See the above problem. If I want to broadcast a message that an instance variable of instance #5 has changed, how do I make sure the same instance is changed on host and all clients without any consistent UID? The auto-syncing handles this for me. I'm not saying I can't work around this, but it's much hackier and I imagine Ashley's syncing functions are more reliable and efficient than my manual ones would be.
[quote:2vngnzy1]* As for rubber banding. that's a good point in regards for teleport. But that's an easy fix.
While I agree with your premise, the specific context is local input prediction combined with the wrap behavior. Especially when the local input prediction is combined with object acceleration. In this case I have flying airplanes, but you could get the same issue with a multiplayer version of asteroids.
You can try a slightly older buggier version of both games here to better understand:
The point of the plugin is to provide user friendly multiplayer features. If I wanted to do things the harder way I wouldn't be using Construct 2 in the first place would I? There's no shame in ASKING for features, I'm not demanding them.