Developing Bugs
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Developing Bugs
by drdev » 07 Nov 2014, 20:15
Are you talking about converting the Card class or the CardView class (or both)?elcnesh wrote:I'm working on refactoring block declarations, but in order to do everything correctly, I need the field Card::mustBlock to become a multiset (it needs to count the nr of requirements on each creature to block). However, it uses the new property tracking system which I don't quite fully understand yet. Is there a simple way to convert this?
Basically, there needs to be a enum value in TrackableProperty for the property you want to add, and a corresponding TrackableType derived class defining the property type. You can re-use one of the existing classes that derive from TrackableType if possible. If there isn't one for the type you need, you just need to create a new class, likely by copying one of the ones with TODOs in it and just tweaking the name and the generic type.
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Developing Bugs
by Agetian » 01 Dec 2014, 09:13
I'm getting the following compilation error as of r28336. Can you please help?
- Agetian
- Code: Select all
COMPILATION ERROR :
-------------------------------------------------------------
forge/game/mana/ManaCostBeingPaidTest.java:[3,23] package junit.framework does not exist
forge/game/mana/ManaCostBeingPaidTest.java:[9,44] cannot find symbol
symbol: class TestCase
forge/game/mana/ManaCostBeingPaidTest.java:[20,13] cannot find symbol
symbol: method assertEquals(java.lang.String,java.lang.String)
location: class forge.game.mana.ManaCostBeingPaidTest
forge/game/mana/ManaCostBeingPaidTest.java:[23,9] cannot find symbol
symbol: method assertEquals(java.lang.String,java.lang.String)
location: class forge.game.mana.ManaCostBeingPaidTest
4 errors
-------------------------------------------------------------
- Agetian
- Agetian
- Programmer
- Posts: 3471
- Joined: 14 Mar 2011, 05:58
- Has thanked: 676 times
- Been thanked: 561 times
Re: Developing Bugs
by elcnesh » 13 Jan 2015, 19:26
So I've been offline for a while (vacation and stuff), but I'm back! And I've done some testing about an issue posted in the bug tracker; try the following game state:
It gets a bit weirder when leaving the aforementioned state-based action commented out. Everytime you play a land, none of the permanents turn into a creature, and everytime you tap one for mana, suddenly the game knows what to do and produces the correct game state. In fact, that game state doesn't even allow you to tap those lands for mana since they have summoning sickness...
- Code: Select all
HumanCardsInPlay=Mycosynth Lattice; March of the Machines; Darksteel Ingot
ActivePlayer=Human
ActivePhase=Main1
It gets a bit weirder when leaving the aforementioned state-based action commented out. Everytime you play a land, none of the permanents turn into a creature, and everytime you tap one for mana, suddenly the game knows what to do and produces the correct game state. In fact, that game state doesn't even allow you to tap those lands for mana since they have summoning sickness...
- elcnesh
- Posts: 290
- Joined: 16 May 2014, 15:11
- Location: Netherlands
- Has thanked: 34 times
- Been thanked: 92 times
Re: Developing Bugs
by oskarolw » 15 Jan 2015, 10:22
Who maintains the bugtracker right now? I have commented on a few older tickets that should probably be closed/removed since they are either already resolved or not applicable anymore. Maybe I could get permission to modify tickets, at the moment I am just a reporter.
Re: Developing Bugs
by friarsol » 15 Jan 2015, 13:22
Nobody does, we tried using it for a little while, but it fell out of favor pretty quickly. Occassionally Sloth or I will go on there, but we've been too busy to do anything with it.oskarolw wrote:Who maintains the bugtracker right now? I have commented on a few older tickets that should probably be closed/removed since they are either already resolved or not applicable anymore. Maybe I could get permission to modify tickets, at the moment I am just a reporter.
I can grant you more permissions later on.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Developing Bugs
by elcnesh » 15 Jan 2015, 13:25
Maybe it's an idea to completely clear it? There may be some useful reports on there, but it's drowned in all kinds of things that have already been fixed or are no longer relevant. It'd allow us to correctly tag any new reports and keep it up-to-date. I could do it, but I don't have any rights there (how do I get them...?).
- elcnesh
- Posts: 290
- Joined: 16 May 2014, 15:11
- Location: Netherlands
- Has thanked: 34 times
- Been thanked: 92 times
Re: Developing Bugs
by friarsol » 15 Jan 2015, 15:15
Sure we can try it again and see how it works out this time.
I can raise people's privileges on there, oskarolw what account do you have on there? I don't see a matching handle from your slightlymagic boards one?
I can raise people's privileges on there, oskarolw what account do you have on there? I don't see a matching handle from your slightlymagic boards one?
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Developing Bugs
by oskarolw » 16 Jan 2015, 10:45
On there I got Gorgonzola.friarsol wrote:Sure we can try it again and see how it works out this time.
I can raise people's privileges on there, oskarolw what account do you have on there? I don't see a matching handle from your slightlymagic boards one?
Re: Developing Bugs
by drdev » 20 Jan 2015, 02:13
So it turns out the issue was with Card.getType() relying on the CardView object's type having been updated in the case of having changedTypes, which it wasn't if TrackableObject's are frozen. As having the game object's property depending on the view's property is a bad idea, I fixed the issue by just returning currentState.getType().getTypeWithChanges(changedCardTypes) directly from this property. The fix is committed in r28666.elcnesh wrote:So I've been offline for a while (vacation and stuff), but I'm back! And I've done some testing about an issue posted in the bug tracker; try the following game state:Somehow all cards get toughness 0 and die (confirmed by commenting out that state-based action). When I comment out the line that calls TrackableObject.freeze() in GameAction, this doesn't happen... What worries me is that the trackable objects are supposed to be related to view classes, yet somehow manage to interfere with the actual game.
- Code: Select all
HumanCardsInPlay=Mycosynth Lattice; March of the Machines; Darksteel Ingot
ActivePlayer=Human
ActivePhase=Main1
It gets a bit weirder when leaving the aforementioned state-based action commented out. Everytime you play a land, none of the permanents turn into a creature, and everytime you tap one for mana, suddenly the game knows what to do and produces the correct game state. In fact, that game state doesn't even allow you to tap those lands for mana since they have summoning sickness...
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Developing Bugs
by elcnesh » 22 Jan 2015, 10:52
Dan, I'm planning some changes to the structure of the Trackable objects, namely getting rid of the static part and delegating that responsibility to a Tracker object associated to a single Game. This is necessary for a single computer to run multiple Games simultaneously, which hopefully can be done sometime in the future. Do you know a priori of anything that might break? So far everything seems to work just fine in my tests, but I thought I'd just quickly check it with you.
- elcnesh
- Posts: 290
- Joined: 16 May 2014, 15:11
- Location: Netherlands
- Has thanked: 34 times
- Been thanked: 92 times
Re: Developing Bugs
by Marek14 » 22 Jan 2015, 13:28
Oh, that might allow to implement Ass Whuppin'elcnesh wrote:Dan, I'm planning some changes to the structure of the Trackable objects, namely getting rid of the static part and delegating that responsibility to a Tracker object associated to a single Game. This is necessary for a single computer to run multiple Games simultaneously, which hopefully can be done sometime in the future. Do you know a priori of anything that might break? So far everything seems to work just fine in my tests, but I thought I'd just quickly check it with you.
Re: Developing Bugs
by drdev » 23 Jan 2015, 06:05
Sounds reasonable to me. As long as everything continues to work and perform well, I have no objections.Marek14 wrote:Oh, that might allow to implement Ass Whuppin'elcnesh wrote:Dan, I'm planning some changes to the structure of the Trackable objects, namely getting rid of the static part and delegating that responsibility to a Tracker object associated to a single Game. This is necessary for a single computer to run multiple Games simultaneously, which hopefully can be done sometime in the future. Do you know a priori of anything that might break? So far everything seems to work just fine in my tests, but I thought I'd just quickly check it with you.
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Developing Bugs
by Agetian » 27 Jan 2015, 15:36
I was looking at CountersRemoveEffect.java today (for AB RemoveCounter) and I got a bit concerned by what it's trying to do:
Why this is a problem is because certain cards rely on this effect, such as e.g. the Take portion of Give // Take, which will remove all counters correctly but which will only draw 1 card (because there's only one instance of the counter remembered). I don't know how many things are actually affected by this (probably not too many), but it is a bit worrying nonetheless.
Does anyone know what a good enough solution for this would be? Obviously, changing the type of remembered objects from Set to List will make this work, but will likely break other things because it will enable the possibility of remembering the same card multiple times. So, probably a bad idea. Does anyone have a good enough idea to suggest here?
- Agetian
- Code: Select all
if (rememberRemoved) {
for (int i = 0; i < chosenAmount; i++) {
card.addRemembered(chosenType);
}
}
Why this is a problem is because certain cards rely on this effect, such as e.g. the Take portion of Give // Take, which will remove all counters correctly but which will only draw 1 card (because there's only one instance of the counter remembered). I don't know how many things are actually affected by this (probably not too many), but it is a bit worrying nonetheless.
Does anyone know what a good enough solution for this would be? Obviously, changing the type of remembered objects from Set to List will make this work, but will likely break other things because it will enable the possibility of remembering the same card multiple times. So, probably a bad idea. Does anyone have a good enough idea to suggest here?
- Agetian
- Agetian
- Programmer
- Posts: 3471
- Joined: 14 Mar 2011, 05:58
- Has thanked: 676 times
- Been thanked: 561 times
Re: Developing Bugs
by elcnesh » 27 Jan 2015, 15:40
Is there anything that relies explicitly on the type of counter stored? Otherwise you could just store the total number of counters.
- elcnesh
- Posts: 290
- Joined: 16 May 2014, 15:11
- Location: Netherlands
- Has thanked: 34 times
- Been thanked: 92 times
Re: Developing Bugs
by Agetian » 27 Jan 2015, 15:44
This card in particular, for instance (Give // Take) refers specifically to the +1/+1 counters by type in addition to by number... I don't know if more complex interactions are possible.elcnesh wrote:Is there anything that relies explicitly on the type of counter stored? Otherwise you could just store the total number of counters.
- Agetian
- Agetian
- Programmer
- Posts: 3471
- Joined: 14 Mar 2011, 05:58
- Has thanked: 676 times
- Been thanked: 561 times
Who is online
Users browsing this forum: No registered users and 102 guests