antz

ok, my impression was that some signatures had offsets unique to each version of the client - in which case having a client version associated with those checks in the db seems the logical place to have them. That way the implementation would remain the same with just the db entries changing

Since the server knows the version of the connected client, one possible solution is to extend the db table to include the target client version. Then when it performs it's checks, it can skip the ones not for the current client.

I would appreciate everyone trying the Develop21 branch of Zero and report back on any Warden issues found

Thank you for your offer of help

the database changes in Rel20 should have resolved this

This should now be resolved with the recent db updates

Is this still a issue after the recent changes ?

Is anyone aware of any issues that are preventing Rel20 from being released ?

a fix for this is currently being developed

@chucksta - Could you create a pr for that ?

I would say yes

merged in :D

I performed a fresh load of the db last night, the wolves in northshire abbey are hitting for at least 15, so it seems ok. We need specifics here, as discussed on the forum, most people are not having issues. If you can break this down a little to find out what is wrong with your db. Select an mob, the type .npcinfo and give us some id's to check. I will now close all the open forum posts and refer them to this tracker task.

We spotted an error in the SQL which affects Linux builds, please try again

I have PlayerBot-AI on my hit list of new features for Rel21

This is now fixed in the Rel20 DB [url]https://github.com/mangosone/database/commit/38518b5d0ca74661d50a7e02fe296479630c60f1[/url]

This is now in the latest Rel20 DB

Closed in commit: [url]https://github.com/mangos/realmd/commit/15df5d42ae03cabe9cebfbd7534df8af4f739ecb[/url]

That commit must have never been ported to the other cores and needs to be found !!

I have also made a 'hotfix' update to the DBDocs to reflect this information and published to the Wiki, to hopefully prevent anyone else from making the same mistake.

I'm sure of the reason behind why this should take that much longer in debug. In the Build process there is a definition _DEBUG which indicates that it's a debug build The issue with trying to do something with movemaps extractor itself is that it is called multiple times by the build scripts - so it cannot keep track of its overall status beyond the current run Olion has mentioned about setting and using the errorcode to flag the error during the run - This combined with a -DEBUGOVERRIDE flag, might do the trick As I see it, the logic flow would be this.. Are we in Debug Mode ? No... Carry on as normal Yes.... Do we have -DEBUGOVERRIDE set ? Yes... Carry on as normal No.... Do we have an Errorcode >0 No... Generate the Debug warning message and then set Errorcode to be greater then 0 and and Exit Yes.... Exit Thoughts ?

We were attempting to fix a majority of the broken mobs in Zero (especially casters) I reviewed the changes and agreed they looked good to go. In light of you highlighting the potential issue with the change, we are reviewing it to see whether a) We need to revert it and reapplying with extra restrictions b) Apply a correction to the small number of mobs affected by the global change Anything you can add to this would be appreciated

This has been fixed by commit [url]https://github.com/mangosone/server/commit/fea55512f09d25f6a759da630a85ac45eb419b97[/url] Can you please confirm ?

This may have been fixed by commit [url]https://github.com/mangosone/server/commit/fea55512f09d25f6a759da630a85ac45eb419b97[/url] Can you please confirm ?

I have also activated "living world" on my server and will leave it running for a day to collect any world issues.