faramir118

Same problem was happening on a few batch files, like the ones in contrib/vmap_extract_assembler_bin, but I may have overwritten and committed them at some point.

Ok, good. If I load map 43 (no tiles) with VMapManager2::loadMap(43, "vmaps", 64, 64), do I have to call VMapManager2::unloadMap(43, 64, 64) before VMapManager::unloadMap(43)?

you are my hero

I've been using notepad++ for years, and I've gotten in the habit of working with formatting characters on. I see that after a fresh fetch, merge, and checkout on a brand new branch, CRLF characters are there git diff says that every line of each of those files has changed git diff --ignore-space-at-eol says there are no changes I can do Edit > EOL Conversion > Unix Format, and they all change to LF, and then I save git diff still says that every line of each of those files has changed git diff --ignore-space-at-eol still says there are no changes Ugh. I think I'll just save my code outside the repo somewhere, delete the repo, and start from scratch. Now, should I use CRLF or just LF? I can set my editors to do either, just need to know.

Lynx, can you tell me how to load model info with IVMapManager where the map has no tiles? Need to know for mmaps project Or did I just stumble onto the fact that we're not handling maps correctly when their model info is in the WDT (not ADT files)?

This has been an intermittent problem for me, and it's starting to get on my nerves. Can anyone tell me what I'm doing wrong? faramir118@lappy /c/wowemu/mangos-src (main) $ git checkout vmap_rewrite error: You have local changes to 'contrib/vmap_extractor_v2/doc/The MoPaQ File Format.txt'; cannot switch branches. faramir118@lappy /c/wowemu/mangos-src (main) $ git status # On branch main # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: contrib/vmap_extractor_v2/doc/The MoPaQ File Format.txt # modified: contrib/vmap_extractor_v2/stormdll/StormDll.def # modified: contrib/vmap_extractor_v2/stormlib/bzip2/dlltest.dsp # modified: contrib/vmap_extractor_v2/stormlib/bzip2/libbz2.def # modified: contrib/vmap_extractor_v2/stormlib/bzip2/libbz2.dsp # modified: contrib/vmap_extractor_v2/stormlib/bzip2/makefile.msc # no changes added to commit (use "git add" and/or "git commit -a") faramir118@lappy /c/wowemu/mangos-src (main) $ git reset --hard HEAD is now at 5ef2e49 [9986] Talent 51459 and ranks affect only melee auto-attacks. faramir118@lappy /c/wowemu/mangos-src (main) $ git status # On branch main # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: contrib/vmap_extractor_v2/doc/The MoPaQ File Format.txt # modified: contrib/vmap_extractor_v2/stormdll/StormDll.def # modified: contrib/vmap_extractor_v2/stormlib/bzip2/dlltest.dsp # modified: contrib/vmap_extractor_v2/stormlib/bzip2/libbz2.def # modified: contrib/vmap_extractor_v2/stormlib/bzip2/libbz2.dsp # modified: contrib/vmap_extractor_v2/stormlib/bzip2/makefile.msc # no changes added to commit (use "git add" and/or "git commit -a") faramir118@lappy /c/wowemu/mangos-src (main) $ git diff --ignore-space-at-eol faramir118@lappy /c/wowemu/mangos-src (main) $ I have tried autocrlf false, autocrlf true, and autcrlf input. I have tried converting the line endings from CRLF (what they are in the working directory) to LF (which I assume they are in the index), but I get the same output from git status and git diff. The only thing that works is to commit the 'changes'

mmaps are static at the moment. Some instances require dynamic mmaps though (like the bridge in gun'drak, or the floor in the coliseum). There are five ways to make it work, but I haven't decided which is better. * Generate two versions of these maps, one without the GO and one with the GO This is kind of a hacky way to do it. * Generate a map with all GOs spawned, but flag the GO polys in a special way. I haven't even begun to look at how to flag specific polys, but I like this way best so far. * Define off-mesh connections. There is no way to automate this. * Rebuild the navmesh tiles at runtime. Navmesh generation is extremely time consuming. However, time is dependant on tile size. If the tiles are small, and the GO doesn't span across a lot of tiles, it might be do-able as long as rebuilding didn't happen that often. * Disable mmaps on the maps that have dynamic GOs as walkable surfaces. Yes, it defeats the purpose. But it's the easy thing to do. And if a GO exists in only one phase, it will either affect all of them or none of them. But, I'm having enough 'fun' getting the generator finished. Don't want to think too much about this at the moment. FYI, just want to do a bit of housekeeping on my local repo, then I'll push new generator. Next step is making core load/unload tiles into navmesh at the same time it loads/unloads grids.

I always recommend to start with Java or C#/Mono. From a learning perspective, they are a subset of C/C++. You can learn about pointers, references, memory management, templates, etc after you know how to make basic programs work.

127.0.0.1 is the local loopback device, so your realmlist is telling him to connect to himself. Set use ipconfig (windows) or ifconfig (*nix) to find out the ip address of your server's LAN adapter, and use that in the database.

Nice, that's a clean way to do it!

http://github.com/faramir118/mangos/commit/b68fbeb5707e7640fce5f54e861e2e46730fd071 This branch makes horde/alliance friendly when in groups. You should look at the Object.cpp changes, I think they'll help.

That article you linked was wrong about *nix systems. There are several APIs that accommodate asynchronous IO, and ACE uses them for the Proactor. I found an interesting paper that does a bit of benchmarking and scalability testing using different IO mechanisms on linux, you can read it here. I also looked at the code for lighttpd - it uses asynchronous IO, and only falls back on poll()/select() if the OS doesn't support the more efficient mechanisms.

The core should compile just like normal. However, you can only compile the generator on windows. I need help from a linux coder to redo the makefile.

Perhaps he assumes that you want a non-blocking call, and is saying that select() will block for as long as it takes to iterate over the entire set of sockets... Using the OS-provided select() is much, much more efficient than blocking on a read() call in a bunch of spawned threads. He should have at least said that. And according to the article you linked, Unix doesn't support the 'better' ways (asynchronous sockets, overlapped IO) - I don't know if that's true, so I assume that is why we block on select(). I'll dig through the code a little more to find out the specifics. Who knows, maybe there's room for improvement in the current system? edit: perhaps it would be prudent to look at other open-source projects that are scalable servers, and see how their network IO is handled.

Not true! In fact, this is a terrible way to write network IO handling for a server. The extra threads will slow down your program with context changes and consume resources needlessly. Most importantly, it can create excess latency. A particular client's network IO thread may be stuck in a sleep state for several hundred miliseconds, because the OS controls how long a time slice is and the order of thread execution. Instead, you should use synchronous event demultiplexing. This is provided by the select function. (see Windows or Unix documentation) In short, select asks the OS to block until any of the sockets are ready to read, write, or are in an exception state, or until a certain amount of time has passed (timeout). When select returns, the read socket list will contain only sockets that have data ready to be read. You can read from them, process the data, and then call select again. If any of the sockets have data before select is called, select returns immediately. There are two design patterns for synchronous event demultiplexing: Reactor - data is queued, then processed synchronously. Proactor - data is processed asynchronously. MaNGOS uses the Reactor pattern. More specificially, MaNGOS uses the ACE Reactor, which can receive events from multiple sources (network, console, etc). Even more specifically, MaNGOS uses the ACE TP_Reactor, which can dispatch events to multiple threads. However, each time an event is dispatched, the Reactor is suspended - this is creates the same behavior as synchronous execution, so there's no need for thread-safety mechanisms. IMHO, using extra threads in this fashion is wasteful because of context switches.

I have some changes to make before I upload the code. * No VC90 or linux build yet, so... Once again requesting a linux guru's help! * Many maps have models above or below the terrain. I believe I have the answer to it * Not actually building navmesh yet... just obj file for RecastDemo And a more general todo: * implement liquids (heightmap, maybe vmap) * implement low-res heightmap Pictures here: http://img195.imageshack.us/gal.php?g=bgav1.png bgav2.png is the important one - shows that tiled navmesh works!

Ok, time for an update. I made a new branch from vmap_rewrite, and have rewritten the generator. Being rushed out the door for a family affair, but will put things online later.

Sorry for the mess with my repo, I've been trying to do rebases as I go so the vmap_rewrite changes remain on top. Hasn't worked out very well. I started with VC90, then switched to VC100 when it was made available to me (offtopic - C# 4.0 has some nice new features) The only thing new in my repo is a VC100 project that builds AD, libmpq, extractor, and assembler all at once, along with updated batch files for windows. Anyway, go ahead and remove my repo's address from the front page. Lynx's should be cross-platform.

I had always assumed that other devices used the same address space, and Win32 just addressed RAM last, such as graphic adapter memory taking up a considerable chunk of address space. Never would have guessed it was intentionally crippled like this. Do you have any recommended reading on the subject?

The mmap generator uses the old vmap code, so that won't work. But if you extract the vmaps the old way and use them to generate mmaps, mangos should run just fine It was the latter. Which begs the question why the assembler tried to convert liquid data when there was none

@vladex Merge conflict. Open Map.h and remove bool IsInWater(float x, float y, float z) const; You should only have bool IsInWater(float x, float y, float z, LiquidData *data = 0) const;

Getting vmap_assembler crash, tries to allocate 22GB for float array >vmap_assembler.exe!operator new[](unsigned int count=2979583320) Line 6 + 0x9 bytes C++ >vmap_assembler.exe!VMAP::WmoLiquid::WmoLiquid(unsigned int width=3253294421, unsigned int height=1069240320, const G3D::Vector3 & corner={...}, unsigned int type=21845) Line 107 + 0x25 bytes C++ >vmap_assembler.exe!VMAP::TileAssembler::readRawFile2(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & pModelFilename="Abbeygate01.wmo", VMAP::ModelPosition & pModelPosition={...}) Line 464 + 0x68 bytes C++ >vmap_assembler.exe!VMAP::TileAssembler::convertWorld2() Line 184 + 0x1b bytes C++ >vmap_assembler.exe!main(int argc=3, char * * argv=0x00574580) Line 110 + 0x8 bytes C++ Maybe writing uninitialized values for WMOLiquidHeader members in extractor?

Derex's initial implementation did this because some WMOs get split on tile edges. I didn't read his code to find out why this was important. For Recast, the best way to do it would be to load ALL .map and .vmap tiles from a map into memory at once, then process them with Recast to generate a tiled navmesh. Tiled navmesh will allow us to have complete pathing information for a map, whereas right now each tile is self-contained and can't generate a path to another tile. Yes, and if I'm not correct it creates 2 polygons because some triangles were the wrong way, and the result was meshes that didn't have a surface on the outside It is a lot of polys, but that is an intermediate step. The final data we are after doesn't (shouldn't?) contain all of those polys. Recast/Detour data is broken into two discreet parts: The Detail mesh stores all geometry data. The Nav mesh stores only important vertices for turning around corners, going up and down inclined surfaces, etc. We only care about the Nav mesh - the rest of the data we already have in .map and .vmap files. I have been meaning to figure out how to save ONLY the Nav mesh, but at this point I'm not 100% positive that we can throw out the Detail mesh at all. If it also contains data that the navmesh needs to function, then I'll be very very sad. And I apologize for not keeping up with this project. vmap_rewrite seems to be stable now, and it works on windows. At this point I am debating whether I should merge vmap_rewrite and mmaps. I don't want to make the tiled navmesh generator work now, and then have to rewrite it later for vmap_rewrite. What do you all think?

I say add config option, then move to under review. Plenty of non-official features exist in mangos master, they're just off by default.

Ok, I updated it. There's one caveat - I broke the generator's *nix build in order to do some major code changes. I did a rebase, so you *nix users will still be able to pull from my branch and then reset to commit fafeb6ba05becea36f472e71cb8f65da2b5ea313 'makefile typo fixes' - you get most recent mangos. I would appreciate someone's help with creating working automake files. Just send me a pm