Messages

Going back to this discussion...

I think that scoring members need to be determined before the season starts or at least before the end or the first race.

I dont't agree with this. If an inactive member of a team makes a mid-season comeback, and the team has a free seat, they should be able to rejoin immediately.  I'd also extend that to new recruitments: while there are a few more aspects to consider in that case, all in all I don't feel the rules should get in the way of people joining teams if an opportunity arises.

(It's worth noting, BTW, that both scenarios I mentioned above are allowed by the rules as they are currently written.)

You had also mentioned switches, and I agree they can be more problematic. There are, however, ways to further restrict switches without transfer windows or a blanket ban on mid-season enrollment.

Yeah, i get that.
I was thinking about a scenario where a team changes there scoring drivers based on the track so they can score on races they are good at. That feels like cheating.
But that can also be solved if team changes are done before the track is revealed.

In any case, I'm playing devil's advocate. I don't think this scenario will be a problem.

Is it sensible to keep zip files in the garage and only Copy (extract) to stunts and keep the original safely packed.
It would need to check if all cars in the game folder are also safely in the garage.
Or a three way split in game folder, garage and local archive.
The local archive could be useful for wip cars. When finished it can be presented to the central archive.

YAML and a basic INI file are equivalent in terms of expressive power for what we would do here, so it might be better to implement full INI support than partial YAML 🤔  Less ambiguity in the future.

That sounds very sensible to me.

Yes, the files are slightly different in the FM towns. But this comes from a car model file (STUFOO.3sh) . There is nothing else. Don't know where it is used in the game.
The original and converted version of the file attached below.

I remembered that I need to buy a cleaning robot to test one of these days. 

Hahaha.. Guess you found it.
Please share a screenshot. There is something I want to tell about it..

Uhm... was the purple Lambo in the default replay already present in the DOS version?  I don't remember because I never let the demo play, ha, ha. I used to when I had 1.0, but there I had a different demo

The default replay is new obviously. Older replays are not compatible by design.

[U]

• find the Unidentified FM Towns Object..
  
• You don't have to do anything special to see it.
• patience to wait for it..

Please let me know if you find any error in the car in general or an easter egg in the dashboard.

Talking about Easter eggs 😎

Did anyone find the Easter egg in the NoRH version yet?

I really did take something from the FM-Towns version and put it in there.

I guess nobody has the patience to wait for it.. 😆

If we allow multiple versions with the same id we should keep them well separated. An important issue to keep in mind for car managers.
That would mean (I guess) keeping a garage folder with cars in their own "WXYZ-VERSION" folder.

On the one hand, independent primary sources will continue to exist, and we'll keep an eye on them for new stuff; on the other hand, when it comes to telling people where to find cars we'll point to the Car Archive, a consolidated, tidied up and convenient secondary source.

That is what I meant. And i think cas as well.
There is the main source for cars in the archive. But other sources should not be prohibited. It's up to the user if he wants to use them. Like you can make Android accept apps from other sources than the playstore.
A standard for presenting the cars (API?)
Would allow for new cars to quickly reach the user.

If it needs to match the level of detail the repository has, I don't know.
Maybe pretty garage can automatically generate the ini based on the source (for instance ryoma) or combine it with archive information (in case of and updated version of Mark)

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.

So .. if I understand correctly...
The question is, can we create a communication standard so a frontend program like pretty garage can communicate with a backend car database.

Preferably only one backend, car archive, but mark will probably keep his up as he should.

Mark can flag his cars as bug fixed, since he only fixes graphics related issues.

A frontend could inform the user that a alternative download is available (if not yet updated by the main archive) to name a sensible use case..

Or you can do it the nerdy way. (Like ryoma his spreadsheet).

max_speed_mph = sqrt(2*torque*gear_ratio/drag)

This relation allows to predict the flat track top speed of a car.

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.

Quite interesting.
He has an installer for stunts. Stprog.exe and a track pack.


[dreadnaut] replaced large attachments with links