Some multiplayer questions - could someone please educate?

The Multiplayer manual entry accurately describes what 'Is ready for input' does. Is there something else about it you were wondering?

DUTOIT, you are right...sorry for the confusion...Here is the revised capx with changes

Ashley, could you please give some reference help link on the below - I have gone through the tutorials but was not able to make out which one should be exactly used in what case...

1. Which method out of the below is preferred to propagate data from peer to host in multiplayer and in what conditions each of them is used ?

A. Set Client input state "<variable>" to something and then use Multiplayer.PeerState (Associatedobject.peerid", "<variable>") sequence

B. Send message with peer data within the message

C. Use Sync variable

The Multiplayer manual entry accurately describes what 'Is ready for input' does. Is there something else about it you were wondering?

For me I was wondering on what case should I be using it. I find myself never used this so far, I think this is of some use for network optimization but I can't really figure out how to fully exploit this.

For me the confusion is whether this condition should be checked by host or by a peer? (should be under host group or peer group?) I guess local testing doesn't give me distinctive result that would give an intuitive idea on how to correctly utilize this.

Another confusion is for the "on client update", this is a trigger, but what triggers it? Did the host send some signal to trigger this or, this is triggered on client side when the set client input is done? How frequent it triggers? Is this related to the excerpt "30 times on internet, 60 times in LAN"?

The Multiplayer manual entry accurately describes what 'Is ready for input' does. Is there something else about it you were wondering?

Sorry ashley...

I'm with duckfaceninja in querring under what conditions should we be using it. From what I understand, and the fact that it does what "On Client Update Does" and more... can use it all the time instead of "On Client Update" because both are true that client is about to update, or has updated. And "Is ready for input" has the added bonus of ensuring that we have no input prediction error.

Actually everything duckfaceninja said

1. Which method out of the below is preferred to propagate data from peer to host in multiplayer and in what conditions each of them is used ?

A. Set Client input state "<variable>" to something and then use Multiplayer.PeerState (Associatedobject.peerid", "<variable>") sequence

Use that for anything latency-sensitive, which is generally the buttons the peer is pressing, i.e. as the name suggests, input states.

[quote:2rfc2qr0]B. Send message with peer data within the message

Anything not latency sensitive, like chat messages.

[quote:2rfc2qr0]C. Use Sync variable

Not an option, because that *only* sends data from the host to the peer. 'Sync' never sends anything from the peer to the host.

[quote:2rfc2qr0][re: is read for input] For me the confusion is whether this condition should be checked by host or by a peer?

By the peer, because only peers send their input. The condition is very simple. Imagine setting a global variable to true when 'On client update' triggers. The condition just checks if the global has been set. If you allow the player to move before then, it will simply cause an input prediction error, because the host is not yet aware of your movement. It's pretty minor though - even if an input prediction error occurs, it will be corrected a few moments later.

[quote:2rfc2qr0]Another confusion is for the "on client update", this is a trigger, but what triggers it?

It fires 30 times a second to test the inputs, because that's how often messages are sent to the host (not 60, because that would use double bandwidth for little benefit). The frequency should not be important though. The trigger basically means "time to check what the inputs are, because it's about to be sent to the host".

Thank you very much ASHLEY. This clarifies lot of things

It's pretty minor though - even if an input prediction error occurs, it will be corrected a few moments later.

Ah good to know this, so the conclusion is this will see some use for fast paced games like racing. That's why it is a bit difficult to make test case, simply because the error is quite unnoticeable visually. Is the input prediction error logged into the browser console? I don't remember seeing any error with regard to it.

It fires 30 times a second to test the inputs, because that's how often messages are sent to the host (not 60, because that would use double bandwidth for little benefit). The frequency should not be important though. The trigger basically means "time to check what the inputs are, because it's about to be sent to the host".

Is this frame rate dependent and is it correct if I assume it fires every other tick? I wonder what will happen if one of the peer have a significantly slower device compared to others..

Is this frame rate dependent and is it correct if I assume it fires every other tick? I wonder what will happen if one of the peer have a significantly slower device compared to others..

i) That is my interpretation.

ii) Lag

