Resource icon

C3X: EXE Mod including Bug Fixes, Stack Bombard, and Much More Release 22

Hi Flintlock! Happy new year everyone, BTW.
I encounter some bug. Every time I try to load auto-saved game, it crashes, but when I restart it loads successfuly. Have someone reported similar thing?
Hello and happy new year. Does that happen for every autosave or just the ones from a particular game? I have a save that reliably crashes if I load it after loading some scenarios, but works if loaded first thing after starting up the game. I investigated that issue once and found it was related to the minimap somehow, as if the game wasn't resetting the minimap properly between the two saves. I'm not familiar with that part of the code so I wasn't able to see what exactly the issue was and in the end I decided it wasn't worth the time to look deeper. That might be the same bug you're seeing.

Hi folks, I've really lost track of this thread and recent releases (has there been any talk of splitting C3X out into its own subforum?) so apologies if some of this is rehashing topics already covered or even implemented, but I've been collecting some more ideas that I'd like to apply in future projects: ...
Hello again. Someone mentioned a subforum for C3X before. I think that would make sense after I add Lua scripting to the game, if I ever do, because then C3X would be a real platform for other mods. Right now one thread of requests is already more than enough and I don't think there's much else to discuss.

About your list:
  • I'll try putting a limit on how many units are allowed on each tile for the next version since that's been requested several times now and it would be easy to do at least as an experiment. I'd implement it similarly to the trespassing restriction, as another condition in the movement logic that makes certain moves invalid. I'm not sure the AI will be able to deal with it, but we'll see.
  • Allowing barbs to capture and enslave and making commercial buildings half price for commercial civs ought to be easy, I'll look into those.
  • The unit limit already applies to unit spawning buildings. Specifically, it applies to spawning buildings, normal city production, and upgrading. It does not apply to any other forms of unit creation.
  • Maintenance from cities themselves would be easy since it could be tacked onto an existing method that sums maintenance from buildings. I really think it should be communicated somewhere on the city screen, though, maybe as a dummy entry in the list of improvements?
  • I'm not sure about allowing siege units to hit multiple units in one volley, that sounds a bit difficult but is probably doable.
Wouldn't it be nice to have Lua integrated into the game? I keep mentioning Lua hoping someone will show interest but so far no takers. A lot of the requests I've been getting recently, including some of yours, really are like game rules that would be better implemented through scripts in my opinion. C3X itself is limited by its config files. For example, alternate barb unit types wouldn't be difficult to make happen in terms of editing the game logic. Basically what I'd do is intercept the calls from the barb logic to the unit spawner method and swap out the unit type IDs. I'd have to make up some rule about what type to swap out and I'm sure I'd get multiple requests for different rules, and it really ought to be configurable through the INIs. It would be nice to call out to Lua to get a type for each barb spawn. That covers whatever rules people may want, although it does push the job of implementing the rules onto them.

