Commit 4f3466cf

Add job queues (per object) and wire everything up so that objects work through a work queue

This brings a lot of pieces together, finally not only are single jobs executed, but an arbitrary number of jobs can be queued up and executed in order, the interface in the ObjectManager looks like this for the time being:

What is still missing here is cancelling jobs, but one step at a time. 🙂
If you look carefully at the console output you can see the job queue in action:

Commit f8ef72ef

Add job wrapper class

This adds what is in essence just a container for job that is currently being executed, it is made up of

  • the JobType, that describes the full nature of the job
  • the JobContext, that stores information about the “where” and “what” to interact with
  • the JobStep, that stores information about the state of the current step being executed

This was added in preparation for the job queues which will be implemented next. As always the python mappings (and scripts) had to be adapted to support this change.

Commit 03c50e68

Move the (controllable) object by running the “walk” job instead of manually setting a target

Building on the previous commits, this finally means that an objects executes a job. This means that a the mappings were extended considerable and a fair amount of helper and convenience logic was written on the C++ side as well. The resulting piece of Python is pretty straightforward:

Commit 7cb508d8

– Flesh out job concepts
– Extend job step class
– Introduce job context class

Next to adding a whole lot of getters and setters, this commit also adds some class members to the Object and JobStep classes that keep track of the current job progress.
It further adds the concept of a job context, meaning that a job that is being executed needs to keep track of a different object it needs to interact with in order to complete a job or a coordinate it needs to move to in order to do so.
As always that also means the Python mappings get extended:

Commit 6c3f89da

Extend the object configuration by adding job and job step information to it (2)

Once again some files forgotten in the first commit. On a more positive note, this also gives a good example of where the idea behind the job system is going by also adding a fridge object (which is currently sporting the old chair model since there is no fridge model yet):

The new fridge object is advertising some three different jobs that can be executed by objects that support these actions. Each step may have a price that only gets subtracted one we actually reach that specific step, but the same information needs to be available as well for the job itself, as otherwise we would not know what to offer to the user in the first place (as the funds might be insufficient). All these new definitions will see some use soon. 🙂

Commit 48cc0914

Extend the object configuration by adding job and job step information to it

This is the first in a line of commits to introduce a job system to OLives.
The goal is to enable (Controllable)Objects to work through a list of tasks as requested by the user. This requires the introduction of quit a few new concepts, but this commit is just about adding configuration data for the jobs that can be broken down the jobs themselves, which have a name, and individual steps that a that need to be executed in order to consider the job to be complete.
The configuration of the human object has been extended to define the most basic of jobs: walk

As mentioned before, right now this has no effect whatsoever, it is just about defining and validating the new information.

Commit 0f07bc50

Extend the python mapping and port the quote hunger unquote behaviour to python

Much like in a previous commit more of the existing behaviour is ported to Python, this time that means the logic that lets the “hunger” (read: the object’s satiety level) drop passively and more quickly when the object is moving. If it hits zero it will start removing hit points from the object. Check out the clumsily written Python script doing that:

In order to make this possible the mappings had to be considerably extended.

Commit 1a5999ce

Make the python script object based instead of calling plain functions in it

As could be seen in a previous commit, so far the python modules for objects were simple modules without any class information, as calling into Python from C++ is resolved at run-time anyway. In order to clean things up a bit and enforce a bit of structure, that has been changed now: