Re: [crossfire] Release proposal

[Robert Brockway]

On Fri, 23 Jun 2017, Kevin Zheng wrote:


As much as possible I've been automating the world building.  I hope it
offers different game play to keep people interested.


I think this could offer something to players who want to try something
new. Is the new world compatible with the standard server and client?


Late response :)

Currently I land the players on the old maps and they pass through a 
portal to the new maps.  I want this to go away soon.



I remember some complaints from the Galactic Mileau folks that it was
hard to get recent versions of the client/server running a custom world.
Are there changes that would make this easier for you?


Absolutely.  The newer clients make assumptions about the locations of 
Scorn and Navar City.


The older approach of having the character move around in the Hall of 
Selection would have made it easier than the current approach of having 
the information closely integrated in to the client.


Perhaps the clients could get a start location list from the server, or we 
could return to using something like a Hall Of Selection.


Cheers,

Rob
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Ruben Safir]

On 06/23/2017 07:56 PM, Rick Tanner wrote:
> On 6/23/17 10:02 AM, Matthew Giassa wrote:
>>
>> Also, has anyone tested how much bandwidth, disk space, etc; the latest
>> stable release uses under a test load (i.e. a few users/players)? 
> 
> Disk space needed for (trunk only) source content:
> 


where is everything that was in my guild ;)


> arch = 124M
> server = 39M
> maps = 549M
> 
> After compiling the server:
> 
> arch = 124M
> server = 163M
> maps = 549M
> 
> I have some stats in regards to server resources. This is with Ubuntu
> 16.04 with 6 players running around various maps.
> 
>>From my observations...
> 
> crossfire-server requires 30.0 MiB of RAM to run when idle according to
> the server host System Monitor.
> 
> Each player connected uses an additional ~3 MiB of RAM/ea just to move
> around and interact with the game world.
> 
> When a player with hundreds (or thousands) of items in their apartment,
> guild maps, et al. first enters such a map, RAM utilization jumps
> dramatically. At the moment, I don't have a way to quantify these numbers.
> 
> Each player requires/uses about 10 KiB/s of bandwidth. Some maps with
> lots of spell casting and monsters (i.e., Tower of Demonology, Hanuk)
> causes this to spike as high as 10MB/s or more while that map or spell
> effects are taking place. In a recent test session, I missed tracking
> total bandwidth sent and received.
> 
> Highest use of CPU appears to be calculating damage from spell effects
> (especially comet and meteor) and/or magical attacks (dragons and large
> lightning or large ice storm, etc.)
> 
> Disk space recommended for player files & unique map files, looking on
> Metalforge - there is currently 111M of active player content. There is
> 13 years of archived content that is a total of 651M (low 33M, high 123M).
> 
> 
> 
> 
> 
> 
> ___
> crossfire mailing list
> crossfire@metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
> 


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Rick Tanner]

On 6/23/17 10:02 AM, Matthew Giassa wrote:
> 
> Finally, who maintains the package currently available via `apt` on
> Ubuntu/Debian systems? The Ubuntu page notes that it is Kari Pahula [1].
> Is this person a CF dev?

*IF* it is someone else, I am not aware of it.

To my knowledge Kari Pahula has only done packaging work on the client
and server content. They are not listed on the SourceForge project team.

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Mark Wedel]

On 06/25/2017 08:18 AM, Matthew Giassa wrote:

My guess is with meteor, let's assume 10 projectiles in rapid
succession, each generating a 15 tile radius (approx) effect, that's
about 10 * 700 = 7000 objects. How does the bandwidth shoot up to
10MB/s though?  What is the minimal unit/"tick" of time the server uses?


120 ms is the tick time.

 However, spells (unfortunately), do not move that simply.  If one takes a cone 
(simpler) that is cast to the right, it becomes


 / (a)
-- (b)
 \ (c)

 So on the next tick, when a moves more, it adds an object in the same 
direction (upper right) as a, as well as an object directly right.  Object b 
creates 3 new objects (in directions/spaces a,b,c), and c creates another one in 
c direction as well as b.


 A nice side effect of this is that something in the middle of the cone takes 
more damage at the edges, becaus there are more damage causing objects in the 
middle.  But it means that for an even modest sized cone, it can be a lot of 
objects (there is some merging logic, but a lot of these can not be merged.


 A better approach, would be that when that cone is cast, an invisible object 
is put on the map at the origin point that records various import details 
(direction, how long, etc). Then, each ticket, it just extends the cone to the 
next space as needed, inserting only the objects as needed on those new spaces. 
Then, the number of objects used would match exactly the number of spaces the 
object is on.


 Merging may not be possible, because of different durations (the first fire 
effects would burn out before the second.  Though this could perhaps even be 
handled by recording that information in each effect, eg, a fire object may 
contain data saying it does 20 damage and burns out in 8 ticks, but within that, 
says 6 damage burns out in 5 ticks, so that for the last 3 ticks,the spell does 
14 instead of 20, etc.


 But none of that is a trivial change.

 I'm not quite sure why the bandwidth would go that high - the map information 
is tried to be done efficiently (only send changed data, and each map space 
isn't a huge number of bytes).  However, I suppose if the fireball is killing a 
bunch of creatures and burning up a bunch of objects, the map is actually 
changing considerably.




Finally, does the server employ any sort of compression when sending out
this data, or is that impractical in such a case?


 I think this was investigated, but never done.  One has to make sure that 
adding the compression does not add more latency, which may mean that there are 
many small chunks of data compressed.


 Note also that bandwidth used is going to be pretty directly related to the 
size of the map - a 25x25 is going to use up about 4x the bandwidth of a 13x13 
in highly dynamic content, simply because it has that many spaces.




___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Matthew Giassa]

My guess is with meteor, let's assume 10 projectiles in rapid
succession, each generating a 15 tile radius (approx) effect, that's
about 10 * 700 = 7000 objects. How does the bandwidth shoot up to
10MB/s though?  What is the minimal unit/"tick" of time the server uses?

Finally, does the server employ any sort of compression when sending out
this data, or is that impractical in such a case?

Cheers!

* Mark Wedel  [2017-06-24 13:06:36 -0700]:


On 06/23/2017 04:56 PM, Rick Tanner wrote:

On 6/23/17 10:02 AM, Matthew Giassa wrote:


Also, has anyone tested how much bandwidth, disk space, etc; the latest
stable release uses under a test load (i.e. a few users/players)?


Disk space needed for (trunk only) source content:

arch = 124M
server = 39M
maps = 549M

After compiling the server:

arch = 124M
server = 163M
maps = 549M

I have some stats in regards to server resources. This is with Ubuntu
16.04 with 6 players running around various maps.


Disk space (and memory use) is pretty minimal for modern systems - 
the game goes back 20+ years, and while it has grown, it hasn't grown 
as much computer resources has.




From my observations...

crossfire-server requires 30.0 MiB of RAM to run when idle according to
the server host System Monitor.

Each player connected uses an additional ~3 MiB of RAM/ea just to move
around and interact with the game world.

When a player with hundreds (or thousands) of items in their apartment,
guild maps, et al. first enters such a map, RAM utilization jumps
dramatically. At the moment, I don't have a way to quantify these numbers.


There is a sizeof command you can run, that dumps the sizes of various objects.

IIRC, each object was ~500 bytes (sizes can also vary based on 32 
bit/64 bit or other factors).  A world map (50x50) perhaps has 5000 
objects on it (2/space), but pretty easy for apartments or guild halls 
to easily exceed that.




Each player requires/uses about 10 KiB/s of bandwidth. Some maps with
lots of spell casting and monsters (i.e., Tower of Demonology, Hanuk)
causes this to spike as high as 10MB/s or more while that map or spell
effects are taking place. In a recent test session, I missed tracking
total bandwidth sent and received.

Highest use of CPU appears to be calculating damage from spell effects
(especially comet and meteor) and/or magical attacks (dragons and large
lightning or large ice storm, etc.)


Yes, this is a problem with how the spells propagate - one spell can 
easy make hundreds or perhaps thousands of objects.  That in itself 
may not be bad, but the insertion of each object and interactions with 
other objects chews up that cpu time.


The other issue is that the game is only single threaded, so a 
massive spell burst (or loading a big map) slows everything down.  20 
years ago, multi cpu (now core) systems were pretty rare, now they are 
commonplace.  However, making the server multithreaded isn't a simple 
change.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Mark Wedel]

On 06/23/2017 04:56 PM, Rick Tanner wrote:

On 6/23/17 10:02 AM, Matthew Giassa wrote:


Also, has anyone tested how much bandwidth, disk space, etc; the latest
stable release uses under a test load (i.e. a few users/players)?


Disk space needed for (trunk only) source content:

arch = 124M
server = 39M
maps = 549M

After compiling the server:

arch = 124M
server = 163M
maps = 549M

I have some stats in regards to server resources. This is with Ubuntu
16.04 with 6 players running around various maps.


 Disk space (and memory use) is pretty minimal for modern systems - the game 
goes back 20+ years, and while it has grown, it hasn't grown as much computer 
resources has.




From my observations...

crossfire-server requires 30.0 MiB of RAM to run when idle according to
the server host System Monitor.

Each player connected uses an additional ~3 MiB of RAM/ea just to move
around and interact with the game world.

When a player with hundreds (or thousands) of items in their apartment,
guild maps, et al. first enters such a map, RAM utilization jumps
dramatically. At the moment, I don't have a way to quantify these numbers.


 There is a sizeof command you can run, that dumps the sizes of various objects.

IIRC, each object was ~500 bytes (sizes can also vary based on 32 bit/64 bit or 
other factors).  A world map (50x50) perhaps has 5000 objects on it (2/space), 
but pretty easy for apartments or guild halls to easily exceed that.




Each player requires/uses about 10 KiB/s of bandwidth. Some maps with
lots of spell casting and monsters (i.e., Tower of Demonology, Hanuk)
causes this to spike as high as 10MB/s or more while that map or spell
effects are taking place. In a recent test session, I missed tracking
total bandwidth sent and received.

Highest use of CPU appears to be calculating damage from spell effects
(especially comet and meteor) and/or magical attacks (dragons and large
lightning or large ice storm, etc.)


 Yes, this is a problem with how the spells propagate - one spell can easy make 
hundreds or perhaps thousands of objects.  That in itself may not be bad, but 
the insertion of each object and interactions with other objects chews up that 
cpu time.


 The other issue is that the game is only single threaded, so a massive spell 
burst (or loading a big map) slows everything down.  20 years ago, multi cpu 
(now core) systems were pretty rare, now they are commonplace.  However, making 
the server multithreaded isn't a simple change.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Ruben Safir]

everytime someone has done something like that, they have regretted it.

FWIW, our class was considering writing a nueral network for crossfire


On Thu, Jun 22, 2017 at 10:01:20PM -0700, Mark Wedel wrote:
> On 06/22/2017 09:06 PM, Kevin Zheng wrote:
> >Hi there,
> >
> >It has now been 3 years since the last release. Since then we've
> >accumulated a decent amount of fixes and improvements.
> >
> >To make it easier on packagers, and so that more people might benefit
> >from these changes, I propose getting the ball rolling on cutting a new
> >release.
> >
> >If there are no objections I'll get the ball rolling on this next week.
> 
>  No objections from me.  I have to admit that I've gotten
> sidetracked on other projects and really don't spend much time on
> crossfire anymore.  I should probably transfer the admin/ownership
> rights in sourceforge to you or someone else that is more active
> than I am.
> 
> 
> ___
> crossfire mailing list
> crossfire@metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire

-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive 
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[David Hurst]

Hi, I'm currently using a 1.71 build of the gtk client on Windows 10. It
works well with only two issues.

1. The Meta server doesn't work
2. The default numpad key bindings don't work and have to be bound manually.

I'm happy to help bug test a gtk client (and the Java client) for this
release. Given that all of the current clients (1.60?) for Windows are
broken, I think this would be a really important step.

Saru

On 23 Jun. 2017 11:46 pm, "Kevin Zheng"  wrote:

On 06/23/2017 05:37, Rick Tanner wrote:
> Would/could/will the planned release include an .exe version of the GTK
> client for Windows?

It's been a while since I've tried to build the GTK client on Windows,
but I'll remember to give it a shot.

--
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Matthew Giassa]

