Announcement

**EPW** · October 17, 2004, 22:48

Just downloaded it, and the AI does take an extremely long time to complete their turns. I was using the lstest playtest.

It looks like it will be really good though once the bugs are worked out

**Immortal Wombat** · October 18, 2004, 06:32

Cool

Did you ever get a fix for the AI moving stacks on roads thing?

**Locutus** · October 18, 2004, 13:19

Well, we used some common sense solutions like spreading the stacks more evenly over the whole map rather than concentrating them around one or two cities, and we simply created more roads so units can move around chokepoints

I also had some (unfinished) ideas about how to work around the problem with SLIC, but before I continue on those I would first like to test how the scenario currently holds up, especially since AI movement is also being reworked for the Source Code Project...

**Immortal Wombat** · October 18, 2004, 16:20

Ah ok. Excellent.

**The Big Mc** · October 18, 2004, 16:22

Loc I think I may have solved you colour.txt nightmare the reason ( at lest what I suspect) is that you have made it so ships can sail up river by putting the

MovementType: ShallowWater

Flag on the terrain this makes the terrain show up as water as it can be navigated by sea. Eg the map is painted completely green then the tiles were ships can sail is painted blue making the min map mistake them for shallow wetter tiles. (not a coder so pleas feel free to give me a slap.)

As for detailed map a simple modification to color.txt can be done to make the detailed version see that its grass land.

**Locutus** · October 18, 2004, 16:33

Originally posted by The Big Mc
MovementType: ShallowWater

Flag on the terrain this makes the terrain show up as water as it can be navigated by sea.

No, not really. The river tiles show up as land just fine. It's the Polar Mountains that show up as sea -- while they can't be navigated by anyone.

The problem with the river tiles is that the minimap takes the colour of those tiles rather than the regular grassland tiles for the land/sea only minimap. I.e. on the detailed minimap, Grassland is pale green and River Grassland is bright green. On the land/sea only minimap, all land is bright green (as opposed to the pale green of the normal game).

**The Big Mc** · October 18, 2004, 16:54

try this it should make river grassland the same as grassland.

But it needs testing as it was made on the fly as I don't currently have the latest play test.

Attached Files

colors00.txt (5.5 KB, 402 views)

**Locutus** · October 18, 2004, 18:07

The Big Mc,
The only line you changed in that file was an outcommented line, part of the old CtP1 set. Obviously that didn't have any kind of effect. The radarmap colours are further down, from line 105 onwards (you changed line 69).

**The Big Mc** · October 18, 2004, 18:42

try now

sory to much time off.

**Locutus** · October 19, 2004, 05:58

I was afraid that's what you were trying to do. Yes, now the land/sea only minimap looks normal again, but now you can't distinguish between regular grassland and river grassland on the detailed minimap. And that's quite important, as you can't distinguish between regular grassland+river and river grassland on the main map either (except for right-clicking on a tile and requesting terrain info). What I would want is for river grassland (and other major river terrains) to have its own unique colour (ideally blue) in the detailed minimap, while the land/sea only minimap uses the colour of regular grassland (otherwise you get that both land and water in the land/sea only minimap are blue).

**Fromafar** · October 20, 2004, 16:33

If you want a slow game, you should try running this in the debugger with the Apolyton edition

. I didn't even make it to turn 2

. It looks like the AI is busy determining how to schedule its transport goals. Player 2 is handled relatively fast (around 1000 matches to consider), player 3 takes a little bit longer (about 5200 matches), and player 4 takes forever, with over 34000 matches and an enormous amount of sorting large lists.
Can this be caused by the rivers? If so, adding some river crossings may reduce the need for transports. OTOH, this could introduce chokepoints.

An observation about the Slic code: the construct

Code:

GetCityByLocation(x, tmpCity);
if (CityIsValid(tmpCity) ...

is used quite often. This is at best inefficient, and may even be incorrect. See the observation by BureauBert and some following posts for an explanation.

Oh, and another one: some comments about defection probabilities do not reflect the state of the actual code.

**The Big Mc** · October 20, 2004, 19:07

it happens in the original too.

**Locutus** · October 20, 2004, 19:09

Originally posted by Fromafar
If you want a slow game, you should try running this in the debugger with the Apolyton edition

. I didn't even make it to turn 2

. It looks like the AI is busy determining how to schedule its transport goals. Player 2 is handled relatively fast (around 1000 matches to consider), player 3 takes a little bit longer (about 5200 matches), and player 4 takes forever, with over 34000 matches and an enormous amount of sorting large lists.
Can this be caused by the rivers? If so, adding some river crossings may reduce the need for transports. OTOH, this could introduce chokepoints.

That's the sort of info I was looking for, especially since I don't have a working version of the source (I get all sorts of weird bugs when I run the latest version, I need to do a clean install but simply don't have the time). Thanks a ton

I'll try adding some river crossings later when I have the time and see what that does...

An observation about the Slic code

Yeah, the folks at Activision seemed to really love that CityIsValid function, never quite got that

It's not causing any problems AFAIK so I think I'm leaving it as it is for now, until I get really bored sometime

Oh, and another one: some comments about defection probabilities do not reflect the state of the actual code.

Well, that's what you get when you have non-programmers working on code. They tend to be sloppy, especially when it comes to keeping documentation updated (especially Harlan)

When in doubt, the actual code is correct

**Martin Gühmann** · October 21, 2004, 10:42

Originally posted by Locutus
That's the sort of info I was looking for, especially since I don't have a working version of the source (I get all sorts of weird bugs when I run the latest version, I need to do a clean install but simply don't have the time). Thanks a ton

I'll try adding some river crossings later when I have the time and see what that does...

Yeah that's a problem of the playtest version in general, as soon as the AI has to use transports it is getting slow.

Originally posted by Locutus
Yeah, the folks at Activision seemed to really love that CityIsValid function, never quite got that

It's not causing any problems AFAIK so I think I'm leaving it as it is for now, until I get really bored sometime

Probably it doesn't cause any problems as long as all the cities are valid, but if one gets destroyed, you might see the slic code in action even if the slic code is not supposed to work if the city is destroyed.

Here is another piece of code that is - well slower than necessary. At least I don't see any reason why:

Code:

HandleEvent(MoveUnits) 'AGSeres2_F' post {
army_t		tmpArmy;
location_t	tmpLoc;
	tmpArmy = army[0];
	player[0] = tmpArmy.owner;
	if (player[0] == 1) {
		tmpLoc = tmpArmy.location;
		if (SquaredDistance(tmpLoc, seres2Loc) < 25) {
			Message(1, 'AGSeres2');
			DisableTrigger('AGSeres2_F');
		}
	}
}

I don't see the need for the temporary variables, so that it looks like this:

Code:

HandleEvent(MoveUnits) 'AGSeres2_F' post {
	if (army[0].owner == 1) {
		if (SquaredDistance(army[0].location, seres2Loc) < 25) {
			Message(1, 'AGSeres2');
			DisableTrigger('AGSeres2_F');
		}
	}
}

-Martin

Announcement

Alexander the Great v1.5

Alexander the Great v1.5

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment