Upcoming Release: Forge version 1.5.57

[friarsol]

Hopefully the next week will just be a quick turnaround release (1-2 weeks). Fix any card issues that have slipped through the cracks, and bolster the AI.

[drdev]

I just rolled out Kaladesh for Android. Before doing so, I commited a few UI fixes for energy counters, a couple of which also affect the desktop app. Just FYI.

[friarsol]

I just rolled out Kaladesh for Android. Before doing so, I commited a couple UI fixes for energy counters, a couple of which also affect the desktop app. Just FYI.

Sweet I was hoping one of you UI savvy types would find an hour or two to rig something together.

[Agetian]

I added an ability to show Energy counters in desktop version of Forge similar to the way it's done in the mobile version of Forge, but I can't for the life of me figure out one thing: when the energy counters are depleted, the life label still uses the "heart icon" that it uses when there is some kind of a counter indicator as well. I tried calling:

Code: Select all

lblLife.setIcon(null); // didn't work because it's ambiguous
lblLife.setIcon((Icon)null); // was accepted but did nothing
lblLife.setIcon((FSkin.SkinImage)null); // was accepted but did nothing


but none of this actually worked, the "heart icon" was still preserved. Is there a reliable way to clear the icon on a FLabel? I mean, it's no biggie, but it would have looked more professional if the label were reset to its default state if the counter indicator went away... :/ I'm a newbie in the GUI stuff, so please assist if possible... Thanks in advance for help!

- Agetian

[friarsol]

There seems to be some logic issues in the engine in relation to SpellAbility.canTarget() in regards to changing targets, and SAs that target other SpellAbilities (such as Counterspells). So currently, a Spellskite can just eat all Counterspells that could target the Spellskite creature spell. This is more noticeable with Captured by the Consulate since it happens automatically, but is more an engine issue than a scripted issue.

[Agetian]

I also wanted to discuss one more thing that's been an issue with the latest versions of Forge for quite a while: something has made the game start flickering heavily again when certain cards are present on the battlefield. This is most noticeable, for example, with Theros Gods, particularly when they are not yet "active" (not creatures yet). This is especially a nightmare on the mobile version of the game, which simply goes crazy in the presence of a God or another enchantment that changes the type of a given card (for instance, Wind Zendikon is known to do that for lands). Does anyone know where to start looking for clues as to why this happens? I thought maybe it's due to the subtle, yet aggressive changes I introduced a while ago to continuous static abilities which caused the query for redraw to happen more often for cards like that, but removing those did not, unfortunately, get rid of the flickering or make it any better, so I think it's got to be something else :/ I believe this is one of the "major" issues we currently have, as a certain category of cards becomes really visually distracting on desktop and horrifyingly jumpy on mobile, and can in fact make the card even temporarily visually disappear from the battlefield at all (e.g. a land enchanted by Wind Zendikon will sometimes disappear and then reappear later during this "intense flickering"). Thanks a lot in advance for advice...

EDIT: Ok, I did some more testing by introducing the following line to trace the calls to Card.updateState:

Code: Select all

System.out.println("updateState called for " + c + " from " + Thread.currentThread().getStackTrace()[2].getClassName()+"::"+Thread.currentThread().getStackTrace()[2].getMethodName()+ " -> " + Thread.currentThread().getStackTrace()[3].getClassName()+"::"+Thread.currentThread().getStackTrace()[3].getMethodName() + " -> " + Thread.currentThread().getStackTrace()[4].getClassName() + "::" + Thread.currentThread().getStackTrace()[4].getMethodName());


It looks like the flickering, for the most part, is indeed caused by the calls to "updateStateForView" I introduced previously in r26979 and r28842, mostly because those methods are called repeatedly multiple times from various layers of static effects, and thus cause "flickering".

I have temporarily reverted those revisions (r32217) to make the flickering less prominent (there may still be some in case of cards like Wind Zendikon, but not nearly as much). Unfortunately, I couldn't figure out a way to get rid of the flickering while keeping the beneficial effects caused by r26979,r28842, namely, visually clearing some static abilities from cards that would otherwise "linger" when not necessary (a classic example being the presence of Humility on the battlefield vs. some static abilities of cards). Please assist if possible, if you know how to fix the latter bug without reintroducing the nightmarish visual flickering, your help is very very welcome!

A little note of potential interest: a lot of the flickering with e.g. Wind Zendikon seems to come from the spam calls to updateStateForView from "GameAction::checkStaticAbilities" which eventually calls it from inside a loop called 9 times (for q=0; q<9; q++). This is most likely where the [still remaining] visual flickering with this card type comes from. Not sure what to do with that either, sadly... Ideally we should somehow decouple all this check/add/remove ability logic from the visual side of things, but I'm not an expert at how to do this best

- Agetian

[friarsol]

A little note of potential interest: a lot of the flickering with e.g. Wind Zendikon seems to come from the spam calls to updateStateForView from "GameAction::checkStaticAbilities" which eventually calls it from inside a loop called 9 times (for q=0; q<9; q++). This is most likely where the [still remaining] visual flickering with this card type comes from. Not sure what to do with that either, sadly... Ideally we should somehow decouple all this check/add/remove ability logic from the visual side of things, but I'm not an expert at how to do this best

