Forge version 1.5.28

[friarsol]

Jeez guys, go away for one weekend and everyone flips out about a trigger bug. Was stuff on Battalion actually committed? I'll take a look at it later, it should be a pretty straightforward fix. Just got to reset the active triggers once all attackers are finalized being declared. That way we don't have to duplicate triggers or add things by hand.

[Agetian]

Nope, I did not commit a fix because it wasn't really an actual workable fix, just a hacky workaround with possible side effects. Feel free to implement the way it should actually work, you probably realize how stuff should work in the area of triggers the best at the moment

EDIT: Ok, I committed an actual fix (r27746) according to your suggestion, seems to work fine and does not need any hacky additions to trigger code.

- Agetian

[friarsol]

Also, I saw that there was a commit that said we could no longer deselect "must attack" creatures. Does that mean these creatures can no longer attack Planeswalkers? If so, that's a larger case than just not being able to attack with certain other things out.

[elcnesh]

I'll go look into declaring attackers (and blockers). I think there's been a lot of bugs concerning this already, as just (un)declaring is not enough to check for all constraints such as "must attack" and "can't attack alone". Probably best to loosen the input and implement a check function.

[Agetian]

I'll go look into declaring attackers (and blockers). I think there's been a lot of bugs concerning this already, as just (un)declaring is not enough to check for all constraints such as "must attack" and "can't attack alone". Probably best to loosen the input and implement a check function.

