Filter ideas

[Mydor]

After looking at the filters by BlueAdept I thought there had to be a better way to manage "global" filters instead of including them in each and every zone filter file.

My first thought is to have SEQ load the filters.conf file after it loads a more specific zone filter file. I've managed a cludge in the filter.cpp that works, but I'm not happy with it. Ideally I think it should go in the filtermgr.cpp, but I am not fluent enough in c++ to follow how the two interact yet. The additional problem came from the fact that loadFilters flushes the stored filters before opening the file, so I limited loadFilters to that task as well as figuring out what the global filename should be and passing the actual reading and parsing of the filter file to a new method.

My second thought, that I haven't worked on yet but would be more suited for a location in filter.cpp, is to have some type of include directive in the filter file. I think I like this idea better as it allows for more flexibility. However, since # is used for comments I'm not sure the best way to denote the directive would be. One thought, which I think is a little ugly would be [include /pathto/somefilter.conf]. Similar to the first idea, would have to split out the actual reading/parsing of the filter file to a new method so the includes don't get wiped out by the clear, but overall I think a better solution to the whole problem.

I would like some input on the two ideas and I will work on putting it together and getting a patch for it. Of particular interest to me would be comments on the second solution and how to denote the include directive since that is the course I would rather take. The only other thing that would be missing is to know LOGDIR inside of filter.cpp. How much havoc would it cause to #include "main.h" in filter.cpp?

[karrde]

My second thought, that I haven't worked on yet but would be more suited for a location in filter.cpp, is to have some type of include directive in the filter file. I think I like this idea better as it allows for more flexibility. However, since # is used for comments I'm not sure the best way to denote the directive would be. One thought, which I think is a little ugly would be [include /pathto/somefilter.conf]. Similar to the first idea, would have to split out the actual reading/parsing of the filter file to a new method so the includes don't get wiped out by the clear, but overall I think a better solution to the whole problem.

I would like some input on the two ideas and I will work on putting it together and getting a patch for it. Of particular interest to me would be comments on the second solution and how to denote the include directive since that is the course I would rather take. The only other thing that would be missing is to know LOGDIR inside of filter.cpp. How much havoc would it cause to #include "main.h" in filter.cpp?

Has any progress been made on this or has it been give up as a lost cause with no support? I've been ponering this same thing since I started using seq not long ago. I'd like to be able to speciy a "generic" filter for all dungeons that I could include in all the zone specifc filter files for the dungeons w/ putting it in the main filter file for all zones.

[Zaphod]

Originally posted by karrde
Has any progress been made on this or has it been give up as a lost cause with no support? I've been ponering this same thing since I started using seq not long ago. I'd like to be able to speciy a "generic" filter for all dungeons that I could include in all the zone specifc filter files for the dungeons w/ putting it in the main filter file for all zones.

While recently performing some hard disk archeology I discovered I had coded this (and a few other neat features) up back in the 4.2.13 timeframe around July 2002, but that code base had never made it to CVS commit. I'm going to see if I can dust this code off (ie. make it work in the current codebase) and get it into my next CVS commit.

Enjoy,
Zaphod (dohpaZ)