Messages

Wait, was there actually an Ikarus card? Was it a racing bus?

Because there are never enough ideas mid-flight! It's all because I re-discovered this old post by Duplode:

Thanks God, I don't have to make that "Vehicle data" section.

I wonder about which data to include. For the purposes I have in mind it would be nice to summarize the key features in a way that wouldn't take half a screen per car. For instance, one unoriginal idea would be a NFS-style bar chart with acceleration, handling and so on, plus a few icons for things like PG...

The first thought was of course "that would be cool!", because in my mind I was looking at actual printed cards, like collectable ones, with the Stunts cars!

Now, actually printing them might be going too far, but let's say we had the space of a playing card, back and front, how would you showcase a car? What would the bars on the chart be? Let's say there's space for five. Maximum speed? Performance on different terrains? Magic-carpet-ness? Which icons do we need? Anti-, flexible-, powergear?

How do you see these cards? how about your Paint skills?

I experimented with extending ZakStunts to be an OAuth provider, and it should not be too difficult. A competition on a different website could add a "Login through ZakStunts" button and a process equivalent to this, and they would receive the pipsqueak's name, three-letter code, and a token. That would give all ZakStunts pipsqueaks immediate access to R4K, no excuses!

It would be a bit insecure, because stunts.hu does not have a HTTPS, but the thread model is quite relaxed around here

The code above is connected to this tutorial, which is nice and readable I think.

Also, so far, we have a vague definition of "track name". The "file name" is indeed well-defined, but for example, if a track is used twice in ZakStunts, then it'll have two different file names. Also, in another tournament, it may have yet another file name and still, it's the same track. This has put me to think that the "fantasy name" is perhaps more unique and more deserving of recognition, so I prefer to call it "track title" most of the time. But the track name could be some other thing too. Whatever, as long as it's agreed on and is unique.

Good point, I'm having some trouble in ZakStunts because a track and a race are the same thing, and there are multiple races on the same track, which is still saved twice (e.g., Oligoway). Maybe the 8-char name should just be the "download name". It's a bit disappointing that Stunts does not include a title in the format

Thanks Duplode, the code is a good starting point. I'll compile a CSV this week.

I'm trying to rewrite the track preview, so that it can load different track skins from a single image, like the one used in Bliss. It would render images faster, and it would be easier to customise

A rational reply to your slightly bitter "P.S.". Yes, you're right, but that supposed person creating that supposed tool wouldn't be doing what I did. They would be "modifying" a previous value. Bliss doesn't do that. It just uses a value for new tracks that's not the same as that of tracks created with the internal editor. In short, I do understand what you hate about this byte being changed. I am just not doing it.

Yes, when I realized that with Bliss you are creating new tracks, that makes more sense. Which is way you could leave 153 as a marker. As you said, though, when a tool reads an existing track it should not change the last byte if they save it again.

I'll double check to make sure that ZakStunts follows that rule, and leave all the tracks and replays as they are, because they match the tracks that all the pipsqueaks have on their computers. And I'll go and download the most recent Bliss

And sorry again for the grumpy text above :|

As grumpy as my previous message could be, you should notice that I did not blame you, I described the problems I encountered. Note that the last byte of ZCT208 is actually 3, not 153, so I'm not sure what happened there.

I am not going to redefine the hash of a track as the hash on the first 1801 bytes, because that's not what the hash of a file is, and doing so would confuse anyone trying to compare tracks and unaware of the special definition.

What I'm going to do remove the lenient check and just zero the last byte of every track uploaded on ZakStunts. I'll probably have to do the same for replays as well. Which means that instead of calling sha1_file on the file and be done, I have to load the replay, check the Stunts version, zero the correct byte, calculate the hash on the data.

I would ask you to update Bliss to set the last byte to zero, all the time. If you want to append metadata, you can still do it: have the word at the 1803rd position be a magic number that you can use to recognise the record, followed by the same data as before.

Scratch that, I'll do the opposite and take the concept of reserved byte as strictly as possible. Software does not need to know what it is for, it just needs to persist the value, as Stunts does.

Make sure that Bliss writes one specific value there when you create a new track, if you must, and we're good. However, double check the code: ZCT208 ends with 3, while ZCT200 and ZCT201 end with 2. All the other tracks in ZakStunts end with 150, 151, or 152, which means people need to update to the latest version.


