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

[Kevin Zheng]

On 06/23/2017 15:29, David Hurst wrote:
> 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

Because I didn't compile with Curl.

> 2. The default numpad key bindings don't work and have to be bound manually.

Not sure why this is happening; I might not be able to investigate that.

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

Thanks for offering. I'll do my best to get a Windows build out.

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

[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

[Rick Tanner]

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.

>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

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

[Rick Tanner]

Would/could/will the planned release include an .exe version of the GTK
client for Windows?




___
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

[crossfire] Release proposal

[Kevin Zheng]

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

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090



signature.asc
Description: OpenPGP digital signature
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Crossfire release

[Mark Wedel]

 It's been quite a while since there has been a crossfire release, so it seems 
about time for one.


 So I'm thinking that in a couple weeks time, packing up what is there as a 
release and putting it up on sourceforge.


 There are a few reasons for this announcement:
- If there is code/changes that are ready for commit, it gives you time to get 
those committed (a complaint in the past was someone missing the deadline by a 
few days and has to wait for the next release)


- To be aware of this upcoming release, and _not_ to commit large untested 
changes.  Making a release where the code has had little real world testing 
tends not to be good.


- To focus on bug fixes/stability improvements for the next few weeks.

 Since a couple weeks is vague, I'll just say end of the month.  That does not 
mean the release will happen on March 1, but it could, so just take that as a 
deadline.


 Any concerns, questions, issues, let me know.

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

Re: [crossfire] Crossfire release?

[Mark Wedel]

On 11/14/10 09:19 PM, Mark Wedel wrote:
>
>Been a little more than 6 months since last official release, and I was
> thinking that trying to get one out before end of the year might be nice.
>
>Thoughts/comments?
>
>Any list of bugs or other things that must be fixed before a release is 
> made?
>
>Likewise, any list of the major changes since last release?  Looking at
> changelog can be a little problematic, as it may not be readily apparent from
> the notes whether it is a significant/meaningful change.
>
>I figure release should probably be called 1.51, but could do 1.60 - not 
> sure
> if that makes much difference.

  Got a bit sidetracked on this, but still thinking about getting it out - 
maybe 
in the next week or two.

  In short summary of the things to do or related notes:

call release 1.60
gtk2 client: Change default layout to something else (what?)
Changelog: Keep summary short
verify 1.50/1.60 client/server interoperability
have windows client (who to make?)
remove metaserver1 support (very easy to turn it off, but only 2 servers are 
using metaserver2 right now, despite at least 4 supporting it)




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

Re: [crossfire] Crossfire release?

[Mark Wedel]

On 11/22/10 10:19 AM, Nicolas Weeger wrote:
>>Client too old may be reasonable - at some point, the older clients
>> really will not work.
>>
>>It isn't feasible of course to test every client with every version of
>> the server, and vice versa.  The problem of enforcing versions gets tricky
>> - one does not want to force version 1.60 client with 1.60 release, as
>> everyone with older clients now have to update right then to play.  But I
>> will verify that 1.50 client works properly, and if you are playing older
>> than that, probably time to update.
>
> Seems fine to me.
>
> Note there was a character creation bug that prevented creating new characters
> with some versions...

  I thought I had checked that, but apparently I missed it.


>>Is that suggesting that maybe the java client should be the official
>> windows client.
>
> Is that a question? :)
>
> No, I'm not suggesting anything.
> But I admit to not having much interest in trying to build the GTK client
> under Windows.

  My take is that not many of the crossfire devs are particularly active 
developers on windows, which is why the glade/gtk issue persist.

  Java (in theory) is very cross platform, so can make for easy client for 
windows, mac osx, or anything else that can run java.

  A java client release (meaning posted to the sourceforge crossfire site) 
should probably be done to make it more known.


>>Discussion of that probably gets beyond this message - but some of that
>> also goes into gameplay and other aspects - I certainly think it would be
>> good to have the recipe chains for alchemy be such that one could, through
>> alchemy, reasonably get high experience (this would involve making the
>> basic recipes much more easy to find or perhaps common knowledge (eg, each
>> time you gain a level in alchemy, you learn a recipe for that level).
>>
>>The hard part IMO for quest chains/skill leveling is ideally, you want
>> the process of completely the quest to use the skill in question - having
>> an alchemy type quest which is to get the liver of the boss monster at a
>> bottom of a dungeon is fine, but one really isn't using alchemy (most
>> likely) to solve that quest.  A few of those may be reasonable, but I just
>> get the feeling that if too many are about, it might start to feel
>> somewhat artificial.
>
> Or have a quest in which you need to create via alchemy some specific item,
> requiring you to have a minimum alchemy level. Item that can't be traded, or
> just don't care if a player gets it from someone else.

  Or even quests/maps in which various materials are available (in chests, 
monster drops, etc) which allows one to use alchemy to make potions, bombs, etc 
to defeat some monsters - at least in that case, alchemy can be used to 
complete 
the quest.  A character could use other skills (and not use alchemy at all), 
but 
at least alchemy could be used heavily, so it makes more sense to get alchemy 
experience.

  It would perhaps also be interesting that if one makes a device through 
alchemy (dust as an example) and uses that dust to kill creatures, may some 
portion of that experience should go to alchemy.  Not sure how to do it all, 
and 
it probably has to be limited to the character that created the dust also using 
it.  But in a sense, you are putting your skill to the ultimate test there.

>
>
>>Yes, but I'd almost be tempted that if redoing/adding a lot of graphics
>> get looked at, having an larger image set (64x64 base lets say) would be
>> nice, but that probably gets into the dreamworld below.
>
> I'd suggest either some vector-based solution, or why not 3D models - at 64x64
> for base tiles, I hope you can start to do nice things :)

  From having done this a few times (bitmap to xpm conversion, 24x24 to 32x32 
conversion), being able to populate the entire new image set is a big plus - in 
this case, that would mean having all images available as 64x64 images, even 
though they are just scaled up 32x32 images.

  Now at that point, how to clean those up is another question - for some 
number 
of images, probably just doing manual cleanup is fine.

  For some, it may be making a 3d model or other basis, and then doing 
manipulations on that and saving in 64x64 image may be best.  For something 
like 
some characters and monsters, making the 3d model which you can then rotate for 
the 8 different directions as well as do basic animation (moving arms/legs) may 
be a lot easier than actually drawing all those images by hand (but not having 
done much with 3d models, can't really say myself)

  For others, doing vector graphics and saving/converting those to 64x64 png 
images may make sense (for non animated objects that also wouldn't have any 
rotation, this may make sense - things like floors, walls, even fair number of 
items).

  Now at some point, things may be such that there are 100 3d models in the 
arch 
tree, and it then makes a lot more sense to send those models and have

Re: [crossfire] Crossfire release?

[Nicolas Weeger]

>   Client too old may be reasonable - at some point, the older clients
> really will not work.
> 
>   It isn't feasible of course to test every client with every version of
> the server, and vice versa.  The problem of enforcing versions gets tricky
> - one does not want to force version 1.60 client with 1.60 release, as
> everyone with older clients now have to update right then to play.  But I
> will verify that 1.50 client works properly, and if you are playing older
> than that, probably time to update.

Seems fine to me.

Note there was a character creation bug that prevented creating new characters 
with some versions...




>   Is that suggesting that maybe the java client should be the official
> windows client.

Is that a question? :)

No, I'm not suggesting anything.
But I admit to not having much interest in trying to build the GTK client 
under Windows.


> I haven't looked, so I don't know how easy/hard it would
> be to take the glade file and make the static config file (old method) -
> while less than ideal, if there are issues with windows, that may be one
> approach.

Or find a decent libglade version, I think there exists builds for it.


>   Should perhaps metaserver1 support also get removed from server at same
> time? In that way, the client at least has to be know enough to support
> metaserver2 to play on newer servers (probably not much difference there,
> since that support has been there a while).

Sure. Let's clean old code.



