michael blunck wrote:George wrote:Idea of flags is better, because it is not limited to houses
Mmh?
The Idea is to allow GRF file to give information for the other GRF file about its' possibilities.
For example, ECS chemical vector requires petrol stations, petrol tankers (wagons), petrol trucks, petrol carrying ships. If any of them is missing, it can provide some basic object to fix it (add a new house, change the default oil truck, oil wagon, oil ship). Only for missing objects, not for all of the. How can it do it? Especially in case of new sets in the future? It can't check GRFIDs, because new ones are unknown.
Here came the idea of flags. Every GRF can (in documentation) specify a list of flags, it is looking for, and if they are defined, not to add the fix. All the other sets can provide the required objects and information for the set (set a flag).
How could it work?
There are two commands for the GRF:
- define a flag (new global string valuable, like cargo labels)
- check the flag defined (like cargo label defined)
For example, ECS chemical vector may require flag PETROLSTATIONS. If it is defined, no new house "petrol station" is created. If not, it creates a new house. TTRS / NACS / Alpine set may define the flag PETROLSTATIONS to prevent ECS chemical vector from creating it's own petrol stations. For ECS chemical vector it does not matter what GRF has provided the flag. All, it needs is the flag being defined. The same way it may require PETROLTRUCK or ANYCARGOTRUCK or ANYLIQUIDCARGOTRUCK flags being defined. These flags (all or any) can be defined by LV or GVS or German RV set, so the ECS chemical vector does not do any attempt to provide a new truck for petrol.
This mechanism is independent from object type (it can be applied for anything - houses, vehicles, industries, landscape ...) and allow collaboration with future sets.