Invisible Spots
- Thread starter X-Bomb
- Start date
-
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.
@invis:
For each player UT maintains a list of "relevant" actors. To save bandwidth UT only transmits info on the actors that it "thinks" the client should see.
The number of relevancy checks UT needs to make is (number of players)*(number of actors) so it needs a VERY fast method to determine if a player can see an actor. Both invisible and transparent brushes will cause check to fail but movers will not. (Glass bridge on submarine blocks but glass floor at final on bridge does not)
Also the check is not performed every tick so there is usually a delay before the invisibility kicks in.
We know of a few ways to fix it:
1) Making an AL version where the problem brushes have been replaced with movers (they dont have to move)
2) Setting balwaysrelevant to true for all actors will fix all invis problems (except if caused by sliding which is something different). It doubles bandwidth however so not an option.
3) Placing a trigger at problem locations making players balwaysrelevant while touching it. This wont cause a significant increase in bw but otoh putting new triggers all over a map wouldt hurt cpu performance.
Both 1 and 3 requires that an invis spot is known before it can be fixed.
@lag on stairs
When you see another player walking up a staircase your clientside prediction thinks that each step is a wall and simulation will stop at that step until a new update is received. This makes the movement appear jerky.
@lag on slopes:
I noticed that too although i dont know what is causing it. On very steep slopes ppl seem to warp alot even when moving in straight lines.
@lag on water:
As mentioned the mesh is a very poor approximation of the "hitcylinder" when swimming. A rule of thumb: the hips will remain at the center of the hitcylinder no matter what a player is doing so aiming above hips should give a headshot.
Its not impossible that there could be some lagdistortion for ppl swimming though. UTs netcode tends to be "lazy".
For each player UT maintains a list of "relevant" actors. To save bandwidth UT only transmits info on the actors that it "thinks" the client should see.
The number of relevancy checks UT needs to make is (number of players)*(number of actors) so it needs a VERY fast method to determine if a player can see an actor. Both invisible and transparent brushes will cause check to fail but movers will not. (Glass bridge on submarine blocks but glass floor at final on bridge does not)
Also the check is not performed every tick so there is usually a delay before the invisibility kicks in.
We know of a few ways to fix it:
1) Making an AL version where the problem brushes have been replaced with movers (they dont have to move)
2) Setting balwaysrelevant to true for all actors will fix all invis problems (except if caused by sliding which is something different). It doubles bandwidth however so not an option.
3) Placing a trigger at problem locations making players balwaysrelevant while touching it. This wont cause a significant increase in bw but otoh putting new triggers all over a map wouldt hurt cpu performance.
Both 1 and 3 requires that an invis spot is known before it can be fixed.
@lag on stairs
When you see another player walking up a staircase your clientside prediction thinks that each step is a wall and simulation will stop at that step until a new update is received. This makes the movement appear jerky.
@lag on slopes:
I noticed that too although i dont know what is causing it. On very steep slopes ppl seem to warp alot even when moving in straight lines.
@lag on water:
As mentioned the mesh is a very poor approximation of the "hitcylinder" when swimming. A rule of thumb: the hips will remain at the center of the hitcylinder no matter what a player is doing so aiming above hips should give a headshot.
Its not impossible that there could be some lagdistortion for ppl swimming though. UTs netcode tends to be "lazy".
the mesh-hitzone disharmony for swimming players is known for 5 years. What ive only noticed recently and exclusively on bridge is what Stylefish already said:
snpier jump into the water and swim in it at about surface level. Yet they are displayed about 3 metres deep in the water.
You are free to try aiming for those hips, youll hit nowhere but *FAR* too low.
Afaik this only happens for players who are on the water surface and not completely in the water so maybe this can help fixing it.
snpier jump into the water and swim in it at about surface level. Yet they are displayed about 3 metres deep in the water.
You are free to try aiming for those hips, youll hit nowhere but *FAR* too low.
Afaik this only happens for players who are on the water surface and not completely in the water so maybe this can help fixing it.