This way strategy_live_game_check() only needs to evaluate the condition
and does not need to reparse it over and over again.
This reduces the number of instructions reported by
./test/benchmark.sh --benchmark by ~35%.
team_get_fixture() is expensive and we can avoid this call in the
majority of cases.
This reduces the number of instructions reported by
./test/benchmark.sh --benchmark by ~40%.
The function incorrectly assumed that cups where all the scheduled games
had been played wre complete, and did not take into account the fact
that games for later rounds may not have been scheduled yet.
This allows you to specify an alternative choose_team in the case the
first choose_team does not match any teams. This can happen if a team
qualifies for another cup in the same cup group. You may list an
unlimited number of alternatives with this new tag. Here is an example of
how to use it:
<choose_team>
<choose_team_sid>faroe_islands_cup</choose_team_sid>
<number_of_teams>1</number_of_teams>
<start_idx>1</start_idx>
<end_idx>1</end_idx>
<alternatives>
<choose_team>
<choose_team_sid>faroe_islands1</choose_team_sid>
<number_of_teams>1</number_of_teams>
<start_idx>1</start_idx>
<end_idx>1</end_idx>
</choose_team>
</alternatives>
</choose_team>
This example chooses the winner of the faroe_islands_cup, but if that
team is not eligible for the cup, then it will choose the winner of the
faroe_islands1 league.
This allows for consistent and accurate international cup definitions,
because the draws will be the same no matter what the country a user
has choosen.
So now if a user is playing Faroe Islands, for example, a choose_team with an
sid of faroe_islands1, will select a team from the Faroe Islands.
Previously, this sid would have been ignored and the only way for a
user team to play in an international cup was if it used the special
LEAGUE* or CUP* sid.
As a result of this change, the 'generate' property of CupChooseTeam is
now infered based on the sid, so the generated tag no longer has an
effect in the definition files.
This adds an initial version of a json interface to bygfoot. This
is still in development so the interface may change in the future. This
interface can be used for writing tests or for communication between a
client and server.
To use the interface, you can pass a json file with commands to bygfoot
using the --json option.
We only need to do this validation on program startup and main_init()
may be called multiple times (e.g. if someone starts multiple new games
without exiting)
Also introduce a new Bygfoot struct for holding all the global data.
This will eventually replace all the global variables in bygfoot, but
for now it is an empty struct that we are just passing it through to
functions that access global variables.
I'm not sure why this was done in the first place, but it doesn't seem
to be necessary. This change will make it easier to add alternative
user interfaces.
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.
Tom Stellard