Lynx3d

Yes, delete checks for Null-pointers, yet many many people still do it redundantly, probably because they learned C before where free() did NOT check pointers. I had seen it that often that i even believed myself it was needed when i started C++, but it isn't. Both clear() calls the destructor of the element type. Elements here is Item* (pointer to Item), pointers do not have any real destructor, they only hold a memory address. So yes, you do leak the memory from all items if those were supposed to get deallocated here.

Greetings, there was a thread with a nice collection of known things on how creatures on transports should work (i think in this section but not sure), but it seems it got wiped with last forum maintenance. If anyone (TheLuda?) could restore it, or has a copy or simply other useful information, that would be great, as there is some thread in the public section that deserves a bit of input IMHO. Maybe it'll result in something worth looking at.

Then you're doing it wrong And maybe read commit log next time: http://github.com/mangos/mangos/commit/9fda6b50752803f33afdc88962c2594356ccd7ed

Fix commited as [10275], thank you. Was just too tired to not confuse Alias with Name when looking at your github profile...one day i'll do a perfect commit -edit- If it still crashes i don't know right now, at least i have no problems.

tehmarto: Your line numbers are suspicously off compared to [10264]...what revision with which custom patches are we talking about this time?

And i don't think you'll have much success trying to read Visual C++ debug information with cygwin's gdb... I heard there's a special mingw gdb version called "Dr. Mingw" that can read MS' PDB files.

m_modAuras is no member of SpellAuraHolder, so no, cannot put it in the destructor. Also, you're talking about Unit::AddSpellAuraHolder(SpellAuraHolder *holder), if it gets deleted here, it is not yet added to Unit and its auras can't be in m_modAuras anyway...or at least i think it shouldn't. This is also the only place besides RemoveSpellAuraHolder() where holders are deleted, and RemoveSpellAuraHolder() clearly takes care of m_modAuras removal by calling RemoveAura() -edit- never mind, my proposed change was not required...

Ah yes weapon type implementation was never implemented either Unfortunately, Titan's Grip is the only talent which enables special equipment abilities, which makes some "generic" implementation little more than a guessing game. And it seems unlikely there will be more of those until the next expansion turns every single class upside down... I had thought about something like keeping a seperate list of Effect #155 spells and check them for equipment requirements and apply the referenced spell if the item could only be equipped using this special ability, but who knows if that is reasonably close to how blizz designed it, and all for just 2 spells in the whole game (well, plus one "Dual Wield 2H Test" definitely not available to players)... Also the fact that it is not just a new aura type also made us wonder if blizzard really has anything more than a mostly hard-coded solution...

More or less accepted in [10248], at least the idea survived Required some adaptions (no surprise after this time...) but some things just didn't seem correct to me. Don't understand why you modified Player::UpdateZone(). About: There is a config option "OffhandCheckAtTalentsReset" that should take care of it, better enable it instead of removing the code for it. Also Player::QuickEquipItem() required a check too, otherwise you did not have the damage penalty right after login, allowing for some abuse. Maybe the Player::UpdateZone() was a workaround for that? But i totally forgot to mention you as author in commit, sorry about that -edit- argh, the first posts are so old that they don't have a thanks button...so, thanks everyone for their effort!

Report doesn't make much sense, Flametongue Weapon dummy proc was not implemented at all, so it could not "hit more than it should"...

Several things not very nice or plain wrong in this patch, after a lot of work and many dead creatures, new implementation finally added to [10237].

Alternative fix added in [10237] On further investigation, after patch 3.1 spellpower bonus was no longer a fixed 10%, probably the reason why the proc spell is a dummy which does a custom attack spell cast. This also prevents the downranking problem, the attack spell does not get any direct spell damage bonus. Also special care was required to make it proc only for attacks of the enchanted weapon. And another fix was required to make some special attack properly be detected as off-hand attacks, such as the Stormstrike off-hand attack and Lava Lash. Hope i got everything right... One remaining bug: When enchanting main-hand, Stormstrike procs Flametongue twice, because the base spell triggers two attack spells, but itself is also classified as melee attack spell. Funnily enough, this bug even existed (or maybe even still does?) on retail servers... This however must be considered a Stormstrike bug and may affect other procs too, not just Flametongue. Needs further research...

