Ok, I'm taking a first look through the code and I see that Koma13 made it so you can build transport units in any city. I hear this code comes from Maniac.

What I'm not seeing is any modifications to the unit AI. Therefore, I assume that the AI might build transports in any city, but it will only actually load them on a coastal city.

Theres a boolean all over the unit AI code called bLandWar. This variable is set by the AI state of the area that the unit is in. As far as units loading onto transports, I might be able to change this from an area analysis to a distance-to-target analysis. The difficulty is that I don't think the target is known by the AI at this stage, I may have to do a separate calculation.

While I know absolutely nothing about AI or code details, my understanding was that there is no longer such a thing as a coastal city in the mod.

Ahriman is correct, isCoastal always returns true in DW.

I support the general goal of this thread, but you may need to draw attention to it from the BBAI forum and also the folks following TheLadiesOgre's thread.

The canonical goal of "Land Transport" is that on a pangaea or solid earth map like greatplains, a slow infantry unit should be carried by the land transport to a target city. Presumably the land transport is fast, but vulnerable, and therefore the AI should build an appropriate number of fast, strong (but not cargo-carrying) escorts.

If you can do this, you will become rich and famous. Or at least famous. At least at civfanatics. ... But could you also work on the starting location problem in the existing mapscript?

If you can do this, you will become rich and famous. Or at least famous. At least at civfanatics. ... But could you also work on the starting location problem in the existing mapscript?

Well, this solution might not work in a mod that needs land transport and sea transport. I'm purely focusing on the needs of this mod.

The problem with fixing the starting plots on Arrakis.py is that I need to control the size of continents. That is impossible under the current implimentation and will require a nearly gound up rewrite. That is going to be alot of work, and the results will not look very nice.

Before I do all that, I want to find out whats involved in AI all terrain transport. If I'm in for alot of work, I would prefer a large complicated solution to a large complicated work-around.

Another issue that concerns me is that if I can get the AI to load up for land wars, it may simply cause them to unwisely split their forces if they are low on transports, while the understrengh transport speeds ahead without the main body.

Well, I pumped up Arrakis.py to give me a pangaea, and I did a few tweaks to see if I could cause the AI to always use available transport no matter the distance. Probably because I'm on a pangaea, the AI is not building any transports at all. Tommorow I will investigate the production choice.

After some more investigation, I'm going to scrap my original experiment. I think I found the heart of the issue. There's a function called CvTeamAI::AI_calculateAreaAIType that decides for each team how to treat the different areas(continents).

For example, if you have cities in an area, and your enemies are more powerful than you in that area. The areaAIType is set to AREAAI_DEFENSIVE.

In order for an amphibious assault to happen, the continent you are on must be set to AREAAI_ASSAULT, which only happens when there are no enemies in this area. If there are enemies in an area, that area is generally set to AREAAI_OFFENSIVE. In a normal amphibious assault, the staging area will be set to AREAAI_ASSAULT and the destination area would be set to AREAAI_OFFENSIVE.

Unfortunately, a continent can only be one or the other. I don't know what would happen if you set an area to AREAAI_ASSAULT while there are enemy cities on that area. Transports would be built and loaded, but I'm not sure if they would attack those enemies on the area. If you switch to AREAAI_OFFENSIVE when everyone's ready to go, they may simply unload the transports and travel on foot.

I don't think this is insurmountable, but it is a bit complicated.

On a side note, I think I found a bug in this function. The function has been fairly chopped up by the better AI guys, so this may be due to something they did.

CvPlayerAI& kPlayer = GET_PLAYER((PlayerTypes)iI);

I think the index "iI" is a garbage value left over from a team loop. It is uninitialized. Not sure what this will break exactly, but it might prevent the proper massing of troops in the intended case.

I've read about these AREAAIs before in this post (http://forums.civfanatics.com/showpost.php?p=8165348&postcount=158) diagnosing a Planetfall issue.

It does sound like you've got to the heart of the issue. Good luck with finding a solution.

I've read about these AREAAIs before in this post (http://forums.civfanatics.com/showpost.php?p=8165348&postcount=158) diagnosing a Planetfall issue.

It does sound like you've got to the heart of the issue. Good luck with finding a solution.

Interesting thread. Do we have any units that are expected to cross water and attack on their own? If so they probably don't work so well. While I'm here maybe I could look at that as well. Apologies for not being aquainted with all our units, life keeps me busy.

