Peer's getting stuck on 'Ready for Input'

Post reply
0 favourites
  • 7 posts
From the Asset Store
Antisuspend Plugin
$9 USD
Antisuspend Plugin for Construct 3 prevents the runtime from getting suspended.
ppstudiomty's avatar
ppstudiomty

  • Hi all. I'm running into a weird error where the peers are indefinitely waiting for the 'ready for input' trigger from the host. At first I thought it might be that I deleted something important by accident, so I went to a really old back up and even this old copy hits the same problem.

    Has something recently changed in/on/with the signaling server?

    Here is a screenshot of the events where the peers are getting stuck. I can see that the peers are getting stuck at 'TP2_LO1_Progress = 10.11'. They are sitting there and waiting for the secondary 'Is ready for input' condition to trigger.

  • Some additional info on this;

    As far as I can tell, the host is able to see and seems willing to accept the peer into the room. It looks like nothing has changed on the hosts end. The peers alias, ID, etc is all getting picked up successfully by the host.

  • This is not the correct use of the "Is ready for input" condition, from what I can see only from the screenshot it serves no purpose here. Does it work if you disable that condition?

  • Yeah, I realized that after posting the screenshot. Really the only important part is that it gets stuck at:

    If TP2_LO1_Progress = 10.11 and Is ready for input

    When I disable the 'Is ready for input' condition, the peer is able to progress onto and gets stuck at the next condition:

    If Peer message Send_... and TP2_LO1_Progress = 10.12

    This is the reason why I put the Is ready for input condition there in the first place, to make sure the host is ready to receive and transmit the data.

    What is the correct way to use this condition?

    Why is there a communication breakdown between the host and the peer?

    Everything was working perfectly until a couple days ago. It is super strange because all my older backups are hitting the same issue in the same place.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Well, I just realized that I have been using the r248 release (beta). I must have updated without realizing. Anyways, I tried an older release and this issue goes away. So it must be something related to this beta release.

    The shitty thing is that it wont let me roll back my most current save, so i'm stuck working on r248 now.

    Is this something I should report to the Construct head honchos?

    EDIT:I was able to easily migrate all the recent progress into an older non-r428 save. So all is well with me now :)

  • It could be a bug, and a bug report would probably help, but only if you isolate the issue by itself with a minimal project.

    Similarly, I can't really answer your other questions from just a screenshot.

    Re ready for input from the manual:

    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

    My understanding is that it is used to sync up client input values and local input prediction.

    But it shouldn't have anything to do with messages. I'm not sure why it would break your project in the beta, it works as expected when I tested a minimal project. There is probably something else going on. Again, can't diagnose without seeing the whole thing.

  • Thanks for all your help and advice oosyrag! Yeah, I can see what you're saying now, that I am using it incorrectly. I will have a play with it and see if I can find another way around the problem.

    On the topic of the peer not communicating with the host, it was definitely related to the beta. You are right about it not being that 'peer ready' trigger, but I have no idea what else it could be.

    I may just leave this one to the experts.

    Again thanks for the trouble shooting! 🌠

    EDIT:

    I found the issue; the peers were waiting for a message from the host, which only triggers once. So if the host somehow misses the original message, then the peer is waiting indefinitely.

    Just wanted to own up and say, this was not a construct error in the new beta, but my own silliness.

Post reply
  • 7 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)