Bug Reports (snapshot builds)
Moderators: timmermac, Agetian, friarsol, Blacksmith, KrazyTheFox, CCGHQ Admins
Re: Bug Reports (snapshot builds)
by Agetian » 16 Jan 2015, 08:08
r28605: I fixed the bug that caused the keywords and other stuff granted by enchantments, equipment and fortifications to linger longer than necessary (it was an issue with the copyCard routine that copied this information over to copies, including temporary copies which are e.g. created when a card is moved to another zone). Correct me if I'm wrong, but I don't think this information should ever be copied over to another copy of the card because only one card can be enchanted, fortified, or equipped by a certain particular card at the same time. If I'm wrong in this assumption, feel free to build upon r28605 and correct this further.
- Agetian
- Agetian
- Agetian
- Programmer
- Posts: 3490
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Bug Reports (snapshot builds)
by Agetian » 16 Jan 2015, 10:21
Ok I actually take this back, that wasn't the reason for the issue which is still there... I'll investigate a bit more.Agetian wrote:r28605: I fixed the bug that caused the keywords and other stuff granted by enchantments, equipment and fortifications to linger longer than necessary (it was an issue with the copyCard routine that copied this information over to copies, including temporary copies which are e.g. created when a card is moved to another zone). Correct me if I'm wrong, but I don't think this information should ever be copied over to another copy of the card because only one card can be enchanted, fortified, or equipped by a certain particular card at the same time. If I'm wrong in this assumption, feel free to build upon r28605 and correct this further.
- Agetian
- Agetian
- Agetian
- Programmer
- Posts: 3490
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Bug Reports (snapshot builds)
by Agetian » 16 Jan 2015, 10:45
r28607: Ok, here goes the second attempt at fixing the keywords lingering longer than necessary, looks like there were actually two related problems - the data about equipments being copied over to a temporary copy that then became a card going to graveyard *and* the keywords from enchantments and such staying on the card (even the copied one, without any enchantment info being hard-copied) when going to graveyard. A better fix for the second problem would be to actually find *why* (and where in the code) those keywords are not cleaned up and clean them up there, but I can't find where it happens for now, so I'm hard-removing them from the copied card in GameAction.java:142-145. I also left the "copy enchantments/equipment/etc." on by default in copyCard because it seems to be used by some routines such as the AI Pump code which expects it to make a full copy including the attachments so that the AI can properly assess what happens to the card (and messing with it causes odd side effects with the enchantments unattaching when the AI tries to pump a card on the battlefield).
Not sure if my current fix might have any negative side effects, but it does fix the cards having wrong effects and attached stuff in the graveyard, exile, etc. after LTBing. Please review and update as necessary.
- Agetian
Not sure if my current fix might have any negative side effects, but it does fix the cards having wrong effects and attached stuff in the graveyard, exile, etc. after LTBing. Please review and update as necessary.
- Agetian
- Agetian
- Programmer
- Posts: 3490
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Bug Reports (snapshot builds)
by elcnesh » 16 Jan 2015, 12:16
Agetian, your attempt at removing changed keywords et al. will fail (I think, but haven't tested!). You have to provide the timestamp of the particular keyword change, which you can't possibly know at that point. It'd probably best to create a new method in Card to remove all of those things (just clear the maps) and call that.
- elcnesh
- Posts: 290
- Joined: 16 May 2014, 15:11
- Location: Netherlands
- Has thanked: 34 times
- Been thanked: 92 times
Re: Bug Reports (snapshot builds)
by Agetian » 16 Jan 2015, 14:51
Amazingly enough it works, at least in simple tests, but thanks a lot for the hint, I agree it will be a safer bet - I'll switch to doing that in just a short while!elcnesh wrote:Agetian, your attempt at removing changed keywords et al. will fail (I think, but haven't tested!). You have to provide the timestamp of the particular keyword change, which you can't possibly know at that point. It'd probably best to create a new method in Card to remove all of those things (just clear the maps) and call that.
- Agetian
- Agetian
- Programmer
- Posts: 3490
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Bug Reports (snapshot builds)
by Agetian » 16 Jan 2015, 15:59
Ok, I fixed the issue with lingering keywords in a better way - actually, a map clearing function wasn't even necessary for that, it looks like the game state update call was missed before and that caused the issue. Seems to work fine this way.
- Agetian
- Agetian
- Agetian
- Programmer
- Posts: 3490
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Bug Reports (snapshot builds)
by Agetian » 16 Jan 2015, 16:04
NOTE: Possibly the thing below is already fixed, so feel free to disregard, at least for now.
I ran into an issue a while ago that I know how to fix but I'm not sure if fixing it this way may have unwanted repercussions elsewhere: the cards that "remember" things (e.g. Animate Dead), even the ones that only do it temporarily (e.g. Fire // Ice remembering its chosen target(s) after choosing Fire as a mode and declaring targets but before paying the mana cost) seem to remember those things for longer than necessary - for instance, Animate Dead still keeps information about which card it was animating when it goes to graveyard, and Fire // Ice remembers what it was targeting and which mode was chosen for it even if you cancel the mana payment and it returns back to your hand. This results in inability to choose another mode for it or declare another target for it for the rest of the game (even if you then Regrowth it back to hand!). A seemingly easy way to fix it would be to add a call to "copied.clearRemembered()" to the same zone-changing function right before updateStateForView such that the remembered information is cleared when the card changes zones - in particular when it leaves the stack or the battlefield. I have a question though: should a card outside of the battlefield (e.g. in one's graveyard, exile, or hand) ever be able to keep anything "remembered"? If yes, then this solution won't work and something else will have to be invented. If, however, it's safe to clear the remembered objects if a card goes from the stack or from the battlefield to the hand, graveyard, or exile, it's going to be possible to fix the issue I was talking about above. If at least the hand (as a card destination) is safe for clearing remembered objects, then at least the Fire // Ice issue mentioned above can be fixed (but fixing e.g. Animate Dead remembering its target in the graveyard would require clearing remembered objects in the graveyard). The real problem with Animate Dead remembering its previous target, by the way, lies in the fact that if you Regrowth it back to your hand you will no longer be able to cast it since it already has a remembered target.
EDIT: Interestingly enough, I'm no longer getting this as of r28615. Maybe it's also fixed by that call to updateStateForView (although I'm pretty sure I saw it happening with that call already, hmm...). Anyway, I'll be on the lookout for this possible issue and if it does come up again, for now feel free to disregard my question above.
- Agetian
I ran into an issue a while ago that I know how to fix but I'm not sure if fixing it this way may have unwanted repercussions elsewhere: the cards that "remember" things (e.g. Animate Dead), even the ones that only do it temporarily (e.g. Fire // Ice remembering its chosen target(s) after choosing Fire as a mode and declaring targets but before paying the mana cost) seem to remember those things for longer than necessary - for instance, Animate Dead still keeps information about which card it was animating when it goes to graveyard, and Fire // Ice remembers what it was targeting and which mode was chosen for it even if you cancel the mana payment and it returns back to your hand. This results in inability to choose another mode for it or declare another target for it for the rest of the game (even if you then Regrowth it back to hand!). A seemingly easy way to fix it would be to add a call to "copied.clearRemembered()" to the same zone-changing function right before updateStateForView such that the remembered information is cleared when the card changes zones - in particular when it leaves the stack or the battlefield. I have a question though: should a card outside of the battlefield (e.g. in one's graveyard, exile, or hand) ever be able to keep anything "remembered"? If yes, then this solution won't work and something else will have to be invented. If, however, it's safe to clear the remembered objects if a card goes from the stack or from the battlefield to the hand, graveyard, or exile, it's going to be possible to fix the issue I was talking about above. If at least the hand (as a card destination) is safe for clearing remembered objects, then at least the Fire // Ice issue mentioned above can be fixed (but fixing e.g. Animate Dead remembering its target in the graveyard would require clearing remembered objects in the graveyard). The real problem with Animate Dead remembering its previous target, by the way, lies in the fact that if you Regrowth it back to your hand you will no longer be able to cast it since it already has a remembered target.
EDIT: Interestingly enough, I'm no longer getting this as of r28615. Maybe it's also fixed by that call to updateStateForView (although I'm pretty sure I saw it happening with that call already, hmm...). Anyway, I'll be on the lookout for this possible issue and if it does come up again, for now feel free to disregard my question above.
- Agetian
- Agetian
- Programmer
- Posts: 3490
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Bug Reports (snapshot builds)
by Agetian » 16 Jan 2015, 19:07
r28622: The AI misuses Tribute to the Wild, casting it even when I don't have an artifact or an enchantment on the battlefield to sacrifice.
- Agetian
- Agetian
- Agetian
- Programmer
- Posts: 3490
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Bug Reports (snapshot builds)
by Fizanko » 16 Jan 2015, 23:15
r28623 , but it's possible it has happened in previous versions
I loaded that snapshot to check if the FRF intro decks were working but the program became stuck in "Loading Decks" stage
After waiting several long minutes, i killed the process and checked the .log file and noticed it was one of those decks i was going to test :
I checked that deck and noticed that i simply forgot to add
Maybe something can be done to avoid Forge just staying stuck like that because there's a broken deck ?
As i imagine such a simple mistake can be easy to make in one of the several thousands of dck file available to download in the board, without the user necessarly knowing where to look (the .log) and then being unable to play
I loaded that snapshot to check if the FRF intro decks were working but the program became stuck in "Loading Decks" stage
After waiting several long minutes, i killed the process and checked the .log file and noticed it was one of those decks i was going to test :
- the error | Open
I checked that deck and noticed that i simply forgot to add
At the beginning of the .dck file (after that Forge loaded correctly).[metadata]
Name=Cunning Plan
Maybe something can be done to avoid Forge just staying stuck like that because there's a broken deck ?
As i imagine such a simple mistake can be easy to make in one of the several thousands of dck file available to download in the board, without the user necessarly knowing where to look (the .log) and then being unable to play
probably outdated by now so you should avoid : Innistrad world for Forge (updated 17/11/2014)
Duel Decks for Forge - Forge custom decks (updated 25/10/2014)
Duel Decks for Forge - Forge custom decks (updated 25/10/2014)
Re: Bug Reports (snapshot builds)
by Kapoue » 17 Jan 2015, 00:13
Got this on my upkeep afterplaying Outpost Siege choosing Dragons.
- Code: Select all
Game-0 > java.lang.RuntimeException: AbilityFactory : getAbility -- no Cost in Outpost Siege
at forge.game.ability.AbilityFactory.parseAbilityCost(AbilityFactory.java:117)
at forge.game.ability.AbilityFactory.getAbility(AbilityFactory.java:110)
at forge.game.trigger.TriggerHandler.runSingleTrigger(TriggerHandler.java:448)
at forge.game.trigger.TriggerHandler.runNonStaticTriggersForPlayer(TriggerHandler.java:328)
at forge.game.trigger.TriggerHandler.runWaitingTrigger(TriggerHandler.java:301)
at forge.game.trigger.TriggerHandler.runTrigger(TriggerHandler.java:238)
at forge.game.phase.PhaseHandler.onPhaseBegin(PhaseHandler.java:380)
at forge.game.phase.PhaseHandler.startFirstTurn(PhaseHandler.java:969)
at forge.game.GameAction.startGame(GameAction.java:1387)
at forge.game.Match.startGame(Match.java:71)
at forge.match.MatchUtil$2.run(MatchUtil.java:201)
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:745)
Re: Bug Reports (snapshot builds)
by Kapoue » 17 Jan 2015, 00:40
I think the AI has a few problems with Dash. It plays a dash creature while he has the mana to pay for the normal cost, doesn't attack and then passes with enough mana to have paid the normal cost
It also enchants creatures that were dashed. I'd like to see that tomorrow at the pre-release
It also enchants creatures that were dashed. I'd like to see that tomorrow at the pre-release
Re: Bug Reports (snapshot builds)
by friarsol » 17 Jan 2015, 01:20
You got that choosing Khans right? Not Dragons?Kapoue wrote:Got this on my upkeep afterplaying Outpost Siege choosing Dragons.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Bug Reports (snapshot builds)
by Agkistro » 17 Jan 2015, 03:49
- Agkistro
- Posts: 5
- Joined: 30 May 2014, 03:21
- Has thanked: 0 time
- Been thanked: 0 time
Who is online
Users browsing this forum: No registered users and 10 guests