CQ_Action Guide

Eudemons Online `cq_action` Table Guide

Welcome to the ultimate guide for understanding the cq_action table used in Eudemons Online private servers. This table plays a critical role in controlling game behavior — from NPC dialogs and item rewards to experience gains, system messages, and conditional logic.

Whether you’re new to EO development or looking to refine your scripting skills, this guide will walk you through:

The purpose and structure of the cq_action table
Common type codes and how they work
Practical examples like giving items, showing NPC dialogs, and triggering system messages
Tips for chaining actions using id_next and handling conditions with id_nextfail

All content is written clearly and includes real-world examples to help you build, debug, and expand your server’s functionality faster.

⚙️ Built by the EO dev community — for the EO dev community.

Explore the sections below and level up your EO server customization!

What is cq_action?
Field Explanations
Common Action Types
Type Explaination Download
Action Type Guides

What is `cq_action`?

Alt text

The cq_action table controls sequences of actions triggered in-game — like when you click an NPC, receive an item, or complete a quest. It uses an ID-based flow system with support for conditions and multiple outcomes.

Field Explanations

INSERT INTO `cq_action` (`id`, `id_next`, `id_nextfail`, `type`, `data`, `param`) VALUES (1000, 0000, 0000, 0501, 810007, '');

Field	Description
`id`	Unique action ID
`id_next`	Next action if success/condition true
`id_nextfail`	Next action if condition fails
`type`	Type of action (dialog, give item, etc.)
`data`	Depends on type (item ID, message ID, etc.)
`param`	Usually contains message text or command

Common Action Types

Type Code	Description
`0101`	NPC Dialog Text
`0102`	NPC Options (buttons)
`0125`	System Announcement (Global)
`0126`	System Tip (Local)
`501`	Give Item
`1001`	Give EXP, Money, Stones

Download Full Action Types

You can download the full explanation of action types here.

Download Here

Action Type Guides

✅ Tip:
Old Engine = 3-class system (2008)
➤ Reference: 2008 Release (Mannequin DB)

New Engine = 9-class system with new features (2022)
➤ Reference: 2022 Release (v1655 Engine)

🗨️ Create Dialog (Type 101, 102, 104 and 120)

This action shows a dialog when the player interacts with an NPC or item.

💡 Example SQL:

REPLACE INTO `cq_action` VALUES (1001, 1002, 0000, 0101, 0, 'I can sell it only for an hour every day.');
REPLACE INTO `cq_action` VALUES (1002, 1003, 0000, 0101, 0, 'Do you want to give it a go?');
REPLACE INTO `cq_action` VALUES (1003, 1004, 0000, 0102, 0, 'Just~one,~please. 1007');
REPLACE INTO `cq_action` VALUES (1004, 1005, 0000, 0102, 0, 'Sorry,~but~I~dont~need~it. 0');
REPLACE INTO `cq_action` VALUES (1005, 1006, 0000, 0104, 0, '0 0 34');
REPLACE INTO `cq_action` VALUES (1006, 0000, 0000, 0120, 0, '');

🧾 Required Task Entries (cq_task)

REPLACE INTO `cq_task` VALUES (1001, 1001, 0000, '', '', 0, 0, 999, -100000, 100000, 0999, 0000, 0, -1, 0);
REPLACE INTO `cq_task` VALUES (1007, 1007, 0000, '', '', 0, 0, 999, -100000, 100000, 0999, 0000, 0, -1, 0);

📘 Explanation Table:

Type	Purpose	param Explanation
`101`	Show dialog text	NPC or item dialog string (≈ 40–45 chars per line)
`102`	Dialog options / buttons	Text ~ spacing + task_id (use `0` for close)
`104`	Dialog face image	x y pic_id — from Ani/NpcFace.ANI (e.g. Face34)
`120`	End of dialog	(none)

💡 Tips:

Every type 101 must have a corresponding cq_task entry
Every task_id used in type 102 must also exist in cq_task
Use ~ for spacing inside all dialog text and option strings
Use 0104 to show NPC face image (optional)
End your dialog with 0120 to ensure it closes cleanly

🔧 Reminder: If the dialog doesn't show or options do nothing, double check your cq_task entries!

💠 Modern NPC Dialog (Type 132 & 133)

⚠️ New Engine Only

This dialog system creates stylish, story-driven NPC interactions with portrait images, background panels, and up to 4 interactive options.This feature is only available on the 🆕 New Engine.

🖼️ Example: Linleria Dialog

📜 Linleria SQL

REPLACE INTO cq_action VALUES (1001, 1002, 0000, 0101, 0, 'Hello~i`am~Linleria~the~designer,~do~you~have~enough~essence~to~trade~off~with~these~cosmetic~items?');
REPLACE INTO cq_action VALUES (1002, 1003, 0000, 0102, 0, 'Yes,send~me~there. 1006');
REPLACE INTO cq_action VALUES (1003, 1004, 0000, 0102, 0, 'Close. 1005');
REPLACE INTO cq_action VALUES (1004, 0000, 0000, 0132, 0, '0 Tasksystem_GeneralbotPic Linleria 0 Tasksystem_WnbeishangPic');
REPLACE INTO cq_action VALUES (1005, 0000, 0000, 133, 0, '');

`Linleria`: Displayed name (customizable)
`Tasksystem_GeneralbotPic`: Dialog background (default, don’t change)
`Tasksystem_WnbeishangPic`: Portrait image (can change, from control.ani)
Image preview path: data/interface/style01/Tasksystem/God/WnbeishangPic.dds

🖼️ Example: Skuld Dialog

📜 Skuld SQL

REPLACE INTO cq_action VALUES (1001, 1002, 0000, 0101, 0, 'Do~You~see~the~Sword~there?~This~sword~is~belong~to~King~of~the~Four~Seas.~I~need~your~help~to~stop~him. sound/dice_move.wav');
REPLACE INTO cq_action VALUES (1002, 1003, 0000, 0102, 0, 'I~am~going~to~absorb~the~energy. 1006');
REPLACE INTO cq_action VALUES (1003, 1004, 0000, 0102, 0, 'Close. 1005');
REPLACE INTO cq_action VALUES (1004, 0000, 0000, 0132, 0, 'Novice_BottomBG Novice_RolePic 21650');
REPLACE INTO cq_action VALUES (1005, 0000, 0000, 0133, 2, '');

`Novice_BottomBG`: Background (default)
`Novice_RolePic`: NPC portrait name (can change, from control.ani)
Image preview path: data/interface/style01/Rookie/RolePic.dds
`21650`: NPC label ID (used for Skuld style)

⚠️ Important Notes

Maximum 4 options (0102) per dialog
One option must be a Close (linked to type 133)
Use ~ instead of spaces in all dialog lines or they won't display!
Type 132 requires the player to be very close to the NPC (within ~5 tiles)
An NPC object is required — dialog won’t trigger if no valid NPC is nearby
type 133 must use data = 2 to allow proper closing for some UIs
Supports ambient sound: add file at end of param like sound/dice_move.wav (Skuld dialog only!)

💡 Tip: All dialog lines and button text must use ~ instead of spaces. Example:
Hello~brave~warrior! ✅ Hello brave warrior! ❌

🎁 Sent Items (Type 501, 525, 540, 550)

Sends specific items to the player when triggered. Used for quest rewards, shop systems, monster drops, and more.

📜 Basic Example – Type 501 (Give Item)

-- Give 1 item (basic)
REPLACE INTO cq_action VALUES (1000, 1002134, 0000, 0501, 754826, '');

📜 Custom Stats – Type 501

-- With custom stats (Old Engine)
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0501, 1081990, '0 0 0 0 0 0 0 0 0 0 0 0 1');

-- Old Engine Params:
amount amount_limit ident gem1 gem2 magic1 magic2 magic3 data warghostexp gemtype availabletime MONOPOLY

-- With custom stats (New Engine)
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0501, 1081990, '0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0');

-- New Engine Params:
amount amount_limit ident gem1 gem2 magic1 magic2 magic3 data warghostexp gemtype availabletime MONOPOLY
eudemon_attack1 eudemon_attack2 eudemon_attack3 eudemon_attack4 special_effect Gem3 GodExp prescription

📌 Special Variants:

-- Type 501 (New Engine): Give Necro Eudemon Egg
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0501, 1081610, '1');

-- Notes:
When giving a Eudemon Egg (e.g., 1081610), setting the first param to 1 marks it as a Necro Eudemon.
This applies only in the New Engine and only for specific Necro Eudemon egg items.

-- Type 525 (New Engine Only): Same as 501 but "availabletime" becomes "aging days".This type can only be used for 820xxxx items only.
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0525, 820646, '0 0 0 0 0 0 0 0 0 0 0 30');
-- 30 = 30 days

-- Type 540 (Both Engines): Modifies stackable item count
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0540, 1020171, 'amount += 1');

-- Notes:
Supports: +=, -=, =, >, <, >=, <=
Can also be used to remove items: 'amount += -1'
Only works for stackable items
Recommended for adjusting count instead of deleting via 502

-- Type 550 (New Engine Only): Same as 501 but with client-side display effect
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0550, 1600261, '');

💡 Tips:

Use type 503 to check item count before giving or removing
540 is more flexible and safer than deleting stackable items with 502
To show visual reward feedback, use 550 (New Engine only)
525 is useful for timed items like trial gear or events

✅ Type 540 works in both Old and New Engine. Use it for adjusting stackable item amounts, both add and subtract.

🗑️ Delete Item (Type 502)

Type 502 is used to remove one or more items from the player’s inventory based on type or name.

📦 Syntax Behavior

data = ItemTypeID (or 0 to match by name)
param = quantity or item name (if using data = 0)
Use id_nextfail to handle missing items or not enough quantity

📜 Example: Delete Single Quantity by Item Type

REPLACE INTO cq_action VALUES (1001, 1003, 1002, 0502, 1020030, '1 1');
REPLACE INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'You don`t have enough item.');

📜 Example: Delete Stack of Items

REPLACE INTO cq_action VALUES (1001, 1003, 1002, 0502, 810002, '10');
REPLACE INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'You don`t have enough item.');

📜 Example: Delete Unstackable Items (Repeat Action)

-- Delete 2x [ItemID: 111006] if item is NOT stackable
REPLACE INTO cq_action VALUES (1001, 1002, 1003, 0502, 111006, 0);
REPLACE INTO cq_action VALUES (1002, 1004, 1003, 0502, 111006, 0);
REPLACE INTO cq_action VALUES (1003, 0000, 0000, 0126, 0, 'You don`t have enough item.');

📜 Example: Delete Items by Name

-- Delete 2x "Blue Crest Helmet" by item name
REPLACE INTO cq_action VALUES (1001, 1002, 1003, 0502, 0, 'Blue~Crest~Helmet');
REPLACE INTO cq_action VALUES (1002, 1004, 1003, 0502, 0, 'Blue~Crest~Helmet');
REPLACE INTO cq_action VALUES (1003, 0000, 0000, 0126, 0, 'You don`t have enough item.');

✅ For Stack Items: Use `Type 540` (Recommended)

-- Safely subtract 5x stackable item (e.g., EXP Scroll)
REPLACE INTO cq_action VALUES (1001, 0000, 0000, 0540, 1020116, 'amount += -5');

💡 Best Practice:

Use type 503 to check quantity before deleting items
Use type 0126 to notify player if the item is missing
For stack items, type 540 is cleaner and more reliable

⚠️ Reminder: For non-stackable items, repeat type 502 multiple times to match how many you want to delete.

🔍 Check Item (Type 503)

Type 503 is used to check if a player has a specific item, with optional quantity/durability validation.

📦 Syntax Behavior

data = ItemTypeID (or 0 for name-based check)
param = quantity or full item name (if data = 0)
If only checking existence (not quantity), set param = 0
If item is missing or quantity is not enough → goes to id_nextfail

📜 Example 1: Check If Player Has 5x of Item

-- Check if player has at least 5x of ItemTypeID 111007
REPLACE INTO cq_action VALUES (0001, 0002, 0003, 0503, 111007, 5);

-- Success
REPLACE INTO cq_action VALUES (0002, 0000, 0000, 0126, 0, 'You have this item');

-- Failure
REPLACE INTO cq_action VALUES (0003, 0000, 0000, 0126, 0, 'You don`t have this item');

📜 Example 2: Check If Player Has Item (No Quantity Required)

REPLACE INTO cq_action VALUES (0001, 0002, 0003, 0503, 111007, 0);
REPLACE INTO cq_action VALUES (0002, 0000, 0000, 0126, 0, 'You have this item');
REPLACE INTO cq_action VALUES (0003, 0000, 0000, 0126, 0, 'You don`t have this item');

📜 Example 3: Check by Item Name

REPLACE INTO cq_action VALUES (0001, 0002, 0003, 0503, 0, 'Blue~Crest~Helmet');
REPLACE INTO cq_action VALUES (0002, 0000, 0000, 0126, 0, 'You have this item');
REPLACE INTO cq_action VALUES (0003, 0000, 0000, 0126, 0, 'You don`t have this item');

💡 Notes:

Item name matching must be same with cq_itemtype
This type is often used before type 502 to verify quantity before removing
Very useful for quest checking, crafting checks, and condition-based actions

💡 Tip: Always use id_nextfail for fallback messaging.

⚙️ Modify Player Attributes (Type 1001)

This action modifies or checks player attributes using logic like +=, ==, <, etc.

💡 Example SQL:

INSERT INTO `cq_action` VALUES (1000, 0000, 0000, 1001, 0, 'e_money += 13500');  // add
INSERT INTO `cq_action` VALUES (1000, 0000, 0000, 1001, 0, 'e_money += -13500'); // remove

📘 Supported Attributes & Operators:

life, mana, money, exp, pk, energy(stamina) — (+=, ==, <)
xp, nob_rank_donate — (+=)
profession — (==, set, >=, <=)
level, force, dexterity, speed, health, soul — (+=, ==, <)
rank, rankshow — (==, <)
iterator — (=, <=, +=, ==)
crime — (==, set)
gamecard, gamecard2, totalbattlelev — (==, >=, <=)
metempsychosis — (==, <)
mercenary_rank, mercenary_exp, exploit — (==, <, +=)
maxlifepercent — (+=, ==, <)
tutor_exp, tutor_level — (==, <, +=, =)
eudemon_boord_size — (==, <, +=, =)
syn_proffer, maxeudemon, soul_value — (<, +=, =)
ahlife — (-=)
moonmoney, starmoney — (==, +=, <>)
BftitlePlaneid — (==, +=, =)
DstitleId — (==, <)
crystalmoney, honourmoney, olggodmoney — (+=, <, ==)
energy — (<, +=, =)
goddesspoint — (==, <, +=)
godexp — (+=, ==, <)
exp_percent, godexp_percent — (+=)

🧠 Most attributes use += to add, == to compare, and < to check thresholds.

⚠️ Note: Only some attributes are available in the old engine.
Refer to your cq_user or cq_user_new table to verify which fields are available in your version.

📌 Old Engine: cq_user
🆕 New Engine: cq_user_new

🎲 Random Chance & Random Action (Type 121 & 122)

These types allow you to introduce randomness into your server logic:

Type 121 – Checks if a random chance is successful (e.g., 20% chance to win)
Type 122 – Randomly selects and executes one of 8 possible actions

🎯 Type 121 – Random Chance

param format: "chance total"

INSERT INTO cq_action VALUES (1000, 1001, 1002, 0121, 0, '20 100');
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'succeed');
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'fails');

This means: 20 out of 100 (20%) chance of success.

If the check succeeds, it continues to id_next (1001)
If the check fails, it continues to id_nextfail (1002)

🔀 Type 122 – Random Action Select

param format: "action0 action1 action2 ... action7"

INSERT INTO cq_action VALUES (1000, 0000, 0000, 0122, 0, '1001 1002 1003 1004 1005 1006 1007 1008');

This means: randomly choose ONE action ID from the list above.
Each ID must refer to a valid cq_action that will be executed.

🧠 Tip: You can repeat the same ID multiple times to increase its chance of being selected.
Example: '1001 1001 1001 1002 1002 1003 1004 1005'
This gives 1001 a higher weight than the others (appears 3 out of 8).

💡 Use Case: type 121 is great for chance-based triggers (e.g. success/failure), while type 122 is ideal for random branching events, rewards, or NPC reactions.

💬 Message Box (Type 126)

Type 126 displays a simple message box popup on the client with a YES button. It is for informational purposes only — it does not execute any action on click.

🖼️ Example Output:

💡 Example SQL:

INSERT INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'Your text here.');

📌 Notes:

param: The message to display. Spaces are allowed — you do not need to use ~.
Text limit: Keep your message short and concise. Long messages will overflow or be cut off.
Useful for showing warnings, notifications, or short instructions.

📢 Broadcast Message (Type 125)

Type 125 sends system-wide broadcast messages across different UI locations depending on the data value (channel type).

💡 Example SQL:

-- Top-left corner (Old & New Engine)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0125, 2005, 'Your text here');

-- Center screen classic popup (Old & New Engine)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0125, 2011, 'Your text here');

-- Bottom-left in chat (New Engine only)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0125, 2007, 'Your text here');

-- Center screen modern popup (New Engine only)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0125, 2024, 'Your text here');

📸 Broadcast Styles:

Channel	Location	Engine
`2007`	Bottom-left (chat area)	New Engine Only
`2005`	Top-left system notice	Old & New Engine
`2024`	Modern popup (center screen)	New Engine Only
`2011`	Classic popup (center screen)	Old & New Engine

💡 Tip: Choose data based on how visible the message should be.
Use 2007 for chat-style messages, 2024 for clean centered alerts.

💡 Local System Message (Type 1010)

Type 1010 is used for sending client-side local messages, popups, and web links. The display behavior is defined by the data (channel) value.

💡 Example SQL:

-- Local chat system notice
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1010, 2000, 'Your text here.');

-- Modern pop-up (new engine only)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1010, 2024, 'You`ve arrived in Forgotten Realms');

-- Web link
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1010, 2105, 'http://www.google.com');

📘 Message Channels (data values):

Data	Channel	Message Example
`2000/2007`	System Chat Channel	Welcome to Knightfall.
`2001`	Whisper Chat Channel	Announcer: reminder has end.
`2002`	[Action] Chat Channel	Eliminate 16 Elite monsters.
`2003`	Team Chat Channel	%user_name has used Double EXP Potion.(your teammate cannot see this.)
`2023`	Boss Chat Channel	King MadBull has Appear!
`2025`	Help Chat Channel	You don't have enough gold.
`2005`	Top-left Notice	You learned Tornado Skill.
`2011`	Center Screen - [System]	You donated 1000 HP and the Hatred Wraith revived!
`2024`	Modern Popup (New Engine)	You’ve arrived in Cronus
`2105`	Open Web Link	`http://www.google.com`

⚠️ Behavior Notes:

All messages are local (only visible to the player)
data 2105 will immediately open the provided web URL
Text limits apply to some channels; keep messages concise

💡 Tip: Use type 1010 for immersive local feedback like quests, status effects, zone tips, or helper links — without global broadcast noise.

🎒 Check Inventory Space (Type 508)

Type 508 checks if the player has enough remaining space in a specific inventory bag. If not enough space is available, it goes to id_nextfail.

🧠 param format:

required_space weight pack_type

required_space: Number of free slots needed
weight: Usually 0 (reserved for future logic)
pack_type: Type of inventory bag to check

📦 Supported `pack_type` Values:

Pack Type	Description	Engine
`50`	Common item bag (main backpack)	✅ Old & New Engine
`52`	Eudemons Egg bag	✅ Old & New Engine
`53`	Eudemons Inventory	✅ Old & New Engine
`46`	Quest item bag	🆕 New Engine Only
`47`	Material item bag	🆕 New Engine Only
`43`	Divine Fire item bag	🆕 New Engine Only

🧭 Compatibility Summary:
✅ Old Engine: 50, 52, 53
🆕 New Engine: 46, 47, 43, 50, 52, 53

💡 Example Usage:

-- Check 1 slot in main backpack
INSERT INTO cq_action VALUES (1000, 1002, 1001, 0508, 0, '1 0 50');
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Your backpack is full!');
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0501, 191740, '');

-- Check 1 slot in egg bag
INSERT INTO cq_action VALUES (1000, 1002, 1001, 0508, 0, '1 0 52');
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Your egg bag is full.');
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0501, 1083060, '');


-- Check 1 slot in Eudemon Inventory
INSERT INTO cq_action VALUES (1000, 1002, 1001, 0508, 0, '1 0 53');
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You need 1 free space in your inventory.');
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0526, 0, '');

💡 Tip: Always use type 126 to show user-friendly messages when space is insufficient.

⏰ Check Time (Type 123)

Type 123 checks the current server time using various time-based formats. It can be used to limit actions to certain dates, times, or days of the week.

🧠 param format:

Depends on data (0 to 6) – see formats below

📆 Supported Time Types (`data` values):

Data	Format	Example	Description	Engine
`0`	`%d-%d-%d %d:%d %d-%d-%d %d:%d`	2024-04-01 10:00 2024-04-01 18:00	Full date & time range	Old & New
`1`	`%m-%d %H:%M %m-%d %H:%M`	04-01 09:00 04-01 17:00	Month-day with time range	Old & New
`2`	`%d %H:%M %d %H:%M`	15 10:00 15 12:00	Day of month with time range	Old & New
`3`	`%d %H:%M %d %H:%M`	2 14:00 2 18:00	Day of week (1=Monday) with time range	Old & New
`4`	`%H:%M %H:%M`	08:00 17:00	Any time of day (daily range)	Old & New
`5`	`%d %d`	10 20	Minute range in current hour	Old & New
`6`	`%d %d %d %d %d %d %d`	0 1 1 0 0 0 0	Day of week (Mon–Sun as 1/0 mask)	🆕 New Engine Only

💡 Examples:

-- Run only from 9 AM to 5 PM daily
INSERT INTO cq_action VALUES (1000, 1002, 1001, 0123, 4, '09:00 17:00');

-- Run only on Tuesday and Wednesday
INSERT INTO cq_action VALUES (1000, 1002, 1001, 0123, 6, '0 1 1 0 0 0 0');

-- Run only from minute 10 to 20 of each hour
INSERT INTO cq_action VALUES (1000, 1002, 1001, 0123, 5, '10 20');

🔗 Reference:

elitepvpers: Time Type Action Guide

🧠 Reminder: Use id_next for when the time check passes and id_nextfail for when it fails.
⚠️ Note: data = 6 (weekday mask) is only supported in the new engine.

📰 Update Announcement Window (Type 130 & 131)

Type 130 displays in-game announcement window (like patch notes or news). It supports multiple lines of text chained via id_next.

🖼️ Example Display:

📜 Example SQL Script:

-- Start of announcement chain
INSERT INTO cq_action VALUES (1000064, 1000065, 0000, 0130, 0, 'Knightfall newest update! Information is showed below:');
INSERT INTO cq_action VALUES (1000065, 1000066, 0000, 0130, 0, 'New class and new features come to Cronus!');
INSERT INTO cq_action VALUES (1000066, 1000067, 0000, 0130, 0, '1.New Class `Star Guardian` and brand new skill!');
INSERT INTO cq_action VALUES (1000067, 1000068, 0000, 0130, 0, '2.Celebrity hall fully fixed and updated.');
INSERT INTO cq_action VALUES (1000068, 1000069, 0000, 0130, 0, '3.Skytower introduced! limit level up to 310 floor!');
INSERT INTO cq_action VALUES (1000069, 1000070, 0000, 0130, 0, '4.Complete demon rising expansion to explore!');
INSERT INTO cq_action VALUES (1000070, 1000071, 0000, 0130, 0, '5.New domain! Get high stats with new talisman');
INSERT INTO cq_action VALUES (1000071, 1000072, 0000, 0130, 0, '6.New divine fire level 85 with latest tomb to conquer');

-- End of announcement
INSERT INTO cq_action VALUES (1000072, 0000, 0000, 0131, 0, '0');

🔧 Usage:

Trigger it when a player enters the game
Each type 130 is one line of text
End the sequence with type 131 to close the window
Max ~7–10 lines for best layout appearance

💡 Tip: Use this for new patch notes, event schedules, server updates, or rules.

🎁 God’s Treasure (Type 188)

⚠️ New Engine Only

Type 188 opens the God’s Treasure spinning interface, where players can draw from 8 randomized rewards. This feature is only available on the 🆕 New Engine.

🖼️ Example Display:

🧠 param format:

ItemID Quantity DisplayActionID RandomWeight

There must be exactly 8 entries, separated by commas.

💰 Pricing:

data = total price (in EP) to Claim All items
Set data = 0 to disable the Claim All button

💡 Example SQL:

-- Open interface (Claim All disabled)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0188, 0, 
'1026624 3 1001 1,
1026625 1 1002 20,
1026624 1 1003 20,
1026624 1 1004 20,
1026625 3 1005 1,
1026626 3 1006 1,
1026626 1 1007 20,
1026626 1 1008 20');

-- Rewards for each draw
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0540, 1026624, 'amount += 3');
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0540, 1026625, 'amount += 1');
INSERT INTO cq_action VALUES (1003, 0000, 0000, 0540, 1026624, 'amount += 1');
INSERT INTO cq_action VALUES (1004, 0000, 0000, 0540, 1026624, 'amount += 1');
INSERT INTO cq_action VALUES (1005, 0000, 0000, 0540, 1026625, 'amount += 3');
INSERT INTO cq_action VALUES (1006, 0000, 0000, 0540, 1026626, 'amount += 3');
INSERT INTO cq_action VALUES (1007, 0000, 0000, 0540, 1026626, 'amount += 1');
INSERT INTO cq_action VALUES (1008, 0000, 0000, 0540, 1026626, 'amount += 1');

📝 Use Case Ideas:

🎯 Boss drops that trigger a lucky spin
🎁 Treasure chests with randomized loot
🐉 RNG rewards from event monsters or world bosses
🧧 Event-based lotteries or login prizes

📌 Parameter Breakdown:

ItemID: The item to show in the gift box
Quantity: How much to display
DisplayActionID: What action runs when claimed
RandomWeight: The higher the number, the easier it is to get. The lower the number, the rarer it becomes (e.g., 1 = rare, 20 = common).

💡 Tip: Combine type 188 with type 121/122 if you want conditional treasure or tiered draw access.

🧾 Temporary Dialog & In-Game Web (Type 189)

⚠️ New Engine Only

Type 189 is used for two purposes depending on the data value:

data = 204: Temporary dialog box (shows for 4–5 seconds)
data = 202: Opens a web browser window in-game (linked to areaid.ini)

💬 Example: Temporary Dialog (data = 204)

INSERT INTO `cq_action` VALUES (1000, 0000, 0000, 0189, 204,
  'Lorem~ipsum~dolor~sit~amet. Tasksystem_GeneralbotPic|1 null -520 30 250 -30 1 Tasksystem_xnhlhxtgwbsx Title~Manager|100|217|1 500 500');

🧩 Parameter Breakdown (dialog format):

Lorem~ipsum~dolor~sit~amet: Dialog content (must use ~ for spacing)
Tasksystem_GeneralbotPic: Background panel (black theme, default)
|1: Unknown, typically set to 1
null: Placeholder for optional elements (e.g., sound/dice_move.wav)
-520 30: X and Y position of the dialog box (X: left/right, Y: up/down)
250 -30: Text position (left/right, up/down)
1: Dialog screen location (1 = center screen, 2 = top right)
Tasksystem_xnhlhxtgwbsx: Portrait (from control.ani)
Title~Manager: Name below portrait (use ~ instead of spaces)
|100: Name X offset (right = bigger, left = smaller)
|217: Name Y offset (down = bigger, up = smaller)
|1: Name alignment/location (guess)
500 500: Unknown values (typically left untouched)

📜 Alternate Example:

INSERT INTO `cq_action` VALUES (1000, 0000, 0000, 0189, 204,
  'Well?~Is~that~the~young~Ranger~who~fought~off~the~enemy~at~the~city~gates~you~are?~Not~bad. Archer_PhoenixPic null -520 30 250 -250 1');

Some portraits already include name overlays and background. Browse: data/interface/style01/Tasksystem/God/

🌐 Example: Open In-Game Website (data = 202)

