From nicolas.weeger at laposte.net Fri Jan 1 15:33:06 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 1 Jan 2010 22:33:06 +0100 Subject: [crossfire] Happy New Year! Message-ID: <201001012233.07002.nicolas.weeger@laposte.net> Happy New Year to all the members of the team! May 2010 bring you inspiration to tweak maps, add content, write (and implement) good stories, and such things ;) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100101/82a6d0a0/attachment.pgp From nicolas.weeger at laposte.net Tue Jan 5 12:13:30 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 5 Jan 2010 19:13:30 +0100 Subject: [crossfire] NPC respawning Message-ID: <201001051913.34549.nicolas.weeger@laposte.net> Hello. I'm wondering about NPC (not monsters, but "real" NPC the player can interact with) respawning when killed. If for instance you kill the owner of a tavern, should she respawn? I can see three options: - keep the same way it is now, respawn at map reset - make (some) NPCs unkillable - generate a random NPC close, with random dialogs not too far from the original one's I admit to prefer the last solution, as it makes the world more dynamic IMO. Of course, then, you have to put all relevant dialogs in a script / plugin so they can be redispatched on other NPCs. Thoughts? Opinions? :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100105/d325485e/attachment.pgp From nicolas.weeger at laposte.net Tue Jan 5 12:17:10 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 5 Jan 2010 19:17:10 +0100 Subject: [crossfire] Dialog mode Message-ID: <201001051917.10844.nicolas.weeger@laposte.net> Hello. I'd like to propose a (menu-driven) dialog mode for players. Something like what you can find in various RPG games. Description: - started when player says something to a NPC, like now - player is presented with text and options, and a free text zone (to not have all options visible/obvious) - player can't really move (or moving exits the dialog mode) - NPCs are marked as 'busy' and thus won't move while talked to - separates more the 'hack' part and the 'role playing' part - separates clearly the 'say' to trigger things / talk to other players, and the dialog with an NPC What do you think of that? :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100105/133caa59/attachment.pgp From leaf at real-time.com Tue Jan 5 13:16:06 2010 From: leaf at real-time.com (Rick Tanner) Date: Tue, 05 Jan 2010 13:16:06 -0600 Subject: [crossfire] NPC respawning In-Reply-To: <201001051913.34549.nicolas.weeger@laposte.net> References: <201001051913.34549.nicolas.weeger@laposte.net> Message-ID: <4B438FF6.30000@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/5/10 12:13 PM, Nicolas Weeger wrote: > Hello. > > I'm wondering about NPC (not monsters, but "real" NPC the player can interact > with) respawning when killed. > > If for instance you kill the owner of a tavern, should she respawn? So the tavern owner would never respawn .. ever? > I can see three options: > - keep the same way it is now, respawn at map reset > - make (some) NPCs unkillable > - generate a random NPC close, with random dialogs not too far from the > original one's What about making the NPC un-attackable or immune to all attacks? > I admit to prefer the last solution, as it makes the world more dynamic IMO. > Of course, then, you have to put all relevant dialogs in a script / plugin so > they can be redispatched on other NPCs. Going with you preferred option listed above.. what happens when that NPC dies for some reason? Another nearby NPC is created? What happens if the entire tavern population is wiped out from a misfired spell or marauding player? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLQ4/2hHyvgBp+vH4RAl8PAKDvSaC1Im4aXrDNfZOGvxHJW+CsGQCgqBcC MxUbVTUnm6fmd7wRV6IhtbA= =Lv+l -----END PGP SIGNATURE----- From leaf at real-time.com Tue Jan 5 13:54:22 2010 From: leaf at real-time.com (Rick Tanner) Date: Tue, 05 Jan 2010 13:54:22 -0600 Subject: [crossfire] Dialog mode In-Reply-To: <201001051917.10844.nicolas.weeger@laposte.net> References: <201001051917.10844.nicolas.weeger@laposte.net> Message-ID: <4B4398EE.6040901@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/5/10 12:17 PM, Nicolas Weeger wrote: > Hello. > > > I'd like to propose a (menu-driven) dialog mode for players. > Something like what you can find in various RPG games. > > Description: > - started when player says something to a NPC, like now Would the dialog system (at least, initially) work like it does now? Meaning, NPC response is based on key word(s) from the player character? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLQ5jthHyvgBp+vH4RAlNiAJ9GxWjRZHZsyWpOZ99JCxczuTTSUwCgvNVN il8DcYJLowtPBMEjyghiWik= =MG3l -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Tue Jan 5 16:31:31 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 5 Jan 2010 23:31:31 +0100 Subject: [crossfire] NPC respawning In-Reply-To: <4B438FF6.30000@real-time.com> References: <201001051913.34549.nicolas.weeger@laposte.net> <4B438FF6.30000@real-time.com> Message-ID: <201001052331.34768.nicolas.weeger@laposte.net> > So the tavern owner would never respawn .. ever? That's the subject of this thread :) > What about making the NPC un-attackable or immune to all attacks? => unkillable. > Going with you preferred option listed above.. what happens when that > NPC dies for some reason? Another nearby NPC is created? Yes, a NPC is created nearby (in the same building for a tavern, for instance), after some delay. > What happens if the entire tavern population is wiped out from a > misfired spell or marauding player? Depends on the role this tavern plays, and the various NPCs. If random NPCs, they'll respawn maybe later. If "special" NPCs (dragon emissary?), then after some time there should be a similar one. Of course it really depends on the context. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100105/f440fbd4/attachment.pgp From nicolas.weeger at laposte.net Tue Jan 5 16:34:00 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 5 Jan 2010 23:34:00 +0100 Subject: [crossfire] Dialog mode In-Reply-To: <4B4398EE.6040901@real-time.com> References: <201001051917.10844.nicolas.weeger@laposte.net> <4B4398EE.6040901@real-time.com> Message-ID: <201001052334.00750.nicolas.weeger@laposte.net> > Would the dialog system (at least, initially) work like it does now? > > Meaning, NPC response is based on key word(s) from the player character? Yes, probably keywords. Though the player wouldn't use the 'say' command, but click on the selected reply in the dialog. Game-wise the player will see eg 'you say azerty' while other players will see 'player says azerty to NPC'. Or the text could be changed ('you nod'), like what I started to do with the @question @reply system. This could also add more options ('give an item', 'drop an item' [NPC says you 'can't enter library without letting bag outside'], and so on) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100105/f9e42596/attachment.pgp From mwedel at sonic.net Wed Jan 6 00:36:19 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 05 Jan 2010 22:36:19 -0800 Subject: [crossfire] NPC respawning In-Reply-To: <201001052331.34768.nicolas.weeger@laposte.net> References: <201001051913.34549.nicolas.weeger@laposte.net> <4B438FF6.30000@real-time.com> <201001052331.34768.nicolas.weeger@laposte.net> Message-ID: <4B442F63.1010003@sonic.net> Having the NPC's be unkillable is the easiest approach - all that is needed is set up of proper immunities, etc to do so. Having new ones spawn is reasonable, but I then start wondering what do we really get from that vs making them unkillable? If the bar tender is killed and in a minute a new one shows up with all the same information, not sure what letting them kill gains us. Sure, it may be more realistic, but having a new person show up isn't, so your trade one point of realism for another. If anything, if people kept getting killed in a tavern, you'd think people would actually stay away from it. I'd think both of these cases would not really alter the case of maps resetting - if map resets for whatever reason, tavern would go back to default setup. One could even see the tavern closing down (people can not enter it), which would force a reset sooner. Could be said that new workers need to be found, damage repaired, etc. I'm not really adverse to any of them - it just seems like writing respawn code could be a fair amount of work. One thing to keep in mind is that a solution that can only be done in maps is best - I know that not everyone knows the scripting system, so I could imagine some folks wouldn't bother with the scripting work. From a maintenance point, if changing the conversation of an NPC means having to load up the map, see that it points to a script, go to that script, and then update it, that also becomes a bit more of a pain. I wonder if instead the NPC's could somehow be stored/associated with the map, and there is a script that goes and places them (during initial load an periodically during the life of the map). For example, on a special space (or maybe as a new map property) the different NPC's are stored. Maybe even several different ones with similar messages, but the NPC's themselves could be different. Lets say there are 50 such NPC's stored away. During initial load, based on some parameter, 20 of those NPC's are copied and placed onto the map. The script that takes care of these periodically runs to make sure that there are always about 20 NPC's on the map. If one dies, it goes and places one on the map again. There would be code that makes sure the same NPC is not placed twice. One could even extend this so that NPC's come and go - maybe some NPC's wander away, and are replaced by other ones - also adds some flavor (the NPC that told you about the tower a day ago isn't around anymore, but may show up again down the road). What is also perhaps interesting is that since which NPCs are on the map, what information is present may also change. For example, of those 20 NPC's chosen, maybe 2 of them have basically the same information about some tower. But maybe the NPC with information about a dungeon is not about. Now I'm not sure if this approach is easier or harder. A plus here is that all conversation is stored on the map, not in scripts - the script is just used for the placement (and maybe having NPC's wander about). So a person without any scripting knowledge could add new NPC's and have them behave like the rest. From mwedel at sonic.net Wed Jan 6 00:43:54 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 05 Jan 2010 22:43:54 -0800 Subject: [crossfire] Dialog mode In-Reply-To: <201001052334.00750.nicolas.weeger@laposte.net> References: <201001051917.10844.nicolas.weeger@laposte.net> <4B4398EE.6040901@real-time.com> <201001052334.00750.nicolas.weeger@laposte.net> Message-ID: <4B44312A.6090601@sonic.net> Nicolas Weeger wrote: >> Would the dialog system (at least, initially) work like it does now? >> >> Meaning, NPC response is based on key word(s) from the player character? > > Yes, probably keywords. > Though the player wouldn't use the 'say' command, but click on the selected > reply in the dialog. > Game-wise the player will see eg 'you say azerty' while other players will > see 'player says azerty to NPC'. Or the text could be changed ('you nod'), > like what I started to do with the @question @reply system. > > This could also add more options ('give an item', 'drop an item' [NPC says > you 'can't enter library without letting bag outside'], and so on) > I like it. I've never really liked the somewhat random approach right now of trying to figure out what keywords the NPC is looking for. Do you imagine do this by scripts, or extending the msg/endmsg logic? A complication for something like player giving items to NPC is that option can really only be available if the player has that item, but this starts needing some scripting logic to basically say 'only present this option to player if...' But a general approach could probably be done with something like: @match hello I know about all sorts of interesting monsters and dungeons @reply monsters dungeons @match dungeons .... That would cover a large amount of desired conversations - I'd think the give/take items would be a fairly small number and requiring scripts for those might be reasonable. But I wonder if something @script tags could be added to allow for calling general purpose scripts. From om at iki.fi Thu Jan 7 05:02:34 2010 From: om at iki.fi (Otto J. Makela) Date: Thu, 07 Jan 2010 13:02:34 +0200 Subject: [crossfire] NPC respawning In-Reply-To: <4B442F63.1010003@sonic.net> References: <201001051913.34549.nicolas.weeger@laposte.net> <4B438FF6.30000@real-time.com> <201001052331.34768.nicolas.weeger@laposte.net> <4B442F63.1010003@sonic.net> Message-ID: <4B45BF4A.3080802@iki.fi> Mark Wedel wrote: > One could even see the tavern closing down (people can not enter it), which > would force a reset sooner. Could be said that new workers need to be found, > damage repaired, etc. I assume this would apply also to stores where the merchant is represented by a NPC inside the store (for example in Pupland)? Sounds like it could be a possibility for players to get stuck inside "closed" locations without normal players being able to help them from the outside. Tread carefully unless we are sure none contain structures (like door mechanisms which can only be opened from one side or that require payment or special items) where one can get stuck. Maybe players could be ejected from the area when this happens, but this is again a bit risky as some special stores have monsters etc. around them? Apropos, have we been thinking of general solutions to situations like this, even spells like word of recall (which not all players have) can be unusable in no spells areas? For example, I've once become stuck inside the Devourers' temple cellar, when I mistakenly re-flipped the door opening lever and ran through the closing door into the vampire hideout. Yes, I can see how having a lever also on the inside would mean the curious vampires would sooner than later use it, but it was a bit of a bummer being stuck in there with vampires on the outside (so I could not just create a new character to open the door), and nobody else on the game to give me a hand... -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From mwedel at sonic.net Fri Jan 8 00:17:24 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 07 Jan 2010 22:17:24 -0800 Subject: [crossfire] NPC respawning In-Reply-To: <4B45BF4A.3080802@iki.fi> References: <201001051913.34549.nicolas.weeger@laposte.net> <4B438FF6.30000@real-time.com> <201001052331.34768.nicolas.weeger@laposte.net> <4B442F63.1010003@sonic.net> <4B45BF4A.3080802@iki.fi> Message-ID: <4B46CDF4.9000406@sonic.net> Otto J. Makela wrote: > Mark Wedel wrote: > >> One could even see the tavern closing down (people can not enter it), which >> would force a reset sooner. Could be said that new workers need to be found, >> damage repaired, etc. > > I assume this would apply also to stores where the merchant is represented by > a NPC inside the store (for example in Pupland)? I would think so. > > Sounds like it could be a possibility for players to get stuck inside "closed" > locations without normal players being able to help them from the outside. Some mechanism to relocate players, etc, would probably be needed. But this is a complicated situation - for some of the reasons you mention. But also some taverns/shops/whatnot also have dungeons beneath them - it wouldn't be too uncommon for someone to be in those dungeons with their exit (to the tavern) now closed. In retrospect, closing the building probably isn't a good idea, as it could also be used as a DOS attack by players, eg, player goes in, kills some NPC's, gets kicked out of the building, when it reopens, he repeats,and effectively the building is never usable by anyone. > > Tread carefully unless we are sure none contain structures (like door > mechanisms which can only be opened from one side or that require payment or > special items) where one can get stuck. Maybe players could be ejected from > the area when this happens, but this is again a bit risky as some special > stores have monsters etc. around them? > > Apropos, have we been thinking of general solutions to situations like this, > even spells like word of recall (which not all players have) can be unusable > in no spells areas? For example, I've once become stuck inside the Devourers' > temple cellar, when I mistakenly re-flipped the door opening lever and ran > through the closing door into the vampire hideout. Yes, I can see how having a > lever also on the inside would mean the curious vampires would sooner than > later use it, but it was a bit of a bummer being stuck in there with vampires > on the outside (so I could not just create a new character to open the door), > and nobody else on the game to give me a hand... There are probably many areas where players can become stuck. Some are intentional, most are probably bugs. A solution is also to just log out, and after some amount of time, if you log back in, you'll be back at your last savebed location. Annoying, especially if you want to play the game - you don't have to wait an hour (I'm not sure if that is the time limit) before coming back in. It probably wouldn't be too hard to add some ingame command to do that - something like 'returnhome' (better name needed). Put a 60 second (or something) timer on it, so you can't use it to immediately get out of combat/death. One could also make it so you can't do any movement/combat/spellcasting during that sixty seconds either - otherwise the returnhome is cancelled. In that way, you can't use it to prepare for combat/something dangerous. There may be a few maps where getting out is meant to be the hard/dangerous part (I think the power crystal map/fire temple is such a case), but with the savebed reset, there are already ways around it - it just takes an hour to wait for the reset. However, in most cases, buggy maps should be identified and fixed - put a lever on both sides of the door. In that vampire example, the vampires could be modified so they don't activate the levers - IIRC, one of the flags controls that, and it could just be cleared. > From nicolas.weeger at laposte.net Sat Jan 9 09:12:20 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jan 2010 16:12:20 +0100 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <4B2B02C5.1090803@sonic.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <200912172253.30346.nicolas.weeger@laposte.net> <4B2B02C5.1090803@sonic.net> Message-ID: <201001091612.25055.nicolas.weeger@laposte.net> > True - there is no migration plan/support. However, there are some > number of servers right now that running trunk bits. > > But maybe we just state all trunk servers must convert over, and let them > deal with any conflicts they have on their own. As I see it, first will be server-side support (which you started to implement), then client-side. So let's add a new "use_account" SETUP setting sent by clients. If set, use account mode, then use regular/current player login. Obviously add options in account management to link an character to an account :) And after some time remove legacy support. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100109/e4603cb4/attachment.pgp From nicolas.weeger at laposte.net Sat Jan 9 09:15:33 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jan 2010 16:15:33 +0100 Subject: [crossfire] Dialog mode In-Reply-To: <4B44312A.6090601@sonic.net> References: <201001051917.10844.nicolas.weeger@laposte.net> <201001052334.00750.nicolas.weeger@laposte.net> <4B44312A.6090601@sonic.net> Message-ID: <201001091615.33077.nicolas.weeger@laposte.net> > I like it. I've never really liked the somewhat random approach right > now of trying to figure out what keywords the NPC is looking for. > > Do you imagine do this by scripts, or extending the msg/endmsg logic? Right now there is some support for that already. So it would be a matter of extending the client support, and adding some glue for NPCs themselves - so they don't move when talked to for some time. After that, of course, if the editor has a nice interface to edit, it'd be great - but that's secondary. > A complication for something like player giving items to NPC is that > option can really only be available if the player has that item, but this > starts needing some scripting logic to basically say 'only present this > option to player if...' > > But a general approach could probably be done with something like: > > @match hello > I know about all sorts of interesting monsters and dungeons > @reply monsters dungeons > @match dungeons That is already done, almost, through @reply and @question. > That would cover a large amount of desired conversations - I'd think the > give/take items would be a fairly small number and requiring scripts for > those might be reasonable. But I wonder if something @script tags could be > added to allow for calling general purpose scripts. I strongly oppose that @script idea. If you want scripting, use Python or do your own plugin - through the event_say archetype. We don't need yet another way to call a script :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100109/106a3f4e/attachment.pgp From nicolas.weeger at laposte.net Sat Jan 9 09:20:13 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jan 2010 16:20:13 +0100 Subject: [crossfire] NPC respawning In-Reply-To: <4B46CDF4.9000406@sonic.net> References: <201001051913.34549.nicolas.weeger@laposte.net> <4B45BF4A.3080802@iki.fi> <4B46CDF4.9000406@sonic.net> Message-ID: <201001091620.13929.nicolas.weeger@laposte.net> > > I assume this would apply also to stores where the merchant is > > represented by a NPC inside the store (for example in Pupland)? > > I would think so. Actually I haven't thought of that. Or at least killing the merchant wouldn't close the shop. > Some mechanism to relocate players, etc, would probably be needed. But > this is a complicated situation - for some of the reasons you mention. But > also some taverns/shops/whatnot also have dungeons beneath them - it > wouldn't be too uncommon for someone to be in those dungeons with their > exit (to the tavern) now closed. > > In retrospect, closing the building probably isn't a good idea, as it > could also be used as a DOS attack by players, eg, player goes in, kills > some NPC's, gets kicked out of the building, when it reopens, he > repeats,and effectively the building is never usable by anyone. So what? One can already do a DOS on maps anyway :) And anyway I don't plan on letting NPCs be killed without bad consequences for the player! > > Apropos, have we been thinking of general solutions to situations like > > this, even spells like word of recall (which not all players have) can be > > unusable in no spells areas? For example, I've once become stuck inside > > the Devourers' temple cellar, when I mistakenly re-flipped the door > > opening lever and ran through the closing door into the vampire hideout. > > Yes, I can see how having a lever also on the inside would mean the > > curious vampires would sooner than later use it, but it was a bit of a > > bummer being stuck in there with vampires on the outside (so I could not > > just create a new character to open the door), and nobody else on the > > game to give me a hand... > > There are probably many areas where players can become stuck. Some are > intentional, most are probably bugs. All should be fixed, IMO - players shouldn't be trapped. Exception would be maps specifically and explicitely for many players, where doors depend on other players triggering some things. And still you should be able to get out if needed. > It probably wouldn't be too hard to add some ingame command to do that - > something like 'returnhome' (better name needed). Put a 60 second (or > something) timer on it, so you can't use it to immediately get out of > combat/death. One could also make it so you can't do any > movement/combat/spellcasting during that sixty seconds either - otherwise > the returnhome is cancelled. In that way, you can't use it to prepare for > combat/something dangerous. Overkill, IMO. > However, in most cases, buggy maps should be identified and fixed - put a > lever on both sides of the door. In that vampire example, the vampires > could be modified so they don't activate the levers - IIRC, one of the > flags controls that, and it could just be cleared. Put a lever behind a destructible wall, put a "emergency door opening" sign, and open the door when lever is pulled - and don't forget to teleport/create monsters too, to make the player pay the emergency price :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100109/1f6ffea2/attachment.pgp From nicolas.weeger at laposte.net Sat Jan 9 09:24:23 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jan 2010 16:24:23 +0100 Subject: [crossfire] NPC respawning In-Reply-To: <4B442F63.1010003@sonic.net> References: <201001051913.34549.nicolas.weeger@laposte.net> <201001052331.34768.nicolas.weeger@laposte.net> <4B442F63.1010003@sonic.net> Message-ID: <201001091624.23536.nicolas.weeger@laposte.net> > Having new ones spawn is reasonable, but I then start wondering what do > we really get from that vs making them unkillable? If the bar tender is > killed and in a minute a new one shows up with all the same information, > not sure what letting them kill gains us. Sure, it may be more realistic, > but having a new person show up isn't, so your trade one point of realism > for another. If anything, if people kept getting killed in a tavern, you'd > think people would actually stay away from it. Yes, actually. If someone is killed in a tavern, NPCs should either flee or fight the killer. And then guards should be called. And the killer should be unable to enter various shops for some time. Though of course if you kill the magical shop merchant, maybe you'll get rewarded (by an item, a special thing) by the holy priest of Gorokh of the town because he hated him! > I'd think both of these cases would not really alter the case of maps > resetting - if map resets for whatever reason, tavern would go back to > default setup. > > One could even see the tavern closing down (people can not enter it), > which would force a reset sooner. Could be said that new workers need to > be found, damage repaired, etc. I was thinking of a delay before a new NPC appears - transmission time? > I'm not really adverse to any of them - it just seems like writing > respawn code could be a fair amount of work. One thing to keep in mind is > that a solution that can only be done in maps is best - I know that not > everyone knows the scripting system, so I could imagine some folks wouldn't > bother with the scripting work. > > From a maintenance point, if changing the conversation of an NPC means > having to load up the map, see that it points to a script, go to that > script, and then update it, that also becomes a bit more of a pain. > > I wonder if instead the NPC's could somehow be stored/associated with the > map, and there is a script that goes and places them (during initial load > an periodically during the life of the map). Yes, I was thinking of handling NPCs plugin-side directly, for those reasons. And also because it's IMO the easiest way to "link" characters, have interaction between them / the actions of the player. > Now I'm not sure if this approach is easier or harder. A plus here is > that all conversation is stored on the map, not in scripts - the script is > just used for the placement (and maybe having NPC's wander about). So a > person without any scripting knowledge could add new NPC's and have them > behave like the rest. Could be done, for some NPCs, yes. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100109/5549905c/attachment.pgp From mwedel at sonic.net Sat Jan 9 13:17:18 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Jan 2010 11:17:18 -0800 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <201001091612.25055.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <200912172253.30346.nicolas.weeger@laposte.net> <4B2B02C5.1090803@sonic.net> <201001091612.25055.nicolas.weeger@laposte.net> Message-ID: <4B48D63E.6070607@sonic.net> Nicolas Weeger wrote: >> True - there is no migration plan/support. However, there are some >> number of servers right now that running trunk bits. >> >> But maybe we just state all trunk servers must convert over, and let them >> deal with any conflicts they have on their own. > > As I see it, first will be server-side support (which you started to > implement), then client-side. > So let's add a new "use_account" SETUP setting sent by clients. If set, use > account mode, then use regular/current player login. > Obviously add options in account management to link an character to an > account :) Yep - that is my next step or work. The only complication in all of this is player name uniqueness. If we go by the idea of storing player files as lower case names, so there can only be one 'Mark' player on a server, regardless of capitalization (mark, mArk, etc), ideally you want to convert all existing player files to be all lower case. Otherwise you could get the case where I create a new character, and it is called Mark, and the save file is Mark.pl Now somone else goes and creates a character called mark, save file mark.pl. Because the existing save fail is not in all lowercase, the second one is valid. Now I can think of various ways to handle this - all new characters have save files all in lower case, but if old characters, we have legacy support and look for them in upper case. I'd rather just write a conversion script and tell server admins to run it, so we don't have to have that code around, which we know would only be used for transition. > > And after some time remove legacy support. The problems we run into is that tends not to be done/not clear what 'some time' is. 6 months? 3 years? But there are really 2 cases of legacy supported needed - legacy support for login without the account support (for old clients), and player file naming. The second one, as I note above, can be eliminated with some scripts. The first one probably needs some support - maybe 6 months after we release a client that supports it? From nicolas.weeger at laposte.net Sat Jan 9 16:20:26 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jan 2010 23:20:26 +0100 Subject: [crossfire] Conventions for exits in town Message-ID: <201001092320.31142.nicolas.weeger@laposte.net> Hello. To have some coherence in maps in town, I'd like to suggest the following rules for exits: - in the world map, you need to apply an exit to enter the map - in a town map, exit is applied automatically when you step on it Does that sound ok? Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100109/e93f8d1d/attachment.pgp From om at iki.fi Sat Jan 9 20:40:52 2010 From: om at iki.fi (Otto J. Makela) Date: Sun, 10 Jan 2010 04:40:52 +0200 Subject: [crossfire] Conventions for exits in town In-Reply-To: <201001092320.31142.nicolas.weeger@laposte.net> References: <201001092320.31142.nicolas.weeger@laposte.net> Message-ID: <4B493E34.2050400@iki.fi> Nicolas Weeger wrote: > To have some coherence in maps in town, I'd like to suggest the following > rules for exits: > - in the world map, you need to apply an exit to enter the map > - in a town map, exit is applied automatically when you step on it > > Does that sound ok? I'd say this depends on how the town sub-map you are exiting is built, either including the house surroundings or just an interior view. If there is a door icon, you would obviously want it to work only when applied, but if there is an "whirlwind" exit (or an hidden exit, for example under pavement) you wouldn't want to need to apply it. If you want to be consistent, you need to edit lots of town views, creating surroundings for each house to be able to use the hidden exit strategy. Which reminds me, who remembers far back to when you were a beginner? Did you find it confusing in the world map the way some of the 2?2 houses have a "roof" area you cannot walk over, even though some of the larger buildings like keeps and temples do not have this limitation? I also found it a bit confusing that there are statues and lampposts which do block your way and identical-looking ones which do not do that. PS. Easiest solution to create an "panic exit" for the Devourers underground is just to hide it under a generator, that way the vampires won't activate it. I didn't realize vampires will by default also dig through weak walls :-/ Now, where does one submit map updates? -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From mwedel at sonic.net Sun Jan 10 21:31:17 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 10 Jan 2010 19:31:17 -0800 Subject: [crossfire] Conventions for exits in town In-Reply-To: <201001092320.31142.nicolas.weeger@laposte.net> References: <201001092320.31142.nicolas.weeger@laposte.net> Message-ID: <4B4A9B85.1000504@sonic.net> Nicolas Weeger wrote: > Hello. > > To have some coherence in maps in town, I'd like to suggest the following > rules for exits: > - in the world map, you need to apply an exit to enter the map That sounds good. > - in a town map, exit is applied automatically when you step on it I take that to mean that this is the exit in the building/shop/whatever that leads back out onto the world map? Might need to be careful about that - I could see some situations where the player is placed on the exit, but doesn't want to leave the building (eg, using the shop mat, and the only available place in the exit space, etc). Also, what about dungeons within the town (basement in goth's tavern for example)? I'm not wild about that being automatically applied when one steps on it. I think as much as anything else, the meaning of the exit (based on appearance) should be consistent. For example, stairs no matter where they are, should require an explicit apply to use them Oak doors could always be auto apply, etc. Buildings are always explicit apply, and so on. So as a player, if I see an oakdoor, I know what it will (or won't do) no matter where I am. Beyond that, having more consistency based on location sounds good. It may just mean updating all the maps to have the appropriate exit for their location. From nicolas.weeger at laposte.net Thu Jan 14 16:04:36 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Jan 2010 23:04:36 +0100 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <4B48D63E.6070607@sonic.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <201001091612.25055.nicolas.weeger@laposte.net> <4B48D63E.6070607@sonic.net> Message-ID: <201001142304.42845.nicolas.weeger@laposte.net> > Yep - that is my next step or work. > > The only complication in all of this is player name uniqueness. If we go > by the idea of storing player files as lower case names, so there can only > be one 'Mark' player on a server, regardless of capitalization (mark, mArk, > etc), ideally you want to convert all existing player files to be all lower > case. Seems ok by me - any storage mechanism is ok as long as it works :) > The problems we run into is that tends not to be done/not clear what > 'some time' is. 6 months? 3 years? Add near your checking code: if (current_date() >= "may 2010") { LOG(llevError, "obsolete code detected!\n"); exit(5); } Issue solved :) > But there are really 2 cases of legacy supported needed - legacy support > for login without the account support (for old clients), and player file > naming. No account support shouldn't be too hard to compensate. Clients can reply to arbitrary "queries", IIRC - so just emulate accounts through that. > The second one, as I note above, can be eliminated with some scripts. > The first one probably needs some support - maybe 6 months after we release > a client that supports it? If it's on the trunk branch, I'd suggest to remove it after some days only. Trunk is supposed to be unstable. Or, another option I'd prefer, we forget 1.x, declare current trunk 2.0, and then start fixing stuff. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100114/dd3f008a/attachment.pgp From nicolas.weeger at laposte.net Thu Jan 14 16:09:18 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Jan 2010 23:09:18 +0100 Subject: [crossfire] Conventions for exits in town In-Reply-To: <4B493E34.2050400@iki.fi> References: <201001092320.31142.nicolas.weeger@laposte.net> <4B493E34.2050400@iki.fi> Message-ID: <201001142309.18643.nicolas.weeger@laposte.net> > I'd say this depends on how the town sub-map you are exiting is built, > either including the house surroundings or just an interior view. > > If there is a door icon, you would obviously want it to work only > when applied, but if there is an "whirlwind" exit (or an hidden exit, > for example under pavement) you wouldn't want to need to apply it. > > If you want to be consistent, you need to edit lots of town views, > creating surroundings for each house to be able to use the hidden > exit strategy. I'm ok with doors you have to apply. And obviously hidden exits are applied automatically, yes :) > Which reminds me, who remembers far back to when you were a beginner? > Did you find it confusing in the world map the way some of the 2?2 > houses have a "roof" area you cannot walk over, even though some of > the larger buildings like keeps and temples do not have this limitation? > I also found it a bit confusing that there are statues and lampposts > which do block your way and identical-looking ones which do not do that. That is indeed confusing. IMO, statues you can walk on - else how could you see the bigger picture of the statue? :D As for buildings, things like view restrictions were introduced, IIRC, to give more depth. For blocking, yes, that could be removed. > PS. Easiest solution to create an "panic exit" for the Devourers > underground is just to hide it under a generator, that way the vampires > won't activate it. I didn't realize vampires will by default also dig > through weak walls :-/ Now, where does one submit map updates? No idea whether vampires actually attack weak walls or not :) But under generator should be ok, yes. For the patch, submit to http://sourceforge.net/tracker/?atid=313833&group_id=13833&func=browse [and send a mail here to warn of it, so it doesn't get forgotten!] or send directly to this list. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100114/37fb764b/attachment.pgp From nicolas.weeger at laposte.net Thu Jan 14 16:12:11 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Jan 2010 23:12:11 +0100 Subject: [crossfire] Conventions for exits in town In-Reply-To: <4B4A9B85.1000504@sonic.net> References: <201001092320.31142.nicolas.weeger@laposte.net> <4B4A9B85.1000504@sonic.net> Message-ID: <201001142312.11305.nicolas.weeger@laposte.net> > I think as much as anything else, the meaning of the exit (based on > appearance) should be consistent. Yes, indeed. > For example, stairs no matter where they are, should require an explicit > apply to use them > > Oak doors could always be auto apply, etc. Buildings are always explicit > apply, and so on. I'd say explicit apply for all things you'd expect to use/apply in real life: doors, stairs, ladders, boats, ... On the other hands, things like teleporters, shop mats, whirlwind exits aren't expected to need to be applied, IMO. > So as a player, if I see an oakdoor, I know what it will (or won't do) no > matter where I am. > > Beyond that, having more consistency based on location sounds good. It > may just mean updating all the maps to have the appropriate exit for their > location. Yes, some massive update :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100114/4857ba6a/attachment.pgp From nicolas.weeger at laposte.net Thu Jan 14 16:26:44 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Jan 2010 23:26:44 +0100 Subject: [crossfire] TODO list Message-ID: <201001142326.47886.nicolas.weeger@laposte.net> Hello. Considering the low feedback/participation on the list, I'm totally changing how I work :) I've put my plans for the future at http://wiki.metalforge.net/doku.php/user:ryo:todo and I intend to do them, except maybe the "Various" ones. If you have questions, feel free to ask me (this list or privately), but else I'll just implement as I see fit and discuss after if needed :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100114/c578d8e4/attachment.pgp From crystalmir at gmail.com Thu Jan 14 21:20:57 2010 From: crystalmir at gmail.com (Dany Talbot) Date: Thu, 14 Jan 2010 22:20:57 -0500 Subject: [crossfire] TODO list In-Reply-To: <201001142326.47886.nicolas.weeger@laposte.net> References: <201001142326.47886.nicolas.weeger@laposte.net> Message-ID: <9739c5511001141920x2f6e36f0g292b485759848473@mail.gmail.com> "move to Qt/C++, to not reinvent the wheel all the time; and massively clean the code" such as this: (naive draft) (the object superstructure need to be separated into a base 'object' class - and then you'd have God : Object inheriting from it and adding stuff specific to God that are in the former object superstructure in the C code. Also I didn't check the code to rework the function parameters - that is why it is called a naive draft). #include #include #include #include #include #include // TODO: other includes /* TODO: move * Compares 2 strings. * @param s1 * @param s2 * strings to compare. * @return * 1 if s1 and s2 are the same - either both NULL, or strcmp( ) == 0. static int same_string(const char *s1, const char *s2) { if (s1 == NULL) return s2 == NULL; else return s2 != NULL && strcmp(s1, s2) == 0; } to an utility function/class */ class God : Object { public: // default constructor Gods(); // default destructor ~Gods(); // operator overload '==' // operator overload '=' // accesors // modifiers Archetype *determine_holy_arch(const Object *god, std::string type); const God *find_god(std::string name); const std::string determine_god(Object *op); int become_follower(Object *op, const Object *new_god); int tailor_god_spell(Object *spellop, Object *caster); void pray_at_altar(Object *pl, Object *altar, Object *skill); private: const std::string get_god_for_race(std::string race); int _follower_has_similar_item(Object *op, Object *item); int _follower_level_to_enchantments(int level, int difficulty); int _god_enchants_weapon(Object *op, const Object *god, Object *tr, Object *skill); int _god_examines_item(const Object *god, Object *item); int _god_examines_priest(Object *op, const Object *god); int _god_gives_present(Object *op, const Object *god, Treasure *tr); int _god_removes_curse(Object *op, int remove_damnation); int _improve_weapon_magic(Object *op, Object *tr, Object *weapon, Object *skill); int _lookup_god_by_name(std::string name); int _worship_forbids_use(Object *op, Object *exp_obj, uint32 flag, const std::string string); void _follower_remove_given_items(Object *pl, Object *op, const Object *god); void _god_intervention(Object *op, const Object *god, Object *skill); void _remove_special_prayers(Object *op, const Object *god); void _stop_using_item(Object *op, int type, int number); void _update_priest_flag(const Object *god, Object *exp_ob, uint32 flag); }; On Thu, Jan 14, 2010 at 5:26 PM, Nicolas Weeger wrote: > Hello. > > Considering the low feedback/participation on the list, I'm totally changing > how I work :) > > > I've put my plans for the future at > http://wiki.metalforge.net/doku.php/user:ryo:todo and I intend to do them, > except maybe the "Various" ones. > > If you have questions, feel free to ask me (this list or privately), but else > I'll just implement as I see fit and discuss after if needed :) > > > > Nicolas > -- > http://nicolas.weeger.org [Mon p'tit coin du web] > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- Dany Talbot, Quebec, Canada [ Crystalmir at gmail.com ] "Per aspera ad astra" From mwedel at sonic.net Fri Jan 15 01:24:03 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 14 Jan 2010 23:24:03 -0800 Subject: [crossfire] TODO list In-Reply-To: <9739c5511001141920x2f6e36f0g292b485759848473@mail.gmail.com> References: <201001142326.47886.nicolas.weeger@laposte.net> <9739c5511001141920x2f6e36f0g292b485759848473@mail.gmail.com> Message-ID: <4B501813.9020607@sonic.net> Dany Talbot wrote: > "move to Qt/C++, to not reinvent the wheel all the time; and massively > clean the code" I know someone sort of looked into doing crossfire in C++ several years back. Their opinion was it was probably easier to start writing the code from scratch vs trying to convert the existing code. I haven't looked at it enough to say for sure, but I could certainly see it may be easier to start from scratch but keep in archetype/map/player/protocol compatible. On the same basis, one could use that to clean up lots of bits of code that are their for compatibility reasons or because that is the way things should work - one could actually define how those things should work. But I suspect the stuff under Various is low priority - for the most part it cleans things up for developers, but doesn't really change the experience for players. As for other points - pretty much agree with them all. One question/comment however about: reduce food supply, like divide by 10 the current values?, to give more interest to food - right now it?s useless Most RPG's don't really concern themselves with the player needing to feed themselves. And in fact food as a rapidly decrease attribute is I'm sure something that dates back to early versions of crossfire, which were much more gauntlet based than an RPG. I wonder if part of reducing that food supply, of the food attribute should just be removed, and the sole purpose of food is to give various benefits, like some of the special foods do right now (give some healing, resistances, etc, for some time). Most normal food could be removed, except for dungeon dressing and perhaps some quests. Dying as starvation because you can't find food has to be one of the suckiest ways to die. And having to carry around huge quantities of food because you are going into a deep dungeon is also somewhat annoying (more annoying is realizing you are about out of food, have to abandon the dungeon, go back, get some more, etc). I guess my question would be whether food as a core stat really adds much to the game or is as much a headache as anything else. From mwedel at sonic.net Fri Jan 15 01:29:47 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 14 Jan 2010 23:29:47 -0800 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <201001142304.42845.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <201001091612.25055.nicolas.weeger@laposte.net> <4B48D63E.6070607@sonic.net> <201001142304.42845.nicolas.weeger@laposte.net> Message-ID: <4B50196B.5050403@sonic.net> Nicolas Weeger wrote: > > >> The problems we run into is that tends not to be done/not clear what >> 'some time' is. 6 months? 3 years? > > Add near your checking code: > if (current_date() >= "may 2010") { > LOG(llevError, "obsolete code detected!\n"); > exit(5); > } > > Issue solved :) I wonder if you could do that if #ifdef's :) > > >> But there are really 2 cases of legacy supported needed - legacy support >> for login without the account support (for old clients), and player file >> naming. > > No account support shouldn't be too hard to compensate. > Clients can reply to arbitrary "queries", IIRC - so just emulate accounts > through that. Yeah, no account support isn't hard, because that basically just uses the code that is there instead of the new code. So very simple, it is just having some legacy code sit around. > > >> The second one, as I note above, can be eliminated with some scripts. >> The first one probably needs some support - maybe 6 months after we release >> a client that supports it? > > If it's on the trunk branch, I'd suggest to remove it after some days only. > Trunk is supposed to be unstable. Fair enough. I was thinking of going through and cleaning up a bunch of the protocol stuff - there are like 20 different setup options. Some are actual choices (mapsize, do you want lighting, etc). But a fair a number are related to protocol versions (I support these protocol commands - use them if possible) > > > Or, another option I'd prefer, we forget 1.x, declare current trunk 2.0, and > then start fixing stuff. That may not be a bad idea. It's been a _long_ time since any official release. I don't think 2.0 is ready right now for a release, but the amount of cleanup/fixes probably isn't huge. From mwedel at sonic.net Fri Jan 15 01:38:34 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 14 Jan 2010 23:38:34 -0800 Subject: [crossfire] Conventions for exits in town In-Reply-To: <201001142312.11305.nicolas.weeger@laposte.net> References: <201001092320.31142.nicolas.weeger@laposte.net> <4B4A9B85.1000504@sonic.net> <201001142312.11305.nicolas.weeger@laposte.net> Message-ID: <4B501B7A.9050608@sonic.net> Nicolas Weeger wrote: >> For example, stairs no matter where they are, should require an explicit >> apply to use them >> >> Oak doors could always be auto apply, etc. Buildings are always explicit >> apply, and so on. > > I'd say explicit apply for all things you'd expect to use/apply in real life: > doors, stairs, ladders, boats, ... > On the other hands, things like teleporters, shop mats, whirlwind exits aren't > expected to need to be applied, IMO. And some things may be explicit just based on what they are. Things like pits you don't have much choice of - if there is a pit under you, you are falling. A question might be whether are exits, whether auto apply or not, should in general be visible. If you need to apply it, that is clearly the case, but for auto apply, it is more a question - on some maps, (front gate to scorn being one example) the exits are invisible and applied automatically. There are also some houses same way - you can't see the exits - you just happen to step on the right space and are back home. I'm sort of the opinion that all exits (unless meant to be hidden, like pit traps) should be visible. The reason for this is that exits are a game mechanism - its nice to know what will cause you to move from one place to the next. In real life (I know, always a bad example), when I leave my house and walk to the curb, I don't suddenly warp from one map to another as I get to the curb - it is a continuous flow. But in crossfire, you do suddenly get popped from one map to another, and that can be somewhat jarring. > > >> So as a player, if I see an oakdoor, I know what it will (or won't do) no >> matter where I am. >> >> Beyond that, having more consistency based on location sounds good. It >> may just mean updating all the maps to have the appropriate exit for their >> location. > > Yes, some massive update :) First step would be to make the archetypes consistent, which may now mean there are some duplicate archetypes. And writing scripts to find exits on maps which are changing the move_on would be easy enough. The hard part would be examining all of those to see if changing them to default (based on that exit) is reasonable - there could be some cases on why it was done some way, and changing it another way sort of break things. The other time consuming part is the standardization of exits (making all town exits oak doors). But I imagine something like 'sed s/invisible exit/oakdoor/' would take care of that pretty easily. From mwedel at sonic.net Fri Jan 15 01:55:28 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 14 Jan 2010 23:55:28 -0800 Subject: [crossfire] TODO list In-Reply-To: <201001142326.47886.nicolas.weeger@laposte.net> References: <201001142326.47886.nicolas.weeger@laposte.net> Message-ID: <4B501F70.3060704@sonic.net> Nicolas Weeger wrote: > Hello. > > Considering the low feedback/participation on the list, I'm totally changing > how I work :) > Seems like a reasonable idea. I've made a list of stuff I plan to work on - I put it at: http://wiki.metalforge.net/doku.php/user:mwedel:todo Plus side is there doesn't seem to be much overlap between our lists. From nicolas.weeger at laposte.net Fri Jan 15 12:16:32 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 15 Jan 2010 19:16:32 +0100 Subject: [crossfire] TODO list In-Reply-To: <4B501813.9020607@sonic.net> References: <201001142326.47886.nicolas.weeger@laposte.net> <9739c5511001141920x2f6e36f0g292b485759848473@mail.gmail.com> <4B501813.9020607@sonic.net> Message-ID: <201001151916.35966.nicolas.weeger@laposte.net> > I know someone sort of looked into doing crossfire in C++ several years > back. Their opinion was it was probably easier to start writing the code > from scratch vs trying to convert the existing code. I haven't looked at > it enough to say for sure, but I could certainly see it may be easier to > start from scratch but keep in archetype/map/player/protocol compatible. > On the same basis, one could use that to clean up lots of bits of code that > are their for compatibility reasons or because that is the way things > should work - one could actually define how those things should work. Around one year ago I and another did an experiment converting to C++ and introducing Qt. It was never completed, mind you (but as a by-product there is the CRE tool in utils/), but it wasn't *too* bad to do. Making it build C++ mode was like 2h work. Introducing classes did take more time, though, but was doable too. I could probably dig the source code if needed, even if it is obsolete by now. Oh, and it did have dynamic archetype loading ;) (ie change an archetype in the tree, it'd pick up the change a few seconds later - worked for faces at least) But maybe yes rethinking the whole game architecture could be done taking the opportunity. Of course, not a 2 days project. And we would need to know the focus - modular design? robuste? performant? (and see next reply :)) > But I suspect the stuff under Various is low priority - for the most part > it cleans things up for developers, but doesn't really change the > experience for players. Correct. Various is more 'in some years', or 'never'. C++/Qt would be a real time-saver in the long run - don't have to redefine shared strings, many many "free" stuff - threads, sockets, and such. And using a tested library. But the first topic for me is gameplay / content. As long as no one is seriously working on that, I'll not do much on code, I think. Unless I get seriously bored with reinventing the wheel and just introduce Qt to have basic functions - and not change the current non class mode. But I wouldn't do that without having a consensus on the list - worse case I'd make my own branch and work still on content :) > I guess my question would be whether food as a core stat really adds much > to the game or is as much a headache as anything else. IMO it adds some fun. And you could still eat some raw meat from monsters, when they give some. And you could introduce some fun diseases related to food - "hum, that cow steak was good... err, why are you feeling crazy, suddenly?" Or it could just be used to regenerate sp. But right now it's useless. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100115/1cb45d38/attachment.pgp From nicolas.weeger at laposte.net Fri Jan 15 12:29:20 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 15 Jan 2010 19:29:20 +0100 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <4B50196B.5050403@sonic.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <201001142304.42845.nicolas.weeger@laposte.net> <4B50196B.5050403@sonic.net> Message-ID: <201001151929.24030.nicolas.weeger@laposte.net> > I wonder if you could do that if #ifdef's :) Why #ifdef's? Just put the check in the code, at least it won't be forgotten! > Yeah, no account support isn't hard, because that basically just uses the > code that is there instead of the new code. So very simple, it is just > having some legacy code sit around. Yup. > Fair enough. I was thinking of going through and cleaning up a bunch of > the protocol stuff - there are like 20 different setup options. Some are > actual choices (mapsize, do you want lighting, etc). But a fair a number > are related to protocol versions (I support these protocol commands - use > them if possible) Seems ok. And while we're at it, let's ensure documentation is uptodate! :) > That may not be a bad idea. It's been a _long_ time since any official > release. I don't think 2.0 is ready right now for a release, but the > amount of cleanup/fixes probably isn't huge. Then let's do 2.0rc1, and see what needs cleaning. Concentrating on serious issues first, and just declare "2.0 is the first in a branch of major changes, expect some issues to be around" :) Related, maybe the various trackers (bug, patch, feature request) could be pruned / cleaned. Much stuff is really obsolete, I think. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100115/3817bcab/attachment.pgp From crystalmir at gmail.com Fri Jan 15 12:52:00 2010 From: crystalmir at gmail.com (Dany Talbot) Date: Fri, 15 Jan 2010 13:52:00 -0500 Subject: [crossfire] TODO list In-Reply-To: <201001151916.35966.nicolas.weeger@laposte.net> References: <201001142326.47886.nicolas.weeger@laposte.net> <9739c5511001141920x2f6e36f0g292b485759848473@mail.gmail.com> <4B501813.9020607@sonic.net> <201001151916.35966.nicolas.weeger@laposte.net> Message-ID: <9739c5511001151052l46559f87k60140cd3f9ddc4c4@mail.gmail.com> What would be redone with Qt ? anything GUI-related ? so the client(s) [which ones? cfclient ?] the map editors [which ones? cfeditor? or the java one or the gtk one?]? would you need/want to add some sort of server admin console? On Fri, Jan 15, 2010 at 1:16 PM, Nicolas Weeger wrote: >> ? I know someone sort of looked into doing crossfire in C++ several years >> back. Their opinion was it was probably easier to start writing the code >> from scratch vs trying to convert the existing code. ?I haven't looked at >> it enough to say for sure, but I could certainly see it may be easier to >> start from scratch but keep in archetype/map/player/protocol compatible. >> On the same basis, one could use that to clean up lots of bits of code that >> are their for compatibility reasons or because that is the way things >> should work - one could actually define how those things should work. > > Around one year ago I and another did an experiment converting to C++ and > introducing Qt. > It was never completed, mind you (but as a by-product there is the CRE tool in > utils/), but it wasn't *too* bad to do. > Making it build C++ mode was like 2h work. Introducing classes did take more > time, though, but was doable too. > > I could probably dig the source code if needed, even if it is obsolete by now. > Oh, and it did have dynamic archetype loading ;) > (ie change an archetype in the tree, it'd pick up the change a few seconds > later - worked for faces at least) > > > But maybe yes rethinking the whole game architecture could be done taking the > opportunity. > Of course, not a 2 days project. > > And we would need to know the focus - modular design? robuste? performant? > > (and see next reply :)) > > > >> ? But I suspect the stuff under Various is low priority - for the most part >> it cleans things up for developers, but doesn't really change the >> experience for players. > > Correct. Various is more 'in some years', or 'never'. > C++/Qt would be a real time-saver in the long run - don't have to redefine > shared strings, many many "free" stuff - threads, sockets, and such. And > using a tested library. > > > But the first topic for me is gameplay / content. As long as no one is > seriously working on that, I'll not do much on code, I think. > > Unless I get seriously bored with reinventing the wheel and just introduce Qt > to have basic functions - and not change the current non class mode. But I > wouldn't do that without having a consensus on the list - worse case I'd make > my own branch and work still on content :) > > > > >> ? I guess my question would be whether food as a core stat really adds much >> to the game or is as much a headache as anything else. > > IMO it adds some fun. > And you could still eat some raw meat from monsters, when they give some. And > you could introduce some fun diseases related to food - "hum, that cow steak > was good... err, why are you feeling crazy, suddenly?" > > Or it could just be used to regenerate sp. > > But right now it's useless. > > > > > Nicolas > -- > http://nicolas.weeger.org [Mon p'tit coin du web] > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- Dany Talbot, Quebec, Canada [ Crystalmir at gmail.com ] "Per aspera ad astra" From agschult at ucalgary.ca Fri Jan 15 12:58:04 2010 From: agschult at ucalgary.ca (Alexander Schultz) Date: Fri, 15 Jan 2010 11:58:04 -0700 Subject: [crossfire] TODO list In-Reply-To: <9739c5511001151052l46559f87k60140cd3f9ddc4c4@mail.gmail.com> References: <201001142326.47886.nicolas.weeger@laposte.net> <9739c5511001141920x2f6e36f0g292b485759848473@mail.gmail.com> <4B501813.9020607@sonic.net> <201001151916.35966.nicolas.weeger@laposte.net> <9739c5511001151052l46559f87k60140cd3f9ddc4c4@mail.gmail.com> Message-ID: <1263581884.19843.1.camel@ict21810.eng.ad.ucalgary.ca> No, not client or GUI-related. Nicolas means to use it as a utility library for C++, along the lines of the "Boost" libraries (which I personally thing are better suited) On Fri, 2010-01-15 at 13:52 -0500, Dany Talbot wrote: > What would be redone with Qt ? anything GUI-related ? so the client(s) > [which ones? cfclient ?] the map editors [which ones? cfeditor? or the > java one or the gtk one?]? would you need/want to add some sort of > server admin console? > > On Fri, Jan 15, 2010 at 1:16 PM, Nicolas Weeger > wrote: > >> I know someone sort of looked into doing crossfire in C++ several years > >> back. Their opinion was it was probably easier to start writing the code > >> from scratch vs trying to convert the existing code. I haven't looked at > >> it enough to say for sure, but I could certainly see it may be easier to > >> start from scratch but keep in archetype/map/player/protocol compatible. > >> On the same basis, one could use that to clean up lots of bits of code that > >> are their for compatibility reasons or because that is the way things > >> should work - one could actually define how those things should work. > > > > Around one year ago I and another did an experiment converting to C++ and > > introducing Qt. > > It was never completed, mind you (but as a by-product there is the CRE tool in > > utils/), but it wasn't *too* bad to do. > > Making it build C++ mode was like 2h work. Introducing classes did take more > > time, though, but was doable too. > > > > I could probably dig the source code if needed, even if it is obsolete by now. > > Oh, and it did have dynamic archetype loading ;) > > (ie change an archetype in the tree, it'd pick up the change a few seconds > > later - worked for faces at least) > > > > > > But maybe yes rethinking the whole game architecture could be done taking the > > opportunity. > > Of course, not a 2 days project. > > > > And we would need to know the focus - modular design? robuste? performant? > > > > (and see next reply :)) > > > > > > > >> But I suspect the stuff under Various is low priority - for the most part > >> it cleans things up for developers, but doesn't really change the > >> experience for players. > > > > Correct. Various is more 'in some years', or 'never'. > > C++/Qt would be a real time-saver in the long run - don't have to redefine > > shared strings, many many "free" stuff - threads, sockets, and such. And > > using a tested library. > > > > > > But the first topic for me is gameplay / content. As long as no one is > > seriously working on that, I'll not do much on code, I think. > > > > Unless I get seriously bored with reinventing the wheel and just introduce Qt > > to have basic functions - and not change the current non class mode. But I > > wouldn't do that without having a consensus on the list - worse case I'd make > > my own branch and work still on content :) > > > > > > > > > >> I guess my question would be whether food as a core stat really adds much > >> to the game or is as much a headache as anything else. > > > > IMO it adds some fun. > > And you could still eat some raw meat from monsters, when they give some. And > > you could introduce some fun diseases related to food - "hum, that cow steak > > was good... err, why are you feeling crazy, suddenly?" > > > > Or it could just be used to regenerate sp. > > > > But right now it's useless. > > > > > > > > > > Nicolas > > -- > > http://nicolas.weeger.org [Mon p'tit coin du web] > > > > _______________________________________________ > > crossfire mailing list > > crossfire at metalforge.org > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > From nicolas.weeger at laposte.net Fri Jan 15 13:18:20 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 15 Jan 2010 20:18:20 +0100 Subject: [crossfire] TODO list In-Reply-To: <1263581884.19843.1.camel@ict21810.eng.ad.ucalgary.ca> References: <201001142326.47886.nicolas.weeger@laposte.net> <9739c5511001151052l46559f87k60140cd3f9ddc4c4@mail.gmail.com> <1263581884.19843.1.camel@ict21810.eng.ad.ucalgary.ca> Message-ID: <201001152018.24140.nicolas.weeger@laposte.net> > No, not client or GUI-related. Nicolas means to use it as a utility > library for C++, along the lines of the "Boost" libraries (which I > personally thing are better suited) Indeed, I meant server-side. Client-side is JXClient IMO :) Nicolas > > On Fri, 2010-01-15 at 13:52 -0500, Dany Talbot wrote: > > What would be redone with Qt ? anything GUI-related ? so the client(s) > > [which ones? cfclient ?] the map editors [which ones? cfeditor? or the > > java one or the gtk one?]? would you need/want to add some sort of > > server admin console? > > > > On Fri, Jan 15, 2010 at 1:16 PM, Nicolas Weeger > > > > wrote: > > >> I know someone sort of looked into doing crossfire in C++ several > > >> years back. Their opinion was it was probably easier to start writing > > >> the code from scratch vs trying to convert the existing code. I > > >> haven't looked at it enough to say for sure, but I could certainly see > > >> it may be easier to start from scratch but keep in > > >> archetype/map/player/protocol compatible. On the same basis, one could > > >> use that to clean up lots of bits of code that are their for > > >> compatibility reasons or because that is the way things should work - > > >> one could actually define how those things should work. > > > > > > Around one year ago I and another did an experiment converting to C++ > > > and introducing Qt. > > > It was never completed, mind you (but as a by-product there is the CRE > > > tool in utils/), but it wasn't *too* bad to do. > > > Making it build C++ mode was like 2h work. Introducing classes did take > > > more time, though, but was doable too. > > > > > > I could probably dig the source code if needed, even if it is obsolete > > > by now. Oh, and it did have dynamic archetype loading ;) > > > (ie change an archetype in the tree, it'd pick up the change a few > > > seconds later - worked for faces at least) > > > > > > > > > But maybe yes rethinking the whole game architecture could be done > > > taking the opportunity. > > > Of course, not a 2 days project. > > > > > > And we would need to know the focus - modular design? robuste? > > > performant? > > > > > > (and see next reply :)) > > > > > >> But I suspect the stuff under Various is low priority - for the most > > >> part it cleans things up for developers, but doesn't really change the > > >> experience for players. > > > > > > Correct. Various is more 'in some years', or 'never'. > > > C++/Qt would be a real time-saver in the long run - don't have to > > > redefine shared strings, many many "free" stuff - threads, sockets, and > > > such. And using a tested library. > > > > > > > > > But the first topic for me is gameplay / content. As long as no one is > > > seriously working on that, I'll not do much on code, I think. > > > > > > Unless I get seriously bored with reinventing the wheel and just > > > introduce Qt to have basic functions - and not change the current non > > > class mode. But I wouldn't do that without having a consensus on the > > > list - worse case I'd make my own branch and work still on content :) > > > > > >> I guess my question would be whether food as a core stat really adds > > >> much to the game or is as much a headache as anything else. > > > > > > IMO it adds some fun. > > > And you could still eat some raw meat from monsters, when they give > > > some. And you could introduce some fun diseases related to food - "hum, > > > that cow steak was good... err, why are you feeling crazy, suddenly?" > > > > > > Or it could just be used to regenerate sp. > > > > > > But right now it's useless. > > > > > > > > > > > > > > > Nicolas > > > -- > > > http://nicolas.weeger.org [Mon p'tit coin du web] > > > > > > _______________________________________________ > > > crossfire mailing list > > > crossfire at metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100115/0155e159/attachment.pgp From mwedel at sonic.net Fri Jan 15 22:45:16 2010 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 15 Jan 2010 20:45:16 -0800 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <201001151929.24030.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <201001142304.42845.nicolas.weeger@laposte.net> <4B50196B.5050403@sonic.net> <201001151929.24030.nicolas.weeger@laposte.net> Message-ID: <4B51445C.8030004@sonic.net> Nicolas Weeger wrote: >> I wonder if you could do that if #ifdef's :) > > Why #ifdef's? > Just put the check in the code, at least it won't be forgotten! I don't like the idea of putting an actual exit in the code or something - that could be pretty annoying if it is a section of code not executed very often, but someone runs into and causes the server to exit (really annoying for server admins who servers suddenly start exiting through no fault of their own) #ifdefs, if done on date, can at least be interesting - if the code ceases to compile, pretty clear something needs to be done, but at least running servers won't be directly affected. I wonder if just standardizing a comment to use might work - something like: /* Removeme - 2010-06-01 ... (not sure if the date should be the time of the comment, or targeted time to remove the code). At least in that way, a simple grep can be used to find all of those, and decide which of them qualify for removal. >> Fair enough. I was thinking of going through and cleaning up a bunch of >> the protocol stuff - there are like 20 different setup options. Some are >> actual choices (mapsize, do you want lighting, etc). But a fair a number >> are related to protocol versions (I support these protocol commands - use >> them if possible) > > Seems ok. And while we're at it, let's ensure documentation is uptodate! :) Yep - I noticed some things fairly out of date. > > > >> That may not be a bad idea. It's been a _long_ time since any official >> release. I don't think 2.0 is ready right now for a release, but the >> amount of cleanup/fixes probably isn't huge. > > Then let's do 2.0rc1, and see what needs cleaning. Concentrating on serious > issues first, and just declare "2.0 is the first in a branch of major > changes, expect some issues to be around" :) The release methodology sort of needs to be sorted out - if we plan to do a lot of cleanup (which may break things), I'd sort of like to do that before the first rc - typically you make an rc when you think you are about ready and are trying to sort out bugs. Otherwise, I could see various servers running that, and then when rc2, suddenly a lot more stuff gets broken because of code cleanup, which isn't really the way to move. > > > Related, maybe the various trackers (bug, patch, feature request) could be > pruned / cleaned. Much stuff is really obsolete, I think. Probably so - and in the case of some patches/contributions, need to figure out if we're going to accept them or not - no reason for them to just sit in limbo. From mwedel at sonic.net Fri Jan 15 22:57:04 2010 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 15 Jan 2010 20:57:04 -0800 Subject: [crossfire] TODO list In-Reply-To: <201001151916.35966.nicolas.weeger@laposte.net> References: <201001142326.47886.nicolas.weeger@laposte.net> <9739c5511001141920x2f6e36f0g292b485759848473@mail.gmail.com> <4B501813.9020607@sonic.net> <201001151916.35966.nicolas.weeger@laposte.net> Message-ID: <4B514720.8030904@sonic.net> Nicolas Weeger wrote: >> I know someone sort of looked into doing crossfire in C++ several years >> back. Their opinion was it was probably easier to start writing the code >> from scratch vs trying to convert the existing code. I haven't looked at >> it enough to say for sure, but I could certainly see it may be easier to >> start from scratch but keep in archetype/map/player/protocol compatible. >> On the same basis, one could use that to clean up lots of bits of code that >> are their for compatibility reasons or because that is the way things >> should work - one could actually define how those things should work. > > Around one year ago I and another did an experiment converting to C++ and > introducing Qt. > It was never completed, mind you (but as a by-product there is the CRE tool in > utils/), but it wasn't *too* bad to do. > Making it build C++ mode was like 2h work. Introducing classes did take more > time, though, but was doable too. I could see that - C code in general should compile under C++, but there may be a few areas where it doesn't. But just making it compile under C++ doesn't get a lot. To be really valuable, conversion to classes, etc, is likely needed, and that is a much bigger project. And the question then is whether it is worth it to try to convert the existing code base (structure by structure) or start with something new, with perhaps lots of copy/pasting, but also proper/better design in how the classes and like interact. > >> But I suspect the stuff under Various is low priority - for the most part >> it cleans things up for developers, but doesn't really change the >> experience for players. > > Correct. Various is more 'in some years', or 'never'. > C++/Qt would be a real time-saver in the long run - don't have to redefine > shared strings, many many "free" stuff - threads, sockets, and such. And > using a tested library. I don't know a lot about Qt, but it looks like the big bonus is better cross platform stuff. POSIX doesn't define everything we use, as evidenced by a fair number of #idef > > > But the first topic for me is gameplay / content. As long as no one is > seriously working on that, I'll not do much on code, I think. I agree that should be primary focus - we can always toss lots of stuff in code, but unless it makes the game better to play, doesn't get us a lot. > >> I guess my question would be whether food as a core stat really adds much >> to the game or is as much a headache as anything else. > > IMO it adds some fun. > And you could still eat some raw meat from monsters, when they give some. And > you could introduce some fun diseases related to food - "hum, that cow steak > was good... err, why are you feeling crazy, suddenly?" > > Or it could just be used to regenerate sp. > > But right now it's useless. The problem is some maps are very food scarce, because of the monsters on them. But maybe this just goes back to me playing a troll character at one time, and having to deal with carrying large amounts of food (due to the trolls bonus is HP regeneration, food usage goes up). Priests at least have the odd case where they can create food. But I guess nethack had food. I think one change, relative to food, is for all flesh type things (which can be eaten as food) should have some time limit where they start to decompose/rot. I shouldn't be able to carry around an ogre leg for a week and eat it like nothing has happened. Just adding some form of rotting would probably reduce available food by a bit. From nicolas.weeger at laposte.net Sat Jan 16 08:30:10 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 16 Jan 2010 15:30:10 +0100 Subject: [crossfire] Quests mechanism ideas Message-ID: <201001161530.14122.nicolas.weeger@laposte.net> Hello. I've dumped at http://wiki.metalforge.net/doku.php/user:ryo:todo#quest_mechanism some ideas for quests mechanisms. I'll first just do the low-level tracking mechanism, then I'll see how to handle things. Comments and ideas welcome :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100116/4a180a8a/attachment.pgp From mwedel at sonic.net Sat Jan 16 14:08:13 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 16 Jan 2010 12:08:13 -0800 Subject: [crossfire] Quests mechanism ideas In-Reply-To: <201001161530.14122.nicolas.weeger@laposte.net> References: <201001161530.14122.nicolas.weeger@laposte.net> Message-ID: <4B521CAD.5030506@sonic.net> Nicolas Weeger wrote: > Hello. > > I've dumped at > http://wiki.metalforge.net/doku.php/user:ryo:todo#quest_mechanism some ideas > for quests mechanisms. > > > I'll first just do the low-level tracking mechanism, then I'll see how to > handle things. > > > Comments and ideas welcome :) My quick thoughts: - Yes, there should be some in game mechanism to see quests I've signed up for. This is purely a convenience function - sure, in real life, there isn't a list floating about saying everything I have to do, but this is a game. If there is no such list, then more likely I'll end up having to write stuff down out of game, which IMO isn't good. In the past some folks have said that crossfire should be more immersive and played full screen, but if in order to track stuff I need to record things out of game, that will remove some of the immersion. Note that some of the quests may be more or less explicit in what to do. I could imagine some NPC saying 'if you kill a bunch of orcs, I'll do ...'. Under a quest, that could be listed as something like 'orc bounty', and description is to kill a bunch of orcs, but up to player to figure out how to do that, and may have to explicitly go back to the quest giver to see if they have done a sufficient job. I'd note that alchemy currently has this problem - if you find a formula, you need to record it out of game, which IMO isn't good. - For active quests, probably easiest to only do one active one, if that is giving hints (like map locations). Otherwise, if you are trying to give map locations for 3 different ones, you need some way to clarify what hint is for what quest. OTOH, this could be more a client/interface issue. The quest information as transmitted to the client could contain this map hint, but it is up to the client to know how to display it, and if it can display multiple points at once, maybe let it do so? I guess the question might be whether the server actually cares what the active quest is or not. - One other note, which isn't listed, but isn't not listed either - multiple exclusion quests. Eg, both the fighter and wizard guild may have a quest to do something, but because they are competing interests, should only be possible to complete one of them. What this means: - It may be possible to get both of them given to you, but once you complete one of them, the other is automatically removed from lists of quests. - If you have completed one of them, you can't get assigned the other one. - Last point: It may be worthwhile to note if a quest is repeatable or single instance. I'd think most can only be done once, but I could imagine a few where you could repeatedly do so. Maybe this is just a definition of quest states. From nicolas.weeger at laposte.net Sun Jan 17 05:15:02 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 17 Jan 2010 12:15:02 +0100 Subject: [crossfire] Alchemy tweaks Message-ID: <201001171215.05911.nicolas.weeger@laposte.net> Hello. I added 3 fields for alchemy formulae, 'min_level', 'failure_arch' and 'failure_message'. Description is in related file. I also changed the recipe of 'mushroom of Gourmet' to yield ashes instead of blowing up or other nasty things in case of failure. Min_level isn't used yet. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100117/8733c247/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 17 09:28:37 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 17 Jan 2010 16:28:37 +0100 Subject: [crossfire] Quest support Message-ID: <201001171628.41672.nicolas.weeger@laposte.net> Hello. I just added a basic low-level quest state information storage mechanism (whao, *that* is a great name for a poor code :)) From the documentation: ******************************************************************* Quest support information ------------------------- Current quest support is low-level only. That is the server provides routines to query and store quest status, and that's all. It is the responsibility of the quest writer to call the functions, hook what needs to be handled, and such. The server does no internal state check, and it doesn't know how to handle anything except the status. Currently, a quest is composed of: - an internal code, which should be unique - a player title, a short sentence describing the quest - a longer description of the quest - the current player state (integer value, any positive value is ok, quest-specific meaning) - the current state description for the player, so she knows what to do next The information is stored in the player's directory, in a file named .quest File is saved at each state modification, to ensure consistency. ******************************************************************* Functions are in server/quest.c One quest was written for Darcap, and is handled in the cf_darcap plugin. Now, if someone were ambitious, a quest engine could be written to handle common quest styles. I'd see some rudimentary scripting engine interpreting a pseudo-XML file, something like that... But well, maybe for another time ;) If you need help writing a quest, don't hesitate to ping me. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100117/340fe8b8/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 17 11:19:49 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 17 Jan 2010 18:19:49 +0100 Subject: [crossfire] use_skill change proposal Message-ID: <201001171819.53005.nicolas.weeger@laposte.net> Hello. Proposed change for 'use_skill' behaviour for alchemy-like skills: - remove the item identification part; use_skill only attempts alchemy (or equivalent) - add a new 'identify' command, that will identify based on (alchemy-like) skills the player knows Comments? Opinions? Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100117/bea4df40/attachment.pgp From om at iki.fi Sun Jan 17 18:32:17 2010 From: om at iki.fi (Otto J. Makela) Date: Mon, 18 Jan 2010 02:32:17 +0200 Subject: [crossfire] use_skill change proposal In-Reply-To: <201001171819.53005.nicolas.weeger@laposte.net> References: <201001171819.53005.nicolas.weeger@laposte.net> Message-ID: <4B53AC11.2050209@iki.fi> Nicolas Weeger wrote: > Proposed change for 'use_skill' behaviour for alchemy-like skills: > - remove the item identification part; use_skill only attempts alchemy (or > equivalent) > - add a new 'identify' command, that will identify based on (alchemy-like) > skills the player knows Using that word would probably cause no end of confusion, as there are already numerous magicks (both object-based and skill-based) called "identify". How about using an somewhat obscure word for it, like "determinate"? -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From om at iki.fi Sun Jan 17 19:22:13 2010 From: om at iki.fi (Otto J. Makela) Date: Mon, 18 Jan 2010 03:22:13 +0200 Subject: [crossfire] Dragons, throwing skill and limitations Message-ID: <4B53B7C5.4040706@iki.fi> If a dragon acquires a throwing skill, the items they end up throwing at their enemies from their inventory are random, as they cannot wield the items they want to be thrown. This does not really make much sense, the fact that one does not have the anatomy for swords etc. doesn't mean one can't select what items to throw at enemies? PS. If dragons don't have hands (the logic behind "no swords", I think), where do they wear their rings? And why do dragon monsters often leave swords when you kill them? PPS. How about a "ring/amulet of extra ring fingers" (and if cursed, remove ability to use two rings), or would that affect game balance too much? -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From om at iki.fi Sun Jan 17 19:24:19 2010 From: om at iki.fi (Otto J. Makela) Date: Mon, 18 Jan 2010 03:24:19 +0200 Subject: [crossfire] Added exit lever to Devourer's temple lower level Message-ID: <4B53B843.8000508@iki.fi> I submitted as patch 2934041 to sourceforge the micro-change to add an exit lever to the alcove in the Devourer's temple lower level. -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From agschult at ucalgary.ca Sun Jan 17 20:05:34 2010 From: agschult at ucalgary.ca (Alex Schultz) Date: Sun, 17 Jan 2010 19:05:34 -0700 Subject: [crossfire] Dragons, throwing skill and limitations In-Reply-To: <4B53B7C5.4040706@iki.fi> References: <4B53B7C5.4040706@iki.fi> Message-ID: <20100117190534.23305b74@ucalgary.ca> One can choose what to throw with dragons actually. You need to 'mark' the item, which if I remember correctly is done with either shift-middle-click or the 'mark' command. Throwing the wielded item is simply the fallback when no item is marked. On Mon, 18 Jan 2010 03:22:13 +0200 "Otto J. Makela" wrote: > If a dragon acquires a throwing skill, the items they end up throwing > at their enemies from their inventory are random, as they cannot > wield the items they want to be thrown. This does not really make > much sense, the fact that one does not have the anatomy for swords > etc. doesn't mean one can't select what items to throw at enemies? > > PS. If dragons don't have hands (the logic behind "no swords", I > think), where do they wear their rings? And why do dragon monsters > often leave swords when you kill them? > > PPS. How about a "ring/amulet of extra ring fingers" (and if cursed, > remove ability to use two rings), or would that affect game balance > too much? > From mwedel at sonic.net Sun Jan 17 22:05:41 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 17 Jan 2010 20:05:41 -0800 Subject: [crossfire] use_skill change proposal In-Reply-To: <201001171819.53005.nicolas.weeger@laposte.net> References: <201001171819.53005.nicolas.weeger@laposte.net> Message-ID: <4B53DE15.2050309@sonic.net> Nicolas Weeger wrote: > Hello. > > Proposed change for 'use_skill' behaviour for alchemy-like skills: > - remove the item identification part; use_skill only attempts alchemy (or > equivalent) > - add a new 'identify' command, that will identify based on (alchemy-like) > skills the player knows I'm presuming you are saying that the same skill, like now, has multiple ways to be used, and different commands should be used. I'm not sure if I like that as much vs adding options to use_skill to denote how you want to use it. Maybe something like 'use_skill smithery identify'. An advantage here is that if there are yet other ways to use skills, we're not creating new commands to use them (which then probably just call the same skill routine with different parameters). Also, what about skills that don't have an identification component (meditation comes to mind, but search is also there) - do you still use use_skill for those? I'd think you would, but it sort of means use_skill has a bunch of different functionalities, and it is unclear what the default should really be (I'd sort of argue that one is more likely to be identifying items than crafting stuff) In an ideal world, the players should really never need to know that arcane usage - the client should provide some mechanism for them to do that (nothing would actually prevent players from using those explicit commands, but probably not the best user to have to have players to know that they should do use_skill even right now. I'm quite sure how to do it, but one could click on the skill name in the client and it would to the appropriate action (or if a skill has multiple ways to be used, bring up a menu asking them how they want to use it). The hard part for that right now would be communicating to the client what skills have what actions (it wouldn't be too hard to hard code in values, but that is sure to break down the road). If we are going to keep in those commands that players need to issue, I'd prefer for them to have some semblance to natural english language. For example, 'cast fireball' or 'use_skill smithery' seem, while a bit verbose, seem somewhat natural. 'identify smithery' would seem to suggest something different from a pure language perspective. From mwedel at sonic.net Sun Jan 17 22:15:49 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 17 Jan 2010 20:15:49 -0800 Subject: [crossfire] Dragons, throwing skill and limitations In-Reply-To: <4B53B7C5.4040706@iki.fi> References: <4B53B7C5.4040706@iki.fi> Message-ID: <4B53E075.30206@sonic.net> Otto J. Makela wrote: > > PS. If dragons don't have hands (the logic behind "no swords", I think), > where do they wear their rings? And why do dragon monsters often leave swords > when you kill them? People have suggested all sorts of places where dragons may put those rings - tail, horns, etc. While dragons can't use weapons, based on shape of hands being unable to properly grasp them, that doesn't necessary mean they could manage to put some rings on their claws. > > PPS. How about a "ring/amulet of extra ring fingers" (and if cursed, remove > ability to use two rings), or would that affect game balance too much? Anything that gives characters a benefit with no drawback affects balance. Adding an amulet that uses the amulet spot but gives them another ring location may be OK, especially if it has some nominal item power value. But if you just had a ring, which if when put on you now have 4 locations for rings (so you get 3 rings in addition to that one), such an item probably needs a decent item power - otherwise it probably does become too powerful. Cursed items really don't have too much impact in the game - too easy to wait until you get back to town to see what is and is not cursed, and also even if you do put on something cursed, usually not that hard to get a remove curse or something. I'm not quite sure how to fix that - I had suggested in the distant past that spellbooks could be cursed, and if you read them, you'll lose that spell (as a problem right now is that trying to read a spellbook is an easy way to identify it) - but with that change, I suspect players will just wait until they can properly detect curse on items. It's interesting that a lot of commercial RPG's don't have cursed items - maybe simply because of the reasons mentioned - if you have a way to know what is cursed, you'll just wait for that. And if you don't, then you're just saying that players will be screwed 10% (or however often cursed stuff shows up) of the time. From nicolas.weeger at laposte.net Mon Jan 18 11:31:20 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jan 2010 18:31:20 +0100 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <4B51445C.8030004@sonic.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <201001151929.24030.nicolas.weeger@laposte.net> <4B51445C.8030004@sonic.net> Message-ID: <201001181831.23755.nicolas.weeger@laposte.net> > I don't like the idea of putting an actual exit in the code or something > - that could be pretty annoying if it is a section of code not executed > very often, but someone runs into and causes the server to exit (really > annoying for server admins who servers suddenly start exiting through no > fault of their own) > > #ifdefs, if done on date, can at least be interesting - if the code > ceases to compile, pretty clear something needs to be done, but at least > running servers won't be directly affected. > > I wonder if just standardizing a comment to use might work - something > like: > > /* Removeme - 2010-06-01 > ... > > (not sure if the date should be the time of the comment, or targeted time > to remove the code). At least in that way, a simple grep can be used to > find all of those, and decide which of them qualify for removal. I was thinking of an exit() in the main() function directly, with a pointer to the code to remove :p > The release methodology sort of needs to be sorted out - if we plan to do > a lot of cleanup (which may break things), I'd sort of like to do that > before the first rc - typically you make an rc when you think you are about > ready and are trying to sort out bugs. > > Otherwise, I could see various servers running that, and then when rc2, > suddenly a lot more stuff gets broken because of code cleanup, which isn't > really the way to move. We need someone willing to decide what needs to be fixed, and enforce the rules, create branches, things like that. Though to be honest, I'd suggest we just take current code, label it "1.90", and see what happens. > Probably so - and in the case of some patches/contributions, need to > figure out if we're going to accept them or not - no reason for them to > just sit in limbo. Yup, not nice for people. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100118/feeb9e21/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 18 11:33:44 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jan 2010 18:33:44 +0100 Subject: [crossfire] TODO list In-Reply-To: <4B514720.8030904@sonic.net> References: <201001142326.47886.nicolas.weeger@laposte.net> <201001151916.35966.nicolas.weeger@laposte.net> <4B514720.8030904@sonic.net> Message-ID: <201001181833.44376.nicolas.weeger@laposte.net> > I don't know a lot about Qt, but it looks like the big bonus is better > cross platform stuff. POSIX doesn't define everything we use, as evidenced > by a fair number of #idef Forgot but you also gain multilinguage support through a nice mechanism - tr("Your text with %1").args(parameter), making it easy to see texts instead of obscure constants. > I agree that should be primary focus - we can always toss lots of stuff > in code, but unless it makes the game better to play, doesn't get us a lot. Yep, that's why C++ is in my "various" list. > The problem is some maps are very food scarce, because of the monsters on > them. But maybe this just goes back to me playing a troll character at one > time, and having to deal with carrying large amounts of food (due to the > trolls bonus is HP regeneration, food usage goes up). > > Priests at least have the odd case where they can create food. But I > guess nethack had food. > > I think one change, relative to food, is for all flesh type things (which > can be eaten as food) should have some time limit where they start to > decompose/rot. I shouldn't be able to carry around an ogre leg for a week > and eat it like nothing has happened. Just adding some form of rotting > would probably reduce available food by a bit. Rotting could be fun, but depending on implementation you'd have multiple food parts similar but not merging because "dropped-tick" isn't the same... As for trolls, that's one disadvantage they have - need MUCH food. On the opposite, Devourer adepts almost don't use food... Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100118/cb29d3b8/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 18 11:39:47 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jan 2010 18:39:47 +0100 Subject: [crossfire] Quests mechanism ideas In-Reply-To: <4B521CAD.5030506@sonic.net> References: <201001161530.14122.nicolas.weeger@laposte.net> <4B521CAD.5030506@sonic.net> Message-ID: <201001181839.47703.nicolas.weeger@laposte.net> > - Yes, there should be some in game mechanism to see quests I've signed up > for. This is purely a convenience function - sure, in real life, there > isn't a list floating about saying everything I have to do, but this is a > game. If there is no such list, then more likely I'll end up having to > write stuff down out of game, which IMO isn't good. In the past some folks > have said that crossfire should be more immersive and played full screen, > but if in order to track stuff I need to record things out of game, that > will remove some of the immersion. Done for quests. Coming soon for more general knowledge. And hopefully client-side explicite interfaces could be added to make it more game-like and less text-like. > Note that some of the quests may be more or less explicit in what to do. > I could imagine some NPC saying 'if you kill a bunch of orcs, I'll do ...'. > Under a quest, that could be listed as something like 'orc bounty', and > description is to kill a bunch of orcs, but up to player to figure out how > to do that, and may have to explicitly go back to the quest giver to see if > they have done a sufficient job. Up to the quest designer :) > I'd note that alchemy currently has this problem - if you find a formula, > you need to record it out of game, which IMO isn't good. Will be fixed as soon as I clean my code :) > - For active quests, probably easiest to only do one active one, if that > is giving hints (like map locations). Otherwise, if you are trying to give > map locations for 3 different ones, you need some way to clarify what hint > is for what quest. Yup. > OTOH, this could be more a client/interface issue. The quest information > as transmitted to the client could contain this map hint, but it is up to > the client to know how to display it, and if it can display multiple points > at once, maybe let it do so? Yup too. > I guess the question might be whether the server actually cares what the > active quest is or not. Right now, no - quest functions I added a low-level, and don't concern at all with this kind of things. > - One other note, which isn't listed, but isn't not listed either - > multiple exclusion quests. Eg, both the fighter and wizard guild may have > a quest to do something, but because they are competing interests, should > only be possible to complete one of them. What this means: > - It may be possible to get both of them given to you, but once you > complete one of them, the other is automatically removed from lists of > quests. - If you have completed one of them, you can't get assigned the > other one. Quest design issue, up to quest writers :) > - Last point: It may be worthwhile to note if a quest is repeatable or > single instance. I'd think most can only be done once, but I could imagine > a few where you could repeatedly do so. Maybe this is just a definition of > quest states. Same, up to quest writers :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100118/99300a73/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 18 11:44:25 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jan 2010 18:44:25 +0100 Subject: [crossfire] use_skill change proposal In-Reply-To: <4B53DE15.2050309@sonic.net> References: <201001171819.53005.nicolas.weeger@laposte.net> <4B53DE15.2050309@sonic.net> Message-ID: <201001181844.25895.nicolas.weeger@laposte.net> > I'm presuming you are saying that the same skill, like now, has multiple > ways to be used, and different commands should be used. I'm talking about alchemy-like spells, actually. The proposed change is for those skills to only do alchemy and not identification, and add a new 'identify' *global* command which will identify based on all skills at once. This avoids the need to add a 'bind use_skill thaumaturgy ; use_skill alchemy ; use_skill woodsman' and change it for each skill :) > Maybe something like 'use_skill smithery identify'. An advantage here is > that if there are yet other ways to use skills, we're not creating new > commands to use them (which then probably just call the same skill routine > with different parameters). It'd split the code between alchemy-like use and identification use. > Also, what about skills that don't have an identification component > (meditation comes to mind, but search is also there) - do you still use > use_skill for those? I'd think you would, but it sort of means use_skill > has a bunch of different functionalities, and it is unclear what the > default should really be (I'd sort of argue that one is more likely to be > identifying items than crafting stuff) Not concerned, right now - only alchemy-like skills. > In an ideal world, the players should really never need to know that > arcane usage - the client should provide some mechanism for them to do that > (nothing would actually prevent players from using those explicit commands, > but probably not the best user to have to have players to know that they > should do use_skill even right now. Yes, but we're not yet in an ideal world :) > I'm quite sure how to do it, but one could click on the skill name in the > client and it would to the appropriate action (or if a skill has multiple > ways to be used, bring up a menu asking them how they want to use it). The > hard part for that right now would be communicating to the client what > skills have what actions (it wouldn't be too hard to hard code in values, > but that is sure to break down the road). I'd even go as far as saying to have the available options for any item - drop, apply, and such. Though it could restrain creativity - who would think of applying a key [which when applied spawns a strange monster asking for a riddle and rewarding you if you reply corrctly]? > If we are going to keep in those commands that players need to issue, I'd > prefer for them to have some semblance to natural english language. > > For example, 'cast fireball' or 'use_skill smithery' seem, while a bit > verbose, seem somewhat natural. 'identify smithery' would seem to suggest > something different from a pure language perspective. I'd just go with 'identify' and the server would use all available skills. It's pretty rare imo to want to only use one skill for identification purposes. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100118/2e631651/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 18 11:46:35 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jan 2010 18:46:35 +0100 Subject: [crossfire] Dragons, throwing skill and limitations In-Reply-To: <4B53E075.30206@sonic.net> References: <4B53B7C5.4040706@iki.fi> <4B53E075.30206@sonic.net> Message-ID: <201001181846.35299.nicolas.weeger@laposte.net> > I'm not quite sure how to fix that - I had suggested in the distant past > that spellbooks could be cursed, and if you read them, you'll lose that > spell (as a problem right now is that trying to read a spellbook is an easy > way to identify it) - but with that change, I suspect players will just > wait until they can properly detect curse on items. That's actually implemented :) Cursed/blessed items. Read a cursed spellbook, 20% chance to lose the known spell. For scrolled, blessed means a small chance the scroll doesn't turn to dust. > It's interesting that a lot of commercial RPG's don't have cursed items - > maybe simply because of the reasons mentioned - if you have a way to know > what is cursed, you'll just wait for that. And if you don't, then you're > just saying that players will be screwed 10% (or however often cursed stuff > shows up) of the time. Probably 'detect curse' should be reduced, something like that, then. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100118/bff652ae/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 18 15:08:48 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jan 2010 22:08:48 +0100 Subject: [crossfire] Player knowledge management Message-ID: <201001182208.51682.nicolas.weeger@laposte.net> Hello. I just committed the framework for player knowledge management. For now it only tracks alchemy formulas, but it shouldn't be hard (or I made a design mistake!) to extend to monsters, and other information thought to be relevant to track. This commit introduces the new 'knowledge' command, which with a 'list' parameter lists all known knowledge items, and 'show ' displays details of the item. No more wondering what ingredients are needed for a formula, as long as you found it ingame :) Enjoy. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100118/c698a6d1/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 18 15:41:31 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jan 2010 22:41:31 +0100 Subject: [crossfire] Offering to implement quests Message-ID: <201001182241.35018.nicolas.weeger@laposte.net> Hello. Right now, implementing quests can be pretty hard, since it can mean scripting / coding, things like that. Therefore I hereby volunteer to implement, totally or partially, quest ideas you could have :) My conditions: - I'll implement only if and when I feel like it, obviously ;) - I may suggest changes, or help tweak the quest if needed - you'll get credit for the quest idea; if that's ok, I'll get credit for implementing / helping implement it - I'll implement however I feel like, be it scripts, plugins, server side changes, ... What I expect from you dear reader: quests ideas! By 'idea' I mean a reasonable subpart of: - a quest description - "the search for the pain killer" - the various quest steps: "talk to the old man, he'll ask you to go fetch his much needed potion against back aches from the nearest potion shop; if you accept, the quests starts"; go to potion shop, talk to the vendor who'll give you the potion; give it to the old man who'll thank you - whether the quest has various branches, incompatible choices, things like that - the expected quest reward: "the old man thanks you and gives you 3 gold coins - you feel cheated" - whether the quest can be done again and again, and in such cases if the reward should change, or required condition to (re)start (eg player lost the reward, and can get it again) - 'failure' conditions: what happens if the player destroys the item she must bring back? talk to last NPC who'll give another one? restart quest from scratch? fail quest? (I'm not favoring that last option) - incompatibility with quests already done (you can't have a quest having you kill an NPC and another having you protect it), or time of the day the quest can start, in short 'quest start conditions' Please remember the following rules when thinking about stuff: A quest should be FUN, and IMAGINATIVE! **************************************** "kill ogre nearby" is not fun. "I was finishing a thesis demonstrating that the gods we know are only humans like us, though in another dimension, but a gust of wind dispatched all my scrolls around, and I saw a troll take a few sheet, please recover them for me as it's the work of my life!" can be fun, especially if it implies having to find the Legendary Time Machine (Reduced Version Limited to One Use), which is just big enough to contain the final (and most decisive, of course) sheet of paper which had ink spilled on by the troll - alas, the sheet was blank from the start, and the NPC forgot the conclusion in the shock of having his work lost. Quest reward(s) shouldn't be overpowered/unbalanced **************************************************** not getting 110 levels worth of experience for bringing a mere potion without any challenge. Note that a reward could be exp for a skill, a skill, a spell, some ingame knowledge, access to specific place(s), some item with specific properties, you imagine it, I'll figure a way to do it - if it's fun! (example: the book for the 'Unforgettable Banquet of Lursendis') Extra points for: - reusing an existing map, giving it some background story / some interest besides pure hack and slash - giving dialogs needed for the quest, fun ones if possible - but keep coherent with the game mood, unless you give good reasons - providing required pics/archetypes if applicable - you definitely don't want to have me draw the picture! - using or linking with lore on the wiki, or even adding new one - fun ideas, of course :) Feel free to contact me, on the list, the forum, publically or in private, if you do have quest ideas :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100118/903ee5fa/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 18 16:54:45 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jan 2010 23:54:45 +0100 Subject: [crossfire] Added exit lever to Devourer's temple lower level In-Reply-To: <4B53B843.8000508@iki.fi> References: <4B53B843.8000508@iki.fi> Message-ID: <201001182354.52696.nicolas.weeger@laposte.net> > I submitted as patch 2934041 to sourceforge the micro-change to add > an exit lever to the alcove in the Devourer's temple lower level. Applied to SVN trunk, thanks :) (if someone could close the patch on SF: https://sourceforge.net/tracker/?func=detail&aid=2934041&group_id=13833&atid=313833 ) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100118/6ae044ad/attachment.pgp From agschult at ucalgary.ca Mon Jan 18 18:31:03 2010 From: agschult at ucalgary.ca (Alex Schultz) Date: Mon, 18 Jan 2010 17:31:03 -0700 Subject: [crossfire] TODO list In-Reply-To: <201001181833.44376.nicolas.weeger@laposte.net> References: <201001142326.47886.nicolas.weeger@laposte.net> <201001151916.35966.nicolas.weeger@laposte.net> <4B514720.8030904@sonic.net> <201001181833.44376.nicolas.weeger@laposte.net> Message-ID: <20100118173103.67b139e9@ucalgary.ca> On Mon, 18 Jan 2010 18:33:44 +0100 Nicolas Weeger wrote: > > I think one change, relative to food, is for all flesh type > > things (which can be eaten as food) should have some time limit > > where they start to decompose/rot. I shouldn't be able to carry > > around an ogre leg for a week and eat it like nothing has > > happened. Just adding some form of rotting would probably reduce > > available food by a bit. > > > Rotting could be fun, but depending on implementation you'd have > multiple food parts similar but not merging because "dropped-tick" > isn't the same... We could always implement "multiple timeouts" for objects that would in this case specify how many were dropped on a given tick... not sure it's worth the bother, but just noting that that isn't an insurmountable issue. > As for trolls, that's one disadvantage they have - need MUCH food. On > the opposite, Devourer adepts almost don't use food... Expand cooking to allow players to salt the meats and such? Perhaps make weight-reduction-enchanted containers have some kind of partial preservative magic? That would help trolls :) From mwedel at sonic.net Mon Jan 18 20:20:21 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 18 Jan 2010 18:20:21 -0800 Subject: [crossfire] Cursed items In-Reply-To: <201001181846.35299.nicolas.weeger@laposte.net> References: <4B53B7C5.4040706@iki.fi> <4B53E075.30206@sonic.net> <201001181846.35299.nicolas.weeger@laposte.net> Message-ID: <4B5516E5.9040900@sonic.net> Nicolas Weeger wrote: >> I'm not quite sure how to fix that - I had suggested in the distant past >> that spellbooks could be cursed, and if you read them, you'll lose that >> spell (as a problem right now is that trying to read a spellbook is an easy >> way to identify it) - but with that change, I suspect players will just >> wait until they can properly detect curse on items. > > That's actually implemented :) > Cursed/blessed items. Read a cursed spellbook, 20% chance to lose the known > spell. > For scrolled, blessed means a small chance the scroll doesn't turn to dust. Good to know. >> It's interesting that a lot of commercial RPG's don't have cursed items - >> maybe simply because of the reasons mentioned - if you have a way to know >> what is cursed, you'll just wait for that. And if you don't, then you're >> just saying that players will be screwed 10% (or however often cursed stuff >> shows up) of the time. > > > Probably 'detect curse' should be reduced, something like that, then. Even if the spell (and skill) were removed, it probably wouldn't mean much so long as the detect curse tables still exist. I think one problem is that players acquire so many items on an even normal outing that it is a sure thing that at least some of them are cursed. Right now, the people that usually seem to get hit by cursed items are new players who don't have the resources to get rid of them and don't know that it is fairly easy to know what is and is not cursed. Couple thoughts come to mind: - Reduce occurrence of cursed items greatly (<=1% of items). In this way, it would be fairly rare for players to find cursed items. - Remove detect curse methods or make them much more expensive (identify will continue to work) That may make it worth it for players to try to equip items (instead of identifying them) when they sell them, since they get more money but don't have to pay for the identify. Even if cursed items are impossible to identify, I suspect players will just wait until they are in town to see what they are - It would such to use one in a dungeon and find out you are in bad shape because you are stuck wearing crappy armor. Live action RPG tends to have cursed items because the GM can control when the curse takes effect - there is no way to detect it, and usually manifests itself only in life or death situations. A more interesting approach in crossfire is that curses are undetectable, but in rare circumstances the item does something unexpected. For example, a cursed wand might 5% of the time fire in the wrong/random direction. A player may still find that wand useful. Weapons could suddenly disintegrate, but until it does so, may be a nice weapon (and when it does fall apart, just means the player needs to equip something else) So in other words, cursed items still have some positive use - they aren't all bad. From mwedel at sonic.net Mon Jan 18 20:37:25 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 18 Jan 2010 18:37:25 -0800 Subject: [crossfire] TODO list In-Reply-To: <20100118173103.67b139e9@ucalgary.ca> References: <201001142326.47886.nicolas.weeger@laposte.net> <201001151916.35966.nicolas.weeger@laposte.net> <4B514720.8030904@sonic.net> <201001181833.44376.nicolas.weeger@laposte.net> <20100118173103.67b139e9@ucalgary.ca> Message-ID: <4B551AE5.7060503@sonic.net> Alex Schultz wrote: > On Mon, 18 Jan 2010 18:33:44 +0100 > Nicolas Weeger wrote: > >>> I think one change, relative to food, is for all flesh type >>> things (which can be eaten as food) should have some time limit >>> where they start to decompose/rot. I shouldn't be able to carry >>> around an ogre leg for a week and eat it like nothing has >>> happened. Just adding some form of rotting would probably reduce >>> available food by a bit. >> >> Rotting could be fun, but depending on implementation you'd have >> multiple food parts similar but not merging because "dropped-tick" >> isn't the same... > > We could always implement "multiple timeouts" for objects that > would in this case specify how many were dropped on a given tick... not > sure it's worth the bother, but just noting that that isn't an > insurmountable issue. Another possibility is that each flesh has several different states - fresh, smelly, molding, rotting, and then gone. The scale may be 1-100, but each of those corresponds to a range (81-100 is fresh, 61-80 is smelly, etc) When you pick up a food item or otherwise cause a case where it would merge, you find something in the same state (moldy lets say) and average the results. For example, player has 2 moldy items with value of 44 - close to rotting. Picks up 1 item of moldy, but its value is 58 - just went into molding. So we take (44*2 + 58)/3 = 49 value for the 3 items Unless a player is really tracking time, they are unlikely to notice those adjustments. But one problem is that if a player has a big stack of smelly flesh that goes into moldy, it would make that moldy items fresher and they wouldn't go into rotting, like they should. Another thought, which probably works better, is that globally all food active in the game drops one category at once. EG, all flesh in the world goes from fresh to smelly at the same time, goes from smelly to moldy at same time, etc. In that way, they are all synced up in status - not realistic. A middle approach of all food decomposes in units of 5 may work better - you could still get the case of some food becoming fresher, but this may be less likely to happen. OTOH, one could just say that if the food is being merged together, it is effectively being stored in the same place, so that their state sort of does average (if you have 6 eggs that are month old and 6 eggs that are fresh and store them together, how fresh is that dozen eggs?) > >> As for trolls, that's one disadvantage they have - need MUCH food. On >> the opposite, Devourer adepts almost don't use food... > > Expand cooking to allow players to salt the meats and such? Perhaps > make weight-reduction-enchanted containers have some kind of partial > preservative magic? That would help trolls :) That could work. It may just be that for even normal characters, food consumption can be fairly high - reducing it by half across the board may not be a bad thing. From mwedel at sonic.net Tue Jan 19 00:27:01 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 18 Jan 2010 22:27:01 -0800 Subject: [crossfire] use_skill change proposal In-Reply-To: <201001181844.25895.nicolas.weeger@laposte.net> References: <201001171819.53005.nicolas.weeger@laposte.net> <4B53DE15.2050309@sonic.net> <201001181844.25895.nicolas.weeger@laposte.net> Message-ID: <4B5550B5.2010307@sonic.net> Nicolas Weeger wrote: >> I'm presuming you are saying that the same skill, like now, has multiple >> ways to be used, and different commands should be used. > > I'm talking about alchemy-like spells, actually. > The proposed change is for those skills to only do alchemy and not > identification, and add a new 'identify' *global* command which will identify > based on all skills at once. > This avoids the need to add a 'bind use_skill thaumaturgy ; use_skill > alchemy ; use_skill woodsman' and change it for each skill :) Ok - in a sense, it is somewhat acting as a predefined binding, but also using an alternative use for the skills. Are there any skills out there that only identify objects? >> I'm quite sure how to do it, but one could click on the skill name in the >> client and it would to the appropriate action (or if a skill has multiple >> ways to be used, bring up a menu asking them how they want to use it). The >> hard part for that right now would be communicating to the client what >> skills have what actions (it wouldn't be too hard to hard code in values, >> but that is sure to break down the road). > > I'd even go as far as saying to have the available options for any item - > drop, apply, and such. Though it could restrain creativity - who would think > of applying a key [which when applied spawns a strange monster asking for a > riddle and rewarding you if you reply corrctly]? I often thought that bringing up a context menu for objects in a players inventory (lock, unlock, drop, mark, etc) would make more sense than having to hit arcane shift/control/mouseclick operations. In terms of your apply example, it really depends on what the client knows - at some level, it probably shouldn't know all what an item can and can not do. Right now, the client will let the player apply any item they want (and send that request to the server). In that menu, I'd think the options would basically have to be the same for all objects, since the client doesn't know any better. >> If we are going to keep in those commands that players need to issue, I'd >> prefer for them to have some semblance to natural english language. >> >> For example, 'cast fireball' or 'use_skill smithery' seem, while a bit >> verbose, seem somewhat natural. 'identify smithery' would seem to suggest >> something different from a pure language perspective. > > I'd just go with 'identify' and the server would use all available skills. > It's pretty rare imo to want to only use one skill for identification > purposes. I could think of some rare cases where it may be useful (since the ability to identify is based on the skill level, one could see that trading items might improve the odds of being identified). But as noted, that would probably be a pretty rare case, and that one could still be worked around by dropping/transferring the objects before using the skill. But like Otto, I'm not sure I like the name identify since it is used other places, and in those other places, is sure to say what the items are. I wonder if 'analyze' might be better? It sort of describes the act (with the characters various skills, they are analyzing the items trying to figure out what they do). From om at iki.fi Tue Jan 19 08:14:56 2010 From: om at iki.fi (Otto J. Makela) Date: Tue, 19 Jan 2010 16:14:56 +0200 Subject: [crossfire] TODO list In-Reply-To: <4B551AE5.7060503@sonic.net> References: <201001142326.47886.nicolas.weeger@laposte.net> <201001151916.35966.nicolas.weeger@laposte.net> <4B514720.8030904@sonic.net> <201001181833.44376.nicolas.weeger@laposte.net> <20100118173103.67b139e9@ucalgary.ca> <4B551AE5.7060503@sonic.net> Message-ID: <4B55BE60.80906@iki.fi> Mark Wedel wrote: > Alex Schultz wrote: >> Expand cooking to allow players to salt the meats and such? Perhaps >> make weight-reduction-enchanted containers have some kind of partial >> preservative magic? That would help trolls :) > > That could work. It may just be that for even normal characters, food > consumption can be fairly high - reducing it by half across the board may > not be a bad thing. I was just earlier today thinking that the woodsman skill is in addition to the "fast moving in wooded terrain" ability (does anyone actually use this?) an identification skill -- what if it also included the ability to cure and preserve meats so they don't spoil as fast? What about a skill to butcher corpses down into more stable food items, or is that just too gory? Or do we want to make all this a part of cooking? -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From mwedel at sonic.net Wed Jan 20 01:01:32 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 19 Jan 2010 23:01:32 -0800 Subject: [crossfire] TODO list In-Reply-To: <4B55BE60.80906@iki.fi> References: <201001142326.47886.nicolas.weeger@laposte.net> <201001151916.35966.nicolas.weeger@laposte.net> <4B514720.8030904@sonic.net> <201001181833.44376.nicolas.weeger@laposte.net> <20100118173103.67b139e9@ucalgary.ca> <4B551AE5.7060503@sonic.net> <4B55BE60.80906@iki.fi> Message-ID: <4B56AA4C.4010701@sonic.net> Otto J. Makela wrote: > Mark Wedel wrote: >> Alex Schultz wrote: >>> Expand cooking to allow players to salt the meats and such? Perhaps >>> make weight-reduction-enchanted containers have some kind of partial >>> preservative magic? That would help trolls :) >> That could work. It may just be that for even normal characters, food >> consumption can be fairly high - reducing it by half across the board may >> not be a bad thing. > > I was just earlier today thinking that the woodsman skill is in addition to > the "fast moving in wooded terrain" ability (does anyone actually use this?) > an identification skill -- what if it also included the ability to cure and > preserve meats so they don't spoil as fast? What about a skill to butcher > corpses down into more stable food items, or is that just too gory? Mountaineering and woodsmen (movement bonus skills) get applied automatically, just like bargaining should. A player shouldn't need to explicitly use them. I could see several levels of cooking - woodsmen may allow basic preserving of flesh items (salt/smoke it for example) - this basically gets you a normal food item that won't rot. Cooking might be needed to make special food items (those that give some form of bonus). > > Or do we want to make all this a part of cooking? That might be simpler. But a general evaluation of the skills, what they do, and if they can/should be adjusted/made more useful could be in order. Things like woodsmen doesn't have any skill levels IIRC, because there is no proper way to gain exp. As such, you gain it, and that is it. But one could see it having levels, so that as you gain levels, the amount forest slows you down decreases, where at some point you might not have any penalty. If not already in place, woodsmen would also be the natural skill for harvesting wood. From mwedel at sonic.net Thu Jan 21 00:23:27 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 20 Jan 2010 22:23:27 -0800 Subject: [crossfire] account login thoughts/ideas Message-ID: <4B57F2DF.2020108@sonic.net> So as noted someplace, my thoughts for login is this: You log in with account name & password. You then see list of characters associated with that account, and options to add new one. In that list of characters, what would useful information be? My thoughts right now: -name (obviously) -class & race -level -face (not as much useful, but gives something nice for the client to show) Anyone have other thoughts? My thought also is that to gather that information by reading in the player files may be a bit time consuming (on one hand, we can stop reading once we get the desired data. But the other is that if a player has 10 characters on an account, that is 10 files to open, look for that data, etc). So my thought would be to store this someplace else - perhaps a flat file for each account that lists those attributes, and update that file whenever the player logs out with that character. That way it is fairly fast. One other concern (unrelated to above) is account management/spamming. Since one can easily create new accounts without human interaction, I could see some malicious person writing code that creates hundreds/thousands of accounts. My thought here is that an account with no characters associated just gets removed (or more precisely, just not saved out) - in this way, an account needs characters associated, and that takes more time (a new character would have to get created) - at that point, I think any malicious attack would take sufficiently long to not be worthwhile. Especially if we don't consider a character valid until it gets some exp total (that is sort of done, but sort of not done right now. If you try to use a savebed, it puts a minimum check there, but if you just disconnect, it will save you regardless of exp I believe) From mwedel at sonic.net Thu Jan 21 00:29:45 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 20 Jan 2010 22:29:45 -0800 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <201001181831.23755.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <201001151929.24030.nicolas.weeger@laposte.net> <4B51445C.8030004@sonic.net> <201001181831.23755.nicolas.weeger@laposte.net> Message-ID: <4B57F459.4020901@sonic.net> Nicolas Weeger wrote: >> The release methodology sort of needs to be sorted out - if we plan to do >> a lot of cleanup (which may break things), I'd sort of like to do that >> before the first rc - typically you make an rc when you think you are about >> ready and are trying to sort out bugs. >> >> Otherwise, I could see various servers running that, and then when rc2, >> suddenly a lot more stuff gets broken because of code cleanup, which isn't >> really the way to move. > > We need someone willing to decide what needs to be fixed, and enforce the > rules, create branches, things like that. > Though to be honest, I'd suggest we just take current code, label it "1.90", > and see what happens. Even the old method of just releasing something every few months with version number++ worked out reasonably good. There was never a perfect version, but new features got out there, bugs would be found, etc. I might be more inclined to call it version 1.50 - the trunk has moved quite a bit from 1.12, but is still compatible with it (the way some things work is different). I'm not sure what the goal for 2.0 is - needs to be something realistic, but I could also see that where we are may be half way there. then every few months, make a new release - 1.51, 1.52, or maybe skip going to 1.60, 1.70, etc. if significant changes. From mwedel at sonic.net Fri Jan 22 01:52:58 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 21 Jan 2010 23:52:58 -0800 Subject: [crossfire] crossfire image handling Message-ID: <4B59595A.2080708@sonic.net> I'm writing this message to mostly capture ideas/thoughts from last nights IRC discussion before they leave my brain. The basic idea is to communicate all face (and I think animation data) to the client before play starts. This should improve bandwidth some (no spike in sent data when entering a new map to send images, etc). This also simplifies a lot of code - no need to check to see if images have been sent - this is more relevant if things like embedding images is added. To do this would mean that all clients must do image caching. A problem right now is that to just download information on the 4000 images in use takes measurable amount of time. To fix this, the image numbers on a server would remain constant - new or changed images would get added to the end. Right now, all images are put in alphabetical order, and then assigned numerically. Thus, if a new image starting with A is added, all images after that point have new numbers. So under this scheme, if the server currently had 4126 images, and some new images were added, they would get numbers 4127, 4128, and so on - in this way, images 1-4126 remain the same, so the the client doesn't need to request names and checksum information for those. Likewise, if an image changes, its old entry would get blanked out (a whole in the image numbers), and it put at the end. In this way, when the client connects, it request the highest image number the server has and records that away. If its stored value does not match the number the server reports, it knows from what point to start requesting that new information - so in general it would likely need a fairly small set of new images, and if connecting to the same server, in many cases it would know instantly that it is up to date. For any new images, it could then use askface to fetch them. It might be nice to also allow out of band methods (ftp, http) as an alternative to fetch images - in this case, it would presumably be fetching things the consolidated image files. However, this is more complicated - if only 10 images have changed, I don't want to fetch an image file with 4000 images, so incremental image files would be needed. But if the collect script knows which images have changed or are new, it is a pretty simple matter to put those images into incremental image files. Other thoughts: I've mulled over the idea of using checksums (md5 or something) instead of the current checksum and image name. With this, the server would basically just say 'image 6 checksum is 12ab53....'. The client can then check to see if has an image of that checksum anyplace - if doesn't care where it got it from (different server, part of standard image package, etc), and if so, uses it, otherwise requests it. In some ways, this can be more efficient, because some images have long names. It looks like the current average name length is 12 characters - an md5 would be 16 bytes, but would no longer be needed to send checksum data since that is the checksum, so would be a wash. The problem here is that it is likely we will want to be able include image names in text messages and the like, so we can't get away from names. I'm not sure how good our current checksum method is - it is a 32 bit, but I doubt is especially collision resistant. A current problem with just storing images by image names is you get the case of different servers may have an image by the same name but different contents. This basically means that caching information must be stored per server. While in most cases, these duplicate names are not likely to cause much issue, one could imagine that the names are such that they do cause issues (calling it something like map.111 which is a map meant to display to players as part of a quest). Using good checksums means that the client can basically share images from all the servers it may play against, but we avoid the problem of images of same name. One other random thought: The new login method will be such that no map/image data will be shown until the player logs in and selects a character. What this means is that the client could conceivably do a lot of the image updating while that is happening, and only if not done by the time the login is finished does it have to pop up a notice saying something like 'fetching images' From nicolas.weeger at laposte.net Fri Jan 22 02:37:19 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 22 Jan 2010 09:37:19 +0100 Subject: [crossfire] Character names, was Re: Changing connection texts In-Reply-To: <4B57F459.4020901@sonic.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <201001181831.23755.nicolas.weeger@laposte.net> <4B57F459.4020901@sonic.net> Message-ID: <201001220937.22974.nicolas.weeger@laposte.net> > Even the old method of just releasing something every few months with > version number++ worked out reasonably good. > > There was never a perfect version, but new features got out there, bugs > would be found, etc. > > I might be more inclined to call it version 1.50 - the trunk has moved > quite a bit from 1.12, but is still compatible with it (the way some things > work is different). I'm not sure what the goal for 2.0 is - needs to be > something realistic, but I could also see that where we are may be half way > there. > > then every few months, make a new release - 1.51, 1.52, or maybe skip > going to 1.60, 1.70, etc. if significant changes. Fine by me, as long as someone actually manages the releases :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100122/e763c11b/attachment.pgp From nicolas.weeger at laposte.net Fri Jan 22 02:42:08 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 22 Jan 2010 09:42:08 +0100 Subject: [crossfire] use_skill change proposal In-Reply-To: <4B5550B5.2010307@sonic.net> References: <201001171819.53005.nicolas.weeger@laposte.net> <201001181844.25895.nicolas.weeger@laposte.net> <4B5550B5.2010307@sonic.net> Message-ID: <201001220942.08532.nicolas.weeger@laposte.net> > Ok - in a sense, it is somewhat acting as a predefined binding, but also > using an alternative use for the skills. Correct. > Are there any skills out there that only identify objects? Detect magic / curse. So the logic for "use_skill" for those will just be changed for "no specific use", or keep the current behaviour. > But like Otto, I'm not sure I like the name identify since it is used > other places, and in those other places, is sure to say what the items are. > > I wonder if 'analyze' might be better? It sort of describes the act > (with the characters various skills, they are analyzing the items trying to > figure out what they do). 'analyse' is fine by me. If no one objects, I'll implement those changes around next week. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100122/b16b4ca1/attachment.pgp From nicolas.weeger at laposte.net Fri Jan 22 02:44:03 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 22 Jan 2010 09:44:03 +0100 Subject: [crossfire] TODO list In-Reply-To: <4B56AA4C.4010701@sonic.net> References: <201001142326.47886.nicolas.weeger@laposte.net> <4B55BE60.80906@iki.fi> <4B56AA4C.4010701@sonic.net> Message-ID: <201001220944.03835.nicolas.weeger@laposte.net> > That might be simpler. But a general evaluation of the skills, what they > do, and if they can/should be adjusted/made more useful could be in order. > > Things like woodsmen doesn't have any skill levels IIRC, because there is > no proper way to gain exp. As such, you gain it, and that is it. But one > could see it having levels, so that as you gain levels, the amount forest > slows you down decreases, where at some point you might not have any > penalty. Woodsman has skill levels, as it does alchemy-like transformation and item identification, too. But I agree with the need to evaluate all skills and sort/clean stuff. Any volunteer? :) > If not already in place, woodsmen would also be the natural skill for > harvesting wood. Probably. Right now you could implement "woodcutting" through the "harvesting" stuff already. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100122/5da12d64/attachment.pgp From mwedel at sonic.net Fri Jan 22 12:41:36 2010 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 22 Jan 2010 10:41:36 -0800 Subject: [crossfire] use_skill change proposal In-Reply-To: <201001220942.08532.nicolas.weeger@laposte.net> References: <201001171819.53005.nicolas.weeger@laposte.net> <201001181844.25895.nicolas.weeger@laposte.net> <4B5550B5.2010307@sonic.net> <201001220942.08532.nicolas.weeger@laposte.net> Message-ID: <4B59F160.70900@sonic.net> Nicolas Weeger wrote: >> Ok - in a sense, it is somewhat acting as a predefined binding, but also >> using an alternative use for the skills. > > Correct. > > >> Are there any skills out there that only identify objects? > > Detect magic / curse. So the logic for "use_skill" for those will just be > changed for "no specific use", or keep the current behaviour. Note one issue there - if I use sense curse and find cursed items, I typically don't want to then identify them, as you can sell cursed (but not identified) items for some nominal amount of money. So my standard procedure was always: detect cursed and magic items sell anything that is cursed or non magical then identify the rest, and sell most of those. From nicolas.weeger at laposte.net Sun Jan 24 05:44:52 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 24 Jan 2010 12:44:52 +0100 Subject: [crossfire] Messy multiface items Message-ID: <201001241244.57135.nicolas.weeger@laposte.net> Hello. There is a bug / incoherent behaviour with multiface items which are not monsters. Best illustration: /scorn/misc/castle_kitchen Check the tables - sometimes the item will be on top, sometimes under. And the object_fix_multipart() function doesn't really concern with the exact layer to put to. Any idea on how to fix that? Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100124/b8368d7c/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 24 10:53:23 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 24 Jan 2010 17:53:23 +0100 Subject: [crossfire] NPC behaviour change Message-ID: <201001241753.28108.nicolas.weeger@laposte.net> Hello. I just committed to trunk a small patch making NPCs stand still for a few (3 to 9 of their moves) ticks after being talked to. Only applies to NPCs. Could probably be smarter, feel free to fix it :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100124/a49d4031/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 24 13:07:07 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 24 Jan 2010 20:07:07 +0100 Subject: [crossfire] Spells consuming items Message-ID: <201001242007.10711.nicolas.weeger@laposte.net> Hello. I just committed a small patch enabling spells to require and consume items when cast. The patch uses a 'casting_requirements' key (in the spell object itself) to enforce restrictions. The value should be a list of items, like the alchemy uses. Currently it is restricted to 10 items (hardcoded value) - putting more will make the spell impossible to cast. Check the 'test/spell_requirements' maps for an example. Now let your imagination take over and invent fun spells with weird items! :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100124/0316c3b8/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 24 16:52:31 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 24 Jan 2010 23:52:31 +0100 Subject: [crossfire] Protocol extension Message-ID: <201001242352.36392.nicolas.weeger@laposte.net> Hello. I just added a small protocol extension. "spellmon" setup command can now take a value of "2", resulting in more spell information sent (including required items to send, and if the spell needs arguments to be used - text for rune of marking, things like that). Hopefully JXClient will implement that at some point ;) And maybe GTK/GTK2, if someone feels like implementing that :p For clients wishing to use that new feature, just send "setup spellmon 1 spellmon 2", and if you get "spellmon 1 spellmon FALSE" then the server doesn't accept 2 - sending invalid setup command doesn't change the server-side value, so the "1" will be taken into account correctly. And if you get "spellmon 1 spellmon 2" then you'll get that extended information. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100124/290b118c/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 25 16:12:41 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 25 Jan 2010 23:12:41 +0100 Subject: [crossfire] Cursed items In-Reply-To: <4B5516E5.9040900@sonic.net> References: <4B53B7C5.4040706@iki.fi> <201001181846.35299.nicolas.weeger@laposte.net> <4B5516E5.9040900@sonic.net> Message-ID: <201001252312.46150.nicolas.weeger@laposte.net> > Even if the spell (and skill) were removed, it probably wouldn't mean > much so long as the detect curse tables still exist. Unless the tables aren't infaillible and cost a lot? If it's 10 000 diamonds each detect, and it can fail (or curse the item?), then it gets really expensive to check :) > I think one problem is that players acquire so many items on an even > normal outing that it is a sure thing that at least some of them are > cursed. Right now, the people that usually seem to get hit by cursed items > are new players who don't have the resources to get rid of them and don't > know that it is fairly easy to know what is and is not cursed. > > Couple thoughts come to mind: > - Reduce occurrence of cursed items greatly (<=1% of items). In this way, > it would be fairly rare for players to find cursed items. > - Remove detect curse methods or make them much more expensive (identify > will continue to work) > > That may make it worth it for players to try to equip items (instead of > identifying them) when they sell them, since they get more money but don't > have to pay for the identify. Maybe... > Even if cursed items are impossible to identify, I suspect players will > just wait until they are in town to see what they are - It would such to > use one in a dungeon and find out you are in bad shape because you are > stuck wearing crappy armor. > > Live action RPG tends to have cursed items because the GM can control > when the curse takes effect - there is no way to detect it, and usually > manifests itself only in life or death situations. So it's up to use to add such things :) A perfectly normal sword - but after you killed 15 opponents, it'll bite you on the hand, making you unable to use a weapon for some time. A shield that has a nice armor - and after 1 day, you suddenly morph into a werewolf. > A more interesting approach in crossfire is that curses are undetectable, > but in rare circumstances the item does something unexpected. For example, > a cursed wand might 5% of the time fire in the wrong/random direction. A > player may still find that wand useful. Weapons could suddenly > disintegrate, but until it does so, may be a nice weapon (and when it does > fall apart, just means the player needs to equip something else) > > So in other words, cursed items still have some positive use - they > aren't all bad. It really depends what the 'cursed' status is supposed to mean, I'd say. If "cursed" is just "can't unequip", then maybe it's limited. If on the other hand we got a list of potentially bad effects somewhere, then it could be really fun. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100125/fa55399c/attachment.pgp From nicolas.weeger at laposte.net Mon Jan 25 16:16:44 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 25 Jan 2010 23:16:44 +0100 Subject: [crossfire] account login thoughts/ideas In-Reply-To: <4B57F2DF.2020108@sonic.net> References: <4B57F2DF.2020108@sonic.net> Message-ID: <201001252316.44691.nicolas.weeger@laposte.net> > So as noted someplace, my thoughts for login is this: > You log in with account name & password. > You then see list of characters associated with that account, and options > to add new one. Seems fine :) > In that list of characters, what would useful information be? My > thoughts right now: > > -name (obviously) > -class & race > -level > -face (not as much useful, but gives something nice for the client to show) > > Anyone have other thoughts? That seems fine too, that's the bare minimum. Other things to think about: currently equipped weapons/armors/rings ; money on character ; party the player was in. > My thought also is that to gather that information by reading in the > player files may be a bit time consuming (on one hand, we can stop reading > once we get the desired data. But the other is that if a player has 10 > characters on an account, that is 10 files to open, look for that data, > etc). So my thought would be to store this someplace else - perhaps a flat > file for each account that lists those attributes, and update that file > whenever the player logs out with that character. That way it is fairly > fast. Yes, having a flat file would be ok. Related option is to have player files as subdirectories of the account directory. But then you have issues checking character names are globally unique :) > One other concern (unrelated to above) is account management/spamming. > Since one can easily create new accounts without human interaction, I could > see some malicious person writing code that creates hundreds/thousands of > accounts. > > My thought here is that an account with no characters associated just > gets removed (or more precisely, just not saved out) - in this way, an > account needs characters associated, and that takes more time (a new > character would have to get created) - at that point, I think any malicious > attack would take sufficiently long to not be worthwhile. Especially if we > don't consider a character valid until it gets some exp total (that is sort > of done, but sort of not done right now. If you try to use a savebed, it > puts a minimum check there, but if you just disconnect, it will save you > regardless of exp I believe) Seems as a good way, yes - no character, no account saved. In this case, better warn players enough - so they don't create an account, play a few minutes, disconnect without saving, and lose everything! Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100125/00cc1692/attachment.pgp From mwedel at sonic.net Tue Jan 26 01:11:59 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Jan 2010 23:11:59 -0800 Subject: [crossfire] Cursed items In-Reply-To: <201001252312.46150.nicolas.weeger@laposte.net> References: <4B53B7C5.4040706@iki.fi> <201001181846.35299.nicolas.weeger@laposte.net> <4B5516E5.9040900@sonic.net> <201001252312.46150.nicolas.weeger@laposte.net> Message-ID: <4B5E95BF.6060001@sonic.net> Nicolas Weeger wrote: >> Even if cursed items are impossible to identify, I suspect players will >> just wait until they are in town to see what they are - It would such to >> use one in a dungeon and find out you are in bad shape because you are >> stuck wearing crappy armor. >> >> Live action RPG tends to have cursed items because the GM can control >> when the curse takes effect - there is no way to detect it, and usually >> manifests itself only in life or death situations. > > So it's up to use to add such things :) > A perfectly normal sword - but after you killed 15 opponents, it'll bite you > on the hand, making you unable to use a weapon for some time. > A shield that has a nice armor - and after 1 day, you suddenly morph into a > werewolf. > But I have a feeling players will easily be able to know/defeat these things. As said, getting stuck with a cursed item in that dungeon would be really annoying. Especially if you thought it was a really good item (if it isn't a good item, you wouldn't use it in the first place). It's fairly simple to defeat that kill test - go into an easy dungeon and kill that 100 creatures in 10 seconds (and I'd say more likely, you don't even need to do that - most dungeons are such that you'll be killing hundreds of monsters before you get something tough). It may be possible to have the effect manifest itself on that tough monster, but I'm not sure how one measures that. But more to the point, does this make the game more or less fun? If I had a weapon that bit me on the hand and I could use a weapon for some amount of time, I'd just run away from whatever I'm doing and wait for that time to pass. Is that fun? If it is relatively short (10-15 seconds), maybe, if it is incredibly rare. If that time is in the minutes, then it is just annoying to sit around for those minutes. Same for morphing into a werewolf. If it just means I have to trudge back to town to get a cure, does that add anything? That is the harder part. Putting things in because LRPGs have them may not always be the best answer - the goal is to really have a fun game. > > >> A more interesting approach in crossfire is that curses are undetectable, >> but in rare circumstances the item does something unexpected. For example, >> a cursed wand might 5% of the time fire in the wrong/random direction. A >> player may still find that wand useful. Weapons could suddenly >> disintegrate, but until it does so, may be a nice weapon (and when it does >> fall apart, just means the player needs to equip something else) >> >> So in other words, cursed items still have some positive use - they >> aren't all bad. > > It really depends what the 'cursed' status is supposed to mean, I'd say. > If "cursed" is just "can't unequip", then maybe it's limited. > If on the other hand we got a list of potentially bad effects somewhere, then > it could be really fun. Yes, but I think the key is to make sure it doesn't make the game less fun. So the effects are key. Wands that occasionally misfire are perhaps not bad, nor are weapons that disintegrate. On the weapon one, one could imagine a weapon that slowly gets better as it is used, but its chance of falling apart is also related to that. So you might have a real good weapon, but also know that its time is very limited. Something similar to the occidental rings but for armor could be done. Gives fairly good protection, but when you take damage of that type, there is a chance it switches to a different protection. From mwedel at sonic.net Tue Jan 26 01:23:56 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Jan 2010 23:23:56 -0800 Subject: [crossfire] account login thoughts/ideas In-Reply-To: <201001252316.44691.nicolas.weeger@laposte.net> References: <4B57F2DF.2020108@sonic.net> <201001252316.44691.nicolas.weeger@laposte.net> Message-ID: <4B5E988C.4060105@sonic.net> Nicolas Weeger wrote: >> In that list of characters, what would useful information be? My >> thoughts right now: >> >> -name (obviously) >> -class & race >> -level >> -face (not as much useful, but gives something nice for the client to show) >> >> Anyone have other thoughts? > > That seems fine too, that's the bare minimum. > Other things to think about: currently equipped weapons/armors/rings ; money > on character ; party the player was in. > There is certainly a balance here between providing useful enough information for the player to basically know what character they are choosing, and so much information that it maybe doesn't help or maybe you just log in as that character. At some point there is also conveying all this information to the player is a useful manner - at some point, you could start getting to the point that everything about the character could be conveyed (stats, sp, grace, etc), but at that point, might as well just have the user select that character and see if it is the right one. Switching between characters once you've logged in the account should be pretty lightweight - basically it just returns to that screen, so cycling between characters to find the right one shouldn't be as time consuming. I guess the question is what information becomes useful is finding the right character. I'm thinking map might be another one, but this requires maps all have good names and not things like /world/world_140_180 (there is a property in the map file itself which one can give a real name to it, like Great Forest, etc) > > >> My thought also is that to gather that information by reading in the >> player files may be a bit time consuming (on one hand, we can stop reading >> once we get the desired data. But the other is that if a player has 10 >> characters on an account, that is 10 files to open, look for that data, >> etc). So my thought would be to store this someplace else - perhaps a flat >> file for each account that lists those attributes, and update that file >> whenever the player logs out with that character. That way it is fairly >> fast. > > Yes, having a flat file would be ok. > Related option is to have player files as subdirectories of the account > directory. But then you have issues checking character names are globally > unique :) Sub directories doesn't really help out too much in reading in the player files and extracting that data. At some point, all characters would be associated with accounts - at that point one could just look through all that information and see if a character by that name exists (the current data structures don't make it a very efficient method, but given number of characters, probably not much an issue - and even if it was, during load, character names could be stored in a simple array that is sorted or something, and use that). Put the player files under an account directory makes more sense if some number of resources become account wide properties, and not character wide. Things like apartments, and maybe all unique maps (unique to the player, not character). > > > >> One other concern (unrelated to above) is account management/spamming. >> Since one can easily create new accounts without human interaction, I could >> see some malicious person writing code that creates hundreds/thousands of >> accounts. >> >> My thought here is that an account with no characters associated just >> gets removed (or more precisely, just not saved out) - in this way, an >> account needs characters associated, and that takes more time (a new >> character would have to get created) - at that point, I think any malicious >> attack would take sufficiently long to not be worthwhile. Especially if we >> don't consider a character valid until it gets some exp total (that is sort >> of done, but sort of not done right now. If you try to use a savebed, it >> puts a minimum check there, but if you just disconnect, it will save you >> regardless of exp I believe) > > Seems as a good way, yes - no character, no account saved. > In this case, better warn players enough - so they don't create an account, > play a few minutes, disconnect without saving, and lose everything! The biggest danger would be more the case of a player with an establish account, and for some reason they delete their last character, but have plans to make a new one - another case to warn them. One problem, I think, is that the client has a quit type thing, and on that, the client just does it, so if players use that, there isn't much the server can do to warn them about it. From mwedel at sonic.net Tue Jan 26 01:27:32 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Jan 2010 23:27:32 -0800 Subject: [crossfire] Protocol extension In-Reply-To: <201001242352.36392.nicolas.weeger@laposte.net> References: <201001242352.36392.nicolas.weeger@laposte.net> Message-ID: <4B5E9964.6060502@sonic.net> Nicolas Weeger wrote: > Hello. > > I just added a small protocol extension. > > "spellmon" setup command can now take a value of "2", resulting in more spell > information sent (including required items to send, and if the spell needs > arguments to be used - text for rune of marking, things like that). > > > Hopefully JXClient will implement that at some point ;) > And maybe GTK/GTK2, if someone feels like implementing that :p > > > > For clients wishing to use that new feature, just send "setup spellmon 1 > spellmon 2", and if you get "spellmon 1 spellmon FALSE" then the server > doesn't accept 2 - sending invalid setup command doesn't change the > server-side value, so the "1" will be taken into account correctly. > And if you get "spellmon 1 spellmon 2" then you'll get that extended > information. Just curious, is there any test spell that uses this (by test spell, it may be a spell that is never found by players, but a server admin could manually assign/learn it via dm powers to test out functionality of this command as well as proper handling on the client. From mwedel at sonic.net Tue Jan 26 01:31:16 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Jan 2010 23:31:16 -0800 Subject: [crossfire] Spells consuming items In-Reply-To: <201001242007.10711.nicolas.weeger@laposte.net> References: <201001242007.10711.nicolas.weeger@laposte.net> Message-ID: <4B5E9A44.7070401@sonic.net> Nicolas Weeger wrote: > Hello. > > I just committed a small patch enabling spells to require and consume items > when cast. > > The patch uses a 'casting_requirements' key (in the spell object itself) to > enforce restrictions. > The value should be a list of items, like the alchemy uses. > Currently it is restricted to 10 items (hardcoded value) - putting more will > make the spell impossible to cast. > > > Check the 'test/spell_requirements' maps for an example Random question on this: Is there any way to really clearly know that this is going to happen? For example, if one had a spell that used up diamonds, it should be pretty darn clear it does so, since diamonds will now just start disappearing from the players inventory. IIRC, all of the crafting stuff pretty much requires you putting the items on the crafting devices and using the appropriate skill. I wonder if adding something like a 'spell reagents' container might not be a bad idea, and spell using items will only use objects from that container. This probably isn't a problem until spells that use this functionality become widespread - my main concern in there may be some confused/upset players if there are spells that end up using valuable items. From nicolas.weeger at laposte.net Tue Jan 26 13:18:00 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 26 Jan 2010 20:18:00 +0100 Subject: [crossfire] Spells consuming items In-Reply-To: <4B5E9A44.7070401@sonic.net> References: <201001242007.10711.nicolas.weeger@laposte.net> <4B5E9A44.7070401@sonic.net> Message-ID: <201001262018.03174.nicolas.weeger@laposte.net> > Random question on this: Is there any way to really clearly know that > this is going to happen? > > For example, if one had a spell that used up diamonds, it should be > pretty darn clear it does so, since diamonds will now just start > disappearing from the players inventory. > > IIRC, all of the crafting stuff pretty much requires you putting the > items on the crafting devices and using the appropriate skill. Currently no, the player doesn't know if the spell description doesn't have the information. > I wonder if adding something like a 'spell reagents' container might not > be a bad idea, and spell using items will only use objects from that > container. Maybe... But would that make the game fun? :) > This probably isn't a problem until spells that use this functionality > become widespread - my main concern in there may be some confused/upset > players if there are spells that end up using valuable items. Hopefully, client will warn when selecting such a spell (which is why I added the protocol extension). Or we can even have the server send a reminder - "you ready the spell firebolt, which consumes diamonds to be cast". Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100126/2d35f142/attachment.pgp From nicolas.weeger at laposte.net Tue Jan 26 13:20:01 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 26 Jan 2010 20:20:01 +0100 Subject: [crossfire] use_skill change proposal In-Reply-To: <4B59F160.70900@sonic.net> References: <201001171819.53005.nicolas.weeger@laposte.net> <201001220942.08532.nicolas.weeger@laposte.net> <4B59F160.70900@sonic.net> Message-ID: <201001262020.01304.nicolas.weeger@laposte.net> > Note one issue there - if I use sense curse and find cursed items, I > typically don't want to then identify them, as you can sell cursed (but not > identified) items for some nominal amount of money. > > So my standard procedure was always: > detect cursed and magic items > sell anything that is cursed or non magical > then identify the rest, and sell most of those. Then I see two options: 1) don't include "detect cursed / magic" in the "analyze" function 2) stop the analyze if the item is magic/cursed, saying to analyze again for more information. I would say option 2), with a player setting to go on anyway :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100126/d40f9175/attachment.pgp From nicolas.weeger at laposte.net Tue Jan 26 13:18:51 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 26 Jan 2010 20:18:51 +0100 Subject: [crossfire] Protocol extension In-Reply-To: <4B5E9964.6060502@sonic.net> References: <201001242352.36392.nicolas.weeger@laposte.net> <4B5E9964.6060502@sonic.net> Message-ID: <201001262018.51179.nicolas.weeger@laposte.net> > Just curious, is there any test spell that uses this (by test spell, it > may be a spell that is never found by players, but a server admin could > manually assign/learn it via dm powers to test out functionality of this > command as well as proper handling on the client. The map /test/spell_requirements has such a special firebolt, requiring 1 diamond and 3 emeralds to be cast. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100126/8891b7c8/attachment.pgp From mwedel at sonic.net Wed Jan 27 00:23:13 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 26 Jan 2010 22:23:13 -0800 Subject: [crossfire] Spells consuming items In-Reply-To: <201001262018.03174.nicolas.weeger@laposte.net> References: <201001242007.10711.nicolas.weeger@laposte.net> <4B5E9A44.7070401@sonic.net> <201001262018.03174.nicolas.weeger@laposte.net> Message-ID: <4B5FDBD1.10608@sonic.net> Nicolas Weeger wrote: >> This probably isn't a problem until spells that use this functionality >> become widespread - my main concern in there may be some confused/upset >> players if there are spells that end up using valuable items. > > Hopefully, client will warn when selecting such a spell (which is why I added > the protocol extension). > Or we can even have the server send a reminder - "you ready the spell > firebolt, which consumes diamonds to be cast". That last one is probably a good method - it universally works. While the client could do some of the work, it (at least the C client) currently doesn't watch commands that much. It watches it to the extent to know if it is a command it should execute or a command that it should pass to the server, but beyond that, it just passes the data on to the server. Since the server currently says 'you ready abc', putting in a note that it has components doesn't really add much in the way of extra messages, and seems like a pretty easy solution. From mwedel at sonic.net Wed Jan 27 00:28:44 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 26 Jan 2010 22:28:44 -0800 Subject: [crossfire] use_skill change proposal In-Reply-To: <201001262020.01304.nicolas.weeger@laposte.net> References: <201001171819.53005.nicolas.weeger@laposte.net> <201001220942.08532.nicolas.weeger@laposte.net> <4B59F160.70900@sonic.net> <201001262020.01304.nicolas.weeger@laposte.net> Message-ID: <4B5FDD1C.1000107@sonic.net> Nicolas Weeger wrote: >> Note one issue there - if I use sense curse and find cursed items, I >> typically don't want to then identify them, as you can sell cursed (but not >> identified) items for some nominal amount of money. >> >> So my standard procedure was always: >> detect cursed and magic items >> sell anything that is cursed or non magical >> then identify the rest, and sell most of those. > > Then I see two options: > 1) don't include "detect cursed / magic" in the "analyze" function > 2) stop the analyze if the item is magic/cursed, saying to analyze again for > more information. > > > I would say option 2), with a player setting to go on anyway :) That second one works, but how does the server count it as the second analyze? I think simplest would be some option to analyze that says analyze cursed items. I ask this because I could imagine use cases where a person is out adventuring, gathering items, and periodically does the analyze, and they are like me and don't want to analyze cursed items. From nicolas.weeger at laposte.net Fri Jan 29 11:10:50 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 29 Jan 2010 18:10:50 +0100 Subject: [crossfire] use_skill change proposal In-Reply-To: <4B5FDD1C.1000107@sonic.net> References: <201001171819.53005.nicolas.weeger@laposte.net> <201001262020.01304.nicolas.weeger@laposte.net> <4B5FDD1C.1000107@sonic.net> Message-ID: <201001291810.55018.nicolas.weeger@laposte.net> > That second one works, but how does the server count it as the second > analyze? I think simplest would be some option to analyze that says analyze > cursed items. > > I ask this because I could imagine use cases where a person is out > adventuring, gathering items, and periodically does the analyze, and they > are like me and don't want to analyze cursed items. The 'known_cursed' flag will be useful for that, then. 'analyze -c': analyze items with unknown cursed status for curse check, leave others. 'analyze -a': analyze all items with all possible skills. Then player option to default to -c or -a Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100129/322a2f4a/attachment.pgp From nicolas.weeger at laposte.net Fri Jan 29 11:14:03 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 29 Jan 2010 18:14:03 +0100 Subject: [crossfire] account login thoughts/ideas In-Reply-To: <4B5E988C.4060105@sonic.net> References: <4B57F2DF.2020108@sonic.net> <201001252316.44691.nicolas.weeger@laposte.net> <4B5E988C.4060105@sonic.net> Message-ID: <201001291814.03736.nicolas.weeger@laposte.net> > Switching between characters once you've logged in the account should be > pretty lightweight - basically it just returns to that screen, so cycling > between characters to find the right one shouldn't be as time consuming. Yep, with just updated information sent for last used character. > Put the player files under an account directory makes more sense if some > number of resources become account wide properties, and not character wide. > Things like apartments, and maybe all unique maps (unique to the player, > not character). I'd rather have a share mechanism between players - that'll solve the sharing between characters of an account :p > The biggest danger would be more the case of a player with an establish > account, and for some reason they delete their last character, but have > plans to make a new one - another case to warn them. > > One problem, I think, is that the client has a quit type thing, and on > that, the client just does it, so if players use that, there isn't much the > server can do to warn them about it. Let's remove the 'quit' command, then. Have characters be deleted from the account management mode. And if an account has no character, don't remove it if it's because the last character was deleted. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100129/f0140c0a/attachment.pgp From nicolas.weeger at laposte.net Fri Jan 29 11:15:19 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 29 Jan 2010 18:15:19 +0100 Subject: [crossfire] Spells consuming items In-Reply-To: <4B5FDBD1.10608@sonic.net> References: <201001242007.10711.nicolas.weeger@laposte.net> <201001262018.03174.nicolas.weeger@laposte.net> <4B5FDBD1.10608@sonic.net> Message-ID: <201001291815.19868.nicolas.weeger@laposte.net> > While the client could do some of the work, it (at least the C client) > currently doesn't watch commands that much. It watches it to the extent to > know if it is a command it should execute or a command that it should pass > to the server, but beyond that, it just passes the data on to the server. > > Since the server currently says 'you ready abc', putting in a note that > it has components doesn't really add much in the way of extra messages, and > seems like a pretty easy solution. Possible :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100129/9a19e16e/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 31 05:19:12 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 31 Jan 2010 12:19:12 +0100 Subject: [crossfire] Alchemy expansion / modifications Message-ID: <201001311219.16316.nicolas.weeger@laposte.net> Hello. I've tweaked alchemy recipes to be able to describe item "transformations", that is for instance the result of using a slicing knife on an apple (generating 2 apples halves). Check the end of the lib/formulae file for examples. Not sure it won't break a few things related to alchemy, but well, it's worth changing I think :) Many things are left to do on this topic, including "multiple" ingredients and such (like poison vial + food => poisoned food). The goal is to replace the "on_use_with_xxx" hacks in the archetypes for item manipulation. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100131/77315cd0/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 31 06:33:11 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 31 Jan 2010 13:33:11 +0100 Subject: [crossfire] Spells consuming items In-Reply-To: <4B5FDBD1.10608@sonic.net> References: <201001242007.10711.nicolas.weeger@laposte.net> <201001262018.03174.nicolas.weeger@laposte.net> <4B5FDBD1.10608@sonic.net> Message-ID: <201001311333.14520.nicolas.weeger@laposte.net> > That last one is probably a good method - it universally works. > > While the client could do some of the work, it (at least the C client) > currently doesn't watch commands that much. It watches it to the extent to > know if it is a command it should execute or a command that it should pass > to the server, but beyond that, it just passes the data on to the server. > > Since the server currently says 'you ready abc', putting in a note that > it has components doesn't really add much in the way of extra messages, and > seems like a pretty easy solution. Implemented like that (though display isn't nice :)) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100131/93f8f69b/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 31 06:35:31 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 31 Jan 2010 13:35:31 +0100 Subject: [crossfire] Cursed items In-Reply-To: <4B5E95BF.6060001@sonic.net> References: <4B53B7C5.4040706@iki.fi> <201001252312.46150.nicolas.weeger@laposte.net> <4B5E95BF.6060001@sonic.net> Message-ID: <201001311335.31945.nicolas.weeger@laposte.net> > But I have a feeling players will easily be able to know/defeat these > things. > > As said, getting stuck with a cursed item in that dungeon would be really > annoying. Especially if you thought it was a really good item (if it isn't > a good item, you wouldn't use it in the first place). > > It's fairly simple to defeat that kill test - go into an easy dungeon and > kill that 100 creatures in 10 seconds (and I'd say more likely, you don't > even need to do that - most dungeons are such that you'll be killing > hundreds of monsters before you get something tough). > > It may be possible to have the effect manifest itself on that tough > monster, but I'm not sure how one measures that. > > But more to the point, does this make the game more or less fun? Well, then let's remove the whole 'cursed' flag concept, and only do scripted things... :) > That is the harder part. Putting things in because LRPGs have them may > not always be the best answer - the goal is to really have a fun game. Yes. > Something similar to the occidental rings but for armor could be done. > Gives fairly good protection, but when you take damage of that type, there > is a chance it switches to a different protection. So scripted instead of a mere flag :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100131/8897644f/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 31 06:40:34 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 31 Jan 2010 13:40:34 +0100 Subject: [crossfire] crossfire image handling In-Reply-To: <4B59595A.2080708@sonic.net> References: <4B59595A.2080708@sonic.net> Message-ID: <201001311340.34652.nicolas.weeger@laposte.net> > The basic idea is to communicate all face (and I think animation data) to > the client before play starts. This should improve bandwidth some (no > spike in sent data when entering a new map to send images, etc). This also > simplifies a lot of code - no need to check to see if images have been sent > - this is more relevant if things like embedding images is added. > > To do this would mean that all clients must do image caching. A problem > right now is that to just download information on the 4000 images in use > takes measurable amount of time. > > To fix this, the image numbers on a server would remain constant - new or > changed images would get added to the end. Right now, all images are put > in alphabetical order, and then assigned numerically. Thus, if a new image > starting with A is added, all images after that point have new numbers. I think that should implemented in a way coherent with the expected image update frequency. If we expect pics to be updated really often, then it makes sense to only send changes. If on the other hand pics don't change that often, then isn't the current method ok (assuming clients download all pics at start)? > So under this scheme, if the server currently had 4126 images, and some > new images were added, they would get numbers 4127, 4128, and so on - in > this way, images 1-4126 remain the same, so the the client doesn't need to > request names and checksum information for those. Likewise, if an image > changes, its old entry would get blanked out (a whole in the image > numbers), and it put at the end. But then the server itself has to track image changes, which isn't that easy with current implementation. > In this way, when the client connects, it request the highest image > number the server has and records that away. If its stored value does not > match the number the server reports, it knows from what point to start > requesting that new information - so in general it would likely need a > fairly small set of new images, and if connecting to the same server, in > many cases it would know instantly that it is up to date. What about using a timestamp for the last change? > For any new images, it could then use askface to fetch them. It might be > nice to also allow out of band methods (ftp, http) as an alternative to > fetch images - in this case, it would presumably be fetching things the > consolidated image files. However, this is more complicated - if only 10 > images have changed, I don't want to fetch an image file with 4000 images, > so incremental image files would be needed. But if the collect script > knows which images have changed or are new, it is a pretty simple matter to > put those images into incremental image files. Indeed. > I've mulled over the idea of using checksums (md5 or something) instead of > the current checksum and image name. With this, the server would basically > just say 'image 6 checksum is 12ab53....'. The client can then check to > see if has an image of that checksum anyplace - if doesn't care where it > got it from (different server, part of standard image package, etc), and if > so, uses it, otherwise requests it. Yup, makes sense. > The problem here is that it is likely we will want to be able include > image names in text messages and the like, so we can't get away from names. Yup. > > I'm not sure how good our current checksum method is - it is a 32 bit, > but I doubt is especially collision resistant. Right now doesn't matter, as name is taken into account (I think), client caches from the name. > A current problem with just storing images by image names is you get the > case of different servers may have an image by the same name but different > contents. This basically means that caching information must be stored per > server. While in most cases, these duplicate names are not likely to cause > much issue, one could imagine that the names are such that they do cause > issues (calling it something like map.111 which is a map meant to display > to players as part of a quest). That's a current issue anyway :) > Using good checksums means that the client can basically share images > from all the servers it may play against, but we avoid the problem of > images of same name. > One other random thought: The new login method will be such that no > map/image data will be shown until the player logs in and selects a > character. What this means is that the client could conceivably do a lot > of the image updating while that is happening, and only if not done by the > time the login is finished does it have to pop up a notice saying something > like 'fetching images' Depending on the expected transfer time, obviously. I remember GTK client having all image from the start, though (crossfire.0? something like that). Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100131/1e5be392/attachment.pgp From mwedel at sonic.net Sun Jan 31 23:45:31 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 31 Jan 2010 21:45:31 -0800 Subject: [crossfire] crossfire image handling In-Reply-To: <201001311340.34652.nicolas.weeger@laposte.net> References: <4B59595A.2080708@sonic.net> <201001311340.34652.nicolas.weeger@laposte.net> Message-ID: <4B666A7B.9030205@sonic.net> On 01/31/10 04:40 AM, Nicolas Weeger wrote: >> The basic idea is to communicate all face (and I think animation data) to >> the client before play starts. This should improve bandwidth some (no >> spike in sent data when entering a new map to send images, etc). This also >> simplifies a lot of code - no need to check to see if images have been sent >> - this is more relevant if things like embedding images is added. >> >> To do this would mean that all clients must do image caching. A problem >> right now is that to just download information on the 4000 images in use >> takes measurable amount of time. >> >> To fix this, the image numbers on a server would remain constant - new or >> changed images would get added to the end. Right now, all images are put >> in alphabetical order, and then assigned numerically. Thus, if a new image >> starting with A is added, all images after that point have new numbers. > > I think that should implemented in a way coherent with the expected image > update frequency. > > If we expect pics to be updated really often, then it makes sense to only send > changes. > If on the other hand pics don't change that often, then isn't the current > method ok (assuming clients download all pics at start)? We don't really know how often images will change, so from that point, hard to say what is the right approach. If image updates are infrequent, then the client could download the image information once and keep using it. However, if there is any change, no matter how small, the client then needs to download the entire image name->number mapping, which at current time is about 5000 images. Of course, that number is only likely to increase, which means that for additions, we end up download a lot of data that we don't need to. >> So under this scheme, if the server currently had 4126 images, and some >> new images were added, they would get numbers 4127, 4128, and so on - in >> this way, images 1-4126 remain the same, so the the client doesn't need to >> request names and checksum information for those. Likewise, if an image >> changes, its old entry would get blanked out (a whole in the image >> numbers), and it put at the end. > > But then the server itself has to track image changes, which isn't that easy > with current implementation. Really it is the collect script that would do this, not the server. In fact, the server wouldn't care - all that would be needed for the server (I believe) is for it to be able to handle bmaps files that are not in alphabetical order. For the collect script, what it would need to do is read in the existing bmaps file, and whenever it runs into a face, see if it is an existing face or new one - shouldn't be that hard. The one change here is that the bmaps file would need to contain checksums so the collect script could detect changed faces, but even that isn't that hard. >> In this way, when the client connects, it request the highest image >> number the server has and records that away. If its stored value does not >> match the number the server reports, it knows from what point to start >> requesting that new information - so in general it would likely need a >> fairly small set of new images, and if connecting to the same server, in >> many cases it would know instantly that it is up to date. > > What about using a timestamp for the last change? Maybe, but that doesn't really solve the problem of needing to download 5000 faces to find information about one new one. The other issue with that is at least right now, the collect script will always write out a bmaps file when run, even if no changes. So if you make a change to an archetype, run collect, that file is updated, so from that perspective, timestamp isn't great. >> I'm not sure how good our current checksum method is - it is a 32 bit, >> but I doubt is especially collision resistant. > > Right now doesn't matter, as name is taken into account (I think), client > caches from the name. It does. But if checksum was good (non collision resistant), checksum could be used to see if client already has that image. A problem right now with the C client (maybe it was fixed) was the fact it uses image names causes problems when different servers use different images for the same face. I connect to server A, and it downloads grass.111 I connect to server B, it uses a different image, so downloads grass.111 I go back to A, since that file has been replaced, it downloads again. Now that is really an implementation detail - one way to handle it is per server image caches (so client has a different directory to cache A vs B images). But that is sort of wasteful when 90% may be the same. Ideally, if image is the same, you want to share them, but if different, you want to be able to store them away and access them. Another more real situation could be case of image changing on server then reverted for whatever reason. In that case, once again, you'd like to just be able to go back to the original and not download again. This is all really a client issue, but if the checksum was really good, it does make life easier. >> One other random thought: The new login method will be such that no >> map/image data will be shown until the player logs in and selects a >> character. What this means is that the client could conceivably do a lot >> of the image updating while that is happening, and only if not done by the >> time the login is finished does it have to pop up a notice saying something >> like 'fetching images' > > > Depending on the expected transfer time, obviously. > I remember GTK client having all image from the start, though (crossfire.0? > something like that). Yes - prebuilt image libraries can be included - and if we go to forced cache, would no longer be an option but a requirement. This removes the need to download a lot of images, but doesn't remove the need to know the number to name mapping. From mwedel at sonic.net Sun Jan 31 23:55:40 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 31 Jan 2010 21:55:40 -0800 Subject: [crossfire] Cursed items In-Reply-To: <201001311335.31945.nicolas.weeger@laposte.net> References: <4B53B7C5.4040706@iki.fi> <201001252312.46150.nicolas.weeger@laposte.net> <4B5E95BF.6060001@sonic.net> <201001311335.31945.nicolas.weeger@laposte.net> Message-ID: <4B666CDC.9080803@sonic.net> On 01/31/10 04:35 AM, Nicolas Weeger wrote: >> But I have a feeling players will easily be able to know/defeat these >> things. >> >> As said, getting stuck with a cursed item in that dungeon would be really >> annoying. Especially if you thought it was a really good item (if it isn't >> a good item, you wouldn't use it in the first place). >> >> It's fairly simple to defeat that kill test - go into an easy dungeon and >> kill that 100 creatures in 10 seconds (and I'd say more likely, you don't >> even need to do that - most dungeons are such that you'll be killing >> hundreds of monsters before you get something tough). >> >> It may be possible to have the effect manifest itself on that tough >> monster, but I'm not sure how one measures that. >> >> But more to the point, does this make the game more or less fun? > > Well, then let's remove the whole 'cursed' flag concept, and only do scripted > things... :) that would work. Would require some changes to the treasurelist to be able to add scripts to generated items (or maybe simpler to have cursed archetypes which have treasure list entries, but which have no outward sign of being cursed to players). This works better with objects that normally don't merge (wands, rods come to mind). Otherwise, when you have a +2 sword that doesn't merge with other +2 swords in your inventory, you would know something is up (but don't know what that something is) >> Something similar to the occidental rings but for armor could be done. >> Gives fairly good protection, but when you take damage of that type, there >> is a chance it switches to a different protection. > > > So scripted instead of a mere flag :) For the most part yes. In a sense, there is no such thing as cursed items, there are just some items that have strange effects. Folks may consider them cursed, or may not, but relative to game mechanics, they are just like normal items. It certainly makes things interesting. But even without scripts, you could have some items with pluses and minus. For example, a sword that does +4 dam but gives wearing -10 armor. Is it worth it or not (and one could adjust values to make that a difficult decision)? And certainly some items may basically be useless. A wand that does something unexpected 50% of the time probably isn't useful. But a wand that did that same unexpected stuff 5% of the time might be useful if the spell it contains is a useful spell (that 5% risk is a risk that is low enough you're willing to take it)