#Rewinded shots
dawn urchin
with the testing of my clock it was like 6 ms off accurate idk if that is enough to make it break like i'm seeing
vagrant stag
circular buffer based?
but 6ms would only make hits slightly outside your bounding box to be discarded, crank up the tolerance a bit and u'll be good, either way review that ur rewinding code is doing what it should do
dawn urchin
yep
I put my tolerance on 1.5x and its still dropping hits
idk what a traditional tolerance is
vagrant stag
1.5x sounds aight.. whats the distance?
vagrant stag
no, like how far are the shots from the bounding box
dawn urchin
its super inconsitant is the issue
it works a lot of the time
I got this one,, gold white box is where it has to be(not including lenience) green is where they were on the client when they hit them.
red sqare is hit
vagrant stag
wdym by "red square is hit"?
vagrant stag
are you for some reason ticking at a low frequency in the rewinding component?
dawn urchin
the blue and white boxes are between the ticks
so its a small window
but the real box of where the client thought it should be at that time doesn match up with that window
vagrant stag
how big is your buffer?
maybe try to increase the buffer\
void UShooterRewindableComponent::UpdateSavedMoves(bool bInTeleported)
{
const float WorldTime = GetWorld()->GetTimeSeconds();
new(SavedMoves)FSavedMove(GetOwner()->GetComponentsBoundingBox(), bInTeleported, WorldTime);
// maintain one position beyond MaxSavedPositionAge for interpolation
if (SavedMoves.Num() > 1 && SavedMoves[1].Time < WorldTime - 0.5f)
{
SavedMoves.RemoveAt(0);
}
}
see that 0.5f
increase it a bit
0.5 should be aight for most the cases but maybe ur dealing here with a lag spike
dawn urchin
the time isnt past the length of the buffer
vagrant stag
so ur telling me that green should be the correct hit
whereas ur getting white/blue
dawn urchin
white to blue is the tick window on the server for the time but green is where the client saw them at that time
vagrant stag
so u send the timestamp, reaches the server, the server rewinds by that rate, results in blue/white (assuming interpolation)
dawn urchin
yeah
vagrant stag
and the view of that actor in the server decreasing the time delta results in the blue/white
and ur telling me its within window, less than max time in this case 0.5
not a result of any lag-spike... etc
dawn urchin
could be a lag spike but not more than 0.5
vagrant stag
can we ensure that it's not exceeding 0.5 at all? It can also be an artifact of extrapolation of the cmc
remember that extrapolations doesnt exist in the server
dawn urchin
I have it printing out the timestamps for debugging
vagrant stag
how much drifting are you observing in the clock, 6ms you said, right? that should be fine
so 2 things that are important for competitive integrity:
- consider disabling extrapolation and make simulated proxies live in the interpolated timeline
- try cranking up a bit the tolerance box
dawn urchin
would that be with the character class and movement component
vagrant stag
https://www.snapnet.dev/blog/performing-lag-compensation-in-unreal-engine-5/ yes, more info here
dawn urchin
I looked into this a bit
Is this a rewrite of how unreal handles moving replicated charactres
vagrant stag
yes, a bit lol
the cmc
as you can see in the video the simulated proxy is at times in a place that never ever existed in the server
because of extrapolation
you will see this when u reduce the net update rate of your actors
or when you are running at average to bad ping conditions
rewinding does work to an extent... and in unreal... with extrapolation it doesnt when u have lag spikes because of the extrapolation code of the cmc
dawn urchin
does this lead to the psimulated proxy's always being behind the server a bit in this new version
vagrant stag
ye
which is acceptable if all the pawns are behind the server
it wouldnt if some are and some others arent XD
vagrant stag
oh yes the video from jay mattis is exaggerated mainly to show the effect from a pedagogical point of view
hahaha
dawn urchin
but does having the proxy behind the server lead to gameplay effects in a fast paced game
vagrant stag
it has implications yes
but you can control them
one of the implications is that you might be able to hit someone that is already behind a wall
because he is slightly in the past in your client
and the server would verify this hit
which would possibly make the victim rage
X'D
dawn urchin
yeah I mean thats kinda a trait that i've excepted with the rewound hitscan system
vagrant stag
well with extrapolation ur kinda kinda kinda avoiding that
dawn urchin
so basically this makes it so you are just [ping] amount of time behind the server
vagrant stag
yes, ur using whatever latest data u got from this sim proxy
of course the more lag u have the more degraded experience u'll see
i mean... same happens with extrapolation in this case ur seeing that are hits that are called "bullshit" because the server is saying "hey, this never existed"
so its... a.... ey theres not a perfect solution... we have several solutions, we can mix and match them... but ultimately there is always a compromise
dawn urchin
i mean its trade off of delay at high ping versus ruber banding at high ping
dawn urchin
yeah
and like attacks, abilities, gameplay important events like that are already based on a delay system and kinda have to catch up with the extrapolation
vagrant stag
im not sure actually! i can't tell u how complex it would be because i didnt get to do it myself
but... ive extended a lot cmc... its a bit of a PITA, but should be feasible
dawn urchin
okay ill look into it and get back to you with my findings
vagrant stag
oki doki
if you want we can also extend the article with som extra info you'll find as a collab :)
the community will find it helpful for sure
dawn urchin
I also was planning on using ue5.4's new motion matching animation system which as long as I also replicate velocity information and such and do a little math on the client side could be the perfect match of getting smooth animations with this fully server authoritive movement
and in terms of hit detection, the proxy location ticks that get sent to the clients can also have server time data and therefore the interpolated location and time should be able to exactly match a interpolatable server location
dawn urchin
reading through the article it seems like its gonna be kinda a lot of work to implement this new netcode system
dawn urchin
I think the big question on difficulty is if im changing the system or making it work for the characters only
vagrant stag
u dont have to implement/buy snapnet
or the full extent of the solution, you simply want to opt out from the part that movement is extrapolated
dawn urchin
yeah I think its doable to override some of the handling on the side of the character
dawn urchin
I screwed around with it a little bit. I think the amount of work it would take to work around the existing unreal sytems is not really worth my time right now with the other development things I have to do.
I may come back to it in the future
dawn urchin
I FIXED MY OLD HIT DETECTION PROBLEM
I tried to do little bit of the new net code and it was not working well so I reverted to my version control before I started but I applied some of the things.
Basically each character has a "ServerStateTime" value that updated from the server every tick and also on client side tick the timer goes up, but it represents the server time for the pawn's respective location which when used in the same rewound hitscan code I was using before perfectly matches the bounding boxes to where the should be.
vagrant stag
can you elaborate?
because this sounds like it would drift a lot, since its not a synced clock
dawn urchin
it is synced
it's just synced per pawn
or per "rewinding component"
and its synced with the time of the movement replication not where the "actual server time" is at the moment.
basically on tick on the server I replicate the current server time over with no ping compensation. it's on purpose because that non-compensated time on the server will match up with the the client sees them because the character's location also has the same delay with ping.
vagrant stag
and its synced with the time of the movement replication not where the "actual s...
ah if you need your clock with no ping compensation then use the default clock that exists in the gamestate, you dont need to create another one