[7.x] Conditions for phase area under zone are not executed

[Lopfest]

Description: conditions for area phases are ignored when there is a phase for whole zone

Current behaviour: phase area conditions are not checked at all, when there is an entry in phase_area for whole zone and you make condition only for specific area under that zone. Even if you have condition in DB, the core evaluates it always like following:

bool ConditionMgr::IsObjectMeetToConditions(ConditionSourceInfo& sourceInfo, ConditionContainer const& conditions) const
{
    if (conditions.empty())
        return true;          <------
    ...
}

Function void WorldObject::UpdateAreaAndZonePhase() is not passing any phase.Conditions argument here if (sConditionMgr->IsObjectMeetToConditions(this, phase.Conditions))

EDIT: I have found out in DBErrors.log that this kind of condition is not even loaded on server startup
[Condition SourceType: 26 (Phase), SourceGroup: 1329, SourceEntry: 5848] Area 5848 does not have phase 1329.

Expected behaviour: evaluate every existing phase_area condition when you have zoneId (not areaId) in phase_area and condition only for area within that zone.
Below code needs to be changed, so it checks also areas within entered zoneId.

// condition loading helpers
std::vector<PhaseInfoStruct>* GetPhasesForAreaOrZoneForLoading(uint32 areaOrZone)
{
    auto itr = _phases.find(areaOrZone);
    return itr != _phases.end() ? &itr->second : nullptr;
}

Aditionally, switch cond->SourceGroup, cond->SourceEntry to cond->SourceEntry, cond->SourceGroup in TC_LOG_ERROR("sql.sql", "%s Area %u does not have phase %u.", cond->ToString().c_str(), cond->SourceGroup, cond->SourceEntry); because it is now vice-versa.

Steps to reproduce the problem:

1. create phase for zone
2. restrict this phase in specific area with condition
3. enter the area when condition should apply= condition is not working

Sample SQL:

DELETE FROM `phase_area` WHERE `AreaId`=5736 AND `PhaseId`=1329;
INSERT INTO `phase_area` (`AreaId`, `PhaseId`, `Comment`) VALUES
(5736, 1329, 'The Wandering Isle - see creatures');

DELETE FROM `conditions` WHERE `SourceTypeOrReferenceId`=26 AND `SourceGroup`=1329 AND `SourceEntry`=5848;
INSERT INTO `conditions` (`SourceTypeOrReferenceId`, `SourceGroup`, `SourceEntry`, `SourceId`, `ElseGroup`, `ConditionTypeOrReference`, `ConditionTarget`, `ConditionValue1`, `ConditionValue2`, `ConditionValue3`, `NegativeCondition`, `ErrorType`, `ErrorTextId`, `ScriptName`, `Comment`) VALUES
(26, 1329, 5848, 0, 0, 9, 0, 29414, 0, 0, 1, 0, 0, '', 'Cave of Meditation Phase 1329 when Quest 29414 not taken');

.go xyz 1189 3452 103

Branch(es): master

TC rev. hash/commit: 725208d

TDB version: 703.00

Operating system: Windows 7 x64

[funjoker]

For me the condition doesn't fit with the phase_area entry.

INSERT INTO `phase_area` (`AreaId`, `PhaseId`, `Comment`) VALUES
(**5736**, 1329, 'The Wandering Isle - see creatures');

INSERT INTO `conditions` (`SourceTypeOrReferenceId`, `SourceGroup`, `SourceEntry`, `SourceId`, `ElseGroup`, `ConditionTypeOrReference`, `ConditionTarget`, `ConditionValue1`, `ConditionValue2`, `ConditionValue3`, `NegativeCondition`, `ErrorType`, `ErrorTextId`, `ScriptName`, `Comment`) VALUES
(26, 1329, **5848**, 0, 0, 9, 0, 29414, 0, 0, 1, 0, 0, '', 'Cave of Meditation Phase 1329 when Quest 29414 not taken');

[Lopfest]

@funjoker ... 5736 is zone ID of wandering isle, 5848 is area ID within wandering isle - Cave of Meditation. Condition is OK.

[funjoker]

Condition needs an Entry in phase_area too.
If there is no phase_area entry with Area and Phase the Condition is ignored.

Actually you should be allways in Phase 1329 no matter if quest is taken or not.

Add this and tell me what happens.

INSERT INTO `phase_area` (`AreaId`, `PhaseId`, `Comment`) VALUES
(5848, 1329, 'Cave of Meditation - Phase 1329');

[Lopfest]

Actually you should be allways in Phase 1329 no matter if quest is rewarded or not.

Exactly, thas't how it works now. And it's wrong.
As I said, this was already working on WoD, MitchesD made it possible to create conditions like this back then.
Btw, this extract of code is nothing new that I just created. It is in my old PR for months, and it has been tested. I tested it again few days ago on Legion, and it's not working anymore as expected.

[funjoker]

Well i keep working with old Phasing logic.
They working perfectly.
Atlassian isn't even updated thought :/

[funjoker]

I would also change phase_area column areaid to AreaOrZoneId.
And then making Areas positive and Zones negative.

[Lopfest]

Column name change might be helpful for others I agree, but making positive and negative numbers was not necessary since areaId and zoneId are unique numbers.

[funjoker]

It's not because of unique problem. It's about to see directly that this phase is for Zone or Area only.

[Lopfest]

root cause found, description updated