Page 1 of 1

2.3.3 Release

Posted: Mon Jan 03, 2022 4:35 am
by tstellar
I've tagged the 2.3.3 release. You can find the sources and binaries on the gitlab release page: https://gitlab.com/bygfoot/bygfoot/-/releases

The most visible change in this release are the improved country definitions. Each country now has more leagues and teams and the European cups are much more realistic. Hopefully, this will make the game more fun. Besides this, there are also bug fixes and some simulation performance improvements.

In other news, I've been working some more on creating a bygfoot server for playing over the network. I have a basic prototype working that uses a REST API for communicating between the client and the server. However, it is really slow at the moment, because it's using the xml save files as its 'database'. We will need to add a proper database backend to make the server usable.

If anyone has any other suggestions for how to make the game better, please file a ticket on the giltab project: https://gitlab.com/bygfoot/bygfoot/-/issues and I will take a look at it.

Re: 2.3.3 Release

Posted: Sun Jan 16, 2022 2:47 pm
by David
Thank you very much for your work. When will this version be available for download from https://bygfoot.sourceforge.io/new/download/ ?

Re: 2.3.3 Release

Posted: Wed Jan 19, 2022 5:00 am
by tstellar
David wrote: Sun Jan 16, 2022 2:47 pm Thank you very much for your work. When will this version be available for download from https://bygfoot.sourceforge.io/new/download/ ?
All the binaries are up on the gitlab page that I linked to in the original post, so you can get them from there. However, I found some bugs in the save game feature, so I'm probably going to have to do a 2.3.4 release with the fixes.

Re: 2.3.3 Release

Posted: Sun Jan 23, 2022 12:57 pm
by will_the_canuck
tstellar wrote: Wed Jan 19, 2022 5:00 am All the binaries are up on the gitlab page that I linked to in the original post, so you can get them from there. However, I found some bugs in the save game feature, so I'm probably going to have to do a 2.3.4 release with the fixes.
Hello tstellar. As for these bugs that you found in the save game feature, I am curious a little. Do they just affect the filename of the autosave game or is it the content of the save game that is buggy? I ask since if it just has to deal with the format of the filename, it is something that was already discussed on the forum here. Two examples are: 1) from the "Help" section, Bygfoot crashes when autosaving (2.3.2); and 2) from the "Definitions" section, Informal How-To: The country_<country_name>.xml file.

The autosave filename bug relates to where the components are taken from and how the developers at the time (gunnar) didn't account for the user id or country name to potentially have more than one word in it, although the team name was properly accounted for in that regard. Now if it is content for the save game file, well, that is different and what might that bug entail? I'm just curious.

Additionally, as I was thinking of doing some definition updates myself eventually, I will be curious to see what "updates" to the definitions you have done and included with your release before I start mine, but I'll be waiting before I start mine nonetheless. I'm wanting to wait until February when the first FIFA update is released for 2022. I think I'll try to tackle updating the South American definitions first. I will just need to update the Copa Libertadores and Copa Sudamericana from 2020 to 2022 specs, but as for the country definitions, some can truly need a good update. :) I'll work on adding more names files too, so that there will be more than just the Argentina, Brazil, Peru, and Latinoamerica names files for the players.

Anyways, things take time and I guess I'm more interested in definitions than the actual program. As I am still working with version 2.3.2 and after all the definitions are done, I then might take a look at your version. The prospects of the changes made sound promising.

Will aka will_the_canuck

Re: 2.3.3 Release

Posted: Tue Jan 25, 2022 12:06 am
by tstellar
All the save/load game bugs I fixed were problems that I introduced with some of my other changes. I did not fix the autoave problem you mention.

The new definitions in the 2.3.3 release are all the Europe definitions from the forums (including the international cups).

Re: 2.3.3 Release

Posted: Thu Jan 27, 2022 1:55 am
by will_the_canuck
tstellar wrote: Tue Jan 25, 2022 12:06 am All the save/load game bugs I fixed were problems that I introduced with some of my other changes. I did not fix the autoave problem you mention.

The new definitions in the 2.3.3 release are all the Europe definitions from the forums (including the international cups).
Edited February 3, 2022: See below for edited portion

Ok. As for the "new definitions" being all the European definitions from the forums, at least they are relatively updated. Some of the other definitions that came with the 2.3.3 branch, well, they are what they are. :)

As for bugs and all, I hope you won't overlook a valuable resource that is this forum for potential bugs that can appear in the version that you created. Yes, the "Bug Report" section relates to bugs found in version 2.3.2 and potentially earlier versions, but some of the ones listed haven't been fixed and can still be in the code that you worked on, enough to a point that they can still exist in your version and can pop up again, unless they are checked for. So, with this in mind, I'm going to list a few things that might be of interest and all and although I personally haven't really tried your versions enough to see if these bugs still exist, hopefully over time I will play the version you are creating and hopefully any bugs that I am mentioning will be resolved in your version too. So, before I begin, this might be a long post...just letting you know. Also, even though I am writing what I am going to write, you can do with this information whatever you choose. I am just bringing it to your attention.

Bugs Section:

1) The "Too many substitutions" message bug found here:
Although you've done some optimizations on the code to make things more efficient, this bug recently hit me when playing a game in version 2.3.2 and might still rear its ugly head in your updated version. Basically, this pop up message comes up when you make more than 3 player substitutions in one match. When this error happens, it can happen when say even one player gets banned and the program thinks three or more players were substituted as their positions have changed from when the match first started. The problem is that when the error happens, it won't let you escape out of it or reset your team list and continue your game. It basically stops the game and won't proceed. Your only option is to close the game, without being able to save your progress, so that you are forced to restart your game from your last saved point.

Assuming the team roster is an array, from 0 to 10 for the starting 11 line up, where the goalie would be in position 0 and a forward would be in position 10, whenever a player is banned, their current position is changed to "F" and they are moved in the array from whatever position they were in to position 10. Subsequent banned players are treated the same and moved to the next available position, which is likely 9. But as this is happening, the remaining players are moved up in the list, closer to position 0, to fill the open spot left by the player being banned. And as I like to sometimes use my back up goalie in a position other than goalie when my players on the team have low fitness levels, whenever a player is banned, my goalie is moved to position 1, which is just behind the starting goalie. That is truly annoying.

The checks and balances of the substitution check need to be strengthened because unless a player is moved out of the starting 11 to the bench (positions 11 to up to 21 in an array), no substitution will have taken place. So if a player is banned and is moved to the position of 10 and given a current position of "F", no player substitution would have taken place and a count should not be added to the substitution counter as happening. Also, any movement of players within the starting 11 but not leaving the starting 11 should also not be counted as being substituted, in case a back up goalie is used because the other players have fitness levels that are very, very low.

Edited portion here:

With relation to the "too many substitutions" bug, it is worth mentioning that when I dig a little deeper, I am using an option that is found on the "Preferences" page under the "Options" menu. Under the "Gameplay" tab, there is a selectable option called "Swap adapts structure". The blurb that goes along with that option states, "whether swapping two players automatically adapts the team structure to the player positions." As I mostly had that option selected, I would get the errors that I mention above. I am trying it out without that option selected and so far, it seems to be working ok. I did get the "too many substitutions" message once when I had enough banned players but I was able to get out of it without having to close the program to restart. So something may be different when this option is selected compared to unselected. But either way, as this error is happening in the first place with this option selected, that is a bug and needs to be fixed nonetheless.


2) The "Banned player becomes active again" bug, which is found here:
Besides the "too many substitutions" bug which can literally kill your game, this bug has the power to change the outcome of your game and affect you when you are not even aware of it. Though I've seen this bug happen in both live games and computer controlled games, it can end up with a player being banned and then being able to come back and score later on in the game and in one example, even getting a second red card in the same game.

This bug happens when a proceeding match is different from the type of match you are currently playing. So that if you are playing a league match presently and your next match is a cup match, which would have different team statistics compared to your team's league statistics, when the team statistics are periodically updated for both teams during the game, the statistics can change by showing the statistics for the current week and type of match that you are playing or by showing the statistics for the proceeding week/round that that type of match would be. It is truly annoying. Even after the match is over and before you hit the "close" button in the live game, in such an instance, if you were to check out your opponent's team, the statistics you see will usually be for the next match that they have, which can be annoying especially if one or more of the players has been banned in the match you just played.

To resolve this issue, my thought process is that the two teams that will be playing a match will have to be isolated and a snapshot of their team statistics has to be taken so that during the match, only those statistics will be updated and shown when the match is happening. After the match, the statistics of the match can then be reintegrated with the master statistics for the type of match that was played. And this is something that will have to be done for all teams and all matches as again, this can affect live games and non-live games too. With live games, the "close" button should be able to update all of these records and prepare for the next week/round of matches to be played. In the non-live games, it will depend on whether or not the player has chosen the "skip weeks without matches" option or not, but the bus to advance to the next week/round should also be given some power to the updating of the records also, when it is applicable. Although the solution to this bug can be extensive and consuming, it would be necessary to get things accurate and fair I'd say.

3) "The aggregate table" bug, which is found here:
This bug was introduced when the option of adding new tables to the game was added. By that I mean, when you add more than one additional table to the season, for perhaps an opening and closing season/tournament to the season, but still having an aggregate table, when the time came to go from one season to another, the order in which the new season's table would look would resemble the order that was from the last table added in the previous season. The adding of a new table to use during a season was by using the <new_table> tag in the league file.

Now when I did check this out a little further, it appeared that this bug did not affect promotions and relegations within the league as it seems they were properly read from the aggregate table, as the seasons were being updated. Just that when the order of the new season's table was read, it was read from the last table added. So somewhere, somehow, most likely a pointer might be needed to be updated or checked to see if more than one table was created and if so, use the aggregate table for updating the new season's table. This is a bug because although the promotions and relegations appear to be working properly, it is the selections for the international cups that are affected by this. So instead of properly selecting the teams that earned the various spots in the international cups, the spots are given to the teams in how they performed during the time the last table was available.

