oosyrag's Forum Posts

  • For a larger set of data, I would use an array, with an instance variable to store the picked value. Upon randomly selecting an index, delete it out of the array, and store the value in the instance variable. You can push it back into the array when the next value is chosen.

  • Functions don't preserve picking, so you're selecting all spheres as it is right now anyway, which may be your problem.

  • I'm not sure if loopindex works with For Each?

    Try using Repeat (or For) sphere.count times instead.

  • First thing that comes to mind would be to have different animation frames as the card in each deck, then it's simple enough to progress to the next animation frame.

    Proceeding to the next deck would be on trigger, if current card = deck size, destroy current deck and create next deck.

    You can also use the advanced random plugin with permutation tables to keep track of shuffled decks if you want.

  • I don't even see any sprite scaling in the example given, so the simplest approach would be to have the sprites orbit, and sort z-order by y position.

  • construct.net/en/make-games/manuals/construct-3/system-reference/system-actions

    Set canvas size

    Set the size of the canvas area in the page, if appearing inline to the page (i.e. a fullscreen mode is not used). If a fullscreen mode is in use, this effectively changes the size of the Viewport size project property, which adjusts the size of the viewport.

  • Do you have the correct object picked when running on start of layout?

  • What arguments are you sending to the function on start of layout?

  • construct.net/en/forum/construct-3/general-discussion-7/report-bugs-amp-post-128538

    However, there are so many things that can be done wrong in a multiplayer project that are not necessarily intuitively incorrect that I'm pretty certain it isn't a bug.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • An alternative way to handle this is with the drawing canvas object to take a snapshot of the previous sprite texture. The drawing canvas can keep the name or index of the sprite in an instance variable to assist in picking.

  • The scroll to is updating the position of player2's viewport every tick. Before it updates, all objects are moved the difference between player 1 and 2's positions, saved to the canvas to take a snapshot, then moved back. This all happens within a tick, so no movement is actually displayed to the user. The viewport scroll to is then updated to player2's position for the next frame.

  • Not really understanding what you want.

    Just import the single image you want into a sprite object then.

    You can also set animation speed to 0 in the animations editor.

  • You can use the system expression tokenat(src, index, separator).

  • Physics is as good as you know how to handle the physics object and your understanding of how actual physics works to apply them to your game mechanics.

    Note that there are two stepping modes, dt, or framerate independent which is non-deterministic (may be bad for precision), and fixed, or framerate dependant, which is consistent but will run at different speeds at different refresh rates.

    You should not be using other behaviors such as solid or bullet with physics. They will absolutely cause problems.

    Often people end up realizing didn't need a full physics simulation to begin with for what they were trying to do, and would be better served by other behaviors and game logic/mechanics.

  • Syncing projectiles is a pretty frustrating topic for networking code. I've attempted to tackle similar problems a few different ways, each with their own issues.

    One way I've tried is to have the actual synced projectile object invisible. Each peer will create their own visible sprite for the projectile locally, that is not synced but should behave synchronously. It can be accelerated towards the actual (invisible) synced projectile over time, to fudge latency. This is in effect putting a second layer of local input prediction and interpolation net code on top of the built in one, but you get a little more control over how you want it to appear for each peer. It is a tradeoff between "looking right" when network conditions are good and desync artifacts when network connections are bad.

    Another way is to delay the destruction of the projectile. You can simulate its destruction with an animation or setting it invisible and disabling its behaviors/events, but this gives peers some time to catch up before it actually gets destroyed.

    The last way I've tried is to simply not sync the projectile at all, only the input and the result. Let each peer display what it thinks should have happened to the projectile. This works best when you can fudge the visuals and precision isn't as important, so probably not the best for a top down tank game.

    One fairly common method that doesn't work with the built multiplayer object's method of syncing is to run a lockstep simulation, where everything is deterministic and can be recreated accurately on each peer. There are pretty much always syncing issues that build up over time due to the differences in hardware though, so corrections are made periodically by peers checking in with the host. I think this works best when input lag is acceptable (no local input prediction).