INSERT INTO `cq_action` VALUES (1000, 0000, 0000, 0189, 202, '6 6');
INSERT INTO `cq_action` VALUES (1000, 0000, 0000, 0189, 202, '8 654');
INSERT INTO `cq_action` VALUES (1000, 0000, 0000, 0189, 202, '9 1396');
INSERT INTO `cq_action` VALUES (1000, 0000, 0000, 0189, 202, '6 4');

🌐 Parameter Breakdown (browser format):

size: Window layout (see chart below)
areaid: Web index (linked to areaid.ini)
Example: URL654 = http://knightfall.my.to/newbie/

📏 Browser Window Sizes:

Size	Dimensions
1	300 × 400
2	400 × 500
3	500 × 600
4	500 × 500
5	580 × 475
6	900 × 650
7	427 × 469
8	820 × 568
9	900 × 650
10	990 × 730
11	905 × 655

⚠️ Note: Make sure the web URL is properly set in your client areaid.ini as URL{areaid}.

🔢 Global Variable Control (Type 191 & 192)

⚠️ New Engine Only

Type 191 and Type 192 are used to manipulate global or session-wide variables stored in cq_vardata and cq_varstrdata respectively.

📌 Type 191 – Numeric Variables (`cq_vardata`)

Used to store and manipulate numbers like counters, flags, or progress markers.

-- Add +1 to variable index 3
INSERT INTO cq_action VALUES (1000, 0000, 0, 191, 0, 'var(3) += 1');

-- Set variable index 3 to 999
INSERT INTO cq_action VALUES (1000, 0000, 0, 191, 0, 'var(3) set 999');

-- Conditional check: If var(3) equals 100
INSERT INTO cq_action VALUES (1000, 1001, 1002, 191, 0, 'var(3) == 100');

Supports: set, +=, /=, *=, ==
For conditional checks, use id_nextfail for failure path

📥 Access value in dialog: %public_var_data3

📤 Show numeric value to player (example):

-- Display value of public_var_data3
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, '%public_var_data3');

📌 Type 192 – Text/String Variables (`cq_varstrdata`)

Used to store names, states, or any string-based logic values.

-- Set string var(3) to "Hello"
INSERT INTO cq_action VALUES (1000, 0000, 0, 192, 0, 'var(3) set Hello');

-- Check if var(3) is "Hello"
INSERT INTO cq_action VALUES (1000, 1001, 1002, 192, 0, 'var(3) == Hello');

Supports: set, ==
Use id_nextfail for string mismatch handling

📥 Access value in dialog: %public_var_str3

📤 Show string value to player (example):

-- Display value of public_var_str3
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, '%public_var_str3');

💡 Tip: Combine with type 101 or 125 for dynamic storytelling or debugging purposes.

🛠️ Check or Modify NPC Attributes (Type 201 & 206)

Type 201 and Type 206 are used to check or modify NPC attributes such as data, datastr, life, lookface, and more. These can apply to both cq_npc and cq_dynanpc tables.

🔁 Type 201 — Check or Modify (Same Thread)

Type 201 is used when the NPC is within the same map or thread. It can check values, compare, or perform operations like +=, pass, etc. This is commonly used to control quest flow or internal NPC states.

📜 Example – Conditional Check:

-- Check if npc.data3 >= 21
INSERT INTO cq_action VALUES (1000, 1001, 1002, 0201, 0, 'data3 >= 21 20257');
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Your data3 is more than 21.');
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Your data3 is less than 21.');

📜 Example – Modify data field:

-- Decrease data1 by 1
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0201, 0, 'data1 += -1 20362');

🧠 Syntax:

attr opt value npc_id (e.g., data3 >= 21 20257)
attr: data0~3, datastr, life, maxlife, ownerid, ownertype, lookface
opt: =, ==, +=, >=, <=, >, <, pass
value: numerical value or string depending on attr

✅ Supported Attributes:

data0 ~ data3, datastr
life, maxlife
ownerid, ownertype, lookface
New Engine only: newdata1 ~ newdata8, newdatastr1 ~ newdatastr2

✅ Tip: Use pass to adjust date/time values ,e.g., data2 pass +3 increases DateStamp by 3 days (Just theory never seen in database).

✏️ Type 206 — Modify Only (Cross Thread)

Type 206 is used when the target NPC is outside the current execution thread (e.g. different map or unrelated script). It can only be used to directly assign values using = (no checking, no math).

📜 Example:

-- Set data0 of npc_id 10018 to 1
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0206, 0, '10018 data0 = 1');

🧠 Syntax:

npc_id attr = value
Only supports = operator

⚙️ Supported Attributes:

data0 ~ data3, datastr, lookface
New Engine only: newdata1 ~ newdata8, newdatastr1 ~ newdatastr2

📜 New Engine Example:

-- Set newdatastr1 to HelloWorld
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0206, 0, '10018 newdatastr1 = HelloWorld');

⚠️ Note: Type 206 is limited to = only. Old Engine only supports data fields (data0~3).

💡 Reminder: For both cq_npc and cq_dynanpc, only datastr, newdatastr1, and newdatastr2 can store letters and numbers (A–Z, 0–9). All other fields must use numeric values only.

🧹 Delete Dynamic NPC (Type 205)

Type 205 is used to delete a dynamic NPC from the map. It only works on NPCs created in cq_dynanpc — not static NPCs from cq_npc. Once deleted, the NPC is permanently removed and cannot be used in any further action steps.

📜 Basic Example:

-- Delete current dynamic NPC
INSERT INTO cq_action VALUES (8410200, 8410201, 0000, 0205, 0, '');

📌 Important Behavior:

Only applies to cq_dynanpc (dynamic NPCs)
Must be placed as the last line in the action chain
Any actions listed after a 0205 will not be executed

🧠 Syntax Options:

data ≠ 0: Deletes all dynamic NPCs with matching type in the current map
param: Can be used to delete by map_id type pair

📜 Map-Wide Delete by Type:

-- Delete all dynanpc with type = 999 in current map
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0205, 999, '');

📜 Delete by Map + Type (New Engine):

-- Delete NPCs of type 888 from map 1002
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0205, 0, '1002 888');

⚠️ Warning: Once this action runs, the dynamic NPC is permanently deleted. Do not add further actions after a 0205 or they will never run.

⚔️ Check Legion War Time (Type 223 & 226)

Type 223 & 226 checks whether the current time is within the configured Legion War period. It's used to control war-based logic like teleportation, dialogue conditions, or reward distribution.

🧠 Behavior:

If war is currently ongoing → goes to id_next
If not within Legion War period → goes to id_nextfail

📜 Example SQL:

-- Check if it's Legion War time
REPLACE INTO cq_action VALUES (1001, 1002, 1003, 0226, 0, '');

-- If war is on
REPLACE INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Legion War is already start');

-- If war is off
REPLACE INTO cq_action VALUES (1003, 0000, 0000, 0126, 0, 'Legion war not started yet');

📌 Use Cases:

NPC war entry control
Trigger different dialogs based on war state
Prevent or allow map teleportation

💡 Tip:

Combine with type 126 to give user-friendly feedback, or teleport (type 1006) if war is active.

🗝️ Clear Warehouse Password (Type 228, 229, 1058)

⚠️ Old Engine Only

These actions manage player warehouse passwords, including checks and clearance. Used for secure item storage systems.

🛡️ Type 228 – Check Warehouse Lock Status

Purpose: Verifies if the warehouse is password-locked before clearance.

Behavior:

If locked → proceeds to id_next (clear password with 229).
If unlocked → jumps to id_nextfail (error message).

📜 Example SQL:

REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0228, 0, '');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Warehouse not locked!');

🗝️ Type 229 – Clear Warehouse Password

Purpose: Removes the warehouse password (requires prior 228 check).

Behavior:

No parameters needed. Always follows 228's id_next.

📜 Example SQL:

REPLACE INTO `cq_action` VALUES (1001, 1003, 0000, 0229, 0, '');

✅ Type 1058 – Confirm Clearance

Purpose: Validates if the password was cleared successfully.

Behavior:

If success → id_next (confirmation message).
If failure → id_nextfail (error message).

📜 Example SQL:

REPLACE INTO `cq_action` VALUES (1003, 1004, 1005, 1058, 0, '');
REPLACE INTO `cq_action` VALUES (1004, 0000, 0000, 0126, 0, 'Password cleared!');
REPLACE INTO `cq_action` VALUES (1005, 0000, 0000, 0126, 0, 'Clearance failed.');

🔗 Full Workflow Example

-- 1. Check lock status
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0228, 0, '');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'No password set.');

-- 2. Clear password
REPLACE INTO `cq_action` VALUES (1001, 1003, 0000, 0229, 0, '');

-- 3. Confirm result
REPLACE INTO `cq_action` VALUES (1003, 1004, 1005, 1058, 0, '');
REPLACE INTO `cq_action` VALUES (1004, 0000, 0000, 0126, 0, 'Success!');
REPLACE INTO `cq_action` VALUES (1005, 0000, 0000, 0126, 0, 'Failed.');

💡 Tip: Chain with type 126 for user feedback. Use id_nextfail rigorously for error handling.

🛒 Exchange Store System (Type 250)

⚠️ New Engine Only

This system allows players to exchange items via NPCs using Type 250 actions and the cq_exchangegoods table.

⚠️ Important:

Type 250 can only be triggered by NPCs, not item packages
The data value must always be 601 for exchange shop interface

🖼️ Exchange Store Interface

📜 Type 250 – Open Exchange Store

Purpose: Opens the exchange store interface.

Parameters:

data: Fixed value 601 (required for interface)
param: Unused (leave empty)

📜 Example NPC Dialog Chain:

REPLACE INTO `cq_action` VALUES (80000000, 80000001, 0, 0101, 0, 'Welcome honored guest. I can exchange various');
REPLACE INTO `cq_action` VALUES (80000001, 80000002, 0, 0101, 0, 'robes for you. A well-crafted robe can enhance');
REPLACE INTO `cq_action` VALUES (80000002, 80000003, 0, 0101, 0, 'your charm. Would you like to choose one?');
REPLACE INTO `cq_action` VALUES (80000003, 80000004, 0, 0102, 0, 'I~want~to~exchange~items. 80000007');
REPLACE INTO `cq_action` VALUES (80000004, 80000005, 0, 0102, 0, 'No~thanks. 0');
REPLACE INTO `cq_action` VALUES (80000005, 80000006, 0, 0104, 0, '10 10 10');
REPLACE INTO `cq_action` VALUES (80000006, 0, 0, 0120, 0, '');
REPLACE INTO `cq_action` VALUES (80000007, 0, 0, 0250, 601, '');

📦 cq_exchangegoods Table Structure

Field	Description
`id`	Unique entry ID
`ownerid`	NPC ID (from `cq_npc` or `cq_dynanpc`)
`itemtype`	Item ID to give
`price`	Quantity of `needitem` required
`needitem`	Item ID required for exchange
`maxcount`	Daily exchange limit (-1 = unlimited)
`RetainField`	Unused (set to 0)

📜 Sample Exchange Data

INSERT INTO `cq_exchangegoods` VALUES
(0001, 1044, 753231, 18, 1020157, -1, 0),  -- Unlimited exchanges
(0002, 1044, 753232, 8, 1025644, -1, 0),
(0003, 1044, 753233, 12, 1025644, -1, 0),
(0004, 1044, 753234, 18, 1020157, -1, 0),
(0005, 1044, 753235, 8, 1025644, -1, 0),
(0006, 1044, 753236, 12, 1025644, -1, 0);

💡 Tips:

Stock resets daily at 24:00 or server restart
Use maxcount=-1 for unlimited exchanges
All exchange shops use interface ID 601
ownerid must match an existing NPC ID

🚚 Move NPC (Type 301)

This action moves static NPCs (from cq_npc) to specified map coordinates or hides them by moving to (0,0).

⚠️ Important:

Only works with cq_npc (not dynamic NPCs from cq_dynanpc)
Moving to (0,0) effectively hides the NPC

📜 Type 301 Parameters

Field	Usage
`data`	NPC ID (from `cq_npc`)
`param`	`"map_id posX posY"` coordinates

📜 Example SQL

Move NPC 2678 to map 1000 at (174,388):

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0301, 2678, '1000 174 388');

Hide NPC 2678 (move to 0,0):

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0301, 2678, '1000 0 0');

🔧 Practical Uses

Create NPCs that "travel" between locations
Hide/show NPCs for time-limited events
Reposition NPCs after map changes

💡 Tip: Combine with type 123 (time check) for NPCs that appear/disappear at specific times.

👥 Map User Check (Type 302)

This action checks player counts on specified maps, with special handling for large map IDs (>2.1 billion) in New Engine.

⚠️ New Engine Only: The extended format (data=0) is only available in New Engine versions.

📜 Standard Parameters (data ≠ 0)

INSERT INTO `cq_action` VALUES (1000, 1001, 1002, 0302, 8764, 'alive_user == 1');
INSERT INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'There are 1 user in that map');
INSERT INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'There are 0 or more than 1 user in that map');

Field	Value
`data`	Map ID (from `cq_map`)
`param`	`"cmd opt quantity"`
`cmd`	`map_user` (all users) or `alive_user` (non-ghost users)
`opt`	`==`, `<=`, or `>=`

📜 Extended Parameters (data=0) - New Engine Only

INSERT INTO `cq_action` VALUES (1000, 1001, 1002, 0302, 0, '1200 map_user <= 0');
INSERT INTO `cq_action` VALUES (1000, 1001, 1002, 0302, 0, '4070000001 map_user <= 0'); -- instance map
INSERT INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'There are no user in that map');
INSERT INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'There are user in that map');

Field	Value
`data`	Must be `0`
`param`	`"map_id cmd opt quantity"`

🔧 Practical Uses

Restrict access to maps when crowded (map_user >= 50)
Trigger events when first player enters (alive_user == 1)
Create solo-instance maps (map_user <= 0 check before teleport)

💡 Tip: Combine with type 1006 (teleport) to create player-limited zones.
Old Engine: Only supports standard format (data ≠ 0) with map IDs ≤ 2.1 billion

📢 Map Broadcast Message (Type 303)

Sends a broadcast message to all players on a specific map.

⚠️ Important:

data field requires a valid map ID
Messages are only visible to players on the specified map

🖼️ Example Output

📜 Type 303 Parameters

Field	Usage
`data`	Target map ID
`param`	Message text

📜 Example SQL

REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0303, 1000, 'Congratulations! %user_name has combined a Super Amber.');

💡 Note: For global announcements, use type 125 instead.

🎁 Map Drop Item (Type 304)

Spawns items at specified map coordinates with optional lifetime and protection periods.

📜 Standard Parameters

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0304, 0, '1010030 1000 492 320');

📜 New Engine Extended Parameters

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0304, 0, '1010030 1000 492 320 1800 900');

📦 Parameter Breakdown

Parameter	Description	Example
`idItemType`	Item ID to spawn	1010030
`idMap`	Target map ID	1000
`nPosX nPosY`	Spawn coordinates	492 320
`alivesecs`	Item lifetime (seconds) New Engine only	1800 (30 mins)
`priv_secs`	Protection period (seconds) New Engine only	900 (15 mins)

⚠️ New Engine Behavior:

When alivesecs and priv_secs are 0 or empty, uses server defaults
Old Engine only use Standard Parameters

🔧 Practical Uses

Event item spawns (holiday gifts, rare drops)
Quest objective items
Boss fight rewards

💡 Tip: Combine with type 303 to announce important item spawns.

🗺️ Map Attribute Control (Type 306)

Checks or modifies specific map attributes. Supports conditional checks and direct modifications.

📜 Basic Syntax

param = "field opt data [idMap]"

📜 Example

REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0306, 0, 'mapdoc == 8773');

📦 Supported Operations

Field	Operations	Description
`synid`	==, =	Synarchy ID operations
`status`	test, set, reset	Map status flags
`type`	test	Map type check
`res_lev`	=, ==, <	Resource level
`mapdoc`	=, ==	Map document ID
`portal0_x`	=	Main portal X coordinate
`portal0_y`	=	Main portal Y coordinate
`castle`	==	Castle association

⚠️ Notes:

When idMap is omitted, affects current map
Use id_nextfail for conditional failure paths

🔧 Practical Examples

-- Check map document ID
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0306, 0, 'mapdoc == 8773');

-- Modify resource level
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0306, 0, 'res_lev = 3 1002');

-- Test castle association
REPLACE INTO `cq_action` VALUES (1002, 1003, 1004, 0306, 0, 'castle == 5');

💡 Tip: Combine with type 1006 for conditional map teleports.

👀 Region Monitoring (Types 307,322,323)

⚠️ New Engine Only

Checks entity counts within specific map regions with different detection methods.

⚠️ Note: Type 307 references are scarce - recommended to use 322/323 instead.

📜 Type 322 - Circular Area Check

REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0322, 1, '1000 527 361 5 > 1');

Parameters: mapid x y radius > value

data=1: Exclude ghost players
Radius defines circular detection area
Supports >, ==, >=

📜 Type 323 - Rectangular Area Check

REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0323, 1, '1000 106 406 12 12 > 3');

Parameters: mapid x y width height > value

Similar to Type 322 but rectangular area
Width/Height define detection rectangle

📦 Parameter Comparison

Type	Area Shape	Ghost Handling	Operators
322	Circle (radius)	`data=0/1`	>, ==, >=
323	Rectangle (w/h)	`data=0/1`	>, ==, >=

🔧 Practical Uses

Boss room player limits
Event participation checks
Safe zone monitoring

💡 Implementation Guide:

Use 322 for radial detection (e.g. spawn points)
Use 323 for zone-based checks (e.g. rectangular arenas)
Set data=1 for alive-player-only events

🚶‍♂️ Move dynaNPC (Type 309)

Type 309 is used to move a dynamic NPC (dynaNPC) to a specified map and coordinates. You can also hide the NPC by moving it to coordinate (0,0).

📜 Example SQL:

-- Move dynaNPC id=5001 to map 1000 (x=300, y=300)
REPLACE INTO cq_action VALUES (910010, 910011, 910012, 309, 5001, '1000 300 300');

-- Success message
REPLACE INTO cq_action  VALUES (910011, 0, 0, 126, 0, 'dynaNPC #5001 moved to (300,300).');

-- Fail message
REPLACE INTO cq_action VALUES (910012, 0, 0, 126, 0, 'Failed to move dynaNPC #5001.');

📦 Parameter Breakdown

Field	Description	Example
`data`	dynaNPC ID	5001
`param`	`mapId posX posY`	1000 300 300

💡 Tips:

Use coordinate 0 0 to hide the dynaNPC without deleting it.
id_next is executed on success, id_next_fail on failure.
Make sure the dynaNPC ID exists, otherwise the fail branch will trigger.
Useful for moving event NPCs, respawning them in another location, or making them temporarily vanish.

✨ Map Effects (Type 312)

Displays visual effects at specified map coordinates. Supports hundreds of built-in effect animations.

📜 Basic Syntax

param = "idMap x y EffectName"

📜 Example

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0312, 0, '2010 325 438 fire555');

📦 Parameter Breakdown

Parameter	Description	Example
`idMap`	Target map ID	2010
`x y`	Effect coordinates	325 438
`EffectName`	Predefined effect identifier	fire555

🎆 Effect Names (Refer ini/3deffect.ini inside your client)

fire555
skill281
CoolPose03
chgdamage
pet31
gem16
bless
zfgx06
FF09
FF15

skill335
gcyh10
zfgx01
pilidan
gcyh9
other12
pet40
skill090
FF14
HeroGem

skill323
callpet05
skill064
monster02
noconfirm001
PetEvo
skill156
FF19
zhongqiu1
organ08

⚠️ Note:

Effects are client-side only
Duration depends on effect type
Coordinates are map-specific

🔧 Practical Uses

Quest completion markers
Event decorations
Boss spawn animations
Treasure location highlights

💡 Tip: Combine with type 303 for coordinated effect+announcement combos.

🗺️ Map Variables (Types 316,317,318,319)

⚠️ New Engine Only

Manipulates persistent variables tied to specific maps, supporting both numeric and text data.

📜 Type 316 - Initialize Numeric Variable

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0316, 0, 'map_var(1000,10) set 0');

Format: map_var(map_id,index) set value

Initializes variable to 0 (or specified value)
Variables: %map_iter_var_data{index}

📜 Type 317 - Modify/Compare Numeric Variable

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0317, 0, 'map_var(1200,0) += 1');

Operations: = == += -= *= /=

📜 Type 318 - Compare Text Variable

REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0318, 0, 'map_var(%user_map_id,2) == Tree');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'This is Tree');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'This is not Tree');

Note: Case-insensitive comparison

📜 Type 319 - Initialize Text Variable

REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0319, 0, 'map_var(1000,5) set %user_name');

Variables: %map_iter_var_str{index}

📦 Variable Index Range

Type	Index Range	Variable Format
Numeric	0-19	`%map_iter_var_data{index}`
Text	0-19	`%map_iter_var_str{index}`

⚠️ Special Map IDs:

%user_map_id - Current player's map
Numeric IDs reference cq_map

🔧 Practical Uses

Map-specific event counters
Boss spawn conditions
Dynamic puzzle states
Player progress tracking

💡 Tip: Combine with type 201 (NPC attributes) for complex map behaviors.

💉 Monster HP Check (Type 325)

⚠️ New Engine Only

Retrieves current or max HP of monsters on a map and stores in variables.

📜 Basic Syntax

param = "mapmonsterhp(map_id,monster_type_id,var_index,var_type,hp_mode)"

📦 Parameter Breakdown

Parameter	Description	Values
`map_id`	Target map ID	Number or `%user_map_id`
`monster_type_id`	Monster ID from `cq_monstertype`	e.g. 26171
`var_index`	Variable storage slot	0-99
`var_type`	Variable scope	0 = Personal (`%iter_var_data#`) 1 = Global (`%public_var_data#`)
`hp_mode`	HP retrieval mode	0 = Current HP 1 = Max HP

👤 Personal Variable Examples

-- Check current HP
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0325, 0, 'mapmonsterhp(%user_map_id,26171,3,0,0)');
REPLACE INTO `cq_action` VALUES (1001, 0, 0, 0126, 0, 'HP:%iter_var_data3');
REPLACE INTO `cq_action` VALUES (1002, 0, 0, 0126, 0, 'Get failed, the monster does not exist or HP is 0');

-- Check max HP
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0325, 0, 'mapmonsterhp(%user_map_id,26171,3,0,1)');
REPLACE INTO `cq_action` VALUES (1001, 0, 0, 0126, 0, 'Max HP:%iter_var_data3');
REPLACE INTO `cq_action` VALUES (1002, 0, 0, 0126, 0, 'Get failed, the monster does not exist or max HP is 0');

🌍 Global Variable Examples

-- Check current HP
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0325, 0, 'mapmonsterhp(%user_map_id,26171,3,1,0)');
REPLACE INTO `cq_action` VALUES (1001, 0, 0, 0126, 0, 'HP:%public_var_data3');
REPLACE INTO `cq_action` VALUES (1002, 0, 0, 0126, 0, 'Get failed, the monster does not exist or HP is 0');

-- Check max HP
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0325, 0, 'mapmonsterhp(%user_map_id,26171,3,1,1)');
REPLACE INTO `cq_action` VALUES (1001, 0, 0, 0126, 0, 'Max HP:%public_var_data3');
REPLACE INTO `cq_action` VALUES (1002, 0, 0, 0126, 0, 'Get failed, the monster does not exist or max HP is 0');

⚠️ Behavior Notes:

Returns false if monster doesn't exist or is dead
May return 0 even when successful
Global variables don't require player context

🔧 Practical Uses

Boss health percentage displays
Event triggers at specific HP thresholds
Dynamic difficulty adjustment
Raid mechanics implementation

💡 Tip: Combine with type 317 to create HP-based event counters.

🗑️ Delete Current Item (Type 498)

Deletes the item that triggered the action chain. Requires specifying the ItemTypeID and should be the last action in a sequence.

⚠️ Critical:

data field must contain the ItemTypeID
Always place this action last in your chain
Only deletes if the current item matches the specified ID

📜 Strict Syntax

data = ItemTypeID
param = "" (empty)

📜 Valid Examples

-- Delete current item (verified)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0498, 729011, '');

-- Full item exchange workflow:
REPLACE INTO `cq_action` VALUES (1001, 1002, 0000, 0501, 500002, '1 1 2 0 0 0 0 0 200 0 0 0'); -- Give reward
REPLACE INTO `cq_action` VALUES (1002, 1003, 0000, 1010, 2005, 'You received Eudemon Crystal.'); -- Announce
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0498, 729011, ''); -- Delete original item (LAST!)

❌ Invalid Usage:

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0498, 0, ''); -- ERROR: Missing ItemTypeID

🔧 Required Workflow

Process rewards/effects
Show notifications
Finally delete source item with type 498

🔄 Multi-Item Operations (Types 506 & 507)

Handles batch operations for ranges of items with binding status control.

⚠️ Note:

Supports item ranges (ID1 to ID2)
Old Engine only supports data=0

📜 Type 507 - Multi-Item Check

REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0507, 0, '743032 743032 10');

Parameters: "start_id end_id quantity"

📜 Type 506 - Multi-Item Delete

REPLACE INTO `cq_action` VALUES (1001, 1003, 0000, 0506, 0, '743032 743032 10');

📦 Binding Status Control (data field)

`data`	Behavior	Engine Support
0	Ignore binding status (delete/check all)	Old & New Engine
1	Delete/check both bound and unbound	New Engine Only
2	Only affect bound items	New Engine Only

🔧 Complete Workflow Example

-- Check for 10 Flower Cards (ID 743032)
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0507, 0, '743032 743032 10');

-- Success path: Delete 10 Flower Cards
REPLACE INTO `cq_action` VALUES (1001, 1003, 0000, 0506, 0, '743032 743032 10');
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0126, 0, 'You have given 10 flower cards');