Would it be worth migrating the project to GitHub, along with a copy of
the HTML, assets, etc; for the real-time.com CF wiki? Issues wouldn't be
migrated, but a more modern VCS could be employed.

Also, has anyone tested how much bandwidth, disk space, etc; the latest
stable release uses under a test load (i.e. a few users/players)? I
don't mind chipping in for an AWS micro install as an alternative to
someone having to dedicate a spare PC or VM as an in-house server. The
biggest problem would likely be maps. Maybe we require users to download
them in advance via apt/yum/tarball?

Finally, who maintains the package currently available via `apt` on
Ubuntu/Debian systems? The Ubuntu page notes that it is Kari Pahula [1].
Is this person a CF dev?

-Matthew

1. "Package: crossfire-client (1.71.0-1.1) [universe]",
  

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Kevin Zheng]

On 06/23/2017 05:37, Rick Tanner wrote:
> Would/could/will the planned release include an .exe version of the GTK
> client for Windows?

It's been a while since I've tried to build the GTK client on Windows,
but I'll remember to give it a shot.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Kevin Zheng]

On 06/22/2017 22:30, Robert Brockway wrote:
> About 18 months ago I sparked a discussion about an expanded Crossfire
> world I was developing.  Well I went away and did that but wasn't
> willing to host it on a VPS (Linode, Digital Ocean) as the size of the
> world made this quite expensive.  So I decided to wait until until my
> home was connected to the Australian National Broadband Network (NBN). 
> Well that's happening on June 29.  So, sometime in the next few weeks
> I'll launch the expanded world running on my NBN link.  I'll update my
> expanded world with the new release before going live with it.
> 
> The expanded world is 1000x1000 maps with the 'old world' (original
> world maps) positioned dead centre at 485-514 on each axis.
> 
> As much as possible I've been automating the world building.  I hope it
> offers different game play to keep people interested.

I think this could offer something to players who want to try something
new. Is the new world compatible with the standard server and client?

I remember some complaints from the Galactic Mileau folks that it was
hard to get recent versions of the client/server running a custom world.
Are there changes that would make this easier for you?

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Robert Brockway]

Sounds exciting.

About 18 months ago I sparked a discussion about an expanded Crossfire 
world I was developing.  Well I went away and did that but wasn't willing 
to host it on a VPS (Linode, Digital Ocean) as the size of the world made 
this quite expensive.  So I decided to wait until until my home was 
connected to the Australian National Broadband Network (NBN).  Well that's 
happening on June 29.  So, sometime in the next few weeks I'll launch the 
expanded world running on my NBN link.  I'll update my expanded world with 
the new release before going live with it.


The expanded world is 1000x1000 maps with the 'old world' (original world 
maps) positioned dead centre at 485-514 on each axis.


As much as possible I've been automating the world building.  I hope it 
offers different game play to keep people interested.


Cheers,

Rob

On Thu, 22 Jun 2017, Kevin Zheng wrote:


Hi there,

It has now been 3 years since the last release. Since then we've
accumulated a decent amount of fixes and improvements.

To make it easier on packagers, and so that more people might benefit
from these changes, I propose getting the ball rolling on cutting a new
release.

If there are no objections I'll get the ball rolling on this next week.

Thanks,
Kevin



___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Mark Wedel]

On 06/22/2017 09:06 PM, Kevin Zheng wrote:

Hi there,

It has now been 3 years since the last release. Since then we've
accumulated a decent amount of fixes and improvements.

To make it easier on packagers, and so that more people might benefit
from these changes, I propose getting the ball rolling on cutting a new
release.

If there are no objections I'll get the ball rolling on this next week.


 No objections from me.  I have to admit that I've gotten sidetracked on other 
projects and really don't spend much time on crossfire anymore.  I should 
probably transfer the admin/ownership rights in sourceforge to you or someone 
else that is more active than I am.



___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Mark Wedel]

On 04/14/10 12:29 PM, Rick Tanner wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 3/31/10 2:01 AM, Mark Wedel wrote:

