From nicolas.weeger at laposte.net Tue May 1 05:01:47 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 1 May 2007 12:01:47 +0200 Subject: [crossfire] Blue and green dragon scale / mail Message-ID: <200705011201.51360.nicolas.weeger@laposte.net> Hello. In response to feature request https://sourceforge.net/support/tracker.php?aid=1560406 I added blue and green dragon scales (archetype copied from dragon scale), linked them to electric and chinese dragons. I also added blue and green dragon mail (archetype copied from dragon mail), and matching shop converters (again copied from dragon mail creator). Now we can add some converters to shops around the world :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070501/4ae736bb/attachment.pgp From lalo.martins at gmail.com Tue May 1 16:33:56 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 1 May 2007 21:33:56 +0000 (UTC) Subject: [crossfire] Blue and green dragon scale / mail References: <200705011201.51360.nicolas.weeger@laposte.net> Message-ID: On Tue, 01 May 2007 12:01:47 +0200, Nicolas Weeger wrote: > Hello. > > In response to feature request > https://sourceforge.net/support/tracker.php?aid=1560406 I added blue and > green dragon scales (archetype copied from dragon scale), linked them to > electric and chinese dragons. > I also added blue and green dragon mail (archetype copied from dragon > mail), and matching shop converters (again copied from dragon mail > creator). > > Now we can add some converters to shops around the world :) Awesome, thanks! I'd say, however... now the "normal" scales need to be made red :-P best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Thu May 3 16:05:31 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 3 May 2007 23:05:31 +0200 Subject: [crossfire] Blue and green dragon scale / mail In-Reply-To: References: <200705011201.51360.nicolas.weeger@laposte.net> Message-ID: <200705032305.31880.nicolas.weeger@laposte.net> > Awesome, thanks! > > I'd say, however... now the "normal" scales need to be made red :-P Done :) Old scale is now "orange dragon scale", to match color. (stupid SF won't let me copy files, had to cp / svn add...) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Fri May 4 16:48:46 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 4 May 2007 23:48:46 +0200 Subject: [crossfire] Patches on tracker In-Reply-To: <46342BE5.8010803@gmail.com> References: <200704282144.46221.nicolas.weeger@laposte.net> <46342BE5.8010803@gmail.com> Message-ID: <200705042348.47061.nicolas.weeger@laposte.net> Sorry for the late reply. > My question is, when does the worm swallow you? Random chance, poor > health, or proximity? You get a 25% chance of being swallowed when attacking it with melee weapon. That's another thing I'm not sure of, seems quite a heavy penality as you can't exit the map (maybe with WoR, would need to check) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sat May 5 04:27:44 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 5 May 2007 11:27:44 +0200 Subject: [crossfire] Patches on tracker In-Reply-To: <200704282144.46221.nicolas.weeger@laposte.net> References: <200704282144.46221.nicolas.weeger@laposte.net> Message-ID: <200705051127.44581.nicolas.weeger@laposte.net> Hello, some feedback on the patches on tracker. > https://sourceforge.net/tracker/index.php?func=detail&aid=1673222&group_id= >13833&atid=313833 arrows that stone victim, things like that (not sure how > you unstone) could be fun, imo I'm not totally sure how you can unstone. It seems to me it's a permanent stone, not sure we want that... > https://sourceforge.net/tracker/index.php?func=detail&aid=1680135&group_id= >13833&atid=313833 Buildable buildings > as that one says, full buildings you can buy & enter later > could be fun too (but script would also need some tweaking, hardcoded paths > aren't fun ^_-) Looking at the script, it has one drawback/thing to consider: to work, it requires write access to (a subdirectory of) the maps directory, as it copies template maps to a subdirectory. Would that be a security concern? Not sure of another way to do that, though, as buildings are not player unique maps (other players can use it). I do think I'll commit it anyway, if no one objects. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Sat May 5 09:46:36 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 05 May 2007 08:46:36 -0600 Subject: [crossfire] Patches on tracker In-Reply-To: <200705051127.44581.nicolas.weeger@laposte.net> References: <200704282144.46221.nicolas.weeger@laposte.net> <200705051127.44581.nicolas.weeger@laposte.net> Message-ID: <463C98CC.8090301@telus.net> Nicolas Weeger wrote: > Hello, some feedback on the patches on tracker. > > >> https://sourceforge.net/tracker/index.php?func=detail&aid=1673222&group_id= >> 13833&atid=313833 arrows that stone victim, things like that (not sure how >> you unstone) could be fun, imo >> > > I'm not totally sure how you can unstone. It seems to me it's a permanent > stone, not sure we want that... I was giving Mikee a little guidance on technical details of coding it when he was making this script. His intent was to make an artifact with another script, for unstoning things, however this has not been implemented yet. Even if that is implemented though, I believe that it may still be something we would not want, due to how much it may bug a player to wait until another comes who has that artifact to unstone them. Alex Scji;tz From nicolas.weeger at laposte.net Sat May 5 11:59:02 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 5 May 2007 18:59:02 +0200 Subject: [crossfire] New item: smoking pipe Message-ID: <200705051859.02528.nicolas.weeger@laposte.net> Hello :) Based on feature request http://sourceforge.net/tracker/index.php?func=detail&aid=1549717&group_id=13833&atid=363833 I added a smoking pipe. It requires 'pipeweed' to smoke, and will give a 100% fear resist (yes, full resist) and -2 Con -2 Dex malus. It's Python-script based :) Not sure pipeweed is used, so maybe we could put some somewhere in a map? :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Sat May 5 12:46:45 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 05 May 2007 11:46:45 -0600 Subject: [crossfire] New item: smoking pipe In-Reply-To: <200705051859.02528.nicolas.weeger@laposte.net> References: <200705051859.02528.nicolas.weeger@laposte.net> Message-ID: <463CC305.7030504@telus.net> Nicolas Weeger wrote: > Not sure pipeweed is used, so maybe we could put some somewhere in a map? :) Eracc has some in his Zorn maps, and there's also a Zorn's Pipe in there. Perhaps Zorn's Pipe should get that script attached too? Alex Schultz From mwedel at sonic.net Sat May 5 16:10:35 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 05 May 2007 14:10:35 -0700 Subject: [crossfire] Patches on tracker In-Reply-To: <200705051127.44581.nicolas.weeger@laposte.net> References: <200704282144.46221.nicolas.weeger@laposte.net> <200705051127.44581.nicolas.weeger@laposte.net> Message-ID: <463CF2CB.4000305@sonic.net> Nicolas Weeger wrote: >> https://sourceforge.net/tracker/index.php?func=detail&aid=1680135&group_id= >> 13833&atid=313833 Buildable buildings >> as that one says, full buildings you can buy & enter later >> could be fun too (but script would also need some tweaking, hardcoded paths >> aren't fun ^_-) > > Looking at the script, it has one drawback/thing to consider: to work, it > requires write access to (a subdirectory of) the maps directory, as it copies > template maps to a subdirectory. > Would that be a security concern? Not sure of another way to do that, though, > as buildings are not player unique maps (other players can use it). > I do think I'll commit it anyway, if no one objects. Yes, that is a problem. The fact that the maps are in the 'share' directory means that write access to that area is not a requirement. Lack of write access could be for any number of reasons - permissions issues, or for some sites, something like that could be put on a read-only filesystem. I'd also think there are some problems as related to packaging - various packaging programs removing the entire map area on upgrades, etc. IMO, for that patch to be acceptable, it must write someplace under the var/ install area, which is the area for read/write files. It probably wouldn't be that hard to modify the respective map code such that if it doesn't find the map in share/maps/... to look in var/maps/... From leaf at real-time.com Sat May 5 17:11:11 2007 From: leaf at real-time.com (Rick Tanner) Date: Sat, 05 May 2007 17:11:11 -0500 Subject: [crossfire] OT: SVN Mailing list, subcribers using myrealbox.com Message-ID: <463D00FF.40004@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI There appears to have been an email delivery issue between SourceForge and MyRealBox.com - to the point where the mailing list automatically unsubscribed those users due to excessive or fatal bounces. Any @myrealbox.com user who was subscribed will need to re-subscribe to the mailing list to go back to receiving the commit notices, etc. https://lists.sourceforge.net/lists/listinfo/crossfire-maps -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPQD/hHyvgBp+vH4RAsyYAJ9noCSb9yqjBnTDIix7AatbCYgdbwCdEeIe MMupCnBnfED0NKdkWgOYrmk= =yfxr -----END PGP SIGNATURE----- From lalo.martins at gmail.com Sat May 5 17:26:24 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 5 May 2007 22:26:24 +0000 (UTC) Subject: [crossfire] scripts Message-ID: One thing that has been bothering me recently, is that increasingly, most scripts are tied to arches, yet they reside inside maps, which means an admin needs to keep arches and maps strictly in sync. I'd like to propose the tiniest addition to the complexity of the python plugin, so that we'd have a structure like this on a server: lib/ python/ (arch scripts) maps/ (maps) python/ (map scripts) So we can introduce a notation to mark a script as an arch script, eg: arch event_apply title Python slaying @python/items/smoking_pipe.py (@ rather than /); or we can just have the plugin look in both places. Then arch-related scripts could be kept in the arch module where they belong, or maybe in server, and be installed by server's "make install". Thoughts? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From subs at eracc.com Sat May 5 20:10:59 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Sat, 5 May 2007 20:10:59 -0500 Subject: [crossfire] New item: smoking pipe In-Reply-To: <463CC305.7030504@telus.net> References: <200705051859.02528.nicolas.weeger@laposte.net> <463CC305.7030504@telus.net> Message-ID: <200705052011.00948.subs@eracc.com> On Saturday 05 May 2007 12:46 pm Alex Schultz wrote: > Nicolas Weeger wrote: > > Not sure pipeweed is used, so maybe we could put some somewhere in a map? > > :) > > Eracc has some in his Zorn maps, and there's also a Zorn's Pipe in > there. Perhaps Zorn's Pipe should get that script attached too? I have no objection to that if someone wants to make Zorn's Pipe work with the script. Also there is a tobacco pouch in Zorn's desk that will only hold pipeweed. :-) Gene Alexander (aka eracc) -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From nicolas.weeger at laposte.net Sun May 6 11:13:32 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 6 May 2007 18:13:32 +0200 Subject: [crossfire] scripts In-Reply-To: References: Message-ID: <200705061813.36164.nicolas.weeger@laposte.net> Hello. > One thing that has been bothering me recently, is that increasingly, most > scripts are tied to arches, yet they reside inside maps, which means an > admin needs to keep arches and maps strictly in sync. > > I'd like to propose the tiniest addition to the complexity of the python > plugin, so that we'd have a structure like this on a server: I agree there need to be a way to separate scripts for archetypes, instead of having'em in the maps directory. I would put them in a subdirectory under where archetypes / treasures / formulae are, so we keep some coherence. As for having some special syntax, hum..... we can always do that first, and change later on :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070506/164ccdbc/attachment.pgp From lalo.martins at gmail.com Sun May 6 18:20:33 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 6 May 2007 23:20:33 +0000 (UTC) Subject: [crossfire] scripts References: <200705061813.36164.nicolas.weeger@laposte.net> Message-ID: On Sun, 06 May 2007 18:13:32 +0200, Nicolas Weeger wrote: > I agree there need to be a way to separate scripts for archetypes, > instead of having'em in the maps directory. > I would put them in a subdirectory under where archetypes / treasures / > formulae are, so we keep some coherence. Right... that's exactly what I suggested, isn't it? ;-) > As for having some special syntax, hum..... we can always do that first, > and change later on :) Which one? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Mon May 7 15:52:51 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 7 May 2007 22:52:51 +0200 Subject: [crossfire] Patches on tracker In-Reply-To: <463CF2CB.4000305@sonic.net> References: <200704282144.46221.nicolas.weeger@laposte.net> <200705051127.44581.nicolas.weeger@laposte.net> <463CF2CB.4000305@sonic.net> Message-ID: <200705072252.57499.nicolas.weeger@laposte.net> Le samedi 05 mai 2007 23:10, Mark Wedel a ?crit?: > Yes, that is a problem. > > The fact that the maps are in the 'share' directory means that write > access to that area is not a requirement. Lack of write access could be > for any number of reasons - permissions issues, or for some sites, > something like that could be put on a read-only filesystem. As a side-note, Python can write in the maps's python/ directories, since Python compiles the scripts to .pyc files. > IMO, for that patch to be acceptable, it must write someplace under the > var/ install area, which is the area for read/write files. It probably > wouldn't be that hard to modify the respective map code such that if it > doesn't find the map in share/maps/... to look in var/maps/... Actually, the script uses its own apply script, so wouldn't be too hard to change the map path to point to some writable directory (in var?) - set the 'unique' map flag when loading, and you're set, server won't change the path :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070507/89df8903/attachment.pgp From lalo.martins at gmail.com Mon May 7 17:35:10 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 7 May 2007 22:35:10 +0000 (UTC) Subject: [crossfire] Patches on tracker References: <200704282144.46221.nicolas.weeger@laposte.net> <200705051127.44581.nicolas.weeger@laposte.net> <463CF2CB.4000305@sonic.net> <200705072252.57499.nicolas.weeger@laposte.net> Message-ID: On Mon, 07 May 2007 22:52:51 +0200, Nicolas Weeger wrote: > Le samedi 05 mai 2007 23:10, Mark Wedel a ?crit?: >> >> The fact that the maps are in the 'share' directory means that write >> access to that area is not a requirement. Lack of write access could >> be for any number of reasons - permissions issues, or for some sites, >> something like that could be put on a read-only filesystem. > > As a side-note, Python can write in the maps's python/ directories, > since Python compiles the scripts to .pyc files. Righto, but if it's unable to due to permissions, then nothing will break. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Mon May 7 23:37:55 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 07 May 2007 21:37:55 -0700 Subject: [crossfire] Patches on tracker In-Reply-To: References: <200704282144.46221.nicolas.weeger@laposte.net> <200705051127.44581.nicolas.weeger@laposte.net> <463CF2CB.4000305@sonic.net> <200705072252.57499.nicolas.weeger@laposte.net> Message-ID: <463FFEA3.5020003@sonic.net> Lalo Martins wrote: > On Mon, 07 May 2007 22:52:51 +0200, Nicolas Weeger wrote: >> Le samedi 05 mai 2007 23:10, Mark Wedel a ?crit : >>> The fact that the maps are in the 'share' directory means that write >>> access to that area is not a requirement. Lack of write access could >>> be for any number of reasons - permissions issues, or for some sites, >>> something like that could be put on a read-only filesystem. >> As a side-note, Python can write in the maps's python/ directories, >> since Python compiles the scripts to .pyc files. > > Righto, but if it's unable to due to permissions, then nothing will break. And as I think about this more, for almost anyone that is using precompiled binaries (rpms, debs, whatever), there is a good chance that the process/scripts will not be able to write into the maps directory. This because in most all cases, the root user would install the appropriate package, and so would have root ownership, and no write permissions. We strongly suggest that you do not run the server as root, but some other uid, and as such, it would not be able to write to this area. From nicolas.weeger at laposte.net Tue May 8 09:44:51 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 8 May 2007 16:44:51 +0200 Subject: [crossfire] New command: use Message-ID: <200705081644.57003.nicolas.weeger@laposte.net> Hello. I added a new command, 'use', which syntax is 'use with '. The aim is to replace the 'item transformation' code that uses the 'item_transformer' type but isn't that flexible. It will also enable to do complex things, ie use (regular) sword with paper => cut paper Documentation can be found in doc/Developers/item_transformation. I plan on removing the now obsolete item type in the future. Note that this is only available in trunk. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070508/0c53bc72/attachment.pgp From mwedel at sonic.net Thu May 10 01:34:07 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 09 May 2007 23:34:07 -0700 Subject: [crossfire] scripts In-Reply-To: References: Message-ID: <4642BCDF.5030905@sonic.net> Lalo Martins wrote: > One thing that has been bothering me recently, is that increasingly, most > scripts are tied to arches, yet they reside inside maps, which means an > admin needs to keep arches and maps strictly in sync. Note that this is often the case, and unrelated to scripts. Often times when a new arch is added, it is used in maps pretty quickly (after all, what is the point of new arches if you don't use them), so if you update the maps without the arches, problems arise. > > I'd like to propose the tiniest addition to the complexity of the python > plugin, so that we'd have a structure like this on a server: > > lib/ > python/ > (arch scripts) > maps/ > (maps) > python/ > (map scripts) > > So we can introduce a notation to mark a script as an arch script, eg: > arch event_apply > title Python > slaying @python/items/smoking_pipe.py > (@ rather than /); or we can just have the plugin look in both places. > > Then arch-related scripts could be kept in the arch module where they > belong, or maybe in server, and be installed by server's "make install". Is it possible to run scripts from text that is in memory? If so, then an approach similar to the treasures - collect them into a file, read them into memory, and when needed, run the script from that information in memory. I'd think in that case, the slaying is simpler - just something like 'slaying smoking_pipe.py' - since the script is in memory, there is effectively no need for a pathname. One advantage of this collection approach is that the scripts themselves sit with the arches (same idea behind the treasurelists) - the script would be in the same directory as the object itself. If this idea isn't feasible, the next approach would be to have a 'scripts' directory, and the collect process just takes the scripts and copies them over there, and then install copies all the scripts elsewhere. From yann.chachkoff at myrealbox.com Thu May 10 02:18:09 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Thu, 10 May 2007 09:18:09 +0200 Subject: [crossfire] scripts In-Reply-To: <4642BCDF.5030905@sonic.net> References: <4642BCDF.5030905@sonic.net> Message-ID: <200705100918.10467.yann.chachkoff@myrealbox.com> Le Thursday 10 May 2007 08:34:07 Mark Wedel, vous avez ?crit?: > Lalo Martins wrote: > > One thing that has been bothering me recently, is that increasingly, most > > scripts are tied to arches, yet they reside inside maps, which means an > > admin needs to keep arches and maps strictly in sync. > I don't think "keeping both in sync" is a problem - if I create a new map and use a new archetype in it, I'll have to sync both regardless is scripts are involved or not. Now, it could be more convenient for the archetype-maker to have the scripts in the arch package itself; the collect script could copy those into the appropriate places in the maps/python subdirectory (or elsewhere) when needed. > > I'd like to propose the tiniest addition to the complexity of the python > > plugin, so that we'd have a structure like this on a server: > > > > lib/ > > python/ > > (arch scripts) > > maps/ > > (maps) > > python/ > > (map scripts) > > > > So we can introduce a notation to mark a script as an arch script, eg: mmm... I don't understand what the advantage of this would be - I think it makes things rather complex for map-makers, with no obvious benefit. > Is it possible to run scripts from text that is in memory? If so, then > an approach similar to the treasures - collect them into a file, read them > into memory, and when needed, run the script from that information in > memory. > Yes, it is possible - the problem in that case is that as the number of scripts increases, this may become a noticeable waste of memory. Also, not that the current system allows one to test scripts "on the fly", without having to restart the server each time - memory loading would not provide the same possibility. > If this idea isn't feasible, the next approach would be to have a > 'scripts' directory, and the collect process just takes the scripts and > copies them over there, and then install copies all the scripts elsewhere. > I tend to think this is a better approach. From lalo.martins at gmail.com Thu May 10 06:41:08 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 10 May 2007 11:41:08 +0000 (UTC) Subject: [crossfire] scripts References: <4642BCDF.5030905@sonic.net> <200705100918.10467.yann.chachkoff@myrealbox.com> Message-ID: On Thu, 10 May 2007 09:18:09 +0200, Yann Chachkoff wrote: >> > lib/ >> > python/ >> > (arch scripts) >> > maps/ >> > (maps) >> > python/ >> > (map scripts) >> > >> > So we can introduce a notation to mark a script as an arch script, >> > eg: > mmm... I don't understand what the advantage of this would be - I think > it makes things rather complex for map-makers, with no obvious benefit. You missed the point here. It couldn't possibly make things complex for map-makers, since this would never be visible to them :-) map scripts stay exactly as they are. What I'm talking about is introducing a distinction between them and arch scripts. So it would "make things complex" for arch writers... which, IMO, it wouldn't, it would make things a bit simpler for them. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Thu May 10 06:45:23 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 10 May 2007 11:45:23 +0000 (UTC) Subject: [crossfire] scripts References: <4642BCDF.5030905@sonic.net> Message-ID: On Wed, 09 May 2007 23:34:07 -0700, Mark Wedel wrote: > Lalo Martins wrote: >> One thing that has been bothering me recently, is that increasingly, >> most scripts are tied to arches, yet they reside inside maps, which >> means an admin needs to keep arches and maps strictly in sync. > > Note that this is often the case, and unrelated to scripts. No, but you need to keep them somewhat in sync. With the current state of affairs, you need to keep them *strictly* in sync: update one, update the other. If arch scripts were separate, you could always update arches and not maps, and you could sometimes, not often, update maps and not arches. > Is it possible to run scripts from text that is in memory? If so, > then an > approach similar to the treasures - collect them into a file, read them > into memory, and when needed, run the script from that information in > memory. > > I'd think in that case, the slaying is simpler - just something like > 'slaying > smoking_pipe.py' - since the script is in memory, there is effectively > no need for a pathname. > > One advantage of this collection approach is that the scripts > themselves sit > with the arches (same idea behind the treasurelists) - the script would > be in the same directory as the object itself. I like this idea! It is possible, yes, but not very practical to do. Easier however (and arguably cooler), we can run scripts from a zip file! (Disclaimer: I haven't ever looked at how the plugin loads scripts. I'm making assumptions based on what I know of Python's internals. Ergo, I may be wrong.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From alex_sch at telus.net Thu May 10 08:24:48 2007 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 10 May 2007 07:24:48 -0600 Subject: [crossfire] scripts In-Reply-To: <4642BCDF.5030905@sonic.net> References: <4642BCDF.5030905@sonic.net> Message-ID: <46431D20.5080109@telus.net> Mark Wedel wrote: > Is it possible to run scripts from text that is in memory? If so, then an > approach similar to the treasures - collect them into a file, read them into > memory, and when needed, run the script from that information in memory. > > I'd think in that case, the slaying is simpler - just something like 'slaying > smoking_pipe.py' - since the script is in memory, there is effectively no need > for a pathname. > > One advantage of this collection approach is that the scripts themselves sit > with the arches (same idea behind the treasurelists) - the script would be in > the same directory as the object itself. Such running scripts from text in memory is very possible indeed :) In fact, we could (and should IMHO) go one step further: Run it from the bytecodes in memory. The python code already has faculties for caching the bytecode of python scripts in memory (caches up to 16 scripts as bytecode in memory) and this increases speed of running the same script over and over VERY dramatically (code for this derived from daimonin's changes in the python plugin before it moved to lua). So, why store text in memory as such to run, when one could store the bytecode which would be much much faster and use less memory :) Alex Schultz From yann.chachkoff at myrealbox.com Thu May 10 08:28:42 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Thu, 10 May 2007 15:28:42 +0200 Subject: [crossfire] scripts In-Reply-To: References: <200705100918.10467.yann.chachkoff@myrealbox.com> Message-ID: <200705101528.42744.yann.chachkoff@myrealbox.com> Le Thursday 10 May 2007 13:41:08 Lalo Martins, vous avez ?crit?: > > mmm... I don't understand what the advantage of this would be - I think > > it makes things rather complex for map-makers, with no obvious benefit. > > You missed the point here. It couldn't possibly make things complex for > map-makers, since this would never be visible to them :-) map scripts > stay exactly as they are. What I'm talking about is introducing a > distinction between them and arch scripts. So it would "make things > complex" for arch writers... which, IMO, it wouldn't, it would make > things a bit simpler for them. > I consider arch-makers to be the same kind of people as map-makers :). Granted, I should have used "arch-maker" there, which is what I really meant. What I don't like is that "@" syntax - it is cryptic and not required, provided that archetype scripts get installed at the proper place upon archetype collection. I don't think introducing another specific notation would make things "a bit simpler". As for the idea of shipping scripts in the arch package, instead of having to put them into the map package, my position is "why not ?". I doubt that "compiling" scripts in a single archive would be a great idea, though. From mwedel at sonic.net Thu May 10 23:29:44 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 10 May 2007 21:29:44 -0700 Subject: [crossfire] scripts In-Reply-To: <46431D20.5080109@telus.net> References: <4642BCDF.5030905@sonic.net> <46431D20.5080109@telus.net> Message-ID: <4643F138.4020000@sonic.net> Alex Schultz wrote: > Such running scripts from text in memory is very possible indeed :) > In fact, we could (and should IMHO) go one step further: Run it from the > bytecodes in memory. The python code already has faculties for caching > the bytecode of python scripts in memory (caches up to 16 scripts as > bytecode in memory) and this increases speed of running the same script > over and over VERY dramatically (code for this derived from daimonin's > changes in the python plugin before it moved to lua). So, why store text > in memory as such to run, when one could store the bytecode which would > be much much faster and use less memory :) Right - I was thinking that it may be possible to store some machine format. As someone said, the one disadvantage of these collected scripts is that you can't change them on the fly. However, I'd consider that a pretty minor issue - if you're developing a script, you could certainly store it is a plain file so you can run it over and over again until it works, and then move it to the arch where it gets collected. As far as the idea of collect copying the scripts over to the maps script idea, I think this is a bad idea for many reasons: - In a sense, it pollutes the maps directory as far as SVN goes - you now have a bunch of files under maps which are not part of SVN. As things go right now, you can use a svn checkout for your maps area, and it will remain pure. - The abilities/ownership of the collect process gets many. It probably isn't that uncommon that one uid is used to build the source and run collect, and another is actually used for the make install. In this model, the collection process would be unable to copy the scripts directly over into the maps area - instead, it would have to copy them to a temporary area, (lib/scripts/...), and then the install copies those over. But if we're going to do that, it probably makes sense to just copy those over into some non map area of the install directory (share/scripts/...) or something - This may make packaging (rpms) more of a problem - this is especially true if a map script becomes an arch script or vice versa - now you have conflicting files in the RPMs. If they are in completely separate directories, no issue. As far as pathnames, to me, the simplest thing is to have a basic pathname and there just be a search order - server looks first in maps/scripts/..., then in share/scripts/..., etc. That should be very easy to do - the only issue is if there are two scripts of the same name. > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From lalo.martins at gmail.com Mon May 14 23:55:06 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 15 May 2007 04:55:06 +0000 (UTC) Subject: [crossfire] Ryo's cleanup Message-ID: Ryo, I believe I speak for most or all the developers when I express my (our) gratitude, for your tireless efforts cleaning up the Augean Stables... er, I mean, the deprecated stuff in the maps and codebase. Thanks! best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From subs at eracc.com Tue May 15 14:18:15 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Tue, 15 May 2007 14:18:15 -0500 Subject: [crossfire] Ryo's cleanup In-Reply-To: References: Message-ID: <200705151418.16939.subs@eracc.com> On Monday 14 May 2007 11:55 pm Lalo Martins wrote: > Ryo, > > I believe I speak for most or all the developers when I express my (our) > gratitude, for your tireless efforts cleaning up the Augean Stables... > er, I mean, the deprecated stuff in the maps and codebase. ?Thanks! > > best, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Lalo Martins Hear! Hear! It appears that Nicolas is The Man lately when it comes to crossfire code cleanup. Thanks Nicolas. :-) Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From nicolas.weeger at laposte.net Wed May 16 11:56:00 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 16 May 2007 18:56:00 +0200 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [6297] server/trunk In-Reply-To: References: Message-ID: <200705161856.00224.nicolas.weeger@laposte.net> > Revision: 6297 > http://svn.sourceforge.net/crossfire/?rev=6297&view=rev > Author: mwedel > Date: 2007-05-14 23:43:06 -0700 (Mon, 14 May 2007) > > Log Message: > ----------- > Add spell merging code - this makes the server run much faster when many > spell objects are in use. For more details, see doc/Developers/spells Yeah! Nice thing to help combat comet/asteroid/nova lag ^_^ Thanks Mark. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Wed May 16 12:15:42 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 16 May 2007 19:15:42 +0200 Subject: [crossfire] Ryo's cleanup In-Reply-To: References: Message-ID: <200705161915.42848.nicolas.weeger@laposte.net> > I believe I speak for most or all the developers when I express my (our) > gratitude, for your tireless efforts cleaning up the Augean Stables... > er, I mean, the deprecated stuff in the maps and codebase. Thanks! Well, can't say I don't like some praise for that :) But if you really want to thank me, contribute too, even if it's a small thing, a small map, a small fix, a small graphism, a small wiki edit, anything ;) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From lalo.martins at gmail.com Thu May 17 08:13:45 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 17 May 2007 13:13:45 +0000 (UTC) Subject: [crossfire] Ryo's cleanup References: <200705161915.42848.nicolas.weeger@laposte.net> Message-ID: No, you don't get us. The reason we're thanking you is precisely that nobody wants to do that work :-D we all know it needs doing but... it's not exciting, it's not shiny, it's not cool... so it gathers dust :-P Hence the comparison to the Augean Stables. It's quite heroic of you to be doing it. In my case, I have things in my queue that I think have a higher priority, and if I ever get some crossfire time, I spend it on that. I think it's safe to assume that applies to many other contributors. Yet... of course, this is not to discourage anyone from helping Nicolas. If you can, then by all means do it. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Thu May 17 08:33:20 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 17 May 2007 15:33:20 +0200 Subject: [crossfire] Ryo's cleanup In-Reply-To: References: <200705161915.42848.nicolas.weeger@laposte.net> Message-ID: <200705171533.20303.nicolas.weeger@laposte.net> > No, you don't get us. The reason we're thanking you is precisely that > nobody wants to do that work :-D we all know it needs doing but... it's > not exciting, it's not shiny, it's not cool... so it gathers dust :-P > Hence the comparison to the Augean Stables. It's quite heroic of you to > be doing it. > > In my case, I have things in my queue that I think have a higher > priority, and if I ever get some crossfire time, I spend it on that. I > think it's safe to assume that applies to many other contributors. > > Yet... of course, this is not to discourage anyone from helping Nicolas. > If you can, then by all means do it. Tss, you didn't read correctly what I said :) I didn't ask to help cleaning - I asked to contribute, whatever it is, even it isn't cleaning ;) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sun May 20 01:03:53 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 19 May 2007 23:03:53 -0700 Subject: [crossfire] Ryo's cleanup In-Reply-To: <200705171533.20303.nicolas.weeger@laposte.net> References: <200705161915.42848.nicolas.weeger@laposte.net> <200705171533.20303.nicolas.weeger@laposte.net> Message-ID: <464FE4C9.6090307@sonic.net> Much thanks to Ryo for the work he's done. Much thanks to anyone who helps out on crossfire. Relative to others helping out, there is probably a long list. I realize that a fair number of people on this list are not programmers or even map makers, but even players with a fair amount of experience can help out. It might be nice to have a list of things like this. One thing that pops off the top of my head is both the lore fields in archetypes and the msg/endmsg field in spells. For spells, the idea of msg/endmsg is to add documentation on what the spell does, and if non intuitive, how to use it. In both of the gtk clients, if you bring up the spell window, it provides these descriptions - a lot of spells don't have any information. Filling in that information doesn't really require much more than an experienced player to know what they do. The lore/endlore field was something added but never used, at least not yet. The idea behind that was to fill out information for books and other readables - right now, for things like spells and monsters, the program will make books, but obviously in a form that is machine generated. The idea of the lore was to provide information that was human generated, and could also include other information about the monster - things like how it attacks, hints to attack it back, etc. IIRC, there was some mechanism in place to have different levels of lore (so how to kill Jessy wouldn't show up in a level 1 book). But once again, this type of lore knowledge is something that can be filled in players who have fought those monsters, etc. From nicolas.weeger at laposte.net Sun May 20 10:24:29 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 20 May 2007 17:24:29 +0200 Subject: [crossfire] Ryo's cleanup In-Reply-To: <464FE4C9.6090307@sonic.net> References: <200705171533.20303.nicolas.weeger@laposte.net> <464FE4C9.6090307@sonic.net> Message-ID: <200705201724.29806.nicolas.weeger@laposte.net> Concerning the cleaning, lemme be clear: I'll clean some stuff, but IMO we shouldn't go refactoring for the sake of it. Let's just fix bugs, add new (fun) features, make the game fun - not concentrate on the code itself :) > Relative to others helping out, there is probably a long list. I realize > that a fair number of people on this list are not programmers or even map > makers, but even players with a fair amount of experience can help out. > > It might be nice to have a list of things like this. One thing that pops > off the top of my head is both the lore fields in archetypes and the > msg/endmsg field in spells. There is a kind of todo list, on the wiki - even a few. http://wiki.metalforge.net/doku.php/dev_todo http://wiki.metalforge.net/doku.php/dev_todo_new http://wiki.metalforge.net/doku.php/dev_todo:cf2.0?s=todo including individual todo lists (arguably, some should be merged...) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun May 20 13:10:44 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 20 May 2007 20:10:44 +0200 Subject: [crossfire] Material In-Reply-To: <200704031959.01573.nicolas.weeger@laposte.net> References: <200704031959.01573.nicolas.weeger@laposte.net> Message-ID: <200705202010.45041.nicolas.weeger@laposte.net> > I'm wondering if there is documentation on the material system. Couldn't > really find much :) So no one has any idea? The code looks to me like there is a cross between 2 things, "material" and "materialname". Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun May 20 15:56:03 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 20 May 2007 22:56:03 +0200 Subject: [crossfire] "identification" skills patch Message-ID: <200705202256.04076.nicolas.weeger@laposte.net> Hello. http://sourceforge.net/support/tracker.php?aid=1638868 is a patch that makes the various identifying skills (smithing, alchemy, ...) work on a zone instead of a single spot under the player. I think that's a fun one, what do you think? (apparently it doesn't take into account los, so that should probably be fixed before committing) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Sun May 20 20:59:43 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 20 May 2007 19:59:43 -0600 Subject: [crossfire] "identification" skills patch In-Reply-To: <200705202256.04076.nicolas.weeger@laposte.net> References: <200705202256.04076.nicolas.weeger@laposte.net> Message-ID: <4650FD0F.9050006@telus.net> Nicolas Weeger wrote: > http://sourceforge.net/support/tracker.php?aid=1638868 is a patch that makes > the various identifying skills (smithing, alchemy, ...) work on a zone > instead of a single spot under the player. > I think that's a fun one, what do you think? > (apparently it doesn't take into account los, so that should probably be fixed > before committing) Sounds neat to me. I'd also like to note, in addition to LOS, take blind status into account such that you can't ID if you can't see, to be consistent with the LOS checks. Alex Schultz From mwedel at sonic.net Sun May 20 23:20:34 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 May 2007 21:20:34 -0700 Subject: [crossfire] "identification" skills patch In-Reply-To: <4650FD0F.9050006@telus.net> References: <200705202256.04076.nicolas.weeger@laposte.net> <4650FD0F.9050006@telus.net> Message-ID: <46511E12.6040609@sonic.net> Alex Schultz wrote: > Nicolas Weeger wrote: >> http://sourceforge.net/support/tracker.php?aid=1638868 is a patch that makes >> the various identifying skills (smithing, alchemy, ...) work on a zone >> instead of a single spot under the player. >> I think that's a fun one, what do you think? >> (apparently it doesn't take into account los, so that should probably be fixed >> before committing) > Sounds neat to me. I'd also like to note, in addition to LOS, take blind > status into account such that you can't ID if you can't see, to be > consistent with the LOS checks. Hmm - should you be able to identify stuff you can see, but can't reach? An example being a treasure room behind a grate, but the grate is closed - you can see the treasure room, but are unable to actually get it. But having ident related skills cover a larger area does make some sense. From lalo.martins at gmail.com Mon May 21 03:06:06 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 21 May 2007 08:06:06 +0000 (UTC) Subject: [crossfire] "identification" skills patch References: <200705202256.04076.nicolas.weeger@laposte.net> <4650FD0F.9050006@telus.net> <46511E12.6040609@sonic.net> Message-ID: On Sun, 20 May 2007 21:20:34 -0700, Mark Wedel wrote: > Alex Schultz wrote: > Hmm - should you be able to identify stuff you can see, but can't > reach? An > example being a treasure room behind a grate, but the grate is closed - > you can see the treasure room, but are unable to actually get it. > > But having ident related skills cover a larger area does make some > sense. I'm not so sure. Sometimes you have to touch, smell, or even taste something to identify it. Maybe make the range depend on level? Something like lvl/20, so up to level 20 you only identify what you can touch, smell and taste, and after that you're experienced enough to be sure from a distance. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Mon May 21 03:22:25 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 21 May 2007 08:22:25 +0000 (UTC) Subject: [crossfire] "identification" skills patch References: <200705202256.04076.nicolas.weeger@laposte.net> Message-ID: Some further suggestions re distance identification :-) Now there's a much higher chance we'll identify a number of identical items. So maybe they should "stack"? Say something like: You see 7 bronze swords. (...) Second: now that you can identify things that you can't necessarily carry, maybe there should be some new skills for some of those? Specially, a skill to id monsters would be sweet. You see 3 beholders. They seem healthy and aggressive. Beholders usually attack with spells, and often drop beholder eyes. You see 4 wights. They seem healthy and aggressive. Wights are usually attack with cold, and often drop wight corpses. You see 2 monsters you can't identify. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From antonoussik at gmail.com Mon May 21 05:39:32 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Mon, 21 May 2007 11:39:32 +0100 Subject: [crossfire] "identification" skills patch In-Reply-To: References: <200705202256.04076.nicolas.weeger@laposte.net> Message-ID: Would making a unified identify command that calls whatever skills you have to try to identify things around you make sense? That way you can just bind 'identify once and not bother with any other binds or commands. From mwedel at sonic.net Mon May 21 23:01:58 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 May 2007 21:01:58 -0700 Subject: [crossfire] "identification" skills patch In-Reply-To: References: <200705202256.04076.nicolas.weeger@laposte.net> Message-ID: <46526B36.7050003@sonic.net> Anton Oussik wrote: > Would making a unified identify command that calls whatever skills you > have to try to identify things around you make sense? That way you can > just bind 'identify once and not bother with any other binds or > commands. I sort of do this right now - have one bind command do all the identification skills - if I don't have the skill, it just prints out error messages for what I'm missing. Having this be an official command wouldn't be hard, but one would perhaps have to consider the time aspects - arguably, if you are using 10 identification skills, that one command should take 10 times longer than if you have just one skill. And one could argue that identification should in most cases take longer than it does right now. At some level, this level of smarts could be in the client - the client, to some extent, knows what skills the player has (because they have exp totals for it). The only problem is that the client doesn't really know what the skills are used for. From mwedel at sonic.net Mon May 21 23:09:31 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 May 2007 21:09:31 -0700 Subject: [crossfire] "identification" skills patch In-Reply-To: References: <200705202256.04076.nicolas.weeger@laposte.net> Message-ID: <46526CFB.6010700@sonic.net> Lalo Martins wrote: > Some further suggestions re distance identification :-) > > Now there's a much higher chance we'll identify a number of identical > items. So maybe they should "stack"? Say something like: > > You see 7 bronze swords. (...) If the objects are already on the same space, this of course happens. If the objects are on different spaces, doing this gets a bit messier - see the shop code for an example of that - instead of printing results are you traverse the stack of items on the space, you need to store/record all that information and then print it at the end. Not hard to do, bit a bit more work than expanding the search area. > > Second: now that you can identify things that you can't necessarily > carry, maybe there should be some new skills for some of those? > Specially, a skill to id monsters would be sweet. > > You see 3 beholders. > They seem healthy and aggressive. > Beholders usually attack with spells, and often drop beholder eyes. > > You see 4 wights. > They seem healthy and aggressive. > Wights are usually attack with cold, and often drop wight corpses. > > You see 2 monsters you can't identify. That is reasonable, but to really do that, it would seem that the lore information should be filled in, rather than trying to figure it out from the monster attributes. To figure out what they usually drops requires parsing the treasure structure - not impossible, but defining often/rarely/etc for drop frequency gets odd. I'm also not sure I'd like the output for dragons and other monsters, with a list of 20 things they frequently drop. The idea of a skill itself, that identifies the monsters, is a nice idea. This could perhaps be extended to some other things also - one could imagine that one shouldn't really be able to find rare herbs just sitting on the space, but using the skill (woodsman, whatever) might reveal these items that could be picked up (one way to do this would be to have treasurelists for things like forest, plains, etc, which infrequently generates these items - however, like other things, these generated items would be in the inventory of the space, so not seen, but using the skill correctly would look at inventory of these ground spaces and move the item from the inventory onto the space itself) From mwedel at sonic.net Tue May 22 01:36:14 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 May 2007 23:36:14 -0700 Subject: [crossfire] Using openal for client audio? Message-ID: <46528F5E.6040903@sonic.net> I ran across openal (http://www.openal.org/) a cross platform 3d audio API. I haven't dug really deeply into it, but it looks interesting to me in many regards: - Cross platform (windows, mac, linux, solaris, and others) - this removes the various specialized support currently in the sound playing logic, and adds more platforms that the client currently has - Takes care of sound mixing, adjustments based on location, can even do things like doppler shift. Some of this logic is currently in the sound client, but other aspects are not. - Related to above, can more fully utilize sound hardware. For example, right now the client only does mixing/adjustment of volume presuming a 2 speaker set up. If someone had a 5.1 setup, the client wouldn't make any extra use, where as openal would - Is used by a fair number of mainstream games, so hardly seems like it should be stable and not disappear The only real disadvantages with this: - Would require some work to write up using this library (OTOH, the current sound implementation needs some work to deal with background music, so may not be a big net loss) - Adds a new dependancy for the client. But the easy thing to do in this case is have a check for the library, and if it doesn't exist, compile the sound support with just stub functions that don't do anything (looking at the library, it would seem that there isn't a need to set up a separate sound playing process - this can do things properly on its own, which also makes things easier in terms of starting/stopping sounds) Thoughts/comments? From mwedel at sonic.net Tue May 22 02:01:25 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 May 2007 00:01:25 -0700 Subject: [crossfire] Ryo's cleanup In-Reply-To: <200705201724.29806.nicolas.weeger@laposte.net> References: <200705171533.20303.nicolas.weeger@laposte.net> <464FE4C9.6090307@sonic.net> <200705201724.29806.nicolas.weeger@laposte.net> Message-ID: <46529545.5090600@sonic.net> Nicolas Weeger wrote: > > There is a kind of todo list, on the wiki - even a few. > http://wiki.metalforge.net/doku.php/dev_todo > http://wiki.metalforge.net/doku.php/dev_todo_new > http://wiki.metalforge.net/doku.php/dev_todo:cf2.0?s=todo > including individual todo lists (arguably, some should be merged...) Yes - there should be one, or at least a common set, of TODO lists. Maybe we should put that on the TODO list. It is a bit of a mess - in some cases, the same thing is listed on multiple TODO lists, and other cases, only one thing is listed. and in some cases, things listed on multiple lists have different statuses. So that would be another thing that a non technical person could do - merge all of these into one list. It may be that the unified todo list is getting a bit too long and a bit unwieldly - it could make sense to break it up into some smaller pieces (perhaps by target release, so in a sense, that stuff listed on the 2.0 target more or less coincides in the requirement list). Or maybe break things down by arch/maps/client/server, so someone who feels comfortable working on maps can easily see what needs to be done there, etc. From lalo.martins at gmail.com Tue May 22 04:27:53 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 22 May 2007 09:27:53 +0000 (UTC) Subject: [crossfire] "identification" skills patch References: <200705202256.04076.nicolas.weeger@laposte.net> <46526CFB.6010700@sonic.net> Message-ID: On Mon, 21 May 2007 21:09:31 -0700, Mark Wedel wrote: > Lalo Martins wrote: >> You see 3 beholders. >> They seem healthy and aggressive. >> Beholders usually attack with spells, and often drop beholder eyes. > > That is reasonable, but to really do that, it would seem that the lore > information should be filled in, rather than trying to figure it out > from the monster attributes. My thinking is that we would use the format above when there is no lore field (or, if people really like it, in addition to it). > To figure out what they usually drops > requires parsing the treasure structure - not impossible, but defining > often/rarely/etc for drop frequency gets odd. I'm also not sure I'd > like the output for dragons and other monsters, with a list of 20 things > they frequently drop. My idea is that the code would pick the item(s) most likely to be dropped and print that; the word "often" is static. However, I don't remember how "dropping" works, so I'm not sure there even is a way to determine what's most likely. Equally, the "usually attack" actually displays what attack is stronger; if the monster actually uses that or not, is beyond our scope to know. (How to compare relative "strength" of spells vs. physical attacks is something that still has to be worked out, I'll give this a thought, but only if people generally agree this format is worth the work. I'll obviously also write the code, since I had the idea :-P) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Tue May 22 04:29:23 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 22 May 2007 09:29:23 +0000 (UTC) Subject: [crossfire] Using openal for client audio? References: <46528F5E.6040903@sonic.net> Message-ID: +1. OpenAL is on my list of cool tech I need to set aside some time to investigate. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Tue May 22 23:20:01 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 May 2007 21:20:01 -0700 Subject: [crossfire] "identification" skills patch In-Reply-To: References: <200705202256.04076.nicolas.weeger@laposte.net> <46526CFB.6010700@sonic.net> Message-ID: <4653C0F1.8030706@sonic.net> Lalo Martins wrote: > My idea is that the code would pick the item(s) most likely to be dropped > and print that; the word "often" is static. However, I don't remember > how "dropping" works, so I'm not sure there even is a way to determine > what's most likely. One can parse the treasure lists, but that is a complete new set of code that doesn't really exist. The treasure generation logic is quite formulaic - in some cases, like the treasureone list, it is very easy to see the most likely object, as only one object will get generated. However, other treasurelists can basically have if/else type of logic, and within those areas, depending on the condition, a group of items is generated (an obvious case of this is bows & arrows - we don't generate one without the other for monsters). It gets even more complicated in that treasurelists can contain other treasurelists, also within those clauses, or have different odds of going to that other treasurelist. Throw in the fact that some treasures (or traversals to other treasure lists) may have minimum map difficulties. Does the code try to figure out what difficulty maps the monsters would typically be on? So figuring out the most likely objects is certainly possible, but may not be as simple as one thinks it may be. In some sense, this is almost like figuring out odds in blackjack (21). One can do it mathematically, but is is easier to just brute force it - you write a program that plays a million hands and records different probabilities. That could pretty much work in crossfire also - one could do a thousand calls to the treasure generation function, and record each time what is generated, and then figure out what is the most likely. But that has its own drawbacks - you want some level of grouping - you'd rather say 'generates potions often' by grouping all the times it generates a potion of some sort vs the potion of strength, potion of int, etc. Also, given the time it is likely to take to do this, you'd need to do this as startup or something. It may in fact be reasonable to generate a file in lib periodically (maybe as part of make install) that has this information. > > Equally, the "usually attack" actually displays what attack is stronger; > if the monster actually uses that or not, is beyond our scope to know. > (How to compare relative "strength" of spells vs. physical attacks is > something that still has to be worked out, I'll give this a thought, but > only if people generally agree this format is worth the work. I'll > obviously also write the code, since I had the idea :-P) Figuring if a monster usually attacks with spells compared to physical gets tricky. And for many monsters, you now need to factor in what equipment they have - titans always have bonecrushers, which I believe change their physical attack characteristics quite a bit compared to if they didn't have them. Other monsters may be similar. The spoiler already extracts some of this information, but IIRC, it does some basic parsing of treasurelists, and in the spoiler list all the spell like abilities the creature may have, where as in almost all cases, a monster would only have a subset of those. Now some of this can become a lot easier if you look at the monster on the spaces being examined - in those cases, you know exactly what objects the monster has, as well as what spells, so can pretty easily give accurate results, but these are now specific to the monsters around, not general case. From nicolas.weeger at laposte.net Wed May 23 12:50:48 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 23 May 2007 19:50:48 +0200 Subject: [crossfire] Using openal for client audio? In-Reply-To: <46528F5E.6040903@sonic.net> References: <46528F5E.6040903@sonic.net> Message-ID: <200705231950.48518.nicolas.weeger@laposte.net> > Thoughts/comments? Sounds fine by me. Though I'd first redo the sound system for the server :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Wed May 23 17:20:49 2007 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 23 May 2007 16:20:49 -0600 Subject: [crossfire] Using openal for client audio? In-Reply-To: <200705231950.48518.nicolas.weeger@laposte.net> References: <46528F5E.6040903@sonic.net> <200705231950.48518.nicolas.weeger@laposte.net> Message-ID: <4654BE41.9090302@telus.net> Nicolas Weeger wrote: >> Thoughts/comments? >> > > Sounds fine by me. > Though I'd first redo the sound system for the server :) Agreed. OpenAL sounds like a fine choice for client sound support, but personally I think the server and protocol infrastructure and should be redone first, but of course, whatever order people get things done in works as I'm sure the OpenAL code could be ported easily enough to whatever changes happen in the rest of the sound infrastructure. Alex Schultz From mwedel at sonic.net Wed May 23 23:34:44 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 23 May 2007 21:34:44 -0700 Subject: [crossfire] Sound information, was Re: Using openal for client audio? In-Reply-To: <4654BE41.9090302@telus.net> References: <46528F5E.6040903@sonic.net> <200705231950.48518.nicolas.weeger@laposte.net> <4654BE41.9090302@telus.net> Message-ID: <465515E4.50604@sonic.net> Alex Schultz wrote: > Nicolas Weeger wrote: >>> Thoughts/comments? >>> >> Sounds fine by me. >> Though I'd first redo the sound system for the server :) > Agreed. OpenAL sounds like a fine choice for client sound support, but > personally I think the server and protocol infrastructure and should be > redone first, but of course, whatever order people get things done in > works as I'm sure the OpenAL code could be ported easily enough to > whatever changes happen in the rest of the sound infrastructure. IMO, there are really 3 pieces of this: 1) How sounds are specified in objects 2) How that information is communicated to the client 3) How the client uses that information. Each builds upon the previous point to some extent - the server can't really know how to send sound data to the client until it knows how it will have sound data. Likewise, hard to write a good implementation on the client unless you know how it will get the data. I think this has been discussed before, but doesn't look like it is recorded on the wiki: http://wiki.metalforge.net/doku.php/dev_todo:fix_sound For objects (which then includes archetypes), my thought is there would be something like a linked list of sound attributes. This would contain: - What event to play the sound on (object moves, object is applied, object is destroyed, etc). This could be extended later, as only the server cares about this - it basically determines when the server sends sound information to the client. However, having a full list earlier makes things easier. - What sound to play (in the object, this is free form text - for archetypes, it may be desirable to do something like the images, which we assign a number to each sound file and thus can send information by number instead of name. However, since it is probably desirable to specify sound names in maps, which may not be standard sound files, it probably means that that table must be dynamically updatable (no entry for this file, lets add a new one), and likewise client must be able to deal with a larger table. - Attributes of the sound. This could be things like is the sound continuous (so a fountain) or single use, like say a door being destroyed. It is perhaps this is redundant with event (there could be pseudo event, like event_always to denote always play this sound). Other attributes could be volume - may want to use the same sound file, but use different volumes. In terms of sound file availability, I don't really like the idea of this media provided by the server itself. What I'd instead suggest is that when a client connects to the server, the server can tell it the location of its media file, as well as current version. Client can see if it has downloaded that, and if not, go and download it. I'd suggest it should use http as a protocol for this - for one, http access is extremely common - if you can run a server, almost certainly you can have a place to put up files available by http. Second is that if/when the new metaserver stuff is done, that would probably also use http logic (for similar reasons), so that code/library could be re-used. From nicolas.weeger at laposte.net Thu May 24 16:21:16 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 24 May 2007 23:21:16 +0200 Subject: [crossfire] Legs Message-ID: <200705242321.17195.nicolas.weeger@laposte.net> Hello. I just implemented feature request http://sourceforge.net/tracker/index.php?func=detail&aid=1653768&group_id=13833&atid=363833 for legs body slot. Player archetypes now have 2 legs when relevant. Now we just need armor for that ;) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Fri May 25 00:23:53 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 24 May 2007 22:23:53 -0700 Subject: [crossfire] Legs In-Reply-To: <200705242321.17195.nicolas.weeger@laposte.net> References: <200705242321.17195.nicolas.weeger@laposte.net> Message-ID: <465672E9.8000202@sonic.net> Nicolas Weeger wrote: > Hello. > > I just implemented feature request > http://sourceforge.net/tracker/index.php?func=detail&aid=1653768&group_id=13833&atid=363833 > for legs body slot. > > Player archetypes now have 2 legs when relevant. > > Now we just need armor for that ;) We have to keep balance in mind. One problem that happened when 'normal' boots and gauntlets could be found (instead of only the artifact ones) is that players AC now jumped 4 points - could find ac+2 boots and ac+2 gauntlets. Some could happen for pants/greaves. May not seem like a lot, but low level characters are able to pick up these items, so it was level 3-4 characters getting 4 points of AC, which is a pretty big difference. One way to perhaps fix this is that full armor suits should perhaps use both torso & legs (it is a full suit after all) - things like dragon scale armor, plate, etc. And one could perhaps have more piecemeal armor - you could wear that breastplate & greaves, etc. From nicolas.weeger at laposte.net Fri May 25 12:39:10 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 25 May 2007 19:39:10 +0200 Subject: [crossfire] Legs In-Reply-To: <465672E9.8000202@sonic.net> References: <200705242321.17195.nicolas.weeger@laposte.net> <465672E9.8000202@sonic.net> Message-ID: <200705251939.10647.nicolas.weeger@laposte.net> > One problem that happened when 'normal' boots and gauntlets could be > found (instead of only the artifact ones) is that players AC now jumped 4 > points - could find ac+2 boots and ac+2 gauntlets. Some could happen for > pants/greaves. > > May not seem like a lot, but low level characters are able to pick up > these items, so it was level 3-4 characters getting 4 points of AC, which > is a pretty big difference. > > One way to perhaps fix this is that full armor suits should perhaps use > both torso & legs (it is a full suit after all) - things like dragon scale > armor, plate, etc. And one could perhaps have more piecemeal armor - you > could wear that breastplate & greaves, etc. Sure, that can be fixed :) Just need to decide how ^_- Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mail-lists+cfdev at dogphilosophy.net Sun May 27 17:40:54 2007 From: mail-lists+cfdev at dogphilosophy.net (Epicanis) Date: Sun, 27 May 2007 16:40:54 -0600 Subject: [crossfire] Argh! Invisible spell! Message-ID: <200705271640.55413.mail-lists+cfdev@dogphilosophy.net> After a half-decade of being too busy, I decided to try messing around adding things to Crossfire. (I'm STILL too busy, but I'm doing it anyway - I need to relax.) As a warmup, I'm trying to add a "waterballoon" spell (low level, low power). Eventually, I'd like to set it so that the bullet drops a single-square (range 0?) "explosion" of water, but right now I'm just trying to figure out how to get the basic "fling the 'bullet', hit the target" thing working. The problem I can't seem to figure out is...it's invisible. It's hits its targets and goes off as expected, but nothing is visible flying across them room. I've tried a few different variations of "face" but I can't seem to get a visible "bullet". Any hints? The current iteration of the arch looks like this: spell_waterballoon.arc: Object spell_waterballoon name waterballoon name_pl waterballoon face spell_evocation.111 level 1 sp 1 casting_time 5 path_attuned 0 other_arch waterbullet dam 2 dam_modifier 5 range 1 duration 1 maxsp 24 type 101 subtype 5 value 20 attacktype 3 slaying fire,scrolls,demon no_drop 1 invisible 1 skill evocation food 15 end waterbullet.arc Object waterbullet type 102 subtype 5 face blackfirebullet.111 anim blackfirebullet.111 blackfirebullet.121 blackfirebullet.131 blackfirebullet.141 blackfirebullet.151 blackfirebullet.161 blackfirebullet.171 blackfirebullet.181 mina is_animated 0 is_turnable 1 move_on walk fly_low glow_radius 1 range 0 speed 1 move_type fly_low no_pick 1 editable 0 end Any help would be appreciated. Thanks From nicolas.weeger at laposte.net Wed May 30 12:18:02 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 30 May 2007 19:18:02 +0200 Subject: [crossfire] Undead dragon Message-ID: <200705301918.02485.nicolas.weeger@laposte.net> Hello. With relation to the bug at http://sourceforge.net/tracker/index.php?func=detail&aid=1727118&group_id=13833&atid=113833 (which isn't per se a bug - dragons worshipping Devourers aren't dragons anymore). The is_dragon_pl() function will though return 1, allowing such a dragon to gain resistances. So undead dragons can gain resistances, but can't enter dragon guilds. What do you think of that? IMO undead dragon must be able to gain resistances, else too hard. On the other hand, entering a guild, we can decide some dragon guilds reject undead dragons. So I'd say we keep the situation this way :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Wed May 30 16:54:08 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 30 May 2007 23:54:08 +0200 Subject: [crossfire] Argh! Invisible spell! In-Reply-To: <200705271640.55413.mail-lists+cfdev@dogphilosophy.net> References: <200705271640.55413.mail-lists+cfdev@dogphilosophy.net> Message-ID: <200705302354.08645.nicolas.weeger@laposte.net> Hello. Sorry for the reply delay :) > The problem I can't seem to figure out is...it's invisible. It's hits its > targets and goes off as expected, but nothing is visible flying across them > room. > > I've tried a few different variations of "face" but I can't seem to get > a visible "bullet". Any hints? I tried with your item, and there is one issue: you actually need *9* lines in the 'anim' part. Just duplicate the first (blackfirebullet.111) at the first position (so 2 111 lines, then 121, ...). Fixing that, the bullet works correctly with SVN trunk - haven't tried with branch, but it should work the same. Did you write the .arc in the arch directory, and run a 'make collect && make install' from the server/lib directory? To correctly add archetypes, you need the 'arch' SVN tree, (symlinked) in server/lib. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !]