[not mangos problem][CRASH] Camera-system (detalied)

[selector]

Core: [11001] Fixed crashes in ACE network code.

DB: YTDB 580

SD: never mind

Server crashes with such crashdump http://pastebin.com/7KXEAxe Found the cause of the crash:

Use spell Far Sight reg into BattleGround/Arena join map and use spell again = crash. After entering BG/arena all objects/players are "in another phase" and you don't see them.

Very easy to reproduce. Use .debug bg command, register BattleGround(but don't join), cast spell - join BG, cast spell again...

Crash appeared on clean core and with some mods(rsa's fork).

[VladimirMangos]

While i test your bug report i have only single time something like described crash but in same time find another source of crash in code cleary not related to spell cast. Found case fixed in [11015]. Can you recheck with this rev?

After this fix i can't repeat any crashes in many attempts.

[selector]

Didn't help

http://pastebin.com/HJMgP0es - crash

http://www.youtube.com/watch?v=N3Ku25wjlfk - video

As you could see. After been teleported to BG there was no dome(you don't see player's, GO's, etc.)

[_VENOM_]

After entering BG/arena all objects/players are "in another phase" and you don't see them.

nope. they ar NOT in another phase.

you removed your normal camera position to a diffrent place, after you teleported your character is on diffrent map but camera is still in orgrimar. looks like spell is still active. and when u use already active spell again then you get that crash.

i hope you got it

this looks like crash when i [mind control] player and make that player go to transport from orgrimmar to northrend. after teleport mind controled player crashed the server. becose its like imposble to use camera from diffrent maps or at really far range.

this crash is really old one.

[sart13]

bad hack for solve this problem (bad tested, but worked) -

https://github.com/rsa/mangos/commit/ba5d324d5ebf3150ded02f589e50a4e0bed1189e

for sample, problem whats type is appeared.

[VladimirMangos]

Hmm, but at my testes aura always correctly removed at far teleport and camera reset to player back.

[sart13]

tested on clean 11015.

shaman totem call-> switch view on character->teleport to BG-> switch to totem (or call new totem) = crush (may be delayed on 1-2 min).

hunter Eagle eye use->teleport while channeling->eagle eye use = crush

and many other this type. after hack - none of the above.

[VladimirMangos]

i will test...

[Vinolentus]

That hack isn't a solution.

Problem is:

Player's camera attached to dynamicObject's viewpoint. Player is teleported far, its map pointer is now nulled, it is in world no more.

IF dynamicObject 'll be removed now - we fail to reset camera

void Camera::SetView(WorldObject *obj, bool update_far_sight_field /*= true*/)
{
  ...
   if (!m_owner.IsInMap(obj))
   {
       sLog.outError("Camera::SetView, viewpoint is not in map with camera's owner.");
       return;
   }

and get crashed next visibility update or something like that.

[sart13]

this hack not a solution, this gag. it just clears _all_ possible set's the camera up to teleport, while not looking exactly which need to be cleaned. I do not have enough time to research the real mechanics of the problem...

[VladimirMangos]

all dynamic object created by player destroyed at far teleport _before_ teleport. So strange that problem exist. (i still not check yet suggested way for reproduce)

[Vinolentus]

sart13, it is not even a gag. MSG_MOVE_WORLDPORT_ACK received while player _NOT_ in world. Camera will not be reset.

Vladimir, no. Dynamic objects added to removeList in Player::TeleportTo. We handle removeList later.

[sart13]

for cleaning camera does not matter in the world player or not. cleared the camera object (linked with dynobject), and what is not a change of view is not important.

[VladimirMangos]

Vladimir, no. Dynamic objects added to removeList in Player::TeleportTo. We handle removeList later.

This is not related. remove list handeled at tick end. far teleport confirmation from client can't be received (and in any case processed) early next tick.

[VladimirMangos]

tested on clean 11015.

shaman totem call-> switch view on character->teleport to BG-> switch to totem (or call new totem) = crush (may be delayed on 1-2 min).

hunter Eagle eye use->teleport while channeling->eagle eye use = crush

and many other this type. after hack - none of the above.

I test this cases: no crash. Ofc, i test at clean mangos sources, so no mtmaps and etc patches.

[Vinolentus]

*sigh*

Player::TeleportTo
   |
   |-- Unit::RemoveAllDynObjects
   |
   |-- Map::Remove
       |
       |
       |-- Player::RemoveFromWorld
       |   |
       |   |
       |   |-- Unit::RemoveFromWorld
       |       |
       |       |
       |       |-- Object::RemoveFromWorld
       |           {
       |               ...
       |               m_inWorld = false;
       |           }
       |
       |-- WorldObject::ResetMap
           {
               m_currMap = NULL;
           }

[VladimirMangos]

And what?

Unit::RemoveAllDynObjects

1) cleanup dynobj list at owner side

2) call CleanupsBeforeDelete for dynobject that call DynamicObject::RemoveFromWorld

that call: GetViewPoint().Event_RemovedFromWorld() that call in chain ResetView();

And this all _before_ map reset for player.

[Vinolentus]

Uups... Pardon. Mea culpa. The only function I didn't checked was Map::AddObjectToRemoveList.

https://github.com/insider42/mangos/commit/52382da487dcf870b85aa890a5c5f50a9e717687

Old hack

[sart13]

I bring all the panelists apologize. As it turned out, my "clean" Branch had more than 20 differences from the off mangos, including those found by Vinolentus old patch from Silverice.

Indeed, the problem was precisely the refusal of treatment facilities in AddObjectToRemoveList

[VladimirMangos]

ok, so i mark problem as not mangos clean core related.