@Piboso:
why do we now have, in the bike's .cfg file:
- A (new) tyres section, referencing a new .cfg file (e.g. m_gp1000_03.cfg for the 990)
- A wheel0 and a wheel1 section containing tyre0, tyre1 etc sections, each referencing a tyre via its ID (and adding to it a name and a numsets value)
And in the m_gp1000_03.cfg file:
- A wheel0 and a wheel1 section containing tyre0, tyre1 etc with an ID and a params file (.tyre)
It seems over-complicated, I really don't see the need for the m_gp1000_03.cfg file: the tyre0, tyre1 sections in the bike's .cfg file could simply reference a .tyre file, no ?
It is complicated, but needed because it was decided to add shared tyres to MX Bikes.
Yeah I've seen that (the need of tyre sharing across bikes) and it's something good in fact.
But I still can't see why it's needed to have the tyre0/1 etc in the wheel0/1 section of the bike's .cfg: if the bike's .cfg has a tyres section referencing a "master" tyres file (itself referencing multiple tyre files per wheel) then there should be no need for tyre0/1 etc in the wheel0/1 of the bike's .cfg. Or, the other way around: no tyres section (no "master" tyres file) and just reference .tyre files (which can be shared) from the wheel0/1 section of the bike's .cfg.
With the current organization, the ID of a tyre is present at 3 different places (bike's .cfg, master tyre file and .tyre file): I think there's something redundant here.