From nicolas.weeger at laposte.net Sun Jan 1 07:22:28 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 1 Jan 2012 14:22:28 +0100 Subject: [crossfire] Happy New Year! Message-ID: <201201011422.31527.nicolas.weeger@laposte.net> Hello. I wish to everyone a Happy New Year, and many good things for 2012! Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sun Jan 1 07:23:51 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 1 Jan 2012 14:23:51 +0100 Subject: [crossfire] Messages and quests Message-ID: <201201011423.51433.nicolas.weeger@laposte.net> Hello. I've modified the message handling, for messages in lib/messages, to enable to alter quest stats, and thus start a quest when a message is read. Example is with the 'Temple of Justice' quest. This will enable to add (even small) quests so players learn of various places in the world. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Wed Jan 18 16:26:20 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 18 Jan 2012 23:26:20 +0100 Subject: [crossfire] Patch proposal: unidentified generic faces Message-ID: <201201182326.24151.nicolas.weeger@laposte.net> Hello. I've been playing with having items hide their "real" face unless they are identified. So for instance potions would keep their generic face when not identified. Here's a patch that makes that behaviour. Right now it's only the face (and animation-related parameters), but I was thinking of doing that for the name too. So eg unidentified skill scrolls could have a generic blank face and name until they are identified. Would that behaviour change be ok? The code relies on key-values containing "identified" properties (see common/item.c:object_give_identified_properties for more details). Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: faces-identify.patch Type: text/x-patch Size: 5330 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Thu Jan 19 00:56:20 2012 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 18 Jan 2012 22:56:20 -0800 Subject: [crossfire] Patch proposal: unidentified generic faces In-Reply-To: <201201182326.24151.nicolas.weeger@laposte.net> References: <201201182326.24151.nicolas.weeger@laposte.net> Message-ID: <4F17BE94.50201@sonic.net> On 01/18/12 02:26 PM, Nicolas Weeger wrote: > Hello. > > > I've been playing with having items hide their "real" face unless they are > identified. > > So for instance potions would keep their generic face when not identified. In the distant past, potions used to work that way - generic face until identified. > > > Here's a patch that makes that behaviour. > > > Right now it's only the face (and animation-related parameters), but I was > thinking of doing that for the name too. So eg unidentified skill scrolls could > have a generic blank face and name until they are identified. Yes - this makes sense. Using key/value or other abstraction vs coding in those values makes a lot more sense. I suspect that is the reason that skill scrolls do not work that way - when they were put in, the code was not modified to hide their names. > > > Would that behaviour change be ok? Fine by me. > > > The code relies on key-values containing "identified" properties (see > common/item.c:object_give_identified_properties for more details). Is the way you see doing this is that the archetype contains the unidentified values? I'm just curious as to how the unidentified name/face is determined. From om at iki.fi Thu Jan 19 05:01:06 2012 From: om at iki.fi (Otto J. Makela) Date: Thu, 19 Jan 2012 13:01:06 +0200 Subject: [crossfire] Patch proposal: unidentified generic faces In-Reply-To: <4F17BE94.50201@sonic.net> References: <201201182326.24151.nicolas.weeger@laposte.net> <4F17BE94.50201@sonic.net> Message-ID: <4F17F7F2.8080002@iki.fi> On 2012-01-19 08:56, Mark Wedel wrote: >> The code relies on key-values containing "identified" properties (see >> common/item.c:object_give_identified_properties for more details). > > Is the way you see doing this is that the archetype contains the > unidentified values? I'm just curious as to how the unidentified > name/face is determined. I've been meaning to ask for an addition to the "drop" command (which already has provisions for "all", "cursed", "unpaid" and some similar group properties) to have "identified" and "unidentified" added to the possible groups lists. For symmetry, the "take" command should also have similar properties, I tried and it doesn't even seem to recognize "all" in current versions. And the online documentation (given with "help drop", "help pick" etc) should be expanded to explain this. Maybe the identified/unidentified status should be given more thought, it seems a bit strange to have no need to identify jewels but that the jewelry skill is required specifically for gold nuggets? Currently there are a few things (gold nuggets, lock picks, bottles...) which will fetch more money in the store when identified, but for which neither the face nor seemingly the functionality change when id'd. Zathras: Yes, yes, Zathras is used to being beast of burden to other people's needs. Very sad life. Probably have very sad death, but at least there is symmetry. -- J. Michael Straczynski: Babylon5 -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */ From nicolas.weeger at laposte.net Sat Jan 21 02:13:11 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 21 Jan 2012 09:13:11 +0100 Subject: [crossfire] Patch proposal: unidentified generic faces In-Reply-To: <4F17BE94.50201@sonic.net> References: <201201182326.24151.nicolas.weeger@laposte.net> <4F17BE94.50201@sonic.net> Message-ID: <201201210913.15630.nicolas.weeger@laposte.net> > Is the way you see doing this is that the archetype contains the > unidentified values? I'm just curious as to how the unidentified > name/face is determined. If I implement like the patch suggests, the archetype will contain in the "name", "face" and "animation" fields the unidentified values. And there will be keys for "identified_name", "identified_face", "identified_animation" (and related values like speed). The "object_give_identified_properties()" function, called from "identify()" and some other places, would ensure those "identified_" values are copied over to the item when needed. So we'd alter archetypes to be unidentified by default. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sun Jan 22 06:08:43 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 22 Jan 2012 13:08:43 +0100 Subject: [crossfire] Random maps Message-ID: <201201221308.47925.nicolas.weeger@laposte.net> Hello. So far Crossfire's random maps have been mostly "fillers", really random maps without any particular difficulty (apart killing everything). I'm wondering about trying to improve that, and have more complex maps, with eg traps, levers to find, secret passages, and such things. What do you think of that? Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sun Jan 22 09:40:48 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 22 Jan 2012 16:40:48 +0100 Subject: [crossfire] Archetype and inventory bug Message-ID: <201201221640.48540.nicolas.weeger@laposte.net> Hello. After a crash on invidious, I've found a bug related to archetypes in inventory handling, and I'm really wondering how to fix it :s Here's the description: - when a random map is generated, a special submap can be /styles/specialmaps/powerroom - in this map are firewalls, with a "transferrence" spell in their inventory. The archetypes are "firewall_1", "firewall_2" and such - those archetype contain an archetype "firebullet", because they are firewalls - when the map is generated, the "firebullet" is copied from the archetype, then the "transferrence spell is added - transferrence is the first item in inventory, so that's what the wall casts ; casting this, the wall increases its stats.sp (probably from the crystal, or a player standing on the crystal) - if the map is swapped out, then reloaded from disk, the firewall will have its firebullet item copied from the archetype, then reloads the transferrence item, and the initial firebullet - the firewall now contains, in the order: firebullet (archetype instanciation for reloading), transferrence (from the map definition), firebullet (archetype instanciation for creation) - this is already a bug, but the fun is when the firewall will move, it'll fire in the direction... stats.sp which is now something like 15, 50, 100 - an invalid direction, of course - this crashes in the face updating, setting an invalid face to the item So I'm really puzzled on a correct fix for that... So far I can see: - using a treasurelist for the firewall's spell, having it set to NONE in the map - somehow detecting the map defines an inventory, and not generating the default firebullet, not saving it, or something like that - something else entirely Opinions? Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mail-lists+cfdev at dogphilosophy.net Sun Jan 22 17:04:17 2012 From: mail-lists+cfdev at dogphilosophy.net (mail-lists+cfdev at dogphilosophy.net) Date: Sun, 22 Jan 2012 18:04:17 -0500 Subject: [crossfire] Random maps In-Reply-To: <201201221308.47925.nicolas.weeger@laposte.net> References: <201201221308.47925.nicolas.weeger@laposte.net> Message-ID: <1763753.LueU9mott9@bunnies> The idea sounds great, but the more I think about it, the less enthusiastic I feel about it. Right now, my impression is that random maps are purely unfocussed experience-and-treasure harvesting exercises that don't really advance any sort of storyline. That being the case, it seems like adding randomly-placed traps, doors that need to be opened with randomly-placed levers, etc. would end up just being speedbumps rather than enhancing the play (well, except to the extent that players could gain some experience in search and disarm traps). On the other hand, if there were means of keeping the traps from being TOO random (so players wouldn't have to just keep searching every step to spot them) and additional means of gaining something in exchange for the additional time they cost (for example, if the non-hostile randomly-generated NPC's that show up in places like the "small houses" in Scorn tapped into some database of "general gossip" conversation and/or could grant experience or occasionally give items, or some of the random levers or secret passages led to things you don't normally find (special treasures? Portals to interesting places? A greater likelihood of finding something interesting on or under randomly-generated chairs and tables [even if it's just used gum]?) ) In short, setting it up such that the additional randomly-generated features added something that made the random maps more attractive to play rather than just adding more clutter and/or unrewarding delays to deal with. On the other hand, my own tastes may not match the typical Crossfire player. From mwedel at sonic.net Mon Jan 23 01:28:24 2012 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 22 Jan 2012 23:28:24 -0800 Subject: [crossfire] Archetype and inventory bug In-Reply-To: <201201221640.48540.nicolas.weeger@laposte.net> References: <201201221640.48540.nicolas.weeger@laposte.net> Message-ID: <4F1D0C18.4020007@sonic.net> On 01/22/12 07:40 AM, Nicolas Weeger wrote: > Hello. > > > After a crash on invidious, I've found a bug related to archetypes in > inventory handling, and I'm really wondering how to fix it :s > > > Here's the description: > - when a random map is generated, a special submap can be > /styles/specialmaps/powerroom > > - in this map are firewalls, with a "transferrence" spell in their inventory. > The archetypes are "firewall_1", "firewall_2" and such > > - those archetype contain an archetype "firebullet", because they are firewalls > > - when the map is generated, the "firebullet" is copied from the archetype, > then the "transferrence spell is added > > - transferrence is the first item in inventory, so that's what the wall casts ; > casting this, the wall increases its stats.sp (probably from the crystal, or a > player standing on the crystal) > > - if the map is swapped out, then reloaded from disk, the firewall will have > its firebullet item copied from the archetype, then reloads the transferrence > item, and the initial firebullet Yes - the re-arranging of objects on load/save is a bit of a headache. This was probably originally done for efficiency - it is a lot faster to insert the new object at the head of the list than to walk the list and get the tail (in this case, it doesn't make much difference with just a few objects, but imagine a chest with 500) In practical terms, it may not be that costly to save the map with proper ordering - for objects with inventory, you traverse the list to get to the end, and then just walk backwards - that really isn't going to be any more costly than walking it forward. I also think that if the server is loading in a swapped out map (vs original map), it should not be doing anything with regards to fixing up these objects - the server did that when it originally loaded it, so there is no reason for it to do it again. So the fact it does is a bug. > So I'm really puzzled on a correct fix for that... So far I can see: > > - using a treasurelist for the firewall's spell, having it set to NONE in the > map That is also a pretty good solution, as it is more generally useful. As things are now, there is a reliance on object ordering when the map is loaded. I think it is fair to say that if an archetype has an inventory and it shows up on a map, it is presume that the inventory will be created when the map is loaded. As such, there is no way to remove an archetypes inventory within a map file - one could only add to it. > > - somehow detecting the map defines an inventory, and not generating the > default firebullet, not saving it, or something like that That seems fairly complicated, as there could be many different special cases (in some cases, the map make could be assuming that the object they put in the inventory will get added to what is already there, so if that doesn't happen anymore, that could cause some breakage) From mwedel at sonic.net Mon Jan 23 01:12:17 2012 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 22 Jan 2012 23:12:17 -0800 Subject: [crossfire] Patch proposal: unidentified generic faces In-Reply-To: <201201210913.15630.nicolas.weeger@laposte.net> References: <201201182326.24151.nicolas.weeger@laposte.net> <4F17BE94.50201@sonic.net> <201201210913.15630.nicolas.weeger@laposte.net> Message-ID: <4F1D0851.8090805@sonic.net> On 01/21/12 12:13 AM, Nicolas Weeger wrote: >> Is the way you see doing this is that the archetype contains the >> unidentified values? I'm just curious as to how the unidentified >> name/face is determined. > > > If I implement like the patch suggests, the archetype will contain in the > "name", "face" and "animation" fields the unidentified values. And there will be > keys for "identified_name", "identified_face", "identified_animation" (and > related values like speed). > > The "object_give_identified_properties()" function, called from "identify()" > and some other places, would ensure those "identified_" values are copied over > to the item when needed. > > > So we'd alter archetypes to be unidentified by default. That sounds like it would work out fine. I didn't look at things closely, but one thing I would suggest would be identified/unidentified entries for value of the object. Right now, I believe the code just says unidentified value is some percentage of base archetype value, which I don't think is great. The complication here is that when an item is granted additional properties (for example, pluses added to the sword), the treasure code uses the base value to determine the new value, and stores that new value away (in ob->value) - so to rework that is a bit more effort, so a simpler thing may just to add an 'unidentified_value' to the archetype, and the code can just use that when asked for price. Another reason to have values coded in is if one is really trying to obscure the object, one needs to obscure the value. Otherwise, in the example of potions where the face is the same, one could get the estimated price of two unidentified potions, and get different values, and potentially be able to figure out what the potion is from the value given. If the character has no idea what they are, then they should get the same value for all potions. From nicolas.weeger at laposte.net Wed Jan 25 13:29:52 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 25 Jan 2012 20:29:52 +0100 Subject: [crossfire] Random maps In-Reply-To: <1763753.LueU9mott9@bunnies> References: <201201221308.47925.nicolas.weeger@laposte.net> <1763753.LueU9mott9@bunnies> Message-ID: <201201252029.55569.nicolas.weeger@laposte.net> Hello. > In short, setting it up such that the additional randomly-generated > features added something that made the random maps more attractive to play > rather than just adding more clutter and/or unrewarding delays to deal > with. > > On the other hand, my own tastes may not match the typical Crossfire > player. That was more the kind of things I was thinking of. I don't (for now) intend to change existing random map generation, but merely to add a new type, let's say "sophisticated". The idea would be to use it to generate "complex" maps to challenge the player at some specific points, in special cases. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sat Jan 28 05:47:26 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 28 Jan 2012 12:47:26 +0100 Subject: [crossfire] Patch proposal: unidentified generic faces In-Reply-To: <201201182326.24151.nicolas.weeger@laposte.net> References: <201201182326.24151.nicolas.weeger@laposte.net> Message-ID: <201201281247.32376.nicolas.weeger@laposte.net> Hello. I've committed the patch. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sat Jan 28 07:25:58 2012 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 28 Jan 2012 14:25:58 +0100 Subject: [crossfire] Patch proposal: unidentified generic faces In-Reply-To: <201201281247.32376.nicolas.weeger@laposte.net> References: <201201182326.24151.nicolas.weeger@laposte.net> <201201281247.32376.nicolas.weeger@laposte.net> Message-ID: <201201281426.05122.nicolas.weeger@laposte.net> Hello. I've also changed various scrolls' properties (skill scrolls, improve weapon and enchant armor) so they are regular scrolls by default. I removed their "identified 1" line. This probably means some maps in which those scrolls appear and should be identified will need updating (adding the "identified 1" in the map should do the trick). Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: