Re: [crossfire] Release proposal

[Robert Brockway]

On Fri, 23 Jun 2017, Kevin Zheng wrote:


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


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


Late response :)

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



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


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


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


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


Cheers,

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

Re: [crossfire] Release proposal

[Ruben Safir]

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


where is everything that was in my guild ;)


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


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

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

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

Re: [crossfire] Release proposal

[Rick Tanner]

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

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

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

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

Re: [crossfire] Release proposal

[Mark Wedel]

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

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


120 ms is the tick time.

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


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

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


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


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


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


 But none of that is a trivial change.

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




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


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


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




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

Re: [crossfire] Release proposal

[Matthew Giassa]

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

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

Cheers!

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


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

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


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


Disk space needed for (trunk only) source content:

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

After compiling the server:

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

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


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




From my observations...

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

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

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


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

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




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

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


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


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


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

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

Re: [crossfire] Release proposal

[Mark Wedel]

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

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


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


Disk space needed for (trunk only) source content:

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

After compiling the server:

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

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


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




From my observations...

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

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

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


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

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




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

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


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


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


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

Re: [crossfire] Release proposal

[Ruben Safir]

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

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


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

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

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

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

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

Re: [crossfire] Release proposal

[David Hurst]

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

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

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

Saru

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

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

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

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

Re: [crossfire] Release proposal

[Matthew Giassa]

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

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

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

-Matthew

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

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

Re: [crossfire] Release proposal

[Kevin Zheng]

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

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

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

Re: [crossfire] Release proposal

[Kevin Zheng]

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

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

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

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

Re: [crossfire] Release proposal

[Robert Brockway]

Sounds exciting.

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


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


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


Cheers,

Rob

On Thu, 22 Jun 2017, Kevin Zheng wrote:


Hi there,

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

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

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

Thanks,
Kevin



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

Re: [crossfire] Release proposal

[Mark Wedel]

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

Hi there,

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

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

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


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



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

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