-- Failure path
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Sorry, but you don`t have 10 flower cards');

💡 Advanced Usage:

Use identical start/end IDs for single item types
Combine with type 501 for exchange systems

🛡️ Equipment Check (Type 511)

Verifies if a player has specific equipment in a particular slot.

📜 Basic Syntax

data = Equipment slot position
param = ItemTypeID to check

📜 Example

REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0511, 4, '480001');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Weapon equipped');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Weapon not equipped');

📦 Equipment Slot Positions

Position	Value	Description
Helmet	1	Head slot
Necklace	2	Amulet/necklace slot
Armor	3	Armor slot
Weapon	4	Weapon slot
Ring	7	Ring slot
Shoes	8	Foot slot
Casual	12	Casual slot
Wardrobe Toy	38	Toy slot (New Engine)

⚠️ Note:

Position 38 (Wardrobe Toy) is New Engine only
Use id_next for equipped case
Use id_nextfail for unequipped case

🔧 Practical Uses

Class-specific quest requirements
Equipment-based skill unlocks
Cosmetic item verification
Special event participation checks

💡 Tip: Combine with type 503 to check both equipment and inventory items.

👥 Team Teleport Scroll (Type 517)

Enables user to teleport to team members location. Requires party membership.

📜 Basic Usage

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0517, 0, '');

📦 Requirements

User must be in a party
Target teammate must be on same map
Typically used with item ID 810001 (Portal Scroll)

🔧 Full Implementation Example

-- Portal Scroll item action chain
REPLACE INTO `cq_action` VALUES (1000, 1001, 0, 0517, 0, '');
REPLACE INTO `cq_action` VALUES (1001, 0, 0, 0126, 0, 'Teleported to teammate!');

⚠️ Behavior Notes:

Teleports user to teammate's position
Consumes the scroll on use
Some maps may restrict teleportation

🔍 Identify Item (Type 519)

Used to identify unknown equipment using a scroll, like the Equipment Scroll (ItemID: 810004).

🧪 Purpose:

Removes the “unidentified” status from an item.

📜 Example SQL

-- Use Equipment Scroll (ItemID 810004) to identify an item
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0519, 0, '');

⚙️ Behavior:

No `data` or `param` values needed; the system auto-identifies the target item equipped or selected.

🔍 Identify Eudemons (Type 520)

Used to identify an Eudemon using an identification scroll, checking its stats and quality. This action is triggered by using the Eudemon Scroll (ItemID: 810002).

🧪 Purpose:

Reveals the hidden stats and quality of a Eudemon.

📜 Example SQL

-- Use Eudemon Scroll (ItemID 810002) to identify an Eudemon's stats
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0520, 0, '');

⚙️ Behavior:

The scroll reveals the Eudemon's characteristics based on pre-defined data in the cq_eudemons table.

🐉 Create Universal O/XO (Types 526, 527, 530, 531)

These actions allow players to create Eudemons directly in their inventory. Each type corresponds to different star ratings of Eudemons:

🧪 Purpose:

Type 526: Create a 12-star XO Eudemon directly in the player's inventory.
Type 527: Create an 8-star O Eudemon directly in the player's inventory.
Type 530: Create a 6-star O Eudemon directly in the player's inventory.
Type 531: Create a 19-star XO Eudemon directly in the player's inventory.

📜 Full SQL Example for Creating a 12-Star Eudemon

-- Check if the player has enough space in the inventory (Eudemon bag 53)
REPLACE INTO `cq_action` VALUES (1000, 1001, 1003, 0508, 0, '1 0 53');

-- Create 12-Star XO Eudemon (ID 815038)
REPLACE INTO `cq_action` VALUES (1001, 1002, 0000, 0526, 0, '');

-- Remove the used item (creation item used)
REPLACE INTO `cq_action` VALUES (1002, 1004, 0000, 0502, 815038, '');

-- Notify the player of insufficient space if needed
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0126, 0, 'You need 1 free space in your inventory.');

-- Confirm the success of the creation
REPLACE INTO `cq_action` VALUES (1004, 0000, 0000, 0126, 0, 'Congratulations! You have obtained a 12-Star UniversalXO!');

⚙️ Behavior Notes:

Type 503 should be used before this action to check if there is enough space in the player's inventory (bag 53) to hold the Eudemon.
Type 526-531 actions correspond to different star-level Eudemons. For example, Type 526 creates a 12-star XO Eudemon, and Type 527 creates an 8-star O Eudemon.
Type 0502 is used to remove the item (used for the Eudemon creation) after successful creation.
Type 0126 provides feedback messages, like informing the player if there is insufficient space or confirming the successful creation of the Eudemon.

📝 Tips:

Ensure the player checks for sufficient inventory space using Type 503 before attempting to create the Eudemon.
The creation action (Type 526-531) will only set the star level of the Eudemon. The Type 503 action should handle the check for available space before the creation.
Use Type 0126 to notify the player if their inventory is full, or confirm successful creation with a custom message.

⚡ Change Eudemon Attribute (Type 523 & 524)

Used for checking and modifying Eudemon stats. A common example is changing an Eudemon’s elemental type using an item like Thunder Juice (ItemID: 831002).

🧪 Purpose:

Type 523: Checks multiple conditions related to the Eudemon — ownership, summon status, level, state, etc.
Type 524: Applies a stat change to the Eudemon — such as setting its damage, level, or element. Only one condition per statement allowed.

📜 Full SQL Sequence – Use Thunder Juice

-- Check: must be user's Eudemon, summoned, alive, level 1, and not already thunder
REPLACE INTO `cq_action` VALUES (1000, 1002, 1001, 0523, 0, 'ismyselfeudemon == 1,iscallout == 1,isalive == 1,level == 1,damage != 5');

-- Failure Message: not valid target
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Thunder Juice can only be used on level 1 Eudemons.');

-- Set Eudemon damage element to 5 (Thunder)
REPLACE INTO `cq_action` VALUES (1002, 1003, 0000, 0524, 0, 'damage 5');

-- Delete the used Thunder Juice item
REPLACE INTO `cq_action` VALUES (1003, 1004, 0000, 0498, 831002, '');

-- Announce to local system message
REPLACE INTO `cq_action` VALUES (1004, 0000, 0000, 1010, 2005, '%target_name has changed its race to Thunder!');

⚙️ Behavior Notes:

Type 523: Allows multiple checks in one param string, separated by commas
Type 524: Can only apply ONE attribute at a time (e.g., damage 5 or level 2)
ismyselfeudemon ensures the target belongs to the player
iscallout ensures the Eudemon is currently summoned
isalive ensures it's not dead or dismissed

📘 Common Conditions for 523:

ismyselfeudemon == 1 → belongs to the player
iscallout == 1 → summoned
isalive == 1 → not dead
level == 1 → required level
damage != 5 → not already thunder
godlevel == 1 → required level

📝 Tips:

Always handle id_nextfail for 523 to show rejection reason
Stack actions for longer flows — check ➝ modify ➝ delete item ➝ show message

🌟 Create 25-Star XO Eudemon (Type 538)

This action creates a 25-star XO Eudemon directly on the player's body. The param determines the number of stars, with a value of 0 indicating a 25-star XO Eudemon. Other values can be used to create Eudemons with different star ratings.

🧪 Purpose:

Type 538: Creates a specified star-rated XO Eudemon directly on the player's body.
When param = 0, a 25-star XO Eudemon is created.
For other values (e.g., param = 3500), it creates a corresponding number of stars (e.g., 35-star XO Eudemon).

📜 Full SQL Example for Creating a 25-Star Eudemon

-- Check for free space in the player's Eudemon bag (inventory bag 53)
REPLACE INTO `cq_action` VALUES (1000, 1002, 1001, 0508, 0, '1 0 53');

-- Failure Message: not enough space in inventory
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You need 1 free space in your inventory.');

-- Remove 1 used creation item (e.g., Eudemon creation item)
REPLACE INTO `cq_action` VALUES (1002, 1003, 0000, 0540, 1024838, 'amount += -1');

-- Create 25-star XO Eudemon directly on the player's body
REPLACE INTO `cq_action` VALUES (1003, 1004, 0000, 0538, 0, '2500');

-- Success Message: Notify the player of the Eudemon creation
REPLACE INTO `cq_action` VALUES (1004, 0000, 0000, 0126, 0, 'You received 25-star XO Eudemons.');

⚙️ Behavior Notes:

Type 0508 checks if there is enough space in the player's Eudemon bag (inventory bag 53) before proceeding with the Eudemon creation.
Type 0540 removes the used creation item (such as a scroll or other item used to trigger the Eudemon creation).
Type 0538 actually creates the Eudemon on the player's body with a specified number of stars (e.g., 25 stars). The param value can be customized to create Eudemons with other star ratings (e.g., param = 3500 creates a 35-star XO Eudemon).
Type 0126 sends feedback messages to the player — either about inventory space or confirmation of the Eudemon creation.

📝 Tips:

Always ensure that the player has enough space in their inventory before attempting to create the Eudemon using Type 0508.
For other star-level Eudemons, modify the param value accordingly (e.g., 3500 for 35 stars).
Consider chaining actions with failure conditions using id_nextfail to handle space issues or prevent creation if prerequisites aren’t met.

🎁 Monster Item Drop (Type 801)

Type 801 is used to drop items, money, or traps after a monster is killed. The parameters supported are `dropitem`, `dropmoney`, and `droptrap`. You can specify the item type, money amount, or a trap to be dropped. The new engine extension also allows for specifying the quantity for item drops. Below are examples of how to use this action type:

💡 Example SQL:

-- Drop an item with ItemTypeID 131000
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0801, 0, 'dropitem 131000');
          
-- Drop 100,000 money
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0801, 0, 'dropmoney 100000');
          
-- Drop a trap with ID 3000 (trap ID from cq_trap) and life period 30 (seconds)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0801, 0, 'droptrap 3000 30');
          
-- New Engine Only: Drop 3 items of ItemTypeID 723003
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0801, 0, 'dropitem 723003 3');

📘 Parameter Explanation:

Field	Operator	Description	Example
dropitem	`itemtype`	Drop a specified item by ItemTypeID	`dropitem 131000` (drop item with ItemTypeID 131000)
dropmoney	`money`	Drop a specified amount of money	`dropmoney 100000` (drop 100,000 money)
droptrap	`trap_id lifeperiod`	Drop a trap with a specified ID (from `cq_trap`) and a life period	`droptrap 3000 30` (drop trap with ID 3000, with a life period of 30 seconds)
dropitem (New Engine Only)	`itemtype quantity`	Drop a specified quantity of a given item	`dropitem 723003 3` (drop 3 items of ItemTypeID 723003)

💡 Tips:

Use `dropitem` to specify the item you want to drop by its ItemTypeID. For the new engine, you can also specify the quantity of items to drop.
Use `dropmoney` to drop a specified amount of money after a monster is killed.
Use `droptrap` to drop a trap with a specified trap ID. The second parameter (`lifeperiod`) defines the duration for which the trap remains active. This is typically in seconds.
The new engine supports specifying the quantity for item drops with `dropitem` (e.g., `dropitem 723003 3` to drop 3 items).

🔥 Skill Check/Learn/Upgrade (Type 802)

Type 802 is used to check, learn, or upgrade player skills (spells). The param supports multiple modes:

check type – Check if the player has learned the skill with type type.
check type level – Check if the player has learned a skill of type type at a specific level.
learn type – Learn a spell of type at level 0.
uplevel type – Upgrade an existing spell of type to the next level.

Note: The type value refers to the spell ID from cq_magictype.

💡 Example SQL – Check & Learn Skill:

-- Check if skill 8001 is already learned
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0802, 0, 'check 8001');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 1010, 2005, 'You already learned this skill');

-- Learn the skill 8001 if not yet learned
REPLACE INTO `cq_action` VALUES (1002, 1003, 0000, 0802, 0, 'learn 8001');
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 1010, 2005, 'You learned a new skill!');

💡 Example SQL – Upgrade Existing Skill:

-- Upgrade skill 3011 to the next level
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0802, 0, 'uplevel 3011');

💡 Example SQL – Check Skill Level:

-- Check if player has learned skill 3011 at level 0
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 0802, 0, 'check 3011 0');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your skill is level 1');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Your skill is not level 1');

📘 Parameter Modes:

Format	Function	Example
`check type`	Check if the player has learned this skill	`check 8001`
`check type level`	Check if the skill is at the given level	`check 3011 0`
`learn type`	Learn the skill (adds skill at level 0)	`learn 8001`
`uplevel type`	Increase the spell's level by 1	`uplevel 3011`

💡 Tips:

Use check before learn to prevent duplicate skills.
All type values must refer to IDs in cq_magictype.
Use uplevel carefully — it assumes the player already has the skill.
Always use id_nextfail when checking skills to show appropriate fallback messages.

💎 VIP Level Check & Set (Type 5001)

Type 5001 checks the player's VIP level or sets it directly (new engine only). You can use this to branch actions depending on the player's VIP status, or upgrade the VIP level programmatically. Supported operators include ==, >, <, >=, <=, and = (only in new engine for setting VIP).

💡 Example SQL – Check VIP Level:

-- Check if VIP level is exactly 4
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 5001, 0, '== 4');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You`re vip 4');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You`re not vip 4');

-- Check if VIP is greater than 3
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 5001, 0, '> 3');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your vip is higher than 3');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Your vip is less than or equal to 3');

-- Check if VIP is less than 4
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 5001, 0, '< 4');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your vip is less than 4');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Your vip is 4 or higher');

-- Check if VIP is 5 or higher
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 5001, 0, '>= 5');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your vip is 5 and above');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Your vip is less than 5');

⚙️ Example SQL – Set VIP Level (New Engine Only):

-- Set player's VIP level to 4
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 5001, 0, '= 4');

📘 Notes:

Checking VIP level: Use ==, >, <, >=, or <= to perform condition checks.
Setting VIP level: Use = to directly assign a VIP level to the player. Only works in the New Engine.
Account sync warning: For VIP assignment to work, account database and player database must be in the same database schema.
VIP changes won’t be reflected until the player relogs.

⚠️ New Engine Info: Using = to set VIP level is only supported in the new engine.
Ensure databases are merged and user relogs to see the update.

⚙️ Eudemon Attributes Check/Delete (Type 1503, 1504)

Type 1503 is used to check various attributes of a player's summoned Eudemon, such as its star rating, callout status, damage type, and other attributes. Type 1504 is used for deleting Eudemons, with specific checks related to the summoned Eudemon. The New Engine introduces the newtype parameter to more specifically refer to Eudemons, as well as additional support for deskknight and syndicate checks.

💡 Example SQL – Check Eudemon Attributes:


-- Check if Eudemon's damage type is 5 (Thunder) and if it's summoned
REPLACE INTO `cq_action` VALUES (1000, 1001, 1004, 1503, 0, 'damagetype == 5 callout == 1');

-- Check if Eudemon's type is 42 (Warrior Lulu) and if it's summoned
REPLACE INTO `cq_action` VALUES (1001, 1002, 1005, 1503, 0, 'type == 42 callout == 1');

-- Check if Eudemon's type is 42 (Warrior Lulu) and then delete it
REPLACE INTO `cq_action` VALUES (1002, 1003, 0000, 1504, 0, 'type == 42 callout == 1');

-- Display message if Eudemon has been deleted
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0126, 0, 'Your Warrior Lulu has been deleted.');

-- Display message if Eudemon is not of Thunder damage type
REPLACE INTO `cq_action` VALUES (1004, 0000, 0000, 0126, 0, 'Your pet is not thunder.');

-- Display message if no Warrior Lulu is summoned
REPLACE INTO `cq_action` VALUES (1005, 0000, 0000, 0126, 0, 'Please summon Warrior Lulu first.');

📘 New Engine Modifications:

New Engine introduces newtype to replace type, with the algorithm itemtype / 10 to specify the exact Eudemon. Additionally, deskknight == 1 and syndicate == 1 can be added to check whether the desk knight and the legion totem have been registered.

💡 Example SQL – New Engine Modifications: (use , as separator)

-- Check if Eudemon's star is less than 500.
REPLACE INTO `cq_action` VALUES (1000, 1001, 1004, 1503, 0, 'star > 500,callout == 1');

-- Use newtype (itemtype / 10) for more specific Eudemon type
REPLACE INTO `cq_action` VALUES (1001, 1003, 1005, 1503, 0, 'newtype == 107019,callout == 1');  -- Eudemon with itemtype 107019, newtype = 107019

-- Delete Eudemon of newtype 107019
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 1504, 0, 'newtype == 107019,callout == 1');

-- Display message if Eudemon star is less than 500.
REPLACE INTO `cq_action` VALUES (1004, 0000, 0000, 0126, 0, 'Your eudemons is less than 5 star.');

-- Display message if not specific Eudemon type.
REPLACE INTO `cq_action` VALUES (1005, 0000, 0000, 0126, 0, 'Please summon Kong first.');

📘 Parameter Explanation:

Field	Operator	Description	Example
star	`<, >, ==, >=, <=`	Check or compare the star level of the Eudemon	`star < 500` (check if star is less than 500)
callout	`==`	Check if the Eudemon is summoned	`callout == 1` (check if summoned)
damagetype	`==`	Check the damage type of the Eudemon	`damagetype == 5` (check if the damage type is Thunder)
type / newtype	`==`	Check the Eudemon type	`type == 42`
newtype (new engine)	`==`	Check the Eudemon specific type	`newtype == 107019` (check for a specific Eudemon ID)
deskknight (new engine)	`==`	Check if the desk knight is registered	`deskknight == 1`
syndicate (new engine)	`==`	Check if the syndicate (legion totem) is registered	`syndicate == 1`

💡 Tips:

Use the callout field to check if an Eudemon is currently summoned (1 for summoned, 0 for not summoned).
New Engine Only: Use newtype to refer to Eudemons more specifically, calculated as itemtype / 10.
For damagetype, use 5 for Thunder element Eudemons.

💫 Revive Eudemons (Type 1531)

Type 1531 is used to resurrect dead Eudemons. The behavior of the action is controlled by the data field:

💡 Example SQL:

-- Old Engine: Revive only summoned dead Eudemons
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1531, 0, '');

-- New Engine: Revive all dead Eudemons (including unsummoned ones)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1531, 1, '');

📘 Parameter Explanation:

Data	Engine	Effect
`0`	Old & New	Revives only currently summoned (in-battle) dead Eudemons.
`1`	New Engine Only	Revives all dead Eudemons, including unsummoned ones.

💡 Tips:

Use data = 0 for compatibility with both old and new engines.
Use data = 1 only if your server runs the new engine and you want to fully restore all fallen Eudemons.
Ideal for NPC healers, rebirth rituals, or revival buffs in battle events.

❤️ Resurrect Character & Eudemons (Type 1539 & 1540)

Type 1539 is used to resurrect the player character, but only if the player is dead and the internal cooldown time has passed. Type 1540 is used to instantly revive all Eudemons, including those not currently summoned, without any time check. Useful for full revives during events or special rewards.

💡 Example SQL – Type 1539 (Character Resurrection with Time Check)

-- Check if player is dead
REPLACE INTO `cq_action` VALUES (1000, 1001, 0000, 1001, 0, 'life == 0');

-- Resurrect character if time condition is met
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 1539, 0, '');

📘 Type 1539 Notes

Only works if player is dead (life == 0).
Resurrection only triggers if the cooldown time has passed.
If not enough time has passed, nothing happens.

💡 Example SQL – Type 1540 (Resurrect All Eudemons Instantly)

-- Instantly revive all Eudemons, summoned or not
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1540, 0, '');

📘 Type 1540 Notes

Works on all Eudemons, regardless of summon status.
No cooldown or time check – executes instantly.
Good for full revive functions (event prize, healer NPC, etc).

💡 Tips

Use Type 1539 when resurrection needs to be limited by time.
Use Type 1540 when you want to revive all Euds at once without checks.
Can be combined with 0126 to display messages like "You have been revived!"

🚚 Delivery System (Type 1511,1512,1513)

These action types control the log delivery system using a cart (style 991–994). Players can begin a delivery run with a specified wood quantity, unit price, and time limit. During delivery, teleporting is restricted. Delivery ends when the task is complete or aborted manually.

💡 Example SQL – Start Delivery (Type 1511)

-- Start delivery: 1000 logs, 100 gold each, 3600 seconds (1 hour), cart style 991
REPLACE INTO `cq_action` VALUES (1001, 1004, 1003, 1511, 991, '1000 100 3600');

-- Player can't buy logs due to flying status or insufficient gold
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0126, 0, 'Unable to buy these logs when you are flying or don`t have enough gold.');

-- Delivery start confirmation message
REPLACE INTO `cq_action` VALUES (1004, 0000, 0000, 0126, 0, 'You must deliver 1,000 logs to the destination within one hour.');

💡 Example SQL – End Delivery (Type 1512)

-- End the delivery run manually or upon completion
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1512, 0, '');

💡 Example SQL – Check Delivery Status (Type 1513)

-- Check if the player is currently in delivery
REPLACE INTO `cq_action` VALUES (1000, 1001, 0000, 1513, 0, '');

