Canals

[RandyG]

I am new to modding so I am not sure if this is an SDK, XML, or neither question. I would like to make a mod that allows workers to create canals. I can think of two ways to do this.

Currently there are 4 domains: sea, land, air, and immobile. For this method to work, I would need to be able to make a 5th domain, canals. Then I would need to figure out how to allow workers to change the terrain type from land to canal. Finally I would need to figure how how to make a promotion allowing units to access the canal domain. To me this seems to not be possible using just XML, and from what I can tell this seems unlikely to be possible using SDK. I have used XML but not SDK.

After giving up on the previous idea, it struck me that land and sea units can access cities, so why not figure out how this is accomplished and replicate it for a canal improvement. However, from the files in the Gameplay/XML folder, I cannot find anything that sheds any light on how land and sea units are allowed in cities.

Can anyone tell me how I might get either of the these two methods to work or suggest a better way? Also how ever this is accomplished I would like to be able to build roads on canal improvements.

Also, I read that forts in BtS could support land or sea units. I don't have BtS so I am not able to see how this is done for that, but maybe someone else can.

 

[ww2commander]

Minus SDK, all of your ideas won't work.

This idea/request has been floated a few times, but it just is not possible with the current tool and data set available.

 

[RandyG]

That is pretty much what I thought, and I was sure others have thought of making canals before. Still it seems that whatever is allowing land and sea units to occupy city tiles should be accessible for other purposes like a canal improvement.

 

[Spatzimaus]

Still it seems that whatever is allowing land and sea units to occupy city tiles should be accessible for other purposes like a canal improvement.

Never, ever assume something like this. This is something a lot of new modders can't get past; they assume that just because X is possible, a very similar Y must also be possible. What you're missing is that a LOT of stuff is completely hard-coded inside the engine, like how cities allow for that sort of stacking. We don't have any ability to modify that hard-coding; as a result, no matter how obvious you think it'd be, you just can't modify that functionality to allow for the things you're looking for. There's just no accessibility to speak of.

You see, the game already allows land and sea units to stack; what it doesn't do, however, is allow a tile to act as both land and sea, except for cities. How do I know this? Because, interestingly enough, you can give naval units the "CanMoveImpassable" flag (the one that lets helicopters move over lakes and mountains) to allow them to sail across land. My own mod actually has several all-terrain units that take advantage of this. And because they count as naval units, they can stack with land units in the same hexes. Unfortunately, you can't turn this into a canal system because there's no wasy way to make those land-moving naval units hold to a specific path.

Now, you could get around this in a very simple way, by creating two linked coastal Improvements and having a unit that moves onto a hex adjacent to one to automatically teleport to the other (but at a cost in movement points). Lua can do something like this. But creating a canal/river route along which units can move/attack as normal? That's just not possible with the tools we've been given, and no matter how obvious you think it might be to do something like that based on some other systems, it just can't be done well without the SDK.

 

[RandyG]

Now, you could get around this in a very simple way, by creating two linked coastal Improvements and having a unit that moves onto a hex adjacent to one to automatically teleport to the other (but at a cost in movement points). Lua can do something like this. But creating a canal/river route along which units can move/attack as normal? That's just not possible with the tools we've been given, and no matter how obvious you think it might be to do something like that based on some other systems, it just can't be done well without the SDK.

This is an interesting idea. I have not played a mod that featured teleporting, so I would have never imagined doing it this way. Unfortunately, I won't have the time to learn what I would need to do to implement this until later in the summer. Of course the ability to attack from some inland canal tile would be nice, but I can be satisfied by the teleporting implementation.

 

[Spatzimaus]

Of course the ability to attack from some inland canal tile would be nice, but I can be satisfied by the teleporting implementation.

Actually, being able to attack from inland canal tiles would be much less realistic. A naval vessel going through the Panama Canal is pretty much defenseless while it does so. And remember, turns are supposed to be an abstraction for YEARS of movement, so realistically a unit would pass from end to end in a blink. But let's get away from the realism argument for the moment, and talk mechanics.

There are two basic problems with the teleporting canal method:
1> The AI would have no idea how to use it. When deciding to go between points A and B, it won't realize that there's a shortcut; the AI will either decide not to bother with that path, or it'll pick the long, circuitous route around one of the continents.
2> The triggers aren't easy. You can use the UnitSetXY GameEvent (which, despite its name, is actually a listener for unit movements and not a movement Set command) to see when a unit moves into the right area, but A) listening to every unit's movement commands would add a lot of overhead, and B) you can't gauge intent easily. If the trigger was "move into a coastal hex adjacent to this Improvement" then it'd trigger even if your intent was to just sail down the coast and not use the canal.

There are actually a few other options you could consider. For instance, I liked the Airlift mechanism from Civ4, and wanted something like it in Civ5 (albeit not quite as abuseable). So in my Ascension (future era) mod I have an Aerospace Complex building that, when a unit starts the turn inside a city, it gains a temporary Airlift (range-12 paradrop) promotion that is removed on the next turn, unless of course the unit is still in a city that has the right building. This method is messy, but it has the advantage that the AI can use it; since the unit will have the promotion at the start of the turn, the AI will take the paradrop into account when deciding where to move on that turn. (I then added a "Space Elevator" wonder that does the same thing, but with a range-99 "Orbital Drop" promotion.)

So in theory, you could do the same to solve this issue. Create a Canal improvement that can only be built on Coast tiles and represents an entry into the canal network. If a naval unit starts a turn in (or near) that hex, it gains a temporary promotion that allows it to move across a landmass. The easy option would be a Paradrop effect, which the AI already knows would require it to land in water. That's because land hexes would still be impassable, and would limit options in the same way that a paratrooper can't choose to land on a mountain hex. Graphically it'd be a mess, since you'd have to use the paratrooper animation, but it'd work and it's something the AI's already familiar with. It wouldn't stop the AI from choosing to go around a continent, depending on exactly where it ended its previous turn, but it could happen often enough to be relatively balanced.

The HARD option would be to give the unit the CanMoveImpassable ability, which'd allow the sea unit to sail across land hexes normally (meaning even easier for the AI to use). I use this mechanism in my own mods to create "All-Terrain" units that can move across both land and sea.
There are just two major issues with this idea:
> The unit would be able to attack while in the middle of the land
> If it ends the turn on land, a sea unit would usually get teleported to the nearest ocean hex. Depending on geography, this might be really abuseable or really bad. And note the "usually"; sometimes, the unit rarely just dies when this happens.
Note that most early naval units end their turn by attacking, so combining these two problems is even worse, although you can fix that by having the temporary promotion also give the "can move after attacking" ability while the naval unit is sailing across the plains. Of course, this becomes really abuseable for a human player.

The reason I say this is the hard option is that you'd almost definitely need to add some sort of additional overrides, probably in Lua, to the movement command, suck as a DoTask override to move straight to the nearest water on the opposite side of the land. At the very least you'd need some sort of selective impassability for certain terrain types to keep it from trying to sail through forests or mountains. This is actually not as hard as it sounds, since this temporary land-sailing promotion can also add entries in the UnitPromotion_Terrains and UnitPromotion_Features tables, both of which have Impassable flags to flag a particular type of terrain or feature as off-limits. So you can easily make any rough terrain impassable to land-sailing ships, and since these tables also have a PassableTech option, you can even add a technology trigger to override any of these. (That is, maybe at later techs your canal-using units can go through mountains or jungles, like Panama, while early-era canals limit you to Plains, Grassland, or Desert like the Suez canal, the ones in Germany, or the one the Persians used to connect the Tigris to the Euphrates.) You could do this already by using multiple promotions, since you're awarding this all through Lua anyway, but the PassableTech option saves you a promotion slot, which are in short supply.

The biggest issue with all of these is the same issue all AIs deal with: how would the AI decide where to place the triggering Canal improvement? The AI's Flavor system is extremely limited, and it's very hard to teach it that building 1 of something is good but putting many in the same area is bad. You can use a CanConstruct Lua override to prevent it from placing several copies in a small area, but the base issue remains: the AI wouldn't understand where the best place to create the Improvement would be. It might pick a spot on the coast that's too far from any opposite shore, meaning no naval unit could ever get across naturally. Or, if you use the straight teleport method, it might try to place two ends of a canal halfway around the world from each other, which is either really abuseable or really stupid.

