Issues/bugs with version 2.4.0-dev-97

Here you can... report bugs. Open a new thread for each bug, please.
Post Reply
will_the_canuck
Posts: 145
Joined: Tue Jan 16, 2018 5:54 am
Location: Canada

Issues/bugs with version 2.4.0-dev-97

Post by will_the_canuck »

Hello all. Well, as I tested both version 2.3.5 and version 2.4.0-dev-97, I did come across a few bugs that could apply to both versions but I mostly documented the bugs when using version 2.4.0-dev-97, so I'll list them all here. Instead of listing them individually in their own thread, I'll group them together here as they all apply to the same version anyways. I'll start by listing the bugs that I want to talk about and then later go into them in deeper detail. Hopefully it will be easier to follow along. Also, as I've mostly used version 2.3.2, some of the issues / bugs may be compared to version 2.3.2, for their behaviour, for example.

Before I continue, I'll mention that I am using version 2.4.0-dev-97 for ubuntu 20.04 as my operating system is Linux Mint 20.3 (64-bit) with Xfce. The computer I'm using is an older HP laptop (HP Pavilion dv6000) with an AMD processor (AMD Turion 64 X2 Mobile TL-50) and 4 gigs of ram. It is over 10 years old for sure, but it still works. And lastly, when playing the game for testing purposes, I let the computer play the game for me instead of me playing a live game, so some decisions were out of my hands, like when player substitutions and all were decided.

The list of issues / bugs are:
(1) the size of the saved game file is too big / large, at least when compared to version 2.3.2;
(2) when using the "browse teams" option, some teams listed may appear more than once, depending on how many international cups they may participate in;
(3) in a computer controlled game, a player that was substituted off of my team was later substituted back on, in the same game;
(4) following up to number 3, in another match I was playing, one of the players that was substituted off was my best player at a particular position, and when looking at the players in the starting 11 at the end of the game, it appears to have been one of the fittest players too, at that particular position;
(5) when using the training camp feature, the full amount shown that would be charged does not appear to be taken off from the current money that the user has;
(6) when the sponsor contracts are coming up for renewal, if the sponsor is satisfied with the results of the user, the previous contract details are not being shown;
(7) the ability to build up to 10,001 seats per time, and multiple times per round, if desired;
(8) average attendance values can be higher than what might be normal in version 2.3.2;
(9) when a league or team has a low enough starting average skill value / level to begin with, if a player were to select a team from a league like that, they could start the game with their stadium capacity and money total at zero, in addition to having a player or two with weekly wages of zero also;
(10) a player that received a red card in the game was still active and participating in the game;
(11) performing some actions would give Gtk-CRITICAL errors that were shown in the terminal window;
(12) when trying to perform a debug in the terminal window, some error messages would show up and a core dump would be produced;
(13) a particular action when done likely too fast would produce a multi-thread error and produce a core dump, one that has been seen in version 2.3.2
also.

So, as the list above gives the idea of what the bugs or issues are, below will be the details of what I am trying to say about the bugs or issues.

(1) the size of the saved game file is too big / large, at least when compared to version 2.3.2:
Ok. This is one of the bigger bugs I would say as it directly relates to the size of the saved game files for bygfoot. If you were to start a game selecting any definition available, and then save the game in the first round of the first week, before doing anything else, there is a chance that the saved game file will be over 16 megabytes in size. And I do mean ANY definition. For comparison, when I was testing my 9 tier definition for England for the 2023-2024 season, when I would start the game up using bygfoot version 2.3.2, I could save just the England definitions by themselves at the start of the game and it would take about 2.1 megabytes in size. Now in version 2.4.0-dev-97, that same saved game file would occupy over 16 megabytes of file space. As for how much exactly, it depends on how your file system interprets bits and bytes I guess.

So the problem with this bug is that within version 2.4.0-dev-97, when it saves a game to a file, the saved game includes all definitions that are present on the system, not just the definitions that are being used or required by the user's game play. So an example would be that if a user was playing a game in Europe, they would have the definitions saved for the country that they are playing as well as any international cups that may apply to that country also. But besides just that, the saved game will have saved the definitions for other countries that the user themselves are not even playing, like the other countries in Europe and copies again of the international cups that would apply to each of those countries, and even the definitions of countries from the other continents, like Asia, Africa, North America, South America, and Australia. That's the problem. When a user was playing within version 2.3.2, the files that would be saved would only be definitions that were relevant to the user's game and nothing else, unlike what is currently happening with version 2.4.0-dev-97.

