Messages

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! 

Oh, what a scoreboard...

What's more, Brazil also played yesterday vs. Portugal (in Gama, a city neighbour to Brasilia), and guess what, we played a great game, with flair and effectiveness: 6-2! That would be unbelieavble under any circumstances a few days ago...

(...) but this debut was a lot different than matches Basile played against similar teams, where Argentina suffered a lot (Algeria, Norway)

With Brazil it does not seem to be too different from those issues: if the opposing team plays a deadlock, the creation/attack fails completely, even if it is Bolivia at home or something like that...

Well, I can't really assess technicaly if it would be good enough... but the only reasonable one I've seen is http://tools.rosinstrument.com/cgi-proxy.htm , which has a big list of randomly-chosen proxies (even if far smaller than proxy.org).

I should check my Linux Java JRE/JDK Setup...  Anyway, rebuilt the .jar with Java 5.0 compliance. I tested it on my Windows, so this time there should be no problems... (new .zip attached on the original post)

OK, stupid problem with file paths solved, here you have the first functional alpha version. General instructions:

• Naturally, you need to have the Java Runtime Environment installed to run it. To run the program, unzip the package to some folder, reach the folder in your system's command prompt and type java -jar ReplayHandler.jar. It is possible that in Windows you can launch the .jar with a double-click, but I haven't tried it myself.
• Once in the main menu, you'll find two basic operation modes.
  
  
  
  • The RPLInfo mode will get data from a .RPL file you provide, perform the basic checks and print replay information to the screen. If the .TRK of the replay is available in the same folder of the .RPL, it will perform track checking as well. You will also have the option to test the novel .RPL signature mechanism, which will create a copy of the replay and append the pipsqueak name (assumed to be the file name for the moment) to it. 
  • The Round manager mode will get a folder name and generate a 7 pipsqueak maximum .HIG file based on the .RPLs on the folder and print some basic info to the screen. It also asks for a .TRK file path in case there is no .TRK on the folder, so it can get the proper name for the .HIG, so it is advisable you place the .TRK in the test folder. The program will overwrite any existing .HIG for the track without asking for confirmation.
• You will also see there are Zak'08 variants of the operation mode on the menu. Those will use car bonus data to print corrected times (RPLInfo) or to compare replays (Round manager). For these to work, a carbonus.dat file must be available at the folder where the .RPL files are. A sample file is provided in the .zip, with data from Z86 (Z86 replays are available too, for a quick sanity check).
• If you're launching the program from the command line, you can pass a file or directory path as command line argument. Note that the different modes will use the path as is, so if you pass a file to Round Manager or a folder to RPLInfo mode it won't work...

That's it - test, report, enjoy 

Edit: replaced the (original) bugged build for one that should work.

Did we ever make experiments, on how writing some extra bytes to a replay modifies it?
If it wouldn't interfere with the replay itself, we could use this tool's next generation to write competition, track, pipsqueak name into the file, even along with some short comments or other identification. This could be then the new generation RPL, and online competitions would require replays edited (or rather only parsed) through this tool.

I performed two tests with extending default formats yesterday:

• Writing more than seven entries to a .HIG, hoping that they would be stored normally, even if not displayed in game. It seems one can put up to 12 entries in a .HIG. More than that, however, will make the .HIG overflow into the track file within the game RAM, causing gibberish tiles to be added to the bottom of the track and the .HIG not getting loaded properly. That means we have to be very cautious with unforeseen consequences of appending stuff to the default formats... and since most likely the game will rewrite the scoreboard as soon as you get a new replay and reset it to 7 entries, the best way to store the full results would be generating a new file for each set of 7 pipsqueaks (the main one being, say, ZCT86.HIG and the others ZCT86.HI2, ZCT86.HI3, etc.)
• Appending a zero-terminated tagging string "SIGNATURE" to the end of an .RPL followed by the zero-terminated pipsqueak name, so that Zak's suggestion could be implemented. It seems that, unlike in the .HIG case, there are no visible problems generated by the file overflowing its reserved memory area, so it may well be a viable strategy. Of course, adding such signatures would break all existing replay time identification algorithms based on file length, but that's a workable obstacle I guess (and naturally in case we do use signatures the new replay checking tool should be able to handle both signed and non-signed replays).

The bottom line is that the programmer should exercise a lot of caution when extending default file formats. But it works...

As for a full-fledged competition management system, there are two main requests that need to be fulfilled:

• Creating a round management system that is pipsqueak-based, as opposed to replay-based as my simple test version is. The coding itself should not be too much of a problem (make a Pipsqueak class which stores a Replay object and make the Pipsqueak able to update his Replay accordingly); the main issue is finding a convenient mechanism for automatically (i.e. without the manager having to enter the names manually) finding to whom does a replay belong. File-name based, directory-path based, RPL-signature based... I don't know, and accept suggestions on what would be more user-friendly.
• Implementing Rounds of different kinds for different competitions, so that stuff such as replay name parsing schemes and replay sorting methods can be tuned at will. I implemented it in a small scale into my test app and it works fine.

The first functional alpha version of the application is ready, and I would have posted it already weren't for a stupid little thing I couldn't figure out yet (how to make the program read an auxiliary .txt file included within the .jar package I will post...). As soon as I solve it you'll be able to test the program.

Well, I know virtually nothing about HTML edition and do not try such software since maybe five years ago, but you might want to check a portable WYSIWYG editor available at PortableApps (an useful site to bookmark, BTW): http://portableapps.com/apps/development/nvu_portable