2008 site comments

[Duplode]

Zak: here and there I run into a minor issue with the site I don't know if it is really a bug, or whether there's a way to "fix" it. Often I go into the page to post something, post the message, leave the tab open and go do something else. Then, after I return to the page and hit "refresh" out of reflex, the message is posted again despite the text box being apparently cleared. Since everyone hates double posts, would you please give it a look if it can be helped?

[zaqrack]

well, it must be because of some cookie. I'll try to fix it, but its not really my field, I was happy enough to find out how to maintain logged in users throughout the site...

[BonzaiJoe]

When I refresh with a blank news-posting field, I get a prompt saying "you cannot refresh without re-sending information" or something like that. Isn't it rather that the URL is cloaked, and when you reload, even though it just looks like "stunts.hu/zak", it is actually a news-posting URL? Well I don't know much about these things...

[Duplode]

When I refresh with a blank news-posting field, I get a prompt saying "you cannot refresh without re-sending information" or something like that. Isn't it rather that the URL is cloaked, and when you reload, even though it just looks like "stunts.hu/zak", it is actually a news-posting URL? Well I don't know much about these things...

Yep, I get that "The page contains POSTDATA, blah blah blah" dialog too, but usually I click OK before I get to think on what I'm doing. Even though it is my fault at the end ( ), I wondered whether there would be a way to clear the message the "cache" (I know this isn't the proper term) after you click post.

[CTG]

Zak: is it possible to code an automatic update to the end of the month? The system could publish the hidden times after the deadline, adding them to the scoreboard. It would be easier for you, immediate info for us.

[zaqrack]

it was meant to work this way, but actually it doesn't. I'm activating the hidden times now, but the update will be delayed to thursday or friday - sorry I'm really unable to do any proper work today :-S

[CTG]

Zak: is it possible to filter unfinished replays with RPLInfo? It always happens once or twice a month that somebody (it's me this time) sends a false replay by accident.

[zaqrack]

No. The only thing I could filter are "null" replays (when you forget to attach a replay, which results in 0.:27.60)

[dstien]

I checked a few replays and it looks like 20 0x00 bytes will be added after the finish line is crossed. The problem is that the user can press escape after finishing, in one of my tests I could cancel the recording exactly at the finish line (no 0x00 bytes written). However, by using heuristics we could guess that a replay not ending with a few 0x00 bytes does not cross the finish line and at the very least ask the user for confirmation.

Also, the track section embeded in the replay file should be checked, but you probably do this already?

[zaqrack]

I checked a few replays and it looks like 20 0x00 bytes will be added after the finish line is crossed. The problem is that the user can press escape after finishing, in one of my tests I could cancel the recording exactly at the finish line (no 0x00 bytes written). However, by using heuristics we could guess that a replay not ending with a few 0x00 bytes does not cross the finish line and at the very least ask the user for confirmation.

Also, the track section embeded in the replay file should be checked, but you probably do this already?

that's a good idea. If you cancel the replay recording before it ends by itself, the replay is considered invalid (as the time is calculated from the replay length)

I'll include this check for 20x 0x00 byte soon in the rpl sending code.

and no, the track is not verified yet. But it's only a matter of time. 

[dstien]

If you cancel the replay recording before it ends by itself, the replay is considered invalid (as the time is calculated from the replay length)

Indeed. I didn't realize this, it's possible to cheat up to -1 second by simply deleting 20 bytes.

[Duplode]

While I was watching Z88 replays for performing the analysis, I identified a few issues with tgm's replay, a BB 1.0 lap. First of all, it was not finished, but rather stopped in the middle of the final cork l/r. The additional ~2.8s would not affect the final scoreboard order, and it probably wasn't done in bad faith - the probable scenario was tgm realized having sent an invalid lap, sent a proper replay one hour later (as shown by the stats) but, either thinking the system would deal automatically with such problems or just driven by general newbie shyness, did not warn Zak of what had happened. Anyway, such issues may well happen again with other newbies on the future, and thus the "20 0x00" check appears to be more important after this. There is a second, more subtle problem: as mentioned, his lap was done with BB 1.0 . Looking at the scoreboard or with RPLInfo, the returned length of the replay is 1:55.30; however the actual replay tape stops at 1:56.40... the 0.1s difference appears to come from the different .RPL headers from versions BB1.0 and BB1.1, which mean laps having the same length will result in files two bytes longer if they are done in BB1.1 . That is another issue to be checked if support for versions other than BB1.1 is to be kept.