This has stopped working for some reason. When I click on "Last turn" the turn starts loading (you can tell because you can click on "Stop loading") but after a second or two the replay ends with the usual "Continue" dialogue box. The actual turn hasn't been replayed though. Not a single move in the turn is displayed. Anyone else seen this?

Unfortunately, this is [very] old news.  The devs are not prioritizing fixing the replays.  It must be too much work, and/or difficult to debug?

Well, it's odd because the replays *did* work perfectly when I first joined and they still do from time to time (though increasingly rarely). What a pity they are not getting worked on because I think they're very useful, especially for a beginning player like me.

Nice to get your vote on this, though.

Replays are horrible. They never work. Take that button out.

And even if I ever (dare to) click on the 'replay' button, it even hangs up my firefox, forcing me to close all other tabs, and gmail chat windows involving many pretty ladies

oooh, that sucks.  it doesn't hang ff for me.

Weewar without replays is a bit like playing chess closing your eyes when your opponent moves.

^^ that is a nice analogy

I'll throw my voice in for a working replay last turn feature.  I often want to see what happened.

+1 for last turn replay. Sure, a whole game review might be nice but a luxury. Knowing what happened last turn, especially in multiplayer games is close to a necessity. It's easily the biggest complaint I hear from my gaming buddies. Even a log just listing what happened would be very helpful.

I got used to it long ago, I am not even aware anymore of the buttons existence, but it pisses me off that I never see what was done the last turn. a textbase log would be nice, if I only knew which of my units got killed would be an advantage.

I heve never ever even once seen the last turn replay work. so one month into my weewar career, I stopped trying

off and on for me... although that month for you streen must've been when it was really truly completely down though.

It's off and on for me, but tends to be on only during early turns, and then dies as the game progresses.  The devs have hinted that it has to do with some malformed or illegal event data being injected into the event log, and the replayer is unable to handle them.

One possible solution is to get willing players to use a GM script which sends move data to a third party server which logs the moves independently of weewar.com .  The only issue there is getting all the people you play with to agree to download and use such a script.  The only remote chance of this happening that I see is if something like the WWPA enforces usage of such a script for WWPA members.  But that seems a bit too drastic.

Would the script not suffer from the same problems as the official replay-recorder?

and if not, why not write the script then provide it to the devs to replace the code that's currently handling it.

Super-King: I don't know the complete nature of the actual problems, but the proposed script would be developed completely independently.  Off the top of my head, I'm thinking it would simply capture every action (move, build, attack, etc.), including undos, and fire them off to the logging server.  I'm not sure this wouldn't be blocked by browser's cross-site scripting protection, though.

But anyway, it couldn't replace the code that's currently handling it, because it would be a completely different beast -- different architecture, different data format.  For as long as the game remains closed source, third-party contribution and improvement is stifled; a nocturnal hike of sorts.

If only the devs would let us in on how things are run, then some of us with the time, skill, and motivation, like Pistos, could help out

If they're making money, probably not going to happen.  You'd dilute or give away your marketshare by open sourcing, because anyone can use the code to run myownweewar.com.

Writing a game replayer isn't that hard as the whole history of each game is served up as a giant XML document. I have code running on my laptop that parses the XML and replays the whole game, but it needs a fair bit more work to make it actually useful (i.e. being able to jump to rounds, replay just the last round, UI etc.) I'll probably publish it at some point.

However what the devs are doing wrong (imho) is they are looping (with a for/each) over each "event" in the XML file, and any browser worth it's salt will say it's a 'long running script' and also not have a chance to update the display. A fix is to have a pointer to the current 'event', parse the event, update the display, increment the index by 1, and then set a timeout for 50ms or so to call the whole function again. That way it's not one long running script, but smaller function calls one after the other, with an amount of time to let the browser breath inbetween updates.

Well that's what I'm doing anyway Nothing as complex as a 3rd party logging server needed. Oh Screencast of what I have so far (running realtime in JavaScript)

   -D

If you want to have a go yourself, here's a link to the XML history for a game I'm currently in, from which the above screencast was taken, you can change the "object=77027" to the id of your own game (sorter games will download quicker) ...

