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.

Well, I think it is enough.

Rsa, if you cannot manage to contribute in any way to a thread, then stop posting.

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.

Can we have a new repo please Cyber

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)

I know that...but thanks for the reminder:|

Any I was asking due to the fact that I have been porting the trinity one for the past week and would like to know if there is some repo that being worked on. Always better to have more than one person looking at new code

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.

cyberium wrote:

So it's time to think about moving this to underreview...

I think we need to list all known issues first. Then, get it tested on major sized server for some time and get proper feedback. Only then we can start talking about moving to review.

In any case, it can be nice to get some remarks about the general design from one of the devs.

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

Just as question would it be possible to have NPCs using mmaps on their default movement? On ytdb there is a certain Ironforge guard moving right through the great forge, if it was using mmaps it should not move through lava and fly across the air.

Other than that, these special places (like in bootybay) where movement is blocked by "strange" environment can be fix after adding the mmaps patch to the core. They are spotted by coincidence.

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/

you can use union to hold multiple data in same list

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.

see boost::any

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

https://github.com/TrinityCore/TrinityCore/commit/c2b0bcbd6c8155812857523681cd787059cd9bf9

my DungeonEncounter.dbc implementation

that extra flag for boss isnt needed

Thank you i will look on it.

Why have an extra flag?

Could it not be done using the map IDs instead? Wouldn't that allow you to determine if an NPC or Boss were killed in a specific instance by simply checking the map?

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...