Skip to content

Conversation

@davidklaw
Copy link
Contributor

@davidklaw davidklaw commented Jul 31, 2025

Problem

Players often receive no feedback when they fail to meet the requirements for a quest, making it unclear whether they’re on the right track or missing something.

Solution

This update adds support for restriction hints when a player can’t progress in a quest. It applies only to message quests, where the player speaks to an NPC and expects a response. These hints are designed to clarify why the player is ineligible (e.g., not enough hitpoints, missing a spell, etc.), and can be overridden on a per-node basis if needed.

Video Walkthrough

Technical Implementation Details

  1. Enhanced CheckPlayerCriteria: Modified from returning simple TRUE/FALSE to returning:
    • TRUE if player is eligible
    • FALSE if no restrictions apply
    • Restriction ID if player fails a specific requirement
  2. New feedback logic: When CheckCompletionCriteria determines a quest node is waiting for a player, it now:
    • Handles CheckPlayerCriteria returning a restriction ID by looking up the corresponding hint message and sending it to the player.
  3. Hint system:
    • Default hints have been added for all quest restriction types
    • Special token replacement for dynamic hints (e.g. hp requirements, spell counts, karma)
    • Override capability in quest node templates for more unique responses

Closes #741
Closes #491

Q_R2_NUM_AMULETS = 8 % [Q_R2_, minNumAmulets]
Q_R2_HAS_HEALTH_LEVEL = 9 % [Q_R2_, minHPs] (calls GetMaxHealth)
Q_R2_DOES_NOT_HAVE_ITEM = 10 % [Q_R2_, itemclass]
Q_R2_QN_ASSIGNABLE = 0xB0 % [Q_R2_, boolean] (is this quest in an assignable state?)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These hex values were updated to avoid ID conflicts when mapping restriction types to their hint messages.

@davidklaw
Copy link
Contributor Author

Added a video walkthrough to the PR description.

@davidklaw
Copy link
Contributor Author

During testing I found an edge case with the TRADING_POST quest: two message nodes (good/evil karma paths) share the same trigger word, and if eligibility is only checked on the first matched node, a valid second node is never reached. This change, still limited to QN_TYPE_MESSAGE, makes the NPC evaluate all active message nodes. The first eligible node is assigned and if none are eligible, the NPC sends exactly one restriction message explaining why, using the first failure’s hint. Hints are queued per player and flushed once at the end of the interaction.

@davidklaw davidklaw marked this pull request as ready for review September 13, 2025 18:03
@davidklaw davidklaw marked this pull request as draft December 21, 2025 01:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant