Implementing variants

[Max mtg]

Chris, it's by design that top label is 80% wide and pushed to the right, meanwhile the remaining part of view takes all avaliable space and is enlarged or shrinked with the window.

Your solution is about center-aligning the 80%-wide contents while it should take 100% of the space avaliable with some gaps from edges of the panel. That's not how constructed/draft/sealed or quest home screens are shown.

[Max mtg]

I made something similiar to constructed menus - the central panel takes all available space with 20px gaps from each side.

[myk]

I'm starting to go through the submenus to look for focus issues, and I'm seeing some serious code duplication (especially in the variant and gauntlet submenus). Would it be a good idea to just make some base classes and inherit functionality instead of rewriting it? This would require that we change the submenu views from enums to classes, but I don't think that would take any architecture changes since they'd still be available as singletons via EDocID.getDoc() (not that I'm promoting the singleton access pattern, I'm just trying to keep changes to a minimum).

[Chris H.]

I made a few minor adjustments to the variant UI and a major one to the Archenemy UI.

The Archenemy view now will resize to 800 x 600 pixels but the random button is drawn offscreen and can not be seen or used. This view used to draw the bottom portion of the view off screen when size was minimized.

If anyone can figure out why the Random button is being drawn off screen I would appreciate it as I suspect that I may not be able to figure it out.

[myk]

I think we can fix a lot of the variant submenus by using the proper widgets -- most of the screen is just a copied version of DeckChooser. If we use that widget (properly generalized to meet variant submenu needs), we can probably solve a lot of the problems.

[Max mtg]

Are you about to force scheme/avatar selection and generation into FDeckChooser?

[Chris H.]

I think we can fix a lot of the variant submenus by using the proper widgets -- most of the screen is just a copied version of DeckChooser. If we use that widget (properly generalized to meet variant submenu needs), we can probably solve a lot of the problems.

 
I have noticed a number of issues while testing the three views at the smallest 800 x 600 pixel size, Vanguard appears to have the most problems.

[myk]

Are you about to force scheme/avatar selection and generation into FDeckChooser?

I wasn't planning to. Rather, FDeckChooser can expose APIs for adding the variant-specific widgets.

[Chris H.]

I think we can fix a lot of the variant submenus by using the proper widgets -- most of the screen is just a copied version of DeckChooser. If we use that widget (properly generalized to meet variant submenu needs), we can probably solve a lot of the problems.

 
I have noticed a number of issues while testing the three views at the smallest 800 x 600 pixel size, Vanguard appears to have the most problems.

 
I have made a few more observations over the last week or so.

My monitor is normally set to 1920 x 1200. When I launch Forge it will fill this display and the objects in the Archenemy and Planechase views will draw correctly. While at this resolution, if I resize the Forge window down to a smaller size (at or near the minimum 800 x 600 size) the random button is drawn off screen. If I click on the various player tabs the view will sometimes be drawn too big and other times will draw at a smaller size where more of the components will become visable.

On several occasions I changed my monitor's resolution down to 800 x 600. When I then launch Forge it will fill this display and the objects in the Archenemy and Planechase views will draw correctly.

The problems apparently is connected to resizing the window down to less than it's original/maximum size. I do not notice this in other views and it may be limited to the variant game modes.


Note:

I moved the constraints that I created for the Archenemy mode over to the Planechase mode and they now appear in a similar fashion.

The vanguard mode is tricky as it includes a card detail panel and as such probably requires a display that is at least 1280 wide.

[friarsol]

I think it'd be useful for Planes to Statically grant the change planes trigger instead of scripting it on every card, similarly to how Basic Land types Statically have Mana abilities.

[swordshine]

Is there a convenient way to test planes?

[Hellfish]

You can rig the planar dice, but that's about it.Anything specific you were after?

[swordshine]

You can rig the planar dice, but that's about it.Anything specific you were after?

It doesn't work for me currently.

IllegalStateException | Open

Code: Select all

Forge Version:    SVN
Operating System: Windows XP 5.1 x86
Java Version:     1.7.0_17 Oracle Corporation

java.lang.IllegalStateException: forge.game.player.HumanPlayer.playSpellAbility may not be accessed from the event dispatch thread.
   at forge.FThreads.assertExecutedByEdt(FThreads.java:51)
   at forge.game.player.HumanPlayer.playSpellAbility(HumanPlayer.java:105)
   at forge.game.zone.MagicStack.chooseOrderOfSimultaneousStackEntry(MagicStack.java:1065)
   at forge.game.zone.MagicStack.chooseOrderOfSimultaneousStackEntryAll(MagicStack.java:1007)
   at forge.gui.GuiDisplayUtil.devModeRiggedPlanarRoll(GuiDisplayUtil.java:689)
   at forge.gui.match.controllers.CDev$13.mousePressed(CDev.java:87)
   at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:280)
   at java.awt.Component.processMouseEvent(Component.java:6502)
   at javax.swing.JComponent.processMouseEvent(JComponent.java:3321)
   at java.awt.Component.processEvent(Component.java:6270)
   at java.awt.Container.processEvent(Container.java:2229)
   at java.awt.Component.dispatchEventImpl(Component.java:4861)
   at java.awt.Container.dispatchEventImpl(Container.java:2287)
   at java.awt.Component.dispatchEvent(Component.java:4687)
   at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
   at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4489)
   at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
   at java.awt.Container.dispatchEventImpl(Container.java:2273)
   at java.awt.Window.dispatchEventImpl(Window.java:2719)
   at java.awt.Component.dispatchEvent(Component.java:4687)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729)
   at java.awt.EventQueue.access$200(EventQueue.java:103)
   at java.awt.EventQueue$3.run(EventQueue.java:688)
   at java.awt.EventQueue$3.run(EventQueue.java:686)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
   at java.awt.EventQueue$4.run(EventQueue.java:702)
   at java.awt.EventQueue$4.run(EventQueue.java:700)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:699)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)


[Hellfish]

Alright,took me long enough, but it's fixed now

[Hellfish]

Btw, Marc,I forgot to mention this in the svn log, but I added your Orzhova script when I converted the variant decks to zones. Works a treat, thanks!