So we can give Zak our feedback...
As for me, everything looks nice, clear and simple. My only suggestion for now, which is completely unrelated to the new stuff anyway, is to make some secondary colours on pipsqueaks' profiles (like on borders or textbox foreground/backgrounds) customizable, so that we could, for instance, apply team colours on them. Also, will data on Car Bonuses for older tracks be stored on "Car Bonuses" pages, or in the old scoreboards themselves?
Site looks as good as usual, and idea is great. No negative comments about it (at least not yet ;))
One important and useful update which you cant see right now, is the update of the replay sending form.
The only data you have to enter is the penalty. The car and the transmission type is extracted from the rpl file.
Quote from: zaqrack on December 29, 2007, 12:12:22 AM
The only data you have to enter is the penalty.
And the .rpl file, of course! :D
please post here all the troubles and errors you encounter on the site. thanks!
Maybe it's only my PC but podium always leaves an empty column between 1st and 2nd place.
as i recall thats a common bug with Internet Explorer. Do you use IE?
Yes, I do. Then that's the problem. Anyway, it won't kill me to see it that way.
Zak, is there a way to have a separete RPLinfo which applies the coefficient so that we don't have to calculate or send it to know if we improved after a car change?
sure, i'll implement it to the online RPLinfo page asap
Since we have ZSC 2008, there's always a stupid pop-up advertisment about ringtones when opening the site.
for me too. don't know yet how to make it disappear :(
we might change servers soon anyway, so for now just live with it please.
Quote from: Chulk on January 02, 2008, 05:27:45 PM
Zak, is there a way to have a separete RPLinfo which applies the coefficient so that we don't have to calculate or send it to know if we improved after a car change?
done, RPLinfo online always shows the corrected time with the active track's coeff values if you tick "show correction"
Thanks, but I won't change car again... hopefully...
Quote from: CTG on January 02, 2008, 07:43:17 PM
Since we have ZSC 2008, there's always a stupid pop-up advertisment about ringtones when opening the site.
I have a pop-up of ad (often about "vuelving") since mid-2007 personnally, even with FF. ::)
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?
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...
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...
Quote from: BonzaiJoe on April 02, 2008, 10:27:22 AM
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.
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.
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
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.
No. The only thing I could filter are "null" replays (when you forget to attach a replay, which results in 0.:27.60)
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?
Quote from: dstien on September 04, 2008, 10:18:37 PM
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. :)
Quote from: zaqrack on September 05, 2008, 12:41:56 PM
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.
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.