What causes "condition token expected: {type}, actual: {token.Text}" in egametang/ET?

Inspect the reported `expected` vs `actual` token: the actual token tells you what the lexer saw where the expected one should be.

egametang/ET · error · Exception

condition token expected: {type}, actual: {token.Text}

Error message

condition token expected: {type}, actual: {token.Text}

What it means

Generic parser mismatch raised by Expect(): the current token's type does not equal the type the grammar requires at this position. This is the single guard behind every required-token step (RightParen, Number, Identifier, End), so most malformed-expression errors surface here.

Source

Thrown at Packages/cn.etetet.conditionexpr/Scripts/Model/Share/ConditionExprParser.cs:361

        }

        private bool Match(ConditionTokenType type)
        {
            if (this.Current.Type != type)
            {
                return false;
            }

            ++this.position;
            return true;
        }

        private ConditionToken Expect(ConditionTokenType type)
        {
            ConditionToken token = this.Current;
            if (token.Type != type)
            {
                throw new Exception($"condition token expected: {type}, actual: {token.Text}");
            }

            ++this.position;
            return token;
        }

        private ConditionToken Current => this.tokens[this.position];
    }
}

View on GitHub (pinned to 5cab01f7a8)

Solutions

Inspect the reported `expected` vs `actual` token: the actual token tells you what the lexer saw where the expected one should be.
Re-add the missing token (operator, operand, or closing paren) at that position.
If actual is an unexpected identifier after a complete expression, you probably forgot a `&&` / `||` between two sub-expressions.
Validate cells with the parser in a unit test or pre-commit lint so authoring errors are caught before export.

Example fix

// before
HP > 0 MP < 100
// after
HP > 0 && MP < 100

Defensive patterns

Strategy: try-catch

Validate before calling

// cheap structural pre-check before full parse
bool LooksBalanced(string expr)
{
    int depth = 0;
    foreach (char c in expr)
    {
        if (c == '(') depth++;
        else if (c == ')') { depth--; if (depth < 0) return false; }
    }
    return depth == 0;
}

Try / catch

try { ConditionRoot root = parser.Parse(); }
catch (Exception ex) when (ex.Message.StartsWith("condition token expected"))
{
    // surface a friendly authoring error with the cell/row id
    logger.Error($"condition expression malformed: {ex.Message} in cell '{cell}'");
}

Prevention

Validate condition cells in a unit test or pre-export lint.
Always read the expected-vs-actual token in the message to locate the missing character.
When chaining sub-expressions, never forget the boolean operator between them.

When it happens

Trigger: Missing comparison operator (`HP 0`), missing operand after an operator (`HP >`), unbalanced parentheses (`(HP > 0`), missing closing token / trailing garbage (`HP > 0 MP > 1` without a boolean operator), or a stray token where End was expected.

Common situations: Hand-editing a condition cell in Excel/Luban and dropping a character; copy-paste that loses the operator; locale/format issues where a comma vs period breaks tokenization upstream.

Related errors

AI-assisted analysis of egametang/ET@5cab01f7a8 (2026-08-13). Data as JSON: /api/errors/9692db22d34f568c. Report an issue: GitHub.