cyberium

Hello, Some news. I have corrected some timer bug and group joining queue. Cleaned unused code and added some debug info. I discovered this commit "[11785] Implement dungeon encounters (DBC part)". Yeah i think i will implement (at least) basic reward with these wonderful commit! But i prefer for now continue on the main code. Simplify is the hard part. Classes are not so clear than i wanted. Make more classes with less feature? I dont know for now. Question about "try to replace one member leaved group" (my actual developement) If someone leave an lfg group, is leader show an popup with rejoining queue proposal? Only leader recieve this popup? Is that proposal always sended no mater if dungeon is finished or not? If leader accept proposal, rolescheck recasted? Iam hunting all instabilities/crash so if anyone tested this patch and experienced some of them i will be happy to get any feedback. Cheers

If you type command who need subcommand like ".modify" without any subcommand then help not contain command name. First in ChatHandler::ExecuteCommand(const char* text) : We use ChatCommandSearchResult res = FindCommand(getCommandTable(), text, command, &parentCommand); This command modify "text" pointer so we cannot use it to point on current command. But after somme line : case CHAT_COMMAND_UNKNOWN_SUBCOMMAND: { SendSysMessage(LANG_NO_SUBCMD); ShowHelpForCommand(command->ChildCommands,text); SetSentErrorMessage(true); break; }

For any one have take a look to the code, yes i use smartpointer on first stage of lfg. When the code will be enought mature and published under "under review section" i will reevaluate this following official dev comment. For now after done some testing i see there is still lot of thing to do. First part for me is to make it stable, clean the code and try to make it less complex. See you all.

I remember that dungeon reward need working detection of dungeonencounters. I already take a look around that but there is too much work to do, so i ve decided to focus on LFG code only. When this code will be enought develloped and stable if no one have already done any work on dungeon encounters i will see what i can do. So for now reward will not be developed.

Still buggy and unfinished but i pushed my LFG implementation. I need to remember all my precedent work on it and retest all. But if you have comment. warning, core is running but i do not recommand you any real testing on live server. Some minor modification must be done on Database. Files are in /sql/DungeonFinder Reversible change for any sql users.

I was thinking any discution about any part of the code is good... Si IMHO any dev who know what they talk about and have any interest on MaNGOS are proudly invited to post. Rsa included. This patch need complete rework and analyse.

I was develloping Too much thing to do forced me to stop all non essential dev. But mangos is still in my interest. I will see what i can do after reading all work done during my absence.

Happy to see this in the core. Thanks all.

Soon sorry for the wait i am realy busy for other stuff actually. I will take time this monday to update my repo.

You are right. I will update my repo soon. Greetings

Patch and repo are updated to 11191 (Thanks Skirnir)

No online repo (at least of my version) at this moment. Be sure i will considere all your remark and if you are skilled no problem for me to add you as collaborator of the project when it will be released. Some news : - No enought time to work on the code but... - At this point i choosed to delete all the code related to reward, Yes, this part need realy a global look on it, so i don't have time/knowledge to code it in the good way. - Main code is now threaded so normaly this will reduce any bad impact to mangos performance. I know this feature need to be tested on big server to validate it. - I am curently rebasing the code. I need to work on new class to make it more clear. - I need more time to have a global look on the code to delete any duplicate stuff or optimise some function. (Actual patch is 5400 lines longs...) If you whant to know all, this monday i created new branch on my local repo called "LfgToUp" so yes i plan (like two month ago lol) to release the code asap

Is EAGAIN have olso something to do with thread creation? I mean i experienced same 1024 limitation with 'ThreadManager.spawn()' function. So if all thread slot will be used for communication we are not being able to spawn some other to our specific task. Just confirm me iam wrong and it's not related to thread.

Sorry i add my two cent. Generaly not enough feedback until the code is realy released... If you want to have dev review beter chance is to place this in underreview section. Eventualy add [DEV] tag to your post For known bug list, i think we are in acceptable area. I mean release and get last bug list directly from users. It's not a kind of pressure

I second this, olso, if any npc is blocked due to any path problem we just need to correct some waypoint on DB. My test on little server ( <10 player) give me impression that all mob have a real reaction (better than blizz?). So it's time to think about moving this to underreview... Thank you qsa and faramir118. You are my exemple

Thank you Yad, you have done a good (and long) work. The only bad point is it will be difficult to isolate only your "autobot" patch in case to install it on clean mangos. In your src/game you have actualy 2 "PlayerBot" subdir...

updated first post

Patch and repo updated to [11131].

Fine thank all of you i found an elegant way using some research from words "type erasure". http://www.cplusplus.com/forum/articles/18756/

One bad thing using union is constructor will be called for all type i declare on it. I probably can do some workaround by using only pointer to type but this require like void* method to handle new and delete for that data. boost::any seem to be realy polyvalent but need boost lib... Iam doing some test with new class containing template but no good result for now...

Hi, Considering struct like this : struct myData { int myInt; bool myBool; someType data; myData(const int& intValue, const bool& boolValue, const someType& dataValue) { myInt = intValue; myBool = boolValue; data = dataValue; } } std::list < myData > myList; ... main { myData* d = new myData(5, true, 1); myList.push_back(d); myData* d = new myData(5, true, "hello"); myList.push_back(d); ... } Idea is to have multiple type of data possible in same List. Is it possible to realise this without using void*?

WIP when i have time

Thank you i will look on it.

And then? How you can know when a boss is killed? How you make diff between 10 bosses and 200 trash mob? List of name? List of guid? Do check in every mob killed if it appear in boss list? Found a better way, and i'll implement it... Anyway iam stopping this part for now : - lazy about some reaction... - it's too much for me adding this part to DF while DF not finished. Greetings

I am working on DungeonEncounter only. I will not handle all the encounters in DungeonEncounters.dbc. But the door will be opened. If any dev is interested ofc...