From nicolas.weeger at laposte.net Wed Nov 11 02:59:13 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 11 Nov 2020 09:59:13 +0100 Subject: [crossfire] Graphism, tiles, size, and such Message-ID: <2045231.2u01eHhg90@gros> Hello. I've been thinking about game graphics, and I'd like to share some questions and thoughts. Monsters like the hill giant (I can also think of the ArchAngel, the Retributioner, some dragons too) have an incoherent size IMO. They are 1x2 in tiles, but that only reflects their height, not their "planar" size. So I'm wondering: - should we keep that behaviour - should monsters be only tiled squarely (eg 1x1, 2x2, etc.), and we adjust the sprite to reflect the height - should we allow sprites to overflow on top of another sprite, so the height would appear (the hill giant would then be 1x1 with a 1x2 sprite adjusted to its feet) Other ideas? Another thought was wondering about making 48x48 (or 64x64?) sprites. 32x32 seems quite small with current resolutions... I'm not saying to redo all sprites, but maybe clients could handle resizing from 32x32 to 48x48 when required or directly use a 48x48 sprite. This would allow to slowly rework some tiles as we feel it, introducing more details. Been also idly thinking of changing players to be eg 3x3 tiles, so we could have really small monsters (1x1 tiles). But that would be quite a change... In this case, maybe on the opposite sprites could stay 32x32, or even go down to 16x16, but eg players would be bigger anyway. Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Wed Nov 11 03:07:23 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 11 Nov 2020 10:07:23 +0100 Subject: [crossfire] Code cleaning: discrete damage Message-ID: <2601972.siR9A8jBxB@gros> Hello. Unless someone objects with good arguments, I'd like to remove support for discrete damage for each attack type. This is only used by flame touch, for physical damage, so I guess it can safely be removed... Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Thu Nov 12 00:15:27 2020 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 11 Nov 2020 22:15:27 -0800 Subject: [crossfire] Graphism, tiles, size, and such In-Reply-To: <2045231.2u01eHhg90@gros> References: <2045231.2u01eHhg90@gros> Message-ID: On 11/11/20 12:59 AM, Nicolas Weeger wrote: > Hello. > > > I've been thinking about game graphics, and I'd like to share some questions > and thoughts. > > > > Monsters like the hill giant (I can also think of the ArchAngel, the > Retributioner, some dragons too) have an incoherent size IMO. They are 1x2 in > tiles, but that only reflects their height, not their "planar" size. > > So I'm wondering: > - should we keep that behaviour > - should monsters be only tiled squarely (eg 1x1, 2x2, etc.), and we adjust > the sprite to reflect the height > - should we allow sprites to overflow on top of another sprite, so the height > would appear (the hill giant would then be 1x1 with a 1x2 sprite adjusted to > its feet) > > Other ideas? I think when things were changed a while back so that image size & footprint of the creature were not tied together, making hill giants 1x1 footprint (and other similar tall creatures have a square footprint) was either done or investigated, but not done or reverted back. For players, higher density monsters tends to be an advantage (those AoE spells hits more targets). I can't remember if there might now have been some map breakage by changing this, and monsters could now wander to places they were not envisioned going, etc. There are also some other cases where monsters should be rectangular - wyverns come to mind. But there really isn't good support for going from a 1x2 monsters to a 2x1 monster as it changes direction. > > > > Another thought was wondering about making 48x48 (or 64x64?) sprites. > > 32x32 seems quite small with current resolutions... > > I'm not saying to redo all sprites, but maybe clients could handle resizing > from 32x32 to 48x48 when required or directly use a 48x48 sprite. This would > allow to slowly rework some tiles as we feel it, introducing more details. The gtk client at least supported resizing the images used for the map and inventory. As resolution has gone up (a 25x25 map at 32 pixels/image is only 800x800), bigger images could certainly be done. I'm not sure the correct size - whether 128x128 would be best, and then scale down would be best way to future proof for a while? Disadvantage is size. > > > Been also idly thinking of changing players to be eg 3x3 tiles, so we could > have really small monsters (1x1 tiles). But that would be quite a change... In > this case, maybe on the opposite sprites could stay 32x32, or even go down to > 16x16, but eg players would be bigger anyway. Multispace players will likely require lots of work (does every map now need to expanded, because otherwise that 3x3 player won't fit down those small passage or through small doors?) but things like what space does a spell leave the player from? How about incoming spells, and does the player end up taking more damage if many 4 of his spaces are hit by a spell (I sort of recall this was the case for monsters) But I suppose it depends on what is the minimum reasonable 'unit' for most things to me. For small monsters, I wonder if it would be easier to let small creatures share a space - instead of the 'is there something alive on this space', instead each creature could have how much of the space they use. So small creatures might only use 25% of a space, so 4 of them could be on the same space. Though I'm not sure how you deal with what image is used for each of those creatures. From nicolas.weeger at laposte.net Fri Nov 13 11:15:56 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 13 Nov 2020 18:15:56 +0100 Subject: [crossfire] Archetypes collection changes proposal In-Reply-To: <1906015.4M1vBobDh4@gros> References: <1906015.4M1vBobDh4@gros> Message-ID: <4111432.yx9kclvYjC@gros> Hello. I finally managed to make good progress, so joining a patch to this message for comments & review & whatever else :) This is a work in progress, and may crash at any point :) The following files are now grabbed from individual files instead of "collected" files: - treasures (from .trs files) - face and animations (from .face files) - archetypes (from .arc files) It should be safe to point to the install directory containing the collected files, if the "arch" directory is linked from there. Still needs to be done: - artifacts - messages - alchemy formulae - faceset informations - face data - change the location of "smooth face" definition - it's in the .arc but applied to the face with that name... (this will require changes to Gridarta if used) Maybe specific extensions may be introduced for eg artifacts, messages, formulae, to not use the exact filename. Collect is done from the base directory, each file is processed, then for each sub-directory the process is repeated. Names are sorted case-sensitive in both cases. With those changes, it is now possible to redefine archetypes, treasures, faces or animations. It's allowed to have multiple definitions, the latest found will be used. Archetypes in particular should correctly update items in inventories of other archetypes when redefined (thus you could redefine the "event_apply" if you want, it should be ok and update eg the altar of Valkyrie). Warning: for multiple tiles monsters, this may crash, especially if you change the size of monsters... For artifacts, since it's hard to identify exactly an artifact (no exact name), I think I'll add a mechanism to "remove" choices & such for types - thus one could clean part of artifacts before adding one's specific ones. Same mechanism for formulae probably. Various comments on the code: - I did introduce C++ (C++11 I think) for the collect code, and moved arch.c to arch.cpp - CRE is broken - unit tests are broken / invalid / need to be updated - much cleaning will probably be done, to separate cleanly "collecting" and "use" parts (thus a collecting class, maintaining eg the list of treasures, in its file, and functions related to actual treasure generation and thus). I do intend to use C++ features for this, but not change everything for the sake of it Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: nc.patch Type: text/x-patch Size: 96129 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nkipps at gmail.com Sun Nov 15 11:43:49 2020 From: nkipps at gmail.com (Nathaniel Kipps) Date: Sun, 15 Nov 2020 12:43:49 -0500 Subject: [crossfire] Graphism, tiles, size, and such In-Reply-To: References: <2045231.2u01eHhg90@gros> Message-ID: On Thu, Nov 12, 2020 at 1:26 AM Mark Wedel wrote: > On 11/11/20 12:59 AM, Nicolas Weeger wrote: > - should monsters be only tiled squarely (eg 1x1, 2x2, etc.), and we adjust > the sprite to reflect the height Based on personal preference, I think that having rectangular monsters is interesting, and there is no need to force everything to conform to a square. > > - should we allow sprites to overflow on top of another sprite, so the height > > would appear (the hill giant would then be 1x1 with a 1x2 sprite adjusted to > > its feet) I would say no. CF already does well with non-overlapping sprites looking "good", I think adding overlapping sprites in any fashion is a huge effort for minimal gain. At the very least, it's a large shift in the project direction, and one that I wouldn't like. > > Another thought was wondering about making 48x48 (or 64x64?) sprites. > > I'm not saying to redo all sprites, but maybe clients could handle resizing > > from 32x32 to 48x48 when required or directly use a 48x48 sprite. This would > > allow to slowly rework some tiles as we feel it, introducing more details. Per SilverNexus' efforts, there is already some level of support for other sizes of sprites. I would suggest that effort toward other sprite sizes be limited to alternate tilesets, and if such a tileset was ever complete enough to be used for the entire game, then the client devs can decide if they want to make it the default, and if they need any fallback logic for missing sprites. > The gtk client at least supported resizing the images used for the map and inventory. As resolution has gone up (a 25x25 map at 32 pixels/image is only 800x800), bigger images could certainly be done. I'm not sure the correct size - whether 128x128 would be best, and then scale down would be best way to future proof for a while? Disadvantage is size. When calculating the "new ideal" size, remember that many screens are rapidly increasing not only resolution, but also density. Both 2k @ 27 inches and 4k @ 27 inches are rather common right now, and densities could increase even more, especially on laptops (4k @ 15 inches is not unheard of) > But I suppose it depends on what is the minimum reasonable 'unit' for most things to me. For small monsters, I wonder if it would be easier to let small creatures share a space - instead of the 'is there something alive on this space', instead each creature could have how much of the space they use. So small creatures might only use 25% of a space, so 4 of them could be on the same space. Though I'm not sure how you deal with what image is used for each of those creatures. I don't really like this idea, partly because I don't see much of a reason to have it. (We're still basically a Gauntlet/Nethack/LoTR, and I like it that way.) --DraugTheWhopper From nicolas.weeger at laposte.net Mon Nov 16 10:55:20 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 16 Nov 2020 17:55:20 +0100 Subject: [crossfire] Archetypes collection changes proposal In-Reply-To: <1906015.4M1vBobDh4@gros> References: <1906015.4M1vBobDh4@gros> Message-ID: <1656050.unDkfINhoB@gros> Hello. I've made enough progress to consider that things work as expected :) My tests are basically to connect as a player, move some around, cast spells, create artifacts, things like that. As well as check things through CRE, and the unit tests. Attached are patches to the server & CRE. The server will now load everything directly from the arch directory, without any collect mechanism at all (you can probably leave your collected files, it should be all right, else I have a bug :)). After some runs, the launch of "crossfire-server -m3" (which does load everything) takes <6s, which I consider quite adequate. From a "cold" start, it may be more of course... I'd like opinions (please read the caveats too before replying :)) on the next step: - should I commit to a branch, and let people running a server test that branch? - should I commit to trunk directly and hope for the best? I should point out I don't plan running a server myself - not enough players around to attract some testers :) Caveats of the current code: - unit tests (some were modified) and CRE now work correctly - you'll probably have memory leaks when redefining things like actual PNG, messages, and such - it's a "static" leak, so won't grow over time, but still, it'll be fixed - code is still quite messy, planning a big cleaning up soon - files "materials" and "races" are still copied from arch, on my to-fix list :) - I only compiled using g++ (version 6.3.0), but Partmedia compiled the previous patch with clang and pointed some stuff I fixed - no idea on portability And someday I'll move the "smoothface" out of the .arc files to put'em in the .face where they definitely belong... This will require changes to Gridarta though ;) Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: nc-cre.patch Type: text/x-patch Size: 15697 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nc.patch Type: text/x-patch Size: 137070 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Tue Nov 17 13:44:16 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 17 Nov 2020 20:44:16 +0100 Subject: [crossfire] Chaos attack type (v1.12 17760rc): good or bad? In-Reply-To: References: Message-ID: <15753423.4aobfqRUod@gros> Hello. Sorry for the late reply :) Indeed, chaos apparently uses a random attack type, ignoring the weapon's one. And obviously not caring about what you're hitting :) So losing life-stealing is logical in this case. I'm not sure there is chaos resistance on armor, but I may be wrong. In any case I don't think it'd protect from anything, as chaos merely makes that random choice, it's not used. Best regards Nicolas Le mercredi 30 septembre 2020, 11:38:02 CET Siegfried Eureca a écrit : > I've been playing around with a Xerina I blessed with devourers (i.e. > attack types include physical, chaos, death, depletion, drain, life > stealing). I'm noticing that, despite the weapon having great speed and WC > bonuses, it performs poorly on angels (Valriel's Church) and demons > (Gorokh's Pit), it performs poorly compared to other one-handed weapons > like Dark Blade of Devourers and Harakiri Sword of Devourers. > > It's to my understanding that, if a weapon has multiple attack types, the > server will calculate the potential damage per attack of each attack type, > and use the "best"/maximal value when deciding how much damage a creature > receives (nice!). However, I'm noticing that when using a weapon that has > the chaos attack type, this doesn't appear to be the case. I see attack > types that don't benefit me being used (i.e. electricity on hill giants, > fire on demons, etc.). > > I've done some source diving, but can't quite make out how chaos is > supposed to work. Does it just pick a random attack type from the "pool" of > attack types that chaos provides, or some random value of the other attack > types on the weapon AND those supplied by the chaos "pool", or some other > calculation? It seems that chaos isn't a particularly useful attack type in > general, since it appears to be random in nature (rather than the default > "pick the best" behavior most other weapons have), and seems to turn off > the life-stealing ability of Devourers-blessed weapons. > > Also, does armor with chaos resistance block damage from chaos > weapons/spells, or does it just protect against a random element when I'm > attacked? > > Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From leaf at real-time.com Tue Nov 17 13:58:29 2020 From: leaf at real-time.com (Rick Tanner) Date: Tue, 17 Nov 2020 13:58:29 -0600 Subject: [crossfire] Chaos attack type (v1.12 17760rc): good or bad? In-Reply-To: <15753423.4aobfqRUod@gros> References: <15753423.4aobfqRUod@gros> Message-ID: <46ce8106-facc-ae25-d29b-607572458004@real-time.com> As far as I know, this is the only item that offers Chaos resistance. Vardimar the Singing Axe +5 Damage: 18 Attacks: physical, chaos Protected: resist chaos +30 Vulnerable: resist confusion -100 Djinn-slaying Material: metal wood Weight: 28.000 kg On 11/17/20 1:44 PM, Nicolas Weeger wrote: > > I'm not sure there is chaos resistance on armor, but I may be wrong. In any > case I don't think it'd protect from anything, as chaos merely makes that > random choice, it's not used. > From pc-crossfire06 at crowcastle.net Tue Nov 17 13:50:32 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Tue, 17 Nov 2020 14:50:32 -0500 Subject: [crossfire] Chaos attack type (v1.12 17760rc): good or bad? In-Reply-To: <15753423.4aobfqRUod@gros> References: <15753423.4aobfqRUod@gros> Message-ID: <8a6565cc-476c-9c5a-4efb-b000f038a08f@crowcastle.net> I should stop wearing these: That is Chaos shoes * (worn) (ac+5)(Spell regen penalty 1)(armour +5)(resist chaos +10) It goes on your feet (2) It weighs 2.000 kg. You reckon it is worth 7 platinum coins and 2 silver coins. On 2020-11-17 14:44, Nicolas Weeger wrote: > Hello. > > > Sorry for the late reply :) > > > Indeed, chaos apparently uses a random attack type, ignoring the weapon's one. > And obviously not caring about what you're hitting :) > > So losing life-stealing is logical in this case. > > > I'm not sure there is chaos resistance on armor, but I may be wrong. In any > case I don't think it'd protect from anything, as chaos merely makes that > random choice, it's not used. > > > Best regards > > > Nicolas > > > Le mercredi 30 septembre 2020, 11:38:02 CET Siegfried Eureca a écrit : >> I've been playing around with a Xerina I blessed with devourers (i.e. >> attack types include physical, chaos, death, depletion, drain, life >> stealing). I'm noticing that, despite the weapon having great speed and WC >> bonuses, it performs poorly on angels (Valriel's Church) and demons >> (Gorokh's Pit), it performs poorly compared to other one-handed weapons >> like Dark Blade of Devourers and Harakiri Sword of Devourers. >> >> It's to my understanding that, if a weapon has multiple attack types, the >> server will calculate the potential damage per attack of each attack type, >> and use the "best"/maximal value when deciding how much damage a creature >> receives (nice!). However, I'm noticing that when using a weapon that has >> the chaos attack type, this doesn't appear to be the case. I see attack >> types that don't benefit me being used (i.e. electricity on hill giants, >> fire on demons, etc.). >> >> I've done some source diving, but can't quite make out how chaos is >> supposed to work. Does it just pick a random attack type from the "pool" of >> attack types that chaos provides, or some random value of the other attack >> types on the weapon AND those supplied by the chaos "pool", or some other >> calculation? It seems that chaos isn't a particularly useful attack type in >> general, since it appears to be random in nature (rather than the default >> "pick the best" behavior most other weapons have), and seems to turn off >> the life-stealing ability of Devourers-blessed weapons. >> >> Also, does armor with chaos resistance block damage from chaos >> weapons/spells, or does it just protect against a random element when I'm >> attacked? >> >> Thank you. > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.weeger at laposte.net Thu Nov 19 15:51:23 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 19 Nov 2020 22:51:23 +0100 Subject: [crossfire] Graphism, tiles, size, and such In-Reply-To: References: <2045231.2u01eHhg90@gros> Message-ID: <1883607.osnZfbDN4D@gros> Hello. > I think when things were changed a while back so that image size & > footprint of the creature were not tied together, making hill giants 1x1 > footprint (and other similar tall creatures have a square footprint) was > either done or investigated, but not done or reverted back. For players, > higher density monsters tends to be an advantage (those AoE spells hits > more targets). I can't remember if there might now have been some map > breakage by changing this, and monsters could now wander to places they > were not envisioned going, etc. Don't remember those changes, but then I don't remember everything that happened on the project :) > There are also some other cases where monsters should be rectangular - > wyverns come to mind. But there really isn't good support for going from a > 1x2 monsters to a 2x1 monster as it changes direction. Note that "turning transports" actually fulfill that, in the sense that even if they are 2x2, they don't occupy all space depending on the orientation. Check the "/test/boat" map (just fixed a glitch there), the transport turns and can go through 1 height passage when horizontal even though it is 2x2. Granted, the code seems slightly hackish... So this could be expanded to monsters if needed and wanted, maybe making it even cleaner. > The gtk client at least supported resizing the images used for the map and > inventory. Good to know, then bigger pictures can be made for clients which would display bigger than 32x32 :) > As resolution has gone up (a 25x25 map at 32 pixels/image is > only 800x800), bigger images could certainly be done. I'm not sure the > correct size - whether 128x128 would be best, and then scale down would be > best way to future proof for a while? Disadvantage is size. Yes, really big pictures could be an issue... On the other hand, if we solve that size issue, then sounds may work the same way ;) > Multispace players will likely require lots of work (does every map now > need to expanded, because otherwise that 3x3 player won't fit down those > small passage or through small doors?) but things like what space does a > spell leave the player from? True. That's why it's idly thinking :) But as a first step current maps could be "tripled" at loading, to keep'em working... Not sure it'd be worth doing that, again :) > How about incoming spells, and does the > player end up taking more damage if many 4 of his spaces are hit by a spell > (I sort of recall this was the case for monsters) Yes, monsters take more damage per square hit, I think. > But I suppose it depends on what is the minimum reasonable 'unit' for most > things to me. For small monsters, I wonder if it would be easier to let > small creatures share a space - instead of the 'is there something alive on > this space', instead each creature could have how much of the space they > use. So small creatures might only use 25% of a space, so 4 of them could > be on the same space. Though I'm not sure how you deal with what image is > used for each of those creatures. That's an interesting idea. I'm not sure how easy it'd be to implement, and whether it is worth it or not... Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Wed Nov 18 11:47:36 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 18 Nov 2020 18:47:36 +0100 Subject: [crossfire] Archetypes collection changes proposal In-Reply-To: <1906015.4M1vBobDh4@gros> References: <1906015.4M1vBobDh4@gros> Message-ID: <2267145.JV12C2HrmB@gros> Hello. Here is another version of the patches, in which I moved stuff around and refactored. The code is from my point of view clean enough for committing, but it probably needs more testing :) Note that I didn't touch code when I didn't have to, I only adjusted what I needed for my collect-less rewrite - in the future, many things could be simplified with C++ stuff... Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: nc-cre.patch Type: text/x-patch Size: 19353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nc.patch Type: text/x-patch Size: 238907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Tue Nov 24 16:00:12 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 24 Nov 2020 23:00:12 +0100 Subject: [crossfire] Archetypes collection changes proposal In-Reply-To: <1906015.4M1vBobDh4@gros> References: <1906015.4M1vBobDh4@gros> Message-ID: <19358184.cMnRteQz4t@gros> Hello. Here's the latest version of my patch :) Comments & suggestions welcome of course. I'd really like some feedback or ideas on how to integrate it to trunk :D Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: nc.patch Type: text/x-patch Size: 257628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nc-cre.patch Type: text/x-patch Size: 19353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From kevinz5000 at gmail.com Thu Nov 26 14:41:04 2020 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Thu, 26 Nov 2020 12:41:04 -0800 Subject: [crossfire] Speech bubbles for NPCs In-Reply-To: <1771308c-e364-412b-3dda-9f833b82324e@gmail.com> References: <1771308c-e364-412b-3dda-9f833b82324e@gmail.com> Message-ID: <7b1233c8-88a8-65bf-b12d-ad389ff2c6cd@gmail.com> On 11/26/20 12:39 PM, Kevin Zheng wrote: > This attached patch, along with the attached archetypes, adds speech > bubbles to monsters and NPCs. I attached the wrong patch. The right one is attached here. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 2348 bytes Desc: not available URL: From kevinz5000 at gmail.com Thu Nov 26 14:39:56 2020 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Thu, 26 Nov 2020 12:39:56 -0800 Subject: [crossfire] Speech bubbles for NPCs Message-ID: <1771308c-e364-412b-3dda-9f833b82324e@gmail.com> Hi there, This attached patch, along with the attached archetypes, adds speech bubbles to monsters and NPCs. Speech bubbles increase discoverability for interesting dialog. In Crossfire, there are many NPCs and monsters who have no dialog, and so trying to chat up every single NPC is a bit tedious. I think a change like this makes the game more fun to play. Regards, Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 3264 bytes Desc: not available URL: -------------- next part -------------- Object speechbubble face speech.111 end -------------- next part -------------- A non-text attachment was scrubbed... Name: speech.base.111.png Type: image/png Size: 500 bytes Desc: not available URL: From nicolas.weeger at laposte.net Fri Nov 27 02:06:11 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 27 Nov 2020 09:06:11 +0100 Subject: [crossfire] Speech bubbles for NPCs In-Reply-To: <1771308c-e364-412b-3dda-9f833b82324e@gmail.com> References: <1771308c-e364-412b-3dda-9f833b82324e@gmail.com> Message-ID: <13279721.HHkUbyii7m@gros> Hello. Sounds nice :) Wouldn't it be worth checking the "is_friendly" flag too? I think some monsters (raas in particular) have a message defined but will definitely not talk to the player :) Best regards Nicolas Le jeudi 26 novembre 2020, 12:39:56 CET Kevin Zheng a écrit : > Hi there, > > This attached patch, along with the attached archetypes, adds speech > bubbles to monsters and NPCs. > > Speech bubbles increase discoverability for interesting dialog. In > Crossfire, there are many NPCs and monsters who have no dialog, and so > trying to chat up every single NPC is a bit tedious. > > I think a change like this makes the game more fun to play. > > Regards, > Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Mon Nov 30 12:28:29 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 30 Nov 2020 19:28:29 +0100 Subject: [crossfire] Archetypes collection changes proposal In-Reply-To: <19358184.cMnRteQz4t@gros> References: <1906015.4M1vBobDh4@gros> <19358184.cMnRteQz4t@gros> Message-ID: <3256487.CeY3E2ERJf@gros> Hello. So, anyone courageous (or crazy? :)) enough to have looked at my patch? :) Best regards Nicolas Le mardi 24 novembre 2020, 23:00:12 CET Nicolas Weeger a écrit : > Hello. > > > Here's the latest version of my patch :) > > Comments & suggestions welcome of course. > > > > > I'd really like some feedback or ideas on how to integrate it to trunk :D > > > > Best regards > > > Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: