Resource icon

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

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.
...
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.
This would be difficult since vision range is hardcoded. I believe the way it works is that, when a unit steps onto a tile, the game loops over the nearby tiles within a range of 2 and computes whether or not each is visible from the unit's position, and the number of tiles to check is hardcoded into the loop. I don't remember that code exactly, which is why I'm a bit uncertain, but that's how vision works in the other cases I've seen like recon missions. Changing a hardcoded value is not hard but de-hardcoding it, making it variable, is. I could maybe make the game loop over more tiles to extend vision but varying the loop based on units' radar ability would be difficult. Anyway, anything's possible with enough effort.

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?
Lua's a pretty simple language. If you're already familiar with programming at all, you'll be able to pick it up very quickly. The big question about integrating it is whether it's worth the trouble. How long that would take depends on, for one thing, how deeply it is to be integrated, for example limiting it to game logic and ignoring interface, music, multiplayer, and AI, would mean there's a lot less to do. For another thing, how difficult it would be also depends on how different the Lua interface is to be from the base game's internals. The internals are pretty crude, f.e. to loop over all cities in the game, you'd do a for loop from zero to the maximum city index, checking at each step if the slot in the master city list is occupied and, if so, grabbing the pointer to the city. In Lua you'd want a nicer layer on top of that using Lua's iterators, and in fact I set that up as a proof of concept a while back. The problem is those sort of things take time.

If I were to commit to Lua then, yes, I'd put everything else on the back burner for a few months while I worked on that. A few months wouldn't be enough for everything but I expect I would be able to get a nice interface to most of the game logic set up in that time. Another option is to do it incrementally, so I'd just set up some basic Lua functions and then as people request features I'd flesh out the interface where necessary to make each thing possible. A third option I've been thinking about is using AI to speed the process along. I already have much of the game's internals mapped out in the language of C & C++ so just making that available to Lua could potentially be a task mindless enough for an AI. The problem, as always, is that once you've thoroughly specified the task and broken it down into small enough pieces for an AI, you've already done most of the work of solving it.

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?
One potential issue I can see is that yields in cities are cached, they are not recomputed each time they're needed. So it would be necessary to update the nearby cities each time a unit moves. That shouldn't be too difficult, though, as it's similar to blocking tiles occupied by enemy units, which the game already does. This is the sort of thing I'd want to implement through Lua just because the game rules involved would be so complex. C3X right now isn't a good platform for those kind of things since releases are so infrequent and it's hard to allow for elaborate customization through config files.

Another issue is passenger units. If they get a free ride in terms of food, that could be exploited by human players, but if they still need to eat, that would make invasions almost impossible especially for the AI.

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.
Fast roads just means roads with a higher movement rate than regular, which is 3. I think that's what you mean by "flat bump" in road speed. In the next version you'll be able to set, for example, limit_railroad_movement = 5 and limited_railroads_work_like_fast_roads = true then units will move along railroads as if they were roads with a movement rate of 5, so riflemen will move 5 spaces and cavalry 15.

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).
Yes, not being able to move through stacks will be a major nuisance if you set the stack limit too low. Also, thanks for mentioning airdropping, I had forgotten about that. I'll make sure to block airdropping onto tiles that can't take any more units.

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.
The way it'll work, at least to start, is that there will be no limit on units in cities. It's hard to enforce a limit there anyway because cities can add units to their own tiles by producing them, and it would be annoying to have land and sea units fighting over space in cities. Units that are contained in others won't count towards the stack limit so there will be no problem about passengers on transports crowding out other naval units. That also means armies will only count as one unit toward the stack limit, not sure if that's the best rule but this whole thing is kind of an experiment for the moment.

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.
I've seen that code before but I can't say I'm familiar with it. Interestingly, what you suggest is like the reverse of the king flag, which makes units the last to defend on their tile. I added an option to change that behavior a while back so it might be possible to do the reverse too.
 
Regarding that last request, could the "AI strategy" flags perhaps be exploited for that purpose, i.e. that units flagged with the "defender" strat would always be chosen as city-defenders preferentially over "attackers", even if the defenders' remaining HP-fraction * D-value * Def-bonus products are lower than any attacker's (which seems to be -- roughly -- how the game picks the next defender)?

(I also hate it when the game forces my 5/5 eKnights to defend first, before my 3/3 rPikes!)
 
Last edited:
How long that would take depends on, for one thing, how deeply it is to be integrated, for example limiting it to game logic and ignoring interface, music, multiplayer, and AI, would mean there's a lot less to do.
Personally, I am most interested in game logic and AI. Maybe a little interface. I guess that puts me in the deep integration category.

If I were to commit to Lua then, yes, I'd put everything else on the back burner for a few months while I worked on that. A few months wouldn't be enough for everything but I expect I would be able to get a nice interface to most of the game logic set up in that time. Another option is to do it incrementally, so I'd just set up some basic Lua functions and then as people request features I'd flesh out the interface where necessary to make each thing possible. A third option I've been thinking about is using AI to speed the process along.
So it depends on how many things on your list you intend to finish before you start including Lua in the next version. Maybe it would be good to share what things will have to be put on hold for that, because I don't know who among the others is waiting excitedly for what? On the other hand, I've noticed that you like to surprise people with new stuff, so maybe you don't want to reveal everything you have in the works. And given that I'm very excited for this whole food experiment myself, I'm all for starting to integrate Lua as soon as possible so I can fiddle with the complex rules myself in 6/9/12 months, maybe. But I think that if you start with the first approach mentioned, the second one probably won't be avoided in the future anyway, so you'll end up with a mishmash of all the approaches and everything will undoubtedly take time to work out all the unexpected bugs. Still, I'm probably in favor of the first approach.

Another issue is passenger units. If they get a free ride in terms of food, that could be exploited by human players, but if they still need to eat, that would make invasions almost impossible especially for the AI.
Yes, it's true that I personally work with scaled food tiles (desert = 0; tundra, mountain = 1; hill, sea = 2; plain, coast = 3; grassland, ocean = 4; flood plain = 5) with irrigation giving 2 food and citizen consuming 4 food, so I'm kind of forgetting that water tiles are pretty poor for food in the base game. However, deserts would still be literally deadly, which reminds me that units without hps like workers shouldn't be dying because of starvation.

The logical solution, in my opinion, would be to count the food cost of units transported in transport ships:
1) to the own largest city having a port with an allowed sea trade and having the largest food surplus.
2) If no such city exists, to the largest coastal city with the largest food surplus.
3) If no such city exists, to the largest inland city with the largest food surplus.
4a) If there were no cities with allowed sea trade, coastal, or inland with food surpluses, the food surplus requirement would be dropped and the burden would be placed on non-growing cities in the same manner.
4b) If a city already has an empty box of stored food and is in danger of shrinking, a popup should appear with an advisor asking whether
A) to break the food link (let the unit starve),
B) automatically search for a replacement, or
C) let the city shrink.
5) If there were no cities and only settlers, the non-feedable units on the ships would slowly starve.

It is then important that such a burden can be automatically distributed among the entire network of cities according to the scheme outlined above. Obviously, for simplicity's sake, it would be enough to search for the cities with the largest food surplus instead of points 1), 2) and 3).
I don't know if the game internally keeps track of the number of all units currently being transported, but I think it would be handy if units supported in this way were displayed in a row with the food eaten and stored in cities (a single unit icon over the stored food means that this food goes to this unit).

The moment units board their ship and are not in a city, a food link is created.
The moment the transported units leave their ship, the food link is removed.
Food links shouldn't randomly move between cities at the end of turns.
The link should be terminated either by unloading the unit from the transport or manually in the city by clicking on the supported unit icon in the food row.
At this point, if one could also manually select an alternate city from which the transported unit should take food in this way, that would of course be absolutely ideal.

Perhaps some alternative to creating god knows how complex food links would be to also use adjacent unused tiles in cases where a given tile would not be able to feed all of its occupants, assuming the ocean would give at least 1 food. In other words, units would suck food from adjacent tiles to feed themselves. So is this a better or worse solution?

If anyone has a simpler or more elegant solution, please share it. I certainly don't think that transported units should have their food consumption forgiven.

