05-10-2004 20:11									#61
	Support Apolyton or Terrorists Win

Thanks a lot Fromafar. I had previously looked through the gameevent code, but not found the right place to look.

ArmyData::PerformOrderHere looks interesting. I'm not sure, but I hope I'll have time in some three hours to look at it. There are, as I see it, several ways to change bombard to range. First - pay attention to the order_rec->GetRange(range); line and modify the GEV_BOMBARD order to have its range equal to bombarding unit's bombard range. Other ways seem to be not so clean, so this way is, I am sure, the best, just gotta check the OrderRecord or whatever class it is then.

I am not sure yet, but I suspect that it might create a situation where the game wouldn't let ranged bombard units bombard targets they couldn't reach (such as over a strip of water they can't cross).

If I have time this evening, I'll report on my findings in ~4 hours.

	07-10-2004 02:49									#62
	Support Apolyton, buy Civilization III: Complete

Solver,

Any luck or is it related to not being able to compile again?

	07-10-2004 20:29									#63
	Got spare money?

Able to compile here and all is fine. Just hit a little snag now, but that's to be fixed soon.

	08-10-2004 01:02									#64
	Put an end to popups!

Awesome. looking forward to it.

	06-11-2004 07:35									#65
	Tired of ads?

quote: Originally posted by Solver Able to compile here and all is fine. Just hit a little snag now, but that's to be fixed soon.

Solver any luck?

	06-11-2004 10:48									#66
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

IDEA!

Ranged bombardment = good

add 2 things to it...

1- the paradrop has a part of the code that allows a paradrop to "miss" its drop and land its drop in an adjacent tile (as long as they can land there and its vacant)
USE THIS CODE somehow,... (I haven't looked at it) for the ranged bombardment give it a chance to miss

2- say, every 1 tile past adjacent, scale the previous chance and add a +20% chance to miss, therefore the max distance for firing is 4 squares away to guarantee a chance of a direct hit


which gave me an idea for a new unit type...

remember railway cannons in WW2???
railroad + explosives = railway cannons
limit the cannons to movement to railroads ONLY and (for future maglev's too) and drop its max movement to 1 square.
give them some insane range like 15 tiles, a very powerful shell hell even two shells, and a 20% accuracy at max range.

this kind of unit could decimate a city from afar, and would require a ranged means of engagement, LIKE BOMBERS!... I never really used bombers much in the origional game, but this unit would give it a reason to.

and the levithan, give it the same ranged ability, but no limitation on where to move.

just my .02$

	09-11-2004 22:28									#67
	Support Apolyton

Solver sent me this. i'm going to dig around unless any coders can double check it first...

quote: I haven't compiled this... but I'll give you te pointers on what I think has to be done. In ArmyData::PerformOrderHere, it enacts the "fire and forget" feauture. I believe that the line 8555 (around that, that's with my changes) has to be changed from code: if (tmp_path->GetMovesRemaining() > 0 && !order_rec->GetIsTeleport() && !order_rec->GetIsTarget(){ to code: if (tmp_path->GetMovesRemaining() > 0 && !order_rec->GetIsTeleport() && !order_rec->GetIsTarget() && order_rec->GetEventName() != "BombardOrder") { Or just createa new function in order_rec like GetIsBombard, which I don't think should matter, but the above way seems easier. Likewise, in ArmyData::Bombard, make sure that code: if(!point.IsNextTo(m_pos)) {//rem: this is why you can't bombard from range as in Civ:CTP return ORDER_RESULT_ILLEGAL; Is not active. Something like this should work. code: if(point == m_pos) { return ORDER_RESULT_ILLEGAL; } else { if (!CanBombard(point)) { return ORDER_RESULT_ILLEGAL; } /* if(!point.IsNextTo(m_pos)) {//rem: this is why you can't bombard from range as in Civ:CTP return ORDER_RESULT_ILLEGAL; }*/ } That's what I have tinkered with, but these ideas are untested, yet they are probably a good foundation for checking out.

I'll dig up the code and do the changes but I dont have a compiler (but I will test it)

	11-11-2004 06:54									#68
	Enter the AD-FREE zone

I made solver's recommendedd hanges, can anyone with a compiler make an exe for this? I'll test it

Attachment: armydata.zip
This has been downloaded 2 time(s).

	15-12-2004 10:29									#69
	Support Apolyton, buy Galactic Civilizations

Actually, it turns out to be more complicated than that.

It's not that difficult to get an army to bombard from range, provided that it's within it's range of the target. Where it gets hairy is when the army is outside of that range. I have a feeling that it may be necessary to change UnitAstar::FindPath so that it can return a 'ranged path': visualize this as solid lines from the army's position to the point at which it is within bombarding range of the target and then, say, dotted lines from that point to the target. If the army is out of range we then insert a move order to that firing point.

Comments greatly appreciated (especially if someone can come up with an easier way of doing this).

	15-12-2004 10:35									#70
	Lose 30 kilos (of popups)

By increasing bombardment range do you mean being able to bombard
further than the tile next to the unit?

I apologize for my ignorance.

	15-12-2004 10:55									#71
	Support Apolyton buy from Amazon

Yup, that's the way it used to work in CTP1.

	15-12-2004 22:46									#72
	Remove this text

quote: It's not that difficult to get an army to bombard from range, provided that it's within it's range of the target. Where it gets hairy is when the army is outside of that range. I have a feeling that it may be necessary to change UnitAstar::FindPath so that it can return a 'ranged path': visualize this as solid lines from the army's position to the point at which it is within bombarding range of the target and then, say, dotted lines from that point to the target. If the army is out of range we then insert a move order to that firing point.

Or just tell the game not to draw an Astar path if the target is outside of range, returning an order invalid message .

	16-12-2004 22:15									#73
	Browse Apolyton AD-FREE

Where can we add that in the code?

quote: Originally posted by Solver quote: It's not that difficult to get an army to bombard from range, provided that it's within it's range of the target. Where it gets hairy is when the army is outside of that range. I have a feeling that it may be necessary to change UnitAstar::FindPath so that it can return a 'ranged path': visualize this as solid lines from the army's position to the point at which it is within bombarding range of the target and then, say, dotted lines from that point to the target. If the army is out of range we then insert a move order to that firing point. Or just tell the game not to draw an Astar path if the target is outside of range, returning an order invalid message .

	18-12-2004 03:16									#74
	Support Apolyton, buy Civilization III: Complete

I just had a quick look at the changes you made to ArmyData.cpp. Unfortunately, I have been too busy this week to do much coding and compiling. And I am not sure whether I will get around to do anything on CtP2 in the next 2 weeks.

The change in Bombard looks OK to me. However, the change in PerformOrderHere is probably not needed. Actually, reinstating the original code may already go a large step towards what you are looking for. Note that the "SnipEnd" for-loop will have removed the last "range" steps of the path before inserting the move order - so you will stop moving when "range" steps from the target, and start the actual bombarding from there. When the path is straight, this is most likely just what you want. When the path is bent (around unpassable or higher move cost tiles), you may want to replace the simple for-loop with something more intelligent, so you will stop at the first step of the path that allows you to bombard the target.

Even better would be to make a specialised BombardAStar - as suggested by Peter Triggs - to be used e.g. in the SelectedItem class when the path is computed and you have the bombard order selected.

	18-12-2004 06:35									#75
	Support Apolyton, buy GURPS/ Alpha Centauri

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:

code:

 #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

code:

#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:

void ArmyData::PerformOrderHere(const OrderRecord * order_rec, const Path * path)
{
    Assert(path != NULL);

    if (path == NULL)
	return ;
    if (m_flags & k_CULF_IN_SPACE)
	return;
    Path *tmp_path = new Path((Path *) path);
    MapPoint target_pos;

    if (tmp_path->GetMovesRemaining() > 0)
    {		
	target_pos = tmp_path->GetEnd();
    }
    else
    {		
        target_pos = m_pos;
    }
    if (s_orderDBToEventMap == NULL)
	AssociateEventsWithOrdersDB();
    Assert(s_orderDBToEventMap != NULL);
    sint32 game_event = s_orderDBToEventMap[order_rec->GetIndex()];
    sint32 range = 0;
    sint32 moves = tmp_path->GetMovesRemaining();
    //order_rec: range = 0 (army must be on top of tile) or range = 1 (can execute order from adjacent tile)
    if (order_rec->GetRange()) {
	order_rec->GetRange(range);
	Assert(range <= moves || order_rec->GetTargetPretestAdjacentPosition());            
    }

#if !defined(ACTIVISION_ORIGINAL)

    sint32 min_rge, max_rge=0;
    MapPoint move_pos = m_pos;//move_pos will become a position to move to if trying to bombard out of range
    Path *move_path = tmp_path;//copy tmp_path
    if (strcmp (order_rec->GetEventName(),"BombardOrder") == 0){
        if(GetBombardRange(min_rge, max_rge)){
            sint32 dist = MapPoint::GetSquaredDistance(m_pos,target_pos);
	    dist=sqrt(dist);
            if(dist > max_rge){//target is out of range
                for(sint32 i=0;iIncDir();			
                    tmp_path->GetCurrentPoint(move_pos);
                    dist =  MapPoint::GetSquaredDistance(move_pos,target_pos);

		    dist = sqrt(dist);

                    if(dist <= max_rge){ //we're now within range
			tmp_path->Start(m_pos);//reset tmp_path
			for(sint32 j=1; jSnipEnd();
			}
			i=moves;//exit the loop and continue
		    }
		}
	    }
        }
    }
    else{
#endif		
        for (sint32 i = 0; moves > 0 && i < range; i++){
	    tmp_path->SnipEnd();
	    moves--;
	}
#if !defined(ACTIVISION_ORIGINAL)
    }
#endif	
    g_gevManager->Pause();
    //insert order's game_event here	
    if (game_event > 0)	{
	if (range > 0 || order_rec->GetIsTeleport() || order_rec->GetIsTarget())//event needs target pos
	    {
	    	g_gevManager->AddEvent( GEV_INSERT_AfterCurrent, 
		static_cast(game_event), 
		GEA_Army, Army(m_id), 
		GEA_MapPoint, target_pos,
		GEA_End);
	}
        else {
		g_gevManager->AddEvent( GEV_INSERT_AfterCurrent, 
		static_cast(game_event), 
		GEA_Army, Army(m_id), 
		GEA_End);
	}
    }
    //insert GEV_MoveOrder here, i.e., move adjacent to target pos or within bombarding range of target pos	
    if (tmp_path->GetMovesRemaining() > 0 && !order_rec->GetIsTeleport() && !order_rec->GetIsTarget()) {
#if !defined(ACTIVISION_ORIGINAL)
        if(max_rge){//max_rge >0 implys BombardOrder and army has bombarding units
	    if(move_pos != m_pos){//then first move army to move_pos

                g_gevManager->AddEvent(GEV_INSERT_AfterCurrent, GEV_MoveOrder, 
		    GEA_Army, Army(m_id),
		    GEA_Path, move_path,
		    GEA_MapPoint, move_pos,
		    GEA_Int, (game_event == -1),
		    GEA_End);
	     }
	     //bombard target_pos

	     g_gevManager->AddEvent( GEV_INSERT_AfterCurrent, 
	         static_cast(game_event), 
		 GEA_Army, Army(m_id), 
		 GEA_MapPoint, target_pos, 
		 GEA_End);

	 }
	 else{//not a bombard order
#endif
             g_gevManager->AddEvent(GEV_INSERT_AfterCurrent,
	         GEV_MoveOrder, 
		 GEA_Army, Army(m_id),			
		 GEA_Path, tmp_path,		 
		 GEA_MapPoint, target_pos, 
		 GEA_Int, (game_event == -1), 
		 GEA_End);

#if !defined(ACTIVISION_ORIGINAL)
	}
#endif
    }
    else {
	     delete tmp_path;
    }
    g_gevManager->AddEvent(GEV_INSERT_AfterCurrent, GEV_ClearOrders,
	GEA_Army, Army(m_id),
	GEA_End);
    g_gevManager->Resume();
}

	18-12-2004 18:36									#76
	Support Apolyton, buy GURPS/ Alpha Centauri

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.

	19-12-2004 10:10									#77
	Support Apolyton buy from Amazon

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

	19-12-2004 22:50									#78
	Support Apolyton

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.

	19-12-2004 23:01									#79
	Support Apolyton, buy Call to Power 2

quote: 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

	19-12-2004 23:17									#80
	Put an end to popups!

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.

	19-12-2004 23:29									#81
	Avatar Enlargement: We've got the solution

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?

quote: 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: code: #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: code: #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]

	19-12-2004 23:31									#82
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

quote: 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

	19-12-2004 23:39									#83
	Support Apolyton, pre-order Civilization IV

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 .

	19-12-2004 23:58									#84
	Increase Your PM Length

quote: 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

	20-12-2004 01:07									#85
	Support Apolyton buy from Amazon

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?

	20-12-2004 18:12									#86
	Help yourself to an AD-FREE life

quote: 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.

	23-12-2004 02:24									#87
	Support Apolyton

quote: 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

	05-01-2005 03:48									#88
	Help yourself to an AD-FREE life

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.

	05-01-2005 04:08									#89
	Enter the AD-FREE zone

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?

	05-01-2005 04:22									#90
	Support Apolyton, pre-order Civilization IV

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?