[Bug]Instance Reset Time

[ProjectX]

Mangos: 7502

SD2: 921

UDB: 369

Problem: When instnace reset time is calcuted for 2nd time after the last server restart, the timer says that instance will be reseted after about 49700 days and some hours. But if you restart server it will be recalculated as it should be. The best examples are Heroic instances, we have reset time set at 04:00 AM, when the new reset time is calculated it will be set on 49k days and etc. But all instaces behave same. ( 7-day instances get mad after 7th day , 3-day instances after 3rd day and etc ).

Very strange bug but I havn't found any report about this. Any ideas ?

EDIT:

added some screenshots

Server Uptime

Heroic Magister Terrace Reset Time after 1. boss killed

[ProjectX]

Any ideas ? Someone with same problem ?

[Espec]

Reset of instances is programmed in mangos but i'm missing some guide how to change time of instance reset, e.g. 3 or 7 days for raids, 1 day for heroic dungs...

[Sephiroth1983]

Reset of instances is programmed in mangos but i'm missing some guide how to change time of instance reset, e.g. 3 or 7 days for raids, 1 day for heroic dungs...

Setting 0 in resetdelay field of instance_template should make it use the DBC values for resets

but currently I got many reports that is broken, by not binding or not saving the group to the instance.

[Espec]

Setting 0 in resetdelay field of instance_template should make it use the DBC values for resets

but currently I got many reports that is broken, by not binding or not saving the group to the instance.

this is the only information i have. Which other settings do influence the instance reset time? And how can i set nonblizz reset time?

i am sorry for small offtopic

[ProjectX]

please can someone confirm this or not because Im little bit confused right now and dont know if it is just my problem or it is global bug

[oc_redfox]

Semi-Confirmed...

Happens sometimes and sometimes it works

::Edit::

Maybe it happens when server unbinds the 1-day instances?

Seems like it then unbinds all instances, even those with longer reset time...

[Trazom]

This is DB related. I've seen no bug in the core (thougth I might have missed it )

In the table Instance_template, reset_delay is the delay to reset in DAYS. not minute. not second. DAY.

