VladimirMangos

Lol, next will be 8...

possible do same thing as for string ids if this really need: signed ids with reserve some for core, other for DB.

That is very strange, the accounts not working is probably not created properly.

maybe, but those accounts can be logged perfectly by game...

Client apply upper case to login/password before send. Mangos apply upper case at accound creating by internal command and expect that in DB you store hascode created from _upper_ version login/password if it calculated by external tools

possible missing some code in backports. As i remember this fixed in past in mangos master version.

I not see how this possible because different needs in conditions list for different DB projects and not calling conditions from core code directly (by ids).

Just check its by self. In past like topics start flame war only. So closed.

If mutex need only for original LootItem structure then you can overwrite operator= or LootItem(LootItem const&) to proper way avoid copy mutet (create new in new struct copy. Also i not look but possible LootItems stored as value in storage container and then copy constructor can called when container grow/etc.

But posible most correct answer: you add mutex to wrong type when it not expected and wrong placed for any uses.

You add mutex field to copyable object. In other cases related objects not copy. In result compiler attempt find operator= or ACE_RW_Mutex(ACE_RW_Mutex const&) but both private because mutex copy is strange idea

Does this mean Schmoo or Nighoo wrote the code? And how does this workflow really work? I just wanna know how the workflow really works.

If commiter set author for commit then he meaning that author write/prepare all/most added in commit code.

Sometime in result applied by commiet cleanup/improve codesyle or another reasons commit code can be different from original patch ofc.

In case backporting to another mangos repos commit cherry-picked from main mangos repo direcly by use cherry-pick command or by using special script

created in past for simplify like backports. Ofc, commiter often do some locla chnages after cherrypick for make backported commit compatible with related clietn version

Compress condition table by remove duplicates can be contra-productive infact. This make very hard fix condition because will be unclear is it shared or not with other condition as part its. At condition loading it registered and lookup by condition data so it auto merge with same data to single record.

commiter can provide author data when commit added to repo. In command line case this something like:

git commit --author="lillecarl <[email protected]>"

Then i will be commiter and you will be author of created commit.

In general change make sense for me. If target mode same for 2 effects and for example expected random target selection then expected as i think same targets for both effects. Avoid relookup targets also will provide some speedup for related code part. Good catch.

It's meaning: if client binary allow use this world ids for zone then it will show. If client bionary not allow then you will can't do anything with it.

if world id listed for zone in binary you can do, if not listed then you can't do...

Look in http://github.com/mangos/mangos/blob/master/src/mangosd/Main.cpp#L61

lnstall as services not work? Look in mangosd/realmd command line options.

Sorry, thread has been deleted by me by error. Original content:

I know MANGOS is setup as a single server but is that the way WOW also works? Basically, when one travels to another land does one stay on the same server/port? In looking through my captures for Lego Universe, I noticed that when I traveled from one world to another, the server IP and port changed. Lego Universe always had a loading screen when traveling to another world. I do not recall if WOW had a visible loading screen when traveling to another land. It has been many, many years since I played WOW. Thanks, Patrick

World state ids for zones hardcoded into client binary. As i know its not listed in dbc and etc.

Stay in world some time at unexpected disconnect not implemented in mangos.

In mangos lost connection triggered logout.

> login player in world > disconnect server from internet for 10 seconds then reconnect

In case unexpected disconnect client _not_ send anything, just connection closed.

In case client timeout client _explictly_ send logout request in same way as it send in case player normal logout.

This is totally different from lost connection.

In dbc stored graveyards coordinates, in table as i remember stored faction data.

Instead factions i suggest compare teams: Player::getTeam()

maybe stick it?

In any case at FreeBSD strongly recommended use gmake.

ACE versions sometime change API and have build problems at some platforms. Maybe errors outputs can provide some more info?

It can be unavoidable. From server side no difference in packets for both ways as i understand, so no way do different checks for its.