xarly

Yes, that's right that it would be better don't teleport player and send a message like when you try to enter without raid ("You must be in a raid group to enter X instance"), but I didn't find out how implement that about + if (!player->isAlive()) + player->ResurrectPlayer(0.5f); I think that isn't necessary, player will revive when enter at instance

I'm pretty sure you are doing something wrong, check brackets just in case. This patch cannot cause compile errors

I think this is because a custom patch, I had the same problem and I fixed it adding some modifications in MovementHandler.cpp diff --git a/src/game/MovementHandler.cpp b/src/game/MovementHandler.cpp index 5e42bab..f7f1a39 100644 --- a/src/game/MovementHandler.cpp +++ b/src/game/MovementHandler.cpp @@ -43,8 +43,5 @@ void WorldSession::HandleMoveWorldportAckOpcode() // ignore unexpected far teleports if(!GetPlayer()->IsBeingTeleportedFar()) return; // get the teleport destination + float PlayerX = GetPlayer()->GetPositionX(); + float PlayerY = GetPlayer()->GetPositionY(); + float PlayerZ = GetPlayer()->GetPositionZ(); uint32 PlayerMap = GetPlayer()->GetMapId(); WorldLocation &loc = GetPlayer()->GetTeleportDest(); @@ -50,8 +50,5 @@ void WorldSession::HandleMoveWorldportAckOpcode() // possible errors in the coordinate validity check if(!MapManager::IsValidMapCoord(loc.mapid, loc.coord_x, loc.coord_y, loc.coord_z, loc.orientation)) { sLog.outError("WorldSession::HandleMoveWorldportAckOpcode: player %s (%d) was teleported far to a not valid location. (map:%u, x:%f, y:%f, " "z:%f) We port him to his homebind instead..", GetPlayer()->GetName(), GetPlayer()->GetGUIDLow(), loc.mapid, loc.coord_x, loc.coord_y, loc.coord_z); // stop teleportation else we would try this again and again in LogoutPlayer... GetPlayer()->SetSemaphoreTeleportFar(false); // and teleport the player to a valid place - GetPlayer()->TeleportToHomebind(); + GetPlayer()->TeleportTo(PlayerMap, PlayerX, PlayerY, PlayerZ, 0, 0); return; } @@ -77,8 +77,5 @@ void WorldSession::HandleMoveWorldportAckOpcode() // the CanEnter checks are done in TeleporTo but conditions may change // while the player is in transit, for example the map may get full if(!GetPlayer()->GetMap()->Add(GetPlayer())) { //if player wasn't added to map, reset his map pointer! GetPlayer()->ResetMap(); sLog.outError("WorldSession::HandleMoveWorldportAckOpcode: player %s (%d) was teleported far but couldn't be added to map. (map:%u, x:%f, y:%f, " "z:%f) We port him to his homebind instead..", GetPlayer()->GetName(), GetPlayer()->GetGUIDLow(), loc.mapid, loc.coord_x, loc.coord_y, loc.coord_z); // teleport the player home - GetPlayer()->TeleportToHomebind(); + GetPlayer()->TeleportTo(PlayerMap, PlayerX, PlayerY, PlayerZ, 0, 0); return; } With this, player is teleported where he was before trying to enter

I thougth about "player->GetMapId() != GetId()", but I think that the main thing of this check is if pGroup is in combat, so no more checks are necessary, are they?

I have tested with // cannot enter while players in the instance are in combat Group *pGroup = player->GetGroup(); if(pGroup && pGroup->InCombatToInstance(GetInstanceId())) { player->SendTransferAborted(GetId(), TRANSFER_ABORT_ZONE_IN_COMBAT); return false; } return true; } and it works, so problem solved I think

wtf! look at this ------------------------------------------------------------------------------- bool InstanceMap::CanEnter(Player *player) { if(player->GetMapRef().getTarget() == this) { sLog.outError("InstanceMap::CanEnter - player %s(%u) already in map %d,%d,%d!", player->GetName(), player->GetGUIDLow(), GetId(), GetInstanceId(), GetSpawnMode()); assert(false); return false; } // cannot enter if the instance is full (player cap), GMs don't count uint32 maxPlayers = GetMaxPlayers(); if (!player->isGameMaster() && GetPlayersCountExceptGMs() >= maxPlayers) { sLog.outDetail("MAP: Instance '%u' of map '%s' cannot have more than '%u' players. Player '%s' rejected", GetInstanceId(), GetMapName(), maxPlayers, player->GetName()); player->SendTransferAborted(GetId(), TRANSFER_ABORT_MAX_PLAYERS); return false; } // cannot enter while players in the instance are in combat Group *pGroup = player->GetGroup(); if(pGroup && pGroup->InCombatToInstance(GetInstanceId()) && player->isAlive() && player->GetMapId() != GetId()) { player->SendTransferAborted(GetId(), TRANSFER_ABORT_ZONE_IN_COMBAT); return false; } return Map::CanEnter(player); } ------------------------------------------------------------------------------------ The function is written, but i think that not in the correct way, maybe player->isAlive() should be removed, beacouse if the player die inside, when he wipes, it's dead outside, and that restriction will never be true. And also I would replace return Map::CanEnter(player); by return true;, but i'm not very sure about that What do you think?

I have a friend in offy, he told me that only in raid instances

Instances like TOC has a counter of how many times the raid has wiped, so it's important tha testers cannot enter the instance until the raid is not in combat (all of them have wiped or have defeated the boss). In any other case, testers will always have the best mark, and then, the best loot, that's unfair. I wonder if can be implemented in core a system that don't allow testers to enter an instance while the raid is in combat. I think that in offy this system is working. Thank you

Sorry for post this here, I know that this forum is for bugs in lastest revision, but i didn't find where to comment this :confused:, also i have looked for this problem many times and nothing similar... The problem is that when I go in Trial of Crusade, there is no floor so I fall, but if with a gm go flying to the middle of the coliseum, the floor appears, for example, on this coords 563.7562 99.0595 394.5703 (near the entrance) the floor is missing, but on 564.0095 114.9868 294.3203 the floor is there Also i have seen that the minimap changes when there is no floor, showing the whole coliseum from above, not just the floor Please, can you help me? Thank you

Could you update this patch for last revision of 3.2.2?:rolleyes: I'm working with 9133, but this patch doesn't remove buff when player remove cat form

Mangos Version: 9133 Custom Patches:SD2_R1542 ACID_R302 Database Name and Version : YTDB R528 In Arenas, hunter pet is non attackable, appears as friendly for the other team. Only can be killed with areas I think it's a bug, isn't it?

For me the second variant not apply +10% max. health, i've not tested the first variant, but they are almost the same.. mangos 9133

Is it possible define a minimun required level for enter in Northrend? I would like to only allow players with at least level 68, as offy

What's the difference with this "Arsenal"? http://code.google.com/p/xmlarsenal/ Apparently are the same (Live Demo)

Is this patch compatible with my revision? Thank you

I have 3.2.2a, i'm testing this patch but when i talk with any innkeeper, server crash My conf: Mangos 9133 & SD2 1542 The last log line 2010-01-28 14:53:55 WORLD: Received CMSG_GOSSIP_HELLO

very useful thank you

If someone gets it running in IIS, please explain how I'm trying with "ISAPI_Rewrite 3" but nothing...

Thank you I will try this becouse i don't like delete data from db and bulek solution is only for equilibrate factions

Oh thank you, i will test it then

I would like to ask if anyone knows a way to change character faction, like the blizzard service . I have seen that some pservers have this service, but i cannot guess if it's a query, a command or they just create another character and do it manually... Thank you!

The logging data that exeeds 2*size_of_lines (two log files) is not stored, an will be lost. Maybe i have misunderstood how it works, bu If I am logging with Level 3 and the two logs files are full, Will i be able to see the last line logged? I think Aokromes is rigth. the better system would be Thank you anyway

PEOPLE! I have disabled spell 20185 and no more crash with Judgement of Light! Try it!

I have the same crash. but I think that is this spell also 20185 I paste some logs llid : 20053, Aura : 79 Duration : 30000 Target : 1 Damage : 3 2010-01-12 18:23:54 ProcDamageAndSpell: casting spell id 20375 (triggered by an attacker's dummy aura of spell 20375) 2010-01-12 18:23:54 ProcDamageAndSpell: casting spell id 31878 (triggered by an attacker's dummy aura of spell 31878) 2010-01-12 18:23:54 ProcDamageAndSpell: casting spell id 53382 (triggered by an attacker's dummy aura of spell 53382) 2010-01-12 18:23:54 Sending SMSG_SPELL_GO id=61840 2010-01-12 18:23:54 ProcDamageAndSpell: casting spell id 53488 (triggered by an attacker's dummy aura of spell 53488) 2010-01-12 18:23:54 ProcDamageAndSpell: casting spell 53488 (triggered by an attacker's aura of spell 53488) 2010-01-12 18:23:54 Sending SMSG_SPELL_GO id=59578 2010-01-12 18:23:54 Spell 59578 Effect0 : 6 2010-01-12 18:23:54 Spell: Aura is: 108 2010-01-12 18:23:54 Aura: construct Spellid : 59578, Aura : 108 Duration : 15000 Target : 1 Damage : -100 2010-01-12 18:23:54 Aura 108 now is in use 2010-01-12 18:23:54 ProcDamageAndSpell: casting spell id[color="Yellow"] 20185[/color] (triggered by a victim's dummy aura of spell 20185) 2010-01-12 18:23:54 Sending SMSG_SPELL_GO id=[color="Yellow"]20267[/color] 2010-01-12 18:23:54 Spell 20267 Effect0 : 10 2010-01-12 18:23:54 ProcDamageAndSpell: casting spell 60063 (triggered by an attacker's aura of spell 60063) 2010-01-12 18:31:14 Sending SMSG_SPELL_GO id=879 2010-01-12 18:31:14 Spell 879 Effect0 : 2 2010-01-12 18:31:14 ProcDamageAndSpell: casting spell id 20185 (triggered by a victim's dummy aura of spell 20185) 2010-01-12 18:31:14 Sending SMSG_SPELL_GO id=20267 2010-01-12 18:31:14 Spell 20267 Effect0 : 10 2010-01-12 18:31:14 deal dmg:125 to health:135 2010-01-12 18:31:14 Sending SMSG_SPELL_GO id=20271 2010-01-12 18:31:14 Spell 20271 Effect0 : 77 2010-01-12 18:31:14 Spell 20185 Effect0 : 6 2010-01-12 18:31:14 Spell: Aura is: 4 2010-01-12 18:31:14 Aura: construct Spellid :[color="Yellow"] 20185[/color], Aura : 4 Duration : 20000 Target : 6 Damage : 2 2010-01-12 18:31:14 Aura 4 now is remove mode 1 2010-01-12 18:31:14 Aura 4 now is in use 2010-01-12 18:31:14 Spell 20425 Effect0 : 3 2010-01-12 18:31:14 Spell 20467 Effect0 : 58 2010-01-12 18:31:14 Spell [color="Yellow"]20467[/color] Effect1 : 31 2010-01-12 18:31:14 ProcDamageAndSpell: casting spell 20375 (triggered by an attacker's aura of spell 20375) 2010-01-12 18:31:14 WORLD: Sent SMSG_AI_REACTION, type 2. 2010-01-12 18:18:42 ProcDamageAndSpell: casting spell id 31878 (triggered by an attacker's dummy aura of spell 31878) 2010-01-12 18:18:42 ProcDamageAndSpell: casting spell id 53382 (triggered by an attacker's dummy aura of spell 53382) 2010-01-12 18:18:42 Sending SMSG_SPELL_GO id=61840 2010-01-12 18:18:42 Spell 61840 Effect0 : 6 2010-01-12 18:18:42 Spell: Aura is: 3 2010-01-12 18:18:42 Aura: construct Spellid : 61840, Aura : 3 Duration : 8000 Target : 6 Damage : 82 2010-01-12 18:18:42 Aura 3 now is in use 2010-01-12 18:18:42 ProcDamageAndSpell: casting spell id 53488 (triggered by an attacker's dummy aura of spell 53488) 2010-01-12 18:18:42 ProcDamageAndSpell: casting spell 53488 (triggered by an attacker's aura of spell 53488) 2010-01-12 18:18:42 Sending SMSG_SPELL_GO id=59578 2010-01-12 18:18:42 Spell 59578 Effect0 : 6 2010-01-12 18:18:42 Spell: Aura is: 108 2010-01-12 18:18:42 Aura: construct Spellid : 59578, Aura : 108 Duration : 15000 Target : 1 Damage : -100 2010-01-12 18:18:42 Aura 108 now is in use 2010-01-12 18:18:42 ProcDamageAndSpell: casting spell id [color="Yellow"]20185[/color] (triggered by a victim's dummy aura of spell 20185) 2010-01-12 18:18:42 Sending SMSG_SPELL_GO id=[color="Yellow"]20267[/color] 2010-01-12 18:18:42 Spell 20267 Effect0 : 10 2010-01-12 18:18:42 ProcDamageAndSpell: casting spell 60063 (triggered by an attacker's aura of spell 60063) 2010-01-12 18:09:11 Sending SMSG_SPELL_GO id=61840 2010-01-12 18:09:11 Spell 61840 Effect0 : 6 2010-01-12 18:09:11 Spell: Aura is: 3 2010-01-12 18:09:11 Aura: construct Spellid : 61840, Aura : 3 Duration : 8000 Target : 6 Damage : 99 2010-01-12 18:09:11 Aura 3 now is in use 2010-01-12 18:09:11 ProcDamageAndSpell: casting spell id 53488 (triggered by an attacker's dummy aura of spell 53488) 2010-01-12 18:09:11 ProcDamageAndSpell: casting spell 53488 (triggered by an attacker's aura of spell 53488) 2010-01-12 18:09:11 Sending SMSG_SPELL_GO id=59578 2010-01-12 18:09:11 Spell 59578 Effect0 : 6 2010-01-12 18:09:11 Spell: Aura is: 108 2010-01-12 18:09:11 Aura: construct Spellid : 59578, Aura : 108 Duration : 15000 Target : 1 Damage : -100 2010-01-12 18:09:11 Aura 108 now is in use 2010-01-12 18:09:11 ProcDamageAndSpell: casting spell id [color="Yellow"]20185[/color] (triggered by a victim's dummy aura of spell 20185) 2010-01-12 18:09:11 Sending SMSG_SPELL_GO id=[color="Yellow"]20267[/color] 2010-01-12 18:09:11 Spell 20267 Effect0 : 10 2010-01-12 18:09:11 ProcDamageAndSpell: casting spell 60063 (triggered by an attacker's aura of spell 60063)

I have the same problem, this only happen in Salvaged Demolisher with spells Hurl Pyrite Barrel and Hurl Boulder As Numnut, i have updated to 9071, I think it may be a commit between 9062 and 9071.