Just a heads up - I'm targeting weekend of April 10-11 to make a release,
 since I should have time then (certainly won't this weekend)..

 To recap or confirm..

 This will or would be called 1.5 and based on what is currently in trunk?

  Called 1.50, and be based what is in trunk.


 Or is this the final branch roll out of maps  server and client and
 called 1.12?

  No, I think the 1.x branch is basically dead - it hasn't had any significant 
updates, and I don't see much point in making a release knowing 1) it has out 
of 
date content 2) there are no plans to fix it 3) trunk is all that is worked on 
going forward.

  its basically releasing a product that we already know is EOL.



 (client based on SVN R12303 - the confirmed working checkin to work with
 Branch content)

  I think the main thing that breaks the client right now is the lack of newmap 
setup command - that could easily be added simply for backward compatibility 
reasons (and might not be a bad idea until the next release, on the idea that 
by 
then, all servers should have gotten updated, and if they are not going to 
update, the client is going to break sooner or later, so may as well do it 
sooner)


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Kevin Bulgrien]

On Wed, 14 Apr 2010 23:03:04 -0700
Mark Wedel mwe...@sonic.net wrote:

 On 04/14/10 12:29 PM, Rick Tanner wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 3/31/10 2:01 AM, Mark Wedel wrote:
 
 Just a heads up - I'm targeting weekend of April 10-11 to make a 
  release,
  since I should have time then (certainly won't this weekend)..
 
  To recap or confirm..
 
  This will or would be called 1.5 and based on what is currently in trunk?
 
   Called 1.50, and be based what is in trunk.
 
 
  Or is this the final branch roll out of maps  server and client and
  called 1.12?
 
   No, I think the 1.x branch is basically dead - it hasn't had any 
 significant 
 updates, and I don't see much point in making a release knowing 1) it has out 
 of 
 date content 2) there are no plans to fix it 3) trunk is all that is worked 
 on 
 going forward.
 
   its basically releasing a product that we already know is EOL.
 
  (client based on SVN R12303 - the confirmed working checkin to work with
  Branch content)
 
   I think the main thing that breaks the client right now is the lack of 
 newmap 
 setup command - that could easily be added simply for backward compatibility 
 reasons (and might not be a bad idea until the next release, on the idea that 
 by 
 then, all servers should have gotten updated, and if they are not going to 
 update, the client is going to break sooner or later, so may as well do it 
 sooner)

Without countering Mark, I have build scripts that go all the way down to making
RPMs... I'll support you in making a client release compatible with branch if 
you
really want that.  I can see part of the point of having branch for stability, 
but
at some point it seems to detract from CF progress since people are banging on
current development and pointing out issues, making suggestions, etc.

I am, however, in full agreement with Mark regarding server, etc. and I'm not
interested in putting time in on branch for server.  The scripts automatically 
do
assemble maps, etc as was done for prior releases, so its not like I'd have to
spend a lot of time trying to help out on the client, but I don't have the
server builds scripted.

Kevin

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Mark Wedel]

On 04/15/10 08:47 PM, Kevin Bulgrien wrote:

 Without countering Mark, I have build scripts that go all the way down to 
 making
 RPMs... I'll support you in making a client release compatible with branch if 
 you
 really want that.  I can see part of the point of having branch for 
 stability, but
 at some point it seems to detract from CF progress since people are banging on
 current development and pointing out issues, making suggestions, etc.

 I am, however, in full agreement with Mark regarding server, etc. and I'm not
 interested in putting time in on branch for server.  The scripts 
 automatically do
 assemble maps, etc as was done for prior releases, so its not like I'd have to
 spend a lot of time trying to help out on the client, but I don't have the
 server builds scripted.

  Quick thoughts:

  On the client side, a few trivial changes would let the 1.50 (proposed) 
client 
work on 1.12 servers.  I'd rather do that than have both a 1.50 and 1.12 client 
release.

  I believe the main thing that the 1.50 client did was remove some of the set 
up options, on the basis these are now defaults.  Now certainly there is some 
new logic in the 1.50 client which one would not use on a 1.12 server (account 
based, I think the improved spell monitoring, etc).

  Likewise, the 1.12 client should be able to run on latest server without any 
real issues, but also wouldn't be able to use the new features the server 
offers.

  If the concern here is for servers that will spend some time migrating but 
players would be using the latest client, then my preferred solution would be 
to 
make sure latest client works on 1.x branch servers.

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Rick Tanner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/31/10 2:01 AM, Mark Wedel wrote:
 
   Just a heads up - I'm targeting weekend of April 10-11 to make a release, 
 since I should have time then (certainly won't this weekend)..

To recap or confirm..

This will or would be called 1.5 and based on what is currently in trunk?

Or is this the final branch roll out of maps  server and client and
called 1.12?

(client based on SVN R12303 - the confirmed working checkin to work with
Branch content)



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLxhe1hHyvgBp+vH4RAlAsAKCtPeu//VVGR6no6cfYBGk3RYev/gCgyYqS
TO4c8LlI+qRVYZ4jiVBrEQ8=
=npgk
-END PGP SIGNATURE-

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Mark Wedel]

  Just a heads up - I'm targeting weekend of April 10-11 to make a release, 
since I should have time then (certainly won't this weekend)..


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Nicolas Weeger]

   Yes, in the past, usually for a week or two.

   Of course, there is nothing that prevents one from making a branch from
 something other than the latest version.  So if tomorrow, someone made a
 lot of big changes in which you think 'hmmm - I'd like more testing before
 and don't want them in this release', someone could make a branch for 1.50
 from right before that commit.

   That doesn't eliminate the issue of now having two branches to update
 when making a fix (presuming the fix is not related to that commit, but
 something unrelated which needs to be fixed in both releases)

But the project seems to be moving fast lately, so one week could be too 
long ;)


Yes, it's spring!


   In general, complete things that are not completed, and fix bugs.

Considering some are working on quest mechanisms and various scripts, not 
completed can be some weeks or months ;)
Also there's your account system.
And maybe other things.


   That would be good.  I'm never sure about the demand for the server, but
 demand for the client still seems there.

Well, if I have time to make one, I'll make one, anyway :)




Nicolas
-- 
http://nicolas.weeger.org [Mon p'tit coin du web]


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Mark Wedel]

On 03/20/10 12:55 AM, Nicolas Weeger wrote:
 Hello.

Yes, that is the ideal case, especially if there is lots of active
 development.

If there isn't, it is simpler to just freeze the trunk gate for anything
 but bug fixes needed for the 1.50 release.  That way quality can get
 better, without the overhead of a branch, potentially needing to do merges
 (a fix in trunk needing to get in for the 1.50 release or vice versa), etc.

The other thing is we don't typically make patches a release, so the
 branch isn't that useful in that area - instead, we just say it will be
 fixed in the next release.  If we do releases on a regular basis, that
 isn't that bad.


 Well, I can see quite many things in the pipe lately - healthbars being one,
 and other fun things coming.

 So totally freezing trunkmay not be a great idea, or it should be really a
 short time period :)

  Yes, in the past, usually for a week or two.

  Of course, there is nothing that prevents one from making a branch from 
something other than the latest version.  So if tomorrow, someone made a lot of 
big changes in which you think 'hmmm - I'd like more testing before and don't 
want them in this release', someone could make a branch for 1.50 from right 
before that commit.

  That doesn't eliminate the issue of now having two branches to update when 
making a fix (presuming the fix is not related to that commit, but something 
unrelated which needs to be fixed in both releases)



 If we are still thinking of end of march, what should be done right now?

  In general, complete things that are not completed, and fix bugs.


 AFAIK the Windows build works (more or less), so I could produce a version if
 needed.

  That would be good.  I'm never sure about the demand for the server, but 
demand for the client still seems there.  a release of the JXclient should also 
be done (just to make it more readily available).  I'm not quite sure what a 
release of the jxclient means - presumably a precompiled .jar file in one, with 
a source release for the others (similar to how the client has a source 
release, 
as well as some binary packages for specific OS's).  But I'd think in the case 
of the jxclient, that 'binary' release should be platform independent, but I 
could be wrong on that.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Nicolas Weeger]

