cyberium

Patch updated.

Hi, Some issue i have. - Unknown group member name after teleport... If i deleay each teleport and send and "grp->SendUpdate()" the issue can be greatly dimunued but not resolved. I tried many workaround without succes, if anyone can help me here at least for pointing some place where i can take a look... - When player is teleported out the dungeon it appear offline or died for other member. All my try to identify problem are failed until now. These two issue are not blocking but annoying... So if do not hesit to contact me if you know anything about these issues. I will soon post some little patch for group.cpp followed some time after by the big LFG patch still in developement mode. Greetings

My bad thanks i understand now Greetings.

You are right blueboy but IMHO for quick testing and 'universal" patch i recommand using default setting. I personaly have scriptdev2 only on my stable server and do all testing without it. But you pethaps need some function from scriptdev2 to have playerbot work correctly? Greetings

Hi, In an devevelopement session about Dungeon Finder system i have some question. How to be sure i can saftly active "ThreatSafe" option under opcode that i need? Actually i implemented 2 important thing about that but iam not sure it's enought. EventList -> All event will be added to an list of event and processed only under "ProcessEvent" called on update. ActionList -> All action will be added to an list of action and only processed under "ProcessAction" called olso on update. Exemple -> player request adding to queue - Event received and added, - Event processed in (updateworld) - If action decided new action is created "add this guy to list" - Action processed just after event. And the guy is in the list. (EventList processing can do some action too and i think about have only one list processing but it's not the purpose of this post) So what iam not sure, - When event is processed do new event can be added? - Where is the case of concurent data access risk? Thanks

Hi, Two more question : Assume one group with 3 guy for ex. Leader add the group to LFG Queue. - If leader quit group/or get disconected what happen to 1) his queue status, 2) his two member queue status? - If candidat found (to complete group) and proposal is refused (or timed out) by one of already grouped guy, is all the group leave the queue or only the guy refused? Thanks for any answear.

Good health and happiness to all of you!

Ooooh i see now... I don't know why i cannot see this because i was playing mage and it's right no mater server i played "french or english" the most used sign for sheep is moon... So don't tell it to other lol

As i don't understaind all above sentence, i olso don't understaind why ... Moon is sheep??? According this

There is no way to limit buyout for now. It must be implemented has added feature. I have no time for now to do this. Normaly for stacking items i implemented some kind of limitation to avoid some situation like you describe. But i need more information about your issue because iam sure there i forgetted some scenario. Anyway generaly like in normal AH. If there is only 20 copper ore in AH there is some very little chance (but there is chance) to sell it at higth price. Perhaps you are in this situation. Please active buyer debug command to follow your item buying stage and found abnormal situation. Greetings

I will try. I don't think all actual solution : - need to call delete mob somewhere. - need to constantly be sure we have correct data pointed by copied ptr. - no "try catch" system implemented. is better than using shared_ptr. If i take my previously exemple here is the final code struct myStruct { uint32 data; ... }; typedef std::shared_ptr<myStruct> pMyStruct; struct mySecondStruct; { uint32 value; pMyStruct myInfo; } typedef std::shared_ptr<mySecondStruct> pMySecStruct; pMyStruct GetMyStruct() { if (m_DummyData) { pMyStruct info(new myStruct); // create mystruct info->data = 0; // assign something return info; } return NULL; } pMySecStruct MyFunction() { if (m_OtherData) { pMySecStruct info(new mySecStruct); // create struct info->value = 0; // assign something info->myInfo = GetMyStruct(); return info; } return NULL; } Now the call is pretty more simple than ever : pMySecStruct info = MyFunction(); if (info) { // Do something with info // No need to call any delete and no delete have seen in the code } No need to call any delete and the code is better than before in term of memory usage. shared_ptr template is little more cpu consuming but it's a price to have all correct test done to avoid any bad memory usage. But in my case i admit i use it more for code simplication/reading than for more "anti memory leak" property. Greetings

The only good raison i see is, is not goot to mix different way to handle pointer. So the best is to have complete coherent code not using smart_ptr. Anyway i am currently modifying my DungeonFinder implementation with the shared_ptr class because i cannot ignore the benefict of using them. Just 3 of them - Code is more easy to read. - I dont bother about any delete. - Memory management is more advanced than actual version. (anti memory leak, handle exception) I know this can reduce chance to integrate my DF implementation but it's not my absolutly goal. Iam firstly here to learn Greetings

Finaly using Reference variable for function result is not so elegant solution. Using shared_ptr seem to be a very good solution. Ambal, or anyone else, can you confirm me shared_ptr can be used on mangos code without any problem? (i mean gcc compilation or other unknow situation)

Yeah sometimes it's look like "old style" but anyway this section permit this and i don't bother if i don't know you. Happy Christmas for all of you.

Thank you Both. I think i will use Reference just because i already use it lot of time where smart_ptr are completly new for me. It's seem these auto ptr class are not so hard to learn and handle lot of case for me so i will do some learning about that asap. Thank Ambal pointing me that.

