Trace() versus code example conflict

[DYLANzzz]

Looking up the parameters for fxDTSBrick::addEvent() / serverCmdAddEvent() and Im getting two different things.
The add-on for Checkpoint bricks as well as a few others lists the variables as...

Code: [Select]

(%enabled, %delay, %inputEvent, %target, %outputEvent, %par1)

But from the trace() I'm getting

Code: [Select]

(%enabled, %inputEventID, %delay, %targetID, %namedBrick?, %outputEventID, %par1, %par2, %par3, %par4)

It seems that the input event ID and delay are switched (I dont even know why though, because if you read an event row in the gui straight across, it seems more like the top pattern), and there is no %namedBrick (I think this is a named brick ID but it was giving me either a blank (with no named brick selected), or a -1 (with one selected) but I didn't test this rigorously).
I don't understand how the top one would even function by having two parameters switched and missing a parameter. I understand how leaving out %par2, 3 and 4 wouldn't change anything, but yeah...

Clarification would be appreciated

[Ad Bot]

[Greek2me]

These are the arguments I use for serverCmdAddEvent.

Code: [Select]

serverCmdAddEvent(%client,%enabled,%inputEventIdx,%delay,%targetIdx,%namedTargetNameIdx,%outputEventIdx,%par1,%par2,%par3,%par4,%par5,%par6,%par7,%par8,%par9,%par10,%par11,%par12,%par13)

[DYLANzzz]

These are the arguments I use for serverCmdAddEvent.

Code: [Select]

serverCmdAddEvent(%client,%enabled,%inputEventIdx,%delay,%targetIdx,%namedTargetNameIdx,%outputEventIdx,%par1,%par2,%par3,%par4,%par5,%par6,%par7,%par8,%par9,%par10,%par11,%par12,%par13)

That's the one I had already been going with. Does this mean serverCmdAddEvent() and fxDTSBrick::addEvent() are different? (Ive seen both sets of arguments for fxDTSBrick::addEvent())

[DYLANzzz]

Okay did a bit more research

Code: [Select]

fxDTSBrick::AddEvent(%this, %enabled, %delay, %inputEvent, %target, %outputEvent, %par1, etc...);

calls

Code: [Select]

serverCmdAddEvent(%client,%enabled,%inputEventIdx,%delay,%targetIdx,%namedTargetNameIdx,%outputEventIdx,%par1,%par2,%par3,%par4,%par5,%par6,%par7,%par8,%par9,%par10,%par11,%par12,%par13);

They seem to both use a different set of parameters.

Still not sure how fxDTSBrick::AddEvent() actually uses the named brick feature for target though

[Greek2me]

serverCmdAddEvent calls fxDtsBrick::addEvent.

::addEvent takes event and target names, while serverCmdAddEvent takes their IDs and then converts them to names.

[DYLANzzz]

serverCmdAddEvent calls fxDtsBrick::addEvent.

::addEvent takes event and target names, while serverCmdAddEvent takes their IDs and then converts them to names.

I was using trace on the Checkpoint brick placement and if I'm reading the trace right, it seems that serverCmdAddEvent was higher in the "heirarchy" (it was tabbed over more and called later) than fxDTSBrick::addEvent was so that means it's calling it? And if this is true, why doesn't serverCmdAddEvent() have the brick ID in it, 19179 (to know which brick to apply the event to)


To me, serverCmdAddEvent() calling fxDtsBrick::AddEvent() makes more sense (because of how the $OutputEvent* variables work and the principle of encapsulation for fxDTSBrick), but I'm just not seeing that in the trace?

[Zeblote]

I was using trace on the Checkpoint brick placement and if I'm reading the trace right, it seems that serverCmdAddEvent was higher in the "heirarchy" (it was tabbed over more and called later) than fxDTSBrick::addEvent was so that means it's calling it? And if this is true, why doesn't serverCmdAddEvent() have the brick ID in it, 19179 (to know which brick to apply the event to)


To me, serverCmdAddEvent() calling fxDtsBrick::AddEvent() makes more sense (because of how the $OutputEvent* variables work and the principle of encapsulation for fxDTSBrick), but I'm just not seeing that in the trace?

No, that's actually correct, the addevent function calls servercmdaddevent with the owner of the brick, which is also why addevent doesn't work while the owner isn't in the server

It most likely get's the id from some variable, maybe wrenchbrick


Not sure what you're doing but if it is about adding events by script you're probably better off by directly modifying the brick variables that hold the events (add an event to a brick and call dump)