Yeah but TB I said invisible to other domains. Land units from different nations could still interact in the tile.
Invisibility to a particular domain may be a way to simplify. But it still opens up the main degree of complexity, which is an evaluation of can my UNIT see your unit or not - not can any of my units see your unit or not. The distinction is profound when you consider that it has never been made previously and that the real processing shortcut in use prior to these changes was to track only what the player's worth of units can see or not with rare recalculations of the whole map and once done, if your unit can attack and the enemy is among those visible to the player is all that was ever determined to decide if the attack could be made, the visibility determination made very infrequently, not each time a unit wanted to determine if it could attack.
It's a little hard to explain. I hope I've been able to express it effectively. In short, this means that even making a unit invisible to a particular domain may well not bring us back to enough efficiency. Perhaps it would help to explain that the whole of the code assumes that if an enemy unit is visible to any of your units, it is visible, and thus attackable, to them all, regardless of the domain, what types of units they are, gamestates, etc... and the biggest delay generating hitch here is trying to break that rule at all. As soon as you do, you have to let each unit figure out if it can attack a particular unit or not. This is the basis of the problem.
However, it's similar to the answer I was considering with the Z layers perhaps. With that method I was thinking that visibility determinations may be able to be made just as infrequently as it ever was but made for each Z layer and those Z layers isolated in the attack considerations.
Perhaps, then, you can see how,
The simplification is already there, in that if you have two adjacent tiles of tunnels, they are assumed to be connected. And a tunnel is assumed to be connected to all adjacent land tiles, no tunnel mouth location is defined.
I say let the not-so-horrible simplification stand, that all adjacent tunnel tiles are connected, no matter who owns them. You will still be unable to access your neighbour's tunnel in peacetime without Open Borders (actually that's only if it's in their culture... or do tunnels have to be?).
And to be clear I am not saying that ships and aircraft can attack units in tunnels - that's a separate issue. Here I'm just dealing with the question of "which tunnels are connected?".
Isn't addressing the issue. The issue is the moment where we say its possible for one of your units to be able to attack a unit, but not all of your units may be able to. The game code has always assumed that if one can attack, all can, and where it may not seem this way you'll find its because its quick to establish that some units cannot attack at all - that doesn't cause the unit to have to evaluate the enemy - it's a factor on the unit taking action, and thus checked quickly and patently.
The same problem would exist if you wanted to make it possible for say, only hunters, to attack animals. (Not saying you'd want to) The code has never allowed a gamestate of the enemy unit to determine attackability for some units and not for others.
Since Size Matters it is even possible to split units so not only production causes high numbers of units
Something isn't quite right about how it's working. It's enabling units to split under conditions that units should've merged to compensate but don't. This is incorrect but I can't find the logic flaw. It shouldn't split any units until 4 units that can merge with each other are on the same tile and thus naturally 3 of them merge and one of them splits. Then, when this process has caused enough 'lesser' size units to co-habitate the same space that they reach again that magical count of 4,3 merge and 1 further splits. Without a merge being legal, a split shouldn't take place. But if a split is not legal (min size) then a merge should still be able to take place. This was intended to eventually weight a bit towards merging over splitting. 4 units thus should never split into more than 4 units since 3 merge into one and 1 is left to split into 3 making it still 4.
However, there's also the attempt units may make to split to fit onto a transport. I rather figured that once they were dropped off the above method would stratify them towards a greater amount of merged units again.
But something's not quite working about all that and sometimes you see huge amounts of split units. This shouldn't even be possible for so many split units to be on the same tile without merging as soon as they can. I don't know what's not working right there... maybe you can spot it.
This was intended to be a base rule for the AI from which some more advanced splitting and merging might take place to react to or plan for a situation for specific unit types, more often this would mean merging than splitting.
I wonder if assigning to units the basic chart base values as was redetermined in the modder's documentation recently would help to balance unit production. And then again, the AI shouldn't WANT to build such amazingly large stacks either. it's simply bad strategy to be that over the top because at a point it gets economically impacting and if they were to have that many units, it should be in more large stacks rather than less gargantuan stacks, some being held back as reinforcements or sent towards other targets to split enemy focus. It's also a bad strategy since there's nukes and so much that can quickly tear down the whole stack on one specific tile.
aka, stack limits are a poor bandaid for what's basically AI and game balance flaws.
while at the same time the Noble level player is drowning in a sea of Red Ink ( On Strike). And those Deity players that insist on playing Eternity Gamespeed just exacerbate the problem. 
