Increasing Bombardment Range

[Solver]

Nah, that's not it. I have myself played the 14.09. playtest build without any problems, the one that was up for download.

However, taking a fresh copy of the original source and unzipping the zip file with all changed files from 13.09. over that, I get all that trouble. Assertion errors in great quantities, so I can't even start a new game.

But you probably compiled it exactly like that, just taking the source and unzipping the changes onto it, right?

[J Bytheway]

I think so. I don't remember having to take any special measures except rearranging the order of the include paths to put DXMedia before standard DirectX.

[Solver]

Yeah, during the summer and before I could do that myself, compile a debug version from the all-changes file posted by Martin and proceed to experiement with it. Now, however, I am for some reason unable to.

[Martin Gühmann]

Originally posted by Solver
Grr, I can't test changes to the code. I finally compiled & linked a Debug version on this comp, but I keep getting pummeled by various assertion faults when strating a new game. As for compilning a non-Debug version, that one crashes when starting a new game.

Which mods do you use Solver? For instance some text file hacks in GoodMod cause some problems and also the slic code causes asserts, because the improvment_t type is not implemented but is used in the events concerning tile improvement. However you get less asserts with the unmodded game.

-Martin

[Ekmek]

if (m_array[i].CanBombard(defender)) { 
			if(m_array[i].Bombard(defender, FALSE)) {
				numAttacks++;
				
				
				g_director->AddAttackPos(m_array[i], point);
				
				AddSpecialActionUsed(m_array[i]);
				
				if(!m_array[i].GetDBRec()->GetMovementTypeAir()) {
					m_array[i].SetMovementPoints(0.0);
				} else {
					m_array[i].DeductMoveCost(k_MOVE_COMBAT_COST, out_of_fuel);

I think may also be the part where, if people were inclined, to add something that checks for unit flag "blitz" which could allow a unit to attack multiple times if there were enough movements left a la Civ3....


Solver,
thinking of uses beyond just increasing bombard range and thinking about your "immobile" flag, would it be possible to just change the air units properties to "exclude" all of theterrain types. this may restrict them only to cities but if a flag was made that replicated all of the excludes and a later code for rebasing to airbases and carriers that might help finish your air combat code (assuming the changes to bombarg range work)

[Solver]

Martin,

I am running the game I compile without any mods. I'll try and see what I can do better now.

E,
For aircraft, I think MovementType: Air should stay, not to break anything else. So Immobile goes as a new flag that prevents movement. That's not the tricky part, I have gotten the Immobile flag to work. Of course, stacks that have an Immobile unit in them can't move either. The harder part would be the rebase code.... but for now I just need to get the damn thing to run properly.

[Solver]

The damn thing is running nice finally. Ths is what I've found. As it stands, the GetDistance in UnitData::CanBombard is reduntant. It only gets invoked when the unit is adjacent to its target.

I did a test with a Catapult(range 1) bombing an adjacent target. The bombard order was processed, CanBombard and GetDistance invoked, all fine, target bombarded. Then a Cannon (range 2) trying to bombard a target two squares away. The bombard order was received, and the Cannon moved adjacent to its target - and only THEN was the UnitData::CanBombard invoked. When a Cannon is given the bombard order, it's a SelectedItem class event, not a UnitData or ArmyData event. I suspect the following code is to blame for this movement:

void SelectedItem::Bombard(const MapPoint &pnt)
{
	PLAYER_INDEX player = GetVisiblePlayer();

	if(m_select_state[player] == SELECT_TYPE_LOCAL_ARMY ) {
		g_gevManager->AddEvent(GEV_INSERT_Tail, GEV_BombardOrder,
							   GEA_Army, m_selected_army[player],
							   GEA_MapPoint, pnt,
							   GEA_End);
		
	}
}

So we have a specific bombard event added to the event manager... but I have no clue how that works yet. Am off to look at it further.

[Ekmek]

Great stuff Solver. Thanks for digging into this. i'm going to bump your air combat thread in case you feel like completing it

[Solver]

Alright, I spent more time looking through that code... so the fire & forget is what interferes, definitely, and is hidden somewhere in between the event code. I couldn't see where it orders units to move or checks distance there...

With the GameEvent and GameEventSomething classes I got pretty clear, but then there's this weird Walker class I don't really understand. If someone could dig in into how events work and get an explanation on how events are processed and where it checks if units need to move to execute orders, it would be most appreciated.

[Ekmek]

STDEHANDLER(ArmyBombardOrderEvent)
{
	Army a;
	MapPoint pos;
	if(!args->GetArmy(0, a)) return GEV_HD_Continue;
	if(!args->GetPos(0, pos)) return GEV_HD_Continue;

	a->AddOrders(UNIT_ORDER_BOMBARD , pos);
	return GEV_HD_Continue;

From Armyevent.cpp

It looks like it goes to add orders and then to Unit Orders so I dont think its here

[Ekmek]

then there is this towards the end of the armyevent.cpp

void armyevent_Initialize()
{
	
	g_gevManager->AddCallback(GEV_MoveOrder, GEV_PRI_Primary, &s_ArmyMoveOrderEvent);
	g_gevManager->AddCallback(GEV_MoveToOrder, GEV_PRI_Primary, &s_ArmyMoveToOrderEvent);
	g_gevManager->AddCallback(GEV_MovePathOrder, GEV_PRI_Primary, &s_ArmyMovePathOrderEvent);
	g_gevManager->AddCallback(GEV_VictoryMoveOrder, GEV_PRI_Primary, &s_ArmyVictoryMoveOrderEvent);

	g_gevManager->AddCallback(GEV_UnloadOrder, GEV_PRI_Primary, &s_ArmyUnloadOrderEvent);
	g_gevManager->AddCallback(GEV_SleepOrder, GEV_PRI_Primary, &s_ArmySleepOrderEvent);
	g_gevManager->AddCallback(GEV_MoveUnloadOrder, GEV_PRI_Primary, &s_ArmyMoveUnloadOrderEvent);
	g_gevManager->AddCallback(GEV_EntrenchOrder, GEV_PRI_Primary, &s_ArmyEntrenchOrderEvent);
	g_gevManager->AddCallback(GEV_DetrenchOrder, GEV_PRI_Primary, &s_ArmyDetrenchOrderEvent);
	g_gevManager->AddCallback(GEV_DisbandArmyOrder, GEV_PRI_Primary, &s_ArmyDisbandArmyOrderEvent);
	g_gevManager->AddCallback(GEV_GroupOrder, GEV_PRI_Primary, &s_ArmyGroupOrderEvent);
	g_gevManager->AddCallback(GEV_GroupUnitOrder, GEV_PRI_Primary, &s_ArmyGroupUnitOrderEvent);
	g_gevManager->AddCallback(GEV_UngroupOrder, GEV_PRI_Primary, &s_ArmyUngroupOrderEvent);
	g_gevManager->AddCallback(GEV_InvestigateCityOrder, GEV_PRI_Primary, &s_ArmyInvestigateCityOrderEvent);
	g_gevManager->AddCallback(GEV_NullifyWallsOrder, GEV_PRI_Primary, &s_ArmyNullifyWallsOrderEvent);
	g_gevManager->AddCallback(GEV_StealTechnologyOrder, GEV_PRI_Primary, &s_ArmyStealTechnologyOrderEvent);
	g_gevManager->AddCallback(GEV_InciteRevolutionOrder, GEV_PRI_Primary, &s_ArmyInciteRevolutionOrderEvent);
	g_gevManager->AddCallback(GEV_AssassinateRulerOrder, GEV_PRI_Primary, &s_ArmyAssassinateRulerOrderEvent);
	g_gevManager->AddCallback(GEV_InvestigateReadinessOrder, GEV_PRI_Primary, &s_ArmyInvestigateReadinessOrderEvent);
	[b]g_gevManager->AddCallback(GEV_BombardOrder, GEV_PRI_Primary, &s_ArmyBombardOrderEvent);[/b]

[Ekmek]

Add I found nothing relating to bombard in unitevent.cpp and nothingin events.cpp either.

BUt maybe if you add a true/false check for the imobile flag in this unitevent.cpp:

STDEHANDLER(AddUnitToArmyEvent)
{
	Unit u;
	Army a;
	CAUSE_NEW_ARMY cause;
	if(!args->GetUnit(0, u)) return GEV_HD_Continue;
	if(!args->GetArmy(0, a)) return GEV_HD_Continue;
	if(!args->GetInt(0, (sint32 &)cause)) return GEV_HD_Continue;

	u->ChangeArmy(a, cause);
	
	Assert(u->GetArmy()->m_id == a->m_id);

	return GEV_HD_Continue;
}

it might prevent immobile units from joining armies...

[Ekmek]

The only other thing I can think of (and I'll stop posting) is in order.cpp

bool Order::IsSpecialAttack(UNIT_ORDER_TYPE order)
{
	switch(order) {
		case UNIT_ORDER_INVESTIGATE_CITY:
		case UNIT_ORDER_NULLIFY_WALLS:
		case UNIT_ORDER_STEAL_TECHNOLOGY:
		case UNIT_ORDER_INCITE_REVOLUTION:
		case UNIT_ORDER_ASSASSINATE:
		case UNIT_ORDER_INVESTIGATE_READINESS:
		[b]case UNIT_ORDER_BOMBARD:[/b]
		case UNIT_ORDER_SUE:
		case UNIT_ORDER_FRANCHISE:
		case UNIT_ORDER_SUE_FRANCHISE:
		case UNIT_ORDER_EXPEL:
		case UNIT_ORDER_ESTABLISH_EMBASSY:
		case UNIT_ORDER_THROW_PARTY:
		case UNIT_ORDER_CAUSE_UNHAPPINESS:
		case UNIT_ORDER_PLANT_NUKE:
		case UNIT_ORDER_SLAVE_RAID:
		case UNIT_ORDER_ENSLAVE_SETTLER:
		case UNIT_ORDER_UNDERGROUND_RAILWAY:
		case UNIT_ORDER_INCITE_UPRISING:
		case UNIT_ORDER_BIO_INFECT:
		case UNIT_ORDER_NANO_INFECT:
		case UNIT_ORDER_CONVERT:
		case UNIT_ORDER_REFORM:
		case UNIT_ORDER_INDULGENCE:
		case UNIT_ORDER_SOOTHSAY:
		case UNIT_ORDER_CREATE_PARK:
		case UNIT_ORDER_PILLAGE:
		case UNIT_ORDER_INJOIN:
		case UNIT_ORDER_INTERCEPT_TRADE:
		case UNIT_ORDER_ADVERTISE:
		case UNIT_ORDER_SETTLE:
		case UNIT_ORDER_DISBAND:
		case UNIT_ORDER_UNLOAD:
		case UNIT_ORDER_LAUNCH:
		case UNIT_ORDER_TARGET:
		case UNIT_ORDER_CLEAR_TARGET:			
			return true;
		default:
			return false;

lumps bombard as a special attack which usually requires moving close to something so it might be there? And it might require making separte code for bombard attacks and removing it from special attacks...

[Fromafar]

You are getting colder . When the bombard order is chosen from the user interface (or from the AI goal code), it is using the ArmyData::PerformOrderHere function. This function will insert a GEV_MoveOrder before the GEV_BombardOrder when you are not adjacent to the target. So by the time you will encounter the actual bombard order, you should be at the target already.

And the Walker class is nothing to be afraid of. It is used to traverse the elements of a list. Nowadays, this would be called an iterator. This is probably old (CTP1) code, since newer parts do use the standard iterator.

[Ekmek]

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();
	if (order_rec->GetRange()) {
		order_rec->GetRange(range);
		
		Assert(range <= moves || order_rec->GetTargetPretestAdjacentPosition());
	}

	
	for (sint32 i = 0; moves > 0 && i < range; i++)	{
		tmp_path->SnipEnd();
		moves--;
	}

	
	
	g_gevManager->Pause();

	

	
	if (game_event > 0)	{
		if (range > 0 || order_rec->GetIsTeleport() || order_rec->GetIsTarget())
			{
				
				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);
		}
	}

	
	if (tmp_path->GetMovesRemaining() > 0 && !order_rec->GetIsTeleport() && !order_rec->GetIsTarget()) {
		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);
	}
	else {
		
		delete tmp_path;
	}

	
	g_gevManager->AddEvent(GEV_INSERT_AfterCurrent, GEV_ClearOrders,
						   GEA_Army, Army(m_id),	
						   GEA_End);

	
	g_gevManager->Resume();
	
}