P.S. —In the end I would still feel more comfortable if that value were zero. Setting a non-zero value creates a precedent, and someone might write a program that changes that number to something else. For example, an automatic track downloader that stamps its tracks with 99, because hey, there's a spare byte, and there's no standard. And then we would have different versions of the same track, for no good reason.

P.P.S —apologies, there seems to be some extra bitterness above, but it's been a long day; thanks for not raising the stakes and keeping the conversation on thinking about solutions!

[2]

Ah, the headache. As we knew, Stunts does not store Bliss metadata in the replay, but it turns out it does store the value of the reserved byte. I made the mistake to be "open" with the code, and simply ignore that byte in the tracks, and only reject tracks above the standard size.

Now, I've spend the last three hours trying to clean up the mess: I have tracks ending in 150, 151, 152, and... 2 and 3, which should be allowed values. But they all come from Bliss: I made ZCT208 Invaders with the editor, told it to save without metadata, and it's the one ending with 3.

That would be easy to clear: zero the last byte, update the file hashes... but! For the same track, I have replays containing the same track data, but with a different reserved bytes. So I also have to scrub all the stored replays, zeroing the last byte of the track, etc etc.  That's going to be at least another hour.

All this brings me back to non-standard standards, the in-track metadata, and the discussion in this thread

It's a Bad Idea™, can we get rid of it?

Does anyone have a table with all the track tiles, with id, dimensions and possibly the name?
I was about to start compiling one, but with all the editors and tools around, there's bound to be one already

Any format is fine!

Hahaha, your pm was far shorter than this!

Anyway, above are a bunch of interesting idea, and connecting competitions would be infinitely cool. I have some reservations on building a PM system, even on ZakStunts, as there are now a thousand ways to communicate and I think I'd better direct my effort in a different direction

However... receiving messages and replays should not be too difficult. There's a bit of work to prevent abuse (possibly signing messages with short lived keys, etc.) but it's definitely doable.

The "passport" bit is a bit more complicated. That's what the industry calls Single Sign-On, and you step into OAuth territory. It's stuff I've used at work, there's library for it, but it requires some effort to set up.

One thing I'd like work on for multiple competitions would be a standard format to archive a race. Put the track, the final replays, details about submissions (just CSV would work), all inside a zip file. We could make a library for that format and use it in ZakStunts or R4K, and we could store races in an easy format. One day, when we build the final archive of all track and all replays (!!!), it could read the archives and import then.

We should add them to the wiki, so they don't go lost!

It's quite disappointing having missed all these small competitions. I've read most of the wiki pages, but if you have more details, please add them!

In the meantime, an area on the website where you could "drop" the replay file could be fast enough

Note that if you drop a file on the "Browse" button of the upload form, it will be selected for you. That's standard in all desktop browsers, as far as I know.

For R4K, you could add the accept attribute to limit the file shown in the selector:

Code Select Expand


<input type="file" name="replay" accept=".rpl" />


To be honest, I have no idea how the newbie league code works, but it seems to cover all the pipsqueaks for which...

Code Select Expand


pipsqueaks.joined + INTERVAL 18 MONTH > season.year . date('-m-04')

The code refers to the 4th day of the current month, whenever the season scores are recalculated.

I suppose that was meant to say "all the pipsqueaks who joined within 18 months from the start of this race", but races don't start on the 4th of the month anymore, so that can be wrong of up to 4 weeks. And if anything changes and we recalculate the scores for an earlier race, the set of newbie pipsqueaks could be disturbed... leading to a messed up scoreboard.

So I'll likely have to fix the date filtering, then fix the whole "recalculate for a previous race/season", then recalculate the past five seasons and hope that scoreboards don't change too much

Last time we raced at 17:00 Buenos Aires / 18:00 Brasilia / 20:00 London / 21:00 Rome and Budapest. Because of coordination delays, it usually takes an hour, or 1.5h if we race two tracks.

Time to get one organised again
For those who are new, read about the "Le Stunts" format that we usually follow.

I was thinking about live races while having breakfast, and this came to my mind. I'll dump it here, not to forget.

Uploading a replay for a race is a multi-step operation, nothing too long, but seconds! are really important at the end of a live race. So what if there was a little program that looks at the Stunts directory, and every time a .RPL file is created or modified, it uploads it to ZakStunts?

The website should have an endpoint to allow automated uploads, and keep only the most recent 15-20 replays to save space. pipsqueaks would have a new page with a list of their uploaded replays, and the option to Publish, Download, or Delete each.

Bonus, a "Team mode" where the list is shared among the members of the team.