Hello.

   Call the release 1.50, to note it diverges a bit from the 1.11 release
 (isn't a minor update) but at the same time isn't what we consider 2.0

Fine by me.


   Target release for end of March or so.  Are there any must fix bugs to be
 dealt with?  I hope to have the new account login stuff done soon, but I've
 been saying that for months :(


The recent object_free2() and object_free_drop_inventory() changes could have 
issues.
Not necessarily critical, but some things to keep in mind.


Ideally, we'd make a 1.5 branch on which we'd fix bugs before and after 
release, while works goes on trunk...
But then there are too many branches already :)





   Relative to C client, drop X11 and GTK client, and _only_ support/include
 the gtk2 client.  I believe there are sufficient theme files for the gtk2
 client to cover what in the past were shortcomings (either look of gtk1
 client or need for low resolution support).  Some of this is based on that
 account code above - I don't want to even attempt to add support for that
 to those old clients.

Fine by me.


Nicolas
-- 
http://nicolas.weeger.org [Mon p'tit coin du web]


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Mark Wedel]

On 03/15/10 12:41 PM, Nicolas Weeger wrote:
snip
Target release for end of March or so.  Are there any must fix bugs to be
 dealt with?  I hope to have the new account login stuff done soon, but I've
 been saying that for months :(


 The recent object_free2() and object_free_drop_inventory() changes could have
 issues.
 Not necessarily critical, but some things to keep in mind.


 Ideally, we'd make a 1.5 branch on which we'd fix bugs before and after
 release, while works goes on trunk...
 But then there are too many branches already :)

  Yes, that is the ideal case, especially if there is lots of active 
development.

  If there isn't, it is simpler to just freeze the trunk gate for anything but 
bug fixes needed for the 1.50 release.  That way quality can get better, 
without 
the overhead of a branch, potentially needing to do merges (a fix in trunk 
needing to get in for the 1.50 release or vice versa), etc.

  The other thing is we don't typically make patches a release, so the branch 
isn't that useful in that area - instead, we just say it will be fixed in the 
next release.  If we do releases on a regular basis, that isn't that bad.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Mark Wedel]

On 02/28/10 12:50 PM, Nicolas Weeger wrote:
 Hello.

 What about we just decide to do a release of trunk end of march?
 Whatever it is called, 1.5, 2.0, 1.9, and such :)

 Then let's kill branch, and work on trunk.


 Does that sound ok?

  Just to follow up on this some more and other ideas:

  Call the release 1.50, to note it diverges a bit from the 1.11 release (isn't 
a minor update) but at the same time isn't what we consider 2.0

  Target release for end of March or so.  Are there any must fix bugs to be 
dealt with?  I hope to have the new account login stuff done soon, but I've 
been 
saying that for months :(

  Relative to C client, drop X11 and GTK client, and _only_ support/include the 
gtk2 client.  I believe there are sufficient theme files for the gtk2 client to 
cover what in the past were shortcomings (either look of gtk1 client or need 
for 
low resolution support).  Some of this is based on that account code above - I 
don't want to even attempt to add support for that to those old clients.



___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Mark Wedel]

On 03/ 1/10 05:32 PM, Alex Schultz wrote:
 I haven't been very active with things these days, but I'd be in
 agreement with a release being made. My one reservation is that of
 those options, I wouldn't want it numbered 2.0 since I don't think
 enough has happened to justify that yet.

  Making a release seems like a good idea.  I'm not quite sure what to call it.

  The previous releases were 1.x.y, and x had got up to 11 (1.11.0)

  So 1.5, or even 1.9, don't really work as numbers, since they would be very 
confusing with the 1.5.0 or 1.9.0 release

  I'm not sure if anything too much should be read into version numbers.  Some 
projects cycle through major numbers without it being any big deal, others 
treat 
it as a very serious manner and have criteria for increase in major version.

  We could just jump to 1.20.0, to sort of note that this is a bit different 
than the branch, but still largely compatible with it.  I'd sort of like to 
reserve the major release numbers (2.0, 3.0, etc) to note when compatibility 
really just breaks - eg, moving to 2.0 means you really can't move forward any 
1.x files, 3.x means you really can't use any of the files from 2.x, etc (files 
in this context is meaning existing characters, apartments, etc)

  But even then, exactly how that breaks is somewhat open - if all skills are 
renamed as an example, the files would still be compatible, but the characters 
not really playable as all their skills are gone.  This is different than a 
case 
where the file format actually changes in an incompatible manner.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Kevin Bulgrien]

 Hello.
 
 What about we just decide to do a release of trunk end of march?
 Whatever it is called, 1.5, 2.0, 1.9, and such :)
 
 Then let's kill branch, and work on trunk.
 
 
 Does that sound ok?

Sure - though perhaps my recent inactivity lowers the weight of the vote.

It has gotten to the point where gtk-v2 being incompatible with metalforge is
really annoying - getting bug reports that aren't bugs... though that it not
strictly the issue with killing branch.  It's too bad I ran into RL issues
about the time I was ready to release a snapshot of gtk-v2.  If branch
servers persist, it's annoying enough to probably release a snapshot at the
point just before compatibility was broken, though that seems a drain of
effort that would be best put to other purposes.

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release?

[Alex Schultz]

I haven't been very active with things these days, but I'd be in
agreement with a release being made. My one reservation is that of
those options, I wouldn't want it numbered 2.0 since I don't think
enough has happened to justify that yet.

Alex Schultz

On Sun, 28 Feb 2010 21:50:50 +0100
Nicolas Weeger nicolas.wee...@laposte.net wrote:

 Hello.
 
 What about we just decide to do a release of trunk end of march?
 Whatever it is called, 1.5, 2.0, 1.9, and such :)
 
 Then let's kill branch, and work on trunk.
 
 
 Does that sound ok?
 
 
 
 Nicolas


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Rick Tanner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lalo Martins wrote:
 All right... with the help of crossfire traffic and svn, I compiled a 
 list of what's in the trunk and branch.
 
 http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown

I've added about 10 new points of difference to the wiki page.

During the next couple of days, I will go through all the maps again and
post the any more differences I find between Trunk and Branches/1.x

There are some (infamous) cosmetic changes I've made and will merge back
in to Branch which should not have an impact on functionality.

Lalo - How do things look for the Jan-20th target date?




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJbPGghHyvgBp+vH4RAhwoAKDP6AOKAonS/W7wA4fDpKzS4YhfzwCgpxOD
IXUjgtK7f2FSaYRvBWM4E8U=
=CQzs
-END PGP SIGNATURE-

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Lalo Martins]

quoth Rick Tanner as of Tue, 13 Jan 2009 13:55:12 -0600:
 Lalo Martins wrote:
 http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown
 
 I've added about 10 new points of difference to the wiki page.
 
 During the next couple of days, I will go through all the maps again and
 post the any more differences I find between Trunk and Branches/1.x

Thanks!

 There are some (infamous) cosmetic changes I've made and will merge back
 in to Branch which should not have an impact on functionality.

Oakdoors?  :-)

 Lalo - How do things look for the Jan-20th target date?

Well.  Actually cutting an alpha is about one day's worth of work for me, 
so meeting the target date isn't hard.  The reason I set the date so far 
was, rather, to give other people time to act on it.  If anyone wanted 
some particular changes in the release, or out of the release, they had 
time to speak up.  And I also was hoping to see a decision on whether 
there will be a corresponding code release, although the lack of any 
comments about it does mean there won't ;-) at least not in the same 
timeframe.

I'm not saying the release is easy work, I'm just saying cutting the 
alpha is the easy part.  Then the real work begins -- lots of testing and 
fixing for the March 1st target.

best,
   Lalo Martins
-- 
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
   -
  http://lalomartins.info/
GNU: never give up freedom  http://www.gnu.org/


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Mark Wedel]

Lalo Martins wrote:
 quoth Mark Wedel as of Thu, 08 Jan 2009 22:08:38 -0800:
 Lalo Martins wrote:
 As far as I've seen, the only change that breaks character
 compatibility is the combat rebalance.  So until/unless we hear from
 the code leadership, let's assume the rebalance won't be in the
 release.
   As far as I know, the combat rebalance does not break character
 compatibility - old characters can get loaded and played fine.

   The main issue is that the play experience is radically different, and
 so players not ready/aware of these changes my incur many deaths.
 
 Okay... a few questions, then, as you're the one who knows those changes 
 best :-)
 
 - Won't old characters be excessively strong (or weak) compared to 
 rebalanced ones?  Or will the differences balance out in the bottom line?
 
 - Won't old characters be excessively strong (or weak) when fighting 
 rebalanced monsters?  Or will the differences balance out in the bottom 
 line?

  Most of the rebalancing work was done by modifying archetypes, monsters, and 
