From pc-crossfire06 at crowcastle.net Sat Feb 5 11:28:30 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Sat, 5 Feb 2022 12:28:30 -0500 Subject: [crossfire] auto_apply_fix() issue Message-ID: <55f6b214-641a-1104-81ed-17ad874f8810@crowcastle.net> I'm playing with some map ideas, and I found that if you have a random item in a container, it works fine, but if you put that container inside something else, the random item isn't processed. I modified auto_apply_fix() to pull out the inventory scanning loop and put it in it's own function so that it can recurse through inventory objects that have inventories of their own. It works for my use case, but I'm nervous about unintended consequences, so I'm not pushing the change unless I get agreement here that it's good.  I've attached the patch for review. -------------- next part -------------- A non-text attachment was scrubbed... Name: auto_apply_fix.patch Type: text/x-patch Size: 5108 bytes Desc: not available URL: From nicolas.weeger at laposte.net Sat Feb 5 12:42:52 2022 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 05 Feb 2022 19:42:52 +0100 Subject: [crossfire] auto_apply_fix() issue In-Reply-To: <55f6b214-641a-1104-81ed-17ad874f8810@crowcastle.net> References: <55f6b214-641a-1104-81ed-17ad874f8810@crowcastle.net> Message-ID: <6864025.HlPKlqn8q7@gros> Hello. The patch looks fine to me, thanks :) One small remark: The test if ( !tmp->inv ) return; at start of auto_apply_fix_inventory isn't required, since you always check the inv before calling the function. 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 pc-crossfire06 at crowcastle.net Sat Feb 5 12:57:55 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Sat, 5 Feb 2022 13:57:55 -0500 Subject: [crossfire] auto_apply_fix() issue In-Reply-To: <6864025.HlPKlqn8q7@gros> References: <55f6b214-641a-1104-81ed-17ad874f8810@crowcastle.net> <6864025.HlPKlqn8q7@gros> Message-ID: <46de862d-9e99-e94a-339b-b230dc052ae1@crowcastle.net> Yes, I'm aware of that, but I'm paranoid about how code might change in the future. On 2022-02-05 13:42, Nicolas Weeger wrote: > Hello. > > > The patch looks fine to me, thanks :) > > > One small remark: > > The test > > if ( !tmp->inv ) return; > > at start of auto_apply_fix_inventory isn't required, since you always check the > inv before calling the function. > > > Best regards > > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pc-crossfire06 at crowcastle.net Thu Feb 10 01:09:45 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Thu, 10 Feb 2022 02:09:45 -0500 Subject: [crossfire] Alchemy formulae file broken Message-ID: <09540ae7-da16-1eb3-ee3a-091d5e2090fe@crowcastle.net> I was doing some testing, and I found several basic alchemy formulas never showed up in books (mercury, philosophical oil, and philosophical salt).  After a lot of digging, I found that this accounted for a chance of 30, and there are 30 chance-1 formulas near the end of the file that aren't getting added to the total correctly.  This is because in recipe.c, it adds the chance to the total_chance when it reads the ingredients, but on those 30 formulas, the chance is listed in the file after the ingredients. While we could say the bug is in the formula file for putting the entries in the wrong order, it would seem like the right fix is to change recipe.c to not care about the order.  I think trying to set the total_chance field as we parse the file is wrong, and we should scan the lists at the end to set the value. From pc-crossfire06 at crowcastle.net Thu Feb 10 11:25:30 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Thu, 10 Feb 2022 12:25:30 -0500 Subject: [crossfire] Alchemy formulae file broken In-Reply-To: <09540ae7-da16-1eb3-ee3a-091d5e2090fe@crowcastle.net> References: <09540ae7-da16-1eb3-ee3a-091d5e2090fe@crowcastle.net> Message-ID: <0d3dc2d8-2bfc-806a-7cbc-b07d04388223@crowcastle.net> I pushed a fix to compute the total_chance at the end. On 2022-02-10 02:09, Preston Crow wrote: > I was doing some testing, and I found several basic alchemy formulas > never showed up in books (mercury, philosophical oil, and > philosophical salt).  After a lot of digging, I found that this > accounted for a chance of 30, and there are 30 chance-1 formulas near > the end of the file that aren't getting added to the total correctly.  > This is because in recipe.c, it adds the chance to the total_chance > when it reads the ingredients, but on those 30 formulas, the chance is > listed in the file after the ingredients. > > While we could say the bug is in the formula file for putting the > entries in the wrong order, it would seem like the right fix is to > change recipe.c to not care about the order.  I think trying to set > the total_chance field as we parse the file is wrong, and we should > scan the lists at the end to set the value. > From pc-crossfire06 at crowcastle.net Tue Feb 15 22:11:43 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Tue, 15 Feb 2022 23:11:43 -0500 Subject: [crossfire] Duplicators that self-destruct Message-ID: <16c6181f-9e5b-690f-b2a5-82fbb483d852@crowcastle.net> I would like to have duplicators that self-destruct after use.  I would use the 'hp' field, but it's already set to one in the archetype, so I'm thinking of using the value.  I have it working on my server:             } *            if ( op->value ) {** **                --op->value;** **                if ( !op->value ) {** **                    object_remove( op );** **object_free_drop_inventory(op);** **                    return;** **                }** **            }*             if ( count <= 1 ) break;             --count; That works.  I'm using it in apartments to remove goldfloors and leave everything pristine, especially where it's buildable after things trigger.  Is there any issue with my pushing this change? Would a different field make more sense for this (perhaps 'sp')? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinz5000 at gmail.com Tue Feb 15 22:15:37 2022 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Tue, 15 Feb 2022 20:15:37 -0800 Subject: [crossfire] Duplicators that self-destruct In-Reply-To: <16c6181f-9e5b-690f-b2a5-82fbb483d852@crowcastle.net> References: <16c6181f-9e5b-690f-b2a5-82fbb483d852@crowcastle.net> Message-ID: On 2/15/22 8:11 PM, Preston Crow wrote: > I would like to have duplicators that self-destruct after use.  I would > use the 'hp' field, but it's already set to one in the archetype, so I'm > thinking of using the value.  I have it working on my server: > >             } > *            if ( op->value ) {** > **                --op->value;** > **                if ( !op->value ) {** > **                    object_remove( op );** > **object_free_drop_inventory(op);** > **                    return;** > **                }** > **            }* >             if ( count <= 1 ) break; >             --count; > > That works.  I'm using it in apartments to remove goldfloors and leave > everything pristine, especially where it's buildable after things > trigger.  Is there any issue with my pushing this change? Would a > different field make more sense for this (perhaps 'sp')? A couple other fields that come to mind are 'food' and 'generator_limit'. As long as it's not being used for something else in the type you're working with though, it should be fine. Just double checking because I don't have diff context, this is only being applied in the type code for duplicators, right? Regards, Kevin From pc-crossfire06 at crowcastle.net Thu Feb 17 15:18:52 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Thu, 17 Feb 2022 16:18:52 -0500 Subject: [crossfire] Default hp/sp for exits Message-ID: <2dd39d96-825f-29f3-1fb9-fbb4361e5840@crowcastle.net> I would like to set the default hp/sp in the archetype for exits to -1, which would make the default be to use the enter_x/y values for the target maps.  I expect these values are always overridden in the maps, so the impact should be minimal, and it would make it cleaner when using a map's default entrance.  My thinking is to encourage the use of the default entrance, as it makes it easier to redesign a map without having to modify the maps that link to it.  (I ran into this on my server adjusting pocket reality maps, and I had to modify all existing apartments to make the changes work cleanly.) I expect there are maps where the exit target is zero in one of the two coordinates.  Since doing a mix of default and specified coordinates is probably a bad idea, I would have the server convert a single -1 to a 0.  I would then only need to search through the maps for any exits with a slaying field but not hp or sp, just in case there are any 0,0 exits on purpose. I noticed a recent commit to all the guild maps to correct an exit coordinate, which might have been avoided by using the map default, but I'm not proposing a mass change to existing exits to convert them (eliminating coordinates on exits if they match the defaults for the target map), though that might not be a bad idea. From pc-crossfire06 at crowcastle.net Thu Feb 17 15:27:15 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Thu, 17 Feb 2022 16:27:15 -0500 Subject: [crossfire] Duplicators that self-destruct In-Reply-To: References: <16c6181f-9e5b-690f-b2a5-82fbb483d852@crowcastle.net> Message-ID: <16ffd15b-64e7-1b32-f8c7-8815195ce234@crowcastle.net> On 2022-02-15 23:15, Kevin Zheng wrote: > On 2/15/22 8:11 PM, Preston Crow wrote: >> I would like to have duplicators that self-destruct after use.  I >> would use the 'hp' field, but it's already set to one in the >> archetype, so I'm thinking of using the value.  I have it working on >> my server: >> >>              } >> *            if ( op->value ) {** >> **                --op->value;** >> **                if ( !op->value ) {** >> **                    object_remove( op );** >> **object_free_drop_inventory(op);** >> **                    return;** >> **                }** >> **            }* >>              if ( count <= 1 ) break; >>              --count; >> >> That works.  I'm using it in apartments to remove goldfloors and >> leave everything pristine, especially where it's buildable after >> things trigger.  Is there any issue with my pushing this change? >> Would a different field make more sense for this (perhaps 'sp')? > > A couple other fields that come to mind are 'food' and > 'generator_limit'. As long as it's not being used for something else > in the type you're working with though, it should be fine. Using 'food' makes a lot more sense.  I'll switch to that. > > Just double checking because I don't have diff context, this is only > being applied in the type code for duplicators, right? > Exactly. From nicolas.weeger at laposte.net Fri Feb 18 12:54:16 2022 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 18 Feb 2022 19:54:16 +0100 Subject: [crossfire] Default hp/sp for exits In-Reply-To: <2dd39d96-825f-29f3-1fb9-fbb4361e5840@crowcastle.net> References: <2dd39d96-825f-29f3-1fb9-fbb4361e5840@crowcastle.net> Message-ID: <1645237897.vTku7B84ee@gros> Hello. > I would like to set the default hp/sp in the archetype for exits to -1, > which would make the default be to use the enter_x/y values for the > target maps. I expect these values are always overridden in the maps, I like the idea, but I wouldn't guarantee that it's the case for all maps :) It's pretty easy to check automatically, though. > so the impact should be minimal, and it would make it cleaner when using > a map's default entrance. My thinking is to encourage the use of the > default entrance, as it makes it easier to redesign a map without having > to modify the maps that link to it. (I ran into this on my server > adjusting pocket reality maps, and I had to modify all existing > apartments to make the changes work cleanly.) Agreed, it's easier. You may need to change some warnings in the server, though, enter_map() will complain if supplied coordinated are invalid. > I expect there are maps where the exit target is zero in one of the two > coordinates. Since doing a mix of default and specified coordinates is > probably a bad idea, I would have the server convert a single -1 to a > 0. I would then only need to search through the maps for any exits with > a slaying field but not hp or sp, just in case there are any 0,0 exits > on purpose. That can easily be checked automatically if needed. Note that this is the current behaviour - if one coordinate is -1, then it'll be replaced by the default map enter x/y one (again, see enter_map()). > I noticed a recent commit to all the guild maps to correct an exit > coordinate, which might have been avoided by using the map default, but > I'm not proposing a mass change to existing exits to convert them > (eliminating coordinates on exits if they match the defaults for the > target map), though that might not be a bad idea. I guess it's easier to do that progressively once your changes are in place. 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 Fri Feb 18 12:56:23 2022 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 18 Feb 2022 19:56:23 +0100 Subject: [crossfire] Modifying Multi-Square Objects In-Reply-To: <5a25cc99-095c-3d23-7b9f-085ac457635f@crowcastle.net> References: <5a25cc99-095c-3d23-7b9f-085ac457635f@crowcastle.net> Message-ID: <2312455.eQQQZU5e44@gros> Hello. Using Gridarta (I suppose that's what you are using?), you can't change those settings for parts, I think. Right now the only good solution is to create a new archetype, or change the part's field in the map directly after editing with Gridarta... 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 pc-crossfire06 at crowcastle.net Fri Feb 18 13:00:39 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Fri, 18 Feb 2022 14:00:39 -0500 Subject: [crossfire] Modifying Multi-Square Objects In-Reply-To: <2312455.eQQQZU5e44@gros> References: <5a25cc99-095c-3d23-7b9f-085ac457635f@crowcastle.net> <2312455.eQQQZU5e44@gros> Message-ID: What's the syntax for changing a field in a specific part in the map? On 2022-02-18 13:56, Nicolas Weeger wrote: > Hello. > > Using Gridarta (I suppose that's what you are using?), you can't change those > settings for parts, I think. > > > Right now the only good solution is to create a new archetype, or change the > part's field in the map directly after editing with Gridarta... > > > Best regards > > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinz5000 at gmail.com Fri Feb 18 13:32:50 2022 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Fri, 18 Feb 2022 11:32:50 -0800 Subject: [crossfire] Default hp/sp for exits In-Reply-To: <1645237897.vTku7B84ee@gros> References: <2dd39d96-825f-29f3-1fb9-fbb4361e5840@crowcastle.net> <1645237897.vTku7B84ee@gros> Message-ID: <173c4737-ea0a-334d-da31-f073159aeedf@gmail.com> On 2/18/22 10:54 AM, Nicolas Weeger wrote: >> I expect there are maps where the exit target is zero in one of the two >> coordinates. Since doing a mix of default and specified coordinates is >> probably a bad idea, I would have the server convert a single -1 to a >> 0. I would then only need to search through the maps for any exits with >> a slaying field but not hp or sp, just in case there are any 0,0 exits >> on purpose. > > That can easily be checked automatically if needed. > > Note that this is the current behaviour - if one coordinate is -1, then it'll > be replaced by the default map enter x/y one (again, see enter_map()). I believe Preston was pointing out that existing maps, that have one of hp/sp set to zero, will not have a hp/sp field (because object_diff() will remove them), but will change to -1 after the change. I suspect there are few exits where one of the coordinates to go zero, but it would be good to do a search and fix them up in case. Regards, Kevin From pc-crossfire06 at crowcastle.net Fri Feb 18 20:54:39 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Fri, 18 Feb 2022 21:54:39 -0500 Subject: [crossfire] Default hp/sp for exits In-Reply-To: <173c4737-ea0a-334d-da31-f073159aeedf@gmail.com> References: <2dd39d96-825f-29f3-1fb9-fbb4361e5840@crowcastle.net> <1645237897.vTku7B84ee@gros> <173c4737-ea0a-334d-da31-f073159aeedf@gmail.com> Message-ID: <8d9cb1d4-53f5-6b5e-1f55-e60cc2a8b006@crowcastle.net> On 2022-02-18 14:32, Kevin Zheng wrote: > On 2/18/22 10:54 AM, Nicolas Weeger wrote: >>> I expect there are maps where the exit target is zero in one of the two >>> coordinates.  Since doing a mix of default and specified coordinates is >>> probably a bad idea, I would have the server convert a single -1 to a >>> 0.  I would then only need to search through the maps for any exits >>> with >>> a slaying field but not hp or sp, just in case there are any 0,0 exits >>> on purpose. >> >> That can easily be checked automatically if needed. >> >> Note that this is the current behaviour - if one coordinate is -1, >> then it'll >> be replaced by the default map enter x/y one (again, see enter_map()). > > I believe Preston was pointing out that existing maps, that have one > of hp/sp set to zero, will not have a hp/sp field (because > object_diff() will remove them), but will change to -1 after the change. > > I suspect there are few exits where one of the coordinates to go zero, > but it would be good to do a search and fix them up in case. > Yes, I pushed a change to enter_map() in server/server.c to change the input x or y to zero if one and only one is negative. This handles most cases of intentional use of 0 as an exit coordinate, such as in buildings in cities on tiled map boundaries.  There was only one legitimate exit to 0,0, which is beginners2 in Scorn.  I pushed a change to the map to specify the 0,0 exit, as the world map has a enter_x/y of 1,1.  These changes should have no impact to anyone. The big change is to the arches. I was surprised to see the arches for magic_portal and perm_magic_portal having default hp/sp of 15,19 and slaying of /city/city.  The hp/sp defaults are used in some of the guild portals, possibly by accident, but I'm not touching those. There are a ton of type 66 (exit) archetypes.  I've set them all to have hp/sp of -1,-1 in my code with an awk script, but it's 297 files (and skips the aforementioned portals). I did some testing, and I pushed the change (961eba31eb8d2df5ec6811d971a4194357aced0e). So unless I missed something, nobody should notice any difference, and going forward, you can leave hp/sp off when defining exits for the main map entrance if enter_x,enter_y are correct.  This should make it simpler to modify maps without also having to change the maps that link to them. I was thinking about decoupling the links in both directions, but that gets a lot more complicated. From pc-crossfire06 at crowcastle.net Sat Feb 19 19:59:08 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Sat, 19 Feb 2022 20:59:08 -0500 Subject: [crossfire] NPC Help Message-ID: <9f783940-5750-5c5f-aeda-678e9f3d1f84@crowcastle.net> If I attack an NPC by standing next to it and attacking with something like 'use_skill one' (or applying a sword and shift-arrow in the direction of the monster), then the NPC will clear the unaggressive flag and call monster_npc_call_help() to alert nearby monsters.  This is in server/attack.c: hit_player() at about line 2072.  If I attack the monster by running at it, then the code in server/move.c: push_obj() at about line 481 does not call for help. Is that intentional? Also, in mosnter_npc_call_help(), it uses object_set_enemy() but does not clear the unaggressive flag, which doesn't seem to make the NPCs move and attack me in my testing. Is that also intentional? From kevinz5000 at gmail.com Sun Feb 20 00:57:50 2022 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 19 Feb 2022 22:57:50 -0800 Subject: [crossfire] NPC Help In-Reply-To: <9f783940-5750-5c5f-aeda-678e9f3d1f84@crowcastle.net> References: <9f783940-5750-5c5f-aeda-678e9f3d1f84@crowcastle.net> Message-ID: On 2/19/22 5:59 PM, Preston Crow wrote: > If I attack an NPC by standing next to it and attacking with something > like 'use_skill one' (or applying a sword and shift-arrow in the > direction of the monster), then the NPC will clear the unaggressive flag > and call monster_npc_call_help() to alert nearby monsters.  This is in > server/attack.c: hit_player() at about line 2072.  If I attack the > monster by running at it, then the code in server/move.c: push_obj() at > about line 481 does not call for help. > > Is that intentional? > > Also, in mosnter_npc_call_help(), it uses object_set_enemy() but does > not clear the unaggressive flag, which doesn't seem to make the NPCs > move and attack me in my testing. > > Is that also intentional? I remember looking nearby in that neighborhood of code, and so my guess is probably not. There are a lot of code paths that should result in a monster calling for help, so my guess is that there is some code duplication that makes this happen inconsistently. (If I remember, I was looking at how monsters that are asleep, when attacked through a certain code path, call for help...) If you have a fix, I would welcome it to be committed. Regards, Kevin From pc-crossfire06 at crowcastle.net Sun Feb 20 17:26:18 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Sun, 20 Feb 2022 18:26:18 -0500 Subject: [crossfire] buttons and teleporting Message-ID: If you teleport off of a button, it stays pressed, so the next player to move onto it doesn't trigger it.  I ran into this with a map where a button triggers a teleporter and other actions on the map.  It works great for the first player to hit it, but then fails.  I think the teleporter bypasses any move off logic, but I don't see how to fix that.