(2) when using the "browse teams" option, some teams listed may appear more than once, depending on how many international cups they may participate in:
When looking at this issue, I understand that you previously had a bug related to this and it was national teams that showed up in national cups that were listed when using the "browse teams" option. Now, it does appear as if all teams that are participating in international cups will be shown in the "browse teams" listing, even if they are national teams that are a part of the user's country definitions and teams that would not normally be listed, or shown, as being a part of an international cup. As all teams that participate in an international cup are being shown as being associated with that international cup, all international cups are showing all teams that have participated in them, even if the teams in question started off or finished in a different cup. So if a particular team participated in three different international cups in a single season, by the end of the season, they would show up as being a part of those three separate international cups.

In version 2.3.2, national teams (teams that belong to the country definition that the user is playing) would not show up as part of the teams that were associated with the international cups. It seems that in version 2.4.0-dev-97, those same national teams are showing up. Additionally, in version 2.4.0-dev-97, any international team that was in two or more international cups, or any national team that qualified for an international cup, would be shown at least twice when using the "browse teams" option, although they would likely have the same team and statistics. In version 2.3.2, I do believe that the international teams would only be associated with the international cups that they started out in. Additionally, national teams that qualified for international cups would not be listed with those international cups that they qualified for.

One issue I'm wondering about is the number of teams in any game that the user is playing, and by having teams showing up more than once, that can add to the number of teams listed. Might this have any affect on the game at all? And when it comes to the trade market / transfer list, might that be affected too in any way?

(3) in a computer controlled game, a player that was substituted off of my team was later substituted back on, in the same game:
Basically, the above blurb says it all. A player that was substituted off and replaced with another player was later substituted back on, in the same game. I have seen this happen more than once and it relates to players from my team only. I haven't checked out whether or not the computer will do it for the computer controlled team or not, but there is likely a chance it is doing it too.

As we all know, once a player is substituted off, they are no longer allowed back on the field during the same game. This is clearly a bug. Now whether or not this affects users that play the live game, I do not know as I never tested it. That is something that could be tested by someone else at least.

(4) following up to number 3, in another match I was playing, one of the players that was substituted off was my best player at a particular position, and when looking at the players in the starting 11 at the end of the game, it appears to have been one of the fittest players too, at that particular position:
Ok. This one is a funny one as when it happened, I believe I was in a cup competition and in the semi-finals. The computer was controlling my game play as I was not playing a live game and I did end up losing that game and the two game series, thus not being able to qualify for the finals of it. It was disappointing. But what happened was that I started off I believe in a 4-3-3 and the computer switched me to a 3-3-4. So it took one of my defence players and replaced them with a forward. I would not have minded that except that it took out my strongest player, and also healthiest I believe, and replaced it with a forward that was much lower in skill level. Additionally, it left defence players that were lower in skill level and health levels I think, which is the kicker here. And when I'm talking about skill level for the players, the player it took off was at least 20 to 30 points higher in skill level than some other players in the same position. I think at the time, it was up to 40 points higher in skill level than the forward that replaced it. It makes little sense. Although we are able to select a "team strategy", I do not believe I selected one, so I would just go off of the default strategy. But the behaviour of the player selection made no sense to me as it basically crippled my team in a way because it replaced a higher skilled player with a much lower skilled player and although it could have taken out a lower skilled player than the one it did, it did not do that.

So I guess I'm wondering what criteria does the computer use when selecting players to substitute off? Is there a ranking or such? Why would it go for the stronger players when weaker players are available to be taken off? I do not know what the behaviour was like in version 2.3.2 as I do not believe I even thought of it, but I guess now I am curious.

(5) when using the training camp feature, the full amount shown that would be charged does not appear to be taken off from the current money that the user has:
Self explanatory. Basically when you use the "training camp" feature, you are presented with a value that you would be charged to use it, depending on the quality of the hotel you use. After you accept the level of training you wish to do, the full amount of what the charge was is not deducted from your current level of money but rather a lesser amount. So in other words, you're getting a discount. Yes, this does benefit the player but also, it does not represent the true value of what you are supposed to be charged. So something is stopping it from charging the full amount, for whatever reason.

Of note, I do believe this behaviour was also present in version 2.3.2.

