phpStunts

[dreadnaut]

Let's inaugurate this section then! (and thanks Zak!)

Here's a bunch of code for reading and messing with tracks and replays. I'll slowly add to it, but for the moment you can read tracks and replays, extract tracks from replays, create maps. It's more or less the same code from the other threads, but as a nice PSR-0 package. Also, the other code is php4, while this will require > 5.3.0.

https://bitbucket.org/dreadnaut/phpstunts/

These are but foundations, more exciting stuff to come!

phpStunts is evolving, and has moved here: https://github.com/dreadnaut/phpStunts

[Friker]

Very good code!

https://bitbucket.org/dreadnaut/phpstunts/src/e0c8bad52c78/vendor/phpStunts/replay.php?at=default#cl-125

This is very misleading condition - I would throw it away completely, because you can save a replay imidiately after crossing a finish line with going straight last second (or be crashed or whatever). So you should delete a last sec always. Another option is to delete ending zeros (counting with non-zeros through the replay ) and substract all of them from the final time.

Also you could code a time to time w/ bonus converter in case when someone doesn't want to upload a replay.

Another useful function could be testing a track in a replay file against a selected (racing) track.

[Duplode]

This is very misleading condition - I would throw it away completely, because you can save a replay imidiately after crossing a finish line with going straight last second (or be crashed or whatever). So you should delete a last sec always. Another option is to delete ending zeros (counting with non-zeros through the replay ) and substract all of them from the final time.

Misleading it may be, but it is one of those issues which are hard to work around, like RH in competition racing. That field can be useful, even if $replaySeemsComplete might be a better name. After all, a replay interrupted before the customary final second would get you a stern warning from Zak, so it would make sense for the submission engine to reject them. And deleting final zeros won't do - what if someone crosses the finish line without pressing any button?

[dreadnaut]

Very good code!

Cheers

I completely agree on the "misleading" but after reading old threads and faq and websites that now exist on in the wayback machine, that seems the only heuristic to detect the end of a run.

Since we know that this cannot be fully automated and human verification is necessary —and that Zak will strike down upon the cheaters with great vengeance!— we can assume that pipsqueaks will be gentlepipsqueaks and will only submit complete replays. At that point, checking the last second is enough.

(And I'm only being consistent with the various implementations of RPLInfo, although I fixed a few bugs)

Also you could code a time to time w/ bonus converter in case when someone doesn't want to upload a replay.

That would need access to Zak's database tables, but you just have to multiply replayTime for the right coefficients.

Another useful function could be testing a track in a replay file against a selected (racing) track.

Three lines, I think

$reference = Track::load('zct138.trk');
$replay = Replay::load('cheater.rpl');
$isTrackCorrect = ($reference->getData() == $replay->trackData);
 

[dreadnaut]

Something interesting, finally: a way to list replays looking at times and tracks —instructions at the bottom of the page.

Code is on the repo, next time I'll add uploading to the list

[Duplode]

Something interesting, finally: a way to list replays looking at times and tracks —instructions at the bottom of the page.

Very nice. That reminds me a bit of my early attempt at the RPLInfo problem. While that program is by and large a dead-end (desktop Java, a plain text "database"... ), .HIG file generation would be a handy extra for any replay / competition archive management tool.

[dreadnaut]

I'll go dig through the old discussions, they seem full of interesting stuff!

Random thoughts:

• keeping meta information in a separate db might be blunt, but is safer than storing them extending files in an unsupported way;
  
• the hash of a replay file is a good unique identifier for a database of that kind, removes the issue of filenames changing

edit+attachment: mmmmh...

[Duplode]

keeping meta information in a separate db might be blunt, but is safer than storing them extending files in an unsupported way;

It would not be as blunt if the actual replays were kept in the database as blobs. Pushing it further, only the (compressed?) keystroke data would need to live in the blob column;  human-readable data (car, transmission, etc.) and the track could go to separate columns/tables. (That is roughly what I would do were I going to redo the competition management part of JRPLInfo nowadays  )

Edit: LOL, I actually hadn't seen your edit with the database schema 

[zaqrack]

wow guys, this is great. I am not sure I can follow you anymore. I enjoy coding, but I admit I can't do it properly.

I always planned to extend ZakStunts with two features:
- checking track in replay against replay, just as Friker mentioned and you solved in three lines - just to add one more layer of security.

- properly renaming and saving sent replays on the web server, then making them available with a click of a button - this is currently the last fully manual step of the ZakStunts update process. Almost everything else is a piece of cake for each new track - adjust some variables, add some database entries for the new track coefficients, etc., the replays still just get forwarded in my inbox and I have to sort and rename them manually. Not that it hurts, but it feels so tiresome sometimes

[dreadnaut]

It would not be as blunt if the actual replays were kept in the database as blobs.

I was looking into this tonight, and I think it's a good idea. However, working with blobs is annoying: troubles with wrappers, a lot of custom code :|  (to give you an idea: binary data is handled as strings in php, but save a string to database and you'll bump into encoding issue, so you have to point out that the specific field is binary everytime you work on it, etc. )

