LeagueAS Bug?

  • Hey - turns out IRC is out and something a little more modern has taken it's place... A little thing called Discord!

    Join our community @ https://discord.gg/JuaSzXBZrk for a pick-up game, or just to rekindle with fellow community members.

The Client logfile of UT is a very powerful help to analyze clientside problems tho it is very difficult to understand the warnings/error unless you are a skilled uscript programmer.

Almost all of the random scriptwarnings in that logfile are very typical and nothing to worry about (Postrender, UDemo, Playeranimation). The only untypical warning is the "StarterBoltTIW.CheckBeam". Seems you played on a Server where TIW was enabled. Since it only happened 'once' it could be a random incident on that map on your client. But we will keep an eye on that. Plz keep us updated with logs if this happens more frequently ;)
 
The pulsegunTIW is in by default. TIW isnt a big deal for pulsegun though and its mainly a fix for the exploit that could be used to finish objectives.
 
thePROPHET! said:
Same goes for Sniper Rifle in water (on Bridge for example), when i´m in water, and i directly shoot the enemy, he doesnt get damaged or killed, only rarely
same here, first i thought that's because of my sucky connection (~130 f6 ping), but it seems that i'm not the only one who noticed these problems.
I also experienced the same "enemy-rocket-launching" problem like p00f explained, but that wasn't a big problem for me in the past so i didn't moan about it.

Well UT doesn't feel as "smooth" anymore, as it felt before. Just a feeling so it's hard to explain.
 
Launch enemy with 1 rocket :nod: might aswell let us launch em with 6 rockets :nod: back to there spawn point hrhr
 
Last week we finally got the very first demo of the so called "rocket bug". Now we finally got the chance to analyze the mystery (Thx to Traffy for sending us the demo)

Maybe you should first watch the demo: At Timestamp 0:36 Timeleft the Demoplayer shoots 3 rockets to the victims feet, but for "some" reason the victim does not die. Instead he is launched away into the opposite direction. Tbh when I first watched it I just thought WTF?

Well what happened there?
Fortunately Demomanager allows to watch the scene in slomo so I could take some screenshots: On the first picture below you can see the Rockets exploding at the victims feet. On the second picture we can see that the victim wasn't just lauched away, but is performing a foreward dodge.

To finally see what happened we have to watch the scene from the side (3rd picture). Keep in mind that this is what the client has seen (not what really happened on the server): The rockets are flying towards the victim. They seem to hit him at his feet. Therefore an explosion is triggered on the clients view. But for some reason the victim doesn't die but is launched towards the player. But since the clients view is some milliseconds behind the scene on the server, this is not what really happened. On the server the victim has started a foreward dodge. He has already moved foreward a little bit, so the rockets do not hit his feet. Instead they keep flying and hit the ground somewhere behind him. So the "real" explosion only gives little damage to the victim and maybe boosts his dodge a little bit. This explains why the victim doesn't die and is boosted into the wrong direction instead.

So what we have seen here is a typical "WTF" situation where every watcher would cry out "leagueAS rocket bug" but in fact it is a very regular reaction that would have happened exactly the same way in every other gametype (plain Assault or even Deathmatch).
 

Attachments

  • rockets1.jpg
    28.9 KB · Views: 138
  • rockets2.jpg
    25.4 KB · Views: 132
  • rockets3.jpg
    35.5 KB · Views: 132
  • demo.zip
    1.1 MB · Views: 26
Last edited:
  • Like
Reactions: Felerian
warning, some sarcasm is present.
well well, surprise innit cratos? Your explanation is (exactly) the same that happend on that demo u got from me but couldnt use because it turned out to be with 135c, except that was a side dodge. Like i said earlier, i didnt set out to prove or disprove the reported 136roxbug, but it sure is convenient how it happens to coincide with that way of explaining (the reported problems away).
Pardon, but that only covers situations where there is a dodge, and probably only when the dodge is instigated 1 or 2 ticks prior to when the collision should have occured if no dodge was executed. How about run and/or jumps? Jury still out on that one? Would be nice to hear if its dodge-only or not and even more so, why.
 
Cratos said:
Last week we finally got the very first demo of the so called "rocket bug". Now we finally got the chance to analyze the mystery (Thx to Traffy for sending us the demo)

Maybe you should first watch the demo: At Timestamp 0:36 Timeleft the Demoplayer shoots 3 rockets to the victims feet, but for "some" reason the victim does not die. Instead he is launched away into the opposite direction. Tbh when I first watched it I just thought WTF?

Well what happened there?
Fortunately Demomanager allows to watch the scene in slomo so I could take some screenshots: On the first picture below you can see the Rockets exploding at the victims feet. On the second picture we can see that the victim wasn't just lauched away, but is performing a foreward dodge.