On a complete side note: The rows with production shields in cities are not displayed correctly for buildings costing more than 1080 shields.
 
Hi Flintolck and Happy New Year,

I do not know if you plan to add my request about visibility of the resource within borders to the next update, that would be good of course, but what realised that even if you will do that, the resource will be visible to faction which owns the building which produce that resource and therefore it won't be visible for other players. What I wanted to achieve is cultural or religious uniqueness which could be emphasized by the resource available to the faction which produce it but is also visible to other players, not for trade. Let's say the Wicker Man resource which presents religious believes of Celtic faction.. Is it doable?
 
I've just recently started the experience, and wow! This is a real (and literal) game changer. Thank you Flintlock for this amazing work.
Here are my few cents:

- When you buy the enemy plans, grouping the units in the overview does not seem to work all the time (see attachment). Some units are grouped, others not.
- Making units dependent on buildings is a dream come true. But having a mod with 3000+ different units, it would be very tedious to put them all in manually. Is it possible to fetch just a part of the name? For example, I'd like to only allow cities to build major warships if they have a major port. All my ships are named with their hull designation, for example XXX Class BB oder YYY Class CA. Would it be possible to make a code like this:

building_prereqs_for_units = Major Port: "[all] Class CA" "[all] Class CB" "[all] Class B" "[all] Class BB" "[all] Class CV"

?

That would be awesome. And it could even help with other units, for example:

building_prereqs_for_units = Mercenary Camp: "[all] Mercenary"

instead of typing "Viking Mercenary", "Nubian Mercenary" etc.

Another nice feature would be to attach all units that are dependent on a certain resource to a building, for example all Horses needing a stable or all vehicles with a certain resource combination (for example, iron + oil) needing a workshop.
 

Attachments

  • Untitled-1.jpg
    Untitled-1.jpg
    140.4 KB · Views: 35
Last edited:
Ares, all these problems can be solved elegantly by virtual local resources (strategic or luxury resources that can only be produced by a building and don´t become a part of the trade net of a civ): https://forums.civfanatics.com/thre...d-and-much-more.666881/page-113#post-16664328

This is a method I created for CCM 3 to deal with thousands of units and that is working very well. Per example the virtual strategic resource "Capital Ships" produced in CCM 3 by several different SWs allows that battleships and dreadnoughts can only be produced in the cities, that hold these buildings (and other harbor cities can only produce ships up to cruisers).

This method also allows, that several different buildings can be alternative prerequisites for another building.
 
Re: road movement.I've been playing my modified version for so long I've forgotten that I increased unit speeds since the mod originally didn't use railways and was frustratingly slow without them (it can now thank to C3X), so units have between 1 and 4 movement points. I set the limit railway to 8 and everything got jolly fast, including siege engines and zombies! Either way I've probably given cavalry too much, I didn't think they actually move at 12 on plain roads though, I though it was eight, cripes, perhaps I have changed the road speed and forgotten I did.

So, as I understand it: roads: 1/3 per MP default. Railways can be limited to a fixed number currently. The future 'limited_railroads_work_like_fast_roads = true' feature would take that fixed lower limit and then follows the fast road rule of thirds right? So If I set the railway limit to 2 and enabled fast road anything with 1 MP would move at 6, 2 still at 6. 3 at 9 and 4 at 12. This fixes super-fast engines and zombie.

tgs282: Defender choice, yes good idea, putting anything flagged as defender first is logical and (hopefully) easy[ish].

Ares de Borg: I feel you: guess what I've been doing over the last few days :) Great features, but oh boy, what a lot of editing!.
 
Thank you Civinator, but it would be still a lot easier with a simple text entry. :) I will keep your proposal in mind, though.
 
- Making units dependent on buildings is a dream come true. But having a mod with 3000+ different units, it would be very tedious to put them all in manually. Is it possible to fetch just a part of the name? For example, I'd like to only allow cities to build major warships if they have a major port. All my ships are named with their hull designation, for example XXX Class BB oder YYY Class CA. Would it be possible to make a code like this:

building_prereqs_for_units = Major Port: "[all] Class CA" "[all] Class CB" "[all] Class B" "[all] Class BB" "[all] Class CV"
If I may, this sounds like a job for regex
 