Hi I one more time invoke your help. I am faced lot of situation like this [ code=cpp ] struct myStruct { uint32 data; ... }; typedef myStruct* pMyStruct; pMyStruct GetMyStruct() { if (m_DummyData) { pMyStruct info = new myStruct; // create mystruct info->data = 0; // assign something return info; } return NULL; } [ /code ] So if i call MyFunction i know i must do : pMyStruct info = GetMyStruct(); if (info) { // Do something delete info; //delete mystruct; } It's simple. But imagine this info is imbriqued in another struct returned by another function. struct myStruct { uint32 data; ... }; typedef myStruct* pMyStruct; struct mySecondStruct; { uint32 value; pMyStruct myInfo; } typedef mySecondStruct* pMySecStruct; pMyStruct GetMyStruct() { if (m_DummyData) { pMyStruct info = new myStruct; // create mystruct info->data = 0; // assign something return info; } return NULL; } pMySecStruct MyFunction() { if (m_OtherData) { pMySecStruct info = new mySecStruct; // create struct info->value = 0; // assign something info->myInfo = GetMyStruct(); return info; } return NULL; } Now you see i must do something like pMySecStruct info = MyFunction(); if (info) { // Do something delete info->myInfo; //delete mystruct; delete info; //delete mysecondstruct; } This is pain in big project. So i usualy avoid this doing auto delete in destructor : struct myStruct { uint32 data; ... }; typedef myStruct* pMyStruct; struct mySecondStruct; { uint32 value; pMyStruct myInfo; ~mySecondStruct() { if (myInfo) delete myInfo; } } typedef mySecondStruct* pMySecStruct; pMyStruct GetMyStruct() { if (m_DummyData) { pMyStruct info = new myStruct; // create mystruct info->data = 0; // assign something return info; } return NULL; } pMySecStruct MyFunction() { if (m_OtherData) { pMySecStruct info = new mySecStruct; // create struct info->value = 0; // assign something info->myInfo = GetMyStruct(); return info; } return NULL; } Now the call is usual pMySecStruct info = MyFunction(); if (info) { // Do something delete info; //delete mysecondstruct; } Recently i talked with more experienced programmer than me. He told me to use more often Reference variable in place of returned pointer and olso i must not be affraid to use directly structure on returned value to let compilator handle all memory stuff. So in this case code is pretty more simple. struct myStruct { uint32 data; ... }; struct mySecondStruct; { uint32 value; myStruct myInfo; } myStruct GetMyStruct() { if (m_DummyData) { myStruct info; //no need to do new info.data = 0; // assign something return info; } } mySecStruct MyFunction() { if (m_OtherData) { mySecStruct info; info.value = 0; // assign something info.myInfo = GetMyStruct(); return info; } } Now you see i must do something like mySecStruct info = MyFunction(); // Do something with info For what i know the second version have less risk (or zero) to have any problem with memory usage. But it's not optimised at all due to lot of memory copy. My friend told me it's not a big lost than i imagine... Actual compilator are able to optmize code for me... Can you confirm me this point with any compilator? Do the work to handle correctly memory and pass only pointer is still needed with actual compilator? Sory for this big post. ps : can someone explaine me how code=language bbcode work?

By the way not from me I need some other couple of week to make a releasable code. I don't support anymore my current branch (will be deleted when new one is pushed)

Probably your Giant FAQ thread link in your signature

A better "compromise" sollution is to use uint64 (i think). Anyway this patch resolve main big problem in a good way so this discution (about 49 day limit) is secondary for me.

I realy understaind what you say. But unfortunaly, there is some bad exemple of small unreviewed code from long time or old one recently accepted but in "under_review" from a long time... So how the chance you will accept a patch will improve nothing, perhaps modify some functionality and introduce some regression, but needed in "future" patch with new absolutly working feature? So yes it's hard to manage and i am not here to say you "do this or that" and i respect your choice. I will continue helping until i want and it's your responsability to do what you want with provided code. Anyway send it to trash is the easyest way. Friendly.

Thank i will take a look soon.

@vladex, forbiddenn Only to help you LFGMgr.cpp: line 1003 - if (plr->GetSocial()->HasIgnore((*itPlayer)->GetGUIDLow()) || (*itPlayer)->GetSocial()->HasIgnore(plr->GetGUIDLow())) + if (plr->GetSocial()->HasIgnore((*itPlayer)->GetObjectGuid()) || (*itPlayer)->GetSocial()->HasIgnore(plr->GetObjectGuid())) Theses Encounters doesn't exist in original Dungeon Finder system. Or iam wrong? If iam wrong does any one can point me theses special case from DBC dungeonEncounters?

Definitly the best idea i seen. But i am still not at this stage. Actualy iam faced some trouble with group joining queue. Hope this time when group implementation done the code will be releasable. Still no reward and need some additional check to secure the code. Greetings

Why? I think there is a lack of cooperation between developers, all af us are working for what we want but there is some part of the code as required more than one developper at same time. Vehicule patch require lot of SQL modification as well code modification and probably more sniffing stuff. Start with actual code is possible but require same kind of cooperation you can see on mmapredux patch to get some advencement. If you look "accepted" section you will see last update concern only some little part of the code (almost spell) except vmaprewrite. Anyway i know it's not easy to focalise dev on a point and make cooperation work.

Before commit do the gain (at least for big server) is real? Has i connot see any diff (realy little server) and in this case this patch has only risk to create any new unknow situation with some new devellopement. Yes this partialy multithread implementation need for me at least prove enought good benefict just because it's only a partial solution. Anyway it's still a good piece of code not any doubt about that