Posts by sqroot

    Congratulations this is the unique FREE open-beta game in this planet that is 1000% guaranteed free of hackers..... maybe Wiple could share this miracle with EA, Steam, Ubisoft....

    Oh, the secret to this is simple: Ironsight both isn't very popular and running on a unique game engine, i.e. you can't transfer cheats from other games as easily.

    It is easier to port cheats between games that have been built on Source, Unreal, Unity or Frostbite than to build something entirely new, and not many people are gonna bother with a game as small as Ironsight. This also drives up cheat prices, because cheats will be rarer and more exclusive.

    Nobody is claiming that the game is hacker-free.

    I have invented a notation for this beast: it shall be called ◻◻ = ◻^2 to denote the quadratic growth of possible items.

    Lootboxes are just ◻, MOAMOABs are ◻◻◻, and the mighty MOAMOAMOABs are denoted by ◻◻◻◻.

    You should also math out the probability of getting gp and chips from the lootbox

    Oh, that's easy!

    As far as my personal tests are concerned, the chance to get GP or chips is always about 100% for every lootbox that has GP or chips in the possible items list.

    Can't wait for when Ironsight, the pioneer of monetization systems, takes it to the next level and finally offers lootboxes that contain lootboxes that contain lootboxes, and more importantly to always be one step ahead of the competition, lootboxes that contain lootboxes that contain lootboxes that contain lootboxes.

    Be careful that you don't run into Russell's paradox!

    roflmao git gud noob

    I agree Misfire is incorrect, and I don't see an answer in sqroot's calculations, aside from how to receive one box twice.

    The calculation needs to be how to get 8 different pairs of identical boxes (b1,b1) (b2,b2) (b3,b3) (b4,b4) (b5,b5) (b6,b6) (b7,b7) (b8,b8) in 16 drawings from 8 items.

    I guess I'll spend some time on it in the next few days.

    Again, this is not difficult, and the answer is in my post.

    To do *any* calculations with probability, you need to assume a distribution. The stuff you (miss)learned in school is for Bernoulli trials with a uniform distribution.

    A uniform distribution is quite literally that you have the same chance to receive each item. To make any statements about probability, we need to assume the probability to get each item and a corresponding distribution, and that is statistics, not probability!

    Disregarding confidence, Noobles' post suggests exactly a uniform distribution. I'm gonna spare you with calculating the confidence (which is only dependent on the 16 trials, here), but by the law of big numbers, the expected values of a uniform distribution actually converge towards exactly all boxes being dropped the same amount of times, so Noobles' result is optimal for the given hypothesis!

    This is very intuitive, and even people that have never heard of probability will find this intuitive.

    What you're doing is assuming a uniform distribution and then trying to disprove that it is a uniform distribution.

    Every attempt at this kind of "proof" will be wrong, because it would prove that there are no uniform distributions, which is trivially wrong itself.

    For your question, ask yourself this: Which result to your problem would confirm that it is a uniform distribution, and which result would disprove it? (Hint: There's no correct answer to this question, because you're trying to solve the wrong problem!)

    I suggest you go pick up a book and relearn the stuff about probability you misslearned in school, instead of investing time into a pointless endeavor.

    Anyways, since I enjoy pointless endeavors, the answer to your question is ~0.029%.

    Let B(n, k, p) := (n over k) * 1/p^k * (1-1/p)^(n-k).

    If "Getting exactly 2 boxes of a kind i when drawing n times with probability p to get the box" is our event E_i(n, p) for every box i, then we're looking for the probability P(E_1(16, 1/8) ∩ E_2(16, 1/8) ∩ ... ∩ E_8(16, 1/8)).

    Applying the theorem of multiplication, we get

    P(E_1(16, 1/8) ∩ E_2(16, 1/8) ∩ ... ∩ E_8(16, 1/8))

    = P(E_1(16, 1/8)) * P(E_2(16, 1/8) | E_1(16, 1/8)) * P(E_3(16, 1/8) | E_2(16, 1/8) ∩ E_1(16, 1/8)) * ... * P(E_8(16, 1/8) | E_7(16, 1/8) ∩ ... ∩ E_1(16, 1/8))

    = P(E_1(16, 1/8)) * P(E_2(14, 1/7)) * ... * P(E_8(2, 1/1))

    = B(16, 2, 1/8) * B(14, 2, 1/7) * ... * B(2, 2, 1/1)

    ~= 0.029%.

    A quick experiment confirms this:

    16 of these "random" crates, and I received 2 of each crate. Exactly 2 of each of the 8 different crates. That to me seems like each box had an equal chance of being received.

    This actually suggests that the boxes are not random. By having an equal chance of being received the probability of getting one specific box is 12.5%, getting two of the same box is 1.5%, getting exactly two of each boxes I believe would be [(1.5%)(1.5%)]16 which is what you did. I mean you could have received all 16 Christmas supply boxes or zero Lucky boxes. My compound probability of independent events is rusty so maybe someone else can confirm or correct.

    This is very easy to grasp, no need for independent events: Noobles dropped 2/16 of each crate, which yields a 1/8 chance for every crate. This suggests exactly a uniform distribution (disregarding confidence).

    The chance for getting two same boxes in a row is 1.5%. Nowhere did Noobles mention that he dropped those two of each crate in a row.

    The last probability you wrote down is the probability for getting the same box 64 times in a row, which is also irrelevant here.

    I spent $10 worth of AP on these, allowing me to have enough AP in total to buy 16 of these "random" crates, and I received 2 of each crate. Exactly 2 of each of the 8 different crates. That to me seems like each box had an equal chance of being received.
    It's a sad state of affairs where the lootbox for lootboxes has better droprates than the lootboxes

    Also I got 450 chips from them in total. because of the terrible drop rates of the boxes, that deal is an excellent source of chips for a low price

    This actually suggests that the boxes are not random. By having an equal chance of being received the probability of getting one specific box is 12.5%, getting two of the same box is 1.5%, getting exactly two of each boxes I believe would be [(1.5%)(1.5%)]16 which is what you did. I mean you could have received all 16 Christmas supply boxes or zero Lucky boxes. My compound probability of independent events is rusty so maybe someone else can confirm or correct.

    Well if each has 12.5% of dropping and you open that 16 times its 0.125 x 16 = 2% for getting all the same box 16 times or 25% for getting the same box twice.

    Hooo boy. 0.125 * 16 =/= 2% = 0.02, but 0.125 * 16 = 2 = 200%, so this is both a wrong calculation and the wrong operation to use (assuming we correct your calculation to yield 2, not 2%, what you actually did was calculate the expected value of the amount of boxes of one kind you will get).

    The chance to get the same box 16 times when drawing 16 times is 1/8^16 (here we coincidentally can use cumulative probabilities).

    Using the induced binomial distribution for this uniform distribution, the chance to get a specific box exactly twice is (16 over 2)*1/8^2*(1-1/8)^14 ~= 29%, and the chance to get a specific box at least twice is 1 - (16 over 1)*1/8^1*(1-1/8)^15 - (16 over 0)*1/8^0*(1-1/8)^16 ~= 61%.

    The chance to get any box at least twice is 100%! By the pigeonhole principle, when drawing 16 boxes from a set of 8 elements, we HAVE to draw at least one box at least twice!

    Why is it worth 500 chips? How is that value calculated/justified?

    I’m pretty sure it’s the amount you get after drawing a duplicate.

    However, this is not related to this thread in any way.

    I'm sorry for bumping this thread once more so late, but to clear up any confusion for people that stumble upon this thread at a later time:

    You do not get 500 chips when drawing an orange duplicate, you get 50 chips.

    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.

    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.

    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):

    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.

    "I hope ur mom loves u and treats u well"

    Good boi seekax is a gent. Who knows what his mother has done to make people hate her so much. ?(

    Not that it matters, but that image was from my perspective.

    Please don't call out people in public.

    Use our ticket system for such reports:

    Since my post was deleted (but other off-topic-y posts weren't), I conclude that it is apparently disallowed to post any kind of censored chat logs on here. Could you explain which forum rule my post violated?

    I am starting to wonder whether you just delete these kinds of posts to hide the fact that your entirely unmoderated in-game-chat is a cesspool of toxicity.

    This is a known issue and not a permanent change. Anyway, as of now it's unclear when this will get solved.

    Why would shooting while sprinting be a mechanic or at least one without a perk? Now shotguns and smg are even more op.

    Is it because if it being a perk, it would contest with faster health regen?

    You are missunderstanding the issue. The issue is that before the patch, you could sprint, and while sprinting, start shooting, which would stop your sprinting and start shooting your weapon.

    Now, if you press LMB while sprinting, you will not stop sprinting and start shooting, you will just get slowed down instead. This means that if you want to hipfire after sprinting, you always need to hit "shift" beforehand to stop sprinting, pressing LMB will not do that for you.

    I just wanna say that it is absolutely incomprehensible to me why someone would push a patch with a bug as significant as the sprint + shoot bug, *especially* when it is a known issue. Something along the way went very wrong for anyone to think that a bug that affects your interaction with the gameplay as significantly as this one is fine to push into the live version.

    As for the GP gain, judging from the posts here, it is infeasable to make enough GP to buy things like soft point without investing real money while still repairing all your guns (and for new players, occasionally buying a new one).

    This doesn't seem accidental at all, it looks like a very calculated change to me that is intended to make people invest more money into the game.

    Oh my. There's another big change: Buffering has been added. This buffes semi-autos a lot.

    EDIT: The hit confirmation thing is probably on my end, I am laggy as hell. I think I'll wait until tomorrow to properly play.

    Some more things:

    • Hit confirmation is super delayed for me now. Consistently, every kill.
    • Recoil feels very different. Not sure if this is just because of the RPM changes, will have to test with a high RPM SMG.

    EDIT: First main menu game crash.

    I posted those videos, and none of them were similar to what you described - the one I posted that I suppose you are refering to demonstrated something akin to a lag spike, with *everything* getting delayed, not just hit detection, and the other one was a typical instance of extreme killtrading, which I have written extensively about before. None of these are due to hit registration, and especially none of those demonstrate that a worse connection leads to you having the upper hand. This again reduces the amount of examples that you have provided to zero, and if those videos are what caused you to suggest that hit registration is the major cause for the issue you are describing, then you seriously missunderstood what was happening in those videos.

    Could you please elaborate how I am protecting the game, when I am even the very person that posted the videos you are referencing?

    Just because I don't think that the issues are caused by what you claim they are caused by, doesn't mean that I don't believe those issues exist, and I am becoming increasingly annoyed by people on this forum randomly thinking of reason X why issue Y occurs and asserting that reason X has to cause issue Y without solid justification as to why that should be the case. This kind of stuff is not helpful to anyone, and anything but constructive criticism - there are better places to vent.

    Calling out weak opinions that are being held strongly is not equivalent to protecting the shitty state of the game.

    Now, what exactly are you referring to when you talk about "bullet sponges"?

    I take "bullet sponges" as "lots of hits are being registered, but they just don't die", not "I shoot at people but no hits are being registered", which you seem to imply with the stuff about hit registration. If you meant the latter, then what I said obviously doesn't apply, although I haven't noticed the issue yet (except for what appears to be massive lagspikes) and would like to see the videos in question. Could you link them?

    On another note, a lag comp system that is correctly implemented does not result in hits not registering that should; lag compensation exists in the first place so that the converse is true.

    They certainly use lag compensation, as pretty much all FPS games do, since you would have to lead your shots without one, which is only remotely tolerable in games like Quake.

    I won't reply to your sniper points to honor the "agree to disagree" statement, except for the fact that you should consider not being so harsh on the devs in regards to balancing (feel free to be in any other regard), because there are clearly many people in the community that disagree with you.

    As for bullet sponges, that's likely on your end.

    Kills typically get confirmed by the server, not by the other client. As such, the time it takes for a kill to be displayed depends on your ping and the server tickrate only, not the ping of the other player. According to my measurements, the max. delay by server tickrate is about 40ms, so it will take a maximum of your ping + 40ms for hits to be displayed on your end.

    Again, the reason why hing ping players might seem stronger to you is because of strong kickback in the first place, because people with bad connections won't experience the kickback before killing you.

    >Then why is netcode still broken?

    That wasn't their point. It is obvious that they did some work on it, the work just wasn't very good, apparently.

    >"this is a beta test and they are working on it"

    The person you're replying to did not assert that, that was someone else.

    >Have you just discovered F2P online games? Have you not played Alliance of Valiant Arms, Blacklight Retribution, Soldier Front, Combat Arms, Black Squad, Ghost in the Shell First Assault, Dirty Bomb (and many others)?

    Dirty Bomb is not a good example, because it actually had solid development and regular patches for a long time, even if people might not like the changes they made later.

    You're attacking a strawman, OhEmGee just stated that there was some work being done, and that claiming that there had been no work being done at all is a bit of a stretch.

    >SP bullet kick is so negligible that it might as well not even be in the game.

    Again, I disagree, and you are the only player I know that thinks this, which leads me to believe that your perception of the game is warped, not mine.

    >If you have half decent aim they are viable at any range and beat every gun, unless you catch that person 100% off guard and unload in their back.

    There is only a handful of players that can consistently compete with seekax and me, and all those people run assault rifles. On every map. I've seen some of them run sniper rifles before and do consistently worse, so my personal experience, both that of my own sniper gameplay, and that of those I play against, disagrees with this sentiment. I have also given plenty of theoretical reasons as to why this might be false, all of which you have ignored.

    >like instead of crotch up its upper chest neck head only for 1 hit kills and the guns are better

    What "guns" (note the plural) are you talking about? The blaser is already upper chest, neck, and head only, and the DSR is the only gun that oneshots on the entirety of the torso.

    >it just becomes a quick scoping mess with 2 or 3 snipers per team minimum even on maps like cloud 9

    Cloud9 is good for snipers because pretty much any angle you can hold from the middle building is a choke point angle that you can easily peek and unpeek, making it very easy to spawn trap people if you have someone hold the other entry. Even inside of the building there's many angles that are very easy to peek/unpeek repeatedly, and then there's obviously also the long stretch where snipers camp (and should be able to camp, if we're willing to accept the sniper as a gun that is effective at long range). None of your proposed changes make a difference for this kind of situation, as opposed to the solutions we have already discussed.

    >If 33% guns in the game are the blaser or DSR, it's a clear indicator of what the weapon hierarchy is, and since the inception of this game it's been sniper rifles.

    Again, I am not sure what you are perceiving here or where that sentiment comes from, but my perception is that most players, and especially all decent players, run assault rifles, not sniper rifles. I can literally not think of a single good player that can keep up with seekax and me that is running a sniper. Even I have way more combined assault rifle kills than sniper kills.

    I didn't suggest for it to be reduced, we were talking about the hypotheticals of a fast game that also focuses heavily on ADS.

    Games like this *have no polished final versions*, they become abandoned projects at some point at best. This game is using a continuous development model AND a continuous monitization model, and refering to such a thing as a beta, implying that there will ever be a finished version, especially to refer to it as a beta only to disregard criticism about the game being broken or unfinished, is at least a bit dishonest.

    If you unironically believe that this is just a huge 2-year-long testing phase that will eventually turn into a complete and finished game where most people would agree that it is indeed complete, you will be disappointed.

    There are bugs that I have reported at least 9 months ago that haven't and will likely never be fixed. There are super obvious and easily reproducable issues that have been present for a year.

    If this was a beta, there would be way more emphasis on testing. Instead you get a public test server, a beta for the supposed "beta".

    This is not a beta, this is just continuous development.

    I don't realy understand why you guys defending softpoint bullets so much?I tell you why, because if devs delete this bullets much more players can easly countering you.I already dominate %70-80 of matches I played, softpoint cancers just like flies on the soup to me.I am realy happy to see how ppl crying taken advantages from their hands even we are just talking lul.Okay guys snipers are to OP, softpoints OK.Casual friendly tools is casual, no need to argue this.And yes AIM control, intelligence and reflex most important things for fps games.Once upon a time we have a Blacklight Retribution Esl community and have a electronic, magnum, explosive, toxic ammos but never used to ESL matches.So softpoint is not appropriate to ranked matches.I hope you guys understand now.

    Who exactly has defended softpoint bullets in this thread since your last post? Except for Krusti, you're attacking a strawman - I don't see all those people that state that softpoint is great.

    There's a few things you need to do additionally for it to not be janky. The TTK needs to be reduced, ADS movespeed needs to be higher and firing in ADS needs to be integrated into the rest of the moveset (e.g. being accurate in ADS while jumping and maintaining momentum).

    There's also the possibility for "explosive" gameplay, like in CoD4 promod, for instance, although CoD4 isn't an example for a game with an extreme focus on ADS.

    The game is fast at the start of the round, where everyone is rushing to their respective positions. The game then slows down while people try not to make any sound. When shots are fired, the game becomes very fast for a while, and then slows down only if there is a chance that you're not giving away your position.

    Personally, I agree with you in so far as there's not really a need for a game to be super ADS centric, and I've been wondering what a CoD-esque game without any ADS and with accurate hipfire but also low TTK would feel like for a while now (think Dirty Bomb, but no hipfire randomness and low TTK), but I don't think it's obligatory.

    Making the game faster and friendlier to hipfire does not make it more casual, it simply strikes a different balance between the movement, positioning and aiming skillsets to other games you might have played.

    Good aim is not the gold standard of FPS skills, it's the minimum standard requirement. Anyone playing FPS games regularly should, without interference, be expected to be able to hit their target when stationary and aiming down sights. It's nothing special.

    There are dozens of games around that strongly favour ADS from ARMA to PUBG. The thing that all those I have played have in common is that they're boring as hell and don't last more than a month on my hard drive.

    >The thing that all those I have played have in common is that they're boring as hell

    I don't think they're boring because they favor ADS, I think they're boring because they're slow and lack any kind of movement. Being fast and having neat movement isn't exclusive with favoring ADS.

    Good aim might not be the gold standard (although it is arguably more important than decent movement in most FPS except for maybe AFPS, although not more important than good gamesense), but shifting towards hipfire too much (and at the same time not reducing the randomness of it, like they did in Dirty Bomb, for instance) does lessen the relevance of that aspect.

    I think for most guns, Ironsight does strike a good balance, but as I have stated before, I think the 50 ammo SMGs are a bit too hipfire-centric, which could also be changed by reducing the ammo a little and buffing the guns in other regards.

    What I'm trying to get at is the following: Buffing hipfire (without decreasing randomness) does not improve the aspects of movement and positioning, it only lessens the aim aspect. If you want to improve these aspects, you need to add decent movement mechanics, which Ironsight doesn't really have.

    Note that I'm not saying anything about buffing hipfire while decreasing randomness, games like Quake are obviously fine in all regards, that doesn't lessen the aim aspect at all.

    They really should, but they argue that the prices next to non-purchasable items is there to provide an indication of its value.

    Which I am not sure is true. Firstly, it is quite a stretch to refer to the amount that you supposedly get refunded when you get the item twice as "the value of the item", secondly I am not even sure if duplicates actually give you that amount of chips. I know that I did get a duplicate orange skin once, and I don't think I got 500 chips, but I am not super confident that I didn't and I didn't record it either, so I can't really confidently refute the claim made by the mod in question. Given that the mods here have spread false information by accident in the past, I wouldn't put too much money into it being true.

    In any case, absolutely nothing has changed about the abusive monitization system, and nothing new has been announced. If I remember correctly, the director even stated that nothing was explicitly planned.

    I'm not sure who is responsible for deciding that the system should stay like it is (explicitly or implicitly by requiring a quota or similar to be fulfilled), whether it is the devs, AG, Gamigo, some stockholders with a sufficient amount of shares or whatever, but I believe that they are disgusting people that encourage extremely unfair gambling with hidden rates, arguably targeting teenagers as well. Not to mention that they have also been made aware that the chips being displayed next to orange skins the way they are is extremely missleading, and still not taking any action to remove this kind of false advertising.

    At the slim chance of one of the people that decide this kind of stuff reading this: You should be ashamed. Your morals are unbelievably twisted.

    Softpoint kickback effect is not only usable for snipers.This bullets clearly ruining game.You are not happy for current sniper state and you okay with softpoint bullets lol.Okay I explain you what is actually softpoint bullets.Softpoint bullets = Who fire first to win!(Even you are a newcomer if you have better spec pc with this bad optimization or you have better internet connection you can easily beat a veteran fps player.) With this bullets your aim or experience does not work.If devs realy aiming better competitive play they need to fix this bullets first.Because to many players acting like pro with using this bullets.If you use any scopes, even holo you can be cancered by softpoint user.

    Ps:Sorry about my grammar.

    Soft point bullets do so little with hip fire weapons and the view kick on snipers is literally nothing. If you're having trouble adjusting to a little bit of vertical lift from soft points you've never played a game with actual recoil. As well you only need to hit 1 shot anywhere that isn't the arms or legs to get a kill.

    Please name an example for a CoD-like game that has stronger kickback than Ironsight and a comparable or higher TTK (which means that the CoD games themselves don't count - if you only need 2-3 shots on avg to kill, kickback obviously doesn't matter as much, because the person that shoots first would win either way).

    I also doubt that you yourself wil be able to consistently hit shots with the sniper at range while an smg is consistently inducing kickback on you, but that is difficult to prove, as is your claim that the kickback is supposedly super easy to overcome.