22-11-2003 22:58									#31
	Get a bigger avatar today!

I'll bite. However, it will take some time, because I first want to resynchronise with the altered source code update. Nice job, Martin .

	24-11-2003 22:31									#32
	Lose 30 kilos (of popups)

Status update after resynchronisation and changing the code: it doesn't work.

The ships are still running around swiftly in the tunnel, and there is no penalty for having to dive to reach it. Maybe we can ask someone to work on the animations .

I am not sure about the validity of methods 2 and 4: the concept of a common movement cost for an army looks strange, because the individual units move at different rates.
When moving a land army through roads and tunnels and merging it at some location with a sea army (which may have moved before as well), you would have to consider each individual unit's move cost to see if you can get to the next location as a combined army. If the "land" cost - used because there is at least 1 land unit - is lower than the "sea" cost, and some ship has insufficient movement points for the sea cost, but sufficient ones for the land cost, it will give you an incorrect result.

But I don't think this is the cause: even when alone in an army, ships are using the fast tunnel movement rate.

	24-11-2003 22:51									#33
	Support Apolyton, buy Civilization III: Complete

From a design standpoint an army has only as much movement points as much movement points the unit in that army with the least movement points has. As far as I know there is no problem with land stacks.

For sea stacks sea only armies shouldn't be allowed to use undersea tunnels, that should also be true for mixed armies, if one unit can't use the undersea tunnel than the whole armie can't use the undersea tunnel.

And I remember that this bug also exists in CTP1 and it was fixed in one of the patches, unfortunatly I don't know if it was in the hack patch or earlier.

-Martin

	24-11-2003 23:23									#34
	Support Apolyton buy from Amazon

quote: Originally posted by Martin Gühmann From a design standpoint an army has only as much movement points as much movement points the unit in that army with the least movement points has.

This is a bit too pessimistic. I would not expect my combined land/air strike to fail, because since airplanes do not use roads, they make my land forces slow down considerably .
As long as the individual units can get to the same spot at the same time, it should be fine to move them together.

And I also found the bug. The GetMovement() function returns a bool telling you whether the movement is possible. But some parts of the code interpret this as the actual cost, so you get movement cost 0 or 1 .

	25-11-2003 00:23									#35
	Support Apolyton, buy Civilization III: Complete

quote: Originally posted by Fromafar This is a bit too pessimistic. I would not expect my combined land/air strike to fail, because since airplanes do not use roads, they make my land forces slow down considerably . As long as the individual units can get to the same spot at the same time, it should be fine to move them together.

Actual this is the reason why you shouldn't combine land units with aeroplanes, therefore we have airbases and aicraft cariers and that is also a problem the AI can't handle and therefore all slic scripts that deal with aircrafts try to prevent the AI from grouping land units and air units together. So that is the way it should work. If you want to move your airplanes further than the rest of the stack you have to remove them from the stack.

-Martin

	25-11-2003 02:53									#36
	Put an end to popups!

I am afraid we are talking about 2 (or maybe 3) different things here.

Firstly, there is the problem that airplanes have to refuel, and land units do not. I fully agree with you there: it is unwise to keep your stack together, because it will kill the airplanes.

Secondly, there is the problem of optimal movement. When the optimal path for the land units is not straight (e.g. following roads/coastline), you may lose movement points of the airplane by keeping it with the land units. No argument there: ungrouping and recombing is better, and maybe even necessary to reach the target together at all.

Thirdly, and this is what I was talking about, there is the GUI for the human player. When the path is straight or short enough, I don't want to ungroup, move 2 or 3 different stacks to 1 tile just before the target, group, and make the final attack together. I just want to aim the whole force directly to the target.

Ideally, I would love my - competent AI - army generals and admirals to know how to move troops, and even synchronise the optimal paths (solve the second problem) themselves when I just point out the target on the map to them. But I may be a bit too optimistic right now.

	25-11-2003 03:22									#37
	Support Apolyton buy from Amazon

quote: Originally posted by Fromafar Thirdly, and this is what I was talking about, there is the GUI for the human player. When the path is straight or short enough, I don't want to ungroup, move 2 or 3 different stacks to 1 tile just before the target, group, and make the final attack together. I just want to aim the whole force directly to the target.

In that case you need to compute that would take the land units, so the aircrafts and the land units pay for that part of the way they move together. Once one units has used all its movepoints the stack can't move any further for the whole remaining turn.

So how is the path caculated in a mixed Air-Land stack, after a short test it seems that the path is calculated on the movepoints of the land units and their ability to use roads, that the aircraft can't use the road doesn't matter for the path colors, but the stack stops when the aircraft used all its movepoints.

In fact the path should be calculated on the ability of the land units to use roads, but it should be taken in consideration that the aircrafts can'T use roads, so that the green length of the path is displayed correctly.

-Martin

	25-11-2003 04:22									#38
	Put an end to popups!

Basically, it now works the way you describe here. The actual movement cost deduction when executing the move is done correctly - for each unit individually in UnitData.cpp.

The path coloring in TileHighLight.cpp does it incorrectly, and may be off. But this will correct itself fairly quickly: because the actual movement is computed correctly, you may end up with a "green" army that has still movement points left at what was originally the end of the path.
Also, the fixed air and sea movement costs are always 100, and all air and sea movers have movement rates that are multiples of 100, so you will not get any problems with partial moves in the game.
I only encountered problems with Fusion Tanks in combination with tunnels in deep sea. Trying to move the army gave a red path, while ungrouping and selecting one unit at a time did give a green path for all units!

Any selected path is slavishly followed by all units as a group. There are no attempts to split off units temporarily and recombine later.