Tutorial: Gamethread discussed

Requires: ES 2.x
Difficulty: Medium
Author: Errant
Contributors: ~
Length: 5 mins

Tutorial Overview

Table of Contents

Description

A look at the new Gamethread module and why it is important

Tutorial Content

Gamethread is a new ESP module provided with the core ES download (in version 2.0 onwards). It provides a simple interface for scripts to interact with the SRCDS game thread. This 'tutorial' is a quick discussion of why it is needed.

What are threads / threading?

I suppose this is a concept that has to be addressed first - as the majority of people will not have come across threads before. When you run a program or script (we are talking generally here NOT ES specific) the instance of that program on the computer is called a process, it is very like instancing a class. Like class instances a process creates an independent set of variables, methods and so forth to be run on the machine. As with classes, processes do not share resources with each other.

Within a program it is possible to fork - split the program so that it runs 2 separate things (either simultaneously or in series). It is possible to fork by creating a new process, however this also has drawbacks:

• It is hard to talk between the 2 processes as each one is very independent.
• It becomes harder to keep track of what is running and where it is running, leading to programming nightmares.

Creating a new process by forking creates a new totally separate instance of the program or script.

Threads are a much cleaner solution to the problem of forking. Threads basically allow multiple sections of a program to run at the same time - essentially emulating 2 separate processes. Uniquely, however, they run under the same 'process', and share scope and variables; so are able to easily communicate.

Each operating system deals with threads and processes differently, but the broad concept is the same:

• Process are separate and independent instances of a program
• Threads are multiple sections of a program / script running under the same process

To complicate matters further the word threading is also often used to refer to both processes and threads - in the case of SRCDS and ES2 the threads and processes are so intermingled it is best just to lump them all together. From now on when I use the word threads it basically means either a thread or process.

I recommend before continuing you read this Wikipedia article on threads as it will clarify matters better than I can.

So why are they important in ESP?

Phew all that was potentially quite complicated (and you didn't really need to know it all, I just included it for completeness - there is a much fuller discussion of threading and how to do it in Python, Threads and ES2), the main thing you should have drawn was that threads (or processes) can run simultaneously. Meaning you really can do 2 (or more!) things at once. Now here's the bad news - neither the Source Dedicated server OR Python are totally thread safe (by design).

When threads and processes talk to each other they have a large capacity for messing each other up. This is very true of the SRCDS engine. Because your ES Python script is running independently (in a separate thread / process) to SRCDS there is much potential for them to become out of sync - so that when you talk back to the SRCDS you could cause untold confusion and much merry hell. A normal Python script is fine running SRCDS reliant methods (eg es. commands), the problems come when you wish to delay a command or even run multiple threads in your script. There are 2 solutions to this problem - both of them covered by the new Gamethread module.

Delaying commands

Delaying a command is obviously going to cause sychronisation issues if you use the usual Python sleep() method. Gamethread provides a safe way to delay commands without disrupting SRCDS.

gamethread.delayed() provides a method to delay an ES command for a set number of seconds. Several other methods (check out the gamethread page for reference to them) allow you to manage the delays you create.

Example: Delays myfunc by 0.1 seconds then safely executes it.

def myfunc(arg1, arg2):
     print 'Arg1 = %s, Arg2 = %s' % (arg1, arg2)
 
gamethread.delayed(0.1, myfunc, ('Hello', 'Test'))

Output:

Arg1 = Hello, Arg2 = Test

Queuing commands

Much more interesting is the concept of queuing. The only use for this is if you are creating separate threads within your script. In this case your synchronisation with the game engine goes totally out of the window and you must use this safe method to run any ES commands into SRCDS.

Put simply gamethread.queue() allows you to add a command to the thread queue to be executed during the next game frame (or tick) - essentially when it is safe to do so. In real world terms this should be fairly instant (as soon as you add it to the queue) but could theoretically be longer. If you require input back from SRCDS you need to work some even more complex trickery (basically by creating a reverse queue back into your threads), again this is discussed in the threading tutorial.

Queue's are another (incredibly simple) programming idea. When you add a command to the queue it is tagged on to the end. When something (in this case the gamethread module) is ready to run the queue it iterates through the list of commands in the queue and executes them one after the other, removing them from the queue as it does so. Queuing just ensures there is no direct contact between the thread wanting to run the command and the process or thread actually running it.

Conclusion

Gamethread fixes all our horrible sync issues in ESP / ES2. Hopefully this short discussion has made it clearer why gamethread is important and how it basically works. A full understanding of these matters is probably beyond the scope of most ESP scripters however the basic concepts here should help you understand more of how Python, ESP2 and SRCDS work together.

Thanks for reading