Yes, that would be absolutely optimal. We could not deselect creatures that "attack each turn if able" already (even before the commit referred to above), I merely made the behavior consistent for "attacks each turn" and "attacks each combat". I agree that generally it's best to loosen the input (allow to deselect attackers and retarget them to planeswalkers) but implement a full-blown validation function like Sloth also suggested above. I'd be very grateful (as well as everyone else, I'm sure) if you looked into implementing this function. Thank you very much in advance!

- Agetian

[friarsol]

And if we have a full on validation system, then we should be able to implement some of the "meta-combatant" cards that remain. The tricky part would be giving the AI enough hints to be able to use them, without getting stuck in an infinite loop (or trapped without ever being able to attack/block).

These cards are: Ekundu Cyclops, Magnetic Web, Okk, Orcish Conscripts, Scarred Puma, Viashino Bey, War's Toll

[Marek14]

The main problems would be combination of attack enforcement/meta-combatants with cards that limit number of attackers or blockers like Dueling Grounds -- to implement that properly, cards would have to count their individual number of enforcements.

I wrote about this before -- the perfect system would check all combinations and allow only those that have maximum number of requirements obeyed. However, such a system consumes too much time (not only for AI, but also for human players).
Instead, there could be a system that will take a set of attackers or blockers and try some basic operations. If maximum amount of obeyed requirements increases for any of those, the original set is flagged as illegal.

The operations would be adding or removing attacker or blocking assignment, but also switching an attacker to different player/planeswalker, switching a blocking assignment to different attacker or removing an attacker or blocker and adding another. The replacement operation is necessary in cases such as two creatures that must attack plus Dueling Grounds. If one creature has two requirements while the other one has only one, the system would flag attack with second creature as invalid since it can be replaced by the first creature which increases the total requirements.

This could take care of Ekundu Cyclops (requirement on Ekundu Cyclops is obeyed if it attacks OR if no creature attacks), Magnetic Web (each creature with magnet counter has a requirement that is obeyed if that creature attacks OR if no creatures with magnet counter attack), Viashino Bey (each creature has a requirement that is obeyed if that creature attacks OR if Viashino Bey doesn't attack) and War's Toll (each creature has a requirement that is obeyed if that creature attacks OR if no creature controlled by that player attacks). Possibly also Nacatl War-Pride.
(I hope I interpret those cards correctly. I find the term "must attack if able" very vague since in corner cases the fact that a creature MUST attack can affect whether it, in fact, CAN.)

The next problem are "interim" assignments which are not legal by themselves, but can be made legal by additional declarations. This covers Okk, Orcish Conscripts and Scarred Puma, as well as various "can be only blocked by 2/3 creatures", "can't attack/block alone" etc. If these occur, either during normal declaration or during the legality check, it would be immediately checked whether further declarations can make them legal. If it's not possible or if any such combination would have lower amount of obeyed requirements than something that's already known, the interim assignment is not allowed.

This is just a suggestion, but the advantage would be that there would be no sticking in an infinite loop. If the legality check would be run after AI declares attackers, it could be corrected to a version with higher amount of requirements, so there would be no loops, only possible suboptimal attacks if AI doesn't realize that they are going to get corrected.

Another card that would become possible would be Season of the Witch since the legality check could easily set "could attack" flag on every creature that is a part of a legal set of attackers.

[drdev]

I just committed a very important change which makes it so events sent from the game engine to the GUI are now queued, with multiple events able to be processed all together after a short delay. This allows a single call to update all the PlayerView and CardView objects to apply for all the events that are processed together, rather than needing to update them for each such event received.

The result is a big performance boost to game startup where previously the GUI would get bogged down by trying to handle dozens of events and view updates in rapid succession. I'm also hoping this might help with some of the lag the mobile game experiences after several turns, though I haven't been able to test that yet. Lastly, this might help dodge some of the ConcurrentModification issues that occasional pop up.

Please let me know if you see any ill effects of this change. I tried to make it as smart as possible, even ensuring the delayed event processing happens much quicker immediately following user input (like pressing the OK button) than it does while processing AI and game logic doing stuff behind the scenes.

[Chris H.]

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

 
How do people feel about a beta release on Friday October 3 or should we wait another week?

[friarsol]

Please let me know if you see any ill effects of this change. I tried to make it as smart as possible, even ensuring the delayed event processing happens much quicker immediately following user input (like pressing the OK button) than it does while processing AI and game logic doing stuff behind the scenes.

The first game I loaded up with these changes I was forced to choose to Mulligan or not with only 2 cards displayed in my hand. The other 5 cards were only visible after I kept, and played my first land.

And my tokens didn't draw when ETB... This doesn't feel to be working at all for me...

[Agetian]

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

 
How do people feel about a beta release on Friday October 3 or should we wait another week?

As of right now (r27774), the game is not really in a playable state, so unless the major issues with card visualization can be resolved in a timely enough manner, I think it's necessary to wait another week.

- Agetian

[drdev]

I'm working on an even better overhaul of the event handling system that should perform even better and work much more reliably. I should have it ready to release soon.

EDIT: Just committed r27775 which should hopefully resolve all the issues people were seeing. I'll roll out an Android update once I get the chance to do some testing on an Android device.

Please let me know if you're still seeing issues with things not updating properly.

[Devilman06]

I used kiki jiki on bogardan hellkite but the enter the battlefield did not trigger i'm not sure if it's kiki jiki related but it did trigger when i played it from my hand
using version forge-gui-desktop-1.5.28-20140929.225500-8.tar

[Agetian]

Card visualization definitely works much much better now. I'm aware of at least one issue though: when discarding cards (e.g. during the cleanup phase) and when you're selecting multiple cards to discard, the purple "selected" border does not appear immediately on the cards (you have to move the mouse away from the card to make it appear).

Something indeed broke Animate Dead and other reanimation effects very recently though. At first I thought it wasn't resolving correctly when cast on the opponent's creatures only (as of r27776), but then I realized it wasn't resolving correctly at all no matter what.

It was working correctly just recently (I can confirm it working just fine in r27764).

EDIT: I determined that Animate Dead is broken by r27765 (works fine in r27764, broken in r27765).

- Agetian

[drdev]

I think I've worked out most of the kinks at this point, though I had to rework some of my changes. I just released a new version of the Android app I'm hoping will work for everyone.

Please let me know if you encounter any issues.