>   Discussion of that probably gets beyond this message - but some of that
> also goes into gameplay and other aspects - I certainly think it would be
> good to have the recipe chains for alchemy be such that one could, through
> alchemy, reasonably get high experience (this would involve making the
> basic recipes much more easy to find or perhaps common knowledge (eg, each
> time you gain a level in alchemy, you learn a recipe for that level).
> 
>   The hard part IMO for quest chains/skill leveling is ideally, you want
> the process of completely the quest to use the skill in question - having
> an alchemy type quest which is to get the liver of the boss monster at a
> bottom of a dungeon is fine, but one really isn't using alchemy (most
> likely) to solve that quest.  A few of those may be reasonable, but I just
> get the feeling that if too many are about, it might start to feel
> somewhat artificial.

Or have a quest in which you need to create via alchemy some specific item, 
requiring you to have a minimum alchemy level. Item that can't be traded, or 
just don't care if a player gets it from someone else.


>   Yes, but I'd almost be tempted that if redoing/adding a lot of graphics
> get looked at, having an larger image set (64x64 base lets say) would be
> nice, but that probably gets into the dreamworld below.

I'd suggest either some vector-based solution, or why not 3D models - at 64x64 
for base tiles, I hope you can start to do nice things :)



>   I suspect that within maps which do set item power, it hasn't been done
> consistently accross the board - mapmaker A's maps are consistent, but
> mapmaker B may use a higher basic item power than A.

Yup.
So a whole revision of that is in order. As well as for artifacts.





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


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] Crossfire release?

[Mark Wedel]

On 11/20/10 01:04 AM, Nicolas Weeger wrote:
> Hello.
>
>
>>Been a little more than 6 months since last official release, and I was
>> thinking that trying to get one out before end of the year might be nice.
>>
>>Thoughts/comments?
>>
>>Any list of bugs or other things that must be fixed before a release is
>> made?
>
>
> Things to fix for the next release:
>
> - ensure all clients versions are either disconnected with a "client too old"
> message or able to create account or at least characters on latest server

  Client too old may be reasonable - at some point, the older clients really 
will not work.

  It isn't feasible of course to test every client with every version of the 
server, and vice versa.  The problem of enforcing versions gets tricky - one 
does not want to force version 1.60 client with 1.60 release, as everyone with 
older clients now have to update right then to play.  But I will verify that 
1.50 client works properly, and if you are playing older than that, probably 
time to update.

>
> - have an official Windows client ; if GTK should be it, actually build and
> package it (last tests I made showed issues with Glade library)

  Is that suggesting that maybe the java client should be the official windows 
client.  I haven't looked, so I don't know how easy/hard it would be to take 
the 
glade file and make the static config file (old method) - while less than 
ideal, 
if there are issues with windows, that may be one approach.

  I personally do not have a windows dev environment - that is of course one of 
those things that always makes things harder to work for.

>
> - remove metaserver1 support from clients, so players don't go to old obsolete
> servers

  Should perhaps metaserver1 support also get removed from server at same time? 
  In that way, the client at least has to be know enough to support metaserver2 
to play on newer servers (probably not much difference there, since that 
support 
has been there a while).


> Things to fix someday:
>
> - add more quests, link maps or stories ; this would give players some hints
> on what to do or point to maps they don't know

  Yes - one other thought I've had, and which many other games do, is have some 
form of achievements/titles.  These may not have any actual in game effect, but 
to some extent let a player track what they have done.  Eg, kill 1000 demons 
and 
you get the demon slayer title.  Maybe remove the custom title currently in the 
game, and only let player set their titles to ones they have earned.

>
> - make enough quests to nicely level in various skills (eg suite of alchemy-
> related quests enabling the player to learn recipes and level up)

  Discussion of that probably gets beyond this message - but some of that also 
goes into gameplay and other aspects - I certainly think it would be good to 
have the recipe chains for alchemy be such that one could, through alchemy, 
reasonably get high experience (this would involve making the basic recipes 
much 
more easy to find or perhaps common knowledge (eg, each time you gain a level 
in 
alchemy, you learn a recipe for that level).

  The hard part IMO for quest chains/skill leveling is ideally, you want the 
process of completely the quest to use the skill in question - having an 
alchemy 
type quest which is to get the liver of the boss monster at a bottom of a 
dungeon is fine, but one really isn't using alchemy (most likely) to solve that 
quest.  A few of those may be reasonable, but I just get the feeling that if 
too 
many are about, it might start to feel somewhat artificial.

>
> - many more compound graphics - create a Fenx character, and use singing,
> fight, cast magic, do the same for other races and classes

  Yes, but I'd almost be tempted that if redoing/adding a lot of graphics get 
looked at, having an larger image set (64x64 base lets say) would be nice, but 
that probably gets into the dreamworld below.

>
> - fix many broken monsters (hint: ac<-70 will make the monster almost
> invulnerable in melee), balance exp/sp/hp/gr and such

  Yes - those should get fixed.

>
> - fix various Python guild bugs and issues
>
> - fix item_power ; some items are more powerful than others with less
> item_power (eg some rings, I think) ; also item_power is almost useless once
> you reach level 50, so spread the scale more

  Some of the idea behind item power was to prevent high level characters from 
giving low level characters really great items, so fact it becomes less 
relevant 
at higher levels would be less a concern.

  But the real problem behind it is that for probably 99% of the items, it is 
computed by the server, and it can only make general assumptions on value - 
certainly some attacktypes are better than others, as are protections.

  I suspect that within maps which do set item power, it hasn't been done 
consistently accross the board - mapmaker A's maps are consistent, but mapmaker 
B may use a higher basic item power than A.

>

Re: [crossfire] Crossfire release?

[Nicolas Weeger]

Hello.


>   Been a little more than 6 months since last official release, and I was
> thinking that trying to get one out before end of the year might be nice.
> 
>   Thoughts/comments?
> 
>   Any list of bugs or other things that must be fixed before a release is
> made?


Things to fix for the next release:

- ensure all clients versions are either disconnected with a "client too old" 
message or able to create account or at least characters on latest server

- have an official Windows client ; if GTK should be it, actually build and 
package it (last tests I made showed issues with Glade library)

- remove metaserver1 support from clients, so players don't go to old obsolete 
servers



Things to fix someday:

- add more quests, link maps or stories ; this would give players some hints 
on what to do or point to maps they don't know

- make enough quests to nicely level in various skills (eg suite of alchemy-
related quests enabling the player to learn recipes and level up)

- many more compound graphics - create a Fenx character, and use singing, 
fight, cast magic, do the same for other races and classes

- fix many broken monsters (hint: ac <-70 will make the monster almost 
invulnerable in melee), balance exp/sp/hp/gr and such

- fix various Python guild bugs and issues

- fix item_power ; some items are more powerful than others with less 
item_power (eg some rings, I think) ; also item_power is almost useless once 
you reach level 50, so spread the scale more



In a dreamworld:

- better unique map or unique spots modification handling (merge changes to 
initial map with the saved map) ; makes it easier to change guilds

- handle many more errors ; flat out refuse to open maps containing some 
invalid item

- enable people to use the arch directory from svn without collecting process, 
or just put their .arc or .png files in a correct directory for it to be used

- enable archetypes, treasures, formulae, etc. reloading while server is 
running

- limited threading for map or player loading and saving, to not lock the 
server with big maps ; or progressive loading/saving, whichever



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


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] Crossfire release?

[Mark Wedel]

On 11/16/10 08:24 PM, Kevin R. Bulgrien wrote:


> IMO, it is time to ditch gtk-v2.glade as the default.  It is becoming a
> not so uncommon event for a new user to come on IRC and have fits
> getting the important window panels to show up (inventory in particular).
> I've had one disappear off IRC after trying hard to help with little success.
> I'd personally rate this pretty much a necessity.  Maybe dealing with that
> should be a different thread though.

  I have no issue changing the default to something that is easier to use/works 
for a larger number of users.

