FunkyBit

I can confirm these console errors. I see them ALL the time (also clean core).

I agree that is it worth to fix warnings. If there is NO problem with the code that produces warnings... why are there warnings? So warnings exist for a reason. So the should be fixes if possible. Easy conclusion. So thanks for taking care about these warnings!

* What bug does the patch fix? Currently "Blessing of Light" increases not the healing taken by the player who has this buff. It wrongly increases the healing done by a paladin that buffs this spell onto himself. It was wronly taken the AuraList of the caster of the healing spell instead of the AuraList of the target. * For which repository revision was the patch created? MaNGOS-One, s1434 (up2date) * Who has been writing this patch? me diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp index 43b396a..44f5f08 100644 --- a/src/game/Unit.cpp +++ b/src/game/Unit.cpp @@ -6528,7 +6528,7 @@ uint32 Unit::SpellHealingBonusTaken(Unit *pCaster, SpellEntry const *spellProto, // Blessing of Light dummy effects healing taken from Holy Light and Flash of Light if (spellProto->SpellFamilyName == SPELLFAMILY_PALADIN && (spellProto->SpellFamilyFlags & UI64LIT(0x00000000C0000000))) { - AuraList const& mDummyAuras = pCaster->GetAurasByType(SPELL_AURA_DUMMY); + AuraList const& mDummyAuras = GetAurasByType(SPELL_AURA_DUMMY); for(AuraList::const_iterator i = mDummyAuras.begin();i != mDummyAuras.end(); ++i) { if((*i)->GetSpellProto()->SpellVisual == 9180)

I just hat the time to take the first look at the patch. Do I understand it right, that you used only ENTRYs to link and group creatures? So it is only possible to link a complete species of creatures to an other? If that is: That would be not sufficient to cope with all the creature-to-creature respawn relations in all the different instances. It is often that you find a species bevor and after a boss and if the boss dies the mobs bevor should not respawn but the mobs after him should. For my opinion the GUID of each mob must be used to link this spawned creature to an other one. Otherwise I see no way to apply this system for example to Eye of the Storm, SSC, Steamvault, Karazhan, Gruul, Shadow Lab. and many more. Edit: Ah sorry, just have re-read the first post and found: Well ok... but still... for my feeling and as I mentaly walked through the instances... the total generic solution by using the ENTRYs is the rare one.

I didn't know Github can already do that on its own. I can recommend http://twitterfeed.com and what you get as postet tweets looks like this: - https://twitter.com/#!/MaNGOS_TBC - https://twitter.com/#!/ScriptDev_TBC Than you can also look at how many clicks the short-link inside the tweed has recieved.

Thanks this solved the problem! But there is still the problem that the WoW TBC client won't start under Lion

Confirmed. Is a bug in One and the linked master commit can fix the problem.

In general this statement is wrong. In instances (and this was tested by my girlfriend in SSC just last week on retail) whenever you have a group of mobs that all come together on pull... ...whenever you whipe and at least one mob is still alive, then the whole group respawns and you have to do the whole group again. This results for mob groups that no "leader change" is needed because on enter evade all respawn and the default leader is available again to link the other mobs. I can't imagine a case where you kill just a part of a group and the rest needs to choose a new leader and continue their path - either you defeate them or they defeat you -> no mob left or all respawn and reset. This grouped respawn (and also grouped aggro; means that you can define mobs standing together and you can never just pull one or a part of it) behaviour is missing for MaNGOS. If you take these challenges as seperate tasks and implement these first... you don't have to worry about the behaviour when patrolling mob groups just die partly. Please note: Just take this statement valid for TBC instances as SSC, Eye, ... that I have seen myself working that way. I didn't pay attention to this in the open world area or WotLK/Classic instance content.

Yeah, congratulations! I'm using this branch for some time now and I'm happy to see it her finally. Without this branch working with MaNGOS on a Mac OS machine (and Debian also) would have been hell to me since there was no Xcode project bevor. Hopefully this will make it's way into the official repos and then improve the whole process for everyone. Nice work and big thanks!!

Use this patch, it fixes the ACE_LIB_TEXT Problem: https://github.com/cipherCOM/mangos/commit/ce2638fd623a5ba20ec4a0a1a0702e3cd699eb0e Edit: Ok, it already found it's way into the repos in [10894] and [s0537]

diff --git a/dep/src/g3dlite/prompt.cpp b/dep/src/g3dlite/prompt.cpp index d78f8b7..df3da50 100644 --- a/dep/src/g3dlite/prompt.cpp +++ b/dep/src/g3dlite/prompt.cpp @@ -21,6 +21,7 @@ # define _getch getchar #endif +#undef G3D_OSX #if 0 /* MANGOS exclude for disabled gui prompt */ #ifdef G3D_OSX This should do it.

Yes and no. Is I have written in the first post the patch is for mangos-0.12 and there "MapDifficulty" does not exist. So "yes" maybe that fixes it for the WotLK branch and "no" it would not work for the TBC branch

Fixed a little error in patch. First Post updated.

What Bug is this about? When a server is up longer than 2 days the heroic instances don't get resetted anymore. What version was this Bug written for? MaNGOS-0.12 up2date; as far as I read the code this could be a problem in Master too. Who tracked the error down and wrote the change? Funkybit and Baileys Description of Bug in Detail: I have to restart my server at least every 2 days otherwise the daily or raid instances don't get their ID killed in the morning. So I noticed that 'm_resetTimeQueue' was about 32 entries right after server start but after a daily reset of heroic instances it only contains 17 entries. This concludes for me to: After you start your server, the heroic instances get resetted once normaly when the schedule event expires. Than after an other day there is no event to expire again because when the last one for that map was executed it gets deleted but not readded to the queue. So we need to re-add it as it already happens in the 'event.type != RESET_EVENT_INFORM_LAST' case of the 'ScheduleReset(..)' method. This way we can ensure that there is always an event for each map that can expire and delete all the instance id's in the database. diff --git a/src/game/InstanceSaveMgr.cpp b/src/game/InstanceSaveMgr.cpp index bc8d89d..267a751 100644 --- a/src/game/InstanceSaveMgr.cpp +++ b/src/game/InstanceSaveMgr.cpp @@ -287,28 +287,45 @@ void InstanceResetScheduler::ScheduleReset(bool add, time_t time, InstanceResetE void InstanceResetScheduler::Update() { time_t now = time(NULL), t; - while(!m_resetTimeQueue.empty() && (t = m_resetTimeQueue.begin()->first) < now) + while (!m_resetTimeQueue.empty() && (t = m_resetTimeQueue.begin()->first) < now) { InstanceResetEvent &event = m_resetTimeQueue.begin()->second; - if(event.type == RESET_EVENT_DUNGEON) + if (event.type == RESET_EVENT_DUNGEON) { // for individual normal instances, max creature respawn + X hours m_InstanceSaves._ResetInstance(event.mapid, event.instanceId); - m_resetTimeQueue.erase(m_resetTimeQueue.begin()); } else { - // global reset/warning for a certain map + // global reset/warning for a certain map (heroic/raid) time_t resetTime = GetResetTimeFor(event.mapid); m_InstanceSaves._ResetOrWarnAll(event.mapid, event.type != RESET_EVENT_INFORM_LAST, uint32(resetTime - now)); - if(event.type != RESET_EVENT_INFORM_LAST) + if (event.type != RESET_EVENT_INFORM_LAST) { // schedule the next warning/reset event.type = ResetEventType(event.type+1); ScheduleReset(true, resetTime - resetEventTypeDelay[event.type], event); } - m_resetTimeQueue.erase(m_resetTimeQueue.begin()); + else + { + // re-schedule the next/new global reset/warning + // calculate the next reset time + InstanceTemplate const* temp = ObjectMgr::GetInstanceTemplate(event.mapid); + uint32 diff = sWorld.getConfig(CONFIG_UINT32_INSTANCE_RESET_TIME_HOUR) * HOUR; + uint32 period = InstanceResetScheduler::GetMaxResetTimeFor(temp); + time_t next_reset = ((resetTime + MINUTE) / DAY * DAY) + period + diff; + + ResetEventType type = RESET_EVENT_INFORM_1; + for (; type < RESET_EVENT_INFORM_LAST; type = ResetEventType(type+1)) + if (next_reset - resetEventTypeDelay[type] > now) + break; + + // add new scheduler event to the queue + event.type = type; + ScheduleReset(true, next_reset - resetEventTypeDelay[event.type], event); + } } + m_resetTimeQueue.erase(m_resetTimeQueue.begin()); } } http://gist.github.com/593766 http://pastebin.com/mT6fHn0y So, I'm not really shure if this is the right way to do and would be happy to discuss this if any of you thinks it's wrong. Greets! Funkybit

Hi! Just apply this little patch here diff --git a/dep/src/g3dlite/prompt.cpp b/dep/src/g3dlite/prompt.cpp index d78f8b7..df3da50 100644 --- a/dep/src/g3dlite/prompt.cpp +++ b/dep/src/g3dlite/prompt.cpp @@ -21,6 +21,7 @@ # define _getch getchar #endif +#undef G3D_OSX #if 0 /* MANGOS exclude for disabled gui prompt */ #ifdef G3D_OSX AND pimp the flags of your configure call with: CFLAGS="-framework Carbon" CXXFLAGS="-framework Carbon" This works for me and a second friend who also compiles on Mac OS X. Hope I could help!