In Splitsing drie links niet snijden 500! I wrote about how I ended up making a Dutch co-driver voice for EA WRC. Whilst I was doing that, I ended up rummaging through the game files. It’s always interesting to see how the game works internally. Whilst I was going through all the assets, I was wondering if I could do something with it — I ended up printing the pacenotes for all 252 stages in EA WRC.

Let’s back up slightly to 2022. At that time I was playing a game called Dakar 18, which aimed to simulate (or approach, at least, it was not a full on simulator) the famous Dakar race from 2018. Dakar works slightly differently than WRC - the roadbook gives directions of where to go, rather than highlighting every corner. It’s more the directions of a scavenger hunt, telling you to follow a compass heading for the next 5 kilometres. The game had quite a few stages, and looking at the game files, I found that the roadbook notes were actually stored in an easily machine-readable format. Given the central role of the roadbook (and admittedly also the annoyance of the codriver voice, who was overenthusiastic and not focussing on giving me the right information in time and then berating me for going the wrong way), I decided to make a physical version. This was very well received by the developers as well.

Later that year the next version of the game came out. The stages were different, and the roadbook format had changed (it now had colour!). The amount of stages and the number of pages also would no longer fit in a single book, so I ended up printing it as a separate booklet for every stage. I had them printed as “print samples” to save on money, and frankly I don’t mind the watermark. Again this was well-received by the developers and the community.

That was 2022. Forward again to 2025. I was reminded of the Dakar booklets when I was browsing through the assets for EA WRC. I decided that it might be nice to have pacenotes for EA WRC printed on paper as well. I looked through the assets with FModel, a community tool to browse through Unreal Engine assets, to see if I could find some definition for the stages. It also has a JSON export function that came in really handy. After some searching I found the asset, which I thought was just one stage, but actually contained every stage from that location. Searching through that file was sometimes a bit tedious, as it is ~500 MB of JSON file. However, with some searching I found an array with co-driver calls.

Now these were the co-driver calls, but where were the actual calls that the co-driver says in-game? Initially I found a property called m_scriptLineModeComplex which seemed to contain what I was looking for. I printed an entire stage that way, and tried to match it up with an existing stage based on a video I found on the internet. The calls were very close, but not quite what I was looking for. This caught me slightly off-guard at first, although I now believe these were notes made by the developers what the calls should be, and later they were changed slightly.

I also noticed that often there would be large gaps where there was no data. Upon some inspection, I found out that there is a parentId property, that, when not 0, means that the calls should be used from the parent call instead. I believe this is because when EA advertises with, e.g., 12 stages in Chile, what is actually happening is that they have one long stage in Chile, that same stage in reverse, and then 10 subsections of that one stage as their own separate stages. This is also very apparent from the stage maps visible in-game.

Now, I had data, but I still did not know where the actual calls were. It took some time before I realised the property m_segmentIdList, which just contains a list of integers, actually refers to the IDs of the different calls. Once I exported the master call list and matched up the IDs in that list with the textual representation of that call, it suddenly fit like a glove. Eureka! All of this was written using many loops and parsing in Python — by hand this would have taken ages.

I decided to log all the stages in that file, and, for for example Chile, I nicely got an output with all 14 stages. Hold on, 14? According to the game there were only 12… Hmm… It seems that there are stage variations made for the game that are not in the final game, and the annoying thing is that it does not tell me which stage is which — to debug my system I looked up a stage video on YouTube, and tried to match the calls to one of the 14 stages in order to find out which one it was. Given that, at the time of making, there were 252 stages in EA WRC, that was not a sustainable method. Also, there were clearly some imposter stages in there as well that made things even more difficult. It just told me that it was stage 0, 1, 2, 3, …, 11, 12, 13. After digging through some more files, I found that the translation files actually used those numbers as a key as well. This allowed me to also filter out which ones were not being used, and I could thus discard.

As a quick intermezzo: every call also contains four booleans: m_usedInWinter, m_usedInSpring, m_usedInSummer, m_usedInAutumn. I knew Monaco was slightly different in Winter due to the ice on the road, but I was curious to see if there were any other differences based on the season. I can conclude that no, there are not. This is only used for Monaco in winter.

A question I still had not solved was how I was going to present the pacenotes. Dakar is nice in the sense that the roadbook format is standardised, and bar some minor details most of it is the same. WRC on the other hand is not — if you ask 10 different co-drivers their pacenote system, you get 11 different answers. I needed something that I could make work with the data I had (I was not going to edit it all by hand, that was infeasible).

Most co-drivers have a notebook that they scribble on by hand. I initially wanted to see whether I could get that aesthetic, but I quickly realised that the data I had was not suitable for that. The call data I had was too detailed for that, plus the spacing etc. would be difficult to get right, as the handwritten version is all based on feel and flow, and computers don’t really understand that concept. Pictures and general data on how people do it in real life is also just really quite scarce. Often I found myself staring at pixels to find out how a team did it. In my search I did however find a computer-generated format I quite liked, the Jemba Inertia Notes System (example). The nice thing is that it worked line by line.

