Ancient era Wooden Watchtowers

[Thunderbrd]

In reply to the tile-distance between 'cities' Joseph mentioned- fort improvements cannot currently be built directly adjacent to another fort. However, their prior improvement the palisade (and the abatis) can be built directly adjacent to each other. In this manner, if you want to build a wall of defensive improvements across a passage wider than 1 square, or a canal across a 2-tile wide isthmus, you have to do it before discovering mathematics (or save gatherers, maybe?)

It seems rather backward that discovering a tech reduces defensive ability in this manner. Ideally, either A) the 'ability' of palisades to build directly adjacent to each other should be removed, or B) the enforced distancing of forts should be removed such that forts too can be built next to each other.

Spoiler Palisade/fort build restriction comparison :

View attachment 570874

The bActsAsCity tag on an improvement is what causes the forts to be required to maintain that distance and also is what allows the fort to act as a canal (though there is a new tag for that separately as you mentioned.) among other things, like act as an airport and so on.

The tower line of forts was supposed to be the fort type that did NOT act as a city. For some reason, most of those are commented out right now, leading to the strange aspect of how forts seem to lose the ability to be placed closer together, and I would like to see them back on but DH keeps piping up and saying why they were disabled and I still don't really understand the reasoning but maybe just cuz I forget every time. Anyone happen to remember why we have these commented out? In my traits plan I saw them as a good thing to turn back on...

The forts shouldn't be made to work like endless canals (and with bActsAsCity alone they won't by the way due to specific programming to keep the depth of naval intrusion through forts/cities to only 1 space max away from the actual water tiles they link to) BUT we SHOULD add a a canal graphic and an improvement for the canal improvement that CAN break that rule and be strung with that new canal tag - the main thing, and maybe toffer could help with this (I suggest @Toffer90 because I think he's the only one with the python and art skill sets), is that there's gotta be some kind of python to control the rotation of the canal image so that it connects one canal to another graphically without looking stupid.

One reason acts as city forts can't be placed against each other like that is that such forts apply a zone of control if ZOC option is on. A nest of them thus becomes problematic.

 

[Blazenclaw]

DH keeps piping up and saying why they were disabled and I still don't really understand the reasoning but maybe just cuz I forget every time

The most recent post by them I could find on the topic was here in which they thought the adjacency limitation was removed altogether from forts - which is what I'm suggesting given Joseph's valid argument against adding the limitation to palisades, and given that it's an easy xml change to make. Amusingly, it was me in the discussion last time as well, heh.

The forts shouldn't be made to work like endless canals (and with bActsAsCity alone they won't by the way due to specific programming to keep the depth of naval intrusion through forts/cities to only 1 space max away from the actual water tiles they link to)

I just did a quick test to confirm (mostly for my own sake) and yes, currently neither forts nor wooden palisades act as endless canals; they both prevent naval units traveling into them if the improvement is not water-adjacent. The point of contention with this is 2-tile wide 'canals' currently possible ingame; possible to make if you have not researched mathematics, then becomes impossible to make with the tech.

Spoiler :

One reason acts as city forts can't be placed against each other like that is that such forts apply a zone of control if ZOC option is on. A nest of them thus becomes problematic.

That did cross my mind as well. However, A) the ZOC option is still not recommended by author in the tooltip (DH as well?), and B) the problem will not be removed due to it already being entirely probable to have adjacent forts in the game due to palisades upgrading; I just doublechecked and yes, a palisade will still upgrade to a fort if adjacent to another fort.

Regarding an actual canal improvement, I imagine that's a fair bit more effort than it's worth at the moment. Certainly would be nice to have, but outside the scope of this as a quick fix/adjustment ^^;

 

[Thunderbrd]

The most recent post by them I could find on the topic was here in which they thought the adjacency limitation was removed altogether from forts - which is what I'm suggesting given Joseph's valid argument against adding the limitation to palisades, and given that it's an easy xml change to make. Amusingly, it was me in the discussion last time as well, heh.

Towers used to upgrade but it caused problems with other things being introduced at the same time so we removed all but the first. I think they may still be in the XML and art just deactivated, unless someone tidied them out.

It used to be that if two palisades were too close only one would upgrade to a fort. The idea of two forts to make a canal was supposed to be replaced by an actual canal improvement instead.