some code.

  An old character that was level 100 in 1 handed weapons would still be level 
100.  But the meaning of being level 100 is different - before it might have 
meant a wc of -50, now it might be a wc -20 for example.

  I don't think there are many/any values stored in the player file itself. 
Clearly, the changes to the code will affect everyone.  Changes to the 
archetype 
will affect everyone.

  The issue would be any custom objects on maps that were updated - old version 
could be better.

  And the other issue, as mentioned, is that the old character might log in 
with 
speed of 1.5, wc -50 and weapon_speed of 4.0, but with the rebalance, speed may 
be 1.0, wc -20, weapon_speed 1.5.

  I don't think new vs old character will have any issue - the main difference 
would be play experience is quite a bit different.  A character may be used to 
hacking through monsters at a rapid pace, and not find they move much slower, 
and thus things could be more deadly (it may be that with the rebalance, the 
appropriate level to take on certain monsters is different than before)

  Note that part of the rebalance was a new experience table with slow 
advancement.  If that is made active on old servers, characters may now be in a 
case that they do not have sufficient experience for the level they are, and 
thus lose several levels at login.

  Other changes:
The stats for players is a fixed total instead of a range.  IIRC, this fixed 
total is near the upper end of what the range was before, but not the very top. 
  It does mean that players who were sufficient patient may have gotten higher 
starting stats than are achievable now.

  The other change is generator limits - I believe this was mentioned, but some 
number of maps may need to get updated, as they should have unlimited 
generation 
and break if they don't have unlimited generation.

 
 - Can the changes be easily calculated without human intervention?  If 
 so, I could just write a script to do that.

  As said above, I don't really think there is anything to recalculate (maybe 
exp).

 
 - Do you feel it's worth shipping this in 1.12 without the magic 
 rebalance (which, if you have the time, would follow in 1.13)?  Or is it 
 better to wait and ship both in the same release?

  I'd ship both - otherwise things are unbalanced in various ways.

 
 - How well would the (archetype) rebalance work without the corresponding 
 server changes?  Would it work at all?

  I'm not sure.  One of the server changes was changing how wc for players was 
calculated (it increased really fast before the change).

  As such, the AC of many tough monsters were made worse, to compensate for for 
the lower WC of the character.

  I'm not sure how well things would work.  They would probably work in the 
sense that the server wouldn't crash, but you could have cases where characters 
are unable to hit monsters - the lower attack speeds (in server code) would 
mean 
the comparatively, monsters would be tougher than they were before (other than 
archetype changes, they were not weakened).

  I'd consider such an environment untested/unsupported.  One would have to do 
some actual playtesting I think to see how things work out.

  I did a fair amount of playtesting in that rebalance - this monster seems too 
tough, this not enough, and made various adjustments.  I suspect the biggest 
issue is that many of these adjustments were finely tuned - in general, I tried 
to target a fighter hitting a monster about 25% of the time.  If due to server 
changes, a fighter now hits that same monster 50% of the time, he is now 
hitting 
it twice as often, and monster is that much weaker.

  So based on AC, WC, etc of various monsters, I'm almost say for sure that 
some 
would be considered very easy for the experience they get, and others would 
seem 
very hard because they were adjusted for the new way server calculates things, 
and not the old way

Re: [crossfire] Release 1.12

[Lalo Martins]

All right... with the help of crossfire traffic and svn, I compiled a 
list of what's in the trunk and branch.

http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown

Comments welcome.

As far as I've seen, the only change that breaks character compatibility 
is the combat rebalance.  So until/unless we hear from the code 
leadership, let's assume the rebalance won't be in the release.

It seems a lot of those changes require code changes... as seen on other 
posts to this thread by Leaf and Kevin.

So the question of whether there will be a server 1.12 release becomes 
somewhat important.  If there won't, then it would be better to base the 
content release on the branch, and manually merge each set of changes 
that are compatible.  Significantly more work... but doable.

best,
   Lalo Martins
-- 
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
   -
  http://lalomartins.info/
GNU: never give up freedom  http://www.gnu.org/


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Lalo Martins]

quoth Mark Wedel as of Thu, 08 Jan 2009 22:08:38 -0800:
 Lalo Martins wrote:
 
 As far as I've seen, the only change that breaks character
 compatibility is the combat rebalance.  So until/unless we hear from
 the code leadership, let's assume the rebalance won't be in the
 release.
 
   As far as I know, the combat rebalance does not break character
 compatibility - old characters can get loaded and played fine.
 
   The main issue is that the play experience is radically different, and
 so players not ready/aware of these changes my incur many deaths.

Okay... a few questions, then, as you're the one who knows those changes 
best :-)

- Won't old characters be excessively strong (or weak) compared to 
rebalanced ones?  Or will the differences balance out in the bottom line?

- Won't old characters be excessively strong (or weak) when fighting 
rebalanced monsters?  Or will the differences balance out in the bottom 
line?

- Can the changes be easily calculated without human intervention?  If 
so, I could just write a script to do that.

- Do you feel it's worth shipping this in 1.12 without the magic 
rebalance (which, if you have the time, would follow in 1.13)?  Or is it 
better to wait and ship both in the same release?

- How well would the (archetype) rebalance work without the corresponding 
server changes?  Would it work at all?

best,
   Lalo Martins
-- 
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
   -
  http://lalomartins.info/
GNU: never give up freedom  http://www.gnu.org/


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Rick Tanner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lalo Martins wrote:
 - As suggested earlier on this thread, current trunk will become
   further 1.x releases.  I remind you, that's for content; the
   decision whether or not to do the same wrt server and clients
   will be left to the people who take charge of code.

Going with the assumption that this takes place...

Some sort of clear notification or announcement will need to be included
that that player files and content from 1.11 servers are incompatible
with the 1.12 release.

AFAIK, there are maps in trunk that require (as in will only work
with..) archetypes and server code changes in trunk.  So, migrating just
map(?) content from trunk will likely cause complications or break things.

Or, has this been addressed and I missed such a post?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJY+IDhHyvgBp+vH4RAtVXAKCDSUp3BpWyO8o0yjiDY4GGRiRsPQCg02OY
3sg/X+KKlbK01A8dHkCYTlA=
=5zPj
-END PGP SIGNATURE-

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Lalo Martins]

quoth Rick Tanner as of Tue, 06 Jan 2009 16:58:11 -0600:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Lalo Martins wrote:
 - As suggested earlier on this thread, current trunk will become
   further 1.x releases.  I remind you, that's for content; the decision
   whether or not to do the same wrt server and clients will be left to
   the people who take charge of code.
 
 Going with the assumption that this takes place...
 
 Some sort of clear notification or announcement will need to be included
 that that player files and content from 1.11 servers are incompatible
 with the 1.12 release.
 
 AFAIK, there are maps in trunk that require (as in will only work
 with..) archetypes and server code changes in trunk.  So, migrating just
 map(?) content from trunk will likely cause complications or break
 things.
 
 Or, has this been addressed and I missed such a post?

Maps and arch are content.  The fact that the server ships with 
collected archetypes is a bit confusing there, as is the fact that the 
artifacts, recipes, etc files are in the server tree; I'd like those bits 
of confusion to be cleared up in 2.x.  On the other side, there are 
scripts in maps that can be considered both code and content :-)

Can you make a list, either here or the wiki, of known points where 1.12 
would break backwards compatibility?  I don't mind required that content 
is updated in step, but breaking character compatibility I'd prefer not 
to (last time that happened people were pretty mad, and with 2.0 in the 
horizon... no need to aggravate people too much.)

If we can boil the incompatibility to only the combat rebalance, then I 
suppose I could write a script that fixes characters.  Or we leave the 
rebalance to 1.13 and then include said script.

best,
   Lalo Martins
-- 
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
   -
  http://lalomartins.info/
GNU: never give up freedom  http://www.gnu.org/


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Lalo Martins]

quoth Lalo Martins as of Wed, 07 Jan 2009 00:22:52 +:
 Can you make a list, either here or the wiki, of known points where 1.12
 would break backwards compatibility?  I don't mind required that content
 is updated in step, but breaking character compatibility I'd prefer not
 to (last time that happened people were pretty mad, and with 2.0 in the
 horizon... no need to aggravate people too much.)

