Tasks, Priority and Execution

General Discussion
1

I need some advice here -

I’m finding something out the hard way and that is…

Where code is placed or where tasks are added to the task manager (within your entire source file)
makes a difference on the execution outcome.

For example, I had a task that ran and stopped when it was done (TaskA). I created another task that pretty much did the same thing as TaskA, but with different values (TaskB). TaskB however, did not stop. That is, it did not call return task.done. TaskB continued to loop.

What I found out was, the rate TaskA executed codes was not the same rate TaskB executed codes. I guess this wouldn’t really be a shocker because TaskA does stop and has to be restarted.

But this is what gets to me…

A new task (TaskC). Task C is like TaskA, that is it starts and then stops and has to be restarted again. The difference is, TaskC is set up higher in the source file (that is, TaskC source code is written way before TaskA source code).

TaskC had a different code execution speed than TaskA, but when I moved TaskC’s source code down where TaskA’s source code was, TaskC and TaskA executed at the same speed!

God!!!

Someone please clear this up for me! I feel like I’m loosing my mind!

Is this behavior do to the fact I am not setting a priority to tasks when starting them?

What I'm doing:
	self.MyA = taskMgr.add(self.TaskA, "Atask");

What I'm not doing:
	self.MyA = taskMgr.add(self.TaskA, "Atask", 4);

If I remember correct, I think Drwr did say I could prioritize my tasks with that extra argument.

2

When you call taskMgr.add(), you add the task to the default task chain. Each frame, all of the tasks on the task chain are executed exactly once. If the task returns task.cont, then it is retained on the task chain for the next frame; otherwise it is removed.

So, a repeating task will execute exactly once each frame. A stopping task will execute exactly once, period. If you add the tasks back to the task chain explicitly, they will execute more often, of course.

The placement of the task function itself within the body of code means nothing.

Assuming you don’t change the task chain parameters, the priority setting is really the sort setting, and all it controls is the relative order of execution of the tasks within the task chain. A task with a lower sort value will execute sooner than one with a higher sort value, but both will still execute only once per frame. For two tasks with the same sort value, the relative order of operation is indeterminate, but could be affected by the order in which they were added to the task chain.

I don’t know how you’re measuring the “rate” at which your tasks are executing, but unless you are adding multiple copies of your tasks to the task chains, they will not execute faster than once per frame.

Perhaps you can gain some insight by printing out taskMgr, which will show you the list of tasks that you have added to the task chain.

David

3

Extreme programming has brought this P3D behavior to light. I don’t think you’ll experience it with light weight programming or medium.

The way P3D is structured is way different from anything I’ve used before, so I expected execution to be different anyway.

The only solution I have found is to keep my tasks sitting where they need to be within my source and I made sure all my similar tasks that do similar things, do those things the same way. In other words, my tasks that looped instead of breaking now break.

Why such a thing is effecting how often tasks execute is over my head.

I guess this behavior would be hard to understand without seeing the source itself in action (but I’ve made the changes, so the issues caused can’t be seen now anyway).

Trust me…you don’t want to see any extreme source content that comes from me. It’s getting to the point I’m even getting confused. Lol.

Not really confused, I only slip up when I expect things to go my way and then the engine shows me that it’s going to do it P3D’s way, then I have to adjust.

So things are more difficult than I thought with P3D, but so far I have slayed every beast that has surfaced.

I’m completely tired from the last three days of writing code that takes the place of IK effects. The code it self is light weight, but powerfully written.

4

What exactly do you mean by “how often it executes”? Maybe we should get this sorted before anything else, because it’s not obvious what the problem actually is.

David has told you, it’s once a frame. He knows what he’s talking about.

You write a method, Panda executes it once in every main loop pass. There’s really no magic there, no threads and, contrary to what your statements are, it’s about as standard as you can get with it.