Bug Reports (snapshot builds)
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Bug Reports (snapshot builds)
by Max mtg » 21 Feb 2013, 17:45
That can be avoided, if you parse mtg-data.txt or xml and get card's collection number. Won't work for every set (because early sets don't have numbers strictly assigned to cards), but for most will do.friarsol wrote:Otherwise we'd be trying to hit magiccards.info 12000+ times in short order everytime the script would run.
There might be a special mode to run the script so that it re-evaluates all the cards.
That's sad. Wish they were.friarsol wrote:I don't believe flip cards are handled by SetInfoScript, so that just proves my point that having scriptors hardcode this info will lead to issues.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Bug Reports (snapshot builds)
by friarsol » 21 Feb 2013, 18:00
Yea we have a separate script that's run to clear out anything for particular sets, that's what moomarc was referring to early. It's a bit heavy-handed, since you need to re-run SetInfo afterwards. Maybe if I have some free time I'll make that a bit more elegant.Max mtg wrote:There might be a special mode to run the script so that it re-evaluates all the cards.
Yep, it's because the SetInfoScript was written before Alternate card faces were made available, so there's no consideration for that style of script.Max mtg wrote:That's sad. Wish they were.friarsol wrote:I don't believe flip cards are handled by SetInfoScript, so that just proves my point that having scriptors hardcode this info will lead to issues.
- 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 Almeida » 21 Feb 2013, 18:57
-
Almeida - Posts: 41
- Joined: 24 Dec 2011, 04:48
- Has thanked: 0 time
- Been thanked: 0 time
Re: Bug Reports (snapshot builds)
by myk » 21 Feb 2013, 19:58
@Almeida - ensure your res/ directory is as up-to-date as your src/ directory
There are some notes in the code that the svn revision is not always reported properly. This is because the svn revision is pulled from the root directory when doing a build, and a lot of people just do their svn updates from some sort of GUI, which usually only updates whatever directory tree you r-clicked on when you selected 'update'. We use the buildnumber plugin to get the svn revision for us in the pom. I was looking at its documentation, and it seems we can get a consistently updated value if we set its doUpdate parameter to true. Any bug reports that come in to this thread will then have accurate SVN revision labels. Another plus is that it would ensure the res directory is always up to date, preventing issues like what Almeida saw. The potential downside, though, is that it will attempt to merge whatever is on the server, and if there are local changes, this can be a hassle. What do you guys think? Would enabling the doUpdate param be a good idea?
There are some notes in the code that the svn revision is not always reported properly. This is because the svn revision is pulled from the root directory when doing a build, and a lot of people just do their svn updates from some sort of GUI, which usually only updates whatever directory tree you r-clicked on when you selected 'update'. We use the buildnumber plugin to get the svn revision for us in the pom. I was looking at its documentation, and it seems we can get a consistently updated value if we set its doUpdate parameter to true. Any bug reports that come in to this thread will then have accurate SVN revision labels. Another plus is that it would ensure the res directory is always up to date, preventing issues like what Almeida saw. The potential downside, though, is that it will attempt to merge whatever is on the server, and if there are local changes, this can be a hassle. What do you guys think? Would enabling the doUpdate param be a good idea?
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Bug Reports (snapshot builds)
by myk » 21 Feb 2013, 20:33
I ran into a bug myself. The AI struck Hound of Griselbrand with a Lightning Helix during his draw phase (which was disabled in the UI, if that's relevant). The '1. Hound of Griselbrand - Returning from Undying' item was added to the stack, but the OK button does not allow it to resolve. The prompt window reads:
Turn: Frodo
Phase: Draw
Stack: 1 to Resolve.
Priority: Human
Turn: Frodo
Phase: Draw
Stack: 1 to Resolve.
Priority: Human
- log | Open
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Bug Reports (snapshot builds)
by Corwin72 » 21 Feb 2013, 22:54
forge-1.3.9-20130220.131435-12
this happened when the comp cast Squandered Resources:
this happened when the comp cast Squandered Resources:
- NullPointerException | Open
-
Corwin72 - Posts: 793
- Joined: 15 Sep 2009, 13:26
- Location: Grayson, Ga
- Has thanked: 25 times
- Been thanked: 9 times
Re: Bug Reports (snapshot builds)
by Chris H. » 21 Feb 2013, 23:54
myk wrote:There are some notes in the code that the svn revision is not always reported properly. This is because the svn revision is pulled from the root directory when doing a build, and a lot of people just do their svn updates from some sort of GUI, which usually only updates whatever directory tree you r-clicked on when you selected 'update'. We use the buildnumber plugin to get the svn revision for us in the pom. I was looking at its documentation, and it seems we can get a consistently updated value if we set its doUpdate parameter to true. Any bug reports that come in to this thread will then have accurate SVN revision labels. Another plus is that it would ensure the res directory is always up to date, preventing issues like what Almeida saw. The potential downside, though, is that it will attempt to merge whatever is on the server, and if there are local changes, this can be a hassle. What do you guys think? Would enabling the doUpdate param be a good idea?
I would like it if we can re-introduce the rev numbers to the snapshot builds.
How would this impact my building and deploying the snapshots and the betas?
I currently have two shell scripts/command files which set the dir to my local copy and it then runs a maven command to do the magic.
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Bug Reports (snapshot builds)
by friarsol » 22 Feb 2013, 01:50
r19187
Ok I have Deathlace scripted and it works as expected. SpellPermanents that ETB retain the color change granted by Deathlace. The color change is locked in permanently for anything that hits the Battlefield or is already there. It also successfully laces a Lightning Bolt black to prevent a Hydroblast from Countering it.
The only issue I've noticed with it is non-Permanent spells that leave the stack don't reset their colors as they should (whether it's the GY or wherever they go). I'll hold off on committing until this is resolved (or whoever resolves that can also checkin Deathlace).
Edit: Clarification, Spells going from the Stack to any zone doesn't reset colors. So perhaps unintentionally, going from Stack to Battlefield is functional. But Stack to anywhere else (no matter what type of spell) the color doesn't reset.
Ok I have Deathlace scripted and it works as expected. SpellPermanents that ETB retain the color change granted by Deathlace. The color change is locked in permanently for anything that hits the Battlefield or is already there. It also successfully laces a Lightning Bolt black to prevent a Hydroblast from Countering it.
The only issue I've noticed with it is non-Permanent spells that leave the stack don't reset their colors as they should (whether it's the GY or wherever they go). I'll hold off on committing until this is resolved (or whoever resolves that can also checkin Deathlace).
Edit: Clarification, Spells going from the Stack to any zone doesn't reset colors. So perhaps unintentionally, going from Stack to Battlefield is functional. But Stack to anywhere else (no matter what type of spell) the color doesn't reset.
- 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 friarsol » 22 Feb 2013, 03:52
Ok, here's a patch below that seems to do what I want. I didn't commit it because I wasn't sure if we should be using CardCharacteristic in this way, or if there's a different spot in changeZone where we'd prefer the color reset. Feel free to confirm anyone who is familiar. If noone has any strong preference, I can patch this in and add Deathlace tomorrow night.friarsol wrote:Edit: Clarification, Spells going from the Stack to any zone doesn't reset colors. So perhaps unintentionally, going from Stack to Battlefield is functional. But Stack to anywhere else (no matter what type of spell) the color doesn't reset.
- Patch | Open
- 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 myk » 22 Feb 2013, 06:24
It should not affect them at all. It would be the equivalent of doing an 'svn up' command before running 'mvn package'. For people who are just syncing svn to stay bleeding edge, it would actually be less work compared to now, since they would no longer need to do explicit svn updates. It would just be a potential annoyance if (1) local changes are unmerged and conflict with something that was just checked in by someone else or (2) you're doing revision bisecting trying to find the first bad commit while tracking down a bug. We could solve (2) by introducing an optional commandline parameter (e.g. 'mvn -DdoUpdate=false package'), but I do fear that (1) might cause some angst. Those devs who do not want svn to be automatically updated could create a properties file and set doUpdate to false in there, and we could read that from the pom, but of course if that were to become popular to do, why have the autoupdate at all. We could try it and see how it goes -- it might not become a problem at all. Let me test it out locally for a bit to see if it causes issues.Chris H. wrote:How would this impact my building and deploying the snapshots and the betas?myk wrote:Would enabling the doUpdate param be a good idea?
edit: not sure if this is an option, but this particular kind of problem doesn't exist with git.
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Bug Reports (snapshot builds)
by myk » 22 Feb 2013, 09:24
bug report (I think): the AI activated Sneak Attack during its end phase, just after it had sacrificed a creature from a previous activation of Sneak Attack. During my turn, I exiled Sneak Attack. The second creature was not sacrificed at my end step and it was not sacrificed on the AI's next end step. Shouldn't the creature have been sacrificed regardless of whether Sneak Attack is still in play?
- relevant portion of log | Open
- full log | Open
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Bug Reports (snapshot builds)
by mark » 22 Feb 2013, 11:17
I found a problem in the Han Solo 3 deck as I played it in constructed mode: The enchantment destruction of Dawning Purist does not work. Enchanted Evening changed an Air Elemental of the AI player into a "creature enchantment - elemental" but selecting it after dealing combat damage did nothing
Re: Bug Reports (snapshot builds)
by Chris H. » 22 Feb 2013, 14:38
myk wrote:It should not affect them at all. It would be the equivalent of doing an 'svn up' command before running 'mvn package'. For people who are just syncing svn to stay bleeding edge, it would actually be less work compared to now, since they would no longer need to do explicit svn updates. It would just be a potential annoyance if (1) local changes are unmerged and conflict with something that was just checked in by someone else or (2) you're doing revision bisecting trying to find the first bad commit while tracking down a bug. We could solve (2) by introducing an optional commandline parameter (e.g. 'mvn -DdoUpdate=false package'), but I do fear that (1) might cause some angst. Those devs who do not want svn to be automatically updated could create a properties file and set doUpdate to false in there, and we could read that from the pom, but of course if that were to become popular to do, why have the autoupdate at all. We could try it and see how it goes -- it might not become a problem at all. Let me test it out locally for a bit to see if it causes issues.
edit: not sure if this is an option, but this particular kind of problem doesn't exist with git.
The auto updating might be more of a problem for other people than myself. Then again, people are creatures of habit and it is not easy to get us to change even if it is in our best interests.
Oh, we tried git for a couple of months and then decided to go back to SVN.
We were on googlecode SVN for a couple of years and went to git in an effort to avoid the sleeping giant. Git turned out to be more complicated for those people who were into the project more as a hobby and did not have much tech background.
We moved to the current SVN in the hopes that people like myself would be able to stay with the project.
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Bug Reports (snapshot builds)
by Bundy » 22 Feb 2013, 16:57
forge-1.3.9-20130220.131435-12
Something is not working like it should:
I have 6 swamps,2 Cabal Coffers and a Diamond Kaleidoscope in play.
I tap the Cabal Coffers and pay 2 mana to activate it. I now have 6 black mana available. Then i click the Kaleidoscope and it asks me to pay 3 mana. Instead of clicking on the mana in my mana pool, i click the second Cabal Coffers. Now 3 mana is drained from my mana pool and the effect of the kaleidoscope is placed on the stack, but the kaleidoscope effect also stays on the prompt, asking to pay 3 mana for it. I can pay the 3 mana and the kaleidoscope effect is added to the stack again, resulting in 2 tokens at once from the Diamond Kaleidoscope.
I also tried this with Nuisance Engine and The Hive. The engine does the same thing as the kaleidoscope, yet with The Hive everything works like it should and the Cabal Coffers both add mana and you only get 1 token.
Something is not working like it should:
I have 6 swamps,2 Cabal Coffers and a Diamond Kaleidoscope in play.
I tap the Cabal Coffers and pay 2 mana to activate it. I now have 6 black mana available. Then i click the Kaleidoscope and it asks me to pay 3 mana. Instead of clicking on the mana in my mana pool, i click the second Cabal Coffers. Now 3 mana is drained from my mana pool and the effect of the kaleidoscope is placed on the stack, but the kaleidoscope effect also stays on the prompt, asking to pay 3 mana for it. I can pay the 3 mana and the kaleidoscope effect is added to the stack again, resulting in 2 tokens at once from the Diamond Kaleidoscope.
I also tried this with Nuisance Engine and The Hive. The engine does the same thing as the kaleidoscope, yet with The Hive everything works like it should and the Cabal Coffers both add mana and you only get 1 token.
- Bundy
- Posts: 348
- Joined: 17 Dec 2010, 17:32
- Location: The netherlands
- Has thanked: 23 times
- Been thanked: 3 times
Who is online
Users browsing this forum: No registered users and 17 guests