From leaf at real-time.com Mon May 1 15:58:11 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 01 May 2006 15:58:11 -0500 Subject: [crossfire] Sourceforge project admin intervention request In-Reply-To: <4454D8CE.6010809@myrealbox.com> References: <4454D8CE.6010809@myrealbox.com> Message-ID: <44567663.8020107@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 tchize wrote: > > Due to a bug in sourceforge security management, only project admins > have access to the page named 'source logos' which contains the codes > samples to use on every project webpage hosted on sf. Following up on this.. HTML snippets and other information was sent privately/off-list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEVnZjhHyvgBp+vH4RAp1fAJ913Rkd16MNIEt+ZYOEpGKvZ2LqQACguhP2 D2G4CooNAa7ottoBrWkj95M= =4XhL -----END PGP SIGNATURE----- From alex_sch at telus.net Tue May 2 18:04:00 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 02 May 2006 17:04:00 -0600 Subject: [crossfire] Steam Protocol Proposal In-Reply-To: <4455834A.4020700@telus.net> References: <4455834A.4020700@telus.net> Message-ID: <4457E560.4010503@telus.net> Alex Schultz wrote: >(When the client wants the server to start sending in stream format foo, >where foo can be something such as 'zlib', 'ssl' or 'plaintext') >C->S: req_recv_stream foo "May you send me data in stream >format foo?" >S->C: ack_send_stream foo "Sure. Here, sending it in format foo >now" >S->C: > An important thing to note, I don't endorse the need for an ssl stream mode, that was just for the sake of example. The point was more, allowing the types of allowed data streams (mainly for compression, but doesn't have to just be for compression) to be extended easily in the future if needed. Alex Schultz From leaf at real-time.com Wed May 3 17:30:59 2006 From: leaf at real-time.com (Rick Tanner) Date: Wed, 03 May 2006 17:30:59 -0500 Subject: [crossfire] Backup(?) CVS via darcs Message-ID: <44592F23.4020406@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For possible discussion... Now that we are looking at week #6 of anonymous CVS access at SourceForge being offline (and development CVS access off & on during that time..) what about using something like darcs which is a distributed revision control system? http://darcs.net/ http://darcs.net/DarcsWiki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEWS8ihHyvgBp+vH4RAiBnAJ9A0UOVPxQ+7NkSSDshWvEQ0zfOjACgjsRp o1w7qL/TRzJ91uFVF46WDSY= =SzUP -----END PGP SIGNATURE----- From alex_sch at telus.net Wed May 3 23:59:28 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 03 May 2006 22:59:28 -0600 Subject: [crossfire] Backup(?) CVS via darcs In-Reply-To: <44592F23.4020406@real-time.com> References: <44592F23.4020406@real-time.com> Message-ID: <44598A30.5010907@telus.net> I've been thinking about this a bit, and IMHO, switching to anything but CVS would be an improvement, and that switching would be good for the long term, not just for backup. For one, just about any other version control system allows local branches of the code easier which would be helpful for working on larger features, and also if we don't use sourceforge we will be free from various limitations Here is my opinion of Darcs as well as some other alternatives to CVS: SVN: Rather nice and mature, and a very easy learning curve from CVS. It has the "advantage" that we could stick with sourceforge for version control, however that could easily have the same uptime issues as SF CVS some time down the road. Darcs: Like SVN, also seems to good mature one. I don't know much about it but it looks like it might be nicer than either SVN or CVS in many ways. It would however have a little bit of a steeper learning curve from cvs users, but personally I'm *very* willing to learn it (in fact, I've been planing to eventually some time anyways). Bazaar-ng: I've tried this python based one a bit, and it seems very nice with good features, except two major issues that make it IMHO *not* suitable for crossfire: Not very mature of an API and featureset, and also from what I understand doesn't work on win32. It is however the best one I've seen in terms of ease of making local branches. Also, as a general note, I believe that in any of these cases, we should sync back to SF cvs, because for when that is up, it would be an easier place to get development versions from than darcs, as common users generally wouldn't install darcs just for downloading the latest development version of crossfire, or it would also be possible set the darcs server to build tarballs on a nightly basis, however this wouldn't give non-developers a way to see the revision logs and such via the command line, however I'm not sure how important this is. Alex Schultz Rick Tanner wrote: >For possible discussion... > >Now that we are looking at week #6 of anonymous CVS access at >SourceForge being offline (and development CVS access off & on during >that time..) what about using something like darcs which is a >distributed revision control system? > >http://darcs.net/ >http://darcs.net/DarcsWiki > From alex_sch at telus.net Thu May 4 00:13:20 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 03 May 2006 23:13:20 -0600 Subject: [crossfire] Backup(?) CVS via darcs In-Reply-To: <44598A30.5010907@telus.net> References: <44592F23.4020406@real-time.com> <44598A30.5010907@telus.net> Message-ID: <44598D70.4090505@telus.net> Alex Schultz wrote: >Darcs: >Like SVN, also seems to good mature one. I don't know much about it but >it looks like it might be nicer than either SVN or CVS in many ways. It >would however have a little bit of a steeper learning curve from cvs >users, but personally I'm *very* willing to learn it (in fact, I've been >planing to eventually some time anyways) > Oh, also. Was doing some reading and these are some helpful documents for cvs to darcs migration: http://www.abridgegame.org/darcs/manual/node2.html#SECTION00220000000000000000 http://www.abridgegame.org/pipermail/darcs-users/2004-July/002351.html Also, looking at the second one, I see some of the disadvantages of it, however compared to CVS, it's still worth it IMHO, however there might be better ways to go away from cvs than darcs. Alex Schultz From won_fang at yahoo.com.au Thu May 4 00:13:13 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Thu, 4 May 2006 15:13:13 +1000 Subject: [crossfire] Backup(?) CVS via darcs In-Reply-To: <44598A30.5010907@telus.net> References: <44592F23.4020406@real-time.com> <44598A30.5010907@telus.net> Message-ID: <20060504151313.57a84c82@cluster.meeting.humbug.org.au> On Wed, 03 May 2006 22:59:28 -0600 Alex Schultz wrote: > and also if we don't use sourceforge we will be free from various > limitations Enlightenment, which was the second project to ever join sourceforge, moved it's cvs completely over to it's own server, just two days before the big sourceforge cvs server crash. Everything else was left on sourceforge. It's not that we knew the big crash was coming, we just where tired of all the problems the overworked sourceforge cvs servers where causing. Just a data point I thought I would add to this conversation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060504/84c0986a/attachment.pgp From brenlally at gmail.com Thu May 4 02:47:14 2006 From: brenlally at gmail.com (Brendan Lally) Date: Thu, 4 May 2006 08:47:14 +0100 Subject: [crossfire] Backup(?) CVS via darcs In-Reply-To: <44598A30.5010907@telus.net> References: <44592F23.4020406@real-time.com> <44598A30.5010907@telus.net> Message-ID: <7903f03c0605040047l6d240ac3yb51f2495a1e1330e@mail.gmail.com> On 5/4/06, Alex Schultz wrote: > Here is my opinion > of Darcs as well as some other alternatives to CVS: Is there any reason why GNU Arch hasn't been considered in your comparison? Is there something wrong with it that discounts it straight away? (NB: I have never used it, but savannah does). From alex_sch at telus.net Thu May 4 07:45:45 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 04 May 2006 06:45:45 -0600 Subject: [crossfire] Backup(?) CVS via darcs In-Reply-To: <7903f03c0605040047l6d240ac3yb51f2495a1e1330e@mail.gmail.com> References: <44592F23.4020406@real-time.com> <44598A30.5010907@telus.net> <7903f03c0605040047l6d240ac3yb51f2495a1e1330e@mail.gmail.com> Message-ID: <4459F779.5040803@telus.net> Brendan Lally wrote: >On 5/4/06, Alex Schultz wrote: > > >>Here is my opinion >>of Darcs as well as some other alternatives to CVS: >> >> >Is there any reason why GNU Arch hasn't been considered in your >comparison? Is there something wrong with it that discounts it >straight away? (NB: I have never used it, but savannah does). > I don't have GNU Arch in my comparison because I don't know enough about it to compare at all. No reason that I know of why it wouldn't work (though there could be one) Alex Schultz From lalo.martins at gmail.com Thu May 4 11:16:30 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 05 May 2006 00:16:30 +0800 Subject: [crossfire] Backup(?) CVS via darcs References: <44592F23.4020406@real-time.com> <44598A30.5010907@telus.net> Message-ID: Yes. Please. *Any* distributed version control system. On Wed, 03 May 2006 22:59:28 -0600, Alex Schultz wrote: > SVN: > Rather nice and mature, and a very easy learning curve from CVS. It has > the "advantage" that we could stick with sourceforge for version > control, however that could easily have the same uptime issues as SF CVS > some time down the road. Cons: SVN server is a bit heavyweight. It's not a distributed system; there is a thing called svk which hacks distributedness on top of it. > Darcs: > Like SVN, also seems to good mature one. I don't know much about it but > it looks like it might be nicer than either SVN or CVS in many ways. It > would however have a little bit of a steeper learning curve from cvs > users, but personally I'm *very* willing to learn it (in fact, I've been > planing to eventually some time anyways). My only experience with darcs is collaborating to tailor (more on tailor later). I find it has a steep learning curve as you say; because it's based on quite different principles. If you're coming from no version control at all (just sending patches around), it's a lot easier. It's also written in some weird language, for which most people don't have a working environment already. (Which one is it again? Let me check. Oh, Haskell.) That's not a very big deal; it's compiled, and you don't need any Haskell stuff to run it. But if you decide to hack it, then you have to learn a new language. Whereas I hack bzr routinely, it even has a very nifty plugin system. > Bazaar-ng: > I've tried this python based one a bit, and it seems very nice with good > features, except two major issues that make it IMHO *not* suitable for > crossfire: Not very mature of an API and featureset, and also from what > I understand doesn't work on win32. It is however the best one I've seen > in terms of ease of making local branches. Well, bzr 0.8 is out at some point in May, according to Martin Pool; and this is the point where the team is committing to stability and support. I understand "maturity" though, it's a rather young system. As for win32: there's no pretty GUI, but I use it at work, from the windows command line, on a daily basis. Works quite well for me. It feels much slower than darcs, mercurial, or monotone, right now. Getting a branch with long history on 0.8 ('knit' format) takes much longer than cvs, on 0.7 ('weave' format) it might take more than an hour. An now on to Tailor: Tailor is a tool originally written to sync SVN (or was it CVS?) repositories to Darcs. It's now a very interesting cross-VC syncer. I helped Rednaxela set up a Tailor config to mirror crossfire's cvs repo to bzr (with the intention of using the bzr version myself, too, once it was working). I just thought I should mention. Whatever distributed VC we switch to, tailor could be used to do the migration. I'd be willing to do the actual work (well, what little there is, as Rednaxela already did the ugly parts). And it can also be used afterwards, to keep a read-only CVS copy of the main branch, as you say. 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://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From alex_sch at telus.net Thu May 4 19:27:15 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 04 May 2006 18:27:15 -0600 Subject: [crossfire] Backup(?) CVS via darcs In-Reply-To: References: <44592F23.4020406@real-time.com> <44598A30.5010907@telus.net> Message-ID: <445A9BE3.9080809@telus.net> Lalo Martins wrote: >An now on to Tailor: > >Tailor is a tool originally written to sync SVN (or was it CVS?) >repositories to Darcs. It's now a very interesting cross-VC syncer. I >helped Rednaxela set up a Tailor config to mirror crossfire's cvs repo to >bzr (with the intention of using the bzr version myself, too, once it was >working). I just thought I should mention. Whatever distributed VC we >switch to, tailor could be used to do the migration. I'd be willing to do >the actual work (well, what little there is, as Rednaxela already did the >ugly parts). And it can also be used afterwards, to keep a read-only CVS >copy of the main branch, as you say. > Well, yes, not much to do to get that working, I pretty much made a script that deals with all of it. There is however one issue. I didn't get syncing back to SF cvs (i.e. two way sync. I was trying to at the time hack some stuff together so I could have distributed VC features with the existing CVS server) isn't quite working, however syncing back to a CLEAN cvs repository for read-only cvs purposes should work perfectly well. Or in other words, when keeping a read-only cvs copy of the main branch, we likely couldn't overwrite the existing SF CVS module and would instead have to make a new module on cvs for it Another note for those who don't know much about tailor, it DOES preserve revision history very nicely. Alex Schultz Alex Schultz From nicolas.weeger at laposte.net Fri May 5 03:41:27 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 5 May 2006 10:41:27 +0200 Subject: [crossfire] requestable party lists In-Reply-To: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> References: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> Message-ID: <200605051041.27076.nicolas.weeger@laposte.net> Hello. > I have uploaded a patch to the sourceforge tracker which forms an > initial proposal for requestable party lists. I like the idea. Forbidding : in party name isn't too bad imo. I looked at the patch, and have a few comments: * not totally sure lastparty gets initialized (maybe through a memset, haven't checked the code on player structure initialization) * you should definitely use snprintf instead of sprintf to send data, in send_party_list Nicolas From nicolas.weeger at laposte.net Sun May 7 03:50:09 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 7 May 2006 10:50:09 +0200 Subject: [crossfire] Create earth wall / earth to dust issue Message-ID: <200605071050.09397.nicolas.weeger@laposte.net> Hello. juhaj on IRC reported a earth to dust bug. Looking at the code, I see 2 issues: * in server/spell_effect.c, lines 705/706, it should be imo for(i= -range;i<=range;i++) instead of for(i= -range;i References: <200605071050.09397.nicolas.weeger@laposte.net> Message-ID: <20060507122342.GA6319@elmex> On Sun, May 07, 2006 at 10:50:09AM +0200, Nicolas Weeger (Laposte) wrote: > * earth to dust fails because no object with move_block is on the spot. This > is because earth wall that was created has no move_block set - wall is alive, > thus player/monsters can't get on it. I'm not totally sure what's the best > way to fix that. Maybe spell should have a move_block set? I noticed that earthwalls changed, so that the monsters can attack you through it. I wasn't aware of the way the earthwalls were changed, now that i see how, i'm confused about that hack. IMHO earthwalls should keep a distance between you and the monsters. The change in the earthwalls made the monsters attack you through the earthwall, as if they could see you. But, if they can see you, you should also be able to see them (at least that would be consistent and logic). This should be fixed IMHO. I don't know whether move_block implies blocksview, but it shouldn't if it does. And if it doesnt imply blocksview, earthwalls should be something like this: blocksview 0 move_block all If the problem is, that existing maps rely on viewblocking earthwalls the maps should be fixed and use something different. Maybe make a second earthwall archetype, with a different name "earthhill" or whatever. So that the summoned earthwalls are different from the earthwalls used in the maps. This would make sense to me: Earthwalls in maps represent some kind of spillage, where summoned earthwalls should only be some kind of obstacle for monsters, so that they can't get near you. -- elmex at ta-sa.org / robin at nethype.de / r.redeker at gmail.com Robin Redeker From alex_sch at telus.net Sun May 7 12:51:29 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 07 May 2006 11:51:29 -0600 Subject: [crossfire] Create earth wall / earth to dust issue In-Reply-To: <20060507122342.GA6319@elmex> References: <200605071050.09397.nicolas.weeger@laposte.net> <20060507122342.GA6319@elmex> Message-ID: <445E33A1.90207@telus.net> Robin Redeker wrote: >The change in the earthwalls made the monsters attack you through the >earthwall, as if they could see you > On a slightly unrelated note to the topic of earth walls. Monsters currently omniscient to everything on the map that isn't 1) too dark a place for them to see, or 2) invisible when the monster can't see invisible. that is something that has ALWAYS been the case. However, I personally thing that perhaps it should be changed, if the concern that it may make monsters to weak, can be addressed well. Alex Schultz From mwedel at sonic.net Mon May 8 01:55:36 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 07 May 2006 23:55:36 -0700 Subject: [crossfire] Create earth wall / earth to dust issue In-Reply-To: <200605071050.09397.nicolas.weeger@laposte.net> References: <200605071050.09397.nicolas.weeger@laposte.net> Message-ID: <445EEB68.1090607@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > juhaj on IRC reported a earth to dust bug. > > Looking at the code, I see 2 issues: > * in server/spell_effect.c, lines 705/706, it should be imo for(i= > -range;i<=range;i++) instead of for(i= -range;i do [-range..range] inclusive > * earth to dust fails because no object with move_block is on the spot. This > is because earth wall that was created has no move_block set - wall is alive, > thus player/monsters can't get on it. I'm not totally sure what's the best > way to fix that. Maybe spell should have a move_block set? I think that the earthwalls should have move_block set. While most of the movement code basically has logic of 'if living creature on this space, you can't move on it', IMO, at some point that needs to change. A flying creature should be able to fly over (on top) of a creature on the ground without problems. It appears that move_player_attack() does the right thing - doesn't care why the player can't move on the space - it just goes and examines the objects on the space to see if it if soemething the player should attack. From mwedel at sonic.net Mon May 8 01:59:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 07 May 2006 23:59:33 -0700 Subject: [crossfire] Create earth wall / earth to dust issue In-Reply-To: <20060507122342.GA6319@elmex> References: <200605071050.09397.nicolas.weeger@laposte.net> <20060507122342.GA6319@elmex> Message-ID: <445EEC55.9040206@sonic.net> Robin Redeker wrote: > On Sun, May 07, 2006 at 10:50:09AM +0200, Nicolas Weeger (Laposte) wrote: >> * earth to dust fails because no object with move_block is on the spot. This >> is because earth wall that was created has no move_block set - wall is alive, >> thus player/monsters can't get on it. I'm not totally sure what's the best >> way to fix that. Maybe spell should have a move_block set? > > I noticed that earthwalls changed, so that the monsters can attack you through > it. I wasn't aware of the way the earthwalls were changed, now that i > see how, i'm confused about that hack. That is probably because move_block is not set on the walls. The attack doesn't see anything that stops it, so it keeps going (I'm presuming we're talking arrows and spells here). > > IMHO earthwalls should keep a distance between you and the monsters. > The change in the earthwalls made the monsters attack you through the > earthwall, as if they could see you. > But, if they can see you, you should also be able to see them > (at least that would be consistent and logic). > This should be fixed IMHO. As Alex states, monsters use a bit different sight logic. More on that in his message. > > I don't know whether move_block implies blocksview, but it shouldn't > if it does. And if it doesnt imply blocksview, earthwalls should be > something like this: > > blocksview 0 > move_block all move block and blocksview are not tied to anything. You can have a wall that blocks you from seeing through it, but does not block movement. Likewise, you can have a wall that you can see through, but can't move through (the walls separating the entry area from the shop area of the scorn shops is an example of that). I think the real fix here is to make it so that the earthwalls block movement. that sort of fixes the problem - the monsters still know where you are, but can't get to you through the earthwall. From mwedel at sonic.net Mon May 8 02:02:53 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 08 May 2006 00:02:53 -0700 Subject: [crossfire] Create earth wall / earth to dust issue In-Reply-To: <445E33A1.90207@telus.net> References: <200605071050.09397.nicolas.weeger@laposte.net> <20060507122342.GA6319@elmex> <445E33A1.90207@telus.net> Message-ID: <445EED1D.3030200@sonic.net> Alex Schultz wrote: > Robin Redeker wrote: > >> The change in the earthwalls made the monsters attack you through the >> earthwall, as if they could see you >> > On a slightly unrelated note to the topic of earth walls. Monsters > currently omniscient to everything on the map that isn't 1) too dark a > place for them to see, or 2) invisible when the monster can't see > invisible. that is something that has ALWAYS been the case. > However, I personally thing that perhaps it should be changed, if the > concern that it may make monsters to weak, can be addressed well. I thought there was some range limit based on the monsters Int or something. So monsters sould only detect you so far. But simply put, the monster logic really needs to be improved. The fact that monsters can see through the walls probably doesn't help them that much - it may in fact just bunch them in a corner which the player runs around and then whaps them with one spell. But monster logic could be greatly improved. From mwedel at sonic.net Mon May 8 02:18:26 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 08 May 2006 00:18:26 -0700 Subject: [crossfire] Backup(?) CVS via darcs In-Reply-To: <44592F23.4020406@real-time.com> References: <44592F23.4020406@real-time.com> Message-ID: <445EF0C2.9020508@sonic.net> To me, there are perhaps two issues, which may or may not be related: 1) Ability to have multiple repositories on stable systems. 2) What source control tool to use. Right now, and probably with any source control tool, multiple _read only_ repositories could be done. In CVS, this would basically be setting up a CVS repository, and have that repository pull (sync) the data from the main repository on an hour or nightly basis (for crossfire, nightly is probably sufficient). The disadvantage here is that it means if you pulled your copy out of some mirror, and then later want to commit some code back to the read/write repository, you have to jump through some hoops. However, I'm not sure how often that happens (I'd expect developers to always stick to using the main repository, so it would really be the case of a non developer getting developer access). The second question is what is the best source control software to use for crossfire. If it has distributedness on top of that, that could be nice, but I'd think it is more important to look for the features we want. I say that in that I don't think crossfire would pound a CVS (or whatever repository server) so much to actually need/require multiple instances. The issue really is that sourceforge just isn't really stable (you get what you pay for I suppose). If sourceforge had 99.99% uptime, I don't think there would be any real issues relative to crossfire for needing a distributed server environment. But that does sort of lead to other questions. Right now, as far as I know, soruceforge only supports CVS and SVN. any other source system would require external hosting and/or a bridge mechanism to CVS. My personal thought is I'd much rather have whatever people commit code to be the main repository, and everything else, including sourceforge CVS, to be a read-only (from user perspective) mirror of that - it seems that have several potential read/write repositories would be a conflict waiting to happen. From mwedel at sonic.net Mon May 8 02:33:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 08 May 2006 00:33:51 -0700 Subject: [crossfire] Steam Protocol Proposal In-Reply-To: <4455834A.4020700@telus.net> References: <4455834A.4020700@telus.net> Message-ID: <445EF45F.7030407@sonic.net> Some general quick thoughts: As stated before, selective 'per packet' compression has the nice advantage very easy to do - no need for extra buffers on the client or server side needed. That said, if someone is willing to write that extra code, sounds good to me. A quick question is - are multiple simultaneous stream types supported? For example, suppose I'm using zlib stream all the time. But for passwords, SSL is used. Does that mean the SSL data is encapsulated in the zlib stream, or does it mean that the zlib stream ends, and the ssl stream starts, ssl stream ends, then zlib restarts? I'm personally thinking that it is much easier to only support a single stream at a time. I actually don't think the mechanism proposed would work really good for SSL and password data - this is because of the latency involved in the negotiating the stream type (client has to wait for the server to respond that it is OK to send SSL data before it can actually do so, which means the round trip time from the server to client). Unless you use the SSL stream all the time (enter it once, and never exit it), I think you'd be better off with finding out if the server can handle SSL at start up via the setup command, and then doing stuff like: C->S: ssldata In fact, given the latency involved in switch modes, you really don't want to switch very often. On the S->C side, not a big deal, as once the server receives the request from the client, it can switch to that mode. But on the C->S side of things, if it really wants to send that next packet in SSL mode because it has a password, it really can't send anything else to the server until the mode is negotiated (the server I don't believe would be happen to receive an apply command while it is waiting for a password). However, that last problem can be solved somewhat by another patch/suggestion I believe which would send the command and password at the same time. From mwedel at sonic.net Mon May 8 02:37:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 08 May 2006 00:37:04 -0700 Subject: [crossfire] Fwd: [gentoo-announce] [ GLSA 200604-11 ] Crossfire server: Denial of Service and potential arbitrary code execution In-Reply-To: References: <444A8E2E.7010909@gentoo.org> Message-ID: <445EF520.7040901@sonic.net> Andrew Fuchs wrote: > Umm, was this the flaw i discovered, or is it a new one? The fact it says version >= 1.9.0 are not affected would seem to suggest that this isn't a problem anymore. but I'm not sure exactly what bug this is describing. > > ---------- Forwarded message ---------- > From: Thierry Carrez > Date: Apr 22, 2006 4:12 PM > Subject: [gentoo-announce] [ GLSA 200604-11 ] Crossfire server: Denial > of Service and potential arbitrary code execution > To: gentoo-announce at lists.gentoo.org > Cc: bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk, > security-alerts at linuxsecurity.com > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Gentoo Linux Security Advisory GLSA 200604-11 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > http://security.gentoo.org/ > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Severity: High > Title: Crossfire server: Denial of Service and potential arbitrary > code execution > Date: April 22, 2006 > Bugs: #126169 > ID: 200604-11 > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Synopsis > ======== > > The Crossfire game server is vulnerable to a Denial of Service and > potentially to the execution of arbitrary code. > > Background > ========== > > Crossfire is a cooperative multiplayer graphical adventure and > role-playing game. The Crossfire game server allows various compatible > clients to connect to participate in a cooperative game. > > Affected packages > ================= > > ------------------------------------------------------------------- > Package / Vulnerable / Unaffected > ------------------------------------------------------------------- > 1 games-server/crossfire-server < 1.9.0 >= 1.9.0 > > Description > =========== > > Luigi Auriemma discovered a vulnerability in the Crossfire game server, > in the handling of the "oldsocketmode" option when processing overly > large requests. > > Impact > ====== > > An attacker can set up a malicious Crossfire client that would send a > large request in "oldsocketmode", resulting in a Denial of Service on > the Crossfire server and potentially in the execution of arbitrary code > on the server with the rights of the game server. > > Workaround > ========== > > There is no known workaround at this time. > > Resolution > ========== > > All Crossfire server users should upgrade to the latest version: > > # emerge --sync > # emerge --ask --oneshot --verbose > ">=games-server/crossfire-server-1.9.0" > > References > ========== > > [ 1 ] CVE-2006-1010 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1010 > > Availability > ============ > > This GLSA and any updates to it are available for viewing at > the Gentoo Security Website: > > http://security.gentoo.org/glsa/glsa-200604-11.xml > > Concerns? > ========= > > Security is a primary focus of Gentoo Linux and ensuring the > confidentiality and security of our users machines is of utmost > importance to us. Any security concerns should be addressed to > security at gentoo.org or alternatively, you may file a bug at > http://bugs.gentoo.org. > > License > ======= > > Copyright 2006 Gentoo Foundation, Inc; referenced text > belongs to its owner(s). > > The contents of this document are licensed under the > Creative Commons - Attribution / Share Alike license. > > http://creativecommons.org/licenses/by-sa/2.0 > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From alex_sch at telus.net Mon May 8 07:43:20 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 08 May 2006 06:43:20 -0600 Subject: [crossfire] Steam Protocol Proposal In-Reply-To: <445EF45F.7030407@sonic.net> References: <4455834A.4020700@telus.net> <445EF45F.7030407@sonic.net> Message-ID: <445F3CE8.3000605@telus.net> Mark Wedel wrote: > Some general quick thoughts: > > As stated before, selective 'per packet' compression has the nice advantage >very easy to do - no need for extra buffers on the client or server side needed. >That said, if someone is willing to write that extra code, sounds good to me. > > It is simpler to do selective 'per packet', however given some tests I did, it can easily take up to 50% more bandwidth, so I think for compression that streams are the way to go. > A quick question is - are multiple simultaneous stream types supported? For >example, suppose I'm using zlib stream all the time. But for passwords, SSL is >used. Does that mean the SSL data is encapsulated in the zlib stream, or does >it mean that the zlib stream ends, and the ssl stream starts, ssl stream ends, >then zlib restarts? > > I'm personally thinking that it is much easier to only support a single stream >at a time. > > Well, I was thinking of allowing layering different types of streams within eachother, however now I don't really think there is a need for such and hence isn't worth bothering with. > I actually don't think the mechanism proposed would work really good for SSL >and password data - this is because of the latency involved in the negotiating >the stream type (client has to wait for the server to respond that it is OK to >send SSL data before it can actually do so, which means the round trip time from >the server to client). > Agreed. This protocol while suitable for streams in general, isn't suitable for switching to a stream for a specific purpose (i.e password). At that, I'm not completely sure ssl is the best way to send a password for more secure login, however if that is done, some sort of per-packet would be better. Alex Schultz From mwedel at sonic.net Tue May 9 02:10:11 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 09 May 2006 00:10:11 -0700 Subject: [crossfire] Steam Protocol Proposal In-Reply-To: <445F3CE8.3000605@telus.net> References: <4455834A.4020700@telus.net> <445EF45F.7030407@sonic.net> <445F3CE8.3000605@telus.net> Message-ID: <44604053.2060801@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > >> Some general quick thoughts: >> >> As stated before, selective 'per packet' compression has the nice advantage >> very easy to do - no need for extra buffers on the client or server side needed. >> That said, if someone is willing to write that extra code, sounds good to me. >> >> > It is simpler to do selective 'per packet', however given some tests I > did, it can easily take up to 50% more bandwidth, so I think for > compression that streams are the way to go. It's hard for me to see why compressing per packet would take 50% more bandwidth, but I suppose it could be a matter of grouping those smaller packets together. I don't know the specific test methodology used, but one point is that for real life usage, the server will often need to compress small amounts of data, just so that it gets sent to the client in a timely fashion (the server can't really wait for 6 ticks to gather a good block of compressible data - it needs to send things every tick). But in any case, doing stream compression makes sense, save for the extra work needed to do it. We also had a discussion on IRC about a separate media server (for images/sounds/whatever) - if that is in fact done, that also removes some of the issue of the server compressing data it doesn't need to compress (client would grab the images from that other server where they are precompressed or not compressed, whatever) > Well, I was thinking of allowing layering different types of streams > within eachother, however now I don't really think there is a need for > such and hence isn't worth bothering with. Ok - that is good. Otherwise, it does add a fair amount of complication - its not just recording which encapsulation methods are in use, but also the order of use (ssl inside of zlib is different than zlib inside of ssl). Supporting only a single stream type makes things much easier. > Agreed. This protocol while suitable for streams in general, isn't > suitable for switching to a stream for a specific purpose (i.e > password). At that, I'm not completely sure ssl is the best way to send > a password for more secure login, however if that is done, some sort of > per-packet would be better. And some point, it depends on how paranoid we are. But one consideration also is what external dependencies this puts in. For example, SSL is quite secure, but would require SSL on both server and client. It would probably also require some setup on the server side to properly create a SSL certificate - a self signed certificate could be created, but that also isn't quite as secure. From nicolas.weeger at laposte.net Tue May 9 04:43:03 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 9 May 2006 11:43:03 +0200 Subject: [crossfire] Modelling monsters, longer animations? Message-ID: <200605091143.03249.nicolas.weeger@laposte.net> Hello. I've been toying with the idea to do some (3d) modelling for monsters and such for Crossfire, like some are doing for CF+. Right now many (monster) animations are 4 frames long (3 frames with 1 repetition), and all I think are under 10. I was wondering about doing longer animations, like 10 frames, maybe with a higher anim speed, for monsters - make 10 frames the norm instead of the exception. If monsters are modelled, it wouldn't be too hard :) Also we could (finally) have 8 directions for monsters. What would you think? Nicolas From alex_sch at telus.net Tue May 9 07:49:29 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 09 May 2006 06:49:29 -0600 Subject: [crossfire] Steam Protocol Proposal In-Reply-To: <44604053.2060801@sonic.net> References: <4455834A.4020700@telus.net> <445EF45F.7030407@sonic.net> <445F3CE8.3000605@telus.net> <44604053.2060801@sonic.net> Message-ID: <44608FD9.3050003@telus.net> Mark Wedel wrote: >Alex Schultz wrote: > > >>Mark Wedel wrote: >> >> >> >>> Some general quick thoughts: >>> >>> As stated before, selective 'per packet' compression has the nice advantage >>>very easy to do - no need for extra buffers on the client or server side needed. >>>That said, if someone is willing to write that extra code, sounds good to me. >>> >>> >>> >>It is simpler to do selective 'per packet', however given some tests I >>did, it can easily take up to 50% more bandwidth, so I think for >>compression that streams are the way to go. >> >> > > It's hard for me to see why compressing per packet would take 50% more >bandwidth, but I suppose it could be a matter of grouping those smaller packets >together. > > I don't know the specific test methodology used, but one point is that for >real life usage, the server will often need to compress small amounts of data, >just so that it gets sent to the client in a timely fashion (the server can't >really wait for 6 ticks to gather a good block of compressible data - it needs >to send things every tick). > > The testing was done by using my pylibcfclient library that is in development, and putting hooks in for compressing received and sent data with various methods (per-packet streamed (like per packet, but data payload of a special stream packet is part of a stream), and streamed) and totaling up the data sent and received in each mode. Also, I set the compression streams to flush each packet, so smaller packets weren't being grouped together or anything. > And some point, it depends on how paranoid we are. But one consideration also >is what external dependencies this puts in. For example, SSL is quite secure, >but would require SSL on both server and client. It would probably also require >some setup on the server side to properly create a SSL certificate - a self >signed certificate could be created, but that also isn't quite as secure. > Well, the insecurity of self signed certificates is only a factor for authenticating that it is who it is. However it is still perfectly secure for, verifying it's the same client or server as before (though you can't be sure of it's identity other than as "same as before"), as well as providing secure encryption. Alex Schultz From lalo.martins at gmail.com Tue May 9 19:02:50 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 10 May 2006 08:02:50 +0800 Subject: [crossfire] Launchpad (was Re: Backup(?) CVS via darcs) References: <44592F23.4020406@real-time.com> <44598A30.5010907@telus.net> <445A9BE3.9080809@telus.net> Message-ID: Actually, forget tailor... launchpad is already set up to sync crossfire, crossfire-client and crossfire-maps from cvs to bzr. It doesn't have arch, due to an oversight, but we can set that up ourselves easily. Of course right now the syncs are a few weeks outdated, thanks to sourceforge sucking. And since launchpad only moved from Gnu Arch to bzr recently, the only one which is actually synced is crossfire-client. But the three of them are already there, and launchpad can do the hard work for us. See here: https://launchpad.net/products?text=crossfire Launchpad is Canonical's development portal thingie; it has hosting and mirroring for bzr branches, plus a simple release planning system, plus the only bug tracking system I know about that doesn't suck too much. It also has a neat i18n system to which I contributed in the beginning, but we don't care about that, since we have no i18n. I'd like to propose that we start using it for a few things. Maybe release planning is overkill, but at least the bug system is immensely better than the sf offering. And anyone with an account can host and publish a bzr branch, so this would allow us to use bzr even if the official development mainline remains in cvs. If anyone who is currently a cf developer registers a launchpad account, drop me a word by email or irc and I'll add you to the team object on launchpad. 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://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Wed May 10 01:05:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 09 May 2006 23:05:33 -0700 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <200605091143.03249.nicolas.weeger@laposte.net> References: <200605091143.03249.nicolas.weeger@laposte.net> Message-ID: <446182AD.1010302@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > I've been toying with the idea to do some (3d) modelling for monsters and such > for Crossfire, like some are doing for CF+. > > Right now many (monster) animations are 4 frames long (3 frames with 1 > repetition), and all I think are under 10. > > I was wondering about doing longer animations, like 10 frames, maybe with a > higher anim speed, for monsters - make 10 frames the norm instead of the > exception. > > If monsters are modelled, it wouldn't be too hard :) > > Also we could (finally) have 8 directions for monsters. > > What would you think? sounds good to me. I don't believe there is anything preventing that right now, other than the necessary animation frames. I don't think there was ever really a limit on the number of animations allowed for a single object. However, I think it was more just a case that most people were not going to make 40 images for a single object. From crossfire at suckfuell.net Wed May 10 02:53:17 2006 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Wed, 10 May 2006 09:53:17 +0200 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <446182AD.1010302@sonic.net> References: <200605091143.03249.nicolas.weeger@laposte.net> <446182AD.1010302@sonic.net> Message-ID: <20060510075317.GA1286@suckfuell.net> Hi! On Tue, May 09, 2006 at 11:05:33PM -0700, Mark Wedel wrote: > Nicolas Weeger (Laposte) wrote: > > [...] > > Also we could (finally) have 8 directions for monsters. > > > > What would you think? > > sounds good to me. I don't believe there is anything preventing that right > now, other than the necessary animation frames. > > I don't think there was ever really a limit on the number of animations > allowed for a single object. However, I think it was more just a case that most > people were not going to make 40 images for a single object. 10 frames \times 8 directions makes 80 images each. IIRC all those images have to be kept in memory all the time. We might end up using more memory on the frame images of one object than the 3d model itself used. As long as the client doesn't support loading only those animations that are currently needed (and caching them until a cache size in bytes is reached), this could be a problem. I wouldn't want to see the crossfire client's memory footprint exceed 500 MB (or does it already? - long time no play). Just my two cents, Jochen From elmex at ta-sa.org Wed May 10 02:52:40 2006 From: elmex at ta-sa.org (Robin Redeker) Date: Wed, 10 May 2006 09:52:40 +0200 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <200605091143.03249.nicolas.weeger@laposte.net> References: <200605091143.03249.nicolas.weeger@laposte.net> Message-ID: <20060510075240.GA2074@elmex> Hi! Here are some of the experiences i made when making models for CF+: On Tue, May 09, 2006 at 11:43:03AM +0200, Nicolas Weeger (Laposte) wrote: > Hello. > > I've been toying with the idea to do some (3d) modelling for monsters and such > for Crossfire, like some are doing for CF+. You maybe want to check the render script (in Perl) i wrote for yafray. http://cvs.schmorp.de/browse/cf.schmorp.de/Crossfire/bin/cfxmlrender?rev=1.3&view=auto It's not documented yet. It does the following: - Take a yafray xml file, remove the lights, cameras, render settings and background from the scene. - Applys a shear transformation to all objects (Shear x by 0.25 * z and y by 0.5 * z, so that if you look from above you get the same perspective as the houses in scorn have). - Next it adds 2 lights: one in the 'top-left' (if you look from above) with power 0.5 and one in the 'lower-right' with power 1. (Both slightly above the ground plane) - The camera is inserted, with a per model configurable destination pixel size and othrographic perspective, along with some finetuned focal-values. The camera looks straight from above on the model. Then a render setting is added with an output file. > I was wondering about doing longer animations, like 10 frames, maybe with a > higher anim speed, for monsters - make 10 frames the norm instead of the > exception. > > If monsters are modelled, it wouldn't be too hard :) Currrently i'm having a bad time doing animations, as the tools are just sub-optimal. First i use wings3d for modelling, it's a dream of a mesh-modelling tool. It has a steep learning curve and is way easier to use than blender. The only problem is, that it lacks animations support and the UV texture exporter for yafray is broken. Blender is the classics under the free modelling tools. But the learning curve is just a mess. It's confusing to use, and offers only few mesh-modelling functions and the parametric-modelling tools are awkward to use (as it is blender). But blender has a complete and good animation support (bone deformers, key frame animations, etc.). Currently i sometimes export the models from wings3d to wavefront .obj format (as this is the only format wings3d exports that doesn't crash blender when importing if importing it at all). The only problem after importing the .obj file(s) in blender is that blender somehow messes up the texture<->material links, but that repairable. So i end up copying the .wings model, change it, export it to yafray and render it as second frame. But this is tedious, and most of the models lack nice textures for the reason that the wings exporter is broken. But aside that: It's a great idea, and it's indeed relatively easy with a 3D model. - I mean: Compare that to pixeling the stuff in Gimp: 2 frames * 8 directions = 16 pictures to draw. And that multiplies even worse for more frames :-) > > Also we could (finally) have 8 directions for monsters. > When i made the dread, beholder and the goblins with 8 directions i noticed that the monsters move in a strage way. They only change directions when they walk. So is happens that the goblin stands right on your right side but is facing to north while hitting you. Dreads have a different movement mode, as they run away until they are ~10 tiles away, they look exactly in the opposite direction, also when attacking you. I hacked the code for the movement type of dreads, so that the monster is facing you while running away. But i guess the clean solution would have been to improve the movement code in such a way that monsters that attack you always look at you. PS: The models aren't yet in our CVS, but they will certainly be put into the CVS once i get around checking them in and writing a 'build script' that renders all models in the tree. -- elmex at ta-sa.org / robin at nethype.de / r.redeker at gmail.com Robin Redeker From pip88nl at gmail.com Mon May 8 13:08:58 2006 From: pip88nl at gmail.com (Pippijn van Steenhoven) Date: Mon, 8 May 2006 20:08:58 +0200 Subject: [crossfire] Steam Protocol Proposal Message-ID: <8c584a860605081108k3f89a3b7h403c346b0fc12f68@mail.gmail.com> Hi, just one thing about SSL streams. I suppose they would be used to transmit passwords from the client to the server? Well, if the model was changed and the password would not even be transmitted, there would be no need for such streams and the entire code would be a lot smaller than it would be with SSL streams implemented. Look at how public key authentication works. You just send a hash, the server checks whether that hash equals the one in the player file and ... and and you get the picture. Public key authentication. I am well aware of the fact that this might break compatibility but for now, Crossfire could as well support both methods using some SetupCmd option.. say "pubkeycmd". That would certainly get rid of 1) gdb backtraces containing passwords and 2) people sniffing passwords. One problem exists and that is player creation. To make player creation secure, you either do need SSL or have web-based player creation over HTTPS, as suggested by schmorp, but I am not going into further detail on that. Make up your own minds, this is my contribution to the issue. Pippijn van Steenhoven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060508/247a2d42/attachment-0001.htm From lalo.martins at gmail.com Wed May 10 06:45:02 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 10 May 2006 19:45:02 +0800 Subject: [crossfire] Modelling monsters, longer animations? References: <200605091143.03249.nicolas.weeger@laposte.net> Message-ID: On Tue, 09 May 2006 11:43:03 +0200, Nicolas Weeger (Laposte) wrote: > I've been toying with the idea to do some (3d) modelling for monsters and such > for Crossfire, like some are doing for CF+. Sounds great, but what's wrong with using the ones from CF+ too? 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://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From brenlally at gmail.com Wed May 10 18:24:42 2006 From: brenlally at gmail.com (Brendan Lally) Date: Thu, 11 May 2006 00:24:42 +0100 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: References: <200605091143.03249.nicolas.weeger@laposte.net> Message-ID: <7903f03c0605101624o460dc1b8n8b13a15bc496d072@mail.gmail.com> On 5/10/06, Lalo Martins wrote: > Sounds great, but what's wrong with using the ones from CF+ too? We can't yet see the models, until such time as they are available, the images generated from them are effectively unmaintable, and IMHO do not belong in CVS (by analogy; the images are the 'binary' that is produced by a model which is the 'source code' and we don't want to have to maintain the 'programs' without the corresponding 'source') Once the models and 'build script' that were mentioned are available to us, then I shall strongly support their inclusion. - especially if there is a nice way to render images with a series of different textures (for the different building styles for example) From mwedel at sonic.net Thu May 11 01:33:21 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 10 May 2006 23:33:21 -0700 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <20060510075317.GA1286@suckfuell.net> References: <200605091143.03249.nicolas.weeger@laposte.net> <446182AD.1010302@sonic.net> <20060510075317.GA1286@suckfuell.net> Message-ID: <4462DAB1.1050307@sonic.net> Jochen Suckfuell wrote: > > I wouldn't want to see the crossfire client's memory footprint exceed 500 MB > (or does it already? - long time no play). Each 32x32 image should take about 4k (32 * 32 * 4). There is of course some other overhead, but probably not too much. Thus, you get about 250 images/MB of memory. The 5240 images therefore take about 21 MB memory (not really true, as some images are bigger, etc). All that said, I don't see the images making a huge difference in the memory footprint. From mwedel at sonic.net Thu May 11 01:56:07 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 10 May 2006 23:56:07 -0700 Subject: [crossfire] Steam Protocol Proposal In-Reply-To: <8c584a860605081108k3f89a3b7h403c346b0fc12f68@mail.gmail.com> References: <8c584a860605081108k3f89a3b7h403c346b0fc12f68@mail.gmail.com> Message-ID: <4462E007.9090305@sonic.net> Pippijn van Steenhoven wrote: > Hi, > > just one thing about SSL streams. I suppose they would be used to transmit > passwords from the client to the server? Well, if the model was changed and > the password would not even be transmitted, there would be no need for such > streams and the entire code would be a lot smaller than it would be with > SSL streams implemented. Look at how public key authentication works. You > just send a hash, the server checks whether that hash equals the one in the > player file and ... and and you get the picture. Public key authentication. This depends on what why are trying to protect. If the concern is that people are using the same password on crossfire as other services, this works - you can't find out a users common password by looking at crossfire. Pretty much any one way method that obfuscates the password works (one way hash, etc) However, if we are looking to also make the crossfire passwords more secure, this doesn't work so well - one just grabs the hash in the player file (core file, whatever), and just hack the client to send that hash. Now true public key can be used, with the player file storing one key, and the other being transmitted. That helps in the core dump/player analysis (that one key doesn't do any good), but doesn't help out much in the case of people sniffing - you just sniff what the client is sending to the server, and once again, hack your client to send that same byte sequence. My personal thought is that starts to over engineer this - I somehow doubt there are people out their sniffing the network for crossfire passwords. Core dumps/stack traces could be made secure - store the player password in something like .pw and not in the password file itself. Thus, when a player logs in, password compared with that in that file, but once that is done, we don't need to keep the password in memory anymore. It has to be kept in memory right now so we know what to write out when saving the player. From nicolas.weeger at laposte.net Thu May 11 05:41:10 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 11 May 2006 12:41:10 +0200 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <7903f03c0605101624o460dc1b8n8b13a15bc496d072@mail.gmail.com> References: <200605091143.03249.nicolas.weeger@laposte.net> <7903f03c0605101624o460dc1b8n8b13a15bc496d072@mail.gmail.com> Message-ID: <200605111241.10614.nicolas.weeger@laposte.net> Hello. > We can't yet see the models, until such time as they are available, > the images generated from them are effectively unmaintable, and IMHO > do not belong in CVS (by analogy; the images are the 'binary' that is > produced by a model which is the 'source code' and we don't want to > have to maintain the 'programs' without the corresponding 'source') > > Once the models and 'build script' that were mentioned are available > to us, then I shall strongly support their inclusion. - especially if > there is a nice way to render images with a series of different > textures (for the different building styles for example) Actually, I'd do the following: * put generated pics in the arch/ directory * put models and scripts in a new 3dmodels or whatever directory This way, we got a clean separation: arch is the pics all ready, no supplementary required tool. 3dmodels is for people wanting to have fun with modelling (also, maybe not all pics will be modelled) Nicolas From leaf at real-time.com Thu May 11 19:24:46 2006 From: leaf at real-time.com (Rick Tanner) Date: Thu, 11 May 2006 19:24:46 -0500 Subject: [crossfire] FYI: SourceForge.net: CVS service offering changes Message-ID: <4463D5CE.8080402@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm sending this to the mailing list as an FYI - -------- Original Message -------- Subject: SUBJECT: SourceForge.net: CVS service offering changes Date: Thu, 11 May 2006 16:56:49 -0700 (PDT) From: SourceForge.net Team Greetings, You are receiving this mail because you are a project admin for a SourceForge.net-hosted project. One of our primary services, CVS, suffered a series of interrelated, critical hardware failures in recent weeks. We understand how frustrating this CVS outage must be to you and your users; however, our top priority remains preservation of the integrity of your data. The series of CVS hardware failures prompted us to expedite the deployment of planed improvements to our CVS infrastructure, drawing upon much of the knowledge that we gained from our Subversion deployment. Our improved CVS service architecture, which we plan to deploy tomorrow afternoon (2006-05-12), will offer greater performance and stability and will eliminate several single points of failure. The Site Status page (https://www.sf.net/docs/A04) will be updated as soon as the new infrastructure is rolled out. In the interim, please read the important information provided below to learn about how these changes will affect your project. Summary of changes, effective 2006-05-12: 1. Hostname for CVS service Old: cvs.sourceforge.net New: PROJECT_UNIX_NAME.cvs.sourceforge.net This change will require new working copies to be checked out of all repositories (so control files in the working copy will point to the right place). We will be updating the instructions we supply, but instructions that your team has written within documentation, etc. will need to be updated. cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/gaim co gaim would be changed to cvs -d:pserver:anonymous at gaim.cvs.sourceforge.net:/cvsroot/gaim co gaim 2. ViewCVS We are moving from ViewCVS to its successor, ViewVC. ViewVC is currently in use for our Subversion service. 3. Sync delay Old: CVS pserver, tarballs and ViewCVS provided against a separate server which is a minimum of three hours behind developer CVS. New: ViewVC will be provided against developer CVS (it will be current). CVS pserver will be provided against a secondary server (not developer server) with a maximum expected delay of two hours. Follow-up work is planned (this infrastructure takes us 80% of the way) to essentially eliminate the sync delay. 4. Read-only rsync service As a new service offering, we are now providing read-only rsync access against developer CVS. This allows projects to efficiently make on-demand backups of their entire CVS repository. All projects should be making regular backups of their CVS repository contents using this service. 5. Nightly tarball service Nightly tarball service is being dropped in lieu of read-only rsync service. Projects which currently depend on nightly tarballs for repository backups will need to begin using rsync to make a backup copy of their repository contents. We see this as a major functional improvement. For a number of reasons, tarballs have fallen out of sync with the data in the repository at times in the past few years. Tarballs required a substantial amount of additional disk, and I/O to generate. The move to read-only rsync allows backups to be produced on-demand, with an update frequency chosen by the project. 6. Points of failure In the past, developer CVS service for all projects was provided from a single host. CVS pserver service was provided from individual backend heads based on a split of the data. Under our new design, developer CVS and most of our CVS-related services are provided from one of ten CVS hosts (count subject to increase with growth). Each host is independent, and makes a backup copy of the repository data of another host (which is used to provide the pserver CVS service). Failure of a single host will impact only the availability of data on that host. Since the data is split among a larger number of hosts, the size of data impacted by an individual host outage is substantially smaller, and the time required for us to restore service will be substantially shorter. This rapid architecture change has been made possible specifically using the research we performed for our recent launch of Subversion service. We've applied our best practices, produced a substantial amount of internal documentation, and kept an eye toward maintainability. This effort has allowed us to deploy this new architecture quickly once hardware was received, and will permit us to quickly scale this service horizontally as growth and demand requires. Many other minor improvements have also been made to improve the service offering and make it less trouble-prone. The most important of which are listed above. For a full description of the new service offering, and for information on how to use the services described above, please refer to the site documentation for the CVS service after the service has been launched: https://www.sf.net/docs/E04 Thank you, The SourceForge.net Team . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEY9XOhHyvgBp+vH4RAjYoAKCK5psJPtsV+XU4nszU4tey6ww+MwCg/SD2 w/xZ6TP3mS9ia+9P/nPKXlQ= =o9Ih -----END PGP SIGNATURE----- From mwedel at sonic.net Sat May 13 02:59:58 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 13 May 2006 00:59:58 -0700 Subject: [crossfire] FYI: SourceForge.net: CVS service offering changes In-Reply-To: <4463D5CE.8080402@real-time.com> References: <4463D5CE.8080402@real-time.com> Message-ID: <446591FE.7060802@sonic.net> Here is a little script I wrote to update the repository information - in this way, you don't need to do a new checkout and then merge. cd into your CVS tree, then run 'update_rep .' to update the entries. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: update_rep Url: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060513/6d02167c/attachment.diff From pipbsd at gmail.com Sat May 13 20:09:02 2006 From: pipbsd at gmail.com (Pippijn van Steenhoven) Date: Sun, 14 May 2006 03:09:02 +0200 Subject: [crossfire] Modelling monsters, longer animations? References: <200605091143.03249.nicolas.weeger@laposte.net> <7903f03c0605101624o460dc1b8n8b13a15bc496d072@mail.gmail.com> <200605111241.10614.nicolas.weeger@laposte.net> Message-ID: > * put generated pics in the arch/ directory > * put models and scripts in a new 3dmodels or whatever directory We are currently discussing this for Crossfire+. Ideas have mainly been expressed in IRC but some are here: http://cf.schmorp.de/tracker/view.php?id=49. Our plan is to make a separate arch3d module that contains the models in .wings, .blend, .3ds, .whatever and a yafray file .xml with a cfxmlrender .xml.cfg. Either there will be a separate arch tree or the models will just reside alongside with the .png, .arc and .trs files. lib/collect.pl will step over those calling them garbage anyway. Pippijn From pipbsd at gmail.com Sat May 13 20:11:39 2006 From: pipbsd at gmail.com (Pippijn van Steenhoven) Date: Sun, 14 May 2006 03:11:39 +0200 Subject: [crossfire] Steam Protocol Proposal References: <8c584a860605081108k3f89a3b7h403c346b0fc12f68@mail.gmail.com> <4462E007.9090305@sonic.net> Message-ID: Mark Wedel wrote: > Now true public key can be used, with the player file storing one key, > and the > other being transmitted. That helps in the core dump/player analysis > (that one key doesn't do any good), but doesn't help out much in the case > of people sniffing - you just sniff what the client is sending to the > server, and once again, hack your client to send that same byte sequence. There is one thing not being thought about here, that is, that you can let the server send a random sequence of bytes to the client, let it process that and use the sequence in the server itself again to decode what the client sent. That way, you cannot sniff and resend hashes because the sent password will always be different. Pippijn From mwedel at sonic.net Mon May 15 01:23:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 14 May 2006 23:23:51 -0700 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: References: <200605091143.03249.nicolas.weeger@laposte.net> <7903f03c0605101624o460dc1b8n8b13a15bc496d072@mail.gmail.com> <200605111241.10614.nicolas.weeger@laposte.net> Message-ID: <44681E77.1050909@sonic.net> Pippijn van Steenhoven wrote: >> * put generated pics in the arch/ directory >> * put models and scripts in a new 3dmodels or whatever directory > > We are currently discussing this for Crossfire+. Ideas have mainly been > expressed in IRC but some are here: > http://cf.schmorp.de/tracker/view.php?id=49. Our plan is to make a separate > arch3d module that contains the models in .wings, .blend, .3ds, .whatever > and a yafray file .xml with a cfxmlrender .xml.cfg. Either there will be a > separate arch tree or the models will just reside alongside with > the .png, .arc and .trs files. lib/collect.pl will step over those calling > them garbage anyway. I'd tend to go with just having them in the arch tree, along side the existing images. You then get the case, however, of perhaps needing makefiles or the like to convert these images into whatever the standard format will be. A separate directory tree could also be done (3dmodels? whatever), but then it sort of needs to mirror the other arch tree so that one can find the original (if it is /a/b/c here, the source is also in /a/b/c, not /d/e/f). One other reason that perhaps having them alongside the generated images is simply to make it clear where the image comes from. I could otherwise forsee someone saying 'hmm, these images need some touch up', and touch up those images, and not be aware that those images are computer generated and that his changes will be lost if the 'source' for those is not visible. From nicolas.weeger at laposte.net Mon May 15 15:57:49 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 15 May 2006 22:57:49 +0200 Subject: [crossfire] FYI: SourceForge.net: CVS service offering changes In-Reply-To: <446591FE.7060802@sonic.net> References: <4463D5CE.8080402@real-time.com> <446591FE.7060802@sonic.net> Message-ID: <200605152257.49703.nicolas.weeger@laposte.net> Le Samedi 13 Mai 2006 09:59, Mark Wedel a ?crit?: > Here is a little script I wrote to update the repository information - in > this way, you don't need to do a new checkout and then merge. cd into your > CVS tree, then run 'update_rep .' to update the entries. Many thanks :) (just a note: i had a weird character in the $contents ?= ; line, before the = [note there are 2 blank chars]) Nicolas From nicolas.weeger at laposte.net Mon May 15 16:51:56 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 15 May 2006 23:51:56 +0200 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <44681E77.1050909@sonic.net> References: <200605091143.03249.nicolas.weeger@laposte.net> <44681E77.1050909@sonic.net> Message-ID: <200605152351.56846.nicolas.weeger@laposte.net> > A separate directory tree could also be done (3dmodels? whatever), but > then it sort of needs to mirror the other arch tree so that one can find > the original (if it is /a/b/c here, the source is also in /a/b/c, not > /d/e/f). Yes, to ease maintenance. > One other reason that perhaps having them alongside the generated images > is simply to make it clear where the image comes from. I could otherwise > forsee someone saying 'hmm, these images need some touch up', and touch up > those images, and not be aware that those images are computer generated and > that his changes will be lost if the 'source' for those is not visible. Hum, what about a small 'generated files' text file in directories, then? That would list files made from models. Of course this would add many text files around... The drawback of adding models to arch tree is that it will grow up a lot - Blender files are quite big (min 100k per file). So people will need time to get'em... Also collect script will report many junk files (scripts we can of course tweak to ignore those files ^_-) Nicolas From delbd at oma.be Tue May 16 03:24:57 2006 From: delbd at oma.be (David Delbecq) Date: Tue, 16 May 2006 10:24:57 +0200 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <200605152351.56846.nicolas.weeger@laposte.net> References: <200605091143.03249.nicolas.weeger@laposte.net> <44681E77.1050909@sonic.net> <200605152351.56846.nicolas.weeger@laposte.net> Message-ID: <44698C59.40708@oma.be> +1 for keeping models inside same repository as arches (arch/...) -1 for integrating their rendering in a Makefile process Nicolas Weeger (Laposte) wrote: > Hum, what about a small 'generated files' text file in directories, then? That > would list files made from models. Of course this would add many text files > around... > > The drawback of adding models to arch tree is that it will grow up a lot - > Blender files are quite big (min 100k per file). So people will need time to > get'em... Also collect script will report many junk files (scripts we can of > course tweak to ignore those files ^_-) > > Nicolas > This is not an issue. Map files checking out already takes long. Moreover, i see 2 kind of people requiring archetypes 1) People needing them to run server. They can simply use the already compiled arch files 2) People needing to tweak arch and / or pictures. They then probably want to have the models too. I vote for keeping models within same directory as picture. But i opt out for the idea of a Makefile to build them all. Because this would lead to lots of tweak a model make 3dmodels commit and you get a commit of lots of unchanged png. Contrary to generated textfile other places in project, there is no way for CVS i think to notice the png has not changed (no diff in binary files) and so this could lead to overbloating of cvs repository history. Better make a generating script run only on a specific model. Tchize > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From mwedel at sonic.net Wed May 17 01:07:12 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 16 May 2006 23:07:12 -0700 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <44698C59.40708@oma.be> References: <200605091143.03249.nicolas.weeger@laposte.net> <44681E77.1050909@sonic.net> <200605152351.56846.nicolas.weeger@laposte.net> <44698C59.40708@oma.be> Message-ID: <446ABD90.5040601@sonic.net> To me, the model sizes isn't that big a deal. After all, most people will only need to check out the arch tree once at most. So that initial checkout will take longer. But unless the models actually change, the time to do cvs updates shouldn't be longer. The only way to get around that is for the models to be in a completely different repository (arch3d) which seems odd to me). As for generation, not required that makefiles be used, but the method to update them needs to be pretty clear. If I have to run some command and pass it 5 options for it to do the right thing, that is hardly appropriate. That said, properly written makefiles shouldn't have any of the problems tchize mentions - it should only create new images if the model itself has a later timestamp that the image it generates. So there shouldn't be any problem with someone typing 'make models' and it generating all new images - it should only generate those out of date, which is what should happen. That said, CVS does have timing issues - if the check out order isn't write, the makefiles can thing the images are out of date. However, any update mechanism potentially has that problem - the model looks newer than the images. Slightly more complex makefile would do something like 'if out of date, generate as png.new, compare with old png, if different, mv png.new to png, else remove png.new' The only problem there is that the script will keep trying to regenerate the image because it will think it is out of date. And if you do a 'touch old_image.png', cvs will think it is different and want to commit it (note that this isn't an issue related to binary vs text files - cvs commit doesn't look at contents, it just looks at the date stamp) From tchize at myrealbox.com Wed May 17 03:29:09 2006 From: tchize at myrealbox.com (Tchize) Date: Wed, 17 May 2006 10:29:09 +0200 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <446ABD90.5040601@sonic.net> References: <200605091143.03249.nicolas.weeger@laposte.net> <44681E77.1050909@sonic.net> <200605152351.56846.nicolas.weeger@laposte.net> <44698C59.40708@oma.be> <446ABD90.5040601@sonic.net> Message-ID: <446ADED5.8050305@myrealbox.com> Mark Wedel wrote: > > That said, CVS does have timing issues - if the check out order isn't write, > the makefiles can thing the images are out of date. > That's what i had in my mind > note that this isn't an issue related to binary vs text files - cvs commit doesn't look at > contents, it just looks at the date stamp) > This is because, for text files, a diff is done for the storage on server and if the diff show no difference (empty diff) , the server drops the commit of this file (there is even a specific server or client message for this). This is to prevent commit of files which have changed and then restored to original by editor (like add a function, then decide it's finally better to put this function in another .c file). This is even more powerfull when used in conjunction with the ignore indentation changes flag :) Personally, i prefer a script you run manually. From nicolas.weeger at laposte.net Wed May 17 16:43:56 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Wed, 17 May 2006 23:43:56 +0200 Subject: [crossfire] Modelling monsters, longer animations? In-Reply-To: <200605091143.03249.nicolas.weeger@laposte.net> References: <200605091143.03249.nicolas.weeger@laposte.net> Message-ID: <200605172343.56380.nicolas.weeger@laposte.net> If anyone wants to have fun to my awful drawing skills, just check http://nicolas.weeger.free.fr/article.php3?id_article=12 for a cannon mockup :) Nicolas From mwedel at sonic.net Thu May 18 00:49:42 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 17 May 2006 22:49:42 -0700 Subject: [crossfire] server commit for map2 support. Message-ID: <446C0AF6.3040604@sonic.net> I just committed the code that adds the map2 protocol command to the server. I played around with it quite a bit and didn't notice anything odd. A few worthy notes however: 1) Support for the original map command was removed. Clients as of 1.2 (or thereabouts) have support for the map1 command, so it shouldn't effect much. Rather than drop the connection to a client that doesn't request decent map support, a message is instead printed out. I decided to do this in case any scripts were out there that didn't care about map data and thus never did a 'setup map1' - I thought that could lead to a connect, do setup, get bumped, connect, etc cycle. Interestingly enough, other than not being able to see anything, the server should still let you (or the bot) play in this case, just lacking any map information. So for bots that just watch messages or other events, this could actually save them a little bandwidth. 2) the map2 has support for 10 layers. However, compared to the old 3 layer method where it tried to find something to fill each of those 3 layers, different layers are well defined to hold specific data (objects, monsters, etc). So you will probably never see all 10 layers filled with something at the same time. But you can pretty easily see 5 or 6 layers filled (stand on floor with a sign, drop 3 objects, and have someone cast a spell over you :) One of the main reasons for doing this is that one of the problems with the old client is objects shifting layers - this caused more a problem with big images and whether they should or should not be erased. The old portion of 3 layers in the map structure is removed. Instead, in the map1 draw code, it looks at the 10 objects and figures out which are visible and thus which to draw. This is probably a little bit more cpu intensive than the old method. 3) the map2 protocol adds support for clients to handle map animations. On my test server, I did the ocean spaces and the fountains and it works just fine - I'll probably modify more archetypes. My thought for the first group of objects are those that are always the same speed and never change (ocean, fountains, grass, etc). With the client being able to handle the client animation, there is now no need for these objects to have any object speed. Removing speed from these objects is likely to free up a fair amount of server load. The one problem with doing so is that clients not using the map2 protocol won't see these objects being animated anymore. My personal thought is that this isn't that big a deal - the animation of these objects is more window dressing than anything important, and also if people do care, perhaps that would speed them up to updating their client. Thoughts/comments? From mwedel at sonic.net Thu May 18 00:59:32 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 17 May 2006 22:59:32 -0700 Subject: [crossfire] 64 bit crossfire musings. Message-ID: <446C0D44.5030903@sonic.net> Having recently updated my computer to an athlon 64, this creates some issues for crossfire. Specifically, on 32 bit, sizeof(long)=4, sizeof(long long)=8. On 64 bit, sizeof(long)=8, sizeof(long long)=8 This pretty much means the use of the 'long' type most anywhere in crossfire is incorrect, especially if that variable is getting used in a 32 bit context (example being if that long is being passed in to SockList_Addint() - that would be fine on 32 bit systems, not necessarily good on 64 bit) On while long and long long are the same size on my system, it does seem that gcc does care that %ld and %lld be used correctly. I think the fix there is to change the global.h so move the sizeof_long_long check before the sizeof_long check, so that on x86_64, a uint64 is still defined as a unsigned long long. The other more portable approach would be to define the format strings, eg: #define UINT64_FMT "%ulld" #define SINT64_FMT "%lld" (or %ld, or for windows, %I64 I think) - that would necessitate change everyplace that uses those long formats, but that may not be that many. Comments/thoughts/suggestions? From wim-cf at villerius.nl Thu May 18 03:34:25 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Thu, 18 May 2006 10:34:25 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: References: <1143480087.14079.216.camel@localhost.localdomain> Message-ID: <1147941265.3001.33.camel@localhost.localdomain> On Tue, 2006-04-11 at 21:21 +0100, Anton Oussik wrote: > To those unfamiliar with it, shadow alchemy generally involves finding > hash collisions for the recipes, fooling the alchemy code into > thinking you are doing something else entirely. Since the hashing > function is (on purpose) very weak, there is no easy way of making > shadow alchemy impossible short of entirely changing the way > traditional alchemy works. It is currently hard enough to discourage > most people though (thanks to some safeguards in the code). For most > purposes, however, it currently does what dynamic alchemy will do, but > without the much needed game balancing, and very scarce documentation. AFAIK shadow alchemy is indeed in desperate need of game balancing and since it is by no means documentated (except that it's written 'in the code') it is almost never practised (anymore). At least on MF, I know no active players that do anything with it. (Are there any active players anyway?) Perhaps I could even put it this way: because shadow alchemy is undocumented (and almost unknown) there is a request for dynamic alchemy! > I like your idea about dynamic alchemy, but creating a resistance > table seems like a lot of work, and so does messing with the arches. > Instead, why not make a semi-random roll on what to add/subtract, > partially based on the hash value of the ingredient? This means that > only the alchemy.c file will need changing, and dynamic alchemy will > have a much better chance of actually happening (+working). That would be very interesting, the only question is how to make a reasonable guess. It would be kind of weird if a Vampire's heart gives resist_fire bonus. I'm terribly afraid that it has to be documentend (one way or the other) what bonusses an item can give, but that could be my ignorance :) If you (or someone else) has an idea to make this suggestion work, I'd be happy with it. From wim-cf at villerius.nl Thu May 18 03:34:22 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Thu, 18 May 2006 10:34:22 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <4428DB11.1050101@sonic.net> References: <1143480087.14079.216.camel@localhost.localdomain> <4428DB11.1050101@sonic.net> Message-ID: <1147941262.3001.32.camel@localhost.localdomain> First of all, apologize for not replying before, I guess you almost forgot what the proposal was about - so did I. ;-) A quick summary: Dynamic Alchemy is the art of transferring magical powers (bonusses) from one object to another. It is not yet clear how the magical powers travel. There are at least two proposals. 1: mark an item as receiving object. 2: they flow from low to high. Due to this unusual direction, items with low magical value cannot be used to enchant to infinity. All items have an upper limit, above which they are useless. A dragon steak might raise (in several steps) the fire resistance from an object to e.g. +30, but not any higher. To make it +50, better stuff is needed (ancient red dragon's steaks) Also, it is not defined what 'magical powers' are. In principle, it is not limited to anything. The idea is that you can use alchemy without predefined results - and without fixed ingredients. Anyone who wants to know more is invited to read the message that opened the discussion - sent on March 27 2006. you wrote: Mark Wedel > 1) The idea is interesting. However, like most such proposals, > balance has to be maintained - if I can take a couple ancient red > dragon steaks and get mithril chain resist fire +90, the case can be > made that that is a bit too power. So true. for resist fire+90 one would need more than just ancient red steaks. Defining a max_resistance in a table (or the arches) would prevent this can happen. In the formula I suggested I included a factor (current_resistance - max_resistance) which is the upper limit of possible improvement for a particular source. Thus if an ancient red dragon's steak is defined to give at most +50 fire resistance, it will never ever add more fire resistance using these steaks. For sure, this value of 50 is an arbitrary choice, balancing issue's should settle the real value. > 2) You mention where to store information about alchemical > improvements, and state your preference for a table instead of the > arches. I'd say arches are the right place - a large table is just > unwieldy, and unlikely to get updated > The other point is that if anything, the more recent push has been to > get rid of files in the lib directory and put that into archetypes. OK, that's fine too. The main reason to prefer a large table was the initial work that is needed to change lots of arche files, that I'm uncommon with them and that in the beginning a lot of things need some tweaks for balancing purposes - which is easier with a 'huge table'. Anyway, I would say that it's not up to me to make such a decision. > 3) Other things that could be added: hp/sp/grace regen, sustenance. > Bonus movement types (flying, swimming, etc). This last one is > trickier because it is really an all or nothing type of thing (either > the item lets you fly, or it doesn't). An unrelated but perhaps > interesting improvement would by duration items. Eg, this object will > let you fly for up to 1000 ticks. Then, for each tick it doesn't fly, > it recharges 1 tick of duration. In that model, partial movement types > make sense - this object lets you fly, but right now, only for 20 > ticks before it needs to rest - further improvements increase the > duration. Doing this wouldn't be that far off from the rod code. I see no reason why these couldn't be added - as long as the item remains in balance. About movement types, I cannot exactly grasp how a platemail could give the ability to swim, my first guess would be it gives a 'dive' (rather: sink) ability. Nevertheless, magic is magic, so why not euh? I like the idea of temporary giving an ability, but what do you do with a swiming player that looses his abiltiy to swim? Unless boots of levitation become very rare, nobody will add a flying ability to their equipment - you can't thrust it. > 4) In terms of stats - they are sort of like movement type - either > you add a stat point or don't. However, the key-value lists could be > used to hold fractional improvements. So each improvement gets you > say 0.1 of a point - you could in fact use similar logic to your > resistance improvement idea. Thus, it could a bunch of objects to > improve a stat. Or the whole stat-thing should be redesigned to allow stats to grow into a few hunderd ;-) This requires a lot of work - all items should be updated. (And I think it's quite a different discussion at all.) A problem with the approach you suggest is perhaps that stats are stored as ints (I assume). I have no clue if it is possible to change that behaviour. > 5) Direction of resistance - if prepare weapon scroll is used, as > said, that solves the problem. However, as one of the potential bad > effects, maybe it does reverse. One problem with 'low to high' is > that if you are starting with something relatively mundane you want to > improve, that is unpredictable. Lets suppose for some reason you just > want to start with a simple +1 sword. That could be low. Yes, but then first start improving it with other low lvl items. If you think this is really a problem, then perhaps make a scroll that increases the magic of an item. This doesn't have to be a prepare item scroll, just an 'increase magic' scroll. > However, I think that given crossfire is multiplayer, binding improved > objects to players isn't a good idea. I should be able to create some > cool stuff for a friend - that will help things IMO than everyone > having their own stash. It also means that not everyone has to be an > alchemists - a few powerful player alchemists in the town could > possibly make pretty good business improvement objects for other > players. However, one could perhaps change the enchant item scrolls - > it just marks the object for improvement, but doesn't tie it to the > player. To some lvl of improvement this is fine, but just like some items are god-given to prevent trade in them (WDSM, cloak of magic resistance), highly enchanted armour/... should (I think) not be traded for much the same reasons. > 6) I think even some more dynamic aspects are needed. For example, > you can't really enumerate the normal rings - rings have their > resistances added in the treasure code - there is no way to say a ring > of str +1 is this archetype. So you need some way to say 'if this is a > ring, examine what properties it has and choose one for dynamic > alchemy'. Perhaps some for a large majority of food items. Mmm, so rings are a complicating factor? As long as these values are known, it shouldn't be a big problem, I guess. I wonder, does this problem arise for some items as well? A shining dragon scale mail for example is a modified dragon scale mail and I don't know if it's a different arch or not. Is it possible to extract properties of genuine (unmodified by anyone) objects from the item itself (without using the arch-files)? If so, that is perhaps the way to go. > One thought on this is that for a baseline, the object can't improve > the object any more than it grants. <...> That does make sense. It is fully in line with the way I would like to threat food items. I think stats are a bit different. It should be possible to improve a ring with Str+2 with a ring Str+1. > This does get interesting if you have a ring like 'resist fire +20, > resist cold -20'. Can resistances (or other things) get drained away? > Does the code try to optimize for improvements? Well... that would be very interesting. It depends on how we define negative resistances. Is this the absense of magical powers, or the existence of bad power? In the first case, it is easily fixed by filling the gaps. I doubt if it makes sense to say that negative resistance is absense of bad magical power, an item with no modifiers does not have any magical power and it has no negative anything. Besides, 'evil magic' does nicely explain why some items are cursed. To remove bad powers is hard (gamewise). Perhaps we could invent items that attract bad powers. But maybe it's easier to reuse existing ideas and say that negative resistances (etc) reduce the upper limit. E.g. if the max resistance that any object can have is 90, an item with default cold -30 cannot be enhanted past resist_cold +60 (just like the current resistance calculation for players works now). > That also raises the other interesting point: > Suppose I have plate armor resist cold -20. Can I transfer away that > resist cold -20 to just some other object, or is the only way to get > rid of it is via resist cold + objects? > I bring that point up because that could be used to explain why there > are items with negative resistances - they were used to get rid of the > undesirable aspects of an otherwise good object. Isn't this a little circular? "There are objects with negative resistances because they are used to remove negative resistances form objects." I think we should change it to "There are objects with negative resistances because very powerful achemists where capable to create power and anti-power from nothing to create good items. The anti-power went into the thing with negative resistance. You are not as good as they where, therefore you cannot use their tricks. But you can transfer anti-power from one object to another." From leaf at real-time.com Thu May 18 16:47:31 2006 From: leaf at real-time.com (Rick Tanner) Date: Thu, 18 May 2006 16:47:31 -0500 Subject: [crossfire] Crossfire Wiki offline Message-ID: <446CEB73.0@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Crossfire Wiki will be offline for the next few days due to unplanned maintenance (AKA: borked dokuwiki upgrade) I'll post again when the wiki is back online. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEbOtzhHyvgBp+vH4RArJeAKDknxraIlqZ8ZfDKk51dZlBqy9OYACfRzqX 4mBqkjqyHiWmckn2H+crw8Q= =cr+3 -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Thu May 18 17:37:41 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 19 May 2006 00:37:41 +0200 Subject: [crossfire] 64 bit crossfire musings. In-Reply-To: <446C0D44.5030903@sonic.net> References: <446C0D44.5030903@sonic.net> Message-ID: <200605190037.41568.nicolas.weeger@laposte.net> Hello. > Having recently updated my computer to an athlon 64, this creates some > issues for crossfire. I'm under an AMD64 since end of january, and didn't see any specific Crossfire issue. Ok, I don't run a local server, or play intensively :) There are some gcc warnings now and then (about printf formats mostly), though. But I think we are already doing the ? right ? thing by having uint64 & such types. Doing as you suggest would finish cleaning the potential issues, and it's probably a good thing to do :) Nicolas From nicolas.weeger at laposte.net Thu May 18 17:39:25 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 19 May 2006 00:39:25 +0200 Subject: [crossfire] server commit for map2 support. In-Reply-To: <446C0AF6.3040604@sonic.net> References: <446C0AF6.3040604@sonic.net> Message-ID: <200605190039.25403.nicolas.weeger@laposte.net> > I just committed the code that adds the map2 protocol command to the > server. I played around with it quite a bit and didn't notice anything odd. Great! Thanks for the work :) > One of the main reasons for doing this is that one of the problems with > the old client is objects shifting layers - this caused more a problem with > big images and whether they should or should not be erased. Yes, those issues aren't fun to handle, I remember many bugs over this :) Now maybe we'll be able to merge all archetype image parts into one big image, finally! > The one problem with doing so is that clients not using the map2 protocol > won't see these objects being animated anymore. My personal thought is > that this isn't that big a deal - the animation of these objects is more > window dressing than anything important, and also if people do care, > perhaps that would speed them up to updating their client. Maybe we could have a transitional period, like a few months with still the speed, to let clients be upgraded? My 2 cents of ? Nicolas From alex_sch at telus.net Thu May 18 22:44:45 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 18 May 2006 21:44:45 -0600 Subject: [crossfire] server commit for map2 support. In-Reply-To: <446C0AF6.3040604@sonic.net> References: <446C0AF6.3040604@sonic.net> Message-ID: <446D3F2D.3090808@telus.net> Mark Wedel wrote: > > >2) the map2 has support for 10 layers. However, compared to the old 3 layer >method where it tried to find something to fill each of those 3 layers, >different layers are well defined to hold specific data (objects, monsters, >etc). So you will probably never see all 10 layers filled with something at the >same time. But you can pretty easily see 5 or 6 layers filled (stand on floor >with a sign, drop 3 objects, and have someone cast a spell over you :) > > One of the main reasons for doing this is that one of the problems with the >old client is objects shifting layers - this caused more a problem with big >images and whether they should or should not be erased. > > I'm a bit concerned about this. I'm not sure that simply adding more layers is the real fix to the objects shifting layers, simply a workaround. I'm not completely sure what the proper fix would be though, however perhaps a proper fix would be arbitrary layering, not limited except by how many a server is configured to send and limits on some variables. A possible implementation of "arbitrary layering" would be by sending the layer as where each is an bit signed value. The server would allocate by majorlayer starting at 0, to insert below majorlayer 0, it goes into the negatives, above into the positives, and for in between two already allocated layers, it starts using the minorlayer values like a decimal place. Please note, I don't endorse my particular proposal of "arbitrary layering", but that some form of "arbitrary layering" would be the proper fix to the above problem. Alex Schultz From mwedel at sonic.net Fri May 19 00:17:32 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 18 May 2006 22:17:32 -0700 Subject: [crossfire] 64 bit crossfire musings. In-Reply-To: <200605190037.41568.nicolas.weeger@laposte.net> References: <446C0D44.5030903@sonic.net> <200605190037.41568.nicolas.weeger@laposte.net> Message-ID: <446D54EC.7090502@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > >> Having recently updated my computer to an athlon 64, this creates some >> issues for crossfire. > > I'm under an AMD64 since end of january, and didn't see any specific Crossfire > issue. Ok, I don't run a local server, or play intensively :) > > There are some gcc warnings now and then (about printf formats mostly), > though. > > But I think we are already doing the ? right ? thing by having uint64 & such > types. > > Doing as you suggest would finish cleaning the potential issues, and it's > probably a good thing to do :) Yes - I doubt there are any real potential issues. That said, I did change the pticks type from a long to a uint32, simply because that is now sent to the client. But the other issue is more that compiling spews out a fair number of warnings, and the basic problem is that if too many warnings are generated, people just ignore them, and there could be valid issues. From mwedel at sonic.net Fri May 19 00:37:39 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 18 May 2006 22:37:39 -0700 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <1147941262.3001.32.camel@localhost.localdomain> References: <1143480087.14079.216.camel@localhost.localdomain> <4428DB11.1050101@sonic.net> <1147941262.3001.32.camel@localhost.localdomain> Message-ID: <446D59A3.8040703@sonic.net> Quick thoughts: 1) I'd prefer a way to say what item I want improved, vs it improving the strongest. this is more an issue for the first improvements most likely. Or if it is very clear how it decides what is the more powerful object (item power) that may be reasonable, except you have 2 objects with power 0. 2) Limiting the improvement of the target item based on the first item probably isn't good. In the case of resistances, one can find items that have very high resistances, but these can not be directly applied to the player or have a limited duration (think of the potions here). If I can take that potion of fire resistance (90% resistance) and apply it to a sword or other permanent item, that would make things way out of whack. Even 75% fire reistance on an item may be too powerful. This is more a case if the player has a mechanism for making those items. While there are some good items out there right now, there are some effectively limitations because they would go on the same place on the body (dragon plate mail gives good protection, but you can only wear one suit of armor at once). If I can make a hat, boots, gloves, belt, etc of fire resistance, many limitations may be easily overcome (OTOH, there really isn't anything that prevents those items from showing up in maps.) 3) I'd also think it is nice for items improved not to be tied to the player as previously state. However, I was thinking that what could be done is that based on the power of the item, there is a random chance it becomes tied. In this way, a player could make items for others, but not really powerful ones. That said, IMO, the need to make some objects god given is no longer relevant with the item power code. At one point, I think that was to make it so that you couldn't give really good stuff to low level players. While item_power doesn't prevent that gift, it effectively prevents the low level character from using it. IMO, if we really want more multi player cooperation and interaction in crossfire, we really shouldn't limit what players can trade, etc. 4) Stats are currently ints. Changing it so that the max value is much higher is IMO not a worthwhile task. They could probably be changed to floats with a lesser amount of work. Another approach is the mimicing of floats via random numbers. If that item should really improve it by .1, you make a random roll with a 10% chance of it increasing it, the rest, it does nothing. For alchemy, this could be good enough, and adds some luck and 'oh cool, it worked this time' factor. 5) For most custom objects (white dragon scale armor) there is no way to know if it has been modified from the normal one. The only thing you can really find is if it has been modified from the archetype, but lots of things on maps are already modifications from an archetype (almost all generated treasure is in fact). From mwedel at sonic.net Fri May 19 00:40:42 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 18 May 2006 22:40:42 -0700 Subject: [crossfire] server commit for map2 support. In-Reply-To: <200605190039.25403.nicolas.weeger@laposte.net> References: <446C0AF6.3040604@sonic.net> <200605190039.25403.nicolas.weeger@laposte.net> Message-ID: <446D5A5A.6060207@sonic.net> Nicolas Weeger (Laposte) wrote: >> The one problem with doing so is that clients not using the map2 protocol >> won't see these objects being animated anymore. My personal thought is >> that this isn't that big a deal - the animation of these objects is more >> window dressing than anything important, and also if people do care, >> perhaps that would speed them up to updating their client. > > Maybe we could have a transitional period, like a few months with still the > speed, to let clients be upgraded? To enable client side animation, the objects need to be updated with the flag_client_animate value. As of now, animations with map2 are handled just as before - the server has to send new image info each time the object changes. So the client really isn't getting any benefit. My plan is to go through and modify appropriate arches so that client does handle their animation. It is of course to make all the changes at once (add flag, remove speed) then go through once adding the flag, and 2 months from now going through and removing the speed value. Plus, experience sort of shows that 'do this later' type of thing often doesn't happen. From mwedel at sonic.net Fri May 19 00:54:31 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 18 May 2006 22:54:31 -0700 Subject: [crossfire] server commit for map2 support. In-Reply-To: <446D3F2D.3090808@telus.net> References: <446C0AF6.3040604@sonic.net> <446D3F2D.3090808@telus.net> Message-ID: <446D5D97.3080005@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > >> >> >> 2) the map2 has support for 10 layers. However, compared to the old 3 layer >> method where it tried to find something to fill each of those 3 layers, >> different layers are well defined to hold specific data (objects, monsters, >> etc). So you will probably never see all 10 layers filled with something at the >> same time. But you can pretty easily see 5 or 6 layers filled (stand on floor >> with a sign, drop 3 objects, and have someone cast a spell over you :) >> >> One of the main reasons for doing this is that one of the problems with the >> old client is objects shifting layers - this caused more a problem with big >> images and whether they should or should not be erased. >> >> > I'm a bit concerned about this. I'm not sure that simply adding more > layers is the real fix to the objects shifting layers, simply a > workaround. I'm not completely sure what the proper fix would be though, > however perhaps a proper fix would be arbitrary layering, not limited > except by how many a server is configured to send and limits on some > variables. A possible implementation of "arbitrary layering" would be by > sending the layer as where each is an or 8, not sure> bit signed value. The server would allocate by > majorlayer starting at 0, to insert below majorlayer 0, it goes into the > negatives, above into the positives, and for in between two already > allocated layers, it starts using the minorlayer values like a decimal > place. > Please note, I don't endorse my particular proposal of "arbitrary > layering", but that some form of "arbitrary layering" would be the > proper fix to the above problem. The change I made should greatly reduce, and perhaps, eliminate the layer shifting problem. The main (only) places where big images show up right now are buildings (and some landscape, like mountains) and monsters. There are not any big objects that the player picks up, nor any big flying objects (eg, spells, rocks, bullets). I believe even with the old code, there was never a problem with the building/mountains (no pick) objects, because those would always be sent as the object right above the floor, and you wouldn't get a case of a new object between it and the floor showing up. The problem was really the monsters. In the old code, if we have a big open area of sand, layer 1 would all be sand. The monster would be on layer 2. However, if that monster now steps on a space with something else on it (sword, staircase, etc), it would move up to layer 3, with the sword being level 2. When it steps off, it goes back to level 2. This won't happen any more. living objects are defined to be on level 6 and 7. So the only thing that would cause it to change layers is if it steps on top of something with another living object (which can't currently happen under normal circumstances). There is also some need of having hard layers. for example, if available, you always want to send the floor. And the building for the matter, as well as monster or player. you just can't send the top 4/8/20 objects and necessarily call it done. So if we are going to check for specific layers that we always want to send, I think it makes to store them based on that stacking. From tchize at myrealbox.com Fri May 19 03:46:16 2006 From: tchize at myrealbox.com (Tchize) Date: Fri, 19 May 2006 10:46:16 +0200 Subject: [crossfire] server commit for map2 support. In-Reply-To: <446D5D97.3080005@sonic.net> References: <446C0AF6.3040604@sonic.net> <446D3F2D.3090808@telus.net> <446D5D97.3080005@sonic.net> Message-ID: <446D85D8.1050907@myrealbox.com> Mark Wedel wrote: > Alex Schultz wrote: > > > This won't happen any more. living objects are defined to be on level 6 and > 7. So the only thing that would cause it to change layers is if it steps on top > of something with another living object (which can't currently happen under > normal circumstances). > > I *think* traps are living objects. And monsters / players can walk on traps. From nicolas.weeger at laposte.net Fri May 19 17:15:05 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 20 May 2006 00:15:05 +0200 Subject: [crossfire] 64 bit crossfire musings. In-Reply-To: <446D54EC.7090502@sonic.net> References: <446C0D44.5030903@sonic.net> <200605190037.41568.nicolas.weeger@laposte.net> <446D54EC.7090502@sonic.net> Message-ID: <200605200015.05307.nicolas.weeger@laposte.net> > But the other issue is more that compiling spews out a fair number of > warnings, and the basic problem is that if too many warnings are generated, > people just ignore them, and there could be valid issues. Latest tests i've done show only 2 warnings for the whole compilation, and only for command_kick casting a const char* to a char* (this one is harmless). Or maybe i'm using wrong compilation flags :) But yes, warnings should be cleaned. Also, I'm thinking of adding a whole lot of asserts here and there, some day (would probably need to change for instance the create command to not be able to generate invalid objets, else asserts would crash). Nicolas From mwedel at sonic.net Fri May 19 23:50:21 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 19 May 2006 21:50:21 -0700 Subject: [crossfire] 64 bit crossfire musings. In-Reply-To: <200605200015.05307.nicolas.weeger@laposte.net> References: <446C0D44.5030903@sonic.net> <200605190037.41568.nicolas.weeger@laposte.net> <446D54EC.7090502@sonic.net> <200605200015.05307.nicolas.weeger@laposte.net> Message-ID: <446EA00D.20403@sonic.net> Nicolas Weeger (Laposte) wrote: >> But the other issue is more that compiling spews out a fair number of >> warnings, and the basic problem is that if too many warnings are generated, >> people just ignore them, and there could be valid issues. > > Latest tests i've done show only 2 warnings for the whole compilation, and > only for command_kick casting a const char* to a char* (this one is > harmless). > Or maybe i'm using wrong compilation flags :) I use -Wall, which is probably excessive, but does tend to catch some other errors. > > But yes, warnings should be cleaned. > Also, I'm thinking of adding a whole lot of asserts here and there, some day > (would probably need to change for instance the create command to not be able > to generate invalid objets, else asserts would crash). Note that IMO, asserts should really be used to check the data of passed in functions from other functions. For data that is passed in from user input, asserts that cause crashes probably isn't the correct approach - instead, if the data is bad, the server should print a message to the player. Right now, I think a problem is a lot of the DM code really didn't do much data checking of what is being passed in. From mwedel at sonic.net Sat May 20 00:11:00 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 19 May 2006 22:11:00 -0700 Subject: [crossfire] server commit for map2 support. In-Reply-To: <446D85D8.1050907@myrealbox.com> References: <446C0AF6.3040604@sonic.net> <446D3F2D.3090808@telus.net> <446D5D97.3080005@sonic.net> <446D85D8.1050907@myrealbox.com> Message-ID: <446EA4E4.3090307@sonic.net> Tchize wrote: > Mark Wedel wrote: >> Alex Schultz wrote: >> >> >> This won't happen any more. living objects are defined to be on level 6 and >> 7. So the only thing that would cause it to change layers is if it steps on top >> of something with another living object (which can't currently happen under >> normal circumstances). >> >> > I *think* traps are living objects. And monsters / players can walk on > traps. Traps definately are not living objects (and pretty much all runes do have no_pick). Thus, it is true, no_pick objects could change layers. I don't remember the details of the layer swapping - I seem to recall it was when a portion of a big image was not in sight or the like. I'd have to look at the map2 code again, but one issue is we need to send the big image, and would use the layer from the first visible space as its real layer. So to be honest, I don't know if the problem is completely solved or not. From nicolas.weeger at laposte.net Sat May 20 02:55:00 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 20 May 2006 09:55:00 +0200 Subject: [crossfire] 64 bit crossfire musings. In-Reply-To: <446EA00D.20403@sonic.net> References: <446C0D44.5030903@sonic.net> <200605200015.05307.nicolas.weeger@laposte.net> <446EA00D.20403@sonic.net> Message-ID: <200605200955.00598.nicolas.weeger@laposte.net> > I use -Wall, which is probably excessive, but does tend to catch some > other errors. IMO that should be included in the debug build of server. > Note that IMO, asserts should really be used to check the data of passed > in functions from other functions. *nods* > For data that is passed in from user input, asserts that cause crashes > probably isn't the correct approach - instead, if the data is bad, the > server should print a message to the player. Right now, I think a problem > is a lot of the DM code really didn't do much data checking of what is > being passed in. That is the problematic part. I could use 'create' to make an item without any spell, or use patch to put a negative x value, or something like that. Thus the DMs commands, if we add asserts, will have to be hardened to prevent weird things. I had the idea of extending the create command (via a plugin) to correctly check everything before creating an item - so for instance you say "i wanna start creating a rod", code says "ok, now you're missing: level, spell", and you couldn't actually create the item before everything is alright. Nicolas From nicolas.weeger at laposte.net Sat May 20 07:40:46 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 20 May 2006 14:40:46 +0200 Subject: [crossfire] New bot flag Message-ID: <200605201440.46882.nicolas.weeger@laposte.net> Hello. I just added a bot flag, for players. To activate it, a client just has to send "bot 1" (or anything atoi will recognize as non zero) through the "setup" command. When activated, this flag will make the player have a proeminent "[BOT]" in "who" output, and more important this player will not be counted in statistics sent to metaserver. This lets us send only relevant information to metaserver, real players :) Nicolas From fuchs.andy at gmail.com Sat May 20 14:06:00 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 20 May 2006 15:06:00 -0400 Subject: [crossfire] New bot flag In-Reply-To: <200605201440.46882.nicolas.weeger@laposte.net> References: <200605201440.46882.nicolas.weeger@laposte.net> Message-ID: On 5/20/06, Nicolas Weeger (Laposte) wrote: > Hello. > > I just added a bot flag, for players. > > To activate it, a client just has to send "bot 1" (or anything atoi will > recognize as non zero) through the "setup" command. > > When activated, this flag will make the player have a proeminent "[BOT]" in > "who" output, and more important this player will not be counted in > statistics sent to metaserver. Both will probably help players a lot, once the bots adapt the flag. > This lets us send only relevant information to metaserver, real players :) Unfortunately, some servers seem to purposely boost their player count, so new players will connect to their server. This IMO should be taken care of at the metaserver. -- Andrew Fuchs From fuchs.andy at gmail.com Sat May 20 14:24:38 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 20 May 2006 15:24:38 -0400 Subject: [crossfire] server commit for map2 support. In-Reply-To: <446EA4E4.3090307@sonic.net> References: <446C0AF6.3040604@sonic.net> <446D3F2D.3090808@telus.net> <446D5D97.3080005@sonic.net> <446D85D8.1050907@myrealbox.com> <446EA4E4.3090307@sonic.net> Message-ID: I would like to ask a few questions in terms of making maps and archetypes. There are currently archetypes for chandeliers, would it require more code to make these appear above players? Same for elevated parts of towers, and the back of some buildings. Second, what are the chances of some sort of vertical tiling being introduced? (even though this is unlikely) -- Andrew Fuchs From mwedel at sonic.net Sun May 21 00:12:50 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 20 May 2006 22:12:50 -0700 Subject: [crossfire] server commit for map2 support. In-Reply-To: References: <446C0AF6.3040604@sonic.net> <446D3F2D.3090808@telus.net> <446D5D97.3080005@sonic.net> <446D85D8.1050907@myrealbox.com> <446EA4E4.3090307@sonic.net> Message-ID: <446FF6D2.6040708@sonic.net> Andrew Fuchs wrote: > I would like to ask a few questions in terms of making maps and archetypes. > > There are currently archetypes for chandeliers, would it require more > code to make these appear above players? For chandeliers, if fly is set on them, they will appear above players, as the fly layer is above the player/monster layer. > Same for elevated parts of > towers, and the back of some buildings. If the object does not have merged images (is still 2 or 4 or whatever separate images), then the fly trick would work for those. But then, I'm not sure if the player would be able enter them, and when the player is on a space, they would appear above the player in the look window. With a little work, it would be possible to add something like 'layer ...' to objects which denote which layer they should be drawn on, but not affect the actual layer in terms of the look window. For combined images, this doesn't work, as the layer that that image appears on is only sent once for the head. The draw logic could be changed to make it work, but then it would draw all big images the same way. So while tall towers should be drawn in front (on top) of the player, that probably isn't the right thing to do for things like the coliseum (the change in draw logic would basically be draw all objects on space x,y, then all objects on x+1,y ... and for big images, you do the draw once at the head location, so it then obscures stuff behind it). The only way I can really see for fixing that is to add some object attribute to denote the 'rear' portion of the object should be drawn at a higher layer. But that starts to make things messier on the client side (do you resolve that layer at draw time?). Plus, this doesn't work as well for the opengl which draws the entire big image at one time and not pieces (but that could be changed). And then you start to get the issue of what about a 3x4 image. Does it only obscure the player for the top half? The top 3 rows? Can a universal flag cover those? The other possibility is to send the image for every space it appears on and not send only the head, but do send an offset (eg, here is a shop, but the head is +1,+1 from this space). This uses more bandwidth, but then would allow the layer to be specified for each part, so proper drawing could be done. IIRC, the practice of merging layers was never really to save bandwidth. Instead, there was the annoying factor of when drawing images, you'd need to split them apart before, and then potentially merge them for future edits, etc. I think some was also related to isomorphic crossfire (becoming daimonin) - merged images could be drawn correctly in isomorphic mode, but split images appeared, well, split apart. > > Second, what are the chances of some sort of vertical tiling being > introduced? (even though this is unlikely) I take this to mean the idea of different stories of a building? this is doable, but has some issues. The simple case to visualize is say a fort - you have an outside wall, and an inner courtyard. On the ground floor along the wall, you have various rooms. On the second floor, you can walk along the walls on top of the roof of these rooms. It is pretty clear that if you are along the wall (on the roofs), you could see people in the courtyard. If they walk off the roofs, they would fall into the courtyard. But for the person in the courtyard, it is probably proper for them to see the rooms on that same layer, and not the walls/roofs. One issue is what happens if someone on the roofs fire down to those people in the courtyard? This should be allowed, but to those in the courtyard, it appears that arrows (or spells) are basically show up from nowhere. People in the courtyard can't really return fire, etc. One fix would be to add some command like 'look up', which changes the player view from the level they are on to the level above them. But if there are 5 layers, that isn't a really good solution (fly/levitate should be a way to change layers also). Also, ideally, line of sight would need to be changed. If for example the roof are 8 tiles wide, and the player is farthest from the courtyard, then 8 spaces of the courtyard nearest to the player shouldn't really be visible (being obscured by the wall/roof). But that is tricky - a person standing up would be more visible than a dagger laying on the ground. All that said, codewise, I don't think this is really hard. But there are these other issues. From mwedel at sonic.net Sun May 21 01:28:28 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 20 May 2006 23:28:28 -0700 Subject: [crossfire] lighting & LOS redo. Message-ID: <4470088C.5040006@sonic.net> Now that I've finished the map2 command, bringing up the idea of lighting redo. As doing part of that, I've thought up some new issues. But first, summary of proposed changes - most of these are from discussion last summer. Note that all are not likely to be done at the same time, and this list in no way represents that order they will be done in. In fact, the ordering of this list is basically random 1) Increase number of lighting levels from 4 to 12. 2) Calculate light levels as a map attribute, and not part of player LOS (this will make things more efficient.) 3) Add ambient light level attribute to map header, which says what basic lighting level on all spaces is (dimly lit rooms). 4) Change meaning of darkness map header (should change name - light_threshold?) - if space is below that light level, space can not be seen 5) Have walls block light (note that the wall itself will be illuminated, so for single thickness wall, this still won't look very good). The idea was brought up of walls being lit base on where the light source is relative to the player - if the lightsource was on the opposite side of the wall from the player, it doesn't illuminate the wall. I think this is doable. 6) Add partial blocking to terrain (or other objects) - for example, jungle might have a value of 3, so everything beyond the first space is darker, everything beyond the second space is darker still, and and some point, can't see any further. This is done basically by darkness. 7) Add colored lighting. Note that this is opaque to the server - it doesn't care what the color of the light is - it just passes that info to the client to do with it what it wants. Note that handling more than 1 light source/space adds a bunch of complication, so my thought is the brightest light source on a space is the one that is sent. One question is then what form to use for the color - using the crossfire built in colors is pretty limiting (and probably is not a good enough representation). One thought might be 6 bit RGB value, as it is compact and probably still provides a good enough resolution (you're unlikely to need a dim green value - I'd think that in most cases you want pretty saturated values). 8) Light source information is sent to the client, and not actual darkness of each space. The color of the light is also sent. Light values could be negative to denote that the space partially blocks the light. Out of view light sources are sent to the client if they illuminate a space the client can see. Also, this will also have to be used to denote spaces that block all light (eg walls) From alex_sch at telus.net Sun May 21 10:20:34 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 21 May 2006 09:20:34 -0600 Subject: [crossfire] lighting & LOS redo. In-Reply-To: <4470088C.5040006@sonic.net> References: <4470088C.5040006@sonic.net> Message-ID: <44708542.6030905@telus.net> Mark Wedel wrote: >1) Increase number of lighting levels from 4 to 12. > > Seems rather arbitrary, but seems reasonable. >2) Calculate light levels as a map attribute, and not part of player LOS (this >will make things more efficient.) > > Yep, that seems good, though we do have to remember that even without a light source players have a small area around them they can see better in. >3) Add ambient light level attribute to map header, which says what basic >lighting level on all spaces is (dimly lit rooms). > > Yes, this seems like a good idea, also if light color is implemented, might be a good idea to allow the ambient light to be colored optionally. >4) Change meaning of darkness map header (should change name - light_threshold?) >- if space is below that light level, space can not be seen > > Hmm, that seems good, and should map fairly well to existing values in maps, however we still may need to tweak some existing maps. >5) Have walls block light (note that the wall itself will be illuminated, so for >single thickness wall, this still won't look very good). The idea was brought >up of walls being lit base on where the light source is relative to the player - >if the lightsource was on the opposite side of the wall from the player, it >doesn't illuminate the wall. I think this is doable. > > This seems like a good idea to me, including deciding if it's lit by where the player and lightsource, which would in my opinion be very good to implement. >6) Add partial blocking to terrain (or other objects) - for example, jungle >might have a value of 3, so everything beyond the first space is darker, >everything beyond the second space is darker still, and and some point, can't >see any further. This is done basically by darkness. > > This seems like a good idea, also some monsters and items could be made partial blocking to be realistic to how they do block your view a bit, not really sure about that, but perhaps. >7) Add colored lighting. Note that this is opaque to the server - it doesn't >care what the color of the light is - it just passes that info to the client to >do with it what it wants. Note that handling more than 1 light source/space >adds a bunch of complication, so my thought is the brightest light source on a >space is the one that is sent. One question is then what form to use for the >color - using the crossfire built in colors is pretty limiting (and probably is >not a good enough representation). One thought might be 6 bit RGB value, as it >is compact and probably still provides a good enough resolution (you're unlikely >to need a dim green value - I'd think that in most cases you want pretty >saturated values). > > Well, this would allow "black lights" that actually illuminate. I'm not sure such flexibility is useful or good, as we don't need to send the intensity of the light source in a second form at once. Perhaps we would be better off sending a 6 bit Hue/Saturation pair? >8) Light source information is sent to the client, and not actual darkness of >each space. The color of the light is also sent. Light values could be >negative to denote that the space partially blocks the light. Out of view light >sources are sent to the client if they illuminate a space the client can see. >Also, this will also have to be used to denote spaces that block all light (eg >walls) > This seems like a good idea to me anyways. Also, it might be good to allow objects to specify the rate at which light coming from them fades. Yes, it is true that it fades at a fixed rate in real life, however in order to simulate something like a significantly elevated light source one would need to make how fast it fades slower. Also, it might be interesting to make it so there are light levels brighter than 'fully lit', and if it's enough higher than that, then a partial fade-to-white/color effect could be useful and realistic. (this would be handled client-side, however we would need to have enough light levels that there is room for such) Another feature that would be interesting, though perhaps a bit impractical. It would be possible to for each image, make a "lightmask" which would define how much it would pick up light from each direction. It would be difficult to get lightmasks made for every image, however it wouldn't be too hard to implement in the client and would make things look very shiny. That said, I'm not sure this last idea is worth it, just brainstorming a bit :-P Alex Schultz From mwedel at sonic.net Sun May 21 20:08:14 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 21 May 2006 18:08:14 -0700 Subject: [crossfire] lighting & LOS redo. In-Reply-To: <44708542.6030905@telus.net> References: <4470088C.5040006@sonic.net> <44708542.6030905@telus.net> Message-ID: <44710EFE.7010904@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > >> 1) Increase number of lighting levels from 4 to 12. >> >> > Seems rather arbitrary, but seems reasonable. Most constants are arbitrary at some level. However, I came to that number for a few reasons: a) the MAP2_COORD_OFFSET is set at 15 - I think I arrived at that number by figuring current map size was 33x33, and max coordinate was 64, and splitting the remainder came to be 15. That actually isn't right, because for all purposes we care about, the map size is 25x25, (64-25)/2 = 20. b) A glow radius 12 light would reach the map edges when the player is in the middle of the map (however, with circular lighting doesn't reach the corners.) c) Always has to be some compromise - too high a value means a lot of time is spent looking for light sources. > >> 2) Calculate light levels as a map attribute, and not part of player LOS (this >> will make things more efficient.) >> >> > Yep, that seems good, though we do have to remember that even without a > light source players have a small area around them they can see better in. Arguably, that isn't correct. If you are in complete darkness (in a cave/mine), you won't be able to see the hand in front of your face. That said, setting a basic visiblity for spaces around the player would be done in the LOS code. The server still enforces LOS on light - if space is too dark, can't see it > >> 3) Add ambient light level attribute to map header, which says what basic >> lighting level on all spaces is (dimly lit rooms). >> >> > Yes, this seems like a good idea, also if light color is implemented, > might be a good idea to allow the ambient light to be colored optionally. Maybe. I'd have to think more about how ambiant colored light would work, but putting that in wouldn't be that hard. >> 6) Add partial blocking to terrain (or other objects) - for example, jungle >> might have a value of 3, so everything beyond the first space is darker, >> everything beyond the second space is darker still, and and some point, can't >> see any further. This is done basically by darkness. >> >> > This seems like a good idea, also some monsters and items could be made > partial blocking to be realistic to how they do block your view a bit, > not really sure about that, but perhaps. Yes - from the server perspective, it doesn't care what the object is that is blocking the light - it would just look for some attribute in the object. > >> 7) Add colored lighting. Note that this is opaque to the server - it doesn't >> care what the color of the light is - it just passes that info to the client to >> do with it what it wants. Note that handling more than 1 light source/space >> adds a bunch of complication, so my thought is the brightest light source on a >> space is the one that is sent. One question is then what form to use for the >> color - using the crossfire built in colors is pretty limiting (and probably is >> not a good enough representation). One thought might be 6 bit RGB value, as it >> is compact and probably still provides a good enough resolution (you're unlikely >> to need a dim green value - I'd think that in most cases you want pretty >> saturated values). >> >> > Well, this would allow "black lights" that actually illuminate. I'm not > sure such flexibility is useful or good, as we don't need to send the > intensity of the light source in a second form at once. Perhaps we would > be better off sending a 6 bit Hue/Saturation pair? Black light is a different issue, as it probably wouldn't have the affect people would really want. But even grey lights get odd - what does a grey light mean compared to a white light? That the light source isn't as bright? That should be handled by glow_radius. the actual form of the color isn't that important - as said, the server cares less - it is basically taking a byte of data that is set in the object and sends it to the client. But one consideration is that whatever form it is in, should be something that is easy to set for players. I don't really like the idea of english names - it is the easiest thing to do, but now means the server needs to have a large table of 'this color is this number', and the client has to have a 'this number is drawn with this rgb value'. So my ideal case is a value that the server loads and can easily convert to an int and throw to the client, and the client can know what to do with that. > >> 8) Light source information is sent to the client, and not actual darkness of >> each space. The color of the light is also sent. Light values could be >> negative to denote that the space partially blocks the light. Out of view light >> sources are sent to the client if they illuminate a space the client can see. >> Also, this will also have to be used to denote spaces that block all light (eg >> walls) >> > This seems like a good idea to me anyways. > > Also, it might be good to allow objects to specify the rate at which > light coming from them fades. Yes, it is true that it fades at a fixed > rate in real life, however in order to simulate something like a > significantly elevated light source one would need to make how fast it > fades slower. Maybe, but that 'fade value' also needs to be sent to the client. I'm not actually sure how many times that would come up. It probably wouldn't be hard, just not sure if it would get enough use to be worth it. > > Also, it might be interesting to make it so there are light levels > brighter than 'fully lit', and if it's enough higher than that, then a > partial fade-to-white/color effect could be useful and realistic. (this > would be handled client-side, however we would need to have enough light > levels that there is room for such) That may be doable. I'm not sure how useful it is to actually fade colors. The idea I had was something like a 'glow_radius 16', which would basicaly mean the first 4 spaces around it are fully lit, next one at 11, next at 10, etc, and only goes out 12 spaces, at which point it is still relatively bright. That is in a sense easier to, as it really doesn't require any extra info to be set to the client (as long as the client knows the max effective glow radius is 12, it is fine). > > Another feature that would be interesting, though perhaps a bit > impractical. It would be possible to for each image, make a "lightmask" > which would define how much it would pick up light from each direction. > It would be difficult to get lightmasks made for every image, however it > wouldn't be too hard to implement in the client and would make things > look very shiny. That said, I'm not sure this last idea is worth it, > just brainstorming a bit :-P The gotcha there is that is now an object/image attribute and not really related to lighting per se. I'm also not sure how well any graphic support could really take advantage of that with the basic images - making the entire image brighter probably doesn't add much - ideally, you would want the image to be lighted on that info (eg, only the side of the tower that is getting light is brighter, then you could also draw shadows,etc). From fuchs.andy at gmail.com Sun May 21 20:36:37 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 21 May 2006 21:36:37 -0400 Subject: [crossfire] lighting & LOS redo. In-Reply-To: <44710EFE.7010904@sonic.net> References: <4470088C.5040006@sonic.net> <44708542.6030905@telus.net> <44710EFE.7010904@sonic.net> Message-ID: Just want to bring up the possibility of mirrors in the game (in terms of the general lighting level) and ways to make lights move to create more visual effect (could the animator plugin work?). -- Andrew Fuchs From lalo.martins at gmail.com Mon May 22 06:51:23 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 22 May 2006 19:51:23 +0800 Subject: [crossfire] lighting & LOS redo. References: <4470088C.5040006@sonic.net> <44708542.6030905@telus.net> <44710EFE.7010904@sonic.net> Message-ID: On Sun, 21 May 2006 18:08:14 -0700, Mark Wedel wrote: > Alex Schultz wrote: >> Mark Wedel wrote: >>> 7) Add colored lighting. (...) >>> One thought might be 6 bit RGB value, as it is compact and... >>> >> Well, this would allow "black lights" that actually illuminate. I'm not >> sure such flexibility is useful or good, as we don't need to send the >> intensity of the light source in a second form at once. Perhaps we >> would be better off sending a 6 bit Hue/Saturation pair? > > Black light is a different issue, as it probably wouldn't have the > affect people would really want. > > But even grey lights get odd - what does a grey light mean compared to > a white light? That the light source isn't as bright? That should be > handled by glow_radius. > > the actual form of the color isn't that important - as said, the > server cares less - it is basically taking a byte of data that is > set in the object and sends it to the client. But one consideration > is that whatever form it is in, should be something that is easy to > set for players. > > I don't really like the idea of english names - it is the easiest > thing to do, but now means the server needs to have a large table of > 'this color is this number', and the client has to have a 'this number > is drawn with this rgb value'. So my ideal case is a value that the > server loads and can easily convert to an int and throw to the client, > and the client can know what to do with that. Having spent most of my last two working days implementing a colour picker :-P I must say I like the idea of hue/saturation; it's perfect for this purpose, as it completely describes a light colour. And you can use one byte, wasting no bits, and have great resolution; 4 bits of hue and 4 of saturation is pretty good. Of course, people don't know how to write their favourite colours as hue/saturation pairs :-) but they can open up the gimp and get the correct values from the colour picker therein. 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://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From quinet at gamers.org Mon May 22 13:50:14 2006 From: quinet at gamers.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 22 May 2006 20:50:14 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <1147941265.3001.33.camel@localhost.localdomain> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> Message-ID: <20060522205014.0737b276.quinet@gamers.org> On Thu, 18 May 2006 10:34:25 +0200, Wim Villerius wrote: > On Tue, 2006-04-11 at 21:21 +0100, Anton Oussik wrote: > > To those unfamiliar with it, shadow alchemy generally involves finding > > hash collisions for the recipes, fooling the alchemy code into > > thinking you are doing something else entirely. Since the hashing > > function is (on purpose) very weak, there is no easy way of making > > shadow alchemy impossible short of entirely changing the way > > traditional alchemy works. It is currently hard enough to discourage > > most people though (thanks to some safeguards in the code). For most > > purposes, however, it currently does what dynamic alchemy will do, but > > without the much needed game balancing, and very scarce documentation. > AFAIK shadow alchemy is indeed in desperate need of game balancing and > since it is by no means documentated (except that it's written 'in the > code') it is almost never practised (anymore). At least on MF, I know no > active players that do anything with it. (Are there any active players > anyway?) > Perhaps I could even put it this way: because shadow alchemy is > undocumented (and almost unknown) there is a request for dynamic > alchemy! Sorry for joining this discussion a bit late, but I only restarted plauing Crossfire a few weeks ago. In my opinion, the shadow alchemy should be removed from the game because it will soon be too easy to abuse it (more on that at the end of this message). I am not sure that the dynamic alchemy as proposed here is the best alternative, but at least it is better than the abuses that are allowed by the shadow alchemy tricks. Also, shadow alchemy is player knowledge and not character knowledge: this gives an unfair advantage to experienced players regardless of their character level. One of the reasons for the RFC on dynamic alchemy was that alchemy is not used that much in the game. Before reading that RFC (while being mostly off the net) I started working on a partial solution to that problem: I have started creating a set of maps for an "alchemy quest". The basic idea of these quests is that you can apply for being thaught some alchemy tricks by some some alchemists (and smiths, bowyers). They ask you to perform some specific tasks before they reveal more of their secrets to you. This is a bit similar to the quest for becoming the prince of Scorn and the rewards are some formulas, like in the fire temple quest (by the way, I would like to put a lock code on the potion of cold resistance, like there is one for the fire potion that can be found in the fire temple). Some of the tasks that the alchemists assign to their pupils involve the creation of specific items that can only be created by alchemy. For example, you will only get the next task if you sacrifice a Frostbrand or Firebrand of Slay Dragon. It will probably still take a few weeks (or months?) before I am ready with these maps and offer them for testing, but I am hoping that adding some quests related to alchemy could encourage more players to develop their alchemy skills. One of the things that hinder the usage of alchemy in the game is that the formulas are *much* too difficult to find in dungeons and in shops. As a test, I created a new character and I decided to collect all readable items that I would find in the dungeons (bestiaries, books on religion and of course alchemy) and to buy any formula that I could find in a shop. After a few weeks, I had collected a few hundred books on religions and on the various monsters and items, but only 53 unique formulas (I got rid of the multiple copies for the "water of the wise"). As a comparison, I had also collected 4416 scrolls of identify (various levels) during that time. More than four thousand. Another comparison: before finding the formula for the Ring of Beguilement, I had already found 15 of them in the dungeons. And before finding the formula for the Ring of Mithrandir, I had 4 of them. It is not surprising that nobody uses alchemy if it is so hard to find the formula for any useful item. Not to mention that having the formula is a prerequisite, but only a small part of the solution: the ingredients are usually hard to find and the difficulty for creating the most useful items is such that there is a very high probability of failure. I had to slay a very large number of dragons and many Firebrands/Frostbrands before I was able to create a (non cursed) weapon of Slay Dragon. My suggestion would be to increase (by a large amount) the probability of finding formulas in treasure lists. On the other hand, there could be less books on religions. In my opinion, the random books on religions could even be removed from the treasure lists: the knowledge of gods is mostly useful for low-level characters. After having gained a few levels, it is likely that the player would have already picked a god and is unlikely to change. For that reason, it would be more useful to have the books on religions as part of some maps near Scorn or Navar so that beginners could find them easily and decide which god is best for them instead of having to pick one god early based on incomplete information or on information available from the web site but not within the game. If these religion books were removed and replaced by a larger number of alchemy books, then maybe alchemy would become more attractive. Last but not least, I mentioned that abusing shadow alchemy would soon become too easy... The reason is that while playing, I was annoyed by the errors in some maps (broken exits or errors in the lock codes for doors or altars) and I also wanted to improve the alchemy checking code that I wrote a long time ago ("crossfire -m9"). So I decided to work on something that I had in mind for ages but never found the time/motivation to write: a script that goes through all maps in the game, checks which ones are not reachable, checks for any broken or blocked exits, collects all archetypes and all named items available on all maps, checks the lock codes or objects needed by altars, and so on... This script is about 1000 lines of Perl code and I hope that it will be ready in a few days. It takes around 5 minutes to perform all checks on the bigworld maps. I think that it would be a useful complement to the unit tests that have been added recently: this script does more or less the same for all maps. Anyway, one of the outputs of that script is a complete list of all items that can be found in the game (including items with a title or flesh items) sorted by number of occurences in the maps. Once this full list of all items is available, it is not very difficult to perform a "brute force attack" on the alchemy hashes. This would be easy to do because the large but finite list of all named items that can be picked up in the game can now be generated easily. And I am sure that once I publish my map checking script, it will not take long until someone does exactly that and publishes the full list of hash collisions for the alchemy code. Then the problems of the shadow alchemy code will become even more apparent. -Rapha?l P.S.: Did you know that there are 5931 random_wealth objects in 405 maps and 3833 random_treasure in 309 maps? Or that there are only two maps in which one can find Ancient dragons (and the corresponding dragon steaks required for entering the dragon training levels)? From quinet at gamers.org Mon May 22 16:11:39 2006 From: quinet at gamers.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 22 May 2006 23:11:39 +0200 Subject: [crossfire] Automatic map checking Message-ID: <20060522231139.2662743d.quinet@gamers.org> In my previous message discussing the alchemy code, I mentioned the script that I am currently writing for performing automatic checks of all crossfire maps. I tested this script on the bigworld maps (latest tarball as well as CVS) and it reported a bunch of errors. Some of them are simple warnings and others are real errors. I am planning to improve the output of the script so that it reports different severity levels, but in the meantime I thought that it could be useful to post some excerpts from the output of that script in case someone feels like fixing some of these errors. Some notes: - Non-existing maps: these are maps that have an exit pointing to them, but there is no corresponding file. Two notable sources of such errors are the player shops in Brest (missing floor2) and many broken "mlab" maps. - Unreachable maps: these are maps that exist but cannot be reached by following an exit (starting from (/HallOfSelection). Some of these unreachable maps are still connected to each other, but the group of maps is not reachable. The /HallOfDMs map is unreachable by design. Some other unreachable maps are just test maps that should probably be moved elsewhere (in /unlinked, for example). The other ones are probably errors that should be fixed. - The blocked exits are exits that point to an area that contains an object that blocks MOVE_WALK (or more, such as MOVE_ALL). Exits that are blocked by a check_inv trigger are probably fine. Exits that point ot a wall are almost certainly wrong and should be fixed. Exits that are blocked by a connected object or by a door with a keycode (slaying) may be dangerous: they are usually the return path from a dungeon and they work fine as long as the player goes through the levels fast enough. But if the map is reset while the player is inside the dungeon, then the player could be stuck on the way back because the entrance map has been reset and the exit is now blocked. These maps should probably be redesigned for extra safety, although this is probably not a critical issue. - The blocked exit from /scorn/apartment/Apartments1 should not be reported because the floor has the "unique" flag. This is one of the things that I still have to improve in the script. So here is an excert from the output of the script: Checking for non-existing maps... no /brest/pshops/pshop1/floor2 (12, 7) from /brest/pshops/pshop1/floor1 (12, 7) no /brest/pshops/pshop10/floor2 (12, 7) from /brest/pshops/pshop10/floor1 (12, 7) no /brest/pshops/pshop11/floor2 (12, 7) from /brest/pshops/pshop11/floor1 (12, 7) no /brest/pshops/pshop12/floor2 (12, 7) from /brest/pshops/pshop12/floor1 (12, 7) no /brest/pshops/pshop13/floor2 (12, 7) from /brest/pshops/pshop13/floor1 (12, 7) no /brest/pshops/pshop14/floor2 (12, 7) from /brest/pshops/pshop14/floor1 (12, 7) no /brest/pshops/pshop15/floor2 (12, 7) from /brest/pshops/pshop15/floor1 (12, 7) no /brest/pshops/pshop16/floor2 (12, 7) from /brest/pshops/pshop16/floor1 (12, 7) no /brest/pshops/pshop17/floor2 (12, 7) from /brest/pshops/pshop17/floor1 (12, 7) no /brest/pshops/pshop18/floor2 (12, 7) from /brest/pshops/pshop18/floor1 (12, 7) no /brest/pshops/pshop19/floor2 (12, 7) from /brest/pshops/pshop19/floor1 (12, 7) no /brest/pshops/pshop2/floor2 (12, 7) from /brest/pshops/pshop2/floor1 (12, 7) no /brest/pshops/pshop20/floor2 (12, 7) from /brest/pshops/pshop20/floor1 (12, 7) no /brest/pshops/pshop21/floor2 (12, 7) from /brest/pshops/pshop21/floor1 (12, 7) no /brest/pshops/pshop22/floor2 (12, 7) from /brest/pshops/pshop22/floor1 (12, 7) no /brest/pshops/pshop23/floor2 (12, 7) from /brest/pshops/pshop23/floor1 (12, 7) no /brest/pshops/pshop24/floor2 (12, 7) from /brest/pshops/pshop24/floor1 (12, 7) no /brest/pshops/pshop25/floor2 (12, 7) from /brest/pshops/pshop25/floor1 (12, 7) no /brest/pshops/pshop26/floor2 (12, 7) from /brest/pshops/pshop26/floor1 (12, 7) no /brest/pshops/pshop27/floor2 (12, 7) from /brest/pshops/pshop27/floor1 (12, 7) no /brest/pshops/pshop3/floor2 (12, 7) from /brest/pshops/pshop3/floor1 (12, 7) no /brest/pshops/pshop4/floor2 (12, 7) from /brest/pshops/pshop4/floor1 (12, 7) no /brest/pshops/pshop5/floor2 (12, 7) from /brest/pshops/pshop5/floor1 (12, 7) no /brest/pshops/pshop6/floor2 (12, 7) from /brest/pshops/pshop6/floor1 (12, 7) no /brest/pshops/pshop7/floor2 (12, 7) from /brest/pshops/pshop7/floor1 (12, 7) no /brest/pshops/pshop8/floor2 (12, 7) from /brest/pshops/pshop8/floor1 (12, 7) no /brest/pshops/pshop9/floor2 (12, 7) from /brest/pshops/pshop9/floor1 (12, 7) no /inn_and_outpost/downthewell (1, 1) from /world/world_111_116 (46, 31) no /lake_country/pup_land/nurnberg/city (25, 15) from /lake_country/dragon_hangar/hangar (34, 2) no /mlab/citydeclouds/IPO_citydeclouds (11, 8) from /mlab/citydeclouds/citydeclouds2H (6, 48) (10, 20) from /mlab/citydeclouds/citydeclouds2I (5, 10) no /mlab/citydeclouds/cdcapart/cdcapart1 (13, 12) from /mlab/citydeclouds/citydeclouds2G (7, 48) no /mlab/citydeclouds/cdcapart1 (23, 50) from /mlab/citydeclouds/citydeclouds2H (17, 36) no /mlab/citydeclouds/cdcbigstore/cdccotgf1 (11, 22) from /mlab/citydeclouds/cdcbigstore/cdcbigstore3f (4, 46) no /mlab/citydeclouds/cdccloudre1 (17, 3) from /mlab/citydeclouds/citydeclouds2E (45, 37) (17, 5) from /mlab/citydeclouds/citydeclouds2E (45, 39) no /mlab/citydeclouds/cdccotgf1 (18, 67) from /mlab/citydeclouds/citydeclouds2C (49, 25) (42, 22) from /mlab/citydeclouds/citydeclouds2E (23, 30) (19, 60) from /mlab/citydeclouds/citydeclouds2F (0, 18) (34, 80) from /mlab/citydeclouds/citydeclouds2F (15, 38) (55, 67) from /mlab/citydeclouds/citydeclouds2F (36, 25) (63, 57) from /mlab/citydeclouds/citydeclouds2F (44, 15) (115, 48) from /mlab/citydeclouds/citydeclouds2I (46, 6) no /mlab/citydeclouds/cdccourthsuplvl1 (3, 4) from /mlab/citydeclouds/citydeclouds2A (3, 41) (3, 10) from /mlab/citydeclouds/citydeclouds2A (3, 47) (8, 7) from /mlab/citydeclouds/citydeclouds2A (5, 42) (8, 7) from /mlab/citydeclouds/citydeclouds2A (5, 43) (8, 7) from /mlab/citydeclouds/citydeclouds2A (5, 44) (8, 7) from /mlab/citydeclouds/citydeclouds2A (5, 45) (8, 7) from /mlab/citydeclouds/citydeclouds2A (5, 46) (8, 7) from /mlab/citydeclouds/citydeclouds2A (6, 42) (8, 7) from /mlab/citydeclouds/citydeclouds2A (6, 43) (8, 7) from /mlab/citydeclouds/citydeclouds2A (6, 44) (8, 7) from /mlab/citydeclouds/citydeclouds2A (6, 45) (8, 7) from /mlab/citydeclouds/citydeclouds2A (6, 46) (8, 7) from /mlab/citydeclouds/citydeclouds2A (7, 42) (8, 7) from /mlab/citydeclouds/citydeclouds2A (7, 43) (8, 7) from /mlab/citydeclouds/citydeclouds2A (7, 44) (8, 7) from /mlab/citydeclouds/citydeclouds2A (7, 45) (8, 7) from /mlab/citydeclouds/citydeclouds2A (7, 46) (8, 7) from /mlab/citydeclouds/citydeclouds2A (8, 42) (8, 7) from /mlab/citydeclouds/citydeclouds2A (8, 43) (8, 7) from /mlab/citydeclouds/citydeclouds2A (8, 44) (8, 7) from /mlab/citydeclouds/citydeclouds2A (8, 45) (8, 7) from /mlab/citydeclouds/citydeclouds2A (8, 46) no /mlab/citydeclouds/cdcgatea2 (13, 15) from /mlab/citydeclouds/citydeclouds2D (49, 31) no /mlab/citydeclouds/cdcjjbuild/cdcjjbuild1 (11, 5) from /mlab/citydeclouds/citydeclouds2E (43, 20) no /mlab/citydeclouds/cdcmesshluper1 (1, 6) from /mlab/citydeclouds/citydeclouds2C (3, 16) no /mlab/citydeclouds/cdcnrkpdevtmp1 (1, 1) from /mlab/citydeclouds/citydeclouds2B (3, 1) no /mlab/citydeclouds/cdcnwgateuprlv1 (10, 12) from /mlab/citydeclouds/citydeclouds2A (10, 30) no /mlab/citydeclouds/cdcscasino (7, 11) from /mlab/citydeclouds/citydeclouds2H (2, 29) (7, 12) from /mlab/citydeclouds/citydeclouds2H (2, 30) no /mlab/citydeclouds/cdcunderbigstre1 (9, 76) from /mlab/citydeclouds/citydeclouds2B (40, 45) (50, 42) from /mlab/citydeclouds/citydeclouds2E (31, 10) (50, 43) from /mlab/citydeclouds/citydeclouds2E (31, 11) (50, 44) from /mlab/citydeclouds/citydeclouds2E (31, 12) (19, 98) from /mlab/citydeclouds/citydeclouds2F (0, 17) (66, 93) from /mlab/citydeclouds/citydeclouds2F (47, 12) (70, 53) from /mlab/citydeclouds/citydeclouds2H (1, 21) (75, 62) from /mlab/citydeclouds/citydeclouds2H (6, 30) (86, 74) from /mlab/citydeclouds/citydeclouds2H (17, 42) (101, 94) from /mlab/citydeclouds/citydeclouds2I (32, 12) (102, 94) from /mlab/citydeclouds/citydeclouds2I (33, 12) no /mlab/citydeclouds/cdcvillaarC1 (22, 7) from /mlab/citydeclouds/citydeclouds2G (29, 23) no /mlab/citydeclouds/cdcwgrotto1 (28, 55) from /mlab/citydeclouds/citydeclouds2F (49, 26) no /mlab/citydeclouds/citydeclouds (26, 144) from /mlab/citydeclouds/citydeclouds2G (0, 4) no /mlab/citydeclouds/citydecloudsvilla/citydecloudsvillaC1 (6, 6) from /mlab/citydeclouds/citydeclouds2G (20, 29) no /mlab/citydeclouds/citydecloudsvilla/citydecloudsvillab1 (1, 41) from /mlab/citydeclouds/citydeclouds2G (6, 48) (23, 31) from /mlab/citydeclouds/citydeclouds2G (28, 38) no /mlab/citydeclouds/cloudworlddecity (45, 76) from /mlab/citydeclouds/citydeclouds2A (0, 26) no /mlab/citydeclouds/tavernb3 (41, 7) from /mlab/citydeclouds/citydeclouds2G (22, 31) no /mlab/citydeclouds2 (122, 31) from /navar_city/mlab/tavernb3 (41, 7) no /mlab/cloudworlddecity (45, 76) from /mlab/citydeclouds/citydeclouds2A (0, 25) (62, 106) from /mlab/citydeclouds/citydeclouds2F (13, 46) (62, 106) from /mlab/citydeclouds/citydeclouds2F (14, 46) (62, 106) from /mlab/citydeclouds/citydeclouds2F (15, 46) (62, 106) from /mlab/citydeclouds/citydeclouds2F (16, 46) (29, 112) from /mlab/mlabscrntrd2 (24, 9) no /morok_dun/mines1 (18, 27) from /world/world_120_109 (27, 41) no /navar_city/mlab/tadobebuild2 (10, 18) from /navar_city/mlab/tavern (73, 19) no /navar_city/mlab/zealothouse2 (16, 15) from /navar_city/mlab/tavern (19, 70) no /navar_city/mlab/zealothouseb1 (6, 12) from /navar_city/mlab/tavern (9, 67) no /navar_city/pup_land/nurnberg/city (25, 15) from /navar_city/dragon_hangar/hangar (34, 2) no /navar_city/smugglers_cove/sc_cave1 (26, 38) from /world/world_124_119 (25, 17) no /navar_city/smugglers_cove/sc_lair1 (5, 29) from /world/world_124_119 (13, 26) (12, 24) from /world/world_124_119 (20, 21) no /navar_city/smugglers_cove/smugglers_ship2 (8, 7) from /world/world_124_119 (18, 38) no /pup_land/ancient/mountain/0 (0, 0) from /pup_land/ancient/mountain/tower.1 (25, 24) (0, 0) from /pup_land/ancient/mountain/tower.2 (0, 17) no /pup_land/lone_town/pup_land/nurnberg/city (25, 15) from /pup_land/lone_town/dragonhangar/hangar (34, 2) no /pup_land/nurnberg/pup_land/nurnberg/city (25, 15) from /pup_land/nurnberg/dragonhangar/hangar (34, 2) no /scorn/houses/rolandos_house (3, 1) from /world/world_105_116 (7, 4) no /scorn/houses/yolandas_house (2, 1) from /world/world_105_116 (6, 4) no /wolfsburg/hut/hut (2, 17) from /world/world_128_109 (26, 37) no /world/goei mezon (0, 0) from /world/world_127_102 (27, 3) (0, 0) from /world/world_128_101 (6, 19) Checking for existing but unreachable maps... unreachable /HallOfDMs (11, 24) to /world/world_105_116 (4, 4) (14, 24) to /world/world_122_117 (3, 10) unreachable /azumauindo/suno-yamatoshi/tou/tou1 (5, 14) to /azumauindo/suno-yamatoshi/tou/tou2 (5, 14) (5, 14) from /azumauindo/suno-yamatoshi/tou/tou2 (5, 14) unreachable /azumauindo/suno-yamatoshi/tou/tou2 (5, 14) to /azumauindo/suno-yamatoshi/tou/tou1 (5, 14) (3, 10) to /azumauindo/suno-yamatoshi/tou/tou3 (3, 10) (5, 14) from /azumauindo/suno-yamatoshi/tou/tou1 (5, 14) (3, 10) from /azumauindo/suno-yamatoshi/tou/tou3 (3, 10) unreachable /azumauindo/suno-yamatoshi/tou/tou3 (3, 10) to /azumauindo/suno-yamatoshi/tou/tou2 (3, 10) (4, 7) to /azumauindo/suno-yamatoshi/tou/tou4 (4, 7) (3, 10) from /azumauindo/suno-yamatoshi/tou/tou2 (3, 10) (4, 7) from /azumauindo/suno-yamatoshi/tou/tou4 (4, 7) unreachable /azumauindo/suno-yamatoshi/tou/tou4 (4, 7) to /azumauindo/suno-yamatoshi/tou/tou3 (4, 7) (8, 8) to /azumauindo/suno-yamatoshi/tou/tou5 (8, 8) (4, 7) from /azumauindo/suno-yamatoshi/tou/tou3 (4, 7) (8, 8) from /azumauindo/suno-yamatoshi/tou/tou5 (8, 8) unreachable /azumauindo/suno-yamatoshi/tou/tou5 (8, 8) to /azumauindo/suno-yamatoshi/tou/tou4 (8, 8) (8, 8) from /azumauindo/suno-yamatoshi/tou/tou4 (8, 8) unreachable /brest/sport.jess (0, 9) to /brest/sport.jess (23, 22) (0, 10) to /brest/sport.jess (27, 23) (38, 34) to /world/world_107_123 (27, 29) (23, 22) from /brest/sport.jess (0, 9) (27, 23) from /brest/sport.jess (0, 10) unreachable /darcap/darcap/circus/movers unreachable /darcap/darcap/circus/walls unreachable /dungeons/train/train-old (1, 16) to /dungeons/train/goblin (19, 3) (1, 12) to /dungeons/train/ogre (19, 12) (8, 12) to /dungeons/train/skeleton (19, 12) (8, 16) to /dungeons/train/zombie (19, 3) (1, 5) to /world/world_104_115 (48, 24) (1, 9) to /world/world_104_115 (48, 24) (4, 18) to /world/world_104_115 (48, 25) (5, 18) to /world/world_104_115 (49, 25) (8, 5) to /world/world_104_115 (49, 24) (8, 9) to /world/world_104_115 (49, 24) unreachable /planes/IPO_storage unreachable /pup_land/ancient/castle/ghoswolte (0, 0) to /pup_land/castle_eureca/castle_eureca5 (9, 31) unreachable /pup_land/ancient/castle/gothwolte.1 (12, 2) to /pup_land/ancient/castle/gothwolte.3 (9, 20) (12, 2) from /pup_land/ancient/castle/gothwolte.3 (9, 20) unreachable /pup_land/ancient/castle/gothwolte.2 unreachable /pup_land/ancient/castle/gothwolte.3 (9, 20) to /pup_land/ancient/castle/gothwolte.1 (12, 2) (0, 0) to /pup_land/castle_eureca/castle_eureca5 (9, 31) (9, 20) from /pup_land/ancient/castle/gothwolte.1 (12, 2) unreachable /pup_land/ancient/ruin/tower (14, 31) to /pup_land/ancient/ruin/path (17, 2) unreachable /pup_land/ancient/village/siegfried/lever (0, 15) to /pup_land/ancient/village/siegfried/siegfried.1 (22, 29) (8, 11) to /pup_land/ancient/village/siegfried/siegfried.1 (35, 13) unreachable /pup_land/castle_eureca/castle_eurecaB2 (1, 19) to /pup_land/castle_eureca/castle_eurecaB1 (8, 12) (2, 23) to /pup_land/castle_eureca/castle_eurecaB2 (2, 19) (2, 19) from /pup_land/castle_eureca/castle_eurecaB2 (2, 23) unreachable /pup_land/cave_weapon/cave51 (15, 15) to /pup_land/cave_weapon/cave4 (16, 14) (10, 22) to /pup_land/cave_weapon/cave5 (15, 16) (15, 16) to /pup_land/cave_weapon/cave5 (10, 22) unreachable /pup_land/jk/heads (15, 0) to /pup_land/rainbow/islands (28, 24) (3, 26) to /pup_land/s_f/cave2 (15, 3) unreachable /pup_land/kurte/eureca_road31 (4, 31) to /pup_land/kurte/eureca_road3 (6, 8) (37, 4) to /pup_land/kurte/eureca_road3 (6, 8) unreachable /pup_land/lone_town/guild_freedom_ud (1, 1) to /pup_land/lone_town/guild_freedom (13, 14) unreachable /pup_land/lone_town/guild_law_ud (5, 1) to /pup_land/lone_town/guild_law (4, 14) unreachable /pup_land/lone_town/nf_bar unreachable /pup_land/nurnberg/agito (1, 13) to /pup_land/nurnberg/hotel (13, 2) unreachable /pup_land/nurnberg/dick/bomb (7, 15) to /pup_land/nurnberg/city (4, 9) (16, 24) to /pup_land/nurnberg/city (4, 9) unreachable /pup_land/rainbow/Lv1/Bizuzu (6, 8) to /pup_land/rainbow/Lv1/b_pass (1, 4) (6, 4) to /pup_land/rainbow/river (1, 1) (6, 8) from /pup_land/rainbow/Lv1/b_pass (1, 4) (6, 4) from /pup_land/rainbow/river (1, 1) unreachable /pup_land/rainbow/Lv1/b_pass (1, 4) to /pup_land/rainbow/Lv1/Bizuzu (6, 8) (13, 1) to /pup_land/rainbow/Lv1/orc_f (2, 1) (1, 4) from /pup_land/rainbow/Lv1/Bizuzu (6, 8) (12, 1) from /pup_land/rainbow/Lv1/orc_f (1, 1) unreachable /pup_land/rainbow/Lv1/orc_f (1, 1) to /pup_land/rainbow/Lv1/b_pass (12, 1) (7, 5) to /pup_land/rainbow/Lv1/orc_f (20, 3) (8, 13) to /pup_land/rainbow/Lv1/orc_f (20, 12) (20, 3) to /pup_land/rainbow/Lv1/orc_f (7, 5) (20, 12) to /pup_land/rainbow/Lv1/orc_f (7, 11) (14, 14) to /pup_land/rainbow/Lv1/prison (4, 1) (2, 1) from /pup_land/rainbow/Lv1/b_pass (13, 1) (20, 3) from /pup_land/rainbow/Lv1/orc_f (7, 5) (20, 12) from /pup_land/rainbow/Lv1/orc_f (8, 13) (7, 5) from /pup_land/rainbow/Lv1/orc_f (20, 3) (7, 11) from /pup_land/rainbow/Lv1/orc_f (20, 12) unreachable /pup_land/rainbow/Lv5/romm88 unreachable /pup_land/rainbow/river (1, 1) to /pup_land/rainbow/Lv1/Bizuzu (6, 4) (42, 5) to /pup_land/rainbow/islands (24, 18) (1, 1) from /pup_land/rainbow/Lv1/Bizuzu (6, 4) unreachable /quests/mak/chaos/monsters.pick unreachable /quests/mak/dragons/chaos.orig (6, 34) to /quests/mak/MainFloor (6, 14) (6, 30) to /quests/mak/dragons/chaos (15, 29) (15, 30) to /quests/mak/dragons/chaos (6, 30) unreachable /quests/peterm/quests/dragon_quest (4, 3) to /quests/peterm/quests/dragonquest2 (3, 2) (3, 2) to /world/world_111_117 (39, 42) unreachable /quests/todd/aljwaf/ruins (21, 8) to /quests/todd/aljwaf/crypt (1, 1) (6, 19) to /quests/todd/aljwaf/crypt2 (2, 2) (18, 17) to /quests/todd/aljwaf/crypt3 (1, 1) (6, 3) to /quests/todd/aljwaf/crypt4 (8, 1) (16, 9) to /quests/todd/aljwaf/crypt5 (8, 3) (23, 23) to /world/world_122_111 (11, 26) (24, 23) to /world/world_122_111 (11, 26) unreachable /scorn/misc/testing_area (1, 1) to /scorn/misc/castle2 (17, 7) unreachable /scorn/oldcity/oldcity4 (19, 20) to /scorn/oldcity/oldcity2 (1, 20) (0, 33) to /scorn/oldcity/oldcity5 (19, 33) (13, 0) to /scorn/oldcity/oldcity9 (33, 19) (0, 33) from /scorn/oldcity/oldcity5 (19, 33) unreachable /scorn/oldcity/oldcity5 (19, 33) to /scorn/oldcity/oldcity4 (0, 33) (12, 39) to /scorn/oldcity/oldcity6 (12, 0) (0, 5) to /scorn/oldcity/oldcity7 (19, 5) (10, 0) to /scorn/oldcity/oldcity9 (10, 19) (19, 33) from /scorn/oldcity/oldcity4 (0, 33) Checking for blocked exits... blocked exit from /brest/Castle/Finale (1, 58) to /brest/Castle/LargeRoom (27, 56) blocked by door blocked exits from /darcap/darcap/circus/illusions (9, 6) to /darcap/darcap/circus/illusions (34, 6) blocked by grate (connected 1) (9, 7) to /darcap/darcap/circus/illusions (34, 7) blocked by grate (connected 1) (9, 11) to /darcap/darcap/circus/illusions (34, 11) blocked by grate (connected 2) (9, 12) to /darcap/darcap/circus/illusions (34, 12) blocked by grate (connected 2) (9, 16) to /darcap/darcap/circus/illusions (34, 16) blocked by grate (connected 3) (9, 17) to /darcap/darcap/circus/illusions (34, 17) blocked by grate (connected 3) blocked exit from /darcap/darcap/gshop (15, 6) to /world/world_116_102 (23, 25) blocked by shop blocked exit from /inn_and_outpost/hermes_inn2 (20, 8) to /inn_and_outpost/hermes_inn (20, 8) blocked by check inv trigger (slaying hermes_inn_pass) blocked exit from /lake_country/Butakis/prison_s (5, 6) to /scorn/shops/bowshop (5, 6) blocked by wall blocked exit from /lake_country/small_buildings/burial_ground (1, 1) to /world/world_109_126 (18, 22) blocked by river blocked exit from /marksel/grumms_inn2 (20, 3) to /marksel/grumms_inn (20, 3) blocked by check inv trigger (slaying grumms_inn_pass) blocked exits from /navar_city/city1houses (3, 12) to /world/world_122_116 (2, 42) blocked by grass (33, 3) to /world/world_122_116 (2, 41) blocked by grass blocked exit from /navar_city/magara/houses/large_house (24, 1) to /navar_city/magara/houses/large_house (19, 19) blocked by iron gate (connected 2) blocked exit from /navar_city/misc/aliswell (11, 34) to /navar_city/misc/aliswell (10, 9) blocked by clay well plug (slaying rodofalitheaterb4) blocked exit from /navar_city/misc/theaterb1 (2, 29) to /navar_city/misc/theater (2, 29) blocked by spikes (connected 100) blocked exits from /navar_city/mlab/tavern3 (0, 18) to /navar_city/mlab/tavern (3, 18) blocked by wall (0, 26) to /navar_city/mlab/tavern (3, 26) blocked by wall (0, 27) to /navar_city/mlab/tavern (3, 27) blocked by wall (0, 29) to /navar_city/mlab/tavern (3, 29) blocked by wall (1, 18) to /navar_city/mlab/tavern (3, 18) blocked by wall (1, 26) to /navar_city/mlab/tavern (3, 26) blocked by wall (1, 27) to /navar_city/mlab/tavern (3, 27) blocked by wall (1, 29) to /navar_city/mlab/tavern (3, 29) blocked by wall (2, 18) to /navar_city/mlab/tavern (3, 18) blocked by wall (2, 26) to /navar_city/mlab/tavern (3, 26) blocked by wall (3, 18) to /navar_city/mlab/tavern (3, 18) blocked by wall (9, 0) to /navar_city/mlab/tavern (14, 2) blocked by wall (9, 1) to /navar_city/mlab/tavern (14, 2) blocked by wall (10, 0) to /navar_city/mlab/tavern (14, 2) blocked by wall (10, 1) to /navar_city/mlab/tavern (14, 2) blocked by wall (11, 0) to /navar_city/mlab/tavern (14, 2) blocked by wall (11, 1) to /navar_city/mlab/tavern (14, 2) blocked by wall (11, 2) to /navar_city/mlab/tavern (14, 2) blocked by wall (12, 0) to /navar_city/mlab/tavern (14, 2) blocked by wall (12, 1) to /navar_city/mlab/tavern (14, 2) blocked by wall (12, 2) to /navar_city/mlab/tavern (14, 2) blocked by wall (13, 0) to /navar_city/mlab/tavern (14, 2) blocked by wall (13, 1) to /navar_city/mlab/tavern (14, 2) blocked by wall (13, 2) to /navar_city/mlab/tavern (14, 2) blocked by wall (14, 0) to /navar_city/mlab/tavern (14, 2) blocked by wall (14, 1) to /navar_city/mlab/tavern (14, 2) blocked by wall (14, 1) to /navar_city/mlab/tavern (14, 2) blocked by wall (14, 2) to /navar_city/mlab/tavern (14, 2) blocked by wall (14, 6) to /navar_city/mlab/tavern (14, 6) blocked by wall (14, 9) to /navar_city/mlab/tavern (14, 9) blocked by wall blocked exits from /navar_city/mlab/ttower15 (6, 5) to /navar_city/mlab/ttower14 (6, 5) blocked by wall (12, 11) to /navar_city/mlab/ttower14 (12, 11) blocked by wall blocked exit from /navar_city/mlab/ttower16 (7, 13) to /navar_city/mlab/ttower15 (7, 13) blocked by spikes blocked exit from /navar_city/mlab/ttower32 (12, 12) to /navar_city/mlab/ttower31 (12, 12) blocked by spikes (connected 3) blocked exit from /navar_city/mlab/ttower33 (14, 8) to /navar_city/mlab/ttower32 (14, 8) blocked by grate (connected 2) blocked exit from /port_joseph/pirates/tortship2 (9, 11) to /port_joseph/pirates/tortship (9, 6) blocked by mast blocked exit from /pup_land/ancient/ruin/tower (14, 31) to /pup_land/ancient/ruin/path (17, 2) blocked by wall blocked exits from /pup_land/ancient/village/siegfried/siegfried.B4 (23, 26) to /pup_land/ancient/village/siegfried/siegfried.B5a (1, 1) blocked by firewall (5, 17) to /pup_land/ancient/village/siegfried/siegfried.B5b (1, 14) blocked by lightningwall blocked exit from /pup_land/cave_weapon/cave1 (31, 18) to /pup_land/cave_weapon/cave2 (1, 6) blocked by mine2 blocked exit from /pup_land/jk/heads (3, 26) to /pup_land/s_f/cave2 (15, 3) blocked by wall blocked exits from /pup_land/kurte/to_past (6, 7) to /pup_land/kurte/kurte (15, 3) blocked by wall (connected 100) (6, 25) to /pup_land/kurte/kurte (15, 3) blocked by wall (connected 100) (7, 6) to /pup_land/kurte/kurte (15, 3) blocked by wall (connected 100) (7, 8) to /pup_land/kurte/kurte (15, 3) blocked by wall (connected 100) (7, 24) to /pup_land/kurte/kurte (15, 3) blocked by wall (connected 100) (7, 26) to /pup_land/kurte/kurte (15, 3) blocked by wall (connected 100) (8, 7) to /pup_land/kurte/kurte (15, 3) blocked by wall (connected 100) (8, 25) to /pup_land/kurte/kurte (15, 3) blocked by wall (connected 100) blocked exit from /pup_land/nurnberg/aqueduct (24, 24) to /pup_land/nurnberg/city (14, 16) blocked by biglake_3_1 blocked exit from /pup_land/raffle/raffle1_u2 (2, 16) to /pup_land/raffle/raffle1_u3 (2, 16) blocked by boulder blocked exits from /quests/peterm/Demonology/HighTower1 (3, 4) to /quests/peterm/Demonology/Demon3 (6, 7) blocked by stone (slaying Earth_up), locked door (slaying Air_up), locked door (slaying Water_up), locked door (slaying Fire_up) (4, 3) to /quests/peterm/Demonology/Demon3 (7, 6) blocked by stone (slaying Earth_up), locked door (slaying Air_up), locked door (slaying Water_up), locked door (slaying Fire_up) (4, 5) to /quests/peterm/Demonology/Demon3 (7, 8) blocked by stone (slaying Earth_up), locked door (slaying Air_up), locked door (slaying Water_up), locked door (slaying Fire_up) (5, 4) to /quests/peterm/Demonology/Demon3 (8, 7) blocked by stone (slaying Earth_up), locked door (slaying Air_up), locked door (slaying Water_up), locked door (slaying Fire_up) blocked exits from /quests/peterm/Demonology/HighTower2 (6, 5) to /quests/peterm/Demonology/HighTower1 (4, 4) blocked by spikes (connected 4), spikes (connected 3), spikes (connected 2), spikes (connected 1) blocked exit from /quests/peterm/Demonology/HighTowerTop (1, 1) to /quests/peterm/Demonology/HighTower2 (1, 1) blocked by locked door (slaying Bkey) blocked exit from /quests/peterm/DragonQuest/FireHatchery (3, 3) to /quests/peterm/DragonQuest/FireAnte (2, 4) blocked by wall blocked exit from /quests/skud/court (20, 0) to /quests/skud/north_1 (16, 39) blocked by wall blocked exits from /quests/todd/aljwaf/hall1 (0, 9) to /quests/todd/aljwaf/crypt (6, 9) blocked by garden gate (connected 1) (0, 10) to /quests/todd/aljwaf/crypt (6, 9) blocked by garden gate (connected 1) (0, 11) to /quests/todd/aljwaf/crypt (6, 9) blocked by garden gate (connected 1) (0, 12) to /quests/todd/aljwaf/crypt (6, 9) blocked by garden gate (connected 1) blocked exit from /santo_dominion/lord_byron/1st_floor (1, 1) to /santo_dominion/lord_byron/2nd_floor (5, 5) blocked by wall blocked exit from /scorn/apartment/Apartments1 (0, 0) to /scorn/apartment/apartments (1, 8) blocked by locked door (slaying ExtendedApartmentKey) blocked exits from /scorn/misc/prison (0, 51) to /scorn/anthony/prison (17, 20) blocked by spikes (connected 100) (0, 52) to /scorn/anthony/prison (17, 21) blocked by spikes (connected 100) blocked exit from /whalingoutpost/misc/frostcavern1 (62, 40) to /whalingoutpost/misc/polarbearcave3 (34, 42) blocked by ice blocked exit from /whalingoutpost/taverns/fishershallb1 (19, 9) to /whalingoutpost/taverns/fishershall1 (19, 9) blocked by barrel blocked exit from /wolfsburg/dungeons/treas_room (3, 2) to /world/world_129_109 (20, 42) blocked by rocks (slaying shovel) blocked exits from /wolfsburg/volcano/vvmansion (16, 0) to /world/world_129_108 (6, 30) blocked by Mansion (17, 0) to /world/world_129_108 (6, 30) blocked by Mansion blocked exit from /world/world_127_109 (18, 17) to /world/world_127_109 (46, 43) blocked by shallow_sea [...] The other parts of the script are reporting locked doors without keys, altars without matching object or keycode, unused keys, etc. But I am still working on that part and the list is a bit long anyway so I will not post it. The script also reports a full list of archetypes used in all maps, and full list of named objects (which is much longer if treasure lists and flesh items are included). I will try to publish the script as soon as it is reasonably usable. -Rapha?l From nicolas.weeger at laposte.net Mon May 22 16:56:52 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 22 May 2006 23:56:52 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <20060522205014.0737b276.quinet@gamers.org> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> Message-ID: <200605222356.52096.nicolas.weeger@laposte.net> Hello. > The basic idea of these quests is that you can apply for being thaught > some alchemy tricks by some some alchemists (and smiths, bowyers). They > ask you to perform some specific tasks before they reveal more of their > secrets to you. This is a bit similar to the quest for becoming the I like the idea, though it merely goes with the ?lock? code as used by the fire resistance potion, I think. > One of the things that hinder the usage of alchemy in the game is that the > formulas are *much* too difficult to find in dungeons and in shops. As a Indeed. You can of course experiment, but exploding cauldrons kill all too often :) > formula for any useful item. Not to mention that having the formula is a > prerequisite, but only a small part of the solution: the ingredients are > usually hard to find and the difficulty for creating the most useful items > is such that there is a very high probability of failure. I had to slay a For many formulaes I find the ingredients way too hard to find as compared to finding the equivalent item. I'll grant you that potions will work everywhere, as opposed to scrolls/spells on cursed/non magic squares. But still, for instance balm of first aid is way too hard to do, for a few hitpoints restored! (as a side note: shouldn't the balm of flying [word of recall] work whether square is cursed or not, like other balms?) As for finding formulas, I'd say your idea of alchemists could be interesting, but shouldn't require combat or such - maybe finding ingredients, or rare items? Nicolas From fuchs.andy at gmail.com Mon May 22 18:00:31 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 22 May 2006 19:00:31 -0400 Subject: [crossfire] lighting & LOS redo. In-Reply-To: References: <4470088C.5040006@sonic.net> <44708542.6030905@telus.net> <44710EFE.7010904@sonic.net> Message-ID: On 5/22/06, Lalo Martins wrote: ... > Having spent most of my last two working days implementing a colour picker > :-P I must say I like the idea of hue/saturation; it's perfect for this > purpose, as it completely describes a light colour. And you can use one > byte, wasting no bits, and have great resolution; 4 bits of hue and 4 of > saturation is pretty good. > > Of course, people don't know how to write their favourite colours as > hue/saturation pairs :-) but they can open up the gimp and get the correct > values from the colour picker therein. Or an implementation in the map editors. This will probably be requested frequently once the lighting code is redone. -- Andrew Fuchs From alex_sch at telus.net Mon May 22 19:46:50 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 22 May 2006 18:46:50 -0600 Subject: [crossfire] Automatic map checking In-Reply-To: <20060522231139.2662743d.quinet@gamers.org> References: <20060522231139.2662743d.quinet@gamers.org> Message-ID: <44725B7A.2090000@telus.net> Rapha?l Quinet wrote: >- Non-existing maps: these are maps that have an exit pointing to them, > but there is no corresponding file. Two notable sources of such > errors are the player shops in Brest (missing floor2) and many broken > "mlab" maps. > > Note, many of the non-existing maps are like such by design. For example the floor2 thing in Brest is because that is simply unimplemented, and those exits are there as a placeholder which gives players a sensible message. Such placeholders are very common and aren't considered errors generally. The mlab thing is because much of mlab is not in CVS, for various reasons including that the creator of mlab uses a flat directory structure which people do not have the time to change. /lake_country/pup_land/nurnberg/city is likely a typo >- Unreachable maps: these are maps that exist but cannot be reached by > following an exit (starting from (/HallOfSelection). Some of these > unreachable maps are still connected to each other, but the group of > maps is not reachable. The /HallOfDMs map is unreachable by design. > Some other unreachable maps are just test maps that should probably > be moved elsewhere (in /unlinked, for example). The other ones are > probably errors that should be fixed. > > /dungeons/train/train-old for one should either be deleted or moved to unlinked, it is as I understand a sort of backup of the old training center lobby That's my 2 cents on some of these cases. Alex Schultz From antonoussik at gmail.com Mon May 22 19:56:44 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 23 May 2006 01:56:44 +0100 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <20060522205014.0737b276.quinet@gamers.org> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> Message-ID: On 22/05/06, Rapha?l Quinet wrote: > On Thu, 18 May 2006 10:34:25 +0200, Wim Villerius wrote: > > On Tue, 2006-04-11 at 21:21 +0100, Anton Oussik wrote: > > > To those unfamiliar with it, shadow alchemy generally involves finding > > > hash collisions for the recipes, fooling the alchemy code into > > > thinking you are doing something else entirely. Since the hashing > > > function is (on purpose) very weak, there is no easy way of making > > > shadow alchemy impossible short of entirely changing the way > > > traditional alchemy works. It is currently hard enough to discourage > > > most people though (thanks to some safeguards in the code). For most > > > purposes, however, it currently does what dynamic alchemy will do, but > > > without the much needed game balancing, and very scarce documentation. > > AFAIK shadow alchemy is indeed in desperate need of game balancing and > > since it is by no means documentated (except that it's written 'in the > > code') it is almost never practised (anymore). At least on MF, I know no > > active players that do anything with it. (Are there any active players > > anyway?) > Once this full list of all items is available, it is not very > difficult to perform a "brute force attack" on the alchemy hashes. This > would be easy to do because the large but finite list of all named items > that can be picked up in the game can now be generated easily. And I am > sure that once I publish my map checking script, it will not take long until > someone does exactly that and publishes the full list of hash collisions for > the alchemy code. Then the problems of the shadow alchemy code will become > even more apparent. The full list of items is not really needed nor preferred. What you want is a list of easily avaliable ingredients (things you can get in large quantities from altars, money, and summonable items), and generate hash collisions using those. A couple of summers ago I wrote a short C program that parsed formulae file and generated collisions using these ingredients in O(n^2), it worked quite well. I also saw a Windows collision seeking program that would find a collision that was very profitable and generate a client side script repeatedly doing it. In my opinion shadow alchemy is not widely used because it is so obscure, not because it is impractical. The actual number of collisions is huge though - publishing (and generating) a full list of collisions is quite pointless. Removing shadow alchemy alltogether would only work by not allowing recipes not found in formulae file at all, in which case there is no point in having a hash value representing the recipe, and the way alchemy works needs redoing entirely. Dynamic alchemy IMO can replace what is used today, but I think it should work thus: If the recipe matches one in formulae file, use that. else use dynamic alchemy: Resistances: Max resistance that can flow in/out of an item is the level of the player in alchemy up to 100%. One can argue that this is too high, but it is already possible to get 100% resist items from traditional alchemy without shadow alchemy - on of the failures generates the desired item with stats doubled. Stats: Max stat that can flow in/out of an item is up to 5, and also depends on alchemy level, where lvl 1-20 is +/-1, lvl 21-40 +/-2, ... for each item in the device for each non-zero property (affected by alchemy) in the item find a random item in inventory get a random number between 0 and the max level allows if the number is greater than the amount in the original item reduce it accordingly transfer the property if amount in the new item is greater than level allows reduce to max level allows effectively alchemy will then have reproducible and yet random behaviour, and will act as a method to transfer properties between objects. Although this method will allow high resistance items in theory, they will be very very rare. This approach also does not need to build up any aditional tables, and so can be entirely implemented within alchemy.c. Also IMO traditional alchemy recipes should be made easier to do. By the time you find ingredients, you can already find/buy the target item. Perhaps ingredient shop should extract ingredients straight from the formulae file, and stock those, in large quantities. This way alchemist would be able to buy ingredients without spending ages looking for them in the wild. I know ingredient list is supposed to encourage exploration, but if you go exploring you will find the target more easily than find and collect all the ingredients. There also needs to be more medium and high level alchemy-only items that require high (100+) level to generate. From mwedel at sonic.net Tue May 23 00:35:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 22 May 2006 22:35:52 -0700 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> Message-ID: <44729F38.4090701@sonic.net> Looking at the readable code, there are basically 6 readable object types. I'm not sure if any treasure lists explicitly try to creatable alchemy books, but if not, each has equal chance. (the 6 types are monster info, artifact info, spellpath, formula, god, and stuff from the message file). One could make the case that spellpath and god info should occur less frequently. God info perhaps not at all, and spellpath less info just simply because there are not a lot of spellpaths, so not a whole bunch of need to create as many of those. I do think the hash method should be removed. I do think readable books (not just alchemy) should show up more often. I can go into that random dungeon and get hundreds of scrolls, but only a a few readable objects. Some of this is based on the fact that scrolls come in groups, but even then, scrolls (and spellbooks) for that matter show up a lot. This may be because those show up in monsters, where I think readables only show up in random treasure/treasure chests. I also agree that the ingredients are also generally too hard to find. I remember in a commercial RPG game, there was some alchemy, and basically at the start of the game, you could find the basic ingrediants (flowers/minerals) just laying on the ground and make a fair number of what amounted to be cure light (or regain a few mana point) potions. The alchemy formula should be redone so something in similiar - at low levels, you can find the formula to make basic potions (a new set of less powerful potions may be in order). And the ingrediants for these should also be easy. From mwedel at sonic.net Tue May 23 00:56:07 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 22 May 2006 22:56:07 -0700 Subject: [crossfire] lighting & LOS redo. In-Reply-To: References: <4470088C.5040006@sonic.net> <44708542.6030905@telus.net> <44710EFE.7010904@sonic.net> Message-ID: <4472A3F7.30402@sonic.net> Lalo Martins wrote: > Having spent most of my last two working days implementing a colour picker > :-P I must say I like the idea of hue/saturation; it's perfect for this > purpose, as it completely describes a light colour. And you can use one > byte, wasting no bits, and have great resolution; 4 bits of hue and 4 of > saturation is pretty good. > > Of course, people don't know how to write their favourite colours as > hue/saturation pairs :-) but they can open up the gimp and get the correct > values from the colour picker therein. Playing with the color picker it gimp, it seems there is hue, saturation, and value, so 3 values. I suppose 4 bits (16 values) for hue is probably enough, but a little hard to tell (dividing the color circle in 16 pieces, hard to say where everything where really line up). I'm guessing that we're assuming that value will always be 100 (and thus don't need that)? That makes sense to me - having it dimmer would really seem to be part of the glow radius, and not something that should be done by the light source itself. And thus, 4 bits for saturation may be more than enough, so yeah, that works. Or maybe in a 5/3 mix, to give more colors, since I'm not sure how refinement people need in saturation (I'd tend to think that generally for effect to be more noticable, people will want to use more saturated values). It probably would be best, however, that the individual hue/saturation value be set in the object, like: hue 301 value 86 And then the loader would convert that to the 8 bit value for sending to the client, so that the conversion only needs to be done once. From tchize at myrealbox.com Tue May 23 03:43:31 2006 From: tchize at myrealbox.com (Tchize) Date: Tue, 23 May 2006 10:43:31 +0200 Subject: [crossfire] lighting & LOS redo. In-Reply-To: <4472A3F7.30402@sonic.net> References: <4470088C.5040006@sonic.net> <44708542.6030905@telus.net> <44710EFE.7010904@sonic.net> <4472A3F7.30402@sonic.net> Message-ID: <4472CB33.3000900@myrealbox.com> See attached pics. This is the available color palette in 4x4 mode and in 5x3 mode (5 for Hue, 3 for saturation) I think 5x3 mode gives the best results. The Hue is naturaly the think the human eye is most aware of and so should be given more importance. Mark Wedel wrote: > > And thus, 4 bits for saturation may be more than enough, so yeah, that works. > Or maybe in a 5/3 mix, to give more colors, since I'm not sure how refinement > people need in saturation (I'd tend to think that generally for effect to be > more noticable, people will want to use more saturated values). > -------------- next part -------------- A non-text attachment was scrubbed... Name: hslights_4_4.png Type: image/png Size: 784 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060523/9c730df1/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: hslights_5_3.png Type: image/png Size: 931 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060523/9c730df1/attachment-0001.png From lalo.martins at gmail.com Tue May 23 05:47:04 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 23 May 2006 18:47:04 +0800 Subject: [crossfire] lighting & LOS redo. References: <4470088C.5040006@sonic.net> <44708542.6030905@telus.net> <44710EFE.7010904@sonic.net> <4472A3F7.30402@sonic.net> Message-ID: On Mon, 22 May 2006 22:56:07 -0700, Mark Wedel wrote: > Lalo Martins wrote: >> I must say I like the idea of hue/saturation > > Playing with the color picker it gimp, it seems there is hue, saturation, and > value, so 3 values. > > I'm guessing that we're assuming that value will always be 100 (and thus don't > need that)? That makes sense to me - having it dimmer would really seem to be > part of the glow radius, and not something that should be done by the light > source itself. Not so much that it is always 100; as I said, hue/saturation perfectly describes a light's colour. The value says how much of that light you see, and as such, it would come from the light level on each square. 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://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Tue May 23 17:23:09 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Wed, 24 May 2006 00:23:09 +0200 Subject: [crossfire] New layer code bug :) Message-ID: <200605240023.09744.nicolas.weeger@laposte.net> Hello. Metalforge having been updated, I'm using the new mapcmd2 protocol, and noticed somee fun bugs :) First (no screen copy, sorry), sometimes 1 item only will appear from a pile, sometimes 2 items (without any monster) Second, traps seem to appear above player Third, some items appear above player (see screenshot) Apart that seems ok for now :) Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: capture1.png Type: image/png Size: 9189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060524/b9937fc2/attachment.png From mwedel at sonic.net Wed May 24 01:36:38 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 23 May 2006 23:36:38 -0700 Subject: [crossfire] New layer code bug :) In-Reply-To: <200605240023.09744.nicolas.weeger@laposte.net> References: <200605240023.09744.nicolas.weeger@laposte.net> Message-ID: <4473FEF6.9040809@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > Metalforge having been updated, I'm using the new mapcmd2 protocol, and > noticed somee fun bugs :) > > First (no screen copy, sorry), sometimes 1 item only will appear from a pile, > sometimes 2 items (without any monster) Would be interested in more details on that, especially if you can get a reproducible test case. Note however there are cases where I know this could happen, based simply on the images used. For example, if you drop a dagger, and then drop plate mail on top of it, it would appear that there is only 1 object (plate mail) on that space. In fact, the client is getting both images, it just turns out that the plate mail image is bigger than the dagger image, and thus completely obscures it. This is of course a waste, but I'm not sure how to really fix it - the server certainly doesn't know the extent of the images. The client could perhaps have some idea as to the extent of the image, but that would get pretty messy. Now the visibility of the dagger object could be set higher than platemail, so it appears on top of the platemail. But that is then sort of odd - arguably, daggers should have a relatively low visibility. > Second, traps seem to appear above player I'm presuming this happens when you are searching for traps? Looking at the archetype that is used for that (runedet), it has flying 1 set, so would make sense for it to be above the player. I'm not sure why flying 1 is set for that object, however - I wonder if this was an attempt to make it really visible? I'll trying turning off flying and see if it all still works properly. > Third, some items appear above player (see screenshot) I'm taking it those were levitation boots? If so, that makes some sense, but isn't correctly visually - I think I'll have to do the change I suggest elsewhere where objects can specify what layer they want to be drawn on, basically overriding the mechanism use in the update_position code. From wim-cf at villerius.nl Wed May 24 02:44:18 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Wed, 24 May 2006 09:44:18 +0200 Subject: [crossfire] New layer code bug :) In-Reply-To: <4473FEF6.9040809@sonic.net> References: <200605240023.09744.nicolas.weeger@laposte.net> <4473FEF6.9040809@sonic.net> Message-ID: <1148456658.16489.84.camel@localhost.localdomain> > Would be interested in more details on that, especially if you can get a > reproducible test case. Not exactly the case Nicolas describes, but try the following: cast counterwall and walk in it. You'll see yourself disappearing. (This works for any spell I've seen) Or find a pile of treasure and step in it, you'll likely have to search for yourself :) > > Second, traps seem to appear above player > I'm presuming this happens when you are searching for traps? I guess so as wel. (AFAIK it is the only way to be on a tile with a trap!) > > Third, some items appear above player (see screenshot) > I'm taking it those were levitation boots? If so, that makes some sense, but > isn't correctly visually - I think I'll have to do the change I suggest > elsewhere where objects can specify what layer they want to be drawn on, > basically overriding the mechanism use in the update_position code. Not only levitation boots, but the Feather Crown (Neurmberg Receiption towers), diamonds and rubies as well (but not emeralds and sapphires). Pearls are different matter. They won't hide the player when there are only pearls, but they will in a big pile with other items. You cannot simply reproduce this effect by staying on a pile of diamonds/rubies - and what i'm saying now contradicts a few lines above - but if there are several 'diamonds' (not big ones) that won't stack, they will hide you. Same applied for rubies and even flowers. I guess these items are identical, but I cannot check that, I'm not a DM on Metalforge ;) Perhaps the player should be drawn in one of the highest layers? (such that they remain visible in a pile of treasure as well as in spell effects) From quinet at gamers.org Wed May 24 06:17:49 2006 From: quinet at gamers.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Wed, 24 May 2006 13:17:49 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <200605222356.52096.nicolas.weeger@laposte.net> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> <200605222356.52096.nicolas.weeger@laposte.net> Message-ID: <20060524131749.04813b1f.quinet@gamers.org> On Mon, 22 May 2006 23:56:52 +0200, "Nicolas Weeger (Laposte)" wrote: > For many formulaes I find the ingredients way too hard to find as compared to > finding the equivalent item. I agree. The only exceptions are the "water of the wise" that are easy to create, especially when purchasing water bottles from the converter in the alchemy shop. It is also easy to find the ingredients for the "water of diamond/emerald/ruby/saphire" and the "mushroom of Gourmet". But beyond these simple things, the cost/benefit ratio of alchemy is just too bad. > I'll grant you that potions will work everywhere, as opposed to scrolls/spells > on cursed/non magic squares. But still, for instance balm of first aid is way > too hard to do, for a few hitpoints restored! > (as a side note: shouldn't the balm of flying [word of recall] work whether > square is cursed or not, like other balms?) Isn't that the "balm of return home"? Anyway, I haven't checked but I suspect that the spell is cast when you apply the balm but it fails later when you should be teleported back home (like when you invoke word of recall just before entering a cursed area). Anyway, the cursed squares are a separate issue: I think that too many maps have cursed/no magic areas without giving appropriate clues/warnings to the player. Some of them are there for historical reasons and could probably be removed or replaced by something else. This would deserve a separate discussion. > As for finding formulas, I'd say your idea of alchemists could be interesting, > but shouldn't require combat or such - maybe finding ingredients, or rare > items? Acquiring some of the ingredients may involve some kind of combat. If the alchemist asks you for a chinese dragon's heart or even some simple orc chops, I don't think that you can find them easily without fighting. Currently, the easier quests ask for ingredients that are not too hard to find. Some of them may not even require combat. For example, collecting some flowers or mushrooms. Although they are hard to find inside the cities, they can be found easily in some random maps where they are just waiting to be picked up. The quest gives you some hints about where you might find these ingredients but since they are generic objects you are free to bring them from some other place or even buy them in shops. The more difficult quests (I have only one currently but I am planning for some others) give you access to more interesting formulas. They also require ingredients that are more difficult to find and always require some combat. For these quests, the alchemist (or bowyer, etc.) will ask you to bring him some dread's eyes, lich dusts, etc. Or maybe even more specific items such as blue dragons' steaks or other objects that can only be found in a few places. -Rapha?l From quinet at gamers.org Wed May 24 07:34:01 2006 From: quinet at gamers.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Wed, 24 May 2006 14:34:01 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> Message-ID: <20060524143401.419fdbfc.quinet@gamers.org> On Tue, 23 May 2006 01:56:44 +0100, "Anton Oussik" wrote: > On 22/05/06, Rapha?l Quinet wrote: > > [...] Once this full list of all items is available, it is not very > > difficult to perform a "brute force attack" on the alchemy hashes. This > > would be easy to do because the large but finite list of all named items > > that can be picked up in the game can now be generated easily. [...] > > The full list of items is not really needed nor preferred. What you > want is a list of easily avaliable ingredients (things you can get in > large quantities from altars, money, and summonable items), and > generate hash collisions using those. I should have explained this better in my previous message: the list of items that I get out of my script is sorted by "relative abundance". It counts the total number of objects of each type (or each name, in this case) found in the maps. For the objects that have treasure lists or that are generators, it also takes into account the items that can be generated and their relative probability of being generated (so you can end up with fractional numbers, as I mentioned previously). Besides finding the hash collisions for shadow alchemy, you will also know how easy it is to find the ingredients. > Removing shadow alchemy alltogether would only work by not allowing > recipes not found in formulae file at all, in which case there is no > point in having a hash value representing the recipe, and the way > alchemy works needs redoing entirely. Dynamic alchemy IMO can replace > what is used today, but I think it should work thus: [...] One thing that worries me a bit about dynamic alchemy (including the variant that you described) is that it could be used with almost any item. Even if there are safeguards based for example on the highest level allowed and things like that, there is a risk that it could bring some imbalance in the game if some items with unusual properties go through the dynamic alchemy process. I would prefer a system that is still based on some kind of template given in the formulae file. For example, some "template formula" would only work for daggers, another one would only work for pieces of armour made of copper, etc. Each template would have constraints on the kind of improvements that could be applied to the base item and the ingredients or class of ingredients required for these improvemens. I am not really sure about how these templates could look like, but the general idea is that I would prefer something that is still (loosely) defined in the formulae file rather than something that is a bit too dynamic. > Also IMO traditional alchemy recipes should be made easier to do. By > the time you find ingredients, you can already find/buy the target > item. Perhaps ingredient shop should extract ingredients straight from > the formulae file, and stock those, in large quantities. This way > alchemist would be able to buy ingredients without spending ages > looking for them in the wild. I know ingredient list is supposed to > encourage exploration, but if you go exploring you will find the > target more easily than find and collect all the ingredients. There > also needs to be more medium and high level alchemy-only items that > require high (100+) level to generate. I agree that the cost/benefit ratio of alchemy is bad. Also, reaching level 100+ in the alchemy-related skills is currently rather hard. Besides the improvements that can be made in the maps (like the quests that I described, and the corresponding random maps providing an easier way to get some ingredients), I would like to encourage the usage of alchemy by adding more valuable items that can only be created via alchemy. These items would never be found in treasure lists. Instead of adding more formulae, another option could be to remove some of the items that are currently found in treasure lists and in the formulae file so that they can only be created, not found. -Rapha?l From quinet at gamers.org Wed May 24 07:53:21 2006 From: quinet at gamers.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Wed, 24 May 2006 14:53:21 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <44729F38.4090701@sonic.net> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> <44729F38.4090701@sonic.net> Message-ID: <20060524145321.6d4b8722.quinet@gamers.org> On Mon, 22 May 2006 22:35:52 -0700, Mark Wedel wrote: [...skipped lots of good points...] > I remember in a commercial RPG game, there was some alchemy, and basically at > the start of the game, you could find the basic ingrediants (flowers/minerals) > just laying on the ground and make a fair number of what amounted to be cure > light (or regain a few mana point) potions. The alchemy formula should be > redone so something in similiar - at low levels, you can find the formula to > make basic potions (a new set of less powerful potions may be in order). And > the ingrediants for these should also be easy. Yes, I would like to do something along these lines. This is why I started working on a set of alchemy quests. This also includes some random maps that are easy to find and provide some basic ingredients. Regarding the basic potions, a first suggestion would be to make it easier to create a balm of first aid (or similar items). Note that we can still keep the old formula for backwards compatibility and simply add the new one that is based on ingredients that are easier to find, although it may be necessary to lower the value of the generated balm/potion so that is not used as a money maker. A low level character that can generate and carry around a bunch of balms of first aid would stand a better chance to survive in combat and would therefore be encouraged to use alchemy. Since these balms have a weight, a low level character would not be able to carry too many of them so this should not affect the game balance too much. -Rapha?l P.S.: I will now try to switch my subcription to this list to the address that I use more frequently. So don't be surprised if you see my next messages coming from raphael at gimp.org instead of quinet at gamers.org. From wim-cf at villerius.nl Wed May 24 07:56:16 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Wed, 24 May 2006 14:56:16 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <20060522205014.0737b276.quinet@gamers.org> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> Message-ID: <1148475377.16489.100.camel@localhost.localdomain> On Mon, 2006-05-22 at 20:50 +0200, Rapha?l Quinet wrote: > Sorry for joining this discussion a bit late, but I only restarted > plauing Crossfire a few weeks ago. A most heartly welcome! The discussion was barely started - and perhaps you restarted it :) > In my opinion, the shadow alchemy should be removed from the game > because it will soon be too easy to abuse it (more on that at the end > of this message). Anton Oussik already explained that shadow alchemy is already easy - errr - if you now how to generate hash collisions. But that's not enough, a few months ago alchemy was modified and shadow alchemy is blocked whenever the value of the result exceeds the value of the ingredients - which is pretty much always the case. > I am not sure that the dynamic alchemy as proposed here is the best > alternative, but at least it is better than the abuses that are > allowed by the shadow alchemy tricks. Honestly, I am not sure as well but I am sure that it's better than current alchemy and I am even more sure that we can find a still better solution. That's exactly why I brought up this point. Hopefully we can design an alchemy-system that makes the alchemist-profession as useful as the warrior :) > Also, shadow alchemy is player knowledge and not character knowledge: > this gives an unfair advantage to experienced players regardless of > their character level. Yes, shadow alchemy is player knowledge, not character knowledge. But the same goes for current alchemy, maps (passwords), where to find artifacts, how to beat monsters, etc etc. In other words, (almost) the whole game is player knowledge. Even using dynamic passwords would not change that much: an experienced player knows where to find the password. What's the point? Player experience is just everywhere, so perhaps it is not as worse as it looks. Why do I suggest _that_? Because from a player perspective it's horrible to search for information you already know. Why do a quest to learn that water of the wise is made in a cauldron using 7 water if you already know that? Oh, just because the game forces you to do so. Nothing wrong with that for some items (especially powerful receipes) but I think it will be very annoying if you have to do so for all receipes. (Note that I am not suggesting that this was your suggestion, I just want to express a bit of frustration about games that forces you to find out what you already know) > One of the reasons for the RFC on dynamic alchemy was that alchemy is > not used that much in the game. And, most important, that it is pretty useless - only an easy way to gain some experiece. > The basic idea of these quests is that you can apply for being thaught > some alchemy tricks by some some alchemists (and smiths, bowyers). > They ask you to perform some specific tasks before they reveal more of > their secrets to you. This is a bit similar to the quest for becoming > the prince of Scorn and the rewards are some formulas, like in the > fire temple quest (by the way, I would like to put a lock code on the > potion of cold resistance, like there is one for the fire potion that > can be found in the fire temple). Some of the tasks that the > alchemists assign to their pupils involve the creation of specific > items that can only be created by alchemy. Sounds good. In fact I have been playing with more or less the same idea, but dropped it (more or less) due to lack of time and inspiration. I suggest to put a lock on every receipe that has a change of zero to be found in random treasure. (there are quite a few: face of death (dust, currently broken according to the formulae file), fire immunity, invulnerability, magic immunity, electric immunity, magic power (both formulae), fiery destruction, rainbow wave, bolt/arrow of Assassinating {Dragon, Troll}, bolt/arrow of Blessedness) My reason for that is that the formulae don't show up in the game, so players are not supposed to create them. And in fact, they cannot, unless they cheat. I would as well add the formula for the potion of cold immunity to that list, but it currently has a small but existing chance to appear. > One of the things that hinder the usage of alchemy in the game is that > the formulas are *much* too difficult to find in dungeons and in > shops. > It is not surprising that nobody uses alchemy if it is so hard to find > the formula for any useful item. Not to mention that having the > formula is a prerequisite, but only a small part of the solution: the > ingredients are usually hard to find and the difficulty for creating > the most useful items is such that there is a very high probability of > failure. And quite often the ingredients are worth much more than the result. Dynamic alchemy is supposed to 'fix' both issues. Since there are no fixed receipes, you don't have to search the whole world a few times before you found a reasonable formula. Also you can use pretty 'worthless' ingredients (e.g, wyverns steak) to improve a bit (not a lot) so at lvl 10 you can customize your armour. It is not likely that you'll be 100% successfull, but failure does not imply that you loose your valuable items. > My suggestion would be to increase (by a large amount) the probability > of finding formulas in treasure lists. Yep, good idea although it depends a bit on what alchemy system we choose. > P.S.: Did you know that there are <...> only two maps in which one can > find Ancient dragons (and the corresponding dragon steaks required for > entering the dragon training levels)? Nice statistics... Perhaps this one is not very player-friendly. From antonoussik at gmail.com Wed May 24 08:21:18 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Wed, 24 May 2006 14:21:18 +0100 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <1148475377.16489.100.camel@localhost.localdomain> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> <1148475377.16489.100.camel@localhost.localdomain> Message-ID: Could someone explain how potion making and similar magic where the result is nothing like what you start off with will work? Will you need to put in a water bottle as part of the recipe? What about balms? From wim-cf at villerius.nl Wed May 24 09:16:35 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Wed, 24 May 2006 16:16:35 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <20060524143401.419fdbfc.quinet@gamers.org> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> <20060524143401.419fdbfc.quinet@gamers.org> Message-ID: <1148480195.16489.112.camel@localhost.localdomain> > I should have explained this better in my previous message: the list > of items that I get out of my script is sorted by "relative abundance". > It counts the total number of objects of each type (or each name, in > this case) found in the maps. For the objects that have treasure lists > or that are generators, it also takes into account the items that can > be generated and their relative probability of being generated (so you > can end up with fractional numbers, as I mentioned previously). > Besides finding the hash collisions for shadow alchemy, you will also > know how easy it is to find the ingredients. coins, rubies, pearls, sapphires are all very easy to get (and since any more or less experienced player is capable to collect a huge amount of money, the availability of these items is not a question, it is a fact. And I think these are sufficient to create any item. > One thing that worries me a bit about dynamic alchemy (including the > variant that you described) is that it could be used with almost any > item. Even if there are safeguards based for example on the highest > level allowed and things like that, there is a risk that it could > bring some imbalance in the game if some items with unusual properties > go through the dynamic alchemy process. I think one of the things that makes alchemy interesting is exactly the possibility to create items with unusual properties. Perhaps it is a good thing if the code prevents the creation of any item that has resistances > 95 (except for those attack types that already have an item that gives +100 resistance, such as slow, paralyse, fear, ...) That might result in some items that grant +100 against a whole lot of things (slow, fear, paralyse, drain, deplete, confusion, ghosthit,...) but would that be a serious problem? The ingredients needed for such an item are already quite excessive. It won't be the alchemist-that-never-leaves-town that creates such items. > I would prefer a system that is still based on some kind of template > given in the formulae file. For example, some "template formula" > would only work for daggers, another one would only work for pieces > of armour made of copper, etc. Each template would have constraints > on the kind of improvements that could be applied to the base item > and the ingredients or class of ingredients required for these > improvemens. But that essentially cancells the idea of dynamic alchemy in which not a formula but the ingredients alone define the result. (The ingredients define what to add, depending either on a table, the arches or a biased random roll) I fail to see however why templates would be more secure than dynamic alchemy as proposed. The constrains are either in a template or in (assuming) the arches. So these constrains do exist this way or another. > I would like to encourage the usage of > alchemy by adding more valuable items that can only be created via > alchemy. These items would never be found in treasure lists. Instead > of adding more formulae, another option could be to remove some of the > items that are currently found in treasure lists and in the formulae > file so that they can only be created, not found. There are a few, the Dragon Scale Mail of Ruggilli and the Elven Robe. I don't know more. It's nice that these exists, but not many players are aware that it is even possible to create these items. So yes, it's a good idea to have more (or even a lot) alchemy only items that are attractive (Elven robe is not), but somehow they should be known by players. Otherwise they won't bother learning alchemy. One thing that might help is not only to provide the receipe, but also describe the object in the textbook that offers the formula. Thus: The dragon scale mail of Ruggilli has incredible properties. It offers +75 resistance to fire and as well 65 armour. It is made using a forge and requires these ingredients: ... From raphael at gimp.org Wed May 24 09:46:22 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Wed, 24 May 2006 16:46:22 +0200 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <1148475377.16489.100.camel@localhost.localdomain> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> <1148475377.16489.100.camel@localhost.localdomain> Message-ID: <20060524164622.359ee956.raphael@gimp.org> On Wed, 24 May 2006 14:56:16 +0200, Wim Villerius wrote: > On Mon, 2006-05-22 at 20:50 +0200, Rapha?l Quinet wrote: > > I am not sure that the dynamic alchemy as proposed here is the best > > alternative, but at least it is better than the abuses that are > > allowed by the shadow alchemy tricks. > Honestly, I am not sure as well but I am sure that it's better than > current alchemy and I am even more sure that we can find a still better > solution. That's exactly why I brought up this point. Hopefully we can > design an alchemy-system that makes the alchemist-profession as useful > as the warrior :) As I wrote in my reply to Anton Oussik, I would prefer a system that keeps some constraints on the ingredients and on the result of the formula. A system with a bit more freedom than the current alchemy, but not much more. I think that the dynamic alchemy is very interesting but it goes a bit too far. > > Also, shadow alchemy is player knowledge and not character knowledge: > > this gives an unfair advantage to experienced players regardless of > > their character level. > Yes, shadow alchemy is player knowledge, not character knowledge. But > the same goes for current alchemy, maps (passwords), where to find > artifacts, how to beat monsters, etc etc. In other words, (almost) the > whole game is player knowledge. Well, it is worse for shadow alchemy: it is player knowledge that is very hard to acquire while playing, but easy to remember (or write down) once someone or some program tells you how to do it. So it is a bit like "cheat codes" for the game. The shadow formulas are of very little use for the normal players. > Even using dynamic passwords would not change that much: an experienced > player knows where to find the password. > What's the point? Player experience is just everywhere, so perhaps it is > not as worse as it looks. I agree. But the fact that some things are not perfect should not be an excuse to making them even worse, if you see what I mean. > Why do I suggest _that_? Because from a player perspective it's horrible > to search for information you already know. Why do a quest to learn that > water of the wise is made in a cauldron using 7 water if you already > know that? Oh, just because the game forces you to do so. > Nothing wrong with that for some items (especially powerful receipes) > but I think it will be very annoying if you have to do so for all > receipes. > (Note that I am not suggesting that this was your suggestion, I just > want to express a bit of frustration about games that forces you to find > out what you already know) I also agree with that. None of the basic formulas should be locked. There is no point in forcing the player to go to a specific place to find how to make the water of the wise. These formulas should be much easier to find anyway and if a player already knows them, then they can as well use them directly. On the other hand, the most powerful recipes should be locked because they are quest items. Even if I remember how to create the potion of fire immunity, I do not expect to be able to use it immediately when I create a new character: I know that I have to go through the fire temple first. [...] > I suggest to put a lock on every receipe that has a change of zero to be > found in random treasure. (there are quite a few: face of death (dust, > currently broken according to the formulae file), fire immunity, > invulnerability, magic immunity, electric immunity, magic power (both > formulae), fiery destruction, rainbow wave, bolt/arrow of Assassinating > {Dragon, Troll}, bolt/arrow of Blessedness) > My reason for that is that the formulae don't show up in the game, so > players are not supposed to create them. And in fact, they cannot, > unless they cheat. > I would as well add the formula for the potion of cold immunity to that > list, but it currently has a small but existing chance to appear. As I mentioned earlier, I would also like to lock that potion. But this is only a suggestion. > > P.S.: Did you know that there are <...> only two maps in which one can > > find Ancient dragons (and the corresponding dragon steaks required for > > entering the dragon training levels)? > Nice statistics... Perhaps this one is not very player-friendly. Well, the entrance to the dragon training levels requires three sacrifices (Ancient dragon's steak, ancient red dragon's steak and Acient Blue Dragon's steak). That map is in /dungeons/train/dragon_train. The sacrificed items are difficult to find but I think that it was done on purpose. However, it would have been nice to give a few hints about where these items can be found. In fact, one of the reasons why I wrote my map checking script is because I could not find one of these 3 dragons' steaks, even though I had no problems finding the items required for the other training levels (undead, humanoid, etc.). So I wrote the script in order to check if I had overlooked some area of if that training map was broken because it was asking for an item that does not exist in the game. I will let you guess what the answer is. -Rapha?l From antonoussik at gmail.com Wed May 24 15:10:40 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Wed, 24 May 2006 21:10:40 +0100 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <20060524164622.359ee956.raphael@gimp.org> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> <1148475377.16489.100.camel@localhost.localdomain> <20060524164622.359ee956.raphael@gimp.org> Message-ID: On 24/05/06, Rapha?l Quinet wrote: > On Wed, 24 May 2006 14:56:16 +0200, Wim Villerius wrote: > > On Mon, 2006-05-22 at 20:50 +0200, Rapha?l Quinet wrote: > > > Also, shadow alchemy is player knowledge and not character knowledge: > > > this gives an unfair advantage to experienced players regardless of > > > their character level. > > Yes, shadow alchemy is player knowledge, not character knowledge. But > > the same goes for current alchemy, maps (passwords), where to find > > artifacts, how to beat monsters, etc etc. In other words, (almost) the > > whole game is player knowledge. > Well, it is worse for shadow alchemy: it is player knowledge that is very > hard to acquire while playing, but easy to remember (or write down) once > someone or some program tells you how to do it. So it is a bit like "cheat > codes" for the game. The shadow formulas are of very little use for the > normal players. Which is why I proposed the dynamic dynamnic alchemy - there are no formulae, and a beginner player has the same knowlege as an experienced player, and the result is bounded only by their level at the skill. It will allow a huge amount of new items to exist, since generally it will be possible to create any item at all, which can not be obtained otherwise, thus encouraging trade and inter-player interaction. If you further want to restrict it, you can say that ingredient foo is needed for max transferred property to be 40%, bar for 60%, and so on, but I don't think it is a good idea since it will make alchemy too troublesome to use again. If you see a problem with overpowered items, perhaps created items need their item_power adjusted, so any super-times will be unwieldable because of the item_power requirements. > On the other hand, the most powerful recipes should be > locked because they are quest items. Even if I remember how to create the > potion of fire immunity, I do not expect to be able to use it immediately > when I create a new character: I know that I have to go through the fire > temple first. Although I do not think recipes should be locked as it restricts players, I see a better way of locking them, if that is what everyone wants. Recipe learning can be made to work just like spell books. I.E. you apply a recipe book, and memorise the recipe. After that you should be able to recite it, and when you try performing it, alchemy code should check if you have learnt the recipe in the past. This approach will be much more consistent with the rest of C.F. than arbritrarily locking some recipes. From mwedel at sonic.net Thu May 25 00:34:18 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 24 May 2006 22:34:18 -0700 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <1148480195.16489.112.camel@localhost.localdomain> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> <20060524143401.419fdbfc.quinet@gamers.org> <1148480195.16489.112.camel@localhost.localdomain> Message-ID: <447541DA.4040106@sonic.net> I think the general balance issue on apply dynamic alchemy to any object is basically this: If the same rules apply for all armor type items (boots, gloves, helmet, shield, girdle, bracers, and the armor itself), players can really crank up their power. For most of those, there is a limit on how good you can find (and the good ones are generally artifact level, so pretty hard). But if through shadow alchemy I can make decent (say resist +25%, or ones that give me stats) at some reasonable level (say 20), it now can become pretty easy to run around with 50% resistance in everything, or perhaps more a problem straight 30 stats (make that +2 int helmet, +2 con shield, etc). The armors that give out stat bonuses is really pretty limited right now. Of course, various controls can be put in place to prevent this (limit stats based on different objects, etc), but this then starts to make a more complicated system - such controls should be done in a file, not hardcoded, and this starts to look like a formula file in a different regard. We should assume that clever players will likely figure out how to create whatever they want - we shouldn't believe that having imprecise or random effects will limit it - all that will really happen is that players will pretty much only use the objects that give them the needed effects. From mwedel at sonic.net Thu May 25 01:04:32 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 24 May 2006 23:04:32 -0700 Subject: [crossfire] New layer code bug :) In-Reply-To: <1148456658.16489.84.camel@localhost.localdomain> References: <200605240023.09744.nicolas.weeger@laposte.net> <4473FEF6.9040809@sonic.net> <1148456658.16489.84.camel@localhost.localdomain> Message-ID: <447548F0.2070501@sonic.net> Wim Villerius wrote: >> Would be interested in more details on that, especially if you can get a >> reproducible test case. > Not exactly the case Nicolas describes, but try the following: cast > counterwall and walk in it. You'll see yourself disappearing. (This > works for any spell I've seen) > Or find a pile of treasure and step in it, you'll likely have to search > for yourself :) Update to the latest client :) You are apparantly not using the latest CVS client which uses a different draw logic. For that compatible mode, I'll put some logic in place so that the player is always drawn, but may not always be on the top. From fuchs.andy at gmail.com Thu May 25 16:29:00 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu, 25 May 2006 17:29:00 -0400 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <447541DA.4040106@sonic.net> References: <1143480087.14079.216.camel@localhost.localdomain> <1147941265.3001.33.camel@localhost.localdomain> <20060522205014.0737b276.quinet@gamers.org> <20060524143401.419fdbfc.quinet@gamers.org> <1148480195.16489.112.camel@localhost.localdomain> <447541DA.4040106@sonic.net> Message-ID: I think one way to take care of the maximum enhancements, etc would be to base it off of the materials. Make some materials harder to enhance/morph than others, and cap based on the material. This also will provide an explanation for role playing. -- Andrew Fuchs From nicolas.weeger at laposte.net Thu May 25 16:59:58 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 25 May 2006 23:59:58 +0200 Subject: [crossfire] Balm of return home Message-ID: <200605252359.58943.nicolas.weeger@laposte.net> Hello. Currently, balms of protection and such work correctly even on unholy grounds. On the other hand, balm of return home (word of recall) doesn't work. This because when it actually executes it checks again whether ground is holy or not, thus it can fail. I think we could make its behaviour coherent with other balms, and enable balm of return home to work even on holy ground. It would even make sense again to actually use alchemy to create some :) My proposed fix is to set the DM_FLAG to the word of recall's spell effect (in cast_word_of_recall), and check that in the execute_word_of_recall function. To do that, I'd say to just set that flag on the balm itself (since the balm merely contains the spell). Opinions, comments and criticism welcome :) Nicolas From mwedel at sonic.net Fri May 26 00:56:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 25 May 2006 22:56:33 -0700 Subject: [crossfire] Balm of return home In-Reply-To: <200605252359.58943.nicolas.weeger@laposte.net> References: <200605252359.58943.nicolas.weeger@laposte.net> Message-ID: <44769891.6050504@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > Currently, balms of protection and such work correctly even on unholy grounds. > On the other hand, balm of return home (word of recall) doesn't work. This > because when it actually executes it checks again whether ground is holy or > not, thus it can fail. > > I think we could make its behaviour coherent with other balms, and enable balm > of return home to work even on holy ground. It would even make sense again to > actually use alchemy to create some :) > > My proposed fix is to set the DM_FLAG to the word of recall's spell effect (in > cast_word_of_recall), and check that in the execute_word_of_recall function. > To do that, I'd say to just set that flag on the balm itself (since the balm > merely contains the spell). > > Opinions, comments and criticism welcome :) The reason word of recall (the force that recalls you) doesn't work on unholy ground is so that you can't cast word of recall, go into a shop, and get a bunch of unpaid stuff. I suppose the better fix is not to prevent the word of recall, but just strip any unpaid objects from the player and drop them back on the map. That said, I think no magic/no cleric spells are used too often in maps as 'hey, lets make it hard so you can't cast spells', which I don't think is an especially good map design. > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From nicolas.weeger at laposte.net Fri May 26 03:44:48 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 26 May 2006 10:44:48 +0200 Subject: [crossfire] Fwd: Mail delivery failed: returning message to sender Message-ID: <200605261044.49006.nicolas.weeger@laposte.net> Anyone getting those messages when committing stuff? Nicolas ------------------------------------------------------------------------------------------------------- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: crossfire-cvs at lists.sourceforge.net SMTP error from remote mailer after RCPT TO:: host sc8-sf-list1-new-b.sourceforge.net [10.3.1.93]: 550 Unknown user ------ This is a copy of the message, including all the headers. ------ Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1FjXsG-00075h-Io for crossfire-cvs at lists.sourceforge.net; Fri, 26 May 2006 01:40:48 -0700 Received: from mx-outbound.sourceforge.net ([66.35.250.223] helo=sc8-sf-sshgate.sourceforge.net) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1FjXsG-0004t2-Gj for crossfire-cvs at lists.sourceforge.net; Fri, 26 May 2006 01:40:48 -0700 Received: from sc8-pr-cvs4-b.sourceforge.net ([10.5.1.174] helo=sc8-pr-cvs4.sourceforge.net) by sc8-sf-sshgate.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FjXsC-0002EF-W0 for crossfire-cvs at lists.sourceforge.net; Fri, 26 May 2006 01:40:45 -0700 Received: from ryo_saeba by sc8-pr-cvs4.sourceforge.net with local (Exim 4.43) id 1FjXsB-0002ZO-Ti for crossfire-cvs at lists.sourceforge.net; Fri, 26 May 2006 01:40:44 -0700 From: Nicolas Weeger Subject: CVS commit: arch/monster/insect To: crossfire-cvs at lists.sourceforge.net Reply-To: ryo_saeba at users.sourceforge.net Message-Id: Date: Fri, 26 May 2006 01:40:43 -0700 X-Spam-Score: -2.8 (--) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 -2.8 ALL_TRUSTED Did not pass through any untrusted hosts Module Name: arch Committed By: ryo_saeba Date: Fri May 26 08:40:43 UTC 2006 Modified Files: arch/monster/insect: centipede.arc centipede.base.111.png centipede.base.112.png centipede.base.113.png Added Files: arch/monster/insect: centipede.base.114.png centipede.base.121.png centipede.base.122.png centipede.base.123.png centipede.base.124.png centipede.base.131.png centipede.base.132.png centipede.base.133.png centipede.base.134.png centipede.base.141.png centipede.base.142.png centipede.base.143.png centipede.base.144.png centipede.base.151.png centipede.base.152.png centipede.base.153.png centipede.base.154.png centipede.base.161.png centipede.base.162.png centipede.base.163.png centipede.base.164.png centipede.base.171.png centipede.base.172.png centipede.base.173.png centipede.base.174.png centipede.base.181.png centipede.base.182.png centipede.base.183.png centipede.base.184.png Log Message: Another test, feel free to revert :) Start of context diffs Index: arch/monster/insect/centipede.arc diff -c arch/monster/insect/centipede.arc:1.2 arch/monster/insect/centipede.arc:1.3 *** arch/monster/insect/centipede.arc:1.2 Sun Jun 4 16:25:41 2000 --- arch/monster/insect/centipede.arc Fri May 26 01:40:42 2006 *************** *** 10,18 **** --- 10,48 ---- weight -1 no_pick 1 anim + facings 8 centipede.111 centipede.112 centipede.113 + centipede.114 + centipede.121 + centipede.122 + centipede.123 + centipede.124 + centipede.131 + centipede.132 + centipede.133 + centipede.134 + centipede.141 + centipede.142 + centipede.143 + centipede.144 + centipede.151 + centipede.152 + centipede.153 + centipede.154 + centipede.161 + centipede.162 + centipede.163 + centipede.164 + centipede.171 + centipede.172 + centipede.173 + centipede.174 + centipede.181 + centipede.182 + centipede.183 + centipede.184 mina monster 1 sleep 1 Index: arch/monster/insect/centipede.base.111.png Index: arch/monster/insect/centipede.base.114.png From tchize at myrealbox.com Fri May 26 06:08:48 2006 From: tchize at myrealbox.com (tchize) Date: Fri, 26 May 2006 13:08:48 +0200 Subject: [crossfire] Balm of return home In-Reply-To: <200605252359.58943.nicolas.weeger@laposte.net> References: <200605252359.58943.nicolas.weeger@laposte.net> Message-ID: <4476E1C0.9040100@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am against for the following reasons: - - any priest spell, whatever the way they are invoked, should be forbidden on holy ground - - abuse of a flag dedicated to dungeon masters should never be done - - word of recall is something magical and shouldn't have effect when you are forbidden, be it by using balms or anything. Really am quite surprised other balms goes around this restriction. They could be fixed. - - as i understand protection balms have nothing to do with magic, they are made of plants or other products to provide a natural protection. (Like sun protecting balm you put when you go to the beach). They just use the same code routines as spells. For return home this is clearly something magical. Maybe it should be replaced by a potion of return home, so you know it can fail and is magical. Tchize Nicolas Weeger (Laposte) a ?crit : > Hello. > > Currently, balms of protection and such work correctly even on > unholy grounds. On the other hand, balm of return home (word of > recall) doesn't work. This because when it actually executes it > checks again whether ground is holy or not, thus it can fail. > > I think we could make its behaviour coherent with other balms, and > enable balm of return home to work even on holy ground. It would > even make sense again to actually use alchemy to create some :) > > My proposed fix is to set the DM_FLAG to the word of recall's spell > effect (in cast_word_of_recall), and check that in the > execute_word_of_recall function. To do that, I'd say to just set > that flag on the balm itself (since the balm merely contains the > spell). > > Opinions, comments and criticism welcome :) > > Nicolas > > _______________________________________________ crossfire mailing > list crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEduHAHHGOa1Q2wXwRAoulAKCqtmzjaiu/dUYQmw+75IOWJXLsUgCg8iON Y+l3UChnes+YFkyauFQCJMo= =B7+h -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Sun May 28 12:08:15 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 28 May 2006 19:08:15 +0200 Subject: [crossfire] On item perspective and monster size Message-ID: <200605281908.15631.nicolas.weeger@laposte.net> Hello. Unless I'm totally blind, current items's perspective is: * straight top-down view for ground, shop tiles, and such * top-down view with an angle, maybe around 30 or 45? (so the "bottom" is closed for user than the "top"), for walls, monsters, buildings, and many things * either top, with (books) or without perspective or side view for other items (equipment, shields, ...) If this isn't totally wrong, I think some monsters have a strange size. For instance, a red dragon is 3 tiles horizontal and 2 vertical, for an east- or west-looking pic. Accordingly, the north- or south-looking pic should be the same 3x2 size (unless the code supports different pic sizes for different directions, something I seriously doubt), and the monster will look quite certainly squished. So shouldn't the dragon (and many other monsters) be rather 3x3, or 2x3? Of course, that would mean changing many maps :) What do you think? Nicolas From nicolas.weeger at laposte.net Sun May 28 12:09:19 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 28 May 2006 19:09:19 +0200 Subject: [crossfire] Partial transparency Message-ID: <200605281909.19083.nicolas.weeger@laposte.net> Hello. GTK client (I didn't test the other clients) doesn't seem to support partial pic transparency. Has anyone tried to implement that? I'm asking because my centipede would look much nicer :) Nicolas From alex_sch at telus.net Sun May 28 21:08:42 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 28 May 2006 20:08:42 -0600 Subject: [crossfire] On item perspective and monster size In-Reply-To: <200605281908.15631.nicolas.weeger@laposte.net> References: <200605281908.15631.nicolas.weeger@laposte.net> Message-ID: <447A57AA.60609@telus.net> Nicolas Weeger (Laposte) wrote: >* straight top-down view for ground, shop tiles, and such >* top-down view with an angle, maybe around 30 or 45? (so the "bottom" is >closed for user than the "top"), for walls, monsters, buildings, and many >things > Well, for ground tiles, most of them could go under either 'top-down view with an angle' or 'straight top-down', a cobblestone tile for instance Alex Schultz From mwedel at sonic.net Mon May 29 02:55:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 29 May 2006 00:55:52 -0700 Subject: [crossfire] Partial transparency In-Reply-To: <200605281909.19083.nicolas.weeger@laposte.net> References: <200605281909.19083.nicolas.weeger@laposte.net> Message-ID: <447AA908.9080603@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > GTK client (I didn't test the other clients) doesn't seem to support partial > pic transparency. > > Has anyone tried to implement that? > > I'm asking because my centipede would look much nicer :) IIRC, gtk has no convenient way on handling the alpha channel (the inconvenient way would be for the program to figure it all on its own, figuring out the appropriate RGB values, and then drawing those point by point to the screen. This is also pretty CPU intensive). So I don't expect to add that support anytime soon (it would basically be a complete re-write of how images are handled). The opengl draw mode of the gtkv2 client most certainly does handle partial transparencies, but I've never tested it (ok, most certainly might be an over statement). However, opengl handles alpha channel images, and the client is just passing the data to opengl, so it should all work. And since the blending will be done by your graphics card (if supported) it should be quite fast. That said, opengl support is only in the gtkv2 client (but probably would be pretty easy to port back to the gtkv1 client). Also, only supported on unix/X11 right there. There are I think 20-30 lines of code in the file related to initializing opengl with X11 - for windows or other OS's, those would need to be rewritten to use whatever the proper native code needs to be. I believe the SDL draw mode (in both gtkv1 and gtkv2, but IMO, with opengl mode, SDL mode should go away) also supports alpha channel values. Once again, I don't know if this has ever been tested, but SDL does, and like opengl, we're jsut passing the data to SDL to handle, so it should be doing the right thing. That said, my experience with SDL is that it is relatively slow - I think that the blending is being done by the main cpu, and not the gpu. However, with a fast enough cpu this probably still works. > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Mon May 29 03:10:07 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 29 May 2006 01:10:07 -0700 Subject: [crossfire] On item perspective and monster size In-Reply-To: <200605281908.15631.nicolas.weeger@laposte.net> References: <200605281908.15631.nicolas.weeger@laposte.net> Message-ID: <447AAC5F.80400@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > Unless I'm totally blind, current items's perspective is: > * straight top-down view for ground, shop tiles, and such > * top-down view with an angle, maybe around 30 or 45? (so the "bottom" is > closed for user than the "top"), for walls, monsters, buildings, and many > things > * either top, with (books) or without perspective or side view for other items > (equipment, shields, ...) > > If this isn't totally wrong, I think some monsters have a strange size. For > instance, a red dragon is 3 tiles horizontal and 2 vertical, for an east- or > west-looking pic. Accordingly, the north- or south-looking pic should be the > same 3x2 size (unless the code supports different pic sizes for different > directions, something I seriously doubt), and the monster will look quite > certainly squished. That's a tricky question. The server code, in terms of what spaces it believes the objects are on, can not switch between 2x3 and 3x2. However, with merged images, there isn't any requirement that all the images be the same size. So different facings could be different sizes. However, for the dragon, that probably wouldn't be the right thing, as the player would find it hard to really know where the dragon is and is not. I can't actually think of any cases where it would be appropriate for the image sizes to be radically different based on facing. > So shouldn't the dragon (and many other monsters) be rather 3x3, or 2x3? The dragon (and things like wyverns) are an oddity, as just from what they look like, they certainly are not square. I'm not sure what the fix for the wyvern would be - can't really make it 1x1, and I think making it 2x2 wouldn't look right either. The correct approach could in fact modify the server so a multipart creature could swap between 1x2 and 2x1. But that is tricky, because a lot of the code looks at op->arch->clone.[xy] to know how the pieces go. One way that could perhaps be done is make two archetypes, one east/west, one north/south, with one being 1x2 and one 2x1. Then the code that changes direction could change the op->arch to point to the right image. However, this would make the move code really complicated, as if the creature was in a narrow hall, there isn't space for it to turn north/south. I think the move code would have to be modified to check both archs to see if it can fit by changing directions (this would be necessary for it to turn the turn in a narrow passage for example). That isn't a minor change. That said, for humanoids (giants, titans, etc), they could be changed to have a square base (1x1, 2x2, etc) with the big image just extending above them. However, this will result in the case of a player potentially be obscured by the creature (a titan right now is 3x5 I think, but should be 3x3. If you're attacking from the north, you'd be underneath/behind the 2 spaces that still extend upwards. You could draw the player on top of the titan, but that would look pretty bizarre from a perspective side of things). From alex_sch at telus.net Mon May 29 07:06:09 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 29 May 2006 06:06:09 -0600 Subject: [crossfire] Partial transparency In-Reply-To: <447AA908.9080603@sonic.net> References: <200605281909.19083.nicolas.weeger@laposte.net> <447AA908.9080603@sonic.net> Message-ID: <447AE3B1.9070607@telus.net> Mark Wedel wrote: > IIRC, gtk has no convenient way on handling the alpha channel (the >inconvenient way would be for the program to figure it all on its own, figuring >out the appropriate RGB values, and then drawing those point by point to the >screen. This is also pretty CPU intensive). So I don't expect to add that >support anytime soon (it would basically be a complete re-write of how images >are handled). > Actually, gtk does support it through this api: http://www.gtk.org/api/2.6/gdk/gdk-Drawing-Primitives.html#gdk-draw-pixbuf However it isn't necessarily fast, but I believe on modern machines, given how little crossfire redraws compared to most things, this cost would not be that significant. Alex Schultz From mwedel at sonic.net Tue May 30 00:02:29 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 29 May 2006 22:02:29 -0700 Subject: [crossfire] Partial transparency In-Reply-To: <447AE3B1.9070607@telus.net> References: <200605281909.19083.nicolas.weeger@laposte.net> <447AA908.9080603@sonic.net> <447AE3B1.9070607@telus.net> Message-ID: <447BD1E5.8000801@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > >> IIRC, gtk has no convenient way on handling the alpha channel (the >> inconvenient way would be for the program to figure it all on its own, figuring >> out the appropriate RGB values, and then drawing those point by point to the >> screen. This is also pretty CPU intensive). So I don't expect to add that >> support anytime soon (it would basically be a complete re-write of how images >> are handled). >> > Actually, gtk does support it through this api: > http://www.gtk.org/api/2.6/gdk/gdk-Drawing-Primitives.html#gdk-draw-pixbuf > However it isn't necessarily fast, but I believe on modern machines, > given how little crossfire redraws compared to most things, this cost > would not be that significant. Not sure of that. On my old system (dual athlon mp 2000), for it to redraw the entire 25x25 map each tick, it really taxes the machine. Right now, for the gtk1 client, it only redraws what changes so isn't as much an issue. I can't remember what I did for the gtkv2 client (I thought I just grabbed the gtkv1 logic, but too lazy to look). But poking in the gtk source code, it does appear it is relatively clever in its drawing logic, using shared memory and xrender extension, so performance may actually not be that bad. It'd perhaps be interesting to convert the gtk draw code to use the gdkpixbufs instead of the gdkpixmaps and see how much a performance difference there is just for standard images, and then start throwing in some transparent images. This actually is somewhat relevant, because with my proposed lighting redo, only draw mechanisms that actually have some form of alpha or lighting logic will be able to use it. So for the current gtk logic, can't really do too much given what is there. From mwedel at sonic.net Tue May 30 01:23:21 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 29 May 2006 23:23:21 -0700 Subject: [crossfire] New layer code bug :) In-Reply-To: <200605240023.09744.nicolas.weeger@laposte.net> References: <200605240023.09744.nicolas.weeger@laposte.net> Message-ID: <447BE4D9.7010305@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > Metalforge having been updated, I'm using the new mapcmd2 protocol, and > noticed somee fun bugs :) > > First (no screen copy, sorry), sometimes 1 item only will appear from a pile, > sometimes 2 items (without any monster) I found the bug on that - will commit fix tonight. > Second, traps seem to appear above player I made a change so that doesn't happen. But that doesn't appear right (the old logic draw them atop of the player). But mostly, drawing it below the player for many objects doesn't make it all that visible. That is probably why they were originally done so that they were drawn atop the player - to make sure they are visible. So this isn't a hard thing to change, just not sure if it should be changed. > Third, some items appear above player (see screenshot) Fixed that also. From mwedel at sonic.net Tue May 30 02:08:28 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 30 May 2006 00:08:28 -0700 Subject: [crossfire] Fwd: Mail delivery failed: returning message to sender In-Reply-To: <200605261044.49006.nicolas.weeger@laposte.net> References: <200605261044.49006.nicolas.weeger@laposte.net> Message-ID: <447BEF6C.20606@sonic.net> Nicolas Weeger (Laposte) wrote: > Anyone getting those messages when committing stuff? > > Nicolas Nope, and I just committed a bunch of stuff. I suppose you could always open a ticket with the sourceforge support folks and see what is up. Is it a continuous problem, or some more random? From cher at riedquat.de Sat May 27 07:42:28 2006 From: cher at riedquat.de (Christian Hujer) Date: Sat, 27 May 2006 14:42:28 +0200 Subject: [crossfire] Project Gridarta started Message-ID: <200605271442.28784.cher@riedquat.de> Dear People, (intended audience: map makers, active gamers and developers of crossfire and derived mmorpgs, especially angelion, crossfire, daimonin) The DaimoninEditor, Daimonin's successor of the CFJavaEditor, has "grown up" and become a sourceforge project of its own. It is called "Gridarta" now. The name Gridarta combines "grid" and "art" and coincidently also reminds of "Siddhartha". The project "Gridarta" was founded by zergus and me (Cher). @devs: I hope I have added all relevant (in the sense of interested in active Java map editor development) developers of Crossfire and Daimonin to the Gridarta development team. If you think you should belong there but were forgotten, please send me an e-mail. IMPORTANT @devs: Also don't forget to subscribe the gridarta mailling lists. @all: read more on the new gridarta homepage http://gridarta.sourceforge.net/ CURRENT PROJECT PLAN 1. Import source of both, Crossfire and Daimonin's Java map editors in Gridarta. (done) 2. Setup build environment which fits the needs of both projects. (done) 3. Release the first version of Gridarta for Daimonin. 4. Replace Daimonin's Java map editor in Daimonin's cvs repository with something that gets Gridarta instead. 5. Merge Crossfire's editor into Daimonin's editor, whilst creating a test suite which performs the required tests whether gridarta works correctly with current crossfire resp. daimonin data. FINAL STATEMENT Long live Crossfire and Daimonin! Happy mapping :) -- Christian Hujer Free software developer E-Mail: cher at riedquat.de WWW: http://www.riedquat.de/ From fuchs.andy at gmail.com Tue May 30 15:04:53 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Tue, 30 May 2006 16:04:53 -0400 Subject: [crossfire] Partial transparency In-Reply-To: <447BD1E5.8000801@sonic.net> References: <200605281909.19083.nicolas.weeger@laposte.net> <447AA908.9080603@sonic.net> <447AE3B1.9070607@telus.net> <447BD1E5.8000801@sonic.net> Message-ID: Just want to note that one trick used by mikeeusa and inycino on cat2 (mikeeusa was letting players customize their gfx if they reached a certian level), was to use a checkerboard pattren of transparent/nontransparent pixels, to achive a ghostly effect. -- Andrew Fuchs From nicolas.weeger at laposte.net Tue May 30 16:31:37 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 30 May 2006 23:31:37 +0200 Subject: [crossfire] Fwd: Mail delivery failed: returning message to sender In-Reply-To: <447BEF6C.20606@sonic.net> References: <200605261044.49006.nicolas.weeger@laposte.net> <447BEF6C.20606@sonic.net> Message-ID: <200605302331.37803.nicolas.weeger@laposte.net> > Nope, and I just committed a bunch of stuff. I suppose you could always > open a ticket with the sourceforge support folks and see what is up. Is it > a continuous problem, or some more random? I had it the last 2 or 3 times I committed, but it was the same day - maybe a limited outage. I'll open a ticket if I have another issue next time I commit :) Nicolas From nicolas.weeger at laposte.net Tue May 30 16:32:36 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 30 May 2006 23:32:36 +0200 Subject: [crossfire] Partial transparency In-Reply-To: <447BD1E5.8000801@sonic.net> References: <200605281909.19083.nicolas.weeger@laposte.net> <447AE3B1.9070607@telus.net> <447BD1E5.8000801@sonic.net> Message-ID: <200605302332.37023.nicolas.weeger@laposte.net> > But poking in the gtk source code, it does appear it is relatively clever > in its drawing logic, using shared memory and xrender extension, so > performance may actually not be that bad. It'd perhaps be interesting to > convert the gtk draw code to use the gdkpixbufs instead of the gdkpixmaps > and see how much a performance difference there is just for standard > images, and then start throwing in some transparent images. Let's just hope those tricks, if we use them, work under Windows & Mac & other platforms too :) Nicolas From alex_sch at telus.net Tue May 30 17:26:19 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 30 May 2006 16:26:19 -0600 Subject: [crossfire] Partial transparency In-Reply-To: References: <200605281909.19083.nicolas.weeger@laposte.net> <447AA908.9080603@sonic.net> <447AE3B1.9070607@telus.net> <447BD1E5.8000801@sonic.net> Message-ID: <447CC68B.3060403@telus.net> Andrew Fuchs wrote: >Just want to note that one trick used by mikeeusa and inycino on cat2 >(mikeeusa was letting players customize their gfx if they reached a >certian level), was to use a checkerboard pattren of >transparent/nontransparent pixels, to achive a ghostly effect. > On high resolution displays this effect can even fool one into thinking it's partial transparency if they're not looking rather closely. Also, quickly noting, mikee and inycino are not the first to do this, some existing crossfire monsters already do this ;-) Alex Schultz From alex_sch at telus.net Tue May 30 17:33:41 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 30 May 2006 16:33:41 -0600 Subject: [crossfire] Partial transparency In-Reply-To: <200605302332.37023.nicolas.weeger@laposte.net> References: <200605281909.19083.nicolas.weeger@laposte.net> <447AE3B1.9070607@telus.net> <447BD1E5.8000801@sonic.net> <200605302332.37023.nicolas.weeger@laposte.net> Message-ID: <447CC845.9090307@telus.net> Nicolas Weeger (Laposte) wrote: >> But poking in the gtk source code, it does appear it is relatively clever >>in its drawing logic, using shared memory and xrender extension, so >>performance may actually not be that bad. It'd perhaps be interesting to >>convert the gtk draw code to use the gdkpixbufs instead of the gdkpixmaps >>and see how much a performance difference there is just for standard >>images, and then start throwing in some transparent images. >> >> > >Let's just hope those tricks, if we use them, work under Windows & Mac & other >platforms too :) > I don't think those particular tricks wouldn't work on windows, and for Mac + X11 the shared memory might work but not xrender. However if gtk is built with cairo support and cairo is build with glitz support (used for an opengl backend), it might be possible that that gtk renders could be accelerated on all platforms supporting opengl Alex Schultz From tchize at myrealbox.com Wed May 31 02:28:47 2006 From: tchize at myrealbox.com (Tchize) Date: Wed, 31 May 2006 09:28:47 +0200 Subject: [crossfire] Fwd: Mail delivery failed: returning message to In-Reply-To: <200605302331.37803.nicolas.weeger@laposte.net> References: <200605261044.49006.nicolas.weeger@laposte.net> <447BEF6C.20606@sonic.net> <200605302331.37803.nicolas.weeger@laposte.net> Message-ID: <447D45AF.2010202@myrealbox.com> Sourceforge status page states mailing lists at sourceforge are down Nicolas Weeger (Laposte) wrote: >> Nope, and I just committed a bunch of stuff. I suppose you could always >> open a ticket with the sourceforge support folks and see what is up. Is it >> a continuous problem, or some more random? >> > > I had it the last 2 or 3 times I committed, but it was the same day - maybe a > limited outage. > I'll open a ticket if I have another issue next time I commit :) > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From bogus@does.not.exist.com Fri May 26 14:39:30 2006 From: bogus@does.not.exist.com () Date: Fri, 26 May 2006 19:39:30 -0000 Subject: No subject Message-ID: a new branch, and on on the list of version control system criteria that Mark posted, which I based the matrix on, doing tags AS a 'branch', like SVN does doesn't count. (also if one were to count what SVN does for 'tags' as being sufficient, Mercurial should also get a 'Yes') > The ability to do local branch (which is suppose mean creating a local > repository, working on it and then push your local repository branch to > main server) is marked as 'no' for svn, but according to some doc, it > can be done with SVN-Mirror or SVN-Pusher, it's client side tools you > can install to create your own repository. > I've never heard of SVN-Pusher, and only vaguely remember hearing of SVN-Mirror, but personally, if I want to use local branches frequently (which I have often found myself wanting to), I'm not sure I would trust SVN-Mirror and SVN-Pusher to handle all of the obscure cases of merging, or how well SVN-Mirror handles incremental changes, compared to systems that are designed with local branching in mind. Also, I wouldn't really like having to rely on a separate perl tool for such functionality. > Tracking when merge are done is not No on svn, but svn docs about > branching and merging explicitly explain how to track it efficiently and > easily. > I think I found the documentation you're referring to: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.track And yes, it's not hard to track it manually, but I would consider automatic tracking of such like distributed systems do to be a major advantage with regards to branching. > I have never heard of darcs, bzr and hg before, but if we get to free > hosting service for those tool, we need to ensure those service won't > disappear in the next 3 years. Sourceforge is a solid corporation held > by VA linux. > Well, in terms of bzr, launchpad.net hosts bzr repositories for projects, and that's funded by Canonical Ltd. (the people who fund Ubuntu), so I doubt that would be going away for quite some time. For mercurial, as I mentioned in a different message, Dotsrc.org (formerly SunSITE.dk) looks like a possible option, and they have numerous corporate sponsors (including Sun, HP, and many others), not to mention how I've seen sunsite.dk mirrors of things around for a very long time, so I doubt they'll be going away. > The best solution to decide will probably be a vote amongst commiters as > everyone probably has it's preferences. Agreed. Alex Schultz