This adds the same functionality already supported by the prom_rel
tags to support reserve team promotion rules for promotion games.
This allows you to specify a larger range of teams to promte than
the number of teams defined with the number_of_teams tag, so that
if a team is ineligible for promotion than other teams can be
substituted. For example, if you wanted to promote at most 2
of the top 3 teams, you could do:
<prom_games>
<prom_games_number_of_advance>2</prom_games_number_of_advance>
<rank_start>1</rank_start>
<rank_end>3</rank_end>
</prom_games>
Note that the rank_start and rank_end tags are not supported when using
the prom_games_loser_sid tag.
A cup in wich all teams get byes except for two in the first round
would not have any additional rounds added, because the teams with
byes were not being counted in the total number of teams remaining.
This adds some new rules for promoting and relegating reserve
teams:
+ Reserve teams will not be promoted into a league that contains its
first team or a higher-level reserve team.
+ If a first team or higher-level reserve team is relegated to a league
with a lower reserve team, then that reserve team will also be relegated.
In order to enable these rules, you must add the
<reserve_promotion_rules>default</reserve_promotion_rules> tag to your
contry xml file, and also define reserve teams in your league/team_defs
file using the <first_team> and <reserve_level> tags.
The first_team tag can be used to indicate that a team is a 'reserve
team'. The value for this new tag is the name of the first team
for this reserve team. The reserve_level is used to indicate if this
is the 2nd, 3rd, 4th, etc. team for the first team. For example:
<team>
<team_name>Blue</team_name>
</team>
<team>
<team_name>Blue 2</team_name>
<first_team>Blue</first_team>
<reserve_level>2</reserve_level>
</team>
<team>
<team_name>Blue 3</team_name>
<first_team>Blue</first_team>
<reserve_level>3</reserve_level>
</team>
This tag is intended to be used for leagues that may have some teams in
the league that are ineligible for promotions (e.g. reserve teams).
Often these leagues will promote 2 of the top 3 teams or something
similar, so if one team is ineligible, the league would still be able
to promote 2 teams. Below is an example of how to model this scenario
with the new tag:
<prom_rel_element>
<rank_start>1</rank_start>
<rank_end>3</rank_end>
<number_of_teams>2</number_of_teams>
</prom_rel_element>
All constants were stored in a g_datalist structure, which has very slow
lookups. This was not ideally for constansts used during game play
which are accessed thousands of times. Caching these values makes the
game simulations about 2 times faster.
When searching for a team's next fixture, only search in leagues that the team
is actually in. This improves performance a lot in countries with many leagues.
I see about a 7x speed up simulating the first 6 weeks of English leagues using
billys_boots 2019/2020 definitions from the forums.
Try to load all the country definitions on startup to ensure that they
are all valid. Invalid XML can cause bygfoot to abort when simulating
matches and make users lose any unsaved progress.
g_datalist_id_get_data() performs much better than g_datalist_get_data()
because it uses a hash based lookup instead of string compare.
I tested this by starting a game with an English Premier league team
and then simulating to week 6. According to perf's cycle counts, this
patch makes this test case about 10 times faster.
There is still room for improvement. We currently re-compute the GQuark
value for every lookup, but we could pre-compute the GQuark once for each
option key and then use that value when looking up the data.
