Upcoming Release: Forge version 1.5.57
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Upcoming Release: Forge version 1.5.57
by friarsol » 26 Sep 2016, 22:13
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.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Upcoming Release: Forge version 1.5.57
by drdev » 27 Sep 2016, 03:21
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.
Last edited by drdev on 27 Sep 2016, 04:41, edited 1 time in total.
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Upcoming Release: Forge version 1.5.57
by friarsol » 27 Sep 2016, 03:33
Sweet I was hoping one of you UI savvy types would find an hour or two to rig something together.drdev wrote: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.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Upcoming Release: Forge version 1.5.57
by Agetian » 27 Sep 2016, 06:51
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:
- Agetian
- 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
- Agetian
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Upcoming Release: Forge version 1.5.57
by friarsol » 27 Sep 2016, 13:35
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.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Upcoming Release: Forge version 1.5.57
by Agetian » 27 Sep 2016, 14:34
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:
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
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());
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
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Upcoming Release: Forge version 1.5.57
by friarsol » 27 Sep 2016, 16:33
I never really saw the flickering, maybe I just didn't have the right card setup. But you can try this:Agetian wrote: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
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();
- 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();
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Upcoming Release: Forge version 1.5.57
by Agetian » 27 Sep 2016, 16:45
@ 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
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
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Upcoming Release: Forge version 1.5.57
by friarsol » 27 Sep 2016, 16:57
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.Agetian wrote:@ 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
THEN we want to draw to our UI, which happens here: game.fireEvent(new GameEventCardStatsChanged(affectedCards));
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Upcoming Release: Forge version 1.5.57
by Agetian » 27 Sep 2016, 17:00
kk, thanks a lot for the clarification! I'm going to commit the change then!
- Agetian
- Agetian
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Upcoming Release: Forge version 1.5.57
by Agetian » 27 Sep 2016, 17:06
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
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
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Upcoming Release: Forge version 1.5.57
by drdev » 27 Sep 2016, 19:35
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.
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Upcoming Release: Forge version 1.5.57
by Agetian » 28 Sep 2016, 05:00
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
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Upcoming Release: Forge version 1.5.57
by Agetian » 01 Oct 2016, 08:53
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
- Agetian
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
56 posts
• Page 1 of 4 • 1, 2, 3, 4
Who is online
Users browsing this forum: No registered users and 43 guests