Forge version 1.5.28

[friarsol]

Will the next version contain the Network Multiplayer stuff? Or is this still on hold?

No. We'll make a huge announcement when it's ready. It's not even close to being ready.

[elcnesh]

I've just remerged GuiRefactoring with trunk, meaning that ALL the gui code has changed. I hope there aren't too many bugs (sorry if that happens!!), but I'll remain on standby the coming days to quickly fix things.

(BTW, this is a first step towards network multiplayer. But it's still a long way to go.)

[excessum]

A random question about the auto mana paying mechanism: Is the automatic paying of mana with multi-mana producers (Karoo lands, Black Lotus, etc.) supported? I know that the logic is to pay shards with the least valuable sources first but this might lead to scenarios where too much mana is produced as the AI does not seem to check the amount of mana produced eg: Azorius Chancery;Island -> Azorius Charm will tap both lands when the double land alone is enough.

[KrazyTheFox]

A random question about the auto mana paying mechanism: Is the automatic paying of mana with multi-mana producers (Karoo lands, Black Lotus, etc.) supported? I know that the logic is to pay shards with the least valuable sources first but this might lead to scenarios where too much mana is produced as the AI does not seem to check the amount of mana produced eg: Azorius Chancery;Island -> Azorius Charm will tap both lands when the double land alone is enough.

Hmm, yeah, I might be able to fix that to an extent. I'll look at it after work today if nobody else has by then.

[excessum]

Hmm, yeah, I might be able to fix that to an extent. I'll look at it after work today if nobody else has by then.

Ok so it is unexpected behaviour then... I assume it can be fixed by duplicating the "while (!cost.isPaid())" loop when multi-producers are involved in order to minimise the number of sources used since "cost" is not saved once the earlier shard(s) have been paid for?

Edit:
On second thought, it looks to be much more complicated than I first thought since the very first block in payManaCost() with the existing mana pool should also be considered. It is times like this where I wish the game-state rewinding system is in place...

[KrazyTheFox]

On second thought, it looks to be much more complicated than I first thought since the very first block in payManaCost() with the existing mana pool should also be considered. It is times like this where I wish the game-state rewinding system is in place...

Ha, you and me both. It's expected behavior in that it's really hard to truly get the best payment options at the moment, but I do think if any one mana producing thing can the full cost should be first (within reason).

[Hanmac]

apropos auto paying
i had ones a Mana Myr, a Land, a Myr Token and Krark-Clan Ironworks on the field ...
with AutoPaying to does sacrifice the mana myr instead of tapping the myr and the land or sacrificing the myr token ... i think that should fixed too that it should sacrifice token first instead of mana producing creatures

[Agetian]

I added a new form of deck statistics in r27449. It shows the individual count of mana symbols of different color in mana costs of cards in the deck, which may provide useful additional information for balancing mana bases in addition to the number of cards of different color (since it accounts for the doubles, triples, etc. of the same color in mana costs). Currently it counts all instances of a certain color in the cost (including not only individual "standard" mana symbols but also parts of hybrids and taking into account the color of Phyrexian mana symbols).

Unfortunately, I'm not really a good UI designer, so right now this functionality has a simple text-based interface in the statistics UI. If anybody would like to improve this interface, feel free to do it.

- Agetian

[excessum]

Ha, you and me both. It's expected behavior in that it's really hard to truly get the best payment options at the moment, but I do think if any one mana producing thing can the full cost should be first (within reason).

In conjunction with adding support for mana abilities with costs, I have been working on this issue and I am really stumped. The logic for payManaCost() is inherently not reversible as it literally uses the actual effects from the stack to actively pay the required mana cost. The ordered paying for each mana shard is another headache since it iterates the colours in sequence.

This looks like a constrained optimisation problem and the sequential logic described above does not play ball with this. Ideally, the logic should go as:

Code: Select all

while (cost) {
  if (multi-mana <= cost) {
    pay and continue
  }
  pay single mana
}

Juggling the order of the shards with this is a mess since the multi-mana might inadvertently be required to over-supply mana to meet specific shards. Other than brute-force rewinding to consider the alternatives, I cannot see a simple logical solution to this.

[KrazyTheFox]

In conjunction with adding support for mana abilities with costs, I have been working on this issue and I am really stumped. The logic for payManaCost() is inherently not reversible as it literally uses the actual effects from the stack to actively pay the required mana cost. The ordered paying for each mana shard is another headache since it iterates the colours in sequence.

This looks like a constrained optimisation problem and the sequential logic described above does not play ball with this. Ideally, the logic should go as:

Code: Select all

while (cost) {
  if (multi-mana <= cost) {
    pay and continue
  }
  pay single mana
}

Juggling the order of the shards with this is a mess since the multi-mana might inadvertently be required to over-supply mana to meet specific shards. Other than brute-force rewinding to consider the alternatives, I cannot see a simple logical solution to this.

That's unfortunate. I originally took to sorting the mana abilities specifically because of the way game iterated through mana costs and I was going replace all that eventually and didn't to spend too long on it. I suppose it'll just have to wait for the engine rewrite.

[Agetian]

I'm posting to summarize some of the GUI refactoring issues that we still have open as of this moment. The new beta is targeted for release in five days. The question is: do we have the time/resources necessary to fix these issues before the new release, and if not, should we consider holding off the release? (some of these issues, while not being absolute "blockers", are rather serious and can be consistently reproduced; some of them cause severe visual artifacts that alter the interpretation of the proper battlefield position, and some others cause crashes of varying severity).

To recap:

1. A concurrent modification exception in ViewUtil: see this report (bottom): viewtopic.php?f=52&t=6333&start=3225#p161795
2. A concurrent modification exception in Card.getAbilityText called from ViewUtil: see this report (bottom): viewtopic.php?f=52&t=6333&start=3225#p161795
3. The combat panel lists some creatures as "blocked" when they are not blocked (a fix went upstream but this still happens, and I think it's rather common to see this happen): viewtopic.php?f=52&t=6333&start=3240#p161913 and also see here: viewtopic.php?f=52&t=6333&start=3240#p162077
4. A concurrent modification exception in Game.getCardsIn called from LocalGameView: viewtopic.php?f=52&t=6333&start=3240#p162066 - see here: viewtopic.php?f=52&t=6333&start=3240#p162066 (other reports also made in this thread, many of them are likely not GUI-related though)
5. A problem with Morph creatures not redrawing when demorphed (may become an obvious issue with KTK in trunk that uses a lot of Morph mechanic): viewtopic.php?f=52&t=6333&start=3255#p162078
6. An index out of bounds exception in a call from ViewUtil: viewtopic.php?f=52&t=6333&start=3255#p162129
7. A problem with Phasing - phased creatures disappear from battlefield: viewtopic.php?f=52&t=6333&start=3255#p162141 (another issue also reported there)
8. Dev mode has no toggle to allow viewing all game zones, which complicates testing: also see here viewtopic.php?f=52&t=6333&start=3255#p162141
9. Index out of bounds exception in Card in a call from ViewUtil: viewtopic.php?f=52&t=6333&start=3270#p162144
10. A problem with attacking creatures on the battlefield sometimes not getting tapped when attacking, not getting the attacker icon, not getting the proper P/T set - viewtopic.php?f=52&t=6333&start=3270#p162157
11. A no such element exception in CardView - viewtopic.php?f=52&t=6333&start=3270#p162165
12. Foil overlays are constantly redrawn and changed in the deck editor - viewtopic.php?f=52&t=6333&start=3255#p162112
13. A crash when adding a card to a deck in a deck editor under certain conditions, it seems - viewtopic.php?f=52&t=6333&start=3270#p162205
14. There is a significant visible slowdown of the mobile version of Forge, both in the match UI and in the main menu (see here: viewtopic.php?f=52&t=15332&start=30#p162247 ), it is yet unknown if this is caused by the GUI refactoring or by something else [being investigated].
15. (Reopened) Targeting arrows for blocking creatures do not appear until the "instants" portions of blocker declaration - see here: viewtopic.php?f=52&t=15332&start=45#p162388

Outside of all the possible and different fatal and non-fatal crashes listed above, it's very important to fix the visual artifact issues (such as 3, 5, 7, 10). There are more issues listed in the bug reports thread, I only outlined the ones that seemed to be ones that are most apparently connected to the GUI refactoring that we underwent. Please do not consider the above list complete.

Elcnesh, do you think you'll be able to respond to these issues and fix the ones that are related to GUI refactoring in time before the release? Also, is anyone else possibly able to work on any of these issues? I'm trying to do my best to fix some simple GUI-related things (e.g. I took care of targeting arrow NPEs and some other simple junk) but I don't feel like I'm good enough with the new code base yet to attempt a larger fix just yet (without breaking a couple other things while I'm at it). EDIT: Elcnesh contacted me and said he'll be starting to fix these issues soon. He also said there should be enough time to take care of these issues before the beta. In the meantime I'll keep adding items to this list that are most obviously connected to GUI refactoring in one way or another.

Thanks in advance for everyone's input.

- Agetian

[mastroego]

EDIT: Wrong thread

[drdev]

I'm noticing a significant slowdown in during gameplay on the new Android app build. Is this the result of the GUI refactoring somehow? Is anyone else seeing the same issue?

[Agetian]

I'm noticing a significant slowdown in during gameplay on the new Android app build. Is this the result of the GUI refactoring somehow? Is anyone else seeing the same issue?

Yes, I noticed that the new version of the Android game was considerably slower, not only in the gameplay itself but also even in the menus (the "loading decks..." takes a while even though the game is set to Random Color decks). Don't know what's up... Is it possible to pinpoint what is slowing it down? Maybe some kind of profiling is possible to see what is taking most of the time now (compared to the pre-refactoring version)?

- Agetian

[elcnesh]

1. A concurrent modification exception in ViewUtil: see this report (bottom): viewtopic.php?f=52&t=6333&start=3225#p161795
2. A concurrent modification exception in Card.getAbilityText called from ViewUtil: see this report (bottom): viewtopic.php?f=52&t=6333&start=3225#p161795
3. The combat panel lists some creatures as "blocked" when they are not blocked (a fix went upstream but this still happens, and I think it's rather common to see this happen): viewtopic.php?f=52&t=6333&start=3240#p161913 and also see here: viewtopic.php?f=52&t=6333&start=3240#p162077
4. A concurrent modification exception in Game.getCardsIn called from LocalGameView: viewtopic.php?f=52&t=6333&start=3240#p162066 - see here: viewtopic.php?f=52&t=6333&start=3240#p162066 (other reports also made in this thread, many of them are likely not GUI-related though)
5. A problem with Morph creatures not redrawing when demorphed (may become an obvious issue with KTK in trunk that uses a lot of Morph mechanic): viewtopic.php?f=52&t=6333&start=3255#p162078
6. An index out of bounds exception in a call from ViewUtil: viewtopic.php?f=52&t=6333&start=3255#p162129
7. A problem with Phasing - phased creatures disappear from battlefield: viewtopic.php?f=52&t=6333&start=3255#p162141 (another issue also reported there)
8. Dev mode has no toggle to allow viewing all game zones, which complicates testing: also see here viewtopic.php?f=52&t=6333&start=3255#p162141
9. Index out of bounds exception in Card in a call from ViewUtil: viewtopic.php?f=52&t=6333&start=3270#p162144
10. A problem with attacking creatures on the battlefield sometimes not getting tapped when attacking, not getting the attacker icon, not getting the proper P/T set - viewtopic.php?f=52&t=6333&start=3270#p162157
11. A no such element exception in CardView - viewtopic.php?f=52&t=6333&start=3270#p162165
12. Foil overlays are constantly redrawn and changed in the deck editor - viewtopic.php?f=52&t=6333&start=3255#p162112
13. A crash when adding a card to a deck in a deck editor under certain conditions, it seems - viewtopic.php?f=52&t=6333&start=3270#p162205
14. There is a significant visible slowdown of the mobile version of Forge, both in the match UI and in the main menu (see here: viewtopic.php?f=52&t=15332&start=30#p162247 ), it is yet unknown if this is caused by the GUI refactoring or by something else [being investigated].

Thanks for this list! I was away for the weekend and this saved me a lot of time. I just committed a patch; to summarise:
1, 2, 4, 6, 9, 11: concurrency issues fixed with more synchronisation.
3, 7, 8: fixed.
Others: not yet fixed (because they weren't trivial or I couldn't easily reproduce them). As Agetian mentioned, I'll try to get everything fixed before the beta release!