I still had to come up with shorthands for the actual calls though. The master call list contains the text as spoken, which is far too verbose to print. I looked for examples, but again there were only small bits and pieces I could find online. There is no uniform rally terminology, and whilst at first that was annoying, the positive side of that is that doing it wrong is quite difficult. It took a lot of tinkering, but in the end I managed to get something I was happy with.

Another feature that the Jemba system has that I thought was quite neat was the distance since the start a certain call appears. Looking at the data I had of EA WRC, I did not have that directly. I did however have a percentage of progress for each call, but the file did not contain the actual total distance per stage. Luckily that was not too big of an issue, as the EA WRC website and the game itself do somehow list that (not sure where they store that information). I manually made that list, let it do the calculations, and voila: a distance indicator as well.

At this point I had the data I wanted, but not yet the representation of how it would be printed. With the Dakar booklets I generated long HTML tables, that I then used wkhtmltopdf on to turn into a PDF. That system, whilst sometimes frustrating, worked well for Dakar, so I decided to also use it for EA WRC. Admittedly it’s quite simple - just a table, a table header, and some rows with data.

Compiling this into one PDF resulted in a total of 2908 A4 pages. That was not printable. Again, given the good experiences I had with the previous booklets, I decided to just do it per stage again. Sure, 252 is a bit more than 36, but surely that would not be too big of an issue, right? (Some foreshadowing: it was a bit more of a kerfuffle than expected)

But first: one of the things I did wrong with the Dakar booklets was that even though I designed fancy fronts, I did not design a rear or anything else. Some booklets just had empty white pages at the end. I wanted to avoid that this time. Given that the page number is always a multiple of four, I had to figure out what to do with the one, two, or three empty pages at the end. Someone helpfully suggested making them pages for notes, which I quite liked.

For Dakar, I designed the 36 fronts by hand (albeit systematically). For 252, I thought some more automation was a good idea. I really struggled getting the CSS just right to make the background and text work properly, and every compilation was not exactly quick, but in the end it worked out. For some reason making the background cover but not overflow in wkhtmltopdf was rather tricky. In the game’s assets I found the image the game uses for every location, and I figured I might as well reuse that on the front. Along with the logo for the location, a map of the stage, and of course the name, every booklet felt unique, but I could still generate them easily. All of this was slightly more work than initially expected, but that always seems to be the case.

I printed the Dakar booklets at a printer in Germany that sends out samples for free. I contacted them and asked them whether there was any limit to that, and their customer service kindly replied “No”. That was a clear answer. Now adding all the booklets by hand, uploading the PDF, etc. is tedious, so I did the sensible thing and scripted that. That script took quite some time to run, until the website became so slow it could not handle it anymore… whoops. I had to order them in four separate batches.

This German printer is relatively cheap, and one of the reasons for that is that most of it is on-demand printing that is highly automated. Orders are not necessarily grouped, and no human really looks at it. For that reason they charge shipping per individual item, which in my case was 252 × €7.95. Shipping within Germany is free however, and 252 × €0 is still €0. So I asked a friend if they could receive a package for me.

A couple of days later I receive an email that my order has been shipped… and about a hundred other emails that the order has been shipped. Scrolling through them, I quickly notice that a lot of them have a DPD tracking code, and all of them seem different from each other (but not all, there were some DHL ones in there as well). Oh dear, I had a small suspicion, but was still hoping that it would be batched. I was wrong. Apparently DPD arrived on their doorstep with 100+ individually packaged packages. Luckily they took it in good humour :-) A couple weeks later I came around to visit them (and take home my stack of cardboard). This is what my car looked like: the boot and back seat were filled with boxes.

I had the luck that a couple of days after I arrived home, the paper collection was due. So I spent a total of 1½ hours on the parking lot, boot lid open, ripping open packages (and sometimes putting plasters on my fingers — cardboard can cut). I ended up with a stack of cardboard that the recycling people picked up the next day.

Most of that was packaging (and rather inefficient packaging at that). When laying it all out on the floor, this is what it actually looks like. Size-wise it is about three magazine racks on my shelf, so about ~21 cm wide. I also posted this on Reddit, and the responses, also from the developers, were very positive. That was really great to hear. It is always a bit nerve-wrecking to upload this. In the meantime I had also uploaded all the PDFs to my website, and based on some of the Reddit comments people were actually using them. That was amazing! Quotes like “We've just had the most fun we've ever had simracing together” really make my day (and are quite a contrast to the comments I received for doing other things). Sadly I have not yet seen any footage of it being used. Maybe some day (and if you have found some footage, please send it).

I have shown this to friends and family as well, and a question that keeps popping up is “are you going to actually use this?”. Now the fun part is that I can use it if I wanted to, even though I don’t really plan on it. The fun is in making it, but the chance that I’m actually going to use it for a practical purpose is unlikely. The combination of working with a lot of data, typesetting, generating, automating, and graphics design is just a particular combination that scratches a certain itch. I had the same when making a certain phone book.

So that is how I ended up with a lot of paper booklets, a fun project, and a lovely story to tell later. I hope you enjoy this (very abridged) story as well. If you are interested, all the files are on the website, and if you end up using it, send me a message — I like hearing those stories.