Messages

[Now to the question I've had for a long time]

Which questions do we have about Stunts tracks and replay?

Yes, this is a very good way of seeing it. Inside a tournament, there are of course, internal questions that don't require anything universal. But if it is about the general user, what would he be looking for?  I think there are two kinds of questions. One is of the sort "I have this track or replay and I want to know more about it". In that case, the user would give a whole file, the registry or any other system would use its own hash methods, that wouldn't need to match the methods of other systems, and bring up all the info it can about the track or replay that's relevant to the system. The other type would be "I'm looking for a track or replay that has these characteristics". There could be many answers. Now, for none of these it's necessary to agree on a numbering system, it seems. It would, however, be necessary to internally identify the item uniquely with a non-changing ID so that, for example, one can grab a link from a site and put it in another and that will direct people to the page regarding that item. Things like that.

But what question does this answer? Can it map tracks on a space which gives us useful insights, or is it merely a numeric exercise, and looking at the maps would be faster?

Well, this is a thing separate from the numbering idea. What I envisioned does not necessarily have to be calculated the way I described, but the question it should answer is whether a track or a replay was (probably) created from another, if it's a version of another. The utility in this would be to associate items when coincidence is not perfect. Say somebody drove a replay on a well known track, but first made a couple of touches. Some time later, another person is looking up the replay but can't find it because it turns out the track is not the same. Things like that. For example, my track "Abusái" was slightly modified before entering ZakStunts, which is OK. But I do have the original version. Again, this is an idea and a reason why it could be useful. I'm not saying that it's a requirement in anyway for things to work. But consider also replays that are identical up to a certain byte, meaning they were creating by "continue driving" from a point. I figure it'd be useful to tell that's the case (which brings me to a question I've had for a long time and I'll ask it at the end of this post, ha, ha).

I've recently been working on splitting the concepts for "track" and "race", at least in the back-end.

I believe this is a very good approach. It does make a lot more sense that way. Of course "season x, race y" also solves the problem, but the ZCT system is more orderly in my opinion, especially since races in ZakStunts are not aligned with a day of the month, but weekly, so it's not always easy to say "October's race".

I can't think of a good way to classify non-competition tracks

If we follow the example of the ZCT system, then I think the natural expansion would be to have a leading thing such as "NTB" (non-tournament-based) or each author could have a leading ID and local numbers. The thing is, as you said before, the ZCT method is better to define races than tracks and the same thing happens with these other possibilities. One track could, for some reason, make sense to have more than one number in the same classification or even be present in several classifications.

Now to the question I've had for a long time

I've always assumed that, in ZakStunts, once you've posted a replay, it's not correct to post another that's based on the one you've already posted. That is, I can do all the RH I want, but once the replay is out, I have to start from scratch for the next one. Yet, I have to admit, I've never read that rule anywhere, so I don't know if my assumption is correct. So... is it?  And does ZakStunts check for this at all?  As I've never done that, I haven't tested it.

[What we have]

What we have
This is about one particular point that could later help for the global registry, but also for many other things. As I had said before in another thread, we don't currently have a way to uniquely identify tracks, let alone replays. For tracks, in ZakStunts, there's the ZCT number, which does a very good job, but it's not perfect, since one track may have more than one ZCT number and of course, tracks from other tournaments or well-known tracks that don't particularly belong to a tournament, don't have to have a ZCT number. Also, fantasy-names, which Bliss usually refers to as "track-titles" are good too, but are long to type and may contain non-ASCII characters and besides, many tracks don't have them, so they are good for looks, but not for general identification.

What could be done
I was thinking of a general track identification number system. There are two approaches at this: one would be to directly assign as many tracks as possible a number directly and maybe even reserve numbers depending on where the track originated or how it's been used. The other is to just start from zero or one and assign numbers as tracks are given them. The first option is more orderly, although the second one has the advantage of leaving no "holes". Furthermore, there's the thing about how to format these track IDs. A decimal number?  An alpha-numeric string?  Maybe a hex number?  Could also be a leading letter and a number. Anybody has thought about something like this before?

Estimations
I reckon we have a few thousands of tracks counthing what each of us has in their hard drives, plus old tracks from old championships, etc. Four decimal digits should be enough, but could be surpassed with some effort. Five or six should definitely be good. But usually, we're interested in about 500 tracks only. Something like #00921 could look good for a general track number, or maybe like 14-0122 where the first two digits would identify the source or origin of the track. I kind of prefer the first.

On replays
We currently have no general ID for replays, I think, other than them being saved in folders with their corresponding race in tournaments. A replay ID number could contain the track ID as part of it, but could also be completely general or be based on date-and-time when it was first registered anywhere (such us uploaded to a championship). In that case, it'd be complicated to work out the numbers for the thousands of replay files we already have.

On track hashes and circuit hashes
As I was taking I walk, I thought, it's great to be able to quickly compare tracks by using hashes based on all of the bytes in the file. Then, when they match, if we want, we may go ahead and compare the whole thing byte-by-byte to make sure it's the same, or not. But, depending on what we're looking for, sometimes it could make more sense to compare not the whole contents, but only what's on the accessible path of the track. A sequential follow-up of the track and it's branches could result in a parallel cricuit-hash that could be used to tell if two tracks are very similar or just versions of the same track. We could even be able to tell a rotation. Of course, the general track hash is still very important. I'm just saying the second one could be a plus.

Finally
Thanks, guys for reading my frequent brainstorming. Most people don't like reading long, but I think it's a good idea to just drop this here in case now or anytime anybody would like to think about it and add or maybe I suddenly light up a new idea one of you may have that may be much better than mine. My grain of sand.

Great work, Overdrijf!  About the real picture of the actual car, only problem would be that some custom cars may have no real counterpart.

Some pictures for you guys to see the cards I was talking about before. I had superhero ones and I had a motorbike set, but not the one in the picture:

Yes, you do well in looking for a more predictable weather. Anyway, winter is our sunny season, so we're likely to have a clean sky that day. I hope we do. So great to find another pal interested in this. I studied Physics and didn't finish, but I'm always into science.

EDIT: Oh!  One important thing, Ursin: If you're going to watch the eclipse from Mendoza, make all the research very well in advance to make sure it will be possible. The thing is Mendoza is located near the Andes mountains, to the East and the eclipse will occur in the afternoon, when the Sun is approaching the horizon, also, in the winter, so closer to the horizon than in the summer. The Andes will be just there, and they are the second highest mountain range in the world.

Bliss has a file xlation.dat, if I remember correctly, that contains the look up tables for all track elements. It also includes information on what each item actually is, such as its dimensions, where it's entered from and where to goes to. If you need more info on that and it would be useful so you can convert that file to whichever format you want to extract any useful information from it instead of having to recreate it by hand, let me know. It took me some time to build that file, ha, ha.

Also, feel free use the graphics. There's also the 7x7 version of the graphics that Bliss used before (Castunts version 2.1). I think it's here somewhere. Otherwise, I can send it to you. But there's a catch. The new version (22x22 tiles) is transparent with an alpha channel. The old version (7x7 tiles) I think was opaque and it includes the grid, so it would require some editing. The graphics are not made one set after the other. I completely recreated them. The old one is inspired in the original Stunts editor graphics and because they were introduced gradually, they are able to fit alongside the originals. If you instead scale down the 22x22 tiles, they probably will not fit with the original graphics.

This year I'm travelling to Argentina for six days (30 June-05 July).

Hey, just in case, I'm in Córdoba. If you pass near here, let me know. Also, notice that within that date range (2 July), there will be a total solar eclipse here (actually, a little south from my city; I'm going to go and watch it), in case you're interested in that kind of stuff.

It could be high-res from stressed on a high-res background drawn to resemble the track and maybe a gas station behind or something. I like it in presentation pose, like you described

Oh!  I remember when I was at primary school, some card sets were popular called "Súper Triunfo". This brand included card sets such as "planes", "helicopters", "motorbikes" and "cars". Other brands would make similar cards with super-hero themes and the sort. The way you would play is that the cards were shuffled and each player would get the same amount. You would look at the front card in your deck and pick one of the the attributes, say "max speed", because you thought that particular vehicle was specially good at that. Then you'd call "Speed: 200". The other kids would check the speed attribute in their cards and the one who had the greatest one would take all cards, put them at the end of his deck and continue with his own front card until only one player with cards remained

I'd go for top speed, acceleration (or time from zero to top speed on a straight paved road), number of gears, length (of the car), grip (which unit, not sure) and breaks (also not sure which unit). This, if it were for cards like the ones I described. Now, if it's just to have the most important information, booleans and discrete attributes such as power-gear, creator (or original), etc., would be more significant than some of the ones I listed before.

In the wiki, I tried to create pages for some cars and I realised I didn't know how to add or remove attributes from templates or to make some cars have some attributes that other do not. If I understood templates better, I'd be glad to help in creating such pages.

Don't worry, mate. It's something we have in common.

We could start up by creating a very, very rudimentary and basic version of the track registry and assign each track a unique ID number, for example. The track title is a good thing, but we have to accept that many tracks never actually had one at all.

I liked that you've implemented UTF-8 in ZakStunts. I think by default any text properties for a track, or race, or replay, should be UTF-8. Metadata in Bliss is currently ASCII. It's not possible to enter extended characters. So it's compatible with UTF-8. I'll eventually update it to it.

