Derex

I think there are a lot of bug reports where the server is slow and it crashes with file size limit exceded error. Check your config for this option: WorldLogFile and disable it. Its enabled by default.

The problem is that there is no body to develop it I dont have that much free time.

hope you didnt write this in /boot/grub/menu.lst It needs to be vdso=0 not vsdo

Maybe your world.log file growed more than ulimit -f You also use kernel with bugged vdso, either disable vdso or use newer kernel. this is the message that gdb outputs: Failed to read a valid object file image from memory.

Feel free to find me in irc. And coding it on unix will be much easier than windows. So its good to use unix.

Yea, the problem existed, thats why sd2 need to use patch of the build system in order to compile fine.

Help is not the correct word.

I dont say you break something, but just that it wotn work on linux as expected. Reccomend you to read libtool manual. $ readelf -d ./mangos-worldd Dynamic section at offset 0x827488 contains 37 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libmysqlclient_r.so.15] 0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libnsl.so.1] 0x0000000000000001 (NEEDED) Shared library: [libz.so.1] 0x0000000000000001 (NEEDED) Shared library: [libssl.so.0.9.8] 0x0000000000000001 (NEEDED) Shared library: [libACE-5.6.6.so] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libmangosscript.so.0] 0x0000000000000001 (NEEDED) Shared library: [libZThread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.0.9.8] 0x000000000000000f (RPATH) Library rpath: [/opt/dev/lib] 0x000000000000000c (INIT) 0x6ef0b8 0x000000000000000d (FINI) 0xa8cb64 0x0000000000000004 (HASH) 0x400240 0x000000006ffffef5 (GNU_HASH) 0x42bf50 0x0000000000000005 (STRTAB) 0x5061e0 0x0000000000000006 (SYMTAB) 0x45f650 0x000000000000000a (STRSZ) 1934703 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0xe27738 0x0000000000000002 (PLTRELSZ) 10200 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x6ec8e0 0x0000000000000007 (RELA) 0x6ec6d0 0x0000000000000008 (RELASZ) 528 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x6ec5a0 0x000000006fffffff (VERNEEDNUM) 8 0x000000006ffffff0 (VERSYM) 0x6de750 0x0000000000000000 (NULL) 0x0

I started this thread, because I wanted to put some discussion here, and eventually see somebody who is smart enough to join the "game". Note that smart is different than educated for me, even if somebody is educated and knows about multithreading, networking or whatever, if he is not smart enough to use the knowlege he has ... he is nobody. So I prefer smart person with small or no expiriance in this area of coding, than some dude who has a bunch of computer books in his head and doesnt know what to do when it comes to doing real thing. Ofc knowing C++ is requirement . For me its not that of a big deal what I will code ... I may even not code anything, I dont want to start cowboy coding for such big thing. Its all about fun after all

Sad, from all talking here, I realy dont see a person who has enough knowlege to join and develop the multi-project with me. Doing it alone in the jungle is kinda wierd and If at some point of time I dissapear there will be nobody to maintain the code, or have any idea of what it does and how it does it. Cypherjb seems smart, but he probably has another work. Balrock, if multithreading gets inplemented, you can just forget about multiprocessing, I dont say it wont be possible to do multiprocessing from multithreaded version ( because everything is possible ). BUT doing it will require rewrite of the already written thing, ITS IMPOSSIBLE to reuse the multithreaded code and make multiprocess. ( just forget that any dev will write a bunch of code and then just delete it and write another bunch of code ).

Yes, so need several porcesses in order to alow 32bit OS to handle more than 200 online. And I realy dont want to think how much new memory will be needed when mmaps are developed ... I have seen a lot of crashes of by trying to address more than 3GB. Most linuxes are x64 now, so its not that big problem on the linux front.

There is no way an app to address more than 4GB on 32bit platform. A pointer is 32 bits, 2^32 = 4GB

A* on the fly ... which means very slow and a lot of memory usage. But inplementing accurate navmesh for all this surface maybe very complicated and may be not that accurate.

ACE has inplementation of CORBA thats called TAO, which runs on all platforms on which ACE runs. http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/TAO-INSTALL.html

The red dots are the mmaps dots. The white lines that form the surface are made by navmeshgenerator. The blue is vmaps. PS: The forum alows 4 images per post. [EDIT] Looks like somebody hacked imageshack, I wont remove the pics in case they recover from backup or something.

