XFree86 (3 or 4) to depend to when USE_XLIB is set.
XFREE86_VERSION defaults to 3 for now, but adventurous users can
override it in /etc/make.conf. When XFREE86_VERSION=3, USE_XLIB
will add a dependency to x11/XFree86; when it is set to 4, the
dependency will be to x11/XFree86-4-libraries. When
XFREE86_VERSION=4, the PKG_IGNORE_DEPENDS and ALWAYS_BUILD_DEPENDS
hacks to avoid messing with XFree86 are turned off.
Since XFree86 version 4 includes some software that used to be
separate ports, when XFREE86_VERSION=3 the following variables are
provided:
USE_DGS LIB_DEPENDS on x11/dgs
USE_FREETYPE LIB_DEPENDS on print/freetype
USE_MESA LIB_DEPENDS on graphics/Mesa3
USE_XPM LIB_DEPENDS on graphics/xpm
When XFREE86_VERSION=4, these variables have no effect. The
LIB_DEPENDS in the tree for the above four ports have all been
converted to the USE_* counterparts. For your information, this
is the count of the number of ports:
USE_DGS 0
USE_FREETYPE 16
USE_MESA 36
USE_XPM 236
There is a new variable, XAWVER, which is set to 6 when
XFREE86_VERSION=3 and 7 when XFREE86_VERSION=4. This is also
passed to PLIST_SUB so ports that build Xaw based shared libraries
can use this variable to substitute the shlib version number.
There is also a provision of using a separate mtree file for
XFREE86_VERSION=4, but that part is not enabled yet.
Reviewed by: the ports list
Tested by: make index (XFREE86_VERSION=3 only)
(2) Add hebrew to list of valid categories.
Submitted by: nbm
Make port PREFIX clean
solve gettimeofday compile problem (patch-ao)
sanitize order of header file inclusion in common/porting.c
so that MIN and MAX don't get redefined (patch-ap)
updated PLIST
added dirrm statements in PLIST to allow proper removal of package
- Fix the password problem so passwords are actually checked.
- Change some default options like SAVE_HOMEDIR, XPM_PIX (you hade
the port requiring xpm but CF wasn't configured to link it in),
ForceCCOPTIONS, EXPLORE_MODE, etc.
- Remove the empty ${CFDIR}/lib/shutdown from the Makefile and the
PLIST. This file just causes the program to exit without saying
why until the user manually removes the file.
- Fix "crossfire -o" to call uname correctly.
- Set logfile to be line buffered (instead of block buffered) since they
hardly ever call fflush(3).
Submitted by: Dave Chapeskie <dchapes@golden.net>
MASTER_SITE_SUBDIR=games
swallace wasn't listed as MAINTAINER of any of his ports
janek@gaja.ipan.lublin.pl wasn't listed as MAINTAINER of any of his ports
bin.bin --> ${BINOWN}.${BINGRP}
chown --> /usr/sbin/chown
(not everyone has /usr/sbin in their path, esp. if you sudo'ed to root)
mkdir -p --> ${MKDIR}
Ok, I found the problem.. the artifact code assigns a level value
to artifacts with kind "Berserkergang". The specialweapon/apply
code, when it finds a weapon with a "level" immediately compares
the title field to the weilder's name. If they dont match, it can't
be used.
I created a patch to remove the level designation from the artifact
code since other named weaopns (cf "glamdri") dont have a level
assigned.
B) From: Klaus Elsbernd <elsbernd@dfki.uni-kl.de>
In version 0.92.8 is a bug in the inventory-unlock-code, which
prevents unlocking.
C) From: myself
make post-install target modified in Makefile, *$*HOME was eaten
up by 'make' and displayed nonsense. Tell player to create the players
dir in his login directory.
1) get experience points if you use skills
2) don't crash if player logs in with 2 skills enabled
3) cleaned up PLIST (removed 2 player characters of mine
which aren't part of the distribution)
crossfire is a multiplayer graphical arcade and adventure game made for
X-Windows. It contains elements of various famous games like nethack and
moria. There are different quests to solve, many maps make the game really
interesting. Nice sound capabilities via rplay. Different players can form
a team over network. Treasure and experience points will be shared equally
among the players of a team.
Could please someone try to fix the password authentication ?!
In server/main.c the function check_passwd doesn't work properly.
I made a workaround returning always ok (1) here and marked it as
UGLY_PASSWORD_HACK...
