From nicolas.weeger at laposte.net Sun Nov 7 10:37:10 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 7 Nov 2010 17:37:10 +0100 Subject: [crossfire] Alchemy success chance Message-ID: <201011071737.14139.nicolas.weeger@laposte.net> Hello. Change implemented. Probability will be between .01 and .95, with .5 when you have the same skill level as the recipe difficulty. For interested parties, attached file is the full chance repartition. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: alchemy-probability.txt.gz Type: application/x-gzip Size: 70531 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101107/f971fa21/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101107/f971fa21/attachment.pgp From om at iki.fi Sun Nov 7 14:04:15 2010 From: om at iki.fi (Otto J. Makela) Date: Sun, 07 Nov 2010 22:04:15 +0200 Subject: [crossfire] Skill level needed display: theological limitations Message-ID: <4CD7063F.9020407@iki.fi> The skill level needed for certain actions and spells (like consecrate, heal, etc) depend in part on what gods the player follows. I believe this is currently not taken into account in the display, ie. if I am a follower of the Devourers, and thus have a handicap on healing, "show skills" claims I should be able to do it, but trying it says you need more experience. Should the display be fixed to show that more skill is required because of, er, theological limitations? -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */ From mwedel at sonic.net Sun Nov 7 18:37:40 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 07 Nov 2010 16:37:40 -0800 Subject: [crossfire] Skill level needed display: theological limitations In-Reply-To: <4CD7063F.9020407@iki.fi> References: <4CD7063F.9020407@iki.fi> Message-ID: <4CD74654.5080201@sonic.net> On 11/ 7/10 12:04 PM, Otto J. Makela wrote: > The skill level needed for certain actions and spells (like consecrate, > heal, etc) depend in part on what gods the player follows. I believe this > is currently not taken into account in the display, ie. if I am a follower > of the Devourers, and thus have a handicap on healing, "show skills" claims > I should be able to do it, but trying it says you need more experience. > > Should the display be fixed to show that more skill is required because of, > er, theological limitations? Is this theological limit because of spell path attunements/repulsions, etc, or something different? The skills command itself just dumps skill information, and for gods, just what god you worship - best I can see, it doesn't say anything about ability to use spells (unless you are talking about some different command). the problem is I don't think skills is the right place to take into account spell paths - after all, while devourers will not be able to cast heal at same level as someone who is not repelled, they can cast other spells at that level just fine. I looked at the show_matching_spells(), and it does not take into account attunement or repelled status when showing spell level - it should probably make a call to min_casting_level(). The cost in grace/mana is adjusted by the call to SP_level_spellpoint_cost(), so it makes sense to adjust level as well. I don't know if a * or something should be put after the level if attunement/repulsion has changed the level. For the case of worshipping, adjusting spell paths is difficult, but there is the more general case that a character may have an item which is attuned fire/repelled cold, and could easily remove that item if/when they want to cast a cold spell, and so knowing what real level is might be nice? I'd have to look at what the client side spell handling does - IIRC, for gtk client at least, it changes color of spell based on spell paths, so it is very easy for players to see if a spell is repelled or attuned - but I don't know if it adjust the level on that, or still shows base level and it is up to the player to know that it is ?2 levels depending on spell paths. From nicolas.weeger at laposte.net Sun Nov 14 08:23:59 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 14 Nov 2010 15:23:59 +0100 Subject: [crossfire] Guild changes Message-ID: <201011141524.02526.nicolas.weeger@laposte.net> Hello. I've rewritten a big part of the 'guild_dues.py' file, handling Jack on the guild mainfloor. There should be no functional change for players, hopefully it is slightly more documented on what you can do with it. I took the opportunity to fix typos in some cards names, so I fixed the script and the guild maps. This means the following guild maps should be reset (using 'reset full-reset .' as a DM in the map, after saving loot of course :)): - guild_jeweler - guild_thaum - secondfloor - that fix is to disable a suspicious lightning wall flooding the server log Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101114/ef8d0bc2/attachment.pgp From mwedel at sonic.net Sun Nov 14 23:19:56 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 14 Nov 2010 21:19:56 -0800 Subject: [crossfire] Crossfire release? Message-ID: <4CE0C2FC.80107@sonic.net> 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. From leaf at real-time.com Tue Nov 16 19:34:39 2010 From: leaf at real-time.com (Rick Tanner) Date: Tue, 16 Nov 2010 19:34:39 -0600 Subject: [crossfire] Crossfire release? In-Reply-To: <4CE0C2FC.80107@sonic.net> References: <4CE0C2FC.80107@sonic.net> Message-ID: <4CE3312F.8080204@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/14/10 11:19 PM, Mark Wedel wrote: > > Been a little more than 6 months since last official release, and I was > thinking that trying to get one out before end of the year might be nice. > > Thoughts/comments? There has been a number of changes and updates to make a release necessary, IMO. Would prefer to see a release where the ChangeLog is not a dozen pages or thousands of lines of summary text. ;-) > Likewise, any list of the major changes since last release? Looking at > changelog can be a little problematic, as it may not be readily apparent from > the notes whether it is a significant/meaningful change. I have the SVN Traffic page updated from Nov-2010 back to Sept-2010, so about half way there. Another set of eyes to confirm, clarify and update information so far is always welcome. http://wiki.metalforge.net/doku.php/crossfire_traffic One major change is the new character creation method. Also some new maps, improvements on existing maps, lots of sound related & support changes in the gtk-v2 client. Number of updates in the JXClient as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFM4zEvhHyvgBp+vH4RAlP+AKCJTAIAlMHAci9zjeq/DlMk+AIT8QCgwaEs GgwForc45sNgIt9AaeARyQs= =yWEW -----END PGP SIGNATURE----- From kbulgrien at att.net Tue Nov 16 22:24:32 2010 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Tue, 16 Nov 2010 22:24:32 -0600 Subject: [crossfire] Crossfire release? In-Reply-To: <4CE0C2FC.80107@sonic.net> References: <4CE0C2FC.80107@sonic.net> Message-ID: <201011162224.32978.kbulgrien@att.net> > Been a little more than 6 months since last official release, and I was > thinking that trying to get one out before end of the year might be nice. > > Thoughts/comments? 1.50.0 is broken. One cannot create a new character due to a .glade file bug. A release is needed. Technically, a 1.50.1 could consist of a new dialogs.glade file only. The fix is in SVN already, but, I think I'd prefer to see a general release since so much time has passed. Yes, getting one out would be nice to hit a new round of distribution hits to replace the broken client. I don't really know of any serious stability reports out there, though some users seem to be confused by the account / character setup dialogs. > Any list of bugs or other things that must be fixed before a release is > made? One place where stuff is recorded is: http://wiki.metalforge.net/doku.php/known_client_issues #2938902 crossfire-client-gtk2 has get/take errors https://sourceforge.net/tracker/?func=detail&aid=2938902&group_id=13833&atid=113833 There are a few others in the tracker too... though I'm not sure how significant they are. I think a fair number of them are Windows client issues, but this one is one I run into. IMO, it is time to ditch gtk-v2.glade as the default. It is becoming a not so uncommon event for a new user to come on IRC and have fits getting the important window panels to show up (inventory in particular). I've had one disappear off IRC after trying hard to help with little success. I'd personally rate this pretty much a necessity. Maybe dealing with that should be a different thread though. I did work to fix the caching of hosts in the metaserver dialog, but there is a bug still left. Somehow the cache list displayed isn't quite right. I haven't followed up to find out what's wrong yet. I'd like to rework the new dialogs. They do not match the style of the other dialogs, and, IMO, with apologies to the designer, ugly. It is not necessary to do so, but already that client has a reputation for its not so elegant looks. FWIW, I'd also like to rework the main windows the same way I did the dialogs. I think that would help people find the resize bars more easily. Not critical, but might alleviate issues with gtk-v2.glade somewhat. > Likewise, any list of the major changes since last release? Looking at > changelog can be a little problematic, as it may not be readily apparent > from the notes whether it is a significant/meaningful change. As for ChangeLog, I've personally taken to heart an IRC conversation about that document. I have started only logging things there that seem likely to be of end-user interest., and to allow the SVN log to serve as the technical change log. An important fix for the client is that it should handle backslash vs slash delimited paths properly now when built on windows. Dynamic resize of spells dialog is added. This is pretty significant. A great deal of effort went into populating all the spell help, and the text reflow capability means the dialog is much more useful on a variety of desktop environments. The client has preliminary support for Spellmon 2 (spells that require ingredients), but ingredient listing is not end-user visible at this time. The client now has a 30 second timeout instead of a 3-4 minute lockup if a connection attempt is made to a host/port that does not have a listening server. (Probably 30 seconds is still too long...) Issues with [X] close of dialogs has been improved and segfaults under some window managers are prevented. Delete events are now trapped and ignored to prevent dialogs from disappearing and requiring a client restart to correct the situation. I wonder if the most recently added dialogs are in need of the same fix applied to the account system dialogs. Music is working in GTK-V2 though there is no mechanism to deliver music with the client. I think some work needs to be done to at least define a system-wide location for music and a user-specific location for music. We also have no infrastructure set up to distribute media either. Not sure its worth making a big deal about the new feature at this point. Sound effects are not done at this point, but the infrastructure is technically operational as I can play sound effects in a tweaked development work space, but the server-to-client link is not complete. I think some factoring needs to be done to get a reasonable implementation. All the points made about music are pretty much also true for sound effects. Sound/Music may eventually need with respect to possibly fixing old .crossfire folder content, but then maybe one needs to just ditch the legacy files rather than try convert them to the new system. (The old system was severely broken as it used hard-coded absolute paths that could single-handedly disable sound if changes occurred upstream.) Even with the incomplete implementation, cfsndserv and friend should be release-safe. > I figure release should probably be called 1.51, but could do 1.60 - not > sure if that makes much difference. 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. From leaf at real-time.com Wed Nov 17 19:05:18 2010 From: leaf at real-time.com (Rick Tanner) Date: Wed, 17 Nov 2010 19:05:18 -0600 Subject: [crossfire] Crossfire release? In-Reply-To: <201011162224.32978.kbulgrien@att.net> References: <4CE0C2FC.80107@sonic.net> <201011162224.32978.kbulgrien@att.net> Message-ID: <4CE47BCE.8000406@real-time.com> -----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----- From mwedel at sonic.net Thu Nov 18 00:30:10 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 17 Nov 2010 22:30:10 -0800 Subject: [crossfire] Crossfire release? In-Reply-To: <201011162224.32978.kbulgrien@att.net> References: <4CE0C2FC.80107@sonic.net> <201011162224.32978.kbulgrien@att.net> Message-ID: <4CE4C7F2.9040705@sonic.net> On 11/16/10 08:24 PM, Kevin R. Bulgrien wrote: > IMO, it is time to ditch gtk-v2.glade as the default. It is becoming a > not so uncommon event for a new user to come on IRC and have fits > getting the important window panels to show up (inventory in particular). > I've had one disappear off IRC after trying hard to help with little success. > I'd personally rate this pretty much a necessity. Maybe dealing with that > should be a different thread though. I have no issue changing the default to something that is easier to use/works for a larger number of users. > > I did work to fix the caching of hosts in the metaserver dialog, but there > is a bug still left. Somehow the cache list displayed isn't quite right. I > haven't followed up to find out what's wrong yet. > > I'd like to rework the new dialogs. They do not match the style of the > other dialogs, and, IMO, with apologies to the designer, ugly. It is not > necessary to do so, but already that client has a reputation for its not > so elegant looks. I know many of the new dialogs would need some work. I was also caught somewhat in not quite knowing the best/correct size for them - some of the windows would be much better if they were larger (descriptions are scrunched in small area), but at same time, I didn't want to make the windows too large to work on low res displays - I'm not sure what the minimal display resolution we target currently is. > As for ChangeLog, I've personally taken to heart an IRC conversation about > that document. I have started only logging things there that seem likely to > be of end-user interest., and to allow the SVN log to serve as the technical > change log. That may be a different discussion - I missed the IRC conversation, but what is really recorded in the changelog could become just significant changes, and minor bug fixes not recorded there. I suppose I just followed the format of most projects where everything is recorded in the ChangeLog to high detail, but some are much more general. One concern I do have about that is to make sure comments recorded for the actual changed files be meaningful. Having a comment in the svn log like 'bug fix' is pretty useless - I'd much rather have the description be something like 'fix possible null pointer reference ....'. I only bring this up because in many cases, the same entry in the Changelog is what is used in the files. > Music is working in GTK-V2 though there is no mechanism to deliver music > with the client. I think some work needs to be done to at least define a > system-wide location for music and a user-specific location for music. > We also have no infrastructure set up to distribute media either. Not > sure its worth making a big deal about the new feature at this point. I suspect music will be like sounds - distribution will be in tar files/rpms/whatever. That said, any music files we have should get committed to SVN so they can be distributed. I suspect that music files will change infrequently enough that such a distribution method works fine. But if something more frequent was needed (say you add several new song files and don't want to wait for next official release that may be 6 months away), packing up a new tar archive with the new files and calling it a .1 release or something would probably be fine. > Sound/Music may eventually need with respect to possibly fixing old > .crossfire folder content, but then maybe one needs to just ditch the > legacy files rather than try convert them to the new system. (The old > system was severely broken as it used hard-coded absolute paths that > could single-handedly disable sound if changes occurred upstream.) I have no issues disabling/breaking old stuff if there is a good replacement - in fact, I'd rather ditch legacy stuff than adding bits of code to try and keep it functional. From nicolas.weeger at laposte.net Sat Nov 20 03:04:10 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 20 Nov 2010 10:04:10 +0100 Subject: [crossfire] Crossfire release? In-Reply-To: <4CE0C2FC.80107@sonic.net> References: <4CE0C2FC.80107@sonic.net> Message-ID: <201011201004.14718.nicolas.weeger@laposte.net> Hello. > Been a little more than 6 months since last official release, and I was > thinking that trying to get one out before end of the year might be nice. > > Thoughts/comments? > > Any list of bugs or other things that must be fixed before a release is > made? Things to fix for the next release: - ensure all clients versions are either disconnected with a "client too old" message or able to create account or at least characters on latest server - have an official Windows client ; if GTK should be it, actually build and package it (last tests I made showed issues with Glade library) - remove metaserver1 support from clients, so players don't go to old obsolete servers Things to fix someday: - add more quests, link maps or stories ; this would give players some hints on what to do or point to maps they don't know - make enough quests to nicely level in various skills (eg suite of alchemy- related quests enabling the player to learn recipes and level up) - many more compound graphics - create a Fenx character, and use singing, fight, cast magic, do the same for other races and classes - fix many broken monsters (hint: ac <-70 will make the monster almost invulnerable in melee), balance exp/sp/hp/gr and such - fix various Python guild bugs and issues - fix item_power ; some items are more powerful than others with less item_power (eg some rings, I think) ; also item_power is almost useless once you reach level 50, so spread the scale more In a dreamworld: - better unique map or unique spots modification handling (merge changes to initial map with the saved map) ; makes it easier to change guilds - handle many more errors ; flat out refuse to open maps containing some invalid item - enable people to use the arch directory from svn without collecting process, or just put their .arc or .png files in a correct directory for it to be used - enable archetypes, treasures, formulae, etc. reloading while server is running - limited threading for map or player loading and saving, to not lock the server with big maps ; or progressive loading/saving, whichever Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101120/f0efe3ad/attachment.pgp From nicolas.weeger at laposte.net Sat Nov 20 03:10:25 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 20 Nov 2010 10:10:25 +0100 Subject: [crossfire] Guilds fix Message-ID: <201011201010.26155.nicolas.weeger@laposte.net> Hello. The mainfloor of the guilds was missing a 'unique' flag for the ground where the BBQ's altar was teleported, resulting in said altar disappearing at map reset. This simply made the BBQ unusable even when bought. I committed a fix, unfortunately applying it to existing guilds requires a mainfloor full reset. Reset can be done by removing the file with the unique items, or as a DM using 'reset full-reset .' when in that map. Of course, it is advised to save the member's loot before resetting, and putting back all teleporters and altars... Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101120/8f385730/attachment.pgp From nicolas.weeger at laposte.net Sat Nov 20 05:18:28 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 20 Nov 2010 12:18:28 +0100 Subject: [crossfire] Guilds fix In-Reply-To: <201011201010.26155.nicolas.weeger@laposte.net> References: <201011201010.26155.nicolas.weeger@laposte.net> Message-ID: <201011201218.31437.nicolas.weeger@laposte.net> While you're at it, reset also the secondfloor, there was a mistake with the money needed for the jeweler's room. Nicolas Le samedi 20 novembre 2010 10:10:25, Nicolas Weeger a ?crit : > Hello. > > > The mainfloor of the guilds was missing a 'unique' flag for the ground > where the BBQ's altar was teleported, resulting in said altar disappearing > at map reset. This simply made the BBQ unusable even when bought. > > I committed a fix, unfortunately applying it to existing guilds requires a > mainfloor full reset. > > Reset can be done by removing the file with the unique items, or as a DM > using 'reset full-reset .' when in that map. > Of course, it is advised to save the member's loot before resetting, and > putting back all teleporters and altars... > > > Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101120/97a70955/attachment.pgp From mwedel at sonic.net Sun Nov 21 01:36:24 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 20 Nov 2010 23:36:24 -0800 Subject: [crossfire] Crossfire release? In-Reply-To: <201011201004.14718.nicolas.weeger@laposte.net> References: <4CE0C2FC.80107@sonic.net> <201011201004.14718.nicolas.weeger@laposte.net> Message-ID: <4CE8CBF8.7040602@sonic.net> 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. From nicolas.weeger at laposte.net Mon Nov 22 12:19:49 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 22 Nov 2010 19:19:49 +0100 Subject: [crossfire] Crossfire release? In-Reply-To: <4CE8CBF8.7040602@sonic.net> References: <4CE0C2FC.80107@sonic.net> <201011201004.14718.nicolas.weeger@laposte.net> <4CE8CBF8.7040602@sonic.net> Message-ID: <201011221919.53010.nicolas.weeger@laposte.net> > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101122/06448d0a/attachment.pgp From nicolas.weeger at laposte.net Mon Nov 22 16:48:29 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 22 Nov 2010 23:48:29 +0100 Subject: [crossfire] Guilds fix In-Reply-To: <201011201010.26155.nicolas.weeger@laposte.net> References: <201011201010.26155.nicolas.weeger@laposte.net> Message-ID: <201011222348.32263.nicolas.weeger@laposte.net> And some toolshed fix, so that one too should be reset ;) Patch courtesy Khaleh. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101122/c12d20d0/attachment.pgp From mwedel at sonic.net Tue Nov 23 00:45:53 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 22 Nov 2010 22:45:53 -0800 Subject: [crossfire] Crossfire release? In-Reply-To: <201011221919.53010.nicolas.weeger@laposte.net> References: <4CE0C2FC.80107@sonic.net> <201011201004.14718.nicolas.weeger@laposte.net> <4CE8CBF8.7040602@sonic.net> <201011221919.53010.nicolas.weeger@laposte.net> Message-ID: <4CEB6321.5090004@sonic.net> 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. Same potentially for vector graphics. But if there is only 3 3d models, at that point, it probably does not make sense to put that support in the client - there needs to be some critical mass. Note that a 64x64 image size was a somewhat arbitrary size - by it being an doubling of existing size, it means there shouldn't be as many/any artifacts from resizing are easier to deal with. 64x64 is also big enough that for the major of systems, that map window would fill the entire screen (64*25 is 1600 for those not wanting to do the math) - yes, there are high resolutions than that, but in that case, the extra space would presumably be used for things like inventory or messages or whatnot. But that doubling is size (really 4 times number of pixels) really should allow a lot more detail to be added. In short summary, if this was done (in dreamworld, but this is perhaps one of the easier pieces) 1) Make a big set of images by converting all existing images. 2) As cleanup of images move along, potentially use other formats as the 'source' image to make things easier/better. 3) If enough of these source images are made, then look at adding support to send this to the client and let client do rendering/scaling.