FIRAXIS: Bug reports coming from MT V testing

[DeepO]

Turn 2: If I now move my carrier, even with the F15s on air up., every goes like it should be. A very strange problem indeed.

DeepO

[DeepO]

9. Transports should see the risk of staying on the sea too long, and drop their troops asap
I take back what I just said about the effective use of transports The AI do, in general, but I just saw something else. The first time I went through the turn, one transport moved out of a city, and dropped its load of troops (7 MAs and one longbowman(!)) on a hill in the same turn. I thought: great! They are circumventing my line of defense, and instead of going through the chokepoint they go around it. Clever.

As I had to reload for the F15s to be positioned on my carrier instead of on a floating airfield, I couldn't help myself and possitioned a conscript MI on the hill, so the transport could use the grassland aside of it to drop their troops. This scenario is already hard enough as it is, a little cheating while testing should be possible

Now, the problem is that that transport did not drop its troops again in the same turn, but decided to go on for another empty hill on the other side of the sea... passing my attackforce of 5 destroyers, a few subs, a BS and a Aegis. And I'm pretty sure it is exploitable: If I would take my conscript MI, and move it to that other hill, I'm sure it would return back to the original, passing my attackforce again.

Sure, they are protected by a regular BS, but how long do they think this will last? No, when deciding where to drop off troops, the distance a transport has to move on the sea should be taken into account. I can understand that MAs on hill will be better protected then on grasland, but now they will get lost on sea, without even tying up any of my land troops. And it is way too easy to exploit this: if I put a warrior on every hill and mountain top, except for one very distant mountain, I can set up lines of destroyers towards that lone mountain, which will bombard the transport and their buddy on the way for free, so I can pick them off at the end of the line by any single destroyer I like. Where to land is important, but so is how you get to there...

10. stack AI transports with their defense in larger packs on purpose, instead of by coincidence
In MT V, the transports are divided so that large stacks of these will enter the human coastal area at the same time, making it very hard to kill them off without the use of nukes. However, this should not be done by the scenario builder, but by the AI itself, they should see the advantage of moving a lot of them together, like humans do.

In MT V, you can see lots of them moving in packs: some stacks of transports, followed closely by other small stacks, followed again by other stacks (think 2 transports - 4 transports - 2 transports, all spaced 2 tiles apart). Again this is primarily done by unit spacing in the scenario, and not a 'conscious' decision of the AI. But it should be easily adjustable to build it into the AI...

These packs create maybe the largest threat of all: you can't nuke them all, as you don't have that many nukes available, and they are very hard to kill because by the time you spot them, there isn't enough time to gather you navy and kill them all. Some of these will get through.

11. Adjust the defense of transport according to the needs
Closely related to the previous points. Now it is fixed to, whenever there are enough ships (BS, destroyers, whatever) one of these is coupled with a transport, and they will move together. But this is not always ideal: sometimes, certainly when facing an able navy, it pays to have 2 defensive ships on top of a transport. Sometimes, when there is little navy defending, 3 transports accompanied by 2 destroyers woud be better. The fixed coupling gives again rise to exploits, and makes it easy for the human to intercept AI transports: you know they will come in two's, so having 2 destroyers waiting you can pick them off after bombardment.

DeepO

[DeepO]

12. When AI transports lose their buddy, they should head straight for land (any land) and drop of their troops instead of continuing
Quite self explanatory, this one. It used to be so in the last patch that they just waited until another buddy came along, but now they will continue on their way. Unless they are hit, then they will return home.

Besides, why do hit transports head home so often, when they are less then a move away from the enemy territory? Again, this could take several moves, passing hostile attack forces... first of all drop the troops off, after that the AI may try to get his transport at full health again.

DeepO

[dawidge]

Originally posted by DeepO
12. When AI transports lose their buddy, they should head straight for land (any land) and drop of their troops instead of continuing

Besides, why do hit transports head home so often, when they are less then a move away from the enemy territory? Again, this could take several moves, passing hostile attack forces... first of all drop the troops off, after that the AI may try to get his transport at full health again.
DeepO

Empty transports are expendable. Loaded transports are priceless, but serve a single purpose: point A to point B. Do not pass go, do not collect $200. Drop your load, then go home. If you live, you get to do it again (and again...). If you don't, I'll just have to rush another one to take your place for the next wave.

Stack those transports. In Babylon and On, I had 6 transports with two destroyer escorts conducting the majority of my landings. I could guarantee that I'd soak up two attacks against the convoy before a transport got damaged. While we're on the topic, A transport should never be the preferred defender when a capital ship is in the same sector. That wounded destroyer exists to die saving the transports.

I have never seen the AI use a ferry system between landmasses. If the landmasses are less than 5 sectors apart with conveniently located port cities, then funneling units between landmasses is trivial. If more than 5 sectors, it just takes another transport in the middle for the troops to "load" onto when the first one runs out of mobility. The AI needs to understand about redirecting mobility costs. Again in Babylon... I had a stack of three transports in Chicago. Chicago-Satsuma was 5 sectors. I had a heap of MA and armies in America and needed them in Japan, but had only 5 airports in America. Simply pumping them through the ferry system delivered 24 MA every other turn to the front line (+ 5/turn, plus whetever I was producing on the other landmasses). If the AI had this problem, it would try sailing around the Japanese/German continent to land the troops on the front instead of ferrying them to a railhead. It might take 8 hazardous turns to get a transport to the front, but the troops were able to fight on that turn because I could ferry them. Lucky for me that the French had destroyed all the Japanese subs, but my transports sailed right past a Japanese BB each turn, only occasionally taking ZOC damage.

If the AI had a better understanding of how to use transports effectively, I would have lost the game. Instead, it would drop off 8 troops (a rare occurrence) where it needed 20. More often than not, it would only drop 2-3 units, and those would be delivered onto very hostile shores. The AI's use of transports is an inefficient method of disbanding those troops.

