VladimirMangos

I agree. This will not help. Just triggering spam and useless bug reports.You can _now_ read that mangos support 3.0.2 just in result posting sandbox patch long time ago.

Dependent from option maybe good do logout/login at least. Environment varibales like as paths applied only at re-login.

Rate.Auction.Deposit = 0

I think discussion go to offtopic. If this will go in current way, i will just close it.

This is fixed in sql update where related striong now.

This is not true. Also mangos team member not only apply suggested patches but write own. And last is primary team work in fact in different suggested patch apply. Just onw more remark. This patch change too deep mangos internals for custom feature. And it support if it will added will additional lost time for devs.

But this resolve revs numbering in limited form. Yes, svn mirror will have revs, yes if ppl remember they can report base at this revs numbers. But we still can't used this revision for in game version output...

Thank you for allowing this :rolleyes:1) Who say that team not work at this? :confused: Strange if you not see TOM_RUS patch for basic support some early beta of client addon 2) Who say that this most priority that all other changes fixes :confused: This is just one from way improving mangos work not more not less. You know: it will ready when ready

Ah, thank you for pointing. I currently merge console/CLI commands processing, but i will include your changes in this lines as part of prepering patch.

Is devs goal make happy click-users? I think no. MaNGOS is learning project, not only users learning, but mostly _devs_ learning. git is new tool for us also and we learning now how use it in full power. This is not main reason for switch to git but unknown tool this isn't reason not do like switch if expected better code managment Ofc, someone can create like tool and provide it to community. And this will be intresting project for he, but not think that any from devs plan do like tool. Also note: patch's conflict resolving can't be automated for all cases. It's required human brains and programming expierience for acceptable result.

commit != push, you can made many commits in local repo before do its push to remote repo. And in push result your last commit can be _not_ last commit in merged after push remote repo commite list.

I read this at each client update. Only note: this dead way. Just lost time for devs implement "pefect" something for old client version and _redo_ this (in some cases totally) after client switch.

hmm, strange, i can apply only after described changes. Anyway it can be fixed this or other way then

mangosd have often chnaged large code and possible very hard find source of freeze. And then freeze system for world thread in mangosd is good way avoid freezes. realmd and recent added network threads in mangosd is more specialized things this limited amount places where infinity loop possible and then better attempt fix problems before planning add antifreeze system to its. This is lot easy in compare with mangosd world thread case. Ofc, this still be hard

About old patches. You can make small chnages and let use its with git. For example you have in patch for file: You need chnage it in way: a/ b/ - need just add src/game/ - git understand only full file path from project sources root, so you must be sure that file name include it. Do it for all files in patch and this can help in apply old patch. Ofc, possible also changes conflicts, etc. but this another story

as read recently at another forum: git checkout -f

You not need do "git clone git://github.com/mangos/mangos.git" after git init. In general you or do clone or do init+add+pull clone will create subdirectory mangos with source init+add+pull will save sources in current directory. will do all required for get sources. Just from own expirience when setup git for mangos

No, gift system wotk only single to single item replace at open. And i think better not change this. Gift not considered at "container" but as changed items itself. Maybe more correct way convert item to special bag (without possibility add items in it) and save as bag, and delete at empty. But this will required changes in bag system work. Currently bag expected to equipped in bag slot when open... We need preserve current anti-cheat checks for normal bags and allow work like loot-bags in same time...

But devs anyway will can't use this svn revs in sql update names

count? [10 symbols]

In correct way patch author must create mangos fork (branch in svn naming) at github.com , add patch and do "request pull" to mangos master. After author can pull from mangos master to own fork chnages and update patch for compatibility from time to time. Good side is: 1) author not required search online storage for patch 2) always can update patch 3) other ppl can use author patch in salf sources just pull from his fork... Bad side: author must get some expirience with git system work and github.com work.

We not care about like patches. Offically mangos not support 3.x.y. And this forum not for discussion unsupported version. Closed.

in game mangos version (svn_revison.h generation) will be fixed in some way but later...

in new client it moved to Data/<locale>. But new client not supported anyway.

I agree with many problems from absent revs in git. Devs attempt resolve this in some way. Yes, for sql updates planned use date instead revs. In form: 2008_10_17_01_mangos.sql