Everade's Forum Posts

  • If it's supposed to be a classic tower stacking game, why don't you disable physics once the object has been placed?

    There's no need to further simulate physics with hundreds of stacked sprites, especially not for those outside of view.

    I would suggest:

    On collision -> wait till somewhat stabilized -> disable physics if stable

    So the next one falling down has a flat surface to work with.

    Unless that's your intent of simulating everything with accurate physics.

    However that's gonna be a tough one.

    Some hybrid physics might be better to simulate a long wiggly stick based on current height.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • I think the tutorial is pretty straight forward and fairly easy if you read yourself through part 1-4.

    Peer determines the overall Player object and counts for both, Host and Peer players.

    There's a great example included in both Construct 2 and 3 which comes with all the multiplayer basics and fits the tutorial given.

    The game loads specific Host Group events in case you're the first person to enter an empty room.

    All players following later up will load the Peer Group events.

    This is required for the Host to handle the Data being sent from the Peers to the Host since this is an authoritative Host scenario.

    So that's the only major difference between Host and Peer when it comes to the events.

    Your suggestion of using 2 sprites seperately (host and peer) isn't efficient and would require you to sync double the amount of data between players. In short: No that's a really bad idea.

    So the tutorial shows you sort of a best practice way which i can only recommend to follow.

    Checkout the example. Read all the tutorials again. Understand how data is being synced between Host and Peers. Then go on from there.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • If you sync an objext using NONE. That means that all Peers will automatically create the same amount of that specific object just like the Host has. Not the other way around!

    However without their position being synced. So they all spawn on the very same spot.

    Please share your capx file which shows us how your events are being setup.

  • You do not have permission to view this post

  • You have added the tag "animation" to the variable sync, yet this tag is nowhere to be found from any client input.

    I recommend to remove that tag from the Sync event if you don't use it.

    Multiplayer scenarios can be very complex, so without any .capx file, it's basically impossible for us to tell on how you handle Host and Peers accordingly.

    Otherwise please provide more information on your current state of how you're handling everything.

    Please note that:

    Sending client input from any Peer will ONLY send them to the Host.

    You in most scenarios you send only physical Keyboard/Mouse input to the Host.

    Then let the Host handle what's going to happen.

    And to reflect all actions to all Peers, you then forward this information from Host to all Peers.

    If you don't do that, you're most likely only going to see what's truly happening on the HOST side only.

  • My answer might be a little bit late but let me try to explain it to you.

    It's used to sync certain object variables, since you can't send them directly.

    So we use *Set client input state* event with a certain tag added to it to combine it with a variable sync.

    The Host will always recieve your Client Input.

    However in most cases, you want to Sync this recieved input information back to all the other Peers as well, so now you can use this tag, to sync an object variable according to the input recieved.

    Here's an example according to the Advanced Example from Construct 2/3.

    The Peer sends an INPUT STATE (which includes variable data)

    to the HOST

    So we send X and Y so the host knows our current position.

    At the top, we defined the input value tag lookx and looky (these are the ones we're sending to the host)

    And the 2 Sync variable events, is the information we're syncing back to all the other Peers.

    So we're directly syncing a specific Object variable to all other players!

    The tag is now used, to basically BIND the input value tag, and the Sync Variable event together.

    So the information recieved from the client input value is written into the variable sync, and sent back to all the players.

    Hope it helps

  • You do not have permission to view this post

  • You do not have permission to view this post

  • rayolf

    I don't have that file anymore.

    If you're really interested into this specific topic, then checkout the solution which worked for me as described a few posts back.

    You will need to use a custom "solid" code to be able to dynamicaly make objects "solid" or "non-solid".

    The official solid system from Construct can't handle this at all.

    Which means this solution works for Online - Isometric game using multiple, overlapping floors.

  • I think the Origin of your objects plays a role here.

    And of course the cell size.

    Although something looks really wrong in your example... Maybe Ashley should take a look at it.

    I've adjusted some things and it seems to work now.

    Although it still feels as if the pathfinding system is extremly slow.

    http://92.51.171.10/construct/pathfinding.capx