Most incompetent devs - i've seen in a game.

  • I've never seen a company nerf everything because something has been overpowered ( assault rifles ) now we've even worse weapons which barely can kill some of the snipers on mid-long range distance after the nerf.

    Meanwhile snipers are broken as **** and we've not touched them at all, PSG-1, CF-X50 seriously broken.


    Vector is freaking trash same with PP-2000 AK-47 and AK12 just got a unneeded nerf and are trash tier now, meanwhile pistols are useless there's only the shotgun, python, deagle who's actually good.

    Daily missions sucks, Win 4 times in any mode - f**** yeah try to carry your team which is useless 4 times?


    And then hipfire - most unskilled combat game i've seen in a long time.

    When the game should literally be called hipfire, because ironsight is literally useless:rolleyes:

  • The weird thing is that they nerfed the snipers in one patch and then, a couple patches later, they nerfed everything else.


    The net result was a higher TTK that overall favoured the snipers that initially recognised they needed to nerf.


    It didn't make any sense to me at all.

  • funny fact ... im playing ak-12 and pp-2000 and i dont have problems bcs they are "weak" or something ... also the vector seems pretty strong ... also i see many players with that weapons (also ak.47 etc.) so im not even close to understand what you mean ... ok snipers are 1shot but they are in most games and agains auto snipers i dont have any problems ... so imo. the problem could be you :O

  • Just don't know if he is playing the same game as me. AK-12 was one of the few weapons that got a small buff with the last patch (desperately needed!) , AK-47 still one of the strongest AR in the game... but yeah, SMG with hipfire is easy going here, that's right.

    Snipers are slightly overpowered in the hands of "i-have-a-crosshair-on-my-monitor" players as they can easily quickscope out of movement and the still crappy lag-compensation/netcode still favours players with bad pings.

    Nothing worse than a yellow-bar sniper. Eats up my bullets like a sponge and seems to have all the time of the world to scope on me an kill me one-shot ...


    Complaining about the PSG-1? c'mon ... on the EU server, i'm pretty much the ONLY player who is using this gun ... i like it, but it's defo not OP ... ^^

  • as much as i know not bad-ping players are in favor of the game ... instead good-ping players ... thats what i saw in a post somewhere in the forum

    It's a peeker - defender problem here.


    Since ping is a measure of how long a packet of data takes to travel from the client to server,


    If a person has a high ping, and if he peeks around a corner to an enemy(low pinger) holding the angle(defending), the high pinger will be able to see him before the low pinger does. In this scenario, the high pinger has an advantage for his position hasn't updated to the low pinger yet


    HOWEVER, if the high pinger is the one holding the angle, then the low pinger have an advantage over the highpinger, simply because the position of the lowpinger hasn't been downloaded by the high pinger yet, and therefore, the low pinger will see the high pinger first.


    in a case of high pingers and low pingers battles, they each other being killed through walls a lot. Both cases. It's not like the high pingers can kill through walls you low pingers can't. To high pingers, they also see low pingers killing them through walls because to the delay stated above.


    One way to negate this problem is by improving the movement update rate, such that there are more samples, and therefore, movement positions are more accurate. The current one of 25Hz is just really bad for a game like Ironsight.

  • There's a common fallacy in this post (one that I used to believe a few years ago as well): Despite the fact that the high pinger sees you before you see him, he does not have an advantage, because it will also take the same long amount of time for hit packets to travel to the server.

    In more detail (there's also a visual proof that the ping of the peeker is cancelled out, and only the ping of the one getting peeked remains):

    https://www.youtube.com/watch?v=3JaCcsmjYM8


    That being said, it does feel like there is still peeker's advantage in Ironsight, which might be due to other netcode quirkiness, but not due to the reason you explained.

  • Watched the video, and yeah, that is certainly what might be happening, but Idk whether the servers in Ironsight follow the same mechanism though. Ironsight servers are just weird.

    That being said, it does feel like there is still peeker's advantage in Ironsight, which might be due to other netcode quirkiness, but not due to the reason you explained.

    Perhaps it's the physics engine? Since I play from Asia, I sometimes get a lag spike at the start of the match, and when the players move, they kinda move in a straight line, like gliding. When the come across a object, the are suddenly teleported above it (buildings and such), or are pulled to the nearest outer-corner of the wall. I have a feeling it's due to packet loss as well, but in case of Ironsight, it seems like the game just keeps them moving to their last known velocity it received (I'm taking the direction into account).


    A few updates ago, they said they tweaked the physics engine so that players don't appear to be flying. I think they just kept them grounded and gave it collision so that they slip past the object instead of phasing through it. When this happens battles are very snappy when they peek around the wall. It's like they got pulled by some invisible force and slipped around it.

  • Watched the video, and yeah, that is certainly what might be happening, but Idk whether the servers in Ironsight follow the same mechanism though. Ironsight servers are just weird.

    That being said, it does feel like there is still peeker's advantage in Ironsight, which might be due to other netcode quirkiness, but not due to the reason you explained.

    Perhaps it's the physics engine? Since I play from Asia, I sometimes get a lag spike at the start of the match, and when the players move, they kinda move in a straight line, like gliding. When the come across a object, the are suddenly teleported above it (buildings and such), or are pulled to the nearest outer-corner of the wall. I have a feeling it's due to packet loss as well, but in case of Ironsight, it seems like the game just keeps them moving to their last known velocity it received (I'm taking the direction into account).


    A few updates ago, they said they tweaked the physics engine so that players don't appear to be flying. I think they just kept them grounded and gave it collision so that they slip past the object instead of phasing through it. When this happens battles are very snappy when they peek around the wall. It's like they got pulled by some invisible force and slipped around it.

    The phenomenon you explain is in fact due to packet loss or a different kind of desync. For instance, when you alt-tab during the match (in full screen), you will notice this as well, because the game will stop receiving and sending packets while alt-tabbed.

    The video I linked explains the feature that causes this phenomenon: Interpolation.

    Your game client receives movement packets from other players at a certain rate, say 25 times per second. This leaves a gap of 1/25s between packets. In this time frame, your client needs to display a motion, otherwise it will seem like player models are teleported around every 1/25s.

    To display this motion, you need at least two points of reference: The last movement packet, and the packet before that. We then interpolate a motion between these two packets and display that motion.

    This has two significant implications:

    1. What you see on your screen isn't actually the motion of the most recent movement packet, it's the motion between the second to last and the last movement packet. This results in an effective maximum delay of 1/F between the last update that your client has actually received, and the movement position that your client displays to you, where F is the frequency at which movement packets are sent. Conclusion: Your client has to add some delay, independent of ping, so that it can display smooth motions on your end!
    2. When the client stops receiving another packet, it needs to decide what to display. It can either decide that your character freezes in place after the interpolation reaches the last received movement packet, or it can decide to keep interpolating the motion, even past the last received movement packet. Since ping fluctuations are quite common, and it's a common occurence that movement packets take slightly longer than expected, the latter option is usually taken, to prevent character models from stopping in place for very short periods of time, which might look like a very choppy motion. An implication of this is that in the case of serious packet loss, the characters just keep moving in a straight line, and occasionally your client might move the model to somewhere somewhat sensible when the position you're interpolating to isn't accessible (for instance to the top of the roof or having it slide across a wall instead of having the model walk through a wall).


    However, I don't think that this has got anything to do with peeker's advantage.

    I can't speak for the new netcode, because I have not spent an extensive time testing it.

    With the old netcode however, according to BattleNonsense, hit packets were transmitted *instantly* on the server side, while movement packets were processed via the server processing loop.

    Normally, the server runs in a loop, gathering all the received data at the start, then processing it and then distributing the results to every one at the end. The rate at which this loop runs is the tickrate.

    Hit packets being distributed instantly has one key implication: Assume that while peeking, your client sends a movement packet to signal to the server that your client is peeking, and then a hit packet shortly after. Both of these packets will be delayed by half your ping, and will be received by the server with the same time difference that you sent those packets in.

    But now the hit packet is sent instantly, while the movement packet needs to wait until the last main loop iteration is completed!

    This will either reduce the time delay between the hit packet and the movement packet (because the movement packet needs to wait longer on the server than the hit packet), or it might even result in the hit packet being sent before the movement packet, if the delay between the two packets was smaller than the time it takes to complete one iteration of the server loop (1/tickrate).

    Conclusion: If the tickrate is sufficiently low, hit packets that correspond to a peek will always be sent before the movement packets corresponding to the peak, meaning that you might get hit *before* you can actually see the other player.


    I do not know if this issue was fixed with the new netcode. I've wiresharked the packets sent and received by the game client for a while and I can't really make sense of how the new protocol works. Loads of packets are being sent, some instantly, some only when a tick is complete, some packets via UDP, some via TCP. I can well imagine that this kind of weird protocol complexity results in lots of quirky behavior and interactions that the devs did not consider, but since I don't understand it, I can't tell you which.

  • Post by T0KZIK ().

    This post was deleted by Helix ().
  • And how fast the server loops in present time is fps?


    Meanwhile, the player’s actual clock is ticking. If we measure how quickly the game loop cycles in terms of real time, we get the game’s “frames per second”. If the game loop cycles quickly, the FPS is high and the game moves smoothly and quickly. If it’s slow, the game jerks along like a stop motion movie.

    <3Misfire<3

    <3Yellow Star with dark Background<3

    <3Celebrations DSR<3

    <3Quickscoping most of the time<3

    <3ironsight_20180524115517.png<3

    <3as.jpg<3


    giphy.gifgiphy.gif


    giphy.gif

  • No. There's three relevant values: Server tickrate, client tickrate and FPS.


    But first, something else: As you might have already figured out yourself, there's a limit for how high we can set the tickrate: 1/tickrate should never be larger than the time we need to execute a single iteration of the server, because then we'd have to start a second iteration before the first one has completed, and this isn't really possible for multiple reasons (on a single core it just isn't, and on multiple cores it would have the undesirable effect of divergence, where you need one more core every time the loop takes too long, also eventually reaching a limit). However, you might wanna choose the value to be lower than the time it takes to complete the iteration: To save resources, and run multiple matches/server instances on the same core.


    The server tickrate determines how often the server loop is run (i.e. how often the server calculates things, transmits data, etc.).

    The client tickrate determines how often the client transmits data.

    As you can probably tell, it is a good idea to have server tickrate = client rickrate, so the server doesn't work faster or slower than the client transmits packets.

    FPS determines how often your game client refreshes the picture of the motion to the monitor (and often some other things as well, e.g. how often mouse and keyboard input are processed).

    And lastly, your monitor frequency determines how often the picture from your game client is actually refreshed to you.