(warning, it's a big XML file, and your browser may take up-to 2 minutes to render it, so go make a cup of tea or something. All the moves from our game are in there, around 40 rounds worth)

 http://battleground3.weewar.com/ajax/click.jsp?tbUid=12345678901234&object=77027&method=initialState

  -D

revdancatt: A third-party replayer has already been done: http://weewar.purepistos.net/wwpa/replayer/23689

The problem is not the doing of such a thing, the problem is that the actual data is corrupt on the server; invalid events, missing events, etc.  I also don't think "long running"ness is the issue, as the WWPA replays function fine even for many-round-ed games.

IMO, the issue more likely lies right at the injection of events into the log, server side.  My guesstimate is that they are injecting all or nearly all actions from the browser, including things that the user undoes, or double issues of events (due to general Internet slowness, which causes users to retry actions), and such.  As a result, you get inconsistencies, incongruencies, and other illogic, such as repeated move events.  A replayer (whether official or third-party) can try to work around these problems, as I have done on the WWPA replayer, skipping over duplicate events, etc., but sometimes a particular flaw in the event log of a game is so severe that it is beyond recovery.

But you and I and anyone else can speculate all they like; it's almost wasted breath for as long as the devs remain tight lipped about it and keep the replay mechanism closed source, undetailed and undocumented.

I only suggested a 3rd party logging server *because* I think the logging mechanism of the actual game is flawed.  If a logging mechanism (whether the real one, or third party) can be guaranteed to generate flawless event logs, then (1) nobody, core dev or third party dev, should have any trouble making a replayer, and (2) replays would probably never be broken because the log data is error-free.

If the current logging mechanism is flawless, why are the served event data defective?  Is the server somehow having trouble generating XML from the database?  Or are we losing TCP/IP packets on the way?  I think we can all agree that these are unlikely scenarios.  The data is more likely tainted right at injection time.

Ah, thank you for the detailed response. I've clearly not been trying it with enough game samples to come across the problems you mention. And obviously you're right we can only speculate where the problem happens.

Although if it were tainted at injection time, wouldn't there be a case that if a user closed the browser just after a tainted injection, when they came back to the game, and the map/units state was rebuilt from the data held in the database (to create the html for the page), that new state would also be corrupt. If that's never a problem, then it suggests that at the very least the data held in the database for the most recent position is always correct, or they somehow always correct for tainted injections at that point?

Anyway, I guess an alternative could be, as your wwpa tool polls the weewar API (yes?) to find out when it's a players turn, is to grab the html of the game from the weewar server at that point (or at regular intervals) and extract the position of the units and bases from the page source. And then use that as a checksum against the replay XML, incase anything get messed up along the way. Although that's fairly convoluted in itself and scaling is an issue. Ho hum.

I do think the "long running"ness is an issue in replaying on the weewar website. The WWPA replay functions just fine because, from a quick glance, it's using some event/animation based code, with callback functions being set, so when an animation is complete the next function is called. Somewhere in the animation code (because you can set the speed) "setTimeout"s will be being used, so the code won't be one continuous block/loop of running script. And so it runs just fine.

On the weewar website itself there are no-such timeouts, it is just one giant loop. When I run it through a profiler/firebug that's where it hangs. Besides, in the case of my current game, 77027, the replay on the site doesn't work (it hangs the browser in the loop), but in my own replayer does work, both using the same XML. And I'm not making any corrections of corrupt data because I wasn't aware of any. Assuming then that the data is good, it must be hanging for some other reason ... in this particular instant.

Guess I'll need to poke around with it a bit and to get some corrupt data I just need to play some more games, which I'm sure we can all agree doesn't sound like a bad thing to have to do

I suspect they keep the game state and the event log separate.  I don't think they build the terrain and unit positions, etc. from the database whenever you go to take your turn.  Otherwise, it would suffer from the same problems as the replay, I reckon?

Actually, the WWPA doesn't poll anything for the replays.  It pulls the XML in one shot, just like you do.

Nice insight on the on-site replayer.  Thanks for sharing.  Let us know any further findings.  I'd love to be able to "decorrupt" even some fraction of the corrupt replays.

Interesting. Time to tinker!

I've been tinkering with the javascript and I think revdancatt is on to something here. I think the devs might have changed the replay stuff recently and it might actually be that the last problem to get around is the long long time of looping through the events. (relatedly, pistos, your replayer doesn't work for me. I get an error msg.)

Take a look at this game where the replay is broken: http://battleground3.weewar.com/game/62297

There are about 5211 events in this game. When I told it to replay, I got this message from Firefox: "A script on this page may be busy, or it may have stopped responding. You can stop the script right now, open the script in the debugger, or let the script continue." Why is it taking so long?

Well, here's what a part of the code seems to be doing: For every event in the XML, check to see if this event is a duplicate event by comparing it to all of the included events in the collection "events", and if it's not a duplicate, add the event to the collection "events". This is insanely slow when you have a large number of events (O(n^2) perhaps)! And it seems to be why currently, only games with few events have working replays.

For the record, I had to hit continue about 50 times before the game started replaying. The collection "events" ended up having size 5195 (There are 5211 instances of "<event id=" in the XML.) What's kinda odd is that once the game started replaying, the script was still going through the for-each and for loops, slowing things down, eventually hanging firefox again and again.

revdancatt's solution might work: "A fix is to have a pointer to the current 'event', parse the event, update the display, increment the index by 1, and then set a timeout for 50ms or so to call the whole function again. That way it's not one long running script, but smaller function calls one after the other, with an amount of time to let the browser breath inbetween updates."

but I think there still would be the problem of checking for duplicates, a problem that I think is best resolved by somehow preventing duplicates in the first place when they're being saved into the database.

On a related note, Replay Last Turn generates a null pointer starting in the turn after starting to capture a unit (i.e. the turn where a capturing unit will finish capturing at the end of the turn).

Forgive me for possibly being naive and oversimplifying (bert, chime in any time now), but the obvious solution is not to inject log data unless it actually corresponds to an irreversible action.  That is, let people move and undo over and over to their heart's content, but not log anything unless the action is irreversible.  i.e. under these conditions: it's a second-last move (the last move is undoable); it's an attack; the user has ended turn; etc.

This way, you are not doing any duplication checking at all, and you don't care how many times the browser is refreshed, or extra AJAX hits go to the action URIs, etc.

*shrug*

The replay links are gone!

Why, so they are... I wonder what this means?  :)