Car archive

[Cas]

Uhm... I think we need to take the uniqueness (or lack thereof) of the car ID into consideration not only for the Stunts version. So far, we haven't had great problems with different versions of a car, yet there already is such thing. And I guess, other things could happen that break this uniqueness. While there are tens of thousands of possible car IDs, most of them are unlikely to ever be used (such as "9_#E") while others could spawn independently with ease, for example, if somebody outside the mainstream community begins building cars (think of "BLUE" or "CHEV").

I too feel more inclined towards the last option, but at this pace, with so many cars already, we should be thinking of "plating" our cars, ha, ha.

[Duplode]

And I guess, other things could happen that break this uniqueness.

An example of a corner case: the Competition Car 0.85 used the PMIN ID, as it was meant as a substitute for the original Indy. In the Competition Archive, I dealt with that by changing the ID to CC08, in both the car files and the nine archived replays driven with it. (It's not obvious that such approach would be the best one in all kinds of possible collisions, though.) The Petrol Pete set of cheat cars (the ones that come with the Stunts 1.0 download at Kalpen) are in a similar situation: they were distributed as a set of RES files named like AARCOUN.RES, along with a batch script that would swap them with the files of the original cars.

[Duplode]

I could link instead to a forum section, but also happy to continue in a thread.

After thinking a bit more about it, I feel there's room for both of them: this main thread for general discussion, and a sub-board for wilder tangents and deeper dives into one aspect or another. That being so, I have created the sub-board (and a thread to kickstart it  ), while pinning this topic we're in to the Forum & Portal board -- let's see how well it'll work. (BTW, while the sub-board isn't that much out of the way, it might make sense to link to it from your opening post here.)

[Cas]

Not really sure what the best solution would be for the car IDs, but both Simple Garage and Pretty Garage (the one I'm working on now) heavily rely on standard four-character car IDs to identify cars, so once we have a good clear solution, I should see that they follow it... Hopefully, it wouldn't be super hard to implement.

[Daniel3D]

Not really sure what the best solution would be for the car IDs, but both Simple Garage and Pretty Garage (the one I'm working on now) heavily rely on standard four-character car IDs to identify cars, so once we have a good clear solution, I should see that they follow it... Hopefully, it wouldn't be super hard to implement.

I think we should treat the ID as a number plate.

we should be thinking of "plating" our cars, ha, ha.

That would also mean I think that we have to make an Registry for new plate ID's.
Were you can reserve an ID for your project for a set time (one year, renewable?) So if a creator disappears before it gets done the ID comes available again.

If an outside the community creation is found we have to determine case by case what to do about the ID if it's already in use.

[Duplode]

Not really sure what the best solution would be for the car IDs, but both Simple Garage and Pretty Garage (the one I'm working on now) heavily rely on standard four-character car IDs to identify cars

I think we should treat the ID as a number plate.

My two cents:

• IDs are, and should continue to be, the primary way of identifying a car. They are what the game understands, what pipsqueaks are used to, and what most tools work with.
• While IDs as number plates is a good mental model, and a good way to explain how they should be handled, I don't think that should go as far as we operating a registry, with applications and expiry dates -- too much red tape for dealing with too low an expected number of collisions.
• When ID collisions do happen, we might end up having to decide what to do on a case-by-case basis, though sketching some kind of procedure in advance might help. One possibility (this is not really a proposal, just floating ideas): once we learn about a car with the same ID of an already known one, add it to the archive with a changed ID (maybe modifying it according to predefined rules), and record the ID originally chosen by the author in an optional original-id field. (The archive interface might even have an user-facing option "Use original IDs, even if clashing", which would rename the files being downloaded.)
• Given the archive can help us with documenting versions and telling them apart, we might want it to offer complementary means of identification that go beyond IDs and consider the content of the files. Tool developers, generally speaking, wouldn't be expected to incorporate that into their programs (IDs would still be the baseline), but the information would be available if anyone wants to use it.

[Daniel3D]

The archive interface might even have an user-facing option "Use original IDs, even if clashing", which would rename the files being downloaded.

The archive should at least give warning ⚠️.
If we accept doubling of ID's the Car managers have to be able to distinguish between them.
That would also solve the game version issue because adding that check is quite trivial considering. 
So adding a field to the car information could be wise, like.. | ID Double= (empty =Unknown) or Yes.
Downloading such car With a fake ID may be sensible, but shouldn't be mandatory. A car manager could do it as well, so the alternative ID and original should be stored as well.

[dreadnaut]

Let's stick to identifiers as primary, unique key. We can handle duplicates when (if) they arise.

Beyond the methods discussed above, we can also rename the car, but add a alternative-ids property to list any aliased ones.

[Daniel3D]

Let's stick to identifiers as primary, unique key. We can handle duplicates when (if) they arise.

Beyond the methods discussed above, we can also rename the car, but add a alternative-ids property to list any aliased ones.

Yeah, that is (in the chaos of ideas in my head and the mess I've written down) the main thing.

[Cas]

We'll, I agree it's unlikely to come across collision. For the frequency of those events, we can perfectly handle them one by one. What we could do to make those cases less frequent is agree to try to avoid predictable car IDs for new cars.

For software development, it really is very comfortable to just rely on car IDs!  I can tell you that from my experience with the two garage programs. I've used that for R4K too, but the handling there is simpler.

A simple look-up table of known car IDs against their car names would be good too so when somebody wants to come up with a new ID, they can take a look there first. Not that it's a requirement, but I think it'd help.

[dreadnaut]

Well then, I've put online a first version, and added three cars:

- https://stunts.hu/cars/CDOR
- https://stunts.hu/cars/ZGT3
- https://stunts.hu/cars/ZF40

I've converted the yaml files to INI to make them easier to consume by low-tech tools. I've dropped the descriptions: multiline and INI files don't get along, and it makes sense to keep the archive dry — the wiki can have a longer description.

[Cas]

That's really good!  It prevents unnecessary dependencies on third party libraries and reduces the chance of bugs on independently developed software.

[Daniel3D]

Well then, I've put online a first version, and added three cars:

- https://stunts.hu/cars/CDOR
- https://stunts.hu/cars/ZGT3
- https://stunts.hu/cars/ZF40

I've converted the yaml files to INI to make them easier to consume by low-tech tools. I've dropped the descriptions: multiline and INI files don't get along, and it makes sense to keep the archive dry — the wiki can have a longer description.

A description is also in the car file, so it can be provided if needed. At least, I assume that that can be coded into a website.