Actually, let me rephrase that :-)

Under the premise that current trunk arches and maps will be a 1.12 
content release, I already expressed that I'd like those tested.

I'm now saying that any changes in trunk maps or arches that make 1.11 
characters unusable, with the exception of Mark's rebalance (which we 
don't know yet if we'll include in 1.12), are to be considered bugs and 
reported accordingly.  (Of course, the fix will be simply to not merge 
those changes.)  Anyone who knows about them can report them here, or on 
the tracker, or the wiki.

Content changes that require trunk code are another matter.  I'd like to 
have a list of those if someone who knows about it has the time to 
compile it; but it's unclear whether these are bugs, until the code 
leader decides about a 1.12 code release.

I'll be putting a few hours this week into getting acquainted with all 
differences between trunk and branch content, and I'll do the work above 
alone if necessary, but it will be faster if people already in the know 
can contribute :-)

best,
   Lalo Martins
-- 
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
   -
  http://lalomartins.info/
GNU: never give up freedom  http://www.gnu.org/


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Lalo Martins]

quoth Rick Tanner as of Tue, 06 Jan 2009 20:35:13 -0600:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Lalo Martins wrote:
 
 Content changes that require trunk code are another matter.  I'd like
 to have a list of those if someone who knows about it has the time to
 compile it; snip
 
 One that I am aware of, r10699 through r10701
 
 Re-enable cfpython to change player's title
 
 Allow player dragons to pick metabolism focus in the hallofselection,
 also change player title

LOL guilty as charged... I wrote those!

I have no problem reverting them in 1.12 if there won't be an 1.12 server 
release.

 As far as changes/differences from between trunk and branch from a
 player perspective, a list was started on the wiki:
 
 http://wiki.metalforge.net/doku.php/trunk

Cool, thanks.

best,
   Lalo Martins
-- 
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
   -
  http://lalomartins.info/
GNU: never give up freedom  http://www.gnu.org/


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Klaus Elsbernd]

Hello,

To throw my too cents:
I'm a long time user (since the pre-Mark-area; only debuged the code years ago).
So I would like to speak for those users, which are waiting of a new relase 
since months.
Before making drastical changes to development (c++ implementation...) I would 
like to see a new (complete (?)) stable release, which could be used by us 
players, during the reimplementation.
I think, it wouldn't be a good idea, to rely on svn-access to get a working 
version with all the new features added since the 1.11 almost one year ago.

Klaus

Bis dann
Klaus

-- 
Sure, vi is user friendly.
 It's just particular about who it makes friends with. ;-) 
   _
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH (DFKI GmbH)
Klaus Elsbernd; System Administrator| klaus.elsbe...@dfki.de
Trippstadter Straße 122 | elsbe...@dfki.uni-kl.de
67657 Kaiserslautern; Germany   | Fernruf: 0631/20575-586 Fernbild: -582
Geschäftsführung: Prof. Dr. Wolfgang Wahlster (Vorsitzender), Dr. Walter Olthoff
Vorsitzender des AR: Prof. Hans A. Aukes| Amtsgericht Kaiserslautern, HRB 2313 




pgpRqDSfvcFn2.pgp
Description: PGP signature
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Juha Jäykkä]

  (Maybe there should be a vote on rolling back / not merging the rebalance
  changes.  Personally I love them.  But I've seen some people claim
  they're not finished enough for release.)
 Given that we don't have anyone wishing to coordinate content and maps and
 make them coherent and fun, I have no intention to do massive changes to

Two things. First, I'd like to coordinate, but I don't feel like I'm enough of 
a member of the community here.

Second, I'd like to see a short review of the differences between branch and 
trunk before voicing an option on what Lalo proposed. Also, I thought the 
rebalance stuff would eventually be getting to whatever 2.0 will be - i.e. 
even with the latest discussion about future development, the rebalance would 
still be there. I think the rebalance was a good thing and should not be 
killed off.

-Juha

-- 
 ---
| Juha Jäykkä, juo...@utu.fi|
| home: http://www.utu.fi/~juolja/  |
 ---


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Lalo Martins]

quoth Nicolas Weeger as of Sat, 20 Dec 2008 13:22:50 +0100:
 
 Given that we don't have anyone wishing to coordinate content and maps
 and make them coherent and fun, I have no intention to do massive
 changes to the code, so that question is probably rhetoric :) (unless
 someone else feels like doing such work, obviously)

That's not true... I thought gros was going to do that... if he won't for 
some reason I already said I'll volunteer too.

best,
   Lalo Martins
-- 
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
   -
  http://lalomartins.info/
GNU: never give up freedom  http://www.gnu.org/


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release 1.12

[Nicolas Weeger]

  Given that we don't have anyone wishing to coordinate content and maps
  and make them coherent and fun, I have no intention to do massive
  changes to the code, so that question is probably rhetoric :) (unless
  someone else feels like doing such work, obviously)

 That's not true... I thought gros was going to do that... if he won't for
 some reason I already said I'll volunteer too.

Yann dropped the project. And I didn't know you volunteered :)

To be clear, let me yet again say what I mean by content leader: someone who 
gives the overall gameplay style (fast combat? strategy? much loot?), the 
overall content (medieval fantastic? futuristic?), is willing to decide 
(arbitrarily if needed - and assume this decision against flames sure to come 
by) whether maps fit or not in the game, ensures background stories 
are correct globally, probably sort out gameplay-related feature requests 
and things like that.
To be honest, not some fun part, I'm afraid, but something requires IMO to 
ensure a correct game experience.
(and not saying the content leader must do everything alone - of course other 
people can help, but the content leader is ultimately responsible for the 
global vision of the game)


Nicolas
-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release of 1.11 in a week or two

[Nicolas Weeger]

   There is a difference of something being highly desirable and something
 being strictly required.

   I can think of some number of cases where people may not use the
 metaserver2 for various reasons, and thus don't really want to bother
 downloading what may be extra libraries.

*shrug*
We're talking about Windows version, at least that's the start of the thread, 
and I must say I don't see many people building the client from SVN :)

   There are like 20 different sound mechanisms for linux it seems.  I do
 think openal would be a better long term solution, as it supports more
 advanced sound handling, so instead of the client having to deal with
 mixing, etc, openal would take care of it.

There are maybe many, but we should at least ensure they work under Windows 
and Mac too :)


Nicolas
-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release of 1.11 in a week or two

[Nicolas Weeger]

   It shouldn't be.  It's possible that a few things or other changes were
 outside of #ifdefs.  For both client  server, having curl shouldn't be a
 requirement.

What's the point of metaserver2, then? :)
I think curl is needed, so newer clients use newer servers.

   Having pthread, at least for client, may be, as even for metaserver1
 support, it now uses pthread to get the data from the server in its own
 thread.

   pthread may get used for more stuff - threading the client is an
 interesting idea (one thread to deal with drawing, another for socket) - in
 this way, GUI is always snappy, and the number of locks needed to make this
 happen actually isn't that many.

Actually, pthread is probably harder to get for Windows than curl ;)
And threading the client, what for? I mean, that's not a small task, what is 
the point of threading for now?

   Haven't tried, but see comment about SDL map support getting removed in
 other message.  While I know there is always desire to have as many options
 as available, as the person that has done considerable work with SDL and
 opengl for drawing logic, opengl seems a much better solution (it seems to
 provide many more acceleration options than SDL.  For example, if at some
 point we move lighting effects to the client, opengl has interfaces for
 that.  For SDL, we'd need to write our own lighting routines)

   Now I realize that everyone may not have working opengl, etc, but for
 those people, pixmap mode is still there.

Well, SDL is nice because you can use audio things too, so you get sound 
support. But maybe openal could be used, as another thread mentioned.

Also, if I remember correctly, pixmap does not support alpha transparency, 
which is something it'd be great to have (ok, in a few years / centuries, 
when we have artists...)


Nicolas
-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release of 1.11 in a week or two

[Mark Wedel]

Nicolas Weeger wrote:
   It shouldn't be.  It's possible that a few things or other changes were
 outside of #ifdefs.  For both client  server, having curl shouldn't be a
 requirement.
 
 What's the point of metaserver2, then? :)
 I think curl is needed, so newer clients use newer servers.

  There is a difference of something being highly desirable and something being 
