things i'd like to be implemented

What would you like to see in Freeciv? Do you have a good idea what should be improved or how?
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: things i'd like to be implemented

Post by nef »

Don't forget culture - should be included if culture victory is enabled.
Converse case; not provided in the intelligence report but IS in tolua. I might sometime check on the need for embassy for client console (or even if it works there), but it works in server scripts (albeit with a one turn delay). You could easily modify the techtrade script to report this.

cazfi wrote:Yeah, I think the "default specialist" has meaning only in the case where there is no more space for additional worker when the city grows.
Sounds more likely now that you mention it. Next game I finish I will check it out. If true, A. is the only one relevant (back to what yuh said).
cazfi
Elite
Posts: 3069
Joined: Tue Jan 29, 2013 6:54 pm

Re: things i'd like to be implemented

Post by cazfi »

nef wrote:
Don't forget culture - should be included if culture victory is enabled.
Converse case; not provided in the intelligence report but IS in tolua. I might sometime check on the need for embassy for client console (or even if it works there), but it works in server scripts (albeit with a one turn delay). You could easily modify the techtrade script to report this.
Lua API should have a warning about the fact that in client side it will almost always get a wrong value as it computes it from the client's knowledge.

Inteldialog on the other hand shows correct value as sent by the server, when there's an embassy.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: things i'd like to be implemented

Post by nef »

