teacher4444
-
Posts
12 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by teacher4444
-
-
You need to commit your changes
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.
Hardcore Server
in OldC / C++
Posted
That used to ahppen on wowemu I remember...and people thought it was blizzlike! :°D