(6) when the sponsor contracts are coming up for renewal, if the sponsor is satisfied with the results of the user, the previous contract details are not being shown:
In version 2.3.2, when the sponsor contract was coming up for renewal, you would get one of two pop-ups. If the current sponsor was satisfied with your results, you would get a pop-up showing the current amount that the sponsor was paying you, in addition to their new offer, and their name would also be listed. This offer would usually come around one month before your current sponsored contract ended. If the current sponsor was not satisfied with your results, on the week that your current sponsored contract expired, you would get a pop-up showing a list of names and new contract offers, of which would be different from your previous sponsor. You would not be aware of any wording I believe suggesting that your previous sponsor was satisfied or dissatisfied with your performance.

In version 2.4.0-dev-97, when it came time for sponsor contract renewals, I noticed that the pop-ups did not have any language to say whether or not my current sponsor was satisfied with my performance, just that I was being offered a contract that appeared new. When I looked into it more, it appeared as if when my current sponsor was satisfied with my performance, I was only offered one offer to renew, and it was from my previous sponsor, although the pop-up did not specify that. Nor was I shown what my previous contract terms were. If my contract sponsor was not happy with my performance, I would get the same pop-up window but with multiple contract offers, usually. But again, the only difference being that if my sponsor was happy, I would only get the one offer, and if my sponsor was not happy, I would get multiple offers.

So as this was a feature that was present in version 2.3.2 and was working, I'll ask if you can restore it so that the users can have a better understanding when it comes to sponsor contract renewals.

(7) the ability to build up to 10,001 seats per time, and multiple times per round, if desired:
Ok. This kind of ties in with number 8 also as the attendance values can get higher than what was happening in version 2.3.2, and thus, giving us more spending money in version 2.4.0-dev-97 from that increased attendance. Now I do know that in version 2.3.2, we could only build up to 10,000 seats at a time. If I recall correctly, we could also only build once per round, per week. So if a particular week had 2 rounds in it, we could build 10,000 seats in each round but not more than that in each round. Again, I'm not certain but I do believe it was like that.

With version 2.4.0-dev-97, we can build as much as we want, whenever we want. So if we had the funds and wanted to build 50,000 seats in one week, even if there was only one round in that week, we could do it without problem. We would just have to go to the "Show stadium" feature and select to buy 10,000 seats, five times.

Now whether this is good or bad, I can't say right now. Whether this ability was available in version 2.3.2, I'm not certain but again, I do not believe it was as really, we wouldn't usually have as much money as we can get in version 2.4.0-dev-97, at least in the beginning. I guess this aspect of version 2.3.2 will have to be tested for or if someone can test it and report back, that would be appreciated. But for now, at least the only visible difference is 10,000 seats compared to 10,001 seats.

(8) average attendance values can be higher than what might be normal in version 2.3.2:
Ok. This is the second biggest issue/bug/cheat I might argue when compared to version 2.3.2. I say that since if a player is smart and invests in their stadium capacity, then they can get a larger return on their attendance than if they were playing with version 2.3.2. For my two test games in version 2.4.0-dev-97, I did track my average attendance and stadium capacity through the different seasons and in the various tiers that I played, and I was definitely surprised. I would definitely call it a cheat. And even though I tested my own definitions for England for 6 seasons, I'll continue testing it just to see what the outcome can reach based on the attendance figures alone.

So for my first test of the England definitions that came with version 2.4.0-dev-97, I started off in tier 10, which had an average talent value of 2300. As you can see, I started off with a stadium capacity of 400 seats I believe it was and my teams starting average skill level was 20.3 average, but 19.7 average once I added the lone youth recruit to my team. From there, I made my way up to having a stadium capacity of 50,000 seats by the third season. I spent all three seasons in tier 10, although at the end of the third season, I did qualify for promotion and would then start in tier 9 for the fourth season, if I continued on with the game.

england-test1:
(i) season 1: starting capacity: 400 seats (I believe)
capacity at end of season: 23,147 seats
average attendance for season: 1,788
(ii) season 2: starting capacity (week 6): 26,009 seats
capacity at end of season: 48,371 seats
average attendance for season: 3,889
(iii) season 3: starting capacity (week 4): 50,000 seats
capacity at end of season: 50,000 seats
average attendance for season: 5,077

Starting Av. skills:
Season 1, week 1: 20.3 avg, 19.7 avg w/ 1 youth recruit
Season 2, week 1: 21.1 avg
Season 3, week 1: 23.3 avg

