cyberium

What bug does the patch fix? What features does the patch add?

No bug, only redondant call of reset instance to try to reset Raid. But it's not possible to reset any raid instance this way.

For which repository revision was the patch created?

latest

Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread.

none

Who has been writing this patch? Please include either forum user names or email addresses.

me

Patch:

http://paste2.org/p/1888590

diff --git a/src/game/MiscHandler.cpp b/src/game/MiscHandler.cpp
index 9a1af2b..8d4383e 100644
--- a/src/game/MiscHandler.cpp
+++ b/src/game/MiscHandler.cpp
@@ -1401,16 +1401,10 @@ void WorldSession::HandleResetInstancesOpcode( WorldPacket & /*recv_data*/ )
    if (Group *pGroup = _player->GetGroup())
    {
        if (pGroup->IsLeader(_player->GetObjectGuid()))
-        {
            pGroup->ResetInstances(INSTANCE_RESET_ALL, false, _player);
-            pGroup->ResetInstances(INSTANCE_RESET_ALL, true,_player);
-        }
    }
    else
-    {
        _player->ResetInstances(INSTANCE_RESET_ALL, false);
-        _player->ResetInstances(INSTANCE_RESET_ALL, true);
-    }
}

void WorldSession::HandleSetDungeonDifficultyOpcode( WorldPacket & recv_data )

Edit: Made a mistake in first version sorry.

http://img829.imageshack.us/img829/4640/wowscrnshot012712193726.jpg[/img]

Just to show you my result.

Cheers

Helo,

I cannot confirm that on fresh install. Please verify your install/DB.

Mangos latest, with YTDB an no scriptdev2.

I think the best choice will depend on the final way we'll implement monster's agro reset. (evade mode)

But your suggestion goes to the right direction Schmoozerd.

Happy to see it in master. It's never too late Dark And in actual situation it's good to see some movement...

Welcome

Your first post is well except perhaps misplaced (community café ?) because no question about mangos on it .

Cheers

Hello Talrain,

Best guide for MaNGO is the core comments itself.

Olso take a look to all patch, if you can understaind some of them you will surely learn new thing about the core.

But you must know C++ before.

It's not easy but it worth.

Don't forget a cycle is done every 20 sec/ah.

There is 3 AH and operation can be buy or sell

Yes if all operation need to be updated, each AH are updated every 2 min. (if only one AH need update it will be updated every 20sec until all operation are done)

So AuctionHouseBot.ItemsPerCycle.Normal need to be set according server population.

AuctionHouseBot.ItemsPerCycle.Boost was designed only to fill AH first time. But can be used if you set AuctionHouseBot.ItemsPerCycle.Normal too low.

Good design. No other comment about it.

But i only posted here to say how i was happy to see Vladimir post something here

Happy new year guy's. I wish you the best and hope MaNGOS will resurect.

Spécial Thanks to all actual contributor to this project.

Yeah iam sorry for that. Time is my first enemy now.

But like UnkleNuke say don't wait continue it or best make your version!

Im not sure to continue that. Only thing i can say, I LIKE MaNGOS code!!! ( I wish I could say the same about the team )

