[BUG, 2.7.1beta2, FIXED] Import/Export limits get swapped

[ShadesOfTime]

The limits for importing and exporting a good get swapped when closing the import/export dialog.

Latest observed in v2.7.1beta2.
Reports:
https://forums.civfanatics.com/threads/box-swapping-bug.634589/
https://forums.civfanatics.com/thre...-bugs-and-todos.449958/page-116#post-14964697
https://forums.civfanatics.com/thre...-bugs-and-todos.449958/page-117#post-14968962


Fixed by this commit
https://sourceforge.net/p/religion-...ci/7ea6d29497652550cb15884adbaade8636b9cdd8//

 

[ShadesOfTime]

@Nightinggale

The fix limits the limits to 10 bits = 1023

First, I had cities with limits larger than 1023. Yes, :-D My strategy was to move settlers around by temporarily converting them to scouts. So I had huge ammounts of horses being transporteted back to the coastal cities, which were requesting them at huge numbers, so new arrivees could be made scouts again and be sent to the hinterlands. And say, the quantitiy was above 1500, the horses would be exportet to the continental export city ( which I had a designated one for), which exported the horses to europe/africa/port royale.

Second, the fix narrows the possibilities, to save space, which is not used yet, and ... maybe never will be.

Third, I am forseeing that a limit at 1023 will spawn a bug report when some1 enters a number higher than that and gets the difference to 1023 and for that user it is just a buggy number. This problem already was there 2 years ago, with the limits of 253/254, if I recall right.
With a limit of 16 bits = 65535 this is much less likely.

Wouldn't it be better to leave the limits at 16 bit?

 

[Nightinggale]

The main reason why I picked 10 bits is because the GUI is capped at 999, meaning it would still be just 0-999 even if a full int is used. You do have a point though and I started researching the reason for the 999 limit and it turns out that somebody (vanilla?) just wrote it in the popup generation code for apparently no good reason other than the GUI needs an upper limit. I changed it to 0xFFFF and did so in the network code as well. It appears to work just fine and I have committed this change to git. I can't think of a valid reason anybody would want to use a threshold anywhere near 65535, but at least the number is now based on a technical limit, not some semi random number made up by some unknown person.

This problem already was there 2 years ago, with the limits of 253/254, if I recall right.

That was because the variables were transmitted using 8 and 24 bits for no apparent reason. Even worse, the comments said "implemented Nightinggale's bit twiddling optimization". I had nothing to do with the code at the time despite what the comment said. Also it's unrelated to the 999 limit.

Second, the fix narrows the possibilities, to save space, which is not used yet, and ... maybe never will be.

If somebody really needs more bits in the package, there is another place to get it. It has ints for yield ID and package type. The upper limit for those are 58 and 29 respectively. Also there are 3 bools, which I suspect are transmitted as 32 bit each, despite being used as single bits and some typecasting might make it possible to access all 32 bits. This gives a total of 146 unused bits for those who are desperate enough for more data. The problem is that using those is not really clean code. In fact it will quickly turn into hard to read hackish code and generally code readability and the number of bugs are related.

There is also the option of adding a new network package type, in which case all the variables are available. The problem with that approach is that it generates more network data. While bandwidth is not much of an issue, it will make the game more sensitive to latency. In other words this is about lag when clicking ok in the import/export window. Vanilla has 3 variables for each yield and sends a package for each. RaR has 6 variables in one package. Keep in mind that all packages contains the same amount of bits.

 

[ShadesOfTime]

Thanks! Awesome! No more arbitrarily set limits! :-D

I am updating the original post with your latest commit

https://sourceforge.net/p/religion-.../ci/7ea6d29497652550cb15884adbaade8636b9cdd8/

 

[ShadesOfTime]

@Nightinggale

I tested the commit. Now I can import lumber up to 50000 and export it when it is higher than 30000. Perfect. :-D

I have a last request though, or a proposal:
Lets switch the input fields, so that the import limit is below the import checkbox and the export limit below the export check box. This is more intuitive in my opinion.