I'll go for "files outside" I think, and name + hash (+ useful info) in the database.

[dreadnaut]

New stuff in phpStunts!

The replay list now accepts uploads directly on the page —perfect for team replay-sharing!
Todo: secretly mail a copy of all replays to me

Auto tags for tracks: looks at the tiles used in the track and lists the most important features. For example, the list of tags for Default is

• tropical
• bridge
• banked
• chicane
• loop
• pipe
• crossing
• dual-way
• cork-l/r
• boulevard
• slalom

Todo: detect illusion and road-on-water tracks.

Any ideas for other useful tags, stuff you might want to search for in an archive, for example?

[Duplode]

The tags example link points to localhost. I guess you meant this page

Any ideas for other useful tags, stuff you might want to search for in an archive, for example?

Your list is a good start, specially because I believe most of the interesting tags not on your list would require reimplementing Stunts' pathfinding algorithm - for instance, identifying pitlanes (as in LeStunts), clockwiseness or, for that matter, dual-way tracks discounting scenery roads.

The illusion and road-on-water tags could come in handy for a track-sharing site (in the vein of stuntschallenge.net or even Luke's), as they would make it possible to tell whether it is sensible to open the track in the in-game editor. (A car ghost tag would be necessary too). As for illusion tracks, keep in mind there are two kinds of illusion effects: those reached by filler tile manipulation and those achieved by placing elements in terrain pieces they were not supposed to be. While they are often seen in conjunction (as in Krys' classic illusion tracks), terrain manipulation can be used to reach more subtle effects, such as fitting a large corner tightly around a hill edge (I uploaded a lap in GATE.TRK, an SDR '07 track which has an example of that).

Edit: Oh, and of course: the obvious extension would be implementing replay tags so that we might look for car, colour, game version, etc.

[dreadnaut]

The tags example link points to localhost. I guess you meant this page

Thanks, link fixed above!

I believe most of the interesting tags not on your list would require reimplementing Stunts' pathfinding algorithm - for instance, identifying pitlanes (as in LeStunts), clockwiseness or, for that matter, dual-way tracks discounting scenery roads.

Yes, there's not much you can do just by looking a the track tiles "from above". Also, I can't tell if an element is part of the track or part of the surrounding fake-track. But really, I don't want to implement any pathfinding, it would be a hassle with so many track pieces. These tags would be "suggestions", leaving to the user to add and remove what they see more fit for the actual track.

As for illusion tracks, keep in mind there are two kinds of illusion effects: those reached by filler tile manipulation and those achieved by placing elements in terrain pieces they were not supposed to be.

Good point, hadn't thought about the second type :|

[Duplode]

The lively discussion started here about section time analysis and replay logging was moved to a new thread.

[CTG]

OFF: to be honest, I like to make section time analysis by hand. It's something like watching the F1 qualifications: you don't know if the next section will be better for X than for Y, or not.