H0zen

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.

Until a PR will be made, edit the sql file and @line 53 add the following:

AND `entry`>0

The line in cause shall read

UPDATE `gameobject_template` SET `data2`=3 WHERE `type`=6 AND `data9`>0 AND `data2`=1 AND `entry`>0;.

I just [URL="https://github.com/mangostwo/server/pull/117"]PR the fix[/URL] for this issue. Hope all goes well from now on.

This has already been fixed with [URL="https://github.com/mangoszero/server/commit/3d7be378f4b75e9e83664b29916522891f08c54a"]this commit[/URL]

I [URL="https://github.com/mangoszero/server/pull/50"]PR a possible fix[/URL] for Zero (as the issue is there too). Needs vigorous testing in-game

Hi,
I`ve just [URL="https://github.com/mangosone/server/pull/23"]PR a fix[/URL] for this. Hope all go well from now.

In mangosd.conf you have a line reading MaxPingTime. Set this to a value lower than your MySQL`s wait_timeout and I bet all these problems will dissapear (the default value for MaxPingTime is 30min, which was ok for a wait_timeout of 28800).