Messages

The race will end in (from now) 2 days, 20 hours and 33 minutes - Friday-to-Saturday midnight in Hungarian time.

Hello again! Igor was only able to watch the replays on Sunday, and I've only seen his post at Orkut today... Anyway, here are the results of yet another tight race with yet another Mark victory:

1º Mark L. Rivers - 2:10.85 - +10
2º Felipe NEMESIS - 2:11.30 - +8
3º Daniel DUPLODE - 2:11.90 - +6
4º Rudah FLASH DRIVER - 2:16.65 - +5*
5º Krys TOFF - 2:22.15 - +4

Classificação Parcial:
1º Mark L. Rivers - 40
2º Felipe NEMESIS - 32
3º Daniel DUPLODE - 26
4º Rudah FLASH DRIVER - 14
5º Krys TOFF - 13
6º Marcelo THYASROCK - 8

Due to the long delay, Igor (thankfully) opted to move all deadlines a week forward, so you have almost two weeks to have a shot at Round 5 - the Indy one! See you 

There was a very smashable sign on the section of banked road before the final corner in Z89. From the replays I've seen, Ayrton and Zak missed it by millimeters, while most others avoided it by a slightly different trajectory.

[- Melange by Alan]

wonderful work from both of you, after a half hour of testing I can already conclude that the Speegate and the Skyline both made it to ZakStunts 2009.

- not only due to the Skyline but also because I will really love to make use of the Speedgate next season! Thanks!

- Melange by Alan -> the .res is OK. Uniquely distinguishable  bodywork and proper dashboard (and rev. needle) are needed.

It would be interesting to know whether Alan has some concept about what an unique 3D shape for his creation should look like... 

- No other car, and we'll start with 14 cars. 

You meant 13 (11+2) cars, right? In that case, there would be (theoretically) another free slot?

Edit: Just one minor thing, Zak: I just noticed I forgot to change the line termination on the Skyline readme from Unix to DOS, a minor annoyance to Windows users. I rectified the zip on my previous post, so before you make the Skyline zip available elsewhere can you please re-download it?

Well, sorry I was really busy and see this only now.
Deadline is 19H GMT+1 since western Europe changed from GMT+2 to GMT+1. I changed the website at this moment one month ago. Anyway, deadline is 19H, server time. Server is in France, so the time displayed when you post your time indicates the server time properly compared to the deadline.

The website is programmed to block any new time posted after the deadline, so if you could send your time it means deadline was not over. so your current time is valid and you're 2nd.

As seen on your screen capture : "current time is 18H13". I take the server time to be displayed there, so no issue possible. Maybe I should change "GMT+1" (or "GMT+2") to "server's time" and display the current server date and time on the active race page to avoid any issue/question.

OK, all clear now, thanks... BTW Krys, are you technically obliged to use the server's time for running the clocks? If not, I'd suggest adopting a North African reference time (Algiers for GMT+1, or Tripoli for GMT+2) for next season, as those are not affected by summer time. Displaying the current time on the active race page would largely solve it too, in case fixing the time offset is not possible.

Oh, and congrats Mark, Duplode, Chulk and Zak. Very good times.

Well, as you said on the news page I was really lucky, not only by having noticed the deadline thing, but also due to improving my time just past Chulk's at the very first try after posting that question. Moreover, I only beat Zak's time at 17:58 (two minutes from what I thought the deadline was...), and if I hadn't done so I wouldn't have looked at the submission page again, and would thus end up in fourth...

[Nissan Skyline R32 GT-R]

Well, I had to finish it eventually - so here you have the Nissan Skyline R32 GT-R in all of its might. Performance wise, I'd say (quoting the read-me) the final product is a Stunts car occupying a niche close to Acura NSX and Corvette ZR1 - as the real car probably would - but without powergear. Additionally, some measures were taken to make the handling more enjoyable than that of its direct competitors without making it needlessly easy. As for looks, well, I could provide screenshots, but I prefer you to get your first impressions directly...

I already installed it, and the result is gorgeous - it really looks as fast as it is now! I'd only suggest you to include the .RES on the zip, even if it was left unchanged, in case some newbie decides to get the car form this thread.

not yet. but of course if you're late a little and tell it before, it is no problem at all...