-- Player is delivering, block teleport
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Sorry, you can`t be teleported during delivery.');

📘 Parameter Explanation

1511 – Begins delivery with cart style and parameters:
- woodquantity – Logs to deliver (e.g. 1000)
- unitprice – Gold per log (e.g. 100)
- endtime – Time limit in seconds (e.g. 3600 = 1 hour)
1512 – Ends the delivery mission.
1513 – Checks if delivery is in progress (blocks certain actions).

💡 Tips

Cart styles are 991, 992, 993, 994 – use different IDs for cosmetic or logical variation.
Delivery can be interrupted if the player teleports; use 1513 to block such actions.
Always display clear messages using 0126 so players know delivery status or failure reasons.

🪓 Life Skills (Type 1514)

Type 1514 manages life skills such as Delivery Skill (ID 300). It supports:

learn – To learn a new life skill
check – To check if the player has the skill, or verify its level
addexp – To increase skill EXP

💡 Example SQL – Learn Delivery Skill

-- Learn delivery skill (ID 300)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1514, 0, 'learn 300');

💡 Example SQL – Check Skill Level

-- Check if skill 300 is level 9
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1514, 0, 'check 300 9');

💡 Example SQL – Add EXP to Skill

-- Add 1000 EXP to skill 300
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1514, 0, 'addexp 300 1000');

📘 Parameter Explanation

learn [id] – Learns the specified life skill.
check [id] [level] – Verifies if the player has the skill at that level. Level can be skipped to just check if learned.
addexp [id] [amount] – Adds EXP to that skill (triggers level-up if thresholds met).

💡 Tips

Use check before allowing delivery quests or crafting tasks.
EXP gain can be from quests, farming, or delivery success. Use addexp after events.
TrainReward was supported in older engines but i dont know how it works.

💥 Check Current Number of Summoned Eudemons (Type 1515)

Type 1515 is used to check how many Eudemons the player currently has summoned. The action checks the value of callout_num, which represents the number of Eudemons currently summoned. Based on the value, the system can return different messages.

💡 Example SQL – Check Number of Summoned Eudemons

-- Check if the player has fewer than 1 summoned Eudemon
REPLACE INTO `cq_action` VALUES (1000, 1003, 1004, 1515, 0, 'callout_num < 1');

-- Check if the player has fewer than 2 summoned Eudemons
REPLACE INTO `cq_action` VALUES (1001, 1003, 1004, 1515, 0, 'callout_num < 2');

-- Check if the player has fewer than 3 summoned Eudemons
REPLACE INTO `cq_action` VALUES (1002, 1003, 1004, 1515, 0, 'callout_num < 3');

-- Player message if not all Eudemons are summoned
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0126, 0, 'Please summon all eudemons first!');

📘 Parameter Explanation

callout_num – Represents the number of Eudemons currently summoned by the player.
Operators: <, ==, >
Message – Shows a message based on the number of summoned Eudemons.

📘 Old Engine Notes

Old engine only supports: callout_num == 1 to check if exactly 1 Eudemon is summoned.

💡 Tips

Use callout_num < 1 or similar checks to ensure that players have summoned the required number of Eudemons for an event or task.
Make sure to show clear messages with 0126 to notify players if they need to summon additional Eudemons.
Old engines won’t support the comparison with callout_num < 2 or higher. Use callout_num == 1 for such checks in older engines.

⏳ Experience Time for Level Up (Type 1518)

Type 1518 is used to add experience time for leveling up. The experience is calculated based on 432 seconds (1 minute) of monster killing experience multiplied by the monster's experience multiplier.

The data parameter in this action i cant figure it out what is this:

💡 Example SQL – Old Engine (Values: 1, 2, 3)

-- Add 4500 seconds of experience (1 minute = 432 seconds)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1518, 3, 'uplevtime += 4500');

-- Add 304 seconds of experience
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1518, 2, 'uplevtime += 304');

-- Add 1800 seconds of experience
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1518, 1, 'uplevtime += 1800');

💡 Example SQL – New Engine (Only Value 2)

-- Add 77760 seconds of experience in the new engine
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1518, 2, 'uplevtime += 77760');

📘 Parameter Explanation

uplevtime – The experience time added for leveling up. It is calculated in seconds, and can be modified based on the experience multiplier for the monster type.

💡 Tips

Ensure that the time increments match your desired gameplay pacing. If you want faster leveling, adjust the time added in each uplevtime action accordingly.

💪 Fill Player's Attributes (Type 1002)

Type 1002 is used to fill up a player's attributes, such as their life and mana. You can specify which attribute to fill by passing life or mana as the parameter. This action can be used to instantly restore the player's life or mana to full.

💡 Example SQL – Restore Life

-- Restore player's life
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1002, 0, 'life');

💡 Example SQL – Restore Mana

-- Restore player's mana
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1002, 0, 'mana');

📘 Parameter Explanation

life – Fills the player's life attribute to full.
mana – Fills the player's mana attribute to full.

💡 Tips

Use life and mana to instantly restore the respective attributes during battle or events.
Ensure to handle both attributes separately if you want to use them independently in different conditions.

🌍 Change Map (Type 1003)

Type 1003 is used to change the player's map. It requires the map ID, the X and Y coordinates, and optionally a flag to allow prison exit. By default, players cannot exit the prison, but setting the bPrisonChk parameter to 1 allows them to do so.

💡 Example SQL – Change Map

-- Change map to ID 1000, position (280, 411), allowing prison exit (bPrisonChk = 1)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1003, 0, '1000 280 411 1');

📘 Parameter Explanation

idMap – The ID of the target map to change to.
nPosX – The X-coordinate for the new position on the map.
nPosY – The Y-coordinate for the new position on the map.
bPrisonChk – Optional parameter:
- 0 – Cannot exit the prison (default behavior).
- 1 – Allows the player to exit the prison.

💡 Tips

Ensure that the target map ID and coordinates are valid and accessible for the player.
If you want to allow players to exit the prison, remember to set bPrisonChk = 1 to enable this feature.

📍 Record Map Point (Type 1004)

Type 1004 is used to record the player's current position on the map, allowing them to return to this point later. The parameters include the map ID, X-coordinate, and Y-coordinate.

💡 Example SQL – Record Map Point

-- Record the player's position on map ID 1000 at coordinates (316, 467)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1004, 0, '1000 316 467');

📘 Parameter Explanation

idMap – The ID of the map where the point is being recorded.
nMapX – The X-coordinate for the recorded point.
nMapY – The Y-coordinate for the recorded point.

💡 Tips

Use this action to create checkpoints for players, which they can return to later in the game.
Ensure that the map ID and coordinates are valid and reachable for the player.

🌍 Change Map to Recorded Point (Type 1006)

Type 1006 is used to change the player's map to a previously recorded point. This action helps players quickly travel back to a saved location. Make sure to first set the checkpoint using Type 1004 before attempting to use this action.

💡 Example SQL – Change Map to Recorded Point

-- Change to the recorded map point (ID 1000030)
REPLACE INTO `cq_action` VALUES (1000030, 0000, 0000, 1006, 0, '');

📘 Parameter Explanation

idMap – The map ID of the recorded point to travel to.

📘 Important Note

Make sure to set the checkpoint first using Type 1004 before using Type 1006 to change maps to that recorded point.

💡 Tips

Ensure that the recorded map point ID is valid and that the player has access to that location.
Use this action to quickly return to important locations within the game, such as dungeons, towns, or personal checkpoints.

👤 Change Player Avatar (Type 1008)

Type 1008 is used to change the player's avatar. The parameter for this action is the ID of the new avatar that the player wants to switch to.

💡 Example SQL – Change Player Avatar

-- Change the player's avatar to ID 84
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1008, 0, '84');

📘 Parameter Explanation

id – The avatar ID to change to. This ID corresponds to a specific avatar in the game.

💡 Tips

Ensure that the avatar ID is valid and corresponds to an existing avatar.
This action can be used for character customization or special events where avatars are changed.

🔎 Check Player Status (Type 1009)

Type 1009 is used to check whether the player is currently in a specific state. It simply checks whether a status exists (i.e. whether the seconds remaining is greater than 0), without needing to calculate time ranges or expiration.

💡 Example SQL – Check EXP Boost State

-- Check if the player is under EXP boost (state 158)
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1009, 0, '158 second > 0');

-- If true, show message
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You are currently under an EXP boost.');

-- If false, show alternate message
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You are not under an EXP boost.');

💡 Example SQL – Check Drop Rate Boost (State 889)

-- Check if Drop Rate Boost (State 889) is active
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1009, 0, '889 second > 0');

-- If active
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You are already in Drop Rate Boost status.');

-- If not active, apply 10x drop boost for 20s
REPLACE INTO `cq_action` VALUES (1002, 1003, 0000, 4001, 0, '889 1000 20 0');
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0126, 0, 'You have received 10x drop boost for 20 seconds.');

📘 Parameter Format

[state_id] second > 0 – Returns true if the player is in that status

📘 Common State IDs

158 – EXP Boost
43 – EXP Boost
164 – Dragon Morph
184 – Flying
166 – Delivery Log
889 – Drop Rate Boost
248, 249, 1014 – Unknown

💡 Tips

Use this to enable or restrict content (e.g. flying-only access, EXP boost bonuses).
Works well with 0126 to provide user feedback.
Can be used with Type 4001 to apply statuses conditionally.

🧑 Check Player Avatar (Type 1014)

⚠️ Old Engine Only

Type 1014 is used to check whether the player is currently wearing a specific avatar. This is useful for avatar-based conditions such as quest checks, special dialogue, or restricted access features.

💡 Example SQL – Check if Player is Wearing Avatar ID 45

-- Check if the player is equipped with avatar ID 45
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1014, 0, 'ChkFace 45');

-- If true, show message
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You equip this avatar.');

-- If false, show alternate message
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You are not equip this avatar.');

📘 Parameter Explanation

ChkFace [id] – Checks if the current player face (avatar) matches the given ID.

💡 Tips

Use this check for unlocking avatar-only content, special access, or triggering rewards for wearing specific looks.
Use with 0126 to show clear feedback to the player.
Can be combined with avatar change logic from Type 1008.

✨ God Blessing Status (Type 1012)

Type 1012 is used to manage the "God Blessing" status on a player. You can check if the blessing is active, or apply it using either add or addonly. The second parameter is always 1 (purpose unknown, just required). The last parameter is the duration in hours.

💡 Example SQL – Addonly God Blessing (30 days)

-- Adds blessing only if the player does not already have it (720 hours = 30 days)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1012, 0, 'addonly 1 720');

💡 Example SQL – Add God Blessing (1 day)

-- Adds blessing regardless of current status (24 hours = 1 day)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1012, 0, 'add 1 24');

💡 Example SQL – Check Blessing Status

-- Check if player has God Blessing active
REPLACE INTO `cq_action` VALUES (1001, 1002, 1003, 1012, 0, 'check 1 0');

-- If not active
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You don\'t have blessing on you.');

-- If active
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0126, 0, 'You have blessing on you.');

📘 Parameter Explanation

add – Adds the blessing, even if one already exists. (just my theory)
addonly – Adds the blessing only if none currently exists. (just my theory)
check – Verifies if the blessing is active.
1 – Always used in second position (actual meaning unknown, but required).
duration – Length of the blessing in hours (e.g. 24 = 1 day, 720 = 30 days).

💡 Tips

Use addonly if you want to avoid refreshing or overwriting an existing blessing.
Use add if you want to forcibly apply or refresh the blessing regardless of status.
Use check with branching to show different messages depending on whether the blessing is active.
Combine with 0126 messages to notify players when blessings are applied or missing.

🌀 Skill Control (Type 1020)

Type 1020 is used to manage player skills. It supports checking, learning, leveling up, and adding EXP to specific magic skills. The skill type refers to the skill ID from cq_magictype.

💡 Example SQL – Learn Skill

-- Learn skill with ID 33001 (level 1)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1020, 0, 'learn 33001');

-- Learn skill 33001 at level 3 directly
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1020, 0, 'learn 33001 2');

💡 Example SQL – Check Skill

-- Check if player has learned skill ID 1008
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1020, 0, 'check 1008');

-- If learned
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You already learn this skill');

-- If not learned
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You not learn this skill');

💡 Example SQL – Add EXP to Skill

-- Add 5000 EXP to skill ID 5305
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1020, 0, 'addexp 5305 5000');

📘 Parameter Explanation

check [type] – Checks if the player has learned the skill ID.
check [type] [level] – Checks if the player has the skill at a specific level.
learn [type] – Teaches the player a new skill (defaults to level 0).
learn [type] [level] – Teaches a skill at the specified level.
uplevel [type] – Increases the level of an existing skill by 1.
addexp [type] [exp] – Adds experience points to the specified skill.

💡 Tips

Use check before learn to avoid teaching duplicate skills.
Use uplevel to simulate skill mastery over time or quests.
addexp is useful for skill training systems or battle rewards.

📝 GM Log with Player Info (Type 1022)

Type 1022 is used to write custom log entries to the GM log. This log is saved to the MSGServer/gmlog directory. The log message supports placeholders that automatically insert the triggering player's information such as name, ID, location, item, and NPC data.

💡 Example SQL – Log Player Action

-- Log player info, map, item, and NPC during action
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1022, 0, '%user_name[%user_id] Location(%user_map_id %user_map_x %user_map_y) ITEM(%item_type %target_name) NPC(%name %id %npc_x %npc_y) actionid = 930000070 param = e_money += 54000');

📘 Placeholder Variables

%user_name – Player's name
%user_id – Player's ID
%user_map_id – Current map ID
%user_map_x – Player's X position
%user_map_y – Player's Y position
%item_type – Item type ID
%target_name – Item or target name
%name – NPC name
%id – NPC ID
%npc_x – NPC X coordinate
%npc_y – NPC Y coordinate

💡 Tips

Use this for logging sensitive events like item rewards, purchases, quest completions, or suspicious actions.
Placeholders are replaced automatically by the system at runtime based on the triggering player and context.
The message is saved in MSGServer/gmlog and can be reviewed by server staff.

💍 Marriage & Divorce System (Type 1024 & 1025)

These action types are used to manage player marriage status in the game. Type 1025 checks if the player is married, while Type 1024 is used to perform a divorce action.

💡 Example SQL – Check Marriage Status (Type 1025)

-- Check if the player is married
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1025, 0, '');

-- If not married
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You not married');

-- If already married
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You already married');

💡 Example SQL – Divorce (Type 1024)

-- Perform divorce
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1024, 0, '');

📘 Parameter Explanation

Type 1025 – Checks the marriage status of the player and branches based on result.
Type 1024 – Executes a divorce and resets the marriage data of the player.
No additional parameters are needed for either action.

💡 Tips

Use Type 1025 before allowing marriage-related actions like teleportation or gifting.
Use Type 1024 for NPC-based divorce options or special item effects.
Pair with message actions (0126) to clearly inform the player of their status.

🚻 Gender Check (Type 1026)

Type 1026 is used to check the player's gender. It branches using id_next for male and id_nextfail for female. This is useful for displaying gender-specific messages or giving gender-specific items like casual outfits.

💡 Example SQL – Basic Gender Check

-- Check if player is male or female
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1026, 0, '');

-- Male
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You are male');

-- Female
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You are female');

💡 New Engine Special Case – Give Gendered Casual by Class

In the new engine, the Star Guardian class (ID 110) uses different casual outfits. You need to check class first, then gender, before giving the appropriate item.

-- Check if class is Star Guardian (profession 110)
REPLACE INTO `cq_action` VALUES (1000, 1001, 1010, 1001, 0, 'profession == 110');

-- Star Guardian gender check
REPLACE INTO `cq_action` VALUES (1001, 1002, 1003, 1026, 0, '0');

-- Male Star Guardian gets item 198500
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0501, 198500, 0);

-- Female Star Guardian gets item 198520
REPLACE INTO `cq_action` VALUES (1003, 0000, 0000, 0501, 198520, 0);

-- Other class gender check
REPLACE INTO `cq_action` VALUES (1010, 1011, 1012, 1026, 0, '0');

-- Male (other class) gets item 194600
REPLACE INTO `cq_action` VALUES (1011, 0000, 0000, 0501, 194600, 0);

-- Female (other class) gets item 194620
REPLACE INTO `cq_action` VALUES (1012, 0000, 0000, 0501, 194620, 0);

📘 Parameter Explanation

No param needed or just 0 as a placeholder.
id_next → Male
id_nextfail → Female

💡 Tips

Always check profession before gender if giving class-specific items.
Use Type 0501 to give items based on gender.
This action is useful for casuals, titles, class-locked visuals, and gender-exclusive quests.

🎆 Apply / Remove Visual Effects (Type 1027 & 1060)

Type 1027 applies a visual special effect to the player or target. The effect can be visible to everyone, only the target, or only the triggering player. The effect name must match one defined in ini/3deffect.ini.

Type 1060 is used to remove effects applied by Type 1027. It uses the same format but clears the visual from the client. This is supported in new engine only.

💡 Example SQL – Apply Basic Effects

-- Show effect to yourself (others can see)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1027, 0, 'self skill307');

-- Show effect to target (others can see)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1027, 0, 'target flower2');

-- Show effect to target (only target sees it)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1027, 0, 'targetlone flower-red');

💡 Example SQL – New Engine Only: Self-Only Advanced Effects

-- Show chained effect only to self
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1027, 0, 'selflone shfbqqskill_spexx100');

💡 Example SQL – Remove Effect (New Engine Only)

-- Remove previously applied effect from self
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1060, 0, 'self shfbqqskill_spsxx100');

📘 Parameter Format

opt effect – Two-part value: visibility type and effect name
opt options:
- self – Player sees the effect (public)
- target – Target sees the effect (public)
- targetlone – Only target sees the effect
- selflone – Only the triggering player sees the effect
effect – The effect ID or name as listed in ini/3deffect.ini

📘 Notes

Type 1060 is only supported in new engine.
To remove effects, use the same format as Type 1027 but with script type 1060.

💡 Tips

Use self or target for effects visible to others.
Use selflone or targetlone for personal/secret visuals.
Type 1060 is useful to clear buffs, transform visuals, or temporary animations.

🧠 Task Mask Operations (Type 1028)

⚠️ Old Engine Only

Type 1028 is used to perform operations on task masks. Task masks are used to track task-related flags using bit values (0–31). The action supports checking, adding, and clearing specific mask bits.

💡 Example SQL – Check Task Mask

-- Check if task mask index 3 is active
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1028, 0, 'chk 3');

💡 Example SQL – Add Task Mask

-- Set task mask index 4 to active
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1028, 0, 'add 4');

💡 Example SQL – Clear Task Mask

-- Clear task mask index 4
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1028, 0, 'clr 4');

📘 Parameter Explanation

chk idx – Checks if the bit at index idx is set.
add idx – Sets the bit at index idx to 1 (mark as complete).
clr idx – Clears the bit at index idx to 0 (reset).
idx – The task mask index (range: 0 to 31).

💡 Tips

Use chk with id_next and id_nextfail to branch based on task progress.
Task masks are ideal for tracking story flags, special rewards, one-time events, or hidden triggers.
Be consistent with index usage to avoid conflict between unrelated systems.

🔊 Media Playback (Type 1029)

Type 1029 is used to trigger media playback on the client side. You can use it to play sound or video files that exist in the client directory. The param supports play or broadcast followed by the path to the media file.

💡 Example SQL – Play Sound File

-- Play a sound file (trap.wav) located in the "sound" folder of the client
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1029, 0, 'play sound/trap.wav 0 0 1');

📘 Parameter Format

opt media_path [0 0 1]
opt – Action type:
- play – Play the media for the triggering player only.
- broadcast – Broadcast the media to all nearby players (if supported).
media_path – Path to the media file in the client folder (e.g. sound/trap.wav).
The remaining 0 0 1 values are typically reserved or unused in most cases, but must be included for format compatibility.

💡 Tips

Make sure the media file exists in the specified path on the client, or the effect won't play.
Use play for personalized sound effects (e.g. when opening a chest).
Use broadcast if you want the effect shared with other players in the area (new engine required).
Best used for immersive effects, alert sounds, or cinematic cutscenes.

🃏 Checkout Eudemon Point Cards (Type 1032 & 1037)

⚠️ Old Engine Only

These actions are used to convert Eudemon cards from the cq_card or cq_card2 table into Eudemon Points (EP). When triggered, the system checks the player's card table, converts available entries to EP, sends the points to the player, and updates the card entry's used column to 1 (used).

cq_card cards are worth 270 EP each.
cq_card2 cards are worth 1380 EP each.

💡 Example SQL – Type 1032 (cq_card: 270 EP each)

-- Checkout cq_card and convert to EP if exists
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1032, 0, '');

-- Success message
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You`ve taken out a Eudemon Card. Your Eudemon Points increased.');

-- Fail message
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You don`t have a Eudemon Card here.');

💡 Example SQL – Type 1037 (cq_card2: 1380 EP each)

-- Checkout cq_card2 and convert to EP if exists
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1037, 0, '');

-- Success message
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You`ve taken out a Eudemon Card. Your Eudemon Points increased.');

