Multiple onPositionTargets

#1 Using packages would be a way to achieve this.

#2 I don't think packages would work as you have to activate/deactivate them ... and if he's going to have these triggering at the same time in background schedules ... it might blow up ...

Though, I haven't really looked into packages in TorqueScript ... if I activate a package then call 'schedule' and then deactivate the package before the schedule actually fires off ... does the schedule run assuming the package was activated? (I'm thinking it won't ... but I could be wrong).


Pac, in the event that packages don't work out ... the best way to accomplish this, in my opinion ... would be to have a boolean value tell you whether or not you should call function A or B ... or both ...

function class::onPositionTarget(%this, ...)
{
  if(%this.shouldDoA) A(%this);
  if(%this.shouldDoB) B(%this);
}

function class:A(%this)
{
  %this.shouldDoA = false;
}

function class::B(%this)
{
  %this.shouldDoB = false;
}

Flipping the boolean after calling it ... very similar to how you handle 'moveLeft' and 'moveRight' style functions with the boolean ... but in this case, not defaulting to one direction or the other if both are true ...

Another option is to create a simple 'queue' object in your parent ... and these queued items would represent 'events' of some sort ... so when your object triggers event A, you toss an 'a event' into the queue, and then when event B is triggered a 'b event' in the queue ... and have onPosition just process whats in the queue ... setting a boolean, yet again, so that if your onPositionTarget is called while it's still processing a previous queue ... you just return out of it, as the next loop for the queue will return the latest event ... if done properly (don't get the count of the queue [ie; SimSet] and then use it ... calculate the count each loop interation and keep processing till it's empty)



This may sound like an 'odd' approach, but it's actually a fairly common approach to tackling the problem your working with ... dunno if it's a common 'torque script' approach though ... but it's how i handle my own things :)

#3 The question would be if schedule caches the function handles to the callbacks.
If not, packages shouldn't make a difference as they just "overwrite" the original declaration (note: implement default callbacks that are active with no packages enabled)

he could as well just try to overwrite the on... Function with a new one by assigning a different one to it like with any function handle.

don't know if this works with callbacks thought, never tried it and can't test it at the moment.

#4 @David: Yes, that's kind of the way I was thinking of doing it. It's actually how I do many things, just set flags here and there if there's a need to check where a certain object is in the code, or has been. Was getting a bit worried I'm missing something (which in the other cases I do this I still might be) but as long as I know that's not the case I'm happy. Didn't think of using queues this way but a good little technique, cheers.

@Mark: Haven't tried using packages, didn't even know they existed til now but seems like something I should at least read up on even if it doesn't work here, so thanks. Is it like some sort of wrapper function? Getting an odd feeling it's a bit over my head but as long as there's no source code digging involved I should be able to handle it. :)

#5 Packages are code blocks that can be activated/deactivated on demand and that can overwrite / deoverwrite previously implemented script functionality.