Dealing with Lagged WRCP's and Fixing Maps

[cheazy]

Here is an idea I have been thinking about that would solve a few issues dealing with lagging wrcp's, cheating wrcp's with things such as double boosts, and a place where other people can post for things to be fixed on a certain map.

So we could have a forum called "Maps" and inside "Maps" we have each map, for example "surf_lore". In the thread for the map we will have what we believe to be the maximum prestrafe for a stage on the map. As well as maybe some things that need to be fixed or things that will result in a ban that maybe cannot be fixed.

This would mean we will have A LOT of threads on the forums and it might not be so easy to sort through, but this was the best thing I could think of unless we were to make a wiki or something.

Using the information from http://ksfclan.com/forum/showthread....Moving-Forward, the max startzone for cs:s is 475. And the max I have found for cs:go is 476 (on a standard startzone). As well as a 484 being the max with a false start. In my opinion, if a wrcp is a 477-484, their times stay until someone is able to get a +.01 or +.00. And anything 485+ is a removal (these are cs:go numbers)

I have already made these notes for around 5 maps so far on cs:go, but doing them for all of them would take way too much time. I'd also have to do them on source, because the numbers and fixes are going to be different. So getting help from others would be great.

I think it would be great for Sacred and Nowlech, as well as people who are reporting times. Sacred and Nowlech could check back on these threads to check if a wrcp is lagged, as well as check for reply's in the threads for fixes that may need to be addressed. It would be a database of information on each map we have on the server.

As an example I will use surf_lore on cs:go because it doesn't have all standard startzones and some things that still need to be fixed.

This would be the initial post, which would then be edited as time goes on about fixes. Startzones that are not a standard startzone, I bolded.

Of course, the formatting for this can be changed. This is just what I came up with while making this thread.

surf_lore
T2

Stage 1
Max Prestrafe: 476

Stage 2
Max Prestrafe: 476

Stage 3
Max Prestrafe: 578

Stage 4
Max Prestrafe: 476

Stage 5
Max Prestrafe: 476

Stage 6
Max Prestrafe: 578

Stage 7
Max Prestrafe: 476

Bonus 1
Max Prestrafe: 476

Bonus 2
Max Prestrafe: 476

todo:
• [Stage 1] Can long jump the start. Doesn't seem to be a thing on CS:S.
• [Stage 3] Can climb ramp behind and get a 610 prestrafe. 578 is possible by prestrafing on the ledge. Otherwise this would be a 568. Recommendation: Make floor level and make it so you can't climb ramp.
• [Bonus 1] I'm guessing this would be 476. The XY speed doesn't go down to 350, making this bonus prehoppable.
• [Bonus 2] Can be prehopped. because of the XY speed not going down to 350.

Fixed:
• [Stage 1] Whatever was fixed.

Tell me what you guys think, or any other suggestions you might have about it.

[CRASH FORT]

Start speed barely matters to anything at all and does not define network lag alone unless extreme conditions. You can do a 400 start and still get massive minus on a stage record through actual network lag so please don't call it that.

There's so much wrong information about this subject. A true "false start" is simply because how the server physics operate, when you strafe a specific way your hitbox may stay within the zone for 1 tick longer. And it just so happens when you do a good strafe it adds the extra ~12 u/s as you were in the zone for longer (483+). This is something that can happen with a medium start strafe as well, so you can do a 460 but still get the extra tick inside a zone (334~ Z). There currently is no way of seeing those as XY and Z in prinfo is not separated.

As for knowing what values are "allowed", you just use common sense and use the average by looking at the type of zone.

Client network lag is a whole different matter. In the way that surf is played it's a flaw in the engine that has been with it since HL1. I think I know the cause but I don't have a platform to confirm it on. This is what a lagged time is, a slower and worse run getting a record when it should not have. There are multiple types of this but I don't know how to describe them properly.

[cheazy]

I was always under the impression that it was all in the startzone. And that lagging in between the run, or towards the end, it will always be a worse time.

I guess the way you are putting it though, makes a lot more sense on some records I have seen, because this wasn't the case. Where the startzone wasn't great, the route was worse, and still getting a minus on the wrcp.

There's really not much information out there besides the beetle post. Thanks for posting your information about it.

Anyways, even if the startzone information is of no use on the thread, I still think the threads would be useful for people to post about issues with the map and future fixes. As well as things about maps that players should know about that might not be allowed on a map. The "Maps that still need auto" seems to be pretty successful, so why not just a super thread of things that need to be done? As well as it being nice to read and organized.

Rather than making a thread for each map, just have one thread where people can post about fixes, and then the inital post can stay up to date with what needs to be fixed, and what should be fixed. It might be a lot of information to fit in one thread, though. So maybe one thread per tier.

Here is what it would end up looking like.

surf_how2surf
T1

Comments:
• Comments here

todo:
• [Stage 4] Can enter startzone at a higher elevation by prestrafing on top of the ramp. add no jump.
• [Stage 4] Can't do !s 4. It will teleport the player back to the start of the map.
• [Stage 5] Can enter startzone at a higher elevation by prestrafing on top of the ramp. add no jump.
• [Stage 5] Doing !s 5, teleports the player to s4.
• [Stage 6] Can enter startzone at a higher elevation by prestrafing on top of the ramp. add no jump.
• [Stage 10] Can bhop on grass for a faster time. add no jump.
• [Stage 11] Can bhop on grass for a faster time. add no jump.
• [Stage 12] Can bhop on grass for a faster time. add no jump.
• [Stage 13] Can bhop on grass for a faster time. add no jump.
• [Stage 16] Can bhop on grass for a faster time. add no jump.

Fixed:
• Fixed here

------------------------------------------------

surf_lore
T2

Comments:
• Comments here

todo:
• [Stage 1] Can long jump the start.
• [Stage 3] Can climb ramp behind.
• [Bonus 1] The XY speed doesn't go down to 350, making this bonus prehoppable.
• [Bonus 2] The XY speed doesn't go down to 350, making this bonus prehoppable.

Fixed:
• Fixed here

------------------------------------------------

surf_simpsons_source
T2

Comments:
• [Stage 1] First ramp can be superboosted.
• [Stage 1] Can enter startzone from a higher elevation with boost on first ramp.
• [Stage 3] First ramp can be superboosted.
• [Stage 4] Can enter startzone at a higher elevation with boost on first ramp.
• [Stage 8] First ramp can be superboosted.

todo:
• todo here

Fixed:
• Fixed here

[CRASH FORT]

I think network lagged times do occur inside the start zone in such a way that the server waits for the client command messages to process them, when they are already outside of the zone due to some network issue, gaining a time advantage. I don't believe this is a thing within a run. This is the flaw I mentioned, the server actually waits for a client if there's a hiccup in the user command stream, but once they are all processed, the predicted movement matches with what the server has so it lets them continue. Of course, in normal game play this is not an issue at all so it's only related to surf.

It has been experimented before that leaving the start zone with a higher server latency than what you finish with will give you a time advantage, as well as a time penalty if the opposite happens. I don't know the threshold values or the calculations for this though as I didn't do the testing.

[Crayz]

Could it be solved by performing collision tests manually (player origin vs AABB) rather than using Source Engine physics?