[DeepO]

Indeed Dawidge, I'm glad you approve. Now If only Soren would post a tiny message saying that he has seen this thread, and takes it into consideration...

More of these will come, I think that with a couple of extra rules, the naval combat of the AIs would greatly improve.

DeepO

[DeepO]

13. AI will always go for the least defended tile, which gives rise to exploits as you can move your least defended tile
This one, I alluded on in one of the higher posts, and it is known for some time now. But in this scenario it becomes very visible, and it is very hard to not exploit it... as you have two chokepoints, shifting troops from one side to the other will mean that the now better protected chokepoint will see all it's attackers leaving for the other one. As they arrive there, it is only natural to concentrate some of your defenders there, which will prompt the AI to move back to the first... and again, and again.

Brinoch posted a tactic to gain more out of this yo-yo by bombing the AI troops on their way around the inland sea, which is a fine tactic, but shouldn't be possible to this extend. Where the line between exploit and tactic lays here is unclear, if only the normal troops were moving, it would be very good, but as the yo-yo troops are also here, it is less admirable... At any rate the AI should not be fooled like this.

I am unsure how to solve it. But, similar to the transports that risk too much being at sea for turns and turns when they could have a (less favorable) landing spot just one turn away, this maybe could be improved by taking the turns it will take an army to reach its target into account. After all, if an army has a certain strategic goal (with its 'desirability' factor, not all goals are equal), surely the suddenness is also a factor: if an army can attack a goal in one turn, that should be better then attacking a sligthly easier goal in 5 turns. But the problem of course is the use of slightly: it will be a balancing problem to make sure that in all situations this extra 'turns moving towards the goal' factor works, and doesn't destroy the strategic importance factor already in place.

DeepO

[alexman]

Good job DeepO

Even though Firaxis would argue that most of these points are not bugs but AI enhancement requests, I posted a link to this thread in the 1.29f bugs. I hope you don't mind.

Perhaps Soren will take a look here and tweak the AI for PtW.

[DeepO]

Thanks alexman. And indeed, most are improvements, not bugs. But that doesn't mean that changing them wouldn't make civ even more fun to play

DeepO

[Catt]

Originally posted by dawidge


The AI's use of transports is an inefficient method of disbanding those troops.

[DeepO]

14. Funny things happen in the save game popup
I know from experience that no programmer wants to mess with popup screens, as these do not add anything to the core program but are simply things you have to spend time on, but as they are so basic it makes it even more unforgiving when something goes wrong.

I've got two things I've noticed lately. First can be seen in the attached screenshot: I just loaded the final alamo .sav, and, in windows explorer I made a folder where to put the saves of this game. By coincidence, these two (the .sav and the folder) have the same name. After I set up everything for the first turn, I wanted to enter the folder, and save my game there for future reference. However, the game doesn't let me do that, and thinks I want to overwrite the folder with the .sav... not very nice.

The second is less important: If I do not use the deafults saves, and select a .sav already in a folder (let's say "Alamo 3950 BC.sav") which name I want to change, there is a problem with the selecting of characters: If I select the "5" in "Alamo 3950 BC.sav" to change it into a "0", the game will select "90" and replace it with "0". The new file name becomes "Alamo 300 BC.sav". This is just a wrong counting of what is selected, I don't know it by heart and it will probably depend on which compiler is used (I'm mostly familiar with Visual C++), but my guess is that the GetStartSelect() method is 0-based, where the code presumes it is 1-based. Minor detail, but as I was posting bugs, I thought I should post everything I saw.

DeepO

[DeepO]

15. default popup closing buttons
While we're at the popups, it can be tedious to have to close most popups with your mouse, it would be good if the 'ok' buttons got a default Enter to close it, while the 'cancel' would get a Esc attached as the default key. Another minor thing, but searching for those buttons with your mouse all the time when your hand is already on the Enter key can be too much energy wasted, especially when you are, like me, partly paralyzed in your right (mouse) arm... I have to concentrate each time I move my hand from the keyboard to the mouse, and this concentration can distract from the game

DeepO

[DeepO]

Regarding the second part of 14... I was wrong, and am sorry for that. It seems to be a problem with my mouse selecting, If you start very close to a character, it will take automatically the one in front. I don't have this problem in other applications, but it is not something a programmer can help. If I very precisely select something, there is no problem, it is just that when I'm a bit careless I see it. It seems the margins are a bit too small as opposed to the general OpenFileDialiag from windows.

The first 14 thing still stands though, I had to rename the original file before I could select the folder.

DeepO

[DeepO]

Hmmm... it maybe not a simple 0-based, 1-based thing with the selecting of text in the save game popup, but there is definately something strange going on... for instance simply clicking in the name will always select one character... oh well, never mind.

DeepO

[DeepO]

Oh, and I found why the carriers will move without their fighters (bug 8): The fighters aren't loaded on the carriers. If you give any other order then Load to the F15s, they will stay in their place. After load, you can immediately wake them, set them to air sup, and they will move correctly.

So the title of bug 8 should change to: Airplanes should auto load onto carriers when in the middle of the sea when a new save game is opened

DeepO

[Velociryx]

16. Stacks of two or more units can be set to "Fortify All" even if individual members IN the stack have no movement remaining

This probably falls under the heading of "minor exploit," but in the context of the Alamo scenario, it can make or break you. Example: Turn one, I pillaged all my tier one forts, and retreated back to "The Wire" (tier two fortlines). The units I used for pillaging had no movement points remaining, and so could not fortify on their own, but because they were stacked with other units, right clicking on the stack allowed them to fortify anyway, using the "Fortify All" command.

-=Vel=-