Calling functions with schedule

#1 If your worried that your object will be picked up by two seperate things at once you can make a variable on your object and check to see if it can be picked up and if it can be picked up change the variable to say it can't be picked up.



something like:

function AIWheeledVehicle2::pickupHuman(%obj)
{
// wait until assigned human is > 0
if (%obj.pickedUp == 1)
{
	return;
}
else
{
	%obj.pickedUp = 1;

	if (%obj.totalHumans < %obj.loadCap)
	{
		%obj.schedule(1 * 1000,"pickupHuman",%obj);
	}
	else
	{
		// now go
		%obj.setHalt(false);
	}
}
}

Then when it's able to be picked up again you need to reset that variable %obj.pickedUp = 0;

#2 The engine (simplifying) keeps a list of all these schedules and must process through it each tick and make the appropriate calls. "At the same time" just means "in some sequence during the same tick".

Each object will try to call this function on some tick that includes the millisecond it was scheduled for.

If the function is called, it will complete before the next is called. (They are called one at a time, in some order that could be determined with study.) If one of the functions should happen to take forever, then your game will stop and wait for it. (Forever.) We know it works this way because the TorqueScript ssytem is run in a single thread. Imagine the chaos otherwise.


You probably shouldn't plan on the schedules for any particular object being called before any other. It may work out that those who were scheduled first get run first when both calls are to be made in a particular tick. it might also matter which millisecond it was scheduled to be called on within the 32 milliseconds that schedules will be called for on a particular tick. If this were true, then scheduling for 101 ms later would take place before one scheduled at 102 ms later. But it depends on how the code was written. The only way to figure this out is to actually dig into the code and figure out what the exact constraints are.

It is safer to assume that no particular order will be followed and make sure your code can handle all possible orders.

Suppose you do dig into the code and figure out exacly how it works and then come up with a really difty resource that everyone starts using that depends on exactly this execution order that you have painstakingly researched.

Then what happens when the most evil intern installed into GG by the gaming conglomerates makes a small change in the scheduling system, supposedly to fix some critical bug. The evil intern then jumps into his helicopter and escapes. You, however, remain to handle all the threads that suddenly spring up when 1.5.3 breaks your carefully optimized resource... Best thing to do in this situation is to buy a new license under an assumed name ;)

#3 @mb - thanks for the idea. I'm assigning humans to a designated truck.

The truck has a load cap and will halt until its load cap is reached. Humans walk up to their designated truck and jump into, incrementing the designated trucks total humans inside until it matches the load cap - then it moves off. This way humans are only jumping in trucks that are actually expecting them - damn complicated and needs a refactor but works for now.

The humans also find a new spawn spot next to where the trucks drops humans. Each human finds a spawn spot that is again designated to that truck. When the truck arrives at the drop off there are spawn points for each humans to appear from. This way only humans assigned to that truck spawn at points assigned to that truck - I'm sure this will bite me in the butt later but again, works for now :)

@ Matthew - thanks for explanation - that makes sense, and answers my question. I don't mind that they run the functions out of sequence as long as they do it before the truck drives off - another consideration I've made just in case humans can't get there because they are blocked or are dead.