Although my average talent value didn't quite change that much by how it looks above, I'll say that at the end of the third season, my average talent value for the whole team was 30.4 average. So whether or not that played any part of the increased attendance, I don't quite know but by just looking at the capacity I had available and the increase in the average attendance over the 3 seasons, it is quite noticeable. And again, this is in tier 10 of the England definitions that came with version 2.4.0-dev-97. Since I haven't tried these definitions with version 2.3.2, I can't quite compare them.

As for my second test, I used my own 9 tier definitions that I created for England and did test those in version 2.3.2, before trying them out in version 2.4.0-dev-97. As you can see, I started off in the lowest tier, that being tier 9 and played six seasons and made it up to tier 6. Of note, I did finish the sixth season by winning a promotional cup so I did qualify to be promoted for the seventh season. Also, I should point out that although I created a 9 tier definition and the one that came with bygfoot was a 10 tier definition, the average talent values that I use for my definitions are different from the ones that came with version 2.4.0-dev-97. From tiers 5 thru 9, the average talent values are: 4100, 3300, 2500, 1900, and 1300. So starting off in tier 9, I was starting off with an average talent value that would be close to the 1300 level. And just looking at the values below, where in the third season, in tier 9, I was able to achieve an average attendance of 4,715. That is likely unheard of since when I was playing in version 2.3.2, I believe that the most I could achieve in tier 9 in the three seasons I was in that game, was under 200 for an average attendance. If I recall, I believe it was something like 181 or so was the highest attendance I could normally get. So getting to achieve an average attendance here of 4,715 is just huge in comparison.

england-test2:
(i) season 1: starting capacity: 0 seats
capacity at end of season: 24,242 seats
average attendance for season: 1,054 (tier 9)
(ii) season 2: starting capacity (week 5): 26,957 seats
capacity at end of season: 49,965 seats
average attendance for season: 3,462 (tier 9)
(iii) season 3: starting capacity (week 1): 50,000 seats
capacity at end of season: 50,000 seats
average attendance for season: 4,715 (tier 9)
(iv) season 4: starting capacity (week 1): 50,000 seats
capacity at end of season: 74,360 seats
average attendance for season: 5,685 (tier eight)
(v) season 5: starting capacity (week 6): 77,337 seats
capacity at end of season: 99,864 seats
average attendance for season: 8,114 (tier 7)
(vi) season 6: starting capacity (week 1): 100,000 seats
capacity at end of season: 95,963 seats
average attendance for season: 10,120 (tier 6)

Starting Av. skills:
Season 1, week 1: 11.2 avg, 10.5 avg w/ 2 youth recruits
Season 2, week 1: 10.6 avg
Season 3, week 1: 17.7 avg
Season 4, week 1: 21.5 avg <-- promoted to tier 8 at end of last season
Season 5, week 1: 29.1 avg <-- promoted to tier 7 at end of last season
Season 6, week 1: 33.8 avg <-- promoted to tier 6 at end of last season

When looking at the average attendance for season 6, that being 10,120 in tier 6, that is when the average talent value for the whole tier would have begun at 3300. Again, that's huge. Though of note, when I finished season 6, my average talent value for my whole team was 37.2 average. When I think back to some of the games that I played when using version 2.3.2, I recall that when I played some countries that had lower average talent values around 5000 to 5300 for example, I couldn't really get attendance values more than 15,000 per season. When I look at these values here, I think when I get to tier 4, which will have an average talent value of 5100, I think I can be much more ahead of 15,000. How much more, I won't know but I do feel I'll be getting more than that for sure. It almost makes me wonder if I can push the envelop with version 2.3.2 also as I can push it here, but from my thoughts, I don't really think so. But I will keep trying it here until I get to 200,000 seats and hopefully tier 1, just to see what the attendance levels can bring.

So reporting these values and saying what is wrong are two different things in that I need to think what I think is the cause of all of this. So as there was a previous bug in version 2.3.5 that basically gave the user an attendance that would in theory give them a value equal to their level of stadium capacity, tstellar did work on it and made it better, but it is still producing values that can be higher than what version 2.3.2 offered. So going forward, I believe tstellar did what he felt was correct, although because of it, it might give the user a cheat, especially if they build large amounts of stadium capacity. No, they won't get the entire amount but they might just end up raising/inflating the average capacity and thus benefit from the higher than normal amount when the attendance values are calculated for the user.