By default "cycle" triggered every 20 sec. World.cpp->SetInitialWorldSettings(){m_timers[WUPDATE_AHBOT].SetInterval(20*IN_MILLISECONDS); // every 20 sec} on about line 1341

I do not recommand to reduce this

Link?

Original question is What's going on about MaNGOS, no cries, not hysteric...

Still not any good answear (except some unconfirmed element by SchmooZerd)

So if you stop Vladimir, i have only one word for you.

Respect!

Iam your fan.

Thank you for your time here, it was a gift for any who understaind what you've done.

No fail if even only one develleper continue this project.

TrinityCore and R2 are another project with other priority/requierement. Not comparable. Can you compare R2 and TrinityCore? Why make R2 in place of contribute all to TrinityCore?

You know what is MaNGOS. Learning project only. Not for production. It's why i like the philosophy/rigor/severity of it's DEVs.

It's why olso MaNGOS is still considered like a base. Other are just fork with some good hack but some bad too.

Ex? hum "spell XXXX causing crash"? No problem make new condition like :

if (spell = XXXX) return;

Do you think this kind of patch pass underreview section?

We only need actual Dev to get back again. Loosing VladimirMangos and it's about 50% commit is very rude to MaNGOS community. Olso other Dev like Laise are working in backscene before release big patch (remember aura patch, Vmaps etc...)

We lack their answear in this topic.

Cheers all.

It seems Rsa know coding but don't know what PM is... No offense its joke.

Yeah i was thinking same first. But after looking the code :

- using EntryPoint is clearly not related to BG only code.

- using BG database for other case like LFG is no sense.

- adding player entrypoint method to player class is IMHO logical.

Best regards.

You are still right (as always )

But don't forget, iam sure this patch is heavly used on some big server from longtime now, i hope at least some of admin of them will help us with some feedback like Undergarun was providing us.

Again sorry for this off topic. It's only to make some avancement.

Also especially directed to qsa and faramir:

One big step about developing is not "only" to write code, but to discuss the code and argue about weaknesses in the code.

This is actually one of the things that slows mangos down the most: we try to discuss most serious changes, and this takes most of the time.

You are right

That's UnderReview section is for.

But do we need another 1,5 year?

Cheers

ps: with all my respect for all that work

After 1,5 year of devellopement we can espect the dev are littlebit tired about this.

I personaly didn't get any issue (but on very little server used occasionaly).

Why this not applied to master?

Erf i am completly off topic... Sorry

Is MaNGOS devellopers are all aways?

Your reasonning will be fine Schmoozerd if MaNGOS have enought developpers.

But has i see if il only look "under review" section why there is so much post on it? These forum must be (by definition) more often empty... Patch must be applied or refused in reasonable time.

So this community seem to work to slow (due to not enought devellopers leader)

Keep core clean is an good reason. But with no improvement is too much price.

I don't see anymore any Vladimir, lynx3D, Ambal, NoFantasy, Neo2003, DasBlub commit??? Is all of these dev go away?

So if no enought dynamic here i understaind why fork R2 is created.

Iam litteraly flooded with update on trinitycore everyday. We are agree it's their choice to get "some spaghetti code and hack". Anyway only with more update trinity community keep their dev motivated.

So the question is, is there still enought dev who whant to continue improving MaNGOS?

Actually Stfx, Schmoozerd cannot handle all patch. Laise, SilverIce and Zergtmn are still present but occasionaly.

I understaind all priority (i have mine too "my familly, my job, and some films/game") but you must be honest with us about that.

Your solution work flawlessly.

Thank you.

Yes ofc, Dungeon Cooldown(71328) and LuckOfTheDraw(72221).

But there is probably more existing case.

Case 72221 must be casted after teleport because of spellarea added for these spell.

Cheers

As i see when we teleport player to location (plr->TeleportTo(location) we cannot use in next line "castspell(plr, aura)". (may result with crash in spell method)

So if i want to apply aura after teleportation done what is the best method?

Is test IsBeingTeleportedFar associated with ScheduleDelayedOperations is the good way?

What bug does the patch fix? What features does the patch add?

With that patch we can use Player::SetEntryPoint (was SetBattlegroundEntryPoint) to other purpose than only BG entry. (Planned to use it for LFG)

This olso make that method more specific.

For which repository revision was the patch created?

11834

Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread.

none

Who has been writing this patch? Please include either forum user names or email addresses.

me

Patch:

http://paste2.org/p/1743622

Edit:

Bug identified and corrected. (field selection on loadEntryPoint was not correct)

Lotof good informations i hope i will emulate this as close has possible.

Next soon.

Thank you all.

Edit.

I should probably clarify that the Dungeon Group is a special sort of party a player joins when using the DF. A Dungeon Group supersedes all other party groups. It is possible to be in a party with one or more players while also being in a Dungeon Group just as it is possible for someone in your party to join a Dungeon Group while you continued to adventure or quest in the world. This prevented the Dungeon Finder from disrupting adventuring parties. Upon leaving a dungeon, the player is dropped from the Dungeon Group, but not his party he was in before joining the queue. It works the same for Battlegrounds and Raids. However, if your Party Leader joins a dungeon queue, all other party members are automatically presented with a Role Check. You can choose a role and join the queue with your party or refuse the Role Check and remain in the world to adventure. Parties entering the DF will remain together, with empty roles filled by other players in the DF.

This part that I did not know, seems very difficult to achieve with my current implementation. A new class "group" should be created/derived to make it possible. This profoundly changes the patch and forces me to rewrite a lot of thing...

So iam trying to get correct way to create lfg group before continuing the rest.

Edit 2

Ok i think the best for me for now is to stuck with theses implementation:

- when player is in group and he is not the leader the join lfg queue is disabled for him. (only leader can join lfg queue)

- when player is in lfg queue and accept group invit, he will be removed from current queue.

Is it real issue? (not have 2 group for one player at same time)

Edit 3

After some new research i found that BG system is similar, so iam wrong.

I need more investigation to understaind BG system in order to use same mechanism to teleport/create instance and group.

This step will get this part of LFG at least have same stability of actual BG way. (and probably save me to write any redundant code)