forum.freeciv.org

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".

35. In terrain.ruleset for [Extra_*], the comments read: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 The replacement code could be 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'.

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.

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 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) 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:
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.

36. Two deflua "hut enter" problems referred to (plus another):

36a. There is no consolation prize for no tech. No drama so don't panic.

36b. "type" is a Lua function of some value to a programmer. The abuse of "type" such as in _deflua_hut_get_mercenaries and _deflua_hut_get_barbarians should be deprecated.

36c. Also, while testing I noticed that "random" returns values that are still float not integer as is now possible in the current release of Lua. This causes no obvious problems in the Lua script itself, but it may indicate that the time has come to take a look. I notice that in civ2civ3 the usual paradigm is to use random (1,100). Is this just personal preference or was there more significance to this choice?


An oversight; add to my list of talking points:

• Various flavors of "nothing", "frighten" or "normal" could have individual profiles based on "unit" - not just unit type. In particular, you could use user or system defined unit flags, other aspects of the unit or unit class (such as rule_name). Local/nearby terrain, extras etc., presence and details of units nearby. I could even provide code for multiple hut types (right now in fc2.6.0). Piece of cake to change the code to suit whatever you want. Ask if you have an idea but are not completely confident as to coding.

37. More on [extra_*] etc.

a. Can extra be built? I would have never guessed! Meanwhile there is some hidden black magic hard code going on here. If this had been properly documented it would have saved me some time. More importantly, it may have prevented a bug from being written in the first place. [Probably introduced in fc2.5]

The problem is that 'buildable = FALSE' gratuitously blocks "AutoOnCityCenter". I can see no reason why this should not be the same as for "AlwaysOnCityCenter" - i.e. no effect.

b. Various fields in [road_*] can be set to negative values but these and derived values are sent to the client as 16 bit unsigned. The server issues a warning, the client displays assorted incorrect values. Known examples: Note that *_bonus is a pct bonus and there has been a tradition to allow -ve values that are >= -100, but they fail here (when sent to the client). Others should be allowed to be negative: clipping at zero should be left to the last possible calculation.


c. Terrain road extra move mode. The documentation states: This appears to be NQR. Is this the only reason for mapgen to generate cardinal river systems? Or is it still hardcoded? In any event, the definition is too narrow: triremes can enter/leave river systems from corner connected sea tiles. Is it time to change the definition to mean 'movement allowed'? Also is it time to retire (or deprecate) "Relaxed"?

38. Swings and Roundabouts

Swings:

Items (0, 1, 2) are still present but the incidence/severity has been reduced. Battle animations, in particular, seem to be almost normal (unless rudely interrupted by a caravan pop up). Chiefs still hang around (but this may not be such a bad thing.)

On the subject of chiefs I can answer my own question (1b)- the residual chief appears to be a blend of all those chiefs that were, or would have been, shown as the unit loses HP during the attack.

Item 3 is the big change - although still a little sluggish it is more or less acceptable (and arguably much better than GTK 2.0).

Item 19: The USDB now starts wider so it is much less likely to expand off the RH edge of the screen. So far I have not seen any occasion where it needed to expand.

Item 20: Menu items are now well spaced - perhaps even a little generous.

Item 21: The new color scheme is much better. But see new item (e).

Item 32: the close buttons on the tab line are now back to normal size.

Roundabouts

a. City DB often opens with extension off the RH edge of screen - I presume this is due to the new resizing paradigm. Vertical size of city db still not enough for both row of units.

b. When using drag and drop to move items in the city's TODO list the client usually crashes. I suspect this was extant in the previous version of GTK (for fc 2.6.0) but was not so apparent (i.e. usually did NOT crash).

c. CMA sliders are even harder to use.

d. Hitting the "X" close box often results in window movement cursor instead.

e. As shipped (?) the font size for text (chat, message, white parts of help), suggested a reprise of "If I tilt the screen just so, and lean in this much, I can still read it." A quick tour of Game -> Options -> Local Client -> Font required (but can find no entry for the chat file).

f. Hard to select 100% (or 0%) on the tax sliders - I usually end up with 90%.

39. More documentation problems in terrain.ruleset:

a. NQR: "None" is also valid. Should have additional cooment: b. [terrain_*] is inconsistent with [extra_#]

"; if 0, cannot #" is historical baggage. Replace with "; if 0 (and/or extra's build_time_factor is 0), and extra's build_time is 0 then cannot #" - plus other variations e.g. build -> removal; # = {base, road, irrigation, mining; transform is ok.}


Also does "Value of 0 (default) means that terrain- and build activity specific time ..." mean for example "Value of 0 (default) means mining_time in the terrain section multiplied by build_time_factor ..."?

The same comments apply to removal times and other activities (# as above).

Quick question - why the gymnastics? How about the algebraic "Total mining time = build_time + mining_time * build_time_factor"? If the result is zero then cannot build the extra on the terrain." [In fact, why persist with this restriction? - "buildable = FALSE" is universal (or should be once the bug is fixed)]. I believe civ2civ3 would cope just fine (with the algebra) with +2 LoC (build_time_factor = 0 for both railroad and maglev).

c. rmact_gfx is not used for pillage - presumably the tag for 'Pg' is hardcoded - was this something that 'slipped through the cracks'?


d. [chronic] - "build the extra" is NQR. There is black magic hard code deciding which predicates relate to creation, and which relate to existence, and these are not documented.

e. [units_*]unit flags Does this include mining, build bases?

f. Closer inspection of comments in terrain.ruleset reveal the following Something got half baked here. I could find no use of rmreqs in fc 2.6 rulesets. There is a clear ambiguity in the semantics of the reqs vector - some predicates refer to the creation while others refer to the existence. The latter could be handled by "conflicts" but currently the city center is not a valid 'extra'. This is, and has been, a serious omission that could be simply solved - demand a (hidden?) extra that is 'always on' city center. This could then be referenced by (or could use) the conflicts field. There are a number of features of city centers that could be softcoded in the extra's definition. In additon to "conflicts", we could have "native_to" and various flags such as "NativeTile" and "Refuel" (extra) and "ParadropFrom" (base). Doing all this would allow ruleset authors to deny these features as default city attributes (thus forcing for example the building of a airport for aircraft).

Even better would be to add a [City] section as another "Causes =". Somewhere down the track this could be extended to [City_*] which would allow for features such as Civ III colonies.

40. Disasters.

The presence of buildings as predicates in [disaster_*] rules are assessed perversely when displaying buildings as being redundant. E.g with the great wall, city walls are deemed redundant if the city is on/near a river, but NOT otherwise. I believe the distinction is because of the risk of flooding as per section [disaster_flood]: in the civ1 ruleset.

41. Some problems with startup error messages:

a. If "rmact_gfx = " is missing the start up error message reports that the tags "-" are wrong: ("Hydro" was the [terrain.*] rule_name). Note that the 'omission' (of the field) is a ruleset problem. A better fix for this is to just make the field default to "None", which, although undocumented, works just fine.

b. Similar comment for missing "activity_gfx" (removal -> building)

c. For "graphic =" the error is This one fails to mention the name of the extra. Comments for (a) also apply here as well.


The graphic 'alt'`s in all three cases default to "-" and play no part in any of these errors. The fact that they are optional could be documented - it would save a lot of crap in the ruleset files.