I thought the limit on how far between cities was removed from forts. There was a bug early on that caused some siege warfare issues. Originally you could claim a plot next to an enemy city and build a fort on it and attack from the fort with all the benefits of being in your own territory. Just like in real life.

By the way has the bug for claiming territory been fixed? You used to be able to claim a plot in the wilderness and get your units to heal up faster. When I reported the bug such plots were reverting to wilderness the next turn leaving you vulnerable to fish attacks (for ships).

So... this was vague AF.

I strongly suggest our 'fix' be to turn back on the tower fort improvements that don't act as cities. Done and done. No upgrades from a non-tower type to a tower type so as to keep from being able to use them to later violate the spacing issue on forts that count as cities - which seems to be the main thing you're pointing out.

I just did a quick test to confirm (mostly for my own sake) and yes, currently neither forts nor wooden palisades act as endless canals; they both prevent naval units traveling into them if the improvement is not water-adjacent. The point of contention with this is 2-tile wide 'canals' currently possible ingame; possible to make if you have not researched mathematics, then becomes impossible to make with the tech.

Spoiler :

View attachment 570926
View attachment 570927
View attachment 570928
View attachment 570929

That did cross my mind as well. However, A) the ZOC option is still not recommended by author in the tooltip (DH as well?), and B) the problem will not be removed due to it already being entirely probable to have adjacent forts in the game due to palisades upgrading; I just doublechecked and yes, a palisade will still upgrade to a fort if adjacent to another fort.

Regarding an actual canal improvement, I imagine that's a fair bit more effort than it's worth at the moment. Certainly would be nice to have, but outside the scope of this as a quick fix/adjustment ^^;

ZOC is slow AF, thus by tooltip advising not to use it. If you're patient with turn times it's not so bad.

I'm suggesting tower forts stay tower forts only and city acting forts stay city acting only the whole way through.

As for the Canal... it'll get it's day someday... I did my part years ago anyhow.

 

[Blazenclaw]

I strongly suggest our 'fix' be to turn back on the tower fort improvements that don't act as cities. Done and done. No upgrades from a non-tower type to a tower type so as to keep from being able to use them to later violate the spacing issue on forts that count as cities - which seems to be the main thing you're pointing out.

