Skip to content

EventMatching

VersionStatus
v92Full
v90-
v86-

EventMatching defines the activity finder system: matchable events (dungeons, battlefields, field content), reward schedules, achievements, timeline scheduling, and UI configuration. All data resides in a single EventMatching.xml file with 7 logical entity handlers operating on different sections of the same document.


EventMatching is split across 9 DSL sections, each targeting a different part of the XML structure:

SectionPurposeOperationsReference
eventMatchingEventsMatchable event entriesCRUD, upsertEvents
eventMatchingRewardsDaily/weekly bonuses and limitsupdateRewards
eventMatchingAchievementsAchievement entriesCRUD, upsertConfig
eventMatchingTimelineDay/time schedulingcreate, deleteConfig
eventMatchingSettingsRoot and singleton settingsupdateConfig
eventMatchingFiltersUI filter entriescreate, deleteConfig
eventMatchingDefaultImagesDefault event imagesupdateConfig
eventMatchingContentBannerBanner event listscreate, configConfig
eventMatchingPlayGuidePlay guide UI links and tipscreate, update, deleteConfig

File organization: SingleFile — all entities share EventMatching.xml


eventMatchingEvents:
create:
- eventId: 800100
group: priority
type: Dungeon
questId: 800100
categoryId: 800100
active: true
requiredItemLevel: 446
action:
type: matching
targets:
- id: "9088"
rewards:
- type: exp
templateId: 20000001
amount: 551744
eventMatchingRewards:
dailyBonuses:
update:
- completeCount: 16
minLevel: 65
maxLevel: 70
rewards:
- type: item
templateId: 367
amount: 5
itemRewardMaxCount:
normal: 12
additional: 10
weekly: 8
daily: 8
eventMatchingTimeline:
create:
- day: all
eventId: 800021
openTime: 1200
closeTime: 2400
eventMatchingSettings:
root:
beginLevel: 10
compensationReceivedCountResetTime: "0500"
equipmentGuide:
targetItemLevel: 412

EventMatching.xml
└── EventMatching (root)
├── EventGroup (isSpecialCompensation="false") [priority]
│ └── Event [multiple] ← eventMatchingEvents
│ ├── Action
│ ├── TargetList
│ │ └── Target [multiple]
│ └── CompensationList
│ └── Compensation [multiple]
├── EventGroup (isSpecialCompensation="true") [secondary]
│ └── Event [multiple]
├── DailyBonusList ← eventMatchingRewards
│ └── DailyBonus [multiple]
│ └── CompensationList
│ └── Compensation [multiple]
├── AdditionalReward ← eventMatchingRewards
│ └── CompensationList [multiple]
│ └── Compensation [multiple]
├── CompleteLimitPerDay ← eventMatchingRewards
│ └── Setting [multiple]
├── ItemRewardMaxCount ← eventMatchingRewards
├── MissionAchievementList ← eventMatchingAchievements
│ └── Achievement [multiple]
├── TimeLine ← eventMatchingTimeline
│ └── EnableDay [multiple]
│ └── EnableTime [multiple]
├── EventFilter ← eventMatchingFilters
│ └── Filter [multiple]
├── DefaultEventImage ← eventMatchingDefaultImages
│ └── DefaultImage [multiple]
├── ContentBanner ← eventMatchingContentBanner
│ └── EventList [multiple]
│ └── Event [multiple]
├── EquipmentGuide ← eventMatchingSettings
├── ReputationStoreTeleport ← eventMatchingSettings
├── PlayGuideQuestNotice ← eventMatchingSettings
└── PlayGuideUI ← eventMatchingPlayGuide
├── Link [multiple]
├── Event [multiple]
└── Tip [multiple]

  • Single file, multiple handlers: All 9 DSL sections modify the same EventMatching.xml file. The pipeline routes each operation to the correct handler based on entity type.

  • Event groups: Events are split into two EventGroup elements by isSpecialCompensation. The DSL uses group: priority (false) and group: secondary (true) as the human-readable selector.

  • Update and delete require group: When updating or deleting events, you must specify group alongside eventId so the handler finds the correct EventGroup.

  • Singleton elements: Settings, EquipmentGuide, ReputationStoreTeleport, PlayGuideQuestNotice, and ItemRewardMaxCount are singleton elements — updates target them directly without an ID.

  • Reward mail defaults: When rewards are specified without explicit mail fields, defaults are applied: @EventMatching:2001 (sender), @EventMatching:2002 (title), @EventMatching:2003 (body).

  • Timeline composite key: EnableTime entries are identified by the composite key day + eventId + openTime. Deletes must specify all three.