Invalid Appeal: Daddy Ungern

[Bottiger]

If you look again at the two screenshots, you can see that the cross hair does not in fact move perpendicular as you state. The crosshair has moved down and left (when comparing it's position to the join in the iron cladding behind as a reference). In the video clip of the same shot, it does indeed look 'snappy' and unnatural, if this is a bot performing this action, surely the pattern would be the same on other shots?

I recommend you try to do a flick shot and record a demo of it slowed down. I don't believe you would be able to get anything to look like this.

This looks like an aimbot glitching out. It doesn't happen every time, but an aimbot doesn't glitch out every time. Sometimes the player maybe fighting against the autoaim which could lead to glitches like this. I don't see how packet loss can explain this. If it was packet loss, then his crosshair should have stood still for a few moments, not instantly warp downwards.

Keep in mind that the clip is at 50% speed, here is the clip at full speed. The movement from right to left is already the "snap".


This isn't the only piece of evidence either. You can see his crosshair doing amazing acrobatic tricks around around his team mate at 2 different speeds that should be impossible with high sensitivity settings.


This seems to only happen when he aims at someone and it doesn't happen all the time either. Most of the time his aiming looks smooth and if there is a "flick" it is along 1 direction only.

The other admins have collected other suspicious instances, I will leave it up to them if they want to share, but I think I'm done here.

 

[Daddy Ungern]

Thank you for your input Mr. Bottiger

This looks like an aimbot glitching out. Sometimes the player maybe fighting against the autoaim which could lead to glitches like this.

I can see how you would think that, I have done my share of cheater busting as well (On csgo overwatch)
But all the "evidence" that has been posted in this thread has been my normal gameplay, so I will ask again:
Any admins that are working on this case and are interested enough, please private message me either in discord (Daddy Ungern#5016)
or steam (https://steamcommunity.com/id/agusedo/) and I'll provide any data that would proof my innocence. I do not have anything to hide.

I'll be on from 4pm to 3am EST.
If any of the content that I provide to the admins will be seen beneficial to this thread, I'll post them here.

For anyone interested my sensitivity is this: (Logitech 502)
DPI 3200
Sens 0.6

Mousepad:
Some weird one from china
900x400 mm ~

I do have a program running in the background from time to time called "Primary Lock". (Download link: http://s382701517.online.de/apps/PrimaryLock.zip)
It only allows the cursor to stay on the 1st monitor which gives me the ability to "Yeet" or "Flick" my mouse real fast (Having the issue that the flick might throw me to the 2nd monitor and thus minimizing the game).
This could lead to the weird flickery that is happening on those demos(?).

 

[Maddo]

This seems to only happen when he aims at someone and it doesn't happen all the time either. Most of the time his aiming looks smooth and if there is a "flick" it is along 1 direction only.

The other admins have collected other suspicious instances, I will leave it up to them if they want to share, but I think I'm done here.

Looks pretty damning to me.

For anyone interested my sensitivity is this: (Logitech 502)
DPI 3200
Sens 0.6

Do you use m_rawinput "1" or do you use any m_accelaration settings?

 

[Daddy Ungern]

Do you use m_rawinput "1" or do you use any m_accelaration settings?

I use m_rawinput "1" and I don't know what that m_accelaration is so I probably do not have it, if its the acceleration from the basic "mouse" menu then its at 1.

I hope this helps

 

[Carcalilly]

I recommend you try to do a flick shot and record a demo of it slowed down. I don't believe you would be able to get anything to look like this.

I went out of my way to create a controlled environment to catch clips like these. I collected 9 clips: imgur com/a/LnUoNwR

I made myself a server using na.serveme.tf, and recorded and STV demo of the server match. These are bots playing in the game with me.

Keep in mind that I had to do this on a server where I had operator because the demos you have are spectator demos. They record the server-sided viewpoint. I can't go on skial and record my own because that demo would be a client side view of my screen.

Details of my replication,
-I had a ping around 100-140 (which is less than what Ungern plays with generally)
-All players are bots. This would actually make the server less laggy.
-I was a server operator. I spawned in the bots and ran a tournament config (mp_tournament) so STV would automatically record a server-sided demo for me.
-I did a lot of flick shots with high sensitivity.

I also caught instances of small to servers packet loss and other unknown lag.

These are easy to replicate. I barely spent an hour playing.

 

[Bottiger]

I went out of my way to create a controlled environment to catch clips like these. I collected 9 clips: imgur com/a/LnUoNwR

I made myself a server using na.serveme.tf, and recorded and STV demo of the server match. These are bots playing in the game with me.

Keep in mind that I had to do this on a server where I had operator because the demos you have are spectator demos. They record the server-sided viewpoint. I can't go on skial and record my own because that demo would be a client side view of my screen.

Details of my replication,
-I had a ping around 100-140 (which is less than what Ungern plays with generally)
-All players are bots. This would actually make the server less laggy.
-I was a server operator. I spawned in the bots and ran a tournament config (mp_tournament) so STV would automatically record a server-sided demo for me.
-I did a lot of flick shots with high sensitivity.

I also caught instances of small to servers packet loss and other unknown lag.

These are easy to replicate. I barely spent an hour playing.

This doesn't look like the same thing to me.

In all your clips your movements look smooth even when you slow them down.

In the last few clips where your mouse moves perpendicular to the snap direction, it is a very small movement compared to the rest of the snap, and your mouse always returns to the original path of the snap.

Here is the clip slowed down so you can see how sudden and large of a movement it was.

 

[Maddo]

@Carcalilly Your sens is nowhere near the same, you would not be able to do a flick shot with that crosshair moving at that speed.

 

[Carcalilly]

IMO the clip of Ungern is just an extreme case of the kind of thing that demos do.
Regarding the smoothness, my circumstances were far better than his. Lower ping, 0.1ms LERP, only one connected to the server etc.
I'll have to change some settings. I can ask him specifically to give me his network config and misc in game settings and use those, and VPN to EU to mimic ping.
I'm not sure if there may be some discrepancies between recording a demo as a player-spectator and using STV. I'd assume STV would be smoother.
Getting back to it later tonight.

Also, regarding the distance, if compared, the second-to-last clip isn't too far off. imgur.com/a/ANcsxfA
Remember that it takes less pixels to travel the farther away you're aiming. So even if it's the height of battlments versus the length of a heavy, the pixels per distance are still comparable.

@Carcalilly Your sens is nowhere near the same, you would not be able to do a flick shot with that crosshair moving at that speed.

What I'm trying to communicate is not sniper capabilities. Sensitivity is minimally relevant in a flick because technically you can flick at any sensitivity, higher ones just make it easier. What I wanted these clips to show is that server-side demos are questionable when it comes to a scale of pixels and milliseconds, simply due to things like display/packet reading/framerate
developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

"The other method for determining where to display objects and players is interpolation. Interpolation can be viewed as always moving objects somewhat in the past with respect to the last valid position received for the object. For instance, if the server is sending 10 updates per second (exactly) of the world state, then we might impose 100 milliseconds of interpolation delay in our rendering. Then, as we render frames, we interpolate the position of the object between the last updated position and the position one update before that (alternatively, the last render position) over that 100 milliseconds. As the object just gets to the last updated position, we receive a new update from the server (since 10 updates per second means that the updates come in every 100 milliseconds) we can start moving toward this new position over the next 100 milliseconds.

If one of the update packets fails to arrive, then there are two choices: We can start extrapolating the player position as noted above (with the large potential errors noted) or we can simply have the player rest at the position in the last update until a new update arrives (causing the player's movement to stutter)."

I may have thought differently if it was snapping towards an actual live enemy, or if it demos were truly accurate, but everyone knows that they can display things inaccurately, just like how crosshairs are miles away from heads still hit shots.

 

[Maddo]

I may have thought differently if it was snapping towards an actual live enemy

Maybe it was starting to snap toward the next closest enemy?? Maybe? who can tell.
You are falling in to a common trap. You cannot achieve the SAME result, there are too many variables that you cannot replicate, you might be able to FORCE a SIMILAR result by running through multiple changes of input. For a start, having a different sens will affect extrapolation and you say from the bat that sens is 'minimally relevant'. You would have to use the same screen resolution/refresh rate/mouse/mouse mat/connection/ have the same programs running in the background/you would even need the same arm. I commend your loyalty to the guys integrity, but feel you are wasting your time. I think the only way for you to try and prove your friends innocence is to work with the demo sampled here, perhaps one of the admin can link you to it.

 

[Carcalilly]

Several things...

At first, I attempted replication, although I doubt it was Ungern's entire setup that was the issue.
His LERP ended up making me drop way more packets and those can be shown here, along with what I had to change my in-game sensitivity and network config into:
imgur.com/a/z5hFXdD

Maybe it was starting to snap toward the next closest enemy?? Maybe? who can tell.
You are falling in to a common trap. You cannot achieve the SAME result, there are too many variables that you cannot replicate, you might be able to FORCE a SIMILAR result by running through multiple changes of input. For a start, having a different sens will affect extrapolation and you say from the bat that sens is 'minimally relevant'. You would have to use the same screen resolution/refresh rate/mouse/mouse mat/connection/ have the same programs running in the background/you would even need the same arm. I commend your loyalty to the guys integrity, but feel you are wasting your time. I think the only way for you to try and prove your friends innocence is to work with the demo sampled here, perhaps one of the admin can link you to it.

My goal is to prove that the evidence provided for the permaban isn't reliable. They claim that the circumstances shown in the demo are a result of hacking. However, if the same circumstances are shown through verified non-hackers, then there's no way to solidify it as evidence for hacking.
If different people with different setups achieve the same result, you can't just apply the "hacker" label to one and not the rest. So either ALL of them are hacking, or none of them are.

I pondered over the smoothness of my own demos, and I believe it was due to STV. STV's demos are very high quality.
However I did some testing, what would happen if I recorded the demo myself?
I went to several different servers are recorded demos of handful or so random snipers. Some on skial, some not.
Results: imgur.com/a/7xxlFat

A laggy player screws up the demo. A laggy spectator screws it up even more. Those two put together just confounds whats shown so hard that aimless, 3fps crosshair jumps is not a circumstance that only hacking can create.

If all my clips fall under "not hacking" and Ungern's falls under "hacking", then where do you draw the line? At a specific number of pixels jumped? How many frames were skipped in the recording? How fast it occurred?

If you want more clips such as these just ask. I will log onto my PC, with quality network settings, and record my respected sniper friend's gameplay tomorrow.

 

[Carcalilly]

I am only gonna provide this bit of information no opinions as I am conflicted with both sides, although yes that lag can really do something to a demo, but angular flicks are not something relatively used among people who know how to do it properly, as they're slower than going straight for the head and there are more things to calculate in an angular shot because you got to calculate the movements across the X axis and the Y axis separately instead of calculating both at the same time which is the usual flick.

As I showed everyone here, it shows that the flicks in question are not very practical in a sense and can be reasonably suspicious but this could be the fault of demo errors and the fact that spectator is server side rather than client side.

I'm am certain it is fault of the demos: imgur.com/a/E0IBz9a

 

[Jermaphobe]

If you are not the person that was banned/muted, you are only allowed to post evidence.

 

[Maddo]

If different people with different setups achieve the same result, you can't just apply the "hacker" label to one and not the rest. So either ALL of them are hacking, or none of them are.

All your clips show the cursor skipping but still moving in the same direction, the one bottiger posted shows a compete change of direction in an instant. If you plotted these movements on a graph as coordinates you would see they are nothing the same. (I hope this counts towards the criteria of circumstantial evidence, if not please delete)

 

[Carcalilly]

All your clips show the cursor skipping but still moving in the same direction, the one bottiger posted shows a compete change of direction in an instant. If you plotted these movements on a graph as coordinates you would see they are nothing the same. (I hope this counts towards the criteria of circumstantial evidence, if not please delete)

imgur.com/BoLNSe9 ????????

---> imgur.com/bP5v4dy I mean yeah they aren't the EXACT same, but why is the difference between 90 degrees and 35 degrees an issue?

 

[Maddo]

imgur.com/BoLNSe9 ????????

---> imgur.com/bP5v4dy I mean yeah they aren't the EXACT same, but why is the difference between 90 degrees and 35 degrees an issue?

That crosshair returns to it's original trajectory showing that extrapolation is most likely in effect, what bottiger posted shows the 'skip' followed by the crosshair taking a new trajectory. plus your image it is not following a head shot, nor does it deviate over the same distance, deviate to the same angle, or even in the same direction. They are nowhere near the same.

 

[Carcalilly]

That crosshair returns to it's original trajectory showing that extrapolation is most likely in effect, what bottiger posted shows the 'skip' followed by the crosshair taking a new trajectory. plus your image it is not following a head shot, nor does it deviate over the same distance, deviate to the same angle, or even in the same direction. They are nowhere near the same.

1. Are you saying that if the crosshair returns to a path, then the demo is just "lag compensating" and the sniper themselves never flicked in that direction? How do you feel about the second clip bot showed of the pyro? It snaps at an angle and returns. Same thing.

Again, this is a weird habit that a number of snipers do sometimes.

(1:23 and 1:45 on this one you don't even have to slow it down)
www youtube.com/watch?v=03wVLGZeHSQ

2. Why does it matter if it follows a headshot or not? In fact, you should expect more lag coming post-headshot.

3. Distance is very hard to replicate exactly when we're talking literal pixels. For obvious reasons. But I have made approximations, and they come seriously close for something that is claimed to be 'exclusive proof of hacking'. imgur.com/a/ANcsxfA

2. Does this (i.imgur.com/SYQ8IvS.mp4) count, then? Because its an exact 90 degree angle from left to up? Is left-up really "nowhere near the same" and left-down?

Then again, the whole "moving perpendicular" thing is already shown (imgur.com/a/E0IBz9a) to be a thing that demos do. Most likely, they are actually moving their mouse in a slanted line. And the recording breaks them up into square movements. Ungern's questionable clip could've been a recording of a curved-down shot, but we can't actually know or be sure because demos just record like this.
Because I'm pretty sure no sniper actually moves their mouse like this: i.imgur.com/NT5o3JU.mp4

His mouse may have never actually snapped down. Demos do not reflect what actually happened at the pixel level. They're warped by lag through long pathways: playerclient-server-spectatorclient-demorecordning. In a game like TF2, a movement shooter, where pixels fly by in milliseconds, that pathway of information (internet) simply isn't fast enough to register every single frame. It's not Ungern's fault here unless you show something other than that clip. Because that clip contains so many elements of glitchy demos that are replicable just by tweaking record, network.txt, your ping, player's ping, the kind of server you're on..........etc.etc.etc.


What you seem to be expecting is an exact replica of the clip. I would need a very controlled environment to do that. What I've been showing you is average gameplay by me and other snipers. I was never trying to get exactly a left-down-jump-on-left-battlements-on-a-blue-demoman. I'm trying to show you that all kinds of gameplay recorded by demos display similar glitches. Each and every element of Ungern's clip can be explain by something that demos do consistently across all players.

 

[Maddo]

Are you saying that if the crosshair returns to a path, then the demo is just "lag compensating"

No, I'm just saying you can't replicate it to be the same, therefore all your work is futile. I did say you would be wasting your time. But it's not up to me to judge his guilt or not, I'll leave that to the admin.

 

[Carcalilly]

Eh, until I'm able to get a controlled environment, or until the mods ask me for something more specific, I compiled some misc. demo glitches that I didn't include in any of my other posts.
imgur.com/a/sPr2lRj
Put just a bit of effort into it and you can screw up demos to show weird stuff...

If any of these glitches replicate the extra evidence you may have... then I can explain what I did to make it. Idk what other evidence you have though.

 

[Jermaphobe]

At this point in time your appeal is denied.

Staff have agreed the ban is justified after reviewing all of the evidence recorded by us, and evidence provided by the community. The decision to share evidence collected by the staff was left at their discretion, and have made their choice clear. What we captured is impossible to replicate by human hands

You are not legit, and you should know our policy towards cheaters by this point. You will not be unbanned. Good luck on other servers.

 

[Carcalilly]

I'm sure I'm not talking just for myself and Ungern here when I say there is still a heavy disagreement, but you are still the admins and I understand your decisions are final.

If something else ever comes up, please contact us.