H0zen

Fixed with [URL="https://github.com/mangoszero/server/commit/2b8c55ead053d003da075ed6ebe7d2fb9e29fefb"]this commit[/URL]. Can be closed.

Fixed yesterday with [URL="https://github.com/mangoszero/server/commit/6d77f1839400204c3d8cb16f8a74b2af1415df6e"]this commit[/URL]. Pull and rebuild.

mangosd.conf - Timebar.Breath.Max = 60

@ascentu - [URL="https://github.com/mangoszero/server/commit/b35a53e2b92c191fff54023a7df05f77640e67f7"]https://github.com/mangoszero/server/commit/b35a53e2b92c191fff54023a7df05f77640e67f7[/URL]

@magic - thank you for your report. While issues #1 and #2 were solved, due to their severity, the rest of them are somehow new (at least for me) and we'll take great care to fix them as soon as possible.

Fixed by [url]https://github.com/mangoszero/server/pull/98[/url] The issue can be closed.

Thanks, Olion, for pointing at the root cause. A [URL="https://github.com/mangoszero/server/pull/94"]pull request[/URL] has been made to correct this inexcusable mistake.

I hope you are talking about the flag 0x40, which is 64 in decimal :)

DoSpellHitOnUnit is called when spell succeeded ([URL="https://github.com/mangoszero/server/blob/develop21/src/game/WorldHandlers/Spell.cpp#L957"]Spell.cpp@957[/URL]). In this case, Mind Soothe will not aggro. But for the resist case, the target will aggro ([URL="https://github.com/mangoszero/server/blob/develop21/src/game/WorldHandlers/Spell.cpp#L979"]Server.cpp@L979[/URL])

Fixed in develop21 with commit [URL="https://github.com/mangoszero/server/commit/91df8aa4a6351e45a854036b711e679c702d88d8"]91df8aa[/URL]. Can be closed.

Fixed in develop21 with commit [URL="https://github.com/mangoszero/server/commit/91df8aa4a6351e45a854036b711e679c702d88d8"] 91df8aa[/URL]. Can be closed.

Fixed [URL="https://github.com/mangos/Extractor_projects/pull/8"]with this PR[/URL]. After it's merged, the extractor tools must be rebuild and all maps/vmaps/mmaps reextracted. The issue can be closed.

This issue is fixed now in develop21 branch with commit [URL="https://github.com/mangoszero/server/commit/d721f96076429e6f6e64ca3f7ad25c6b1a9a3d20"]d721f96[/URL].

If you take a close look to the [I]player_classlevelstats[/I] table in the world database, you'll notice that the warriors (class = 1) at level 10 have a base hp of 101 and at level 11 base hp = 100. Indeed, there is something wrong in the database. You can investigate closer and do a PR when you have some spare time. Edit Not only warriors loose hp when they grow up. Look closer at class 2, level 1 & 2 :)

Fixed in develop21 branch

Fixed in develop21 branch

Fixed by commit [URL="https://github.com/mangoszero/server/commit/2cb1c7fc97c9ec36781ad6e19e4bef5ea6e882f8"]2cb1c7f[/URL]. Can be closed.

Fixed by commit [URL="https://github.com/mangoszero/server/commit/2cb1c7fc97c9ec36781ad6e19e4bef5ea6e882f8"]2cb1c7f[/URL]

Fixed by commit [URL="https://github.com/mangoszero/server/commit/fd62f76df91ebd869debd2b0643b774489ad4aad"]fd62f76[/URL]

Fixed by commit [URL="https://github.com/mangoszero/server/commit/f8f4d90dcfc89faed7b959e8858a1ed62d041f9f"]f8f4d90[/URL]

Thanks for your detailed debug info. The fix [URL="https://github.com/mangoszero/server/pull/62"]has been found[/URL]

[quote=Xenithar]I found the issues. You can't do safe updates without specifying an index. I removed all commenting, coding, everything except SQL from the update and ran it. It ran until it hit the following lines. [code] update dbdocsfields SET FieldComment = replace(FieldComment, 'table', 'table'); update dbdocsfields SET fieldNotes = replace(fieldNotes, 'table', 'table'); [/code] There is no index given so it was failing due to not being a safe operation. This was not being shown in the errors log, but it was causing the rollback flag to trip. All updates MUST specify an index! I now have to delete everything up to this line and figure out how to correct it so I can complete the update.[/quote] To make these lines safe add an "always true where clause", involving an index, like you did in a previous PR (21_1_16, if I remeber right). Like: update dbdocsfields SET FieldComment = replace(FieldComment, 'table', 'table') where `fieldId`> 0; update dbdocsfields SET fieldNotes = replace(fieldNotes, 'table', 'table') where `fieldId`> 0; This is a standard procedure to calm down the angry MySQL. PS: What is the meaning of those 2 updates? Maybe I`m blind, but I don't get it. It replaces all occurences of "table" with.. "table"? In the comments I see something about "fixing a typo"...

The fix for this issue has been [URL="https://github.com/mangoszero/server/pull/60"]PR`ed[/URL]. The problem was the destruction of various static ACE_TSS objects. A great hint was quite the [URL="http://www.dre.vanderbilt.edu/Doxygen/5.7.9/html/ace/a00737.html#_details"]documentation[/URL] (the note)

[quote=Xenithar]I will PR that if that is the ONLY entry being updated. Is that confirmed?[/quote] What do u mean by "if that is the only entry"? If it's about the records affected, the addition is an always-true, harmless expression involving a key, as to suppress the MySQL error.