Developing Bugs
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Developing Bugs
by RumbleBBU » 25 Oct 2012, 05:18
It seems that, as a byproduct, this also fixed the issue I reported earlier, i.e., the game advancing phases when the game was over and spawning win/lose multiple times...Max mtg wrote:Starting from r17703 AI won't have fun without you
Yet, that's not a good news to learn that AI is playing without human deep into stack.
Should address that too.
The other problem, preset cards crashing challenges, persists.
My earlier post contains a sample dump, and here's a fresh one from today:
- | Open
Re: Developing Bugs
by Doublestrike » 25 Oct 2012, 06:58
I like your optimism 
Off the top of my head nope, no idea, but I'll look this weekend if the bug is still around.
Off the top of my head nope, no idea, but I'll look this weekend if the bug is still around.---
A joke is a very serious thing.
A joke is a very serious thing.
-
Doublestrike - UI Programmer
- Posts: 715
- Joined: 08 Aug 2011, 09:07
- Location: Bali
- Has thanked: 183 times
- Been thanked: 161 times
Re: Developing Bugs
by RumbleBBU » 25 Oct 2012, 07:49
One more...
I have a Mox Jet + Swamp + Hyppie in play, computer has 2 Islands and plays a Lord of Atlantis. Result:
I have a Mox Jet + Swamp + Hyppie in play, computer has 2 Islands and plays a Lord of Atlantis. Result:
- | Open
- Code: Select all
if (this.getTargetCard().isType(landTypes[i])) {
Re: Developing Bugs
by RumbleBBU » 01 Nov 2012, 08:58
For some reason that eludes me, Juju Bubble causes this error (in deck editor):
- | Open
Re: Developing Bugs
by Max mtg » 01 Nov 2012, 09:46
Not related to AFs, but yes, it's mineRumbleBBU wrote:For some reason that eludes me, Juju Bubble causes this error (in deck editor):
Possibly related to factory changes?
Solved in r17813.
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: Developing Bugs
by Agetian » 02 Nov 2012, 04:52
Umm not sure where this should go, but this thread is the closest I could find since my problem is related to the code base - in some of the classes (e.g. RegenerateEffect, RegenerateAi) there are javadocs in the end of the class, not attached to any method or anything - maybe they became orphaned after refactoring (that's just my guess). I thought of moving them to proper definitions but couldn't find the related methods anymore (most likely they were renamed) - if you want I can go over those and remove them, but I just wanted to make sure it's OK to remove them; if not, I can move them to the proper places but I need to know where those proper places are now (I could find e.g. canPlayAi in RegenerateAllAi, but its signature is different from regenerateCanPlayAi mentioned in the "dangling" javadoc).
- Agetian
- Agetian
- Agetian
- Programmer
- Posts: 3489
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Developing Bugs
by Max mtg » 02 Nov 2012, 05:07
Your guess it true. It must be a result of my refactoring.Agetian wrote:Umm not sure where this should go, but this thread is the closest I could find since my problem is related to the code base - in some of the classes (e.g. RegenerateEffect, RegenerateAi) there are javadocs in the end of the class, not attached to any method or anything - maybe they became orphaned after refactoring (that's just my guess). I thought of moving them to proper definitions but couldn't find the related methods anymore (most likely they were renamed) - if you want I can go over those and remove them, but I just wanted to make sure it's OK to remove them; if not, I can move them to the proper places but I need to know where those proper places are now (I could find e.g. canPlayAi in RegenerateAllAi, but its signature is different from regenerateCanPlayAi mentioned in the "dangling" javadoc).
- Agetian
If a javadoc looks like it has been autogenerated it's absolutelly ok to remove it. If it appears to hold some valuable information, then yes - it might be useful somewhere.
Generally I am not sure if arranging those outdated javadocs is worth the time spent.
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: Developing Bugs
by Agetian » 02 Nov 2012, 05:22
Alrighty, I'll keep an eye on these things and will get rid of the ones that appear not to hold any valuable information then!Max mtg wrote:Your guess it true. It must be a result of my refactoring.
If a javadoc looks like it has been autogenerated it's absolutelly ok to remove it. If it appears to hold some valuable information, then yes - it might be useful somewhere.
Generally I am not sure if arranging those outdated javadocs is worth the time spent.
- Agetian
- Agetian
- Programmer
- Posts: 3489
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Developing Bugs
by Agetian » 03 Nov 2012, 14:53
I wanted to ask a question about something that bugs me when trying to run Forge from within Eclipse or NetBeans (I tried both) - when launching from e.g. Eclipse, it takes a very long time for Forge to boot up because it's loading the card files for nearly a minute (or over a minute). However, if I build Forge and run it normally from the game folder, then the game starts nearly instantaneously. Is there any way to increase the speed of loading the game from within an IDE? It could have helped with running in debug mode with breakpoints and stuff... Thanks in advance for help!
P.S. As a side note, I wanted to ask not to completely remove the targeting overlay code from the code base yet, I'm looking into trying to fix that up and make it workable, but not sure how successful I'm going to be, I'll keep you posted.
- Agetian
P.S. As a side note, I wanted to ask not to completely remove the targeting overlay code from the code base yet, I'm looking into trying to fix that up and make it workable, but not sure how successful I'm going to be, I'll keep you posted.
- Agetian
- Agetian
- Programmer
- Posts: 3489
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Developing Bugs
by Max mtg » 03 Nov 2012, 18:56
When you launch from IDE each card is represented by a single file. When you launch a beta, all cardы are archived and stored in a single file.Agetian wrote:I wanted to ask a question about something that bugs me when trying to run Forge from within Eclipse or NetBeans (I tried both) - when launching from e.g. Eclipse, it takes a very long time for Forge to boot up because it's loading the card files for nearly a minute (or over a minute). However, if I build Forge and run it normally from the game folder, then the game starts nearly instantaneously. Is there any way to increase the speed of loading the game from within an IDE? It could have helped with running in debug mode with breakpoints and stuff... Thanks in advance for help!
As for me, the first time forge is loaded it really takes up to a minute to read all cards. But when I run it for the next time, it takes less than three seconds to load them up. Looks like operating system caches these files and they are accessed much faster on subsequent calls. So, maybe is there a way to enable a similiar cache for you?
On the other hand you may think of replacing all the files with cards by an archive as it ships with betas, but don't commit res folder then
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: Developing Bugs
by Agetian » 03 Nov 2012, 19:23
Alrighty, thanks for the advice, I'll take a look!Max mtg wrote:When you launch from IDE each card is represented by a single file. When you launch a beta, all cardы are archived and stored in a single file.
As for me, the first time forge is loaded it really takes up to a minute to read all cards. But when I run it for the next time, it takes less than three seconds to load them up. Looks like operating system caches these files and they are accessed much faster on subsequent calls. So, maybe is there a way to enable a similiar cache for you?
On the other hand you may think of replacing all the files with cards by an archive as it ships with betas, but don't commit res folder then
- Agetian
- Agetian
- Programmer
- Posts: 3489
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Developing Bugs
by Agetian » 04 Nov 2012, 14:47
Starting with r17834, the Forge test suite fails when it comes to testing ManaCost, with the following error:
P.S. Not sure if this may be related, but builds before r17834 also started to exhibit a rather strange mana-related behavior - the game UI won't update when the mana from the manapool is spent.
- Agetian
- Code: Select all
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running TestSuite
Configuring TestNG with: org.apache.maven.surefire.testng.conf.TestNGMapConfigurator@1dbb27d
[white, red, blue]
failed : 0.9
failed : 0.91
failed : 38.0
failed : 41.0
failed : 42.0
failed : 43.0
ManaCost : addMana() error, mana not needed - 1
failed : 45.1
2
Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.712 sec <<< FAILURE!
- Code: Select all
java.lang.NoSuchMethodError: forge.card.mana.Mana.<init>(Ljava/lang/String;Lforge/Card;Lforge/card/spellability/AbilityMana;)V
at forge.card.mana.ManaPartTest.testPayManaCost(ManaPartTest.java:429)
P.S. Not sure if this may be related, but builds before r17834 also started to exhibit a rather strange mana-related behavior - the game UI won't update when the mana from the manapool is spent.
- Agetian
- Agetian
- Programmer
- Posts: 3489
- Joined: 14 Mar 2011, 05:58
- Has thanked: 684 times
- Been thanked: 572 times
Re: Developing Bugs
by Max mtg » 04 Nov 2012, 15:59
Clean and rebuild. There is no objective reason to fail test for lack of method.Agetian wrote:As such, NetBeans won't let me build Forge anymore because it says that the tests can't be finished.
P.S. Not sure if this may be related, but builds before r17834 also started to exhibit a rather strange mana-related behavior - the game UI won't update when the mana from the manapool is spent.
r17840 should help.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Who is online
Users browsing this forum: No registered users and 28 guests