The current git/SVN version actually does have both lines in the game right now; fort line includes abatis -> palisade -> fort -> command bunker (of which the palisade -> fort is what I'm pointing out has odd behavior), and the tower line includes wooden watchtower (original topic of this thread lol) -> stone watchtower -> steel watchtower (same graphics as stone watchtower) -> radar, for which the latter line only claims the center tile and does not allow naval unit access (in addition to reduced tile defense compared to forts). I wonder if then Joseph would oppose to having the abatis/palisade gain the adjacency restriction in this light, as the tower line also claims territory and can be placed adjacent to each other, if later in the prehistoric tech tree? It does kinda make sense that the ability to just completely paint territory comes a teensy bit later than learning how to build walls of thorn hedges... Anyway, this will remove the capability of 2-tile canal construction without a city placement, but honestly I would prefer that over the current 2-tile-only-before-mathematics. I don't know how the AI handles watchtowers, though; they definitely do build them, but I don't know their logic regarding them as compared to forts. They do serve different purposes, anyhow.

Unless I'm completely misinterpreting you, and there is a third line of improvements that's not in the game?

 

[Dancing Hoskuld]

The current git/SVN version actually does have both lines in the game right now; fort line includes abatis -> palisade -> fort -> command bunker (of which the palisade -> fort is what I'm pointing out has odd behavior), and the tower line includes wooden watchtower (original topic of this thread lol) -> stone watchtower -> steel watchtower (same graphics as stone watchtower) -> radar, for which the latter line only claims the center tile and does not allow naval unit access (in addition to reduced tile defense compared to forts). I wonder if then Joseph would oppose to having the abatis/palisade gain the adjacency restriction in this light, as the tower line also claims territory and can be placed adjacent to each other, if later in the prehistoric tech tree? It does kinda make sense that the ability to just completely paint territory comes a teensy bit later than learning how to build walls of thorn hedges... Anyway, this will remove the capability of 2-tile canal construction without a city placement, but honestly I would prefer that over the current 2-tile-only-before-mathematics. I don't know how the AI handles watchtowers, though; they definitely do build them, but I don't know their logic regarding them as compared to forts. They do serve different purposes, anyhow.

Unless I'm completely misinterpreting you, and there is a third line of improvements that's not in the game?

Those are the two lines. I refer to them as towers and fortifications. The disjoint in fortifications (palisade -> fort) is deliberate.

Towers are supposed to only be about visibility and fortifications about defense. To work both have to claim the plot but neither should provide access to the resource. Forts and better do but that is supposed to be because of the technology not the improvement. Unfortunately if only works coded on the improvement.

One of the problems with the watchtowers was that each upgrade was about increasing the range of visible territory. This never worked. No matter what number you put on the tag that was supposed to increase visibility nothing changed. These were supposed to be frontier buildings that moved back the "fog of war". This was to change with radar towers which were supposed to act similar to the city building of similar name, i.e. they were supposed to help fighters intercept incoming plains and anti-missile systems stop incoming missiles. There was some talk of having them provide support to troops in a similar way as Commanders but it never went anywhere.

Abatis (and caches) upgrade to palisades which upgrade to forts. Part of the upgrade from palisades to forts is the "act like city" flag which enables ships to enter and the resource on the plot to be accessed by your nation. Those two are deliberate as part of the technology that allows the building of forts.

We tried many things to try and get the AI to stop building forts everywhere. I think the "distance between" was one solution which we tried but it did not fix anything so was removed.

Allowing territory to be claimed inside an enemy's territory is something the AI does not "know" about. In theory both towers and fortifications should only be able to be built in your territory or in unowned lands as building them does claim the plot they are on.

If the AI was better then allowing the player to build them in enemy territory would be realistic as it basically simulates many sieges of history. Perhaps only allow this in games where all players are human. Otherwise it is to OP for humans.

edit These improvements were part the merger of the Super Forts mod component.

 

[Blazenclaw]

Hey there DH! Thank you for the input!
Though, I am a bit confused here, sorry:

The disjoint in fortifications (palisade -> fort) is deliberate.

With you here.

To work both have to claim the plot but neither should provide access to the resource.

So... neither should provide resource. However you also say...

Part of the upgrade from palisades to forts is the "act like city" flag which enables ships to enter and the resource on the plot to be accessed by your nation.

Palisades currently allow ships to enter them just like forts do, but don't have the adjacency restriction that forts do. You're saying palisades should not allow naval units in? I'm fine with that, although this is parallel (to a player point of view, not coder) to whether or not they can be built adjacent to one another. I don't know for sure whether or not either provides resource access, though I suspect forts do and palisades don't from memory. Should palisades and/or forts, or should they not, provide access to the resource?

One of the problems with the watchtowers was that each upgrade was about increasing the range of visible territory. This never worked.

I think this is actually functional now, but not certain; will have to doublecheck. Possibly a side effect of some other change by bill/matt/toffer in the dll or an intentional fix, I don't know.

I think the "distance between" was one solution which we tried but it did not fix anything so was removed.

This was not removed, at least in the current version. I'm suggesting for it to be removed, barring strong reason otherwise; e.g.: whether or not any of the tower line or fortification line should provide access to resources, as that may be a side effect I'll have to look into.

Allowing territory to be claimed inside an enemy's territory is something the AI does not "know" about.

Heh, I don't know about this either! Not sure whether or not the player is currently able to do this, or whether or not it'll be possible to do so when removing the distance limitation. Ideally it shouldn't be possible at all, for the same reasons you state.

 

[Thunderbrd]

I wonder if then Joseph would oppose to having the abatis/palisade gain the adjacency restriction in this light

Yeah that would be my suggestion as well as turning on the tower line. I'm not sure how it doesn't already have that though...

One of the problems with the watchtowers was that each upgrade was about increasing the range of visible territory. This never worked. No matter what number you put on the tag that was supposed to increase visibility nothing changed.

That's mostly because there's a severe hard cap limit in the dll on unit sight distance - many units can already get to this in Prehistoric without being on a tower alone. Towers could still be a cheaper land claim with extra defense that doesn't act like a city. We can always work in increases in interception as well - it would be easy enough - just another project is all.

Allowing territory to be claimed inside an enemy's territory is something the AI does not "know" about. In theory both towers and fortifications should only be able to be built in your territory or in unowned lands as building them does claim the plot they are on.

I didn't think you COULD build an improvement of any kind in enemy territory...

If the AI was better then allowing the player to build them in enemy territory would be realistic as it basically simulates many sieges of history. Perhaps only allow this in games where all players are human. Otherwise it is to OP for humans.

I suppose you could if you used fixed border unit claim then built a fort on that claim.

Palisades currently allow ships to enter them just like forts do, but don't have the adjacency restriction that forts do

That's what I'm curious about there - how... is the canal tag in use on palisades? The acts like cities tag is also part of how a fort claims for the nation the resource it happens to be on if linked by route.

This was not removed, at least in the current version. I'm suggesting for it to be removed, barring strong reason otherwise; e.g.: whether or not any of the tower line or fortification line should provide access to resources, as that may be a side effect I'll have to look into.

I don't think it's a good idea considering how widely the AI spams forts when allowed to.

 

[Dancing Hoskuld]

Forts and better should provide the resource. Earlier fortifications and all towers should not.

Unless you have changed something the "canal" tag was the "act like a city" tag. It allows ships to enter and provides the resource. Canals could only be two plots long.

The distance between problem that was removed was due to there only being one distance between value and it applied to cities, forts and towers. If it was set to 2 then no fortification could be built closer than two spaces from any other fortification, city or tower. Similarly cities could not be built within two spaces of each other even when on different continents, nor could they be built near forts or towers.Sounds like that has been fixed.

Sorry misremembered, units can claim enemy plots, then you can build the fort. In vanilla it is possible to build roads etc in allied nations. These were the only improvements you could build in other nations territory. I think it used to be part of the "right of passage" deal. You paid for the improvement and both of you got to use the routes.

 

[JosEPh_II]

Thank you DH for chiming in and clarifying this up for me. I really like your system and would really hate to see it changed. Same for your Religions work. Though thru Civics I have had to reduced the % of for State Religion. I'm not sure if raxxo reduced the % though. He did reduce it on tons of buildings.

 

[JosEPh_II]

Just because something is The Way It Is, does not mean it is The Way It Must Be. You say you're fine with the current system, sure- but I am not, and I don't see an argument for why you'd not be fine with adjacent forts. Nonadjacent palisades I can see why you dislike; that would disallow land claiming early, so I am with you on that. However.

Can you give me a good reason why it is the case for the change in restriction placement between techs? One could argue that the higher defensive bonus from forts is too strong when placed in close proximity - but even then, a civ-Maginot Line suffers from the exact same problems the real one did, and placing forts next to a city not only causes significant loss of tile value, but also is a huge potential loss if the fort is captured, giving attackers a place to heal from. I cannot think of a persuasive reason why the restriction is there.

Intricacies of a system, by themselves, do not necessarily bring value. This is not a gamebreaking problem no, but it is a choice that I cannot understand why was done, and moreover means that a player must engage in odd behavior in order to achieve an effect (2 tile canals); actions such as early war for express purpose of conquering specific regions before mathematics, or potentially saving gatherers and never using them for many centuries.

What downsides are there for allowing forts to placed adjacent to each other after mathematics, considering it was already possible before mathematics?

Hope you are cleared up on this now that Dancing Hoskuld has replied.

 

[Dancing Hoskuld]

I can really only comment on what was intended when we did the conversion. The dll stuff was done by Koshling. These improvements are intended to complement cities and their buildings not replace them.

Unmanned fortifications and towers are not really considered unmanned. They are assumed to have a civilian staff. In the case of watch towers, for example, this would probably be a "grandfather" to make decisions and a child to see far and run to report incursions to the town.

There was an idea floated of making fortifications and towers have their own screen. One where you could assign a garrison; an administrator; add a vicus(sp?) small village to process resource; granaries and arsenals to support and upgrade troops; and so forth. Basically a specialized city but with no population.

 

[Thunderbrd]

Forts and better should provide the resource. Earlier fortifications and all towers should not.

Unless you have changed something the "canal" tag was the "act like a city" tag. It allows ships to enter and provides the resource. Canals could only be two plots long.

The distance between problem that was removed was due to there only being one distance between value and it applied to cities, forts and towers. If it was set to 2 then no fortification could be built closer than two spaces from any other fortification, city or tower. Similarly cities could not be built within two spaces of each other even when on different continents, nor could they be built near forts or towers.Sounds like that has been fixed.

Sorry misremembered, units can claim enemy plots, then you can build the fort. In vanilla it is possible to build roads etc in allied nations. These were the only improvements you could build in other nations territory. I think it used to be part of the "right of passage" deal. You paid for the improvement and both of you got to use the routes.

The distance between limitation is also established by the 'act like a city' tag. Thus why forts are restricted but towers are not. That's the biggest difference between fort line and tower line. What I don't 'get' right now is how an Abatis gets to act like a canal while not being forced to being separated from other city objects like normal forts are - which suggests they DON'T have the 'act like a city' tag but are instead then using the bCanal tag I added that won't respect the 1 space from water limitation cities/forts normally have. I mean, I suppose maybe I could be wrong that the distance limit is established by the 'act as city' tag, but it did last I checked. If it uses a different tag to define the distance from other city limitation then I think that must be some newer programming or I just don't recall that being a separate thing when it was. If it is... where is the limit established? Towers, IIRC, aren't supposed to be worried about that distance between either way because they don't count as cities.

I suppose I could actually start reading some code here at some point.

 

[Dancing Hoskuld]

If I remember correctly we added all the buildings from Super Forts but then removed the Stone and Metal Towers because we could not get them to have the required effect. Radar Towers may have been left in because we had not gotten to the Renaissance at that time.

The bCanal came after the Super Fort integration so it is possible someone started making adjustments to the XML later.

 

[JosEPh_II]

All I will add to this is I do not use the ZOC Option. Have never liked it.

In Blazenclaw's screen shots playing the game without ZOC and Without Fixed Borders you can not build 3 forts in a row. Now iirc building a palisade of 3 in a row maybe possible. I just can not recall the AI or myself ever doing this. Then having the 3 palisades evolve, with appropriate Tech reached, into Forts.

In GlobalDefines.xml this is the current section on Super Forts:

<!-- Super Forts begin -->
<Define>
<DefineName>AI_WORKER_MAX_DISTANCE_FROM_CITY_OUT_BORDERS</DefineName>
<iDefineIntVal>5</iDefineIntVal>
</Define>
<Define>
<DefineName>SUPER_FORTS_DURATION_BEFORE_REVOLT</DefineName>
<iDefineIntVal>5</iDefineIntVal>
</Define>
<!-- Super Forts end -->

This seems, again iirc, less than what was originally in this file for Super Forts. So this begs the question was a line/tag or 2 Removed some time in the past couple of years?

EDIT: Guess I will need to go thru the SVN history and find out if it was.

 

[Thunderbrd]

This seems, again iirc, less than what was originally in this file for Super Forts. So this begs the question was a line/tag or 2 Removed some time in the past couple of years?

The first indicates how far a worker should be able to go beyond your borders to build forts and the second I'm not sure but doesn't sound like something that indicates minimum spacing. Checking the code it looks to involve cultural flipping of the plot.

So this is interesting.

Apparently I was wrong in assuming that 'bActsAsCity' counts as the way that forts are required to be spaced out from one another. In fact, I would wager based on my findings in the code, that forts of all kinds can legit be placed right next to a city, but from Fort onward, you cannot place one closer than 3 spaces away from another FORT (or any of its upgrades.)

The reason is in the way the tag 'iUnique' is programmed. This is in CvPlot::canBuild and pertains to the restriction on fort spacing with the use of the iUnique tag:

        if (GC.getImprovementInfo(eImprovement).getUniqueRange() > 0)
        {
            int iUniqueRange = GC.getImprovementInfo(eImprovement).getUniqueRange();
            for (int iDX = -iUniqueRange; iDX <= iUniqueRange; iDX++)
            {
                for (int iDY = -iUniqueRange; iDY <= iUniqueRange; iDY++)
                {
                    CvPlot *pLoopPlot = plotXY(getX(), getY(), iDX, iDY);
                    if (pLoopPlot != NULL && pLoopPlot->getImprovementType() != NO_IMPROVEMENT)
                    {
                        if (finalImprovementUpgrade(pLoopPlot->getImprovementType()) == finalImprovementUpgrade(eImprovement))
                        {
                            return false;
                        }
                    }
                }
            }
        }

I took a look into all the various calls here to break down that what it's trying to do is make sure that the FINAL possible upgrade in a fort (or ANY improvement) path (interesting method to finding this I'll have to keep in mind too) defines for the entire line before it how far away forts need to be - apparently in an effort to keep a type of fort from being able to be placed too close to another if their upgrades even wouldn't allow it.

iUnique, in the improvements tags, defines how many plots between must exist for you to build such an improvement away from another improvement in that line. IMPROVEMENT_FORT and beyond shows a 2 here.

So... why does it fail for the Abatis? Because the gateway into this check is:
if (GC.getImprovementInfo(eImprovement).getUniqueRange() > 0)
And the Abatis is set to 0 so it never checks its line's iUnique tag.

iUnique is a good example of a tag not descriptive enough to be clear in the XML... wish it had been named as it is in the code: Unique Range (getUniqueRange).

Anyhoo... I find 2 things a little wrong here.

1) the obvious - Abatis is ignoring this because of the first check.