The option to give units range for their air defense values. Long range SAM systems like the Patriot have the range of 160km, that's more than tube artillery. So they should be able to cover a radius of 2 tiles around them.
The option of city improvement preventing another improvement from even appearing in the menu. The palace can prevent courthouses and police stations from being built.
A unit limit on how many each city can produce. So we can have things like immobile defenders and artillery that the AI won't overbuild or get auto produced out of control. A coastal fortress for example would only auto produce 1 coastal battery.
The first challenge I can think of for long range air defense is the animations. That animation with the rocket shooting straight upward is a tile effect, as I recall, which is why replacing it with an animating unit is not easy (that's been requested a few times). To let air defense units defend nearby tiles it would be necessary to replace that animation. Those next two things you mentioned would be easy, again it would be nice if they could put in little Lua scripts...

So I've tested it again in my mod and in stock game on debug mode. Strangely enough, it worked fine in stock game debug with the Scout unit limit being set to 2. Yet in my mod it doesn't. It seems to be the same with the whole PTW targeting. If you could look into that again that would be appreciated. Maybe play the mod till you get catapults and bombard with them. There maybe something that happens in modding that prevents the C3X patch from doing its work.
Alright, thanks for posting this. I'll look into it.
 
Additional info on my C3X config sheet for the bombard: I've set the units to have the charm special order. On my patch I have PTW style targeting with the charm unit special order set to true. But instead of targeting PTW style they'd target C3C style. So clearly, the sheet did something because the unit no longer does the charm bombard. But it's just not PTW style. I have to manually set the units to PTW style bombard to get them to do that.

For long range air defense, the animation could simply the flak animation. There is no missile shooting up, just a buncha black explosions in the sky. After all, SAMs too explode like a Flak shell to hit aircrafts with fragmentations.
 
  • I'll try putting a limit on how many units are allowed on each tile for the next version since that's been requested several times now and it would be easy to do at least as an experiment. I'd implement it similarly to the trespassing restriction, as another condition in the movement logic that makes certain moves invalid. I'm not sure the AI will be able to deal with it, but we'll see.
Sounds good! I know that one is a reach but it would be really powerful if it works out.
  • Allowing barbs to capture and enslave and making commercial buildings half price for commercial civs ought to be easy, I'll look into those.
:thumbsup:
  • The unit limit already applies to unit spawning buildings. Specifically, it applies to spawning buildings, normal city production, and upgrading. It does not apply to any other forms of unit creation.
Excellent! I had assumed it only applied to production. That alone may finally warrant a Lord of the Mods patch. I don't know how long we spent trying to balance things to produce one, three, seven, nine... ;)
  • Maintenance from cities themselves would be easy since it could be tacked onto an existing method that sums maintenance from buildings. I really think it should be communicated somewhere on the city screen, though, maybe as a dummy entry in the list of improvements?
Whatever makes sense. A dummy improvement would work, or something next to the "Commerce" heading.
Wouldn't it be nice to have Lua integrated into the game? I keep mentioning Lua hoping someone will show interest but so far no takers. A lot of the requests I've been getting recently, including some of yours, really are like game rules that would be better implemented through scripts in my opinion.
I 100% support efforts to integrate Lua. I've still never bothered to learn it, but it sounds simple enough and Jim had done some proof of concept work in C7 as we plan to eventually provide a modding API. I don't know if there would be any potential for reuse or collaboration between the two, but you could at least bill it as a bridge to C7 modding :D
 
The first challenge I can think of for long range air defense is the animations.
Given the Flak and SAM attack sequences are aiming up, I'm thinking per-unit air defence was originally planned, but for whatever reason never made it to release or subsequent patches. And just to complicate things further, what if AA anims varied by era?
 
Edit: I've just found out that by using the Palace as a prerequisite building for making the Scout (AI) unit, it cancels out the patch's unit number limit.
Alright, I see this bug now. Basically when a unit has a building prereq, the result from the prereq check overwrites the unit limit check. In fact it causes the mod logic to skip the second check entirely. It's an annoyingly simple mistake but at least an easy fix. Could this have been the issue with unit limits in your mod? By the way, I can't load that save you posted, UnitLimitIssue.SAV, I get a file not found error for "art\advisors\MM_all.pcx". So I'd need more art than just that canoe unit, but it might not matter, I'll post a preview version with this fix soon so you can test yourself.
 
  • I'll try putting a limit on how many units are allowed on each tile for the next version since that's been requested several times now and it would be easy to do at least as an experiment. I'd implement it similarly to the trespassing restriction, as another condition in the movement logic that makes certain moves invalid. I'm not sure the AI will be able to deal with it, but we'll see.
Great news! I think that could add more tactical depth to the game (Need for large-scale troop movement for attack or defend territory without "stacks of doom", ensuring supply routes for Campaigns, Battles at geographical bottlenecks with limited supply opportunities ... ).
I'm really excited! 🤩

However, it makes sense to exclude cities from the unit-limit-per-tile to avoid bugs, especially with AI behavior
 
The first challenge I can think of for long range air defense is the animations. That animation with the rocket shooting straight upward is a tile effect, as I recall, which is why replacing it with an animating unit is not easy (that's been requested a few times). To let air defense units defend nearby tiles it would be necessary to replace that animation.
For long range air defense, the animation could simply the flak animation. There is no missile shooting up, just a buncha black explosions in the sky. After all, SAMs too explode like a Flak shell to hit aircrafts with fragmentations.
I like the idea of having 1 or 2 tile range for air defenses, depending on the type. I think the coolest effect would be if the AA unit responsible for downing the aircraft simply played its Attack animation first, then the aircraft plays its Death animation. Without any generic (missile) animation in between.

The AA unit could react and turn to face the bomber as if it was attacked by a ground unit, shoot rat-a-tat with whatever ordnance is specific to it, then the aircraft appears and explodes in flames. This way you actually get to see who shot it down too, which is informative. Like the dogfight when a fighter plane is defending.
 
Last edited:
Alright, I see this bug now. Basically when a unit has a building prereq, the result from the prereq check overwrites the unit limit check. In fact it causes the mod logic to skip the second check entirely. It's an annoyingly simple mistake but at least an easy fix. Could this have been the issue with unit limits in your mod? By the way, I can't load that save you posted, UnitLimitIssue.SAV, I get a file not found error for "art\advisors\MM_all.pcx". So I'd need more art than just that canoe unit, but it might not matter, I'll post a preview version with this fix soon so you can test yourself.

My bad, I forgot that I also added leader heads. You'd need to have:





Attached are the artillery unit settings. With this I get C3C style targeting. So the C3X patch did something. But instead of turning the charm bombard into PTW bombard as intended something interfered and turns it into C3C bombard.

Putting the unit manually into the PTW bombard list will result in it becoming PTW targeting regardless of charm.
 

Attachments

  • Screenshot (1082).png
    Screenshot (1082).png
    280.8 KB · Views: 24
  • Screenshot (1083).png
    Screenshot (1083).png
    233.6 KB · Views: 19
Finally, to revisit a couple that I brought up before and would very much like to see:
  • Restricting "detect invisible" to only apply to the same land/sea/air class of units.
I've been wanting to do that for a while in my 2021 EXPANSION mod, having a separate "Detect Invisible" for land and sea units. This is why:
  • You can make really cool stealthy land units by, first, giving them the "Invisible" flag.
  • But that makes them totally invisible, and they stay hidden even after they have attacked. You wouldn't even know what killed you. It's like fighting ghosts...
  • A good solution is to give every land unit the "Detect Invisible" flag, then it has the effect of making the units partially invisible.
  • You cannot see them when they cross your borders or roam around your lands, you can only see them once they are right next to one of your own units.
  • This makes it possible to fight them, but you could also walk into an ambush because you couldn't see them before it's too late. In most cases land units see only the nearest tile around itself.
  • I've tested this and it works like a charm! Great for guerrillas, ninjas, commandos, partisans and special forces.

But there is one problem, that spoils the effect:
  • Destroyers, missile cruisers and nuclear subs can spot stealthy land units near the coast with their sonar.
  • Every land unit on the coast can see submarines passing by.

This would be solved if "Detect Invisible" was separate for land and sea units. So land units could only see land units, and vice versa.
Hope this is achievable, I would implement it if it worked.
 
Last edited:
My bad, I forgot that I also added leader heads. You'd need to have: ...
The download link for the Mansa Musa PCX isn't working for me. But anyway I think I've figured out what the problem is. When a scenario gets loaded and charm_flag_triggers_ptw_like_targeting is set, the mod finds every unit type with the charm bombard flag set, adds them to the list of unit types that should do PTW targeting, then clears the charm flags. The point of clearing that flag, IIRC, is so that those units use the regular bombard logic (which has been edited to allow for PTW targeting) instead of the charm bombard logic. That works fine when you start a scenario, which is what I've been testing. The problem comes when you save & reload a scenario. The game stores the scenario data into the save with the charm bombard flags cleared so when the game is reloaded the mod doesn't convert those units to PTW targeting. I'll fix this soon.

However, it makes sense to exclude cities from the unit-limit-per-tile to avoid bugs, especially with AI behavior
I agree it's probably better if cities are exempt from the limit. For two reasons, first is that the limit won't apply to city production anyway so cities will be able to stack as many units as they want by producing them and never moving them out of the city. Second, it's strange and irritating to have land & sea units fight over space in a city, which is something I noticed happening when I briefly tested the limit.

By the way, the limit will work by restricting unit movement. In other words, it will be invalid to move a unit onto a tile if the tile already has at least a certain number of units on it, the specific number depending on a config option. The limit won't apply to unit creation so you'll still have large stacks of barbs during uprisings and can violate the limit using city production, capture, enslavement, etc. Trying to stop all those other ways of stacking units would be a lot more difficult than just restricting movement.

This would be solved if "Detect Invisible" was separate for land and sea units. So land units could only see land units, and vice versa.
Hope this is achievable, I would implement it if it worked.
This looks achievable and even relatively easy. I'll try to get it done soon.
 
This would be solved if "Detect Invisible" was separate for land and sea units. So land units could only see land units, and vice versa.
This looks achievable and even relatively easy. I'll try to get it done soon.
Thanks, Flintlock. :thumbsup:

Related to this request, I would also like to limit the range of "Detect Invisible" (sonars/spotting land units) to a range of 1. As it is now, it is a bit too easy to find subs. Sonars in real life don't have the same range as radars, the ship needs to be fairly close to the sub.

Speaking of radars, I would like to extend their range to 3. The whole point of having a radar is to see beyond the visual horizon. As it is now, whether you set the radar flag or not has little impact on most units. All air units have a 2-tile visibility anyway, regardless of radar or not. Sea units also have 2 visibility at sea without radar. The only difference a radar makes is that the ship can see 2 tiles inland as well, which is, in my opinion, undesirable. As far as land units go, then a radar does make a lot of difference, because they can normally see just 1 tile around themselves (unless they stand on a hill or mountain). But in real life, land based radars are used to detect air threats, not other ground forces (which is hard to do because of topography and terrain).

I would be happy with a fixed range of 3 for radars. But I guess my ultimate wish would be if radars just extended the visual range of the unit it was on by 1. Then air and sea units would see 3 tiles, and land units would see 2 tiles most of the time. I would use the latter to give some units, like explorers and scouts with a telescope (not an actual radar), extended vision on land.
 
Last edited:
Thanks, Flintlock. :thumbsup:

Related to this request, I would also like to limit the range of "Detect Invisible" (sonars/spotting land units) to a range of 1. As it is now, it is a bit too easy to find subs. Sonars in real life don't have the same range as radars, the ship needs to be fairly close to the sub.
That depends on the frequency of the sonar and how noisy the sub is. The very low frequency sonars, that require a very large transducer, can have a range of 40 plus nautical miles, using bottom bounce tactics.
Speaking of radars, I would like to extend their range to 3. The whole point of having a radar is to see beyond the visual horizon. As it is now, whether you set the radar flag or not has little impact on most units. All air units have a 2-tile visibility anyway, regardless of radar or not. Sea units also have 2 visibility at sea without radar. The only difference a radar makes is that the ship can see 2 tiles inland as well, which is, in my opinion, undesirable. As far as land units go, then a radar does make a lot of difference, because they can normally see just 1 tile around themselves (unless they stand on a hill or mountain). But in real life, land based radars are used to detect air threats, not other ground forces (which is hard to do because of topography and terrain).

I would be happy with a fixed range of 3 for radars. But I guess my ultimate wish would be if radars just extended the visual range of the unit it was on by 1. Then air and sea units would see 3 tiles, and land units would see 2 tiles most of the time. I would use the latter to give some units, like explorers and scouts with a telescope (not an actual radar), extended vision on land.
Again, this depends on the frequency of the radar and the height of the antenna. Most of the shipboard radars used in World War 2 had a reliable detection range of maybe 100 miles, if an air search radar. A lot depends also on the height of the target and the strength of the return. Gunnery radars had a much shorter range as they used a much shorter frequency, and again it depended on the height of the antenna and the strength of the return off of the target. The size of the target was a factor as well. A battleship or aircraft carrier gave a much stronger return than a destroyer. Ranges to surfaced submarines were quite short. By the end of the war, the Japanese were experimenting with radar absorbent materials and shaping the submarine conning towers to deflect the radar beam from returning to the antenna. You could give the Aegis cruiser the longer radar range, as a result of advanced signal processing, but again, the height of the target is crucial to performance. A target flying at 100 feet has a much shorter detection range than a target at 30,000 feet.

What the target is made of also plays a role. During the Korean War, the wooden and canvas biplanes used by the North Koreans and Communist Chinese for heckling missions were extremely hard to detect, even at altitude, due to the very poor return of signal.
 
I completely missed the Lua hint.
I have never touched Lua but I do have some programming XP.

Scripting for Civ3 sounds awesome. I pinky promise to learn and use Lua if you want to do the heavy lifting of implementing it.
 
Last edited:
This would be solved if "Detect Invisible" was separate for land and sea units. So land units could only see land units, and vice versa.
Hope this is achievable, I would implement it if it worked.
This looks achievable and even relatively easy. I'll try to get it done soon.
It's probably something easier done via Lua, but as an alternative to a hard per-domain rule, being able to define different invisibility 'classes' (à la Civ4) would allow more flexible modding.

Related to this request, I would also like to limit the range of "Detect Invisible" (sonars/spotting land units) to a range of 1. As it is now, it is a bit too easy to find subs. Sonars in real life don't have the same range as radars, the ship needs to be fairly close to the sub.
Interestingly, Civ2 keeps 'Detect Invisible' and the unit's effective sight separate, and subs are only exposed when immediately adjacent even with 2-tile LOS.

Likewise, extended sight is limited to domain: Land units don't see further into water, sea units don't see further into land. Only air units get unrestricted sight.
 
Wouldn't it be nice to have Lua integrated into the game? I keep mentioning Lua hoping someone will show interest but so far no takers.
I am, of course, completely open to including every nitpicky detail myself via Lua. Admittedly I have only a little bit of outdated experience writing simple scripts for games like Age of Empire II or Dungeon Keeper, but that shouldn't be a problem I hope. What I can't judge, however, is how much work you'll have integrating Lua. Would it mean months to years of hard work before it would be at least partially operational? If I had to guess, I'd say a long time. I don't know how extensive your list of requirements is, but I assume very. Would that mean that all work on that list would be put on hold for that time?

I'll try putting a limit on how many units are allowed on each tile for the next version since that's been requested several times now and it would be easy to do at least as an experiment. I'd implement it similarly to the trespassing restriction, as another condition in the movement logic that makes certain moves invalid. I'm not sure the AI will be able to deal with it, but we'll see.
I'm starting to fully support this promising experiment. I hadn't planned the gameplay from that perspective at all until recently. However, if such a possibility presents itself from the next version onwards, I can think of plenty of other expansions to limit the number of units on the tiles (presenting great potential for future use the more I think about it), such as:
- each terrain type would have its own limitation (similar to how each terrain has its own movement cost);
- towns/cities/metropolises would have their limit derived, for example, as 2x/3x/4x from the terrain they are on;
- dependency on difficulty, some overall benefits for the AI;
- technologies representing logistics or supply that would increase/decrease the limit for a particular terrain;
- government type and possible mobilization could also provide overall advantages;
- terrain infrastructure such as ruins, colonies, outposts, fortresses, radar towers or airports could also move up/down with a limit (this with some existing high restriction for towns/cities/metropolises could serve as a reason for AI to guard more of these mentioned infrastructures, potentially borders or strategic materials);

(And best of all in the end, but probably the most crazy idea, but I'm still curious about its feasibility in conjunction with the previous one or even as a complete alternative in approach to limiting the number of units on a tile)
- units reduce the food yield of the tile they are on (the example is just for simplicity, as it is too harsh (Or maybe not?), I would prefer if the unit consumes only a fraction or if the tile feeds a multiple of its yield (I'm not sure how mathematically problematic for calculations it would be if a unit consumed half/third a food? I guess the graphic representation would be a problem.), alternatively the chance of losing 1 hp could be only 50%/25% per unit (sort of like the sinking of ships on the seas and oceans) (NOTE: on overcrowded tiles, automatic healing would have to be suspended for unit starvation to work effectively));
If a tile yields 2 food and there are more than 2 units on the tile, all units exceeding the number of food provided on the same tile would lose 1 hp next turn. Keeping units on the same tile unable to feed them could result in their death.
- units reduce the food yield would of course also be reflected in the yields of the cities using the tiles (each unit, with specific exceptions such as nukes or missiles and many others (armies and transports), must be fed, enemy units by default prevent cities from using the tiles, friendly units could therefore use at most half of the yield to prevent abuse (the logic is to favor your own citizens over friendly units), so
a tile used by a city giving only 1 food would not feed any friendly units,
a tile used by a city giving 2 food would feed 1 friendly unit and the remaining 1 food would go to the city,
a tile used by a city giving 3 food would feed 1 friendly unit and the remaining 2 food would go to the city,
a tile used by a city giving 4 food would feed 2 friendly units and the remaining 2 food would go to the city,
etc.
);
- units stationed in cities would consume the food collected in the city (your own units should be prioritized over your citizens on the tiles around cities, but inside cities it should work the other way around (this is a great place for government type influence), so
if a city only has a food surplus of X, it is only able to feed X units, but it stops its growth. All other units will starve in the city, unable to heal.
If a city has a food surplus of only Y and there are Y-1 units inside the city, it will grow by 1.
Generally if a city has enough food supply for its own citizens, it should not be possible to put it into a starvation state due to too much military presence in the city. The only exception should be units serving as Military Police (each government type has its own Military Police Limit).
I imagine some government types might want to keep at least a minimal +1 growth at the expense of starving excess troops (probably types with MPL around 0).
Conversely, some less considerate government type to its own citizens like fascism (with high MPL) might let its citizens starve at the expense of the excess troops in the city, resulting in the city starving and possibly shrinking, so the AI should try to find cities, terrain infrastructure, or unused tiles to move the excess troops out of the cities to.
)
Some might argue that cities usually have many dozens of units in them, and thus such food-intensive rules would complicate things considerably and cause a large overall food shortage. I think that new options for generating food in cities can bring the whole system back into balance and make up for the loss caused by experimental food consumption by units. Then further, if we could get the AI to deploy its excess units based on food consumption, it would relieve the busiest cities and dilute the overall burden. Lastly, I wouldn't even worry about additional flat benefits for dumb AI depending on difficulty, similar to the unit support bonuses. Something like additional free food support for tiles and a food bonus for each city that would indicate the amount of AI units on the tile and in the city, for which the food consumption rules would not apply. I'd also be happy to hear any comments or potential issues that would undoubtedly arise, as I hope I'm not the only one who sees the potential beauty in combining unit limits and food consumption by units on the tile.

If Lua is the answer to these expanding complex requirements and would provide the key to set things up your own way, it would of course be utter fantasy. Even if it's just the first small step of many. I can't help but hope, but I better ask again for the record. Is Lua the answer to everything I mentioned above, or what is Lua not the answer to?
 
Hello and happy new year. Does that happen for every autosave or just the ones from a particular game? I have a save that reliably crashes if I load it after loading some scenarios, but works if loaded first thing after starting up the game. I investigated that issue once and found it was related to the minimap somehow, as if the game wasn't resetting the minimap properly between the two saves. I'm not familiar with that part of the code so I wasn't able to see what exactly the issue was and in the end I decided it wasn't worth the time to look deeper. That might be the same bug you're seeing.

It happens each time I load auto-saved game after the first time.
 
Flintlock, for what it is worth, in my considered opinion the detection range for radar and sonar is a reasonable compromise between what both are capable of doing. I would not recommend any changes.
 
I think so. As I recall, chopped status is unrelated to LM terrain, so you can chop each tile once regardless of what kind of forest is or was on it.

I've gotten several requests now to make aqueducts & hospitals sellable so I'll try to prioritize that. I expect it would be a simple change.
It should be possible to combine building requirements like you described, I'll add that to the list and hopefully get around to it.
Fast roads would be doable too and actually very simple. The way limited railroad movement works right now is that the cost of moving along a railroad is scaled by the number of moves the unit's type has. To make RRs work like fast roads, all you have to do is not apply that scaling. It's so simple I ought to have done it long ago, you might be the first to ask.

Cheers,

I tried the LM forests but soon remembered why I don't use LM terrain: there's that graphics glitch with the overlay that spoils the look too much.

Getting rid of aquadcts will be nice, and the building requirement. I have a few wonders tied to this, build six X then you can start the wonder Y, which the AI generally tries to build it in a completely unsuitable small settlement instead of one of the big ones actually containing an X.

A flat bump on the road speed would be ideal: everything goes faster, but not too fast, I only really wanted a small increase. Although what you describe sounds similar with a low scale set, perhaps I am using it wrong? Currently it is set at 8, and everything appears moves at that, even over mountains..I assumed this was how it worked, you just set the most you wanted. I chose 8 so nothing actually got slower over a road. I'll experiment.

I can report the AI has, as yet, not suggested I build the same unit when the number limit is reached and I've had no free phantom units when switching from unit to building.

A big thank you for the error reports BTW,.would be a real pain without them.

CML
 
Great news! I think that could add more tactical depth to the game (Need for large-scale troop movement for attack or defend territory without "stacks of doom", ensuring supply routes for Campaigns, Battles at geographical bottlenecks with limited supply opportunities ... ).
I'm really excited! 🤩

However, it makes sense to exclude cities from the unit-limit-per-tile to avoid bugs, especially with AI behavior

Oh boy another big vote for this! Near llimitless stacks is just odd. This would change things so much and would be an easy change to add to a mod (some of these features are too good to miss but it does means making a lot of config file edits). It has been on my wish list for ages, I asssumed it would be too tricky. Only snag is units, as I understand it, won't be able to pass through a stack. So your mass of pikemen can't let a cavalry charge through their ranks without moving elsewhere for a turn potentially letting the enemy through afterwards. Might run into trouble making barriers for yourself too. Also have to allow for airdrop (or teleport as I use it).

I had envisioned city limits, sounds like that might be tougher. Also, sorry, needs to be by unit type? My 'air' units are actually spells, which (in my mind) are stored in tiny globes of power so no limit required. And we need to remove land limits on sea tiles or you might have to send a fleet of ships out only half full because you've reached the limit, when logically the land units are all inside the ships, already limited by their transport capacity.

Quick one: do you have access to the way the AI selects a defender when a city is attacked? Currently you've no choice and sometimes it really isn't what you would pick. I hankered after the idea of flagging units as 'garrison units' so they would always be the first in line, so you can pick replaceable ones and not that summoned specilist unit that you don't want to lose.
 
Back
Top Bottom