[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 spots modification handling (merge changes to
> initial map with the saved map) ; makes it easier to change guilds

  In theory, some of this can probably be done by scripts that get run when 
updates do happen, but this gets tricky in many different ways

  The overlays sort of handled this better in some way - it wouldn't alter the 
base map, and in the overlay file only save those objects that were added to the 
map (dropped, generated, etc) - so if the map changed, all the basic objects, 
etc, would get updated.

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

  That last one probably isn't so hard - depending on the map.  If it is a 
dungeon map, the loader should be able to error out, bounce the player back to 
the original map and print some message.  But for tiled maps, you sort of get 
the question, what do you do?  You don't want a hole in the world.

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

  Yes - but does this come up often?  while needing to run collect, etc, may be 
some of a bother, it isn't all that hard to do.

  I think the greater value would be able to have arc and png files in the maps 
directory - in that way, maps that are added with some maps are nicely 
colocated.  However, one still has to be careful about removing them - if some 
players have grabbed the unique arch's and they now disappear, that would 
probably produce odd results.

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

  Yes - that would be nice.

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

  Since we're talking about the dreamworld, if I was going to do threading, I 
would have each map its thread, which includes loading and saving.  The 
advantage of this also is that out of control spells, bullet loops, etc, would 
not bring the entire server process to its knees - just that one map would 
freeze up (other maps may get laggy from all that cpu time) - but advantage of 
this is that the thread dispatch could also potentially watch for that and kill 
bad threads.