>
> I did work to fix the caching of hosts in the metaserver dialog, but there
> is a bug still left. Somehow the cache list displayed isn't quite right.  I
> haven't followed up to find out what's wrong yet.
>
> I'd like to rework the new dialogs.  They do not match the style of the
> other dialogs, and, IMO, with apologies to the designer, ugly.  It is not
> necessary to do so, but already that client has a reputation for its not
> so elegant looks.

  I know many of the new dialogs would need some work.  I was also caught 
somewhat in not quite knowing the best/correct size for them - some of the 
windows would be much better if they were larger (descriptions are scrunched in 
small area), but at same time, I didn't want to make the windows too large to 
work on low res displays - I'm not sure what the minimal display resolution we 
target currently is.


> As for ChangeLog, I've personally taken to heart an IRC conversation about
> that document.  I have started only logging things there that seem likely to
> be of end-user interest., and to allow the SVN log to serve as the technical
> change log.

  That may be a different discussion - I missed the IRC conversation, but what 
is really recorded in the changelog could become just significant changes, and 
minor bug fixes not recorded there.

  I suppose I just followed the format of most projects where everything is 
recorded in the ChangeLog to high detail, but some are much more general.

  One concern I do have about that is to make sure comments recorded for the 
actual changed files be meaningful.  Having a comment in the svn log like 'bug 
fix' is pretty useless - I'd much rather have the description be something like 
'fix possible null pointer reference '.  I only bring this up because in 
many cases, the same entry in the Changelog is what is used in the files.


> Music is working in GTK-V2 though there is no mechanism to deliver music
> with the client.  I think some work needs to be done to at least define a
> system-wide location for music and a user-specific location for music.
> We also have no infrastructure set up to distribute media either.  Not
> sure its worth making a big deal about the new feature at this point.

  I suspect music will be like sounds - distribution will be in tar 
files/rpms/whatever.  That said, any music files we have should get committed 
to 
SVN so they can be distributed.

  I suspect that music files will change infrequently enough that such a 
distribution method works fine.  But if something more frequent was needed (say 
you add several new song files and don't want to wait for next official release 
that may be 6 months away), packing up a new tar archive with the new files and 
calling it a .1 release or something would probably be fine.


> Sound/Music may eventually need with respect to possibly fixing old
> .crossfire folder content, but then maybe one needs to just ditch the
> legacy files rather than try convert them to the new system.  (The old
> system was severely broken as it used hard-coded absolute paths that
> could single-handedly disable sound if changes occurred upstream.)

  I have no issues disabling/breaking old stuff if there is a good replacement 
- 
in fact, I'd rather ditch legacy stuff than adding bits of code to try and keep 
it functional.

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

Re: [crossfire] Crossfire release?

