Face information for animations

Hello.

When collecting the .face files, the collect.pl script will only write 
fg/visibility information for faces outside animation, and not all faces. On 
the other hand, when an animation is defined into an archetype file, the 
visiblity/magicmap is set for all faces of the animation.

I'd like to fix that so the various animations can be factorized into .face 
files, with the face information (color_fg and such), that doesn't really 
belong to archetypes imo.
Example: the 'sea' animation is duplicated between 'sea' and 'sea1' (file 
ground/sea.arch) - it would be much easier to have it defined in sea.face, 
including color_fg and magicmap and visibility, and just tell 'animation sea' 
in both archetypes.

Opinions?

Nicolas
--

-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]

_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire

Broken trigger_markers (type 52) breaking several maps in SVN trunk

Hi,

This is about bug 1985944: https://sourceforge.net/tracker/index.php?func=detail&aid=1985944&group_id=13833&atid=113833

Since about four months, the trigger_marker archetype (using the
object type 52 TRIGGER_MARKER) is broken.  During the refactorization
of the code for type 55 MARKER, the code that was also handling the
TRIGGER_MARKER objects was removed.  It is hard to know if that was
an accident or if there were some plans to restore or improve that
code later.  In any case, this bug is rather annoying because it
prevents players from entering the apartments in Brest or Lone Town,
it prevents access to the smithery, kitchen, tannery and similar
shops in Scorn and Navar, and it breaks some parts of the python
guilds.  This affects all servers based on SVN trunk.

If I am not mistaken, the main difference between objects of type 55
(MARKER) and type 52 (TRIGGER_MARKER) is that markers detect when a
player steps on them, and apply the mark.  Trigger_markers are only
activated via a connection, not when someone moves over them.  Both
of them add a mark (force) in the player's inventory.

I would like to fix that bug but I'm not sure about the best way to
do it.  I can think about the following options:
1) Restore the old code that was removed - easy, but bad solution.
2) (Re-)write the /types/... code for object type 52 TRIGGER_MARKER,
   trying to share some code with type 55 MARKER in /types/marker/.
3) Get rid of TRIGGER_MARKER and instead try to use the same object
   type (MARKER) for both archetypes "marker" and "trigger_marker".
   It should be possible to customize some fields of these
   archetypes so that "trigger_marker" is only activated by its

Re: Face information for animations

Nicolas Weeger wrote:
> Hello.
> 
> 
> When collecting the .face files, the collect.pl script will only write 
> fg/visibility information for faces outside animation, and not all faces. On 
> the other hand, when an animation is defined into an archetype file, the 
> visiblity/magicmap is set for all faces of the animation.
> 
> I'd like to fix that so the various animations can be factorized into .face 
> files, with the face information (color_fg and such), that doesn't really 
> belong to archetypes imo.
> Example: the 'sea' animation is duplicated between 'sea' and 'sea1' (file 
> ground/sea.arch) - it would be much easier to have it defined in sea.face, 
> including color_fg and magicmap and visibility, and just tell 'animation sea' 
> in both archetypes.

  Sounds good.  As a note, color_fg is deprecated, and instead every color_fg 
should get replaced with the 'magicmap' name instead.

  The color_fg (and at the time, color_bg) dates back to when crossfire used 
bitmaps, and those colors determined the foreground and background color.  For 
some images, the foreground color was not a good indicator for magicmap 
purposes, so magicmap (as a supplemental field) was added.

  Bitmap support has been gone for years now.  Within the server, if it finds a 
color_fg, it just sets that face->magicmap to that value.

  I'd actually like to get rid of magicmap at some point also, and change what 
magicmap spell does - maybe instead of sending the color information, which is 

Crossfire won't work (several errors)!

_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: Crossfire won't work (several errors)!

Kedjane - wrote:
>  
>  By the way, why can't you register to your forums with a hotmail
> adress, that's just really annoying. 

It's due to the hundreds of spam(mer) accounts that have attempted to
register on the forum using  <at> hotmail.com

> I did register using a different
> email, but it turns out I can't access it (I think it was deleted for
> not being used for a few years).

Please reply to me via private email as to what address you used and I
can investigate.

