TriggerObjectTypes

#1 It looks like addToScene() never is called for the trigger how can I impliment it to be added?

#2 Go to the trigger class, and have it call addToScene?

#3 Ben when I do that I get this error

E:\After School Cartoons\Lore\loreengine\engine\game\trigger.cc(107) : error C2065: 'addToScene' : undeclared identifier
Error executing cl.exe.

Is there a class I need to be included for this function to work?

#4 You need to call addToScene in the object.

#5 Nope tried that too, so vertict is addToScene() is not adding it to the SimSetIterator

#6 SO here is another approach in the trigger I do this

if (isServerObject())
   {
	   Sim::getServerTargetSet()->addObject(this);
   }
   else
   {
	  Sim::getClientTargetSet()->addObject(this);
   }

then in my GUI I do this

SimSetIterator itr(Sim::getServerTargetSet());    
        if(!isServerObject())    
            itr = SimSetIterator(Sim::getClientTargetSet()); 
              
        for (; *itr; ++itr) { 
            if ((*itr)->getType() & TriggerObjectType) {

First off if I try to compile the GUI part with the isServerObject I get an error saying it is undeclared identifyer, then if I add netObject.h to the includes I get newline in constant error

Lab Rat just informed me that triggers are not ghosted, so does that mean I can't acess them at allfor the client. I was able to get the code working for the server just not clients.

#7 Ok found some more interesting stuff

trigger get stopped from being ghoste like this

mNetFlags.clear(Ghostable);

and gets toggled on and off when you open up the editor. So once I set it to always be ghostable this code worked but then it renders the box of the trigger. Finally this little snippet of code in the packUpdate

Quote:
// Note that we don't really care about efficiency here, since this is an
// edit-only ghost...

Doesn't look so good, and after testing it one dosn't seem optimized at all, becaused is resulted in a lot of lag.

So some questions, does PackUpdate() get called only if an object is set as ghostable, if so how should I optimize it? or is this lag a result of the additional rendering of the trigger boxes?

#8 OK well I was able to make the triggers Ghosted, now I just want a cetain trigger. My inital attempt was this

if(dStrcmp(shape->getDataBlock()->getName(),"TeamTrigger") == 0)

It worked well for the server, but when a client joins it caused a crash. Anyone have an Idea?

#9 Have you tried debugging it?!?!

#10 The datablocks aren't loaded at the same time as the shapes, so you need to be careful about accessing members in them.

Why don't you just transmit the location of the trigger to the client via a remote script call, if you only want one? Or use a NetEvent (see netTest.cc for details).

#11 @J. Donovan : debugger says

dodwords:
[b]->[/b]007FC760   mov         eax,dword ptr [edx]

I can only read the debugger when it is in the C++ code , the assemble stuff still beyond me.

@Ben : I have made it ghost only what is needed so there is no overhead.

I still can't find the dataBlock's name. Are the names accesable to the client? My main concern is that the AITurrets use triggers for player detection. I have also tried culling out triggers with an owner (turrets) set but neither seem to work.

Any Ideas?

#12 I think there is overhead; development overhead ;). The two ways I suggested would be much faster and simpler to implement if you only want a one-shot tansferral of the trigger data.

As for the datablock - like I said, it's PROBABLY not loaded yet. The server transfers datablock info the client, but it takes a while for it to get across, make sure that getDatablock is even returning a valid pointer!!!

#13 I know what you are thinking, about development overhead, code for the trigegr's boxes, rending the polygons, I got that all toggled via a flag ;) it just send it's location.

I know that shape is ok, but when you say "is valid" what do you mean?
I did

GameBase* data = shape->getDataBlock();
if(data != NULL)

But still crashes the client.

#14 You meant:

GameBaseData* data = ...

Since the GameBase's datablocks are... of type GameBaseData.

#15 Yeah I actually am using that, but is my if statment the correct test for validity?

#16 Yeah, it should be.

#17 Anthony, If shape->getDataBlock() is blowing up then you don't have a valid shape pointer. You really might want to reconsider your approach.

#18 Any recommendations?

notice how the line Any Ideas? was at the end of each post. That means I have run out of them ;)