Forge version 1.3.15
Posted: 03 May 2013, 12:40Tentative target release date: Friday May 17.
Would be nice to get a few of the bugs fixed for this version.
Would be nice to get a few of the bugs fixed for this version.
Collectible Card Game Headquarters
High Quality Resources for Collectible Card Games
https://www.slightlymagic.net/forum/
Forge version 1.3.15
https://www.slightlymagic.net/forum/viewtopic.php?f=52&t=10230
Page 1 of 1
Posted: 03 May 2013, 12:40Re: Forge version 1.3.15
Posted: 03 May 2013, 14:15Any bug in particular you were thinking of?
Re: Forge version 1.3.15
Posted: 03 May 2013, 14:21Hellfish wrote:Any bug in particular you were thinking of?
Max mentioned a few in the previous 1.3.14 topic and some of these may already be fixed:
Max mtg wrote:Sure, should be good for a mantainance release.
Some issues to b concerned of:
1. Dgm boosters yeild gates in common slot (someone should write a rule to filter them out, see related thread)
2. Preemptivelty make decision for optional tiggers on stack. The ui was referring to game directly, while it should get the current player controlled by gui and write the choices made to its PlayerContoller class instance.
3. Use a thread-safe collection for stack, or maybe marking getStack with synchronized keyword will be sufficint. Edt does not always know the exact number of items on stack, which results in OOB exception.
4. Get x count cannot get a not-null opponent when the game is over which results in npe.
Wish i could do any of the above by that day, but the tablet i have here is not a propper tool to write code.
Re: Forge version 1.3.15
Posted: 03 May 2013, 14:32I know 2 and 4 are fixed and I'm hopeful that 3 is fixed too, it just needs testing.Havn't looked at 1...yet. 
Re: Forge version 1.3.15
Posted: 03 May 2013, 17:38#1 is very easy - see boostergenerator.java, its makePrintSheet method, and a routine that parses slot extra restrictions (they are divided by colons) , find out how dfc filter is implemednted, write some similiar code for lands - to exclude them from common slots of dgm boosters
Re: Forge version 1.3.15
Posted: 03 May 2013, 18:02Hellfish, it looks like your fix for #3 may have broken some triggers. Can you check out the one that gos reported on the release thread and see if it happens before your changes?Hellfish wrote:I know 2 and 4 are fixed and I'm hopeful that 3 is fixed too, it just needs testing.Havn't looked at 1...yet.
Re: Forge version 1.3.15
Posted: 03 May 2013, 22:30Ok, I reverted this synchronize changes since it seemed to break all of the trigger payment stuff. Additionally I added DGM into RTR block and made DGM lands no longer appear in the common slot. I think we should release a new version to replace 1.3.14 with these changes So we don't have two weeks of everyone being annoyed that many games are unplayable.
Re: Forge version 1.3.15
Posted: 03 May 2013, 23:01Thank you for the quick fixes Sol.
Lets plan on releasing 1.3.15 on Monday, May 6 as this will give us the weekend for additional fixes.
Lets plan on releasing 1.3.15 on Monday, May 6 as this will give us the weekend for additional fixes.
Re: Forge version 1.3.15
Posted: 04 May 2013, 05:24Since the porblem is that critical, I would vote for immediate release of a build, named 1.3.14.1 or 1.3.14a if possible. Because it does not bring new features to be called 3.15...
And print a correct list of unsuported dgm cards in title, along with a java version expected update.
What had to be marked as synchronized - i meant getStack routine originally, but Hellfish was thinking in a right direction to mark add/remove methods synchronized as well, yet those routines do a lot more than just adding something to stack, and that broke everything.
What could do the job is enclose into sync-d blocks only the code that alters the 'stack' member of MagicStack class, but i have to note it again, this needs testing.
And print a correct list of unsuported dgm cards in title, along with a java version expected update.
What had to be marked as synchronized - i meant getStack routine originally, but Hellfish was thinking in a right direction to mark add/remove methods synchronized as well, yet those routines do a lot more than just adding something to stack, and that broke everything.
What could do the job is enclose into sync-d blocks only the code that alters the 'stack' member of MagicStack class, but i have to note it again, this needs testing.
Re: Forge version 1.3.15
Posted: 04 May 2013, 10:53Hope you are enjoying your vacation Mac.
I built and deployed a snapshot build and posted links for them in the 1.3.14 announcement topic.
The Maven system handles the version number changing for me and to do as you suggest would likely require me to modify the directories and the file names on the cardforge web site by hand.
I did add a little info to the changes.txt file already:
I built and deployed a snapshot build and posted links for them in the 1.3.14 announcement topic.
The Maven system handles the version number changing for me and to do as you suggest would likely require me to modify the directories and the file names on the cardforge web site by hand.
I did add a little info to the changes.txt file already:
- Bug Fixes -
Reverted the synchronize changes since it seemed to break all of the trigger payment stuff.
Added DGM into RTR block and made DGM lands no longer appear in the common slot.
- DGM card pictures -
Most but not all of the LQ non-set DGM card pics are now available for downloading. The DGM set pics might become available in about a couple of weeks or so.
- Java 7 -
The devs are discussing a plan to update the battlefield display code with Java FX 2.2 and this should help to improve a few things. Java FX 2.2 requires Java 7 so it is important for members of our user base to update in the near future as Forge at the time of the update will no longer run under Java 6.
Re: Forge version 1.3.15
Posted: 04 May 2013, 17:45I've done this and am running through my quest mode to test things even more than I already have. The cases mentioned in the release thread ( Invoke Prejudice, Counterspell, costed/targeted triggers (Blood Artist, Mentor of the Meek)) all work correctly.Max mtg wrote:What had to be marked as synchronized - i meant getStack routine originally, but Hellfish was thinking in a right direction to mark add/remove methods synchronized as well, yet those routines do a lot more than just adding something to stack, and that broke everything.
What could do the job is enclose into sync-d blocks only the code that alters the 'stack' member of MagicStack class, but i have to note it again, this needs testing.
Re: Forge version 1.3.15
Posted: 04 May 2013, 19:05Hellfish, that's not quite correct: all the synchronized blocks have to use the same monitor to achieve the desired order or operations. Let me remind you, that the original problem was related to edt unable to see changes made in stack by other threads. So we need to ensure right ordering, that is changes must 'happen-before' (notion from java memory model docs) they are read by edt, that's why getStack method also needs some kind of synchronized block.
Use synchronized without an implicit monitor ("this" will be used) to use the same monitor. Frozen stack has not been noted in concurrency issues, it does not need to be sync-d.
Chris, the vacation is wonderful, i manage to catch wifi here for an hour twice a day, so I enjoy this balance.
Use synchronized without an implicit monitor ("this" will be used) to use the same monitor. Frozen stack has not been noted in concurrency issues, it does not need to be sync-d.
Chris, the vacation is wonderful, i manage to catch wifi here for an hour twice a day, so I enjoy this balance.
Re: Forge version 1.3.15
Posted: 04 May 2013, 19:51Ah, well, this is really my first foray into the specifics of threading. 
As I understood what I have read; firstly, you should synchronize on the object you are performing operations on to get exclusive access and secondly, it's bad practice to synchronize on this rather than a private member because code outside the class can synchronize on the same instance (and unlock it? I'm a little fuzzy on this bit).
The key words being "As I understood".
Either way, I'll remove the frozenstack synchronized block and add a block for getstack
As I understood what I have read; firstly, you should synchronize on the object you are performing operations on to get exclusive access and secondly, it's bad practice to synchronize on this rather than a private member because code outside the class can synchronize on the same instance (and unlock it? I'm a little fuzzy on this bit).The key words being "As I understood".
Either way, I'll remove the frozenstack synchronized block and add a block for getstack