I'm reading about OAuth. It looks complex. Uhm... yeah, maybe the risk isn't much in our case, but I don't know, the sites are working well now. Still, it's something to keep in mind when we want to unify something else. Like, the PM idea I had mentioned took me to consider logging in with ZakStunts, but you're right that the PM system is probably not really necessary. Then maybe the logging system should be implemented when there is another thing to make it worth all the work. I don't know. I'll keep it roaming in my head, though.

Sorry, mate. I read this thread and I was about to leave home at that time, so I replied with all the heat in my head. When I cooled down, I wasn't home to change anything. I'm a little susceptible to bitterness.

I had noticed before about some files being saved with last byte 2 or 3. First time, I thought somebody had changed this value for some reason. Even Bliss wouldn't recognise it. Then I found a bug in Bliss and fixed it. I think most pipsqueaks currently have a version new enough so that that doesn't happen anymore. It's bug. I never meant for those values to be output.

Alright, next version, I will switch this byte to zero, but... I will make Bliss not change the last byte on preexisting track files. Otherwise, I'd be making matters worse. In th meantime, with the current version, as I said, all new tracks should only have the value 153, so that shouldn't be a problem.

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.

And about the hash. I guess you're using a function to which you pass a whole file and it returns hash. In that case, it could be complicated to go around the last byte. I was imagining something more like I did in Bliss (I wrote my own hash function and tested it to have balanced sensitivity). Well, I guess number 1 priority is to make sure the value is fixed. That, we already have with the current version of Bliss. Even though I, personally, see no problem in this value having a value other than zero as long as it is fixed, I will change it to zero as I described, on future versions.

[149]

I can shine a little light on the issue....

First, for history, on how these extra bytes ended that way. A long time ago, in the first version of the editor which nobody ever had here, I wanted a way that a track made with it could be recognised. I saw that any trailing bytes were lost when the track was edited with the internal editor, but not the 1802nd byte, so I decided I'd set that byte to 149. You won't see any track file ending in this number because this editor was never used by the community. When I made the second version of the editor, that became public, I changed that to 150, to make a difference. So far, so good. This one shouldn't be an issue, but later on, I made a mistake.

At some point, we realised there was a conflict between trailing data in the track file and ZakStunts, besides other programs that would fail to run properly unless the file was exactly 1802 bytes long. Because of this, I created a second format, "split", so that one could save in either format depending on convenience. And here I made a terrible mistake. I thought it was important for each format to have a different final byte. Not only that, but also, I thought 150 should be left behind as an old format. So format byte 151 would come to overlayed files, whereas format byte 152 would go for split files. Some time later, I realised this was a mistake, because now one same track could be saved with different format bytes, so the 1802 bytes were not guaranteed to be the same. What I did was fix this to a single byte value, but, this was to be yet a new one, 153. Right now, Bliss only produces files ending in 153.

How to solve this
For tracks that have extra bytes 0, 150 or 153, there is actually no problem, even though we'd all like all those numbers to be the same. There is no problem because the extra byte is passed to replays and there exist only one of these values for the same track. The internal editor and Track Blaster both keep the extra byte value. But, bytes 151 and 152 are a problem. My opinion is that we can't just change them all to zero and it'll be fine, because if we later encounter a replay made with the other version, we'd have a new problem. From my point of view, the very simplest way of solving this is the following:

1 - Upon encountering track files ending in 0, 150 or 153, leave them as they are. Changing the byte would create a new version of the same file, with another trailing byte. I admit it'd be better if they were all the same, but if we change them now, we'd make it worse.
2 - When a track file comes up with bytes 151 or 152, no matter what we do, we'll still have a problem. Fortunately, they are not many. So if you like this number to be 0, change it. You're not making things any worse. Yet, this is not enough to solve the problem. Number 3 is the fundamental 1:
3 - When comparing tracks or a track and a replay, compare only the first 1801 bytes, not the whole 1802 typical track length. This single action solves the whole issue and it makes the greatest sense. In a way, the whole problem is never a problem as long as we understand tracks being made of 1801 bytes. Byte 1802 never has had any impact on what the track is. Stunts ignores this byte. So why go crazy about it?  I don't mean to argue. Just think about it for a moment. No solution is simpler than that. Of course, hashes should also be made about the 1801 first bytes.
4 - As for me, Bliss currently creates tracks only with final byte 153. This should not cause any problem, but if you wish, I can make the next version use byte 0 instead. Tracks opened with Bliss and then saved again currently keep the same byte. I don't remember how obsolete values 151 and 152 are saved after edition on the new editor, but I can make sure all track files in the new version are saved with last byte 0 if they have a last byte 151 or 152, and new ones always. This should help for the future. I offer an apology about this mistake, but I request to not be blamed on more than I actually did.

You already know my philosophical view of the matter: there is no "standard" here; there never was. Only changes that cause effects and changes that don't. Track Blaster introduced a great deal of changes that weren't previously allowed and nobody came screaming about standards violations. Quite the contrary, people were happy to embrace "illusion tracks" and road on water, even though they did conflict with the internal editor when one would accidentally open the file with it. What I've done is just changing a single byte that does nothing. While I did make the mistake I described above, I've created no mess. If you just blame me, we'll just keep on exchanging messages like this and it will be useless.

So... do we proceed like that?  Any other ideas?  What can I do to help?

It's true there are too many forms of communication. That's what stopped me from creating a PM system in R4K. The simple chat, I though necessary, though, so somebody could say if they had a problem with a RPL or something and would be easily seen, for example. But for general chat or PM, it'd be best for all to be just one thing. Yet, from what you say, it looks complicated to share a pool of messages.... unless.... we don't actually share it. I mean, what if posting at one place would post to all?  Anyway!

About race format, yes, that would be good. For the time being, R4K is saving each race as a directory containing the replays and a scoreboard file that's like an INI file. The track file is also copied there. I could zip all that. I haven't done it yet because that would make people unable to download replays individually, but for archiving purposes, I guess the ZIP file could be sent somewhere else or created when necessary.

For the track registry, maybe we could similarily plan some formats. Of course, if the information is the same, the format doesn't matter as long as it can be shared. But it'd be nice to be able to look up a track and see in which tournaments and which races it was played. Maybe tracks and replays could hold "dynamic tags", meaning that a pipsqueak can come and say "Oh, this track is fast" and then add the tag "fast" to it or maybe "very hard" or "loops" if it has many loops. Similarly, a replay could bear tags such as "inverted crash" or "powergear". These tags would aid in finding a replay we're looking for. I say "dynamic" because we don't have to set all tags when the track or replay is first submitted, but at any point in the future.

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.

Well, I think I'm just moving to another topic   I'm just thinking aloud.

Ah!  Good-old times!

I sent a PM to Dreadnaut about a set of related half-ideas I've had. He replied suggesting that I create a topic so that everybody can contribute and I think that's a good idea. Only problem is I can't find the "sent" PMs, so I'll just have to try to remember and rewrite the concept. Here it goes:

It all started when I was trying to enhance the messaging system in Race For Kicks website. I though it'd be cool if I created a PM system there. What stopped me was the thought that we already have way too many ways of communicating. We have the very basic chat system at R4K, but we also have the Shoutbox at ZakStunts. And we have the forum, which can handle PMs too. And we tend to only check one of them most of the time and the others seldom and it's not always the same we check the most. This makes some of us get messages late. Besides, each system has its advantages and disadvantages. So.... the following things came to my mind:

1 - I was wondering if there could be a way in which the R4K site could use ZakStunts username/password as a "passport" system or if we could create a whole new system that both sites could share, so that pipsqueaks don't have to log in to each. This would simplify matters. I'm sure this is possible because I have access to R4K code and Zak and Dreadnaut have access to ZakStunts code, but I don't know how easy or hard it would be.
2 - If [1] is possible, then we might be able to make the Shoutbox and R4K chat system one thing, so we could all check the chat at any of the sites and/or we could create a PM system for both ZakStunts and R4K and share that (even if the general chat/shoutbox is not shared).
3 - Now, if we make PM system for R4K or ZakStunts or both, then the forum's PM system would be redundant. I wonder (and this time I don't know how possible this is) if we could somehow also make the forum work in conjunction with the sites, that is, read from the same PM pool and possibly use a "passport" system compatible with the sites. About the PM system, if this is too hard, it's easy for us to create a very good PM system for ZakStunts and R4K that will be much more powerful than the one in the forum, so we would just use the forum as a forum and PM on the sites.
4 - If this level of unification can be achieved, it can be used for other purposes too. For example, Dreadnaut mentioned an idea of a non-web-based program that would automatically submit replays as they are created for faster interaction in live races. This same client could be much more than that, and allow a whole non-web system to access the community sites and tournaments. A program like this could allow plugins and modules so it'd be much easier to add things to it than it is to add them to the sites (I think). Of course, this could be a risk for the security of the sites if not done properly. It's just an ambitious idea so far.
5 - Bliss has some minimal integration with ZakStunts currently. I could enhance that. Currently, I don't have Wine on my computer, so I would have to reinstall it, which I'm having a few problems with, but I can solve that, in order to compile Bliss or a client program for Windows. I am ready to compile for GNU/Linux, however.

If you guys have any good idea even if vaguely related to any of these points, please add to the brainstorming!    And if you know the answers to my questions and doubts, of course, I would like to know. Also, whatever I can do, count on me. I have much more experience with non-web programming, but online, I can reasonably handle PHP, although I've never used databases. As some of you already know, I've been a lone wolf all these years, so my programming style is very particular and I have hermit views   I don't get along well with OOP and I prefer to write my own code to using libraries whenever possible. But I'm open minded and can settle to middle-ground, ha, ha.