That brings up some more questions regarding our units. Are all our attack units able to be transported? I assume from my investigation that suspensor gunships are sea units that can move on land and not attack units. Otherwise they would lose their brains on entering the ocean.

Do we have any units that are expected to cross water and attack on their own? If so they probably don't work so well.

Yes, thopters and suspensor gunships/frigates/destroyers are combat units that can cross desert.
But they are weaker than land units, so its actually a good thing if the AI doesn't try to attack you a lot with those by themself, they'll just get them destroyed.
Half the role of these units is as transport escorts.

Ok, after some more investigation I have a plan for the next experiment. I am going to set an area to the land war settings (AREAAI_OFFENSIVE, AREAAI_MASSING) if the proximity to the enemy cities is close, and set it to the sea war settings (AREAAI_ASSAULT, AREAAI_ASSAULT_MASSING) if the distance is long. This will cause the AI to build and load transports and such.

Transports moving to the drop zone(coast adjacent to a fairly weak city) do not appear to use the areaAI settings, so I should be ok there.

In order for the attack units to attack in an area designated for sea war, instead of walking back home, I'm going to treat the sea war settings as land settings in the unit AI when the unit is on or near enemy territory. Hopefully I can do that efficiently as the unit AI's appear to be a performance bottleneck.

Anyone see a problem with that?

cephalo,

very good thread, im all hopes that you can master something :))

Are there any major AI issues that I need to know about while I'm testing? So far I'm not seeing the AI declare war on each other, even with aggressive AI. Is that uh... my fault?

When I force a war with random declarations, I'm not seeing any stack of doom on transports. I think I broke something. The AI is building transports now and even driving around with a unit on board once in a while, but to no purpose. No cities have been taken except for barbarian ones.

I need to start at the beginning and hand execute the whole AI process. I'm still a little fuzzy on some things. I'm sure that with the proper knowlege this is doable.

Several people have observed that the AI is not declaring war often. I have not obtained any statistics on this yet. I recommend you do a run of vanilla archipelago and compare the number of DOW's. Although we do not need to exactly match archipelago, there are substantial gameplay differences between archipelago and everything else. So if you see that vanilla archipelago and DW are similar, the problem is with vanilla AI, not specifically with DW.

I tested 1.5 without my changes and I definately saw cities changing hands. I must of just disabled city attacks with my changes.

That's kinda the nature of this AI code, you can't just tweak things really without the possibility of cascading consequences. It's not object oriented at all it's just a big long ai function. If you make something happen in one place and another place was not expecting that to happen there, you will break something unrelated to what you wanted to change.

I am in the process of reading through all the AI code. The only way to control it is to fully understand it.

I am in the process of reading through all the AI code. The only way to control it is to fully understand it.

This is a very substantial undertaking. I wish you luck.

I'm getting more familiar with the code, and it's alot of work but I have to say it's an interesting read. I have some thoughts I wanted to bring up.

The idea of transport in Civ4 was always rooted on the need to get from one land mass to another. This is slightly different than real life, where there is the additional motivation of travel time. Sea travel historically had this advantage over land travel, but in Civ4, the AI would not load up a settler on to a boat just because it's faster to get to a different part of the same continent by boat. (across the mouth of a large bay for example)

Land transport actually does exist in Civ4 but it is abstracted. Mechanized Infantry for example is really just a bunch of soldiers loaded into a faster moving vehicle. Some games actually abstract sea travel this way also, where the land unit just becomes a boat when it enters the water.

By abandoning the notion of transporting for speed purposes, it allows the AI to bypass many important decisions by simply setting an AI state for each continent. Otherwise, you have to decide for every move whether it would be faster to take any available transport. Easy for the player, expensive for the AI.

I think I can rig the continent system to distinguish between a distant war on the same continent and a land war between close neighbors to preserve that computational efficiency, but then there is another problem for the AI in regard to large continents.

Let's say you have a large empire on a large continent which is shared with another power you are at war with. The player can load up transports in cities that are far from the front lines and go on foot from production centers near the front without waiting for transports. The AI has to choose either transports or walking. It can't do both with the current continent based decision making. In civ4, this is not an issue because the road and rail networks largely negate the need for explicitly using fast transport units on land.

In order for the AI to intelligently use transports for speed, I might need to generate alot more paths. That could slow things down.

So there are two ways I could go about this, but they each have potential drawbacks. The easier method might leave the AI at a disadvantage, but the more thorough method would need alot of significant changes and may slow the turns down considerably.

