Improving the EveHQ updating system | An EveHQ dev chronicle

About the EveHQ updates workflow :

As you may know, we took a bit longer to release the 2.21 update. This was the first time new modules where added to the game since we took over the project. There was also few changes in the SDE database. At this occasion we discovered that the modules effects are all build manually and store into CSV files in the EveHQ project.

Actually, when a new module or ship come out, we have to upgrade the effects manually with a delicate procedure : we need to gather related informations from the Eve Online’s patch notes and from the SDE, then build new rows in the CSV file that contains effects data for EveHQ to work with and create EveHQ data files with the “Cache Creator” that is compiling informations from the CSV and from the SDE.

This procedure make updating EveHQ complex and increases the risk of human errors.


What we want to do :

We are now working on the possibility to extract more information from the SDE database, and pull effects information from CCP Export for lighten the current process by automating this task.

To do it, we need to understand how CCP store and use effect data stored in the SDE and feed directly the data files that are used by EveHQ and create by the cache creator. With this simple thing, we will be able to remove the CSV files and make the updates more simple, and quicker to make the updates available to our users.


Anyone that know the SDE well and want to help us achieving this goal is welcome.


Bookmark the permalink.


  1. pyfa has the same upgrade troubles. We need to have a file for every effect in the game, and this file is a pythonic representation of the effect and how the current items affects other items on the fit.

    Here’s an example of one of our ship bonus effects that increases shield resists for the transport ships using the effect.

    It’s a very manual process. From what I hear, pyfa went this route because at the time dgmexpressions was not part of the SDE.

    Kadesh has created a new engine that we hope to rewrite pyfa around. It uses the dgmexpressions table directly, and builds itself a cache of information that links all the effects together. No more manual effect writing. I don’t exactly know how it works, but you can try to get in touch with Kadesh ( for more information on how this stuff interacts, and maybe even look at the new engine to see how it compiles this information (

    • Hi Blitzmann ! It look exactly like what we want to do now 😀
      Thanks for you interest and those information, we will try to get in touch with him.

      • I actually started looking into dgmExpressions today, and I think I can even help in a limited capacity (maybe not with the code, but with theory). It doesn’t really seem as difficult once you get the general sense of how it works. I’m making my own notes to hopefully write a dev wiki on it.

        You basically keep looping through the expression tree, and you will eventually get to where you have all the needed data. There are a few gotcha’s, though, but operandIDs help to determine what to do with the current expression.

        I would reference the operand IDs in EOS, which have small commends on what they do or how they are used:

Leave a Reply to Blitzmann Cancel reply

Your email address will not be published. Required fields are marked *