Open, human-readable minesweeper video format

Area to discuss development and bugs of official clones (Clone, Arbiter, MSX, Viennasweeper)
User avatar
Tommy
Posts: 223
Joined: Mon Dec 01, 2008 9:22 pm
Location: Vienna

Re: Open, human-readable minesweeper video format

Post by Tommy » Sat Sep 25, 2010 9:18 am

Oh yeah, and I just reread this:
Cryslon wrote:I wrote avf2rawvf.

It writes only mouse events and not board events. Reasons for this were:
1) i think we should separate these two tasks: one program (like avf2rawvf) takes protected format and produces mouse event stream in rawvf, and another program takes this mouse events and produces board events. Notice that first program could be written only by clonemaker since he is the only man to have knowledge about his protected binaries. The second program may be basically written by any person who owns the clone and may test its mouse events processing.
2) i'm pretty disappointed because of total lack of enthusiasm showed by clonemakers. Damn, it takes at most half an hour to write the convertor, and they're still too lazy to write even the light version.
@1):
While I think that we can't expect that from any clonemaker, I do think that the optimal case is that the clonemaker writes a direct converter to tvf - The clonemaker is still the person that has the easiest job doing this by _far_. Simply running the replay routine (modified) and gathering board events would be a dirty, but very quick way to do that. (And yes, I know what the arbiter source code looks like - but from what I remember, arbiters design patterns suit that kind of dirty hack pretty well ;))
Don't anthropomorphize computers - they don't like it.

CBright
Posts: 39
Joined: Sun Nov 30, 2008 11:53 pm
Contact:

Re: Open, human-readable minesweeper video format

Post by CBright » Sat Sep 25, 2010 10:59 pm

Tommy wrote:rawvf contains mouse events and a unique identifier for the clone that the video was made on (or a group of compatible clones - arbiter43, arbiter44, clone 97, clone20x, for instance).
Now, this raises the question: do we want special clone-specific video players? Personally, I think we have some right to declare any click processing discrepancy with the original as bugs (excepting the original's bugs).
Tommy wrote: 1.) It seperates the converter and the video player, making the whole process less bug-prone
But any bugs caused by the converter will be preserved to disk, and might not be evident to a video player. Better to distribute the click processing rules and let video players follow them than to follow board events for which there is no guarantee they weren't generated by faulty click processing rules.

I think basically you've reinvented *.rmv, except as text based rather than binary. Of course that's fine, but at least rawvf solved a pressing problem.
CBright wrote:Maybe I'll start using "sc" to also mean "right click with left pressed" when the left press wasn't recorded; that should allow proper playback, but makes "sc" ambiguous as to what button was pressed.
I realized this still wouldn't work when it was a release event that was missed. My proposal now is to use "left toggle" and "right toggle" events, which switch the state of the button without a press/release event. There could also be a "middle toggle", but that is technically not necessary, at least for *.mvr. Anyone know anything about *.mvf?

User avatar
Tommy
Posts: 223
Joined: Mon Dec 01, 2008 9:22 pm
Location: Vienna

Re: Open, human-readable minesweeper video format

Post by Tommy » Sun Sep 26, 2010 10:10 pm