strictly required.

  I can think of some number of cases where people may not use the metaserver2 
for various reasons, and thus don't really want to bother downloading what may 
be extra libraries.

  The configure in the client is supposed to error out if curl is not found, 
but 
there is also an option to bypass that and compile the client without it.  Now 
any ones I compile and official distribute will have metaserver2 support, but 
if 
it isn't hard to remove requirements of certain libraries, then probably not a 
bad thing to do so.

 
   Having pthread, at least for client, may be, as even for metaserver1
 support, it now uses pthread to get the data from the server in its own
 thread.

   pthread may get used for more stuff - threading the client is an
 interesting idea (one thread to deal with drawing, another for socket) - in
 this way, GUI is always snappy, and the number of locks needed to make this
 happen actually isn't that many.
 
 Actually, pthread is probably harder to get for Windows than curl ;)
 And threading the client, what for? I mean, that's not a small task, what is 
 the point of threading for now?

  I didn't say I was going to hop right on it and do it.

  The most basic would be something like what is done right now for metaserver 
- 
have one thread to deal with handling the gui, and another thread to deal with 
taking the data from the socket and figuring out what to do with it.  In this 
way, the gui should always remain responsive even if the client is spending a 
bit of time digesting data from the socket.

  And in retrospect, having the sound stuff done in a separate thread instead 
of 
a separate program would likely have been better.

 
   Haven't tried, but see comment about SDL map support getting removed in
 other message.  While I know there is always desire to have as many options
 as available, as the person that has done considerable work with SDL and
 opengl for drawing logic, opengl seems a much better solution (it seems to
 provide many more acceleration options than SDL.  For example, if at some
 point we move lighting effects to the client, opengl has interfaces for
 that.  For SDL, we'd need to write our own lighting routines)

   Now I realize that everyone may not have working opengl, etc, but for
 those people, pixmap mode is still there.
 
 Well, SDL is nice because you can use audio things too, so you get sound 
 support. But maybe openal could be used, as another thread mentioned.

  There are like 20 different sound mechanisms for linux it seems.  I do think 
openal would be a better long term solution, as it supports more advanced sound 
handling, so instead of the client having to deal with mixing, etc, openal 
would 
take care of it.

 
 Also, if I remember correctly, pixmap does not support alpha transparency, 
 which is something it'd be great to have (ok, in a few years / centuries, 
 when we have artists...)

  opengl also supports alpha transparencies also.

  I won't really dispute that SDL is better than pixmap mode.  I'm just not 
sure 
if both SDL and opengl support really makes sense.  Also, I'd have to look at 
how the SDL code was done - while I know SDL does support alpha transparencies, 
I'm not sure if the implementation done in the client does or not.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release of 1.11 in a week or two

[Mark Wedel]

Kevin R. Bulgrien wrote:
   I'll likely be packing up a release of 1.11 of server/client in a week or 
 two. 
   If you have fixes that you haven't committed yet, please do so.

   Also, if there are any bugs that you see as critical that need to be fixed 
 before the release, please let me know.  There's a fair number of bugs on 
 the 
 tracker, but not clear which are critical and which are not.
 
 On that note, the libglade client is debugged so far as I know...  It would be
 nice to consider releasing it as an indication of its stability and to get it
 in general use.  So far there are a variety of things not backported to 1.x
 in addition to the libglade conversion.  Does anyone know of anything in
 the trunk client that is unsuitable for a general release as a branch
 client?

  IMO, and others may vary, the 1.x branches should really be for bug fixes, 
and 
not new features.

  Also, just recently playing with the glade client, a few issues:

1) Run using opengl mode, get lots of these messages:
(crossfire-client-gtk2:25842): Gdk-CRITICAL **: gdk_draw_drawable: assertion 
`src != NULL' failed

(crossfire-client-gtk2:25842): Gdk-CRITICAL **: gdk_draw_drawable: assertion 
`src != NULL' failed

  I haven't looked into them yet.  I suspect it is something to do with 
mapscroll, as I get them, and only get them, when I move about on the map.  I 
don't see those in pixmap mode.  As a very quick guess, I'm thinking that when 
the client is getting a mapscroll request, it is always trying to scroll as if 
pixmap mode was used.

2) Haven't looked at this either, but just tried with -sdl, and client died 
even 
before getting a log in screen.  But my personal thought is SDL code should 
perhaps be removed.

3) The menubar stuff seems to stop working at times - its not 100% consistent, 
as sometimes I can select the disconnect or quit client and it works, and other 
times, I select those, and nothing happens.

  These are all probably minor issues, but may be things that probably should 
get fixed before making a release of it.

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release of 1.11 in a week or two

[Mark Wedel]

