Increasing Bombardment Range

[Solver]

Ahh, a very good way of handling ArmyData::PerformOrderHere there, I think . At least it is cleaner than just disabling pathing for bombard orders altogether.

[Ekmek]

I notice the references to activision original that I don't remember in the code. Peter/Solver should I copy exactly Peter's code into the ArmyData.Cpp or is there something else I should add?

(and did either one of you compile it with the latest built

[Solver]

Well, try Peter's code.

Am I correct in understanding that the latest build has been compiled with .NET? If so, I won't be able to compile anything anymore.

[Martin Gühmann]

Originally posted by Solver
Am I correct in understanding that the latest build has been compiled with .NET? If so, I won't be able to compile anything anymore.

And what is the problem. You compile a program from the source code, not from the last build. This means whatever compiler we got compiling the source code in the past should compile it.

-Martin

[Solver]

Well, there are differences between .NET and VC6, maybe something was introduced into the code that the VC6 compiler would not take, which is what I am afraid of.

[Ekmek]

Peter do you have this in a cpp already? I'm a little lost to see where I should paste this code. I'm guessing that getbombardrange is a new function (I didnt see it anywhere) but is there somewhere it has to be placed? And the bombard bitof code is that pasting over something or a new bunch of code?

Originally posted by Peter Triggs
This hasn't been extensively tested but, fingers crossed, so far so good. That is, it seems to work.

The first thing I did was to add a function that lets you get the army's min and max bombarding ranges as determined by Units.txt:

 #if !defined(ACTIVISION_ORIGINAL)
//----------------------------------------------------------------------------
//
// Name       : ArmyData::GetBombardRange
//
// Description: Test if this army can bombard. Fill in min_rge and max_rge.
//
// Parameters : sint32 & min_rge : the min of the bombard ranges of this army's units
//            : sint32 & max_rge : the max of the bombard ranges of this army's units
//
// Globals    : -
//				
// Returns    : bool
//
// Remark(s)  : min_rge is not used yet, pft
//
// Called by  : ArmyData::PerformOrderHere, ArmyData::Bombard
//
//----------------------------------------------------------------------------
bool ArmyData::GetBombardRange(sint32 & min_rge, sint32 & max_rge)
{
	sint32 i;
	min_rge = 99999;
	max_rge = 0;

    for(i = 0; i < m_nElements; i++) {
	const UnitRecord *rec = g_theUnitDB->Get(m_array[i]->GetType());
	sint32 rge;
        rec->GetBombardRange(rge);
	if(rge){
            if(rgemax_rge)
	        max_rge = rge;
            }
	}
	if(max_rge > 0)
	    return true;
	
	return false;
}
#endif

This is used in Bombard as follows:

#if defined(ACTIVISION_ORIGINAL)
    if(!point.IsNextTo(m_pos)) {
#else
    sint32 dist = MapPoint::GetSquaredDistance(m_pos,point);
    dist = sqrt(dist);
    sint32 min_rge, max_rge;
    GetBombardRange(min_rge,max_rge);

    if(dist > max_rge) {//the target is out of this army's bombarding range
#endif
        return ORDER_RESULT_ILLEGAL;
    }

[/code]

[Martin Gühmann]

Originally posted by Solver
Well, there are differences between .NET and VC6, maybe something was introduced into the code that the VC6 compiler would not take, which is what I am afraid of.

And you really think that we add something to the code so that nearly all of the coders cannot compile it anymore.

One of our goals was to make the code compile on VC6 and .NET. We achieved the first thing very early and we achieved the second thing this summer, so why should we go back. Actual the goal is to make the code compile on as much compilers as possible. However I must admit that we lost the focus on this task.

And finally if you are not sure whether it compiles on VC6 anymore you can try, and if it doesn't you can complain here.

-Martin

[Solver]

Ahh yes, now that sounds good .

You know, however, the downside of extremely prolonged exposure to Linux is that it becomes harder to get to MSVC6 . Hmm, dreaming on about the days when it will compile with gcc perfectly and run under Linux... yeah baby .

[Martin Gühmann]

Originally posted by Solver
You know, however, the downside of extremely prolonged exposure to Linux is that it becomes harder to get to MSVC6 . Hmm, dreaming on about the days when it will compile with gcc perfectly and run under Linux... yeah baby .

Maybe you should contact all the Linux guys here and try to kick them into their !**es, or at least ask what happened during all the time. I mean maybe it is time to merge the two code bases. And maybe a little manual to make the code compile under a Windoof gcc would be nice. So that I can try my luck at home.

-Martin

[Solver]

Well as you probably know, a long time ago actually, a Linux port was compiled and reportedly even several turns were played. Hopefully also gcc will compile it the same way on both Linux and Windows.

Hmm, I wonder if I should ask Linux guys that are not CtP players .Has anyone heard from ctplinuxfan?

[J Bytheway]

Originally posted by Solver
Hmm, I wonder if I should ask Linux guys that are not CtP players .Has anyone heard from ctplinuxfan?

He posted some new documentation in the altered source files threwad not long ago.

[Martin Gühmann]

Originally posted by Solver
Hmm, I wonder if I should ask Linux guys that are not CtP players .

Of course you should tell them how wonderful CTP2 is espeacilly once it has been ported to Linux.

-Martin

[Fromafar]

Some observations about the ranged bombarding code:

We have to be more precise when defining what ranged bombarding should do. At the moment, the code is mixing 2 different concepts when comparing the range.

The value that is computed by GetSquaredDistance is using a (x, y) map grid with (2,0) coordinate difference for each step east, and a (1,1) coordinate difference for each step southeast. The value returned is 0.5 * (x-difference^2 + y-difference^2) where ^ is denoting the power operation. Example: 0.5 * (4^2 + 0^2) = 8 for 2 steps east, and 0.5 * (3^2 + 1^2) = 5 for 1 step east and 1 step southeast.
When this function is used in other contexts (vision range, city range), this value is compared to (0.5 + range)^2.
This will give you the familiar civilization city "range 2" shape with blind spots in the 4 corners, because the range compare value is 6.25 (being larger than 5, but smaller than 8).

However, the path steps are just 1 step for any direction. There is no difference in steps east or southeast. The actual path computation is based on terrain type and terrain improvents.

So the question is: do you want to be able to bombard from/into the blind spots with a unit with bombard range "2"?

Another problem will be how to handle stacks with bombarders with different range. Do you want to stop moving at the largest range - so part of your stack is unable to bombard? Or do you get closer, risking short range counter bombardments? I fear that introducing ranged bombardment will just result in weakening the AI, because human players are way better in making this decision.

[Solver]

I think that ranged bombard units should be able to bombard in all tiles within their range, including the "blind spots" as you call them.

As for the AI concern... bombardment being present at all already weakens it dramatically. You can make big bomard stacks now, bombard AI cities and take them with no losses.

Also, I actually hate that auto-pathing function when you can give an order to bombard/enslave/whatever, and your units will move to the target and then execute the order. Maybe we should consider getting rid of this feauture... or does anyone find it useful?

[Ekmek]

I don't find the "auto-move" useful at all, except I guess that it limits the human as much as the AI.

But I think the ranged bombrard should be implemented, its a good feature used in many TBs to differtiate units. Whats the difference with a cannon and catapult now, really?

Perhaps units that are strictly for bombarding (like cannons) not be able to group at all. Maybe that will add micromanagement but it makes them harder to protect too.

The AI in Civ3 doesnt build bombard units enough, or really effectively uses them. How far off is it to code the AI (maybbe personality dependent) to build bombardment units and have them specifically target the largest army group or nearest city as its goal?