18-04-2004 20:17									#1
	DEBUG: Event Manager, adding events Support Apolyton, buy Civilization: The Boardgame

I would like some help from those who have dealt more with the source. I've taken, as an example, the code for bombarding a tile.

code:

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);
		
	}
}

	18-04-2004 20:38									#2
	Support Apolyton, buy Civilization III: Complete

I would look where GEV_BombardOrder is defined and what it does to get started.

Anyway what do like to do in particular, maybe a slic function is more appropiate.

-Martin

	18-04-2004 20:41									#3
	Lose 30 kilos (of popups)

Gah, currently rebuilding the project to get proper browse information for it. From what I understand, adding the GEV_BombardOrder there goes to the part where damage is calculated, but I am not sure at the moment.

I'm just testing around at the moment with adding a unit flag, and thought that an event would be a good way to check how it works. Well, I know that I have no clue on how to add a button in the game panel to check if the flag works anyway!

	18-04-2004 21:19									#4
	Full PM-box? Change here!

For testing a unit flag you can write a slic handler I have here something:

This goes into your ..\ctp2_data\default\gamedata\scenario.slc:

code:

int_t int0;
int_t int1;
int_t int2;
int_t int3;
int_t int4;
int_t int5;
int_t int6;
int_t int7;
int_t int8;
int_t int9;
int_t int10;
int_t int11;
int_t int12;
int_t int13;
int_t int14;
int_t int15;
int_t int16;
int_t int17;
int_t int18;
int_t int19;
int_t int20;
int_t int21;
int_t int22;
int_t int23;
int_t int24;
int_t int25;
int_t int26;
int_t int27;
int_t int28;
int_t int29;

HandleEvent(ArmyClicked)'MG_Test'post{
	unit_t MGUnit;
	unit_t MGUnit2;
	GetUnitFromArmy(army[0], 0, MGUnit);
	int0 = CargoCapacity(MGUnit);
	int1 = MaxCargoSize(MGUnit);
	int2 = CargoSize(MGUnit);
	int3 = GetContinent(MGUnit.location);
	int4 = IsWater(MGUnit.location);
	if(CargoSize(MGUnit) > 0){
		int5 = GetUnitFromCargo(MGUnit, 0, MGUnit2);
		int6 = MGUnit2.type;
	}
	int7 = MGUnit.type;
	MessageAll('MGMAETestMessage');
}

code:

TEST_MESSAGE_FOR_MAE "0: {int0}, 1: {int1}, 2: {int2}, 3: {int3}, 4: {int4}, 5: {int5}, 6: {int6}, 7: {int7}, 8: {int8}, 9: {int9}, 10: {int10}, 11: {int11}, 12: {int12}, 13: {int13}, 14: {int14}, 15: {int15}, 16: {int16}, 17: {int17}, 18: {int18}, 19: {int19}, 20: {int20} 21: {int21}, 22: {int22}, 23: {int23}, 24: {int24}, 25: {int25}, 26: {int26}, 27: {int27}, 28: {int28}, 29: {int29}"

code:

HandleEvent(ArmyClicked)'MG_Test'post{
	unit_t MGUnit;
	GetUnitFromArmy(army[0], 0, MGUnit);
	int0 = UnitDB(MGUnit.type).WhateverFlag;
	MessageAll('MGMAETestMessage');
}

code:

char buff[20];
sprintf(buff, "%i", index);
MessageBox(NULL, buff, buff, MB_OK);

	18-04-2004 21:20									#5
	Increase Your PM Length

The Bombard event is a bit of a pain. They changed bombarding from CTP1 where you could bombard at range. Instead they put in a 'fire and forget' feature where you set the target and the unit moves up next to it and bombards. It would be nice to re-instate range so that the bombarding unit moves to within it's range of the target and then bombards. For example, you could then have the AI move a sub close to one of your ships and bombard, i.e., effectively fire a torpedo.

	18-04-2004 21:23									#6
	Support Apolyton, buy Call to Power 2

Ahhh thanks Martin that sounds like some good ideas, too. Just added what I wanted to through source modification anyway, and will now take a look at how it works. BTW, I can only start new games in the downloaded Playtest exe, and not the one I compile myself, even though I compile from the latest source tree. All other stuff works fine from both the Apolyton exe and the one I compile. Oh well, must be some local screwup here.

	18-04-2004 21:25									#7
	Support Apolyton, buy Alpha Centauri

quote: The Bombard event is a bit of a pain. They changed bombarding from CTP1 where you could bombard at range. Instead they put in a 'fire and forget' feature where you set the target and the unit moves up next to it and bombards. It would be nice to re-instate range so that the bombarding unit moves to within it's range of the target and then bombards. For example, you could then have the AI move a sub close to one of your ships and bombard, i.e., effectively fire a torpedo.

