Game Development Community

Problem trying to communicate between mission 'items'

by Darren Horton · in Torque Game Engine · 06/27/2003 (3:09 pm) · 6 replies

Hi All,

I'm having a few problems adding custom objects to the engine. Basically, I'm trying to achieve communication between two or more 'objects' in the same mission. I have successfully added two new objects to the engine - these are based on the Item class (copied the source files and renamed all classes, so I have a datablock and object class for both items). I have also added the required ,cs scripts to allow creation of the objects in the mission. All is well.

The two objects are PPlatform, and PPerson. At the moment, they are intended to emulate people (or anything) walking around on a platform. I basically want the platform to be the controlling entity - it will tell each PPerson object to move, and will also be responsible for collision and miscellaneous code applying to the PPerson classes as a group. When it receives it's processTick() event, I have attempted to send an event to one of the PPerson classes, by name, using Sim::sendCurrentEvent().

So, in the processTick() for PPlatform I have the following:

void PPlatform::processTick(const Move* move)
{
	//
	// Call parent processTick()
	//
	
	Parent::processTick(move);

	PersonMoveEvent *pEvent = new PersonMoveEvent();

	Sim::postCurrentEvent("Person1", pEvent);
}

However, when the event->process() routine is fired, the SimObject* seems to behave strangely. I have cast the pointer to a PPerson*, but I can't use the setPosition() function - I get a GPF in SimObject::setPosition() because xform (or mObjToWorld) is empty or uninitialised, yet the object is where it should be in the mission. Also, the mNameTag variable is = " " (0xcececece) when debugged - not "Person1", as I'd expect.

I know there is an issue with server/client objects, but I can't get my head around why this isn't working. Am I going about this the wrong way? Am I going totally insane?

Any help or advice would be greatly appreciated.

Regards,

]DaZMaN[ YM Studios
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Torque Owner Badguy
#1
06/27/2003 (3:38 pm)
So let me get this straight ..
your passing a SimObject->PPerson pointer.
thru the postCurrentEvent code.

am I to assume this much?
where in that code is the pointer set?
I see the move event created.
and passed to Sim
but where did you give that event the pointer to the PPerson you wish to have on the other side of the event?

am I missing something here?

Torque Owner Darren Horton
#2
06/27/2003 (3:52 pm)
The postCurrentEvent() function can also take the name of an object - "Person1" is the value given to the NameTag="" variable in the mission file:

new PPerson() {
       	position = "215.781 25.0838 100.101";
       	rotation = "1 0 0 0";
       	scale = "1 1 1";
       	nameTag = "Person1";
       	dataBlock = "PPerson";
       	collideable = "1";
       	static = "1";
       	rotate = "1";
};

nameTage is available to the engine as mNameTag, a member of SceneObject. It is possible to locate objects in the scene by calling Sim::findObject(char *objectName), and it is also possible (apparently) to send events to objects by name using Sim::postCurrentEvent(char *objectName, SimEvent *pEvent).

The postEvent() function seems to find the object alright, but the pointer it then returns (the one that is passed into PersonMoveEvent::process(SimObject *pObject) seems only part-configured - some of the default datablock values are there, such as the gravity and friction values from the original Item datablock. This pointer is provided by the back-end of Sim::postEvent() when it triggers the event. However, pObject->mNameTag is not "Person1", and whatever the object is, it won't allow me to modify it's position in the scene.

Arrrrrrrggh!

Cheers Badguy,

]DaZMaN[ YM Studios

EDIT : Sorry, just realised I didn't answer the important bit very clearly : no, I'm not passing a SimObject/PPerson pointer into the event class - I'm supplying the PPerson objects name in the scene - Person1 - when I generate the event. When the event is triggered, the engine provides a SimObject* for the name you passed - "Person1" - or so I thought!

Torque Owner J. Donavan Stanley
#3
06/27/2003 (4:32 pm)
Well there's at least part of your problem. nameTag isn't what you use for looking up objects it's objectName.

Torque Owner Badguy
#4
06/27/2003 (4:35 pm)
Well,
I think maybe we have exposed the problem then.

you need to resolve why you dont get your pointer back from the "engine"

:)

To be honest you might want to rethink the configuration you have.

I would think that maybe grouping could be a better option for this.
they are not very heavy and very handy.

I have not really looked at the event code.
but I would guess that it is heavier than grouping.

Edit : ..
good work Stanley!

Torque Owner Darren Horton
#5
06/27/2003 (4:45 pm)
Thanks guys,

I debugged again, and sure enough objectName is set to "Person1", so it's found the correct object at least. But, I still get strange problems. Basically, the process() routine in the event casts the pointer PPerson*, then calls a MovePerson() member. It's in this member (of PPerson), where I attempt to call setPosition(), causing a GPF. Strange, because if I simply make each PPerson class call MovePerson() when it receives a processTick() call, the bloody things move perfectly!

I took a quick look at the SimGroup class in the engine, and also down a couple of levels from there - I can see this being useful, but how would I make it react to processTick() type calls? It doesn't seem to have any event-style processing built in...

Thanks again,

Darren.

Torque Owner Darren Horton
#6
06/27/2003 (8:51 pm)
Sorted it guys, I found the point in ProcessList::advanceObjects() (gameProcess.cc) where the engine goes through the list of mission objects, and ticks them along. I can fit my processing nicely in there by catching the required scene objects on the way past. And, they contain the mNameTag value that I was using before :-)

Thanks for your pointers and advice guys,

-Darren.