Bug Reports (snapshot builds)
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Bug Reports (snapshot builds)
by KrazyTheFox » 28 Sep 2014, 01:54
Auto-paying mana doesn't appear to work with some lands for some reason.
Had the following on the field and could not pay 2UU for Jace, the Living Guildpact automatically (manual tapping worked):
Dismal Backwater, Opulent Palace, Jungle Hollow, Llanowar Wastes
Had the following on the field and could not pay 2UU for Jace, the Living Guildpact automatically (manual tapping worked):
Dismal Backwater, Opulent Palace, Jungle Hollow, Llanowar Wastes
-
KrazyTheFox - Programmer
- Posts: 725
- Joined: 18 Mar 2014, 23:51
- Has thanked: 66 times
- Been thanked: 226 times
Re: Bug Reports (snapshot builds)
by excessum » 28 Sep 2014, 03:07
Agetian wrote:r27697: for some reason, Auto mana tapping does not detect that it's possible to cast Stormbreath Dragon when 3 Temple of Plenty, 1 Temple of Triumph, 1 Temple of Abandon, 1 Forest are on the battlefield. It's obviously possible to cast it by tapping the lands manually. I'm afraid that this Auto glitch may also result in the AI not "realizing" the possibility of casting certain spells from its hand (because Auto mana payments and AI mana payments are closely tied IIRC).
- Agetian
I tried both of the above examples in separate dev-mode game-states in r27720 and they seemed to work... Nevertheless, I have also seen auto-pay failing randomly with multi-colour lands so I suspect it is much more complicated than just payManaCost() messing up.KrazyTheFox wrote:Auto-paying mana doesn't appear to work with some lands for some reason.
Had the following on the field and could not pay 2UU for Jace, the Living Guildpact automatically (manual tapping worked):
Dismal Backwater, Opulent Palace, Jungle Hollow, Llanowar Wastes
Re: Bug Reports (snapshot builds)
by Agetian » 28 Sep 2014, 05:42
Oh, yes, makes sense - it did seem random to me.
Speaking of mana payment related bugs, here are two other things I noticed:
1. (easy to reproduce) "Auto" is unable to detect that Gemstone Caverns with a luck counter on it is able to produce mana of any kind, it seems. Maybe this has something to do with the fact that it's also impossible to use it to manually pay for the colored mana in case you start casting a spell first (good test case: put a Mountain and a Gemstone Caverns with a luck counter on it on your side of the battlefield; add Orcish Healer to your hand; click it in your main phase and it'll prompt you to pay RR - not only you can't use Auto here, but you can't even click on Gemstone Caverns to make it produce red mana; you have to cancel and then tap Gemstone Caverns *first* before starting to cast the spell).
2. I noticed that Auto started to fully use up all your mana sources of one color before proceeding to the next color in many (but not all) cases while previously it tried to more or less "balance" the used mana sources such that you don't run out of e.g. Plains. E.g. if you have three Plains and two Swamps, it'll sometimes tap three Plains while it would have been possible to tap 2 Plains + 1 Swamp, for instance (to leave an open Plains and an open Swamp). Can't suggest a specific test case for this yet but as soon as I think of something I'll post it here. Not sure if this was intentional and if this is actually beneficial for the AI or not, but it definitely makes me be more "wary" of using Auto when I have more than one planned spell to cast per turn.
- Agetian
Speaking of mana payment related bugs, here are two other things I noticed:
1. (easy to reproduce) "Auto" is unable to detect that Gemstone Caverns with a luck counter on it is able to produce mana of any kind, it seems. Maybe this has something to do with the fact that it's also impossible to use it to manually pay for the colored mana in case you start casting a spell first (good test case: put a Mountain and a Gemstone Caverns with a luck counter on it on your side of the battlefield; add Orcish Healer to your hand; click it in your main phase and it'll prompt you to pay RR - not only you can't use Auto here, but you can't even click on Gemstone Caverns to make it produce red mana; you have to cancel and then tap Gemstone Caverns *first* before starting to cast the spell).
2. I noticed that Auto started to fully use up all your mana sources of one color before proceeding to the next color in many (but not all) cases while previously it tried to more or less "balance" the used mana sources such that you don't run out of e.g. Plains. E.g. if you have three Plains and two Swamps, it'll sometimes tap three Plains while it would have been possible to tap 2 Plains + 1 Swamp, for instance (to leave an open Plains and an open Swamp). Can't suggest a specific test case for this yet but as soon as I think of something I'll post it here. Not sure if this was intentional and if this is actually beneficial for the AI or not, but it definitely makes me be more "wary" of using Auto when I have more than one planned spell to cast per turn.
- Agetian
Last edited by Agetian on 28 Sep 2014, 06:06, edited 1 time in total.
- Agetian
- Programmer
- Posts: 3486
- Joined: 14 Mar 2011, 05:58
- Has thanked: 683 times
- Been thanked: 569 times
Re: Bug Reports (snapshot builds)
by KrazyTheFox » 28 Sep 2014, 06:03
This is due to the way I had to implement the better tapping ai without having to refactor everything related. Essentially I'm sorting the list of mana abilities so that the least valuable sources are tapped first. In the case of basic lands, I'm guessing that they get sorted so that the same lands are all bunched together. I'm not sure if this is something that would be easy to properly tune without hand analysis, but it should be easy enough to shuffle them up a bit.Agetian wrote:2. I noticed that Auto started to fully use up all your mana sources of one color before proceeding to the next color in many (but not all) cases while previously it tried to more or less "balance" the used mana sources such that you don't run out of e.g. Plains. E.g. if you have three Plains and two Swamps, it'll sometimes tap three Plains while it would have been possible to tap 2 Plains + 1 Swamp, for instance (to leave an open Plains and an open Swamp). Can't suggest a specific test case for this yet but as soon as I think of something I'll post it here. Not sure if this was intentional and if this is actually beneficial for the AI or not, but it definitely makes me be more "wary" of using Auto when I have more than one planned spell to cast per turn.
- Agetian
-
KrazyTheFox - Programmer
- Posts: 725
- Joined: 18 Mar 2014, 23:51
- Has thanked: 66 times
- Been thanked: 226 times
Re: Bug Reports (snapshot builds)
by Agetian » 28 Sep 2014, 06:20
Yes, it's definitely not possible to properly implement this without hand analysis, and I'm not sure if even exactly "shuffling them up [randomly]" will be a good idea (I mean, if it's going to just randomize the order of priority for individual basic lands, it'll only make auto-tapping and AI tapping more unpredictable, but not necessarily "better" in your average situation - in particular, in one case it'll end up screwing the entire color while in another similar case it'll tap a random selection of several colors). Any thoughts and opinions on what would be a good enough idea here?.. And if it's possible to rearrange the priorities after the list is already sorted, is it a good and viable idea to rearrange the basic lands such that they're tapped "one color after another color " if possible (cycle through all the available colors, e.g. in WUBRG or some other order) in an attempt to "balance" mana tapped for colorless/multicolor shards?KrazyTheFox wrote:This is due to the way I had to implement the better tapping ai without having to refactor everything related. Essentially I'm sorting the list of mana abilities so that the least valuable sources are tapped first. In the case of basic lands, I'm guessing that they get sorted so that the same lands are all bunched together. I'm not sure if this is something that would be easy to properly tune without hand analysis, but it should be easy enough to shuffle them up a bit.Agetian wrote:2. I noticed that Auto started to fully use up all your mana sources of one color before proceeding to the next color in many (but not all) cases while previously it tried to more or less "balance" the used mana sources such that you don't run out of e.g. Plains. E.g. if you have three Plains and two Swamps, it'll sometimes tap three Plains while it would have been possible to tap 2 Plains + 1 Swamp, for instance (to leave an open Plains and an open Swamp). Can't suggest a specific test case for this yet but as soon as I think of something I'll post it here. Not sure if this was intentional and if this is actually beneficial for the AI or not, but it definitely makes me be more "wary" of using Auto when I have more than one planned spell to cast per turn.
- Agetian
- Agetian
- Agetian
- Programmer
- Posts: 3486
- Joined: 14 Mar 2011, 05:58
- Has thanked: 683 times
- Been thanked: 569 times
Re: Bug Reports (snapshot builds)
by Marek14 » 28 Sep 2014, 06:47
I think this also affects River of Tears.Agetian wrote:1. (easy to reproduce) "Auto" is unable to detect that Gemstone Caverns with a luck counter on it is able to produce mana of any kind, it seems. Maybe this has something to do with the fact that it's also impossible to use it to manually pay for the colored mana in case you start casting a spell first (good test case: put a Mountain and a Gemstone Caverns with a luck counter on it on your side of the battlefield; add Orcish Healer to your hand; click it in your main phase and it'll prompt you to pay RR - not only you can't use Auto here, but you can't even click on Gemstone Caverns to make it produce red mana; you have to cancel and then tap Gemstone Caverns *first* before starting to cast the spell).
Re: Bug Reports (snapshot builds)
by fiend123 » 28 Sep 2014, 07:08
Fact or Fiction cards are all facedown when splitting the pile
Version: forge-gui-desktop-1.5.28-SNAPSHOT-r27692.tar
- | Open
Version: forge-gui-desktop-1.5.28-SNAPSHOT-r27692.tar
Re: Bug Reports (snapshot builds)
by Agetian » 28 Sep 2014, 07:33
Fixed (r27722).fiend123 wrote:Fact or Fiction cards are all facedown when splitting the pile
- | Open
Version: forge-gui-desktop-1.5.28-SNAPSHOT-r27692.tar
- Agetian
- Agetian
- Programmer
- Posts: 3486
- Joined: 14 Mar 2011, 05:58
- Has thanked: 683 times
- Been thanked: 569 times
Re: Bug Reports (snapshot builds)
by excessum » 28 Sep 2014, 07:39
I think this bug comes from the update that automated targeting for humans when there is only a single legal target since the AI does not encounter it under the same conditions. Activating Polukranos, World Eater when the opponent has a single valid creature also triggers the same NPE.matrix4767 wrote:Armament Corps ability crashes the game if it's activated with no other creatures:
- NullPointerException | Open
I have no idea where the above UI code is located but I presume adding addDividedAllocation(tgt, sa.value) will fix this.
Re: Bug Reports (snapshot builds)
by fiend123 » 28 Sep 2014, 08:26
Achievements are bugged, received a "Mana Screwed (Mythic) - Win a game despite playing 0 lands" after I won a draft game in which I had played lands.
Version: forge-gui-desktop-1.5.28-SNAPSHOT-r27720.tar
- | Open
Version: forge-gui-desktop-1.5.28-SNAPSHOT-r27720.tar
Re: Bug Reports (snapshot builds)
by drdev » 28 Sep 2014, 09:26
Mana Screwed achievement fixed in r27725. Didn't realize the numLandsPlayed field in the Player class was reset each turn, so I was using that for determining the achievement. I've renamed that field to landsPlayedThisTurn to avoid such confusion in the future.
I'm going to create a conversion shortly to throw out any Mana Screwed achievements earned before this fix so they can be earned fairly.
EDIT: Conversion created. It should now properly throw out the achievement if you've earned it previously, but remember it if you earn it fairly from here on.
I'm going to create a conversion shortly to throw out any Mana Screwed achievements earned before this fix so they can be earned fairly.
EDIT: Conversion created. It should now properly throw out the achievement if you've earned it previously, but remember it if you earn it fairly from here on.
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Bug Reports (snapshot builds)
by matrix4767 » 28 Sep 2014, 10:08
Something's wrong with Steam Augury's DDN version. It looks up the cards , but when I get to seperate them into piles, they're shown as unknown, and if I do make 2 piles it crashes:
- NullPointerException | Open
- matrix4767
- Posts: 125
- Joined: 09 Sep 2014, 08:10
- Has thanked: 5 times
- Been thanked: 3 times
Re: Bug Reports (snapshot builds)
by fiend123 » 28 Sep 2014, 10:14
This is not really a bug, but is it possible for the AI to use Austere Command in a smarter manner? It keeps selecting the Destroy all artifact option although there is no artifacts on board and I have multiple creatures in play. The AI also tends not to activate Nevinyrral's Disk even when facing lethal attack.
AI doesn't target any permanents when Yosei, the Morning Star's die trigger triggers.
Wojek Halberdiers's battalion trigger doesn't trigger when I attack with it and 2 other creatures
Version: forge-gui-desktop-1.5.28-SNAPSHOT-r27720.tar
AI doesn't target any permanents when Yosei, the Morning Star's die trigger triggers.
Wojek Halberdiers's battalion trigger doesn't trigger when I attack with it and 2 other creatures
- | Open
Version: forge-gui-desktop-1.5.28-SNAPSHOT-r27720.tar
Re: Bug Reports (snapshot builds)
by Agetian » 28 Sep 2014, 13:37
r27727: Got an interesting NPE today during the very beginning of the game. Was pretty random, not sure what caused it to happen, but I think it happened immediately after I kept my hand. Had to restart the game to proceed. I restarted Forge and the next time I started the match there was no such exception anymore. :\
- Code: Select all
Game-0 > java.lang.NullPointerException
at forge.game.trigger.Trigger.phasesCheck(Trigger.java:181)
at forge.game.trigger.TriggerHandler.isTriggerActive(TriggerHandler.java:335)
at forge.game.trigger.TriggerHandler.resetActiveTriggers(TriggerHandler.java:179)
at forge.game.GameAction.checkStateEffects(GameAction.java:934)
at forge.game.GameAction.startGame(GameAction.java:1564)
at forge.game.Match.startGame(Match.java:81)
at forge.match.MatchUtil$2.run(MatchUtil.java:228)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Last edited by Agetian on 28 Sep 2014, 13:49, edited 1 time in total.
- Agetian
- Programmer
- Posts: 3486
- Joined: 14 Mar 2011, 05:58
- Has thanked: 683 times
- Been thanked: 569 times
Re: Bug Reports (snapshot builds)
by Agetian » 28 Sep 2014, 13:45
I fixed this issue (r27729).excessum wrote:I think this bug comes from the update that automated targeting for humans when there is only a single legal target since the AI does not encounter it under the same conditions. Activating Polukranos, World Eater when the opponent has a single valid creature also triggers the same NPE.matrix4767 wrote:Armament Corps ability crashes the game if it's activated with no other creatures:
- NullPointerException | Open
I have no idea where the above UI code is located but I presume adding addDividedAllocation(tgt, sa.value) will fix this.
- Agetian
- Agetian
- Programmer
- Posts: 3486
- Joined: 14 Mar 2011, 05:58
- Has thanked: 683 times
- Been thanked: 569 times
Who is online
Users browsing this forum: No registered users and 9 guests