Fire delay when looping through gamepads?

0 favourites
  • 13 posts
From the Asset Store
6 looping tracks to use in your games and projects. These tracks are in the style of the 1960s detective movie genre.
  • I have a local multiplayer game I've been working on, but have hit a wall on a bug for players firing projectiles using gamepad analog sticks.

    Basically, I have a variable on each player that contains a playerID that corresponds to a gamepad. If the right analog stick is about a value, the player should fire at a set firing rate.

    The problem I've run into is that it only seems to work for the lowest-numbered player/gamepad. That is, if player 1 is firing, players 2-4 can't fire. If player 2 is firing, players 3 & 4 can't fire.

    Here's the event sheet below:

    <img src="https://dl.dropboxusercontent.com/u/14245368/firedelay_01.jpg" border="0" />

    Note that the playerShooting events are for testing purposes to see if an individual player is firing. It shows that they are, yet the issue with firing remains so long as there is a delay. If I remove the delay, however, all players can fire individually, so it's something to do with the "every x seconds" event, though I can't think of a better way to do the delay.

    Any hints or suggestions would be greatly appreciated. Thanks!

  • Seems like if could be the OR block. For example, if Player 1 is firing, the first condition in the OR block is met, so it won't continue going through the OR block to see if the other players are firing. That's why Player 1 can probably fire if 2-4 already are, and all players can fire is Player 4 is (assuming they start in reverse order: 4, then 3, then 2, then 1).

    Make each one a separate condition and see if that works.

  • Thanks That's exactly what I was trying to avoid having to do, but if that's what it takes, so be it. Also, it does work properly when there isn't a delay between spawning the projectiles, so...that's weird.

    I was hoping the For Each block would handle each player separately, as that's how I thought it was supposed to function...maybe that's not the case?

  • Give it a try and let me know how it works out. I'm not 100% on it, but it makes sense that that's what's going on based on my experience with general programming (it's doing what an OR block should do - if one of the conditions is met, it should ignore every condition after it and execute the block).

    Tip: Make a function for all the stuff that the current block you have is executing. Then you can just call the function instead of having all that code repeated for each player.

  • Still the same issue, plus I've just ended up with duplicated code. I think I just need to find another way to do the delay, hopefully without recreating the events for every potential gamepad.

    Oddly, doing player movement in the exact same way works perfectly, as does creating projectiles without any delay between them - it's just anything with a timer on it that breaks.

    Tip: Make a function for all the stuff that the current block you have is executing. Then you can just call the function instead of having all that code repeated for each player.

    The way it's working now doesn't have it duplicated for each player, and I'm pretty sure calling a function every tick for each player to check for continuous input wouldn't be any more efficient than the way it's set up in the OP.

  • Bumping this in case anyone else has any ideas on what the issue may be.

  • The for each and every x seconds are probably somehow in conflict.

    why not give each player a timer behaviour and add an on timer function instead. The engine will check every tick for each player if the timer is ended, if so you set the timer again for player.projectilerate seconds.

  • Also putting the every x seconds condition above the or-block could make a difference, but I'm not completely sure about that.

  • Also putting the every x seconds condition above the or-block could make a difference, but I'm not completely sure about that.

    The OR block is for player input that should be checked continuously, so I don't think it'd make sense to reverse that. Tried that originally, but I'll try the local timers suggestion - thought about it, wanted to avoid it, but it's better than it not working. The issue seems to be linked to the every x seconds, since it works fine without any delay in place.

    Thanks!

  • Why would the or block have to be checked every tick, when it can only affect anything every player.fireratio seconds?

    Or are you planning to add more code to the block?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Why would the or block have to be checked every tick, when it can only affect anything every player.fireratio seconds?

    Or are you planning to add more code to the block?

    Yep, the second one. Also, since the player can begin firing at any time, having the gamepad input checked in the OR block under the timer could mean a delay in the projectile firing.

    I tried mapping this player input control to a button, and it works fine with the timer (without setting the projectile direction, obviously) - but not the analog stick. I'm almost wondering if it's a bug in the gamepad controller behavior now.

  • The OR block seems fine to me.

    Instead of Every X Seconds try giving the Player a new variable (Player.CanFire boolean start true) and check/set that when they fire.

    for each Player

    check gamepad OR block

          if Player.CanFire == true then

            Set Player.CanFire = false -- so they can't fire again yet

            Do your normal firing stuff

            Wait Player.projectileFireRate seconds -- adds delay between firing

            Set Player.CanFire = true -- lets player fire again

  • The OR block seems fine to me.

    Instead of Every X Seconds try giving the Player a new variable (Player.CanFire boolean start true) and check/set that when they fire.

    for each Player

    check gamepad OR block

          if Player.CanFire == true then

            Set Player.CanFire = false -- so they can't fire again yet

            Do your normal firing stuff

            Wait Player.projectileFireRate seconds -- adds delay between firing

            Set Player.CanFire = true -- lets player fire again

    That does it, but if there's any kind of drop in framerate the weapon doesn't fire. Why Every X works different than Wait X is a bit confusing. Still though, a step in the right direction.

    Thanks!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)