Maybe I won't be able to finish it in 45 minutes indeed... in that case, I'll submit it in the following few hours, even if slightly late (must be within this night or else I won't be able to work on it again until about Thursday). Thanks for the patience...

Pffff, pfffffffff, pffffffffffffffffffffff... Dead race.

Hopefully everyone will be back to normal status and we'll see more action in Z90. And hopefully I won't have to regret again insufficent optimization on the first sector. Damn, what an opportunity...

No. I made those models just for fun, independently from the car designing contest. On the other hand polygons are in mess in all my OBJ files (looking ugly in Stunts), so I lost enthusiasm and did not correct them with the new experiences of you and Duplode written in the correspondent topic. I can make those imperfect OBJ files available and then feel free to improve them - I won't.

Are they looking disproportional, glitchy or something else? We really should have a look at them, those problems may well be easier to solve than it seems (your models looked pretty good on your screenshots...)

And did you start with the Volkswagen T3 yet? 

Sorry, not yet - and I can't really give secure predictions on it. It would be nice, and quicker, if this could be developed as a collaboration between two or more of us, though... And BTW, regardless of any glitches, using CTG's model as base would hasten things a lot with the 3D part.

---

As for the Skyline, my contest entry: it is essentially finished - I will just review it for any "bugs", test the specs and write a read-me. Hopefully I will be able to send it before midnight... BTW Zak, did any other submissions arrive already?

[1:14:60]

Krys, perhaps due to the heat of the race my mind has gotten suddenly very confused about the deadline time: the submission page says 19:00 GMT+1, meaning that we have 52 extra minutes to try. However, I remember clearly that the deadline was, originally, 19:00 GMT+2 (I even set the Tripoli, Libya timezone in my desktop in order to be able to check for it), thus the race would be already over - was it changed at some point? Anyway, in case the deadline is really 19:00 GMT+2 (and not GMT+1) please cancel any further submissions from me in the remaining 50 minutes and set my final time as 1:14:60, sent at 17:58 GMT+1.

Edit: Oh my, now my question is an actual issue... I hope I'm not taking unfair advantage...

Oh, I thought I'd be able to race either on Friday or Saturday, but neither... I'll need some magic by now...

The only thing I know is that I must hurry and find a few (dozens of?) tenths or else I'll find myself in trouble.  And since I haven't said it since this race started: screw the Countach. 

Here in Brazil, as the saying goes, the "cursed month" should be August... perhaps it changes a bit according to the timezone, as it seems 

It throws an uncaught exception when trying to open a directory as a .RPL file. Sorry.

Thanks for calling my attention to it. That's really not surprising, as I had found that I actually was obliged to do something with the exceptions the night before! The next release will hopefully be a bit cleaner when facing such issues.

---

Currently I am beginning to study how to tackle more seriously the concept of off-line round management. As mentioned before, the limiting task for that from an user/contest manager perspective is how to assign a replay to a pipsqueak as unambiguously as possible. The pipsqueaks themselves would be defined as entities whose information can be stored in some simple database outside the program - that way, managers would only need to make use of addNewRäcer function once in the season, when the new pipsqueak takes part for the first time, and statistic-tracking and season standing computation schemes could eventually be implemented. Within the program, pipsqueaks will be mapped to their most recent replays for all purposes due. The question is by which means should we let the program perform the assignment? I can see a few basic alternatives:

• Filename based, pipsqueak-side: Competition manager will ask pipsqueaks to kindly use a standard file naming scheme when sending their replays sot that they are unambiguously assigned. That is the cleanest solution to implement IMHO, but of course it depends on the clear definition of a standard scheme and on the cooperation of the participating pipsqueaks...
• Filename based, manager-side: The obvious alternative is having the manager to rename the files as they are received. I feel (and Mark probably agrees) that doing so would defeat the purpose of the system, however... unless the contest had some sort of server-side scripting which could do the renaming as soon as the replay got submitted (did anyone say ZakStunts? )
• Directory based, manager-side: The folder storing the round replays would be a collection of subfolders, one named after each pipsqueak, from which the program would get the replays accordingly. A manager without php scripting would have to worry with downloading each replay to its proper folder. That is, however, much better than having to rename the replays, and does not rely on pipsqueak-side cooperation in any way. So that seems to be a good compromise solution.
• RPL signature based: In the lines of the advanced replay format Zak described. This solution has the advantage the extra information fully portable by storing it with the replay, and has great potential for archiving purposes (say, a Competition Archive vol. 3), specially if we can prove one can put a lot of bytes into the file without bizarre side-effects. However, it may be not so good for day-to-day usage by pipsqueaks and managers. Requiring the pipsqueaks to use an external tool to parse the .RPL could easily be an obstacle, and having the manager to do it is no better than renaming the replays. And additionally, there is the additional inconvenient of tampering with the file format: for starters, the parsed replays would not be compatible with other existing RPLInfo implementations...

Of course we could have multiple implementations, but I would really appreciate input from the managers on what seems to be the best approach in order to decide on which I should focus first. In case we should go for a filename based mechanism, the topic of file name standardization will inevitably show up, but that's better left for a future post...

Just checked in the new updates which include alpha handling on import; will give them a try in order to finish whl_ and ins_ details on the Skyline dashboard. Thanks!