Re: [Xqf-developer] 1.0

[Ludwig N. <lud...@gm...>]

Ben Winslow wrote:
> On Tue, 2003-10-28 at 18:07, Ludwig Nussel wrote:
> > > Maybe make filters more usable? (in a tree-like scheme under each game?) 
> > > for 1.0 ?
> > 
> > Well, that would certainly be nice but it's also a lot of work.
> 
> IMHO, XQF's lack of flexible server filtering is its current biggest
> problem.  Just being able to simply add keys/values with a boolean
> operator, similar to the way the country filtering is done now (e.g.
> g_antilag must be 1, g_friendlyfire must NOT be 1) would be a tremendous
> usability improvement.  I'd try to code such a beast myself, except that
> my experience with GTK is minimal at best.

Well, if I would implement that people would quickly demand even
more sophisticated filters. I know filters are far from perfect.
Personally I have 38 filters defined. So some structuring mechanism
would really be useful :-). I once experimented with scheme (guile)
as server filter language. You can filter by almost everything with
arbitrary complex terms then. You can still find this experiment in
the branch 'branch_scheme_filter'. As you mentioned yourself, an
advanced filter system needs a new GUI. As everyone wants GTK2 it
wouldn't make much sense to do this with GTK1 now.

> On a slightly related note, I do have a couple of other minor patches:
> xqf-gametypes.diff: Adds support for the most common RtCW and ET fs_game
> values, so that their gametypes are properly displayed.

Ok, thanks.

> xqf-privateclients.diff: When a server has private clients, the number
> of players is displayed as numplayers/publicslots(+privateslots).  I
> personally think this is much easier to read, especially since private
> slots are more often empty than full.

Hmm, I'm not sure what the best way is. Any other opinions on that?
16/14(+3) or 16/17(-3)?

> I tried to preserve indentation style local to each file, but the code
> indentation isn't very consistent throughout xqf.  :/  The patches are
> small enough that correcting them to whatever is preferred should be
> trivial, though.

It's usually two or four spaces per level, choose whatever fits the
surrounding code best ;-) Please note that indentation level is not
the same as the number spaces per tabstop (in vim that means don't
modify tabstop, use :set shiftwidth=2 instead. Don't use <TAB> but
C-t/C-d).

cu
Ludwig

-- 
(o_  Lud...@gm...
//\  PGP Key ID: FF8135CE
V_/_ ICQ:        52166811