Re: Crossfire won't work (several errors)!

> For example: if I open a .txt window and move it above my Crossfire
> window, then close the .txt window it still appears to be there even
> though it's not - proof that Crossfire have frozen.
> 
> The files I'm using are just the Windows Client linked on the
> Crossfire page (1.11.0) and Pidgin 2.4.3.

What version of GTK ?

The issues you described with the screen not refreshing or appearing to
lock up - I have encountered them as well when GTK had some sort of
conflict with the running app.

What server did you try and connect to?
There is at least 1 server that does not work with recent clients.

> Anyhow, I tried to solve it myself by removing everything and saw the
>  "Windows users use this:" thing on the Crossfire site, some GTK thing,
> and downloaded it but when I tried to install it it said a newer version
> of GTK already was installed. I've tried searching through the entire
> computer and I have deleted everything named both "GTK" and "Crossfire"
> but still it sais it's already installed.

The 1.11.0 client did work best with GTK+ Runtime Environment 2.10.11

Earlier this week (2008-Aug-04), a new snapshot release was made and
that looks to use GTK+ 2.12.9

An install HOWTO is available at,
http://wiki.metalforge.net/doku.php/windows#gtk_2_runtime_environment

> So, right now I've installed Crossfire (1.11.0) again along with
> Pidgin but now when I try to play it sais libglib-2.0.0.dll is missing
> and reinstalling might help. My guess is because I deleted all "GTK"
> files earlier - but since there is some fraction of them left somewhere
> I can't reinstall them to solve the problem!

Try re-installing Pidgin?

Try installing GTK+ 2.12.9?

> Any hints on how I can completely delete GTK? Add/remove software and
> searching for "GTK" doesn't work.

As far as removing your old install of GTK, in all my test installs for
creating the screen shots, etc. I have found using the Uninstall menu
option that is created in Program Files -> GTK+ to work.

Testing svnmerge.py

A couple of people have suggested using svnmerge.py to manage and track
merges (or backports) from Trunk to Branch.

So, I have volunteered and taken the initiative to start on this right
away for maps only.

This is the online guide that I am using to get started:
http://www.orcaware.com/svn/wiki/Svnmerge.py

If this crashes and burns on me, then I will spend alot of time putting
out the fire. 

Re: Testing svnmerge.py

Le mardi 12 août 2008, Rick Tanner a écrit :
> A couple of people have suggested using svnmerge.py to manage and track
> merges (or backports) from Trunk to Branch.
>
> So, I have volunteered and taken the initiative to start on this right
> away for maps only.

Many thanks to you :)

(though I admit I'd rather have trunk become the official release, and branch 
forgotten except for major bugfixes maybe)

Nicolas
--

-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]

_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire

Incorrect Type and Material on multiple objects in Fun Zone

Mapper complained about "Couldn't find archetype 0" so I went to check
on the map with the map editor (snapshot build from Aug-18-2008.)

The Map Editor also gave warnings about many objects (chairs, beds,
tables, pipeweed) having the wrong material and type.

I tried to manually fix them, but found it much easier to just remove
and re-insert the objects in question.   I only worked on fz_lobby, see
r9752.

Given the development history of these maps.. I suspect that the
snapshot .jar file is out of date or the gtk editor may have some
outdated information or my archetypes/editor has the wrong or outdated info.

I'm posting this, because I don't know what could be the cause and to
also alert others to this problem(?).

Rick Tanner
leaf@...

Magic map colors and related changes necessary for client and server

After testing on my part and discussion on IRC, it was discovered that
one can add addition colors to server/common/images.c (around line 100)
and then recompile to allow more colors for the magic map spell
(assuming archetypes are also updated with this new color in their
magicmap field -- formerly, color_fg).

(Note: make sure to add a comma after the color "kahki" like this "kahki", )

However, the current X11 and GTKv1 and GTKv2 can/will crash if any new
colors are added.  So, some undetermined change(s?) needs to be made
with the clients to support 13 (or more) colors.  The JXclient does not
crash; it displays, in this case, purple as dark_gray.

With this in mind, I went through the archetypes and replaced purple
with black.  This was r9762.