And...

THANK YOU SO MUCH, ashley, that makes much more sense... really appreciate the clarification.

Is the input prediction error logged into the browser console?

No, because there is always input prediction error, it's just usually small enough to be unnoticeable. You can spot a serious input prediction error though by seeing if your player suddenly jumps somewhere else without you controlling it!

[quote:bisniz60]Is this frame rate dependent and is it correct if I assume it fires every other tick? I wonder what will happen if one of the peer have a significantly slower device compared to others..

It's intended to fire every other tick, but it is not framerate dependent (very few C2 features are). If your framerate drops to 30 it will send input every tick (which is the same frequency as every other tick at 60 FPS), and if it drops further below then input is simply sent less often. However the multiplayer engine is inherently designed to deal with missing data due to packet loss so this won't adversely affect the control, it will just make it a bit less accurate. The bigger problem is that the game is slow!

> It fires 30 times a second to test the inputs, because that's how often messages are sent to the host (not 60, because that would use double bandwidth for little benefit). The frequency should not be important though. The trigger basically means "time to check what the inputs are, because it's about to be sent to the host".

>

Is this frame rate dependent and is it correct if I assume it fires every other tick? I wonder what will happen if one of the peer have a significantly slower device compared to others..

As a sidenote, I think (well I saw, and that would just be logical..) triggers event are designed to work outside the normal event reading state, they can happen anytime, not just during tick normal checks of the entire event sheet, it is like events are verified every tick, but triggers just happen.

Does anyone know how do I make drag-drop behavior on sprite work in multiplayer...Having this behavior on sprite doesnt have any influence as a Peer...Only on host it moves...Is it that I can move on peer side only using client input state variables / sync approach..? Behaviors on objects are not sync'ed?

Edit - I guess this is the answer from manual - It is important to disable any behaviors and deactivate any events on the peers that may attempt to move the objects themselves; this will conflict with what Sync object is trying to do, and will not have any effect on the host.

So does this mean any behavior that alters the positions doesnt work on peer? Because Pong example uses Solid behavior and it works both on peer and host...could someone clarify?

> Is the input prediction error logged into the browser console?

>

No, because there is always input prediction error, it's just usually small enough to be unnoticeable. You can spot a serious input prediction error though by seeing if your player suddenly jumps somewhere else without you controlling it!

[quote:2jxb63o5]Is this frame rate dependent and is it correct if I assume it fires every other tick? I wonder what will happen if one of the peer have a significantly slower device compared to others..

It's intended to fire every other tick, but it is not framerate dependent (very few C2 features are). If your framerate drops to 30 it will send input every tick (which is the same frequency as every other tick at 60 FPS), and if it drops further below then input is simply sent less often. However the multiplayer engine is inherently designed to deal with missing data due to packet loss so this won't adversely affect the control, it will just make it a bit less accurate. The bigger problem is that the game is slow!

Great! Thanks for the info!

kmsravindra - the client input state is the only low-latency way of telling the host what you are doing. So it sounds like you want to set the object's x and y position as the client input values. Then it will move on the host. The peer will see it with lag, so you can simply display it at the mouse position instead of syncing to hide the lag.

Thanks ASHLEY. That technique worked! Now I am trying to add a textbox to each sprite and move it along with the sprite in multiplayer mode...The way I went about it was by adding a container textbox object and tested it..However the textbox doesnt move along with the sprite...Looks like sync doesn't sync container objects? Do I need to repeat the same code that I did for sprite to move the textbox as well?

Edit - I think I got the answer in the forums from Ashley's response to one of the bug - "Closing as not a bug. You only sync one of the objects, so the other object in the container will be created, but not synced".

But I couldnt understand why sync - position cannot happen on container objects...wont that be a good/required feature?