Rick Tanner | 14 Jun 01:35 2014

Development dialogue


It has been quite some time since Crossfire has seen so many code
tweaks and changes like we have seen the past couple of months.

Thank you to everyone who is and has been contributing to this.

Some recent discussion on IRC brought up some concerns with recent SVN
commits and their impact on existing code, server setup practices, and
performance gains or efficiency of such code changes.

I'm making this post to open dialogue on these concerns so they get
addressed, worked on, updated, etc.

If a code rewrite is necessary, or a revert or something else - it
should be made with some sort of agreement.

I ask that we keep the discussion positive and productive. If you have
an axe to grind, this is not the forum for that. ;-)

Thank you,

Rick Tanner

Kevin Zheng | 13 Jun 15:13 2014
Picon

Crossfire should use Git


Hi all,

Crossfire originally lived in the world of CVS, until a handful of brave
knights ventured to move it to SVN. Today I believe it is time to move
again, and this time to Git.

Git is a distributed version control system, which means that checking
out an old revision or reading the commit log does not require accessing
the sometimes painfully slow servers on the Internet. Each 'clone' of
the repository is a fully-functioning repository on its own. This means
that developers, even those who do not have commit access, can work on
projects at their own pace and submit them with tools such as `git
format-patch` and others.

Git makes branching easy. It makes maintaining them manageable. As an
example, several important fixes were made in 'trunk', which have yet to
be backported to 1.12.0. In addition, there are no release engineering
branches, which means that each release is simply cut from the next
'trunk' state in line. Even "trivial" fixes could benefit from topic
branches, but SVN does not make this easy, convenient, or fun. Using Git
branches would help create a more stable codebase by improving release
engineering and adopting intermediate "stable" branches that servers can
track. A recent autotools bug that wiped server configuration files, for
example, could have been prevented if changes on the bleeding edge were
evaluated by test servers first.

Git is not terribly difficult to use. Right now I access the SVN
repository through a local Git clone, but this is inadequate because I
cannot publish my topic branches (without considerably difficulty). A
(Continue reading)

Nicolas Weeger | 12 Jun 20:35 2014
Picon

Game change proposals

Hello.

I'd like to change various things in the game, to make it funnier (IMO) in non 
combat aspects. So here are random proposals.

What about "mini-games"?

For instance, instead of a mere lockpicking, you actually have to use the 
picks in the right order in a limited time to pick a lock - if you fail, you 
trigger the traps, of course.

[bonus points to who knows the old game I'm getting inspiration from :)]

What about changing alchemy (including the jeweler etc. variants)?

For each formulae you start with a ~3% chance of success. You succeed? Get 3 
to 5 points. Failure? Get 0-1 point (failure is a valuable lesson, after all 
:)). Capped to ~90%. And maybe not giving global experience.

What about random (ie player-dependant) parameters? You have more success 
during certain hours, or outside vs inside, or...?

Then reduce the dropped items. I mean, so much junk!

Then, slowing (a lot) combat, making it more tactical. Instead of a zillion 
monsters, some hard to defeat monsters, where you can use all your skills and 
items, and attempt various combinations.

Then various effects on weapons: stun, knock back, confuse, slow, etc.

(Continue reading)

Kevin Zheng | 8 May 03:25 2014
Picon

Update client GLib dependency

Hi there,

The GTKv2 client sources are split up into two parts, one for "common"
code that can be shared across different clients, and a "gtk-v2" part
that implements the GTK+ client itself.

GLib is a very useful library that provides portable data structures,
lexical scanners, threads, mutexes, timers, hook functions, and sockets.
Currently it is only used in the GTKv2 client because it is a dependency
of GTK+. I propose that GLib should be a dependency for the entire client.

1. There are lots of cool things that GLib will let us have that we
don't have now. Dynamically allocated strings, advanced data types, and
even a config file parser are all available from GLib.

2. GLib will make things more portable. I've been able to get the client
building on Windows again, but it's still very messy, particularly due
to excessive conditional compilation. GLib implements its own portable
sockets that can be used on multiple platforms.

3. GLib will make things less broken. Connecting to a server is a mess,
and sometimes freezes the client given the right circumstances.
Threading, callbacks, and parsing are messy, too.

4. GLib is already a dependency. Besides, on my system, the library and
all development files takes only 17 MB. Most people already have it
installed, because it is a dependency for Gtk, Qt, and more.

5. Even if somebody decides to write another client using SDL, OpenGL,
or maybe even Tcl, GLib can still be used and will still provide all of
(Continue reading)

Tolga Dalman | 26 Apr 08:50 2014

[RFC] cfpython: raise minimum required version to Python 2.7

Hi,

currently, Python 2.4 is required for the map scripts to work properly. I
propose to require version 2.7 as minimum Python version, which was released
in 2010 and is still widely used.

With Python 2.7, we have the opportunity to cleanup some very old Python
conditional stuff. This way we should be able to replace cjson by the
Python standard library JSON implementation. What do you think ?

Best regards
Tolga Dalman
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,
etc).

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
Picon

Building crossfire 1.71.0 server fails without arches

Hi.

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
Picon

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.

Thanks,
Kevin Zheng
Kevin Zheng | 9 Apr 01:45 2014
Picon

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.

Availability:

Crossfire is available on SourceForge (and its various mirrors).
http://sourceforge.net/projects/crossfire/files/

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

'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
Picon

'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.

Thanks,
Kevin Zheng
DraugTheWhopper | 28 Mar 16:56 2014
Picon

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.
--Nathan
_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire

Gmane