Page 2 of 2

Re: Slow Production List

Posted: Mon Mar 04, 2019 10:09 am
by nef
Can confirm the general slowdown was a GTK problem - so thanks to cazfi for the advice and help. There have also been several fixes to presentation issues some reported (RIP) and some not. Not all plain sailing - I will provide more details next week.
Grokem wrote:I still experience some very small double click issues when adding production but they are not bad and not consistent. I think a lot of it has to do with the auto scrolling the available production list when adding production to a city. This is a terrible feature that not only slows down the game itself, but makes it much harder to quickly add several items in the correct order I want them produced. This is a very minor problem compared to the slow city dialog, just thought it was worth mentioning in regards to the only hint of slowness left.
33c Edit: I notice that this is reported as ticket HRM #706351

Re: Slow Production List

Posted: Wed Mar 06, 2019 10:08 pm
by Grokem
nef wrote:I notice that this is reported as ticket HRM #706351
Ah, so that wasn't a FreeCiv change but a GTK one. I wouldn't have guessed GTK would have changed the way the widget behaves and from what I can see neither the tree or the listbox behaves that way. Either way, thanks for the bug case reference and good to know I'm not the only one who thinks this isn't good UI/UX for FreeCiv. I thought this was a purposeful decision to improve selection.

Re: Slow Production List

Posted: Mon Mar 11, 2019 11:35 am
by nef
IDL Clarifications: Using the amplio2 'ISO' map the 'window' for the problem ranges from the half tile width WEST of the IDL (IDL defined as native coordinate 0) to a tile East of the IDL which satisfies the following criterion. If the unit (or city etc.) is in this window and is not currently visible then any 'find' type function - such as 'c' will center the view on the tile one FULL tile to the west of the IDL. Criterion: This will always result in the actual destination (unit/city etc.) becoming visible (to the right of center), so a second 'find' will center the destination correctly. My previous description was less precise.
Grokem wrote:Centering is mostly fixed but still not perfect. It's much better than it was and at least gets the unit on screen.
I expect this observation was due to the map sizes being larger than normal meaning that the 'sour spot' window was smaller in proportion to the total map size. Apart from the clarification above I found NO change in this problem.

Although I have done no testing I would presume that wrap n-s maps would produce a similar problem in the n-s direction. So if you were using a torus map (typical for civ2civ3) you might get the confusing results first mentioned by Grokem.