Hi, This is the current work on the mmaps project, which aimed to add pathfinding to mangos. If somebody wants to code it. Me and Neo2003 took the code and fixed the all the bugs we found, ported it to autotools build. Made it perfectly generate all surfaces around the "world". http://filebeam.com/a9d136a33168f6c1621535cc96beb993 What needs to be done is: * There is missing a reliable way of finding out what are the points around a certain point. * The actual logic of which paths will be finded is missing. If somebody is interested in continuing the project I pls contact me for better explanation of the sources. Screens (by Neo2003)

Eclipse, Netbeans, Emacs ( I think you wont go for this if you switched from windows ). KDevelop, Anjuta, SlickEdit (not free). I personally prefer Eclipse atm ( but I sometimes switch IDE`s ). There are a lot of plugins for it.

About why clustering will be the same when running on single machine: CORBA SHMIOP alows using shared memory for IPC for processes on the same machine. CORBA Colocation alows calling servants directly, if they are in the same process. I dont go for multiprocessing, but I put it as strong alternative. Implementing full multithreading will result in the same server layout as with implementing multiprocessing: * Some threads/processes that handle player connections. * Some threads/processes that handle each map ( Its possible one thread to handle several maps ... this is not inportant for now ). * ONE thread/process that handles inter-map things ... chat, guilds, friends etc.

As far as I remember you were the one saying there is no need to rewrite the old code, and that it was running fine and so on. About performance of cluster when running on single machine: It will be the same when using multiprocessing and when using multithreading. Even the multithreading can be much slower if its not syncronized correctly.

Yea, it was my personal research + Sinnerg

Hi, This thread is the beginning/planning of project called multimangos. The goal of this project will be adding multithreading/multiprocessing in mangos, having much more clients connected to the server with less latency. First thing that needs to be decided is wheater to go for multithreading or multiprocessing. Pros/Cons with simple words: Multithreading ( this means mtmaps for Players/WorldSessions also ) Advantages: * Easy to use for noob admins ( I think if admin is noob better not make the server at all ). * Won't require adding aditional IPC libraries/frameworks to mangos source. Disadvantages: * It wont be possible to make multiprocessing version out from the multithreaded version. ( who thinks its possible - go to hell ). * Will require hudge rewrite of mangos, starting from vmaps, database support, half of the files in src/game directory and much more. A lot of bottlenecks/overhead may appear from the mutlithreading. * It will be extremely easy for developer who dont know how to do multithreading to add threading-bugs to the core. Multiprocessing ( this means develop cluster ) Advantages: * If its ready it will be much more stable ( less crashes ). It will include fault tolerance and fault detection services, this will alow when one node crashes to not shut down the whole server. * Can be used like the multithreaded version with the same performance ( maybe a bit bigger memory usage ). * Implementing things like cross-realm battlegrounds and voicechat will come somehow nautral and easy. Disadvantages: * A bit harder to use for admins, will require starting 2-3 aditional services in the simplest case. * Requires some knowlege for IPC technologies for implementation. Currently the only technology I see for C++ is CORBA, and CORBA is not that simple. Both will require the same amount of time to develop. I think the second will be easyer to debug and test.

And less "testers" online.

if you have installed ACE with prefix /usr/local maybe add /usr/local/lib in /etc/ld.so.conf

I think it should work without thsese lines too.

Define.h #ifdef WIN32 #ifdef MANGOS_WIN32_DLL_IMPORT #define MANGOS_DLL_DECL __declspec(dllimport) #else #ifdef MANGOS_WIND_DLL_EXPORT #define MANGOS_DLL_DECL __declspec(dllexport) #else #define MANGOS_DLL_DECL #endif #endif #else #define MANGOS_DLL_DECL #endif #if PLATFORM == PLATFORM_WINDOWS # define MANGOS_DLL_SPEC __declspec(dllexport) # ifndef DECLSPEC_NORETURN # define DECLSPEC_NORETURN __declspec(noreturn) # endif #else # define MANGOS_DLL_SPEC # define DECLSPEC_NORETURN #endif According to this code MANGOS_DLL_DECL seems the correct thing to be used ,however all windows project files need to define MANGOS_WIND_DLL_EXPORT . And all scripting module build files need to define MANGOS_WIN32_DLL_IMPORT . At quick look I couldn`t find any project file where these things are defined . Are they deprecated or what ? MANGOS_DLL_SPEC goes to just one __declspec(dllexport) on windows.