doMethodLater

Scripting Issues
1

For some reason all of my doMethodLaters are doubling up the processes that I put inside the task. Checked the manual a few times to see if I was doing anything wrong.

Call the task with this:

taskMgr.doMethodLater(6, self.serverTick, 'server-Tick' )

Task method looks like this:

def serverTick(self, task):
   print 'Server Tick ', time.strftime("%I:%M:%S",time.localtime())
   for i in self.listOfThings:
      ...stuff...
   return task.again

First go round fires off with the expected delay of 6 seconds. Second one happens instantly after the first one is executed and then waits 6 seconds to execute all over again.

Any thoughts?

2

Are you sure you aren’t accidentally calling doMethodLater() twice, and thus adding the task twice?

David

3

Yessir.

And the speed at which you post replies still amazes me!

Edited to add:

Okay so I ran this in a new Panda program as is and it works just fine. However, when I make this a method of a Repository in the DO system, it doubles up.

I’m trying to get away from the threading that I relied on when making the text-only version of the combat engine my project will be using. My first thought was to use the task manager and set doMethodLater tasks at the delays in which I would needed to account for different functions. If there’s a conflict with the repositories and task manager, would you suggest intervals instead?

4

There is certainly no inherent conflict with the DistributedObject system and the task system.

Are you sure you aren’t calling doMethodLater() twice? For instance, try putting a print statement whenever you call doMethodLater(). Also print taskMgr to list the currently-running tasks. Or, try replacing your doMethodLater statement with something like this:

taskMgr.remove('server-Tick')
taskMgr.doMethodLater(6, self.serverTick, 'server-Tick' )

which ensures that only one instance of server-Tick is added at a time, by first removing any previous instance.

David

5

You were right and I was wrong.

Feel free to delete this. Found the issue now trying to find the solution (and it wasn’t being created twice on purpose, the Repo’s createReady was being called twice for some reason).