DasBlub

i think you probably did something wrong while setting up your db? have a look at the guides how to set up the db and do it step by step

of course you can help just take you something which doesn't work (e.g. have a look into the bugsection here in the forum) and fix it. then post the patchfile in the "under review" section and wait for comments you should update your mangos/sd2/udb/acid from time to time (at least update to the newest version before you post a patch, so it's then compatible with the newest version). if you make much changes then you should use an own repository, then it's easier for you. just register at http://github.com/ and fork the mangos repo and then clone your own repo to your local harddisk (git clone) and commit your changes instead of creating patchfiles

how would you make this association with an std::vector ?i need a map, because i need the association scriptid (uint32) <-> script instance (Script*) (the scriptid comes from the core and is not automatically calculated by the script library, else i would have used std::vector)

currently the scriptlib ('universal') has some bad things in the code. i'm on it to update this library, please do not commit any of those changes yet to the repo, it would break sd2 (i'll write a patch for sd2 before it will be ready for the repo). here is the branch for it: http://github.com/DasBlub/mangos/commits/scriptlib_universal (actually only a clone from the master branch, i'll create a scriptlib_universal_0.12 when i'm done with the changes) changes done: * updating coding style, change defines to enums: * first fixes: http://github.com/DasBlub/mangos/commit/add3aa9544e5654ae0a7e3792863dde6050c80fc * some things pointed out by NoFantasy (thx!): http://github.com/DasBlub/mangos/commit/7459ed1aa77fc51b1641ef6332d0884b6f644410 * change the array m_scripts to a dynamic std::map, so we can have whatever amount of scripts we wanna have: * change the array to std::map: http://github.com/DasBlub/mangos/commit/3a6d2e275ecd0657270b3d077a3a4172c64c735b * fix crash (sorry, didn't test the previous commit, so i haven't seen the NULL-pointer ): http://github.com/DasBlub/mangos/commit/10d8ad5d865ff29cb66f8d27960d1eda0c7c58f5 changes to be done: * code cleanup (if i've missed something^^) * move the functions into a class, this could help with implementing multithreading * move the GetAI_xyz() into the CreatureAI class * create a patchfile for sd2 before submitting this here comments and ideas are welcome if someone who knows the ACE lib will and knows how to implement multithreading could say here, what changes would be needed to implement a better multithreading, would that be nice i had the idea, that we could multithread all instances in the script library (for every instance an own thread)... but i'm unsure if that isn't already the case when using the mtmaps patch?

type first that command: .gm on

ambal/wyk3d: will your changes be commited to the mangos repo or is this 'just' another patchfile which we need to apply by ourself? however, the description looks nice, i didn't gave a look at the patch till now.

just one thing: for lua you don't have to edit the core, you've "just" to create a script library (copy the default library and adjust it to your needs)

i'm working with ca. 8 branches and i have no problem. this network graphic is nice but it is not needed for the work with git.

don't download the patch, just copy the text into a file, else you could run into troubles with the newline encoding (windows CR LF (13 10) vs. linux LF (10))

Core: 7809 (mangos-0.12) SD2: 1071 UDB: 365 ACID: 0.0.9 (2.4.3 version) Patches: no_char_delete, mtmaps, alterac, procflag, some other minor own fixes Logfiles http://paste2.org/p/217424 http://paste2.org/p/217425 http://paste2.org/p/217426 http://paste2.org/p/217427 http://paste2.org/p/217429 http://paste2.org/p/217430 http://paste2.org/p/217433 http://paste2.org/p/217434 http://paste2.org/p/217435 http://paste2.org/p/217437 http://paste2.org/p/217439 http://paste2.org/p/217440 http://paste2.org/p/217441 http://paste2.org/p/217442 http://paste2.org/p/217443 http://paste2.org/p/217445 hope that helps

for a normal patchfile (recomended): git diff key1 key2 > /path/to/my.diff where key1 and key2 defines the sha1 key from the two commits. git diff > /path/to/my.diff generates a diff file between the local version and the HEAD version from the actual branch for the other version (with header): - commit your changes: git commit -a -v - get the commit info into the file git show key > /path/to/my.patch where key is the sha1 key from your commit.

that has nothing to do with .patch/.diff, you have to look into the file and look at the first few lines. if there's somthing like 'author:' and all that stuff, then you'll have to use 'git am' else 'git apply'. and yes, syntax is: git apply /path/to/my.patch git am /path/to/my.patch and i've no idea about the git gui, i've never used it

there are 2 types of patches, the first one you apply with 'git am' and the 2nd with 'git apply'. the first one has a full commit info in his header (commiter, commiter-email, commit-comment, etc.) and the 2nd only has the diff file. so for your patch it seems like you'll need 'git apply' instead of 'git am'

yeah, thx subhuman... it was late in the night and i was allready sleeping, sorry please forget everything what i said about 11111=lvl5 ^^ i just mixed up binary numbers and bitmasks.... *needs more coffee*

lvl5 isn't 11111, that would be lvl31 lvl5 is 110 that's because it's the binary system

it would be nice to set the security settings by flags. so instead of saying gmlevel=3 for a command you say then securityflag=0111 to give it to the first 3 gmlevels and e.g. securityflag=0100 to give it ONLY to gmlevel3. another thing related to gmlevel: it would be nice to remove all hardcoded gmlevel checks from the code and move them all to the commands-table, so it is easier to modify them. next thing: it would be nice to be able to set the gmlevels for each realm. one default gmlevel on the realmd table and then on every mangosd you have the possibility to overwrite the gmlevel for an account, so e.g. the account 'dummy' has defaultly only gmlevel 0, but on the realm 'testrealm' he has then gmlevel2, so we don't need to modify the security-settings in the command table to give this user access. (i know that there is a patch for that, but this patch is bad, because it doesn't change all selects for the gmlevel). oh, and again another thing (sry^^): multiple times in the code there are selects directly on the database to get the gmlevel instead of using the existing method in the Player class, that makes it hard to implement the idea i just mentioned before.

confirmed, i have that too with my 2.4.3 client and mangos-0.12 branch. someone changed something in the grid/map system? ps: i only have 10-20 seconds delay, didn't have 40seconds yet

you can set the expansion in theaccount-table to 2 so that you can use wotlk on the 3.0.9 server and in the mangosd.conf to 0 to disable every tbc/wotlk things on that specific realm (mangosd)

updated to newest revision some hours ago (rev. 7738 on master). any comments...?

Server version: mysql 5.0.51b-community-nt MySQL Community Edition (GPL) why: because it's in xampp (apache2+php+mysql+some other stuff) and i just use it to compile my server and start it every week once to check if it still works^^ and on the other server "5.0.51a source distribution". why: it is the version which is in the repo from fedora

and what about the server uptime from the worldd? did it hold the load? (i mean memory leaks and that damn stuff )

allready exists:

6767 is really, really old... use git to get the newest version and check out the mangos-0.12 branch, that's the 2.4.3 version from mangos

has anyone done once a performance scan which shows us, which parts of mangos are slow? i think the three bottlenecks are the maps, the vmaps and the spellsystem, because all those needs much calculations and they could run parallel. the spellsystem itself has a bad implementation (in my eyes) because everything is hardcoded

hm... CUDA only works when you have a graphic card... much servers don't even have any graphic card (network boot+remote management), or they only have an onboard graphic card... but to really use CUDA you would need a fast graphiccard like a nvidia 9XXX or a 280 (or 295), and that's not a server graphiccard... so implementing a SERVER with CUDA is the wrong way, better implement a clustering system with a good thread- and processmanagement. btw, we're going offtopic here... b2t: i hope MoveMaps will once get into a 'usable' version which doesn't cost much performance, because it would be a big improvement