This build has no new features (well, one new feature) but tries to fix a bunch of issues to do with reconnections. We would very much appreciate any testing you can do on it to make sure we haven't introduced more problems (and, perhaps, have fixed some). Two reconnection cases that we know should be fixed here are: Reconnecting after disconnecting while choosing a move destination for a triggered dodge card. Reconnecting after disconnecting while opening a chest after getting past the 20th chest on the multiplayer reward track. As well as that, there is now a dialog that lets you opt out of reconnecting to a battle. So, if reconnecting is failing, you can just quit and go do something else. This will resign any battle you were in. Reconnection Add a pop-up before rejoining a battle to give players a chance to resign without having to load in. Bug Fixes Increase column size of some statistics columns to eliminate warnings about data truncation Check for a null MP reward type during reconnection to prevent errors. Add more information to log message when a single-player battle is resumed Better exception handling on various recoverable exceptions. Added a proper int vector serializer. Switched hand and deck peek commands to use int vector serializer instead of object vector serializer. All commands, iterators and triggers should serialise properly now (fixed to not have any constructor parameters and so that any object vectors are initialised at construction time, not on init). Should fix failure to reconnect to a battle during a triggered move (e.g. dodge) as well as, possibly, a bunch of other cases.
The pop-up has 'No' button on the left and 'Yes' on the right. I believe UI convention dictates 'Yes' on the left ?
Dimensional Traveller: Dc'ed after choosing the same spot to stay in and before choosing orientation. Reconnecting will allow the player to re-pick where to go instead of the orientation phase. Apparently, all move cards also behave the same way when reconnecting after choosing same spot. edit1: apparently, I can play a Chop...pick 1 char, dc and reconnect to replay the turn. edit2: Consecrate Ground triggered draw for (eventTargetGroups).
phaselock played elvish mobility on lockphase. lockphase had 1 elf which was designated to move first. lockphase refreshed browser before moving his elf and did not re-login. phaselock waited and then after some time, phaselock's elf was asked to move ?! Phaselock did nothing and was defeated. (battle log below). BATTLE LOG: Scenario=MP Celestial Dojo,Room=phaselock's battle vs lockphase,RoomID=13,Msg=The active player is now phaselock stopTimer 1 1185 BATTLE LOG: Player=phaselock,Scenario=MP Celestial Dojo,Room=phaselock's battle vs lockphase,RoomID=13,Event=PlayAction,Action=Elvish Mobility,Instigator=Thienenu,Targets= startTimer 0 1181 startTimer 1 1185 BATTLE LOG: Scenario=MP Celestial Dojo,Room=phaselock's battle vs lockphase,RoomID=13,Msg=phaselock was defeated BATTLE LOG: Scenario=MP Celestial Dojo,Room=phaselock's battle vs lockphase,RoomID=13,Event=GameOver 2nd case, similar to above except that phaselock played elvish mobility and phaselock's elf triggered the move first (due to positioning). Phaselock's elf moved and lockphase's elf was designated to move. lockphase dc'ed and did not re-login. Again, after some time...the turns switched automatically ?! phaselock waited until he grew old (lockphase's timer to hit 0) to win. (battle log below). BATTLE LOG: Scenario=MP Celestial Dojo,Room=lockphase's battle vs phaselock,RoomID=14,Msg=The active player is now phaselock stopTimer 0 1095 BATTLE LOG: Player=phaselock,Scenario=MP Celestial Dojo,Room=lockphase's battle vs phaselock,RoomID=14,Event=PlayAction,Action=Elvish Mobility,Instigator=Thienenu,Targets= startTimer 0 1095 BATTLE LOG: Scenario=MP Celestial Dojo,Room=lockphase's battle vs phaselock,RoomID=14,Player=phaselock,Actor=Thienenu,Event=Move,Origin=(6, 5),StartFacing=(0, 1),Destination=(6, 5),EndFacing=(0, 1) stopTimer 0 1084 startTimer 1 1125 BATTLE LOG: Scenario=MP Celestial Dojo,Room=lockphase's battle vs phaselock,RoomID=14,Msg=The active player is now lockphase BATTLE LOG: Scenario=MP Celestial Dojo,Room=lockphase's battle vs phaselock,RoomID=14,Msg=lockphase was defeated BATTLE LOG: Scenario=MP Celestial Dojo,Room=lockphase's battle vs phaselock,RoomID=14,Event=GameOver
While you're working on connection stuff, how about adding a MP lobby idle timer? Disconnect idle MP players after say 15 minutes. It shouldn't be too onerous to log back in after you timed out when you want to continue actually playing. Currently there are constantly people showing online in MP who aren't really there. This gives the wrong impression to people actually looking for games. There can seem to be rating-appropriate players online but often there really aren't. While this might make the game seem more popular and inviting, it's a false impression leading to disappointment when you can't get a match going as soon as you thought and when you do, it is with an opponent with much more rating difference than you thought it would be. Personally I'm for transparency and truthfulness in this issue. Some people might leave the client running to see all of the chat that happens while they're away but I don't feel enabling this is a good enough reason to compensate for the ill effects the practise has.
I feel that's more of a chat client thing. Why would a multiplayer game want to have idlers in the lobby? It makes sense in a communications program where they want to have everyone in-client all the time but not so much in a game where the point is to play with people and not to stare at the lobby. Having to parse the statuses would be more cognitive load on the user. Having people be either on or out would be simpler and much easier to use. You could get a picture of the true online situation by just quickly flicking through the player list or just from the length of the position indicator on the scrollbar, even. With statuses you'd need to start actually reading those which is much slower and more cumbersome.
I'd rather Pengw1n's suggestion than Jarmo's. Until lobby chat is accessible from outside the game client, people who care about the community need to be able to stay logged in indefinitely.
Thanks for the bug checking Phaselock. None of those issues sound too serious, so I think we're going to go ahead and release this build today.
The way I read that bug description, Phaselock did nothing and was defeated due to time out. I wonder what would have happened had he tried to move his Elf as requested.
I can't repro Phaselock's initial bug, but I do see the wrong timer counting down in the reconnected client. I'll fix that now. It shouldn't affect the actual game outcome. Interested to see if we can get any more info on how to repro the wrong player being asked to move. That sounds very odd.
Elvish Mobility works fine every time I used it on the test server. Haven't encountered a game breaking bug as of yet. On the topic of testing, I must wonder how you accomplished this feat Phaselock. Was it through legitimate or by other means?
erm, which initial bug ? This was what happened during yesterday's test, see below pic. phaselock elf wiz played EM, lockphase priest triggered first. lockphase dc'ed... the rest is as per posted. Tested again today and its slightly different this time round. After lockphase dc, i see the player switch after a timed interval and the elf wizard was asked to move. Idling triggered snoozi successfully. In yesterday's test, snoozi did not trigger... That the only diff. BATTLE LOG: Scenario=MP Celestial Dojo,Room=phaselock's battle vs lockphase,RoomID=8,Msg=The active player is now phaselock stopTimer 1 1147 BATTLE LOG: Player=phaselock,Scenario=MP Celestial Dojo,Room=phaselock's battle vs lockphase,RoomID=8,Event=PlayAction,Action=Elvish Mobility,Instigator=Thienenu,Targets= startTimer 0 1137 startTimer 1 1147
Things are working nice. Perhaps you will fix/update the monster selection in the next build to remove/fix the bugged NPCs.