Yeah, but Unit.txt still has the BombardRange flag, which is set at 1 though. At the first look through bombard code, I couldn't see a check for BombardRange... Instead, it checks for ZBRangeAttack - which is I assume simply normal Ranged attack?

	18-04-2004 21:44									#8
	Support Apolyton, buy Civilization III: Complete

Yup, ZBRangeAttack is normal ranged attack. IIRC, there's also a range field in orders.txt thats no longer used.

	18-04-2004 21:45									#9
	Support Apolyton, buy Alpha Centauri

Drat them.

Well, what I wanted to do was to add a new movement type to Unit.txt, Immobile, that would prevent any and all movement for a unit. At least that seems to work...

	18-04-2004 22:38									#10
	Remove this text

That's a good idea. Have you already done it?

	18-04-2004 22:40									#11
	Suffering from ads?

Yes, just have a little problem that the unit dies if it tries to move - same way as a Knight dies when tries to move on a mountain. Can anyone point me to which procedure is executed first when a unit is given a move order, because that's where the abort move command should be inserted - as it is now, though, the abort movement isn't on top of the stack of calls dealing with move order, so the unit's killed at some point.

I will investigate further though, unless someone knows the exact function called first .

	18-04-2004 22:45									#12
	Enter the AD-FREE zone

If you know the code that causes the death you can do what I suggested above: Assert(FALSE);

Then you should find it in civ3logXX.txt.

-Martin

	18-04-2004 23:00									#13
	Support Apolyton buy from Amazon

BTW - aren't Asserts normally supposed to only work in Debug?

	19-04-2004 00:17									#14
	Full PM-box? Change here!

quote: Originally posted by Solver BTW - aren't Asserts normally supposed to only work in Debug?

Yes, but I suppose if you play around with the code that you want to use all the debug tools, and therefore use the debug setup.

-Martin

	19-04-2004 00:23									#15
	Avatar Enlargement: We've got the solution

Yeah, it's just that the debug setup seems to be pretty much a pain in testing, but well, it's fine.

OK, preliminary investigation reveals a pretty unfortunate thing. Since the movement type for a unit is no longer Land, but becomes Immobile, then an attempt to move it into a Land tile would fail regardless, that's apparently why it dies. Which means that my abortion of the move command after a move order is issued isn't sufficient. Looks like it has to ignore the move order before it's even issued - that is, as soon as an attempt to drag the unit or press the move button is made.

	19-04-2004 00:42									#16
	Browse Apolyton AD-FREE

Actual I wouldn't add it to the movement type, just an extra flag like:

Immobile

or

CantMove

Then this must be checked before, the actual move event. And of course if in a stack such a unit is, the move order button and the move order from the context menu must be removed.

-Martin

	19-04-2004 00:46									#17
	Support Apolyton, buy Galactic Civilizations

Yea, it must be added as a separate flag, actually. I looked at the code that fills the build queues, and it checks units by movement type. So, a city wouldn't list "Immobile" units in its queue, unless that code was changed too.

So I'll have to redo it as a separate flag. I just don't like that it's pretty hard to find the actual move event, as the order system is complex enough - though the place where I put it at least aborts movement for Immobile units the way I did them.

	19-04-2004 02:20									#18
	Browse Apolyton AD-FREE

quote: Originally posted by Solver I just don't like that it's pretty hard to find the actual move event, as the order system is complex enough

It's depressing how difficult it is to locate what you want under circumstances like this. Often you find that the code you're searching for is scattered across dozens of files, in bizarre places... For the movement code I'd takle it by searching out all places that access a unit's movement point allowance and see what calls them.

	19-04-2004 02:23									#19
	Support Apolyton or Terrorists Win

True, true. In that case, the SelectedItem class and files contain the code, as well as UnitData and UnitRecord, ArmyData and the Order classes. An army is looked from the selected item, where units are taken and indexed, and then they get an order to move, and the order processing is complex enough as it is, too.

But at least I do now have quite some knowledge about how unit movement is handled in CtP2 .

	19-04-2004 02:32									#20
	Enter the AD-FREE zone

If you're going at it through the Selected Item class, you're getting the human perspective. Soren Johnson once remarked "The AI can't push buttons."

	19-04-2004 02:36									#21
	Support Apolyton, buy Civilization III: Complete

Yeah, but it has to be done both for the human and the AI. It leads to the same place after that, but tracing the function calls is easier from finding where the human initiates them. The AI just skips to the subsequent classes without Selected Item being used.