teacher4444

That used to ahppen on wowemu I remember...and people thought it was blizzlike! :°D

Thank you for your reply. Mmm, ok, I'll look into commit section to fin info, I am still trying to adapat to Git method.

Come on guys, 42 views and noone has an answer? EDIT: My doubt is whether it is telling me that I customised such files 10 branches ago or whether thare is an issue which eventually I will pay for,

Before any user gets worried, I am a newbie with Git but I configured Git properly as explained in other guides here on Forum, I downloaded Source and compiled it fine with SD2 and now server is running as usual. I just would like to know how to EXACTLY interpret certain error messages. I have my "own" chat.cpp and other files customised with some changes I made and I have been compiling it just fine for ages (as I have compiled it fine 2 hours ago from Git repository). When I type git pull the Source is downloaded and at the end of the list I get ERROR: src\\game\\Chat.cpp not uptodate. Cannot merge. I then type git checkout -m My customised files are listed with an M on their left and at the end of the list I read Your branch is behind the track remote branch 'origin/master' by 10 commits, and can be fast-forwarded. Does this mean that my customised files are not merged with recent changes and it is just mere coincidence that this does not cause problems in compilation? I hope I gave enough info, like many others, I have to and WILL adapt to Git. OS: Win32

Because that requires that you have a 2.4.3 Client anyway (or am I mistaken?) I think our friend here would like a Server which accepts 1.12.1 Clients.

Ok, I think I got it, so please feel free to tell me I'm wrong or if I got it right. By looking at the code, NOWHERE is it defined if an account is GM or non-GM. It does not state that GMlevel>0 is a GM account and GMlevel=0 is a Beta Tester account. What the core does is specify for EVERY situation, where a privilege distinction is needed, a > or < or == ; it always states >SEC_PLAYER, or == SEC_PLAYER, or <SEC_GAMEMASTER and so on. As I quoted from code before, Common.h is where you find the hierarchy or the AccountTypes. So the code knows that SEC_PLAYER is lower than SEC_MODERATOR, which il lower than SEC_GAMEMASTER and so on. Just a hint for Devs: do you think this may cause problems in future when things get even more complicated, and maybe it is best to define 2 groups of AccountTypes, GM and non-GM, and then have sub-AccountTypes in these 2 groups? This way when implementing anything knew you don't care about the name or hierarchy of the AccountType, you just state if it matters whether it is GM or non-GM, and leave the hierarchy part for specific situations which require such precision. I hope I was able to explain my proposition. It is not a critic nor a complain, I wish I had the skills to explain it in proper technical terms or even better submit a patch myself as reference. :unsure: Just a thought.

Ok, I'll go the long way. ^^'' I started searching for keywrds like SetSecurity and AccounTypes, I'll go for those, although I have the slight feeling there will be many search matches. ^^'

Rev 6525 I have found in common.h: enum AccountTypes { SEC_PLAYER = 0, SEC_MODERATOR = 1, SEC_GAMEMASTER = 2, SEC_ADMINISTRATOR = 3 }; Maybe something related to it in CliRunnable.cpp (but only as reference): AccountTypes allowedAccountType = sWorld.GetPlayerSecurityLimit(); char const* secName = ""; switch(allowedAccountType) { case SEC_PLAYER: secName = "Player"; break; case SEC_MODERATOR: secName = "Moderator"; break; case SEC_GAMEMASTER: secName = "Gamemaster"; break; case SEC_ADMINISTRATOR: secName = "Administrator"; break; default: secName = "<unknown>"; break; } The point is: we know that if GMlevel=0 the account has no privileges, if GMlevel>0 the account has privileges, even if it has access to no commands. For example a GMlevel>0 account will always be able to receive whispers byany race and understand them (and be understandable -> universal language) even if mangosd.conf is set NOT to allow TwoSideInteraction. I am trying to find in the core where it states that if GMlevel>0 it is considered a GM Account, instead of (for example) only if GMlevel>2 and so on. If you can direct me it would be very helpful. Thank you.

Thank you for your reply and the info!

No matter how ridiculous my question may seem, I can assure you I would appreciate not having this doubt. If anyone knows if this fix is only related to ad.exe improvement or a more "precise" way of extracting maps thus better map files, I would be very interested in knowing too. Thank you.

I quote from log: "Fixed: in ad.exe allocate temporary buffer not only in compressed case. That fix unexpected crashes and possible corrupted data use in uncompressed case. ad.exe updated." Does this mean we shoud re-extract maps since the ones we extracetd before may lead topossible crashes for missing data? thank you.

Rev 6440 + SD2 558 + UDB 0.10.3 ch359 + Acid 19 Beta Testers during Instance have mobs they killed few minutes earlier respawned. If the whole raid is wiped and they re-enter the Instance (without modifying the raid) the Instance is already fully spawned. If 2 out of 5 Beta Testers die, when they get back in the Instance they are on a different InstanceID then their fellow raid members. Confirmed in Magisters' Terrace, Botanica and Arcatraz. Spawntimesecs field in creature table is set=604800. Reset_delay field in instance_template map is set=3 (I checked on the wiki and the value must be in days, not mins or secs). manogs.conf is set not to use DB values, no multiplier. I am posting it here instead of the bug tracker because I have many doubts it is my own problem, not core nor db related. Has anyone experienced such issue with this or higher Rev? Thank you.