- Agetian

I never really saw the flickering, maybe I just didn't have the right card setup. But you can try this:

in GameAction.java around line 859 or so, there's an extra call to checkStaticAbilities. You can try to remove it and replace it with a natural loop iteration if needed.

Soooo replace -

Code: Select all

            setHoldCheckingStaticAbilities(true);
            if (noRegCreats != null) {
                for (Card c : noRegCreats) {
                    sacrificeDestroy(c);
                }
            }
            if (desCreats != null) {
                for (Card c : desCreats) {
                    destroy(c, null);
                }
            }
            setHoldCheckingStaticAbilities(false);
            checkStaticAbilities();


with:

Code: Select all

            setHoldCheckingStaticAbilities(true);
            if (noRegCreats != null) {
                checkAgain = true;
                for (Card c : noRegCreats) {
                    sacrificeDestroy(c);
                }
            }
            if (desCreats != null) {
                checkAgain = true;
                for (Card c : desCreats) {
                    destroy(c, null);
                }
            }
            setHoldCheckingStaticAbilities(false);
            //checkStaticAbilities();


Edit: You may not even need the checkAgain lines since they look like they are being set earlier, so just commenting out the extraneous checkStaticAbilities() (which isn't passing in the right flags), might do the trick.

[Agetian]

@ friarsol: Looks like commenting out that checkStaticAbilities() line as you advised does indeed solve the Wind Zendikon issue! However, I'm not entirely sure (I'm a bit afraid to break something important here): should I just comment out checkStaticAbilities() or should I introduce something else instead?

P.S. By the way, a very simple and yet effective setup to test Wind Zendikon is to just give the AI one land and enchant it with Wind Zendikon. It usually starts flickering immediately (and kinda even phasing in/out - disappearing from the battlefield temporarily from time to time). Once checkStaticAbilities() is commented out in that segment above, it doesn't seem to flicker anymore, at least 99% of it appears to be gone.

- Agetian

[friarsol]

@ friarsol: Looks like commenting out that checkStaticAbilities() line as you advised does indeed solve the Wind Zendikon issue! However, I'm not entirely sure (I'm a bit afraid to break something important here): should I just comment out checkStaticAbilities() or should I introduce something else instead?

P.S. By the way, a very simple and yet effective setup to test Wind Zendikon is to just give the AI one land and enchant it with Wind Zendikon. It usually starts flickering immediately (and kinda even phasing in/out - disappearing from the battlefield temporarily from time to time). Once checkStaticAbilities() is commented out in that segment above, it doesn't seem to flicker anymore, at least 99% of it appears to be gone.

- Agetian

It doesn't need to be replaced with anything. That specific section is holding the static abilities that would be fired by creatures that are being destroyed. These creatures were just accumulated in a loop above this. But since our giant loop is already calling checkStaticAbilities AND we specifically don't want the UI updating during this time, we don't really nee to call it immediately. The only thing that's going to happen, is we're going to finish running through all of our different state effects, then recheck the static abilities to make sure everything is still ok. The giant loop is really more of a while loop, then a for loop. We're going to recheck everything each time something changes in our state. Once nothing has changed, we finish the loop.

THEN we want to draw to our UI, which happens here: game.fireEvent(new GameEventCardStatsChanged(affectedCards));

[Agetian]

kk, thanks a lot for the clarification! I'm going to commit the change then!

- Agetian

[friarsol]

Is there more of a lingering issue after that? Something about Humility?

[Agetian]

Yeah, from what I recall correctly there's an issue with some static abilities not being cleared off of a card, e.g. if Humility is out, some abilities do not visually disappear from a card (I don't remember which ones, for memory... I think something like "When this card deals damage to opponent, you gain 1 life (for each damage)" or something to that effect. I'll try to find the exact combos...

EDIT: Ok, here's an example: Mourning Thrull with Humility out (the ability is not visually cleared from the card, I mean the life-gaining one, but at least it doesn't fire).

EDIT 2: Btw, Wind Zendikon apparently still flickers a bit on mobile Forge (not really noticeable on my PC on desktop Forge anymore), not sure where that comes from, but at least it's significantly less prominent than before IMO.

- Agetian

[drdev]

Agetian, thanks a lot for fixing this. That flickering issue has really been grating on me for awhile and I just wasn't sure how to fix it.

[Agetian]

No problem! It was kinda difficult to track back to my own changes, I admit, since there's some other "residual" flickering coming from elsewhere in the code (no idea where from) and that was confusing (as to whether I was fixing the right thing or not), glad I pinned it down for now. Granted, there's still some flickering left and there are some other visualization issues (mentioned above) that I don't know how to fix yet :/ But at least things don't jump around like crazy anymore.

- Agetian

[Agetian]

Does anybody happen to have Kaladesh booster pack images? I tried finding them on the web but couldn't find all five thus far, only a couple of them... (We may need them on the server later for the questing purposes).

- Agetian