CivConverter crashing

[Boco]

Originally posted by Catfish
An example: at one point during the testing of WotR, I had some units attack a specific city on the first turn. Further edits were made to the scenario and to my annoyance, the units began to ignore this city and instead go for another further away. I couldn't figure out why this occurred. I zeroed the table for that civ. They now always attack the nearer city first. It was as clear cut as that. No other edits were made.

Could you make any sense of the coordinates in the table before you zilched it? Any as simple as the coordinates of the unwanted target city? Or farther than that, but in the same "go to" path?

Not sure who DLed it Pluto, but I'll bet it's a hex wizard.

[Catfish]

Originally posted by PlutonianEmpire
Who in the world downloaded it 4 times before I did? :P

Dunno, but what about an answer to my question?

Originally posted by Boco
Could you make any sense of the coordinates in the table before you zilched it? Any as simple as the coordinates of the unwanted target city? Or farther than that, but in the same "go to" path?

OK, I managed to dig up a save from last year. Obviously my memory's fuzzy because I found that the coordinates for both cities were listed in the table. The attachment below shows the top half of the table in AXE. The section on the right is the structure view. The coordinates of the two cities are highlighted in yellow: the first (nearer) city is located at (69, 81) and the second (further) city at (65, 67). On turn one the units should attack (69, 81) but instead are issued 'go to' orders for (65, 67). To reach (65, 67) they must navigate some impassable terrain (ocean), which brings them closer to a third city (75, 67), not listed in the table, at the end of turn one. On the second turn the table is recalculated and the 'go to' orders for (65, 67) are dropped in favour of an attack on what is now the closest city (75, 67); the coordinates (69, 81) and (75, 67) are not present in the revised table.

Swapping the coordinates in the table had no effect. If the entire table is zeroed, the units attack (69, 81) on the first turn. Zeroing the table in blocks of rows from the bottom up I found that the entry at offset 19218 made the difference. When I zeroed this entry, they attacked (69, 81) on turn one. However, its coordinates (160, 154) are way over the other side of the map, in essentially the opposite direction (relative to the units) to all three of the aforementioned cities. The tile is vacant but lies within another city's radius. Further testing showed that the coordinates for this entry could be anything and the units would still be issued with 'go to' (65, 67) orders, providing that the 7th and 8th bytes fell within the ranges 0x00-0xFE and 0x02-0x7F, respectively. If values for either of these bytes fell outside of these ranges, then the units would attack (69, 81) on the first turn.

Because the tables are recalculated every turn, I wouldn't put much effort into trying to interpret them. If you've got first turn issues, just zero them. I suppose it might be useful if we knew the parameters used by whatever algorithm is responsible for producing them. That way a scenario designer could exert greater influence over the behaviour of the AI. Of course, we don't want to get ahead of ourselves - the notion that they're associated with AI goals is just a theory.

[Boco]

At this point, I don't have first turn issues, but only because I trap AI units in pockets of transient blocking units of my 'nature' civ. It's a crude solution, so I was interested in setting up a more effective one.

I'm still curious about 7th and 8th bytes. I'll take a look at EA tables to see what they hold.

Thanks for the info