Skip to content

Conversation

@ssk97
Copy link
Contributor

@ssk97 ssk97 commented Jun 20, 2025

Cards should not be referring to themselves by name directly, they should be using "{this}", except in the situation of checking for cards "named ~" in which case it should not be using "{this}", or for Adventure/Omen cards where that SpellAbility is in the rules text.

I also added "\n" to the list of wrongSymbols, as they should not be within an individual ability's rules.

There are 166 cards with the card's name in the text, 10 with "named {this}", and 6 with "\n". That's a lot, but they should all be pretty easy text fixes. I'll do those in master directly, then merge this once that's done.

@github-actions github-actions bot added the tests label Jun 20, 2025
if (rule.contains("&mdash ")) {
fail(card, "rules", "card's rules contains restricted test [&mdash ] instead [—]");
}
if (Pattern.compile("(?<!named )"+Pattern.quote(card.getName())+"(?! \\{)").matcher(rule).find()) {
Copy link
Member

@JayDi85 JayDi85 Jun 20, 2025

Choose a reason for hiding this comment

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

Why regexp and compile each call instead !string.contains(named {this})?

Copy link
Contributor Author

@ssk97 ssk97 Jun 20, 2025

Choose a reason for hiding this comment

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

The first commit has that, rule.contains(card.getName()) && !rule.contains("named " + card.getName()) && !rule.contains(card.getName()+" {"). However, that both involves searching through the rule string three times (which I think mostly negates the efficiency gains, though I didn't check) and more importantly would fail if the rule contains both an allowed use of the card's name and an invalid one.

Though I should compile the pattern just once per card.

Copy link
Member

@JayDi85 JayDi85 Jun 20, 2025

Choose a reason for hiding this comment

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

Use string contains instead regexp as much as possible. Also add how-to fix comment before verify check or in error message.

I’m not sure why you add \n to the rules restrict, but it’s ok for xmage for multilines rules/texts (in most use cases it’s use <br>).

Copy link
Contributor Author

@ssk97 ssk97 Jun 20, 2025

Choose a reason for hiding this comment

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

It should be using <br> instead of \n, right? Or have I misunderstood?

Anyway, I just checked. Of the 6 cards using "\n", 2 of them are definitely wrong (Paroxysm and Scorching Lava). The other 4 should probably be using <br>, assuming I understand correctly.

Copy link
Member

Choose a reason for hiding this comment

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

Should use br for formatted rules text anyway. It will be visible in card view. If there are low amount of \n usage then it’s better to fix it with br and keep \n restrict.

@ssk97
Copy link
Contributor Author

ssk97 commented Jul 8, 2025

This is ready to merge/be reviewed. The exception list is composed of:

  1. keyword actions
  2. cards that involve another name where the card's name is a substring of the other name
  3. Shield of Kaldra, where it's in the middle of a list
  4. Tibalt, Cosmic Imposter: This one is theoretically fixable, but I couldn't figure out how. The emblem should refer to the permanent's name. I could fix the card text to pass the test, but the emblem would still have the wrong text if made by a name-changed permanent and I'd have to duplicate the Emblem's text.

There's also Krovikan Vampire which I think has some incorrect references to the name in the effect, but it was easy to fix the card text for that one.

@ssk97 ssk97 marked this pull request as ready for review July 8, 2025 10:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants