Those notes

[Joseph Carter]

A long time ago now, I got out of the hospital.  I promised I would get my
notes to this list immediately.  I tried, for days I tried.  SF wouldn't
let me mail them.

Well, here they are, at long last...

twinotes-locmodel - Notes on a generic model to use for .loc editing, and
wherever else it's needed.  Also mentions small binary gamedata in the
engine itself, though doesn't really discuss how we should do that (since
I don't know yet..)

twinotes-menu - The Quake menus suck, mmkay?  These notes talk about the
first of a three-stage plan I have in mind to make the menus clean and
even replacable by whatever UI a mod may wish.  Stages two and three only
exist in my mind for now, but if someone wants to work on this, they're
welcome to - there's no black magic in the code, and in fact almost any
one passingly familiar with C can implement these changes with a little
patience.  Low priority, but it would be really nice to have.

twinotes-slist - A simple/stupid internal server list.  In Linux we have
XQF and qstat, but in Win32 the options are pretty limited.  You all know
that I basically hate Gamespy and everything about them, have for years
now.  While this server list code won't replace Gamespy (current versions
of which don't even support QW, I'll note), it will give us a powerful
tool on which to build something that can.

twinotes-sbar - Related to the menu rewrites, but only indirectly.  The
goal is the same as with the menus, user-definable HUDs for the various
mods they play.  The code in sbar.c needs a lot less cleaning up than in
menu.c so these note approximate stage two of the menu rewrite.  It works
the same way vertex arrays do, only higher level.  Rather than doing a
bunch of conditionals to tell you want to draw, you build lists of what to
draw and pass them off wholesale to a function which is smart enough to
figure out if/how to draw what you gave it.  As you can imagine, the only
thing missing then is a way for an end-user or a mod developer to supply
the list for their mods..  I'm thinking XML for that, but I haven't
written notes on an XML parser yet either, so let's not get ahead of
ourselves too much..


Comments from coders, mod makers, and players are welcome.  Half the
project's coders have already seen these, but I ask everyone to look them
over again anyway, just in case.  If you like the ideas in here, speak up!
If you think I've lost my mind, you'd not be the first person to point it
out...  Feedback please!  =)

-- 
Joseph Carter <knghtbrd at bluecherry.net>         Do not write in this space
 
<ultima> netgod: My calculator has more registers than the x86, and
         -thats- sad

-------------- next part --------------
We should have a temporary location model which is hardcoded for now.
Best thing would be a diamond gem (6 verts, 8 tris - cheap enough!)
Maybe give it a glowy green look, maybe a little bluish hint.
Need to decide on the filename for this.  For now the model will probably
  be primarily a C header, but it shouldn't be named that way since it'll
  get replaced at some point with our own model format.  Possibly a subset
  of what we'll use in Neither or a variant of zym models or something.
The sane model with a different set of colors can be used as the null
  model - NQ can't download so it needs to do something when a model is
  missing.  This is something, and it's even something reasonable.
Even after the model is converted to our own format, we'll want to
  continue compiling it in to the engine.  The mechanism for doing this
  hasn't yet been designed.

-------------- next part --------------
DrawSlider takes x,y, but draws at x - 8.  This is a bug.
The size of a slider is fixed at 10 (SLIDER_RANGE), change this.
There is no reason whatsoever DrawSlider cannot do its own math.  It means
  giving it more values, but it'll mean the math is generic and cannot be
  easily broken.
DrawTextBox can be cut down to about 1/4 the code.  And it should be.
Magic should be done to lose the MAX_*_ITEMS constants.
Nearly all of the menu items support the exact same keyset:
  - Enter is used to select an item
  - Left/Right are used to change an item, if it can be
  - Up/Down are used for previous/next item
  - Escape goes back to the previous menu, if there was one.
The exceptions:
  - Backspace is used as expected for editable menu entries, but the key
    bindings code use it to clear an action's bindings.
  - y and n are used by the quit dialog, which is technically a menu (who
    knows why it was implemented this way...)
  - space is used to abort the NQ LAN server scanning
Knowing this, you can define key events for all menu entries:
  - navigation
  - alteration (left and right only)
  - selection
  - anything else (usually not used)
The options menu begins on column 16.  There are 22 characters before the
  center gap between menu captions and values.  The gap is 28 pixels wide
  (3.5 chars), recommend we increase that to 32 pixels and put the cursor
  arrow on the 3rd character.
If you can't tell, the intent of all of this is to make the menu generic
  enough that the individual menu functions can eventually be reduced to a
  bunch of EmitMenuItem type calls.  That's all part of the great menu
  overhaul  mk. II, which has yet to be written.

-------------- next part --------------
The first implementation of the slist will be a console-only thing,
  primarily working on a single active serverlist in memory.  I anticipate
  more complex things later involving multiple lists and saving to disk
  and GUIs and all of that, but we're not there yet.
