Tolga Dalman | 19 Apr 10:46 2014

Crossfire server code cleanup/janitorial

Dear community,

first of all: thank you very much for your efforts in the development of
crossfire. I'm a keen player of this game since around 2002.

Recently, I noticed several cleanup and janitorial work in the trunk. I wonder
whether there should be done more. Looking through the code, I have to
say that the overall quality of the server sources is really good. However,
crossfire is a software that has evolved since at least 1995.

Hence, I would like to ask you, the developer community, a number of general
questions about the future of the crossfire (server) development:

1. What platforms are still relevant ? Beside Linux and BSD, I found references 
to these OSes:  win32, hurd, hpux, ultrix, osf1, sgi, sun, vax, ibm032.

2. What C standard is relevant ? Moving towards C99 or even C11 would allow
large portions of cleanups (standard functions, types, language constructs,

3. What about the use of C++ (2011) ? It is clearly possible to smoothly convert 
existing code to C++ which allows better maintenance of the code.

Please understand these questions as a constructive effort to further improve 
the quality of the current code basis.

Best regards
Tolga Dalman
Kari Pahula | 13 Apr 12:14 2014

Building crossfire 1.71.0 server fails without arches


Crossfire 1.71.0 server is unbuildable without the arch directory.
Here's what happens in lib/ directory (from make -d's output):

    Considering target file `smooth'.
      Considering target file `.collect-stamp'.
       File `.collect-stamp' does not exist.
       Finished prerequisites of target file `.collect-stamp'.
      Must remake target `.collect-stamp'.
touch .collect-stamp
Putting child 0x01251550 (.collect-stamp) PID 15874 on the chain.
Live child 0x01251550 (.collect-stamp) PID 15874 
Reaping winning child 0x01251550 PID 15874 
Removing child 0x01251550 PID 15874 from chain.
      Successfully remade target file `.collect-stamp'.
     Finished prerequisites of target file `smooth'.
     Prerequisite `.collect-stamp' is newer than target `smooth'.
    Must remake target `smooth'.
touch .collect-stamp
Putting child 0x012744c0 (smooth) PID 15875 on the chain.
Live child 0x012744c0 (smooth) PID 15875 
Reaping winning child 0x012744c0 PID 15875 
make collect


Considering target file `collect'.
 File `collect' does not exist.
 Finished prerequisites of target file `collect'.
(Continue reading)

Kevin Zheng | 13 Apr 06:12 2014

Bug tracker group searches

Hi there,

Since the bug/feature/patch trackers switched to the new tracker states,
the group searches have been left unchanged. To make these states more
useful, I would like the following searches:

- New (bugs that are "open")
- In progress ("feedback", "analyzed", or "patched")
- Closed (but NOT "suspended")
- Suspended (but NOT "closed")

In addition, the milestones should be updated:
- 1.11 and 1.12 should be closed
- 1.x_next+trunk should be removed
- Add milestones for 1.72.0 and 1.71.1?
- Maybe re-open the "2.x" milestone for really-distant changes?

Somebody with bug tracker modification permissions should make these
changes. The current milestones/searches are meaningless/broken anyways.

Kevin Zheng
Kevin Zheng | 9 Apr 01:45 2014

Crossfire 1.71.0 Released

The Crossfire Development Team is pleased to announce the 1.71.0 release.

Highlights in this release include:

- Per-character keybindings in the GTKv2 client
- Fixed sound support in the GTKv2 client
- Retirement of the 'crossfire-config' build parameter dumper
- New pixmaps for many objects, including jewelry and more
- Faster server input parsing
- Many, many, many bug fixes

For a complete list of new features and bug fixes, please see the online
ChangeLog on SourceForge.


Crossfire is available on SourceForge (and its various mirrors).

Binary packages are not yet available and will be released when they are

'crossfire-client-1.71.0.tar.bz2' contains the source distribution for
the client. If you want to play, this is the only piece you need.

'crossfire-client-images-1.71.0.tar.bz2' contains client images and
graphics.  This prevents the client from having to request image data
from the server. It is optional but recommended if you have a slow
Internet connection.

(Continue reading)

Kevin Zheng | 1 Apr 00:57 2014

'svn:externals' pointers to stable/next/latest

Hi there,

A while ago I wrote to the list regarding the removal of svn:externals
from the client source directory in Subversion. Now I would like to
point at a few remaining external references in the repository.

The 'stable', 'next', and 'latest' folders in the root were set up as
links to other parts of the repository. In my opinion this is confusing
and has outlived its usefulness, and should be removed.

The 'next' branch currently points to 1.12.0, and is not documented on
the wiki. 1.12.0 is ancient and only in active use on Metalforge. The
name is misleading.

The 'stable' branch currently points to 1.70.0, which makes sense.
Keeping this seems logical. This makes updating a server checked out
from the branch easy, although its usefulness still seems limited.

The 'latest' branch contains a single pointer to gridarta, which
probably deserves its own top-level external reference. According to the
wiki, it's supposed to point to the trunk directories, but those paths
never change so there it's only there for convenience.

I'd like to know whether or not there are still people using these
links. If not, I'd like to get rid of them.

Kevin Zheng
DraugTheWhopper | 28 Mar 16:56 2014

Version bump request?

*Tap* *Tap* *Ahem* (Is this thing on?)
Right, so assuming that this email gets to the intended place [crossfire], here's a request: is there any chance of getting a new official upstream release? So the story is as follows: I do no coding or developing, but know enough about Linux to run Debian Testing. However, the current upstream version of CF is 1.70.0, which as of a week ago, is about two years old. If i understand correctly, all trunk improvements since then are not in any official upstream release, therefore never get packaged for Debian, and so are not seen by the casual people who merely "apt-get dist-upgrade" occasionally. Is there a chance a version 1.70.x could be released periodically, or is there a 1.99 that could be packaged separately, or should someone just start packaging nightly builds as "crossfire-client-unstable"? Please pardon my ignorance and correct me as necessary.
crossfire mailing list
Rick Tanner | 11 Feb 21:56 2014

