Increasing Bombardment Range

[Solver]

I can't remember for sure... would you post armydata.cpp? I think there was something of interest in it...

[Ekmek]

zip:
mapdata.cpp
armydata.cpp
unitdata.cpp

[J Bytheway]

Originally posted by E
I see that (defender.IsAtLeastOneMoveLand())

also restricts it to one movement of land. I'm thinking I should change this to GetbombardRnage in order to have a value. Or I probably need to edit this function to something like "IsWithinRange" anybody see where GetBombardRange is?

That check is simply to ensure that the unit in question can move at all, because units which cannot move cannot bombard - it does not affect the range at all.

[Ekmek]

Ok, thanks J,


I'm thinking if I add a math function to the getNeighborposn that involves less than or equal bombard range, I can make a WithinRange function that will restore bombard range...

but I'm a littlle wary of making a whole new code and not able to test it

[J Bytheway]

Originally posted by E
Again, THank you very much for your walkthrough, it helped more than the C book I'm flipping through

Well, if your C book does not cover C++, then it will be rather less than what you want to understand this code properly.

[J Bytheway]

Originally posted by Solver
Can't remember when I saw that previously, but even the bombardrange unit flag was checked for in the code. It's the IsNextTo function call that overrides ranged bombard orders, IIRC.

I presume the orders will be passed through the ArmyData code before they ever reach the UnitData code, so a test there will be sufficient to prevent ranged bombarding.

[J Bytheway]

Originally posted by E
I'm thinking if I add a math function to the getNeighborposn that involves less than or equal bombard range, I can make a WithinRange function that will restore bombard range...

but I'm a littlle wary of making a whole new code and not able to test it

There is alreay a GetDistance function - it's used in the code you posted at the top of the thread - in fact that code is essentially exactly what you need, except that in ArmyData you have the complication that the units in the army might have differing BombardRange values, and some might not be able to bombard at all, and I'm sure there are other subtleties which don't come to mind right now...

[Solver]

ArmyData:BombardCity seems of interest as it has the (unused apparently) possibilities of damaging citizens/buildings during city bombardment.

The code I was referring to, though, is after all what is in the first post, specifically:

sint32 UnitData::CanBombard(CellUnitList &defender) const 

{
   const UnitRecord *rec = g_theUnitDB->Get(m_type);
   double r = rec->GetBombardRange() + 0.5;
   double rsq = r * r;

   MapPoint dpos;
   defender.GetPos(dpos);
   if(GetDistance(dpos, m_pos, (sint32)r) > rsq)
	   return FALSE;

So, it does check for whether the target is in the distance. I'm not sure if GetDistance > rsq will not return FALSE in some cases where it should actually return TRUE... but point is, all the code for ranged bombard is still there. I haven't found, however, where it tells the unit to move to its target before bombarding if there's a distance between them - disabling that is a must.

[Ekmek]

if I replace it with a function that says something like
if GetDistance =< BombardRange
return true

if getdistance > bombard range return false.

but

const UnitRecord *rec = g_theUnitDB->Get(m_type);
   double r = rec->GetBombardRange() + 0.5;
   double rsq = r * r;

   MapPoint dpos;
   defender.GetPos(dpos);
   if(GetDistance(dpos, m_pos, (sint32)r) > rsq)
	   return FALSE;

but this looks like it already does that...

[Ekmek]

LOl, I think solver and I saw the same thing. except I only have an inkling of knowing what the hell I'm doing...

[Solver]

Well, I did run into that problem. The code gives squared distance there. And one should never let me anywhere near geometrical applications of coding or algebra .

Problem: suppose a cannon with a bombard range of 2. A target standing two tiles ahead. Range=2, r=2.5, rsq=6.25. Since the target is in range, GetDistance should return something less than 6.25. However, the exact way that GetDistance works is something I don't understand really, and I can't check with the code right now.

Why is it using a squared distance anyway, and adds 0.5 to the bombard range? Can't there be a linear function for getting distance that treats all adjacent squares as distance=1, the ones adjacent to those as distance=2, and so on?

[Ekmek]

sint32 UnitData::GetDistance(UnitData* unit1, UnitData* unit2,
							 sint32 wrapRange)
{
	MapPoint u2pos = unit2->m_pos;
	return GetDistance(unit1, u2pos, wrapRange);
}

sint32 UnitData::GetDistance(Installation &inst, UnitData* unit2,
							 sint32 wrapRange)
{
	MapPoint iPos;

	inst.GetPos(iPos);
	return GetDistance(unit2, iPos, wrapRange);
}


sint32 UnitData::GetDistance(const UnitData* unit, const MapPoint &pos,
							 sint32 wrapRange)
{
	MapPoint uPos;

	unit->GetPos(uPos);
	return GetDistance(uPos, pos, wrapRange);
}

sint32 UnitData::GetDistance(const MapPoint &uPos, const MapPoint &pos,
							 sint32 wrapRange)
{
	return MapPoint::GetSquaredDistance(uPos, pos);

[Solver]

Yup, it's the MapPoint:GetSquaredDistance function that actually does the funky calculation, then.

I'm going for some bedtime reading now, hope that someone will provide insight on that function .

[Ekmek]

sint32 MapPoint::GetSquaredDistance(const MapPoint &from, const MapPoint &to)
{
	ScreenPoint src(from);
	ScreenPoint dst(to);
	sint32 dx = dst.x - src.x;
	sint32 dy = dst.y - src.y;
	
	if (g_theWorld->IsYwrap())
		dy = WrapDelta(dy, g_mp_size.y);
	if (g_theWorld->IsXwrap())
		dx = WrapDelta(dx, 2 * g_mp_size.x);
	sint32 retval = (dx * dx + dy * dy) / 2;
	Assert(retval <= OldSquaredDistance(from, to)); 
	return retval;

Why do we need to get squared distance for anything then?

[J Bytheway]

MapPoint::GetSquaredDistance does exactly what it says (modulo some tweaks to account for the isometric tile set and wrapping, of course...). The reason it adds 0.5 is so that diagonally adjacent squares (which have a squaredistance of 2) fit inside distance 1 (which has rsq=(1+0.5)^2=2.25). This is exactly the same function as is used for city radii, so that gives a visual demonstration of what the various distances include. IMHO it's better than the "number of squares to move" definition. Incidentally, there is no linear function that returns that number (at least, not linear in the mathematical sense...). Of course, it would fit in the game as a whole better if unit movement was more expensive diagonally too.