Let's say you have a large empire on a large continent which is shared with another power you are at war with. The player can load up transports in cities that are far from the front lines and go on foot from production centers near the front without waiting for transports. The AI has to choose either transports or walking. It can't do both with the current continent based decision making.

I would think in this circumstance it would be better choose transports over walking so that when the force arrives it arrives at speed.

I'm wondering how all this will affect the units we have that can walk on ocean and coast. In particular, the Fremen units that get double movement on ocean/coast. I suppose it is going to get too complex to have the AI use these effectively as well as Land Transport. I've advocated removing the ability to build vehicles from the Fremen. Would that help?

I think slowing down turns too much is obviously bad, but if a little slowdown is the price of improved AI I could live with it. The AI is already at a disadvantage - anything that puts it at less of a disadvantage is going to be an improvement.

I'm wondering how all this will affect the units we have that can walk on ocean and coast. In particular, the Fremen units that get double movement on ocean/coast. I suppose it is going to get too complex to have the AI use these effectively as well as Land Transport. I've advocated removing the ability to build vehicles from the Fremen. Would that help?


After looking at the AI, I would be surprised if the Fremen could attack another continent without transports. If you take away their transports I don't think they would try to invade without some extra AI logic in place to utilize their ability to cross the desert.

Well, I've been whacking away at my keys for about 8 hours straight. It's not very often you program for that long and have no bugs in the first test, but I have good news and a screenshot.

This is on a version of Arrakis.py with a very high land percent making it a pangaea. All the land except for a few small islands is connected.

http://forums.civfanatics.com/attachment.php?attachmentid=228315&stc=1&d=1253339349

What you are seeing is a floating stack o' doom travelling over land and sea to attack mr. orange on the left. Mr. green already did the same from the south and took a city in the process!

My eyes are burning and I need sleep. So I have to go to bed now. Tommorow I'm going to do some more testing to make sure I'm not just delerious. My luck can't be this good. Anyway when I'm confident of success I'll turn over the goods.

Sounds promising... :)

If this is really working, I hope David will never have to touch the sdk again... :goodjob:

If this is really working, I hope David will never have to touch the sdk again... :goodjob:

The genie is out of the bottle on that one. Now that I have finally done it, I am starting to see possible sdk changes everywhere. For example, a lot of the checking for terrain upgrading/downgrading with terraforming is related to fresh water, and it would be much simpler to make slight changes to fresh water handling in the sdk and then dump about 400 lines of complex python.

Wow, the situation in that screenshot was that harkonnen(orange) declared war on me. In the autoturns my faction bribed two allies, who then completely wiped out harkonnen with huge transport fleets full of troops. I don't think I've ever seen such a decisive war between AI civs.

One minor problem that I've seen is that the drop zones are not so great. In the screen shot I gave, that stack actually went to the west of the target Harkonnen city, and on the way there was exposed to land attack. It was not attacked, possibly because Hark was in defensive mode, but I understand that suspensors are vulnerable to land units is that correct? You don't want to drive circles around the city before landing I assume.

Vehicles, such as rollers and tanks, have a bonus against suspensors. Vehicles also have move 2 and a home ground promotion so they should be able to move out a couple of squares from a city to attack. Are there vanilla units which are more likely to sally against incoming attackers? Perhaps there is a UNITAI change which would make the AI sally more often.

Now that I have finally done it, I am starting to see possible sdk changes everywhere.

For a professed SDK bigot this is an amazing turnaround. :)

Vehicles, such as rollers and tanks, have a bonus against suspensors. Vehicles also have move 2 and a home ground promotion so they should be able to move out a couple of squares from a city to attack. Are there vanilla units which are more likely to sally against incoming attackers? Perhaps there is a UNITAI change which would make the AI sally more often.

Well, in this case Harkonnen was badly outnumbered, and was almost certainly set to AREAAI_DEFENSIVE. They won't move out of their city if there is danger nearby. This would have to be treated as a special circumstance, but even so, Harkonnen really didn't have an option. He had only a few defenders and there were at least two Sus. gunships to deal with before getting to the transports. So maybe he did act properly by not attacking them.

Ok here is the source code. I'm pretty confident that it is working without major problems. All my code is marked with 'cephalo' in the usual manner.

How it works is that I made two new AreaAITypes, AREAAI_ASSAULT_SAME_AREA and AREAAI_ASSAULT_SAME_AREA_MASSING, and because this settings are hybrids of previous ones, I went everywhere the old settings are used and determined the intent of the code and how it should handle these situations.

Basically, if the AI are not touching borders with an enemy, it will use transports. At the unit level, the units will forget about boarding transports when they are standing in enemy territory.

