Wyk3d

You can rant all you want.. the first page of that thread wasn't updated but the last page of that thread contains freghar's post that he made a mirror and then Theluda didn't bother to make a mirror for sourceforge as well. The fact is, the information was there, you didn't read it, and you made stupid accusations. I could have closed your post without giving any information but instead I gave you what you wanted, the link to the svn mirror. As a matter of fact the official git gui and gitk are already quite easy to use though they don't cover everything that git can do. More guis are coming, for example the development for TortoiseGIT started recently. Even on windows, using the git command line is not so hard, you just have to learn it. There is an entire section of the forum devoted to teaching you how to use it so you don't have any excuse. Due to your rude behavior you've earned yourself another closed thread.

So much for actually reading the announcements http://svn2.assembla.com/svn/mangos-svn-mirror .. But Morgan is right, it's best if you learn git ..

The fields usually only store the lower part of the GUID as well.

Are you sure you were not looking at the lower 32 bits of the GUID instead of the full ? A full creature GUID cannot be 11 because its highguid is 0xF130 so the smallest value is 265188460724224. In debug output only the low part of the guid is shown usually so you can have a creature and a player with the same, that's not a problem.

You can reset your local branch to a specific version (discarding all other changes) with git reset. For example if your current branch was set to origin/master before you applied the patch, you would use:git reset --hard origin/master

If you look closely DELETE+INSERT is always put in a transaction. If the server crashes after delete but before insert, the delete is automatically rolled back and there is no data loss (that is assuming your table is not crashed and you haven't change your tables to MyISAM which doesn't support transactions). That said if you still have errors on the inserts that means something is wrong with the core, and just using REPLACE INTO (slower) to hide the errors instead of fixing the real problem would be a hack.

And now you have them back We've considered this long before dates but without something in commit messages it would have been too hard to search for a specific revision and with them it would have been too hard to maintain them manually. These problems have been solved now with git_id which is a tool we use to automatically find the next revision number and make the changes to the commit message and revision file when doing a push. We will probably go back to the old method of revision numbers instead of dates for sql updates too, but only after our tools are able to do this automatically.

Last time I checked there aren't any about gdb. We desperately need one in the linux crash dump thread so if anyone can write one please do.

Soving conflicts is about as easy as with TortoiseSVN if you have KDiff3 installed as a mergetool. So far I haven't seen any merges that were solved better by SVN so I have to say that the algorithms itself is at least as good as good as SVN .. maybe better.

The latest information about the fields is always in http://github.com/mangos/mangos/tree/master/src/game/UpdateFields.h

I don't know where the limits are but I do know that we are far from reaching it since I can list a lot of things that can be done better. So for me the question is not IF we need multiprocessing but WHEN. The answer I can give at this moment is .. NOT YET.

Yes this is why I'm currently opting for multithreading actually. There is no way in hell the memory usage should be this high even with hundreds of players online if you have gridunloading on. There must be some memory leaks somewhere or I don't know. The fact that gridunload makes crashes and lags just means the core is not well optimized. If we just throw more hardware at them then these problems will be neglected and we will go more and more towards and end where the core is a horribly slow / crashy memory hog that you can only cope with by having a cluster of 10 computers working at it. So don't think that clustering is the only solution to the problem .. in fact it's one of the worst solutions .. the lazy man's solution. We should be a learning project that delivers a quality product instead of a corporate hog where you don't care if you write horrible code as long as you write it quickly and you just have the hardware department give you enough muscle to chug that pig along.

No, you need to fix the problems with grid unloading and then you won't need that much memory.

Another way you can do the same: - "git stash" removes all your uncommitted changes and saves them for later - update to new sources - "git stash apply" restores all your uncommitted changes

That hasn't changed .. we ask people to give us the datetime + sha. This pair has the same property as revision numbers in that:- it completely identifies a commit (there is a one in a million chance that you get two commits at the same time, but hash solves that) - you can remember datetimes for at least a short time .. it's harder than revision numbers but doable, it's not random at least - you can compare two datetimes to give you an idea of whether they have a certain change in the workin g copy .. there are some differences though in that when you see two rev numbers you don't know if they were a week apart or a day apart depending on how active the period is, and with dates you don't know if you had 10 commits or one commit in a day .. so it's a tradeoff - you can update to a commit at a certain datetime .. you just need to do this in two steps, one to retrieve the sha corresponding to a datetime and one to copy paste that into something that switches to that commit .. .. note that with visual tools finding the datetime is like a dictionary search, and humans can do that pretty well so with gitk+git gui you can do it fast - you can move "backwards and forwards" with git too .. we try to get rid of the unnecessary branches with rebase so the situation will be clear when you see something like "merged branch for different client version or merge branch for some big feature" .. all you need is to open gitk, find the commit you want and copy paste - the datetime + sha is displayed in the client and we even found a way for users to be able to copypaste it from there when providing bug reports Overall we can do everything we could do before, just a bit less conveniently, in most cases you can get used to it.

Whenever I say that I don't want something to be rewritten I mean that yes it could use a lot of refactoring, but it does not need to be rewritten from scratch. If you don't change what the code does, only how it does that, you shouldn't rewrite but refactor. I did say that some things are doing fine but also that many other things aren't .. so you shouldn't generalize. The point is that with clustering you need a lot of message passing in places that can be much better optimized with multithreading.

Also note that in general scalability is not our biggest problem currently. There are a lot of things that if left uncorrected will bog down clustered servers too. So I think the time has not come yet to choose how we want to scale .. the time has come to start fixing those fundamental problems, and after the core is so fast that nobody will even need scaling .. then think about scaling .. oh wait.

Bottom line: if you don't plan on getting more machines .. clustering = BAD. With clustering on the same hardware you will be able to host much less clients and if you had lag until now will have even more lag with clustering unless you get additional machines. We are in the age of the multithreading .. cpus with more and more cores are coming out and software tools are making advances in supporting them .. A lot of the core needs to be cleaned up anyway, so having to rewrite stuff is actually a good thing. With proper multithreading on new hardware noone would be complaining about lags.

Yes we do use indexing everywhere .. we're actually a lot smarter than you think. If you don't know what you're talking about then how can you be sure ? All of the profilers I mentioned give ample information on method timing , even the time spent on each line in the method ! Some can even tell you exactly how much a method took when it was called by a specific function .. not just average execution times.

We already have full support for async db access (both queries and updates), just not used in all places..

New forum address: http://udbforums.kicks-ass.net/

On windows there is git gui and gitk that does all of that .. though you need an earth shattering 15 clicks to update, not just 3 like tortoisesvn . We will fix SQL updates in a different way.. it will be much easier to work with them than ever before .

Don't believe a word of that announcement .. it did not come from the UDB team.

Because of people who don't know what they're talking about and are just confusing people who would like to know something but don't know who to believe I'm closing this thread .. most of the above are just rants and totally useless for anyone who wants to know the facts anyway.

Don't worry, you are a much better version of yourself now .