-- Fail message
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You don`t have a Eudemon Card here.');

📘 Parameter Explanation

No additional param needed for either type.
The system checks for valid cards in the player’s cq_card or cq_card2 table.
Each valid entry will:
- Be converted into EP based on the card type (270 or 1380 EP)
- Be marked as used by setting used = 1 in the database

💡 Tips

Use 1032 for standard card redemption (270 EP).
Use 1037 for higher-tier card redemption (1380 EP).
Always provide a clear message using 0126 to inform the player whether the card was redeemed.

🧹 Delete Multiple Skills (Type 1039)

⚠️ New Engine Only

Type 1039 is used to permanently delete one or more skills from the player. This type accepts up to 20 skill IDs in the param field. Once a skill is removed using this action, it cannot be restored at its previous level — if the player relearns it, the skill will start again from level 1.

💡 Example SQL – Forget Multiple Skills

-- Permanently remove multiple skills from the player
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1039, 0, '7010 7015 7002 7008 7000 7012 7013 7004 7003 6000 6004 6002 6001 6005 6003 6006 6040 6007 6008 6009');

📘 Parameter Format

type1 type2 ... type20 – A space-separated list of up to 20 skill type IDs (from cq_magictype) to be permanently removed.

📘 Behavior Notes

Skills removed using this action are not recoverable.
If the player relearns the skill using learn, it will restart at level 0.
This is useful for skill resets, class transitions, or rebirth systems.

💡 Tips

Use this type only when you want a clean skill wipe — no backups, no memory of previous levels.
Combine with 0126 messages to alert the player before and after removal.
Consider using 1020 uplevel or addexp afterward if you want to selectively regrant skills at a different progression pace.

🌐 Open Web Page (Type 1041)

Type 1041 is used to notify the client to open a web page in the user's browser. This is useful for directing players to event pages, registration forms, donation portals, patch notes, or community links.

💡 Example SQL – Open External Web Page

-- Open Knightfall Online website
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1041, 0, 'https://knightfall-online.com');

📘 Parameter Explanation

param – The full URL of the web page to open, including http:// or https://.

💡 Tips

Make sure the link is properly formatted and accessible by the client browser.
Ideal for use in NPCs, item interactions, or system announcements that lead players to web-based content.
Can be used to open custom help guides, vote links, or real-time event announcements.

🧨 Drop Magic Skills (Type 1044)

Type 1044 is used to delete specific magic skills from a player, typically during rebirth, skill reset, or class change. You can specify up to 20 skill type IDs in the parameter (for new engine). Skills removed this way are permanent and will restart from level 0 if relearned.

💡 Example SQL – Drop Multiple Skills (New Engine)

-- Remove multiple skills during rebirth
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1044, 0, '17400 17100 17300 17000 18500');

💡 Example SQL – Drop One Skill (Old Engine)

-- Old engine supports only 1 skill per line
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1044, 0, '7012');

📘 Parameter Explanation

type1 type2 ... type20 – Space-separated list of skill type IDs (from cq_magictype).

📘 Engine Support

Old engine: Only 1 skill type can be listed per action.
New engine: Supports up to 20 skill types per line.

💡 Tips

Use during rebirth, job reset, or special quests that wipe specific abilities.
Always inform the player with 0126 messages when deleting important skills.
Combine with 1020 learn or uplevel to rebuild or replace skill sets.

🪟 Open UI Interface (Type 1046)

Type 1046 is used to open a client-side interface (UI dialog) by its ID. The data field determines which interface will appear. Different dialog IDs are supported depending on the engine version.

💡 Example SQL – Open Compose Interface

-- Open dialog ID 37 (Compose UI)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1046, 37, '');

📘 Parameter Explanation

data – ID of the interface/dialog to open on the client.

📘 Supported Dialog IDs

Old Engine:

301, 300, 71, 70, 62, 61, 60, 59, 58, 56, 55, 53, 51, 50, 49, 48, 47, 46, 45, 44, 43,
42, 41, 40, 39, 38, 37, 36, 35, 31, 30, 29, 28, 27, 25, 24, 23, 22, 21, 19, 17, 16,
15, 14, 13, 12, 11, 10, 8, 7, 6, 5, 3, 1

New Engine:

10020, 10002, 10001, 10000, 1041, 927, 918, 917, 701, 602, 501, 421, 420, 419, 418,
415, 412, 410, 301, 300, 122, 121, 81, 80, 79, 74, 72, 60, 59, 58, 56, 55, 53, 49, 
47, 43, 41, 40, 39, 37, 36, 35, 29, 28, 27, 25, 24, 23, 22, 21, 19, 16, 13, 12, 11, 
10, 3, 1

💡 Tips

Make sure the dialog ID is supported by your engine version.
For custom UIs, use new engine IDs like 10000+.

🗺️ Teleport to Main Map Respawn (Type 1052)

Type 1052 is used to teleport the player to the main map’s respawn point. This action will automatically use the map's default revival location, based on the fields reborn_map, portal0_x, and portal0_y set in cq_map for the current map.

💡 Example SQL – Teleport to Main Map Respawn

-- Teleport to the main map's configured respawn point
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1052, 0, '');

📘 Parameter Explanation

No param needed. The system will read reborn_map, portal0_x, and portal0_y from cq_map according to the current map ID.

💡 Tips

This is ideal for auto-respawn or emergency teleport after dungeon runs or failed events.
Ensure the current map has valid values in reborn_map and portal coordinates in cq_map, or the teleport may fail.

🎲 Random Teleport on Current Map (Type 1053)

Type 1053 randomly teleports the player to any valid coordinate on the current map. This can be used for random warp scrolls, escape abilities, or event-based scattering.

💡 Example SQL – Random Teleport

-- Randomly teleport the player somewhere on the current map
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1053, 0, '');

📘 Parameter Explanation

No parameters required. The system automatically selects a valid coordinate within the current map's bounds.

💡 Tips

Useful for escape items, events like treasure hunts, or to create chaos in PvP zones.
Ensure your map has enough walkable terrain, or teleport may land the player in blocked zones.
Can be followed by visual effects using Type 1027 to enhance the teleport animation.

📋 Task Manager (Type 1080)

Type 1080 is used to manage custom task entries for the player. It supports creating tasks, deleting them, and checking if a task already exists. The task number is stored in cq_taskdetail, where its state can also be tracked or modified manually.

💡 Example SQL – Create New Task

-- Create a new task with ID 1114
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1080, 1114, 'new');

💡 Example SQL – Delete Task

-- Delete task ID 1114 from the player's task record
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1080, 1114, 'delete');

💡 Example SQL – Check If Task Exists

-- Check if the player has task ID 1114
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1080, 1114, 'isexit');

-- If task exists
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You task is exist.');

-- If task does not exist
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You task not exist.');

📘 Parameter Format

data – Task number to manage (e.g. 1114).
param – Operation type:
- new – Create a new task entry.
- delete – Delete the task entry.
- isexit – Check if the task exists for the player.

💡 Tips

Use isexit before giving or resetting a task to avoid duplicates.
Combine with 0126 to notify the player if the task was already created or removed.
Task entries created with this type are commonly used for quests, flags, or condition tracking outside of the standard quest system.

⚙️ Task Operations (Type 1081)

Type 1081 is used to operate on internal values of a task created with Type 1080. It can check or update task phase, completion count, or timing data. Useful for multi-stage quests, cooldowns, and advanced task conditions.

💡 Example SQL – Reset Task Start Time

-- Reset the start time of task 1114 to current server time
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1081, 1114, 'begintime reset');

💡 Example SQL – Check Task Phase

-- Check if task 1114 is in phase 3
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1081, 1114, 'phase == 3');

-- If task is in phase 3
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You task currently in phase 3.');

-- If task is not in phase 3
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You task is not in phase 3.');

💡 Example SQL – Add Completion Count

-- Add 1 to the completion count of task 1114
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1081, 1114, 'completenum += 1');

📘 Parameter Format

data – Task ID to operate on. Use -1 to apply on the task returned by findnext.
param – Format is: ope opt value
- phase – Operates on task phase.
- completenum – Operates on completion count.
- begintime – Operates on task start time.
- data1, data2, data3, data4 – Custom data fields for new engine.
opt – Operator used in the operation:
- ==, >= – Compare values
- = – Assign values
- += – Increase value (or add seconds for begintime)
- reset – Only for begintime, resets to current time
value – Can be number (e.g. 3), duration in seconds, or timestamp (yyyy-mm-dd hh:mm:ss)

📘 Notes

You can use this to build complex quest logic with cooldowns, progress stages, or repeatable limits.
Values for phase, completenum, data1–4 have no set limits.
Use data = -1 if you're using findnext and want to operate on its result.

💡 Tips

Use with 0126 to inform the player of their progress or cooldowns.
Use += to advance task phase or increment completion count.
Use reset with begintime to track time-based cooldowns or delays between attempts.

⏱️ Task Cooldown Timer Check (Type 1082)

Type 1082 is used to compare the current server time with the start time of a specific task. It checks whether the time passed since the task began exceeds the given number of seconds. This is useful for cooldowns, waiting periods, or time-limited quest progression.

💡 Example SQL – Check if 5 Minutes (300 seconds) Have Passed

-- Check if at least 300 seconds have passed since task 1114 started
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1082, 1114, '300');

-- If enough time has passed
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You are well-rested and may proceed with your mission.');

-- If not enough time has passed
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You need more rest before continuing. Please come back later.');

📘 Parameter Format

data – Task ID (set with Type 1080).
param – Number of seconds to compare. Returns true if the elapsed time since the task started is greater than this value.

📘 Notes

Set the task's start time using 1081 begintime reset when the task begins.
This action only checks elapsed time; it does not update or modify any task values.

💡 Tips

Perfect for implementing cooldowns, delays between attempts, or real-time waiting mechanics.
Display clear messages using 0126 so players understand when they can retry.
Combine with 1080 and 1081 for full control over task state and timing.

🗂️ Write to Custom Log File (Type 1085)

⚠️ New Engine Only

Type 1085 is used to write custom logs from scripts into a text file. Although originally marked as unused in official sources, it works in practice and allows writing formatted lines into a specified log file. This can be useful for event tracking, race results, or custom admin tools.

💡 Example SQL – Write to Log

-- Write to gmlog/action_log.txt with formatted values
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1085, 0, 'gmlog/action_log 340,%user_name[%user_id],0,0,1,0,124,0,0,0');

📘 Parameter Format

folder/filename – Path to the log file, relative to MSGServer (e.g. gmlog/action_log).
log content – The string to be written. Can include variables like:
- %user_name
- %user_id
Use ~ for spaces in the message (e.g. %user_name~won~the~mount~race).

💡 Customization Tips

You can replace gmlog with any folder name, such as eventlog, and change the filename like mount_race to create eventlog/mount_race.txt.
The folder must exist manually beforehand. If the folder doesn't exist, the log will not be written.
This action does not show any message to the player. It's purely for server-side logging.

💡 Usage Examples

-- Custom win message for event
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1085, 0, 'eventlog/mount_race %user_name~won~the~mount~race!');

📆 Task Day-Based Cooldown Check (Type 1086)

Type 1086 is used to compare the current date with the start time of a specific task. It checks whether the number of full days passed since the task was created is greater than or equal to the given value. This is typically used for daily/weekly reward cooldowns or time-locked progression.

Important: Make sure the task is created first using Type 1080 (new), and its start time is set using Type 1081 (begintime reset).

💡 Example SQL – Require 4 Days Since Task Start

-- Check if 4 days have passed since task 1114 started
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1086, 1114, '4');

-- If 4 days or more have passed
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You can receive reward now');

-- If not enough days have passed
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Sorry! You have received reward, please come after 4 days.');

📘 Parameter Format

data – Task ID created with Type 1080.
param – Number of days to compare. Returns true if current time is greater than or equal to the required days since task start.

📘 Notes

Use Type 1080 to create the task.
Use Type 1081 begintime reset to set the task start time.
This action checks full calendar days, not just 24-hour differences.

💡 Tips

Use this for weekly login rewards, time-gated events, or return-after missions.
Combine with 0126 to inform the player if they can claim or must wait.
Can be used with 1085 to log redemptions when the cooldown expires.

📢 Team Chat Broadcast (Type 1101)

Type 1101 is used to send a custom message to the team chat channel. It allows for dynamic player announcements, progress sharing, or event notifications among team members. Variables like %user_name can be used to personalize the broadcast.

💡 Example SQL – Broadcast Message to Team

-- Broadcast to team: "[PlayerName]: I have completed Fire Tomb 2 times today."
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1101, 0, '%user_name: I have completed Fire Tomb 2 times today.');

📘 Parameter Format

param – The message to send. Can include player variables:
- %user_name – Player's name
- %user_id – Player's ID (optional if needed)

💡 Tips

Use %user_name to personalize messages automatically for the triggering player.
Best used for quest completions, dungeon announcements, event wins, or custom group activities.
This message will only be visible to the player’s current team members, not globally.

👥 Team Attribute Check (Type 1102)

Type 1102 is used to check or operate on attributes of a team. You can check the number of teammates, the level or god level of members, or if specific types of relations like mate or friend are present. If the player is not in a team, the check will return false immediately.

💡 Example SQL – Check if Teammate is Your Mate

-- Check if the player's mate is in the team
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1102, 0, 'mate');

-- If mate is found in the team
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your mate is in your team');

-- If mate is not found
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Your mate is not in your team');

💡 Example SQL – Check Team Size

-- Check if team size is less than 2 (need at least 1 teammate)
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1102, 0, 'count < 2');

-- If not enough teammates
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You need at least 1 teammate');

-- If requirement is met
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You can proceed now');

📘 Parameter Format

param – Format is field opt data depending on the field type.
- level – Compare team member levels. Supports operators: <, >, ==.
- godlev – Compare team member god levels (new engine only). Supports operators: <, >, ==.
- count – Check total number of players in the team (including captain). Supports operators: <, ==.
- count_near – Check number of alive players on the same map. Supports operators: <, ==.
- mate – Check if the player's mate is in the team and alive. No operator needed, only the field name is required (new engine only).
- friend – Check if the player's friend is in the team and alive. No operator needed, only the field name is required (new engine only).

📘 Notes

If no team is formed, count and other checks will immediately return false.
Fields like mate and friend are new engine features and require the players to be alive and near.
Use id_next and id_nextfail properly to branch based on check results.

💡 Tips

Good for event restrictions (e.g., need a team to enter) or special buffs (team with mate gets bonuses).
Combine with 0126 to show clear reasons when blocking player actions.
Can be stacked with team teleportation, buff sharing, or mission entry checks.

🧭 Team Map Teleport (Type 1107)

⚠️ Old Engine Only

Type 1107 is used to teleport an entire team, including the team leader, to a new location. All team members must be alive, and the teleport must happen within the same map group (grouped maps only, not cross-world teleport).

💡 Example SQL – Teleport Team to a New Position

-- Move the entire team to Map ID 8901 at coordinates (35, 48)
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1107, 0, '8901 35 48');

📘 Parameter Format

mapid – Target map ID where the team will teleport.
x – Target X coordinate.
y – Target Y coordinate.

📘 Important Notes

All team members must be alive. Dead members will prevent the teleport.
This only works within the same map group. Cannot teleport across unrelated maps.
The team leader and members will arrive together at the specified position.

💡 Tips

Use for team dungeon entries, multi-player boss rooms, or synchronized event stages.
Always verify that the team meets teleport conditions using checks like 1102 count or count_near before calling this action.
Combine with 1027 visual effects for dramatic entrance effects after teleport.

👑 Team Leader Status Check (Type 1501)

Type 1501 is used to check whether the player is currently the team leader. No parameters are needed for this action. This is useful when you want only the team leader to trigger certain actions like entering dungeons or starting events.

💡 Example SQL – Check Leader Status

-- Check if the player is the team leader
REPLACE INTO `cq_action` VALUES (1000, 1002, 1001, 1501, 0, '');

-- If player is leader
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'You are team leader.');

-- If player is not leader
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'You are not team leader.');

📘 Parameter Format

No parameters are needed. Simply call the action to check leadership status.

📘 Notes

If the player is the team leader, id_next will execute.
If the player is not the team leader, id_nextfail will execute.

💡 Tips

Use this before starting team-only activities like boss fights, dungeon entries, or team rewards.
Always combine with a clear 1010 or 0126 message to inform players why an action is blocked.
You can also pair it with 1102 count to further check if the team has enough members.

🎰 Lottery (Type 1508)

⚠️ data and param format is just my theory,cant find any reference.

Type 1508 is used to trigger a Lottery event related to entries in the cq_lottery table. The action uses data and param fields to specify draw settings, although full behavior depends on server handling and table setup.

💡 Example SQL – Lottery Attempt

-- Trigger a Lottery with color = 1 and type = 5
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 1508, 1, '5');

📘 Parameter Format

data – Assumed to be the "color" field in cq_lottery.
param – Assumed to be the "type" field in cq_lottery.

📘 Notes

Both color and type must match entries inside cq_lottery for the draw to succeed.
The server will search cq_lottery using the color and type values provided and select an appropriate reward randomly.
Exact draw rate, reward item, and amount are controlled inside the cq_lottery database entries.

💡 Tips

Ensure your cq_lottery table is correctly populated and balanced to avoid empty draws.

🧮 User Variable Control (Type 1521,1522,1523,1524)

Types 1521–1524 are used to manage temporary user variables (integer or string) during script execution. These variables are NOT saved into any database. They only exist during the current session and will be lost if the player logs out or if the server restarts. Useful for short-term event tracking, temporary counters, or dynamic scripting without needing database storage.

📘 Type 1521 – Initialize Integer Variable

Initialize an integer variable. You can directly set it to a fixed number or assign a random value within a range.

💡 Example SQL – Set Integer to 0

-- Initialize var(3) to 0
REPLACE INTO `cq_action` VALUES (1000, 1001, 0000, 1521, 0, 'var(3) set 0');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your Integer variable 3 is %iter_var_data3');

💡 Example SQL – Random Assignment (New Engine)

-- Initialize var(2) to random between 10 and 50
REPLACE INTO `cq_action` VALUES (1000, 1001, 0000, 1521, 0, 'var(2) randset 10 50');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your Integer variable 3 randset is %iter_var_data2');

📘 Type 1522 – Operate on Integer Variable

Perform operations on integer variables like adding, dividing, multiplying, or comparing values.

💡 Example SQL – Add 1 to a Variable

-- Increase var(3) by 1
REPLACE INTO `cq_action` VALUES (1000, 1001, 0000, 1522, 0, 'var(5) += 1');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your Integer variable 5 is %iter_var_data5');

💡 Example SQL – Modulo Operation (New Engine)

-- Take var(5) and get remainder after division by 3
REPLACE INTO cq_action VALUES (1000, 1001, 0000, 1522, 0, 'var(5) $= 3');
REPLACE INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Your Integer variable 5 after modulo 3 is %iter_var_data5');

📘 Supported Operators for Integer Variables

== – Compare if equal
+= – Add a value
/= – Divide by a value (New Engine)
*= – Multiply by a value (New Engine)
$= – Modulo (remainder after division) operation (New Engine)

📘 Type 1523 – String Variable Comparison

Compare text variables (not case sensitive). Useful for checking user input, answers, or choice selections.

💡 Example SQL – Compare String

-- Compare if var(8) equals 50
REPLACE INTO `cq_action` VALUES (1000, 1001, 1002, 1523, 0, 'var(8) == Untungla');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your String variable 8 is Untungla');
REPLACE INTO `cq_action` VALUES (1002, 0000, 0000, 0126, 0, 'Your String variable 8 is not Untungla');

📘 Type 1524 – Initialize String Variables

💡 Example SQL – Initialize Text List

-- Set var(3) to "Sembang~Lebat"
REPLACE INTO `cq_action` VALUES (1000, 1001, 0000, 1524, 0, 'var(3) set Sembang~Lebat');
REPLACE INTO `cq_action` VALUES (1001, 0000, 0000, 0126, 0, 'Your string variable 3 is %iter_var_str3');

📘 Notes

var(n) will link to system variables like %iter_var_dataX (integer) or %iter_var_strX (string).
New engine:
- %iter_var_data0 ~ %iter_var_data99 (100 slots for integers)
- %iter_var_str0 ~ %iter_var_str19 (20 slots for strings)
Old engine:
- %iter_var_data0 ~ %iter_var_data9 (10 slots for integers)
- %iter_var_str0 ~ %iter_var_str9 (10 slots for strings)
Random assignment using randset is only available for integers (1521).
String comparison (1523) is case-insensitive.
All values are temporary and will disappear after player relog or server reboot.

💡 Tips

Good for temporary event stages, random rewards, guessing games, or timed puzzles.
Use integer and string combinations for complex in-memory event flow without database load.
Ideal for scripting quick mini-games inside NPC dialogs or event maps.

📦 Save Item Count to Variable (Type 1534)

⚠️ New Engine Only

Type 1534 is used to count how many specific items a player owns, and save the result into a player variable (iter_var_data field).

🧠 Syntax:

data = item_type_id
szParam = "var_id bind_flag"
item_type_id: ID of the item (from cq_itemtype)
var_id: Which iter_var_data[] index to save the count (1-30)
bind_flag:
- 0 = count both bound and non-bound items
- 1 = count only non-bound items
- 2 = count only bound items

📜 Example - Save to var(6):

-- Count all 1111210 items (bound + non-bound), save result into var(6)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1534, 1111210, '6 0');

📜 Example - Save only non-bound items to var(1):

-- Count only non-bound 1111210 items, save into var(1)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1534, 1111210, '1 1');

✅ Quick Notes:

var_id must match an available iter_var_data slot (commonly 1-30).
Useful for checking if player has enough items for quest, upgrade, or event condition.
Use binding flag to separate between bound/unbound inventory checks.

✅ Tip: Combine with conditional checks (Type 2003) after saving item counts to create item requirement logic!

🐲 Eudemon Attribute Check & Modify (Type 1533)

Type 1533 is used to check or modify Eudemon (pet) attributes such as stars, rebirth, luck, god level, and more.

📜 Old Engine Supported Attributes:

star (supports +=, <, >=, ==)
uplevtime (supports +=, <, >=, ==)
rebornlimitadd (supports +=, <, >=, ==)
luck (supports +=, <, >=, ==)
iscallout (supports ==) — Check if summoned or not
alive (supports ==) — Check if Eudemon is dead or alive

🆕 New Engine Additional Supports:

star (+=, <, >=, ==) – can directly increase/decrease stars
rebornlimitadd (+=, <, >=, ==)
luck (+=, <, >=, ==) – ⚠️ New engine: Adjusting luck does NOT affect stars automatically
damagetype (=, ==)
alive (==)
iscallout (==)
egg (==)
godlev (+=, <, >=, ==)
upgodlevtime += value – add divine EXP (multiplying 432)
reborn (+=, >=, ==) – auto updates score
rebornandday (+=) – rebirth limited to once per day

📖 Condition Syntax:

attribute operator value

Example: star >= 30 or alive == 0

⚡ Only ONE condition is allowed per action 1533.

💬 Basic Example – Check if Eudemon is Dead:

-- Check if pet is dead
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1533, 0, 'alive == 0');

-- If dead
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Your eudemon is dead.');

-- If alive
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Your eudemon is alive.');

💡 Other Useful Examples:

-- Add +1 to eudemon rebirth (and auto update rating)
INSERT INTO cq_action VALUES (2000, 0000, 0000, 1533, 0, 'reborn += 1');

-- Check if God Level is at least 5
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1533, 0, 'luck >= 50');

-- If above
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Your eudemon luck is greater than or equal to 50.');

-- If below 
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Your eudemon luck is less than or equal to 50.');

📌 Tips:

Always use one attribute check or operation per 1533 action.
Validate eudemon state (alive, summoned, reborn) before applying upgrades.
Prefer using reborn and rebornandday for new systems instead of manual rebornlimitadd editing.

🧠 Reminder:
In the new engine, luck += 1 does NOT increase pet stars automatically. Use star += if needed.

⚖️ Event Attribute Comparison (Type 2003 & 2004)

Type 2003 and Type 2004 are used to compare system or player attributes dynamically during script execution.

📘 Type Differences:

Type 2003: Signed comparison (normal comparison, can use negative numbers)
Type 2004: Unsigned comparison (only compares positive values)

🧠 Syntax:

data1 opt data2
data1, data2: Must use variable with % symbol (e.g., %user_map_id, %user_map_x, %iter_var_data7)
opt: ==, <, <=

📜 Basic Examples:

-- Type 2003 (Signed) - Allow negative number
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2003, 0, '%iter_var_data7 < -4');

-- Type 2004 (Unsigned) - Positive only
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2004, 0, '%user_map_id == 8971');

✅ Tip: Use Type 2003 when your variable might be negative. Use Type 2004 when comparing IDs, positions, or timers that are always positive.

🐾 Create Monster (Type 2006)

Type 2006 is used to create a monster (or summon) dynamically in the map. You must specify at least 7 parameters. The created monster will exist based on the parameters set.

🧠 Syntax:

nOwnerType idOwner idMap nPosX nPosY idGen idType [nData] [szName]
Minimum 7 parameters are required
idOwner = 0 → The monster will not be saved permanently (temporary summon)
If accept parameter is used, it will rename monster based on accept string
Otherwise, monster uses szName provided at the end

📜 Basic Example:

-- Create a monster without a custom name
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2006, 0, '0 0 %user_map_id 592 486 2013801 20138');

📜 Example with Custom Name:

-- Create a Void Wraith monster with name
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2006, 0, '0 0 %user_map_id 465 637 9639001 12600 0 Void~Wraith');

✅ Parameter Explanation:

nOwnerType: Owner type (0 = no owner, 1 = player, etc.)
idOwner: Owner ID (if 0, monster not saved)
idMap: Map ID to spawn the monster
nPosX / nPosY: Coordinates (X, Y)
idGen: Generator ID (for controlling roaming)
idType: Monster type ID (link to cq_monstertype)
nData: (Optional) Extra data for special behaviors
szName: (Optional) Custom monster name (use ~ instead of spaces)

✅ Tip: Use Void~Wraith format if you want custom monster names (replace spaces with ~).

🏗️ Create New Dynamic NPC (Type 2007)

Type 2007 is used to dynamically create a brand new NPC in the map. The created NPC will be stored in cq_dynanpc, not cq_npc.

🧠 Syntax:

name type sort lookface ownertype ownerid mapid posx posy [life base linkid task0-task7 data0-data3 datastr]
Minimum 9 parameters are required
Maximum 25 parameters supported

📜 Example - Minimum (9 parameters):

-- Create basic blocking NPC
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2007, 0, 'Blocker 2 1 520410 0 0 %user_map_id 185 110');

📜 Example - Full (25 parameters):

-- Create full custom NPC with tasks and extra data
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2007, 0, 'Mallos 154 01 762530 0 0 %user_map_id 64 71 0 0 0 20080250 0 0 0 0 0 0 0 0 0 0 0 0');

✅ Parameter Breakdown:

name: NPC name (use ~ instead of space)
type: NPC type ID
sort: NPC sort (behavior type)
lookface: Appearance ID
ownertype: Owner type (0 = none)
ownerid: Owner ID (0 = none)
mapid: Map ID to spawn
posx / posy: Coordinates (X, Y)
life, base, linkid: Optional extra settings
task0 - task7: Optional task links
data0 - data3: Optional extra data
datastr: Optional string field

💡 Tip: Use minimum 9 parameters if you just need a simple static NPC. Use full 25 parameters if you want NPC linked with tasks, special events, or unique behaviors.

👀 NPC Lookface Direction (52041x)

When creating an NPC, the lookface field controls its appearance and facing direction. It uses the format 52041x where x is the facing direction (0 to 7).

Base lookface comes from ini/npc.ini (example: 52041)
Last digit (0~7) decides the facing direction of the NPC
Without correct direction, NPC might not show properly!

🧭 Basic Direction Guide:

NPC Direction

📸 In-Game Example:

NPC Example

🐉 Check Monster Count (Type 2008)

Type 2008 is used to check the number of monsters in the same map based on their generator ID or monster name. Useful for quests, event triggers, and hunting missions.

🧠 Syntax:

idMap field data opt num
idMap: Map ID or %user_map_id
field: "gen_id" (by generator ID) or "name" (by monster name)
data: Generator ID or Monster Name to check
opt: == or < (equal or less than)
num: Target number to compare

📜 Example - Check if Monster Count is Less Than Target:

-- Check if number of monster generator ID 1000500 is less than 30
INSERT INTO cq_action VALUES (1000, 1001, 1002, 2008, 0, '%user_map_id gen_id 1000500 < 30');

-- If less than 30
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Monster amount is less than 30.');

-- If not
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Monster amount is enough.');

📜 Example - Check if Specific Monster Exists by Name:

-- Check if "Gory" monster is still alive
INSERT INTO cq_action VALUES (1000, 1001, 1002, 2008, 0, '%user_map_id name Gory == 0');

-- If no Gory left
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'No more Gory monsters on map.');

-- If Gory still exists
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Gory monsters still alive.');

✅ Quick Notes:

gen_id: Taken from cq_generator (generator type ID)
name: Taken from cq_monstertype (monster name)
Use id_next and id_nextfail properly to handle success/fail path

✅ Tip: Combine with Type 126 to show friendly system messages after checking monster status!

🗑️ Delete Monster from Map (Type 2009)

Type 2009 is used to delete monsters from a specific map. You can delete based on monster type alone, or both type and monster name together.

🧠 Syntax:

idMap type [data] [name]
idMap: Map ID to delete from
type: Monster type ID (from cq_monstertype)
data: (optional) Extra matching (usually 0)
name: (optional) Specific monster name

📜 Example - Recommended (By Type Only):

-- Delete all monsters of type 23105 from map 1990
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2009, 0, '1990 23105');

📜 Example - By Type and Name:

-- Delete only "Amanyta" monsters of type 23105 from map 1990
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2009, 0, '1990 23105 0 Amanyta');

✅ Quick Notes:

Using only type is faster and more recommended for large map cleanups
Use name if you need to precisely target a specific monster
Type ID is from cq_monstertype table

⚠️ Tip: Always check the monster's type ID correctly to avoid deleting wrong monsters!

🗑️ Delete Dynamic NPC by Type (Type 2011)

Type 2011 is used to delete all dynamic NPCs (cq_dynanpc) of a specific type in a given map. Once deleted, you cannot perform any further operations on them.

🧠 Syntax:

idMap type
idMap: Target map ID or %user_map_id for current user's map
type: NPC type ID to delete

📜 Example - Delete from Specific Map:

-- Delete all NPCs of type 2 from map 1990
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2011, 0, '1990 2');

📜 Example - Delete from Current User's Map:

-- Delete all NPCs of type 23 from current map
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2011, 0, '%user_map_id 23');

✅ Quick Notes:

Only works for cq_dynanpc (dynamic created NPCs)
After deletion, do not attempt to interact with the deleted NPCs
Recommended to use when clearing event NPCs, temporary guards, barriers, etc.

⚠️ Warning: Always ensure the correct type and map ID before running 2011 or you might remove unintended NPCs.

🌎 Run Script for All Players in Map (Type 2012)

Type 2012 is used to make every player inside a specific map execute a specified action script immediately. Useful for mass events, global messages, or sudden teleportation.

🧠 Syntax:

idMap idAction -1
idMap: Target map ID or %user_map_id for current map
idAction: Action ID from cq_action to execute for each player
-1: Always put -1 (purpose unknown but required)

📜 Example - Target Specific Map:

-- Run action 1002 for all players in map 1954
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2012, 0, '1954 1002 -1');

📜 Example - Target Current User's Map:

-- Run action 1002 for all players in user's current map
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2012, 0, '%user_map_id 1002 -1');

✅ Quick Notes:

Make sure the idAction exists in cq_action or nothing will happen.
-1 is mandatory even though its function is unknown.
Useful for teleporting players, sending announcements, or mass event handling.

✅ Tip: Combine with Type 126 (system messages) or teleport actions for smooth mass events!

🧨 Create Trap (Type 2101)

Type 2101 is used to create a trap in the map. Traps are invisible or visible triggers that perform actions when players step into them. Trap types are based on entries from cq_traptype table.

🧠 Syntax:

type look owner_id map_id pos_x pos_y data [pos_cx pos_cy]
type: Trap type ID (from cq_traptype)
look: Appearance (normally 0 if invisible)
owner_id: Owner (0 = no owner)
map_id: Map ID to spawn trap
pos_x / pos_y: Coordinates (X,Y)
data: Special trap data (usually 0)
pos_cx / pos_cy: (New Engine only) – Trap trigger center position offset

📜 Example - Old Engine (7 parameters):

-- Create trap at position (103, 144) on map 1000
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2101, 0, '11506 0 0 1000 103 144 0');

📜 Example - New Engine Extension (9 parameters):

-- Create trap at (103, 144) with center offset (20, 20)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2101, 0, '11506 0 0 1000 103 144 0 20 20');

✅ Quick Notes:

type must match an ID inside cq_traptype
Normally set look = 0 for invisible traps (invisible teleport, triggers, etc.)
Use pos_cx and pos_cy only if using New Engine features (larger trap trigger area)

✅ Tip: Combine traps with teleport actions, condition checks, or monster spawns for dynamic event maps!

🗑️ Delete Trap (Type 2102)

Type 2102 is used to delete (erase) a trap that was created. Once deleted, the trap is permanently removed and cannot be triggered or operated anymore.

🧠 Syntax:

No parameters needed (leave param empty)

📜 Example:

-- Delete the current trap
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2102, 0, '');

✅ Quick Notes:

Only deletes the current trap that is executing the action.
Once deleted, the trap cannot be activated, moved, or modified anymore.
Best used after temporary traps, event triggers, or teleport traps are finished.

⚠️ Warning: Always make sure the trap has finished its purpose before calling 2102 because it cannot be recovered after deletion.

🧮 Check Trap Count (Type 2103)

Type 2103 is used to check the number of traps of a specific type within a defined area of the map. Useful for checking if traps have been activated, removed, or if an area is clear.

🧠 Syntax:

map_id pos_x pos_y pos_cx pos_cy count type
map_id: Target map ID or %user_map_id
pos_x / pos_y: Starting coordinate (X,Y)
pos_cx / pos_cy: Ending coordinate (X,Y)
count: Maximum number of traps allowed
type: Trap type ID (from cq_traptype)

📜 Example:

-- Check if number of trap ID 8839 in area (782,734) is less than 1
INSERT INTO cq_action VALUES (1000, 1001, 1002, 2103, 0, '%user_map_id 782 734 782 734 1 8839');

-- If trap count < 1
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'No traps found in the area.');

-- If trap count >= 1
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'There are still traps active.');

✅ Quick Notes:

Good for checking if traps were triggered, destroyed, or missing after an event.
Use accurate X/Y coordinates to limit the search area precisely.
count is the maximum number allowed. If actual is less, it returns success.
type must match ID inside cq_traptype.

✅ Tip: Combine this with trap erase or teleport traps for smoother map event handling.

🗑️ Delete Trap by Type (Type 2105)

Type 2105 is used to delete all traps of a specific type in a specific map. Once deleted, the traps are permanently removed and cannot be triggered or operated anymore.

🧠 Syntax:

map_id type
map_id: Map ID where traps will be deleted
type: Trap type ID (from cq_traptype)

📜 Example:

-- Delete all traps of type 9525 from map 1000
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2105, 0, '1000 9525');

✅ Quick Notes:

Only traps matching both map_id and type will be deleted.
After deletion, you cannot interact with those traps anymore.
type must match an entry from cq_traptype.
Useful for clearing event-based traps or cleaning maps after events.

⚠️ Warning: Be careful when deleting traps by type — it will remove all matching traps on the map at once!

🛡️ Set Special Status (Type 4001)

Type 4001 is used to apply a special status (buff, debuff, aura, etc.) to the player. Depending on engine version, you can set basic or extended parameters. The status will persist across relogin if saved into cq_special_status table, but will auto-remove after the timer expires.

🧠 Syntax:

Old Engine: status power secs time
New Engine: status power secs time other savedb
status: Status ID
power: Strength or level of effect
secs: Duration in seconds
time: Timer field (normally 0)
other: Reserved (set 0)
savedb: Save into database (1 = yes, 0 = no)

📜 Example - Old Engine (4 Parameters Only):

-- Give status 245 for 86400 seconds (1 day) without database saving
INSERT INTO cq_action VALUES (1000, 0000, 0000, 4001, 0, '245 0 86400 0');

📜 Example - New Engine (Save Status into Database):

-- Give status 245 for 86400 seconds (1 day) and save into cq_special_status
INSERT INTO cq_action VALUES (1000, 0000, 0000, 4001, 0, '245 0 86400 0 0 1');

✅ Quick Notes:

Old Engine: Only supports 4 parameters. Status will disappear after logout if not saved manually elsewhere.
New Engine: Supports up to 6 parameters. Setting savedb = 1 stores the status in cq_special_status.
When stored in database, the status will persist even after logout and relogin — but will auto-delete once secs expires.
status ID must match a valid entry in system settings.

✅ Tip: Use savedb=1 for buffs or event statuses that must survive relogin, but still expire automatically after time ends.

🧹 Delete Special Status (Type 4004)

Type 4004 is used to remove an active player status. If the status is stored in cq_special_status, it can also be deleted from the database by setting DelDB = 1.

🧠 Syntax:

data = unused (use 0)
param = statusID DelDB

📘 Details:

statusID = The ID of the state to remove
DelDB = 1 to delete from cq_special_status, 0 to remove from memory only

📜 Example – Remove status 2000 (from memory only):

REPLACE INTO cq_action VALUES (11000, 0000, 0000, 4004, 0, '2000 0');

📜 Example – Remove status 2000 (from memory + cq_special_status):

REPLACE INTO cq_action VALUES (11001, 0000, 0000, 4004, 0, '2000 1');

📛 Known Stackable Title Statuses:

2000 ~ 2012

⚠️ Warning:

Status effects can stack. Before applying a new title/status, always clear the previous ones to avoid visual or effect overlaps.

📦 Batch Clear Example (All 13 Title Statuses):

-- Clear all known title statuses (2000 to 2012) from cq_special_status and memory
REPLACE INTO cq_action VALUES (12000, 12001, 0000, 4004, 0, '2000 1');
REPLACE INTO cq_action VALUES (12001, 12002, 0000, 4004, 0, '2001 1');
REPLACE INTO cq_action VALUES (12002, 12003, 0000, 4004, 0, '2002 1');
REPLACE INTO cq_action VALUES (12003, 12004, 0000, 4004, 0, '2003 1');
REPLACE INTO cq_action VALUES (12004, 12005, 0000, 4004, 0, '2004 1');
REPLACE INTO cq_action VALUES (12005, 12006, 0000, 4004, 0, '2005 1');
REPLACE INTO cq_action VALUES (12006, 12007, 0000, 4004, 0, '2006 1');
REPLACE INTO cq_action VALUES (12007, 12008, 0000, 4004, 0, '2007 1');
REPLACE INTO cq_action VALUES (12008, 12009, 0000, 4004, 0, '2008 1');
REPLACE INTO cq_action VALUES (12009, 12010, 0000, 4004, 0, '2009 1');
REPLACE INTO cq_action VALUES (12010, 12011, 0000, 4004, 0, '2010 1');
REPLACE INTO cq_action VALUES (12011, 12012, 0000, 4004, 0, '2011 1');
REPLACE INTO cq_action VALUES (12012, 0000, 0000, 4004, 0, '2012 1');

🛡️ Tip: Always clear all title statuses before applying a new one to avoid visual bugs or duplicate effects.

🌀 Force Magic Attack (Type 4002)

⚠️ Old Engine Only

Type 4002 is used to trigger a magic-type effect directly on a player or target. Only specific types of magic (Detach Status or Steal Status) are supported. It is not used for regular damage skills.

🧠 Syntax:

data = magic type ID (from magictype table)
szParam = magic level (optional, usually 0)

📜 Example:

-- Use magic type 5025 (must be MAGICSORT_DETACHSTATUS or MAGICSORT_STEAL)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 4002, 5025, '');

✅ Quick Notes:

MAGICSORT_DETACHSTATUS: Removes buffs or debuffs from the player.
MAGICSORT_STEAL: Steals active buffs from a target.
data must match a valid entry in magictype table with correct magic sort type.
Normal attack magic (damage skills) cannot be used with 4002.
szParam can specify magic level if needed (leave empty if default).

✅ Tip: Use Type 4002 to forcibly clear buffs (detach) or steal buffs (steal) without needing player to manually use skill.

📚 Teach Pet Skill (Type 4003)

⚠️ New Engine Only

Type 4003 is used to teach a specific skill to a Eudemon (pet). This allows controlling which pets can learn which skills and at what level they are allowed to learn.

🧠 Syntax:

data = skill_id × 10
szParam = "skill_id * level_requirement"
skill_id: ID of the skill from cq_magic
level_requirement: Minimum pet level required to learn

📜 Example - Teach Skill 5003:

-- Pet will learn skill 5003 at level 20
INSERT INTO cq_action VALUES (1000, 0000, 0000, 4003, 50030, '5003 * 20');

✅ Quick Notes:

data: Must be skill ID multiplied by 10 (5003 × 10 = 50030)
szParam: Always format as "skill_id * required_level" (example: "5003 * 20")
Use this method to restrict learning certain skills until pet reaches required level.

✅ Tip: Useful for making pet skill progression more balanced and level-gated!

⏳ Start Countdown Timer (Type 8000)

⚠️ New Engine Only

Type 8000 is used to start a countdown timer for a player. When the countdown reaches zero, a specified script will execute automatically. If data = 0, it will close any existing countdown without executing anything.

🧠 Syntax:

data = seconds (duration of countdown)
szParam = action_id (script to execute when countdown ends)

📜 Example - Start 120 Seconds Countdown:

-- Start countdown for 120 seconds, run action 1001 after finish
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8000, 120, '1001');

📜 Example - Stop Countdown Immediately:

-- Stop any existing countdown
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8000, 0, '');

✅ Quick Notes:

Only one countdown can exist per player at a time.
Always close previous countdown before starting a new one to avoid conflicts.
If data=0, it simply closes the countdown without running any script.
Good for time-limited quests, challenges, or event mechanics.

✅ Tip: You can combine with system messages (Type 126) to notify players when a countdown starts or finishes!

⏳ Advanced Countdown Timer (Type 8001)

⚠️ New Engine Only

Type 8001 is an advanced countdown for players, supporting visual effects and interruption controls. It will display a message, optionally show an animation, and execute a script when the countdown ends. Countdown can be interrupted if configured.

🧠 Syntax:

data = seconds (duration of countdown)
szParam = "can_interrupt action_id effect_name display_text"
can_interrupt: 1 = can be interrupted by moving, clicking NPC, using skills; 0 = cannot interrupt
action_id: Action ID to run after countdown ends
effect_name: Visual effect name from 3deffect.ini (use "null" if no effect)
display_text: Text shown during countdown

📜 Example - Simple Countdown:

-- 2 seconds countdown, can interrupt, no effect, shows "Collecting"
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8001, 2, '1 1001 null Collecting');

📜 Example - Countdown with Effect:

-- 5 seconds countdown, cannot interrupt, shows "Pulling out the Holy Sword" with RichGod_Ground effect
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8001, 5, '0 1001 RichGod_Ground Pulling~out~the~Holy~Sword');

📜 Example - Stop Countdown:

-- Stop any existing countdown immediately
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8001, 0, '');

✅ Quick Notes:

Only one countdown can exist per player at a time.
If player interrupts (move/use skill/talk to NPC) and can_interrupt=1, countdown will stop.
effect_name must exist in 3deffect.ini if not set to "null".
display_text spaces must be replaced with ~ symbol.

✅ Tip: Combine this with system messages or teleport scripts for immersive event mechanics!

⏳ Instance Map Countdown (Type 8002)

⚠️ New Engine Only

Type 8002 is used to start a countdown timer specific for players inside a duplicate (instance) map. If the player leaves the map before the countdown ends, the timer is automatically cancelled without executing anything.

🧠 Syntax:

data = duplicate ID (must be from cq_duplicate)
szParam = action_id (script to run after countdown ends)

📜 Example - Start Countdown:

-- Start a countdown linked to duplicate ID 303, execute action 1001 when finished
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8002, 303, '1001');

✅ Important Notes:

Must be used only after teleporting the player into the instance map.
The map ID must be 4000000000+ (special instance maps only).
If player leaves the instance map before timer ends, the countdown will automatically stop without executing the script.
Duplicate map settings are configured in cq_duplicate and Duplicate.ini.
x, y fields in cq_duplicate set the teleport arrival coordinates.
Players already inside instance maps will not be invited again automatically.

⚠️ Tip: Always teleport players into the instance map before running Type 8002 countdown!

🕶️ Hidden Countdown Timer (Type 8003,8005,8006)

⚠️ New Engine Only

Type 8003,8005,8006 is used to start a hidden countdown timer for a player. The countdown will not display any visible time or message on the client's screen. When the countdown reaches zero, a specified action script will execute. Useful for stealth events, traps, or silent triggers.

🧠 Syntax:

data = seconds (duration of countdown)
szParam = action_id (script to run after countdown ends)

📜 Example - Hidden Countdown:

-- Start hidden countdown for 300 seconds, then run action 1001
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8003, 300, '1001');

📜 Example - Stop Countdown:

-- Stop any existing hidden countdown immediately
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8003, 0, '');

✅ Quick Notes:

Hidden countdown will not show any timer to the player.
Only one countdown can exist per player at a time (shared with other countdown types).
If data = 0, it closes the countdown without running the script.
Useful for surprise triggers, timed missions, or background event controls.

✅ Tip: Combine hidden countdown with teleport, spawn monster, or reward actions for surprise events!

🧍 Set Player Pose (Type 8010)

⚠️ New Engine Only

Type 8010 is used to change the player's pose (animation) based on the pose ID. The pose IDs are configured in the 3dmotion.ini file.

🧠 Syntax:

data = pose ID

📜 Example:

-- Set player pose to ID 335
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8010, 335, '');

✅ Common Pose IDs:

Pose ID	Pose ID	Pose ID	Pose ID	Pose ID	Pose ID	Pose ID
100	101	210	233	256	260	261
265	335	351	532	533	534	535
536	537	538	778	779	780	781
782	783	784	851	853

✅ Tip: Use Type 8010 to trigger animations like resting, falling, celebration, or unique reactions during gameplay events!

🗺️ Across Map Auto Path (Type 8011)

⚠️ New Engine Only

Type 8011 is used to initiate an automatic pathfinding movement across different maps. The system will automatically calculate the route based on predefined path information.

🧠 Syntax:

param = mapid x y
mapid: Target map ID
x, y: Target coordinate inside the target map

📜 Example:

-- Auto path to (388,476) on map 1000
INSERT INTO cq_action VALUES (1000, 0000, 0000, 8011, 0, '1000 388 476');

✅ Quick Notes:

cq_acrossmappathinfo must be properly configured in the database for each map jump point.
AcrossMapPathInfo.ini must also be properly configured on the client side to support pathing.
If either setting is missing, the auto-path will fail or the character will stop moving.
This type is useful for quest auto-navigation, long travel auto-walks, or teleport redirection.

✅ Tip: Always double-check cq_acrossmappathinfo and AcrossMapPathInfo.ini entries are correct for smooth auto-path transitions!

🏛️ Celebrity Hall Scripts (Type 230 & 231)

⚠️ New Engine Only

Type 230 and Type 231 are used exclusively for the Celebrity Hall system. They must be performed by Celebrity Hall related NPCs only (Type 100).

🧠 Type Overview:

Type 230: Register for Celebrity Hall
Type 231: Sign up for Celebrity Hall actions
Only used with NPCs in cq_npc ID range 10200 to 11199

📜 Example - Register (Type 230):

-- Register player into Celebrity Hall
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0230, 0, '');

📜 Example - Sign Up (Type 231):

-- Sign up player for Celebrity Hall event
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0231, 0, '');

✅ Quick Notes:

Only Celebrity Hall NPCs should use these types.
General NPCs outside 10200-11199 range should not use these script types.

⚡ Tip: For correct setup, always refer to cq_npc range 10200–11199 and official Celebrity Hall system flow.

🧿 Check Eudemon Celebrity Hall Registration (Type 1067)

⚠️ New Engine Only

Type 1067 is used to check if the player's currently summoned Eudemon has already been registered by another player into the Celebrity Hall for this week. If yes, it will block further registration.

🧠 Syntax:

No parameters needed (param empty)

📜 Example:

-- Check if current summoned Eudemon is already registered
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1067, 0, '');

-- If already registered
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Eudemons that you are currently summon already register in other statues and cannot be re-registered this week!');

✅ Quick Notes:

Only affects the Eudemon currently summoned by the player.
Validation is limited to this week's Celebrity Hall registration.
If already registered, it blocks and shows system message (Type 126).

✅ Tip: Use this before allowing players to submit Eudemons into the Celebrity Hall!

🔥 Register Divine Fire Statue Ranking (Type 232)

⚠️ New Engine Only

Type 232 is used to register the player's ranking into the Divine Fire Statue system. This script type must only be performed by Divine Fire Statue NPCs inside Cronus whic is using type 125.

🧠 Type Overview:

Designed only for Divine Fire Statue system registration.
Must be used by specific NPCs:

NPC ID 12116
NPC ID 12117
NPC ID 12118

Located inside Cronus map.

📜 Example - Divine Fire Registration:

-- Register player into Divine Fire Statue ranking
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0232, 0, '');

✅ Quick Notes:

Do not use this type outside of the Divine Fire Statue NPCs.
Normal NPCs should not use Type 232.
Double-check NPC IDs to match official settings.

⚡ Tip: Always verify that only Divine Fire Statue NPCs (ID 12116, 12117, 12118) are allowed to trigger Type 232!

📍 Run Script for Players in Area (Type 2020)

⚠️ New Engine Only

Type 2020 is used to execute a script on players located inside a specific area on a map. You can define a rectangular zone and choose to affect all players or a limited number of players.

🧠 Syntax:

param = mapid x y cx cy scriptid count
mapid: Target map ID
x, y: Starting coordinates
cx, cy: Area size (coordinate range)
scriptid: Action ID to execute
count:
- -1 = trigger for all players
- Other number = limit to specific number of players

📜 Example - Affect All Players in Area:

-- Trigger action 10519091 for all players inside area (106,406) ~ (118,418) on map 1000
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2020, 0, '1000 106 406 12 12 10519091 -1');

✅ Quick Notes:

The selected area forms a square or rectangle based on x,y and cx,cy.
Use count = -1 if you want to trigger for all players in the zone.
Useful for area events, auto-teleport, mass rewards, or trapping zones.

✅ Tip: Good for dynamic events where players standing inside a zone are affected simultaneously!

🏆 PK Tournament Statue Update (Type 1602)

⚠️ New Engine Only

Type 1602 and NPC Type 126 are used together to manage PK Tournament Statue behavior inside the server. These functions allow updating the PK statue's appearance or settings during PK events.

🧠 Type Overview:

NPC Type 126: PK Tournament Statue type. Editable fields allowed in cq_npc.
Script Type 1602: Updates the PK statue's information if it exists.

📜 Example - Update PK Statue:

-- Update PK Statue info for NPC 12850
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1602, 0, '');

✅ Quick Notes:

This setup only applies to NPC ID 12850.
The PK statue must be created as type = 126 inside cq_npc.
If the statue does not exist when script 1602 runs, no action will be taken.

⚡ Tip: Always make sure PK Statue (NPC 12850) is spawned properly before using Type 1602 to avoid missing updates!

🐉 Delete All Monsters in Map (Type 2015)

⚠️ New Engine Only

Type 2015 deletes all monsters currently existing in the specified map.

🧠 Syntax:

param = mapid

📜 Example:

-- Delete all monsters in map 11052
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2015, 0, '11052');

✅ Notes:

This affects all monsters, regardless of how they were spawned (generator or script).
Use carefully during events or map resets.

🗿 Delete All Dynamic NPCs in Map (Type 2016)

⚠️ New Engine Only

Type 2016 removes all cq_dynanpc entries from the given map. This clears all scripted or event-based NPCs.

🧠 Syntax:

param = mapid

📜 Example:

-- Delete all dynamic NPCs in map 11052
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2016, 0, '11052');

✅ Notes:

Does not affect permanent NPCs from cq_npc.
Good for clearing temporary quest NPCs after completion.

🧨 Delete All Traps in Map (Type 2017)

⚠️ New Engine Only

Type 2017 deletes all traps from the specified map, regardless of type or origin.

🧠 Syntax:

param = mapid

📜 Example:

-- Delete all traps in map 11052
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2017, 0, '11052');

✅ Notes:

Removes everything placed with Type 2101 or related trap scripts.
Best used after time-based trap events or map resets.

🎁 Spawn Item on Map (Type 324)

⚠️ New Engine Only

Type 324 is used to spawn one or more items on the map at a specified coordinate. This can be used as a reward drop, quest item spawn, or map event chest drop.

🧠 Syntax:

Param = idItemType itemCount idMap x y nRange aliveSecs privSecs
idItemType: Item ID from cq_itemtype
itemCount: Number of items to drop (max 100)
idMap: Map ID where item appears (can use %user_map_id)
x, y: Coordinates or dynamic vars like %killmonster_x, %user_pos_x
nRange: Drop radius from center point (max 20)
aliveSecs: Time in seconds before the item disappears
privSecs: Protection time (only owner can pick up)

📜 Example - Drop Item at Monster Death Location:

-- Spawn 30x item 1042068 near kill location, radius 16, lasts 10 minutes, protected for 10 seconds
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0324, 0, '1042068 30 %user_map_id %killmonster_x %killmonster_y 16 600 10');

✅ Quick Notes:

Item ID must exist in cq_itemtype
Max itemCount = 100
Max nRange = 20 tiles
After privSecs, item becomes free-for-all
Use wisely to avoid server lag from mass spawning

✅ Tip: Perfect for dynamic event drops or rewarding players on monster kills or timed events!

👹 Create Advanced Monster (Type 2019)

⚠️ New Engine Only

Type 2019 creates a monster with extended attributes such as HP, damage reduction, and magic power. It's an upgraded version of Type 2018 with more control over the monster's stats.

🧠 Syntax:

nOwnerType idOwner idMap nPosX nPosY nDir idGen idType nHP nDefence2 nSealDevilVal nData szName

📜 Example:

-- Spawn Trial Judge monster with custom HP, defence, and power
INSERT INTO cq_action VALUES (1000, 0000, 0000, 2019, 0, '0 0 %user_map_id 71 67 7 0 43003 100000000 10000 0 0 Trial~Judge');

✅ Quick Notes:

Must include at least the first 10 parameters
nHP: Min value is 1 — server will auto-correct anything lower
idOwner = 0: monster won't be saved
idGen: controls the movement range (from cq_generator, but type field is ignored)
If using accept, monster name will follow accepted value, else use szName

✅ Tip: Great for boss events or scripted monster waves with specific stats and behavior.

🪟 Open UI Window (Type 187)

⚠️ New Engine Only

Type 187 is used to open a specific UI window on the client. This is typically used to trigger interfaces like Divine Furnace or other special panels. The param value is passed to the client and included in the packet, but its purpose is currently unknown.

🧠 Syntax:

data = window ID
param = client-side argument (optional, usage unknown)

📜 Example – Open Divine Furnace:

-- Open Divine Furnace UI (Window ID 13047)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0187, 13047, '0');

✅ Known Window IDs:

13047 – (Divine Furnace)

✅ Quick Notes:

This only affects the client (shows UI window).
Used to trigger panels related to upgrades, events, or systems.
param is included in the sent packet but function unknown (can sniff via packet capture).

✅ Tip: Use this to create shortcut NPCs that trigger in-game upgrade panels or system UIs!

🏯 Open Divine Furnace Stages and Send Extra Info (Type 1601)

⚠️ New Engine Only

Type 1601 is used to send stage unlock and player-specific data to the client, usually after opening the Divine Furnace UI using Type 187. After stage unlocking (1202), two additional info are sent: last dungeon level (1203) and remaining entries (1204).

🧠 Syntax:

szParam = ID data
1202: Stages unlocked (example: 1|2|3|4|5)
1203: Last entered dungeon level (%iter_taskdetail_1data800)
1204: Remaining number of entries (%iter_taskdetail_completenum800)

📜 Full Example - Open UI and Send Data:

-- Step 1: Open Divine Furnace UI
INSERT INTO cq_action VALUES (1000, 1001, 0000, 0187, 13047, '0');

-- Step 2: Send unlocked stages (1 to 5)
INSERT INTO cq_action VALUES (1001, 1002, 0000, 1601, 0, '1202 1|2|3|4|5');

-- Step 3: Send last entered dungeon level
INSERT INTO cq_action VALUES (1002, 1003, 0000, 1601, 0, '1203 %iter_taskdetail_1data800');

-- Step 4: Send remaining entry times
INSERT INTO cq_action VALUES (1003, 0000, 0000, 1601, 0, '1204 %iter_taskdetail_completenum800');

✅ Quick Notes:

1202 - Shows which stages are unlocked
1203 - Displays last dungeon difficulty player entered
1204 - Shows remaining allowed entries
Always use Type 1601 immediately after Type 187 to sync the UI correctly.

✅ Tip: Keep the order correct to avoid client UI desync issues!

🧠 Trigger and Check CAPTCHA (Type 1064 & 1065)

⚠️ New Engine Only

These types are used to implement a CAPTCHA-style quiz system. When triggered, a question will appear on the screen and the player must answer within the given time. You can check whether it's currently active and respond accordingly.

🧠 Script Type Overview:

Type 1065: Trigger CAPTCHA UI, with countdown in seconds
Type 1064: Check if CAPTCHA is currently active

📜 Example – Trigger CAPTCHA:

-- Show CAPTCHA for 99 seconds
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1065, 99, '');

📜 Example – Check CAPTCHA Result:

-- Check if CAPTCHA UI is active, and branch accordingly
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1064, 0, '');

-- If wrong
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You answer wrong');

-- If right
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'You answer right');

✅ Notes:

UI will display a basic math challenge with 20 answer buttons.
Type 1065 defines the active countdown timer.
Type 1064 checks the status and branches result depending on correctness.
Client UI auto-handles input, you only manage logic.

✅ Tip: Great for bot protection, AFK checks, or quick player interaction events!

🚪 Force Logout Player (Type 1066)

⚠️ New Engine Only

Type 1066 is used to forcefully disconnect a player from the server. This script must always be used as the final line in an action chain to prevent unexpected behavior.

🧠 Syntax:

data = 0 (unused)
param = reason for disconnect

📜 Example – Force Disconnect:

-- Kick player with reason "Detected cheating behavior"
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1066, 0, 'Detected cheating behavior');

✅ Quick Notes:

This type immediately disconnects the player.
Always place this as the final action in the sequence.

⚠️ Warning: Use responsibly and only when necessary. Always put as the last action line!

🎯 Run Script on Target (Type 134)

⚠️ New Engine Only

Type 134 is used to run a specific script (action ID) on a targeted player or guild. Only one target condition can be used per call. This is useful for personal rewards, guild triggers, or conditional execution based on name or ID.

🧠 Syntax:

param = [action_id] [target_type] [value]
Target types:

user_id – Player UID (unique account/player ID)
user_name – Exact player name (case-sensitive)
syn_id – Guild ID

📜 Example – Run on Player by ID:

-- Run action 1001 for player with user_id 100000
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0134, 0, '1001 user_id 100000');

📜 Example – Run on Player by Name:

-- Run action 1001 for player named "DuaSelipar"
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0134, 0, '1001 user_name DuaSelipar');

📜 Example – Run on Guild by ID:

-- Run action 1001 for all players in guild ID 10
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0134, 0, '1001 syn_id 10');

✅ Quick Notes:

Only one condition per script call is allowed.
If the condition doesn’t match (e.g., wrong name), the script will not run.
The target script (action ID) must already exist and be valid.
Used in targeted event rewards, name-specific triggers, or guild-wide effects.

✅ Tip: Use this to send private mail rewards, trigger scripts for VIPs, or launch guild-specific events!

⚡ Add Divine EXP to Summoned Divine Pets (Type 1063)

⚠️ New Engine Only

Type 1063 grants divine experience to all currently summoned pets that have evolved into Divine form. The amount of divine experience added is based on a multiplier formula depending on the duration specified.

🧠 Syntax:

data = minutes (length of boost time)
param = empty

📜 Example:

-- Add Divine EXP equivalent to 5 minutes to all active Divine pets
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1063, 5, '');

✅ Calculation:

Divine EXP added = divine EXP rate × 432 × minutes
432 is the system multiplier constant.

✅ Quick Notes:

Only affects summoned pets that have been upgraded to "Divine" status.
Good for implementing divine EXP potions, events, or boss clear rewards.
Setting data = 0 does nothing.

✅ Tip: Perfect for creating power-up items like Divine Energy Potions!

🤝 Team Task Manager (Type 1480)

⚠️ New Engine Only

Type 1480 checks whether team members have accepted a specific task. It operates based on the isexit condition, ensuring task requirements across the team.

🧠 Syntax:

data = task ID
param = [requirement] isexit

1 isexit – All team members must have the task.
0 isexit – Only one team member needs to have the task.

📜 Example – Check All Team Members for Task 1164:

INSERT INTO cq_action VALUES (1000, 1001, 1002, 1480, 1164, '1 isexit');

-- If all have the task
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'All of your team members have accepted this task.');

-- If any member does not have the task
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Some of your team members have not accepted this task.');

✅ Quick Notes:

Only supports isexit condition (task existence check).
Very useful for team-based quests or dungeon entry requirements.

✅ Tip: Combine with team teleport or reward actions to control group quest flow!

👥 Team Task Operation (Type 1481)

⚠️ New Engine Only

Type 1481 is the team version of Type 1081, used to check internal task values (like phase or completion count) across party members. It only supports == and >= operations and must begin with a check mode flag.

🧠 Syntax:

data = task ID
param = [check_mode] field operator value

📘 Parameter Format

data – Task ID to operate on
param – Format: [0/1] field operator value
- 0 = only one member must meet the condition
- 1 = all members must meet the condition
field = task variable
- phase, completenum, data1–data4
operator = only == or >=
value = comparison value

📜 Example – All Members Must Be in Phase 2:

-- Check if all team members have task 1200 in phase 2
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1481, 1200, '1 phase == 2');

-- If all match
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'All team members are in phase 2.');

-- If someone doesn't match
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Someone in your team is not in phase 2.');

📜 Example – At Least One Has completenum >= 5:

-- Check if at least one player has completed 5 times
INSERT INTO cq_action VALUES (2000, 2001, 2002, 1481, 1200, '0 completenum >= 5');

-- If one or more match
INSERT INTO cq_action VALUES (2001, 0000, 0000, 0126, 0, 'Someone in your team has done this 5 or more times.');

-- If no one matches
INSERT INTO cq_action VALUES (2002, 0000, 0000, 0126, 0, 'No one in your team has done this 5 times yet.');

✅ Quick Notes:

Supports only == and >= operators.
Good for team-based stage gating, reward eligibility, or boss challenge locks.
Combine with 0126 to give feedback to players.

✅ Tip: Use this when entering high-level instances where all team members must meet certain conditions.

⏱️ Team Task Cooldown Timer Check (Type 1482)

⚠️ New Engine Only

Type 1482 is the team-based version of Type 1082. It checks whether the cooldown period (in seconds) has passed since the start time of a specific task for one or all team members. Useful for team entry conditions, cooldown gates, and timed challenges.

🧠 Syntax:

data = task ID
param = [0/1] seconds

0 – at least one member must satisfy the time condition
1 – all members must satisfy the time condition

📘 Parameter Format

data – Task ID to check
param – Format: [check_mode] seconds

check_mode: 0 = any member, 1 = all members
seconds: minimum time elapsed since task start

📜 Example – All Members Must Wait 5 Minutes (300s):

-- Check if all members' task 1200 started more than 5 minutes ago
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1482, 1200, '1 300');

-- All passed
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'All of your team may proceed.');

-- At least one did not wait long enough
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Someone in your team must wait longer before proceeding.');

📜 Example – Any One Member Waited Enough:

-- Check if any member passed cooldown
INSERT INTO cq_action VALUES (2000, 2001, 2002, 1482, 1200, '0 300');

-- Success
INSERT INTO cq_action VALUES (2001, 0000, 0000, 0126, 0, 'At least one member is ready.');

-- Failure
INSERT INTO cq_action VALUES (2002, 0000, 0000, 0126, 0, 'No one in your team is ready yet.');

✅ Quick Notes:

Use 1081 begintime reset to set the task start time.
This only checks elapsed time. It doesn’t change task state.
Perfect for time-gated events, group cooldowns, or retry limits.

✅ Tip: Best used for team-based dungeon entry cooldowns or real-time wait logic!

📆 Team Task Day-Based Cooldown Check (Type 1486)

⚠️ New Engine Only

Type 1486 checks if a specified number of full days have passed since the begintime of a task, for all or part of a team. This is the team-based version of Type 1086.

🧠 Syntax:

data = task ID
param = [0/1] days

0 – At least one member must meet the requirement
1 – All members must meet the requirement

📘 Parameter Format

data – Task ID assigned via 1080
param – Format: [check_mode] [day_count]

📜 Example – All Members Must Wait 4 Days:

-- Check if 4 days have passed for all team members
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1486, 1114, '1 4');

-- If all okay
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Everyone in your team can now continue.');

-- If at least one hasn't waited enough
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Someone in your team must wait longer before continuing.');

📜 Example – Any Member Can Proceed:

-- Check if any member waited at least 4 days
INSERT INTO cq_action VALUES (2000, 2001, 2002, 1486, 1114, '0 4');

-- If one or more passed
INSERT INTO cq_action VALUES (2001, 0000, 0000, 0126, 0, 'One of your teammates is ready to proceed.');

-- If no one passed
INSERT INTO cq_action VALUES (2002, 0000, 0000, 0126, 0, 'None of your teammates have reached the cooldown time.');

✅ Notes:

If the player has no party, the check is skipped completely.
Use 1081 begintime reset to initialize the cooldown start time.
This script only checks cooldowns – it doesn’t update or modify task data.

✅ Tip: Great for weekly events or team-locked progression that requires days of wait before retrying.

🆕 New Task Manager (Type 1180)

⚠️ New Engine Only

Type 1180 is used to manage new UI-based task entries. These tasks are displayed in the in-game panel (Story / Daily / Event), and stored in cq_newtaskdetail. It supports creating, deleting, and checking for task existence. It does not trigger any scripts from cq_newtaskconfig.

🧠 Syntax:

data = new task ID
param = new | delete | isexit

📘 Parameter Format

new – Creates a new task entry
delete – Deletes the task entry
isexit – Checks whether the task exists for the player

📜 Example – Create New Task:

-- Create task 2001 (e.g., Beast Hunting)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1180, 2001, 'new');

📜 Example – Delete Task:

-- Remove task 2001
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1180, 2001, 'delete');

📜 Example – Check If Task Exists:

-- Check if task 2001 exists
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1180, 2001, 'isexit');

-- If task exists
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'This task is already active.');

-- If task doesn't exist
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'You don\'t have this task yet.');

✅ Notes:

Task data is saved in cq_newtaskdetail.
This type only manages data; it does NOT trigger scripts from cq_newtaskconfig.
UI will reflect task immediately when created.

✅ Tip: Use Type 1180 to prepare new UI tasks, and combine with Type 1181 to update their status and data.

🛠️ New Task Operations (Type 1181)

⚠️ New Engine Only

Type 1181 is used to manipulate or compare values within cq_newtaskdetail. This is the backbone for progressing new UI-based tasks. You can change phase, mark task complete, set custom counters (like kill count), and reset cooldown timers.

🧠 Syntax:

data = task ID
param = field operator value

📘 Supported Fields:

phase – Task phase or stage
complete – Task completion state
begintime – Time the task started
data1 ~ data10 – Task-specific progress variables

📘 Supported Operators:

== – Equal to (check only)
>= – Greater or equal (check only)
+= – Increment (add number)
= – Assign (set to specific value)
reset – Only for begintime, resets to current time

📜 Example – Increment Kill Count (data1 += 1):

-- Add 1 kill to Beast Hunting Common Beast (task 2001, data1)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1181, 2001, 'data1 += 1');

📜 Example – Set Task to Complete:

-- Mark task 2001 as complete
INSERT INTO cq_action VALUES (1001, 0000, 0000, 1181, 2001, 'complete = 1');

📜 Example – Set Start Time to Now:

-- Reset task 2001 start time
INSERT INTO cq_action VALUES (1002, 0000, 0000, 1181, 2001, 'begintime reset');

📜 Example – Check If Phase >= 3:

-- Conditional check on task phase
INSERT INTO cq_action VALUES (2000, 2001, 2002, 1181, 2001, 'phase >= 3');

-- If true
INSERT INTO cq_action VALUES (2001, 0000, 0000, 0126, 0, 'You have reached phase 3.');

-- If false
INSERT INTO cq_action VALUES (2002, 0000, 0000, 0126, 0, 'You have not reached phase 3 yet.');

✅ Notes:

Used after 1180 new to progress or update task state.
All data is stored in cq_newtaskdetail.
complete should be set to 1 when task is done.
phase is often used for multi-stage growth tasks.

✅ Tip: Use data1~data10 for things like kill count, collection progress, etc. Phase is ideal for story or growth tasks!

⏱️ New Task Cooldown Timer Check (Type 1182)

⚠️ New Engine Only

Type 1182 checks whether a specified number of seconds has passed since the begintime of a new UI-based task stored in cq_newtaskdetail. This is useful for cooldown enforcement, retry restrictions, or time-locked progression.

🧠 Syntax:

data = task ID
param = seconds (e.g. 300 for 5 minutes)

📘 Parameter Format

data – Task ID that has a begintime set
param – Duration in seconds to check against current time

📜 Example – Check if 5 Minutes Have Passed:

-- Check if 300 seconds (5 minutes) have passed since task 2001 started
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1182, 2001, '300');

-- If enough time has passed
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You are well-rested and may proceed.');

-- If not enough time
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'You need to wait a bit longer before continuing.');

✅ Notes:

Use 1181 begintime = now to set start time when task begins.
This action only checks elapsed time — it doesn’t modify task state.
Perfect for real-time delays or retry cooldown logic.

✅ Tip: Combine with Type 1181 to manage cooldown windows and progression delays.

📆 New Task Day-Based Cooldown Check (Type 1186)

⚠️ New Engine Only

Type 1186 checks whether a specified number of full calendar days has passed since the begintime of a new UI task stored in cq_newtaskdetail. This is perfect for time-gated features such as daily rewards, long-term quests, or event re-entry limits.

🧠 Syntax:

data = task ID
param = number of days (e.g. 4 for 4 days)

📘 Parameter Format

data – Task ID assigned using Type 1180
param – Integer number of days since task start

📜 Example – Require 4 Days Since Task 2001 Started:

-- Check if 4 days have passed since task 2001 started
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1186, 2001, '4');

-- If 4+ days have passed
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You are now eligible to proceed.');

-- If not enough days have passed
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'You must wait a few more days before continuing.');

✅ Notes:

Task must be initialized using Type 1180
begintime should be set using Type 1181 begintime reset
This script only checks days – it does not modify any task state

✅ Tip: Best for login rewards, growth quests, or long-term task unlocks that require real waiting periods!

🐲 Check Eudemon Attributes (Type 1971)

⚠️ New Engine Only

Type 1971 is used to check the attributes of a player's eudemons. If at least one eudemon matches all conditions, the result is considered true. The scope of which eudemons are checked depends on the data value.

🧠 Syntax:

data = Eudemon scope (0, 1, or 2)
param = comma-separated attribute checks

📘 Scope (data value):

0 – Only summoned and alive
1 – Summoned (including dead)
2 – All pets (summoned or not, alive or dead)

📘 Supported Conditions:

level – Eudemon level
starlev – Star level
callout – 1 if summoned
godlev – Divine level

📜 Example – Check if Any Summoned Pet Has Level ≥ 20:

-- One of your summoned & alive pets must have level 20+
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1971, 0, 'level >= 20');

-- If condition true
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'At least one of your pets is level 20 or higher.');

-- If condition false
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'None of your pets meet the level requirement.');

📜 Example – Check Combined Conditions:

-- Check if any summoned pet is called out AND star level ≥ 1000 AND not Divine
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1971, 0, 'callout == 1,starlev >= 1000,godlev == 0');

✅ Notes:

Multiple conditions are combined with AND logic.
Only one pet needs to match all conditions to return true.
Useful for unlocking actions based on pet training or Divine evolution.

✅ Tip: Combine with Type 0126 to show messages depending on your pet’s power, star level, or evolution.

👥 New Task Team Manager (Type 1580)

⚠️ New Engine Only

Type 1580 is used to check whether a specified new task exists for players in a party. It works like Type 1180 but supports team-based checking. It only supports the isexit operation.

🧠 Syntax:

data = task ID
param = [check_mode] isexit

0 isexit – At least one member must have the task
1 isexit – All members must have the task

📘 Parameter Format

data: Task ID from cq_newtaskdetail
param: One of:
- 0 isexit – One member is enough
- 1 isexit – All members must have the task

📜 Example – All Members Must Have Task 2001:

-- Check if all team members have task 2001
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1580, 2001, '1 isexit');

-- If true
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'All your team members have accepted the task.');

-- If false
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Someone in your team has not accepted the task.');

📜 Example – Only One Member Required:

-- Check if any member has task 2001
INSERT INTO cq_action VALUES (2000, 2001, 2002, 1580, 2001, '0 isexit');

-- If true
INSERT INTO cq_action VALUES (2001, 0000, 0000, 0126, 0, 'One of your teammates has the required task.');

-- If false
INSERT INTO cq_action VALUES (2002, 0000, 0000, 0126, 0, 'No one in your team has accepted the task yet.');

✅ Notes:

Only works on tasks created with Type 1180 (new UI quests)
Use before entering team-based dungeons or challenge gates
Combine with 0126 to notify player clearly

✅ Tip: Use 1580 to control access to multiplayer content that requires synchronized task progress!

👥 New Task Team Operations (Type 1581)

⚠️ New Engine Only

Type 1581 is the team-based version of Type 1181. It checks whether the values in cq_newtaskdetail for all or some members meet a specified condition. It only supports comparison operators == and >=.

🧠 Syntax:

data = task ID
param = [check_mode] field operator value

0 – Only one team member must meet the condition
1 – All team members must meet the condition

📘 Supported Fields:

phase
data1 ~ data10

📘 Supported Operators:

==
>=

📜 Example – All Members Must Be in Phase ≥ 2:

-- Check if all members have task 2001 at phase 2 or above
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1581, 2001, '1 phase >= 2');

-- If true
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Your entire team has reached phase 2.');

-- If false
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Someone in your team is still below phase 2.');

📜 Example – At Least One Member Has Collected 5 Items (data1):

-- Check if any member has collected 5 or more
INSERT INTO cq_action VALUES (2000, 2001, 2002, 1581, 2001, '0 data1 >= 5');

-- If true
INSERT INTO cq_action VALUES (2001, 0000, 0000, 0126, 0, 'One of your teammates has enough items.');

-- If false
INSERT INTO cq_action VALUES (2002, 0000, 0000, 0126, 0, 'No one in your team has collected enough yet.');

✅ Notes:

Only supports == and >= operators.
Perfect for shared progress validation (e.g. dungeon entry, event boss eligibility).
Combine with Type 0126 to give user feedback.
Only evaluates existing tasks created via Type 1180.

✅ Tip: Good for multi-stage co-op quests where all team members must meet progress conditions!

⏱️ New Task Team Cooldown Timer Check (Type 1582)

⚠️ New Engine Only

Type 1582 is the team-based version of Type 1182. It checks whether the specified cooldown duration (in seconds) has passed since the task begintime for all or some members in the team. Useful for real-time co-op cooldown gates or retry control.

🧠 Syntax:

data = task ID
param = [check_mode] seconds

0 – at least one member must pass
1 – all members must pass

📘 Parameter Format

data – Task ID assigned via Type 1180
param – Format: [0/1] seconds

📜 Example – All Members Must Wait 5 Minutes (300s):

-- Check if 5 minutes have passed for all members
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1582, 2001, '1 300');

-- If passed
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Your team is ready to continue.');

-- If failed
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Someone in your team still needs to wait.');

📜 Example – At Least One Member is Ready:

-- Check if any member waited 300 seconds
INSERT INTO cq_action VALUES (2000, 2001, 2002, 1582, 2001, '0 300');

-- If success
INSERT INTO cq_action VALUES (2001, 0000, 0000, 0126, 0, 'Someone in your team is ready.');

-- If all failed
INSERT INTO cq_action VALUES (2002, 0000, 0000, 0126, 0, 'No one in your team has finished the cooldown yet.');

✅ Notes:

Make sure begintime is set using 1181 begintime reset at task start.
Only checks cooldown time; doesn’t update task values.
Used in real-time retry systems or timed boss access.

✅ Tip: Pair with Type 1186 for calendar-day cooldowns and Type 1581 for team-based phase/data checks!

📆 New Task Team Day-Based Cooldown Check (Type 1586)

⚠️ New Engine Only

Type 1586 checks if a specified number of full calendar days have passed since the begintime of a task (from cq_newtaskdetail) for some or all members in a team. It is the team-based version of Type 1186. If the player is not in a party, no check is performed.

🧠 Syntax:

data = task ID
param = [check_mode] days

0 – at least one member must meet the condition
1 – all members must meet the condition

📘 Parameter Format:

data: Task ID (created using Type 1180)
param: Format: [0/1] [day_count]

📜 Example – All Team Members Must Wait 4 Days:

-- Check if all team members have waited 4 days
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1586, 2001, '1 4');

-- All passed
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Everyone in your team is eligible.');

-- At least one didn’t wait enough
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Someone in your team still needs to wait.');

📜 Example – Any Member Has Waited Enough:

-- At least one member waited long enough
INSERT INTO cq_action VALUES (2000, 2001, 2002, 1586, 2001, '0 4');

-- Passed
INSERT INTO cq_action VALUES (2001, 0000, 0000, 0126, 0, 'Someone in your team is ready.');

-- None passed
INSERT INTO cq_action VALUES (2002, 0000, 0000, 0126, 0, 'No one in your team is ready yet.');

✅ Notes:

If the player is not in a team, this check does nothing.
Uses cq_newtaskdetail.begintime to compare full calendar days.
Task must be initialized with Type 1180 and begintime set via 1181 begintime reset.

✅ Tip: Best for weekly group quests, delayed event entries, or multi-day mission gating.

🔁 Run Script for All Team Members (Type 1412)

⚠️ New Engine Only

Type 1412 is used to trigger a specific action script for all members in the current team, including the one who initiated it. If the player is not in a team, the script will not be executed for anyone.

🧠 Syntax:

data = 0
param = action ID to execute (for all teammates)

📜 Example – Trigger Script 1001 for All Party Members:

-- Execute action ID 1001 for each teammate
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1412, 0, '1001');

📜 Example – Script 1001 (Type 126):

-- Show message to each team member
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'This message was sent to every member of your team.');

✅ Notes:

This is useful for team rewards, synchronized triggers, or team-based cutscenes.
The target action ID (e.g., 1001) must exist and be valid for each player.
Only executes if the player is currently in a team.

✅ Tip: Combine with reward scripts or countdown triggers to sync events across all teammates!

📨 Invitation Dialog with Confirmation (Type 7001)

⚠️ New Engine Only

Type 7001 triggers an invitation-style dialog box for the player, using a message string from strres.ini. A countdown is shown, and if the player confirms before it ends, a predefined script will be executed. This script ID is set server-side via 邀请对话框确认执行脚本 = [ActionID].

🧠 Syntax:

data = message ID (from strres.ini)
param = countdown time in seconds (optional)

📜 Example – Show Dialog with 20 Seconds Countdown:

-- Show invitation dialog with message 5010010, wait 20 seconds
INSERT INTO cq_action VALUES (1000, 0000, 0000, 7001, 5010010, '20');

✅ Server-Side Trigger:

邀请对话框确认执行脚本 = 1001

📜 Example – Confirmation Script (Type 126):

-- Message after player accepts the dialog
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You have accepted the invitation.');

✅ Notes:

If player presses “OK” before countdown ends, confirmation script will be triggered.
If player ignores or closes dialog, no script is executed.
Text is pulled from strres.ini using the ID in data.

⚠️ Tip: Use this for party invites, challenge prompts, entry confirmations, or real-time interactive choices!

🌍 Global Invitation Dialog (Type 197)

⚠️ New Engine Only

Type 197 broadcasts an invitation dialog to all players in a specific map or globally. It uses a message from strres.ini and shows a countdown. If a player confirms before it expires, the server executes a predefined script via 邀请对话框确认执行脚本 = [ActionID].

🧠 Syntax:

data = message ID (from strres.ini)
param = mapid countdown

📘 Examples:

-- Global invitation dialog (all maps), 300s countdown
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0197, 191123, '0 300');

-- Send dialog only to players in map 7000, countdown 300s
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0197, 191123, '7000 300');

✅ Server-Side Setting:

邀请对话框确认执行脚本 = 1001

📜 Example – Confirmation Script (Type 126):

-- Display confirmation message after player clicks "OK"
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You accepted the event invitation!');

✅ Notes:

Only players in the mapid specified will receive the dialog.
If mapid = 0, all online players will receive it.
Use this for real-time events, global raids, boss warnings, etc.
Player must confirm within countdown seconds or script won't run.

🌟 Tip: Use 197 to announce server-wide challenges or dungeon invites with real-time confirmation.

🧛‍♂️ Vampire Awakening Trigger (Type 1964)

⚠️ New Engine Only

Type 1964 is used to activate the Vampire Awakening form. It should only be triggered if the player is not already in the status 1014. This awakening grants enhanced power and visuals for the Vampire class.

🧠 Syntax:

data = 0
param = 0

📘 Prerequisite:

Check if player does NOT already have status 1014 before triggering.

📜 Example – Check Status and Trigger Awakening:

-- If not awakened, trigger awakening
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1964, 0, '0');

✅ Notes:

Status ID 1014 indicates the player is already in awakening mode.
Only use this for characters in the Vampire class (recommended to validate class externally).
This script handles transformation and possible visual changes automatically.

🧛 Tip: Use as part of storyline, reward, or after a PvE challenge to unlock Vampire transformation!

🐲 Custom Eudemon Creator (Type 549)

⚠️ New Engine Only

Type 549 creates a new Eudemon directly in the player's Eudemon backpack with customized stats. You can define its level, divine level, star rating, binding status, and whether it is a necro-type pet.

🧠 Syntax:

data = Eudemon Type ID (e.g. 1071960)
param = level godlevel score [bind] [is_necro]

📘 Parameter Format:

level – Eudemon level (e.g. 81)
godlevel – Divine level
score – Star rating (e.g. 2500 = 25 stars)
bind (optional) – Set to 1 to force bind the pet
is_necro (optional) – Set to 1 to make it a Necro-type Eudemon

📜 Example – Give a 25-Star Divine Eudemon (XO Type):

-- Create a 25-star, divine Level 1 XO-type Eudemon (unbound)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0549, 1071960, '81 1 2500');

📜 Example – Give a Bound Necro-Type Eudemon:

-- Create a 25-star Necro-type Eudemon that is bound to the player
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0549, 1071960, '81 1 2500 1 1');

✅ Notes:

The player must have at least 1 empty Eudemon slot available.
Omitting the 4th param will allow the item pack to decide bind status.
Setting the 5th param to 1 makes it a Necro Eudemon (compatible with "Spirit" fusion).

✅ Tip: Use this type for high-tier pet reward packs, starter bundles, or class-specific unlocks!

📍 Check If Player Is in Cronus Market (Type 1968)

⚠️ New Engine Only

Type 1968 checks if the player is currently located in the Cronus Market map (also known as 雷鸣市场). It requires no parameters and simply returns true if the player is in the correct map.

🧠 Syntax:

data = 0
param = (empty)

📜 Example – Allow Action Only in Cronus Market:

-- Check if player is in Cronus Market
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1968, 0, '');

-- If true
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You are currently in Cronus Market.');

-- If false
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'This feature is only available in Cronus Market.');

✅ Notes:

This only checks the current map — no teleport or movement occurs.
Use before market-exclusive actions, like NPC exchanges or events.
Common Cronus Market Map ID is 1000.

✅ Tip: Use this to restrict actions like pack opening, VIP shops, or trading to the market area only.

📱 Check Mobile Client Login (Type 1969)

⚠️ New Engine Only

Type 1969 checks if the current player is logged in from a mobile client. This is useful for triggering mobile-exclusive content, messages, or limiting features that are not supported on mobile devices.

🧠 Syntax:

data = 0
param = (empty)

📜 Example – Show Message for Mobile Players:

-- Check if player is using mobile client
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1969, 0, '');

-- If mobile
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Welcome mobile player! You are now connected via the mobile client.');

-- If not mobile (likely PC)
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'You are currently using the PC client.');

✅ Notes:

This only checks login source — no effect on gameplay.
Can be used to disable or redirect certain features depending on client type.
No parameters needed beyond data = 0.

✅ Tip: Use this to offer tailored rewards or simplified interactions for mobile users.

📩 Send Broadcast Message (Type 196)

⚠️ New Engine Only

Type 196 sends a pigeon system message (normal or golden). It works like Type 125, but includes the player's name in the param. All spaces in the message must be replaced with ~.

🧠 Syntax:

data = message type:
- 0 = normal pigeon
- 1 = golden pigeon
param = [type] [player_name] [message_with_tildes]

📜 Example:

-- Send golden pigeon (VIP boradcast)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0196, 2017, '1 DuaSelipar[PM] Hello~World');

📜 Example:

-- Send normal pigeon 
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0196, 2017, '0 DuaSelipar[PM] Hello~World');

✅ Notes:

Use ~ instead of spaces in the message content to avoid script parsing errors.

📢 Tip: Combine with rewards or events to directly notify individual players about rare drops, achievements, or wins.

🧭 Auto Pathfinding to NPC (Type 1532)

⚠️ New Engine Only

Type 1532 automatically moves the player to the specified NPC using pathfinding and opens its dialog. Commonly used in guided quests, tutorials, and main storyline scenes.

🧠 Syntax:

data = 0
param = x y npc_id map_id

📜 Example – Auto path to NPC 1034 at (335, 455) in map 1000:

INSERT INTO cq_action VALUES (1000, 0000, 0000, 1532, 0, '335 455 1034 1000');

✅ Notes:

Performs auto pathfinding to the given coordinates and opens the NPC dialog.
Primarily works with static NPCs defined in the cq_npc table.
Supports cross-map navigation — the player will auto-transfer to the target map if needed.
Often used at the end of a cutscene or to guide players during storyline steps.

🐾 Summon Follow Pet / Auto-Loot Assistant (Type 1967)

⚠️ New Engine Only

Type 1967 is used to summon a follow pet (non-Eudemon) that follows the player around and typically auto-collects dropped items. The player must already own the follow pet before this script can successfully summon it.

🧠 Syntax:

data = follow pet ID
param = leave empty

📜 Example – Summon Follow Pet ID 1:

-- Summon follow pet with ID 1 (must be owned)
INSERT INTO cq_action VALUES (1000, 0000, 0000, 1967, 1, '');

✅ Notes:

This is not an Eudemon — it's a cosmetic/helper pet like auto-collector.
If a different follow pet is already active, it will be recalled before summoning the new one.
The follow pet must be owned/unlocked by the player for this to work.

🎬 Play Animation / Visual Effect (Type 194)

⚠️ New Engine Only

Type 194 is used to trigger animation or scripted visual effects from luapartscript.ini. It's typically used for cinematic effects, transformations, special skill triggers, or cutscene visuals.

🧠 Syntax:

data = 0
param = type param1 param2

📘 Known Param Types:

0 0 0 – Likely stops all current effects (optional)
10 0 LuaScriptName – Runs a script from luapartscript.ini
1 effect_id duration – Plays a single effect (e.g. stealth for 8s)

📜 Example – Run Lua Animation Script:

-- Plays Lua script from luapartscript.ini [10]
INSERT INTO cq_action VALUES (1000, 1001, 0000, 0194, 0, '10 0 PerformanceScript_10');

📜 Example – Play Visual Effect (ID 52000) for 10s:

-- This will apply an invisible/stealth-like effect
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0194, 0, '1 52000 10');

📜 (Optional) – Stop Current Effects:

-- Optional: Clear current effect layers
INSERT INTO cq_action VALUES (1000, 0000, 0000, 0194, 0, '0 0 0');

✅ Notes:

Script names like PerformanceScript_10 must be defined inside luapartscript.ini.
Effect IDs like 52000 are internal and engine-specific.
Use to build cutscene sequences, intro effects, or skill unlocks.

✅ Tip: Chain multiple 194 actions for scripted cinematics or epic scene transitions!

🔊 Play Sound Effect (Type 195)

⚠️ New Engine Only

Type 195 plays a sound from SoundRes.ini. It can be used in events, NPC interactions, transformations, or dramatic reveals.

🧠 Syntax:

data = 0
param = sound_id sound_name

📜 Example – Play BGM_State1 (ID 20015):

-- Sound must be defined in SoundRes.ini
INSERT INTO cq_action VALUES (20006403, 0000, 0000, 0195, 0, '20015 BGM_State1');

📘 Example Entry in SoundRes.ini:

[20015]
Sound=sound/BGM_State1.wav

✅ Notes:

Make sure the sound_id and sound name match SoundRes.ini exactly.
This will play client-side and may vary by map or scene.
Supports both music and short effects.

🎧 Tip: Combine with Type 194 for full audiovisual cutscenes or boss intro effects.

🔥 Check Divine Fire Status (Type 1987)

⚠️ New Engine Only

Type 1987 checks whether the player has access to the Divine Fire system. Returns true if it is unlocked and available.

📜 Example:

-- Check if Divine Fire is unlocked
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1987, 0, '');

-- If unlocked
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Divine Fire system is already unlocked.');

-- If locked
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'You have not unlocked the Divine Fire system yet.');

✅ Notes:

No parameters are needed for this check.
Use this to gate access to Divine Fire-related content or upgrades.

🧩 Check Divine Fire Slot (Type 1988)

⚠️ New Engine Only

Type 1988 checks whether a specific Divine Fire slot is open (1–4). Each slot controls 2 grid positions in the interface.

🧠 Syntax:

data = 1 ~ 4 (slot number)

📜 Example – Check if Slot 2 is Open:

INSERT INTO cq_action VALUES (1000, 1001, 1002, 1988, 2, '');

-- If open
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'Slot 2 is already open.');

-- If not open
INSERT INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'Slot 2 is still locked.');

✅ Notes:

Check before upgrades or gear placement in Divine Fire system.

🔓 Unlock Divine Fire Slot (Type 1989)

⚠️ New Engine Only

Type 1989 unlocks a specific Divine Fire slot. This is typically triggered via reward, quest, or item usage.

🧠 Syntax:

data = 1 ~ 4 (slot number to unlock)

📜 Example – Unlock Slot 3:

-- Unlock slot 3
INSERT INTO cq_action VALUES (1000, 1001, 0000, 1989, 3, '');
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You have unlocked Divine Fire Slot 3.');

✅ Notes:

Each slot includes 2 grids — unlocking slot 3 enables grid 5 and 6.
Only works if the Divine Fire system is already unlocked (check with 1987).

🎖️ Check / Unlock / Equip Title (Type 1996, 1997, 1998)

⚠️ New Engine Only

These script types are used to manage player titles based on the title.ini file. Titles are stored in cq_titleid and can be unlocked, equipped, or checked using the following actions:

📘 Type Overview:

1996 – Check if a title is already unlocked
1997 – Unlock a title for the player
1998 – Equip an unlocked title

🧠 Syntax:

data = Title ID (must match title.ini)
param = (leave blank)

📜 Example – Full Chain (Check → Unlock → Equip Title 45):

-- Step 1: Check if title 45 is already unlocked
INSERT INTO cq_action VALUES (1000, 1001, 1002, 1996, 45, '');

-- If unlocked
INSERT INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You have already unlocked this title,please equip in wardrobe.');

-- Step 2: If not unlocked → Unlock it first
INSERT INTO cq_action VALUES (1002, 1003, 0000, 1997, 45, '');

-- Step 3: Equip after unlocking
INSERT INTO cq_action VALUES (1003, 1004, 0000, 1998, 45, '');

💬 Message Feedback (Optional with Type 126):

-- Title equipped
INSERT INTO cq_action VALUES (1004, 0000, 0000, 0126, 0, 'Title equipped successfully.');

✅ Notes:

Title IDs must exist in title.ini
Unlocked titles are saved to cq_titleid
Use 1996 before equipping to avoid invalid equip attempts

✅ Tip: Perfect for achievements, ranking rewards, seasonal events, or permanent unlockable content.

📬 Send Mail to Player (Type 1980)

⚠️ New Engine Only

Type 1980 is used to send mail with attachments (items, EP, PP, Lunar Point) to players. The mail format uses a template from cq_mailtemplate and stores the sent data in cq_mailinfo.

🧠 Syntax:

data = Mail Template ID (from cq_mailtemplate)
param = Mail content (see breakdown below)

📜 Example SQL :

--INSERT INTO cq_action VALUES (1000, 0000, 0000, 1980, 1,'30 5000 4000 3000 754859 1 1 1025491 1 1 751022 1 1 2000 1000'
);

📦 Param Format (in order):

Position	Field	Description	Example
1	saveday	How many days the mail stays. Use `0` = permanent (100 days)	30
2	money	Gold	5000
3	emoney	EP	4000
4	emoney2	PP	3000
5	item1	First item ID to send	754859
6	item1Amount	Amount (must be 1 for equipment)	1
7	item1Lock	`1` = Bound, `0` = Unbound	1
8	item2	Second item ID	1025491
9	item2Amount	Amount	1
10	item2Lock	Bound status	1
11	item3	Third item ID	751022
12	item3Amount	Amount	1
13	item3Lock	Bound status	1
14	moonvalue	Lunar Point	2000
15	starvalue	Star Point	1000

✅ Notes:

Item amount must be 1 for non-stackable items (e.g. equipment).
Use lock = 1 to make items bound to the player.
Only send valid, stackable items or pre-wrapped packs to prevent issues.
All mail content is stored in cq_mailinfo.

✅ Tip: Use this for login rewards, compensation gifts, milestone rewards, or event prize delivery.

🆕 Character Rename (Rerole) Check & Action (Type 1990, 1991, 1992)

⚠️ New Engine Only

This set of scripts is used to allow players to rename their characters, specifically those with default names like rerole[123456]. It includes validation, duplication checks, and rename request logic.

📘 Type Functions:

1990 – Check if player name starts with rerole[ (e.g. rerole[20345])
1991 – Check if the player has already applied for rename
1992 – Apply the rename request (takes effect after maintenance)

📜 Rename Flow – Example SQL Chain:

-- Step 1: Ask for new name input
REPLACE INTO cq_action VALUES (1000, 1001, 0000, 0101, 0, 'Please enter your new name.');
REPLACE INTO cq_action VALUES (1001, 1002, 0000, 0103, 0, '15 1003 New~name:');
REPLACE INTO cq_action VALUES (1002, 4000000, 0000, 0104, 0, '0 0 0');

-- Step 2: Check if current name is in rerole[xxxx] format
REPLACE INTO cq_action VALUES (1003, 1005, 1004, 1990, 0, '');
REPLACE INTO cq_action VALUES (1004, 0000, 0000, 0126, 0, 'Your current name is not a temporary name. Rename is not required.');

-- Step 3: Check if player already applied for rename
REPLACE INTO cq_action VALUES (1005, 1007, 1006, 1991, 0, '');
REPLACE INTO cq_action VALUES (1006, 0000, 0000, 0126, 0, 'You have already submitted a rename request. Please wait for it to be applied.');

-- Step 4: Store new name input into var(0)
REPLACE INTO cq_action VALUES (1007, 1008, 0000, 1524, 0, 'var(0) set %accept0');

-- Step 5: Ask for confirmation (re-type)
REPLACE INTO cq_action VALUES (1008, 1009, 0000, 0101, 0, 'Please enter your new name again.');
REPLACE INTO cq_action VALUES (1009, 1010, 0000, 0103, 0, '15 1011 Re-enter~new~name:');
REPLACE INTO cq_action VALUES (1010, 4000000, 0000, 0104, 0, '0 0 0');

-- Step 6: Compare both entries (var(0) vs second input)
REPLACE INTO cq_action VALUES (1011, 1012, 1014, 1523, 0, 'var(0) == %accept0');

-- Step 7A: If match, apply rename request
REPLACE INTO cq_action VALUES (1012, 1013, 10025049, 1992, 0, '%iter_var_str0');
REPLACE INTO cq_action VALUES (1013, 0000, 0000, 0126, 0, 'Your rename request has been submitted. It will take effect after the next maintenance.');

-- Step 7B: If mismatch
REPLACE INTO cq_action VALUES (1014, 0000, 0000, 0126, 0, 'The two name entries do not match. Please try again.');

✅ Notes:

1990 only allows rename for characters named rerole[xxxx].
1991 prevents duplicate rename requests.
1992 will not instantly rename — it marks the request to be applied after restart/maintenance.
You must input and re-confirm the name to avoid mistakes.

🏷️ Legion Rename (Resyn) Check & Action (Type 1993, 1994, 1995)

⚠️ New Engine Only

This script flow allows legion leaders with default names like resyn[xxxxx] to rename their guild. It checks for leader permission, validates if the name is still default, prevents duplicate requests, and requires confirmation of the new name.

📘 Script Types Used:

1993 – Check if current legion name is resyn[xxx]
1994 – Check if a rename request has already been submitted
1995 – Submit the legion rename request (applies on next maintenance)

📜 SQL Example – Legion Rename Flow:

-- Ask for new legion name
REPLACE INTO cq_action VALUES (1000, 1001, 0000, 0101, 0, 'Please enter your new legion name.');
REPLACE INTO cq_action VALUES (1001, 1002, 0000, 0103, 0, '15 1003 New~legion~name:');
REPLACE INTO cq_action VALUES (1002, 4000000, 0000, 0104, 0, '0 0 0');

-- Only the leader can rename
REPLACE INTO cq_action VALUES (1003, 1005, 1004, 1001, 0, 'ranksshow == 1000');
REPLACE INTO cq_action VALUES (1004, 0000, 0000, 0126, 0, 'Only the legion leader can rename the legion.');

-- Check if name is still resyn[xxx]
REPLACE INTO cq_action VALUES (1005, 1007, 1006, 1993, 0, '');
REPLACE INTO cq_action VALUES (1006, 0000, 0000, 0126, 0, 'This legion already has a custom name. Rename is not required.');

-- Check if rename was already submitted
REPLACE INTO cq_action VALUES (1007, 1009, 1008, 1994, 0, '');
REPLACE INTO cq_action VALUES (1008, 0000, 0000, 0126, 0, 'A rename request has already been submitted. Please wait for the next maintenance.');

-- Save first input
REPLACE INTO cq_action VALUES (1009, 1010, 0000, 1524, 0, 'var(0) set %accept0');

-- Confirm re-entry
REPLACE INTO cq_action VALUES (1010, 1011, 0000, 0101, 0, 'Please enter your new legion name again.');
REPLACE INTO cq_action VALUES (1011, 1012, 0000, 0103, 0, '15 1013 Re-enter~legion~name:');
REPLACE INTO cq_action VALUES (1012, 4000000, 0000, 0104, 0, '0 0 0');

-- Compare both inputs
REPLACE INTO cq_action VALUES (1013, 1014, 1017, 1523, 0, 'var(0) == %accept0');

-- Attempt rename
REPLACE INTO cq_action VALUES (1014, 1015, 1016, 1995, 0, '%iter_var_str0');
REPLACE INTO cq_action VALUES (1015, 0000, 0000, 0126, 0, 'Your legion rename request has been submitted. The new name will take effect after the next maintenance.');
REPLACE INTO cq_action VALUES (1016, 0000, 0000, 0126, 0, 'That name is already taken or invalid. Please choose another.');

-- Name mismatch
REPLACE INTO cq_action VALUES (1017, 0000, 0000, 0126, 0, 'The two name entries do not match. Please try again.');

✅ Notes:

Only the leader (ranksshow == 1000) can rename the legion.
This flow is designed specifically for renaming default-format legions (resyn[xxxxx]).
The rename will take effect after the next server maintenance.
All name inputs are compared using var(0) and 1523.

💡 Tip: You can pair this system with an announcement or mail alert once the rename is successful.

⚔️ Check Legion War Active (Type 193)

⚠️ New Engine Only

Type 193 is used to determine if a Legion War is currently ongoing. It behaves similarly to Type 226.

🧠 Syntax:

data = 0 (required)
param = (leave blank)

📜 Example – Check for active legion war:

-- If legion war is active
REPLACE INTO cq_action VALUES (1000, 1001, 1002, 193, 0, '');

-- If true
REPLACE INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'A legion war is currently in progress!');

-- If false
REPLACE INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'There is no legion war happening right now.');

✅ Notes:

This script returns true if a legion war is ongoing.
Useful for conditionally enabling NPCs, zones, buffs, or messages related to the event.
Can be combined with Type 126 to inform players through dialog.

💡 Tip: Use this script to lock certain features during war hours or activate special buffs/shops for participants only.

📢 Map Broadcast Messages (Type 320 & 321)

⚠️ New Engine Only

These script types are used to send announcements to players within a specific map. Similar to Type 303.

📘 Script Types:

320 – Display message in the bottom-left corner of the screen
321 – Display message in the center of the screen

🧠 Syntax:

data = map ID where the message will be shown
param = message text

📜 Example – Bottom Left Message (Type 320):

-- Show message in lower-left of map 1000
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 320, 1000, 'Legion War has started! Join now!');

📜 Example – Center Screen Message (Type 321):

-- Show center-screen message on map 1000
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 321, 1000, 'BOSS has appeared in the center of the battlefield!');

✅ Notes:

The messages are visible only to players inside the map defined by data.
Best used during war events, boss spawns, or timed PvP announcements.

💡 Tip: Use 320 for passive info (e.g., tips or alerts), and 321 for impactful messages (e.g., countdowns or boss spawn).

🔁 Recall All Summoned Eudemons (Type 1986)

⚠️ New Engine Only

Type 1986 is used to unsummon all currently summoned from the player. This is needed because modern engines no longer auto-recall summoned Eudemons when switching maps.

🧠 Syntax:

data = 0
param = (leave blank)

📜 Example – Unsummon All Pets:

-- Recall all currently summoned (visible) Eudemons
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 1986, 0, '');

✅ Notes:

This only affects summoned Eudemons (main or secondary), not fused or deployed pets.
Useful before teleport, dungeon entry, challenge mode, PvP gate, or cutscenes.
Summon state will need to be reapplied manually if needed after this.

⚠️ Reminder: This does NOT cancel fighting pets or states like fusion — only removes the visual summoned Eudemons.

🧝‍♀️ Servant of the Goddess System (Types 1983, 1984, 1985)

⚠️ New Engine Only

These scripts are used to manage the Servants of the Goddess system. There are two servants: Gift Master (1) and Spirit Master (2). Scripts let you check if they’re activated, activate them, and give them EXP.

📘 Script Overview:

1983 – Check if a servant is activated (data = 1 or 2)
1984 – Activate a servant (data = 1 or 2)
1985 – Add EXP to a servant (data = 1 or 2, param = EXP)

🧪 Example – Check if Gift Master is Activated:

REPLACE INTO cq_action VALUES (16000, 16001, 16002, 1983, 1, '');

-- If activated
REPLACE INTO cq_action VALUES (16001, 0000, 0000, 0126, 0, 'Gift Master is already activated.');

-- If not
REPLACE INTO cq_action VALUES (16002, 0000, 0000, 0126, 0, 'Gift Master is not activated.');

✨ Example – Activate Servants:

-- Activate Gift Master
REPLACE INTO cq_action VALUES (16010, 16011, 0000, 1984, 1, '');
REPLACE INTO cq_action VALUES (16011, 0000, 0000, 0126, 0, 'Gift Master has been activated.');

-- Activate Spirit Master
REPLACE INTO cq_action VALUES (16012, 16013, 0000, 1984, 2, '');
REPLACE INTO cq_action VALUES (16013, 0000, 0000, 0126, 0, 'Spirit Master has been activated.');

📈 Example – Add EXP to Servants (Type 1985):

-- Add 1000 EXP to Gift Master
REPLACE INTO cq_action VALUES (16020, 0000, 0000, 1985, 1, '1000');

-- Add 2500 EXP to Spirit Master
REPLACE INTO cq_action VALUES (16021, 0000, 0000, 1985, 2, '2500');

✅ Notes:

Always check with 1983 before activating using 1984.
EXP via 1985 can be tied to quests, kill rewards, achievements, etc.
You can show progress with 0126 messages or title unlocks.

💡 Tip: Use this for Goddess Trial modes, shrine blessings, or divine mission reward scaling.

⚔️ Set Player PK Mode (Type 1527)

⚠️ New Engine Only

Type 1527 sets the player's PK (player-kill) mode. This allows you to force or script PK mode changes for dungeon rules, arenas, PvP zones, or specific events. Each mode determines who the player can or cannot attack.

🧠 Syntax:

data = unused (set as 0)
param = PK mode (0–5)

📘 PK Mode Reference:

Param	Mode	Description
`0`	Peace Mode	Attack monsters only. Cannot attack any players.
`1`	Team Mode	Attack monsters and players not in your team.
`2`	Capture Mode	Attack monsters, red-named (PK) and blue-named (criminal) players only.
`3`	Free PK Mode	Attack anyone freely without restriction.
`4`	Legion Mode	Attack all except your own legion members.
`5`	Ally Mode	Attack all except your legion and allied legions.

📜 Example – Set Player to Legion Mode (4):

REPLACE INTO cq_action VALUES (17000, 0000, 0000, 1527, 0, '4');

✅ Notes:

This change is immediate and affects combat behavior instantly.
Only affects the local player using the script.
Good for PvP dungeons, special zones, or safe areas (set to 0).

⚠️ Reminder: For event maps or boss zones, always reset PK mode back to 0 (Peace) after exit.

💇‍♂️ Hairstyle Unlock System (Type 1974 & 1975)

⚠️ New Engine Only

These scripts are used to check and unlock character hairstyles. Hair styles are defined in HairData.ini and DressRoomItem.ini (where type = 2).

🧠 Script Functions:

1974 – Check if a specific hairstyle is already unlocked
1975 – Unlock a specific hairstyle

📘 Hairstyle Source:

data = Hairstyle ID (from HairData.ini)
These IDs must exist in DressRoomItem.ini as type 2

📜 Example – Check If Hair 225 Is Unlocked:

REPLACE INTO cq_action VALUES (18000, 18001, 18002, 1974, 225, '');

-- If already unlocked
REPLACE INTO cq_action VALUES (18001, 0000, 0000, 0126, 0, 'This hairstyle is already unlocked!');

-- If not yet unlocked
REPLACE INTO cq_action VALUES (18002, 0000, 0000, 0126, 0, 'This hairstyle is not yet unlocked.');

📜 Example – Unlock Hair 225:

REPLACE INTO cq_action VALUES (18010, 18011, 0000, 1975, 225, '');
REPLACE INTO cq_action VALUES (18011, 0000, 0000, 0126, 0, 'You have unlocked hairstyle 225!');

✅ Notes:

Hairstyles must be listed in both HairData.ini and DressRoomItem.ini (with type 2).
Script can be used as a cosmetic reward, fashion shop feature, or quest unlock.
Use 0126 to notify player about success or already-unlocked status.

💡 Tip: Make sure the hair ID exists in cq_hairinfotype. Once unlocked, the data is stored in cq_hairinfo.

🖼️ Avatar Unlock System (Type 1976 & 1977)

⚠️ New Engine Only

These script types are used to check and unlock player avatar icons (also called head icons or portraits). Avatar data must exist in cq_faceinfotype, and unlocked data is stored in cq_faceinfo.

📘 Script Functions:

1976 – Check if a specific avatar is already unlocked
1977 – Unlock a specific avatar

🧠 Syntax:

data = Avatar ID (must match an entry in cq_faceinfotype)
param = (leave blank)

📜 Example – Check If Avatar ID 85 Is Unlocked:

REPLACE INTO cq_action VALUES (1000, 1001, 1002, 1976, 85, '');

-- If already unlocked
REPLACE INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'This avatar is already unlocked.');

-- If not yet unlocked
REPLACE INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'This avatar is not yet unlocked.');

📜 Example – Unlock Avatar ID 85:

REPLACE INTO cq_action VALUES (1000, 1001, 0000, 1977, 85, '');
REPLACE INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You have successfully unlocked avatar 85!');

✅ Notes:

Avatar IDs must exist in cq_faceinfotype
Unlocked avatars are stored in cq_faceinfo
Ideal for login rewards, battle pass, achievements, or title progression

💡 Tip: Avatar icons are managed using cq_faceinfotype and saved per player in cq_faceinfo.

🐲 Eudemon Skin Unlock System (Type 1972 & 1973)

⚠️ New Engine Only

These script types manage the unlocking of Eudemon Skins. Skins are defined in cq_eudlookinfotype, and once unlocked, are stored in cq_eudlookinfo.

📘 Script Overview:

1972 – Check if a specific Eudemon skin is unlocked
1973 – Unlock a specific Eudemon skin

🧠 Syntax:

data = Skin ID (from cq_eudlookinfotype)
param = (leave blank)

📜 Example – Check If Skin ID 22 Is Unlocked:

REPLACE INTO cq_action VALUES (1000, 1001, 1002, 1972, 22, '');

-- If unlocked
REPLACE INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You have already unlocked this Eudemon skin.');

-- If not unlocked
REPLACE INTO cq_action VALUES (1002, 0000, 0000, 0126, 0, 'This Eudemon skin has not been unlocked yet.');

📜 Example – Unlock Eudemon Skin ID 22:

REPLACE INTO cq_action VALUES (1000, 1001, 0000, 1973, 22, '');
REPLACE INTO cq_action VALUES (1001, 0000, 0000, 0126, 0, 'You have successfully unlocked Eudemon skin 22!');

✅ Notes:

Skin IDs must exist in cq_eudlookinfotype
Unlocks are saved in cq_eudlookinfo
Skins may be tied to limited-time events, promotions, or pet rankings

🌟 Divinize Eudemons (Type 1970)

⚠️ New Engine Only

Type 1970 is used to divinize Eudemons on your character. It targets pets that are summoned/unsummoned (visible or stored).

🧠 Parameters:

data defines the scope of pets affected:

0 — Only summoned and alive Eudemons
1 — Summoned, including dead ones
2 — All pets (summoned or not, alive or dead)

param = stat requirements, must match all to trigger:
- Supports: level and starlev
- Operators: <, >, >=, ==
- Use comma to separate conditions

📜 Example – Apply to All Pets with Level ≥ 1 and Star Level ≥ 4000:

REPLACE INTO cq_action VALUES (21000, 0000, 0000, 1970, 2, 'level >= 1,starlev >= 4000');

✅ Notes:

Used for divine upgrade events, evolution quests, or system unlocks.

📚 Understanding Variables

This section will explain about the types of variables available in the server. Some variables can be modified, while others are read-only and provided by the system.

These variables can be displayed or checked using dialog windows (Type 101), message boxes (Type 126), and other script actions depending on how they are used in the event system.

🛠️ System Variables

📅 %datestamp (New Engine Only)

Description: Returns the current server date in YYYYMMDD format (e.g., 20250427).
Usage: Useful for date-based rewards, daily event locks, or time-limited quests.
Important: Only available in the new engine. The format is intended for internal calculation, not for direct human-readable formatting.

💡 Example SQL – Display Current Date

-- Show the current server date using %datestamp
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%datestamp');

When displayed using a message box (Type 126), it will appear like this:

⚠️ New Engine Only

⏰ %time

Description: Returns the current server timestamp in seconds since Unix epoch (e.g., 1745688972).
Usage: Useful for time-based calculations, cooldown tracking, logging events, or precise timing comparisons.
Important: The timestamp is intended for internal calculations, not formatted for human reading directly.

💡 Example SQL – Display Current Timestamp

-- Show the current server time (timestamp) using %time
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%time');

When displayed using a message box (Type 126), it will appear like this:

🌟 %maxeudemon_starlev (New Engine Only)

Description: Returns the maximum Eudemon star limit setting. The value is stored as an integer, where 30000 means 300.00 stars.
Usage: Useful for comparing pet growth, setting evolution limits, or informing players about star caps in events or promotions.
Important: Only available in the new engine. The maximum star value can be modified in the server MSG settings.

💡 Example SQL – Display Maximum Eudemon Star Level

-- Show the maximum allowed Eudemon star level
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%maxeudemon_starlev');

When displayed using a message box (Type 126), it will appear like this:

⚠️ New Engine Only

📆 %date_ywday1 ~ %date_ywday7

Description: These variables return the current week number based on a custom week start setting. Counting starts from 2018-01-01.
Usage: Useful for weekly events, reset timers, reward tiers, or weekly PVP rankings.
Format: The value returned is a positive integer indicating how many full weeks have passed since your chosen day-of-week reference point.

📘 Variable Explanation:

Variable	Meaning	Week Start Day
`%date_ywday1`	Weekly index if your week starts on Monday	Monday
`%date_ywday2`	Weekly index if your week starts on Tuesday	Tuesday
`%date_ywday3`	Weekly index if your week starts on Wednesday	Wednesday
`%date_ywday4`	Weekly index if your week starts on Thursday	Thursday
`%date_ywday5`	Weekly index if your week starts on Friday	Friday
`%date_ywday6`	Weekly index if your week starts on Saturday	Saturday
`%date_ywday7`	Weekly index if your week starts on Sunday	Sunday

💡 Example SQL – Weekly Reset Check (Week Starts on Tuesday):

-- This shows how many weeks have passed since 2018-01-01, treating Tuesday as start of the week
REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'Week Index (Tuesday Start): %date_ywday2');

🧠 Tip: Use different %date_ywdayX depending on which day you want your server's week to begin (e.g., Monday for school ranking, Sunday for arena season).

🎒 Item Variables

📦 %item_type

Description: Returns the item type ID of the current item. Must be an item listed in cq_itemtype.
Usage: Used for identifying item categories, specific item checks, or triggering item-based events.
Important: When checking player-owned items, the value comes from the TYPE field in cq_item table.

💡 Example SQL – Display Item Type

-- Show the item type using %item_type
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%item_type');

🛠️ %item_data

Description: Returns the item data value of the current item. Must be an item listed in cq_itemtype.
Usage: Used for basic item checks involving item data field.
Important: When checking player-owned items, the value comes from the data field in cq_item table.

💡 Example SQL – Display Item Data

-- Show the item data using %item_data
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%item_data');

🧙‍♂️ NPC Variables

NPC Variables are used to retrieve information about static or dynamic NPCs in the server. The NPC must exist in cq_npc or cq_dynanpc to access these variables.

🔧 Tip: To modify or update NPC attributes, please refer to Check or Modify NPC Attributes (Type 201 & 206).

🏷️ %datastr

Description: Returns the datastr field from the NPC record. It can contain letters and numbers.
Usage: Useful for storing text codes or custom NPC properties.

💡 Example SQL – Display NPC DataStr

-- Show the datastr field using %datastr
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%datastr');

🔢 %data0 ~ %data3

Description: Returns numeric values from the data0 to data3 fields of the NPC.
Usage: Useful for custom configurations like NPC type behavior, event triggers, or dynamic settings.

💡 Example SQL – Display NPC Data0

-- Show data0 field using %data0
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%data0');

🧾 %name

Description: Returns the name of the NPC.
Usage: Display the NPC name dynamically in messages or dialogs.

💡 Example SQL – Display NPC Name

-- Show NPC name using %name
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%name');

🆔 %id

Description: Returns the unique ID of the NPC.
Usage: Useful for identification and targeting in custom scripts.

💡 Example SQL – Display NPC ID

-- Show NPC ID using %id
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%id');

📍 %npc_x and %npc_y

Description: Returns the X and Y coordinates of the NPC on the map.
Usage: Useful for teleportation systems, event placement, or dynamic map interactions.

💡 Example SQL – Display NPC Coordinates

-- Show NPC X and Y positions
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'X: %npc_x Y: %npc_y');

👤 %npc_ownerid

Description: Returns the player ID that owns the NPC (used for summoned or dynamic NPCs).
Usage: Useful for pet systems, summoned guards, or player-owned dynamic objects.

💡 Example SQL – Display NPC Owner ID

-- Show the owner ID using %npc_ownerid
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%npc_ownerid');

❤️ %npc_maxlife

Description: Returns the maximum life/HP value of the NPC.
Usage: Used in battle systems, pet management, or boss status displays.

💡 Example SQL – Display NPC Max Life

-- Show maximum life using %npc_maxlife
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%npc_maxlife');

🗺️ %npc_mapid (New Engine Only)

Description: Returns the map ID where the NPC is located.
Important: Only available in the new engine version.

💡 Example SQL – Display NPC Map ID

-- Show NPC's current map ID
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%npc_mapid');

⚠️ New Engine Only

🆕 %newdata1 ~ %newdata8 (New Engine Only)

Description: Returns numeric values from extended dynamic NPC data fields. Available only in the new engine.
Usage: Useful for additional properties, event states, or advanced dynamic NPC behaviors.

💡 Example SQL – Display New Numeric Data

-- Show new numeric field using %newdata1
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%newdata1');

⚠️ New Engine Only

🆕 %newdatastr1 ~ %newdatastr2 (New Engine Only)

Description: Returns string values from extended dynamic NPC string fields. Available only in the new engine.
Usage: Useful for saving special string data like names, statuses, event codes, or owner information.

💡 Example SQL – Display New String Data

-- Show new string field using %newdatastr1
REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%newdatastr1');

⚠️ New Engine Only

🧑‍💼 User Variables

User Variables are used to retrieve information about the player character. This includes identity, position, name, legion information, and other player-specific attributes. Some variables are only available in the new engine version.

🆔 %user_id

Description: Returns the player's unique user ID.
Usage: Useful for identification, tracking, and ownership systems.

💡 Example SQL – Display User ID

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%user_id');

🗺️ %user_map_id / %user_map_x / %user_map_y

Description: Returns the current map ID and the player's X, Y coordinates on the map.
Usage: Useful for teleport systems, event zone checks, and movement tracking.

💡 Example SQL – Display Map and Coordinates

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Map: %user_map_id, X: %user_map_x, Y: %user_map_y');

🏠 %user_home_id (Old Engine Only)

Description: Returns the player's home map ID. Available only in old engine versions.

💡 Example SQL – Display Home Map ID

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%user_home_id');

🏰 %syn_id / %syn_name

Description: Returns the player's legion (guild) ID and name if they belong to one.

💡 Example SQL – Display Legion Info

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Legion: %syn_name (%syn_id)');

🧑 %user_name / %mate_name

Description: Returns the player’s character name and their mate’s name (if married).

💡 Example SQL – Display Character Name

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Name: %user_name / Mate: %mate_name');

📍 %map_owner_id / %map_owner_type

Description: Returns the owner ID and owner type of the current map.

💡 Example SQL – Display Map Ownership

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Map Owner ID: %map_owner_id, Type: %map_owner_type');

🤝 %ally_syn0 ~ %ally_syn4 / %enemy_syn0 ~ %enemy_syn4 (Old Engine Only)

Description: Returns allied or enemy legion IDs. Available only in the old engine.

💡 Example SQL – Display Alliance and Enemy Syn IDs

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Ally0: %ally_syn0, Enemy0: %enemy_syn0');

🎓 %tutor_exp / %student_exp (Old Engine Only)

Description: Returns mentor (tutor) and student contribution experience points.

💡 Example SQL – Display Mentor/Student EXP

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Tutor EXP: %tutor_exp, Student EXP: %student_exp');

🧿 %user_sealmagic (New Engine Only)

Description: Returns the player's current Seal Magic power.

💡 Example SQL – Display Seal Magic Power

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%user_sealmagic');

⚠️ New Engine Only

🎚️ %user_level (New Engine Only)

Description: Returns the player’s current level.

💡 Example SQL – Display User Level

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%user_level');

⚠️ New Engine Only

⚡ %user_bp (New Engine Only)

Description: Returns the player’s Battle Power (BP) value.

💡 Example SQL – Display Battle Power

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, '%user_bp');

⚠️ New Engine Only

🏆 %halloffamerank

Description: Celebrity Hall ranking. Returns 0 if not ranked.

💡 Example SQL – Check HoF Rank

REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'Your Celebrity Hall Rank: %halloffamerank');

🔥 %godfirerank

Description: Rank among the 3 Divine Fire Statues.

💡 Example SQL – Check God Fire Rank

REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'God Fire Rank: %godfirerank');

🟡 %currentfirepoint

Description: Current score of the Divine Fire equipped on the player.

💡 Example SQL – Show Current Divine Fire Score

REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'Current Fire Score: %currentfirepoint');

💀 %killusertarget_name / %killusertarget_id

Description:Name and ID of the last player killed (or who killed you).

💡 Example SQL – Show Last PK Target Info

REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'You last killed: %killusertarget_name (ID: %killusertarget_id)');

🔥 %firelev

Description: Divine Fire Realm Level.

💡 Example SQL – Check Fire Level

REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'Your Divine Fire Realm Level: %firelev');

🔥 %firepoint

Description: Player's historical highest Fire Score.

💡 Example SQL – Display Highest Fire Score

REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'Highest Fire Score: %firepoint');

🎯 %bonuspoint

Description: Displays the character’s bonus point total.

💡 Example SQL – Display Bonus Points

REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'Your Bonus Points: %bonuspoint');

👑 %allgoddesslevel

Description: Total goddess tier level sum. Returns 0 if no goddess is unlocked.

💡 Example SQL – Display Goddess Total Tier

REPLACE INTO cq_action VALUES (1000, 0000, 0000, 0126, 0, 'Total Goddess Tier: %allgoddesslevel');

⚔️ PK Event Variables

PK Event Variables are used specifically inside Daily, Weekly, or Monthly PK Tournament events. These variables help track player performance such as kill count and experience rewards during PK matches.

⚔️ %pkgame_user_kill

Description: Returns the number of enemy players the user has killed during a PK tournament match.
Usage: Useful for calculating rewards, ranking, or progression inside PK tournaments.

💡 Example SQL – Display PK Kill Count

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'PK Kills: %pkgame_user_kill');

🎖️ %pkgame_user_balance_exp

Description: Returns the experience points rewarded to the player at the end of a PK tournament match.
Usage: Useful for balancing event rewards or displaying end-of-event results.

💡 Example SQL – Display PK Balance EXP

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'PK Balance EXP: %pkgame_user_balance_exp');

🛡️ Legion Variables

⚠️ New Engine Only

Legion Variables are used inside the legion system. These variables allow checking and interacting with legion resources such as available funds, ranks, or contributions.

💰 %available_fund

Description: Returns the amount of legion fund available for allocation or distribution.
Usage: Useful for legion management systems where leaders or officers need to distribute resources among members.

💡 Example SQL – Display Available Legion Fund

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Available Legion Fund: %available_fund');

🗺️ Map Variables

⚠️ New Engine Only

Map Variables are used to manage map-specific data during gameplay. Some variables are temporary and exist only in server memory, while others are permanent based on database information.

🧮 %map_iter_var_data0 ~ %map_iter_var_data19

Description: Temporary numeric values stored per map (index 0 to 19).
Important: These values are not saved into the database. They exist only inside MsgServer memory. After server restart, all values reset to 0. You must set the value manually. To modify these variables, use Map Variable Actions (Types 316, 317, 318, 319).

💡 Example SQL – Display Map Data Variable

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Map Data 0: %map_iter_var_data0');

📝 %map_iter_var_str0 ~ %map_iter_var_str19

Description: Temporary string values stored per map (index 0 to 19).
Important: These values are not saved into the database. They exist only inside MsgServer memory. After server restart, all values reset to empty. You must set the value manually. To modify these variables, use Map Variable Actions (Types 316, 317, 318, 319).

💡 Example SQL – Display Map String Variable

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Map String 0: %map_iter_var_str0');

🧭 %backmapid / %backmap_x / %backmap_y

Description: Returns the backup map ID and X, Y coordinates configured for the map.
Note: These values are stored inside cq_map database table.

💡 Example SQL – Display Backup Map Information

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Backmap ID: %backmapid, X: %backmap_x, Y: %backmap_y');

🌍 %mapid / %map_name

Description: Returns the current map ID and map name where the player or NPC is located.
Note: These values are stored inside cq_map database table.

💡 Example SQL – Display Map ID and Name

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Map ID: %mapid, Map Name: %map_name');

🌍 Global Variables

⚠️ New Engine Only

Global Variables are used to store server-wide persistent values. These variables are shared across all players, maps, and events. Numeric variables use the cq_vardata table, while string variables use the cq_varstrdata table. To modify these variables, refer to Global Variable Control (Type 191 & 192).

🧮 %public_var_data1 ~ %public_var_data99

Description: Global numeric variables stored in cq_vardata. Supports index 1 to 99.
Usage: Useful for server event tracking, counters, server-wide settings, or broadcast states.

💡 Example SQL – Display Global Numeric Variable

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Global Data 0: %public_var_data1');

📝 %public_var_str1 ~ %public_var_str99

Description: Global string variables stored in cq_varstrdata. Supports index 1 to 99.
Usage: Useful for server-wide flags, notices, event statuses, or admin messages.

💡 Example SQL – Display Global String Variable

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Global String 0: %public_var_str1');

👹 Monster Variables

⚠️ New Engine Only

Monster Variables are used to retrieve the position (X, Y coordinates) where a monster was killed. These variables are only available during monster death event triggers. Must be placed on monster kill actions.

📍 %killmonster_x / %killmonster_y

Description: Returns the X and Y coordinates where the monster was killed.
Usage: Useful for spawning rewards, teleport points, or triggering special effects at the kill location.
Important: Must be used inside scripts related to monster events (e.g., after monster killed).

💡 Example SQL – Display Monster Kill Coordinates

REPLACE INTO `cq_action` VALUES (1000, 0000, 0000, 0126, 0, 'Kill Position: %killmonster_x / %killmonster_y');

Pose ID	Pose ID	Pose ID	Pose ID	Pose ID	Pose ID	Pose ID
100	101	210	233	256	260	261
265	335	351	532	533	534	535
536	537	538	778	779	780	781
782	783	784	851	853

Pose ID	Pose ID	Pose ID	Pose ID	Pose ID	Pose ID	Pose ID
100	101	210	233	256	260	261
265	335	351	532	533	534	535
536	537	538	778	779	780	781
782	783	784	851	853

CQ_Action Guide

Eudemons Online cq_action Table Guide

What is cq_action?

Field Explanations

Common Action Types

Download Full Action Types

Action Type Guides

💡 Example SQL:

🧾 Required Task Entries (cq_task)

📘 Explanation Table:

💡 Tips:

🖼️ Example: Linleria Dialog

📜 Linleria SQL

🖼️ Example: Skuld Dialog

📜 Skuld SQL

⚠️ Important Notes

📜 Basic Example – Type 501 (Give Item)

📜 Custom Stats – Type 501

📌 Special Variants:

💡 Tips:

📦 Syntax Behavior

📜 Example: Delete Single Quantity by Item Type

📜 Example: Delete Stack of Items

📜 Example: Delete Unstackable Items (Repeat Action)

📜 Example: Delete Items by Name

✅ For Stack Items: Use Type 540 (Recommended)

💡 Best Practice:

📦 Syntax Behavior

📜 Example 1: Check If Player Has 5x of Item

📜 Example 2: Check If Player Has Item (No Quantity Required)

📜 Example 3: Check by Item Name

💡 Notes:

💡 Example SQL:

📘 Supported Attributes & Operators:

🎯 Type 121 – Random Chance

🔀 Type 122 – Random Action Select

🖼️ Example Output:

💡 Example SQL:

📌 Notes:

💡 Example SQL:

📸 Broadcast Styles:

💡 Example SQL:

📘 Message Channels (data values):

⚠️ Behavior Notes:

🧠 param format:

📦 Supported pack_type Values:

💡 Example Usage:

🧠 param format:

📆 Supported Time Types (data values):

💡 Examples:

🔗 Reference:

🖼️ Example Display:

📜 Example SQL Script:

🔧 Usage:

🖼️ Example Display:

🧠 param format:

💰 Pricing:

💡 Example SQL:

📝 Use Case Ideas:

📌 Parameter Breakdown:

💬 Example: Temporary Dialog (data = 204)

🧩 Parameter Breakdown (dialog format):

📜 Alternate Example:

🌐 Example: Open In-Game Website (data = 202)

🌐 Parameter Breakdown (browser format):

📏 Browser Window Sizes:

📌 Type 191 – Numeric Variables (cq_vardata)

📤 Show numeric value to player (example):

📌 Type 192 – Text/String Variables (cq_varstrdata)

📤 Show string value to player (example):

🔁 Type 201 — Check or Modify (Same Thread)

📜 Example – Conditional Check:

📜 Example – Modify data field:

🧠 Syntax:

✅ Supported Attributes:

✏️ Type 206 — Modify Only (Cross Thread)

📜 Example:

🧠 Syntax:

⚙️ Supported Attributes:

📜 New Engine Example:

Eudemons Online `cq_action` Table Guide

What is `cq_action`?

✅ For Stack Items: Use `Type 540` (Recommended)

📦 Supported `pack_type` Values:

📆 Supported Time Types (`data` values):

📌 Type 191 – Numeric Variables (`cq_vardata`)

📌 Type 192 – Text/String Variables (`cq_varstrdata`)

Pose ID	Pose ID	Pose ID	Pose ID	Pose ID	Pose ID	Pose ID
100	101	210	233	256	260	261
265	335	351	532	533	534	535
536	537	538	778	779	780	781
782	783	784	851	853