To finally see what happened we have to watch the scene from the side (3rd picture). Keep in mind that this is what the client has seen (not what really happened on the server): The rockets are flying towards the victim. They seem to hit him at his feet. Therefore an explosion is triggered on the clients view. But for some reason the victim doesn't die but is launched towards the player. But since the clients view is some milliseconds behind the scene on the server, this is not what really happened. On the server the victim has started a foreward dodge. He has already moved foreward a little bit, so the rockets do not hit his feet. Instead they keep flying and hit the ground somewhere behind him. So the "real" explosion only gives little damage to the victim and maybe boosts his dodge a little bit. This explains why the victim doesn't die and is boosted into the wrong direction instead.

So what we have seen here is a typical "WTF" situation where every watcher would cry out "leagueAS rocket bug" but in fact it is a very regular reaction that would have happened exactly the same way in every other gametype (plain Assault or even Deathmatch).


Nice but anyway why to cry about this, this happens once in like 3 years :P
 
Next time some1 shoots rocks at me i'll dodge like hell!
 
KeKc said:
Nice but anyway why to cry about this, this happens once in like 3 years :P

once in 3 years? happened to me enough times to hate league assault, and NEVER happened me at CTF/DM.
 
warning, some sarcasm is present.
well well, surprise innit cratos? Your explanation is (exactly) the same that happend on that demo u got from me but couldnt use because it turned out to be with 135c, except that was a side dodge. Like i said earlier, i didnt set out to prove or disprove the reported 136roxbug, but it sure is convenient how it happens to coincide with that way of explaining (the reported problems away).

Huh? What does a demo in 135c have to do with anything... most of the ppl complaining insist that their problems started in 136 and thats what we are seeking proof of.

Pardon, but that only covers situations where there is a dodge, and probably only when the dodge is instigated 1 or 2 ticks prior to when the collision should have occured if no dodge was executed. How about run and/or jumps? Jury still out on that one? Would be nice to hear if its dodge-only or not and even more so, why.

Its a quirk of UT that has been documented years before 136. Any movement may cause rockets to explode at different times on client and server and the following paragraph describes it in excellent detail:

The next important method used is simulating an actors behaviour on the client where
possible. This applies to most projectiles (like rockets). When a projectile is fired,
the server tells the client where exactly it is spawned (created) and in which
direction it is flying. From that point on, the client simulates the projectiles
flight without any additional information from the server - the client knows the
speed, and since no direction changes happen, there is no reason why the server should
have to send the client position/movement updates. This simulation, however, is what
causes the "phantom rocket" situations where a client sees his rockets hitting another
player without the player dying when he seemingly should. The reason is simple - since
the rockets are simulated on the client, the client also decides when they "explode"
(visually - damage is of course decided on the server alone). So if the client sees
the rockets hit a player, they blow up - but our client world is not exact, especially
for other players who may have moved away a bit in the "real world" on the server
already. To sum it up - while the rockets miss the "real" other player on the server,
they hit the slightly wrong positioned player on the client. You can be sure that you
did damage if you see the other player bleed or "being bumped around" because both
the blood effect and the player momentum change are done server-side.

Obviously if the target jumps or dodges away from the explosion any damage would accelerate the dodge.
 
Polle said:
Huh? What does a demo in 135c have to do with anything... most of the ppl complaining insist that their problems started in 136 and thats what we are seeking proof of.
Its interesting for the simple fact that the explanation given fits perfectly on a 135 demo, thus it *could* be taken as evidence that there is no difference to 136.
Also, and i know i am repeating myself here, i havent really had any occurrences of it where i was the one firing the rox. Maybe 2-4 times since 136, but nothing on the scale like some ppl suggest.
If you can bury it in a way ppl will be happy with, great, im just playing bad in an attempt to make sure you are being thorough in doing so. Way too much of "136 broke this, broke that" that is unfounded in my experience. Anyway, while im being a pest, can i plz have a special release with options to remove colorcodes sent by enemy AND spectators, possibly also for teamsay, while preserving the color specified in config menu. In short, dont want ppls codes to override my settings.
I am referring to the codes that can be inserted into say/teamsay messages. I want to be positive that color is as i specified it via the config menu and the anemote.ini, not how some weedhead happens to want it. Recently found some ppl finding it immensely amusing to colorcode their messages to look like messages from spectators :( Next stop would ofcourse be learning the enemys colorscheme to mask as teamsay.
 
thePROPHET! said:
Just tick the option "Remove ALL Color Codes from Chatbox" and all the annoying color spamming shit is gone.
listen to da poof, he's right ;)
this setting will remove all color codes without touching your personal colorsheme
 
Last edited: