quixote

Hi quixote,

Glad you like my 'roll for loot' code . Seriously, we would be very interested in any contribution that will improve the playerbot code. I wrote the 'loot roll code' sometime back, as there was nothing in place to handle group looting. At the time, a random roll seemed to be the fairest way to distribute loot.

You will find the loot handling code in PlayerbotMgr.cpp, in function HandleMasterIncomingPacket(). This handles the incoming opcode CMSG_LOOT_ROLL. Let us know if you need anymore information

Cheers

Random is good, at least we have some variety

Hmm, looking at this, the problem is that on receipt of CMSG_LOOT_ROLL we've lost direct visibility of what the roll is for (and it seems difficult to get that info from what's in that message) - it may not be a complete disaster, but not clear how to find it without keeping the PlayerBot code nicely encapsulated...unless we do something with the outbound message to the client - SMSG_LOOT_START_ROLL has all the details we need - including the itemid from which can be derived the ItemPrototype...

If someone can tell me I'm wrong re CMSG_LOOT_ROLL params (as I am new to the vast mangos codebase) then great, otherwise, I'll figure something else out...

Right now I'm focussing on being able to understand the info in ItemPrototype and how it can be used (ItemHandler/ObjectMgr/Player all seem to have examples), then I can figure out...do we want to wait for the "Master" to respond and then have the bots determine what they should do...this would enable us to say, for example, if the Master "Needs" then the bots pass...If we want to do that, it involves storing the item info between the outbound packet and the associated response (if one comes back...) and of course managing and cleaning up that data...

Concerning the collect command syntax: it could probably use some changes. Unfortunately, I have always been poor at the ease of use aspect. The collect command just gives you a display of what the bots are set to. The subcommands do the actual work:

combat - bot will loot after combat for the options that are set

...

profession - bot will grab any profession related item that the bot has from corpse

...

This is what I was looking for...great, now how easy would it be to have sensible responses to rolls for loot - e.g. need vs greed vs disenchant...

Would be great to have some simple rules per class that specified when something could be classed as need (e.g. Mail/Plate can only be needed by someone that can wear it!)

Happy to help, just trying to figure out where to start - not sure where the code that handles rolls lies...

Nice script, some useful stuff in there - I have to admit, I'm a big python fan for knocking together band-aids around issues and this is much nicer than my approach which was a python script that went through all the update files and concat'd them together on a per db basis and then I'd just load them into the mysql cmd line client through "\\. dbscript.sql", but this is much cleaner

Is there a way of keeping the subprocess running in interactive mode and piping the individual scripts to it - this would save on creating a new DB connection for every script ?

BTW: You should use os.path.join(path,file) to concatenate a path and a file, as this is os portable and will use '/' on *nix and '\\' on MS.

This is a reply for and old post, but i have the same error in my server... i found the solution

In some files, in my case src/shared/Database/DatabaseMysql.cpp, are codes like this "#ifdef MANGOS_DEBUG" and "#endif"

This is NOT COMPATIBLE with CentOs Linux... i think # y for comment, isnt ?? well is better to use //

In CentOs the # character for comments is not compatible (im not a c++ programmer)

Read the error, see what file and in what line is the error, go to the line and search something like this

I hope this help some CentOs user in the world

The # is not a comment character, it indicates it's a preprocessor directive.

This means during the initial compilation phase, the preprocessor checks in this case if MANGOS_DEBUG is set and if not it will ignore all code until the #endif

This is very common as it allows optional extra code to be compiled into a "debug" build versus a more streamlined production build, or Linux versus Windows code can be conditionally compiled in.