Collectible Card Game Headquarters

r20163
Just played a Quest game where after Sideboarding (where I didn't even sideboard anything). The Input is stuck on Combat Damage phase instead of prompting me to mulligan. I had to use Dev mode to add a card to play to get the Combat Damage prompt to be cleared out so it would show me the InputMulligan.

r20163

Is Flash working for anyone else? I activate it on a creature I can't afford (full well knowing it'll be sacrificed), but I never get a "pay this cost" input. Flash still appears to be on the Stack and I don't seem to be able to actually do anything. The Input that's displayed still shows me the Phase and State I was in before that.

Problem: general slowness during a match.

(This might not be very new since I hadn't checked out the latest svn for a while until today - but it's fairly new anyway, at least it wasn't in the 1.3.8 beta.)

The problem seems to be somehow related to the auto-updating/scrolling log pane.

This is how it happens (to me):
In the middle of a phase, typically the combat phases (especially when there's something on the stack), the Log pane empties itself. Then, after a loooooooooooooooooooooooong pause, it starts filling itself again. Then it empties itself again and repeats the whole slow process again. And again. And again. Wait, wait, wait. What's up?

How bad is it? Well, the log phenomenon is currently going on in my game. It started updating when I started writing this message. It isn't done yet.

Even worse, I hit Space reflexively to skip through phases when it looks like a phase is finished, and then press Space again if the phase didn't change - resulting in several excess Space presses in the buffer that resolve when the log-updating is finished, causing me to skip my next main phase, and so on.

I'm afraid this makes the game totally unplayable on at least this particular computer (2 years old WXP laptop, 3GB RAM), and the other computers I have are even older.

Addendum: Well, I've written the complete message now. And that single combat still isn't over!

Epilogue: After 30 minutes of a single game in a single match, I gave up. I killed the process in Eclipse. Going back to the last 'working' version of Forge.

r20178
The game hanged when I was playing multiplayer mode and AI started first.
Edit: Also happened in a second game when I started a random constructed game. It showed a "OK" button when the game started but did not ask if you want to mulligan.

RumbleBBU wrote:Problem: general slowness during a match.

 
Using today's snapshot build and it runs fine on my several year old computer.

Can you try the Eclipse -> Project -> Clean... command and see it it helps?

I know how to generate high CPU load in a match - you should just move mouse over cards in battlefield - note how CPU load rises at that time!


Have also wrapped isGameOver into a syncronized block. That should start second match correctlty after sideboarding

For some reason, in duels between matches I have to click the OK button to get to the question about whether I want to mulligan or not (and before I click OK it shows the phase text as if I were still in the previous game or something)... Pretty sure it used to jump straight to mulligan before.

- Agetian

@Agetian If you X out of the stuck window you will lose that match but the next match will be fine. This may be an issue with games won in the combat phase only.

Agetian wrote:For some reason, in duels between matches I have to click the OK button to get to the question about whether I want to mulligan or not (and before I click OK it shows the phase text as if I were still in the previous game or something)... Pretty sure it used to jump straight to mulligan before.

- Agetian

Looks like new game routine is missing a reset input statement

forge-1.3.10-20130309.133718-8

Land search is broken. Terramorphic Expanse or the sac,pay 1 life lands.
The second window to select the land to put into play does not show any lands to select.

friarsol wrote:r20163

Is Flash working for anyone else? I activate it on a creature I can't afford (full well knowing it'll be sacrificed), but I never get a "pay this cost" input. Flash still appears to be on the Stack and I don't seem to be able to actually do anything. The Input that's displayed still shows me the Phase and State I was in before that.

Same thing happened to me when I wanted to pay some unless cost.

r20205 stock trunk build (Clean/Build) plays a bit slower than the yesterday builds and hangs for me on both Java 6 (6u30) and Java 7 (7u15) if I, for instance, skip the phases too quickly (easily reproduced by just mashing space like mad to skip phases - within a few turns the game hangs and I have to kill the process). At first I thought it might have been my AIPersonalities branch changes, but I tried this on stock trunk and it's exactly the same. :\

EDIT: It seems that r20184 is the culprit, reverting it stops the hanging (but the game still 'lags' a bit). I did not revert it though (on SVN) because I know that the changes in r20184 were intentional and I believe that the hanging can just be fixed. Please look into it when possible.

- Agetian

Do you have any chance to collect the code locations which consume most time?

I used TPTP on Eclipse 3.7 to get some profiling reports, but it isn't confirmed to work in Eclipse Indigo.


As for solution to this problem: the culprit is the thread I made to minimize stack depth, so that input.showMessage is mostly called from that thread meanwhile phasehandler, stack and inputcontrol's updateObservers method just sets a variable in InputProxy class and returns instead of actually evaluating and setting the new input and calling its showMessage. If the input belonged to AI or didn't suppose player to have priority, the same thread came to updating input again and so the stack could reach about hundred calls deep... yet it was never seen overflow, because human got priority relativelly soon.

At the moment when it comes to update of input, a flag is raised and it's GameInputUpdatesThread's responsilibity to update input and call showMessage() method.
Looks like a good step in evolution to me, since UI and game get even their own thread so once they might get into different applications. But it didn't work right as soon as I set them up.

So possible solutions are:
1. If you say r20184 decreased performance, try removing "syncronized" keyword from GameState methods (isgameover, setgameover) and mark member isGameOver as volatile. (and revert similiar changes in InputProxy)

2. Add ButtonUtil.disableAll() to forge.gui.InputProxy.update(Observable, Object) - If they were madly hitting space, that may have made a no-longer-valid input trigger 'ok' button press several times.

3. Remove the very thread guided input change for the time being (revert the whole scheme for the next beta or until that thread becomes more reliable)

Max mtg wrote:2. Add ButtonUtil.disableAll() to forge.gui.InputProxy.update(Observable, Object) - If they were madly hitting space, that may have made a no-longer-valid input trigger 'ok' button press several times.

As an extension to this idea, perhaps we could call Buttonutil.disableAll() directly from inside the ok/cancel button ActionListener to ensure they only get clicked once before they get reset with the next message. I fear doing it from anywhere else might let the action events queue up and execute before disableAll() is called. We might have to add some re-enabling calls in cancel/error paths, but if this kind of change will solve the problem, this is a relatively easy way to do it.

I'm probably not the best person to handle this, if anyone can assist, I'd appreciate your help. I'm not sure what NetBeans uses for profiling, haven't tried profiling things on Java yet (I'm still relatively new to the IDEs for the language) but I'll look into it.

As far as performance goes, reverting r20184 might reduce the lag a bit or maybe even not, I'm not sure, to be honest... I compared the two versions side by side and they seem to have roughly the same performance. I think the lag was introduced by something else.

EDIT: r20215: As a temporary measure, I applied the change per the original Max's suggestion (added ButtonUtil.disableAll() to the update part of InputProxy - seems to do the job and not have any side-effects). Didn't do anything with the performance aspect of changes yet. Feel free to expand on it and modify in any way that you think may be beneficial.

- Agetian