Re: Forge version 1.5.28
That's possible – what kind of thing causes the card to be tapped in the first place? That effect probably misses an update call.
High Quality Resources for Collectible Card Games and Home of the CCGHQ Team
https://www.slightlymagic.net/forum/
https://www.slightlymagic.net/forum/viewtopic.php?f=52&t=15332
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.elcnesh wrote:That's possible – what kind of thing causes the card to be tapped in the first place? That effect probably misses an update call.
I committed this fix to trunk (replaced setTapped with tap in the relevant position).excessum wrote: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.elcnesh wrote:That's possible – what kind of thing causes the card to be tapped in the first place? That effect probably misses an update call.
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.P for Pizza wrote:- 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.
Sloth wrote:I can confirm the following bug: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.P for Pizza wrote:- 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.
Are you talking about something like the auto-update check the Android app has?Phoenix wrote: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.
This setup is normally fine, but causes some problems in corner cases. Example:Agetian wrote:Sloth wrote:I can confirm the following bug: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.P for Pizza wrote:- 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.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.
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:fiend123 wrote:Wojek Halberdiers's battalion trigger doesn't trigger when I attack with it and 2 other creatures
Ah, thanks! I was actually about to go look into that myself.drdev wrote: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";
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 registeredSloth wrote:Here is another bug that i can confirm, but not fix immediately: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:fiend123 wrote:Wojek Halberdiers's battalion trigger doesn't trigger when I attack with it and 2 other creatures
game.getTriggerHandler().registerActiveTrigger(c, false);
game.getTriggerHandler().runTrigger(TriggerType.Attacks, runParams, false);
if (isTriggerActive(t) && !activeTriggers.contains(t)) {