Maybe not, that's a thread and that's to execute. Things like "exploders", bombers, etc use "exec" at the top before level waittill spawn. And I think waitthreads are mainly used for xxx.scr::xx like objectives, and "exec" are maybe like "exec global/missioncomplete.scr".
In SP, it's like this:
levelend:
waitthread global/objectives.scr::current_objectives 0
wait 1
exec global/missioncomplete.scr
end
Live to map, not map to live. -mohaa_rox, .map
moderator
So... if I use waitexec XXX, it will not return control to the caller until all the threads in the group has terminated ( including calls like thread YYY inside the XXX method) ?
But if I use waitthread XXX, it WILL return control to the caller as soon as the waitthread XXX has terminated ( ignoring if a thread like thread YYY that is created inside the XXX method has not terminated yet ) ?
Wild guessing here... set me straight...
( can you write waitexec XXX at all without defining the fully qualified label, including the script file name and path? )
Yes, all correct, but remember thread groups are a bit weird. In most cases, a new thread is part of a seperate thread group. A thread only belongs to the parent thread group if it's in the same file and self is not defined (equal to self of parent thread).
$myobject waitexec <myscript>::mythread
mythread:
thread myotherthreada
self thread myotherthreadb
end
myotherthreada:
wait 5
end
myotherthreadb:
wait 10
end
In this example, myotherthreada belongs to the same thread group as mythread, but myotherthreadb has its own thread group (since it has 'self' in front of the call). Therefore the waitexec line will only wait till myotherthreada is finished.