Page 3 of 3

Re: R.I.P Not responding.

Posted: Sun Feb 10, 2019 11:38 am
by nef
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.

Re: R.I.P Not responding.

Posted: Mon Feb 18, 2019 11:39 am
by nef
37. More on [extra_*] etc.

a.

Code: Select all

; buildable               = Can extra be built? Defaults to TRUE
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:

Code: Select all

shield_incr 
shield_bonus
shield_incr_const

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:

Code: Select all

; move_mode               = how movement costs are applied
;   - "Cardinal"   = Road cost applies only on cardinal moves

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

Re: R.I.P Not responding.

Posted: Mon Mar 11, 2019 11:47 am
by nef
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%.

Re: R.I.P Not responding.

Posted: Mon Mar 18, 2019 11:20 am
by nef
39. More documentation problems in terrain.ruleset:

a.

Code: Select all

; graphic                 = tag specifying preferred graphic
NQR: "None" is also valid. Should have additional cooment:

Code: Select all

;                           This can be "None" to indicate that a graphic
;                           is not needed.


b. [terrain_*]

Code: Select all

; #_time               = time for # activity; if 0, cannot #
;                        Nonzero values only affect extras with build_time 0.
;                        Such extras can modify time with build_time_factor.

is inconsistent with [extra_#]

Code: Select all

; build_time              = how long it takes a unit to build this extra.
;                           Value of 0 (default) means that terrain- and
;                           build activity specific time is used instead.


"; 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]

Code: Select all

; reqs                    = requirements to build the extra (see effects.ruleset
;                           and README.effects for help on requirements)
- "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

Code: Select all

; "Settlers"   = can irrigate and build roads
Does this include mining, build bases?

f. Closer inspection of comments in terrain.ruleset reveal the following

Code: Select all

; reqs                    = requirements to build the extra (see effects.ruleset
;                           and README.effects for help on requirements)
; rmreqs                  = requirements to remove the extra

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.

Re: R.I.P Not responding.

Posted: Mon Mar 25, 2019 1:38 pm
by nef
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]:

Code: Select all

name           = _("Flood")
reqs           =
    { "type", "name", "range", "present"
      "Extra", "River", "Adjacent", TRUE
      "Building", "City Walls", "City", FALSE
    }
frequency      = 10
effects        = "ReducePopulation"
in the civ1 ruleset.

Re: R.I.P Not responding.

Posted: Mon Apr 08, 2019 10:47 am
by nef
41. Some problems with startup error messages:

a. If "rmact_gfx = " is missing the start up error message reports that the tags "-" are wrong:

Code: Select all

Tileset problem, it's probably incompatible with the ruleset:
Missing Hydro removal activity sprite for tags "-" and alternative "-".
("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

Code: Select all

Tileset problem, it's probably incompatible with the ruleset:
No extrastyle for "-" or "-".
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.