(see: http://wiki.udbforums.org/index.php/Instance_template#reset_delay )

If this value is 0, the reset_delay is taken from the DBC.

This reset_delay is multiplied by the entry Rate.InstanceResetTime in the config file.

In any case, the minimum reset_delay is 1 day.

=> if you happen to have 49708d, I suspect that the entry in your db is not correct.

BTW, The entry Instance.ResetTimeHour of the config file determines the hour when the reset occurs (default: 4)

The next resettime for each instance is stored in table characters.intance_reset.

=> If you change the reset_delay of an instance, don't forget to update the resettime in characters.instance_reset and set the resettime to 0. This will force a reset of the instance at the next reboot and a new computation of the next reset time. If you don't update that resettime, it will be recompute only at the next reset time (for you, in 49708 day )

The bind to instance is also only DB related. The bind is only done IF the flags_extra of the creature_template contains the flag CREATURE_FLAG_EXTRA_INSTANCE_BIND

(see http://wiki.udbforums.org/index.php/Creature_template#flags_extra). Without this, you have no binding of the player to the instance ID. This flag shall be set for every boss of the instances.

[oc_redfox]

@Trazom

Err...

The 49708d thing is related to the DB table 'instance_reset' (just clean it and that goes away),

But the problem im talking about is;

Lets say you do a instance that should have 7 days reset, you get bound and everything looks normal.. You then do a instance with 1-day reset.. BOTH those instances will unbind after 1day then...

And i have tried with both 0 and 7 in the reset_delay field...

[Espec]

And what global reset all raids and heroic modes?

[ProjectX]

Im 100% sure this hapenss when the new global reset time for the instance is calculated and it depends on type of dungeon

heroic dungeons are recalculated after 1 day, 3-day dungeons are recalculated after 3 days and etc, normal dungeons has own reset time so they are ok

our global reset time is set on 4:00 AM ( btw i was watching it minute after minute , 3:59:00 AM - 1 minute left to reset, 4:00:00 AM - all ok, 4:00:01 AM - new reset time is calculated and is set to 49k days and etc )

[zhenya`]

after restart server it would be fixed... i catch this with uptime > 2 days

[Gwenny]

Bug still exist. heroic instance reset timers = 49708 days...

Mangos rev 8402.

In db the reset time is set to 0 (so its taken from dbc). After server restart and cleaning instance_reset table it works till it should unbind the instance id at 4 am.

I think there is a problem at unbinding instance id, so the time will not updated when it should unbind the ids.

Is there any solution for this? :confused:

[Wowka321]

Bug still exist. heroic instance reset timers = 49708 days...

Mangos rev 8402.

In db the reset time is set to 0 (so its taken from dbc). After server restart and cleaning instance_reset table it works till it should unbind the instance id at 4 am.

I think there is a problem at unbinding instance id, so the time will not updated when it should unbind the ids.

Is there any solution for this? :confused:

Delete post...

[imblizzspy]

The whole system should be a bit rewritten to match 3.2.0 changes I guess.

[Gwenny]

Found this on mangos.ru:

TRUNCATE `character_instance`;

TRUNCATE `groups`;

TRUNCATE `group_instance`;

TRUNCATE `group_member`;

TRUNCATE `instance`;

TRUNCATE `instance_reset`;

I will test if the server unbind the ids and generate the new reset time correctly, but i dont think so ^^

Edit: Stil not working

[MArtemis]

Same problem using trinitycore.

This patch fixes it for trinity; should also work for mangos, i guess.

(Fix ported to mangos, not tested)

diff --git a/src/game/InstanceSaveMgr.cpp b/src/game/InstanceSaveMgr.cpp
index c194624..15344ae 100644
--- a/src/game/InstanceSaveMgr.cpp
+++ b/src/game/InstanceSaveMgr.cpp
@@ -612,6 +612,11 @@ void InstanceSaveManager::_ResetOrWarnAll(uint32 mapid, bool warn, uint32 timeLe
        uint64 next_reset = ((now + timeLeft + MINUTE) / DAY * DAY) + period + diff;
        // update it in the DB
        CharacterDatabase.PExecute("UPDATE instance_reset SET resettime = '"UI64FMTD"' WHERE mapid = '%d'", next_reset, mapid);
+
+        // schedule next reset.
+        m_resetTimeByMapId[mapid] = (time_t) next_reset;
+        ScheduleReset(true, (time_t) (next_reset - 3600), InstResetEvent(1, mapid));
+
    }

    MapInstanced::InstancedMaps &instMaps = ((MapInstanced*)map)->GetInstancedMaps();

[ANTOMA]

Same problem using trinitycore.

This patch fixes it for trinity; should also work for mangos, i guess.

(Fix ported to mangos, not tested)

diff --git a/src/game/InstanceSaveMgr.cpp b/src/game/InstanceSaveMgr.cpp
index c194624..15344ae 100644
--- a/src/game/InstanceSaveMgr.cpp
+++ b/src/game/InstanceSaveMgr.cpp
@@ -612,6 +612,11 @@ void InstanceSaveManager::_ResetOrWarnAll(uint32 mapid, bool warn, uint32 timeLe
        uint64 next_reset = ((now + timeLeft + MINUTE) / DAY * DAY) + period + diff;
        // update it in the DB
        CharacterDatabase.PExecute("UPDATE instance_reset SET resettime = '"UI64FMTD"' WHERE mapid = '%d'", next_reset, mapid);
+
+        // schedule next reset.
+        m_resetTimeByMapId[mapid] = (time_t) next_reset;
+        ScheduleReset(true, (time_t) (next_reset - 3600), InstResetEvent(1, mapid));
+
    }

    MapInstanced::InstancedMaps &instMaps = ((MapInstanced*)map)->GetInstancedMaps();

not working or working wrong - reset always after 24hrs

[MArtemis]

not working or working wrong - reset always after 24hrs

This patch only addresses the problem of extremely large reset times (> 4000 days).

If the reseting of the 1 day instances resets all instances regardless of their reset-delay this is another bug, which is unrelated to this patch.

[NetSky]

this fix does not work with mangos i already did take a look at it when trazom posted it at their forums

[ascent]

move up! not fix 9832