This bug affects only leagues that have more than one table shown in a season, which would usually be teams from South America and Mexico, although Canada would also use a similar system.

Whereas the first two bugs affect game play more so than the third bug, the third bug also relates to an issue with the definition tags. The fourth bug is also related to the definition tags available to be used.

4) The "<two_match_week>" bug, which can be used in cup definitions, can be found here:
Although this cup tag of <two_match_week> was only really used with the Mexico definitions that I found, and thus rarely used at all and even undocumented from what I can tell, it is a very useful tag for when wanting to define a cup and wanting to have a two-legged tie play out in one week, but in two rounds in that one week. So for an example, if you wanted to have a 3 round cup file, starting with 8 teams and playing two-legged rounds, for a total of 6 games for the entire cup, you could in theory have that cup completed in 3 weeks instead of 6 weeks. Though the only problem is that for whatever reason, when using the <two_match_week> tag in the first round, it gives off an error and makes the second match nearly impossible to play for the user. But from the second round and above, there are no problems using this tag. So although there are workarounds like having the first round be a normal 2 week two-legged match and then having the second round and above taking place in a single week for each round, trying to wonder why the first round is failing and the other rounds are succeeding would be of interest to me. If this tag could be resolved to actually work from the first round and up, then that would be something worthwhile.

5) The Player Info bug, which can be found here:
Basically, for whatever reason, this is a bug that shows up when you want to check out the information on any of your players. If in the process of checking out the information for your players, you come across this bug, your game will instantly crash. Definitely something you don't want to come across. Now as you did a lot of optimizations for the program already, you may have actually resolved this bug. I don't know. Because it seems that this bug was being caused by a corruption somewhere, and it was assigning an invalid number to a cup id that apparently didn't exist. From my experience with this bug though, it only lasts the season that it is in and it can affect the computer players too, though it will only affect you if one of your players has this invalid cup id associated with it and you select that particular player to see what their information shows. Otherwise if you don't choose to see the information on your players, this bug won't affect you.

As I said, you may have already resolved this bug through your optimizations. I don't know. Though I would suggest maybe keeping an eye out to see if this bug ever pops back up. I will say too that for it to be active, you have to have both league games and cup games to play in a given season, for this bug to affect you. If you have only league games or cup games but not both in any given season, you should not be affected by this bug.

Other Section - Suggestions, Ideas, etc.:

6) Removing the "away goals" rule, which can be found here:
As UEFA has decided to abolish the away goals rule for two-legged matches in all cup competitions, they have instead decided to allow extra time to be used to resolve ties that occur after regulation time for two-legged matches. And if a 30 minute extra time can not determine a winner, than a penalty shoot out will take place.

I understand CONMEBOL (South America) has also decided to scrap the away goals rule too for all their 2022 club competitions and beyond. But where UEFA will play an extra time of 30 minutes first, CONMEBOL will go straight into a penalty shoot out to determine a winner.

So here's the thing. The away goals rule is being eliminated in some parts of the world and may still exist in other parts, although where, I'd have to look that up. And after a tie score in a two-legged match, the way to determine a winner is not the same in all places. So right now, the away goal rule is active in cup matches for bygfoot. If two teams are tied after two legs and the away goal rule does not apply, then I believe they play a 30 minute extra time and then a penalty shoot out to decide the game.

What needs to change is this:
a) The away goals rule needs to be changed from mandatory to optional. To achieve this, the away goals rule needs to be removed from the two-legged matches and a cup property needs to be added that can enable the away goals rule for a cup, when needed. Maybe something as simple as calling the property "away_goals" or "away_goals_rule". By including it in the cup header section as a property, it will enable all two-legged matches to have the away goals rule active. Otherwise, if the property tag is not used, the away goals rule would not apply.
b) The concept of extra time needs to be made optional also, most likely through a cup property. I'm thinking this can be applied to all two-legged matches as I believe most single matches do have extra time included as well as a penalty shoot out too, if it is needed. Or if the differentiation can't be made between single legged rounds and two-legged rounds, then maybe just making the extra time property a cup tag would suffice. Calling the property something like "extra_time" or "extra_time_rule" would be acceptable I think. But potentially having a cup tag for extra time where for a single legged round it could be omitted and just penalty shoot outs would be available if needed could be useful too. So something like a tag called <extra_time> where a value of "0" would have it omitted for that round. Or might that be confusing as they might share the same name and spelling?

Either way, updating the two above points would be a benefit to bygfoot and also offer a chance at how the game is played for the definitions that are created. Things are changing and keeping up to date would be a benefit also.

As there are potentially more to mention here, I will stop for now as it is getting late and all and maybe talk of the other thoughts and ideas later. But for now, any thoughts on what I mentioned here already? As I said, I haven't used your new builds enough to get an idea on any of the above mentioned bugs, but from history, the above mentioned bugs could just as easily still be in your new builds and you may not even know it. So you can wait and see if any of them show up or take a look at the code and see what you can see.

Take care for now,

Will aka will_the_canuck