nef wrote: C. The script does not identify those tech that can not be traded (e.g. on account of root_req`s). From practical experience I find it not too difficult to make mental adjustments. ....
I have to eat my words.

The civ1 ruleset I am using has a heap of root_reqs techs, AND I found the techtrade script to be really useful. The problem got too much for me so I modified the script to not count these techs. The changes needed will be peculiar to particular circumstances, but the code is straightforward and changes should not be difficult.

Thank you yuh for a brilliant idea. The script is now a regular feature in my client Lua console (along with ukd).
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: things i'd like to be implemented

Post by nef »

nef wrote:
cazfi wrote:Yeah, I think the "default specialist" has meaning only in the case where there is no more space for additional worker when the city grows.
Sounds more likely now that you mention it. Next game I finish I will check it out. ....
Short answer: No.

Longer answer: I tested a city that was working all available tiles (and no specialists). When it grew the new citizen was a scientist (not the entertainer selected on the summary page). But there was also something else: one of the existing tile workers was lifted from a poor performing tile and was also turned into a scientist. It appears to me that the 'default' CMA is trying to guess what an AI would want. Moreover, I would think that this re-evaluation is responsible for tiles being given away to nearby cities - a right royal nuisance if the city is not yours'
cazfi
Elite
Posts: 3069
Joined: Tue Jan 29, 2013 6:54 pm

Re: things i'd like to be implemented

Post by cazfi »

nef wrote:tiles being given away to nearby cities - a right royal nuisance if the city is not yours'
Another reason why I'm starting to think maybe we should completely drop the support for playing without borders. Yes, that would lose some civ1 compatibility but currently borderless mode is practically unmaintained code with issues accumulating (there's an increasing number of rules "within ones borders" and similar language where nobody knows what happens in borderless mode)
Ignatus
Elite
Posts: 644
Joined: Mon Nov 06, 2017 12:05 pm
Location: St.Petersburg, Russia
Contact:

Re: things i'd like to be implemented

Post by Ignatus »

cazfi wrote:
nef wrote:tiles being given away to nearby cities - a right royal nuisance if the city is not yours'
Another reason why I'm starting to think maybe we should completely drop the support for playing without borders.
I don't think it should be done. Even in modes with borders there are unclaimed tiles cities compete for (especially oceanic ones) that should be supported; and I have never seen real issues with bordedless mode. Maybe it should be just a disabled setting in some rulesets that highly rely on borders.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: things i'd like to be implemented

Post by nef »

Do I recall a discussion about tile pinning? It seems to me that this would be a reasonable solution to the tile stealing problem, the uplift problem and several more that I can think of.

As for borders I see this as a second attempt to 'get around' an AI problem: this being the relentless desire to build more cities. This problem is bigger, MUCH bigger, than the border issue so fixing this AI problem would provide several additional benefits.

1. It would reduce, or even remove, the need for rulesets to use citymindist (other than 1). There ARE reasons why you sometimes want to build a city close to another. But the AI with citymindist of 1 (e.g. civ1) goes bananas with it often creating large chains of maybe even a dozen cities (often at least three), thereby creating an exploit (win one and the rest are easy pickings).

2. It would (or could) stop the AI over extending. It IS possible to build too many cities (in fc). The mistake someone has made here is that the name of the game is NOT to maximise the city centre freebies, but instead, it is to maximise the number of tiles worked. This is, in fact, a QUADRATIC function of number of cities and therefore has an optimal number of cities (but note, that number depends on government and a few other issues such as JSB`s cath.) In addition to the wrong objective, overextending causes a delay in development often resulting in the AI being stuck in despotism, sometimes even to the end of the game. (I should speak!!! - I always choose to stay in despotism but that`s to capitalise on that other big AI problem: obsession with democracy.)

3. It would reduce (or stop) AI`s canabalising the territory of allies, this problem likely the reason for citymindist and borders.
Ignatus
Elite
Posts: 644
Joined: Mon Nov 06, 2017 12:05 pm
Location: St.Petersburg, Russia
Contact:

Re: things i'd like to be implemented

Post by Ignatus »

nef wrote:As for borders I see this as a second attempt to 'get around' an AI problem: this being the relentless desire to build more cities. This problem is bigger, MUCH bigger, than the border issue so fixing this AI problem would provide several additional benefits.
Well, if AI plays better with building more cities (since this strategy is stupid and a more clever one it just can't do), why it should not? Commercial games with more "human-like" AI empire development tend to have sizeable citymindist.

Well, the AI's inability to look ahead makes it to follow a way of territory usage that gives good immediate result and dubiously good in the future, that is what is smallpox in its AI variant. But the reasoning "on this tile we can put a city and grow it large, we won't put cities on nearby tiles except this grassland one a bit later to puff the megapolis with immigrants, and the closest city we'll put so that their working radii only slightly overlap on maximal growth, and on this tile we put a city just as a very necessary seagate..." is pretty difficult to code, are you ready to do it?
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: things i'd like to be implemented

Post by nef »

is pretty difficult to code
Sid managed to do it in 640k. But to be fair he had only one ruleset to consider.
are you ready to do it?
If I can write agents and advisors in Lua. The point being that one can customise the code for different rulesets. (The very reason for scripting.)

We could start by developing tolua interfaces for (AI) hut enter, Auto settler, auto eXplore, Goto, and goTo. eXplore would be a good place to start because it would be easy and have a huge payoff.

Selecting suitable sites for cities is not such a big deal - I do it all the time with a simple analysis of surrounding tiles. Can code do as well as a human? Maybe not but it can come close - Sid proved that.

Choosing a time to consolidate? This is just a numbers game. Six cities with two or three large is usually enough.

I already have code to analyse the starting positions and the compensation needed to create reasonable equivalence so some times I have to make do (and win) with just three. In the opposite extreme (with plenty of territory) I never get enough time to fill it. Meanwhile the AI`s will build on every plains tile, most grassland, many desert, forest and hills; and even mountains if that means access to fish (suckers). These mountain cities are just waiting to be destroyed. All it needs is a boat to occupy the fish tile.

I don`t see a problem coding something better.

I might add one little comment about borders. Some of the cities stuff can be simplified if borders were always calculated but only enforced by option.
Ignatus
Elite
Posts: 644
Joined: Mon Nov 06, 2017 12:05 pm
Location: St.Petersburg, Russia
Contact:

Re: things i'd like to be implemented

Post by Ignatus »

nef wrote:
is pretty difficult to code
Sid managed to do it in 640k. But to be fair he had only one ruleset to consider.
are you ready to do it?
If I can write agents and advisors in Lua. The point being that one can customise the code for different rulesets. (The very reason for scripting.)

We could start by developing tolua interfaces for (AI) hut enter, Auto settler, auto eXplore, Goto, and goTo. eXplore would be a good place to start because it would be easy and have a huge payoff.
Hm, inserting some script controls into AI entrails seems not too difficult, the worst part is understanding what does it do now. The advisors usually have some mechanism to calculate "want" of actions (RCA-type AI), if you override C functions with a Lua callback at this point it's almost a one-liner. Just you better need some precalculations done by the advisor and scaling constants that should be interfaced into a more sizeable module. A bit more work is making several callbacks within these advisor's subguts and replacing some magic constants with Lua-controlled settings (again, before you have to grok out what do they do).
Post Reply