That's a good question (about how difficult it would be to add as a filter to Deflate 3).
It will not be a simple addition, probably 2-3 days of building, debugging, and adjusting. It could be a little more, I'm not sure.
There is a key design decision I need to make when putting it together, and it centers around performance. When I build something for LP, I need to keep in mind that maybe a couple dozen different people will be using the program simultaneously, so I need to design things to be as efficient as possible.
With the current vTracs programs that displays the lottery results alongside the vTracs numbers, the program reads all the results from the database that are necessary to generate the display, translates all of the numbers into their matching vTracs, and then formats the data and outputs it to the page.
In that process, the most processor-intensive (computational) task is to do the translations from regular results to vTracs. The program does roughly 75-100 translations every time someone views the page, which may sound like a lot, especially when a few dozen people look at the page at the same time, but I built a very powerful web server, so it happens pretty quickly. (I just tested and it came out in 0.0458 seconds.)
However, if I applied that same strategy to something that searched for vTracs, it would be a completely different story. Every time someone did a search, it would have to do literally thousands of translations, as it goes through every drawing of every game, translates the number to a vTrac, and then compares it against the various possible matching scenarios. Then when you take into account a few dozen people doing it at the same time, we're talking major meltdown. And these days people start tapping their feet when a page takes more than a second.
So what to do?
Well, I have a few ideas, but I haven't decided for sure on one of them. I think one thing is clear, that I can't do all those translations "on the fly", I need to pre-calculate a lot of that stuff. But then comes the issue of do I really want to dedicate the storage space necessary to pre-calculate vTracs for every Pick 3 and Pick 4 lottery game, for drawing that has ever took place? And then how does that date get maintained in real-time, so when new drawings happen the vTracs get updated?
I'm just asking those questions rhetorically, but I wanted to give you a sense of what goes into these things, and why sometimes it takes a good amount of time to plan and execute these things.
Every new feature goes through countless design decisions like this, whether it's a user interface issue, a menu option, a number-crunching program, a database, or anything in between. If I had made a bunch of bad design decisions along the way in the past several years, I would be spending twice as long fixing things today as I do building new things. Fortunately that's not the case.
