Forge version 1.5.1

[Chris H.]

Tentative target release date: Friday October 11.

[spr]

My plans for 1.5.1 (real world willing) -

• Constructed launch screen re-vamp.
  

  

• Custom names for player and AI. I have always found it ironic that the AI gets to have a name but we the players are "the Human". So I will add a setting to let you personalize your copy of Forge with your name. Fed up with playing against boring Justin or Sharon? How about a match-up against Vildar Wild-eyes, Chicken Tumbler, or Devilish Neutron? Well now you can with a new feature that lets you specify the names that can be randomly assigned to the AI.
  download/file.php?id=12714&mode=view
• If you use the Zoomer to examine cards then one big drawback is if the card image is missing since all you have to look at is the default image - you are forced to use the Card Detail view to get the details. To me, that breaks the immersion and makes Forge seem more like a card database than a card game. So, I have added the ability to generate mock card images at runtime so that all the info on the Card Detail pane is overlayed onto a card template image and which is then treated just like any normal card image.
  download/file.php?id=12715&mode=view

Cheers,
Steve

[swordshine]

I'll try to implement cards with mana replacement effects. Mana Reflection is a very useful card for green commander decks.

[friarsol]

A lot of people are complaining about crashes during combat in the release thread. I'm worried that the added Synchronized to these functions may be responsible, and if one of us can repro those crashes, it would be good to know if removing this fixes them. I'm not sure what the added code was supposed to be doing, but crashing the client is definitely not worth whatever the original bug was.

[Max mtg]

got traces?
haven't found any at 1.5.0 release thread viewtopic.php?f=26&t=11965

The out-of-memory errors reported in a few sibling topics are not related to possible thread synchronization anyway

[friarsol]

It's not happening to me, but it sounds like it's freezing Forge outright, so they wouldn't see any trace. That's why I was asking if anyone could repro it.

[spr]

I have just had AI v AI game halt - the GUI is still responsive but the actual game has just stopped with no phases being played. I was actually monitoring the new skinning code and I think it might be the cause - basically every single component that can be skinned is being stored in HashMaps. But these are never released. Everytime you start a new game it just keeps adding more and more components to these HashMaps. I would like to hear from drdev and also it would be useful if others could take a look but I think if we disable the adding of components to the HashMap this will hopefully alleviate the problem.

For those interested, take a look at FSkin.java and the various "get(T)" methods.

Cheers,
Steve

[dripton]

A lot of people are complaining about crashes during combat in the release thread. I'm worried that the added Synchronized to these functions may be responsible, and if one of us can repro those crashes, it would be good to know if removing this fixes them. I'm not sure what the added code was supposed to be doing, but crashing the client is definitely not worth whatever the original bug was.

See http://cardforge.org/bugz/view.php?id=744, which is caused by the fixes for http://cardforge.org/bugz/view.php?id=742 and http://cardforge.org/bugz/view.php?id=740

It was crashing before, with occasional ConcurrentModificationExceptions. (See bugs 740 and 742 for the tracebacks.) I fixed these crashes by adding synchronization to all methods that use the vulnerable variables attackedEntities and blockedBands. (I first tried a ConcurrentHashMap, but that didn't work.) But now it can deadlock. The GameThread is holding the Combat lock and waiting for the EventQueue$1AWTInvocationLock , which the EDT is holding. The EDT thread is waiting for the Combat lock.

I'm going to remove the low-level synchronization on Combat since it's deadlock-prone. That fixes 744 but reopens 740 and 742. Open for suggestions on other ways to fix those two. (I don't think there will be a fix that anyone likes. The answers are going to involve a single global lock, or less sharing of code across threads.)

[swordshine]

I suggest we release 1.5.1 as soon as possible since many users are suffering the deadlock bug.

[spr]

I suggest we release 1.5.1 as soon as possible since many users are suffering the deadlock bug.

I agree. I think dripton's update (r23334) has solved the freezing issue at least.

Cheers,
Steve

[Max mtg]

Just changed defender-to-bands and band-to-blockers custom maps to google's multimaps. Will see if it helps, it actually should since these classes are said to support concurrency better (at least better than my implementations of those MapOfList-s)

Commited as 23341. Please don't mark the orderBlockersForDamageAssignment method synchronized. Or at least its part where it contains potential calls to EDT. - they are separated from attacking bands iteration now.

[Chris H.]

I posted a link to the newest snapshot on the 1.5.0 topic.

I would like to give people a day or two to play test this fix and to hopefully report back that things are now OK.

I now plan to release 1.5.1 sometime Monday through Wednesday.

[drdev]

The full-screen Forge and skinned titlebar support I added (details) is ready to go for 1.5.1 other than a few tweaks I'll work on today.

I'm glad to hear we're doing a quick turnaround on this release to fix these crashes for everyone.

[Max mtg]

We may still need to mark methods iterating through attackingBands as synchronized (taking into consideration the note above) to fix issues 742 and 740.