[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/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 the 
client deal with them vs sending the 32 variations of each model.  

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.




 In a dreamworld:

 - better unique map or unique 

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?

[Mark Wedel]

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

 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?

[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=detailaid=2938902group_id=13833atid=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 called 1.51, 

Re: [crossfire] Release?

[Mark Wedel]

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

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

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

 To recap or confirm..

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

  Called 1.50, and be based what is in trunk.


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

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

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



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

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


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

Re: [crossfire] Release?

[Kevin Bulgrien]

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

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

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

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

Kevin

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

Re: [crossfire] Release?

[Mark Wedel]

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

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

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

  Quick thoughts:

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

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

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

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

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

Re: [crossfire] Release?

[Rick Tanner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

To recap or confirm..

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

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

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



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

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

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

Re: [crossfire] Release?

[Mark Wedel]

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


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

Re: [crossfire] Release?

[Nicolas Weeger]

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

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

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

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


Yes, it's spring!


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

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


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

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




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


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

Re: [crossfire] Release?

[Mark Wedel]

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

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

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

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


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

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

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

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

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



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

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


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

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


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

Re: [crossfire] Release?

[Nicolas Weeger]

Hello.

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

Fine by me.


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


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


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





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

Fine by me.


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


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

Re: [crossfire] Release?

[Mark Wedel]

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


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


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

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

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

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


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

Re: [crossfire] Release?

[Mark Wedel]

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

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

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


 Does that sound ok?

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

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

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

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



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

Re: [crossfire] Release?

[Mark Wedel]

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

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

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

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

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

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

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


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

Re: [crossfire] Release?

[Kevin Bulgrien]

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

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

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

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

Re: [crossfire] Release?

[Alex Schultz]

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

Alex Schultz

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

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


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

[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

[Rick Tanner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

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

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

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




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

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

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

Re: [crossfire] Release 1.12

[Lalo Martins]

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

Thanks!

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

Oakdoors?  :-)

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

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

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

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


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

Re: [crossfire] Release 1.12

[Mark Wedel]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [crossfire] Release 1.12

[Lalo Martins]

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

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

Comments welcome.

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

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

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

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


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

Re: [crossfire] Release 1.12

[Lalo Martins]

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

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

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

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

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

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

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

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


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

Re: [crossfire] Release 1.12

[Rick Tanner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

Going with the assumption that this takes place...

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

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

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

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

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

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

Re: [crossfire] Release 1.12

[Lalo Martins]

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

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

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

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

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


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

Re: [crossfire] Release 1.12

[Lalo Martins]

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

Actually, let me rephrase that :-)

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

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

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

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

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


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

Re: [crossfire] Release 1.12

[Lalo Martins]

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

LOL guilty as charged... I wrote those!

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

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

Cool, thanks.

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


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

Re: [crossfire] Release 1.12

[Klaus Elsbernd]

Hello,

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

Klaus

Bis dann
Klaus

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




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

Re: [crossfire] Release 1.12

[Juha Jäykkä]

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

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

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

-Juha

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


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

Re: [crossfire] Release 1.12

[Lalo Martins]

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

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

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


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

Re: [crossfire] Release 1.12

[Nicolas Weeger]

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

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

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

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


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


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

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

[Nicolas Weeger]

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

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

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

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

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

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

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

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

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


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


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

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

[Mark Wedel]

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

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

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

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

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

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

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

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

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

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

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

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

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

  opengl also supports alpha transparencies also.

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


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

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

[Mark Wedel]

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

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

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

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

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

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

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

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

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

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

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

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

[Mark Wedel]

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

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

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

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

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

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

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

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

Re: [crossfire] Release schedule/notes

[Mark Wedel]

[EMAIL PROTECTED] wrote:

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

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

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

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

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

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

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

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

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


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

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

[Mark Wedel]

Kevin R. Bulgrien wrote:


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

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

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

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

  (I have yet to the server release)

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

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

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

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

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

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

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

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

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

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

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

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

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



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

Re: [crossfire] Release of 1.10 soon.

[Andrew Fuchs]

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

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

-- 
Andrew Fuchs [EMAIL PROTECTED]


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

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

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

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

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

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

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

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

[Alex Schultz]

Lalo Martins wrote:
 snip svn criticisms
   
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

[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

[crossfire] Crossfire Release Cycles/Methodology

[Mark Wedel]

Per the recent discussion on code reorganization and what goes in what
release, this document is an attempt to gather the points raised and make it
into a formal document that can be included in the code or put on the wiki.

This document does not attempt to justify or explain why different things are
done for reasons of brevity - if we actually want every developer to read it,
we want to stick to the what the rules are, and not as much how we arrived at
those rules.

If I missed anything, or there is strong disagreement on any of these points, 
speak up.
.

--

- Crossfire versioning is described as major.minor.micro
   - 2.3.4 means major version 2, minor 3, micro 4
   - The main (head) of the CVS branch contains what will be the next major
 release.
   - A branch for the minor releases will be made when a major release is done
 - It is from this stable-major branch that future minor releases are made.
 - If a micro release is necessary, it will be branched from the
   stable-major branch, as stable-major-minor.
   - The RE may choose to make a branch for an upcoming minor release to
 limit changes, as stable-major-minor.
   - Minor releases will be made at periodic intervals (2-4 months apart).
   - Micro releases will only be done if an immediate release is necessary
 due to a critical bug, and waiting for the next minor release is not
 an option.
   - All releases will be symbolically tagged as rel-major-minor-micro
   - There is no practical upper limit to minor or micro versions -
 crossfire 1.16.22 is valid.
   - 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.
   - Public servers expected to run the stable branch, not the head branch.
   - stable branch will be made for all arch, maps, client, and server
 components of crossfire.

- What goes in each version of Crossfire:
   - All changes go into the main head branch, what will become the
 the next major release.
   - Smaller features/additions will also be done in the stable branch.
 - Developer discretion on whether to make change to stable branch
   in addition to head branch
   - Bug fixes go in both branches.
 - Developer making bug fix responsible for updating both branches
   - Following changes can only be made in the head (next major) branch:
 - Changes that break compatibility
 - Changes that make signficant changes to the code.
 - Removal of programs (discontinue support for a client as an example)
 - Changing name of executables.
   - Feature set of next major release to be discussed by developers.
 - List of proposed changes sent to mailing list.
 - Developers comment, decide priorities on list of features for next
   major release.
 - For major features, brief design document needs to be written,
   describing the feature, why it is important, and in broad terms,
   how it will be done.
   - All changes to protocol must have a design doc, no matter how small.
   - Design doc must be done before changes are commited - no writing
 design doc after code is written
 - Major release is done when feature set is complete.
 - For 2.0, smaller list of features should be the criteria since this
   change of release strategy is happening later in the 1.x release cycle.

--
Open Issues:

- Should we switch to SVN?  Switching repositories at same time as switching
   what the head branch means would make the most sense.
- Need some way to drive development - need some way to make sure items
   on TODO list for next release get done, and that developers just don't
   work on cool features they want that may not match TODO list.

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

Re: [crossfire] Crossfire Release Cycles/Methodology

[Alex Schultz]

Mark Wedel wrote:
 Per the recent discussion on code reorganization and what goes in what
 release, this document is an attempt to gather the points raised and make it
 into a formal document that can be included in the code or put on the wiki.

 snipped the large list
Those rules seem to make alot of sense to me. I can't think of any
disagreement I have with them.
 --
 Open Issues:

 - 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.)
 - Need some way to drive development - need some way to make sure items
on TODO list for next release get done, and that developers just don't
work on cool features they want that may not match TODO list
Well, the best method of dealing with this I've seen, is with how many
projects set things like Blocking 2.0 in their bugzilla system. We
might be able to use either categories or priority with the sf.net
tracker, however that seems hackish to me and wouldn't be the clearest.
That said, I think if we are to continue using the sf.net tracker, it
would be best to use that for TODO goals, however I think it may be
worth considering moving off of sf.net for bug tracking.

Alex Schultz

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