With cordite in the air, splintered steel, shell casings and powder burns, there’s only one explanation...
Discuss & improve the game engine.

Moderators: Tequila, sparcdr, torhu

Invisibility bug review needed

Postby Tequila » Sun Jun 07, 2009 11:01 am

Hi,

I found yesterday what really involved the invisibility bug. The fix needs few tests so if available coders what to do some tests before I commit the fix that would be a good idea.

Firstly, here is the final fix I have at that time for the 1.1 branch, but it should work also with 1.0 release:
1. Remove the workaround I found last summer in code/game/g_utils.c by removing the 2 last lines in the G_InitGentity function
2. Apply the fix by removing the last line (the "trap_LinkEntity(ent);") of G_MoverContents function in code/game/g_mover.c... that's all.

Secondly, after only removing the last summer workaround, you can reproduce the invisibility bug by:
1. start a dedicated server with only one bot and without connecting as client, start the dm_train map: you'll obtain a bot playing in Santa Fe Express map. That bot will then own the entity number 0, that's the important point... (You can also reproduce the case with 2 guys without bots and the first connected guy should own the entity number 0)
2. Connect as client and go in free spectator mode, you'll own the entity number 1
3. As spectator, follow the bot and you should see it going invisible each time it comes next to a door. I discover one thing, if you add other bots, or if other guys are playing, each time someone comes next to a door, the bot as entity 0 will become invisible even if it is not next to a door. So with more bot/people the bot can become invisible really often... Normally you won't see its shadow, but you can see it if you spectate the bot in third person view.

Thirdly, apply the fix, and test again, everything should be normal now.

Maybe other bugs can be related to that fix. Tell me if you notice something.

About the fix, the bugged trap_LinkEntity(ent) will be called everytime a player entity is comming next to a door as G_MoverContents is used to check if the player trigger the door. Then linked entity will be in fact the last known by the game... and should only be an empty one with also "0" as entity number, but also empty mix/max and that's explains why the entity 0 will become invisible... So I'm not completly sure the logic around that test is the best, so anyone interested to enhance it can try some other way and propose the best he found.
Also, my last summer workaround should have involved a little more network traffic by sending too many entities to each clients at each network frame, so that new fix should improve a little the network efficiency. I still don't know if that can be a real improvement, but any such gained overhead should remove any minor cases we can't really understand.

Then I won't be around (and won't do deeper tests then) for 3 days or more, so any other good report before I came back about that bug could help ;)
Thanks in advance to contributors :D

Edit: Fixed a typo in the thread title... :cry:
Last edited by Tequila on Tue Dec 07, 2010 11:22 am, edited 1 time in total.
User avatar
Tequila
SG Team
 
Posts: 1087
Joined: Thu Nov 15, 2007 11:33 pm
Location: Montpellier, France



Postby torhu » Wed Jun 10, 2009 2:40 am

Nice work. :) I'll see if I can do some testing maybe tomorrow or at least this weekend.
In game: =SG=monSter
Monster Browser
User avatar
torhu
SG Team
 
Posts: 1109
Joined: Thu Jan 06, 2005 8:12 pm
Location: Norway



Postby Tequila » Thu Jun 11, 2009 10:45 am

:D
I forgot to thank you torhu as you remind me to follow the bug list after I triggered Conq to do the same :D
So I committed that fix in r233.

Please check that bug fix before the one in r234 maybe related to About little freeze/lag (magnified in Train)

Btw we really need a visible bug tracker, I saw moddb is about to give access to some Trac environment... (check that
MODDB blog entry). If people thinks that could a good idea to join that Moddb effort I can try to officially contact them for the team.
User avatar
Tequila
SG Team
 
Posts: 1087
Joined: Thu Nov 15, 2007 11:33 pm
Location: Montpellier, France



Re: Inivisibility bug review needed

Postby TheDoctor » Mon Dec 06, 2010 3:40 am

Tequila wrote:the workaround I found last summer in code/game/g_utils.c, the 2 last lines in the G_InitGentity function.

Just a note on the temporary workaround, which I think is included in SG1.0 (at least in SG 1.0 SVN r531): The workaround forces the continuous transmission of all player entities (ever touching a door?), thereby levering out the area/cluster checks of SV_AddEntitiesVisibleFromPoint in server/sv_snapshot.c. It is responsible for the current clairaudient acoustics of SG, i.e. the audibility of far away players through all kinds of walls and ground and probably also for the bug in duels, where you can sometimes see players of the other arenas.

The suggested fix works well, re-enabling the area/cluster checks and therefore making the acoustics more realistic. For instance, you can no longer overhear players in the cellar/tunnels of dm_dry. As the area/cluster checks can be seen as a basic form of anti-wallhack functionality, they complement the method SV_IsPlayerVisibleFromPoint (the latter method needs only be called for entities passing the area/cluster checks).
User avatar
TheDoctor
Smokin' Amigo!
 
Posts: 753
Joined: Sun Jun 06, 2010 3:31 am



Postby Tequila » Tue Dec 07, 2010 11:27 am

Thanks for your fine and nice analysis ;)
User avatar
Tequila
SG Team
 
Posts: 1087
Joined: Thu Nov 15, 2007 11:33 pm
Location: Montpellier, France




Return to Code

Show Sidebar
Show Sidebar

User Control Panel