When I look at the menu option of "Options" within bygfoot, and then select the option of "Preferences", the "Options" pop-up menu appears. If you were to select the "Edit" button for the bygfoot_constants file, another pop-up window will appear. Select the "Float" tab, and then search for the options of "float_game_stadium_attendance_percentage_lower" and "float_game_stadium_attendance_percentage_upper". When looking at those two options, I kind of feel that they can likely help determine a teams attendence for any regular league game. There are other constants too to account for other things like national and international cups. So if a user was to create a large stadium capacity and then it was added up with all the other stadium capacities of the other teams within a particular league, using those two options above might be used to calculate a percentage to use and as the average capacity of all the teams in the league will be higher because of the user, the user could possibly get a higher attendance value because of that, I'm guessing.

I'm trying to wonder if version 2.3.2 does it differently in that they maybe remove the user's stadium capacity from the average calculation and then run the numbers as is, and whatever number they come up with, then compare it to the user's stadium capacity. If the number they output is within the user's stadium capacity, they will use that number. If the number is larger than what the user's stadium capacity is, they'll use the user's stadium capacity then, up to the point of the number they output for the user's attendance. I guess the point would be that they would use the output attendance values from the average and then use that as the attendance, up to the point where the user has the available capacity. If the user has less than the suggested attendance, then the maximum at that time that the user has for capacity would be used for the attendance values. I'm guessing. This might be the only way to suggest how the attendance values for version 2.3.2 are as they are. Unless they use other factors, which I can't quite see right now.

But any way you look at it, right now, version 2.4.0-dev-97 can provide an easier time for users if they invest in their stadiums, as they can receive more funds per game and in return, be able to afford better players to make their teams better, even at an earlier level. Although when it comes to the higher levels and definitions that have a higher average talent value for the top tiers, like 8000 or more, you can get teams with players having skill values in the 90s and sometimes even multiple players in the same position. Users will still be limited in that sense where if you have too many players with skills in the 90s, some players may not want to renew their contracts with you or sign with you, which is a bit of a pain. I guess it will make things interesting.

(9) when a league or team has a low enough starting average skill value / level to begin with, if a player were to select a team from a league like that, they could start the game with their stadium capacity and money total at zero, in addition to having a player or two with weekly wages of zero also:
Ok. This more or less relates to my definitions I created for England because in tier 9, I have the average talent value set to 1300, which is by far much lower than anything else out there within bygfoot right now. When I have played a few games with this definition and starting in tier 9, there have been times when my stadium capacity and starting money have both been zero. Though this is not a bug, it might just be how the starting values are rounded off. And yes, it can provide some added challenges to the user as they likely wouldn't expect it to start like that, but it isn't really that hard to get over when you think of it. You just have to be wise and start building enough stadium capacity that you can afford and likely sell one or more of your players as soon as possible, so that you can build adequate stadium capacity.

As I would think it would be a rounding issue, perhaps rounding the values to the nearest factor of 100, or maybe even rounding down to a factor of 100, I wonder if that might be the case, might the factor of 100 be changed to perhaps a factor of 10, so at least they can start off with something other than zero? And yes, this would be something that would be rare I would think, unless other people start creating multi-tiered definitions that go down to such a level to use average talent values near 1000, like I did here. I do wonder what it might be like if it truly was a rounding factor of 100 and you changed it to a rounding factor of 10, how might that affect the user as well as the computer players, since there are times that I see that games are played and the computer player's team had an attendance of zero also. I guess if you changed the average attendance values to not include the users but just using the computer players, then having stadium capacities for the computer players with values greater than zero would definitely help that out.

Additionally, as the stadium capacity and starting money levels can be zero when starting a game at such a low average talent level, there are some players that actually start off with wages of zero also. It does appear as if the wages themselves use a rounding factor of 10. I wonder what things might look like with using a rounding factor of 1 for the wages.

Again, this is likely more just a niche thing but I'll leave it up to you.

(10) a player that received a red card in the game was still active and participating in the game:
Ok. I've mentioned this bug before and it is present in version 2.3.2. I also witnessed it in version 2.4.0-dev-97. I believe I had evidence at one point but lost the saved game. Besides that, the saved game file was over 16 megabytes in size, so where to send it was an interesting thought. Regardless, I'll explain what happens again anyway.

