Kevin R. Bulgrien wrote:
This brings the usual question :-) any objections if we nuke x11 and gtk
from the tree for trunk (and 1.13)?
It's time... the main holdout was due to the lack of another Windows
solution (at least until jxclient is considered complete/stable).
One of the arguments I
Klaus Elsbernd wrote:
Well, one cent from an old user:
lalo.mart...@gmail.com said:
This brings the usual question :-) any objections if we nuke x11 and gtk
from the tree for trunk (and 1.13)?
I would like to remark, that there are more than windows systems out
there. For example simple
Just another notes on clients:
For the gtk-v2 client, having 3 different draw modes (pixmap, opengl, sdl)
seems like overkill and is extra maintenance work.
pixmap is no frills, but is always sure to be there, so should be kept.
I don't think we need both opengl and sdl support. I'd
Quick notes:
Magic needs more rebalance work, and the note about destroy objects is too
true.
Changing how often (if at all) magic destroys item is one of those things to
do.
Magic should probably destroy items on occasion, but that might be limited to
things like fireball or other
As the original write of the output sync, here is some background and my
thoughts.
That code was originally put back in before the client/server split. At that
time, any control of messages had to be done is the server - there was no
client
to do that task. This really makes it a bit
Kevin Bulgrien wrote:
The message types in the system are consecutive numbers from 1 to 20. They
are:
snip
I would like to consider changing the message types to bit values so that it
is easier to use masks to detect message types instead of having to do
sequential tests for individual
The server has some number of tests that can be run if you have the necessary
dependencies and do a 'make check' to run them.
While many of the tests are always deterministic, some of them doing things
that are not deterministic - call treasure generation routines. The processing
of that
Nicolas Weeger wrote:
Hello.
How would one integrate old (as some hundred years old) in-game stories in
the
gameplay flow?
Right now, we have kind of the Know-It-All sage who will conveniently know
everything of things that happened hundred years ago, without any mistake or
Alex Schultz wrote:
On Mon, 16 Nov 2009 23:11:58 +0100
Nicolas Weeger nicolas.wee...@laposte.net wrote:
Suggestion to change the various messages at login:
snip
What do you think? :)
I for one, like it. I'd say... commit time unless anyone has any
suggestions :)
I agree - better
Nicolas Weeger wrote:
Hello.
I'd like to suggest a [img name=xxx] tag for client-side rich tags, as
defined in mediaTags.
As implied, the tag would display a picture from its name :)
Uses:
- illustrate a text
- show a bigger picture of something (map, illustration, ...).
I
Kevin Bulgrien wrote:
Hello.
I'd like to suggest a [img name=xxx] tag for client-side rich tags, as
defined in mediaTags.
As implied, the tag would display a picture from its name :)
Uses:
- illustrate a text
- show a bigger picture of something (map, illustration, ...).
What do you
I was thinking about this some more, and had some other ideas.
If one thinks about it, even someone not very literate can still read
something - he isn't going to read a college level physics book, but could read
a newspaper perhaps.
If one were to go on this logic,than for any given
Nicolas Weeger wrote:
Hello.
Right now there are many houses / maps in the various towns which have
monsters.
What about moving all that outside the towns (which after all have guards and
such, and should probably be safe places?), and putting them in the country
side?
Except
Nicolas Weeger wrote:
Hello.
Off the top of the head, I could imagine some quick cases, like:
- Book containing information about a monster, and containing a picture of
that monster
- Same for other objects (more likely artifacts or unique rare stuff).
However, from a tutorial
Nicolas Weeger wrote:
Hello.
Suggestion to change the various messages at login:
Apparently, those messages are part of the motd / server rules / news.
So they could be changed as part of the default installation, but not that
useful for existing servers.
It's probably more a
Nicolas Weeger wrote:
I think we have sort of learned over time that coding in such solutions
tends to lack flexibility we generally desire, or don't give as good
results as we might hope.
We could certainly have script based text garbling, but having it do it
so that it doesn't look
Nicolas Weeger wrote:
More likely want to have something like an img tag with hints, for things
like popup, desired size, etc.
Then let's do the whole trick and use some XHTML subset?
Note that anything that deals with popups can be annoying in some areas.
If you read some scroll
Andreas Kirschbaum wrote:
More likely want to have something like an img tag with hints, for
things like popup, desired size, etc.
Then let's do the whole trick and use some XHTML subset?
I'd rather keep the existing media tags implementation rather than
switching to another encoding.
Nicolas Weeger wrote:
While you may jest, I still think that last comment is true.
As a very basic level, the client could request both the username
password at once for login, with another button with something like 'create
new character'
Depending on what the user does, gets
Nicolas Weeger wrote:
Hello.
Here are two proposals for spells. They are not totally incompatible, but
well, even only one could fun IMO :)
The aim is to reduce the number of spells, and also make it more customizable
for players;
I'll use the fireball spell as an example.
Nicolas Weeger wrote:
Hello.
On trunk, an interesting issue: a dragon praying on an altar to become
follower of a god will lose burning hands / medium fireball abilities.
The issue seems to be become_follower (server/gods.c), which removes the
FLAG_STARTEQUIP spells - including those
Nicolas Weeger wrote:
Hello.
I'd almost rather just have the server dump all those to the messages
file, and then go through and so some cleanup.
We need a way to generate messages from the archetypes, though, so when
archetypes change we don't forget to update messages.
I agree.
Alex Schultz wrote:
On Sat, 05 Dec 2009 22:29:36 -0800
Mark Wedel mwe...@sonic.net wrote:
Nicolas Weeger wrote:
Then that's not matching :)
A real match would be a level 5 monster being able to kill a level
5 players.
Maybe, but there are some other considerations.
Under
Nicolas Weeger wrote:
But I'm also not sure if your ingame comment refers to selecting a
character to play or creating a new one. For creating a new one, we could
perhaps leave the existing mechanism there since redoing is more work. But
making in game (map based) character selection I
Otto J. Makela wrote:
Nicolas Weeger wrote:
Well, Scorn also has an explanation on why neglected houses have monsters
in them: the situation with Old Town.
Talking about that quest, would anyone have a description? That is what
items
one can find, clues there are, and so on?
:)
Sorry,
With the recent discussions on spells and this or that, tossing out this one
-
get rid of AC and WC (one goes with the other really).
There are a few reasons for this that I found from my rebalance work:
- Going on a rough target of opponents should hit each other about 25% of the
time
Nicolas Weeger wrote:
Hello.
Should some game things maybe be made account wide properties and not
character properties? Off the top of my head, I could think of things like
apartments.
KISS for now. Let's just make an account, we'll think about shared apartments
later.
Though I'd
Recording for posterity a discussion in IRC about quests. I've probably
forgotten a few things, but hopefully I got most of.
One of the issues right now is that for most maps, there is no storyline.
You
have a bunch of maps which you go and kill things and serve no other purpose.
In
Nicolas Weeger wrote:
Hello.
One thing I did think of might be DM access - maybe the dm_file should
use account name instead of/in addition to character name?
It strikes me that if you are going to trust a player with dm access, you
probably don't really care what character they are
Nicolas Weeger wrote:
Maybe. Or just say that the level basing is that a character of level X
can reasonably take on a group of 5 monsters also of level X.
But as said, I think some of the failure is the AI in crossfire, so the
make up for stupid monsters, there are just more of them.
Nicolas Weeger wrote:
So my suggestions on this:
- Allow numbers in names - just the name can not start with a number.
- Going forward, names should be unique in a case insensitive manner. The
player can still choose variations on capitalization, you just can't have a
'mark' and 'Mark'.
Nicolas Weeger wrote:
Hello.
I'm currently tweaking Darcap, to add some (I hope) interesting things to the
town.
My plans include:
- move quest-related stuff outside the town
- no monsters in town houses (but maybe through wells or holes)
- linked characters, based on player's
Having the NPC's be unkillable is the easiest approach - all that is needed
is
set up of proper immunities, etc to do so.
Having new ones spawn is reasonable, but I then start wondering what do we
really get from that vs making them unkillable? If the bar tender is killed
and
in a
Nicolas Weeger wrote:
Would the dialog system (at least, initially) work like it does now?
Meaning, NPC response is based on key word(s) from the player character?
Yes, probably keywords.
Though the player wouldn't use the 'say' command, but click on the selected
reply in the dialog.
Otto J. Makela wrote:
Mark Wedel wrote:
One could even see the tavern closing down (people can not enter it),
which
would force a reset sooner. Could be said that new workers need to be
found,
damage repaired, etc.
I assume this would apply also to stores where the merchant
Nicolas Weeger wrote:
True - there is no migration plan/support. However, there are some
number of servers right now that running trunk bits.
But maybe we just state all trunk servers must convert over, and let them
deal with any conflicts they have on their own.
As I see it, first
Nicolas Weeger wrote:
Hello.
To have some coherence in maps in town, I'd like to suggest the following
rules for exits:
- in the world map, you need to apply an exit to enter the map
That sounds good.
- in a town map, exit is applied automatically when you step on it
I take that to
Dany Talbot wrote:
move to Qt/C++, to not reinvent the wheel all the time; and massively
clean the code
I know someone sort of looked into doing crossfire in C++ several years back.
Their opinion was it was probably easier to start writing the code from
scratch vs trying to convert the
Nicolas Weeger wrote:
For example, stairs no matter where they are, should require an explicit
apply to use them
Oak doors could always be auto apply, etc. Buildings are always explicit
apply, and so on.
I'd say explicit apply for all things you'd expect to use/apply in real life:
Nicolas Weeger wrote:
Hello.
Considering the low feedback/participation on the list, I'm totally changing
how I work :)
Seems like a reasonable idea. I've made a list of stuff I plan to work on -
I
put it at:
http://wiki.metalforge.net/doku.php/user:mwedel:todo
Plus side is there
Nicolas Weeger wrote:
I wonder if you could do that if #ifdef's :)
Why #ifdef's?
Just put the check in the code, at least it won't be forgotten!
I don't like the idea of putting an actual exit in the code or something -
that could be pretty annoying if it is a section of code not
Nicolas Weeger wrote:
I know someone sort of looked into doing crossfire in C++ several years
back. Their opinion was it was probably easier to start writing the code
from scratch vs trying to convert the existing code. I haven't looked at
it enough to say for sure, but I could certainly
Nicolas Weeger wrote:
Hello.
Proposed change for 'use_skill' behaviour for alchemy-like skills:
- remove the item identification part; use_skill only attempts alchemy (or
equivalent)
- add a new 'identify' command, that will identify based on (alchemy-like)
skills the player knows
I'm
Otto J. Makela wrote:
PS. If dragons don't have hands (the logic behind no swords, I think),
where do they wear their rings? And why do dragon monsters often leave swords
when you kill them?
People have suggested all sorts of places where dragons may put those rings -
tail, horns, etc.
Nicolas Weeger wrote:
I'm not quite sure how to fix that - I had suggested in the distant past
that spellbooks could be cursed, and if you read them, you'll lose that
spell (as a problem right now is that trying to read a spellbook is an easy
way to identify it) - but with that change, I
Alex Schultz wrote:
On Mon, 18 Jan 2010 18:33:44 +0100
Nicolas Weeger nicolas.wee...@laposte.net wrote:
I think one change, relative to food, is for all flesh type
things (which can be eaten as food) should have some time limit
where they start to decompose/rot. I shouldn't be able to
Nicolas Weeger wrote:
I'm presuming you are saying that the same skill, like now, has multiple
ways to be used, and different commands should be used.
I'm talking about alchemy-like spells, actually.
The proposed change is for those skills to only do alchemy and not
identification, and
Otto J. Makela wrote:
Mark Wedel wrote:
Alex Schultz wrote:
Expand cooking to allow players to salt the meats and such? Perhaps
make weight-reduction-enchanted containers have some kind of partial
preservative magic? That would help trolls :)
That could work. It may just be that for even
So as noted someplace, my thoughts for login is this:
You log in with account name password.
You then see list of characters associated with that account, and options to
add
new one.
In that list of characters, what would useful information be? My thoughts
right now:
-name (obviously)
Nicolas Weeger wrote:
The release methodology sort of needs to be sorted out - if we plan to do
a lot of cleanup (which may break things), I'd sort of like to do that
before the first rc - typically you make an rc when you think you are about
ready and are trying to sort out bugs.
I'm writing this message to mostly capture ideas/thoughts from last nights
IRC
discussion before they leave my brain.
The basic idea is to communicate all face (and I think animation data) to the
client before play starts. This should improve bandwidth some (no spike in
sent
data when
Nicolas Weeger wrote:
Ok - in a sense, it is somewhat acting as a predefined binding, but also
using an alternative use for the skills.
Correct.
Are there any skills out there that only identify objects?
Detect magic / curse. So the logic for use_skill for those will just be
Nicolas Weeger wrote:
Even if cursed items are impossible to identify, I suspect players will
just wait until they are in town to see what they are - It would such to
use one in a dungeon and find out you are in bad shape because you are
stuck wearing crappy armor.
Live action RPG tends
Nicolas Weeger wrote:
In that list of characters, what would useful information be? My
thoughts right now:
-name (obviously)
-class race
-level
-face (not as much useful, but gives something nice for the client to show)
Anyone have other thoughts?
That seems fine too, that's the
Nicolas Weeger wrote:
Hello.
I just added a small protocol extension.
spellmon setup command can now take a value of 2, resulting in more spell
information sent (including required items to send, and if the spell needs
arguments to be used - text for rune of marking, things like that).
Nicolas Weeger wrote:
Hello.
I just committed a small patch enabling spells to require and consume items
when cast.
The patch uses a 'casting_requirements' key (in the spell object itself) to
enforce restrictions.
The value should be a list of items, like the alchemy uses.
Currently
Nicolas Weeger wrote:
This probably isn't a problem until spells that use this functionality
become widespread - my main concern in there may be some confused/upset
players if there are spells that end up using valuable items.
Hopefully, client will warn when selecting such a spell (which
Nicolas Weeger wrote:
Note one issue there - if I use sense curse and find cursed items, I
typically don't want to then identify them, as you can sell cursed (but not
identified) items for some nominal amount of money.
So my standard procedure was always:
detect cursed and magic items
On 01/31/10 04:40 AM, Nicolas Weeger wrote:
The basic idea is to communicate all face (and I think animation data) to
the client before play starts. This should improve bandwidth some (no
spike in sent data when entering a new map to send images, etc). This also
simplifies a lot of code -
On 01/31/10 04:35 AM, Nicolas Weeger wrote:
But I have a feeling players will easily be able to know/defeat these
things.
As said, getting stuck with a cursed item in that dungeon would be really
annoying. Especially if you thought it was a really good item (if it isn't
a good item,
On 03/ 1/10 05:32 PM, Alex Schultz wrote:
I haven't been very active with things these days, but I'd be in
agreement with a release being made. My one reservation is that of
those options, I wouldn't want it numbered 2.0 since I don't think
enough has happened to justify that yet.
Making a
On 02/28/10 12:50 PM, Nicolas Weeger wrote:
Hello.
What about we just decide to do a release of trunk end of march?
Whatever it is called, 1.5, 2.0, 1.9, and such :)
Then let's kill branch, and work on trunk.
Does that sound ok?
Just to follow up on this some more and other ideas:
On 03/15/10 12:41 PM, Nicolas Weeger wrote:
snip
Target release for end of March or so. Are there any must fix bugs to be
dealt with? I hope to have the new account login stuff done soon, but I've
been saying that for months :(
The recent object_free2() and object_free_drop_inventory()
On 03/20/10 12:55 AM, Nicolas Weeger wrote:
Hello.
Yes, that is the ideal case, especially if there is lots of active
development.
If there isn't, it is simpler to just freeze the trunk gate for anything
but bug fixes needed for the 1.50 release. That way quality can get
better,
On 03/20/10 10:12 PM, Alex Schultz wrote:
On Sat, 20 Mar 2010 21:14:41 -0700
Mark Wedelmwe...@sonic.net wrote:
Just a note, this was discussed several years back, and at that
time, there was concern that that 'gives away' information to the
player that perhaps should not be given away
On 03/21/10 01:37 PM, Brendan Lally wrote:
On Sat, 20 Mar 2010 21:14:41 -0700
Mark Wedelmwe...@sonic.net wrote:
On 03/19/10 11:24 AM, Brendan Lally wrote:
The following is a proposed addition to the crossfire protocol to
enable the clients to show monster health bars.
Just a note, this
So I'm actually making some real progress on the account based login. But in
doing so, have come across a few issues I thought I'd ask for input in.
Character passwords: Legacy characters have a hash password in the .pl file.
This will be used by the new login method to associate one of
On 03/22/10 02:00 PM, Robert Brockway wrote:
On Sun, 21 Mar 2010, Mark Wedel wrote:
snip
Format of news file: Currently, it is listed as oldest first, with
newest at the bottom. It seems to me that the reverse (newest at top)
is better - just like the Changelog - you start reading, and once
On 03/28/10 06:19 PM, Brendan Lally wrote:
snip
quest scorn/PortPass
title Port Pass
description
Acquire a port pass to be allowed into Scorn's docks.
end_description
stopstep 20
restart 0
step 10
description
The guards told me that I could acquire a port pass from the Office for
Gate
On 03/29/10 10:25 AM, Brendan Lally wrote:
snip
Rather than having the stopstep, for each step, would it be
possible/better to have a keyword there to not that the quest is done?
What I'm thinking is that for complex quests, there could be
several paths, and it would seem clearer to me
On 03/30/10 10:20 AM, Brendan Lally wrote:
Random question 2: For repeatable quests, is there any record that
the character is repeating a quest vs it being their first time?
Likewise, would it be worth it to note how many times a character has
done a quest?
I'm thinking that in some
Just a heads up - I'm targeting weekend of April 10-11 to make a release,
since I should have time then (certainly won't this weekend)..
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
On 04/14/10 12:10 PM, Brendan Lally wrote:
Hi All,
As part of an overall aim to make the cf client a little more
user-friendly, I have created a patch to add a skill window to the
client.
This may be found here:
On 04/14/10 12:29 PM, Rick Tanner wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/31/10 2:01 AM, Mark Wedel wrote:
Just a heads up - I'm targeting weekend of April 10-11 to make a release,
since I should have time then (certainly won't this weekend)..
To recap or confirm
On 04/15/10 08:47 PM, Kevin Bulgrien wrote:
Without countering Mark, I have build scripts that go all the way down to
making
RPMs... I'll support you in making a client release compatible with branch if
you
really want that. I can see part of the point of having branch for
stability,
My fairly random thoughts on all of this:
- The space used up for the tab for skills exp is minimal, so for most
layouts, the cost of keeping it in place isn't very high.
- Changes where someone else disagrees with that change are always a problem -
this can also happen in maps. In
On 04/18/10 11:08 AM, Nicolas Weeger wrote:
Hello.
The gnome, and gnome2 monsters have an attacktype of paralyze, for a level
of 6.
IMO that is too hard for new players, so I've changed the attacktype to
physical and magic.
gardengnome on the other hand, level 25, keeps his paralyze
On 04/19/10 05:08 PM, Kevin Bulgrien wrote:
I do not at all like the idea of having to switch items on and off. What I
think would be more practical would be to switch to an MDI interface and
allow layout of the MDI to be saved and restored... either that, or figure
out how hard it would be
On 04/20/10 06:20 PM, Brendan Lally wrote:
On Sat, 17 Apr 2010 13:00:24 +0300
Otto J. Makelao...@iki.fi wrote:
What I would like to also see is having a class identified (similar
in function to cursed and magic) in the inventory, so that you
could more easily manipulate items which you have
On 04/23/10 04:40 PM, Kevin Bulgrien wrote:
The GTK-V2 client gets a bad rap because the default sizing has been removed
from the layout. People who start up the client think it is not working
because it is all jumbled, etc. I think either the change should be reverted,
or a different, more
Now that 1.50 is released, I plan to start work on the new character creation
method.
This new method puts the creation in-client. This has several advantages -
better interface for the end user, removes a lot of code from the server, and
also moves some of the current character
On 05/ 1/10 07:40 AM, Nicolas Weeger wrote:
Hello.
Now that 1.50 is released, I plan to start work on the new character
creation method.
This new method puts the creation in-client. This has several advantages
- better interface for the end user, removes a lot of code from the
As per note in thread about new login method, figuring out what classes/races
should be present really comes down to what type of play we want to have.
I know this has been discussed before, but opinions change, so I thought I'd
restart the conversation.
This much more drives classes
On 05/ 2/10 11:15 AM, Otto J. Makela wrote:
Mark Wedel wrote:
This new method puts the creation in-client. This has several advantages
-
better interface for the end user, removes a lot of code from the server, and
also moves some of the current character information from maps
On 05/ 2/10 06:13 AM, Kevin Bulgrien wrote:
But perhaps this also goes back to my playing ADD, and fact that most
games
have some for of class restriction. I also think that such a system may
generate more player interaction - if I can do every class really well on one
character, not as
In the discussion about races and classes, stats certainly play a role in
that.
If one looks at some games, like ADD, stats are pretty fixed (just like
crossfire, there are some items that improve them, but the natural stats are
hard to improve or have a limited number of improvements
On 05/ 3/10 12:53 PM, Nicolas Weeger wrote:
Hello.
As per note in thread about new login method, figuring out what
classes/races should be present really comes down to what type of play we
want to have.
Related to gameplay, I'd like to propose a shift on the aim of the game.
Having played guild wars a lot, and aside from the pvp combat aspect, another
thing to do after completing the quests is to get titles.
There are around 30-40 titles. For some titles, just completing all the
quests will get you pretty close to maxing it out (most titles have different
A somewhat related question:
Since the quest system (and some other core functionality) is using
python/other plugins, should the configure check be changed so that configure
errors out if the python libraries are not available (eg, will be unable to
compile the plugin)
Most of the
The discussion on the previous thread has died out, so I thought I'd draw
some
conclusions and move the discussion forward. While not a lot of responses,
the most votes seemed to come in on the idea of classes play an important roll
-
there are exclusive skills, a fighter can never be as
Never saw any response, but had some other musings. Changing subject to use
attributes, since that is a bit less general than statistics, which can mean
almost anything.
I was thinking there is some disparity in the different classes and how
many/what starts are important. These are my
On 05/11/10 01:02 AM, Otto J. Makela wrote:
Mark Wedel wrote:
The other thing to note is the relative unimportance of Cha here. For
most
characters, only real effect is on shop pricing, as a lot of characters
probably
do not use singing/oratory. Other than making some other skill use
On 05/12/10 03:58 PM, Brendan Lally wrote:
On Wed, 12 May 2010 19:11:14 +0200
Nicolas Weegernicolas.wee...@laposte.net wrote:
Never saw any response, but had some other musings. Changing
subject to use attributes, since that is a bit less general than
statistics, which can mean almost
following up to myself. This is more some thoughts on how to handle stat
points, improvements, and not as much about making all the stats useful.
- Stat bonuses/penalties become linear (for example, (stat - 10)/2) instead of
the exponential they are now. Depending on the stat and bonus, it
Lost in some of the other discussion is races.
For the most part, they don't need a lot of work - they give some stat
bonuses
and some skills, but generally not weapon skills.
But one thing I was thinking about is what are appropriate races, from a game
view standpoint, to make
On 05/14/10 09:41 AM, Brendan Lally wrote:
On Thu, 13 May 2010 22:51:55 -0700
Mark Wedelmwe...@sonic.net wrote:
Exactly how potion improvement works is a bit different
discussion. One thought is a characters first 10 potions are sure to
work, and potions after that have some reduced
Resending back on the list
Original Message
Subject: Re: [crossfire] Attributes/Stats
Date: Thu, 13 May 2010 21:07:55 -0700
From: Mark Wedel mwe...@sonic.net
To: Brendan Lally brenla...@gmail.com
snip
The one issue I sort of see with that is a lot of times
fire/electricity
On 05/14/10 09:22 AM, Brendan Lally wrote:
On Thu, 13 May 2010 21:07:55 -0700
Mark Wedelmwe...@sonic.net wrote:
However, problem in that case is that if say fire is Dex, and
magic is Pow, if I have a 20 dex and 1 pow, that is the same
damage as if I have a 11 dex and 10 Pow. If I'm a
On 05/15/10 09:02 PM, Kevin R. Bulgrien wrote:
Having never built cre before, I gave it a try tonight because I saw some
advance made in quest support.
I had some trouble with the README instructions to just qmake make as
I have a KDE 3 system. The project will not build with Qt 3, so I
On 05/16/10 12:58 AM, Nicolas Weeger wrote:
But one thing I was thinking about is what are appropriate races, from a
game view standpoint, to make available.
For example, dwarves, elves, humans, half orcs, dragons, trolls, gnomes,
northmen, and wraiths are all fairly common creatures in
501 - 600 of 736 matches
Mail list logo
