From mwedel at sonic.net Wed Sep 1 00:35:34 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 31 Aug 2010 22:35:34 -0700 Subject: [crossfire] Item merging bug In-Reply-To: <4C7C7D21.4010705@sonic.net> References: <201008302212.54341.nicolas.weeger@laposte.net> <4C7C7D21.4010705@sonic.net> Message-ID: <4C7DE626.6070909@sonic.net> On 08/30/10 08:55 PM, Mark Wedel wrote: >> >> Other solution is to remove overlays totally. Not sure if they are used or >> not. > > That would be the approach I'd lean to, but may be harder. But no reason to > have unused code sitting about that creates complications. As I think about this, I believe the main use of overlays was the weather code - so that when it put snow effects, etc, it could know what objects were original to the map (eg, the base mountain) and which objects were put on top by weather effects. I believe the reason for this is so that the base map (say the scorn town) could reset, but the weather effects would persist across that reset. I don?t think anything is using the weather code - I?m not even sure to what extent it still works. From nicolas.weeger at laposte.net Thu Sep 2 11:51:41 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 2 Sep 2010 18:51:41 +0200 Subject: [crossfire] Item merging bug In-Reply-To: <4C7DE626.6070909@sonic.net> References: <201008302212.54341.nicolas.weeger@laposte.net> <4C7C7D21.4010705@sonic.net> <4C7DE626.6070909@sonic.net> Message-ID: <201009021851.45427.nicolas.weeger@laposte.net> > As I think about this, I believe the main use of overlays was the weather > code - so that when it put snow effects, etc, it could know what objects > were original to the map (eg, the base mountain) and which objects were > put on top by weather effects. > > I believe the reason for this is so that the base map (say the scorn > town) could reset, but the weather effects would persist across that > reset. > > I don?t think anything is using the weather code - I?m not even sure to > what extent it still works. The weather code was removed years ago in trunk. So I guess that makes overlays removable? :) Though it can be useful in some cases, like for DMs wanting to leave items persisting resets. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100902/89d8ff0b/attachment.pgp From mwedel at sonic.net Thu Sep 2 23:07:00 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 02 Sep 2010 21:07:00 -0700 Subject: [crossfire] Item merging bug In-Reply-To: <201009021851.45427.nicolas.weeger@laposte.net> References: <201008302212.54341.nicolas.weeger@laposte.net> <4C7C7D21.4010705@sonic.net> <4C7DE626.6070909@sonic.net> <201009021851.45427.nicolas.weeger@laposte.net> Message-ID: <4C807464.2020106@sonic.net> On 09/ 2/10 09:51 AM, Nicolas Weeger wrote: >> As I think about this, I believe the main use of overlays was the weather >> code - so that when it put snow effects, etc, it could know what objects >> were original to the map (eg, the base mountain) and which objects were >> put on top by weather effects. >> >> I believe the reason for this is so that the base map (say the scorn >> town) could reset, but the weather effects would persist across that >> reset. >> >> I don?t think anything is using the weather code - I?m not even sure to >> what extent it still works. > > The weather code was removed years ago in trunk. > > So I guess that makes overlays removable? :) > > > Though it can be useful in some cases, like for DMs wanting to leave items > persisting resets. True. It just seems to me that the implementation is buggy - if on a unique map, it shouldn?t be setting the flag_original value - maybe that is a simpler map - to check for that and not set it. From nicolas.weeger at laposte.net Sat Sep 4 02:55:27 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 4 Sep 2010 09:55:27 +0200 Subject: [crossfire] Item merging bug In-Reply-To: <4C807464.2020106@sonic.net> References: <201008302212.54341.nicolas.weeger@laposte.net> <201009021851.45427.nicolas.weeger@laposte.net> <4C807464.2020106@sonic.net> Message-ID: <201009040955.30405.nicolas.weeger@laposte.net> > True. > > It just seems to me that the implementation is buggy - if on a unique > map, it shouldn?t be setting the flag_original value - maybe that is a > simpler map - to check for that and not set it. But even if we don't set the flag on a unique map, the issue will still be here on non unique maps :) If a DM saves an overlay in a world map, with a silver coin, and a player drops another silver coin, it still won't merge... I think the 2 fixes are either to remove totally overlays, or just ensure items merge even if the ORIGINAL flag is set. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100904/f24ac495/attachment.pgp From nicolas.weeger at laposte.net Sat Sep 4 02:58:06 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 4 Sep 2010 09:58:06 +0200 Subject: [crossfire] Gameplay notes In-Reply-To: <4C7AFAE4.2010008@sonic.net> References: <201008280924.51111.nicolas.weeger@laposte.net> <201008290958.45469.nicolas.weeger@laposte.net> <4C7AFAE4.2010008@sonic.net> Message-ID: <201009040958.06633.nicolas.weeger@laposte.net> > Maybe, but that can be hard if one still tries to keep within those > boundaries of the skill - sorcery is a bit easier since many misc things > can go there, but summoning is trickier - one can add more summoning > spells, but it may just be that summoning itself is going to be less > powerful than shooting up a fireball. For summoning, maybe a fix would be to make base monsters tougher, so they can really help the player kill things, and not just hit 2 times before being destroyed... Maybe increase hp a lot, like tenfold? > Trying to run all ticks at load time would likely create performance > problems, as now you have to do all that processing at once. A better > (and simpler solution) would just be to increase the map swap out time to > something like 10 minutes - most likely, if a player doesn't return within > 10 minutes, unlikely to do so (or if they do, that is probably still long > enough any spells/diseases they created have run their course). For low level diseases like leprosy, it can easily take >20 or 30 minutes to kill a monster... So a player casting that and exiting the map to be safe could not use the disease to kill. > That would also have some performance impact - more memory and cpu time > to process that map while in memory, but that is probably not a problem > for most modern systems - the amount of memory systems have has gone up > dramatically - the cpu one might be more an issue. I really don't think it'd be that bad, but maybe experiments are in order. The first step could be to move swap time to a settings, so admins can experiment. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100904/a3411b75/attachment.pgp From nicolas.weeger at laposte.net Sat Sep 4 03:02:08 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 4 Sep 2010 10:02:08 +0200 Subject: [crossfire] Gameplay notes In-Reply-To: <4C79F06C.2040002@sonic.net> References: <201008280924.51111.nicolas.weeger@laposte.net> <201008280959.14544.nicolas.weeger@laposte.net> <4C79F06C.2040002@sonic.net> Message-ID: <201009041002.08674.nicolas.weeger@laposte.net> > Agree on both of those - I think paralyze would be acceptable if the > duration was much shorter (say for 1-5 ticks) - confusion could perhaps > last a little longer, but same thing, if it was a short duration, that > might be OK. Paralysis can be as long as is it now, provided it isn't used by low level monsters. I mean, a gnome level 6 paralysing (that's now removed) is bad for low level players :( Another option could be to have "temporary immunity", like you get paralyzed 100% of the duration the first time, and if hit in the next 5s only 50%, then only 25%. This would avoid the "getting paralyzed when you're paralyzed" issue. > I suppose the fact you need scrolls adds some use for inscription :) Yes, but that's actually weird - if I'm confused, what's ensuring I'm reading the correct scroll? :D > I also think that there are 'issues' in the way spells also move - it > isn't like your character has to make one saving through and is set - > because the way cones move, you probably get hit by the spell many times, > so are almost sure to be affected. There could be a small immunity / resistance if you avoid the first time. > Yes - the amount of damage it does, and/or the fact that there is no way > to repair them. > > I think experienced players know the monsters to look out for and use > other methods to kill them - but this is probably a real annoyance for new > players. Yes, especially for newbies. Solutions could be to have reparation, but that would downgrade the acid's value. Another option is to use that only on high level maps, or after the player has been warned ("you smell something acid"). > I've found in many cases, if you have some amount of healing (or > potentially enough food), you can outlast it that way also. It really > depends on how many hp you have when you get hit by it, and how quickly > you can get to someplace where you want take any damage other than that of > the poison. I don't think that's an issue. Though poison could be made more violent for higher level monsters - like lose >100 maximum hp and 5 speed, things like that. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100904/01fe2299/attachment.pgp From nicolas.weeger at laposte.net Sat Sep 4 07:54:05 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 4 Sep 2010 14:54:05 +0200 Subject: [crossfire] Map access Message-ID: <201009041454.09146.nicolas.weeger@laposte.net> Hello. With the new quest system, some maps are now only available if the player is doing the correct quest. Such maps will also be available only once. For instance, the animator's quest in Scorn, or the Titan quest. I admit I'm not that glad of those restrictions. One should probably be able to enter any map (unless some restrictions to enter are really mandatory), but maps like titan quest are good places to find monsters. What are your opinions? Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100904/e9b94e00/attachment.pgp From kbulgrien at att.net Sat Sep 4 08:58:06 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sat, 4 Sep 2010 08:58:06 -0500 Subject: [crossfire] Gameplay notes In-Reply-To: <201009040958.06633.nicolas.weeger@laposte.net> References: <201008280924.51111.nicolas.weeger@laposte.net> <201008290958.45469.nicolas.weeger@laposte.net> <4C7AFAE4.2010008@sonic.net> <201009040958.06633.nicolas.weeger@laposte.net> Message-ID: <20100904085806.3180ea02@srv_10s.kbulgrien.att.net> > For summoning, maybe a fix would be to make base monsters tougher, so they can > really help the player kill things, and not just hit 2 times before being > destroyed... > Maybe increase hp a lot, like tenfold? I think I agree to this... though I have never claimed to be a games master. Summoning is unreasonably difficult to use at low levels. This seems like a reasonable way to start making it more usable. Kevin From kbulgrien at att.net Sat Sep 4 09:06:52 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sat, 4 Sep 2010 09:06:52 -0500 Subject: [crossfire] Map access In-Reply-To: <201009041454.09146.nicolas.weeger@laposte.net> References: <201009041454.09146.nicolas.weeger@laposte.net> Message-ID: <20100904090652.165f982b@srv_10s.kbulgrien.att.net> > With the new quest system, some maps are now only available if the player is > doing the correct quest. Such maps will also be available only once. Are you sure? I think that quests are restartable? But maybe not. Perhaps only certain quests are restartable. > For instance, the animator's quest in Scorn, or the Titan quest. > > I admit I'm not that glad of those restrictions. One should probably be able > to enter any map (unless some restrictions to enter are really mandatory), but > maps like titan quest are good places to find monsters. > > What are your opinions? Well, I'm not sure, but perhaps a compromise is to make sure the quests are restartable some relatively small number of times, or, say restartable after some length of time, or some other creative and reasonable parameter. I tend to think that Crossfire will be a better game with some limitations on playing the same maps over and over and over again. Now I don't play a lot, so my play times are often spanned by large amounts of time and I like to be able to replay maps that I have not done in a long time just to re-enjoy them without necessarily trying to abuse the map. In this way I guess I agree. I would really like to be able to revisit maps at least a little bit. I still think that somehow map abuse should probably be nerfed. Like tracking frequency of use and somehow downgrading earned experience, but then I don't know... maybe that is a map problem rather than a game mechanics problem. Kevin From nicolas.weeger at laposte.net Sat Sep 4 14:18:59 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 4 Sep 2010 21:18:59 +0200 Subject: [crossfire] CRE changes, and questions Message-ID: <201009042119.03246.nicolas.weeger@laposte.net> Hello. I'm modifying CRE to load resources (archetypes, treasures, faces and such) from the individual files, instead of the collected ones. This will, ultimately, enable edition of said files (treasures, animations, all I can think of or what people ask for). I do not use the Crossfire structures, but C++ classes (easier to use with Qt stuff). Now, since CRE currently uses the Crossfire common library, I load two times many things, one with my split-file loading, and one with the common library. The library is required to load maps to generate information on archetype use, show exits between maps, things like that. This isn't a great situation :) I see three options: a) leave it that way, use library for map loading and individual files for the edition b) remove the map browsing feature, and the common dependancy altogether c) rewrite the map loading code to adjust to my classes, and remove the common dependancy I voluntarily leave out solutions d) change server to use file-based loading (I won't do that in pure C), and e) move server to C++/Qt (I'm not fire-proof :)). I admit solution a) doesn't suit me much. The 'common' library dependancy makes CRE hard to build under Windows, so I'd rather move to a pure C++/Qt program (this would also enable moving CRE to its own top-level directory, maybe). On the other hand, b) isn't that great either, because use information is useful I think. Any opinion on that? Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100904/f76c3800/attachment.pgp From mwedel at sonic.net Sat Sep 4 23:47:41 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Sep 2010 21:47:41 -0700 Subject: [crossfire] Item merging bug In-Reply-To: <201009040955.30405.nicolas.weeger@laposte.net> References: <201008302212.54341.nicolas.weeger@laposte.net> <201009021851.45427.nicolas.weeger@laposte.net> <4C807464.2020106@sonic.net> <201009040955.30405.nicolas.weeger@laposte.net> Message-ID: <4C8320ED.5020606@sonic.net> On 09/ 4/10 12:55 AM, Nicolas Weeger wrote: >> True. >> >> It just seems to me that the implementation is buggy - if on a unique >> map, it shouldn?t be setting the flag_original value - maybe that is a >> simpler map - to check for that and not set it. > > > But even if we don't set the flag on a unique map, the issue will still be here > on non unique maps :) True. > > If a DM saves an overlay in a world map, with a silver coin, and a player > drops another silver coin, it still won't merge... > > > I think the 2 fixes are either to remove totally overlays, or just ensure items > merge even if the ORIGINAL flag is set. Making it so objects merge is fairly straight forward - just updated CAN_MERGE to ignore that flag. That is probably simplest, and still leaves the overlay functionality in place. From mwedel at sonic.net Sun Sep 5 00:12:05 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Sep 2010 22:12:05 -0700 Subject: [crossfire] Gameplay notes In-Reply-To: <201009041002.08674.nicolas.weeger@laposte.net> References: <201008280924.51111.nicolas.weeger@laposte.net> <201008280959.14544.nicolas.weeger@laposte.net> <4C79F06C.2040002@sonic.net> <201009041002.08674.nicolas.weeger@laposte.net> Message-ID: <4C8326A5.1050005@sonic.net> On 09/ 4/10 01:02 AM, Nicolas Weeger wrote: >> Agree on both of those - I think paralyze would be acceptable if the >> duration was much shorter (say for 1-5 ticks) - confusion could perhaps >> last a little longer, but same thing, if it was a short duration, that >> might be OK. > > Paralysis can be as long as is it now, provided it isn't used by low level > monsters. > I mean, a gnome level 6 paralysing (that's now removed) is bad for low level > players :( Long paralysis is pretty much annoying at any level - at higher levels if you are paralyzed for several seconds of real time, your just stuck there hoping you survive - nothing you can do about it. Not the best experience. But being paralyzed for several ticks would still be pretty bad in higher level fights - it may mean the first thing you have to do when the paralyze runs out is heal yourself. If paralyze still lasted a long time at higher levels, I think the immunity to paralyze items would continue to be a standard item everyone needs. I'd personally prefer that there not be a standard set of items (or attributes they provide), but rather things are balanced such that decisions on items are not as clear cut - being immune to paralysis may be nice, but if it just gets me for a few ticks, maybe I'd rather have a boost in hp regen and take my chances. > Another option could be to have "temporary immunity", like you get paralyzed > 100% of the duration the first time, and if hit in the next 5s only 50%, then > only 25%. > This would avoid the "getting paralyzed when you're paralyzed" issue. Or maybe just some minimal time (few ticks) where you are immune after the effect wears off, so even if paralyze was short, you could never be paralyzed more than 75% of the time or something (this would hopefully at least give you time to heal up, run away, or put on that resistance to paralysis item) I'd also note that currently, confusion, paralysis and drain are really the few attacktypes where 100% immunity items for them exists - this sort of suggests that even 90% immunity just isn't that great, which may be some indication that the attacks are too deadly/annoying. >> I suppose the fact you need scrolls adds some use for inscription :) > > Yes, but that's actually weird - if I'm confused, what's ensuring I'm reading > the correct scroll? :D That's a different discussion. Note that at one time, confusion did not affect spellcasting, it really only affected movement, so back in those days, you could cure confusion yourself and be sure it would work. > > > > >> I also think that there are 'issues' in the way spells also move - it >> isn't like your character has to make one saving through and is set - >> because the way cones move, you probably get hit by the spell many times, >> so are almost sure to be affected. > > > There could be a small immunity / resistance if you avoid the first time. I had thought of redoing the way cones/exploding ball spells move - basic idea is that instead of a bunch of objects moving and copying themselves to move further, one 'master' object is created at the start point (for case of cones) or center point (for case of exploding balls) - that master point would then be what is called and puts in the new objects on the map based on where last one was placed, range, duration, etc. Aside from this being much more efficient (there would only need to be one spell object per spell per space, vs the many right now), this could also allow for nicer looking spell effects - eg, for cones, one could have a 1 space, 2 space, etc, cone graphic (with potentially smooth transitions between them) and that master object updates the graphic in use based on how the cone expands. This is a bit simplistic - for the graphics, one could have to figure out how to handle walls that may be blocking it (putting the spell effect over the wall may not look right). But if that was done, then since there would only be one spell object/space, only one saving throw would be needed - check for creatures on space when spell effect moves there, and do save at that time. If player moves, one could see if they are moving from a space where the effect has already hit - if so, no save is needed (they have already done so), if not, save again. Some spell effects could perhaps have repeated saving throws - something like poison gas should probably cause person to save as long as they are in it. >> Yes - the amount of damage it does, and/or the fact that there is no way >> to repair them. >> >> I think experienced players know the monsters to look out for and use >> other methods to kill them - but this is probably a real annoyance for new >> players. > > Yes, especially for newbies. > Solutions could be to have reparation, but that would downgrade the acid's > value. > Another option is to use that only on high level maps, or after the player has > been warned ("you smell something acid"). Acid, especially at high levels, has been downgraded just on the fact that most items are made from either nothing, or something that is immune to the effects - that is likely an affect simply because even at high levels, acid is really annoying. I think best way would be to allow repairs - and make the cost of the repair based on the items value - that would suck some money at of higher players. Simplest way to do this is not have acid change the object itself (since then you don't really know what it was if it was something like a +4 sword), but either add a key-value field like 'degradation' or perhaps add a force object to the damaged object that indicates how the object has been damaged (eg, ac -2, magic -2, armor -20, etc). The fix player code would then just look for that and apply changes. In case of degradation key/value, that could be used as a percentage value, which reduces the effectiveness of the object, eg, if degradation is 50 (meaning half damaged), the damage it does if 50% less, armor it provides is 50% less, etc. Something with 100% degradation is useless - does no damage, provides no ac, etc. That is probably better than the current system of negatives - it seems completely reasonable to me that a sword may do a lot less damage when corroded, but should still hit just as well - at some point, it is effectively just a club, and thus by default don't have negatives to hit. > > > >> I've found in many cases, if you have some amount of healing (or >> potentially enough food), you can outlast it that way also. It really >> depends on how many hp you have when you get hit by it, and how quickly >> you can get to someplace where you want take any damage other than that of >> the poison. > > > I don't think that's an issue. > Though poison could be made more violent for higher level monsters - like lose >> 100 maximum hp and 5 speed, things like that. AD&Dv3 made interesting changes to poison - they do temporary stat damage. Same could pretty simply be applied to crossfire - a poison that does 6 con damage is going to be something you probably want to cure pretty quickly. But it also means some poisons may be harmless to certain characters, eg, one that does 6 power damage may no be of much concern to barbarians. From mwedel at sonic.net Sun Sep 5 00:18:13 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Sep 2010 22:18:13 -0700 Subject: [crossfire] Gameplay notes In-Reply-To: <201009040958.06633.nicolas.weeger@laposte.net> References: <201008280924.51111.nicolas.weeger@laposte.net> <201008290958.45469.nicolas.weeger@laposte.net> <4C7AFAE4.2010008@sonic.net> <201009040958.06633.nicolas.weeger@laposte.net> Message-ID: <4C832815.6090804@sonic.net> On 09/ 4/10 12:58 AM, Nicolas Weeger wrote: >> Maybe, but that can be hard if one still tries to keep within those >> boundaries of the skill - sorcery is a bit easier since many misc things >> can go there, but summoning is trickier - one can add more summoning >> spells, but it may just be that summoning itself is going to be less >> powerful than shooting up a fireball. > > > For summoning, maybe a fix would be to make base monsters tougher, so they can > really help the player kill things, and not just hit 2 times before being > destroyed... > Maybe increase hp a lot, like tenfold? That seems reasonable, or perhaps other adjustments like better ac or better armor. One weakness of lots of monsters is their armor rating tends to be pretty low. I think right now, summoning basically just uses the 'stock' monsters and makes some customizations to them. One could see why they are pretty weak - player is expected to kill dozens of them, so it is going to be a lot weaker than the player at same level. Probably best to make up a separate set of monsters archs which are used for summoning - these may have same name, but are tougher - this lets one tweak them a lot better than trying to adjust the code that makes changes to do the right thing, because I could imagine for some summoned creatures, giving them a huge number of extra hp would make them way too good. >> Trying to run all ticks at load time would likely create performance >> problems, as now you have to do all that processing at once. A better >> (and simpler solution) would just be to increase the map swap out time to >> something like 10 minutes - most likely, if a player doesn't return within >> 10 minutes, unlikely to do so (or if they do, that is probably still long >> enough any spells/diseases they created have run their course). > > For low level diseases like leprosy, it can easily take>20 or 30 minutes to > kill a monster... > So a player casting that and exiting the map to be safe could not use the > disease to kill. They would have to return to the map so it stays swapped in. That said, one could argue that if one is not on the same map, maybe one should not get exp for kills on it. >> That would also have some performance impact - more memory and cpu time >> to process that map while in memory, but that is probably not a problem >> for most modern systems - the amount of memory systems have has gone up >> dramatically - the cpu one might be more an issue. > > I really don't think it'd be that bad, but maybe experiments are in order. > The first step could be to move swap time to a settings, so admins can > experiment. I expect for vast majority of systems, increasing timeout won't cause any issues. Beyond timeout (which can probably be modified while the server is running with no real bad effects), there is also some counter for max number of objects in memory - that would also need to be a setting. From mwedel at sonic.net Sun Sep 5 00:29:46 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Sep 2010 22:29:46 -0700 Subject: [crossfire] Map access In-Reply-To: <20100904090652.165f982b@srv_10s.kbulgrien.att.net> References: <201009041454.09146.nicolas.weeger@laposte.net> <20100904090652.165f982b@srv_10s.kbulgrien.att.net> Message-ID: <4C832ACA.2060700@sonic.net> On 09/ 4/10 07:06 AM, Kevin Bulgrien wrote: >> With the new quest system, some maps are now only available if the player is >> doing the correct quest. Such maps will also be available only once. > > Are you sure? I think that quests are restartable? But maybe not. Perhaps > only certain quests are restartable. It is never really explained in game terms why maps reset and are suddenly full of bad creatures again (as well as treasure). It is just how the world works. But in such a world, one would think that the authorities wouldn't mind folks going in there again and clearing out all the creatures. They may not reward the character again, but probably wouldn't mind. > >> For instance, the animator's quest in Scorn, or the Titan quest. >> >> I admit I'm not that glad of those restrictions. One should probably be able >> to enter any map (unless some restrictions to enter are really mandatory), but >> maps like titan quest are good places to find monsters. >> >> What are your opinions? > > Well, I'm not sure, but perhaps a compromise is to make sure the quests are > restartable some relatively small number of times, or, say restartable after > some length of time, or some other creative and reasonable parameter. I tend > to think that Crossfire will be a better game with some limitations on playing > the same maps over and over and over again. Some games do this by basically tracking where player has been, and not giving as good loot if player keeps on same maps. I'm not sure how that would be implemented in crossfire, but in theory that discourages players from camping out on maps waiting for the good drop. > > Now I don't play a lot, so my play times are often spanned by large amounts of > time and I like to be able to replay maps that I have not done in a long time > just to re-enjoy them without necessarily trying to abuse the map. In this > way I guess I agree. I would really like to be able to revisit maps at least > a little bit. In that mode of player, putting time gaps in place between revisits would work fine for you. But for players that are looking for good maps that match their level, they may be repeating the same map because it is one they know that works. I guess the question always comes down to why to players repeat the same maps. Is it treasure? If so, reducing treasure on repeated visits would discourage that. Is it exp? If so, one could reduce exp rewards also, but that would then mean that there are good alternatives. > > I still think that somehow map abuse should probably be nerfed. Like tracking > frequency of use and somehow downgrading earned experience, but then I don't > know... maybe that is a map problem rather than a game mechanics problem. Probably depends on why folks repeat - in some cases, it probably is a map problem (lots of fast/easy exp) The exp issue is a harder one to deal with - since you lose exp on death, it is pretty reasonable that character may need to return to maps they have played before. One thought, and I'm not 100% how to do this, would be some option to let playes 'instance' a map/map chain when they first enter it. What I mean by this is that they get a copy for themselves. In that way, if someone else has cleared out that map, they can go and play it - maybe only allow this once for each map, and just treat it as a per player unique map from that point onward. That at least fixes the problem that 'I can never do this map because it is always cleared out'. From agschult at ucalgary.ca Sun Sep 5 00:36:26 2010 From: agschult at ucalgary.ca (Alex Schultz) Date: Sun, 5 Sep 2010 01:36:26 -0400 Subject: [crossfire] Gameplay notes In-Reply-To: <4C832815.6090804@sonic.net> References: <201008280924.51111.nicolas.weeger@laposte.net> <201008290958.45469.nicolas.weeger@laposte.net> <4C7AFAE4.2010008@sonic.net> <201009040958.06633.nicolas.weeger@laposte.net> <4C832815.6090804@sonic.net> Message-ID: <20100905013626.51725d25@ucalgary.ca> On Sat, 04 Sep 2010 22:18:13 -0700 Mark Wedel wrote: > > For summoning, maybe a fix would be to make base monsters tougher, > > so they can really help the player kill things, and not just hit 2 > > times before being destroyed... > > Maybe increase hp a lot, like tenfold? > > That seems reasonable, or perhaps other adjustments like better ac > or better armor. > > One weakness of lots of monsters is their armor rating tends to be > pretty low. > > I think right now, summoning basically just uses the 'stock' > monsters and makes some customizations to them. One could see why > they are pretty weak - player is expected to kill dozens of them, so > it is going to be a lot weaker than the player at same level. > > Probably best to make up a separate set of monsters archs which are > used for summoning - these may have same name, but are tougher - this > lets one tweak them a lot better than trying to adjust the code that > makes changes to do the right thing, because I could imagine for some > summoned creatures, giving them a huge number of extra hp would make > them way too good. It's been a while since I've played or been involved with CF, but I'd like to point out that in my experience summoned monsters are generally much more impaired in attack than toughness. To see what I mean, have two players enter the arena using summons and "petmode arena". You'll tend to see that most summons are unable to kill other summons in any reasonable amount of time. It tends to be a stalemate when monsters fight eachother because they usually regenerate faster than they get damaged by a monster of equal strength. The situation would be the same in using summons against anything else, and simply giving better hp/ac/armor will not alone help. From nicolas.weeger at laposte.net Wed Sep 8 14:17:31 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 8 Sep 2010 21:17:31 +0200 Subject: [crossfire] Map access In-Reply-To: <20100904090652.165f982b@srv_10s.kbulgrien.att.net> References: <201009041454.09146.nicolas.weeger@laposte.net> <20100904090652.165f982b@srv_10s.kbulgrien.att.net> Message-ID: <201009082117.35202.nicolas.weeger@laposte.net> > Are you sure? I think that quests are restartable? But maybe not. > Perhaps only certain quests are restartable. Some are, but the Scorn nobility ones are not :) > I still think that somehow map abuse should probably be nerfed. Like > tracking frequency of use and somehow downgrading earned experience, but > then I don't know... maybe that is a map problem rather than a game > mechanics problem. IMO this is a map problem. And I'd rather spend time making maps than trying to fix map abuse :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100908/dc9efa4b/attachment.pgp From nicolas.weeger at laposte.net Wed Sep 8 14:22:30 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 8 Sep 2010 21:22:30 +0200 Subject: [crossfire] Gameplay notes In-Reply-To: <4C832815.6090804@sonic.net> References: <201008280924.51111.nicolas.weeger@laposte.net> <201009040958.06633.nicolas.weeger@laposte.net> <4C832815.6090804@sonic.net> Message-ID: <201009082122.31112.nicolas.weeger@laposte.net> > That seems reasonable, or perhaps other adjustments like better ac or > better armor. > > One weakness of lots of monsters is their armor rating tends to be pretty > low. > > I think right now, summoning basically just uses the 'stock' monsters and > makes some customizations to them. One could see why they are pretty weak > - player is expected to kill dozens of them, so it is going to be a lot > weaker than the player at same level. > > Probably best to make up a separate set of monsters archs which are used > for summoning - these may have same name, but are tougher - this lets one > tweak them a lot better than trying to adjust the code that makes changes > to do the right thing, because I could imagine for some summoned > creatures, giving them a huge number of extra hp would make them way too > good. Yes, it could be specific monsters, not found in maps. Would make it funnier, maybe, even. As a side note, a fun thing: a summoned golem won't attack another golem :) > They would have to return to the map so it stays swapped in. That said, > one could argue that if one is not on the same map, maybe one should not > get exp for kills on it. I'm not sure one way or the other. In any case care should be taken for tiled maps :) > I expect for vast majority of systems, increasing timeout won't cause any > issues. Beyond timeout (which can probably be modified while the server is > running with no real bad effects), there is also some counter for max > number of objects in memory - that would also need to be a setting. I'd say 5 or 10 mins for a map should be ok. But well, I'm no server admin :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100908/b0462046/attachment.pgp From nicolas.weeger at laposte.net Tue Sep 21 14:17:04 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 21 Sep 2010 21:17:04 +0200 Subject: [crossfire] Setting path to spells Message-ID: <201009212117.08067.nicolas.weeger@laposte.net> Hello. The following spells don't have any path set: - slow ability - invulnerability - levitate - color spray - shockwave - slow - wave - windstorm - destruction - earth to dust - improved invisibility - invisible - invisible to undead - marking rune - aggravation They should probably have one set, so they benefit from various talismans. This would also fix a bug with Valkyrie followers who can still cast spells. I propose the following: - the three invisible spells: mind path ; you twist your opponent's mind to appear invisible - destruction: detonation - levitate: Transmutation or Teleportation? - aggravation: mind - slow: transmutation? Other proposals? :) Note that I gave cause black death the wounding path, to be coherent with other disease spells. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100921/ad823af6/attachment.pgp From nicolas.weeger at laposte.net Tue Sep 21 14:30:36 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 21 Sep 2010 21:30:36 +0200 Subject: [crossfire] Setting path to spells In-Reply-To: <201009212117.08067.nicolas.weeger@laposte.net> References: <201009212117.08067.nicolas.weeger@laposte.net> Message-ID: <201009212130.39979.nicolas.weeger@laposte.net> Courtesy Ragnor: http://crossfire.svn.sourceforge.net/viewvc/crossfire/server/trunk/include/spells.h?revision=13851&content- type=text%2Fplain for the existing paths :) Nicolas Le mardi 21 septembre 2010 21:17:04, Nicolas Weeger a ?crit : > Hello. > > > The following spells don't have any path set: > > - slow ability > - invulnerability > - levitate > - color spray > - shockwave > - slow > - wave > - windstorm > - destruction > - earth to dust > - improved invisibility > - invisible > - invisible to undead > - marking rune > - aggravation > > They should probably have one set, so they benefit from various talismans. > This would also fix a bug with Valkyrie followers who can still cast > spells. > > > I propose the following: > - the three invisible spells: mind path ; you twist your opponent's mind to > appear invisible > - destruction: detonation > - levitate: Transmutation or Teleportation? > - aggravation: mind > - slow: transmutation? > > > Other proposals? :) > > > Note that I gave cause black death the wounding path, to be coherent with > other disease spells. > > > > Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100921/b3c1f11b/attachment.pgp From mwedel at sonic.net Wed Sep 22 00:33:17 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 21 Sep 2010 22:33:17 -0700 Subject: [crossfire] Setting path to spells In-Reply-To: <201009212117.08067.nicolas.weeger@laposte.net> References: <201009212117.08067.nicolas.weeger@laposte.net> Message-ID: <4C99951D.4090804@sonic.net> On 09/21/10 12:17 PM, Nicolas Weeger wrote: > Hello. > > > The following spells don't have any path set: > > - slow ability > - invulnerability > - levitate > - color spray > - shockwave > - slow > - wave > - windstorm > - destruction > - earth to dust > - improved invisibility > - invisible > - invisible to undead > - marking rune > - aggravation > > They should probably have one set, so they benefit from various talismans. > This would also fix a bug with Valkyrie followers who can still cast spells. > > > I propose the following: > - the three invisible spells: mind path ; you twist your opponent's mind to > appear invisible One could also say those are in the light path, since they affect how light travels (a better path name could actually be illusion). That way you don't have to worry if the creature has no mind (say blobs) > - destruction: detonation > - levitate: Transmutation or Teleportation? under normal definition, should be transmutation - you are effectively altering the weight of the given object so that it floats. To me, teleportation is the instant travel from one point to another, like town portal, dimension door, maybe a few others. > - aggravation: mind I think the only thing that used aggravation was the horn of aggravation, so path on that probably doesn't matter much, but mind would seem appropriate. > - slow: transmutation? That would make sense - I guess one could like at what paralyze is, since slow is really just a less extreme version of that. From kbulgrien at att.net Sat Sep 25 20:35:02 2010 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sat, 25 Sep 2010 20:35:02 -0500 Subject: [crossfire] sound2 protocol and issues: sound_chance Message-ID: <201009252035.02891.kbulgrien@att.net> At the time sound2 was implemented, a sound_chance property was set up. No arches were modified. This effectively disables all sound support. By SVN records, sound has been disabled for about 2.75 years because of sound2 implementation of sound_chance. What purpose can sound_chance even be put to in such quantity that it makes such sweeping arch changes reasonable? If an item/action produces sound, it is very difficult to conceive of a logical reason for. I.e. Explode this bomb and 9 out of 10 times the massive, concussive blast produces no sound for absolutely no obvious reason. I suppose a door could randomly squeak, but even then, silence vs. squeak seems less than ideal It would be better to have an alternate sound instead of silence. I think that sound_chance should be dispensed with, however, it would be possible to return the server to functionality without massive arch changes by simply changing the sound_chance 0 to be equivalent to sound_chance 100 at the point where the check is made before the sound is played, perhaps on grounds that a sound-making device probably will rarely need to not make a noise. Kevin From kbulgrien at att.net Sat Sep 25 20:50:54 2010 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sat, 25 Sep 2010 20:50:54 -0500 Subject: [crossfire] sound2 protocol and issues: arbitrary volume Message-ID: <201009252050.54630.kbulgrien@att.net> server/trunk/doc/Developers/sound describes the sound2 protocol and a volume component to the sound protocol. It indicates that the server arbitrarily sets volume "for variability". This seems to be a questionable server-side function. I do not really think it fits well with a client/server paradigm for the server to dictate things like that. While I can see a map or a arch setting volume for some specific purpose, it seems that something like randomizing of volume is better implemented on a client side according to the desires of the player rather than on the whim of the server. Then there is the question of how random the server does it. I see no real benefit in random 0-100% at all as that basically silences the sound if you are running the game quiet to not disturb others. Frankly, I'd prefer to ignore server volume instructions altogether than support randomized volume unless it is implemented in a way that limits the "variability" to a reasonably small range... but the assertion is still made that this is a client function rather than a server function. Kevin From kbulgrien at att.net Sat Sep 25 21:07:11 2010 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sat, 25 Sep 2010 21:07:11 -0500 Subject: [crossfire] sound2 issues: cfsndserv broken 2.75 yrs. Message-ID: <201009252107.11676.kbulgrien@att.net> Here's encouraging the planning of client-breaker implementation of server features such that all officially released clients are not left broken without also considering their repair in a reasonable period of time. From kbulgrien at att.net Sat Sep 25 21:25:09 2010 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sat, 25 Sep 2010 21:25:09 -0500 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <201009252035.02891.kbulgrien@att.net> References: <201009252035.02891.kbulgrien@att.net> Message-ID: <201009252125.09738.kbulgrien@att.net> > What purpose can sound_chance even be put to in such quantity that it makes > such sweeping arch changes reasonable? If an item/action produces sound, > it is very difficult to conceive of a logical reason for. I.e. Explode > this bomb and 9 out of 10 times the massive, concussive blast produces no > sound for absolutely no obvious reason. I suppose a door could randomly > squeak, but even then, silence vs. squeak seems less than ideal It would > be better to have an alternate sound instead of silence. > > I think that sound_chance should be dispensed with, however, it would be > possible to return the server to functionality without massive arch changes > by simply changing the sound_chance 0 to be equivalent to sound_chance 100 > at the point where the check is made before the sound is played, perhaps > on grounds that a sound-making device probably will rarely need to not > make a noise. I retract the "I think sound_chance should be dispensed with". I finally found the mail list note that mentioned some changes to sound so it could support random ambient sounds to improve overall immersion in the game environment... Still, the idea that 0 behaves the same as 100 seems compatible with this. Any objections? Kevin From nicolas.weeger at laposte.net Sun Sep 26 03:23:58 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 26 Sep 2010 10:23:58 +0200 Subject: [crossfire] sound2 protocol and issues: arbitrary volume In-Reply-To: <201009252050.54630.kbulgrien@att.net> References: <201009252050.54630.kbulgrien@att.net> Message-ID: <201009261024.01592.nicolas.weeger@laposte.net> Hello. > server/trunk/doc/Developers/sound describes the sound2 protocol and a > volume component to the sound protocol. It indicates that the server > arbitrarily sets volume "for variability". Actually, the "abitrarily" was supposed to mean "0 is basically totally attenued, 100 is the full sound's volume ; but the maximum sound volume is how many decibels you want". As opposed to "100 means the sound plays at x decibels". But that's probably not really nicely written :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100926/8f0acdbb/attachment.pgp From nicolas.weeger at laposte.net Sun Sep 26 03:29:42 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 26 Sep 2010 10:29:42 +0200 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <201009252125.09738.kbulgrien@att.net> References: <201009252035.02891.kbulgrien@att.net> <201009252125.09738.kbulgrien@att.net> Message-ID: <201009261029.42863.nicolas.weeger@laposte.net> Hello. > I retract the "I think sound_chance should be dispensed with". I finally > found the mail list note that mentioned some changes to sound so it could > support random ambient sounds to improve overall immersion in the game > environment... Still, the idea that 0 behaves the same as 100 seems > compatible with this. Any objections? I'm not against it (though it breaks the "0 or empty by default" rule that is always used elsewhere), but sounds should be defined anyway for archetypes and other things, so it shouldn't be too hard to add the "sound_chance" line at the same time. As for why there is no sound_chance defined for now, the reason is that I expected sounds to be added incrementally, one sound here, another there. So no massive changes, but progressive ones. Alas, never managed to do those changes. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100926/f3cab16e/attachment.pgp From nicolas.weeger at laposte.net Sun Sep 26 03:38:57 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 26 Sep 2010 10:38:57 +0200 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[13885] server/trunk/doc/Developers/protocol In-Reply-To: References: Message-ID: <201009261038.57715.nicolas.weeger@laposte.net> Extract from the Developers/protocol: Change background music. Server will send NONE as the string to stop any music from playing. This song data is set in a map property. (Due to someone forgetting to update this file when he/she implemented the command, it is unknown what exactly should be done with the string parameter, is it a filename? If yes: relative what?) That wasn't precisely defined during server implementation, because client-side wasn't yet implemented. There were 2 global ideas: - it's a song or file name, the client knows where to find it (either bundled or to be downladed from some site to be defined) - it's a mood name (eg: "dangerous place", or "port area") that the client would pick up to arbitrarily decide what music to use from its pool Arguments I remember are that it would be better to have music match on the clients, because if you were playing together it would be weird to have different musics at the same place. So the best idea is probably to make that a filename. Of course that means to wonder where the client should get that one, and how to handle custom background musics. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100926/9d32cf60/attachment.pgp From nicolas.weeger at laposte.net Sun Sep 26 04:31:57 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 26 Sep 2010 11:31:57 +0200 Subject: [crossfire] Setting path to spells In-Reply-To: <201009212117.08067.nicolas.weeger@laposte.net> References: <201009212117.08067.nicolas.weeger@laposte.net> Message-ID: <201009261132.00953.nicolas.weeger@laposte.net> Hello. I set the following paths, feel free to suggest other versions :) > - slow ability > - slow > - aggravation Mind > - invulnerability > - levitate > - color spray > - earth to dust Transmutation (color spray: you rapidly transmute the attack vector to one attack to another) > - shockwave > - destruction Detonation > - improved invisibility > - invisible > - invisible to undead Light > - marking rune Summon > - wave Cold > - windstorm Electricity This means all spells have a path :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100926/984291fd/attachment.pgp From nicolas.weeger at laposte.net Sun Sep 26 05:48:38 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 26 Sep 2010 12:48:38 +0200 Subject: [crossfire] Container dropping behaviour Message-ID: <201009261248.41978.nicolas.weeger@laposte.net> Hello. In relation with bug https://sourceforge.net/tracker/?func=detail&aid=2007078&group_id=13833&atid=113833 I will implement the following changes if no one objects: - when dropping a container, just drop it on the floor with its contents ; locked status applies, ignore if it is opened or not - use the 'empty' command to actually empty the container to the ground This makes containers behave like other items in relation to 'drop'. For avoiding mistake purposes, I'll also prevent dropping a non empty container in a shop ("you don't feel like offering the contents of your bag to the shop owner"). So to sell a full container, first sell the contents, then the container. This would mean adding an 'empty' client-to-server command (like 'drop'), and update clients to send it when for instance ctrl-right-clicking on an item. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100926/08791221/attachment.pgp From nicolas.weeger at laposte.net Sun Sep 26 06:06:28 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 26 Sep 2010 13:06:28 +0200 Subject: [crossfire] Pickup up modes Message-ID: <201009261306.32392.nicolas.weeger@laposte.net> Hello. With relation to bug https://sourceforge.net/tracker/?func=detail&aid=3075860&group_id=13833&atid=113833 Summary: Auto-pickup is failing to pickup Upgrade-type scrolls (Ex: Improve Wisdom Bonus, Enchant Armor, etc), melee weapons (Ex: Sword, Hammer, Morningstar, etc) and also containers/holders (Ex: Key-ring, Quiver, Bag, etc). The weapon is definitely a mistake, that I'll fix. Unless someone objects, I'll do the following: - put upgrade-type scrolls with the "magical devices" category - add a new pickup for containers Does that sound ok? Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100926/406b973b/attachment.pgp From nicolas.weeger at laposte.net Sun Sep 26 06:39:27 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 26 Sep 2010 13:39:27 +0200 Subject: [crossfire] Alchemy success chance Message-ID: <201009261339.30971.nicolas.weeger@laposte.net> Hello. With relation to bug https://sourceforge.net/tracker/?func=detail&aid=2012733&group_id=13833&atid=113833 If no one objects, I'll change the success of the recipe to be equal to 50% when using alchemy at the recipe's difficulty level, and adjusting for more or less levels, in the overall range [1..95] (1 because you can always get lucky, after all, 95 because no one is perfect). Success adjustment will probably be really low chance if 10 levels below recipe level, linear for [-10, +10], and high for >10 levels above. Final item's level will NOT be taken into account - if needed, the formula difficulty should be adjusted instead. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100926/aeaba41c/attachment.pgp From kbulgrien at att.net Sun Sep 26 16:38:39 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sun, 26 Sep 2010 16:38:39 -0500 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <201009261029.42863.nicolas.weeger@laposte.net> References: <201009252035.02891.kbulgrien@att.net> <201009252125.09738.kbulgrien@att.net> <201009261029.42863.nicolas.weeger@laposte.net> Message-ID: <20100926163839.24e7d1ed@srv_10s.kbulgrien.att.net> > > I retract the "I think sound_chance should be dispensed with". I finally > > found the mail list note that mentioned some changes to sound so it could > > support random ambient sounds to improve overall immersion in the game > > environment... Still, the idea that 0 behaves the same as 100 seems > > compatible with this. Any objections? > > I'm not against it (though it breaks the "0 or empty by default" rule that is > always used elsewhere), but sounds should be defined anyway for archetypes and > other things, so it shouldn't be too hard to add the "sound_chance" line at > the same time. > > As for why there is no sound_chance defined for now, the reason is that I > expected sounds to be added incrementally, one sound here, another there. So > no massive changes, but progressive ones. > Alas, never managed to do those changes. The problem is that the sounds already defined were disabled by the change, so it is not a matter of simply not implementing things incrementally. All that used to work no longer does.. It also seems somewhat counter-intuitive to require adding something to an arch for a feature that should be the default behavior. Perhaps an alternative is to add a property that must be present for the new feature to be used. I think that it is not that great to have to go in and find all possible items that should emit sounds and modify them. It is almost inevitable that items will be missed. Basically, I want to get rid of the patch I have to have to play sounds because it means all public servers don't work for sound, and a small simple change seems better than a lot of arch and/or map changes. Kevin From kbulgrien at att.net Sun Sep 26 16:48:26 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sun, 26 Sep 2010 16:48:26 -0500 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[13885] server/trunk/doc/Developers/protocol In-Reply-To: <201009261038.57715.nicolas.weeger@laposte.net> References: <201009261038.57715.nicolas.weeger@laposte.net> Message-ID: <20100926164826.488e5e31@srv_10s.kbulgrien.att.net> > Extract from the Developers/protocol: > > Change background music. Server will send NONE as the string to stop any > music from playing. This song data is set in a map property. (Due to > someone forgetting to update this file when he/she implemented the > command, it is unknown what exactly should be done with the string > parameter, is it a filename? If yes: relative what?) > > That wasn't precisely defined during server implementation, because client-side > wasn't yet implemented. > > There were 2 global ideas: > - it's a song or file name, the client knows where to find it (either bundled or > to be downladed from some site to be defined) > - it's a mood name (eg: "dangerous place", or "port area") that the client > would pick up to arbitrarily decide what music to use from its pool > > Arguments I remember are that it would be better to have music match on the > clients, because if you were playing together it would be weird to have > different musics at the same place. > > So the best idea is probably to make that a filename. > > Of course that means to wonder where the client should get that one, and how > to handle custom background musics. I agree that using the name as the base file name is a good idea with the exception of specifying path and extension. I think it should be a case-insensitive name, not a file name... i.e. with no file extension like .ogg or .wav, and no path. The idea being that the client should be able to determine how to get files, what format of files to play, etc. It is important that the name not include path. This was a weakness of the cfsndserv program. The case issue is to prevent the possibility of having similar names that vary only in case as these cause problems with windows. With it being a name, it could be up to the client to use it as a filename, or simply as a unique name that a player could map to his/her own choice of music. I prefer to require that the name not have spaces for various and sundry reasons. Kevin From kbulgrien at att.net Sun Sep 26 16:49:53 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sun, 26 Sep 2010 16:49:53 -0500 Subject: [crossfire] sound2 protocol and issues: arbitrary volume In-Reply-To: <201009261024.01592.nicolas.weeger@laposte.net> References: <201009252050.54630.kbulgrien@att.net> <201009261024.01592.nicolas.weeger@laposte.net> Message-ID: <20100926164953.4d37add2@srv_10s.kbulgrien.att.net> > Hello. > > > server/trunk/doc/Developers/sound describes the sound2 protocol and a > > volume component to the sound protocol. It indicates that the server > > arbitrarily sets volume "for variability". > > Actually, the "abitrarily" was supposed to mean "0 is basically totally > attenued, 100 is the full sound's volume ; but the maximum sound volume is how > many decibels you want". > > As opposed to "100 means the sound plays at x decibels". > > But that's probably not really nicely written :) So there is no implication that the server randomly sets volume? Ok. Sorry, that's not how I read it. Kevin From mwedel at sonic.net Mon Sep 27 00:22:11 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 26 Sep 2010 22:22:11 -0700 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <20100926163839.24e7d1ed@srv_10s.kbulgrien.att.net> References: <201009252035.02891.kbulgrien@att.net> <201009252125.09738.kbulgrien@att.net> <201009261029.42863.nicolas.weeger@laposte.net> <20100926163839.24e7d1ed@srv_10s.kbulgrien.att.net> Message-ID: <4CA02A03.5080808@sonic.net> On 09/26/10 02:38 PM, Kevin Bulgrien wrote: >>> I retract the "I think sound_chance should be dispensed with". I finally >>> found the mail list note that mentioned some changes to sound so it could >>> support random ambient sounds to improve overall immersion in the game >>> environment... Still, the idea that 0 behaves the same as 100 seems >>> compatible with this. Any objections? >> >> I'm not against it (though it breaks the "0 or empty by default" rule that is >> always used elsewhere), but sounds should be defined anyway for archetypes and >> other things, so it shouldn't be too hard to add the "sound_chance" line at >> the same time. >> >> As for why there is no sound_chance defined for now, the reason is that I >> expected sounds to be added incrementally, one sound here, another there. So >> no massive changes, but progressive ones. >> Alas, never managed to do those changes. > > The problem is that the sounds already defined were disabled by the change, so > it is not a matter of simply not implementing things incrementally. All that > used to work no longer does.. Looking at the code, it also seems suspect for all the hard coded sound values (most all sounds), in that they are looking at an object that does not have any sound information defined - it is looking at skill values, monsters, etc, as for the chance of the sound being generated. In the ideal world, all those hard coded sound values go away - all sound information comes from objects, so only objects that have sounds defined generate noise, and in those cases, if the object does not have the sound information defined, that would be a bug in the object. However, the current code does not really seem to support sounds coming from the objects - there is no 'sound_type' or 'sound_name' field in the object. As such, I think it would be reasonable that for the existing hard coded sound types, it ignores the sound_chance value. As far of better sound support, I think sound information needs to be an object attribute, but that would likely require a different sound playing mechanism (I'd favor a string approach, or if integers are going to get used, they should probably get moved to shared/newclient.h) From mwedel at sonic.net Mon Sep 27 00:26:15 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 26 Sep 2010 22:26:15 -0700 Subject: [crossfire] sound2 protocol and issues: arbitrary volume In-Reply-To: <20100926164953.4d37add2@srv_10s.kbulgrien.att.net> References: <201009252050.54630.kbulgrien@att.net> <201009261024.01592.nicolas.weeger@laposte.net> <20100926164953.4d37add2@srv_10s.kbulgrien.att.net> Message-ID: <4CA02AF7.8070607@sonic.net> On 09/26/10 02:49 PM, Kevin Bulgrien wrote: >> Hello. >> >>> server/trunk/doc/Developers/sound describes the sound2 protocol and a >>> volume component to the sound protocol. It indicates that the server >>> arbitrarily sets volume "for variability". >> >> Actually, the "abitrarily" was supposed to mean "0 is basically totally >> attenued, 100 is the full sound's volume ; but the maximum sound volume is how >> many decibels you want". >> >> As opposed to "100 means the sound plays at x decibels". >> >> But that's probably not really nicely written :) > > So there is no implication that the server randomly sets volume? Ok. Sorry, > that's not how I read it. Looking at the server code, it appears that right now at least, the volume will always be set to 50 (from play_sound_player_only()). I think the protocol doc should get updated to note that the volume is a percentage value, and that a baseline of 50 is average value (so 100 is really loud). Presumably, this would have to be one of those features that would get used if/when true sound support is added to the objects. From mwedel at sonic.net Mon Sep 27 00:39:02 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 26 Sep 2010 22:39:02 -0700 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[13885] server/trunk/doc/Developers/protocol In-Reply-To: <20100926164826.488e5e31@srv_10s.kbulgrien.att.net> References: <201009261038.57715.nicolas.weeger@laposte.net> <20100926164826.488e5e31@srv_10s.kbulgrien.att.net> Message-ID: <4CA02DF6.40305@sonic.net> On 09/26/10 02:48 PM, Kevin Bulgrien wrote: >> Extract from the Developers/protocol: >> >> Change background music. Server will send NONE as the string to stop any >> music from playing. This song data is set in a map property. (Due to >> someone forgetting to update this file when he/she implemented the >> command, it is unknown what exactly should be done with the string >> parameter, is it a filename? If yes: relative what?) >> >> That wasn't precisely defined during server implementation, because client-side >> wasn't yet implemented. >> >> There were 2 global ideas: >> - it's a song or file name, the client knows where to find it (either bundled or >> to be downladed from some site to be defined) >> - it's a mood name (eg: "dangerous place", or "port area") that the client >> would pick up to arbitrarily decide what music to use from its pool >> >> Arguments I remember are that it would be better to have music match on the >> clients, because if you were playing together it would be weird to have >> different musics at the same place. >> >> So the best idea is probably to make that a filename. >> >> Of course that means to wonder where the client should get that one, and how >> to handle custom background musics. > > I agree that using the name as the base file name is a good idea with the > exception of specifying path and extension. > > I think it should be a case-insensitive name, not a file name... i.e. with no > file extension like .ogg or .wav, and no path. The idea being that the client > should be able to determine how to get files, what format of files to play, etc. > It is important that the name not include path. This was a weakness of the > cfsndserv program. The case issue is to prevent the possibility of having > similar names that vary only in case as these cause problems with windows. > > With it being a name, it could be up to the client to use it as a filename, or > simply as a unique name that a player could map to his/her own choice of music. > I prefer to require that the name not have spaces for various and sundry > reasons. I think that was one reason I was more in favor of symbolic names (dangerous_song, port_area) - it seems in many cases the client may do some amount of remapping for what songs it has. OTOH, using file names does not preclude that - it can just make it harder if one adds a new file name - if the file name is really arbitrary, the client would really have no idea - but perhaps more to the point, a person would have to listen to that new file to try to figure out what the song is. So even if it is file names, I would suggest that the names be descriptive of what the sound is/its intended effects, and not something like 'mwedel_5' to denote it is the 5th song I've done. Currently, the server has nothing to do with the sound files either - for the sound effects, it sends a number of the intended effect - for the songs, it just sends the song name, but has no idea if that name is valid. I don't see adding download support for sounds to the server - a lot of bandwidth there. I would see that possibility of the server telling the client where it could download the songs via some well known protocol (ftp, http), and if the server has added custom songs, that location should point to a location that includes those custom songs. As far as different clients playing different songs - even with using filenames, that could still happen (although, probably pretty unlikely for a client maintainer to get rid of a song/replace it, given limited number of songs in the first place). But even with that sound, IIRC, the music command is sent when a player enters a map - so it is almost a sure thing that while 2 different players are hearing the same song, it would be out of phase with respect to each other - thus it could seem to be a different song. From mwedel at sonic.net Mon Sep 27 00:50:39 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 26 Sep 2010 22:50:39 -0700 Subject: [crossfire] Container dropping behaviour In-Reply-To: <201009261248.41978.nicolas.weeger@laposte.net> References: <201009261248.41978.nicolas.weeger@laposte.net> Message-ID: <4CA030AF.1070004@sonic.net> On 09/26/10 03:48 AM, Nicolas Weeger wrote: > Hello. > > > In relation with bug > https://sourceforge.net/tracker/?func=detail&aid=2007078&group_id=13833&atid=113833 > > I will implement the following changes if no one objects: > > > - when dropping a container, just drop it on the floor with its contents ; > locked status applies, ignore if it is opened or not > - use the 'empty' command to actually empty the container to the ground > > > This makes containers behave like other items in relation to 'drop'. > > > For avoiding mistake purposes, I'll also prevent dropping a non empty > container in a shop ("you don't feel like offering the contents of your bag to > the shop owner"). So to sell a full container, first sell the contents, then > the container. > > > This would mean adding an 'empty' client-to-server command (like 'drop'), and > update clients to send it when for instance ctrl-right-clicking on an item. I don't think any protocol changes would really be needed here - whild not most efficient, on the issue of an empty command, the client could just do something like: for object in sack C->S move 0 object_tag 0 done That isn't totally efficient, but for the number of objects typically in a container, still isn't very data. Conversely, the client could check to see if the object is applied and set/clear that status depending on intended behavior - unapply object before dropping it. I guess I'm more in favor of having the client do this type of work instead of the server - arguably, the drop command itself should get removed from the server, and the client do that processing. From nicolas.weeger at laposte.net Wed Sep 29 11:26:05 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 29 Sep 2010 18:26:05 +0200 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <4CA02A03.5080808@sonic.net> References: <201009252035.02891.kbulgrien@att.net> <20100926163839.24e7d1ed@srv_10s.kbulgrien.att.net> <4CA02A03.5080808@sonic.net> Message-ID: <201009291826.10750.nicolas.weeger@laposte.net> > Looking at the code, it also seems suspect for all the hard coded sound > values (most all sounds), in that they are looking at an object that does > not have any sound information defined - it is looking at skill values, > monsters, etc, as for the chance of the sound being generated. > > In the ideal world, all those hard coded sound values go away - all sound > information comes from objects, so only objects that have sounds defined > generate noise, and in those cases, if the object does not have the sound > information defined, that would be a bug in the object. > > However, the current code does not really seem to support sounds coming > from the objects - there is no 'sound_type' or 'sound_name' field in the > object. The idea was to have sound for many actions, so instead of having fields, the server would just send the action - "cast", "move", and such. That name is indeed hard-coded. The sound is then completed by the item's name, from which derives the final sound. Server sends action and item's name. So you'd have: - action "move" on a monster "goblin", client could find the "move_goblin" sound ; if not found, find the global "move" sound - to disable sound for an item, set the "sound_chance" (that one is a field) to 0 I choose to send the action's name, because a string is the easiest to extend - pretend it's a filename, add new files, here you do, you can have any sound. > As far of better sound support, I think sound information needs to be an > object attribute, but that would likely require a different sound playing > mechanism (I'd favor a string approach, or if integers are going to get > used, they should probably get moved to shared/newclient.h) That was the idea I had, but maybe the implementation lacks things :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100929/cbcab1ee/attachment.pgp From nicolas.weeger at laposte.net Wed Sep 29 11:32:36 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 29 Sep 2010 18:32:36 +0200 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <20100926163839.24e7d1ed@srv_10s.kbulgrien.att.net> References: <201009252035.02891.kbulgrien@att.net> <201009261029.42863.nicolas.weeger@laposte.net> <20100926163839.24e7d1ed@srv_10s.kbulgrien.att.net> Message-ID: <201009291832.36789.nicolas.weeger@laposte.net> > The problem is that the sounds already defined were disabled by the change, > so it is not a matter of simply not implementing things incrementally. > All that used to work no longer does.. I don't remember disabling previous sound support, but maybe I indeed did, considering not many people used it... > It also seems somewhat counter-intuitive to require adding something to an > arch for a feature that should be the default behavior. > > Perhaps an alternative is to add a property that must be present for the > new feature to be used. I think that it is not that great to have to go in > and find all possible items that should emit sounds and modify them. It is > almost inevitable that items will be missed. Basically, I want to get rid > of the patch I have to have to play sounds because it means all public > servers don't work for sound, and a small simple change seems better than > a lot of arch and/or map changes. Actually, you don't need to add anything to archetypes. To have a sound, have the client use setup sound2, then when you get messages with "sound2 (params) action name", find the file "action_name.ogg", play it. The idea was to just send free-form strings, to enable clients to "override" sounds. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100929/d6aff545/attachment.pgp From nicolas.weeger at laposte.net Wed Sep 29 11:36:30 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 29 Sep 2010 18:36:30 +0200 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[13885] server/trunk/doc/Developers/protocol In-Reply-To: <4CA02DF6.40305@sonic.net> References: <20100926164826.488e5e31@srv_10s.kbulgrien.att.net> <4CA02DF6.40305@sonic.net> Message-ID: <201009291836.31105.nicolas.weeger@laposte.net> > I think that was one reason I was more in favor of symbolic names > (dangerous_song, port_area) - it seems in many cases the client may do some > amount of remapping for what songs it has. > > OTOH, using file names does not preclude that - it can just make it > harder if one adds a new file name - if the file name is really arbitrary, > the client would really have no idea - but perhaps more to the point, a > person would have to listen to that new file to try to figure out what the > song is. > > So even if it is file names, I would suggest that the names be > descriptive of what the sound is/its intended effects, and not something > like 'mwedel_5' to denote it is the 5th song I've done. Fine by me to have descriptive names. Note that in the current "sound2" implementation, the client will get an action name and an item name. The action name is/was supposed to be a directory, to split/sort files. But client can use it as it want :) > Currently, the server has nothing to do with the sound files either - for > the sound effects, it sends a number of the intended effect - for the > songs, it just sends the song name, but has no idea if that name is valid. In sound2, server sends action and item name, the client having responsibility to figure the right file name. > I don't see adding download support for sounds to the server - a lot of > bandwidth there. I would see that possibility of the server telling the > client where it could download the songs via some well known protocol > (ftp, http), and if the server has added custom songs, that location > should point to a location that includes those custom songs. Well, I'd see a "standard sound pack" distributed with the client. Then people could manually download other packs or replace sounds for custom needs. Of course, ideally ftp/http support would be nice (maybe the server could send that url to the client), so diffent servers could have different sounds. Like face, except for sounds :) > As far as different clients playing different songs - even with using > filenames, that could still happen (although, probably pretty unlikely for > a client maintainer to get rid of a song/replace it, given limited number > of songs in the first place). But even with that sound, IIRC, the music > command is sent when a player enters a map - so it is almost a sure thing > that while 2 different players are hearing the same song, it would be out > of phase with respect to each other - thus it could seem to be a different > song. True. Nicolas --- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100929/008ee77b/attachment.pgp From nicolas.weeger at laposte.net Wed Sep 29 11:38:23 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 29 Sep 2010 18:38:23 +0200 Subject: [crossfire] Container dropping behaviour In-Reply-To: <4CA030AF.1070004@sonic.net> References: <201009261248.41978.nicolas.weeger@laposte.net> <4CA030AF.1070004@sonic.net> Message-ID: <201009291838.23956.nicolas.weeger@laposte.net> > I don't think any protocol changes would really be needed here - whild > not most efficient, on the issue of an empty command, the client could > just do something like: > > for object in sack > C->S move 0 object_tag 0 > done > > That isn't totally efficient, but for the number of objects typically in > a container, still isn't very data. *cough* You never had any container with some hundred of items? :) Also, the client does not necessarily know what is a container, or even if something is a container. > I guess I'm more in favor of having the client do this type of work > instead of the server - arguably, the drop command itself should get > removed from the server, and the client do that processing. Actually 'drop' is nice for players because you can restrict what to drop. 'empty' too. So I'd rather make them coherent - drop drops the container, empty empties it. And same thing through eg mouse, with right-click and ctrl-right-click maybe. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100929/29e1a7ee/attachment.pgp From kbulgrien at att.net Wed Sep 29 23:34:01 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Wed, 29 Sep 2010 23:34:01 -0500 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <201009291832.36789.nicolas.weeger@laposte.net> References: <201009252035.02891.kbulgrien@att.net> <201009261029.42863.nicolas.weeger@laposte.net> <20100926163839.24e7d1ed@srv_10s.kbulgrien.att.net> <201009291832.36789.nicolas.weeger@laposte.net> Message-ID: <20100929233401.3f78d16a@srv_10s.kbulgrien.att.net> > > The problem is that the sounds already defined were disabled by the change, > > so it is not a matter of simply not implementing things incrementally. > > All that used to work no longer does.. > > I don't remember disabling previous sound support, but maybe I indeed did, > considering not many people used it... Because sound_chance is not restrictive on what it operates on, the absence of any sound_chance in any arch completely disables all sounds... Ragnor is the one that clued me on it. The client never, never received any sound messages until the sound_chance check was disabled. The old sounds were number based. sound2 sends strings where a number is expected. That borked up the client sound. It might be that numbers are still passed for old sounds and I didn't notice because I kept seeing the strings after I deleted the sound_chance check. Anyway, on trunk, all sounds are disabled because of sound_chance. > > It also seems somewhat counter-intuitive to require adding something to an > > arch for a feature that should be the default behavior. sound_chance is what requires adding things to arches as I think that is the only way to set sound_chance non-zero, but I don't really know the code. > > Perhaps an alternative is to add a property that must be present for the > > new feature to be used. I think that it is not that great to have to go in > > and find all possible items that should emit sounds and modify them. It is > > almost inevitable that items will be missed. Basically, I want to get rid > > of the patch I have to have to play sounds because it means all public > > servers don't work for sound, and a small simple change seems better than > > a lot of arch and/or map changes. > > Actually, you don't need to add anything to archetypes. > > To have a sound, have the client use setup sound2, then when you get messages > with "sound2 (params) action name", find the file "action_name.ogg", play it. The sound_chance feature prevents it from reaching the client. > The idea was to just send free-form strings, to enable clients to "override" > sounds. Really, on trunk, sounds are entirely disabled at present due to these changes. From kbulgrien at att.net Wed Sep 29 23:40:54 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Wed, 29 Sep 2010 23:40:54 -0500 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[13885] server/trunk/doc/Developers/protocol In-Reply-To: <201009291836.31105.nicolas.weeger@laposte.net> References: <20100926164826.488e5e31@srv_10s.kbulgrien.att.net> <4CA02DF6.40305@sonic.net> <201009291836.31105.nicolas.weeger@laposte.net> Message-ID: <20100929234054.497bbe29@srv_10s.kbulgrien.att.net> > > I think that was one reason I was more in favor of symbolic names > > (dangerous_song, port_area) - it seems in many cases the client may do some > > amount of remapping for what songs it has. > > > > OTOH, using file names does not preclude that - it can just make it > > harder if one adds a new file name - if the file name is really arbitrary, > > the client would really have no idea - but perhaps more to the point, a > > person would have to listen to that new file to try to figure out what the > > song is. > > > > So even if it is file names, I would suggest that the names be > > descriptive of what the sound is/its intended effects, and not something > > like 'mwedel_5' to denote it is the 5th song I've done. > > Fine by me to have descriptive names. > > Note that in the current "sound2" implementation, the client will get an > action name and an item name. The action name is/was supposed to be a > directory, to split/sort files. But client can use it as it want :) I think the directory method could be wasteful of space if you want to reuse the same sound for a lot of different things. > > Currently, the server has nothing to do with the sound files either - for > > the sound effects, it sends a number of the intended effect - for the > > songs, it just sends the song name, but has no idea if that name is valid. > > In sound2, server sends action and item name, the client having responsibility > to figure the right file name. Maybe not for starters, but I think it would be nice for the client to allow a user to remap sounds/songs to their own choices. > > I don't see adding download support for sounds to the server - a lot of > > bandwidth there. I would see that possibility of the server telling the > > client where it could download the songs via some well known protocol > > (ftp, http), and if the server has added custom songs, that location > > should point to a location that includes those custom songs. > > Well, I'd see a "standard sound pack" distributed with the client. > Then people could manually download other packs or replace sounds for custom > needs. > Of course, ideally ftp/http support would be nice (maybe the server could send > that url to the client), so diffent servers could have different sounds. > Like face, except for sounds :) I think a standard protocol like ftp/http is best rather than implementing it in the client/server protocol. I also tend to agree about having a standard sound pack... optional if people want to avoid a big download, but handy if they can get it. > > As far as different clients playing different songs - even with using > > filenames, that could still happen (although, probably pretty unlikely for > > a client maintainer to get rid of a song/replace it, given limited number > > of songs in the first place). But even with that sound, IIRC, the music > > command is sent when a player enters a map - so it is almost a sure thing > > that while 2 different players are hearing the same song, it would be out > > of phase with respect to each other - thus it could seem to be a different > > song. > > True. From mwedel at sonic.net Thu Sep 30 00:53:08 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 29 Sep 2010 22:53:08 -0700 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <201009291826.10750.nicolas.weeger@laposte.net> References: <201009252035.02891.kbulgrien@att.net> <20100926163839.24e7d1ed@srv_10s.kbulgrien.att.net> <4CA02A03.5080808@sonic.net> <201009291826.10750.nicolas.weeger@laposte.net> Message-ID: <4CA425C4.1060806@sonic.net> On 09/29/10 09:26 AM, Nicolas Weeger wrote: >> Looking at the code, it also seems suspect for all the hard coded sound >> values (most all sounds), in that they are looking at an object that does >> not have any sound information defined - it is looking at skill values, >> monsters, etc, as for the chance of the sound being generated. >> >> In the ideal world, all those hard coded sound values go away - all sound >> information comes from objects, so only objects that have sounds defined >> generate noise, and in those cases, if the object does not have the sound >> information defined, that would be a bug in the object. >> >> However, the current code does not really seem to support sounds coming >> from the objects - there is no 'sound_type' or 'sound_name' field in the >> object. > > > The idea was to have sound for many actions, so instead of having fields, the > server would just send the action - "cast", "move", and such. > That name is indeed hard-coded. > > The sound is then completed by the item's name, from which derives the final > sound. > Server sends action and item's name. > > > So you'd have: > - action "move" on a monster "goblin", client could find the "move_goblin" > sound ; if not found, find the global "move" sound > - to disable sound for an item, set the "sound_chance" (that one is a field) to > 0 > > I choose to send the action's name, because a string is the easiest to extend > - pretend it's a filename, add new files, here you do, you can have any sound. Using a string for action name is probably fine, OTOH, there is presumably a finite (and actually quite small) set of actions. Since right now, all the play_sound calls are basically hardcoded on where they get called, putting in an integer type would be fairly easy. That would mean there is the potential for the client getting an event type it doesn't know how to handle - but at the same time, if the client doesn't know how to handle that event type, it would be equally likely it would not have a matching sound file for that even either. But that probably is not that big a deal - it maybe saves a few bytes using a binary code instead of string. I sort of disagree with using the object names as the key however. If I make a new map and put a boss creater on it called 'bob', which lets say is a goblin, the client would get a 'move_bob' sound - it probably won't have a sound for bob, so falls back to the default move sound, which may be less appropriate than the move_goblin sound. But even using archetype names is somewhat problematic - I could certainly see adding a new archetype of which an existing (but non default) sound is ideal, but there is no way to have the client use that, save for an updated sound file for the client. It would seem that this also requires that the client does in fact have a potentially very large sound file which lists many archetype names and actions and what sound file should be used for them. While that exists now, I still think it would be reasonable to have some level of aliases on the server. The problem I otherwise see is that someone adds some new archetypes but doesn't know anything about the client sound files, so it just uses default actions. In a sense, this becomes similar to faces in many regards - we don't have the image an archetype use get derived from the archetype name, rather they have their own face field, so multiple archetypes can use the same face, and there are even ways to change the face. Having sounds based on archetype name would seem to make it really hard to ever change the sound an object generated if one wanted to do it for some reason. For example, we first presume that there are default sounds for all actions (attack, move, apply, etc). Let us suppose I want to put a special goblin thief on a map. I don't want its movements to make any sounds, but I still want its attacks to do so. I don't see any way to do that right now. The fact that sound_chance is global for all sounds the object makes seems less than idea. I could imagine one might want a 'sound_chance 25' for attacks (simply because so many of them happen, especially from monsters, you would just get a huge jumble if all were played), but want a 100 chance for some other action. I know this gets outside of the scope of this conversation, but if we are going to get serious about sound support, we should probably figure out what we really need and figure out best way to do it. From mwedel at sonic.net Thu Sep 30 01:03:20 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 29 Sep 2010 23:03:20 -0700 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[13885] server/trunk/doc/Developers/protocol In-Reply-To: <20100929234054.497bbe29@srv_10s.kbulgrien.att.net> References: <20100926164826.488e5e31@srv_10s.kbulgrien.att.net> <4CA02DF6.40305@sonic.net> <201009291836.31105.nicolas.weeger@laposte.net> <20100929234054.497bbe29@srv_10s.kbulgrien.att.net> Message-ID: <4CA42828.4000001@sonic.net> On 09/29/10 09:40 PM, Kevin Bulgrien wrote: >>> I think that was one reason I was more in favor of symbolic names >>> (dangerous_song, port_area) - it seems in many cases the client may do some >>> amount of remapping for what songs it has. >>> >>> OTOH, using file names does not preclude that - it can just make it >>> harder if one adds a new file name - if the file name is really arbitrary, >>> the client would really have no idea - but perhaps more to the point, a >>> person would have to listen to that new file to try to figure out what the >>> song is. >>> >>> So even if it is file names, I would suggest that the names be >>> descriptive of what the sound is/its intended effects, and not something >>> like 'mwedel_5' to denote it is the 5th song I've done. >> >> Fine by me to have descriptive names. >> >> Note that in the current "sound2" implementation, the client will get an >> action name and an item name. The action name is/was supposed to be a >> directory, to split/sort files. But client can use it as it want :) > > I think the directory method could be wasteful of space if you want to reuse > the same sound for a lot of different things. One could get around some of that with symlinks (for OS's that support it). But as I mentioned in another message, I think the likely scenario is that the client will have a file which maps actions and object names to a corresponding file to play. > >>> Currently, the server has nothing to do with the sound files either - for >>> the sound effects, it sends a number of the intended effect - for the >>> songs, it just sends the song name, but has no idea if that name is valid. >> >> In sound2, server sends action and item name, the client having responsibility >> to figure the right file name. > > Maybe not for starters, but I think it would be nice for the client to allow a > user to remap sounds/songs to their own choices. If the client has that mapping file I mention above, this becomes fairly easy - look for mapping file in .crossfire (or other default location) and use the default one if that is not found. Whether or not there is any nice interface to manager that, or it is up the users to edit that file by hand would really be up to the client maintainer to decide - I personally would think there are better things to work on than an in client sound adjuster, but that is just me. > >>> I don't see adding download support for sounds to the server - a lot of >>> bandwidth there. I would see that possibility of the server telling the >>> client where it could download the songs via some well known protocol >>> (ftp, http), and if the server has added custom songs, that location >>> should point to a location that includes those custom songs. >> >> Well, I'd see a "standard sound pack" distributed with the client. >> Then people could manually download other packs or replace sounds for custom >> needs. >> Of course, ideally ftp/http support would be nice (maybe the server could send >> that url to the client), so diffent servers could have different sounds. >> Like face, except for sounds :) > > I think a standard protocol like ftp/http is best rather than implementing it in > the client/server protocol. I also tend to agree about having a standard sound > pack... optional if people want to avoid a big download, but handy if they can > get it. Yes - all the above is what I was thinking. Standard sound pack that is available as client download (that is really a packaging decision) - these sounds should in fact be in SVN, just like the limited number of sounds right now are. Server can provide URL for client to download additional sounds. Client is not forced to download them, and if the client does download them, it would most likely have to store them in the players home directory and default location. But that is up to many factors - does the client actually do the downloading and unpacking, or just give the URL/bring up a web browser, etc (not that this really means anything, but I've noticed a fair number of commercial games basically fire up the web browser for updates). The one thing I would say is that it is probably desirable to have some directory schema so these different sound packs can coexist. For example: /sounds/default /sounds/metalforge /sounds/invidious etc - I don't want my metalforge sound pack to be messing with either the defaults or invidious. At the same time, these sound packs should be treated as additional sounds, so that they don't have to include everything. So the client, when I connect to metalforge, would look in the sounds/metalforge directory first, and then sounds/default From mwedel at sonic.net Thu Sep 30 01:18:39 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 29 Sep 2010 23:18:39 -0700 Subject: [crossfire] Container dropping behaviour In-Reply-To: <201009291838.23956.nicolas.weeger@laposte.net> References: <201009261248.41978.nicolas.weeger@laposte.net> <4CA030AF.1070004@sonic.net> <201009291838.23956.nicolas.weeger@laposte.net> Message-ID: <4CA42BBF.6050102@sonic.net> On 09/29/10 09:38 AM, Nicolas Weeger wrote: >> I don't think any protocol changes would really be needed here - whild >> not most efficient, on the issue of an empty command, the client could >> just do something like: >> >> for object in sack >> C->S move 0 object_tag 0 >> done >> >> That isn't totally efficient, but for the number of objects typically in >> a container, still isn't very data. > > *cough* > You never had any container with some hundred of items? :) Yes, but each of those commands is 8 or 10 bytes or something? So 200 items is 2K of data? Still not huge. > > Also, the client does not necessarily know what is a container, or even if > something is a container. Yes and no. Once the container has been opened, the client does know, because it gets an inventory of that container, because the location objects for it will have that container. > > > >> I guess I'm more in favor of having the client do this type of work >> instead of the server - arguably, the drop command itself should get >> removed from the server, and the client do that processing. > > Actually 'drop' is nice for players because you can restrict what to drop. > 'empty' too. Nothing really prevents that if that is handled in the client - the client has pretty much all the information that the player should know that the server has - magic, cursed, name, etc. So the client could easily implement a 'drop sword' and do appropriate name matching. In some ways this is better, because in theory, the client should not get information it does not know. I know there have been bugs in the past where pickup/drop was using information that the player (client) does not know - if these are client side, you remove some of that - as long as the enforcement is proper at the protocol level, the client can't do anything it shouldn't do. > So I'd rather make them coherent - drop drops the container, empty empties it. > And same thing through eg mouse, with right-click and ctrl-right-click maybe. I'm more in favor of re-doing all the mouse operations. singe left click = select (by itself, may not mean much) double click == apply (mor standard behavior) right click = bring up context menu of item actions (drop, lock, examine, etc) Now one could allow other mousebindings as shortcuts, but I think right now some of the control/shift/left click vs right click vs whatever is really not a simple solution. I'm also thinking that at least for the gtk client, have a window like the spell or other windows that can be brought up that provides much more detailed (and easier to control actions) for objects could be nice - if I'm in the shop, I don't really care about the map that much and care much more objects objects in my inventory and being able to more easily see all relevant information would be nice. > > > Nicolas > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From kbulgrien at att.net Thu Sep 30 22:05:24 2010 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Thu, 30 Sep 2010 22:05:24 -0500 Subject: [crossfire] SockList buffer size difference in server/client. Bug? Message-ID: <201009302205.24509.kbulgrien@att.net> server/trunk/include/shared/newclient.h: /** * Maximum size of a packet the client expects to get. Using a buffer of this * size allows the client to avoid constant allocation and deallocation of the * same buffer over and over again (at the cost of using extra memory). This * also makes the code simpler. The size is big enough to receive any valid * packet: 2 bytes for length, 65535 for maximum packet size, 1 for appended a * trailing null character. */ #define MAXSOCKBUF (2+65535+1) . . . /** * Contains the base information we use to make up a packet we want to send. */ typedef struct SockList { #ifdef CLIENT_TYPES_H /* Used by the client */ int len; unsigned char *buf; #else /* Used by the server */ size_t len; unsigned char buf[2+65536UL+1]; /* 2=length, 65536=content, 1=trailing NUL */ #endif } SockList; Is use of 65536 in server vs 65535 in the client a bug? In client, the buffer is malloc'd in main(). It almost seems that it could just as well be statically allocated there too... doesn't seem like there is much point in the ifdef here. Kevin From mwedel at sonic.net Thu Sep 30 23:09:32 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 30 Sep 2010 21:09:32 -0700 Subject: [crossfire] SockList buffer size difference in server/client. Bug? In-Reply-To: <201009302205.24509.kbulgrien@att.net> References: <201009302205.24509.kbulgrien@att.net> Message-ID: <4CA55EFC.5040409@sonic.net> On 09/30/10 08:05 PM, Kevin R. Bulgrien wrote: > server/trunk/include/shared/newclient.h: > > /** > * Maximum size of a packet the client expects to get. Using a buffer of this > * size allows the client to avoid constant allocation and deallocation of the > * same buffer over and over again (at the cost of using extra memory). This > * also makes the code simpler. The size is big enough to receive any valid > * packet: 2 bytes for length, 65535 for maximum packet size, 1 for appended a > * trailing null character. > */ > #define MAXSOCKBUF (2+65535+1) > > . . . > > /** > * Contains the base information we use to make up a packet we want to send. > */ > typedef struct SockList { > #ifdef CLIENT_TYPES_H /* Used by the client */ > int len; > unsigned char *buf; > #else /* Used by the server */ > size_t len; > unsigned char buf[2+65536UL+1]; /* 2=length, 65536=content, 1=trailing > NUL */ > #endif > } SockList; > > Is use of 65536 in server vs 65535 in the client a bug? > > In client, the buffer is malloc'd in main(). It almost seems that it could > just as well be statically allocated there too... doesn't seem like there > is much point in the ifdef here. Realistically, I believe 65535 + 2 would always be sufficient. If the length of a packet is greater than that, it can not be held in the 2 byte length parameter. I'm guessing the extra byte just allows one to always put a null one character beyond the end of the buffer - I'm not actually sure if that is really done or not. I'm not sure why the server has it be 65536 - that said, realistically, as long as it is 65538 (65535 + 2 + 1), it probably doesn't make any difference - if the server defined it as 100000, it would still work - just extra space is now being allocated which will never be used. That extra byte in this case almost certainly doesn't make a difference, as I suspect in most cases, the data following it is going to get aligned on a 4 byte boundary, which would bring that to 65540