Thank you Civinator, but it would be still a lot easier with a simple text entry. :) I will keep your proposal in mind, though.
You have the simple text entry with the method I showed above - and not with the tons of text entries in connection with buildings.
 
You have the simple text entry with the method I showed above - and not with the tons of text entries in connection with buildings.
But you would still need to tag the resource seperately in every single unit entry in the editor, right? Forgive me it I didn't understand that correctly.
 
But you would still need to tag the resource seperately in every single unit entry in the editor, right? Forgive me it I didn't understand that correctly.
:yup: Yes, but this is the only resource you have to tag for those units to limit them to special cities.

Edit: This is the small part of the scenario.c3x_config file in CCM 3 for this function:

scenario.c3x_config file.jpg


If I would have listed all the battleships, dreadnoughts, battlecruisers and several tiers of pre-dreadnoughts in that mod behind each of the buildings that allow the production of capital ships, the scenario.c3x_config file would have been at least one page bigger, alone by that option - and I am not sure if the scenario.c3x_config file will still work properly if it has "several pages" by adding such a big amount of entries.

Additionally for me it is much less work to do the limitation by a simple click in the editor for each of those units, compared to correctly writing a big list of these units (also this list can be copied and pasted behind each one of those buildings).
 
Last edited:
Without further delay, here's R21 Preview 1: https://github.com/maxpetul/C3X/releases/tag/Release_21_Preview_1. The additions are mostly small-ish things that were suggested recently and two bug fixes. Here's the changelog:
  • Allow perfume amounts to be specified as percentages
  • Option to limit how many units can share each tile, named limit_units_per_tile
  • Adjustable chance for max one HP units to be destroyed by nuclear strikes
    • Controlled by config option chance_for_nukes_to_destroy_max_one_hp_units
  • Add limited_railroads_work_like_fast_roads option which does just that
  • Option to allow sale of buildings like aqueducts that uncap population growth, named allow_sale_of_aqueducts_and_hospitals
  • Option stopping non-sea detector units from revealing invisible sea units and vice-versa, named no_cross_shore_detection
  • Fix charm flag controling PTW arty targeting not working for reloaded games
  • Fix building unit prereqs interfering with unit limits

Regarding that last request, could the "AI strategy" flags perhaps be exploited for that purpose, i.e. that units flagged with the "defender" strat would always be chosen as city-defenders preferentially over "attackers", even if the defenders' remaining HP-fraction * D-value * Def-bonus products are lower than any attacker's (which seems to be -- roughly -- how the game picks the next defender)?
I could modify the game's logic, which already checks the king flag to deprioritize some units as defenders, to check for other things instead. As you suggest, I could modify it so that all units without the AI defense strategy are considered king-flagged for the purposes of selecting a defender. I don't see any reason that wouldn't work.

So it depends on how many things on your list you intend to finish before you start including Lua in the next version. Maybe it would be good to share what things will have to be put on hold for that, because I don't know who among the others is waiting excitedly for what? On the other hand, I've noticed that you like to surprise people with new stuff, so maybe you don't want to reveal everything you have in the works.
I don't have much in the works, really. My plan is to look into the 32 MB save limit before R21 is finalized. That's something I've been putting off for almost a year now, and it's something that should be done before the city limit is properly removed. After that, hopefully for R22, I want to try lifting the city limit. I'm not certain I'll be able to do that, but it's an interesting challenge at least. I've removed many of the game's other limits and the city limit still stands as the big one, difficult and much requested but potentially doable (unlike the 32 player limit). Meanwhile, I'd still add bug fixes or small additions requested in this thread.

That means Lua integration is still a ways off. However, I've been experimenting with it on and off for the past couple of years, and have so far reimplemented the disorder warning feature in Lua. That WIP branch is on the mod's GitHub, for example you can see the method behind the disorder warning, CheckHappinessAtEndOfTurn, here: https://github.com/maxpetul/C3X/blob/integrate_lua/script.lua. I think it's coming along nicely, for example there are nice Lua iterators over player cities and citizens within each city, and a nice method to open popup windows. However there is still a lot of work to do.

