Compilation can establish that a particular input was accepted by a particular toolchain. It does not establish that the running server loaded the new output, that your character is in the expected quest state or that the event conditions are true.
Trace one event on a staging character
Choose one action that should trigger the quest. Write down the expected event, NPC/item/map if relevant, quest state and conditions. Verify each assumption separately before broadening the test. Avoid using a real player's progress as disposable test data.
Quest identity:
Source and generated-output revision:
How the running server loads that output:
Expected event and target:
Expected state:
Conditions expected to be true:
Observed log/visible result:
Next state or flag expected after success:Reduce the branch
Use a small diagnostic path that records whether execution reached the event and then whether each condition passed. Use only logging or feedback functions available in your own branch. Remove or guard temporary diagnostics before release.
If you use a wrapper to rebuild quests, determine whether it rebuilds everything or only listed/changed files. A targeted test can save time, but only if you preserve preprocessing and dependencies required by that project. Keep a backup of generated output and document the deployment/loading procedure you used.
Do not confuse quest syntax with plain Lua
Metin2 quest files commonly include quest/state/event constructs handled by the quest compiler. A desktop Lua syntax checker is not automatically a substitute for that compiler. Check the language/toolchain used by the source you actually operate.
References
An Elitepvpers debugging guide provides historical context for isolating quest work. An explanation of the quest language provides background on its compiler stage. The trace template here is original; verify commands and functions against your own build rather than copying historical setup instructions.