DEBUG: Event Manager, adding events

[Solver]

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.

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

There's separate code for executing the bombardment, counting the damage, etc., understanable things. However, can anyone enlighten me as to how to properly use that g_gevManager properly? Its class is GameEventManager, and I can see several different classes that do with it, like GameEvent, GameEventArgList, etc.

Any information on those classes would be much appreciated.

[Martin Gühmann]

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

[Solver]

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!

[Martin Gühmann]

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:

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

And this goes into your ..\ctp2_data\german\gamedata\scen_str.txt or whatever the language of your CTP2 currently is.

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}"

Of course you can edit the event handler to your needs:

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

As adding flags is done via dbgen it would be surprisingly if it doesn't work. If you want to know what some code does or get to know the values there use a message box, insert into c++ code something like this given you have some interger lieing around like int index:

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

Or if you want to know wich functions call a certain piece of code use Assert(FALSE); to make the program throuwing an assert and writing the assertion falure stack to ..\ctp2_code\ctp\logs\civ3logXX.txt.

-Martin

[Peter Triggs]

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.

[Solver]

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.

[Solver]

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?

[Peter Triggs]

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

[Solver]

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

[Peter Triggs]

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

[Solver]

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 .

[Martin Gühmann]

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

[Solver]

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

[Martin Gühmann]

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

[Solver]

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.