oosyrag's Forum Posts

  • AFAIK socket.io is a is library for websocket, similar to how the construct websocket plugin is for websocket. Their purpose is analogous, and there shouldn't be much difference that the node.js server cares about.

    I believe you can utilize socket.io with an add on or the scripting feature directly, but I'm not familiar with that.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It can be that your character animations have different collision polygons, causing strange behavior.

    Try using a square invisible helper sprite as a base for collisions.

  • Put your distance() expression inside a min() expression like so...

    min(distance(a,b),y) where y is the maximum you want. The min expression will take the smaller of the two numbers.

  • It's probably networking issues that can be resolved with a TURN server rather than any compatibility problem between pc and mobile.

  • construct.net/en/tutorials/supporting-multiple-screen-17/page-2

    See the section on keeping the ui in place and the anchor behavior.

  • cdn.discordapp.com/attachments/780147845151326229/790121973438480424/unknown.png

    Gamepad #1 is a Dualshock 4

    Gamepad #2 is a Dualshock 4 running through DS4Windows wrapper

    Mine also looks like #2, running a Dualshock 3 through SCP Server

    Not sure how to go about on android...

  • Perhaps if you upload a quick project that displays the returned value for detected controllers I can forward the link to a friend who has one and let you know what he sees.

    FWIW I'm using a dualshock 3 with an xinput wrapper, so the system sees it as an xbox controller. I think most games default to showing xbox style controls/tutorials. It would be nice to be able to choose manually in my case, sense autodetection would result in xbox style controls after all.

  • Even if you call it a real time game, as long as the players have no direct interaction with each other at any given time it is in effect no different than a turn based game. Which means syncing becomes a much lower priority, and you have tons of options to hide latency.

    Even if they do have to interact at some point though, it always helps to break down what information is most important to be consistent across players, and when is it necessary? Anything that has the potential to interrupt or change what is expected to happen from any players point of view needs consideration.

  • One option, given that player 2 doesn't actually know when player 1 hit the ball in real life, is to not send the shot information to player two until it's completed. Then you'd be able to send information about the complete trajectory and end location all at once for player 2 to replay, in a sense.

    Another option is to not sync the ball location at all. Let player two run his own simulation based on the input of player one, and then update the final location to the actual one upon (or right before) coming to rest, whenever that information is available. The difference should be mostly imperceptible if both users are running the same physics engine.

    Basically instead of syncing the ball location at all times, only sync it at key moments, wherever it would be most effective to hide latency (I imagine the final resting position is the only real value of importance here). You can even add an ease/lerp/tween upon syncing the final location, to hide any unnatural looking jumps that might occur.

  • If you want it to increment, you'll need set value at 0 to array at 0+x. You're setting it to array at 1+2, which never changes because you are not changing array at 1.

  • Post a screenshot of your events or right click and copy as text.

    Fwiw, as you described, array.(0) is incorrect and it should be array.at(0), but I don't know if you just typed it wrong here or if construct actually let you do that.

  • Option A. Don't even use the mouse over condition on the peer end. Let the host decide if the mouse was over the object or not.

    Option B. Don't worry about keeping drag and drop host authoritative and synced. Basically favor local input prediction and responsiveness over host authority, and have the host and other peers catch up to the current peer location instead.

    There is no way to remove latency in the real world. You just have to design around it, weather you decide to favor host authority or local authority is up to you. Designing netcode is all about how to best hide the latency from each party involved while preventing inconsistencies and conflicts.

  • I wonder if renaming the wait action to something like "Delay following actions" might help reduce confusion.

    And/or a tooltip maybe in the description that explicitly states that it does not pause event execution.

  • Use an instance variable, put the UID in that.

    Or put the sprite and array in a container so that when you pick (and create) the sprite the correct array is also picked.