Perhaps some alternative to creating god knows how complex food links would be to also use adjacent unused tiles in cases where a given tile would not be able to feed all of its occupants, assuming the ocean would give at least 1 food. In other words, units would suck food from adjacent tiles to feed themselves. So is this a better or worse solution?
Sucking food from adjacent tiles is definitely a lot simpler, which in my opinion makes it a lot better. Complex rules aren't just harder to implement, they're also harder for players to understand and tedious if they require micromanagement.

Hi Flintolck and Happy New Year,
I do not know if you plan to add my request about visibility of the resource within borders to the next update, that would be good of course, but what realised that even if you will do that, the resource will be visible to faction which owns the building which produce that resource and therefore it won't be visible for other players. What I wanted to achieve is cultural or religious uniqueness which could be emphasized by the resource available to the faction which produce it but is also visible to other players, not for trade. Let's say the Wicker Man resource which presents religious believes of Celtic faction.. Is it doable?
Hello and happy new year to you too. I'm not sure about making resources untradable, I would easily be able to gray out resource trade options on the diplomacy screen but I wouldn't know how to stop AIs from trading those resources among themselves. I would have to investigate more about how trade works. Other than that, the game has a function I've called get_resource_visible_to which takes a tile and a civ ID and returns the resource (if any) that's on that tile and accessible to the given civ. I could easily modify that function to add conditions like the resource must be within the civ's borders, if that's what you want.

- When you buy the enemy plans, grouping the units in the overview does not seem to work all the time (see attachment). Some units are grouped, others not.
How odd. I'll have to look into that.

- Making units dependent on buildings is a dream come true. But having a mod with 3000+ different units, it would be very tedious to put them all in manually. Is it possible to fetch just a part of the name? For example, I'd like to only allow cities to build major warships if they have a major port. All my ships are named with their hull designation, for example XXX Class BB oder YYY Class CA. Would it be possible to make a code like this:
building_prereqs_for_units = Major Port: "[all] Class CA" "[all] Class CB" "[all] Class B" "[all] Class BB" "[all] Class CV"
It would be possible to allow for that sort of thing, if a bit awkward. One problem I can see is that "[all] Class CA" is a valid name for a unit on its own, so it's ambiguous whether you want the wildcard or not. In practice, I'd use an asterisk instead of [all] as a wildcard since that's standard, but asterisks are still allowed in unit names.

So, as I understand it: roads: 1/3 per MP default. Railways can be limited to a fixed number currently. The future 'limited_railroads_work_like_fast_roads = true' feature would take that fixed lower limit and then follows the fast road rule of thirds right? So If I set the railway limit to 2 and enabled fast road anything with 1 MP would move at 6, 2 still at 6. 3 at 9 and 4 at 12. This fixes super-fast engines and zombie.
Not quite, there's not really any hard "rule of thirds" for movement, thirds are only relevant if you leave the standard road movement rate at 3 in the editor. If you change it to 2, then moving along a normal road costs half a move, and if you set it to 4, it costs 1/4 of a move, and so on. With the fast roads option, the same thing applies to railroads with the movement rate depending on the limit_railroad_movement setting. So if that setting is put at 5 with fast roads on, moving along a railroad will cost 1/5 of a move. If you still have the road movement rate at 3, the game will internally divide moves into 15 pieces so each move can be divided evenly by one road move or one railroad move.
 
Option stopping non-sea detector units from revealing invisible sea units and vice-versa, named no_cross_shore_detection
I see that it appears that you have no knowledge of shore-based underwater listening stations monitoring submarine and surface ship movement. The US has a large network of underwater listening stations both near shore and in deep water. A number of other nations have them as well. They have been around since the 1970s. Other monitoring options are magnetic cables looking for metal passing near them, although those as primarily shallow water stations. As for ships monitoring shore activities, the use of small drones relaying TV images to the ships is now fairly common. If you have that as an option to be turned on or not, that is not a problem. If it is automatically turned on, and has to be manually turned off, that would be a problem.
 
Option to limit how many units can share each tile, named limit_units_per_tile
Hooray! Not the one I expected to be ready first, but I shall boundary-test it to death :hammer:
Option stopping non-sea detector units from revealing invisible sea units and vice-versa, named no_cross_shore_detection
:thumbsup:
 
It would be possible to allow for that sort of thing, if a bit awkward. One problem I can see is that "[all] Class CA" is a valid name for a unit on its own, so it's ambiguous whether you want the wildcard or not. In practice, I'd use an asterisk instead of [all] as a wildcard since that's standard, but asterisks are still allowed in unit names.

Thank you, Flintlock. Enabling the * would be excellent.
 
Last edited:
Another breakthrough! The unit tile limit should prevent the AI from losing 20 units to a single nuke (though I guess it doesn't apply to cities?). Also, expensive things that have 1 HP like stealth bombers and gunships in my mod won't all be wiped out.

We finally have a limit to the SOD problem. Civ4 counters SODs having collateral damage. Is there a way to implement that? Charm bombard does target every unit in the stack but instead of bombarding normally it halves the defensive value. Unfortunately charm bombard units don't bombard cities and it can only happen once a turn so the AI has no clue how to use it. But what if the charm targeting of all the units on the tile could be changed into regular bombardment?

Although I'd hate to have to give up the charm special order for that. Adding units manually to the PTW targeting list is not practical in a mod with many flavor units. So maybe a separate list for charm units that would do collateral damage can be created? It's a lot easier to just add them onto a config patch list.

That way we can represent low yield tactical nukes like the M29 Davy Crocket that were meant to be fired at enemy armored formations quite close to friendly forces.
 
Hello and happy new year to you too. I'm not sure about making resources untradable, I would easily be able to gray out resource trade options on the diplomacy screen but I wouldn't know how to stop AIs from trading those resources among themselves. I would have to investigate more about how trade works. Other than that, the game has a function I've called get_resource_visible_to which takes a tile and a civ ID and returns the resource (if any) that's on that tile and accessible to the given civ. I could easily modify that function to add conditions like the resource must be within the civ's borders, if that's what you want.
If it cannot be modified further than I'll take what you have :) Thanks
 
but I wouldn't know how to stop AIs from trading those resources among themselves.
Just spitballing here, but could you make the AI infinitely value them in trade negotiations? That would at least take care of single player.

We finally have a limit to the SOD problem. Civ4 counters SODs having collateral damage. Is there a way to implement that?
That was the reason I asked about bombardment + collateral damage on a whole stack

Charm bombard does target every unit in the stack but instead of bombarding normally it halves the defensive value.
...but I forgot about that part. Charm is a separate action from bombard though, right? Meaning I cannot have a unit charm a stack by/while bombarding it.
 
Hello Flintlock. Happy New Year. Thank you for your great work.
1. Limiting movement on railroad. I looked at how these functions work.
In my scenario settings, the range of movement on roads = 6
limit_railroad_movement = 9
limited_railroads_work_like_fast_roads = true
With these settings, the speed of movement on the railroad is 1.5 times greater than on a regular road.
If a unit uses both types of roads during its movement in one turn, then a problem with the movement indicator may occur. It often shows that the unit's movement should end one tile closer (shows 2 instead of 1).
1736546261020.png

This happens in the following cases:
- when the unit first moved an odd number of tiles along a regular road, and then moves the rest of the way along the railroad;
- when the unit first moved a number of tiles along the railroad that is not a multiple of 3, and then moves the rest of the way along a regular road.
The movement range can be expressed using a formula.
Road movement factor = 1.5 (9/6), number of tiles traveled = a, railroad movement factor = 1, number of tiles traveled = b. The movement indicator will only show the correct information if 1.5a + 1b = 9. Is it possible to fix this indicator error, or should the movement factor be an integer?
2. Limiting the number of units per tile. Thanks for this feature.
But the unit limitation does not apply to city tiles. You can bring an unlimited number of units into a city. This will make sieges very difficult.
Also, workers who build improvements on a tile (roads, mines, irrigation, forts) do not allow other units to enter it. Is it possible to make an exception for all units working on a tile, or for a pre-defined list of units (engineers, workers or slaves)?
Thanks again for your great mod.
 
Back
Top Bottom