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

Re: R.I.P Not responding.

Post 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.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post 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"?
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post 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%.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post 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.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post 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.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post 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.
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: R.I.P Not responding.

Post by cazfi »

nef wrote: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.
AlwaysOnCityCenter overrides even the fact that extra is not buildable. Obviously something that is not buildable is not Autobuilt.

That AlwaysOnCityCenter is stronger statement than buildable=FALSE is problematic, but that's the set of problems we've selected instead of those problems that we would have with buildable=FALSE being the stronger statement. Should be better documented, of course.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post by nef »

Obviously something that is not buildable is not Autobuilt.
Not obvious to me.

Seems to me that if you don't want something to be autobuilt then the easiest thing to do is to not ask for it. The interference between features is gratuitous (i.e. UNNECESSARY) and just creates problems without adding anything to the ruleset language.

The key point I am trying to make is that there should be NO issue over whether this or that is stronger when the simpler thing to do is make them independent of each other. I.e. in this case define "Buildable = ..." as a feature applying to discretionary unit activity (e.g. settlers being given an order) and the "...OnCityCenter" features being implicit, happening on account of circumstance. I see no need to conflate the two basic principles. If they were separate there would be no "set of problems". One could choose whatever combination you want.
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: R.I.P Not responding.

Post by cazfi »

The features have also purpose. While it would definitely be easier to implement "Auto..." as an alias to "Always...", neither being subject to buildability limitations, that would quite defy the purposes of having them separate.
I have to admit that purpose of the buildable is not well documented (Feature #821817 should help a bit), its purpose too would be defied if suddenly Autobuild would be able to build such extras. Ruleset author has been given power to define buildable=FALSE for limiting extras in scenarios to pre-placed (in the editor) ones only.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post by nef »

While it would definitely be easier to implement "Auto..." as an alias to "Always...", neither being subject to buildability limitations, that would quite defy the purposes of having them separate.
Not sure I quite understand this (or perhaps I was not understood). I was not trying to say that "Auto.." and "Always... " were one but rather that they should belong to the same class. Is the distinction you are trying to make is that "Always.." should be different to "Auto.." that happens to have no requirements? Is there a distro ruleset that has one of these? (Unlikely - this would be entirely presumptive on what a scenario maker may want.) Would a scenario author need this? My answer would be no.
... its purpose too would be defied if suddenly Autobuild would be able to build such extras. Ruleset author has been given power to define buildable=FALSE for limiting extras in scenarios to pre-placed (in the editor) ones only.
I gather from this that you had in mind some way of providing a facility for scenario makers to defeat the "...OnCityCenter" options but to be honest I don't understand the issue. If the ruleset is written with buildable = FALSE then it can also be NOT written with "...OnCityCenter". In the end, I don't actually see what it has to do with scenarios - they either use a stock standard ruleset or they don't. In the latter case they can choose what they choose - but only if the features are independent. The way it is at the moment they are denied one of the combinations (as it was with me trying to fix the civ1 ruleset).

[As an aside here I might add that it is not just scenarios. You may have noticed that I have been using Lua for a similar purpose and it is in fact the very reason why I identified the problem - I was denied the combination that I needed.]
Post Reply