The serverlist code should be written common, even if that means using
  stub functions for network calls and other hacks.
The first thing on the serverlist line should probably be a two-char
  protocol ID for the server in question.  This will be NQ or QW or
  possibly TW at some point.
Once we have enough of a GUI to make it practical, filters should be
  loadable and editable.  Perhaps loading can be done before then and
  editing can be the process of saving each command in a queue.  When you
  clear the list, you would also clear this queue, to avoid writing too
  much when you're trying to write a new filter.
Even after we have the GUI, just about everything that can be done with
  the serverlist should be available as a console command.  These commands
  just do things to the list in memory, so if you want a list sorted first
  by number of players and then by ping, you would sort by lowest ping and
  then by highest players.
Until and unless we have a single binary for NQ and QW, each client will
  simply only support one protocol, its native one.
Here's the list of commands I've thought about which would be useful:
  - clear
  - add <ip> [port] [protocol]
    Adds one server to the list.  If the port is omitted, standard port
    for the protocol will be assumed.  If protocol is omitted, all
    supported protocols will be scanned for.  Should ping the server and
    add it to the list if found.  Otherwise should tell the user that the
    server is down.
  - scan <network>[/range] [protocol]
    This is what NQ currently does to look for LAN games, given a little
    more power.  Put in the base IP of your LAN, be it 192.168.1.0 or
    whatever.  Ranges are in the /n format, with /24, /16, and sometimes
    /8 being good values.  If one is not provided, we'll assume /24 (which
    will scan 256 addresses) rather than try to guess based on the IP's
    class - which practically has no meaning anymore.  Note, it's possible
    to specify /32 and scan the entire internet.  Be prepared to face the
    consiquences if you do that, since it's likely to take awhile and make
    people mad.
  - master <ip> [port]
    QW/TW only, there are no NQ master servers.  And if there are ever
    Twilight-specific master servers, we'll scan the port we put them on
    after we scan the normal port.  Obivously, if you supply a port, it'll
    be used.
  - filter <field> <operation> <value>
    I haven't bothered to name off all of the fields, but I guess
    generally we will support all of the ones that qstat returns..
    Several of these fields don't matter to NQ, but we'll just treat them
    as 0 in that case and possibly disable them in the NQ cmd list or
    something.  I don't want to commit to disabling them though because of
    the common code for the serverlist from the very outset.  The
    operations are things like "under", "over", etc...  We don't want this
    to get too complex and it need not support all of the comparison
    operators C does really.  Value is obvious.
  - sort <field> <direction>
    Applies a sort up or down based on a field.  Numeric fields get a
    numeric sort.  String fields get ASCII.  Note, the way the filters are
    added together, you will want to sort what will be the secondary sort
    method first, and the primary method last.
  - list [limit]
    Prints out the result of applying all of the above.  If you supply a
    limit (1 based), no more than that number of results will be reserved.
Note that this isn't QUITE as complete as gamespy tab files, but a filter
  could make it close enough for most things.  Improved versions of this
  code will allow you to load a filter set and save all commands since the
  last clear.  A GUI is very desirable, and Forest says that if I don't
  add support for complex expressions in the filter command, he will.  I
  say he's welcome to do it.  =)

-------------- next part --------------
The attempt here is to basically implement the same principle here as I
  have planned for the great menu overhaul mk II.  It should prove much
  easier to implement here than in the menu code, so it probably should be
  done here as a prototype.
Restating it, the intent is to reduce the HUD/Sbar drawing code to a
  series of single function calls which simply emit the various things
  according to specified parameters.  Put this thing here.  Put that thing
  there.  Do that a few more times and return.  This should greatly
  simplify the logic of the code, getting to the point that we could
  eventually load these things from a file using a simple parser.  This is
  highly desirable.
Most likely the various emitted elements would be stored into a queue of
  things to draw.  Once the whole thing is emitted, the queue can be
  flushed.  This mechanism may not work for the menus, but there are only
  so many things you can reasonably expect to put on the screen for the
  player to look at.  64 elements sounds reasonable and will more than
  cover the standard HUD/Sbar for Quake, QW, and the mission packs.  It
  might not be enough for bloodbath unless they use a single background
  like Quake1 did.


I seem to remember mqwcl had some enhancements in this area.  I figured it
would be worth checking out their docs to see if there were any console
commands we would want to implement in the same manner for compatibility
reasons.  Not only do they hoarde the source code to their engine (they
say they will release it, someday - this is a blatant GPL violation, but
frankly I haven't had the energy to fight them on it yet), their website
sucks even worse than ours does.  This is amazing given that they have
content we don't like screenshots.  Yes, it really is an impressively
crappy website!  I could take lessons from them if I wanted the Twilight
website to be even worse than it is right now.  ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <http://icculus.org/pipermail/twilight-devel/attachments/20020628/7a71e0a5/attachment.pgp>