In [10234]. Thank you

/me plays Vladimir In [10201] Thank you

Someone should definitely remove that horrible shell script from the wiki... If you would just read the error message and apply the updates from the stated revision, everything would work. Note that if your DB is too old, not all SQL updates are in the updates base directory, but in 0.xx subirs. You may also try the Python script I wrote to ease the apply process. It's not completely fool-proof either, but at least reads current revision and sorts updates properly. Need to adjust the variables in the beginning to your setup: http://gist.github.com/480372

*digs out thread* That formula doesn't make sense, gives values >100%... After trying several ways to modify it, the most plausible answer to me is that the formulat simply got "stretched" by 20%, that would give: int32 chance = SkillValue < 90 ? 100 : 3000/(SkillValue-60);

Yes random spawns for pools are indeed implemented and also used by UDB for ores (not all yet AFAIK), plants and rare mobs. Pool means you create a number of spawns (say 300+ locations for herbs) and group them with a limit of how many can be spawned at the same time (for example 40 of those 300). However random replacement of type A with type B is not very elegant IMHO, while technically possible by using pools of pools, you need to create two spawns (one for each object type) for each location and put each pair in a sub-pool.

Once again...

For linux see README files in the respective tools dir...

Well i couldn't reproduce the crash (well freeze actually), but for this to trigger you really have to be exactly at an object border, matching to the last float bit. Possibly some architectural differences (x87 vs. SSE2 math) could also influence chances for the bug to occur. In any case, the code that cause above mentioned wrong values should be fixed in [10190]. If you can reproduce the crash by ".go xyz x=1177.09558 -6162.37158 232.168243" then just test before and after the commit to be sure it worked.

Thanks for the exhaustive dedbug info. I haven't tried to reproduce yet, but i think i already see the problem... intervalMin = -nan(0x400000) intervalMax = -inf These ones are already incorrect...and i even had thought about switching out this bound intersection code...well, hindsight is easier than foresight... -edit- Can you tell me which map caused the crash in your second log? Unfortunately it got optimized out...

Hm i'm not sure this is really correct. currently, core assumes flat water and only uses the lower left vertex of a liquid tile, no interpolation/tesselation performed. So those "omitted" values are actually never used from what i can tell. Technically, the (maximum) amount of height values is liquid_height[ADT_CELLS_PER_GRID*(ADT_CELL_SIZE+1)][ADT_CELLS_PER_GRID*(ADT_CELL_SIZE+1)] and not liquid_height[ADT_GRID_SIZE+1][ADT_GRID_SIZE+1] Actually, System.cpp:675 does overwrite values, which is only okay if liquid data never has abrupt height changes between cells, but in any case the client data definitely allows it. -edit- I just modified extractor, in Northrend 3 values are overwritten with differing heights, and in Azjol_LowerCity 14 values are overwritten, so liquid meshes can be discontinuous across cell borders. Probably a minor issue, but still current data is incomplete...

You code lines are way off in comparison to [10175]....or any revision after. So much for "no custom patches" and "clean core"...

Are you sure you actually enabled vmaps on map 571? Because just below dalaran is a river in crystalsong forest, and witout vmaps enabled (or the old vmap system) your bobber will land in the river below. I've tested fishing in dalaran after just about every little change i made, i'm 99.99999% sure it works fine.

So sanctuary thing is a problem of players above level 80? I'm afraid I can't really help there, vmap code doesn't query player level anywhere (it can't even), it just reads the correct area entry instead of using hardcoded ones for a few roughly defined bounds. Whatever it is, I'm confident that I didn't break it And honestly, when custom patches and custom level caps are involved, all alarm bells ring anyway...