That means that you might actually be better making it city-based instead of Improvement-based. That is, if you build a Canal building in a coastal city (probably require a Harbor first), then any naval unit that starts its turn either in the city or in an adjacent hex gains a temporary promotion to move across land, either through the paradrop or the canmoveimpassable method. (This'd still require Lua to implement, but the logic's fairly simple, and I've basically already done it in my mods for the airlifting ability.) Since it's not an Improvement, it'd be fairly harmless; the AI would never try to build one in a bad spot, and all of the usual spacing restrictions for cities would serve the purpose of keeping the AI from trying to stack a lot of them into a small area.
Also, I forgot to mention: the AI doesn't use Flavor values for Improvements. It only decides whether to build an improvement based on the yield it produces for the hex. So if your Canal improvement doesn't add food, production, or gold, then the AI will never built it. (Or if it does, it'll try to immediately destroy it again to build something more "useful".) Yet another reason to go with the city-based option instead, although there's actually a workaround if you really, really don't want to tie it to cities: create two improvements, A and B, both with the name "Canal". A has some huge yield, making it desirable to the AI, while B has a cost of -1 (and so can't be directly built). When an improvement of type A is created, it's immediately replaced with one of type B by a simple Lua command. Since B can be set to indestructible, the AI can't get stuck in a loop. Then, type B is the one you use to trigger the canal access. (I've used this same Improvement-based method in my own mods for planting Forests and Jungles, terraforming terrain, and so on. You build a temporary improvement that claims a large yield, and then a Lua function adjusts the terrain and removes that improvement or replaces it with a "safe" version that won't keep triggering the logic and which has a weaker yield. It's a bit messy, but it definitely works.)

------------------------------------

Bottom line: it's possible. It'd be messy, it'd be prone to all sorts of abuses, and the AI still wouldn't use it as often as it should. But it CAN be done if you really care, using only XML and probably some fairly simple Lua. You don't actually need the SDK to do something like this, you only need it if you want to do it right.

 

[RandyG]

WOW. thank you for your lengthy and concise response. Lot of good insights here. I downloaded your mods a while back, so I guess I need to take a deeper look at them now. I really have no idea how the AI makes any decisions, so this is a great help in understanding some of the logic. I look forward to playing around with these ideas to see what works best.

 

[Spatzimaus]

I really have no idea how the AI makes any decisions, so this is a great help in understanding some of the logic.

The short version: the AI is a moron.

The long version: Whenever the AI wants to make a decision about which tech to research next, which policy to pick, which unit to build, etc., it makes a list of all possible options. Rarely, there are hard overrides; the AI might decide that it NEEDS another worker, so it skips the rest of the process and just queues up a Worker. This is commonly encountered in Policies, where the AI will flat-out refuse to open a third policy branch if it's already got two unfinished ones open. You also see this with Wonders; the AI has a hidden rule that it'll never try to build anything that'd take longer than 50 turns to complete, so that it won't try to make an expensive wonder in a dinky border town.

Barring those sorts of special exception, the AI just takes all of the available options, and weights them. In most cases, this weighting is by Flavor, where an AI that prefers military style will favor the options that have high Offense, Defense, etc. ratings. As I mentioned before, Improvements are sort of an exception in that the game uses the yields of the improvement directly instead of considering Flavors. But no matter how it weights them, all options are still possibilities, even if their probabilities are low. Then, it just does a random draw to see which option it picks.

As a result, the AI almost never "plans". It never decides that it needs to take tech X next because what it REALLY wants is tech Y that comes after that; it'll pick X or Not X purely based on X's flavor values. And ONLY Flavor values; the AI has no ability to check the actual effects of each tech, to know whether or not it actually wants that tech. If a tech unlocks a Wonder, the AI won't actually know whether or not that Wonder has been completed yet; this is why technology Flavor values do NOT include any Wonders. Also, if a resource-harvesting improvement unlocks at that tech (like a Plantation or Offshore Platform), the AI won't actually check to see if it has the resource that Improvement links to. So again, it's a moron.

Since the process is random, the AI really has no control over the order the buildings in a city get completed in, which means an AI city almost never specializes, and the AI's a bit slow to prioritize whatever building or unit it just unlocked. Statistically speaking it all works out fine in the end, but this is a big part of why the AI needs such a large handicap when facing a player. I tried to mitigate this in my own mod by hybridizing the buildings. That is, no more pure +Happiness, +Culture, +Research, etc. buildings; instead, some Happiness buildings add Culture, some Culture buildings add Research, some Research buildings add Gold, and all kinds of buildings add Happiness. The result of this sort of mixing is that the AI is not nearly penalized as badly for picking an inefficient series of choices, as it'll get a little bit of everything as it goes, just like a player would in the same situation.