Some multiplayer questions - could someone please educate?

I went through all the tutorials in detail on multiplayer and have few questions. Will be great if someone could please answer them -

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

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

B. Send message with peer data within the message

C. Use Sync variable

2. Can we set client input state on any event inside peer group OR should it happen only on multiplayer - on client update event?

3. Why cant we not specifiy a boolean type variable in sync variable ? The sync variable dropdown doesnt show boolean variable of the object.

4. Difference between PeerId and MyId

I went through all the tutorials in detail on multiplayer and have few questions. Will be great if someone could please answer them -

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

A. It think this is wrong, it should be Multiplayer.PeerState (AssociatedObject.peerid, "<variable>") sequence

B. Refer to my reply in your previous thread.

C. Refer to my reply in your previous thread.

2. I have no comment on this, but I think if you use outside of the on client update, it's either having no effect on host or it works like a trigger. I haven't test this out, probably do this on weekend.

3. This has something to do with the 8bit=1byte excerpt. I don't remember where I read it from.

4. MyId is always the client user Id, while peerID will be the peer that involved in the triggered event.

Thanks —

For 1.A, this is what I have and it doesn't work...

[attachment=0:4mpe50mq][/attachment:4mpe50mq]

This isn't working precisely, just a demo.

kmsravindra I think you still need at least one "OnClientUpdate" to communicate your input.

The thing I'm unsure of if it is used outside the "OnClientUpdate" whether will it still update the host if "OnClientUpdate" events is placed after "SetClientInput".

kmsravindra You still need at least one "OnClientUpdate" to communicate your input.

The thing I'm unsure of if it is used outside the "OnClientUpdate" whether will it still update the host if "OnClientUpdate" events is placed after "SetClientInput".

Multiplayer is ready for input

> On client update

Edit:

[attachment=0:3w4iwg40][/attachment:3w4iwg40]

Well something like this... sorry I use touch, not mouse

Multiplayer is ready for input

> On client update

I'm curious what will happen if you remove on client update, and just leave the ready for input.

I don't quite remember, but I think "is ready for input" is used by host, undoubtedly I need to revisit this one.

> Multiplayer is ready for input

> > On client update

>

I'm curious what will happen if you remove on client update, and just leave the ready for input.

Just disabled

Lol, it works same... learnt something, can that be right?????

I was using it as a safety check...

Edit

[quote:25wlx59l]Is ready for input

True when a peer is ready to send input to the host. This means On client update has triggered at least once, or is about to trigger. Do not allow players using input prediction to move or act before this condition is true or On client update has triggered: doing so will simply cause an input prediction error since the host is not yet ready to receive input.

On client update

Triggered when a peer is about to send its input state to the host. The input state should be updated in this trigger using the Set client state action.

So "Is ready for input" is the better way then... I was just using it to avoid an input prediction error, but it looks like they both work

Just disabled

Lol, it works same... learnt something, can that be right?????

I was using it as a safety check...

Ah if it works the same, the "On client update" is not needed at all, that should invalidate my statement [quote:1k1fm7i6]"You still need at least one "OnClientUpdate" to communicate your input"

I guess the "On Client Update" is still a mystery to me.

So "Is ready for input" is the better way then... I was just using it to avoid an input prediction error, but it looks like they both work

I don't remember how I used "is ready for input" before, it might not be necessary at all for that event. I still think the sync is already started on start layout. Can you check what'll happen if both onclientupdate and isreadyforinput is removed?

I guess the "On Client Update" is still a mystery to me.

You and me both...

Ok, so does it work when even the "is ready for input" is also removed and some other event like "on touched object coin" is used instead? My question is - "is ready for input" OR "on client update" one of these is necessary to communicate?

on another note, I am trying to work on this scenario --> As a peer/host , lets say I want to create a coin whenever I double click...And each coin could be moved around only by the peer who creates it....if you have some ideas then let me know

My question is - "is ready for input" OR "on client update" one of these is necessary to communicate

Probably not, it's a bit unclear on when it is necessary, so test test and test, that's what I'll do.

I am trying to work on this scenario --> As a peer/host , lets say I want to create a coin whenever I double click...And each coin could be moved around only by the peer who creates it....if you have some ideas then let me know

The host will still be the one who creates it, but to differentiate it, you have to associate them with peer or, store the peerid into instance variable, and structure your conditions based on that to disallow selection from non-creator peer.

Ok, so does it work when even the "is ready for input" is also removed and some other event like "on touched object coin" is used instead? My question is - "is ready for input" OR "on client update" one of these is necessary to communicate?

on another note, I am trying to work on this scenario --> As a peer/host , lets say I want to create a coin whenever I double click...And each coin could be moved around only by the peer who creates it....if you have some ideas then let me know

It appears so, but the "is ready for input" is very important because it stops an input prediction error from firing if the client isn't able to input for whatever reason.

For Ashley:

I myself now have to go play around... Ashley can we just use "is ready for input" as it does the same as "on client update" doesn't that make "on client update" obsolete?

The Mp INPUT example I add the peerid to the coin, so only if your id = the instancevariable peerid can you move it. So pretty straight forward. So when creating, add the users id to that token.

edit;

Agggh overposted. What Duckfaceninja said - has to be done via host

Great! I got this working....To distinguish the peerid from a non-creating peerid, I had a global variable "creatingPeerid" that I set it in host upon creation of the sprite...Then I check in the next condition if the peerid is not equal to myID and peerid is not equal to creatingpeerId --> Then set sprite.x to Multiplayer.PeerState(Paddle.peerid, "x1") and sprite.y to Multiplayer.PeerState(Paddle.peerid, "y1") where x1 and y1 are client input states set to touch.x and touch.y in peer group...

Attached is the capx for someone wanting how it is done...it has some redundancies and the comments are not in place as I am trying to modify the pong example template directly....[attachment=0:3vhpvi5u][/attachment:3vhpvi5u]

One hitch is that I see some lag when I move the sprite on the peer side...it doesnt move instantaneously along with touch...Not sure how to get rid of that...Need to do more research...any thoughts please send them...

Some of my questions in the start of the thread remain as to when to use which method in propagating the information from peer to host ( DuckfaceNinja / — thanks here for your answers, but I think I need to gain some more clarity)...

Skimmed through... haven't much time, will look later.

You have a mix between touch.x touch.y and mouse.x and mouse.y choose one or the other. Touch is the same mouse as long as you don't need to use right button or scroll thingy.