This error occurs when the user or computer player is playing one type of match (league or cup) and their next match is a different type of match. So they might be playing a league match now but their next match would be a cup match. This error will manifest itself if in the current match you are playing, a player who could be either a computer player or a user's player, gets a red card. In the second half of the game, that player that received a red card, sometime in the game, will be allowed to be active because the way bygfoot refreshes the statistics on the players, they somehow use a timeframe that includes the status of the future match, where the currently banned player is not banned, for example. Additionally, if a player is banned in the next match and not the current match, they will show up as being banned in the second half of the current match because of this same issue.

It really is an annoying bug and one that will take consideration on how to resolve it. As it all relates to the way bygfoot refreshes the statistics of the players during a game, the resolution would be to make the future statuses not available while the current rounds are being played. I guess you just have to see it happen for yourself to actually believe it. And when I think back to some of the live games I've played, I do recall that when finishing a game and looking at my opponents' team, some players that got red cards during the match did not show them at the end of the game. As I said, it showed the statistics of the teams as they would appear for the next match. A little annoying that way.

(11) performing some actions would give Gtk-CRITICAL errors that were shown in the terminal window:
Events that gave Gtk-CRITICAL errors:
(a) opening up and viewing the "Youth Academy", through the menu
(b) opening up and viewing the "transfer list", by using the transfer list icon
(c) opening up and viewing the "Finances" page, through the menu
(d) by selecing and viewing the "Tables" page, through the menu

So basically, when I paid attention and looked at the terminal window after some actions were being performed, I noticed that for all the Gtk-CRITICAL errors I was getting in the terminal window, they applied to some of the actions listed above. I will note here that when I do play bygfoot, I do usually have quite a few Gtk-CRITICAL errors show up in the terminal window. It is a mystery to me otherwise. I'll add that the message after the error notification usually says, "Source ID #### was not found when attempting to remove it". A whole example is as follows:
"(bygfoot:16748): GLib-CRITICAL **: 02:48:42.844: Source ID 2587 was not found when attempting to remove it"

So although I only made note of a few actions that create these errors, what effect they might have or how to remedy them, I don't quite know the answer to that. And there may even be more actions that can create these errors, but for now, I don't know which ones those would be.

(12) when trying to perform a debug in the terminal window, some error messages would show up and a core dump would be produced:
One of the things with using a linux version of bygfoot version 2.3.2 was the ability to use the debug mode, by using the command of "bygfoot -debug 500" in the terminal window. For that command, the 500 represented the number of lines to show, or something like it. When I use a similar command on your version of bygfoot, I get some error messages and a segmentation fault, which causes a core dump. The following are the related error messages:
"bygfoot:18963): WARNING **: 03:11:03.983: file_find_support_file: file 'bygfoot_misc2.glade' not found.
(bygfoot:18963): Gtk-CRITICAL **: 03:11:03.983: IA__gtk_builder_add_from_file: assertion 'filename != NULL' failed"

I will add that when I tried to see if there were any man pages for your version of bygfoot, nothing came up. So whether or not the debug mode is available in your version or not, I don't know. if it is, then you are missing a file or two it seems in your installation file. I'll repeat what I mentioned in another post about testing your newer versions...I removed any previous version of bygfoot before I installed a new one, so as to judge your newer versions on their own. So if the file may have existed in a previous version, it wasn't present in the version that I tested.

(13) a particular action when done likely too fast would produce a multi-thread error and produce a core dump, one that has been seen in version 2.3.2 also:
The error message produced is as follows:
"[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
bygfoot: ../../src/xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)"

I would sometimes get this in version 2.3.2 when changing the numbers too quickly when trying to purchase players in the transfer window and using the arrows to change the dollar amounts for both the fee and the wage values. I guess I clicked the mouse button too fast sometimes. I got this once with version 2.4.0-dev-97. Whether or not any of the code calls upon the information mentioned in the error message, I don't know. I'm just mentioning this here for reference.

So anyways, these are some issues / bugs / errors I found within version 2.4.0-dev-97. I'm posting them here since this is a place to post bugs. I'm thinking of also posting them on your gitlab site so you can see them there too, but for now, it will take a little time to complete everything as it took me so long just to do this list. Hopefully you can resolve some of these issues for us as it would likely help make the program even better. So for now, take care and have fun.

Will aka will_the_canuck
Post Reply