World generator (land.c) questions


I'm using the world generator (land.c) found in maps/trunk/Info to
generate a new continent for the in-progress Pup Land Big World migration.

Here's a sample command I ran for a sample map:

$ ./lander -m . -m -x 1500 -y 1500 -s 1007623715 -p 300 -n 170 -w
10000 -l 50000

And here is what I have been able to gather along with my questions
and comments.  Can anyone help clarify or answer my questions for me?

-x = number of 50 tile wide maps on x axis (1500 would be 30 maps that
are 50 pixels wide; 150 would be 3 maps 50 pixels wide).  No questions

-y = number of 50 tile tall maps on y axis (1500 would be 30 maps that
are 50 pixels tall; 150 would be 3 maps 50 pixels tall).  No questions

seed (-s) = ??

Random number used to generate the fractal? Is there a min and max
value that can be used?  Does higher numbers provide more land or more
water or neither? Higher or lower numbers for more jagged coastline or
more rounded coastline and islands?

land (-l) = ??

Is there a min and max value that can be used?  Does higher numbers
provide more land or more water or neither? Higher or lower numbers
for more jagged coastline or more rounded coastline and islands?

passes (-n) = Make lakes and ocean trenches. General note - it works
better to have more passes, but each pass doing less work - this
results in more consistent lakes and ocean trenching. Found this
summary in either the write or source code.  No questions here.

wpasses (-p) = ??

What is this?

Is there a min and max value that can be used?  Does higher numbers
provide more land or more water or neither?

water (-w) = ??

Is there a min and max value that can be used?  Does higher numbers
provide more land or more water or neither? Higher or lower numbers
for more jagged coastline or more rounded coastline and islands?

Kevin Zheng | 27 Dec 21:49 2013

New bug tracker states

Hi there,

The Crossfire bug/patch tracker on SourceForge uses states to keep track
of the state of a bug report/patch. In order to make it more useful, I
propose removing several states and adding new ones to clear things up.

The first state should still be "open", meaning that it was just
submitted, is unread, and very likely needs feedback from the sender.
This means we can remove "unread".

Next, there should be "analyzed". The problem is understood and a
solution is being sought.

Next, "feedback". Further work requires additional information from the
originator or the community—possibly confirmation of the effectiveness
of a proposed solution.

Next, "patched". A patch has been committed, but some issues (e.g.
confirmation from originator) are still open.

Next, "suspended". The problem is not being worked on, due to lack of
information or resources. This is a prime candidate for somebody who is
looking for a project to do. If the problem cannot be solved at all, it
will be closed, rather than suspended. This should replace

Finally, some of the closed states are ambiguous and should be removed.
"closed-postponed", "closed-remind", and "closed-accepted" are prime
candidates because they are redundant. "cloed-wont-fix" is the same as
invalid, so remove that too.

These changes should apply to both the bug and patch tracker, and
probably the feature request tracker as well.

Kevin Zheng
Kevin Zheng | 5 Nov 01:41 2013

Use of svn:externals in client code on SVN

Hi there,

Crossfire currently uses svn:externals to sync protocol definition
headers between the server and GTKv2 client. While this has its merits,
overall I believe it is confusing, cumbersome, and harmful.

From the SVN Book [1]: "An externals definition is a mapping of a local
directory to the URL—and ideally a particular revision—of a versioned
directory. In Subversion, you declare externals definitions in groups
using the svn:externals property."

My guess is that the original intention of using them was to ensure that
the client protocol headers would always remain in sync with those in
the server. However, here are some issues:

 - The svn:externals property must still be modified manually
 - Copy/paste/merge is faster, less confusing, and works outside of SVN
 - Client sources locked to server, JXClient proves unnecessary

Further, there are several disadvantages to using them as well:

 - It only works with SVN - hinders future migration (if ever)
 - Confusing for people not familiar with SVN
 - Slow, try running `svn up` from the root and wait
 - Breaks `git svn`, which pacifies the impatient Git users

I propose that we go back to manually tracking the protocol headers
between the client and server. They are not updated that often, anyways,
and still need updating with the use of svn:externals. We can continue
using svn:externals in /latest, etc.


Kevin Zheng
Arvid Brodin | 5 Nov 00:41 2013

[PATCH] Fix keybinding bug when connected to server-1.12

As the subject says.

The patch should apply to client trunk rev 19091.

The fix is in three parts:

* If no character name is given (is NULL), don't load or save 
  character-specific keys file.
* Load key bindings directly on startup, when name is NULL.
* If playing on a server with a login process, set the 
  character name and load key bindings again.

Also, please do not modify the patches when applying them since 
it messes up any patches that I have queued. If something should 
be changed, tell me what and I'll generate a new one.

crossfire mailing list
Arvid Brodin | 3 Nov 00:31 2013

[PATCH 2/2] Character-specific keybinding files

Today, keybindings are saved as ~/.crossfire/keys. That means you
cannot have different key bindings for each character.

This patch changes that so that keybindings are saved as 
~/.crossfire/≤character-name>.keys. So if your character is named
Leopold, the keybindings are saved to ~/.crossfire/Leopold.keys.

When play is entered with a character, the client tries to load 
keybindings in the following order:


If none of the files are found, it instead uses the default built-
in keybindings.


crossfire mailing list