DEBUG: Boni of undersea tunnels for sea units bug

[NelsonAndBronte]

Have a look at the CellUnitList::IsMovePointsEnough function. This function will test to see if the moving unit is an air unit and then apply the default cost for an air unit -- which therefore ignores the terrain cost of the cell. For any other unit, it uses themovement point value created by Cell::CalcTerrainMoveCost(). This function iterates through all the terrain improvements in a given cell and returns the movement cost of the most effective improvement present. Therefore, since a ship is not an airplane, it is allowed to use undersea tunnels.

It appears that we need a function analogous to GetMovementTypeAir viz:

BOOL CellUnitList::GetMovementTypeWater() const 
{ 
    sint32 i; 
    for (i=0; i < m_nElements; i++) { 
        if (!m_array[i].GetMovementTypeSea() && !m_array[i].GetMovementTypeShallowWater()) {
            return FALSE; 
        }
    }
    
    return TRUE;
}

If this function returns TRUE, then we want the base value for the terrain in the cell unmodified by terrain improvements:

	const TerrainRecord *rec = g_theTerrainDB->Get(m_terrain_type);
	sint32 base;
	bool gotMovement = rec->GetEnvBase()->GetMovement(base);
	Assert(gotMovement);

Perhaps the base movement cost should just be stored along with the modified movement cost and accessed through a call to something like "World::GetBaseMoveCost"

Still no luck finding CtP2 in the bargain bins. I saw it a year ago at Mustapha Center in Singapore! Too bad I'm in Boston now....

[Long Axe]

I can’t find the it either... damn

[centrifuge]

Re: Boni of undersea tunnels for sea units bug

Originally posted by NelsonAndBronte

Still no luck finding CtP2 in the bargain bins. I saw it a year ago at Mustapha Center in Singapore! Too bad I'm in Boston now....

check Ebay I just saw at least 10 listings for it.

[Immortal Wombat]

What would be the effects of that on a unit which can move on Land AND one or both of the water terrains, and is on land when the function is called?

[NelsonAndBronte]

Oh, as in some sort of hovercraft? Thats a good point! I suppose then the solution is to state the assumption that that terrain movement boni are only applicable to units which can move on land. Thus, we actually want a CellUnitList::GetMovementTypeLand() function, and use the cell base movement cost for any unit for which this returns FALSE.

Thoughts?

[J Bytheway]

I think that's the best solution, but it does mean that a hovercraft will effectively be able to enter and leave undersea tunnels at will, which would be a bit strange, but too hard to avoid. I guess the tunnels have ventilation shafts that they can shoot up and down .

[NelsonAndBronte]

This is more complicated than I first thought. I added a new variable "m_base_move_cost" to the Cell class. A new function CalcBaseTerrainMoveCost() sets this value; it contains the base move cost of the cell unmodified by improvements or rivers, etc. Now CalcTerrainMoveCost() accesses this variable instead of looking it up again.
The problem now is that there is a lot of redundant code in other places in the code base. The first example is the Cell Kill() function. This is called whenever we want to make a cell "dead." Unfortunately all the Kill() function does is change the terrain type. The rest of the implications, cutting terrain improvements, changing the surrounding cells terrain improvements to reflect the cut etc.. are handled in the functions which call Kill(). That means all of the different ways a cell can get killed (pollution, nukes, etc) have the same code repeated over and over again -- and therefore I have to edit each of those locations to update the base terrain movement. Similarly the test to see if we are moving an air unit or not is scattered all over the place in the pathing algorithms. The same code is repeated no less than SIX times in TileHighlight.cpp alone!!
Ugh....

[MrBaggins]

Thats one of the problems with the code. They really weren't big on having code deal with things "atomically".

[MrBaggins]

Oh... and out of curiousity, NelsonAndBronte, but how did you come to decide upon that nick? Based on the historical figure and author? or?

[NelsonAndBronte]

Admiral Nelson was made Duke of Bronte by the King of Naples. He always signed his name "Nelson Bronte" thereafter. I use it because one day I needed an AOL Instant messenger name right away. Since my real name was already taken, I randomly picked "NelsonAndBronte" ....

[MrBaggins]

okies. You learn something new (the whole King of Naples, and Nelson thingie) everyday.

[NelsonAndBronte]

FWIW the author's name was originally "Brunty." Her father (i think) changed it to Bronte to take advantage of the association with Nelson and disguise it's Irish origins....

[Martin Gühmann]

Maybe it could also fix the sea city sprite bug, at least undersea tunnels and the sea city sprite bug are somehow related.

For the same code at other places: It has definatly to be removed. And replaced by one function or put into one function.

-Martin

[NelsonAndBronte]

Hi Martin,

I don't think that the undersea tunnel thing and city sprite problem are connected. In the case of ships getting the tunnel movement bonus, its because the function which returns movement point cost nowhere checks for the condition of whether or not the moving unit is a ship. It only checks to see if the unit is a plane, in which case it gets a fixed movement point cost. Everything else gets the 'improved' movement point cost.
I had a quick look at the sea sprite thing. AFAICS it was only looking at city styles to determine what spite to place. I didn't really see any code that checked for an ocean city and changed the retreived sprite. I didn;t look too hard either, so I could have missed it.

I've founds tons of redundant code. Oh well....

[Martin Gühmann]

Yes it should only look on the city styles but if you place in the default game a city on an ocean tile of course with the cheat editor in a fresh game the right sprite is shown. If you lay a undersea tunnel under the city and you add via the cheat editor one pop the city turns into a land city. If you have the advance that gives you undersea tunnels then a undersea tunnel is created under the city automaticly when it is build. And it changes its style immidiatly. So I did a test I removed the movement bonuns of undersea tunnels and the cities look as they are supposed to look. And if you take a look on the minimap and you disabled showing the terrain types, the tiles with undersea tunnels are shown as land tiles. So there must be something else that checks if a city is on a land tile by evaluating the movement flags.

-Martin