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: 166
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Postby nef » Tue Nov 20, 2018 1:02 pm

GTK3.0 GUI.

17. When multiple units are being loaded onto selectable transports the dialog box is repeated for each unit but it gives no details of the home city. The side panel does not help because it summarises multiples. Also one would want even more details of the transporters to provide for an informed choice.

18. CMA sliders: new settable minimums were needed because gold could be -40 (thereabouts). Using this value makes accurate settings difficult. Changing the upper limit to +10 helps but it is still tricky to set accurately. There is plenty of real estate in the presets name panel to reallocate space. As an additional suggestion: allow individual minimums, Many of these can never be less than zero, others typically quite modest negatives. Only gold has the extreme. Another solution would be to have a button for each slider to say 'no minimum'; this would allow the minimum settings to be reduced to small values such as five.

19. Initial dialogue box sizes.
19a. City dialogue box is not quite big enough (vertically) to hold sprites for units in both rows. (I am using solid bg color). It adjusts its size when you have units in both rows.
19b. Unit selection DB another chronic example.
19c. Main window - tab line too small to accommodate the new tab close icon.

20. Indexing menu items can be difficult. I often have to overshoot to the next item and then backtrack.

21. Black on dark green, white on light grey. If I tilt the screen just so, and lean in this much, I can still read it. Nice try but no cigar.

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

Re: R.I.P Not responding.

Postby nef » Tue Nov 20, 2018 2:01 pm

Civ1 ruleset.

22. Lies, lies, lies.

