Forge version 1.5.28

[elcnesh]

That's possible – what kind of thing causes the card to be tapped in the first place? That effect probably misses an update call.

[excessum]

That's possible – what kind of thing causes the card to be tapped in the first place? That effect probably misses an update call.

It was a mistake on my part. I assumed that the Card.setTapped() in ManaCostAdjustment.adjustCostByConvoke() was correct when it should have been Card.tap() instead since tapping for Convoke should fire off "when tapped" events.

[Agetian]

That's possible – what kind of thing causes the card to be tapped in the first place? That effect probably misses an update call.

It was a mistake on my part. I assumed that the Card.setTapped() in ManaCostAdjustment.adjustCostByConvoke() was correct when it should have been Card.tap() instead since tapping for Convoke should fire off "when tapped" events.

I committed this fix to trunk (replaced setTapped with tap in the relevant position).

- Agetian

[Sloth]

I can confirm the following bug:

- Zurgo Helmsmasher, during attack declaration it starts attacking, but if you click on him, you can toggle off its attack. This should not be possible.

The UI should check for validity of the declaration of an attack before proceeding to the next step. I guess we need something similar to the validateBlocks function in CombatUtil.

[Agetian]

I can confirm the following bug:

- Zurgo Helmsmasher, during attack declaration it starts attacking, but if you click on him, you can toggle off its attack. This should not be possible.

The UI should check for validity of the declaration of an attack before proceeding to the next step. I guess we need something similar to the validateBlocks function in CombatUtil.