CBright wrote:
Tommy wrote:rawvf contains mouse events and a unique identifier for the clone that the video was made on (or a group of compatible clones - arbiter43, arbiter44, clone 97, clone20x, for instance).
Now, this raises the question: do we want special clone-specific video players? Personally, I think we have some right to declare any click processing discrepancy with the original as bugs (excepting the original's bugs).
I actually think we have to accept all behaviour clones produce/have produced. Consider what arbiter did before .43 - that ís definetly not acceptable by your definition. Yes, games making use of that did not count for highscores. But, for instance, an old highscore of mine*, played on a more recent version of arbiter, would have been a blast (in the last couple of seconds too) if I'd played it on arbiter43. There is no way to represent a blast like this if we assume that there is only one acceptable behaviour given a "stream" of mouse events. There may be real old arbiter videos of interest that suffer from this.

* (it can be found here http://www.youtube.com/watch?v=qqWOjsmwA50, and I'm not sure, but I guess this http://minesweeper.cc/uploaded/videos/T ... _42.16.avf is the correct avf)
CBright wrote:
Tommy wrote: 1.) It seperates the converter and the video player, making the whole process less bug-prone
But any bugs caused by the converter will be preserved to disk, and might not be evident to a video player. Better to distribute the click processing rules and let video players follow them than to follow board events for which there is no guarantee they weren't generated by faulty click processing rules.

I think basically you've reinvented *.rmv, except as text based rather than binary. Of course that's fine, but at least rawvf solved a pressing problem.

...
They shouldn't be evident to the video player IMO - the video player can be a dumb terminal. Or, of course perform analysis on the video, maybe to find flaws in click handling behaviour of different clones. Or whatever, you get the picture. This also opens the door to viewing videos produced by "lucky mode" clones, for instance. Or in general, varieties that don't adhere to the classic minesweeper rules. What if we are talking about a version that uses input methods other than a mouse? Somehow hacking together mouse events that do the same might work, but a stream of board events is a more accurate representation of what happened (and the video won't look stupid in implementations that are not aware that no mouse was used, and display a cursor haphhazardly and irritatingly jumping across the board, for example).

And yup, this is very close to a 1:1 text impementation of rmv.

About bugs being preserved on disk - sure, but how severe can they get? Basically, we are talking about a display glitch (since text-based video formats will never be authoritative anyway). In the beginning, some converters might produce imperfect output, and the worst case is that a couple of not entirely consistent videos remain online somewhere (If the videos are unusable, they will either be replaced or deleted).
Don't anthropomorphize computers - they don't like it.

User avatar
Tommy
Posts: 223
Joined: Mon Dec 01, 2008 9:22 pm
Location: Vienna

Re: Open, human-readable minesweeper video format

Post by Tommy » Sun Sep 26, 2010 10:15 pm

Oh yeah, and I completed a Python implementation of rmv2tmv today - I'll post it when I have tested and debugged it. I'm also done on a rmv player that could, in theory, be just as easily used with tmv, but that is work in progress (the rmv player started out as a proof of concept long ago).
Don't anthropomorphize computers - they don't like it.

CBright
Posts: 39
Joined: Sun Nov 30, 2008 11:53 pm
Contact:

Re: Open, human-readable minesweeper video format

Post by CBright » Mon Sep 27, 2010 11:29 pm

Cryslon, how about for revision 5:
<left_toggle> ::= lt
<right_toggle> ::= rt
<middle_toggle> ::= mt
<question_mark_toggle> ::= qt

"mt" is just there for completeness (and maybe some clones actually need it). Really, these events are mostly theoretical in that they shouldn't occur in competitive play, so technically I guess they wouldn't need to be a part of the official standard.
Tommy wrote:But, for instance, an old highscore of mine*, played on a more recent version of arbiter, would have been a blast (in the last couple of seconds too) if I'd played it on arbiter43.
OK, for historical purposes. But still, that behaviour could be considered a bug.
Tommy wrote: This also opens the door to viewing videos produced by "lucky mode" clones, for instance. Or in general, varieties that don't adhere to the classic minesweeper rules. What if we are talking about a version that uses input methods other than a mouse?
Lucky mode? So the clone is allowed to move mines around as long so long as it is consistent with the numbers on the board? And a clone which doesn't use a mouse? It's not that I think your format is useless, but it seems to be a different project than Cryslon's project.
Tommy wrote:About bugs being preserved on disk - sure, but how severe can they get?
I just think it doesn't necessarily make the process less bug-prone.

Cryslon
Posts: 122
Joined: Sun Dec 28, 2008 7:41 pm

Re: Open, human-readable minesweeper video format

Post by Cryslon » Tue Sep 28, 2010 8:26 am

CBright wrote:Cryslon, how about for revision 5:
<left_toggle> ::= lt
...
I don't quite understand why these "toggle" events are needed. "Click" is like set button state = pressed, and "release" is set button state = released. I just don't see need for additional complexity.

Am i right that you don't want to represent sequence like "move pressed mouse out of board - release out of board - return to board" as "release" because you haven't tracked "real" release event and its precise time? I think it's pretty OK if you just add fake "release" event when mouse is returned into board borders.
CBright wrote: Lucky mode?
I'm a supporter of lucky mode and of course i want rawvf to represent lucky-mode videos. And i see absolutely no difficulties with current format. RawVF player will be able to know the game was lucky by "Mode" option; and since RawVF player (without board events) is to implement all the minesweeper logic, i see little difficulty in implementing lucky mode as well. The luck just has to be well-described, and i'm certainly going to release my lucky-mode code and descriptions when i finish it.
CBright wrote: Personally, I think we have some right to declare any click processing discrepancy with the original as bugs (excepting the original's bugs).
Yes, i support such approach, but we still need to emulate old clones behaviour.

I don't want to split the format into several formats. How about such solution: make board events optional and add "HasBoardEvents" option.

And seems that, after converter for rmv release, the main problem will be mvf. Could anybody bring Rodrigo back?
Go IRC! (try mibbit)

CBright
Posts: 39
Joined: Sun Nov 30, 2008 11:53 pm
Contact:

Re: Open, human-readable minesweeper video format

Post by CBright » Tue Sep 28, 2010 10:42 am

Cryslon wrote:I don't quite understand why these "toggle" events are needed. "Click" is like set button state = pressed, and "release" is set button state = released. I just don't see need for additional complexity.
The problem is that the clone may not have received the click/release events (e.g., they were received by some other application) so the true state is desynchronized with the state in this simple approach. And click/release events can't be used to represent only a button state change, as they do more than just change the button state; they also change the guessing "press status".

How about this: a rule like if (column, row) = (0, 0) then click/release events should only change the button state and NOT be processed like a BUTTONDOWN/UP message.

Cryslon
Posts: 122
Joined: Sun Dec 28, 2008 7:41 pm

Re: Open, human-readable minesweeper video format

Post by Cryslon » Wed Sep 29, 2010 8:17 am

CBright wrote: The problem is that the clone may not have received the click/release events (e.g., they were received by some other application) so the true state is desynchronized with the state in this simple approach.
Ah, got it.
How about this: a rule like if (column, row) = (0, 0) then click/release events should only change the button state and NOT be processed like a BUTTONDOWN/UP message.
I don't like this because we will need to specify it in the format and it is complication. Can you please describe situations for which such events are needed?
Go IRC! (try mibbit)

CBright
Posts: 39
Joined: Sun Nov 30, 2008 11:53 pm
Contact:

Re: Open, human-readable minesweeper video format

Post by CBright » Wed Sep 29, 2010 2:10 pm

Cryslon wrote:Can you please describe situations for which such events are needed?
The most usual condition is that the mouse is off of the board. From MSDN:
MSDN wrote:If an application has not captured mouse input and the user releases the mouse button outside the window, the window does not receive the button-up message.
But something that I just learned:
MSDN wrote:When mouse messages are posted faster than a thread can process them, the system discards all but the most recent mouse message.
I think this explains the bug video of KAmil's from before. I don't know how often this happens but conceivably click events could be missed during competitive play! Scary! :o

User avatar
Tommy
Posts: 223
Joined: Mon Dec 01, 2008 9:22 pm
Location: Vienna

Re: Open, human-readable minesweeper video format

Post by Tommy » Thu Sep 30, 2010 9:09 am

@current discussion:
Just log the events the application recieved? I don't see the problem. What the application recieved is 1:1 what it processes, so saving that is sufficient to determine what it did (or, alternatively, what it should have done given what it "saw").

Longer post following, I don't have time to finish it just yet.
Don't anthropomorphize computers - they don't like it.

CBright
Posts: 39
Joined: Sun Nov 30, 2008 11:53 pm
Contact:

Re: Open, human-readable minesweeper video format

Post by CBright » Thu Sep 30, 2010 5:04 pm

Tommy wrote:Just log the events the application recieved? I don't see the problem. What the application recieved is 1:1 what it processes, so saving that is sufficient to determine what it did (or, alternatively, what it should have done given what it "saw").
Except that the true state of every button is given in every event the application receives, and this currently can't be recorded with rawvf.

User avatar
Tommy
Posts: 223
Joined: Mon Dec 01, 2008 9:22 pm
Location: Vienna

Re: Open, human-readable minesweeper video format

Post by Tommy » Mon Oct 04, 2010 8:17 am

CBright wrote:
Tommy wrote:Just log the events the application recieved? I don't see the problem. What the application recieved is 1:1 what it processes, so saving that is sufficient to determine what it did (or, alternatively, what it should have done given what it "saw").
Except that the true state of every button is given in every event the application receives, and this currently can't be recorded with rawvf.
In which case both will need to be in the format if every possibility is to be representable.
However, states can be implicit on the events that took place before (and on an initial situation where every state is "released"), and explicit states only need to be included where they are not congruent with what one would expect (the way it was left by the last event including or implying that state).
Don't anthropomorphize computers - they don't like it.

Cryslon
Posts: 122
Joined: Sun Dec 28, 2008 7:41 pm

Re: Open, human-readable minesweeper video format

Post by Cryslon » Mon Apr 16, 2012 6:37 pm

I added the stuff suggested by Thomas and Curtis to the revision 5.

Don't know if using RawVF as a protected format is a good idea though: it is larger than a binary format, and a collection of RawVF videos may take much more space than a usual collection of binaries.
Go IRC! (try mibbit)

CBright
Posts: 39
Joined: Sun Nov 30, 2008 11:53 pm
Contact:

Re: Open, human-readable minesweeper video format

Post by CBright » Tue May 08, 2012 7:09 pm

Thanks Cryslon. I updated mvr2rawvf so that it outputs to RawVF revision 5. It now uses negative time for events before the game starts and specifies the true mouse state for mouse_move events. Additionally, it uses the player name from the video file if available.

And I have some news: I was able to contact Rodrigo by instant message. I told him about the clone issues (apparently he doesn't read email very often) and asked him about extracting data from mvf files. He said he might be able to write a converter, but not for a few months. If that doesn't happen I say we should start a reverse-engineering project.

Cryslon
Posts: 122
Joined: Sun Dec 28, 2008 7:41 pm

Re: Open, human-readable minesweeper video format

Post by Cryslon » Tue Oct 23, 2012 5:49 pm

Here's a new avf2rawvf which handles Freesweeper's "left click with shift/ctrl pressed" events, and also an implementation of rmv2rawvf.
Attachments
rmv2rawvf.zip
(20.68 KiB) Downloaded 478 times
avftools.zip
AVFTools 0.4
(38.42 KiB) Downloaded 565 times
Go IRC! (try mibbit)

Cryslon
Posts: 122
Joined: Sun Dec 28, 2008 7:41 pm

Re: Open, human-readable minesweeper video format

Post by Cryslon » Mon Jul 29, 2013 3:42 pm

Here's a program that processes MVF (yay! finally i'm able to watch all these world records) and a program that adds board events to RawVFs, but it's very far from ideal.
Attachments
rawvf2rawvf.zip
rawvf2rawvf 0.1
(18.71 KiB) Downloaded 430 times
mvf2rawvf.zip
mvf2rawvf 0.1
(13.21 KiB) Downloaded 450 times
Go IRC! (try mibbit)

zhangshenjia
Posts: 8
Joined: Tue May 21, 2013 3:01 am

Re: Open, human-readable minesweeper video format

Post by zhangshenjia » Mon Nov 11, 2013 12:26 am

there is no 3BV and Time in avf2rawvf....

Cryslon
Posts: 122
Joined: Sun Dec 28, 2008 7:41 pm

Re: Open, human-readable minesweeper video format

Post by Cryslon » Mon Nov 11, 2013 8:08 am

zhangshenjia wrote:there is no 3BV and Time in avf2rawvf....
Yeah, that's because, unlike MVF, AVF doesn't contain 3BV. avf2rawvf isn't meant to analyze videos or output anything besides already present bits.

That's what rawvf2rawvf is for.
Go IRC! (try mibbit)

zhangshenjia
Posts: 8
Joined: Tue May 21, 2013 3:01 am

Re: Open, human-readable minesweeper video format

Post by zhangshenjia » Mon Nov 11, 2013 8:26 am

Actually, you can found 3BV and Time in below string (which you pick timestamp from):

[2|5.11.2013.13:06:07:4464|5.13:08:46:9921|HS|B154T160.45]

3bv: 154, time: 160.45

I add this to your code to let it read 3BV and time from AVF:

Code: Select all

int bbbv;
int score_sec,score_ths;
...
// get 3bv
	while(_fgetc(AVF)!='B');	
	for(i=0;i<7;++i) cr[i]=0;
	i=0;
	while(c=_fgetc(AVF))
	{
		if (c=='T') break;
		cr[i]=c;i++;
	}
	bbbv=atoi(cr);

	// get time
	for(i=0;i<7;++i) cr[i]=0;
	i=0;
	while(c=_fgetc(AVF))
	{
		if (c=='.') break;
		cr[i]=c;i++;
	}
	score_sec=atoi(cr)-1;	// real time = time - 1
	for(i=0;i<7;++i) cr[i]=0;
	i=0;
	while(c=_fgetc(AVF))
	{
		if (c==']') break;
		cr[i]=c;i++;
	}
	score_ths=atoi(cr);	
...

	printf("Time: %d.%d\n",score_sec,score_ths);
	printf("3BV: %d\n",bbbv);
Attachments
avf_parser.c.zip
(2.4 KiB) Downloaded 245 times

zhangshenjia
Posts: 8
Joined: Tue May 21, 2013 3:01 am

Re: Open, human-readable minesweeper video format

Post by zhangshenjia » Mon Nov 11, 2013 8:34 am

BTW, I found some MVF videos which was made by Clone 0.97 can not be parsed by your code. I found all of them have a different head with normal MVF videos, but those videos can be played normally by Clone 0.97. I attached one of those videos here.

In the end, I found below code works well with those videos. Although data can be read from those videos, I have no idea about the Clone version and I use "0.97 lost head" by now.

Code: Select all

...
    else if (c==0x00 && d==0x00)
    {
        /* lose some head info*/
        fseek(MVF,7,SEEK_SET);
        version="0.97 lost head";
        return read_097();
    }
...
Attachments
a.mvf.zip
(694 Bytes) Downloaded 265 times
mvf_parser.c.zip
(4.78 KiB) Downloaded 239 times

Cryslon
Posts: 122
Joined: Sun Dec 28, 2008 7:41 pm

Re: Open, human-readable minesweeper video format

Post by Cryslon » Wed Nov 13, 2013 7:53 pm

zhangshenjia wrote:BTW, I found some MVF videos which was made by Clone 0.97 can not be parsed by your code.
Seems to me the games were played on a hacked version of Clone... At least the original strings were deleted and replaced with the empty ones - we can only guess why it was done.
Actually, you can found 3BV and Time in below string
oh, forgot about that one

How do you use rawvf's by the way?
Go IRC! (try mibbit)

zhangshenjia
Posts: 8
Joined: Tue May 21, 2013 3:01 am

Re: Open, human-readable minesweeper video format

Post by zhangshenjia » Sat Nov 23, 2013 1:41 am

zhangshenjia wrote:Actually, you can found 3BV and Time in below string (which you pick timestamp from):

[2|5.11.2013.13:06:07:4464|5.13:08:46:9921|HS|B154T160.45]

3bv: 154, time: 160.45

I add this to your code to let it read 3BV and time from AVF:

Code: Select all

int bbbv;
int score_sec,score_ths;
...
// get 3bv
	while(_fgetc(AVF)!='B');	
	for(i=0;i<7;++i) cr[i]=0;
	i=0;
	while(c=_fgetc(AVF))
	{
		if (c=='T') break;
		cr[i]=c;i++;
	}
	bbbv=atoi(cr);

	// get time
	for(i=0;i<7;++i) cr[i]=0;
	i=0;
	while(c=_fgetc(AVF))
	{
		if (c=='.') break;
		cr[i]=c;i++;
	}
	score_sec=atoi(cr)-1;	// real time = time - 1
	for(i=0;i<7;++i) cr[i]=0;
	i=0;
	while(c=_fgetc(AVF))
	{
		if (c==']') break;
		cr[i]=c;i++;
	}
	score_ths=atoi(cr);	
...

	printf("Time: %d.%d\n",score_sec,score_ths);
	printf("3BV: %d\n",bbbv);
Sorry, I miss %02d in printf, so it will parse 10.01 to 10.10.

Code: Select all

printf("Time: %d.%02d\n",score_sec,score_ths);

zhangshenjia
Posts: 8
Joined: Tue May 21, 2013 3:01 am

Re: Open, human-readable minesweeper video format

Post by zhangshenjia » Sat Nov 23, 2013 1:45 am

Cryslon wrote:
zhangshenjia wrote:BTW, I found some MVF videos which was made by Clone 0.97 can not be parsed by your code.
Seems to me the games were played on a hacked version of Clone... At least the original strings were deleted and replaced with the empty ones - we can only guess why it was done.
Actually, you can found 3BV and Time in below string
oh, forgot about that one

How do you use rawvf's by the way?
I compile it on web server, and invoke it by php code to parse videos. I'm done with data parsing, and heading to make a online video player.

BTW, we are testing new version of saolei.net now. http://new.saolei.net

Cryslon
Posts: 122
Joined: Sun Dec 28, 2008 7:41 pm

Re: Open, human-readable minesweeper video format

Post by Cryslon » Sat Feb 08, 2014 8:51 pm

Fixed the bug with incorrect processing of simultaneous mouse press and release events of different buttons. Clone saves only current mouse state, not mouse events, in MVF, and thinks that release events precede press events; mvf2rawvf previously thought press events preceded click events.
Attachments
mvf2rawvf.zip
mvf2rawvf 0.3
(11.51 KiB) Downloaded 289 times
Go IRC! (try mibbit)

crazyks
Posts: 4
Joined: Wed Jan 08, 2014 4:16 pm

Re: Open, human-readable minesweeper video format

Post by crazyks » Thu Apr 17, 2014 11:34 am

Dear Cryslon,
There is a bug in your code rawvf2rawvf.c line 940.

Code: Select all

int board_event,len=strlen(event);
fgets(event,MAXLEN,input);
if(feof(input)) break;
		
board_event=len<=2 || event[0]=='c' || event[0]=='f' || event[0]=='q' || event[0]=='p' || event[0]=='n';
You get the string length at the defination, but the event will be changed after calling fgets. So in some situation, the result will be wrong. I tested one of kamil's rmv videos. first I use rmv2rawvf to convert the rmv file to a txt file, then use your rawvf2rawvf to convert it to a parsed txt file. But it shows that the game is not won! However, it can play well. So I found this issue. The code should be changed like the following

Code: Select all

int board_event,len;
fgets(event,MAXLEN,input);
if(feof(input)) break;
		
len=strlen(event);
board_event=len<=2 || event[0]=='c' || event[0]=='f' || event[0]=='q' || event[0]=='p' || event[0]=='n';
Then I re-compile the rawvf2rawvf, the txt file can be parsed correctly.

The attached are my code & the kamil's video that I tested.
Attachments
rawvf2rawvf.zip
(47.89 KiB) Downloaded 224 times
kamil_int_nf_bvs4.552.rmv
(20.13 KiB) Downloaded 202 times

Post Reply