I also published a new version of Arrakis.py that is basically a pangaea in order to test this new AI.

I compiled the source files from Cephalo. Now when I try to enter desert I am getting this error again:

http://img188.imageshack.us/img188/6581/civ4screenshot0004c.jpg

I don't know what's causing it, but it's not the CvUnit.cpp. :confused:

EDIT:

I am not sure it is related, but when I compiled the sources I got that 'CvTextMgr.h' error. I handled it by removing CvTextScreens.cpp from the project.

Now here is line 7391, responsible for the python exception:

screen.setHelpTextString( CyInterface().getHelpString() )

getHelpString() <-> CvTextMgr :groucho:

I compiled the source files from Cephalo. Now when I try to enter desert I am getting this error again:

http://img188.imageshack.us/img188/6581/civ4screenshot0004c.jpg

I don't know what's causing it, but it's not the CvUnit.cpp. :confused:

EDIT:

I am not sure it is related, but when I compiled the sources I got that 'CvTextMgr.h' error. I handled it by removing CvTextScreens.cpp from the project.

Now here is line 7391, responsible for the python exception:

screen.setHelpTextString( CyInterface().getHelpString() )

getHelpString() <-> CvTextMgr :groucho:

I got this error too with the 1.5 dll I started with. I just ignored it. :) It's probably due to a helpstring regarding ocean that we removed sue to obvious reasons.

Ah ok, I understand.

Here is a CvGameCoreDLL.dll with Cephalo's changes for people who don't want to compile the sources. There is a quick workaround included to bypass the python exception:

http://www.mediafire.com/download.php?itdcjdzmq22

I pointed cephalo at the sources in the 1.5 distribution, but that was not quite the right thing to do. As you may recall I released 1.5 with a huge bug, regarding right clicking on ocean, and I solved it by dropping back to a slightly earlier dll from koma without some of my latest changes. So the sources in the 1.5 disti do not quite match the dll in the 1.5 disti. The dll works, but recompiling from the sources will still cause this bug. My mistake.

I have subsequently solved the bug for right clicking on ocean, which involved remaking some changes to CvGameTextMgr.cpp. Basically function CvGameTextMgr::setCombatPlotHelp was missing two null checks. Please find attached the file with this bug fixed.

Basically, if the AI are not touching borders with an enemy, it will use transports. At the unit level, the units will forget about boarding transports when they are standing in enemy territory.

I also published a new version of Arrakis.py that is basically a pangaea in order to test this new AI.

I have not merged the code or tried it out. But if I understand correctly, you are saying that the AI will now use all terrain transports and escorts to attack anywhere, except if the borders are directly touching. That is great!