I can add to this observation that "X attacks each turn if able" seems to work fine (it's impossible to cancel it), e.g. on Juggernaut, but "X attacks each combat if able" (Zurgo Helmsmasher) is bugged the way described above (basically, can be turned off at will). Not sure, but maybe it's a simple enough fix if it's possible to make them both work the same way as far as "canceling" them goes?

EDIT: Fixed as of r27721.

- Agetian

[Phoenix]

Do you guys have any plans to integrate an in-game-updater?
That you have a compact core engine that calls the complete game engine. When you want to upgrade the game engine thread will be shut down and the core engine starts the update engine.

Then one had not to download the new version outside of the game.

[drdev]

Do you guys have any plans to integrate an in-game-updater?
That you have a compact core engine that calls the complete game engine. When you want to upgrade the game engine thread will be shut down and the core engine starts the update engine.

Then one had not to download the new version outside of the game.

Are you talking about something like the auto-update check the Android app has?

[Phoenix]

Since I don't use the Android app I just can guess that this is exactly what I'm talking about.
At the moment in my opinion for the PC version I only have the possibility to download the new version onto my PC, unpack the archive file, delete the old version (since I don't save into the same directory), and launch the new version.

An in-game auto-update would be much more comfortable.

[Sloth]

I can confirm the following bug:

- Zurgo Helmsmasher, during attack declaration it starts attacking, but if you click on him, you can toggle off its attack. This should not be possible.

The UI should check for validity of the declaration of an attack before proceeding to the next step. I guess we need something similar to the validateBlocks function in CombatUtil.

I can add to this observation that "X attacks each turn if able" seems to work fine (it's impossible to cancel it), e.g. on Juggernaut, but "X attacks each combat if able" (Zurgo Helmsmasher) is bugged the way described above (basically, can be turned off at will). Not sure, but maybe it's a simple enough fix if it's possible to make them both work the same way as far as "canceling" them goes?

EDIT: Fixed as of r27721.

This setup is normally fine, but causes some problems in corner cases. Example:
I control a Master of Cruelties, another creature and Grand Melee. The Master of Cruelties and the other creature are declared as attackers and they actually attack together. This is against rule 508.1c. So in the long run a validateAttackers function is needed.

[Agetian]

Yes, agreed. I'm probably not the best person to write this, sadly, so if anyone can implement a function like that, help in this respect is more than welcome.

- Agetian

[Sloth]

Here is another bug that i can confirm, but not fix immediately:

Wojek Halberdiers's battalion trigger doesn't trigger when I attack with it and 2 other creatures

It looks like all the battalion triggers are broken, but normal attacks triggers work. That means that it fails to recognize the other attackers, when the trigger is run. Here is the relevant script of Wojek Halberdiers:

Wojek Halberdiers | Open

T:Mode$ Attacks | ValidCard$ Card.Self | TriggerZones$ Battlefield | CheckSVar$ BattalionTest | NoResolvingCheck$ True | SVarCompare$ GE2 | Execute$ TrigBattalionPump | TriggerDescription$ Battalion - Whenever CARDNAME and at least two other creatures attack, CARDNAME gains first strike until end of turn.
SVar:TrigBattalionPump:AB$ Pump | Cost$ 0 | KW$ First Strike | Defined$ Self
SVar:BattalionTest:Count$Valid Creature.attacking+Other

[drdev]

I just fixed Charms so they display properly on the Android app. To prevent such an issue happening again with the use of special characters, please be sure to use the unicode representation (\u####) and check that that unicode character is also included in FSkinFont::generateFont in forge-gui-mobile on this line:

String chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890\"!?'.,;:()[]{}<>|/@\\^$-%+=#_&*\u2014\u2022";

[KrazyTheFox]

I just fixed Charms so they display properly on the Android app. To prevent such an issue happening again with the use of special characters, please be sure to use the unicode representation (\u####) and check that that unicode character is also included in FSkinFont::generateFont in forge-gui-mobile on this line:

String chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890\"!?'.,;:()[]{}<>|/@\\^$-%+=#_&*\u2014\u2022";

Ah, thanks! I was actually about to go look into that myself. The HTML characters were the only ones that seemed to work on the desktop version when I added it, though I can't recall if I actually tried unicode. I'll definitely keep this in mind for future updates.

[Agetian]

Here is another bug that i can confirm, but not fix immediately:

Wojek Halberdiers's battalion trigger doesn't trigger when I attack with it and 2 other creatures

It looks like all the battalion triggers are broken, but normal attacks triggers work. That means that it fails to recognize the other attackers, when the trigger is run. Here is the relevant script of Wojek Halberdiers:

Wojek Halberdiers | Open

T:Mode$ Attacks | ValidCard$ Card.Self | TriggerZones$ Battlefield | CheckSVar$ BattalionTest | NoResolvingCheck$ True | SVarCompare$ GE2 | Execute$ TrigBattalionPump | TriggerDescription$ Battalion - Whenever CARDNAME and at least two other creatures attack, CARDNAME gains first strike until end of turn.
SVar:TrigBattalionPump:AB$ Pump | Cost$ 0 | KW$ First Strike | Defined$ Self
SVar:BattalionTest:Count$Valid Creature.attacking+Other

I tried tracking through the relevant code here but couldn't find what exactly failed - the game seems to do the math correctly (figuring out that there are 2 other attacking creatures), makes the correct comparison against GE2 (e.g. in case of Legion Loyalist which I used as a test case) and then goes through a rather convoluted set of calls which, for some reason, amount to no trigger being actually registered I'm afraid I won't be able to tackle this one either, please assist if someone knows how to fix this (it doesn't break too many cards but it breaks a whole mechanic with a good enough deal of Modern-legal cards in order for it to be relevant).

- Agetian

[Agetian]

Ok, in continuation of my efforts to figure out what is causing Battalion not to work in the current builds, I have at least identified the spot where it's failing and I have found what may potentially restore this functionality, albeit I have not found a way to make it work in such a way that will not break anything else. That's why I'm not committing this to SVN obviously (it's not a real "fix").

Anyhow, the problem seems to be in CombatUtil.checkDeclaredAttacker (or at least some related code) - the "Attacks" trigger for Battalion does not register correctly in CombatUtil.checkDeclaredAttacker, which causes the Battalion trigger not to fire.

In particular, line 946 that calls runTrigger (with mode=Attacks) seems to do nothing - it adds a waiting trigger but that waiting trigger never fires.
Adding this line:

Code: Select all

        game.getTriggerHandler().registerActiveTrigger(c, false);


Right in front of this line (946 in CombatUtil.java):

Code: Select all

        game.getTriggerHandler().runTrigger(TriggerType.Attacks, runParams, false);


will make Battalion apparently work (at least the simple test case with Legion Loyalist, 2 Raging Goblin passes). However, it breaks other things because it will register other ("basic") Attacks triggers twice, thus causing them to fire two times (e.g. for Frenzied Goblin). Therefore, something else probably needs to be done instead.

I hope this little investigation will at least shed some light onto what may be failing and where to look for the potential places to fix.

EDIT: Making the following change in addition to what is done above appears to both fix Battalion *and* avoid duplication of registration of Attacks triggers for everything else, but it feels super hacky and most likely breaks something else somewhere (especially if registering the same trigger two or more times is actually viable in some circumstances - note that this does not include cases when the same card trigger multiple times in a row, such as Deathgreeter after Wrath of God, these cards still trigger correctly, once for each card that makes its trigger fire [e.g. four times if four creatures die at once]).
A better fix is still needed, so consider this change just a "meditation" on what the possible locations of importance are for the Battalion mechanic.

Line 206 in TriggerHandler.java:

Code: Select all

                if (isTriggerActive(t) && !activeTriggers.contains(t)) {


I'm pretty sure that the actual, real fix involves actually adding an extra registration of an Attacks trigger *elsewhere in the code*, but so far I failed to identify the precise location of this extra registration.

- Agetian