forum.freeciv.org

Have NO fear: fciv will never be able to "emulate" other civ fully...

As you say memory can play tricks, but I am heartened somewhat by finding many (but obviously not all) of mine confirmed in other fora, and of course by your own sterling work.

Mostly I used to play on a '386 with VGA but I have been known to use a '286 with EGA. Both of these may be still around somewhere but I am unlikely to find them in a hurry.

As for fidelity to Civ I (and II) fc has a LONG way to go. So far in this thread I have only discussed those issues that I can fix with the materials in the distro .... . One clear advantage is that the fixes can be applied immediately and do not need to wait for any release cycle. (This is also meant to be a not so subtle hint.) I still have (and continue to get) more in the pipeline, so it will be business as usual for some weeks to come. And then, of course, there cometh fc3.0.

nef wrote:As you say memory can play tricks, but I am heartened somewhat by finding many (but obviously not all) of mine confirmed in other fora, and of course by your own sterling work.

And these other fora do confirm a random behavior ? Maybe you could provide some links then.

nef wrote:Mostly I used to play on a '386 with VGA but I have been known to use a '286 with EGA. Both of these may be still around somewhere but I am unlikely to find them in a hurry.

They're not needed, you can use Dosbox. The most difficult thing to find is the game itself.
(And don't count on me to provide it, i'm using Amiga version of the game thru Winuae.)

And these other fora do confirm a random behavior ?

In this case, yes and no. As I said there was general confusion over the issue. As for links - I didn't keep them - because the comments were inconclusive. Mostly my comment was about points that I had commented on here before reading them in the fora.

They're not needed, you can use Dosbox.

I have downloaded Dosbox for this very purpose but as you say I would still need the game itself and getting onto my laptop may be not so easy.

While rumaging through the online fora I discovered that the 'home ownership' issue was just the tip of the iceberg for two reasons:

A. It applies to all manner of new units for Civ I & II.

B. The civ1 hut enter profile is all wrong.

I can't do much about (A.) but I can fix (B.).

Initially, I wrote a special version of the (default) default.lua hut entry code for the civ1 script.lua, but in the end I figured that so much code was common I decided to turn the default code into an engine in its own right. The result was more code than I would like for a dynamically typed language, but I have compartmentalised as best I can.

Here is the new version of (default) default.lua:

Although it keeps to the theme of my original, it has been rewritten to be a general purpose engine for hut entry code in rulesets. I have abandoned trying to second guess the interface to the AI, but that should not be too difficult to retrofit when (or if) the time comes.

For civ1 the following is an INSERT into the (civ1) script.lua:

For those who want to write (or rewrite) their own hut entry code (for their choice of ruleset), I can offer the following comments:

The programmability is tailored to various levels of Lua fluency.

1. Simple changes to the profile best explained with two examples.

For the stock standard fc default we require only the following code:

For a complete list of MPFs available see the subtable MPF in default.lua. (Also you could copy/paste the three civ1 MPFs.)

By way of contrast the code needed for civ1 is

This example also shows the second and third tiers.

2. Options.

There are a small number of options which can be elected. In civ1, for example, I have specified that units should be homed to the nearest city (as per my previous change). Also, for hut outcome purposes being 'near' to a city is now defined as it is in Civ I & II.

3. New probability mass point action functions.

In the civ1 example above you can see that there are three functions all defined locally. The most complex of these is

As it happens, all three can actually be coded quite easily 'inline' in the function _deflua_hut_ruleset_context but I separated them out for readability reasons. If included inline then the only changes to the (civ1) script.lua would be this function (_deflua_hut_ruleset_context ), plus the minor support table civ1_good_site. Elsewhere I will provide an example where code is included inline.

D. Fundamental changes to the engine.

I have done my best to avoid the need for this, but who knows?

Ever noticed that in the beginning of a game you only ever get legion and never calvary (= horsemen) even though both are marked with the role "hut". The answer is that the only facility in Lua is find.role_unit_type. Now this may work 'well enough' for "HutTech", but it is manifestly inadequate for "Hut" since in this case only the first unit found in units.ruleset will ever be used. To solve this problem I have developed the following 'work around'.

In the section [unit_legion] civ1 units.ruleset add the following FLAG
In the section [unit_calvary] (civ1) add the following FLAG For civ2 and other rulesets the section will be [unit_horsemen].

Add BOTH of these to the user defined flags in the vector field in section [control] as follows:
If you want more you can add new flags but the numbering must be contiguous (as used - not just defined). But note, there is a severe limit to how many fc will let you have.

Now to make this do anything useful you need to have some Lua code in the hut enter MPFs in default.lua. As it happens, I have already surreptitiously slipped this in.

I will repeat that this is a work-around and needs to be replaced by something more permanent. However, the only downside at present is that the flag "Hut0" is reserved and should not be used for any other purpose. (To be more precise there must be a break in the sequence.)

IIRC the entering unit may die without a chance to fight if unleashing barbarians (something to do with tile:unleash_barbarians).
Can your custom hut entering script prevent this ?

the entering unit may die without a chance to fight if unleashing barbarians (something to do with tile:unleash_barbarians).

Recently looked more closely at this. It appears to be decided by the server option specifying the curfew (i.e. barbs do not appear before ... - or something like that). So the simple answer is to set it to zero. In fact I believe that is actually the case for Civ I (and II). I have inferred that the fc reasoning was that to implement the curfew one simply had to prevent barb players from being created while the curfew was in effect. No player -> no units. So to implement hut barbs before the curfew was lifted they resorted to the hack of just vaporising your unit. My recollection from the fora was that in Civ II there was some sort of algorithm to specify which turns (or years) the barbs could/would be spawned and this implied a small number of turns at the start. I am not aware of a similar analysis for Civ I.

Having barbs spawn early is BAD NEWS for the AI. Things may have changed, but back in the days of fc2.4.4 I messed about with this option and discovered a critical threshold of 30 turns +/- 5 where the difference meant all AIs dying (<25t) to all surviving (>35t).

So the not so simple answer is no. The problem being that there is no control (from Lua) for the barbs that spawn spontaneously. Having said that, I think it may be possible to tell the server to not spawn barbs at all (i.e. no barbs). The implication from the hut enter code is that this does not stop Lua from creating them. Your question has just promoted a project that was far down on my list. But a) it is non trvial, and b) only just been made feasible by (a feature in) another project I am redacting; c) not yet proven - i.e still some loose ends to test; d) has a secondary benefit of having barbs act more like those in Civ I & II. (In fact, this was my objective - but I now have two.)

Sveinung, where have you been? I have been waiting so long for those extra points you promised.

nef wrote:Sveinung, where have you been? I have been waiting so long for those extra points you promised.

Wow! Do you know how much of this is fixed in Freeciv already?

There have been some changes since 2015. We use Hosted Redmine for bug tracking and Git for version control. The fact that we now use Git means that it is possible to give you, rather than the developer adding your patch to Freeciv, the author credit.

Do you know how to use git and git format-patch? If not I can teach you. That way you can send each fix as a patch that automatically assigns the author credit to you. Based on how many bugs you have found I estimate that there will be enough patches to make learning a bit git to get the machine readable author credit correct worth it for you.