Possible fixes - remove the >0 gateway check - would lengthen turn times and AI evaluations a bit, probably not too noticeable... probably.
Or give Abatis a 1 on iUnique - which would then make it really 2 because all the forts in the whole line are going to refer to the iUnique on the last improvement in the upgrade chain so... might as well make it 2.

2) the less obvious - Shouldn't forts be spaced out from cities the same as they are from each other? Should we make the spacing check simply look for plots that may count as a city, whether a fort or not?

Another point - if we are to consider #2, we could feasibly get rid of iUnique as a tag altogether and do as I had assumed we already had - base the spacing requirement on bActsAsCity entirely.

 

[Dancing Hoskuld]

All I will add to this is I do not use the ZOC Option. Have never liked it.

It is a fair attempt at finding a solution that matches the real world situation before motorised transport. An alternative is to have units loose health due to supply difficulties instead. The further in (=behind enemy lines i.e. from cultural boundaries) they are the faster they loose health.

2) the less obvious - Shouldn't forts be spaced out from cities the same as they are from each other? Should we make the spacing check simply look for plots that may count as a city, whether a fort or not?

Another point - if we are to consider #2, we could feasibly get rid of iUnique as a tag altogether and do as I had assumed we already had - base the spacing requirement on bActsAsCity entirely.

A valid form of siege warfare pre-gunpowder (actually still works then, so probably up until motorised transport again) is to build your fort on your border and they build their fort on their border, Having a distance restriction between forts wont take into consideration who owns the fort.

Similarly it is historical to occasionally build a fort next to a city when attempting to conquer it as it gives defense to your siege units. This is only possible with ZOC in C2C. We don't have much in game to support sieges. Trenches and spiked "fences" placed to make sallying forth from the city/fort difficult, ie the same things as the city has to defend it can be put up in the field to aid the attackers.

BtW I am not sure why the "claim enemy plot" is linked to the ZOC option, but I was not involved in that discussion as, in general, I find the combat side of things boring

 

[JosEPh_II]

It is a fair attempt at finding a solution that matches the real world situation before motorised transport. An alternative is to have units loose health due to supply difficulties instead. The further in (=behind enemy lines i.e. from cultural boundaries) they are the faster they loose health.

I'm not talking about building a Fort in enemy territory. What you say would only be true if actively engaged in a conflict. Otherwise it should not apply to using forts to establish outposts into the wilderness, ie establishing non conflict territory claims. Even moreso if you are not using the Option Fixed Borders.

 

[Dancing Hoskuld]

I'm not talking about building a Fort in enemy territory. What you say would only be true if actively engaged in a conflict. Otherwise it should not apply to using forts to establish outposts into the wilderness, ie establishing non conflict territory claims. Even moreso if you are not using the Option Fixed Borders.

