ssk97

My point though is that with some minor changes, it should be possible for this change to also fix those two problems. I haven't studied it closely so I might...

> As idea: there are possible cards with gain and token effects that can wrongly require target after rules parse. All of those should be handled with the recursive ability...

All cards' targets have been fixed, this verify check is now ready to be merged. The regex and reflection involved are a little ugly, but there's a lot of weird...

Still need to add some card examples and a few more explanations, but hopefully this is a lot more readable than the original. Caught a few cards that the old...

Ok, explanations and example cards added. Is this good to merge or is some part still too weird?

I don't see how it could simplify the checks. It could make them lot more precise (and thus more likely to catch errors), but would need additional complexity to properly...

Now supports per-ability checking of targets. This means it's using the XMage card text instead of the reference card text, which could cause problems if the two don't match up...

@JayDi85 Is this ok to merge? It now does two separate checks: 1) Per-ability check that XMage rules text does or does not contain "target" when expected (always accepts if...

@JayDi85 Is there a problem if I merge this soon? This fixes several problems and, if later we find a better solution of some sort, is easy to remove.

> Yes, looks like it related to wrong usage of `Ability::getSourceObjectZoneChangeCounter()` and exile zone id (see details in #13737) -- I need to check it. This doesn't really make sense...