XTZGZoReX

I don't even know what you mean by development document, but you could try generating yourself some doxygen docs in the doc/ folder.

Player counts, etc?

I suggest only show the current server global locale used.

Ah. So a localized db_version it is?

Uhm... What is a traduction...?

Use Sniffitzt. http://sharesource.org/project/sniffitzt/

The ? on custom items is a client issue. It can, however, be solved by certain UI addons.

Some client addons allow the displaying of custom model id's. I personally think we should keep the field. (Not that I have any real custom items, but eh... As said, others do.)

Won't work. Since the strings you have before you load mangos_string -- what about them?

This is just a thread where I'd like feedback before writing the patch for MaNGOS. I wrote a database logging patch for my own core, as well as Trinity, and would now like to also provide it for MaNGOS. In [7873], Vladimir did a change for me that was necessary to do this. So, kudos to him . Now, there is one downside of database logging: Colors will have to be.. 'altered'. I had issues with colors being saved to the database (which is obviously totally wrong!), and thus, I removed colors completely. I don't currently know a way to do this with colors enabled. Of course it'd work, but logs would be ugly when selecting them from the database. So, I may choose to remove colors. This is one of the main things I want feedback on. Now, that's pretty much the only 'real' problem I've had during development of this. Database logging should generally make a server much faster, because dispatching a query to MySQL usually is faster than writing to a file (after all, MySQL handles the file writing, and thus won't slow down MaNGOS). This is assuming the MySQL server is on a decent machine, with decent settings, of course. Now, just so you have something to drool over: mysql> select count(*) from realmd.logs; +----------+ | count(*) | +----------+ | 31201271 | +----------+ 1 row in set (0.00 sec) Yep, 31 million rows. This is with LogLevel 3 (debug build), on a server with 30~ players, latency is around 40ms. With file logging completely disabled, of course. How the logs table structure will look: CREATE TABLE `logs` ( `time` int(14) NOT NULL, -- time of this log call `realm` int(4) NOT NULL, -- 0 if realmd `type` int(4) NOT NULL, -- will be defined in Log.h `string` text -- actual string ) ENGINE=MyISAM DEFAULT CHARSET=latin1; So, any feedback on all this is appreciated.

Whoever "wrote" that patch practically took it all from megamage's work at Trinity. Also, what's with the [Help] tag? This is a patch submission section...

diff --git a/src/game/World.cpp b/src/game/World.cpp index 86cc58b..da87668 100644 --- a/src/game/World.cpp +++ b/src/game/World.cpp @@ -973,7 +973,7 @@ void World::LoadConfigSettings(bool reload) sLog.outError("Visibility.Distance.Player can't be greater %f",MAX_VISIBILITY_DISTANCE - m_VisibleUnitGreyDistance); m_MaxVisibleDistanceForPlayer = MAX_VISIBILITY_DISTANCE - m_VisibleUnitGreyDistance; } - m_MaxVisibleDistanceForObject = sConfig.GetFloatDefault("Visibility.Distance.Gameobject", DEFAULT_VISIBILITY_DISTANCE); + m_MaxVisibleDistanceForObject = sConfig.GetFloatDefault("Visibility.Distance.Object", DEFAULT_VISIBILITY_DISTANCE); if(m_MaxVisibleDistanceForObject < INTERACTION_DISTANCE) { sLog.outError("Visibility.Distance.Object can't be less max aggro radius %f",float(INTERACTION_DISTANCE)); This fixes loading of the config variable.

Also, some parts of worldd actually still use the dep/sockets library.

Mind you, those parts are _completely_ untested. I don't even know if it works in practice. Raczman's patch is much more safe as-is, because map/BG/OPvP (TC only) updates are tested and confirmed working (mostly). Racz does that as well (and wrote it). Actually, rephrase: Raczman wrote BG/map/OPvP parallelization. I just added some #pragma omp task's to a few other components. So, full credits to him. As for my changes: Instance save parallelization seems a bit obsolete to me, after going over the code recently. Instace saves are relatively fast, and not called very often. As for parallelized game events, that would definitely increase performance. When a game event activates/de-activates, a lot of things are changed in the world. And auctions, I'm fairly sure you'd get nice performance by parallelizing it, but it's far from ready for that. It needs several #pragma omp critical sections to work correctly. Parallelized auctions should especially help for those using AHBot.

And how much memory would the browser end up eating? 400 MB? 500 MB? No way..