22a. (Isaac Newtons help text) "Boosts science production by 100% in the city where it is built." Ruleset only applies the benefit to libraries & universties and only increases the benefit of each from 50% to 100%. Wiki text is ambiguous in terms of magnitude (refers to 2/3rds increase but I don't trust the obvious interpretation. Someone who knows could clarify this.)
22b. (Copernicus observatory help text) "Boosts science production by 50% in the city where it is built". Ruleset increases value by 100%. Applies to citizens, libraries, and universities. (The two wonders do not compound). Wiki text suggests ruleset is correct.
22c. Help text for mysticism says "Improves the effect of temples" - could be specific without any great drama. (e.g. "Doubles the effect of temples.")
22d. "City Walls make it easier to defend a city. They triple the defense\
strength of units within the city against land, sea, and helicopter\
units. They are ineffective against non-helicopter airborne units as well\
as Artillery."

Civ I used the attack value of 12 to define igwall. That is: bombers and artillery only (i.e. not fighters). Civ I HAS NO HELICOPTERS!

These errors are a demonstration of the perils of not using auto generated help. MARK MY WORDS: this will get worse as AGH falls away into oblivion.

22e. (courthouse help text) "Reduces the corruption in a city by 50%.". Not so, increases nett trade from zero to one in far flung cities under despotism even if gross trade is double digit. (N.B. wiki, help text, ruleset, and my own recollection are in agreement on this one so I think there may be a problem with the order of evaluation of the three effects : "Output_Waste", "Output_Waste_By_Distance", and "Output_Waste_Pct".) Note in particular that the civilopedia expressly identifies far flung cities as being the reason for having a courthouse.


23. nreqs predicates (x5) for hoover dam have incorrect range (should be "continent" not "player"). reqs predicates are correct (with "continent").

Next week: even less important matters.

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

Re: R.I.P Not responding.

Postby nef » Mon Nov 26, 2018 1:02 pm

First some amendments to previous posts

15. Closer inspection shows that the north sprite is too short, AND the south sprite is too long. Also the e <-> w sprites don't meet.


22d. I now notice that the ruleset is also wrong. Accordingly, this problem should have been also posted elsewhere.

22f. help text on barracks (I, II & III)
"With a Barracks, each new unit built in a city will\
automatically have Veteran status, which means that its attack and\
defense strengths are increased by 50%. Also, damaged units\
which stay in town for one full turn without moving are completely\
restored.\" Notice the last sentence is gratuitous in civ1 (and Civ I), again illustrating the consequence of not using AGH.

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

Re: R.I.P Not responding.

Postby nef » Mon Nov 26, 2018 2:32 pm

24. The fist showing city riot (in a foreign city) is typically not shown until there is some GUI activity on the tile. This includes something simple like clicking on the tile or something a little more subtle like changing the visibility count (from some +ve value so visibility is already extant).

25. Sentried units do not wakeup when there is a visible attack with no preliminary movement e.g. barbs already adjacent attacking the city in which the sentry is located.

26. The CMA often does not recalculate tile allocation when a new martial law unit is moved into the city. I have not yet noticed any particular precondition.

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

Re: R.I.P Not responding.

Postby nef » Mon Nov 26, 2018 2:38 pm

Client/server issues.

27. Not changing the default value of "Handicapped" (in the start up window) results in the real default value of "Easy".


28. The *saved* server options are not honored if you change the ruleset to something other than the "default". The client loses, and does not reload these options when you load any other ruleset. "Refresh" does not help in this case. This has been complained about before but obviously nothing has been done. This is a straightforward bug but it raises additional issues as to creating multiple save sets e.g. for different rulesets and/or scenarios. One might even like to be able to name additional variants. All this can be done outside fc, but it would be so much easier if the fc client supported at least some of this. So for example, in addition to fixing the 'bug by omission' one could at least have the option to tell the client that you want a new default ruleset. The same could be done for difficulty level. [A simple 'Save Choice' button which creates new entries in the save file:

[Choices]
default_ruleset="<ruleset_directory>"
default_level="<difficulty_level>"

These could have default values e.g. "Default" and "Handicapped" in the event that "Save Choice" is not elected. Note that the [Server} section would need to be removed and placed into separate
files (perhaps named as <ruleset_directory>.choice), or, alternatively have individual sections named (such) as [<ruleset_directory>]. Either could be generalised to be "Choice_name" rather than just <ruleset_directory>.

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

Re: R.I.P Not responding.

Postby nef » Mon Nov 26, 2018 4:02 pm

edit typo 31c ->30c

29. Server help for difficulty levels.

29a. No reference to AI knowing what's in foreign cities (i.e. defenders and buildings)
29b. No reference to AI buy costs.
29c. List of attributes could be (i) simplified to remove redundancies, (ii) presented in a uniform order. E.g. "/help hard" (and "Cheating") list three separate "reveal map at game start" and they are not in sequence, while at the same time not mentioning 29a or 29b. Compare this with "Normal", "Easy" and "Novice" which all list "reveal map" once only.

A number of these 'features' are softcoded so why are they still present in hard code???
(iii) "Can skip anarchy during revolution" ("No_Anarchy")
(iv) Has complete map knowledge (&friends) ("Reveal_Map")
(v) "Research takes 250% as long as usual" ("Tech_Cost_Factor")
(vi) "Has no restrictions on tax rates" ("Max_Rates")
- ai_effects.ruleset actually uses this one for cheating!!!

Also
(vii) what does "limits growth to match human players" mean?
(viii) "Always offers cease-fire on first contact" - absence of this (for hard/cheating) appears to be a gratuitous 'gotcha'. All games I have played so far the AI accepts a ceasefire on first contact - what is the difference?.
(ix) I suspect "Doesn't build air units" could also be implemented but I am too lazy at this time of night to check.

30. What is the protocol for reporting (potential) issues with nation ruleset files:
30a. Duplicate city names? e.g. Korean: Chonju/Chongju
30b. Cities that should have geographic attributes e.g. english *ford, *_on_*, *bridge, *mouth should all be on a river.
30c. Back in the days of fc2.4.4 playing english I was attacked by myself (slight variations on the name Boadicea).


Next week: dregs.

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

Re: R.I.P Not responding.

Postby nef » Mon Dec 03, 2018 12:42 pm

addendum to 22:

22g. civ1 help text for river states:
"Any land terrain type may have a River on it.\" Another example of what happens when you don't (or can't) use AGH. The ruleset is correct: grassland is the only terrain with the flag "CanHaveRiver"



31. There are times when inspect city (incl dbl click) is not active when a city is mentioned in a message e.g. when the city has just been captured. Go to location works OK.

32. Not enough space in city map to show the activity sprite for the top row of tiles.

33a. When active the turn done button does not light up (grey down!) until the mouse has hovered over it. That means that to see any indication that the turn is ready one must continually poll the button (that is move the mouse on and off to test if the turn is ready).
33b. Change production in production tab (city dialogue) sometimes does not change the icon/text in target worklist panel. This appears to be a reversal of the behaviour in fc2.5- where it was the progress bar text that was not changed.
33c. When an item is "moved" to target worklist the source tasks list is readjusted so that the indexed item is at the top of the list. It would be better if the list didn't move so that one can be ready to make the next selection.
33d. Some button changes are erratic. For example the gutter buttons have two features when pressed (i) a rounded box , and (ii) a blue shaded background. The latter is sometimes not displayed. And yes I know this is trivia but it is indicative of deeper problems.

I like the new buttons in the gutter. When adding an item to the target worklist (in the production tab of the city dialogue) the focus could be left on the added item so that it can be moved about more easily. Also "Change Production" could become another button at the top of the list (perhaps better would be to (ex)change entries that are highlighted in both lists).

34. When terrain with a river is transformed into terrain that does not allow river the river is destroyed creating segments that could be landlocked. In Civ I (where this is an issue) the problem presumably is prevented because grassland with river is actually a different terrain type. I don't think I ever tried to transform it into forest but my guess is is that the transform was not allowed).


That's it for now. For those who haven't noticed this is my first (and so far only) "New Topic", so

Next week: back to my opportunistic use of "Reply".

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

Re: R.I.P Not responding.

Postby nef » Tue Dec 18, 2018 1:08 pm

35. In terrain.ruleset for [Extra_*], the comments read:

Code: Select all

; category                = How UI should categorize this extra. One of
;                           "Infra", "Natural", "Nuisance", or "Bonus"
NQR.

This is more than just a documentation problem. My (superficial) assessment is as follows:

A. A 'hut entered' process is started if a unit moves to a tile that contains an extra with causes = "Hut". Subject to unitclass we then continue -

B. FOR EACH extra with category "Bonus" (hence the NQR above) the server:
i. removes the extra,
ii. calls any Lua functions that are connected to the signal "hut_enter".

Note that the two criteria (for (A) and (B)) are different, when one should expect them to be identical.

A quick demonstration can be had by (re)starting a game that has the ruins (and hut) extras in the ruleset. Use the editor to place both on a tile next to an unsuspecting unit. Return to the game and move said unsuspecting unit to the tile. Check messages - you will notice that you get two lots of goodies and both ruins and hut will have disappeared. (If you get vaporised by barbs you might need to try again.)

The code should be easy to spot. I expect it to look like (or have the effect of) a nested sequence of

Code: Select all

iterate extra,
   if cause == "Hut",
       {   iterate extra,
                   if category == "Bonus"  {remove_extra; signal "hut_enter"} 
            break (outer iterate)
       }
The replacement code could be

Code: Select all

iterate extra,
   if cause == "Hut" && category == "Bonus"
        {remove_extra; signal "hut_enter"}


It would be helpful if the exact criteria used for "hut_enter" was defined and documented. Also, there is an opportunity here to soften more code such as in B.i. (remove_extra), and the choices defined by the unitclass field "hut_behavior". These changes could be introduced gracefully i.e add global data and parameters relevant to the Lua callback first, add the extra code to the Lua, and then sometime later rely on the callback to do the extra work. A 'fringe benefit' of this would be to let the Lua code apply additional criteria - even, for example, catering for different types of 'hut'.

Ignatus
Hardened
Posts: 230
Joined: Mon Nov 06, 2017 12:05 pm
Location: St.Petersburg, Russia
Contact:

Re: R.I.P Not responding.

Postby Ignatus » Fri Dec 21, 2018 6:16 am

The huts issue is resolved for 2.6.1: HRM#782719. For 3.0 there should be some support for different hut types:HRM#780730.

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

Re: R.I.P Not responding.

Postby nef » Mon Feb 04, 2019 4:49 pm

Sorry for the delay in responding - I have been distracted by matters civ1.

I am humbled (or is that humiliated) by the prescience.


Actually it was part of my plan to discover extant fixes - that's my story and I am sticking to it. LOOKS GOOD - should hit the nail on the head.

In any event my thanks to Ignatus for the advice.

On my TODO list was to suggest changes to the Lua interface to allow for the Lua script to tell the AI (and AGH) about what it could/would do when callbacks were called back.

Hard code is always going to be at a disadvantage so the ultimate solution is to soften the AI code but this looks distant just now (but not out of the question - high level activities in fc could ALL be moved to Lua - in effect inverting the current control structure ). For now we need to be content with just advising the AI of potentialities. The example I read in HRM

Code: Select all

2. Some hints for AIs and autotasks about different bonuses value "even normal hut is better not to be enteted if bulbs are low and freetech fine is high); "
was about the outcome of hut entry, but it was not clear to me that there are any plans for fc3.x code. If this is right then perhaps a little nudge might help. So I make the following suggestion:

Provide a global table (and/or c function call) that contains the data that the AI may find useful. In the present (fc3.x) case this could be
    (i) a table of "extra"s with cause ="hut" (or now for fc3.x rmcause = "enter"), indexed by rule_name; and for each field in this table
    (ii) an array indexed by outcome with fields specifying the probability mass distribution.
The AI could then make an informed choice on whether to risk an entry. Moreover, one could sometime reverse the direction of communication. E.g. one could have the ruleset (and/or server options) specify these values and then the Lua script would just FOLLOW the prescription. In fact, this would be the case for the unitclass flag (in fc3.x) if one wanted the Lua to handle "frighten" - or even "nothing".

The key interface table could look like (for a single hut type environment such as fc2.6.x)

Code: Select all

hut.default  =  {gold_25 = 1, gold_50 = 3, gold_100 = 1, technology = 3,
                       mercenary = 2, barbarians = 1, city = 1,
                 }


To get this ball rolling all that is needed is to provide the c - Lua interface for (the array of) hut(s), and to provide the save/restore mechanism for data generated by the server (if/when needed). Code cutters could then get to work on AI as/when they please. To help this along I have already recoded default/default.lua:

default.txt
(10.32 KiB) Downloaded 37 times
H:\PortableApps\FreecivPortable\App\Freeciv\data\default\default.txt

(Only the hut enter parts have been changed - so if you are worried you can cut and paste.)

    This code works "AS IS" in fc2.6.0!!! So it could be used as a replacement right now.
    A bug fix comes for free and so it should be used as a replacement right now(ish).
    Fixes the abuse of "type".
    The server could now access the profile (via the global table "hut") - just needs someone to cut the c code. The Lua code has been written to accommodate server originated changes to the data (at any time after the Lua script has run - i.e - once "hut" has been created).
    Only written for current "hut_enter" call back. The new callback in fc3.x allowing multiple types of hut will need new coding. If the same callback is used with a new parameter ("extra"???) that will be nil in fc2.6.1, then I could add the new Lua code now and get it over with.


If someone can help me out with naming conventions (notably case), I can edit the attachment and resubmit.