I am sorry I am not understanding what you are saying here. Forts have always been used to claim territory in lands not claimed by others, well other settled nations, nomads don't count. It is 3am here and I am just not understanding the whole of your comment or your point.

I was trying to say that:-

1. you should be able to build forts next to cities and forts in nations you are at war with and that they should claim the plot they are on. That is the historical point. It gives you a place of defense to wage your siege and heal your troops.
   
   In Civ you can't build anything other than routes in another nations borders. In C2C with Fixed Borders you can claim a plot using a unit. Once the plot is claimed then you can start to build the fort and it is the enemys job to stop you building it...
   
   (Note: last time I tried, the claim did not stick even in the wilderness where the idea of claiming it was to heal the unit. Not sure if that was fixed. Claim is lost as soon as no unit of yours is in the plot.)
   
   
2. Forts can be built anywhere in the wilderness.
   
   
3. You should be able to build a fort anywhere in your nation but especially when that will put the fort next to another nations fort at any time.

The Fixed Borders option does not play any role in this except that currently you can't do 1 without it.

Some of the discussion above is suggesting a minimum distance between forts and other forts as well as forts and cities. I am trying to point out that care should be taken as one of the problems we had earlier was that the solution treated the distance regardless of the owner of each of the cities/forts. In one example I saw two nations on two different continents had a one gap straight separating them. Both wanted to put a fort on the straight coast but couldn't because of the distance between the forts was too small.

 

[Blazenclaw]

In Blazenclaw's screen shots playing the game without ZOC and Without Fixed Borders you can not build 3 forts in a row. Now iirc building a palisade of 3 in a row maybe possible. I just can not recall the AI or myself ever doing this. Then having the 3 palisades evolve, with appropriate Tech reached, into Forts.

This is the entire reason I started this discussion
There are cases where I the player have desire for adjacent forts (2-tile canals, etc), but can only acquire it before mathematics- an odd design choice for which I suggested a change be made.

Or give Abatis a 1 on iUnique - which would then make it really 2 because all the forts in the whole line are going to refer to the iUnique on the last improvement in the upgrade chain so... might as well make it 2.

Thanks for the breakdown here! I got a bit turned around with the unique tags.
This seems the reasonable approach. Giving both Abatis and Palisade a value of 2 here would give them the spacing restriction of forts, removing the odd jump when upgrading at Mathematics. For Joseph, mass land claiming in prehistoric would still be possible with watchtowers, a bit later in the tree, but this makes sense to me. Simple wood abatis and palisades shouldn't be able to link together to claim vast swaths of territory; tech hasn't reached that point yet! They defend their own tile only. Watchtowers can claim 'more' territory, but don't have the defensive bonus, while later forts sortof combine the two in some respects by claiming adjacent tiles as well.
Edit: Fortified Cave, and Fortified Cave w/Cache should probably also have the iUnique restriction as well for the same improve-into-fort reasons.

2) the less obvious - Shouldn't forts be spaced out from cities the same as they are from each other? Should we make the spacing check simply look for plots that may count as a city, whether a fort or not?

I'd argue against this for the same reasons DH brought up, as well as that with the palisade adjacency restriction placed, this would be the only way to make a defacto 2-tile canal; city tile and fort adjacent to each other. For someone who likes to play on maps with large separate water bodies, canals are pretty critical for timely navy maneuvers.

I am sorry I am not understanding what you are saying here.

I think Joseph might be arguing against ZOC applying when not at war i.e. forts or equivalent applying ZOC effects in wilderness terrain? Though someone who also doesn't play with ZOC, from my understanding that would be annoying/not ideal if a random palisade that claims its own tile in the middle of the tundra somewhere prevented me from moving between tiles adjacent to it, or dealt damage (whatever the ZOC effect is used). It might be already the case though that ZOC only applies when at war? Again, I don't have experience playing with the option.

 

[Yudishtira]

I'd argue against this for the same reasons DH brought up, as well as that with the palisade adjacency restriction placed, this would be the only way to make a defacto 2-tile canal; city tile and fort adjacent to each other. For someone who likes to play on maps with large separate water bodies, canals are pretty critical for timely navy maneuvers.

I agree. Two-tile canals are a staple of C2C and removing them would be a literal backward step (and a big one of many many years and versions). The possibility of longer canals (ie. canals on tiles that are not coastal) has been raised in this very discussion, and that is the direction that imo we should be looking.