magefree / magefree/mage

[WIP] Devs: LKI confusion or don't use getPermanentOrLKIBattlefield with targetPointer

Open
#6,187 0 comments 0 reactions 0 assignees View on GitHub
FAQ refactoring
Dominant language
Java
Stars
2.4k
Forks
940
Avg merge
2d 12h
Merged PRs (30d)
160

Description

**Ignore that text until farther research and fixes**

It's about getPermanentOrLKIBattlefield and getPermanent difference and hidden logic in getting target methods. Current card's code uses it at "random" purpose, that's bad.

1. `getPermanentOrLKIBattlefield` (last known information) uses to find permanent after it changed the zone and it no more valid target (dies/exiled/discarded/moved/etc). Use `getPermanent` all time if possible. Popular bug: after your triggered ability another player destroy or blinked affected permanent, but your effect applied to it but must not (it's a new object after zone change).

2. Don't use `getPermanentOrLKIBattlefield` with `targetPointer` -- any methods from targetPointer returns only original permanent (non LKI) -- getPermanentOrLKIBattlefield will fail after trigger and permanent zone change. Use FixedTarget instead. Problem and fix example in e768c375dcf35b1a0163b677a13a9de12907caf5:
```
((FixedTarget) targetPointer).getTargetedPermanentOrLKIBattlefield(game)
```

3. Fast check before use:
* If you need to change target permanent on BATTLEFIELD then use `getPermanent` and any target pointers calls;
* If you need only info from it then use LKI and/or FixedTarget (but be sure that ability code creates FixedTarget, not another class);

See another example and fixes: 3f7b0da8849ecc5ecf9616a0361757b1397e9a77 (all that triggers can be "skipped" by remove triggered permanent to new zone, but it must not).

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by auditing usages of getPermanentOrLKIBattlefield, getPermanent, targetPointer, and FixedTarget, using commits e768c375dcf35b1a0163b677a13a9de12907caf5 and 3f7b0da8849ecc5ecf9616a0361757b1397e9a77 as examples. Determine which calls need battlefield mutation versus information from last known state. Done means the identified target-handling usages follow the stated distinction without applying effects to a new permanent after a zone change.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
game-dev
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.