Re: CF: stable crossfire ?

[Anthony Thyssen <anthony@cit.gu.edu.au>]

Rupert.Goldie@ericsson.com.au on  wrote...
| Subject: Re: Whats the plan? (Was: Re: CF: Suggestions and bugs)
| 
| 0.94.0: complete client/server implementation (done)
| 0.94.x: Various refinements/fixes for the cs stuff above.
| 0.95.0: Remove all X11 dependant code - only client/server play supported
|         at that time.
| 
| 0.99.0: Start refining crossfire to be stable and balanced for 1.0 release.
|         This means the only changes here would likely to be bufixes, and not
|         new features.
| 1.0: First true public release - fully stable, and very well balanced.
| 
|  Note that there is a big gap between 95 and 99 and what features get
| added in there.
| 
| -----
| 
| Is is time to start stabilizing Crossfire ? Could we actually have 
| Crossfire 1.0 before 2000 ? I ask this in all seriousness. Cristian's
| comments recently about changes to Crossfire affecting maps is quite
| valid. If we want to have lots of maps that are balanced and work properly
| we have to, at some point, freeze the server functionality.
| 
| Crossfire has lots of features, maybe it's time to stop adding new ones
| and to start playtesting and tweaking the existing server.
| 
Not until Mark's current work with a complete overhaul of objects.

Part of this I would like to see many of the numerious devices merged 
and fixed so that options on few devices can generate all the
current arch devices and And all the one which should be available and
isn't.

Things I would like to see from this before any final fixing.
  * a handle can generate on/off/toggle signals in any combination
  * all gates could be normal or trigger (timeout) from either closed
    (current trigger gate style) or open (not available) posible
  * trigger handle and gate timeout can be set.
  * altars (sacrifical, not goddly)/converters/gold floors etc
    properly defined with once only, signal type, spell, etc.
    At the moment they are very simular with a mess of code determining
    what is to happen or if it is once off or multiple acting.
    (I've see the code ;-)
  * Magic mouths triggered only on `on signal' not BOTH as it currently
    does. Also maybe a timeout so steping on one, step off, and step on
    another (with same non-zero connect) will only result in ONE message
    until timeout. (Like an invisible trigger button with output :-)
    (EG: a mgic mouth could be a special case button with different edit
    image -- handled by the Archs).
  * Teleport turn on/off, or time to activate started by object on top
    instead of cycling ever fixed period. Eg: object on top will be
    teleported X ticks after moving on top, and not the random amount of
    time until the next cycle.
  * Movers able to move non-living objects (switchable?).

Basically there is a lot of devices (input and output) which have been
haphazardally added to crossfire which needs to be consolidated in there
workings.

Many devices are very simular with only the final `action', reset
timeing, and start position or trigger event different from device to
device.

  Anthony Thyssen ( System Programmer )    http://www.sct.gu.edu.au/~anthony/
- --------------------------------------------------------------------------- -
    Diplomacy(n) :- The art of saying 'Nice doggie!'
                                     ... till you can find a rock.
- --------------------------------------------------------------------------- -
     PGP Public Key available -- finger -l anthony@lyrch.cit.gu.edu.au
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]