Olivier Huet wrote:
 Hello,
 
 
 Something like a month ago, I did try some minor modifications on the
 windows gtk1 client :
 - make it compile on vs2005 (because I didn't have vs 6 installed anymore on
 my current pc)
 - activate back the sdl support (like it is in on gtk2 client, it's only a
 macro use to add)
 
 But I finally did not post it here when I saw that pthread and curl are now
 needed and mandatory : I couldn't make a patch without compiling it on the
 last svn version.
 
 (BTW I didn't tried thoses but pthread and curl do exists too on windows,
 and pthread do probably works well because it is used in at least one good
 software : the mpeg 4 (h264) decoder of PowerDVD).
 -- I don't have a lot of time these days - not sure if I can find some to
 test those libraries.
 
 
 And still regarding pthread and curl, they looks mandatory now (not always
 bracketed in #ifdef). 
 -- Is it normal ?

  It shouldn't be.  It's possible that a few things or other changes were 
outside of #ifdefs.  For both client  server, having curl shouldn't be a 
requirement.

  Having pthread, at least for client, may be, as even for metaserver1 support, 
it now uses pthread to get the data from the server in its own thread.

  pthread may get used for more stuff - threading the client is an interesting 
idea (one thread to deal with drawing, another for socket) - in this way, GUI 
is 
always snappy, and the number of locks needed to make this happen actually 
isn't 
that many.

 
 
 And I don't know if anyone else did test the gtk2 client on windows but
 personally, the last I did try is something like the 6881 in svn's trunk :
 just before the integration of glade lib. It was on a version I did compile
 with the MinGW. It was working very well and fast with OpenGL.
 
 
 In addition, I forgot to ask here or on bug reports, but on SDL client (both
 gtk 1 and gtk 2 - windows versions), when you click somewhere on the ground,
 SDL do probably catch the focus instead of gtk : after, you can't use any
 key before you switch to another application and go back to the cf client.
 -- is it only in SDL's version in windows, or is it the same on linux or
 other OS ?

  Haven't tried, but see comment about SDL map support getting removed in other 
message.  While I know there is always desire to have as many options as 
available, as the person that has done considerable work with SDL and opengl 
for 
drawing logic, opengl seems a much better solution (it seems to provide many 
more acceleration options than SDL.  For example, if at some point we move 
lighting effects to the client, opengl has interfaces for that.  For SDL, we'd 
need to write our own lighting routines)

  Now I realize that everyone may not have working opengl, etc, but for those 
people, pixmap mode is still there.

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release schedule/notes

[Mark Wedel]

[EMAIL PROTECTED] wrote:

 Other thoughts:  I'd say there is nothing prevent some micro releases of 
 some 
 components between now and then, if a change warrants it.  For example, map
 and archetype changes are quite quick to do and contain perhaps some of the
 more noticable changes to the player, so doing a micro release of those
 between now and then may make sense.  Likewise critical bug fixes in either 
 the server of client would warrant a micro release (1.10.1).
 
 To me, it seems more sane to reserve micro releases solely to bug fixes of
 particular note (affects gameplay significantly or affects security). Generic
 quick changes seem like they wouldn't be worth doing micro releases for 
 really.

  I generally agree.  OTOH, if someone wants to do a release of some component 
to fix some aspects, I don't think there is a big reason to stop them

  OTOH, scheduling has to be done properly - it doesn't make sense to do a 
micro 
release 2 days before the next minor release.

 
 Main trunk releases:
 The server is going under some major changes - I'm not sure it makes sense to
 do releases until that is sorted out.  Just from my experience with the 
 1.10.0 
 release, it would seem that someone could otherwise be spending a lot of time
 getting it so the release aspect of it works, only to have a lot of that work
 go away as files and other paths may change.
 
 Agreed. Also note, in terms of finishing major changes first, though the 
 current
 going code changes are among them, we should also think about gameplay 
 changes,
 think about what frusturates players, and think about how to change the game
 mechanics to improve that. Those things are even more important IMHO to
 warrenting a 2.0 release and we should remember that code restructuring while
 important, is largely so the gameplay changes and features are easier to deal
 with. I suggest in terms of gameplay changes/improvements, before we look at
 things like adding a character creation menu, we should look at things like
 movement/attack speed which are easier to change the algorithm for but require
 greater testing and thought IMHO. (Ok, done drifting off from Mark's topic :))

  Ordering of what to work on is always tricky.  Especially given the volunteer 
nature.

  What I'd put near the top:
- things which hold dependencies (I can't do Y until X is finished, so X should 
be done sooner, not later
- Changes that result in incompatibilities (say different save file format), or 
game play changes that would be hard to fix with script, making it so that the 
only fair thing to do is start with all new characters (changing how exp is 
gained, enchanting objects, etc, could fall into this case, with the older 
characters have a perceived benefit that the new characters can't get)
- Game changes related to balance, as the process of changing those could take 
quite a while (this character too weak at low levels, but too powerful at high, 
etc)

  while changes to gameplay themselves should be done sooner, not later, it 
depends on the change.  In the example of speed/attack speed - in some sense, 
that could be done at any time (even to the 1.x release), the main issue being 
that it could be confusing/misleading to players because they attacked at speed 
X, and now attack at speed X/2 for example, making things more difficult.  This 
sort of falls into the incompatibilies realm, but to a lesser extent.  IT 
probably also falls into the game game changes related to balance - if player 
speed is changed, that changes the balance all around - you couldn't do it late 
in the process.

  And while some cosmetic changes may not make sense, in other cases, it may 
make sense rather than doing two versions of the code.

  For example, if we change the way characters are created (like you get so 
many 
stat points), and even extend it to things like choosing some skills, it 
doesn't 
make a lot of sense to do it once with draw infos, replies, message states in 
the server, and then later, write up the nice GUI for it - in a sense, it is 
less effort to just do that gui while those other changes are going on so that 
code isn't written that is then thrown away.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release schedule: was maps/tags/1.10/

[Mark Wedel]

Kevin R. Bulgrien wrote:


   I also think that less than every 3 months is too long a gap - just 
 looking at 
 the client, there were lots of things changed since the last release, such 
 that 
 if there were 3 releases in that time period, each would still have enough 
 changes to be compelling.
 
 More frequent releases than quarterly for stable releases seems questionable,
 and would propose a tri-annual or bi-annual stable release to better line up 
 with
 major distribution release schedules.

  Ok.  I think bi-annual may be too infrequent, by every 3-4 months is probably 
reasonable.

 
 As far as getting more testers running the code that doing monthly or 
 bi-monthly
 build releases is a good idea (all the way to packaging so that the release 
 process
 itself can be tested).  I only see this possible if the release process is 
 documented
 and scripted as much as possible.  At work, I do releases where I use a 
 document
 and a special make file that does all the tasks between events that need 
 operator
 intervention... using the Makefile as a simple library of things that need to 
 be done...
 a la `make zip`.

  I'm documenting the process as I go along.  What I have so far is at:
http://wiki.metalforge.net/doku.php/crossfire_release_guide

  (I have yet to the server release)

  Some things could perhaps be scripted more than they are done now.  For 
example, I could certainly see a top level script along the lines of 'make 1.11 
release', which goes, does the svn copy (to the right name), and perhaps even 
collects that archetype, maps, and sounds.

  Some of it gets trickier - for example, to make the ChangeLog file appear a 
little nicer, I remove the 'for top of SVN' in the branch - and just have 
'Fixed 
in release 1.10'.  That could perhaps get scripted, but becomes a question of 
whether it is worth the time to try and script it (it may be that the automatic 
script fires up an editor).

  OTOH, automating it too far may be bad.  IT may very well be a case that we 
say we'll do a release on some date, and someone says they'll take care of the 
archs, another says they'll do the maps, etc.

  Aside from splitting the load, there could be other reasons - the person 
doing 
the most work with the arches may be the person that is also doing the release 
- 
this makes sense - he'll know when his changes are in, etc.

  there are also some things just not easily scriptable.  Like for me to build 
the 32 bit rpms, I have to boot my other computer, log in, run the commands, 
etc.  Running the commands to build the RPM is the easy part - it is the other 
steps that take more time.

  In terms of more frequent 'build' releases, I'm not sure how that really 
differs from a normal release.

  If it is a semi private release (not uploaded to sourceforge), it probably 
won't get as widespread testing, and in fact may not get any testing.

  If it does get uploaded to sourceforge, then it basically becomes like a 
normal release - people are going to download that (so better make sure all the 
bugs are fixed in it), etc.  I also think there is some limit on how often you 
can release those and get real feedback.

 
 On that note, I'd like to see a top-level tools directory added to SVN to 
 encourage
 us to put our utility scripts in SVN for others to use.  I worked a bit on a 
 map spell
 checker, for instance, but because it is not good enough to release, it 
 rots in my
 working directory.  Such a directory would be a great place for scripts that 
 could be
 used to manage SVN's bizarre concept of making you either waste disk space or
 have bazillions of individual checkouts.  It would also be wonderful for the 
 release
 process to be supported by scripts in that directory.

  That makes some sense.  But from the description, it seems a little odd.

  If the scripts are not of release quality, there is nothing preventing us 
right now from putting those in something like maps/scripts-nrq (non release 
quality), and then just not include that directory when the data is tarred up.

  That may make more sense than putting them in a top level script directory - 
I 
just have visions of hundreds of scripts there, with no real clue what half of 
them do, and then you start wondering if this or that script should be deleted, 
etc.

  I think it also makes sense to have script dirs in the arch and map 
distribution - there are already a bunch of map checking scripts in the server 
area, but that doesn't make a lot of sense - people don't necessarily know that 
they are there, etc.



___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release of 1.10 soon.

[Andrew Fuchs]

On Sat, 2006-12-30 at 00:26 +0100, Yann Chachkoff wrote:
 I do. I'd like to have enough time to solve at least the following
 bugs before the next release:
  - #1612838 : Problem with item_power code;
  - #1539120 : Talisman of Evocation grants wrong skill;
  - #1528525 : Sometimes bad initial items are created.
 
 I think it would also be nice to wait until #1522796, #1551398,
 #1556723 and #1605033, which are all marked as probably fixed, are
 verified and closed.
 
 Given that a significant amount of bugs can be adressed in a
 relatively short time, and that the GTK2 client as only 5 priority 5
 bugs pending, none of which being overly difficult to solve, I think
 it is best to wait until those are pushed into the Pit of Oblivion
 before making a release. After all, there is no deadline to follow, no
 need to rush something out - so trading one week or two for a cleaner
 result would definitely be a good choice, IMHO.

Agreed, we could put more focus on fixing known bugs, IMO.

-- 
Andrew Fuchs [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release of 1.10 soon.

[Yann Chachkoff]

 I'd like to make a 1.10 release of crossfire sometime soon.  So if you have  
 bugs you're currently fixing, getting those fixes in now would be good.

Hrem, I don't think people keep fixes for ages in their local hard disks before 
submitting them :).

 If you are aware of any unreported bugs, please report them now.  
 If you need time to fix some bugs, please also let me know.

I do. I'd like to have enough time to solve at least the following bugs before 
the next release:
 - #1612838 : Problem with item_power code;
 - #1539120 : Talisman of Evocation grants wrong skill;
 - #1528525 : Sometimes bad initial items are created.

I think it would also be nice to wait until #1522796, #1551398, #1556723 and 
#1605033, which are all marked as probably fixed, are verified and closed.

Given that a significant amount of bugs can be adressed in a relatively short 
time, and that the GTK2 client as only 5 priority 5 bugs pending, none of 
which being overly difficult to solve, I think it is best to wait until those 
are pushed into the Pit of Oblivion before making a release. After all, there 
is no deadline to follow, no need to rush something out - so trading one week 
or two for a cleaner result would definitely be a good choice, IMHO.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire