> But relatively to players and developers, what do people see as the top
> feature(s) that should be added (or things fixed) to make crossfire a better
> game.
Apart from the code cleanup idea, here's what I see as important:
- Better visual appearance. On the coding side, it means adding thin
> I am not opposed to porting crossedit to gtk however.
>
The current difficulty I see with crossedit is that it is rather heavily
dependent on the server code. I think that the best would be at some point to
get the editor - being GTK, Athena or whatever else - get its own codebase,
alongside t
Mark Wedel wrote:
> With the current discussion regarding modularization, the topic of new
>features also came up.
>
>
Discussions do that :P
> For 2.0, it was mentioned do a general code cleanup to removed old crufty
> code
>that is only there for compatibility reasons. Fair enough.
>
On 1/28/06, Miguel Ghobangieno <[EMAIL PROTECTED]> wrote:
> Hi, I've asked for just that configuration option
> before. I'll forward this mail to the mailing list so
> the other devs may see that this is a wanted feature.
Correction: it /was/ a wanted feature, about a year ago, which is
roughly wh
On 1/29/06, Yann Chachkoff <[EMAIL PROTECTED]> wrote:
> But it definitely wouldn't work anymore if significant changes occur in the
> server code - in particular, getting rid of the Athena Editor would allow to
> remove the separation between the "common" and "server" subdirectories -
> somethin
On 1/29/06, Mark Wedel <[EMAIL PROTECTED]> wrote:
> but relatively to players and developers, what do people see as the top
> feature(s) that should be added (or things fixed) to make crossfire a better
> game.
I'll split this into two parts, usability issues/improvements, and
game issues/impro
Yann Chachkoff wrote:
>>I am not opposed to porting crossedit to gtk however.
>>
>>
>The current difficulty I see with crossedit is that it is rather heavily
>dependent on the server code. I think that the best would be at some point to
>get the editor - being GTK, Athena or whatever else -
On 1/29/06, Mark Wedel <[EMAIL PROTECTED]> wrote:
> > I would suggest the following mappings (for both binaries and package names)
> > crossedit -> crossedit
>
> Arguably, crossedit should just disappear. This, however, may become more
> or
> less an issue depending on other changes (if a code
I have added a page to the wiki, where crossfire 2.0 features could be tracked.
http://wiki.metalforge.net/doku.php/dev_todo/cf2.0
--
Andrew Fuchs
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossf
Understand this Yann. IF crossedit is removed I remove
myself. Do you want to lose your biggest current media
contributor? If so then remove crossedit.
I think you need to fork off crossfire and make your
own project where you can do whatever you want.
Perhapse crossfire-awsome.sf.net?
--- Yann C
I suppose this would be a nice perk and a big incentive to remove
crossedit, but you've quit so many times before that it just isn't a
reliable enough promise to base a decision like this on ;)
Miguel Ghobangieno wrote:
>Understand this Yann. IF crossedit is removed I remove
>myself. Do you wa
Crossedit still works to some degree.
However, when new things are added, it does break and fixes are needed.
Anyone remember regions?
Also, I haven't looked lately, but I'm not sure sure if crossedit actually
supports all needed features - is there an interface to map tiling information
Miguel Ghobangieno wrote:
> Understand this Yann. IF crossedit is removed I remove
> myself. Do you want to lose your biggest current media
> contributor? If so then remove crossedit.
I seem to see this ultimatum almost once a week now (do this or I leave)
This carries no weight for me. I'm
Brendan Lally wrote:
> On 1/29/06, Mark Wedel <[EMAIL PROTECTED]> wrote:
>>> I would suggest the following mappings (for both binaries and package names)
>>> crossedit -> crossedit
>> Arguably, crossedit should just disappear. This, however, may become more
>> or
>> less an issue depending on o
Yann Chachkoff wrote:
> - Friendlier client. The currently available clients are intimidating for
> newcomers: the cfclient looks rather primitive while gcfclient is crowded
> with options bars, icons and menus and leaves only a small patch in the
> middle to display the game playfield itself. I t
Brendan Lally wrote:
> I would suggest then, in no particular order:
>
> * client side display of parties (so that they can present an
> interface more like gcfclient2 has for the metaserver, removing the
> need for using the rather complex party commands directly).
>
Yes - that sounds like a
Check the CVS logs. I have stopped committing about a
week ago. If you remove crossedit I will not restart.
--- Mark Wedel <[EMAIL PROTECTED]> wrote:
> Miguel Ghobangieno wrote:
> > Understand this Yann. IF crossedit is removed I
> remove
> > myself. Do you want to lose your biggest current
> med
Lol.
--- todd <[EMAIL PROTECTED]> wrote:
> I suppose this would be a nice perk and a big
> incentive to remove
> crossedit, but you've quit so many times before that
> it just isn't a
> reliable enough promise to base a decision like this
> on ;)
>
>
> Miguel Ghobangieno wrote:
>
> >Underst
One of the things we should do for 2.0 (note: we are
not yet at 1.9) is try to decrease bandwith usage. For
instance, some animations are cylical, and the server
knows which ones these are currently IIRC. The server
shouldn't have to send a update for every tile every
time for cylical animations, t
Brace is used, as Leaf said before, to make it easier
to swich deities without being pushed off the alter...
this was allready discussed!
We shouldn't do things that increase bandwidth
usage...
/me watches the bandwith usage skyrocket just to spite
him.
--- Mark Wedel <[EMAIL PROTECTED]> wrote:
On 1/29/06, Miguel Ghobangieno <[EMAIL PROTECTED]> wrote:
> Brace is used, as Leaf said before, to make it easier
> to swich deities without being pushed off the alter...
> this was allready discussed!
But since being pushed off the square is an intended effect, being
able to brace to avoid that i
Well Leaf said that it was so that if someone really
wanted to recant their diety that they could, but they
would have to mean it (not by accident, or by mere
trifiling whim) and thus brace. A question I have is
does brace have any ill effects. EX: if you are on a
mover, and brace, does that stop y
Miguel Ghobangieno wrote:
> Well Leaf said that it was so that if someone really
> wanted to recant their diety that they could, but they
> would have to mean it (not by accident, or by mere
> trifiling whim) and thus brace. A question I have is
> does brace have any ill effects. EX: if you are on
Miguel Ghobangieno wrote:
> One of the things we should do for 2.0 (note: we are
> not yet at 1.9) is try to decrease bandwith usage. For
> instance, some animations are cylical, and the server
> knows which ones these are currently IIRC. The server
> shouldn't have to send a update for every tile
Thinking a little little about transportation objects (boats, horses, etc)
and
came to the realization that at some level, a move_allow field is needed.
The basic idea is that move_allow would override any move_block. The case
I'm
thinking about here is boats - players normally can't mov
25 matches
Mail list logo