Let us discuss what the resulting mapscript might look like. (Yes, on this thread, since we are currently using the other map thread to discuss about deliverator's heightmap changes.)

If you think about Dune as a pangaea, then all the spice is on the outside of the map. For a large map, there is a long distance between the center of the map, and the ocean. This means some civs will start very far away from spice, and the resulting commerce income.

A long time back we had discussed that perhaps the center of the map should be polar ice, with water yield. But we got stuck before agreeing whether cities should be buildable on ice. One could think about a radially symmetric map, with a donut of land. Inside it at the center is ice. Outside is spice. If the donut is not very thick, then civs could reach both. After initial expansion, each civ would have a shape like a pie slice, with a bit of ice terrain and a large outer expanse of spice mining operations.

However, I am not sure how this would scale to larger map sizes. I think the donut would have to become very thick, and then civs would not easily be able to reach *either* the spice or the ice.

What do you think about the big picture of this type of mapscript?

A long time back we had discussed that perhaps the center of the map should be polar ice, with water yield. But we got stuck before agreeing whether cities should be buildable on ice. One could think about a radially symmetric map, with a donut of land. Inside it at the center is ice. Outside is spice. If the donut is not very thick, then civs could reach both. After initial expansion, each civ would have a shape like a pie slice, with a bit of ice terrain and a large outer expanse of spice mining operations.

This is how I imagined the script would be, except that the donut is not a complete chain, it is broken in several places by straits of desert.
I think it is fine for the mapscript to only really work well on a couple of map sizes. We only have ~10 factions, so the game is only likely to work for small-medium-large maps. There is nothing wrong with designing the mod to work on a particular map size and game speed.
Planetfall is designed to be played on a normal sized map, or maybe small.

This is how I imagined the script would be, except that the donut is not a complete chain, it is broken in several places by straits of desert.


That would be like archipelago, with no/fewer islands at the outside of the map. Another possibility would be pangaea, with a huge number of lakes.

We only have ~10 factions, so the game is only likely to work for small-medium-large maps.

We should try to make duel, tiny, small, standard and large all work, we have enough civs for those. I often play small, since I can finish a game in a couple of hours.

That would be like archipelago, with no/fewer islands at the outside of the map. A

Yes, this is what I had in mind; this is what the Arrakis maps look like to me. There isn't a completely unbroken wall of mountains surrounding the pole.

another possibility would be pangaea, with a huge number of lakes.

And lakes being desert? Maybe.

Whatever we use, we need to make sure that it isn't just a pure donut of land, because then culture won't be spreading out into the desert to cover very many spice tiles. If its a pure donut of land, then cultural borders will also be a donut, spreading ~3-5 tiles further outside the land donut, which doesn't cover very much desert.

So there need to be lots of gaps in the land where there is desert, so that cities on the land still cover a decent amount of desert.

I think it is likely to be very difficult to ever get the AI to contest or access spice resources that arent' within their cultural borders.

* * *
Also, its ok for the donut to be fairly wide; it could be an interesting strategic choice on whether you try to expand more towards the center, for the good polar terrain, or towards the outside, for more spice resource.

This is how I imagined the script would be, except that the donut is not a complete chain, it is broken in several places by straits of desert.


Yeah, that's what I would like to go for. It looks like the fictional dune map. The polar areas are actually continuous with the dunes from outside the pole, but the frozen water in them keeps out the worms.

Keep an eye out for transport mishandling by the AI. If they risk them needlessly I may have to make some adjustments. Also, make sure I hear about it if the AI gets stuck in a loop. That happened once when I tried to fix what appears to be a very old bug in the Civ AI. I unfixed it just in case, but if that was not the issue, I might like to fix it again along with whatever is really causing the loop.

One thing about this change that is kinda cool, and very different from BtS, is that AI war allies are now extremely potent. On the continental type maps I played, I never worried about my enemy calling in allies in BtS. I don't think I ever saw an invasion by someone other than my principle enemy.

In this game though, two against one is really two against one, and three against one appears to be devestating! It should be interesting to see if that is as desireable as it should be.

After looking at the AI, I would be surprised if the Fremen could attack another continent without transports. If you take away their transports I don't think they would try to invade without some extra AI logic in place to utilize their ability to cross the desert.

I have done some autoplays with my local version, which is about to become 1.5.4. The Fremen are in serious trouble. In almost every autoplay, they are either dead, or way in last place, by turn 250. That is sad, because the "concept" is that they are supposed to be able to grow very fast in the early game.

The Fremen differ from the other civs because every foot unit is given the "sandrider" promotion by default. This happens in python. The sandrider promotion allows them to enter deep desert from the start of the game, and get a 2x movement bonus. So the starting units, such as worker, scout, settler can all move 4 in desert, and the warrior can move 2 in desert. As a human player, this appears to give me an advantage in development. Other civs have the Scout Thopter to transport two of these foot units, and they appear to be able to found colonies fine. The Fremen have a scout UU, which prevents them from building the scout thopter.

However, the AI appears to be completely unable to recognize the sandrider promotion. Is there another way to accomplish the fast desert move? Or a way for you to tweak the AI so it does not fail so badly?

I have done some autoplays with my local version, which is about to become 1.5.4. The Fremen are in serious trouble.

I wonder if some of this is from being forced to adopt Paradise civic and build catchbasins in every city, and the -3 water kills their economy? Without terraforming, catchbasins are useless, and in your proposed design where terraform rates within your bordrs depend weakly on catchbasins controlled by all civs, rather than strongly on your own catchbasins, catchbasins will still be very weak and the AI will suffer from building them.

I also strongly, strongly suggest that you deactivate the slavery/serfdom/imperial levy whip/drafting for any autoplays, you can get very misleading results without them. Catchbasins also have a magnified effect with whipping; you build a catchbasin, use whipping a lot, and so have a small population which magnifies the % loss of -3 water (ie: city with 10 population bringing in 20 water, -3 is a 15% reduction; city with 3 pop and 6 water, -3 water is a 50% reduction).

I see AI moving crysknife fighters and bladesmen across desert tiles, but not attacking with them; the Fremen assault stacks seem to consist of suspensor transports and escorts, with siege units, vehicles and guardsmen; but no melee troops.
So yes, the AI seems to be confused by the sandrider promotion: Fremen need to lose the transports, gain sandrider on their guardsmen, and get some new assault AI.

I wonder if some of this is from being forced to adopt Paradise civic and build catchbasins in every city ... I also strongly, strongly suggest that you deactivate the slavery/serfdom/imperial levy whip/drafting for any autoplays.

The Fremen get way, way behind even before building catchbasins. I have removed whip in these autoplays.

I see AI moving crysknife fighters and bladesmen across desert tiles, but not attacking with them ... Fremen need to lose the transports, gain sandrider on their guardsmen, and get some new assault AI.

This may be an additional problem, but I am concerned by lack of peaceful expansion. Probably if we find/fix whatever is causing that, then they will either go to par with other civs for war, or perhaps (my goal) even exceed them.

This may be an additional problem, but I am concerned by lack of peaceful expansion.

Hmm. I haven't noticed this. Perhaps because I am playing low desert levels, so there are fewer islands and so worse amphibious tactics aren't a problem? Since they're settling fine across land.
See screenshot.

Another potential issue:
they don't get the scout thopter, and so don't have an early cross-continental transport. Maybe this hurts them in terms of settler spread?

Another potential issue:
they don't get the scout thopter, and so don't have an early cross-continental transport. Maybe this hurts them in terms of settler spread?

Well, their settler, worker, and warrior can cross desert at high speed, if the AI can use it. So that would seem to be a benefit, not a liability. I agree this may not show up, if you have more of a pangaea map.

Well, their settler, worker, and warrior can cross desert at high speed, if the AI can use it.

This is my point; I'm guessing that their settler won't cross desert tiles without a transport, despite its ability to do so when used properly. So their slower access to transports cuts them back in expansion; hence their need for an AI tweak.

Its a liability *given their current AI*.

Much of the unit AI depends on what area you are standing in and what the team strategy is for that area. Because ocean is currently AREAAI_NEUTRAL, as soon as the Fremen step into the desert they will forget what they were doing. That might also be true for settlers actually.

Much of the unit AI depends on what area you are standing in and what the team strategy is for that area. Because ocean is currently AREAAI_NEUTRAL, as soon as the Fremen step into the desert they will forget what they were doing. That might also be true for settlers actually.

Thanks for the info! Why don't transports forget? If I have a game running, how can I tell a settler with amnesia, from a real one?

Does it make sense for desert to be AREAAI_NEUTRAL in this mod considering several units can move on the sand? Would there be major downsides in changing this?

Does this mean that the AI won't use thopters and suspensors to attack incoming stacks? Ideally they would try to do that before they land and unload.

Transports have an AI that is meant to cross ocean, so they are ok. Fixing this problem might be as simple as setting ocean to AREAAI_OFFENSIVE, but I'm not sure. I would think that thopters and suspensors would not attack unless they were already in the immediate vicinity. There are some default routines that attack any nearby enemy if the combat odds are high.

Transports have an AI that is meant to cross ocean, so they are ok.

The problem with Fremen is that we are intending to remove Fremen access to transports, so that they actually don't use them, they just walk across the desert.

@ Cephalo, there was a comment in the 1.5 feedback thread that it is still too easy to pick off incoming enemy transports. Ahriman suggested that transports should automatically unload their cargo after moving and then reload and move at the start of the turn. Obviously they would not do this if their move ended on water, and there is no need to do this in friendly territory.

Do you think this would be possible to add, or would the mission of the group be lost? If a transport was on an assault mission and unloaded and forgot what it was doing, that would obviously not be good.

I was thinking that the existing "worker threat" function might help. A worker which could be reached by an enemy automatically goes off automation. I don't know what that function is, but perhaps calling it for transports could trigger this unload.

@ Cephalo, there was a comment in the 1.5 feedback thread that it is still too easy to pick off incoming enemy transports. Ahriman suggested that transports should automatically unload their cargo after moving and then reload and move at the start of the turn. Obviously they would not do this if their move ended on water, and there is no need to do this in friendly territory.

Do you think this would be possible to add, or would the mission of the group be lost? If a transport was on an assault mission and unloaded and forgot what it was doing, that would obviously not be good.

I was thinking that the existing "worker threat" function might help. A worker which could be reached by an enemy automatically goes off automation. I don't know what that function is, but perhaps calling it for transports could trigger this unload.

I'm not sure I have time to mess with it right now, but I think the function you want to look at is CvUnit_AI::seaTransportMove. You can drop them off anytime you are in enemy territory, or maybe do something like the worker retreat.