# Living World XML Examples This section presents a few examples of how to write a Living World Configuration file - overriding only parts of the data - followed by some descriptions of how the various systems of the living world work "behind the scenes". A complete example is available in the `Samples\LivingWorld_Config` folder of the SDK, explained on [this page](../../../../samples-tutorials/samples/sceneries/livingworld/) of the documentation. For more information about the xml specifications, see [Living World XML Properties](living-world-xml-properties/). ### Minimal Example Here is a minimal example that only defines the list of FuelTruck models to be used in Region B: ``` xml ``` With such a file, only the FuelTrucks list for region B will be overridden. Any other list for region B, and any list for other regions, will stay as read in the base default Asobo `*.xml` file. Note that for region B, the whole list of FuelTrucks is replaced by this list with a single entry, it is not "merged" with the default list. ### Large Example In this larger example, we're defining one of the general settings, as well as the lists of FuelTrucks, Pushbacks, and FreewayTraffic in four different regions: ``` xml ``` In this example, the General setting `AmbientVehiclesQuantityByParking` is overridden. Even though only one parking type is specified here, the whole `AmbientVehiclesQuantityByParking` is overridden, which means that all other parking types will have an implicit `Rate` of 0, instead of their default values. The other GeneralSettings are not mentioned, however, and will thus keep their default value. For regions, each region not mentioned in this `xml` will keep the entirety of its default lists. The region B will only replace its list of FuelTrucks, keeping every other default list. Similarly, regions D and M only replace their Pushbacks lists, and the region T only replace its list of FreewayTraffic vehicles. ### Examples Of EntryWeight When generating objects for the Living World, a random model is chosen from the list using `EntryWeight`s to influence the randomness: ``` xml ``` With such an example, the blue pushback is twice as likely to be chosen as the white one. This means that if an airport has 100 pushbacks, it is likely to have a distribution of approximately 67 blue pushbacks and 33 white, but it can also have something like 61 blue and 39 white, or 72 blue and 28 white, because of the random distribution. The actual value of `EntryWeight` only has a meaning *relative* to other `EntryWeight`. The following example will lead to exactly the same results as the previous one: ``` xml ``` Let's look at another example: ``` xml ``` Here, the Red variant will appear, on average, slightly less than half the time, because it should end up with a frequency of 8/17, while the yellow one will only appear around 3/17 of the time. Finally, note that you can have some entries with a weight of 0, as long as the total accumulated weight is not 0: ``` xml ``` ### Counter-Examples: Errors To Avoid Here is an example of what ***not*** to do. It contains mistakes that are most likely to appear due to inattention, and it's been heavily commented to draw attention to these areas: ``` xml ```