From kbulgrien at att.net Mon Mar 1 17:36:15 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon, 1 Mar 2010 17:36:15 -0600 Subject: [crossfire] Release? In-Reply-To: <201002282150.55437.nicolas.weeger@laposte.net> References: <201002282150.55437.nicolas.weeger@laposte.net> Message-ID: <20100301173615.3e135cf2@a850srvr.kbulgrien.att.net> > Hello. > > What about we just decide to do a release of trunk end of march? > Whatever it is called, 1.5, 2.0, 1.9, and such :) > > Then let's kill branch, and work on trunk. > > > Does that sound ok? Sure - though perhaps my recent inactivity lowers the weight of the vote. It has gotten to the point where gtk-v2 being incompatible with metalforge is really annoying - getting bug reports that aren't bugs... though that it not strictly the issue with killing branch. It's too bad I ran into RL issues about the time I was ready to release a snapshot of gtk-v2. If branch servers persist, it's annoying enough to probably release a snapshot at the point just before compatibility was broken, though that seems a drain of effort that would be best put to other purposes. From agschult at ucalgary.ca Mon Mar 1 19:32:18 2010 From: agschult at ucalgary.ca (Alex Schultz) Date: Mon, 1 Mar 2010 18:32:18 -0700 Subject: [crossfire] Release? In-Reply-To: <201002282150.55437.nicolas.weeger@laposte.net> References: <201002282150.55437.nicolas.weeger@laposte.net> Message-ID: <20100301183218.77d85942@ucalgary.ca> I haven't been very active with things these days, but I'd be in agreement with a release being made. My one reservation is that of those options, I wouldn't want it numbered 2.0 since I don't think enough has happened to justify that yet. Alex Schultz On Sun, 28 Feb 2010 21:50:50 +0100 Nicolas Weeger wrote: > Hello. > > What about we just decide to do a release of trunk end of march? > Whatever it is called, 1.5, 2.0, 1.9, and such :) > > Then let's kill branch, and work on trunk. > > > Does that sound ok? > > > > Nicolas From leaf at real-time.com Tue Mar 2 15:54:38 2010 From: leaf at real-time.com (Rick Tanner) Date: Tue, 02 Mar 2010 15:54:38 -0600 Subject: [crossfire] Scorn house of healing tweaks In-Reply-To: <201002281255.27493.nicolas.weeger@laposte.net> References: <201002281255.27493.nicolas.weeger@laposte.net> Message-ID: <4B8D891E.3030004@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > By a suggestion from Ragnor, I tweaked the house of healing in Scorn. > > Now the priest will remove depletions if the player knows answers to some > basic questions. Right now only 2 questions, pretty easy for players to know > I hope :) > Depletion removal is equivalent to a minor potion of life (level 5). Very good idea! How will, or are players, aware of such feature or service? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLjYkdhHyvgBp+vH4RAiWUAJ0brkAjg5HEMwIJA1SHsIsFEx2YsgCfYTiJ jD3xSmprdEdjJF3/34fIfDU= =tI0f -----END PGP SIGNATURE----- From leaf at real-time.com Tue Mar 2 15:59:03 2010 From: leaf at real-time.com (Rick Tanner) Date: Tue, 02 Mar 2010 15:59:03 -0600 Subject: [crossfire] Scorn house of healing tweaks In-Reply-To: <201002281255.27493.nicolas.weeger@laposte.net> References: <201002281255.27493.nicolas.weeger@laposte.net> Message-ID: <4B8D8A27.1020300@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Now the priest will remove depletions if the player knows answers to some > basic questions. Right now only 2 questions, pretty easy for players to know > I hope :) > Depletion removal is equivalent to a minor potion of life (level 5). > > For higher level restorations, probably require some junk from dungeons, orc > chops, such things - if someone has good ideas, feel free to tell us ;) For the player who recently leveled up and their supply of Potions of Life no longer work on them.. The ability to trade some amount those in for this spell casting service? Trying to make trade-ins for the House of Healing fall in line with what the map actually provides.. Trade X amount of potions of healing in for restoration service? Same could be said for healing staffs, prayer books, holy symbols, balms. Also, alchemy ingredients used to make healing items or components. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLjYonhHyvgBp+vH4RArIYAJ9xefXzzP15Nsnjrq13FtW16HgIeQCfYHaT 8NMw/mIqWUfJv/cKmDf6CCU= =jPZy -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Mar 3 02:04:10 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 03 Mar 2010 00:04:10 -0800 Subject: [crossfire] Release? In-Reply-To: <20100301183218.77d85942@ucalgary.ca> References: <201002282150.55437.nicolas.weeger@laposte.net> <20100301183218.77d85942@ucalgary.ca> Message-ID: <4B8E17FA.4000301@sonic.net> On 03/ 1/10 05:32 PM, Alex Schultz wrote: > I haven't been very active with things these days, but I'd be in > agreement with a release being made. My one reservation is that of > those options, I wouldn't want it numbered 2.0 since I don't think > enough has happened to justify that yet. Making a release seems like a good idea. I'm not quite sure what to call it. The previous releases were 1.x.y, and x had got up to 11 (1.11.0) So 1.5, or even 1.9, don't really work as numbers, since they would be very confusing with the 1.5.0 or 1.9.0 release I'm not sure if anything too much should be read into version numbers. Some projects cycle through major numbers without it being any big deal, others treat it as a very serious manner and have criteria for increase in major version. We could just jump to 1.20.0, to sort of note that this is a bit different than the branch, but still largely compatible with it. I'd sort of like to reserve the major release numbers (2.0, 3.0, etc) to note when compatibility really just breaks - eg, moving to 2.0 means you really can't move forward any 1.x files, 3.x means you really can't use any of the files from 2.x, etc (files in this context is meaning existing characters, apartments, etc) But even then, exactly how that breaks is somewhat open - if all skills are renamed as an example, the files would still be compatible, but the characters not really playable as all their skills are gone. This is different than a case where the file format actually changes in an incompatible manner. From nicolas.weeger at laposte.net Sun Mar 7 11:19:17 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 7 Mar 2010 18:19:17 +0100 Subject: [crossfire] Scorn house of healing tweaks In-Reply-To: <4B8D8A27.1020300@real-time.com> References: <201002281255.27493.nicolas.weeger@laposte.net> <4B8D8A27.1020300@real-time.com> Message-ID: <201003071819.17344.nicolas.weeger@laposte.net> > For the player who recently leveled up and their supply of Potions of > Life no longer work on them.. The ability to trade some amount those in > for this spell casting service? > > Trying to make trade-ins for the House of Healing fall in line with what > the map actually provides.. > > Trade X amount of potions of healing in for restoration service? > > Same could be said for healing staffs, prayer books, holy symbols, balms. > > Also, alchemy ingredients used to make healing items or components. Indeed, could be interesting. Some suggestions on IRC were to use the junk found in maps, low or middle level, as an exchange for restoration. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100307/ba92efde/attachment.pgp From nicolas.weeger at laposte.net Sun Mar 7 11:18:25 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 7 Mar 2010 18:18:25 +0100 Subject: [crossfire] Scorn house of healing tweaks In-Reply-To: <4B8D891E.3030004@real-time.com> References: <201002281255.27493.nicolas.weeger@laposte.net> <4B8D891E.3030004@real-time.com> Message-ID: <201003071818.28627.nicolas.weeger@laposte.net> > Very good idea! > > How will, or are players, aware of such feature or service? Well, I guess it could be written in some tutorials, or explained at some point... Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100307/36be040f/attachment.pgp From mwedel at sonic.net Sun Mar 14 01:35:16 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 13 Mar 2010 23:35:16 -0800 Subject: [crossfire] Release? In-Reply-To: <201002282150.55437.nicolas.weeger@laposte.net> References: <201002282150.55437.nicolas.weeger@laposte.net> Message-ID: <4B9C91B4.1000104@sonic.net> On 02/28/10 12:50 PM, Nicolas Weeger wrote: > Hello. > > What about we just decide to do a release of trunk end of march? > Whatever it is called, 1.5, 2.0, 1.9, and such :) > > Then let's kill branch, and work on trunk. > > > Does that sound ok? Just to follow up on this some more and other ideas: Call the release 1.50, to note it diverges a bit from the 1.11 release (isn't a minor update) but at the same time isn't what we consider 2.0 Target release for end of March or so. Are there any must fix bugs to be dealt with? I hope to have the new account login stuff done soon, but I've been saying that for months :( Relative to C client, drop X11 and GTK client, and _only_ support/include the gtk2 client. I believe there are sufficient theme files for the gtk2 client to cover what in the past were shortcomings (either look of gtk1 client or need for low resolution support). Some of this is based on that account code above - I don't want to even attempt to add support for that to those old clients. From nicolas.weeger at laposte.net Mon Mar 15 14:41:22 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 15 Mar 2010 20:41:22 +0100 Subject: [crossfire] Release? In-Reply-To: <4B9C91B4.1000104@sonic.net> References: <201002282150.55437.nicolas.weeger@laposte.net> <4B9C91B4.1000104@sonic.net> Message-ID: <201003152041.32237.nicolas.weeger@laposte.net> Hello. > Call the release 1.50, to note it diverges a bit from the 1.11 release > (isn't a minor update) but at the same time isn't what we consider 2.0 Fine by me. > Target release for end of March or so. Are there any must fix bugs to be > dealt with? I hope to have the new account login stuff done soon, but I've > been saying that for months :( The recent object_free2() and object_free_drop_inventory() changes could have issues. Not necessarily critical, but some things to keep in mind. Ideally, we'd make a 1.5 branch on which we'd fix bugs before and after release, while works goes on trunk... But then there are too many branches already :) > Relative to C client, drop X11 and GTK client, and _only_ support/include > the gtk2 client. I believe there are sufficient theme files for the gtk2 > client to cover what in the past were shortcomings (either look of gtk1 > client or need for low resolution support). Some of this is based on that > account code above - I don't want to even attempt to add support for that > to those old clients. Fine by me. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100315/88de7b7a/attachment.pgp From mwedel at sonic.net Mon Mar 15 23:26:58 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 15 Mar 2010 21:26:58 -0700 Subject: [crossfire] Release? In-Reply-To: <201003152041.32237.nicolas.weeger@laposte.net> References: <201002282150.55437.nicolas.weeger@laposte.net> <4B9C91B4.1000104@sonic.net> <201003152041.32237.nicolas.weeger@laposte.net> Message-ID: <4B9F0892.2020706@sonic.net> On 03/15/10 12:41 PM, Nicolas Weeger wrote: >> Target release for end of March or so. Are there any must fix bugs to be >> dealt with? I hope to have the new account login stuff done soon, but I've >> been saying that for months :( > > > The recent object_free2() and object_free_drop_inventory() changes could have > issues. > Not necessarily critical, but some things to keep in mind. > > > Ideally, we'd make a 1.5 branch on which we'd fix bugs before and after > release, while works goes on trunk... > But then there are too many branches already :) Yes, that is the ideal case, especially if there is lots of active development. If there isn't, it is simpler to just freeze the trunk gate for anything but bug fixes needed for the 1.50 release. That way quality can get better, without the overhead of a branch, potentially needing to do merges (a fix in trunk needing to get in for the 1.50 release or vice versa), etc. The other thing is we don't typically make patches a release, so the branch isn't that useful in that area - instead, we just say it will be fixed in the next release. If we do releases on a regular basis, that isn't that bad. From brenlally at gmail.com Fri Mar 19 13:24:53 2010 From: brenlally at gmail.com (Brendan Lally) Date: Fri, 19 Mar 2010 18:24:53 +0000 Subject: [crossfire] Healthbars Message-ID: <20100319182453.194e8b50@angmar> Hello, The following is a proposed addition to the crossfire protocol to enable the clients to show monster health bars. Rationale: Currently there are lots of combat messages sent during combat, but no real way to know whether your character is 'winning' in a battle, by displaying health bars above monsters, it is possible to get a quick visual indication of what is happening, without the need to read lots of combat messages. Additionally, the 'flags' I describe below, allow clients to present information about creatures that in game terms should be obvious, but which is not currently visible to the client. In order to implement this, the following is altered. A setup command 'healthbars' is added, if a client request it with argument '1' then the server will send healthbar information to the client, if they do not, then there is no visible change. [Possible expansion, if the setup flag is sent and confirmed, expect that the client will ignore attack messages ('you cut foo', 'you miss foo', etc)] The map2 command is extended to have another type of data that may be sent. type 4 is a healthbar. There follow 2 bytes, the first is the hitpoints as a proportion of maxhp, the second is the flags that apply to the hitpoint bar. The healthbar is sent for an alive creature that is either a monster or a player. It is sent whenever a face changes on the square, or always if the creature is below their maximum health. The client should show healthbars until the information for the square is updated. The first byte has a value between 0 and 255, 128 means that the creature is at full health, above that means the creature is above max health (which doesn't normally happen, but potentially might be possible) 128 has been chosen because it is a multiple of 32 (the size of the tile), so calculating the length of a bar should be trivial for clients. The second byte provides information about the flags that apply to the creature, this is a bitmask, currently the values that are used are: Bit 1, creature is another player or belongs to another player. Bit 2, creature is friendly (someone's pet) Bit 3, creature is unaggressive (townsfolk and the like) Clients are required to ignore any additional flags that they do not understand. In interpreting the first two bits then: 00 => a normal monster 01 => another player 11 => another player's pet 10 => the player's pet The remaining bits are reserved for later use, the intention being that they should correspond to effects that are on the creature in some way. Provisionally, the suggestion is to include * Monster is moving slowly (slowed or paralysed) * Monster is poisoned * Monster has some form of beneficial effect working on them Currently I have a working implementation against the server, and Ragnor has created a modification to jxclient to handle this, that leads to something like the following in use: http://imagebin.ca/view/wD2lvaI.html Since that screenshot was taken, some additional work has been done to change the colouring of the bars to reflect the flags that are sent. the creature has (eg, that sage has been hit, so is now hostile, should have a different colour to the non-hostile townsfolk) There may still need to be something done from a display perspective to have the bars offset to appear in the bottom of the cell above the creature's face (although I do not suggest using such an offset in the data sent from the server.). Brendan From nicolas.weeger at laposte.net Sat Mar 20 02:46:51 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 20 Mar 2010 08:46:51 +0100 Subject: [crossfire] Healthbars In-Reply-To: <20100319182453.194e8b50@angmar> References: <20100319182453.194e8b50@angmar> Message-ID: <201003200846.54920.nicolas.weeger@laposte.net> Hello. > The following is a proposed addition to the crossfire protocol to > enable the clients to show monster health bars. Looks fine and fun to me :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100320/3a5ede43/attachment.pgp From nicolas.weeger at laposte.net Sat Mar 20 02:55:29 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 20 Mar 2010 08:55:29 +0100 Subject: [crossfire] Release? In-Reply-To: <4B9F0892.2020706@sonic.net> References: <201002282150.55437.nicolas.weeger@laposte.net> <201003152041.32237.nicolas.weeger@laposte.net> <4B9F0892.2020706@sonic.net> Message-ID: <201003200855.30070.nicolas.weeger@laposte.net> Hello. > Yes, that is the ideal case, especially if there is lots of active > development. > > If there isn't, it is simpler to just freeze the trunk gate for anything > but bug fixes needed for the 1.50 release. That way quality can get > better, without the overhead of a branch, potentially needing to do merges > (a fix in trunk needing to get in for the 1.50 release or vice versa), etc. > > The other thing is we don't typically make patches a release, so the > branch isn't that useful in that area - instead, we just say it will be > fixed in the next release. If we do releases on a regular basis, that > isn't that bad. Well, I can see quite many things in the pipe lately - healthbars being one, and other fun things coming. So totally freezing trunkmay not be a great idea, or it should be really a short time period :) If we are still thinking of end of march, what should be done right now? AFAIK the Windows build works (more or less), so I could produce a version if needed. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100320/a3caee82/attachment.pgp From mwedel at sonic.net Sat Mar 20 23:14:41 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 20 Mar 2010 21:14:41 -0700 Subject: [crossfire] Healthbars In-Reply-To: <20100319182453.194e8b50@angmar> References: <20100319182453.194e8b50@angmar> Message-ID: <4BA59D31.4070802@sonic.net> On 03/19/10 11:24 AM, Brendan Lally wrote: > Hello, > > The following is a proposed addition to the crossfire protocol to > enable the clients to show monster health bars. Just a note, this was discussed several years back, and at that time, there was concern that that 'gives away' information to the player that perhaps should not be given away (how close a monster is to death as an example, or fast regeneration). I don't know if we still consider that a concern or not - I know lots of other games show something similar, but is something I thought I'd mention. > In order to implement this, the following is altered. > > A setup command 'healthbars' is added, if a client request it with > argument '1' then the server will send healthbar information to the > client, if they do not, then there is no visible change. > [Possible expansion, if the setup flag is sent and confirmed, > expect that the client will ignore attack messages ('you cut > foo', 'you miss foo', etc)] I'd have the player ignore attack messages be some option. While for the most part, they are not needed, I don't know there are some attack messages which you would care about (I'm not 100% sure what all messages fall into the attack category). But dropping them all could result in information not being displayed that is important. While one could rightfully argue that too many options are a bad thing, I'd better like to see the impact if the client ignore the messages before making it standard. > > The map2 command is extended to have another type of data that may be > sent. type 4 is a healthbar. There follow 2 bytes, the first is the > hitpoints as a proportion of maxhp, the second is the flags that apply > to the hitpoint bar. I haven't looked in detail, but it sounds like this information is now space specific (eg, this space has flags 0x02 and hp 0x40). Is that correct? > > The healthbar is sent for an alive creature that is either a monster or > a player. It is sent whenever a face changes on the square, or always > if the creature is below their maximum health. The client should show > healthbars until the information for the square is updated. I'm a little concerned about sending it all the time if creature is not at full health. Maybe with modern connections, the bandwidth isn't a concern, but there are still lots of maps with large mobs of monsters - I could imagine them getting hit with a burning hands, and now sending update for all those monsters every tick (while the 3 bytes for the data isn't bad, there are additional bytes needed for each space to denote the coordinates, etc). If this is a per space attribute, it would be better to cache that data - both in the map structure itself (so fast to fetch) and in socket structure that holds the player map. In that way, server would only need to send data if it has changed in any way. > > The first byte has a value between 0 and 255, 128 means that the > creature is at full health, above that means the creature is above max > health (which doesn't normally happen, but potentially might be > possible) 128 has been chosen because it is a multiple of 32 (the size > of the tile), so calculating the length of a bar should be trivial for > clients. IIRC, the java client resizes tiles to match the screen resolution. I'd also think that in most cases, you want to leave at least one pixel border so if you have 2 monsters next to each other, the stat bars don't run together. I think expressing that number as a percentage (100 being full health) is a bit more intuitive, and doesn't really make processing harder on the client side (it's all math). > > The second byte provides information about the flags that apply to the > creature, this is a bitmask, currently the values that are used are: > > Bit 1, creature is another player or belongs to another player. > Bit 2, creature is friendly (someone's pet) Note there are cases where monsters are set friendly but are not pets > Bit 3, creature is unaggressive (townsfolk and the like) > > Clients are required to ignore any additional flags that they do not > understand. When you say ignore, does that mean they should just ignore the flags, or ignore this HP total all together? Doesn't matter much to me either way, but that should be clarified. Would it make sense to expressly set a bit for monsters (instead of assuming if no bits are set, it is a monster?) Would it also make sense of instead of using a bitmask here, to actually enumerate the values (1=monster, 2=player, 3=this players pet, 4=another players pet, 5=door, 6=..., etc)? I'm just thinking that with a bitmask, you pretty quickly run out of bits if you start adding other things. One way the map command handled this for some things was the low order bits were enumerated value, high order bits were the bitmask, and they worked towards each other (so first bitmask was 0x80, and the enumeration may have had a max of 15 types. In that way, if the enumeration needed to grow, it could, and if the bitmask needed to, it could go to 0x40, etc). Or for that matter, might want to make note that 0x80 is reserved, and denotes that another flag value follows, so you build in some expansion just in case you run out of bits. > The remaining bits are reserved for later use, the intention being that > they should correspond to effects that are on the creature in some way. > > Provisionally, the suggestion is to include > * Monster is moving slowly (slowed or paralysed) > * Monster is poisoned > * Monster has some form of beneficial effect working on them That last one is pretty vague - might want to break it down into protections, attribute gains, etc. I don't know. I also wonder, going back above to discussion about giving too much away, if this should perhaps be limited to players/pets. So you can easily monitor your party members, but don't know that the monster just cast protection on themselves (the monster AI is already pretty stupid - if players can visually see if monster has beneficial spells, the monster code should get modified so monster can 'figure out' if player has spells on them, what the best form of attack the monster should use, etc). As an aside, should stat bar display perhaps be disabled on some maps (map attribute)? In particular, I'm thinking the arena, but I could also imagine that maybe in some places where combat should not happen, there may not be much reason to display it. > > Currently I have a working implementation against the server, and > Ragnor has created a modification to jxclient to handle this, that > leads to something like the following in use: > http://imagebin.ca/view/wD2lvaI.html > > Since that screenshot was taken, some additional work has been done to > change the colouring of the bars to reflect the flags that are sent. > the creature has (eg, that sage has been hit, so is now hostile, should > have a different colour to the non-hostile townsfolk) > There may still need to be something done from a display perspective to > have the bars offset to appear in the bottom of the cell > above the creature's face (although I do not suggest using such an > offset in the data sent from the server.). Right - it is really up to the client to figure out the best way to display the data. If this becomes a default setting, then it may be that the correct answer is to adjust the monster images, etc, so that there is space above the monsters head for the stat bars. I think from a player, it makes a lot more sense for the stat bar to be above the monsters head, and not below their feet (alternatively, you might be able to do it along the left side of the cell - for many monsters, there may be more space there) Random question (and I know this is a pure client issue, so maybe something Ragnar can answer it) - what do you do for big monsters, like trolls or titans? Size the statbar for the entire creature? I suppose an issue here is that the client doesn't know the relation of the statbar to the image it goes with. It would be screwy to display it just above the creatures feet, but I don't know if the client otherwise would know what to do with it. Other than those various comments, it all looks good to me, and IMO is worth adding. I think it may be better to wait until after the release in a week or two to get more testing time, but depends on how much work it needs to be finished. From mwedel at sonic.net Sat Mar 20 23:21:35 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 20 Mar 2010 21:21:35 -0700 Subject: [crossfire] Release? In-Reply-To: <201003200855.30070.nicolas.weeger@laposte.net> References: <201002282150.55437.nicolas.weeger@laposte.net> <201003152041.32237.nicolas.weeger@laposte.net> <4B9F0892.2020706@sonic.net> <201003200855.30070.nicolas.weeger@laposte.net> Message-ID: <4BA59ECF.5070002@sonic.net> On 03/20/10 12:55 AM, Nicolas Weeger wrote: > Hello. > >> Yes, that is the ideal case, especially if there is lots of active >> development. >> >> If there isn't, it is simpler to just freeze the trunk gate for anything >> but bug fixes needed for the 1.50 release. That way quality can get >> better, without the overhead of a branch, potentially needing to do merges >> (a fix in trunk needing to get in for the 1.50 release or vice versa), etc. >> >> The other thing is we don't typically make patches a release, so the >> branch isn't that useful in that area - instead, we just say it will be >> fixed in the next release. If we do releases on a regular basis, that >> isn't that bad. > > > Well, I can see quite many things in the pipe lately - healthbars being one, > and other fun things coming. > > So totally freezing trunkmay not be a great idea, or it should be really a > short time period :) Yes, in the past, usually for a week or two. Of course, there is nothing that prevents one from making a branch from something other than the latest version. So if tomorrow, someone made a lot of big changes in which you think 'hmmm - I'd like more testing before and don't want them in this release', someone could make a branch for 1.50 from right before that commit. That doesn't eliminate the issue of now having two branches to update when making a fix (presuming the fix is not related to that commit, but something unrelated which needs to be fixed in both releases) > > > If we are still thinking of end of march, what should be done right now? In general, complete things that are not completed, and fix bugs. > > AFAIK the Windows build works (more or less), so I could produce a version if > needed. That would be good. I'm never sure about the demand for the server, but demand for the client still seems there. a release of the JXclient should also be done (just to make it more readily available). I'm not quite sure what a release of the jxclient means - presumably a precompiled .jar file in one, with a source release for the others (similar to how the client has a source release, as well as some binary packages for specific OS's). But I'd think in the case of the jxclient, that 'binary' release should be platform independent, but I could be wrong on that. From agschult at ucalgary.ca Sun Mar 21 00:12:18 2010 From: agschult at ucalgary.ca (Alex Schultz) Date: Sat, 20 Mar 2010 23:12:18 -0600 Subject: [crossfire] Healthbars In-Reply-To: <4BA59D31.4070802@sonic.net> References: <20100319182453.194e8b50@angmar> <4BA59D31.4070802@sonic.net> Message-ID: <20100320231218.534d8bb5@ucalgary.ca> On Sat, 20 Mar 2010 21:14:41 -0700 Mark Wedel wrote: > Just a note, this was discussed several years back, and at that > time, there was concern that that 'gives away' information to the > player that perhaps should not be given away (how close a monster is > to death as an example, or fast regeneration). > > I don't know if we still consider that a concern or not - I know > lots of other games show something similar, but is something I > thought I'd mention. I'd say... make it possible for individual maps/monsters to override (either disable display or force a display value) if there is some reason. I think in general it's not an issue but it might be nice to give map makers a little flexibility. Alex From mwedel at sonic.net Sun Mar 21 00:55:37 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 20 Mar 2010 22:55:37 -0700 Subject: [crossfire] Healthbars In-Reply-To: <20100320231218.534d8bb5@ucalgary.ca> References: <20100319182453.194e8b50@angmar> <4BA59D31.4070802@sonic.net> <20100320231218.534d8bb5@ucalgary.ca> Message-ID: <4BA5B4D9.9030102@sonic.net> On 03/20/10 10:12 PM, Alex Schultz wrote: > On Sat, 20 Mar 2010 21:14:41 -0700 > Mark Wedel wrote: >> Just a note, this was discussed several years back, and at that >> time, there was concern that that 'gives away' information to the >> player that perhaps should not be given away (how close a monster is >> to death as an example, or fast regeneration). >> >> I don't know if we still consider that a concern or not - I know >> lots of other games show something similar, but is something I >> thought I'd mention. > > I'd say... make it possible for individual maps/monsters to override > (either disable display or force a display value) if there is some > reason. I think in general it's not an issue but it might be nice to > give map makers a little flexibility. It probably wouldn't be hard to add a flag to a monster to denote this. I suppose one thing here is that this only sends a percentage, and not total hp or the like - sending actual HP would be giving more information away. From brenlally at gmail.com Sun Mar 21 15:37:40 2010 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 21 Mar 2010 20:37:40 +0000 Subject: [crossfire] Healthbars In-Reply-To: <4BA59D31.4070802@sonic.net> References: <20100319182453.194e8b50@angmar> <4BA59D31.4070802@sonic.net> Message-ID: <20100321203740.71fbc0b1@angmar> On Sat, 20 Mar 2010 21:14:41 -0700 Mark Wedel wrote: > On 03/19/10 11:24 AM, Brendan Lally wrote: > > The following is a proposed addition to the crossfire protocol to > > enable the clients to show monster health bars. > > Just a note, this was discussed several years back, and at that > time, there was concern that that 'gives away' information to the > player that perhaps should not be given away (how close a monster is > to death as an example, or fast regeneration). > > I don't know if we still consider that a concern or not - I know > lots of other games show something similar, but is something I > thought I'd mention. The overriding principle I have been working to is that what should be presented is information that the player's character may reasonably be expected to infer from looking at a monster, so if there is something that has a direct visible effect on a monster, then the character would know about it, so the client should, if there is no direct visible effect, then the character won't know about it, so the client shouldn't either. > > > > In order to implement this, the following is altered. > > > > A setup command 'healthbars' is added, if a client request it with > > argument '1' then the server will send healthbar information to the > > client, if they do not, then there is no visible change. > > [Possible expansion, if the setup flag is sent and > > confirmed, expect that the client will ignore attack messages ('you > > cut foo', 'you miss foo', etc)] > > I'd have the player ignore attack messages be some option. While > for the most part, they are not needed, I don't know there are some > attack messages which you would care about (I'm not 100% sure what > all messages fall into the attack category). But dropping them all > could result in information not being displayed that is important. The gtk2 client already has client message configuration, so it would be a question of changing the default to 'off' for that type of message. As it stands, there are a couple of cases where you might want to keep attack messages, invisible creatures would be the obvious ones, because they wouldn't get healthbars sent. - maybe the answer is to use one of the subtypes of attack message to allow those ones to be kept and the others to be filtered out? > > The map2 command is extended to have another type of data that may > > be sent. type 4 is a healthbar. There follow 2 bytes, the first is > > the hitpoints as a proportion of maxhp, the second is the flags > > that apply to the hitpoint bar. > > I haven't looked in detail, but it sounds like this information is > now space specific (eg, this space has flags 0x02 and hp 0x40). Is > that correct? Yes, the information is sent for the highest (by layer) ALIVE object on the map square. - This does potentially mean that there are creatures on lower layers that aren't displayed, but there probably isn't a sensible way to display health bars for multiple creatures on a square anyway. > > The healthbar is sent for an alive creature that is either a > > monster or a player. It is sent whenever a face changes on the > > square, or always if the creature is below their maximum health. > > The client should show healthbars until the information for the > > square is updated. > > I'm a little concerned about sending it all the time if creature is > not at full health. Maybe with modern connections, the bandwidth > isn't a concern, but there are still lots of maps with large mobs of > monsters - I could imagine them getting hit with a burning hands, and > now sending update for all those monsters every tick (while the 3 > bytes for the data isn't bad, there are additional bytes needed for > each space to denote the coordinates, etc). The other thing I have come across is that some maps seem to do odd things with locked doors, I think it probably is useful to be able to see information for them, but they seem to have their maxhp set oddly and are getting sent a lot. > If this is a per space attribute, it would be better to cache that > data - both in the map structure itself (so fast to fetch) and in > socket structure that holds the player map. > > In that way, server would only need to send data if it has changed > in any way. Caching like that is a really interesting idea, the other thing this does, if there are many players viewing the same squares, is mean that the flags only need to be calculated once per tick. Probably the place to store it is in the mapspace struct, then on each tick update all the mapspace information for the maps that either have a player on, or are loaded and linked to a map that does. I would probably add, if other face information is being sent anyway, then always send the healthbar because it is probably better that a map2 clear would clear the healthbars anyway (and things like newmap commands should too) > > The first byte has a value between 0 and 255, 128 means that the > > creature is at full health, above that means the creature is above > > max health (which doesn't normally happen, but potentially might be > > possible) 128 has been chosen because it is a multiple of 32 (the > > size of the tile), so calculating the length of a bar should be > > trivial for clients. > > IIRC, the java client resizes tiles to match the screen > resolution. I'd also think that in most cases, you want to leave at > least one pixel border so if you have 2 monsters next to each other, > the stat bars don't run together. > > I think expressing that number as a percentage (100 being full > health) is a bit more intuitive, and doesn't really make processing > harder on the client side (it's all math). Ok, that's a fair point. > > > > > The second byte provides information about the flags that apply to > > the creature, this is a bitmask, currently the values that are used > > are: > > > > Bit 1, creature is another player or belongs to another player. > > Bit 2, creature is friendly (someone's pet) > > Note there are cases where monsters are set friendly but are not > pets Yes, I think I found a couple of those. > > Clients are required to ignore any additional flags that they do not > > understand. > > When you say ignore, does that mean they should just ignore the > flags, or ignore this HP total all together? Doesn't matter much to > me either way, but that should be clarified. I mean ignore the flags that it doesn't understand. > Would it make sense to expressly set a bit for monsters (instead of > assuming if no bits are set, it is a monster?) Would it also make > sense of instead of using a bitmask here, to actually enumerate the > values (1=monster, 2=player, 3=this players pet, 4=another players > pet, 5=door, 6=..., etc)? I'm just thinking that with a bitmask, you > pretty quickly run out of bits if you start adding other things. One > way the map command handled this for some things was the low order > bits were enumerated value, high order bits were the bitmask, and > they worked towards each other (so first bitmask was 0x80, and the > enumeration may have had a max of 15 types. In that way, if the > enumeration needed to grow, it could, and if the bitmask needed to, > it could go to 0x40, etc). I'm going to modify the proposed change in combination with your comments about faces below. > Or for that matter, might want to make note that 0x80 is reserved, > and denotes that another flag value follows, so you build in some > expansion just in case you run out of bits. The map2 command sends the length of the data that follows it, so the client should be able to look to see if there are additional flags from there. > > The remaining bits are reserved for later use, the intention being > > that they should correspond to effects that are on the creature in > > some way. > > > > Provisionally, the suggestion is to include > > * Monster is moving slowly (slowed or paralysed) > > * Monster is poisoned > > * Monster has some form of beneficial effect working on them > > That last one is pretty vague - might want to break it down into > protections, attribute gains, etc. I don't know. The suggestion on IRC was that this is something the 'probe' spell could do. - I think this really comes back to the question of 'is this something my character might reasonably be able to observe by looking?' In this case, my inclination would be to say that you'd be able to spot glowing magic stuff around a monster, without being able to tell what it is doing. > I also wonder, going back above to discussion about giving too much > away, if this should perhaps be limited to players/pets. So you can > easily monitor your party members, but don't know that the monster > just cast protection on themselves (the monster AI is already pretty > stupid - if players can visually see if monster has beneficial > spells, the monster code should get modified so monster can 'figure > out' if player has spells on them, what the best form of attack the > monster should use, etc). > > As an aside, should stat bar display perhaps be disabled on some > maps (map attribute)? In particular, I'm thinking the arena, but I > could also imagine that maybe in some places where combat should not > happen, there may not be much reason to display it. The arena is one of the places where I think this would be most useful to have this, it gives players a way to tell whether they are winning or need to try something else, and may make the first battle with someone more tactical than merely 'run to the right and see if I win' > > Currently I have a working implementation against the server, and > > Ragnor has created a modification to jxclient to handle this, that > > leads to something like the following in use: > > http://imagebin.ca/view/wD2lvaI.html > > > > Since that screenshot was taken, some additional work has been done > > to change the colouring of the bars to reflect the flags that are > > sent. the creature has (eg, that sage has been hit, so is now > > hostile, should have a different colour to the non-hostile > > townsfolk) There may still need to be something done from a display > > perspective to have the bars offset to appear in the bottom of the > > cell above the creature's face (although I do not suggest using > > such an offset in the data sent from the server.). > > If this becomes a default setting, then it may be that the correct > answer is to adjust the monster images, etc, so that there is space > above the monsters head for the stat bars. I think from a player, it > makes a lot more sense for the stat bar to be above the monsters > head, and not below their feet (alternatively, you might be able to > do it along the left side of the cell - for many monsters, there may > be more space there) Sorry, I maybe didn't make that bit clear, I mean offset the bars so they appear above the player, but drawn in the next cell up (the same way the bars above the player are drawn. > Random question (and I know this is a pure client issue, so maybe > something Ragnar can answer it) - what do you do for big monsters, > like trolls or titans? Size the statbar for the entire creature? > > I suppose an issue here is that the client doesn't know the > relation of the statbar to the image it goes with. It would be > screwy to display it just above the creatures feet, but I don't know > if the client otherwise would know what to do with it. hmm, this is a good point, maybe the thing to do is send the layer that the healthbar corresponds to? The client would then be able to identify the face that is drawn on that layer, and scale to the appropriate width. Ok, so taking all of this together then, I end up with the following: The setup command is as described. The map2 command gets a new type (4) which sends a number of bytes after it as defined in the length mask. There will be two bytes that are always sent, The first contains the hp, scaled so that 100 = full health, The second is for client display hinting, it contains two nybbles, the first is the layer that the healthbar is 'on' the second is the type of healthbar - clients should ignore any healthbars for types they do not know There may then be some number of further bytes, making up to the byte count in the type byte. These contain flags, clients may choose to interpret them if they know how, any flags the client doesn't recognise it must ignore. > Other than those various comments, it all looks good to me, and IMO > is worth adding. I think it may be better to wait until after the > release in a week or two to get more testing time, but depends on how > much work it needs to be finished. I'd be inclined to agree with that, I have a few more changes to make anyway. Brendan. From agschult at ucalgary.ca Sun Mar 21 15:45:38 2010 From: agschult at ucalgary.ca (Alex Schultz) Date: Sun, 21 Mar 2010 14:45:38 -0600 Subject: [crossfire] Healthbars In-Reply-To: <20100321203740.71fbc0b1@angmar> References: <20100319182453.194e8b50@angmar> <4BA59D31.4070802@sonic.net> <20100321203740.71fbc0b1@angmar> Message-ID: <20100321144538.6f17fdb3@ucalgary.ca> On Sun, 21 Mar 2010 20:37:40 +0000 Brendan Lally wrote: > On Sat, 20 Mar 2010 21:14:41 -0700 > Mark Wedel wrote: > > > On 03/19/10 11:24 AM, Brendan Lally wrote: > > > The following is a proposed addition to the crossfire protocol to > > > enable the clients to show monster health bars. > > > > Just a note, this was discussed several years back, and at that > > time, there was concern that that 'gives away' information to the > > player that perhaps should not be given away (how close a monster is > > to death as an example, or fast regeneration). > > > > I don't know if we still consider that a concern or not - I know > > lots of other games show something similar, but is something I > > thought I'd mention. > > The overriding principle I have been working to is that what should be > presented is information that the player's character may reasonably be > expected to infer from looking at a monster, so if there is something > that has a direct visible effect on a monster, then the character > would know about it, so the client should, if there is no direct > visible effect, then the character won't know about it, so the client > shouldn't either. Thus why I'd say it should be allowed, but with map-specific override allowed. This also makes me wonder if the bar could change color or something to represent an "indeterminate" state that a map/script could set. Alex From mwedel at sonic.net Sun Mar 21 23:18:10 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 21 Mar 2010 21:18:10 -0700 Subject: [crossfire] Healthbars In-Reply-To: <20100321203740.71fbc0b1@angmar> References: <20100319182453.194e8b50@angmar> <4BA59D31.4070802@sonic.net> <20100321203740.71fbc0b1@angmar> Message-ID: <4BA6EF82.9070701@sonic.net> On 03/21/10 01:37 PM, Brendan Lally wrote: > On Sat, 20 Mar 2010 21:14:41 -0700 > Mark Wedel wrote: > >> On 03/19/10 11:24 AM, Brendan Lally wrote: >>> The following is a proposed addition to the crossfire protocol to >>> enable the clients to show monster health bars. >> >> Just a note, this was discussed several years back, and at that >> time, there was concern that that 'gives away' information to the >> player that perhaps should not be given away (how close a monster is >> to death as an example, or fast regeneration). >> >> I don't know if we still consider that a concern or not - I know >> lots of other games show something similar, but is something I >> thought I'd mention. > > The overriding principle I have been working to is that what should be > presented is information that the player's character may reasonably be > expected to infer from looking at a monster, so if there is something > that has a direct visible effect on a monster, then the character would > know about it, so the client should, if there is no direct visible > effect, then the character won't know about it, so the client shouldn't > either. That makes a lot of sense. > As it stands, there are a couple of cases where you might want to keep > attack messages, invisible creatures would be the obvious ones, because > they wouldn't get healthbars sent. - maybe the answer is to use one of > the subtypes of attack message to allow those ones to be kept and the > others to be filtered out? Maybe - I'm not sure I'd like a different class of messages for creatures that don't normally show up - at some level, there are already too many message types. One possibility (at least so far as the gtk2 client) is have an 'attack' message pane, where attack messages go. Players could basically just ignore that if they so choose, and if attacking a monster and need that, make that message pane the visible one. (I suppose that in the ideal world for the gtk2 client, one could have as many message panes as one wants, and call them whatever they want, so could route messages all over the place) > >>> The map2 command is extended to have another type of data that may >>> be sent. type 4 is a healthbar. There follow 2 bytes, the first is >>> the hitpoints as a proportion of maxhp, the second is the flags >>> that apply to the hitpoint bar. >> >> I haven't looked in detail, but it sounds like this information is >> now space specific (eg, this space has flags 0x02 and hp 0x40). Is >> that correct? > > Yes, the information is sent for the highest (by layer) ALIVE object > on the map square. - This does potentially mean that there are > creatures on lower layers that aren't displayed, but there probably > isn't a sensible way to display health bars for multiple creatures on a > square anyway. In theory, there should never be 2 living creatures on the same space (not that it doesn't happen). But if there were 2 living creatures on the same space, I can't think of any sensible way to display stat bar information for both of them. > >>> The healthbar is sent for an alive creature that is either a >>> monster or a player. It is sent whenever a face changes on the >>> square, or always if the creature is below their maximum health. >>> The client should show healthbars until the information for the >>> square is updated. >> >> I'm a little concerned about sending it all the time if creature is >> not at full health. Maybe with modern connections, the bandwidth >> isn't a concern, but there are still lots of maps with large mobs of >> monsters - I could imagine them getting hit with a burning hands, and >> now sending update for all those monsters every tick (while the 3 >> bytes for the data isn't bad, there are additional bytes needed for >> each space to denote the coordinates, etc). > > The other thing I have come across is that some maps seem to do odd > things with locked doors, I think it probably is useful to be able to > see information for them, but they seem to have their maxhp set oddly > and are getting sent a lot. It is not too uncommon that via either errors or intentional effect, some monsters hp > maxhp. Under current method, I would think those get sent every tick also. > >> If this is a per space attribute, it would be better to cache that >> data - both in the map structure itself (so fast to fetch) and in >> socket structure that holds the player map. >> >> In that way, server would only need to send data if it has changed >> in any way. > > Caching like that is a really interesting idea, the other thing this > does, if there are many players viewing the same squares, is mean that > the flags only need to be calculated once per tick. > > Probably the place to store it is in the mapspace struct, then on each > tick update all the mapspace information for the maps that either have a > player on, or are loaded and linked to a map that does. > > I would probably add, if other face information is being sent anyway, > then always send the healthbar because it is probably better that a map2 > clear would clear the healthbars anyway (and things like newmap commands > should too) Yes - putting it in the mapspace struct makes sense. And rather than having a different routine that fills in that hp value, it makes sense to just use update_position() to fill in that data - that gets preliminary data filled in. For any updates to monster HP during combat, a simple method would be to just set the NEED_UPDATE flag on the space the monster is at. However, probably better for the combat code to just update the HP value for that space - the combat codes knows the map, x, y, hp values, so simple enough for it to do it. May want to have a generic macro like SET_MAP_HP_PERCENT(...) just like the other SET_MAP_... macros. >> Or for that matter, might want to make note that 0x80 is reserved, >> and denotes that another flag value follows, so you build in some >> expansion just in case you run out of bits. > > The map2 command sends the length of the data that follows it, so the > client should be able to look to see if there are additional > flags from there. True - only a concern if you need more than 7 bytes. > >>> The remaining bits are reserved for later use, the intention being >>> that they should correspond to effects that are on the creature in >>> some way. >>> >>> Provisionally, the suggestion is to include >>> * Monster is moving slowly (slowed or paralysed) >>> * Monster is poisoned >>> * Monster has some form of beneficial effect working on them >> >> That last one is pretty vague - might want to break it down into >> protections, attribute gains, etc. I don't know. > > The suggestion on IRC was that this is something the 'probe' spell > could do. - I think this really comes back to the question of 'is this > something my character might reasonably be able to observe by looking?' > In this case, my inclination would be to say that you'd be able to spot > glowing magic stuff around a monster, without being able to tell what > it is doing. That makes sense, and follows with what you say above. My personal inclination (but more work) would be more spells actually have some aura or like around the player, but that doesn't work well if characters has multiple auras (as an example of this, you cast protection from fire and maybe a red aura surrounds the character). That is beyond the scope of what you are doing here. But one thing is that for many spells, there is nothing to denote if the effect is obvious or not. Does a protection spell have an obvious effect? What about strength or other stat gains? Something like regeneration might, simply on the basis creature is regaining hp (you would see wounds closing, etc) On that basis, however, it may not be long term duration spells you are watching - if a creature heals itself via spell, that would be an obvious effect (lots of wounds close really quickly), but not something the server could infer by looking at forces in the monster. I think trying to hunt those down may get pretty complicated/time consuming. You would need to look at the monsters inventory for these forces, and you'd almost have to do that every tick because there wouldn't be a good/fast way for that code to know that some force just disappeared (maybe adding some new FLAGs would do it) > >> I also wonder, going back above to discussion about giving too much >> away, if this should perhaps be limited to players/pets. So you can >> easily monitor your party members, but don't know that the monster >> just cast protection on themselves (the monster AI is already pretty >> stupid - if players can visually see if monster has beneficial >> spells, the monster code should get modified so monster can 'figure >> out' if player has spells on them, what the best form of attack the >> monster should use, etc). >> >> As an aside, should stat bar display perhaps be disabled on some >> maps (map attribute)? In particular, I'm thinking the arena, but I >> could also imagine that maybe in some places where combat should not >> happen, there may not be much reason to display it. > > The arena is one of the places where I think this would be most > useful to have this, it gives players a way to tell whether they are > winning or need to try something else, and may make the first battle > with someone more tactical than merely 'run to the right and see if I > win' OTOH in the arena, it is probably one of those cases where you can watch the message pane more closely - there is only one other opponent. > >>> Currently I have a working implementation against the server, and >>> Ragnor has created a modification to jxclient to handle this, that >>> leads to something like the following in use: >>> http://imagebin.ca/view/wD2lvaI.html >>> >>> Since that screenshot was taken, some additional work has been done >>> to change the colouring of the bars to reflect the flags that are >>> sent. the creature has (eg, that sage has been hit, so is now >>> hostile, should have a different colour to the non-hostile >>> townsfolk) There may still need to be something done from a display >>> perspective to have the bars offset to appear in the bottom of the >>> cell above the creature's face (although I do not suggest using >>> such an offset in the data sent from the server.). >> >> If this becomes a default setting, then it may be that the correct >> answer is to adjust the monster images, etc, so that there is space >> above the monsters head for the stat bars. I think from a player, it >> makes a lot more sense for the stat bar to be above the monsters >> head, and not below their feet (alternatively, you might be able to >> do it along the left side of the cell - for many monsters, there may >> be more space there) > > Sorry, I maybe didn't make that bit clear, I mean offset the bars so > they appear above the player, but drawn in the next cell up (the same > way the bars above the player are drawn. Ah OK. That works. > > >> Random question (and I know this is a pure client issue, so maybe >> something Ragnar can answer it) - what do you do for big monsters, >> like trolls or titans? Size the statbar for the entire creature? >> >> I suppose an issue here is that the client doesn't know the >> relation of the statbar to the image it goes with. It would be >> screwy to display it just above the creatures feet, but I don't know >> if the client otherwise would know what to do with it. > > hmm, this is a good point, maybe the thing to do is send the layer that > the healthbar corresponds to? The client would then be able to identify > the face that is drawn on that layer, and scale to the appropriate > width. That would work. > > Ok, so taking all of this together then, I end up with the following: > > The setup command is as described. > > The map2 command gets a new type (4) which sends a number of bytes > after it as defined in the length mask. > > There will be two bytes that are always sent, > The first contains the hp, scaled so that 100 = full health, Might want to limit this to 200 to denote creature is at more than double maxhp, just to be clear. I guess that is still screwy if the creature happens to be a 3 times maxhp - you'd do a lot of damage before seeing any indication, but presuming this isn't a design error, maybe such supernatural HP would not be obvious when they are lost. > The second is for client display hinting, it contains two nybbles, > the first is the layer that the healthbar is 'on' > the second is the type of healthbar - clients should ignore > any healthbars for types they do not know > There may then be some number of further bytes, making up to the byte > count in the type byte. These contain flags, clients may choose to > interpret them if they know how, any flags the client doesn't recognise > it must ignore. Looks good. From mwedel at sonic.net Mon Mar 22 01:28:28 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 21 Mar 2010 23:28:28 -0700 Subject: [crossfire] Account based login musings/thoughts/ideas Message-ID: <4BA70E0C.7040607@sonic.net> So I'm actually making some real progress on the account based login. But in doing so, have come across a few issues I thought I'd ask for input in. Character passwords: Legacy characters have a hash password in the .pl file. This will be used by the new login method to associate one of these legacy characters with an account (if you know a name and its password, you can associate it with your new account). Once a character is associated with an account, when you log in your acocunt, you will be able to play any of those characters without needing any more passwords However, for newly created characters, this isn't really relevant - that extra password isn't used (as noted above). But an issue is what to do with that - it could still be useful if you are playing on a legacy client that does not support account based logins (in which case you could login as now - character name & password). One thought I had was to just use the password for the account for the character also - in this way it has a password, and the server should have the hashed version of the password around someplace, so could fill it in without any extra questions. Thoughts? Rules/motd/news files: Aside from the fact that having 3 different files to display at login seems excessive (and one could argue that motd is a subset of news since motd is Message Of The Day, not that it is used for that), my login method will display some/all of these to the player during the account login. My thought is you want to display them early, just as now - you don't want someone to go through creating an account, only for them to find out the rules aren't something they like when they get to the create a character screen. A question then comes on when to display each message. I'm thinking that the 'news' should be displayed at the first login screen - there could be information there that affects their ability to login in. Similarly, the motd contains generally useful information, so display it then makes sense. Since the rules are a bit more in depth, I'm thinking of display it during the account creation screen and character selection screen. This way folks will see it - in the first case, before they create an account, in the second case, each time before they play. Opinions? (as an aside, I plan to update the protocol so that the client can do a 'requestinfo' for these files instead of having to try and intercept drawinfo messages. I'm also thinking that some server based commands could be moved to the client) Format of news file: Currently, it is listed as oldest first, with newest at the bottom. It seems to me that the reverse (newest at top) is better - just like the Changelog - you start reading, and once you get to an entry you have seen before, you stop - this is more relevant for the interface I'm providing since if the news file is many entries long, a scrollbar will be needed to display all the information, at it is more natural to keep the scrollbar at the top and then have the user scroll down then position the scrollbar at the bottom and have the user need to keep scrolling up to find relevant entries. I realize that for many clients in which this text is mixed with the other messages at start up, and for other reasons, you want the scrollbar at the bottom by default, and have the user scroll up. One thought I had here was for the client to re-order the news file on its own (presume it is a oldest first) - the format of the file dictates that % entries denote a heading, but I thought I'd throw this out there for general thoughts. From robert at timetraveller.org Mon Mar 22 16:00:43 2010 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 22 Mar 2010 17:00:43 -0400 (EDT) Subject: [crossfire] Account based login musings/thoughts/ideas In-Reply-To: <4BA70E0C.7040607@sonic.net> References: <4BA70E0C.7040607@sonic.net> Message-ID: On Sun, 21 Mar 2010, Mark Wedel wrote: > Rules/motd/news files: Aside from the fact that having 3 different > files to display at login seems excessive (and one could argue that motd > is a subset of news since motd is Message Of The Day, not that it is > used for that), my login method will display some/all of these to the > player during the account login. > > My thought is you want to display them early, just as now - you don't > want someone to go through creating an account, only for them to find > out the rules aren't something they like when they get to the create a > character screen. > > A question then comes on when to display each message. I'm thinking > that the 'news' should be displayed at the first login screen - there > could be information there that affects their ability to login in. > Similarly, the motd contains generally useful information, so display it > then makes sense. > > Since the rules are a bit more in depth, I'm thinking of display it > during the account creation screen and character selection screen. > This way folks will see it - in the first case, before they create an > account, in the second case, each time before they play. > > Opinions? > > (as an aside, I plan to update the protocol so that the client can do a > 'requestinfo' for these files instead of having to try and intercept drawinfo > messages. I'm also thinking that some server based commands could be moved to > the client) > > Format of news file: Currently, it is listed as oldest first, with > newest at the bottom. It seems to me that the reverse (newest at top) > is better - just like the Changelog - you start reading, and once you > get to an entry you have seen before, you stop - this is more relevant The 'news' command on *nix is nice. By default it only displays news items that you haven't seen before. Presumable it keeps each news item as a separate file and compares the timestamps of the news files to the last login to determine what items the user should see. Users could be free to read all the news again via a command. > for the interface I'm providing since if the news file is many entries > long, a scrollbar will be needed to display all the information, at it > is more natural to keep the scrollbar at the top and then have the user > scroll down then position the scrollbar at the bottom and have the user > need to keep scrolling up to find relevant entries. It could display each item one at a time with the user having to click a 'next' button (or skipping). I don't think this will be terribly onerous as I expect multiple news items would be the exception rather than the rule (based on personal experience of similar situations). BTW I love the idea of accounts. Cheers, Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com Open Source: The revolution that silently changed the world From mwedel at sonic.net Mon Mar 22 23:55:23 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 22 Mar 2010 21:55:23 -0700 Subject: [crossfire] Account based login musings/thoughts/ideas In-Reply-To: References: <4BA70E0C.7040607@sonic.net> Message-ID: <4BA849BB.6010000@sonic.net> On 03/22/10 02:00 PM, Robert Brockway wrote: > On Sun, 21 Mar 2010, Mark Wedel wrote: >> Format of news file: Currently, it is listed as oldest first, with >> newest at the bottom. It seems to me that the reverse (newest at top) >> is better - just like the Changelog - you start reading, and once you >> get to an entry you have seen before, you stop - this is more relevant > > The 'news' command on *nix is nice. By default it only displays news > items that you haven't seen before. Presumable it keeps each news item > as a separate file and compares the timestamps of the news files to the > last login to determine what items the user should see. > > Users could be free to read all the news again via a command. I think there are actually commands that do so. The client could certain remember what news it has seen and hasn't seen - it doesn't have time stamps, but it could just save that information to a file and display what is new. That said, if someone fixed typos, that would confuse that logic. Requiring dates in the format could be done, and then server could easily remember. But that would require admin to enter correct date info, which may not be universal. > >> for the interface I'm providing since if the news file is many entries >> long, a scrollbar will be needed to display all the information, at it >> is more natural to keep the scrollbar at the top and then have the user >> scroll down then position the scrollbar at the bottom and have the user >> need to keep scrolling up to find relevant entries. > > It could display each item one at a time with the user having to click a > 'next' button (or skipping). I don't think this will be terribly onerous > as I expect multiple news items would be the exception rather than the > rule (based on personal experience of similar situations). One thought I had was basically expanders - I'm not sure how hard that is - but basically similar to how something like thunderbird can expand/collapse a group of messages. The client could just display the title of each news item, and user clicks expander and it then displays the news to go with it. With that, user can easily see all the titles - and if the server admins do put in some date, makes it even easier for the user. From nicolas.weeger at laposte.net Wed Mar 24 13:43:14 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 24 Mar 2010 19:43:14 +0100 Subject: [crossfire] Release? In-Reply-To: <4BA59ECF.5070002@sonic.net> References: <201002282150.55437.nicolas.weeger@laposte.net> <201003200855.30070.nicolas.weeger@laposte.net> <4BA59ECF.5070002@sonic.net> Message-ID: <201003241943.18092.nicolas.weeger@laposte.net> > Yes, in the past, usually for a week or two. > > Of course, there is nothing that prevents one from making a branch from > something other than the latest version. So if tomorrow, someone made a > lot of big changes in which you think 'hmmm - I'd like more testing before > and don't want them in this release', someone could make a branch for 1.50 > from right before that commit. > > That doesn't eliminate the issue of now having two branches to update > when making a fix (presuming the fix is not related to that commit, but > something unrelated which needs to be fixed in both releases) But the project seems to be moving fast lately, so one week could be too long ;) Yes, it's spring! > In general, complete things that are not completed, and fix bugs. Considering some are working on quest mechanisms and various scripts, "not completed" can be some weeks or months ;) Also there's your account system. And maybe other things. > That would be good. I'm never sure about the demand for the server, but > demand for the client still seems there. Well, if I have time to make one, I'll make one, anyway :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100324/1f5758d7/attachment.pgp From brenlally at gmail.com Sun Mar 28 20:19:06 2010 From: brenlally at gmail.com (Brendan Lally) Date: Mon, 29 Mar 2010 02:19:06 +0100 Subject: [crossfire] Quests with multiple outcomes Message-ID: <20100329021906.084dd9e6@angmar> Hello All, Those of you who have been following IRC recently will know I have been doing some things involving quests over the last week or so. The bulk of these I am targeting for after the current release is due, and there will be a list of changes that I will be seeking approval and/or editing for on the maps list after that happens However, I am conscious that server administrators are able to cherry-pick map updates, so I want to get the main server changes in ahead of the release. That way that admins may continue to use a stable server with any future map updates that take place. The server changes are twofold: Firstly, there is a patch that 'funnyman3595' wrote to add Object.Clone and Object.Split to the python plugin. - I'll be committing this tomorrow anyway. Secondly, there is a change to the way that quests are represented. Rather than having an idea of an 'endquest' call as there is at the moment, I introduce a 'stopstep'. Any quest which is advanced to a stage beyond the stopstep is marked completed when that occurs. This does three things: 1) Removes the need for separate 'stop quest' calls, making scripts to update quests simpler. 2) Permit multiple outcomes for quests which can then be tracked. 3) Allow (for non-restartable quests) post completion updates (eg, "After Foo mcBar rewarded me for saving his life, I killed him anyway") The following quest definition is an example of one where there are multiple possible outcomes. (this could be expanded further, eg, something like step 50, => "after buying a pass, I found one lying around for free, I took it anyway") quest scorn/PortPass title Port Pass description Acquire a port pass to be allowed into Scorn's docks. end_description stopstep 20 restart 0 step 10 description The guards told me that I could acquire a port pass from the Office for Gate Passes. I should try asking there. end_description end_step step 20 description I have purchased a port pass to allow me into Scorn docks end_description end_step step 30 description I have found a port pass that should allow me access to Scorn Docks description end_step step 40 description I have found another way through the gate that leads to Scorn Docks. end_description end_step end_quest Here then, the 'stopstep' is 20, and the steps 20, 30 and 40 are all steps that complete the quest, but in different ways.* The 'quest info' command is altered to show the outcome for non-restartable quests, so that, rather than just saying 'this quest is complete' it describes how the player chose to complete it so that there is something of a 'narrative' that forms around the character recording the actions of the player. (there is an assumption here that for restartable quests, there will not be an outcome which can have a permanent impact if the quest can be repeated) There are other structural change I have in mind for quests during the next version's lifetime, but this is the only one that substantially impacts on the way quests interact with maps, the others would all preserve compatibility with quests with minimal effort (commenting out some extra fields with a couple of regexps). * Minor style note, I have used numbering 10,20,30,... so that, should a quest be made more complex or have more quest updates attached to it, there is room to add additional steps without breaking any existing scripts, or needing to edit any player files - there are a number of similar things I have been thrashing out over the last few days, they are mostly on the wiki, and I will cover them in more detail when I post on the maps list after the release. Brendan From mwedel at sonic.net Sun Mar 28 23:03:33 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 28 Mar 2010 21:03:33 -0700 Subject: [crossfire] Quests with multiple outcomes In-Reply-To: <20100329021906.084dd9e6@angmar> References: <20100329021906.084dd9e6@angmar> Message-ID: <4BB02695.20109@sonic.net> On 03/28/10 06:19 PM, Brendan Lally wrote: > > quest scorn/PortPass > title Port Pass > description > Acquire a port pass to be allowed into Scorn's docks. > end_description > stopstep 20 > restart 0 > step 10 > description > The guards told me that I could acquire a port pass from the Office for > Gate Passes. I should try asking there. > end_description > end_step > step 20 > description > I have purchased a port pass to allow me into Scorn docks > end_description > end_step > step 30 > description > I have found a port pass that should allow me access to Scorn Docks > description > end_step > step 40 > description > I have found another way through the gate that leads to Scorn Docks. > end_description > end_step > end_quest > > Here then, the 'stopstep' is 20, and the steps 20, 30 and 40 are all > steps that complete the quest, but in different ways.* So just to be clear - in this case, it means that if the player somehow gets the quest state to be >20 (stopstep value) that the quest is done? Rather than having the stopstep, for each step, would it be possible/better to have a keyword there to not that the quest is done? What I'm thinking is that for complex quests, there could be several paths, and it would seem clearer to me that for one path, maybe steps 20->25 dictate one path (with 25 being the finish point) and for another one, steps 30->38. For a map developer, it would be easier to have all steps for one path be together - better than having to go from step 24 to 40 to note the quest is done. (as an aside, not related to the system but the example above, I think the quest description should more or less match - finding another way to the port area doesn't really satisfy the quest description of getting a port pass. If the quest was 'get access to the port area', then that would be fine - and in this example, it may be a guard telling the character that they can buy port passes) > > The 'quest info' command is altered to show the outcome for > non-restartable quests, so that, rather than just saying 'this quest is > complete' it describes how the player chose to complete it so that > there is something of a 'narrative' that forms around the character > recording the actions of the player. (there is an assumption here > that for restartable quests, there will not be an outcome which can > have a permanent impact if the quest can be repeated) As a default, I think only active quests should be shown - otherwise, I could forsee a list of 100 completed quests which isn't great. OTOH, maybe if active and completed quests are set apart, wouldn't be so bad. > > * Minor style note, I have used numbering 10,20,30,... so that, should a > quest be made more complex or have more quest updates attached to it, > there is room to add additional steps without breaking any existing > scripts, or needing to edit any player files - there are a number of > similar things I have been thrashing out over the last few days, they > are mostly on the wiki, and I will cover them in more detail when I > post on the maps list after the release. Yes - leaving gaps is always a good thing for future expansion. From brenlally at gmail.com Mon Mar 29 12:25:49 2010 From: brenlally at gmail.com (Brendan Lally) Date: Mon, 29 Mar 2010 18:25:49 +0100 Subject: [crossfire] Quests with multiple outcomes In-Reply-To: <4BB02695.20109@sonic.net> References: <20100329021906.084dd9e6@angmar> <4BB02695.20109@sonic.net> Message-ID: <20100329182549.69114c8f@angmar> On Sun, 28 Mar 2010 21:03:33 -0700 Mark Wedel wrote: > On 03/28/10 06:19 PM, Brendan Lally wrote: > > > > > quest scorn/PortPass > > title Port Pass > > description > > Acquire a port pass to be allowed into Scorn's docks. > > end_description > > stopstep 20 > > restart 0 > > step 10 > > description > > The guards told me that I could acquire a port pass from the Office > > for Gate Passes. I should try asking there. > > end_description > > end_step > > step 20 > > description > > I have purchased a port pass to allow me into Scorn docks > > end_description > > end_step > > step 30 > > description > > I have found a port pass that should allow me access to Scorn Docks > > description > > end_step > > step 40 > > description > > I have found another way through the gate that leads to Scorn Docks. > > end_description > > end_step > > end_quest > > > > Here then, the 'stopstep' is 20, and the steps 20, 30 and 40 are all > > steps that complete the quest, but in different ways.* > > So just to be clear - in this case, it means that if the player > somehow gets the quest state to be >20 (stopstep value) that the > quest is done? This is correct. > > Rather than having the stopstep, for each step, would it be > possible/better to have a keyword there to not that the quest is done? > > What I'm thinking is that for complex quests, there could be > several paths, and it would seem clearer to me that for one path, > maybe steps 20->25 dictate one path (with 25 being the finish point) > and for another one, steps 30->38. For a map developer, it would be > easier to have all steps for one path be together - better than > having to go from step 24 to 40 to note the quest is done. The design of quests as things stand assumes: * Quests only progress forwards, not backwards * Once a quest is completed, then it is not un-completed (although may be restarted). Taking these two principles, anything that can be represented with finish points at different stages can also be represented with finish points all grouped together at the end. (Any path in a quest that could be completed multiple times will be something that should be implemented as a restartable sub-quest). There is a further assumption, that I have been working with, that bigger stage numbers => nearer completion. In particular, the script I have been using to handle dropping quest items has that assumption built in. The way to fix this is probably to change the meaning of the quest_was_completed command, and assume that most quest items should be kept for the entirety of the quest. (and that, if they shouldn't, then > (as an aside, not related to the system but the example above, I > think the quest description should more or less match - finding > another way to the port area doesn't really satisfy the quest > description of getting a port pass. If the quest was 'get access to > the port area', then that would be fine - and in this example, it may > be a guard telling the character that they can buy port passes) The reason for having the 'finding another way' description is because there are 4 quests that I have defined for the port gate, 1 for each of the three way of getting access, plus another one for the 'getting access' quest. The 'getting access' quest is set to complete once the player successfully walks through the gate any of the three sub quests which haven't been completed by that point are marked as complete to step 40 at that time as well (step 40 says something similar for all 3 of them). In this case, it is not so much that the quest has been 'won' but just that it is unnecessary now, finishing them all at the same time is a way to remove them from the active list. One of the additions I will want 'real soon' after release is an idea of 'parent' quests. That way, rather than listing all of the quests on the same level of priority, there would be quests and subquests, so the list would read: quests: 1) .... 2) .... 3) Down to the docks: a) Port Pass b) Scorn Password c) The Hero of Scorn 4 ... etc and then the info section would say: Down to the docks Description: There is a gate separating the main part of scorn from the docks. It is closed and the guards won't let you past. Current Status: To pass through the gates I need to get a port pass, find the password or become the hero of scorn. Perhaps one of the guards will tell me how I can do one of those things. Subquests: Port Pass Description: Acquire a port pass to be allowed into Scorn's docks. Current Status: The guards told me that I could acquire a port pass from the Office for Gate Passes. I should try asking there. Scorn Password Description: Discover the password that will permit passage through the gates in Scorn. Current Status: The guards have told me that there is a password, just not what it is, I should keep alert for any clues as to what it might be. The Hero of Scorn Description: Be pronounced Hero of Scorn, so that the the guards will permit passage through the gates. Current Status: I have discovered that the king is the only one who can declare me a hero. I should try speaking to someone at his court, and seek to win favour there. After this has been finished then, you might see: Down to the docks Description: There is a gate separating the main part of scorn from the docks. It is closed and the guards won't let you past. This quest has been completed: Outcome: I have been granted passage through scorn port gate. Subquests: Port Pass Description: Acquire a port pass to be allowed into Scorn's docks. Outcome: I have found another way through the gate that leads to Scorn Docks. Scorn Password Description: Discover the password that will permit passage through the gates in Scorn. Outcome: I have given the password, and been permitted through the gate. The Hero of Scorn Description: Be pronounced Hero of Scorn, so that the the guards will permit passage through the gates. Outcome: I have found another way through the gate. During the next release cycle I'll be wanting to look at more sophisticated client side support to make this a bit slicker, something like a dedicated 'quest journal' screen which would collapse or shade these properly (I know Nicolas is after something similar to this also) All of the wording, etc is up for debate, as well as things like the level of detail in the quest texts (my inclination has been to go for lots of detail in the text for the low level quests in scorn because these are probably the ones that will be played within the first couple of hours of picking up the game - I'd be more inclined to have vaguer descriptions of high level quests that players won't find until they have played the game for a few hours - but this is a discussion for the maps list) > > The 'quest info' command is altered to show the outcome for > > non-restartable quests, so that, rather than just saying 'this > > quest is complete' it describes how the player chose to complete it > > so that there is something of a 'narrative' that forms around the > > character recording the actions of the player. (there is an > > assumption here that for restartable quests, there will not be an > > outcome which can have a permanent impact if the quest can be > > repeated) > > As a default, I think only active quests should be shown - > otherwise, I could forsee a list of 100 completed quests which isn't > great. OTOH, maybe if active and completed quests are set apart, > wouldn't be so bad. It shouldn't really matter for quest info, since that shows one quest at a time, where this has an effect is on the 'quest list' command. I hadn't changed the current behaviour of that command, which does show all of the quests, separated into completed and active but I take the point about that potentially being a great many quests, I think the way to handle that is to have 'quest list' say: 'you have completed n quests (of which m are restartable)' followed by active quests: n+1 (foo the bar), n+2 (baz the qux) etc, with the command 'quest list all' showing all of the quests. (when building a client-side interface, you'd be looking at a drop-down, to show all quests, completed only or active only - as well as probably an idea of 'local' quests - I have a few ideas for how to handle that in a way that should work to answer the question 'what quests am I trying to do in this town' falling into the trap of 'follow the arrow and kill whatever is at the end; you win' that some big commercial RPGs do) Brendan From mwedel at sonic.net Mon Mar 29 22:49:23 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 29 Mar 2010 20:49:23 -0700 Subject: [crossfire] Quests with multiple outcomes In-Reply-To: <20100329182549.69114c8f@angmar> References: <20100329021906.084dd9e6@angmar> <4BB02695.20109@sonic.net> <20100329182549.69114c8f@angmar> Message-ID: <4BB174C3.8040405@sonic.net> On 03/29/10 10:25 AM, Brendan Lally wrote: >> >> Rather than having the stopstep, for each step, would it be >> possible/better to have a keyword there to not that the quest is done? >> >> What I'm thinking is that for complex quests, there could be >> several paths, and it would seem clearer to me that for one path, >> maybe steps 20->25 dictate one path (with 25 being the finish point) >> and for another one, steps 30->38. For a map developer, it would be >> easier to have all steps for one path be together - better than >> having to go from step 24 to 40 to note the quest is done. > > The design of quests as things stand assumes: > * Quests only progress forwards, not backwards Random question - is that a fair assumption? I could imagine cases where there are many steps, and there could be cases where due to use of items (which are consumed) that a quest could go back a step. Something like: 1 I need to talk to foo about X. 2 I found that foos lives in scorn in soandso house. 3 I need a baz to get into soandso house. 4 I'm in soandso house - now I need to find foo. 5 I found foo and talked about X (quest completed) If one got to step 4 (using up baz to do so), and then for some reason left, they may now be back to step 3 (need to find baz again). This itself may not be a perfect example, as baz may be something with a known location. But one could imagine alchemy quests, where the quest is to properly make some recipe. And parts of that quest are to find the necessary ingredients, and for some things (like orc livers) it may just be random luck. If after getting all the ingredients, the actual alchemy failed (bad roll), it may be that the quest goes back to finding ingredients if the character doesn't have any extra. Now I don't consider this a big deal, but it just seems to me that there may be many quests (especially those related to items) where the character may take a step backward by selling/trading/whatever the item needed. > * Once a quest is completed, then it is not un-completed (although may > be restarted). That makes sense - completed is completed. And I'd imagine that for restartable quests, the state would revert. Random question 2: For repeatable quests, is there any record that the character is repeating a quest vs it being their first time? Likewise, would it be worth it to note how many times a character has done a quest? I'm thinking that in some cases, one may want to make the secondary reward not as good (or perhaps different). Eg, the lord sends player out to kill some boss creature. On first attempt, they get one item, on second attempt, something different, etc. > > quests: > 1) .... > 2) .... > 3) Down to the docks: > a) Port Pass > b) Scorn Password > c) The Hero of Scorn > 4 ... > etc > > and then the info section would say: Yes, that makes a lot of sense - it sounds like the solution to what I said above was to do sub quests, but I'd really not want to see a huge list of quests which are really subquests and have no value on their own (in my example above, fetching a baz only makes sense as part of talking to foo). > During the next release cycle I'll be wanting to look at more > sophisticated client side support to make this a bit slicker, something > like a dedicated 'quest journal' screen which would collapse or > shade these properly (I know Nicolas is after something similar to this > also) Makes sense. Whenever there are issues about organizing/present data to the user, providing the information to the client and let the client figure it out is the way to go. There is only so much that can be done on a basic text interface. > > All of the wording, etc is up for debate, as well as things like the > level of detail in the quest texts (my inclination has been to go for > lots of detail in the text for the low level quests in scorn because > these are probably the ones that will be played within the first couple > of hours of picking up the game - I'd be more inclined to have vaguer > descriptions of high level quests that players won't find until they > have played the game for a few hours - but this is a discussion for the > maps list) Yep. Some quests may also be vague just by their very nature - some locations are supposed to be somewhat hidden or not well known, so at least on first pass, a detailed description of them doesn't make sense. However, as the character learns more information, maybe that gets filled in. From brenlally at gmail.com Tue Mar 30 12:20:58 2010 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 30 Mar 2010 18:20:58 +0100 Subject: [crossfire] Quests with multiple outcomes In-Reply-To: <4BB174C3.8040405@sonic.net> References: <20100329021906.084dd9e6@angmar> <4BB02695.20109@sonic.net> <20100329182549.69114c8f@angmar> <4BB174C3.8040405@sonic.net> Message-ID: <20100330182058.41144525@angmar> On Mon, 29 Mar 2010 20:49:23 -0700 Mark Wedel wrote: > On 03/29/10 10:25 AM, Brendan Lally wrote: > > > The design of quests as things stand assumes: > > * Quests only progress forwards, not backwards > > Random question - is that a fair assumption? > > I could imagine cases where there are many steps, and there could > be cases where due to use of items (which are consumed) that a quest > could go back a step. > > Something like: > > 1 I need to talk to foo about X. > 2 I found that foos lives in scorn in soandso house. > 3 I need a baz to get into soandso house. > 4 I'm in soandso house - now I need to find foo. > 5 I found foo and talked about X (quest completed) > > If one got to step 4 (using up baz to do so), and then for some > reason left, they may now be back to step 3 (need to find baz > again). This itself may not be a perfect example, as baz may be > something with a known location. > > But one could imagine alchemy quests, where the quest is to > properly make some recipe. And parts of that quest are to find the > necessary ingredients, and for some things (like orc livers) it may > just be random luck. > > If after getting all the ingredients, the actual alchemy failed > (bad roll), it may be that the quest goes back to finding ingredients > if the character doesn't have any extra. > > Now I don't consider this a big deal, but it just seems to me that > there may be many quests (especially those related to items) where > the character may take a step backward by selling/trading/whatever > the item needed. A restartable subquest would cover both cases, there is a case to be made for having restartable steps (as opposed to the entire quest being either restartable or not), > > * Once a quest is completed, then it is not un-completed (although > > may be restarted). > > That makes sense - completed is completed. And I'd imagine that > for restartable quests, the state would revert. > > Random question 2: For repeatable quests, is there any record that > the character is repeating a quest vs it being their first time? > Likewise, would it be worth it to note how many times a character has > done a quest? > > I'm thinking that in some cases, one may want to make the secondary > reward not as good (or perhaps different). Eg, the lord sends player > out to kill some boss creature. On first attempt, they get one item, > on second attempt, something different, etc. Yes, QuestWasCompleted() is non-zero if the quest has been completed before, for map integration, a script can check the value of this before advancing the stage to determine if it has been repeated. Changing to the number of previous completions could potentially be a bit more powerful in terms of reward scaling (eg, have a reward of 500platinum/number of times completed), I haven't been looking to do that myself yet, so it isn't a change I've wanted, but I can see how someone might want to use it. > > quests: > > 1) .... > > 2) .... > > 3) Down to the docks: > > a) Port Pass > > b) Scorn Password > > c) The Hero of Scorn > > 4 ... > > etc > > > > and then the info section would say: > > > > Yes, that makes a lot of sense - it sounds like the solution to > what I said above was to do sub quests, but I'd really not want to > see a huge list of quests which are really subquests and have no > value on their own (in my example above, fetching a baz only makes > sense as part of talking to foo). There is really a trade off here, the choice is between having the smallest possible number of really complex quests, or a greater number of simpler quests. My instinct is to go with the simpler individual quests, because they are a lot easier to build and test in isolation. Within the timescale of the next release cycle, I can't see the number of quests becoming unmanagable, and by the time 1.51/1.60/whatever it is called comes around then the interface should be there to handle it. One of the things I will be doing very shortly (ie, the next time I change the quest file definition after the release) will be to break the default.quests file into lots of smaller files. I was going to use the region file to specify these, so that quests then become attached to a region of the game world as well. Creating a default.quests file for the old servers to use is fairly trivial, but for new servers, the number of quests in each file would be fairly limited. - An extra couple of subquests used for administrative purposes shouldn't make too much difference then. (the other advantage of that approach is that creating a list of quests in each town for the wiki is just 'grep ^title quest_file', although it'd probably be worth excluding subquests from that list) > > All of the wording, etc is up for debate, as well as things like the > > level of detail in the quest texts (my inclination has been to go > > for lots of detail in the text for the low level quests in scorn > > because these are probably the ones that will be played within the > > first couple of hours of picking up the game - I'd be more inclined > > to have vaguer descriptions of high level quests that players won't > > find until they have played the game for a few hours - but this is > > a discussion for the maps list) > > Yep. Some quests may also be vague just by their very nature - > some locations are supposed to be somewhat hidden or not well known, > so at least on first pass, a detailed description of them doesn't > make sense. However, as the character learns more information, maybe > that gets filled in. I think there are three ways that this can go: 1) add 'new_summary' as an option in the quest step which replaces the initial summary with a more detailed one once a certain stage is passed 2) Use the knowledge system to hold knowledge related to a quest, but not directly connected to the advancement of it. 3) Store the entire history of the quest steps that the player has taken, so that the step descriptions for all of them can be made visible. Then any updated information can be written in one of the step descriptions I'd tend to favour option 3, at least for non-restartable quests, you can then have something of a diary style interface that the clients could provide: eg: Custom Armour Morning of 15th Winter, season of new year, year 12: I have placed an order with the smith in Scorn Armour Shop for a custom eyeshield. He promised it would be ready by this time tomorrow. Evening of 17th Winter, season of new year, year 12: I have collected my new armour from the smith. Quest Complete (may be restarted) This may not be the best example, but it is the one that is least likely to be a spoiler. Obviously there is a whole discussion about how to represent server's game time to the player, but it isn't difficult to store. (just a list of date/times and the stage numbers they correspond to). Brendan. From mwedel at sonic.net Tue Mar 30 22:55:36 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 30 Mar 2010 20:55:36 -0700 Subject: [crossfire] Quests with multiple outcomes In-Reply-To: <20100330182058.41144525@angmar> References: <20100329021906.084dd9e6@angmar> <4BB02695.20109@sonic.net> <20100329182549.69114c8f@angmar> <4BB174C3.8040405@sonic.net> <20100330182058.41144525@angmar> Message-ID: <4BB2C7B8.1080803@sonic.net> On 03/30/10 10:20 AM, Brendan Lally wrote: >> Random question 2: For repeatable quests, is there any record that >> the character is repeating a quest vs it being their first time? >> Likewise, would it be worth it to note how many times a character has >> done a quest? >> >> I'm thinking that in some cases, one may want to make the secondary >> reward not as good (or perhaps different). Eg, the lord sends player >> out to kill some boss creature. On first attempt, they get one item, >> on second attempt, something different, etc. > > > Yes, QuestWasCompleted() is non-zero if the quest has been completed > before, for map integration, a script can check the value of this > before advancing the stage to determine if it has been repeated. > > Changing to the number of previous completions could potentially be a > bit more powerful in terms of reward scaling (eg, have a reward of > 500platinum/number of times completed), I haven't been looking to do > that myself yet, so it isn't a change I've wanted, but I can see how > someone might want to use it. I'd consider that a fairly low priority improvement, but one that could be interesting. For quests which are really designed to be repeatable, a counter could also be done - on first time, you get some decent reward (item/money), for times 2->24 you get something not so nice, and then for time 25 you get something pretty nice. It is really up to the quest designer to figure this out. First priority would be to have quests done, and have the first/secondary rewards sorted out, and worry less about rewards after that. > >>> quests: >>> 1) .... >>> 2) .... >>> 3) Down to the docks: >>> a) Port Pass >>> b) Scorn Password >>> c) The Hero of Scorn >>> 4 ... >>> etc >>> >>> and then the info section would say: >> >> >> >> Yes, that makes a lot of sense - it sounds like the solution to >> what I said above was to do sub quests, but I'd really not want to >> see a huge list of quests which are really subquests and have no >> value on their own (in my example above, fetching a baz only makes >> sense as part of talking to foo). > > There is really a trade off here, the choice is between having the > smallest possible number of really complex quests, or a greater number > of simpler quests. > > My instinct is to go with the simpler individual quests, because they > are a lot easier to build and test in isolation. That makes sense. And really, single big quests vs many small quests is a server mechanic - if they are presented to the client in a cohesive fashion (so those 12 subquests appear as steps of a big quest), that is great - you don't need to have the big quest have those 12 individual steps. My main concern, beyond it being managable from a map designer standpoint, is also have some way to make them cohesive for the players. It would seem to me in such a system, you'd need the following information for these subquests: - What part of quest are they (parent quest) - what quests do these open when completed. For example, one could have a quest that has 6 different steps, and they have to be done in order (doing step 3 before step 2 doesn't make sense). But you could have other quests where several of the steps could be done in parallel - a simple example could be alchemy quest - you may need to get 5 materials for the recipe, but what order you get them in doesn't matter. I'm not sure how this later one is handled in the system - the step to go to alchemy master with cauldron shouldn't open up until all 5 of those subquests are done. > > Within the timescale of the next release cycle, I can't see the number > of quests becoming unmanagable, and by the time 1.51/1.60/whatever it > is called comes around then the interface should be there to handle it. yep > > One of the things I will be doing very shortly (ie, the next time I > change the quest file definition after the release) will be to break > the default.quests file into lots of smaller files. I was going to use > the region file to specify these, so that quests then become attached > to a region of the game world as well. Makes sense - ideally, .quest files could sit anywhere in the map tree, but that would make it trickier for the server to find them all. But one could imagine that in some cases, a quest may relate to a small set of maps (already located in its own directory in the maps tree), and keeping the quest near there would make sense. I wonder if rather than regions file, if maybe adding something like #include directives into the the default.quests would work? Server would then just process those and load all quest files. It should only need to do this at startup, so shouldn't add much to load time, but gives maximum flexibility. >> Yep. Some quests may also be vague just by their very nature - >> some locations are supposed to be somewhat hidden or not well known, >> so at least on first pass, a detailed description of them doesn't >> make sense. However, as the character learns more information, maybe >> that gets filled in. > > I think there are three ways that this can go: > > 1) add 'new_summary' as an option in the quest step which replaces the > initial summary with a more detailed one once a certain stage is > passed > 2) Use the knowledge system to hold knowledge related to a > quest, but not directly connected to the advancement of it. > 3) Store the entire history of the quest steps that the player has > taken, so that the step descriptions for all of them can be made > visible. Then any updated information can be written in one of the step > descriptions > > I'd tend to favour option 3, at least for non-restartable quests, you > can then have something of a diary style interface that the clients > could provide: For complex quests, option #1 might be nice - having a quick summary of where you are in the quest might be desirable than reading the 15 things you have done so far. Simplest way in that case would be to have an optional summary/endsummary for each step - if set, then when a player reviews their quest information, it displays the summary of the step the player has completed the most. From mwedel at sonic.net Wed Mar 31 02:01:52 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 31 Mar 2010 00:01:52 -0700 Subject: [crossfire] Release? In-Reply-To: <201002282150.55437.nicolas.weeger@laposte.net> References: <201002282150.55437.nicolas.weeger@laposte.net> Message-ID: <4BB2F360.4070507@sonic.net> Just a heads up - I'm targeting weekend of April 10-11 to make a release, since I should have time then (certainly won't this weekend).. From brenlally at gmail.com Wed Mar 31 13:14:35 2010 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 31 Mar 2010 19:14:35 +0100 Subject: [crossfire] Quests with multiple outcomes In-Reply-To: <4BB2C7B8.1080803@sonic.net> References: <20100329021906.084dd9e6@angmar> <4BB02695.20109@sonic.net> <20100329182549.69114c8f@angmar> <4BB174C3.8040405@sonic.net> <20100330182058.41144525@angmar> <4BB2C7B8.1080803@sonic.net> Message-ID: <20100331191435.49bed74d@angmar> On Tue, 30 Mar 2010 20:55:36 -0700 Mark Wedel wrote: > On 03/30/10 10:20 AM, Brendan Lally wrote: > > >>> quests: > >>> 1) .... > >>> 2) .... > >>> 3) Down to the docks: > >>> a) Port Pass > >>> b) Scorn Password > >>> c) The Hero of Scorn > >>> 4 ... > >>> etc > >>> > >>> and then the info section would say: > >> > >> > >> > >> Yes, that makes a lot of sense - it sounds like the solution to > >> what I said above was to do sub quests, but I'd really not want to > >> see a huge list of quests which are really subquests and have no > >> value on their own (in my example above, fetching a baz only makes > >> sense as part of talking to foo). > > > > There is really a trade off here, the choice is between having the > > smallest possible number of really complex quests, or a greater > > number of simpler quests. > > > > My instinct is to go with the simpler individual quests, because > > they are a lot easier to build and test in isolation. > > That makes sense. And really, single big quests vs many small > quests is a server mechanic - if they are presented to the client in > a cohesive fashion (so those 12 subquests appear as steps of a big > quest), that is great - you don't need to have the big quest have > those 12 individual steps. > > My main concern, beyond it being managable from a map designer > standpoint, is also have some way to make them cohesive for the > players. > > It would seem to me in such a system, you'd need the following > information for these subquests: > - What part of quest are they (parent quest) > - what quests do these open when completed. In terms of what the player sees, I think it will suffice to show them a two level hierarchy. The subquests would probably be called 'objectives' or something similar in the client. The default behaviour then would be to only show the active subquests, not the completed ones Any occasion where there are more than two or three nested layers of subquests for one quest probably indicates a need to rethink how the quest is defined, or to split it up into a 'chain' of top-level quests. One thing I do want is hidden quests and quest steps, simply because for many quests, it will be easier to change the state of the quest rather than use markers, and there is a value to suppressing some status changes. (eg, there is one I am looking at where there are a number of monsters around a leader, if one of the monsters is killed, I want to close off a peaceful resolution with the leader, so easier to set the queststate to $bignum rather than track a marker in the dialogue). I think the generic thing to do this is to have a 'parent' marker in the child quest file, and allow each stage of any quest to conditionally advance any other. ie, quest scorn/TerrysFarm .... step 30 advancetarget scorn/DisputedFarm advanceif 0-5 advanceto 10 so that setting the terry's farm quest to state 30 should advance the disputed farm quest to step 10, but only if it is already between steps 0 and 5 (so if it is at step 7, or 20, nothing happens) Obviously, it would be considered bad form to update another quest without there being some story-line reason for doing so. > For example, one could have a quest that has 6 different steps, and > they have to be done in order (doing step 3 before step 2 doesn't > make sense). But you could have other quests where several of the > steps could be done in parallel - a simple example could be alchemy > quest - you may need to get 5 materials for the recipe, but what > order you get them in doesn't matter. I'm not sure how this later > one is handled in the system - the step to go to alchemy master with > cauldron shouldn't open up until all 5 of those subquests are done. This could be done with a hidden quest and lots of combinations of steps, but I think the more sensible solution would be to check the 5 subquests for completion in a dialogue. (so the dialogue script would check all 5 quests are completed before causing the connection on the map to be triggered. > > > > One of the things I will be doing very shortly (ie, the next time I > > change the quest file definition after the release) will be to break > > the default.quests file into lots of smaller files. I was going to > > use the region file to specify these, so that quests then become > > attached to a region of the game world as well. > > Makes sense - ideally, .quest files could sit anywhere in the map > tree, but that would make it trickier for the server to find them all. > > But one could imagine that in some cases, a quest may relate to a > small set of maps (already located in its own directory in the maps > tree), and keeping the quest near there would make sense. > > I wonder if rather than regions file, if maybe adding something > like #include directives into the the default.quests would work? > Server would then just process those and load all quest files. It > should only need to do this at startup, so shouldn't add much to load > time, but gives maximum flexibility. > The reason to want to tie them to regions, is to give an idea of where quests are. If a point is reached where there are hundreds of quests, then one player might have a score or more active at one time. Being able to show only 'local' quests in the interface would help answer the question 'what should I be doing here?' an #include -type system could work for this too, in that case, the quests in the #included files would be in the same region as the quests in the file they were included from. Server side, it just involves a bit of recursion (and maybe a check that files aren't mutually including each other...) > >> Yep. Some quests may also be vague just by their very nature - > >> some locations are supposed to be somewhat hidden or not well > >> known, so at least on first pass, a detailed description of them > >> doesn't make sense. However, as the character learns more > >> information, maybe that gets filled in. > > > > I think there are three ways that this can go: > > > > 1) add 'new_summary' as an option in the quest step which replaces > > the initial summary with a more detailed one once a certain stage is > > passed > > 2) Use the knowledge system to hold knowledge related to a > > quest, but not directly connected to the advancement of it. > > 3) Store the entire history of the quest steps that the player has > > taken, so that the step descriptions for all of them can be made > > visible. Then any updated information can be written in one of the > > step descriptions > > > > I'd tend to favour option 3, at least for non-restartable quests, > > you can then have something of a diary style interface that the > > clients could provide: > > For complex quests, option #1 might be nice - having a quick > summary of where you are in the quest might be desirable than reading > the 15 things you have done so far. > > Simplest way in that case would be to have an optional > summary/endsummary for each step - if set, then when a player reviews > their quest information, it displays the summary of the step the > player has completed the most. It may even be worth having a hybrid approach, so change the summary and allow more detail to be shown about the quest in the interface so that information the player should remember can be looked up by referring to old updates. - I think this is something that should become more apparent with playtesting. Brendan. From juhaj at iki.fi Wed Mar 31 17:32:03 2010 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Wed, 31 Mar 2010 23:32:03 +0100 Subject: [crossfire] TODO list In-Reply-To: <4B514720.8030904@sonic.net> References: <201001142326.47886.nicolas.weeger@laposte.net> <201001151916.35966.nicolas.weeger@laposte.net> <4B514720.8030904@sonic.net> Message-ID: <201003312332.06738.juhaj@iki.fi> > them. But maybe this just goes back to me playing a troll character at one > time, and having to deal with carrying large amounts of food (due to the > trolls bonus is HP regeneration, food usage goes up). Fireborn have the same thing, they also need lots of food. So these two races need serious tweaking if food is removed as a stat (and I think wraiths as well, since they have the advantage of not requiring any food). I have had times where my fireborn was in trouble killing the monsters faster than food stat went down, so I would say that food is not too abuntant at all! Also, dragons' ability gains by food must be tweaked if food is reduced in any significant amount. > and eat it like nothing has happened. Just adding some form of rotting > would probably reduce available food by a bit. Indeed, this is nice. Of course, lembas etc might not rot at all and hearts and livers rot faster than apples or cooked meat... After one gets create food spells, food becomes moot anyway in any case (except the special food and dragons). -- ----------------------------------------------- | Juha J?ykk?, juhaj at iki.fi | | http://www.maths.leeds.ac.uk/~juhaj | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100331/3e5d39e5/attachment.pgp