Some multiplayer questions - could someone please educate?

Discussion and feedback on Construct 2

Post » Mon Oct 13, 2014 11:29 am

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
B
84
S
20
G
3
Posts: 337
Reputation: 7,368

Post » Mon Oct 13, 2014 11:38 am

kmsravindra wrote: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.
kmsravindra wrote: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.
B
28
S
8
G
4
Posts: 553
Reputation: 4,914

Post » Mon Oct 13, 2014 11:43 am

kmsravindra wrote: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
You think you can do these things, but you can't, Nemo!
Just keep reading.
Just keep learning.
B
65
S
16
G
9
Posts: 1,429
Reputation: 12,708

Post » Mon Oct 13, 2014 12:48 pm

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....
TestMP.capx


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 / @DUTOIT- thanks here for your answers, but I think I need to gain some more clarity)...
You do not have the required permissions to view the files attached to this post.
B
84
S
20
G
3
Posts: 337
Reputation: 7,368

Post » Mon Oct 13, 2014 1:51 pm

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.
You think you can do these things, but you can't, Nemo!
Just keep reading.
Just keep learning.
B
65
S
16
G
9
Posts: 1,429
Reputation: 12,708

Post » Mon Oct 13, 2014 2:11 pm

The Multiplayer manual entry accurately describes what 'Is ready for input' does. Is there something else about it you were wondering?
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,464


Post » Mon Oct 13, 2014 2:18 pm

@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
B
84
S
20
G
3
Posts: 337
Reputation: 7,368

Post » Mon Oct 13, 2014 2:36 pm

Ashley wrote: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"?
B
28
S
8
G
4
Posts: 553
Reputation: 4,914

Post » Mon Oct 13, 2014 3:04 pm

Ashley wrote: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 :)
You think you can do these things, but you can't, Nemo!
Just keep reading.
Just keep learning.
B
65
S
16
G
9
Posts: 1,429
Reputation: 12,708

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: 99Instances2Go, chleep, kebaboom, mehrshadfarahani and 2 guests