Tag: c++

Add new jobs using the job context list (WiP)

Adds the bulk of the logic for starting to enqueuing new jobs through the context lists.

Improve behaviour of the job context list

Even though it definitely does not say so, this means that the job context list can now be hidden again without having to actually push one of the buttons.
This is also the beginning of adding new jobs when clicking one of the buttons, this is very much work in progress however.

Restructure the job context list and make it more dynamic

This is mostly simplifying some code and making the list draw in a more presentable way:

Now the price is also added to give the user some feedback as to why some options might be disabled.

Show available jobs when selecting a context object after selecting a primary object. Introduce the JobContextList to the Interface Manager

This is a big one. This extends the interface manager to show a list of possible jobs that fulfil the following criteria:

• the object being clicked on (“context object”) exposes a list of actions
• the currently selected (“primary”) object supports the action required by a job
• if the job requires funds, make sure the user’s funds are sufficient

This also meant extending the whole click handling logic for objects had to be re-done and the concept of the “context object” selection had to be introduced.
On top of that the JobContextList widget was added, it still looks a little wonky and does not do much except being shown, but here it is:

– add new “parameter” property on job types
– add new “supported actions” property to object types
pass both on to the appropriate python functions and change their signature accordingly

This is properly implementing the aforementioned concept of “supported actions” instead of just hard-coding it. It also adds parameters to the job definitions in order to minimise code duplication. To give a practical example here, look at the definition of the “eat” job in order to see the difference:

Make the job definition more generic and move actual job handlers to separate files

So far all (not like all that much exists yet) the job logic and general object logic were stored in the same file, the implementations for specific tasks no move to separate files. This is realised by iterating over the specified supported actions when instantiating an object (in Python) and dynamically adding the respective functions to the class:

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:

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.