Forge version 1.5.28

[Agetian]

Thanks for working on fixing the issues! I stroke out the items which are presumed to be fixed in my list above. If I manage to recreate reliable conditions for some of the trickier bugs in the list I'll post a test case.

- Agetian

[Agetian]

OK, a new issue (or, rather, the old issue reappearing): as on r27608, the targeting arrows do not register blocking creatures again (until the "instants" phase, that is). Is it possible to make the targeting arrows work correctly (meaning "appear as soon as the creature is assigned to be a blocker, even if the blockers are not final yet) without bringing back another issue (the "creature appears to be blocked while it isn't", which I assume is the issue that got fixed when this old one reappeared again)? If it's a problem to make this work with the current implementation of CombatView, is it viable to add a separate list to it that registers "assigned but not confirmed blockers" for the sake of targeting? Because targeting arrows not appearing on blockers until they are finalized is rather suboptimal - if there are lots of creatures on the battlefield, it really helps to see what targets what when deciding to finalize the block or change something. :\

A simple way to reproduce: give the AI Scathe Zombies, give yourself Raging Goblin. Wait for the AI to attack. Declare Raging Goblin to be the blocker. The targeting arrow does not appear until you hit "space" and get to the "instants" portion of blocker declaration.

EDIT: I tried to fix this in r27609 with a separate array list that is used exclusively to store "planned" blockers. Seems to work fine and should hopefully not break the combat log which relies on the list of confirmed blockers. Feel free to improve/modify if this is suboptimal.

- Agetian

[elcnesh]

That fix is fine I guess (right now I'm in a "let's just get this working" mood, so if it works... ).

I've been improving the speed for Android devices, but I haven't been able to reproduce any of the other outstanding issues, including obvious ones like unmorphing and deck editor crashes. Are they still present, and if yes, can someone give me an easy way to reproduce them?

[Agetian]

@ elcnesh: I haven't seen those issues [with visualization of demorphing, with invalid representation of attackers, with deck editor crashes, etc.] happen to me for quite a while, so I'm not sure if it's just my luck or if they have been fixed together with something else. If I come across one of them I'll be sure to post immediately, especially in case I can reproduce the exact conditions when they happen.

One thing for certain is that the foil effect going crazy in the deck editor issue is still happening to me consistently (the "continuously jump from one foil overlay to another" effect in particular) - this one is very easy to reproduce. Basically, whenever you have at least one foil card in deck and you're in a deck editor, it happens. I don't know if all deck editors are affected, but it affects e.g. the Quest deck editor for sure.

- Agetian

[Agetian]

Just a little heads-up of what issues are currently still in the game prior to the 1.5.28 release which is scheduled for tomorrow, in case anybody can do something with them before the time comes:

1. Mindslaver appears not to function correctly with the new refactored Human x Human code: viewtopic.php?f=52&t=6333&start=3300#p162663 .
2. Randomly and commonly happening concurrent modifications in the UI code (can confirm them happening as of r27646), such as: viewtopic.php?f=52&t=6333&start=3300#p162590 , viewtopic.php?f=52&t=6333&start=3300#p162708 , viewtopic.php?f=52&t=6333&start=3300#p162726 )
3. An illegal argument exception in the UI code: viewtopic.php?f=52&t=6333&start=3300#p162707
4. Some reports still exist of the card overlay (P/T mostly) flickering between phases, such as e.g.: viewtopic.php?f=52&t=6333&start=3300#p162705
5. [Android] The mobile version of the game is currently broken (doesn't go beyond "Loading new game", hangs at the loading overlay). It is also unknown if the in-match slowdowns are fixed with 1.5.26.005+ because the changes can't yet be tested in the game. Original report here: viewtopic.php?f=26&t=14534&start=675#p162736

- Agetian

[drdev]

Mindslaver should be fixed now.

[friarsol]

Just a little heads-up of what issues are currently still in the game prior to the 1.5.28 release which is scheduled for tomorrow, in case anybody can do something with them before the time comes:

While we generally release every 2 weeks, there's nothing saying we have to release tomorrow. Especially with how many remaining bugs there are with the UI refactoring. Commonly in the pass a large refactoring like this has followed with a longer release gap to iron out as much as possible.

[Agetian]

Just a little heads-up of what issues are currently still in the game prior to the 1.5.28 release which is scheduled for tomorrow, in case anybody can do something with them before the time comes:

While we generally release every 2 weeks, there's nothing saying we have to release tomorrow. Especially with how many remaining bugs there are with the UI refactoring. Commonly in the pass a large refactoring like this has followed with a longer release gap to iron out as much as possible.

Yes, very true, I agree.

- Agetian

[Chris H.]

I will delay the beta build for a week and we will see how things stand next Wednesday/Thursday.

[drdev]

Since I've been having trouble investigating the slowness on Android, I've gone ahead an implemented a new tracing API for Forge which can collect timestamp information and print it to forge.log or the Output window of your IDE.

The API is as simple as using these two lines to wrap the code you want to investigate:

forge.FTrace.get("Render").start();
...
forge.FTrace.get("Render").end();

The output then looks like this:

Render start - 07:21:44.885
Render end - 07:21:44.887 (2ms)
Render start - 07:21:44.902
Render end - 07:21:44.904 (2ms)
Render start - 07:21:44.919
Render end - 07:21:44.921 (2ms)
Render start - 07:21:44.935
Render end - 07:21:44.937 (2ms)
Render start - 07:21:44.952
Render end - 07:21:44.953 (1ms)
Render start - 07:21:44.968
Render end - 07:21:44.970 (2ms)
Render start - 07:21:44.986
Render end - 07:21:44.987 (1ms)

Forge total time - 5774ms
Render total time - 821ms (14%)

Let me know if you have any questions on using this API or suggestions for improving it.

[drdev]

So after doing some FTrace investigation, I've discovered the problem is definitely in the combat code. I found that even if there's only one creature in play on each, after declaring and undeclaring my one attacker multiple times in the same phase, InputAttack.onCardSelected was taking half a second.

I'm going to attempt to investigate and fix the problem, but if anyone has any insight, that could help.

EDIT: I'm not having much luck figuring out what's working so poorly. Please help. The Android app is basically unplayable until this is fixed.

[elcnesh]

I'm working on caching the combat code, which works so far except for targeting arrows while selecting blockers (which I know Agetian fixed recently, but that's incompatible with my refactoring ). I guess I'll just commit and fix those later, just to see if it solves the slowness. If so, it's worth it to also implement the last bits; otherwise we can just revert it

[Agetian]

I'd say go ahead and commit it, we need to test if it helps resolve the major issue we're having with the game slowness. However, that being said, please also keep a little list of known issues (such as foils not working properly and targeting arrows not working properly), these are also important to fix later, especially the arrows (while foils are purely cosmetic the targeting arrows *while* blockers are declared actually help keep track of who is already blocking what; not having these is a nightmare on a battlefield with a lot of creatures in a complicated combat situation).

- Agetian

[elcnesh]

Just committed, and even got instantaneous targeting arrows to work (as soon as you click an attacker/blocker). Hopefully this will help with speed on Android.

I agree with holding off the beta build, a few more days and we should be able to *really* get it stable.

[excessum]

There seems to be a display bug when using Card.setTapped(). The game randomly fails to show that a card is tapped but when I try to cast spells like Assassinate, it will properly update the tapped status (ie. magically tap the card while I choose the target).