R.I.P Not responding.

You can get help here if Freeciv doesn't start on your computer, or if you keep getting fatal errors while playing etc.
nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

R.I.P Not responding.

Postby nef » Mon Nov 12, 2018 12:32 pm

Decided to take fc2.6.0 out for a spin and I can now mourn the passing of my dear friend 'Not responding', but I'm afraid there was some rain on the funeral procession.

0. Turn Done .... Eta 14s, 12s 10s, .... Off. Wait a few seconds, check my mail (Messages), chew some fat (Nations/Diplomacy), do some shopping (Cities), quiet reading (Research), back to the game (View); plan my moves, WTF, units zipping around. Cool my heels. What? More zipping. Well at least its better than 'not responding', or is it?

1. Artifacts - false positives.

1a. Comet trail of units moving when part of the tile is clipped by the left hand edge of the screen.
1b. Fragments left on screen - Usually a contiguous set of quadrants but sometimes clipped on a corner. If it is an attack the HP bar (chief) often remains as a an artifact (with or without the unit itself). [Which HP bar? It doesn't look like unit.hp_0 in misc/chiefs.] Also the bar disappears if I click on or near the bar but not on the unit's tile.

N.B. I use "Solid unit background color".


2. Atifacts due to unit display process. Various including -
2a. units arriving before moving to their destination.
2b destination tile sometimes being shown vacant when there are units standing there.
2b. Units dead from an attack staying on screen but will go if you click on the tile.
2c. Some units not being shown for some considerable time. (In one instance I was unable to move a unit to a 'vacant' tile for no apparent reason but after about 10 seconds, or so, it turned out there was a foreign unit there.)
2d. Unit animation time is often not used (or bypassed) for auto/ai movement. As a result units jump about to their destination without any obvious animation. Maybe related to (2a) above. Note that same turn goto can also behave like auto.
2e. While many explicit Goto moves are animated (with or without prearrival) there are cases where no animation occurs. In one clear case I had directed a unit to Goto a transporter. No animation, but (i) the transporter showed loaded sprite (+), and the original unit in its original position showed the loaded (L) and sentry (S) sprites. Opening a USDB on the transporter showed the unit as/where it should be but the orignal artifact stayed on screen until the tile was no longer visible.
2f, After a barbarian attack the map view screen showed a legion but the city view showed the Barb. leader (correctly). Clicking on the barb tile made no difference but repeating the city dialogue view ultimately succeeded in changing the unit shown in map view.

False positives are all cleared when the view is changed so that the tile can no longer be seen. ... tbc.

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Mon Nov 12, 2018 12:34 pm

3. CPU time: As the game progresses the processor time needed for any single city dialogue activity (such as rehoming a unit) increases from being quicker than GTK2.0 to being completely lethargic. Late in the game (from T200 to T300) the time needed for each of these individual actions rises from 10s to 25s. The CPU time saturates at 48% and is used by the lead task (start address in the GTK exe). At 25s I give up in extreme pain so I have not yet completed a game. The problem is definitely non linear with development. I note that some simple responses are quick. For example, when 'moving' an item from "Source Tasks" to "Target Worklist" the icon/text is added promptly but the dialogue box is 'busy' and any attempt to try anything results in - you guessed it - 'not responding'; but of course this time it is the DB rather than the client (if there is any distinction). This problem may have been chronic but recent changes may have just aggravated the problem to make it painful. After some testing I believe (Multiplicative) factors are (a) number of cities, and (b) buildings in those cities (or if you like, total # of buildings). First on my list of suspects would be processing of requirements but much of this would be (should be) gratuitous - if this is the case then it should be easy to fix.

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Mon Nov 12, 2018 1:03 pm

4. While I was looking at #3 I also took a look at the CPU time being taken by having units selected. This is a chronic problem (i.e. I know of from when I started with fc2.4.4). Note that I had sounds turned off but had left the sdl dll loaded.


Details:
Columns: TID, CPU, I/O total rate, Start Address, Priority

No units selected:

Code: Select all

8412,  0.02,    822,328, dsound.dll!DllCanUnloadNow+0x56f0,      Time critical
1040,      ,           , dsound.dll!DllCanUnloadNow+0x56f0,      Time critical
528,   0.61, 26,417,196, dsound.dll!DllCanUnloadNow+0x19b20,     14
10488, 0.53, 22,893,390, SDL2.dll!SDL_LogCritical+0x9d0f0,       Highest
3440,      ,           , winmmbase.dll!waveOutWrite+0x850,       Highest
9872,      ,           , GdiPlus.dll!GdipBitmapUnlockBits+0x500, Normal
9560,      ,           , ntdll.dll!TpIsTimerSet+0x40,            Normal
8168,  0.03,  1,444,742, freeciv-gtk3.exe+0x1300,                Normal
6092,      ,           , ntdll.dll!TpIsTimerSet+0x40,            Normal
5896,      ,           , ntdll.dll!TpIsTimerSet+0x40,            Normal
2716,      ,           , ntdll.dll!TpIsTimerSet+0x40,            Normal

One unit selected:

Code: Select all

8412,  0.03,   1,386,112, dsound.dll!DllCanUnloadNow+0x56f0,      Time critical
1040,      ,            , dsound.dll!DllCanUnloadNow+0x56f0,      Time critical
528,   0.61,  26,516,204, dsound.dll!DllCanUnloadNow+0x19b20,     14
10488, 0.67,  29,045,354, SDL2.dll!SDL_LogCritical+0x9d0f0,       Highest
3440,      ,            , winmmbase.dll!waveOutWrite+0x850,       Highest
9872,      ,            , GdiPlus.dll!GdipBitmapUnlockBits+0x500, Normal
9560,      ,            , ntdll.dll!TpIsTimerSet+0x40,            Normal
8168, 16.38, 709,204,470, freeciv-gtk3.exe+0x1300,                Normal
6092,      ,            , ntdll.dll!TpIsTimerSet+0x40,            Normal
5896,      ,            , ntdll.dll!TpIsTimerSet+0x40,            Normal
2716,      ,            , ntdll.dll!TpIsTimerSet+0x40,            Normal

[site chokes so next part new reply ...]

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Mon Nov 12, 2018 1:06 pm

Five units selected:

Code: Select all

8412,  0.03,     1,110,070, dsound.dll!DllCanUnloadNow+0x56f0,      Time critical
1040,      ,              , dsound.dll!DllCanUnloadNow+0x56f0,      Time critical
528,   0.47,    20,260,812, dsound.dll!DllCanUnloadNow+0x19b20,     14
10488, 0.79,    34,349,276, SDL2.dll!SDL_LogCritical+0x9d0f0,       Highest
3440,      ,              , winmmbase.dll!waveOutWrite+0x850,       Highest
9872,      ,              , GdiPlus.dll!GdipBitmapUnlockBits+0x500, Normal
9560,      ,              , ntdll.dll!TpIsTimerSet+0x40,            Normal
8168, 36.02, 1,560,293,410, freeciv-gtk3.exe+0x1300,                Normal
6092,      ,              , ntdll.dll!TpIsTimerSet+0x40,            Normal
5896,      ,              , ntdll.dll!TpIsTimerSet+0x40,            Normal
2716,      ,              , ntdll.dll!TpIsTimerSet+0x40,            Normal


These stats were taken while the system was otherwise quiescent. Moving the view so that the units were off screen reduced the CPU by about a third. ALSO, changes in selection (e.g. alternating z/v) resulted in a bizarre performance issue - the GTK exe lead task would saturate the processor (at 48%) for a capricious length of time ranging from 'just' a few seconds to many minutes.

In all cases of measurement I used a turn zero game - start units but no moves no cities etc..

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Mon Nov 12, 2018 1:11 pm

5. Some buoys do, some buoys don't.

Buoy and illuminated area go dark after one turn.

(a) In the first case a ship sent to the area also went dark but a second ship lit up again the area suggesting a vis count loss of 2. It's rather weird having your own ship disappear into the fog of war. Still partly visible but loses focus every time you give it a move order with moves left. Also when moving it does a bit of a dance (back and forth) but I would think that is due to problwm #2, The flag on the bouy stayed bright.

(b) Similar to a., but this time a second ship did not light up the area. Also the server crashed. On restarting the last saved game I got 21 of these messages:

Code: Select all

in map_change_seen() [../../../../server/maphand.c::904]: assertion 'plrtile->seen_count[V_INVIS] + !game.info.fogofwar <= plrtile->seen_count[V_MAIN]' failed
Please report this message at https://www.hostedredmine.com/projects/freeciv

and 11 of these:

Code: Select all

in map_change_seen() [../../../../server/maphand.c::894]: assertion '0 <= change[v] || -change[v] <= plrtile->seen_count[v]' failed.
Please report this message at https://www.hostedredmine.com/projects/freeciv
in map_change_seen() [../../../../server/maphand.c::904]: assertion 'plrtile->seen_count[V_INVIS] + !game.info.fogofwar <= plrtile->seen_count[V_MAIN]' failed.
Please report this message at https://www.hostedredmine.com/projects/freeciv

The restart cleared the fog that turn but the same ones went fogged again next turn but with even more erratic behaviour.

Of note: these bouys (and some others not experiencing any problems) were within hostile city radii (but not inside their national border).

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Mon Nov 12, 2018 1:12 pm

The new antipodal layout is taxing my muscle memory, but there is a real downside:

6a. The Unit Selection Dialogue Box expands to the right to accomodate unit names etc., but initial placement on the screen is based on the initial inadequate size. This presented a problem in GTK2.0 (especially fc2.5.10) when selecting a unit stack on the right hand edge of the canvas since the close buttons could go off screen. Manageable in GTK2.0 by remembering to recenter (hah!) No longer a problem in GTK3.0 but it has been replaced with one more serious: selecting the USDB from the panel has no work around, so one often needs to move the box in order to close it. Note: it is not always the case that there is a tiny fragment of the lower close button that is still accessible.
6b. Tool tips for the panel can run off the right edge of the screen.

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Mon Nov 12, 2018 1:17 pm

7. Pathfinding.

edit (7b)

7a. Pathfinding for connect-to road is bizarre. Various examples where an arbitrary (sub optimal) path is chosen. E.g. using roads rather than railroad to reach first tile to be worked with the result that turns are wasted (i.e. not just the immaterial wasted move fragments at the end of each turn). I recall some chronic problems with Goto but not connect_to. [Is this a known problem concerning AI/auto miscalculating rail (non) move cost.]
7b. If a bomber stops in a city during its second turn phase, Goto And goTo will not let it leave the city (that turn) even if the final destination is in reach, Cursor keys can be used to get it out of the city.
EDIT: Same problem occurs with a fighter in its first (and only) turn.
7c. Various connect_to orders are denied if the final destination is next to a foreign city. [This one is chronic,]
7d. Goto an exploring transporter still works (patrol is ok). As an aside here should the new regime be softened a little - there is no issue if the cargo can reach the transporter before it can move (i.e. this turn)?


8. International Date Line.

Various find unit (implicit and explicit) for a unit that is just east of the IDL (approx 7 tiles; native coordinates) mislocates the canvas to center on the IDL itself (highest/lowest tile column number?). This seems to occur if the current center is just east of the IDL e.g. a (second) use of "c" will correctly locate the unit. I recall some discussion on this (as a known problem), but I have not noticed it before. It is now pervasive. Also a problem with various find city.

9. Pillage fortress .... NOT!

Well not until you learn the trick (select something else first, then change your mind). Note that this is only for the new pop up. Civ1 seems to be OK.


10. Patrol (q) does not notice foreign cities that are empty (unless actually obstructed by them).

I am reporting these problems here first for the following reasons:

A. These problems are obvious enough for all of them to be already ticketed. (Please comment)
B. This forum has higher visibilty to the community so others who experience these same problems will know that they are being dealt with.
C. Give others the opportunity to comment on the problems as they may, or may not, experience them.

Next week: some lesser issues ....
Last edited by nef on Mon Dec 03, 2018 12:24 pm, edited 1 time in total.

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Tue Nov 20, 2018 12:49 pm

11. Caravans.

11a. The new caravan pop up defeats two client options: auto center on units, and pop up caravan and spy actions. The auto center is variable. Usually happens IMMEDIATELY after you have done something of significance (like attack) - so you can't see what happened. This even happens when you build a city - the caravan pops up before the (new city) dialogue.

11b. Speaking of caravans is it reasonable to impose a move fragment penalty when the client knows that the activity is illegal. This happens when the caravan is part of a stack already in the city (building a wonder). Normally the illegal activity would not be offered. (In fact there is a perversity to this - the client will report "No action possible" when ENTERING the city and decline the order even though "Keep Moving" is valid and could be offered as a valid menu choice.)

In other circumstances e.g. single caravan, the client admits it knows the action is illegal - "Your caravan was unable to help build wonder".

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Tue Nov 20, 2018 12:52 pm

12. Diplomacy contact.

12a. At peace but no contact. But then when contact was made:

"I found you Sejong! Now make it worth my letting you live, or be crushed."

12b. No contact even with units standing next to a city. Movement needed.

12c. "Concerned citizens point out that that cerasefire with ..... will soon run out" and indeed the nations report shows 1 turn ceasefire. Trouble is, is that it also shows R.I.P. (correctly). Should the ceasfire expire at the time the player dies? Similarly, an armistice should mature.


13. Diplomacy agreements.

13a. If you get gold from one diplomatic agreement being negotiated the client does not recognize the (new) greater amount when using the spinner in another agreement also currently being negotiated (with a different player).
13b. An offer including a payment from me changed to a payment to me (by adding another tech) results in the spinner changing but no change to the agreement itself. Appears to be a special case of 15a because I (used to) do this often (The reason in this case was that the AI player's treasury was actually zero at the time the agreement was being renegotiated - i.e. the agreement document was extant from a previous turn).

nef
Hardened
Posts: 154
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Tue Nov 20, 2018 12:53 pm

14. An eXploring unit ocasionally stops for no apparent reason. Move it (if necessary) and then reissue the order and off it goes.

15. Road sprites don't connect n <-> se (amplio2).

16. When changing government the tax rates often have to be changed (by the fc engine). If the inital rate was 100% tax (democracy) and the change was to, say, communism the tax rate drops to 20% not 80% as you might expect.