[Rick Tanner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/16/10 10:24 PM, Kevin R. Bulgrien wrote:
> I don't really know of any serious stability
> reports out there, though some users seem to be confused by the
> account / character setup dialogs.

I've been working on the walk though for the new account setup, progress
so far is located at:

http://crossfire.real-time.com/guides/character/summary.html


> Probably don't want to go in such big hops as to get to 1.100+ is all I have 
> to add to that.  On one hand the client changes are significant.  On the 
> other,
> without a corresponding server release, its probably a bit weird to go
> jumping the client by leaps and bounds.

In the past, (can't recall the exact release..) having server release
number differ from client release number created new confusion in
regards to compatibility of one with the other.  So, from that point,
we've tried to keep all the release numbers the same.



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

iD8DBQFM5HvOhHyvgBp+vH4RApMPAKCbhm/s5CovgLbmUsCfgrJSlLHDfACfaPW4
TBglFcPmWguQlWsoYLyRMMU=
=OUGY
-END PGP SIGNATURE-

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

Re: [crossfire] Crossfire release?

[Kevin R. Bulgrien]

>   Been a little more than 6 months since last official release, and I was
> thinking that trying to get one out before end of the year might be nice.
> 
>   Thoughts/comments?

1.50.0 is broken.  One cannot create a new character due to a .glade file
bug.  A release is needed.  Technically, a 1.50.1 could consist of a new
dialogs.glade file only.  The fix is in SVN already, but, I think I'd prefer to
see a general release since so much time has passed.

Yes, getting one out would be nice to hit a new round of distribution hits
to replace the broken client.  I don't really know of any serious stability
reports out there, though some users seem to be confused by the
account / character setup dialogs.
 
>   Any list of bugs or other things that must be fixed before a release is
> made?

One place where stuff is recorded is:

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

#2938902 crossfire-client-gtk2 has get/take errors
https://sourceforge.net/tracker/?func=detail&aid=2938902&group_id=13833&atid=113833

There are a few others in the tracker too... though I'm not sure how
significant they are.  I think a fair number of them are Windows
client issues, but this one is one I run into.

IMO, it is time to ditch gtk-v2.glade as the default.  It is becoming a
not so uncommon event for a new user to come on IRC and have fits
getting the important window panels to show up (inventory in particular).
I've had one disappear off IRC after trying hard to help with little success.
I'd personally rate this pretty much a necessity.  Maybe dealing with that
should be a different thread though.

I did work to fix the caching of hosts in the metaserver dialog, but there
is a bug still left. Somehow the cache list displayed isn't quite right.  I
haven't followed up to find out what's wrong yet.

I'd like to rework the new dialogs.  They do not match the style of the
other dialogs, and, IMO, with apologies to the designer, ugly.  It is not
necessary to do so, but already that client has a reputation for its not
so elegant looks.

FWIW, I'd also like to rework the main windows the same way I did the
dialogs.  I think that would help people find the resize bars more
easily.  Not critical, but might alleviate issues with gtk-v2.glade
somewhat.

>   Likewise, any list of the major changes since last release?  Looking at
> changelog can be a little problematic, as it may not be readily apparent
> from the notes whether it is a significant/meaningful change.

As for ChangeLog, I've personally taken to heart an IRC conversation about
that document.  I have started only logging things there that seem likely to
be of end-user interest., and to allow the SVN log to serve as the technical
change log.

An important fix for the client is that it should handle backslash vs slash
delimited paths properly now when built on windows.

Dynamic resize of spells dialog is added.  This is pretty significant.  A
great deal of effort went into populating all the spell help, and the text
reflow capability means the dialog is much more useful on a variety of
desktop environments.

The client has preliminary support for Spellmon 2 (spells that require
ingredients), but ingredient listing is not end-user visible at this time.

The client now has a 30 second timeout instead of a 3-4 minute lockup
if a connection attempt is made to a host/port that does not have a
listening server.  (Probably 30 seconds is still too long...)

Issues with [X] close of dialogs has been improved and segfaults under
some window managers are prevented.  Delete events are now trapped
and ignored to prevent dialogs from disappearing and requiring a client
restart to correct the situation.  I wonder if the most recently added
dialogs are in need of the same fix applied to the account system dialogs.

Music is working in GTK-V2 though there is no mechanism to deliver music
with the client.  I think some work needs to be done to at least define a
system-wide location for music and a user-specific location for music.
We also have no infrastructure set up to distribute media either.  Not
sure its worth making a big deal about the new feature at this point.

Sound effects are not done at this point, but the infrastructure is technically
operational as I can play sound effects in a tweaked development work
space, but the server-to-client link is not complete.  I think some factoring
 needs to be done to get a reasonable implementation.  All the points made
about music are pretty much also true for sound effects.

Sound/Music may eventually need with respect to possibly fixing old
.crossfire folder content, but then maybe one needs to just ditch the
legacy files rather than try convert them to the new system.  (The old
system was severely broken as it used hard-coded absolute paths that
could single-handedly disable sound if changes occurred upstream.)

Even with the incomplete implementation, cfsndserv and friend should be
release-safe.

>   I figure release should probably be 

Re: [crossfire] Crossfire release?

[Rick Tanner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/10 11:19 PM, Mark Wedel wrote:
> 
>   Been a little more than 6 months since last official release, and I was 
> thinking that trying to get one out before end of the year might be nice.
> 
>   Thoughts/comments?

There has been a number of changes and updates to make a release
necessary, IMO.

Would prefer to see a release where the ChangeLog is not a dozen pages
or thousands of lines of summary text. ;-)

>   Likewise, any list of the major changes since last release?  Looking at 
> changelog can be a little problematic, as it may not be readily apparent from 
> the notes whether it is a significant/meaningful change.

I have the SVN Traffic page updated from Nov-2010 back to Sept-2010, so
about half way there.  Another set of eyes to confirm, clarify and
update information so far is always welcome.

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

One major change is the new character creation method.  Also some new
maps, improvements on existing maps, lots of sound related & support
changes in the gtk-v2 client.  Number of updates in the JXClient as well.






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

iD8DBQFM4zEvhHyvgBp+vH4RAlP+AKCJTAIAlMHAci9zjeq/DlMk+AIT8QCgwaEs
GgwForc45sNgIt9AaeARyQs=
=yWEW
-END PGP SIGNATURE-

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

[crossfire] Crossfire release?

[Mark Wedel]

  Been a little more than 6 months since last official release, and I was 
thinking that trying to get one out before end of the year might be nice.

  Thoughts/comments?

  Any list of bugs or other things that must be fixed before a release is made?

  Likewise, any list of the major changes since last release?  Looking at 
changelog can be a little problematic, as it may not be readily apparent from 
the notes whether it is a significant/meaningful change.

  I figure release should probably be called 1.51, but could do 1.60 - not sure 
if that makes much difference.


___
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?

[Kevin Bulgrien]

On Wed, 14 Apr 2010 23:03:04 -0700
Mark Wedel  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/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?

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

>   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 :)


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

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



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:

>>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?

[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 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?

[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  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?

[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

[crossfire] Release?

[Nicolas Weeger]

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

[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

[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 c

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

[Mark Wedel]

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

  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.


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

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

[Kevin Bulgrien]

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

Content changes include various maps that use cfdialog.py/npc_dialog.py.
Of special note, the mork/gork quest is no longer able to be done by simply
knowing the right words (the character has to perform the in-game conversation
that tells them the things they need to do).  Other maps would include
newbiehouse, and a variety of maps associated with the witherspoon manner
ghost-body hunt.  I think that might be it... but I do have some content that
is npc_dialog.py based that is under development, and intended for addition
to trunk.

Since cfdialog/npc_dialog.py make it possible for a mapmaker to create (mini)
quests using stored flags in the player file.  Its not particularly nice that
the status of the quests is not checkable, nor that it is easy to write them
stupidly, but... it was a dramatic improvement on what branch had via the
match system.

Kevin


___
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:
> 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; 

More searching and comparing. I'm not sure if this requires trunk code
or not..

NPC dialog that uses @question

Example map, /brest/taverns/brest.seaside.tavern


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

iEYEARECAAYFAklllE0ACgkQhHyvgBp+vH49iACbBeVhZDZ48+cwBhsOZnlkkz8/
D48AoPBd6aMTApszd08tVGbzYjxuA4Aj
=xskb
-END PGP SIGNATURE-

___
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:
> 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; 

As I (re)discover or remember the differences, here's some more.

Monster generator limits (i.e., generator_limit 10)

scorn/houses/resir
houses/easy_house.1.c
misc/beginners
scorn/temples/valkyrie2
scorn/misc/beginners2
start/newbieshouse

Maps where monster population and stats (lower AC, reduced Wc) are
designed for the combat system in trunk:

/quests/saromok/*
darcap/pygmy_forest/*

The Fun Zone maps, I'm not sure if there is anything with those maps;
they need a closer look.

darcap/darcap/circus/fz_*



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

iEYEARECAAYFAklkRzoACgkQhHyvgBp+vH5tfACg9cFz+FOYO9P0RseSNKVMN5sv
M0cAn2HukmcwKNhBt8iVzMdtSgToUQhH
=O1w1
-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 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; 
> 
> 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

[Rick Tanner]

-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; 

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

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


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

iD8DBQFJZBThhHyvgBp+vH4RAn/rAKC0QC1HjtC838opw3A8VjCBpj4bhQCgh8pQ
Dju7cLN3i3p6Q33kjD1V1wE=
=uKdv
-END PGP SIGNATURE-

___
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 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

[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 Lalo Martins as of Mon, 22 Dec 2008 14:24:28 +:
> :-) let's make it official then.  If nobody objects until 2009, I hereby
> proclaim myself "content leader".

Well.  I've seen discussions about the fine points of my plans, but no 
objections to my proclamation proper.  So I'm assuming the post as of 
today.  I'd strongly suggest someone (*cough*) do the same for the 
code... potentially, if you prefer, different people for client and 
server (I think it's pretty clear who those would be today).

Here are my first acts and plans as content leader:

- Codename "rebootworld" will progress at whatever speed I'm able
  to implement it, as outlined in the "attack plan" thread, with
  the target of being the official content for 2.x.

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

- I'll be using launchpad for release planning and stuff.  Feel
  free to use it too.  It's not really worth the trouble to move
  bugs from sourceforge to malone for 1.x, especially since
  launchpad is more than able to integrate with sf bugs; but I'll
  use malone for 2.x (which is a separate project on launchpad).
  For "blueprints", the best is still the metalforge wiki; again,
  launchpad is able to link and integrate those in its process.

  (The 2.x "attack plan" has already been entered in the form of
  launchpad milestones, coded "drs" for Developer Release -
  Scorn.  It's still unclear how much content constitutes a
  "releaseable" 2.0; offhand I'd say three kingdoms.)

- By January 20th I'd like to merge all trunk changes that are
  sufficiently tested into branch and cut a RC1.  Since I haven't
  been following everything that happened in the last year and a
  half, I kindly ask people to tell me which changes are known
  good, which are known bad, and the rest we'll make an effort to
  test in this time window.

- After the RC please test thoroughly and report any bugs; I'd
  like us to have a clean release.

- There may be an RC2 and even if necessary an RC3 in February.

- Between January 20th and whenever the 1.12 release happens, the
  branch is to be considered bugfixes only.

- The 1.12 release is planned for March the 1st.  That may be a
  pipe dream but I intend to make it happen.

- I think the great 1.12 question is: do mwedel's rebalances go
  in or not?  Assuming he does have time to do the magic
  rebalance, will we have enough time to test it?  If we don't,
  or if he doesn't, should we release combat rebalance without
  its magic counterpart?  Personally I'd like them in 1.12, but
  if the people who have played with it more (especially mwedel
  proper) think it's not mature enough, I wouldn't mind waiting
  for 1.13.

  (For those confused: the changes were mainly to archetypes, so
  yes, they do go in the content release.)

- After the release, the 1.x flow should be: radical new features
  or major changes in a "feature branch", somewhat experimental
  or in-progress new features or major changes in trunk, bugfixes
  in the branch; new features and major changes to be integrated
  from trunk to branch as they're tested and deemed stable.

- I'd like to put out two 1.x releases per year until about a
  year after 2.0 happens.  (By which time if anyone else wants to
  go on maintaining 1.x I won't object.)  Early February and
  early August should get us into Ubuntu and Fedora releases, so
  that's what we'll be aiming for from 1.13 on.

- Of course if server and client do *not* decide to cut 1.x
  releases out of trunk, it will be part of my job to make sure
  these content releases are compatible with whatever server
  versions are available at the time.

What I shall *not* be doing for 1.x is deciding whether new
content is consistent, fits the story, etc; or quality.  New
content will be checked for balance and whether it fits the place
where it's located.  Changes to existing content, of course, are
expected to make it better than before. ;-)

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]

> quoth Nicolas Weeger as of Mon, 22 Dec 2008 08:39:42 +0100:
> > Yann dropped the project. And I didn't know you volunteered :)
>
> I told him, and Alex, and I thought I told you too, but maybe I
> didn't :-) let's make it official then.  If nobody objects until 2009, I
> hereby proclaim myself "content leader".

Well, I may have missed that, then :)
Could you describe what kind of game you want to make? So people know what to 
expect from you! ^_-

> It's fun for me... yeah maybe I'm weird... but that's the part that
> appeals to me.  More than coding, more than actually editing maps, heck
> even more than playing.


Well, fine then :)

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 1.12

[Lalo Martins]

quoth Nicolas Weeger as of Mon, 22 Dec 2008 08:39:42 +0100:
> Yann dropped the project. And I didn't know you volunteered :)

I told him, and Alex, and I thought I told you too, but maybe I 
didn't :-) let's make it official then.  If nobody objects until 2009, I 
hereby proclaim myself "content leader".

> To be honest, not some fun part, I'm afraid, but something requires IMO
> to ensure a correct game experience.

It's fun for me... yeah maybe I'm weird... but that's the part that 
appeals to me.  More than coding, more than actually editing maps, heck 
even more than playing.

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

[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 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

[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

[Nicolas Weeger]

Hello.

> I'd like to propose that, before we set off on major rewrites, we
> officially give up on the previous 2.0 effort, and release what's
> currently on trunk as 1.12.  (Which probably means either merge the
> branch, or abandon it and just use trunk...)
>
> There are major improvements on trunk, notably an actually usable gtk
> client; since trunk is no longer going to be the basis for 2.0, there's
> no point sticking to the 1.x branch any longer.
>
> (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 the 
code, so that question is probably rhetoric :)
(unless someone else feels like doing such work, obviously)

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

[crossfire] Release 1.12

[Lalo Martins]

I'd like to propose that, before we set off on major rewrites, we 
officially give up on the previous 2.0 effort, and release what's 
currently on trunk as 1.12.  (Which probably means either merge the 
branch, or abandon it and just use trunk...)

There are major improvements on trunk, notably an actually usable gtk 
client; since trunk is no longer going to be the basis for 2.0, there's 
no point sticking to the 1.x branch any longer.

(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.)

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

[crossfire] Release 1.12

[Lalo Martins]

I'd like to propose that, before we set off on major rewrites, we 
officially give up on the previous 2.0 effort, and release what's 
currently on trunk as 1.12.  (Which probably means either merge the 
branch, or abandon it and just use trunk...)

There are major improvements on trunk, notably an actually usable gtk 
client; since trunk is no longer going to be the basis for 2.0, there's 
no point sticking to the 1.x branch any longer.

(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.)

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 announcement URLs broken?

[Mark Wedel]

Kevin R. Bulgrien wrote:
> The ftp sites listed in the announcement don't seem to work.
> 
>> Crossfire is available on the following ftp sites
>>
>> Primary:
>>  ftp://ftp.sourceforge.net/pub/sourceforge/crossfire
>>
>> Secondary:
>>  ftp://ftp.real-time.com/pub/games/crossfire
> 
> The SF link... who knows.  I didn't try that hard and sometimes
> their stuff is hit-or-miss.

  It appears you can only download them HTTP now days:
http://sourceforge.net/project/showfiles.php?group_id=13833

  as a starting point.  Sourceforge has several mirrors.

  I'll change release notes for future. I'll likely just include those URL 
links 
in there, eg, 
http://downloads.sourceforge.net/crossfire/crossfire-1.11.0.arch.tar.gz

  And so on for the different files.




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

[crossfire] Release announcement URLs broken?

[Kevin R. Bulgrien]

The ftp sites listed in the announcement don't seem to work.

> Crossfire is available on the following ftp sites
>
> Primary:
>     ftp://ftp.sourceforge.net/pub/sourceforge/crossfire
>
> Secondary:
>     ftp://ftp.real-time.com/pub/games/crossfire

The SF link... who knows.  I didn't try that hard and sometimes
their stuff is hit-or-miss.

Note that ftp.real-time.com has no pub/games directory that is
visible.

Nitpick alert:  The release signature is January 1, 2008. ;-)

In all, though, its good to see another release out.  Some of
those ChangeLogs are huge!

___
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

[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

[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]

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

[Olivier Huet]

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 ?


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 ?


Olivier Huet
(findufin & findragon on metalforge)


-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Nicolas Weeger
Envoyé : mardi 18 septembre 2007 18:51
À : Crossfire Discussion Mailing List
Objet : Re: [crossfire] Release of 1.11 in a week or two

Le mardi 18 septembre 2007, Mark Wedel a écrit :
>   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.

Stopper thing: Windows support.
With the new metaserver and curl, pthread is needed too, so one should take
the time to see how to make everything work nicely.
Also, AFAIK, GTK2 with Kevin's patches hasn't been tested under Windows
either.

Unfortunately I don't have much time lately, so I can't guarantee that I'll
be able to test everything. If anyone has the time and will, of course,
that's another issue :)


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


___
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]

Le mardi 18 septembre 2007, Mark Wedel a écrit :
>   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.

Stopper thing: Windows support.
With the new metaserver and curl, pthread is needed too, so one should take 
the time to see how to make everything work nicely.
Also, AFAIK, GTK2 with Kevin's patches hasn't been tested under Windows 
either.

Unfortunately I don't have much time lately, so I can't guarantee that I'll be 
able to test everything. If anyone has the time and will, of course, that's 
another issue :)


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

[Kevin R. Bulgrien]

>   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?

Kevin

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

[crossfire] Release of 1.11 in a week or two

[Mark Wedel]

  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.


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

Re: [crossfire] Release schedule/notes

[mwedel]

>>   I really thing, relative to the trunk, this is a brief outline of
>> steps:
>> 1) Finish with the major overhaul of whatever we plan to overhaul in the
>> trunk server for 2.0
>> 2) Set up some test server(s), see how they work.
>> 3) start worrying about making pre 2.0 releases once we have a pretty
>> good
>> idea that what we have will have some semblance to what final 2.0 will
>> look
>> like.
>
> Concerning point 2), we should have such servers starting from now. There
> are
> many things in trunk that aren't in branch, so it'd be a waste to wait too
> much before trunk becomes the officiel version :)

 Maybe.  To do so would require the following:
a) It should be difficult to impossible for 1.x clients to connect to a
server.
b) Perhaps they should not even be visible on the metaserver, or a new
metaserver architecture is needed.

 I say this because I think that the _worst_ thing that can happen for
crossfire is for unaware users to play on a 2.0 server.  They'd probably
say things like it is buggy as hell, unreliable, and be PO'd when at some
point the server is wiped because of imcompatible changes

  If the only way for someone to play is to download the SVN client and
compile it themselves, then at that point, I say they probably know the
risks.  This gets a bit messed up as related to windows clients, as
presumably ones would need to be made available, and people unaware
would say 'hey - 2.0 looks the latest, I'll download that'.

 The main thing here is that one bad experience probably carries the
weight of 10 good ones.

>
> IMO, doing a 1.11 release isn't necessary. We should concentrate on trunk
> (yes, there are many bugs, which is why we need to focus on fixing that),
> and
> only do bug fix releases of 1.x branch.

 If that is the case, that is fine.  But if that is the case, then a lot
of stuff that is getting backported to the 1.x branch probably shouldn't
get backported.

 The problem is how do you define a bug?   Or maybe the question here is
severity of bugs.  Because if only 'bugs' are backported, there are going
to be enough changes to warrant more 1.x releases, and portentially
enough changes in those to call them 1.11, 1.12, etc.

 Also, backporting some 'features' to 1.x could be a good way to get
testing on them.  Polymorph might be such an example, and there may be
others.

 But from lots of previous discussions, it was decided that 1.x would
remain the stable branch, with regular releases, with the trunk branch
not making releases for quite a while.

 We could of course change this policy, but this was something
decided/discussed not too long ago.  At some point, if we revisit every
decision 6 months after it is made, it sort of calls into question what
is the point of having these discussions and making decisions if we just
decide something new a few months from now.

>
> Nicolas
> --
> http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code,
> bref
> de l'aléatoire !]
>
> ___
> 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 schedule/notes

[Nicolas Weeger]

Hello.

Reacting kind of lately, but well :)

>   The client, as of right now, should be compatible with older server (eg,
> a trunk client can player on a 1.10.0 server without problems), so we could
> do releases of those.  I almost wonder if it makes sense to completely
> decouple the numbering schemes between those, and instead have a
> compatibility chart.  My expectation is that trunk client will likely be
> able to play on 1.x servers until some protocol changes are made and the
> legacy support for older protocol is removed from the client.  What this
> effectively means is that one day the trunk client could work with 1.x, and
> the next day it doesn't.

We should already clear some really old stuff, which has been left over from 
previous things. That would make some room :)

>   I really thing, relative to the trunk, this is a brief outline of steps:
> 1) Finish with the major overhaul of whatever we plan to overhaul in the
> trunk server for 2.0
> 2) Set up some test server(s), see how they work.
> 3) start worrying about making pre 2.0 releases once we have a pretty good
> idea that what we have will have some semblance to what final 2.0 will look
> like.

Concerning point 2), we should have such servers starting from now. There are 
many things in trunk that aren't in branch, so it'd be a waste to wait too 
much before trunk becomes the officiel version :)

IMO, doing a 1.11 release isn't necessary. We should concentrate on trunk 
(yes, there are many bugs, which is why we need to focus on fixing that), and 
only do bug fix releases of 1.x branch.

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

___
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/notes

[alex_sch]

Quoting Mark Wedel <[EMAIL PROTECTED]>:

> Doing somewhere between 3 and 6 releases/year seems roughly the right rate - 
> not so much time is being used making releases, yet is it often enough to get
> changes out there, but not so often than a release might only have 2 changes.

This rate seems to make sense to me.

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

> 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 :))
 
> maps & archetypes:  These are almost one piece, as they depend on each other
> pretty heavily.  I don't believe there have been any server changes required
> for the maps & archetypes as we have them now, so releases on those could be
> made. OTOH I also don't recall seeing any major changes, so making releases 
> of 
> pre 2.0 releases of just the maps & archetypes would be confusing.

Well, recently Ragnor did remove some depreciated parsing code from the server
for things like "flying", and changed the arches accordingly, thus we'd need pre
2.0 arches and probably maps along with a pre 2.0 server release.

> I really thing, relative to the trunk, this is a brief outline of steps:
> 1) Finish with the major overhaul of whatever we plan to overhaul in the 
> trunk 
> server for 2.0
> 2) Set up some test server(s), see how they work.
> 3) start worrying about making pre 2.0 releases once we have a pretty good
> idea that what we have will have some semblance to what final 2.0 will look
> like.

A quick comment on this, is once #1 of that gets to a certain stage, #2 and #1
should probably go in parallel :)


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

[crossfire] Release schedule/notes

[Mark Wedel]

  After finally finishing up the 1.10.0 release, and the discussion around 
that, 
quick thoughts on future releases.

In this discussion, I'm talking about minor releases from the 1.x branch, so 
this next release would be 1.11.0

  Doing somewhere between 3 and 6 releases/year seems roughly the right rate - 
not so much time is being used making releases, yet is it often enough to get 
changes out there, but not so often than a release might only have 2 changes.

  So I'd say that puts the next release in the June timeframe.  That probably 
works for my schedule, presuming I'm the person still doing the release.  I'd 
send out mail as the date gets closer.

  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).  I'm not sure if doing releases 
of those, especially the server, makes sense, as that is a bit more of a pain.

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

  The client, as of right now, should be compatible with older server (eg, a 
trunk client can player on a 1.10.0 server without problems), so we could do 
releases of those.  I almost wonder if it makes sense to completely decouple 
the 
numbering schemes between those, and instead have a compatibility chart.  My 
expectation is that trunk client will likely be able to play on 1.x servers 
until some protocol changes are made and the legacy support for older protocol 
is removed from the client.  What this effectively means is that one day the 
trunk client could work with 1.x, and the next day it doesn't.

maps & archetypes:  These are almost one piece, as they depend on each other 
pretty heavily.  I don't believe there have been any server changes required 
for 
the maps & archetypes as we have them now, so releases on those could be made. 
OTOH I also don't recall seeing any major changes, so making releases of pre 
2.0 
releases of just the maps & archetypes would be confusing.

  I really thing, relative to the trunk, this is a brief outline of steps:
1) Finish with the major overhaul of whatever we plan to overhaul in the trunk 
server for 2.0
2) Set up some test server(s), see how they work.
3) start worrying about making pre 2.0 releases once we have a pretty good idea 
that what we have will have some semblance to what final 2.0 will look like.



___
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:

>>   In terms of more frequent 'build' releases, I'm not sure how that really 
>> differs from a normal release.
> 
> Perhaps a technicality, but having a distinction would make it "easier" to
> release something even if there was a big bug unfixed, or it might be top of
> tree so that new development gets tested quicker... and also encourages
> new development to not go too long in an unusable state.

  Ok.  I wasn't thinking about the head releases here, just the stable 
releases/branch.

  So we have the case where 1.10.0 was just released.

  The next official release (in 2-3 months time) would be called 1.11.0.

  So if we do these interim (every 2 week) releases, what do we call them?

  Now my thought, and also stated in the in the release guidelines, that micro 
releases could be done.

  So in the case of maps, if you have some bugs that need to be fixed and you 
want to make a new release, you could make a 1.10.1 and release it in a few 
weeks.

  I think that is perfectly reasonably, but should perhaps be more driven by 
bugs it fixes or other changes.  It certainly doesn't make sense to make a map 
release every 2 weeks if the last thing that changed from the previous release 
were a few minor spelling mistakes.

  But the flip side is that if serious bugs are discovered, a release right 
away 
probably makes sense.  And if a serious bug (say security) is discovered the 
day 
after that micro release, then another micro release a day later probably makes 
sense.

  There is also some advantage to this - for the micro releases, there is no 
need for a full release of all the components.  If there are map fixes and they 
will work fine with the 1.10.0 server, make a micro release of the new map set, 
etc.

  For the stable release, this works pretty good, because big changes shouldn't 
be happening in the stable branches, so the interfaces should remain stable.

  IT does get a little trickier with the maps, because you could get the case 
where the new maps require new archetypes, yet the archetypes are part of the 
server, so you'd need to make a new server release.

  One could probably make a strong case that the data files from the server 
should be in a separate archive than the binaries (just like the maps are 
separate).  Server admins are probably more willing to dump a new set of 
archetypes/maps down than to have to recompile everything and make sure nothing 
got messed up in the process.

> 
>>   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.
> 
> Not my intent.  Say Joe wants to run a server... he picks stable because he
> mostly wants to play with a bunch of friends and doesn't want a lot of risk
> that stuff will be busted.  Jack though, likes to hack around, and play the
> bleeding edge, but he's not up to doing SVN checkout and build, so he goes
> for the "unstable".  It's all up to the downloader.  It's not a new concept as
> a number of big projects run that way... TortoiseCVS... CVS... etc.  I'd not
> say it is without some downsides if not managed well.

  As of now, we are not making any releases of the head branch.

  As said, that should perhaps change, but there are lots of downsides to it. 
There are actually lots to think about here - doing both head and stable 
releases double the release work.  have things drifted far enough apart for 
this 
to make lots of sense?  do we want to wait until we are close (6 months) from a 
2.0 release and start doing releases then, on the basis that we know some 
things 
in the code right now are work in progress?

  One reason for the branches was to open up the head branch for more rapid 
development without the more strict model done in a stable release.

  But the other issue I mention is incompability between future releases.

  We pretty much know what is in the main trunk right now is pretty far away 
from 2.0, and will be incompatible in various ways.

  You can imagine some of the reaction where joe user downloads the snapshot of 
the trunk right now that we provides, and sets up a server on it because he 
wants bleeding edge.  The next snapshot 2 months from now is various in 
incompatible ways, meaning that the player files have to be wiped, etc.  I 
think 
the reaction there would be negative, not positive.

  This is a bit different than most other programs, where things may change in 
various incompatible ways, but you don't effectively lose 2 months of work 
because of it

  So in a sense, if we make those snapshots, we almost need to put a warning 
like "What, are you crazy?  You almost certainly should be using the stable 
release because you may be forced to start with new characters at any time with 
this branch"

  That said, if people think we should put these releases out there, I won't 
stop  it.  but I personally would rather wait to the stage where we pretty sure 
things are somewhat st

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

[Kevin R. Bulgrien]

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

FWIW, I agree that it usually is going to take a balance between manual and
assisted.  I tend toward scripting the basic rote work that doesn't take
imagination.  Going to far with the hard stuff doesn't pay back, and is often
to easy to break quickly.

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

Perhaps a technicality, but having a distinction would make it "easier" to
release something even if there was a big bug unfixed, or it might be top of
tree so that new development gets tested quicker... and also encourages
new development to not go too long in an unusable state.

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

Not my intent.  Say Joe wants to run a server... he picks stable because he
mostly wants to play with a bunch of friends and doesn't want a lot of risk
that stuff will be busted.  Jack though, likes to hack around, and play the
bleeding edge, but he's not up to doing SVN checkout and build, so he goes
for the "unstable".  It's all up to the downloader.  It's not a new concept as
a number of big projects run that way... TortoiseCVS... CVS... etc.  I'd not
say it is without some downsides if not managed well.

Say you go for a release every four months, then maybe there are three
"unstable" releases between where people don't try as hard to get all
the bugs out... they are in essence, release candidates on steroids in
that there is not requirement for new features to not be added.  The 
point is to get the stuff tested, not to presume it is error-free.  Maybe
the schedule helps people stop putting in features after the last
unstable before a new release...  or maybe not depending on how
formal you want things to run... but that might help people plan
what to work on so that bug fixing gets attention as well as adding
new stuff.

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

When I said release quality, I was meaning that I wouldn't necessarily want
someone to think I thought they were polished, but since they were in SVN,
someone could hack on them when  I didn't.  It seems too bad to hoard a
script just because I don't know where junk like that goes.  It seems harder
to add a file in a maps directory, etc if your just hacking around a proof of
concept that might just fizzle.  Hav

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

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

[Kevin R. Bulgrien]

> Looking back, the only thing I might really change is perhaps saying 
> something 
> on irc like "I'm going to do a release starting right now - if you have 
> anything 
> ready to commit, let me know now and commit it", to catch any of those ready 
> to 
> commit fixes (but that in itself can sometimes be dangerous).  If I had a 
> time 
> machine, I'd send a note to myself 2 weeks ago to send mail to the list 
> saying 
> I'm going to do a release in 2 weeks.  But I have to go on what I knew at the 
> time, not what I knew later.

Ok... and not to beat a dead horse, but my fixes were in easy maps, the ones 
most
likely for new players to see, which is why it gave me heartburn, and this kind 
of
heartburn is what you begin to address below, so we are on the same page.  I
know some distributions will ship 1.10 with those glaring bugs, and a slow
release means I just let them out the gate for who knows how long even if
I didn't have a hand in when the release occurred

>   Otherwise, I still think my decision to do a release now is better than 
> waiting another 2 months for a release.  Even though the code has some bugs, 
> I'd 
> say it is better than what is out there right now as 1.9.1, and at some 
> level, 
> getting code out there for others to use has some advantages.

I'm not totally on the same page here.  I think I would be if there were stable 
and
unstable releases, and if we were talking about an unstable one, but... on the
flip side, I get the point that it should not have waited another 2 months... 
and
agree on that point even though there rarely seems to be a truly acceptable
reason for releasing without mentioning it to co-developers.

>   This is one of the arguments for frequent releases - sure, each build will 
> have some bugs, and could be made better if delayed, but by getting the 
> builds 
> out there, you get people to discover some of those new bugs so that they can 
> get fixed in the next release.  If infrequent releases are done, quality may 
> in 
> fact not be better because people are stuck using an old buggy build for a 
> longer time period.
> 
>   Now to turn this more constructive, I think the real question is:  How 
> often 
> should we be doing releases?  Every month?  Every 3 months?  Somewhere in 
> between?
>
>   I think anything more frequent then every month (save for critical 
> builds/to 
> fix something DOA) doesn't make much sense, as I don't think the 1.x branch 
> is 
> changing fast enough.
> 
>   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.

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

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.

2 cents... maybe not worth much in some economies...

Kevin

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

Re: [crossfire] Release of 1.10 soon.

[Nicolas Weeger (Laposte)]

Le vendredi 29 décembre 2006 23:08, Mark Wedel a écrit :
>   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.
>
>   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.

Given the rate at which bugs are corrected lately, i'd say to wait ~2 weeks, 
and we'll have a nice clean tracker :)


Nicolas

___
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

[crossfire] Release of 1.10 soon.

[Mark Wedel]

  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.

  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.



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

Re: [crossfire] Crossfire Release Cycles/Methodology

[Mark Wedel]

  Just a note - I've put a copy of this document, with a few minor changes, on 
the wiki:

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

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

Re: [crossfire] Crossfire Release Cycles/Methodology

[Tchize]

Also, about restructurations of code, svn unlike cvs does not 'forget' 
the history of a file when it's moved. I use cvs a lot for work and 
dureing refactoring of our code (which happens from time to time) we 
already lost versions of some files because they were deleted / restored 
/ deleted and as result, you have an unconsistent attic (2 files with 
same name at same directory got deleted, you only have access to latest 
on in Attic)

Nicolas Weeger (Laposte) wrote:
>>   I'm not sure about the other systems out there - once can spend a lot of
>> time looking over all the documentation, etc.  AS with our last discussion,
>> I'm most inclined to stick with CVS since we know what it does and doesn't
>> have any real major shortcomings (it works right now).
>> 
>
> I'm in no way CVS/SVN expert (I use both, but I never really played with 
> branches).
>
> IMO, if SVN isn't too bad for branches, we should switch. SVN has atomic 
> transactions, that's a great feature, specially with upcoming talk about 
> restructuration and such - makes it much easier to revert commits.
>
> Nicolas
>
> ___
> 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] Crossfire Release Cycles/Methodology

[Nicolas Weeger (Laposte)]

>   I'm not sure about the other systems out there - once can spend a lot of
> time looking over all the documentation, etc.  AS with our last discussion,
> I'm most inclined to stick with CVS since we know what it does and doesn't
> have any real major shortcomings (it works right now).

I'm in no way CVS/SVN expert (I use both, but I never really played with 
branches).

IMO, if SVN isn't too bad for branches, we should switch. SVN has atomic 
transactions, that's a great feature, specially with upcoming talk about 
restructuration and such - makes it much easier to revert commits.

Nicolas

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

Re: [crossfire] Crossfire Release Cycles/Methodology

[Tchize]

svn does branching and tagging, and according to this faq 
(http://subversion.tigris.org/faq.html#merge-using-tags) it does it 
pretty well.

basically svn does this to handle branching and merging
copy trunk ->  myBranch
copy myBranch -> myBranchMerged
modify myBranch at will
copy the diff between myBranch and myBranchMerged to trunk

CVS on his side does this
tag the main branch
create a branch from given tag (don't forget to give that branch a name 
that must be different than tag)
modify the branch
copy all changes made to branch to main

As a result, same number of operation, and svn is 'supposed' to be 
faster than cvs at this because the operations do not depend on 
repository size but on change size.

I think that because the branch name appear in url, it make it easier 
for user to checkout a given branch or revision from anonymous svn and 
the fact branches appear on http browsing (which  is not the case of 
svn) is also a pro for svn.

Mark Wedel wrote:
>   Some of SVN big advantages appears to be able to work offline (keeps copy 
> of 
> data you checked out around so you can do diffs without needing connection, 
> as 
> well as ungets).  Some of the other features may not make as big a difference 
> to 
> us - ability to use different connection methods (that really is up to the 
> hosting agent) and better binary support.
>
>   But the fact it doesn't do branching as well as CVS is probably a major 
> shortcoming, especially since we are looking at needing to use branches a lot 
> more.
>
>   I'm not sure about the other systems out there - once can spend a lot of 
> time 
> looking over all the documentation, etc.  AS with our last discussion, I'm 
> most 
> inclined to stick with CVS since we know what it does and doesn't have any 
> real 
> major shortcomings (it works right now).
>
>
>
>
>
> ___
> 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] Crossfire Release Cycles/Methodology

[Mark Wedel]

  Some of SVN big advantages appears to be able to work offline (keeps copy of 
data you checked out around so you can do diffs without needing connection, as 
well as ungets).  Some of the other features may not make as big a difference 
to 
us - ability to use different connection methods (that really is up to the 
hosting agent) and better binary support.

  But the fact it doesn't do branching as well as CVS is probably a major 
shortcoming, especially since we are looking at needing to use branches a lot 
more.

  I'm not sure about the other systems out there - once can spend a lot of time 
looking over all the documentation, etc.  AS with our last discussion, I'm most 
inclined to stick with CVS since we know what it does and doesn't have any real 
major shortcomings (it works right now).





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

Re: [crossfire] Crossfire Release Cycles/Methodology

[Alex Schultz]

Lalo Martins wrote:
> 
>   
Ahh yes, those are the sorts of SVN issues I've heard about, though I'm
not experienced with SVN myself.
> I believe the idea is to try some proper revision control system like bzr 
> (there's
> free hosting at launchpad.net; you can host your own using only ssh and
> a webserver), git/cogito (used by the kernel and many freedesktop.org
> packages; I'm sure there must be free hosting somewhere) or darcs (again,
> needs only ssh and http to host).
One little note, bzr I find to be rather nice, however I find it's a bit
annoyingly memory and cpu intensive on source trees as large as cf.
git/cogito looks interesting, the tools seem pretty nice from what
little I've looked at, though it will be a bit of pain under windows
(and we do have a couple windows-using developers) as under windows it
requires cygwin. One other thought, darcs looks like an interesting one
too, however the fact that it's written in hacksel makes it a bit of a
pain to compile if one can't get binaries for one's system.

Personally I'm thinking just sticking with CVS is best though, largely
due to sticking with sf being easiest. I'm now thinking that SVN
wouldn't be too bad, but wouldn't be worth switching from CVS to use
unless one has some significant reason.

Alex Schultz

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

Re: [crossfire] Crossfire Release Cycles/Methodology

[Alex Schultz]

Mark Wedel wrote:
>   As far as going to something else, I think it would have to be vastly 
> better - 
> sourceforge provides a nice free environment - it keeps things very simple - 
> it 
> is associated with a group, not a single person.
>
>   Something that is not free or associated with one person can become a 
> problem. 
>   Suppose there is some cool site that provides a nice source control package 
> for a relatively nominal amount of money, and I'm willing to pay it.  That 
> works 
> great unless I'm hit by a meteorite, and which time, that could just 
> disappear 
> without anyone really knowing why (same points apply to services hosted on a 
> persons private computer, etc - it sounds reasonable, but if something 
> happened 
> to that computer (house burns down), first priority for that person probably 
> isn't getting that server set up again).
For such reasons I would agree, we shouldn't go for something that is
not free, or associated with one person. My point was more saying that
perhaps it would be worth also evaluating the possibility of using some
other version control system such as bazaar-ng (personally I think
that's a pretty good one, however I don't think it would be a great idea
for cf, largely because it becomes rather slow with source trees as
large as crossfire, but I was just primarily using that as an example).
Personally I currently think that either SVN or CVS are the best options
for crossfire, but I just wanted to make a point that other options are
worth looking at a little too.
In terms of hosting, that is an issue for use of other, the metalforge
server may or may not work (don't know if Leaf would or not), however
that too has a little bit of those "associated with one person"
potential issues, though it is less significant. One thought, is
distributed version control systems would make "associated with one
person" issues less significant, thought it wouldn't eliminate those issues.

Alex Schultz

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

Re: [crossfire] Crossfire Release Cycles/Methodology

[Lalo Martins]

On Tue, 08 Aug 2006 00:44:01 -0700, Mark Wedel wrote:
> Alex Schultz wrote:
>>> - Should we switch to SVN?  Switching repositories at same time as switching
>>>what the head branch means would make the most sense.
>>>   
>> I agree that when switching what the head branch means makes the most
>> sense, however I'm not sure that to SVN would be a great type of move to
>> me. SVN from what I've seen does address some of CVS's weaknesses,
>> however I have heard that the way it handles branching for example is
>> ugly. Could someone with more experience with SVN comment on branching
>> in SVN? Also, if we are willing/able to move off of sf.net for version
>> control, it might be worth considering other version control options (I
>> personally think that if we don't use either SVN or CVS, we should see
>> if we can set up a read-only CVS or SVN mirror for people to download
>> off of who don't have the other type of version control software.)

I have written broadly over SVN a few months ago, I'd rather not repeat
myself: http://lalo.revisioncontrol.net/entry/oooh-lets-migrate-to-svn


>   I'm not sure how big a deal that really is.  It certainly looks like
>   SVN has
> nicer abilities to merge changes.

Merging between multiple branches -- in this case, potentially applying an
important fix to the trunk, stable branch, last release branch, micro
branch, and a branch frozen as candidate for the next release -- is not so
simple; even CVS does this better than SVN.

Merging between two branches -- eg trunk and stable -- more than once is
inconvenient in CVS and nightmarish in SVN.

>   As far as going to something else, I think it would have to be vastly
>   better - sourceforge provides a nice free environment - it keeps
>   things very simple - it is associated with a group, not a single
>   person.
> 
>   Something that is not free or associated with one person can become a
>   problem. Suppose there is some cool site that provides a nice source
>   control package for a relatively nominal amount of money

I don't think anyone's talking about a non-free alternative.  I believe
the idea is to try some proper revision control system like bzr (there's
free hosting at launchpad.net; you can host your own using only ssh and
a webserver), git/cogito (used by the kernel and many freedesktop.org
packages; I'm sure there must be free hosting somewhere) or darcs (again,
needs only ssh and http to host).

IIRC, we've had this discussion before... more or less once every 5 months
or so...

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.
--
personal:  http://www.laranja.org/ technical:
  http://lalo.revisioncontrol.net/ GNU: never give up
freedom http://www.gnu.org/



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

Re: [crossfire] Crossfire Release Cycles/Methodology

[Mark Wedel]

Nicolas Weeger (Laposte) wrote:
> Hello.
> 
> I globally agree, a few points:
> 
>>- Client and server releases will be done at same time, with matching
>>  version numbers.
>>  - Exception is micro releases, where it may be only the client or
>>only the server released.
> 
> This supposes client will evolve too. Experience shows client has a 
> development cycle way slower than server. So we may have cases where client 
> doesn't really need to be released.

  True - OTOH, it isn't really harmful to release the client periodically.

  Actually, given this release model, the changes in the server will be greatly 
diminished.  If we look back what was done since 1.0, all of the big features 
would be in the 2.0 target and missing from the 1.x releases.

> 
>>  - Major release is done when feature set is complete.
> 
> That I'm not totally sure I agree.
> It's nice to agree on a feature set for next major release. But sometimes no 
> one feels working on some point for some months, whereas code moves in 
> another area, enough to warrant a major release.
> So I'd say we decide on a "wanted features list", but we can release a major 
> anyway if enough changes were made.

  Perhaps ammended that the list can be revisited at various times.

  If we are talking years between major releases, I think that is a requirement 
- how can anyone really say what things will be like 18 months from now - 
things 
may change such that some new feature/changes is critically needed.

  Likewise, if there are features on the list that no one is willing to do, it 
may be reasonable to discuss if those features should really be on that list - 
if the list is determined by the developers, there should probably be some 
willingness by the developers to work on those things.

  I guess the main point is that it should be a surprise to anyone when the 
release is done.

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