Lynx3d

You know what, this problem sounds very familiar... You even noticed "(...) that Map.dbc is stored in multiple mpq archives." Now you have to give me a very good reason why you did this: } - gOpenArchives.push_front(this); + gOpenArchives.push_back(this); } In other words, you deliberately broke it Some things indeed have a reason that they are as they are... About the crash of assembler, please give me at least a hint about the type of crash...is it a segmentation fault, stack overflow, floating point exception etc. And maybe someone even knows how to use a debugger to find the causing code line... @KAPATEJib: Yes Linux assembled vmaps should work on windows too unless i overlooked something gross...just make sure the CPU has the same endianness.

Just jound a bug in extractor that caused a crash when enGB (first search locale) was not present. Also improved scan code to not print irritating errors for not installed locales. But i have no clue why assembler fails, need more detailed information. How many files did extractor create? How big is the dir_bin file created? Maybe a checksum (MD5 or SHA1) would also help, but i'm not sure it's really locale independent... What exactly means "hang"? 100% CPU usage? Memory usage? It should definitely go til "Spawning Map 724" before starting printing that Guid ranges, and after that printing which model file it converts...

Eh..."ChamberofAspectRed" is the last map currently in game, so of course it stops there, it's done ^^ -edit- Wait, are you sure you actually let it finish? After it read the map files it starts converting them without further output (except some warnings about empty ADT files and a final success/error message), takes a few minutes.

UnkleNuke, i really don't think it is possible to compile libmpq with MSVC without some code changes...at least not with ver. 8 and 9, because they don't have all C99 headers required. For now i went with suggestion 1) of faramir. If your computer didn't explode in the past when extracting maps/dbc, it should work. But i can't test, there's really no way to make room for WoW on my notebook. I don't think it's a good idea using some untested "quick shot" patch for libmpq just to get current version working, but if someone wants to try a serious porting attempt, please also suggest at libmpq.org.

Which seems to pretty much the same god-knows-why-C++ derivate from who knows of unknown age that we are using too ^^ If you're fine with that, i'll just make a compile option to use that or official libmpq... faramir could've told me the headers of libmpq are not MSVC compatible in the first place, so it's not only the build setup. Though i do wonder why there options in config.h to specify if stdint.h etc. exist, when they still get unconditionally included Anyway, can someone confirm that at least core and vmap_assembler now build with VS 9? And come on, is there not a single linux user interested in this?

insider42 / scriptdev2 forked from scriptdev2/scriptdev2 You are on getmangos.com, not on scriptdev2.com... If you tried to apply an SD2 patch to Mangos, you shouldn't be surprised the files don't even exist...or what exactly are you trying, that makes this topic mangos related? -edit- This was not a suggestion to complain at scriptdev2.com, they are not responsible for forked repos either, just wanted to point out that it seems you try to combine apples with oranges...so to speak...

uhm...you might want to read what software project that repo was forked from...

Hm i just installed MinGW and MSYS on my notebook (only computer with windows here...) and after tediously downloading and unpacking all the components (luckily there's ready zlib and bz2 for mingw), autogen.sh, configure and make worked and produced a libmpq.a (~480kb). Guess it's statically linked to zlib+bz2, so would that one file be enough to compile the extractor with MSVC?

Thanks for your effort faramir118. I should mention that i did not touch the project files for vmap_extractor/assembler yet, maybe they even have been/can be created with cmake anyway, i don't know. Because no one can tell me how old it is, where it even comes from (.cpp files??) or if its even save to use on 64bit systems, so i have to hope it doesn't wreak havoc each time i run it Also, current libmpq just makes code nicer because it encapsulates internal stuff better, so i'd really like to upgrade libmpq for both tools. Hm isn't it possible to run the configure script in MSYS? I would prefer if people not wildly hack inside library code this time... There's not really anything in my config.h that looks like it would be impossible to make a "generic" one that works for MSVC or MinGW: http://paste2.org/p/781286

Disclaimer: Current status of this project is "working, but needs more testing". Use at own risk, although feedback so far has been mostly positive. You probably wonder why one would rewrite the vmap system. I'll try to keep it brief, feel free to ask for more detail... It basically started with arrai starting to implement indoor/outdoor information for vmaps, and me trying to figure out how area information stored in WMO works. While reding the vmap code I came to the conclusion that there's enough rough edges to try a different approach. Basic things i did not like: * all objects are saved as a transformed copy, which makes Vmaps very big * no proper mesh format, each triangle defines new corner points, makes Vmaps even bigger * to counter this, coordinate precision was severely reduced (16bit, fixed range) which made deeprun tram impossible even Also several things were done quite confusingly or inefficiently, making the decision to rewrite even easier. Since the models are stored with transformed coordinates, it was more difficult to check the WMO bounds that delimit the information we were trying to query. This lead me to this approach: * keep models stored in original coordinates, transform rays at intersection instead * to be able to intersect the world, assembler creates a static tree for the entire map * instead of the AABSPTree i chose a Bounding Interval Hierarchy (BIH) which basically is much better at "cutting off" empty space without having to reference models in multiple tree nodes * Since models are re-used all over the game world, model allocations are handled globally All in all, this reduced Vmap size to less than one third, and should improve precision. However, there's much more files now, each model, each tile ("grid") and each map needs one file. I can't really say anything about performance, but i would be very surprised if it's slower than the old code. If anyone can setup some benchmark, i'd love to see some numbers... New features thanks to arrai (and indirectly tom_rus): * indoor/outdoor check which allows automatic unmounting of players * additional area information from WMOAreaTable.dbc, removed existing "hacks" * WMO Liquid information for swimming and fishing correctly in buildings/cities/caves/instances Now that you know what this is about, you may get the code from: http://github.com/Lynx3d/mangos/tree/vmap_rewrite How to use (linux) First, you need to compile libmpq in dep/libmpq the "traditional" way: First './autogen.sh' then './configure' followed by 'make'. Then you can compile vmap_extractor_v2 and vmap_assembler with Cmake like you do with extractor (see contrib/extractor/README.linux if you never did that). The rest should work like it did before, i.e. run vmapextractor in WoW base folder, create <destination dir> and run 'vmap_assembler Buildings <destination dir>'. Should take ~5-10min each. Finally, copy/move the <destination dir> to your data dir and name it 'vmaps' (if not already named like that anyway). 'Buildings' can be deleted afterwards. Update: How to use (windows) Before extracting and assembling, you need to build the new vmap_extractor and vmap_assembler binaries, the precompiled ones are not yet updated. But usage should still be the same...I think. First, you need to build the solution in dep/libmpq/win in the same configuration you want to build the extractor (release or debug) Then, you can build the solutions for vmap_extractor_v2 and vmap_assembler. Windows build setup thanks to faramir118, you may still check his repository for new improvements to build/usage (use at own risk...well...not that mine would give you any guarantees): http://github.com/faramir118/mangos/tree/vmap_rewrite General Info: To enable indoor check for automatic unmounting, set "vmap.enableIndoorCheck" in mangosd.conf to 1. The .gps command also prints a few additional infos to check if area detection works as intended.

From the "Announcements & News" section: So, how about [9691]? I know git history can be confusing when merging a some branch B into A, when A has been merged into B just before...as you may notice, there is no "Merge branch '330' into master" just before [9692]. Pick the actual [9691] (d6b3da1b8...), not what github shows just below [9692]... If you look at the graph in gitk, you will see why your choice is not a 3.3.2 compatible core.

If i'm not mistaken, there's no need to checkout a branch in order to cherry-pick from it, fetch should be enough. You may also have a look at gitk, after fetching you can setup a view to the remote branch to get a history browser plus the ability to cherry-pick simply by right-clicking on commits.

That's not quite true... Multithreaded is anything that has more than one thread. Mangos already has multiple threads, but the "heavy" workload is not distributed among several threads. Thread pool is a more specific concept. If you have 4 hyperthreaded cores, so you can handle 8 threads concurrently, you can create a pool of 8 threads and try to distribute the workload among these threads.

Of course not, pTest has not been declared anywhere in scope, it can't pull it from nowhere. This has nothing to do with pointers at all, you probably should go back to the very basics of programming and how to use/pass variables... No idea what you mean, only way to have a variable available to all functions is making them global, but among the very first things a good C/C++ book should teach you is that global variables are bad design in >95% of all cases. Pass the pointer, period.

SpellEffects[] is an array of function pointers, indeed. They're a bit of a special case, you don't allocate or delete functions, they are tied to the binary file that contain their code. They're more common in C (no virtual member functions), but still can be useful in C++, like in this case to map an integer to a function in an efficient way. As for (1) unitTarget->isAlive(); vs. (2) *unitTarget.isAlive(); they are not the same, because . operator has higher precedence than *, so the equivalence to (1) is (*unitTarget).isAlive(); The pointer itself is by definition destroyed when its scope ends, but you are probably refering to the memory it points to. Of course if the object it points to goes out of scope, the pointer becomes invalid (i.e. dereferencing likely crashes the application, or at least does not give you a valid object instance). As already said, pointers are commonly involved when doing dynamic memory allocation, i.e. with new and delete. new returns a pointer to a newly allocated object, and this pointer (the address it holds, to be super-clear) is valid until you call delete for this very same address. And if the last pointer holding that address goes out of scope, you successfully created a memory leak And yes, constructors/destructors are places where you'll often find new/delete to allocate/free variable sized class members, and common places to leak memory...

@KAPATEJIb: That looks a lot like "out of memory" exception throw to me...you are running 32bit linux? Would help to know the memory usage at time of crash... If that is the case, mangos probably won't even start if you try to preload everything. But there's hope for oniyou, i'm just finishing up a rewrite of Vmaps. The new structure references spawned objects instead of clng it each spawn. Also the geometry storage was horrible... I'm currently down to ~410MB total (from 1.8GB), and that's without sacrificing precision by storing coordinates with only 16bit precision. Memory consumption (with everything loaded) should be roughly equal to disk space in both cases btw...

I don't think you really would want to do that anyway... Your spellbook would probably explode (or your client crash even) and many of them you'd not be able to use anyway, because you don't have mana/energy/rage/focus/runepower etc. or simply because they don't show up in client anywhere at all... You can cast spells in many ways as GM without learning them.

Yea it seems no formula matches all flasks and elixirs. Probably, there is no such formula, I'm afraid it has to be done with yet another column in databse, unless someone sees some dbc data for it...

+ if(!getPetType()==SUMMON_PET) Does most likely not what you intended, you probably want + if(getPetType() != SUMMON_PET)

Storing the pairs in a std::list and doing linear search on it really hurts my eyes... MaNGOS defines an UNORDERED_MAP type for such purposes, if i'm not mistaken. Other than that, this looks like it should work Naming could be a bit clearer though IMHO. Does not make me think of item replacement on duration expire. Some sanity checks on loading wouldn't hurt either, like do the items even exist, do they have duration etc...

Just add this little keyword called "inline" if you're soooo concerned about those 0.00....1% performance loss, instead of going back to stoneage with C Macros... (in fact, i bet your compiler was inlining it anyway, gcc uses -finline-small-functions as early as O1...)

Just updated repository, fixed merge conflicts and did some small changes. Still can't really find anything substantial to improve, but i need to re-test everything to make sure it still works as intended... And maybe someone knows if error messages are correct (when trying to enchant vellum in trade slot, or vellum with scroll etc). Repository still as in my last post. Diff to master (for reviewing purpose): http://paste2.org/p/691125

Phew...i am not 100% sure what you are trying to do... You keep your master deliberately behind origin/master for database reasons? I'll try to explainas good as i can, with my also limited git knowledge. At least right now, the ahbot repo/branch you mention was last merged with [9400], so if you diff your master with ahbot without telling git specific revisions, it will assume current HEAD for both. That means, it includes all ahbot specific commits aswell as everything from master [9310]-[9400], because all that is present in your ahbot branch, but not in your master branch. If you want a diff that only contains ahbot specific code, you need to look at the history of the ahbot branch and pick suitable commits (e.g. by the SHA hash). Suitable commits means, take an ahbot commit, and diff against the last "joint" with origin master, so the last point it synced code. Ideal place to see the apropriate commits is a merge itself, either there is already one in the ahbot branch, or you can merge the branches. For example take this merge commit: http://github.com/Naicisum/mangos/commit/09969c4c6d0a68ca429d61effd1abc365d02451d Take a look at the right side of the blue box, this commit has two parents: http://github.com/Naicisum/mangos/commit/e2a8db20e8310f6226bc919c5fc45d49b55b9723 This is the last commit to ahbot, it apparently resolved merge conflicts http://github.com/Naicisum/mangos/commit/10847c9fc562bb94d55fa66cbac699521530453e This is the mangos commit that was merged with, [9400] in this case. If you tell git to diff from this commit to its mangos parent: git diff 10847c9fc562bb94d55fa66cbac699521530453e 09969c4c6d0a68ca429d61effd1abc365d02451d > ahbot.patch you should get a patch with everything from ahbot that will definitely apply to clean mangos [9400]. However, it will not necessarily apply to [9310], it might, or might not. If it does not, you really have to look at the history and find a common point between the branches as close to [9310] as possible. You could for example try above procedure with e9f2db1016acb6d8eeabd4cd70c88cef8d3d25ef which merges ahbot with [9342]. But in general you cannot expect code written after newer merges to to magically apply to your old mangos, in this case, you either have to live with older ahbot code, or backport new code yourself where necessary.

That commit only changed the Enum type the function wants, and is not the source of your error. As i said, the problem is the fourth argument which is of type double, but should be of type SplineType. I think the commit that "breaks" your script is this one: http://github.com/mangos/mangos/commit/83725e678fe7163f68e0c2a21437ac2be2ef71e1 But that doesn't change the fact that this argument never was float or double and passing a double es 4th argument never made sense. If you didn't change that argument, this script probably only worked by accident then, and only compiled because the compiler converted the double to uint8 without telling you, but that doesn't work with Enum types (which is exactly the reason why those enums were added instead of ints, to prevent passing of unexpected values)

Sorry but i can't reproduce that problem. On second,third etc. cast of Call of Elements i get message that spell not ready and totem on cooldown is not (re-)placed. Clean MaNGOS [9419]