[crossfire] Server log messages
I'm seeing some server log messages that seem to indicate a need to clean stuff up: 23/10/22 13:46:18 [DD] archetype exceptional beauty has nrof set to 4, which will be ignored 23/10/22 13:46:18 [DD] archetype flawless beauty has nrof set to 4, which will be ignored 23/10/22 13:46:18 [DD] archetype Blessedness has nrof set to 10, which will be ignored 23/10/22 13:46:18 [DD] archetype Assassinating Dragons has nrof set to 10, which will be ignored 23/10/22 13:46:18 [DD] archetype Assassinating Trolls has nrof set to 10, which will be ignored I think those are from the artifacts file, and I would remove the nrof entries, but I'm afraid they might be used somewhere despite the message. Also at startup: [DD] Artifact with no chance: white leather [DD] Artifact with no chance: black leather [DD] Artifact with no chance: Sirens [DD] Monster Valkyrie has hp set higher than maxhp (350>0) [DD] Monster Belzebub has hp set higher than maxhp (2>15000) [DD] Monster cave byakie has hp set higher than maxhp (1>8000) [DD] Monster twisted sprite has hp set higher than maxhp (5500>4000) The HP higher than max might be an error, but it does block some healing, so it might be intentional. I also see similar messages on some map loads where I assume the correct answer is to also set maxhp to match hp (e.g., Beserker on /scorn/oldcity/oldcity54) And on some map loads: 23/10/11 14:03:26 [DD] citylife: adding 6 NPC to map /world/world_105_116. 23/10/11 14:03:26 [DD] Merged duplicate skill skill_use_magic_item for farmer 23/10/11 14:03:26 [DD] citylife: adding 5 NPC to map /world/world_105_115. 23/10/11 14:03:26 [DD] Merged duplicate skill skill_use_magic_item for man 23/10/11 14:03:26 [DD] Merged duplicate skill skill_use_magic_item for man 23/10/11 14:03:26 [DD] Warning: Tried to insert object wrong part of multipart object. 23/10/11 14:03:26 [DD] Warning: Tried to insert object wrong part of multipart object. 23/10/11 14:03:26 [DD] Warning: Tried to insert object wrong part of multipart object. 23/10/11 14:08:14 [DD] load_objects on /scorn/misc/battle_arena/entrance took 5679 us 23/10/11 14:08:14 [DD] Merged duplicate skill skill_use_magic_item for ticket vendor I think the duplicate skill has something to do with 'race human,' but I didn't find it. And over two thirds of the messages in my log are starting the Move_Fog.py and Moving_Fog.py scripts (2.2 out of 2.8 million lines). It may be a good idea to only issue log messages for python scripts that fail or have some output. ___ crossfire mailing list crossfire@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
[crossfire] stealing abuse
There are a number of abuses for the stealing skill to gain ridiculous XP. Generally they all boil down to being able to get the stealing XP for a monster every time you steal from it, not just the first time. I'm not sure what the right fix would be, but one idea might be to insert an object into the monster when stealing xp is awarded to flag it as not granting stealing xp. That would eliminate the entire category of abuses. Thoughts? Anyone want to implement a solution? ___ crossfire mailing list crossfire@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
[crossfire] huge money bug
A player alerted me that using alchemy, you can convert a huge gold nugget into a ridiculous number of smaller nuggets that you can actually pick up. While the economy in the game tends to break down for higher level characters, it wouldn't be a bad idea to fix the worst of the abuses. It's probably worth examining all uses of arch hugenugget, though the two in navar_city/mlab/ttower28 are the ones my player cited. ___ crossfire mailing list crossfire@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
Re: [crossfire] metaserver differences and code
Ahh, I'm running on my home fibre connection. That explains why the
metaserver might not like me.
On 4/14/23 16:00, Rick Tanner wrote:
Another note...
https://sourceforge.net/p/crossfire/metaserver/ci/master/tree/meta_update.php#l40
Which is:
// Basically, either forward or reverse addressing must work -
// if the ip that the user specified hostname resolves to does
// not match that of the incoming connection, or the hostname based
// on the ip of the incoming connection does not match that specified
// by the server, we reject this user - no spoofing of other servers
// allowed.
if ($ip != $_SERVER['REMOTE_ADDR'] && $hostname != $_POST['hostname']) {
echo "neither forward nor reverse DNS look corresponds to incoming
ip address.\n";
echo "incoming ip: " . $_SERVER['REMOTE_ADDR'] . ", DNS of that:
$hostname\n";
echo "User specified hostname: " . $_POST['hostname'] . " IP of
that hostname: $ip\n";
log_message(LOG_WARN, $_SERVER['REMOTE_ADDR'] . " does not have
correct hostname set\n");
exit;
}
And find this:
$ dig crossfire.crowcastle.com
crowcastle.com.
173.48.158.241
$ dig -x 173.48.158.241
pool-173-48-158-241.bstnma.fios.verizon.net.
___
crossfire mailing list
crossfire@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
___
crossfire mailing list
crossfire@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
[crossfire] metaserver differences and code
https://crossfire.real-time.com/metaserver-info/index.html The above page and the code reference three active metaservers, the Primary, European, and US mirrors. Looking at the servers they list, they're surprisingly different. I know my server, crowcastle.com, is sending updates to all three without any errors, but only shows up on the EU mirror. Is something broken? I've been looking in the server code, and I don't see anything that would explain the issue. I do get a ton of compiler warnings about deprecated curl interfaces, but I'm not touching that both because I'm not familiar with the library and because I'm afraid of breaking things because I don't know if anyone is depending on an older version that doesn't have the new interfaces. If we're intentionally not updating, then perhaps add -Wno-deprecated to the makefile for that module. ___ crossfire mailing list crossfire@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
[crossfire] Scorn Smith
I think the smith in Scorn is broken. He took my shield and money, but is never able to finish. While I have local changes, I don't think anything impacts this. I see this in the logs: 23/04/12 21:05:41 [DD] CFPython: running script /usr/games/crossfire/share/crossfire/maps/python/dialog/npc_dialog.py 23/04/12 21:05:41 [DD] CFPython: Loading NPC dialog /usr/games/crossfire/share/crossfire/maps/scorn/shops/smith.msg 23/04/12 21:05:41 [EE] CFPython: CFDialog: Failed to evaluate condition ['age', 'orderplaced', '0', '0', '1', '0', '0']: name 'Crossfire' is not defined. 23/04/12 21:05:41 [DD] CFPython: Ignoring NPC dialog from ['smith_finished.msg'], conditions not met This is on the crowcastle.com server. Is this working elsewhere? I have python 3.9 in case that matters. ___ crossfire mailing list crossfire@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
Re: [crossfire] Building in C++?
Crossfire is built around objects, so I can see why making such a change would seem to make sense, but I'm not clear that it would really improve anything in particular. The first question is what language features in C++ would be useful? I was looking at making the maximum window size a runtime config option instead of a compile-time option (default 25x25 now). There are places where using a language with object constructors would make that much simpler since we have a bunch of hard-coded arrays now. I don't think this justifies such a change. I'm a bit concerned about security running a public Crossfire server. Switching to C++ would do nothing to help, but I was thinking Rust would be interesting. That would be a major porting effort; essentially a rewrite. Probably not worth it, especially for such a relatively new language. For the server, the game is quite stable, so we would need some major reason to make a big change. Most of the changes now should be tweaks to fix issues, often hidden bugs that are exposed when a new map tries something original. Ultimately, what the game needs is not server work. It needs more players and more maps. For more players, a browser-based client would be awesome. For more maps, I'm working on some on my server, which I'll push out eventually. If you want to do coding, is there some possibility to build a client in Rust compiled to Webassembly to run in a browser? That would be all kinds of awesome! On 5/27/22 09:46, Nicolas Weeger wrote: Hello. I just pushed branch "cpp-build" which changes all .c files to .cpp files. The only other changes are what was required for correctly building (adding some casts, renaming a few variables, things like that). Functionally, everything is the same. I'd like to merge those changes to master, but well, I'd like to get opinions before. I don't plan on migrating to a full C++ code base with classes, inheritance & other things, the current code is fine. I do plan to use C++ to replace some home-grown things (lists handling mostly - for new code, I don't want to always have to realloc() and check size, a std::vector is enough for that), and to solve issues with object* items being free'd while still referenced (with our nice check on "count == saved_count" here and there urgh). Regards Nicolas ___ crossfire mailing list crossfire@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 ___ crossfire mailing list crossfire@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
[crossfire] buttons and teleporting
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. ___ crossfire mailing list crossfire@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
[crossfire] NPC Help
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? ___ crossfire mailing list crossfire@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
Re: [crossfire] Default hp/sp for exits
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. ___ crossfire mailing list crossfire@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
Re: [crossfire] Modifying Multi-Square Objects
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@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 ___ crossfire mailing list crossfire@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
Re: [crossfire] Duplicators that self-destruct
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.
___
crossfire mailing list
crossfire@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
[crossfire] Default hp/sp for exits
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. ___ crossfire mailing list crossfire@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
[crossfire] Duplicators that self-destruct
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')?
___
crossfire mailing list
crossfire@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
Re: [crossfire] Alchemy formulae file broken
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. ___ crossfire mailing list crossfire@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
[crossfire] Alchemy formulae file broken
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. ___ crossfire mailing list crossfire@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
Re: [crossfire] auto_apply_fix() issue
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@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 ___ crossfire mailing list crossfire@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
[crossfire] auto_apply_fix() issue
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.
--- server/apply.c.orig 2022-02-04 16:16:11.556265095 -0500
+++ server/apply.c 2022-02-05 12:18:26.530299989 -0500
@@ -1451,6 +1451,64 @@
}
/**
+ * Go through one object on a map and process any special treasure creation
+ * or such for anything in it's inventory. Recurse through any inventory
+ * objects that have inventories of their own.
+ * This is only called by auto_apply_fix() below and by itself for recursion.
+ *
+ * @param m
+ * map to fix (only for the difficulty level for treasure creation)
+ * @param tmp
+ * object with inventory to scan
+ */
+
+static void auto_apply_fix_inventory(mapstruct *m, object *tmp)
+{
+ if ( !tmp->inv ) return;
+ FOR_INV_PREPARE(tmp, invtmp) {
+ if ( invtmp->inv ) auto_apply_fix_inventory(m,invtmp); // Recurse for containers in objects
+ if (QUERY_FLAG(invtmp, FLAG_AUTO_APPLY))
+ apply_auto(invtmp);
+ else if (invtmp->type == TREASURE && HAS_RANDOM_ITEMS(invtmp)) {
+ while (invtmp->stats.hp-- > 0)
+ create_treasure(invtmp->randomitems, invtmp, 0, m->difficulty, 0);
+ invtmp->randomitems = NULL;
+ } else if (invtmp && invtmp->arch
+ && invtmp->type != TREASURE
+ && invtmp->type != SPELL
+ && invtmp->type != CLASS
+ && HAS_RANDOM_ITEMS(invtmp)) {
+ create_treasure(invtmp->randomitems, invtmp, 0, m->difficulty, 0);
+ /* Need to clear this so that we never try to
+* create treasure again for this object
+*/
+ invtmp->randomitems = NULL;
+ }
+ } FOR_INV_FINISH();
+ /* This is really temporary - the code at the
+* bottom will also set randomitems to null.
+* The problem is there are bunches of maps/players
+* already out there with items that have spells
+* which haven't had the randomitems set
+* to null yet.
+* MSW 2004-05-13
+*
+* And if it's a spellbook, it's better to set
+* randomitems to NULL too, else you get two spells
+* in the book ^_-
+* Ryo 2004-08-16
+*/
+ if (tmp->type == WAND
+ || tmp->type == ROD
+ || tmp->type == SCROLL
+ || tmp->type == FIREWALL
+ || tmp->type == POTION
+ || tmp->type == ALTAR
+ || tmp->type == SPELLBOOK)
+ tmp->randomitems = NULL;
+}
+
+/**
* Go through the entire map (only the first time
* when an original map is loaded) and performs special actions for
* certain objects (most initialization of chests and creation of
@@ -1470,48 +1528,8 @@
for (y = 0; y < MAP_HEIGHT(m); y++)
FOR_MAP_PREPARE(m, x, y, tmp) {
if (tmp->inv) {
-FOR_INV_PREPARE(tmp, invtmp) {
-if (QUERY_FLAG(invtmp, FLAG_AUTO_APPLY))
-apply_auto(invtmp);
-else if (invtmp->type == TREASURE && HAS_RANDOM_ITEMS(invtmp)) {
-while (invtmp->stats.hp-- > 0)
-create_treasure(invtmp->randomitems, invtmp, 0, m->difficulty, 0);
-invtmp->randomitems = NULL;
-} else if (invtmp && invtmp->arch
-&& invtmp->type != TREASURE
-&& invtmp->type != SPELL
-&& invtmp->type != CLASS
-&& HAS_RANDOM_ITEMS(invtmp)) {
-create_treasure(invtmp->randomitems, invtmp, 0, m->difficulty, 0);
-/* Need to clear this so that we never try to
- * create treasure again for this object
- */
-invtmp->randomitems = NULL;
-}
-} FOR_INV_FINISH();
-/* This is really temporary - the code at the
- * bottom will also set randomitems to null.
- * The problem is there are bunches of maps/players
- * already out there with items that have spells
- * which haven't had the randomitems set
- * to null yet.
- * MSW 2004-05-13
- *
- * And if it's a spellbook, it's better to set
- * randomitems to NULL too, else you get two spells
- *
[crossfire] Modifying Multi-Square Objects
I'm having trouble working with a multi-square arch. I'm trying to modify it so that one square that is normally blocked on the roof of a building is passable. In the arch, it's split up into four separate objects, for example: Object guild ... end More Object guild_2 ... move_block all x 1 end More ... It's this second square that I want to modify, and I can't find a good way of doing it in the map like I can with single-square arches. To just remove the move_block from the second square, I tried using a different building's arch and changing the face to the one I wanted, but the face substitution doesn't seem to work. Ideally I would like to be able to control other aspects like shifting the hp/sp fields by one to change where you enter (or even something really weird in some cases). If I could access the four parts of the image separately, then I could just use four one-square building arches with the face adjusted to look like one big building and get exactly what I want, but there doesn't seem to be a way to grab just one square of an image. Unless there's a trick I'm missing, the only thing I can think of is to create a custom arch just for this one building, and I would really prefer to keep these changes in one place if possible. Is there a trick here I'm missing? ___ crossfire mailing list crossfire@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
Re: [crossfire] Improving random maps
On 2022-01-15 03:46, Nicolas Weeger wrote: For those not checking the tracker: https://sourceforge.net/p/crossfire/feature-requests/282/ Comments, ideas, flames welcome :) That's an awesome idea. It might also be nice to have a new exit type of tile, so the maps tile instead of having traditional exits. Whether you track the history of the map generation to avoid circling back over the old maps is an open question. (There's nothing wrong with doing that, as it suggests that the floors are sloping up or down, but it's a little weird on the client.) Anything that adds new content is good for the game. ___ crossfire mailing list crossfire@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
Re: [crossfire] Custom items & monsters on maps
On 2021-08-01 05:15, Nicolas Weeger wrote: I wonder if instead of setting custom values for items & monsters on maps, it wouldn't be better to create artifacts (with a 0 chance of being generated) and use it in maps. The rationale I can see is that it makes it much easier to balance items/ monsters (since artifacts will give all available items/monsters, instead of needing to check all maps for custom items). It'll also allow changing items the players possess (which is not currently possible with custom items). What do you think? One limitation though is that artifacts can only have names in the form "item of artifact", whereas custom items/monsters can have any custom name. I think both the naming restriction and the added complexity of making custom items in maps makes this a bad idea. For major end-of-dungeon loot items, I can see it making sense, but not as a general requirement. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Account login limitation
On 2021-07-23 15:12, Nicolas Weeger wrote: The code currently forbids being connected more than one time per account. I don't remember what the rationale was for that restriction - game-play ones? technical ones? Any hint appreciated :) I was thinking of removing it, to allow players to exchange easily stuff between their characters... Ideally it would be a server config option. I'm a huge fan of letting the server administrators decide how they want their server to work. There are quests that are designed for multiple players, though only one that I've been unable to do solo, and I can understand trying to make them really encourage social play. Then again, in a pinch, players will just create multiple accounts, so there's not a lot of value in the restriction. On a related note, I could see an argument for a method of letting other characters from your own account into your private apartments. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Private apartments versus guilds
On 2021-05-30 14:51, Kevin Zheng wrote: On 5/30/21 12:44 AM, Nicolas Weeger wrote: From what I see, the 2 major points of guilds are: - having portals to many towns and places in the world - that is probably the most useful for me - sharing items between players (or even your own characters) I think the various crafting benches in guilds are underutilized. I would also be a fan of moving the entrance to "NetHack in Crossfire" to somewhere in the big world, so that you don't need to be a member of a guild to play. I think the guild museum is kind of interesting. In summary, the way I see it, guilds are for having fun playing with other players. I think the main problems with guilds now is that many seem inactive, and it's not easy to join an inactive guild. I think something worth considering is a mechanism to return inactive guilds to new(er) players, either by some script or by some server policy. What do folks think about this? I agree, but the solution that comes to mind is to make guilds into something where the maps are like apartment maps, only instead of being unique to a player, make them unique to a party. This would mean changing around the party system to something where you can be a member of multiple parties, and making unique maps able to be per-party. Or perhaps make all unique maps per-party, but create a default "just me" party for each character. This then raises new questions, such as if you're in two parties that both have a guild in a city, which one do you enter when entering? What can be done to encourage the use of guilds in different locations? Would this mean completely redesigning the guild system? As to portals, I've gotten rid of the apartment portals on my server (crowcastle) in favor of a travel map that is a miniature of the world map, so you at least still get some sense of geography. I haven't done anything about guild maps yet. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Finding maps and their location, moving around
On 2021-05-30 14:45, Kevin Zheng wrote: On 5/30/21 12:37 AM, Nicolas Weeger wrote: I think one issue in the game is that many maps aren't easy to find or even to know that they exist. I agree this is a problem, but don't have good ideas on this right now. I think the problem here is that the density of places worth exploring on the world map is too low. If we had more maps to find, exploring would result in stumbling on stuff all the time, which would result in lots more exploring. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Removing server-side help files for client-side commands
I think we need to be sure that the clients are offering help on the local commands before we remove that help from the server. I think what needs to happen is to have the client intercept the 'help' command, display the client-side commands, then send the command to the server for the server-side commands. If asking for help on a specific command, the client would only pass it on to the server if the command didn't match a local command. But we still have the problem of people using older clients with newer servers. On 2021-05-06 12:26, Nicolas Weeger wrote: Hello. I'd like to remove server-side help files that pertain to client-side commands. I think that includes: - bind - nextkey - prevkey _ sort_inventory - unbind The rationale is that different clients don't necessarily have the same commands. Opinions? Best regards Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Handling massive loot
On 2021-03-23 00:27, Mark Wedel wrote: On 3/22/21 11:58 AM, Nicolas Weeger wrote: Hello. One issue that happens is server delays when dealing with big loot. For instance a player selling some thousands rods can stuck the server for some seconds... Or even dropping many items on a big pile can be quite slow. So to handle that correctly, I was thinking of changing the server code like that: - split data/commands reception and processing - have one loop that reads from the socket, put commands in a waiting queue, then another function later processes those commands - for commands like pick/drop/examine, enable them to work on multiple processing loops instead of a single. So for instance the command would drop 100 items, then store its status, put itself back on top of the command waiting queue, and exit - this way the server can process something else. Being multi threaded would help some things out. It has been a while, by my recollection is the drop (and pickup) problem is that these are in fact handled by the server, eg, 'drop all' is done on the server, dropping everything of matching criteria. And likewise, pickup all is done on the server, so slowing down the command processing from the client doesn't help out. It is also my recollection in that the reason this is slow that each time an object is moved (ground to player or vice versa), it has to check the destination for duplicates to merge them (otherwise, you could have 20 different entries for silver coins). This becomes an O(n^2) operation, so when dropping a few items, it is pretty fast, but when dropping a stack of 100 different items, that takes a lot of time. There are a couple ways to deal with this: - A thought I had a while back is once a space gets too many items on it, items fall over to neighboring spaces - this would reduce the upper threshhold over that operation (never too many items to examine on a space), but this could basically result in an entire shop being filled to a level of 25 items deep. - For items going to the floor, marking the space as needing 'merging' later on could be done (one could even imagine something like a shop keeper standing on the space as this merging is done, preventing players from interacting with it) - For items going into the players inventory (they step onto a pile of junk), deferred merging could be done, but would result in new items getting send to the client, and then and update down the road that the new item does not exist and in fact item X has a different quantity. I'm not sure how visually that works out. - Maybe limit the number of items picked up at once, even with pickup all, to something like 25 or other number where performance is still reasonable. This makes it harder to clean up everything in the dungeon, but is somewhat more realistic (you can only pick up stuff so quickly). - I can't remember if the gold insertion when selling a bunch of items is intelligent. That is to say, if you sell 100 items, does is calculate the net proceeds and inserts it once (intelligent) or inserts the coinage 100 items (1/each item, keeping in mind that there could actually be several different coins being inserted for each item). So changing that (deferred gold updating) could also have some benefit. Well, first look over the drop code to be sure there aren't any optimizations that have been missed, but then I would suggest looking for the simplest solution. For example, only merge-match on the top 50 items, but then flag the square as needing merging. Move the map save code to a separate thread, and have that thread do the merging. Pickup is more complicated, as that can't be deferred. And did the issue with loading an apartment map with too many items get fixed? I really liked the general solution idea that someone mentioned years ago where when something is too slow, the server drops ticks on that map until it's caught up, but other maps continue to get processed. The easiest way of doing something like that would be to have one thread per map, but that's probably excessive, and having tiled maps makes per-map processing more complicated. A more general system would be to have multiple threads that pick up processing for maps, and maps would be put on a queue, so anything that makes things slow would only impact that map. It gets a little complicated when things move from one map to another (especially with tiled maps), so perhaps active tiled maps would be put on the queue as a unit. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 1.75.0 release engineering
It's much simpler to have a number that can be used as an array index. Splitting the harvesting skills simply means there is a case statement for each one instead of a single case statement. That's the only change required. On 2021-01-04 13:23, Nicolas Weeger wrote: Hello. Couldn't you track skills by name instead of subtype? I'm definitely against splitting harvesting skills... Best regards Nicolas Le dimanche 3 janvier 2021, 15:36:14 CET Preston Crow a écrit : Here's the patch. It should be compatible with existing servers, creating a new hiscores directory and storing the information there, initializing the overall scores from the old table. The hiscore command is updated to add a '-s' option to show the scores for individual skills. I had to tweak the mining arch to have a different subtype as that's what the new scores key off of. I don't think there are any mining pickaxes in the game yet, so this shouldn't impact anyone. On 2021-01-02 12:53, Kevin Zheng wrote: On 1/2/21 11:40 AM, Preston Crow wrote: I have a change to track per-skill high scores that I was meaning to put in. Should I do it now, or wait until after the release? (I've been running it on my server for a while.) Would you mind attaching the patch here? If it's not so big, it would be a fun addition to 1.75.0. Thanks, Kevin ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 1.75.0 release engineering
Here's the patch.
It should be compatible with existing servers, creating a new hiscores
directory and storing the information there, initializing the overall
scores from the old table. The hiscore command is updated to add a '-s'
option to show the scores for individual skills.
I had to tweak the mining arch to have a different subtype as that's
what the new scores key off of. I don't think there are any mining
pickaxes in the game yet, so this shouldn't impact anyone.
On 2021-01-02 12:53, Kevin Zheng wrote:
On 1/2/21 11:40 AM, Preston Crow wrote:
I have a change to track per-skill high scores that I was meaning to
put in. Should I do it now, or wait until after the release? (I've
been running it on my server for a while.)
Would you mind attaching the patch here? If it's not so big, it would
be a fun addition to 1.75.0.
Thanks,
Kevin
Index: arch/trunk/skills/mining.arc
===
--- arch/trunk/skills/mining.arc (revision 21712)
+++ arch/trunk/skills/mining.arc (working copy)
@@ -5,7 +5,7 @@
type 43
invisible 1
no_drop 1
-subtype 39
+subtype 44
body_skill -1
exp 100
level 100
Index: server/trunk/include/config.h
===
--- server/trunk/include/config.h (revision 21712)
+++ server/trunk/include/config.h (working copy)
@@ -515,7 +515,8 @@
#define TEMPLATE_DIR"template-maps"
#define ARCHETYPES "archetypes"
#define REGIONS "regions.reg"
-#define HIGHSCORE "highscore"
+#define OLD_HIGHSCORE "highscore"
+#define HIGHSCORE_DIR "highscores"
#define TREASURES "treasures"
#define BANISHFILE "banish_file"
Index: server/trunk/include/skills.h
===
--- server/trunk/include/skills.h (revision 21712)
+++ server/trunk/include/skills.h (working copy)
@@ -55,11 +55,12 @@
SK_SORCERY = 36, /**< Sorcery. */
SK_TWO_HANDED_WEAPON = 37, /**< Two handed weapons. */
SK_WRAITH_FEED = 38, /**< Wraith feed. */
-SK_HARVESTING= 39, /**< Harvesting. */
+SK_FISHING = 39, /**< Harvesting. */
SK_AIR_MAGIC = 40, /**< Air magic, unused. */
SK_EARTH_MAGIC = 41, /**< Earth magic, unused. */
SK_WATER_MAGIC = 42, /**< Water magic, unused. */
SK_FIRE_MAGIC= 43, /**< Fire magic, unused. */
+SK_MINING= 44, /**< Mining. */
};
/**
@@ -122,6 +123,7 @@
extern const char *skill_names[MAX_SKILLS];
extern const Face *skill_faces[MAX_SKILLS];
+extern int skill_subtypes[MAX_SKILLS];
extern int get_skill_client_code(const char *skill_name);
Index: server/trunk/server/c_misc.c
===
--- server/trunk/server/c_misc.c (revision 21712)
+++ server/trunk/server/c_misc.c (working copy)
@@ -874,7 +874,7 @@
* @param op
* player asking for information.
* @param params
- * unused.
+ * options for the hiscore command (typically a match for the names)
*/
void command_hiscore(object *op, const char *params) {
hiscore_display(op, op == NULL ? : 50, params);
Index: server/trunk/server/hiscore.c
===
--- server/trunk/server/hiscore.c (revision 21712)
+++ server/trunk/server/hiscore.c (working copy)
@@ -21,6 +21,8 @@
#include
#include
+#include
+#include
#include "sproto.h"
#include "output_file.h"
@@ -45,6 +47,7 @@
*/
typedef struct {
char fname[MAX_BUF]; /**< Filename of the backing file. */
+char skill_name[MAX_BUF]; /**< The name of the skill or "Overall". */
score entry[HIGHSCORE_LENGTH]; /**< The entries in decreasing exp order. */
} score_table;
@@ -51,7 +54,8 @@
/**
* The highscore table. Unused entries are set to zero (except for position).
*/
-static score_table hiscore_table;
+static score_table hiscore_tables[MAX_SKILLS+1]; // One for each skill, plus one for overall
+//#define hiscore_table hiscore_tables[0] // Overall score
/**
* Writes the given score structure to specified buffer.
@@ -159,7 +163,11 @@
if (strcmp(sc->killer, "quit") == 0 || strcmp(sc->killer, "left") == 0) {
s1 = sc->killer;
s2 = "the game";
-} else {
+} else if ( strcmp(sc->killer,"a dungeon collapse") == 0 ) {
+s1 = "was last";
+s2 = "seen";
+}
+else {
s1 = "was killed by";
s2 = sc->killer;
}
@@ -282,10 +290,46 @@
/**
* Initializes the module.
+ *
+ * @note
+ * There is one table per skill, as well as the "Overall" table, each saved in a file
+ * i
Re: [crossfire] Crossfire 1.75.0 release engineering
I have a change to track per-skill high scores that I was meaning to put in. Should I do it now, or wait until after the release? (I've been running it on my server for a while.) On 2021-01-02 12:05, Kevin Zheng wrote: Hi folks, I am thinking about cutting a 1.75.0 release in the next couple of days. I would like to coordinate a full server/maps/arch release as well as releases for both the GTKv2 and JXClient. This release is a good time for those running servers to switch to Python 3, before some major code rework in the server. This will also be the last GTKv2 client using Gtk+2, since Gtk+2 is now officially EoL'ed (future GTK client releases will use Gtk3). I would certainly appreciate an extra set of eyes testing the server Python (after the Python 2 migration) and checking the GTK client builds. Thanks in advance, and happy 2021. Regards, Kevin ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Chaos attack type (v1.12 17760rc): good or bad?
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@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Advice for late-game gear: getting constantly one-shotted
On 2020-09-29 13:05, Siegfried Eureca wrote: I've been gradually getting back into Crossfire, having played it on-and-off over the years. One thing that has always frustrated me, is seeing the Scorn Sale Shop littered with gear from Zorn's castle, and I can't even beat Zacharus Zorn at the entrance to the Zorn quests. I have decent gear, IMHO, but he just rams into me and kills me in half a second, leaving me no time to react or heal (i.e. "I hope this guy isn't another instant-kill enemy; time to flip a coin and charge him"). Well, you don't need to kill or even confront him to get into the castle. There is another way. But if you really want his key, another approach is to get good enough with the stealing skill to just take it. Of course, if you aren't good enough, you'll anger him, and he'll kill you. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Archetypes collection changes proposal
So the simple version of the proposed change is to have the arch directory work like the maps do now instead of like source code that is complied in. (And other details like allowing overrides.) I like the idea. The current system is broken in that I can make arch changes and the Makefiles don't detect any changes, so I have to manually do the collect to pull in the changes. Fixing that would be a pain. As to the start-up time, how much longer will it really take? Running 'make do-collect' just took 1.166s on my laptop. Even 5s wouldn't be a big problem for recovering from a server crash. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] seg. fault with latest commit
There's a reproducible seg fault in is_identifiable_type() in item.c in
cases where get_typedata(op->type) return NULL.
I hit this consistently when trying to board a sailing ship.
I'm not totally clear on what is going on, so I won't commit my change,
but this is what I've found works for me. Someone who knows the code
better should commit a fix:
int is_identifiable_type(const object *op) {
/* Special case -- skill tools don't have an associated identification
* skill but still need IDing. TODO: we should probably have
per-tool ID
* skills, e.g. thievery for lockpicks and thaumaturgy for
talismans, but
* currently there's no good way to do this because the
identifyskill is
* tied to the itemtype rather than to the arch. */
if ( op->type == SKILL_TOOL ) return TRUE;
if ( !get_typedata(op->type) ) return FALSE;
return get_typedata(op->type)->identifyskill;
}
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] unaggressive monsters
That's helpful. I got it working. I think my problem was that I was editing the map on one system and then copying it over to my server, but somehow I missed the update so the server had an old copy. But knowing how it works is great. In this case, the value of 3 is alright, but I might want to tweak it, so I'll probably change the code to let it be dynamic: help_radius = object_get_value(op,"help_radius"); if ( !help_radius ) help_radius = 3; I think with that, I can set 'help_radius 5' or whatever to a particular creature to make it yell louder when attacked. That's not quite as good as having a monster get angry from seeing combat near it, even if it didn't start near it, but it will do. On 2020-09-06 17:13, Kevin Zheng wrote: On 9/6/20 7:53 AM, Preston Crow wrote: I'm trying to create some monsters that aren't aggressive until they see combat near them. I've taken a regular monster and added 'unaggressive 1' which makes them stand there as expected, but they don't notice fights around them, only when they are attacked. What do I do to make them more trigger happy, but content to stand still and chat most of the time? How close are these unaggressive monsters to the monster you attack? When an unaggressive monster is attacked, it calls monster_npc_call_help() in server/monster.c. It currently has help_radius set to 3, so monsters too far away will not notice. Is this consistent with what you observe? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Permanent Experience
On 2020-08-18 03:18, Robert Brockway wrote: On Mon, 17 Aug 2020, Preston Crow wrote: When you earn experience, it gets added to your regular experience (up to the maximum), and some percentage (default 50%) added to your permanent experience. When you die or are drained, your current experience never drops below the permanent experience. My proposal is to instead of tracking permanent experience, track total experience. This means applying the permanent ratio (50%) to the total when using it instead of when adding to it. Mathematically it's all the same, but the change eliminates rounding errors. It also would in theory let you change the permanent experience ratio on a server, though I see no value in that. My biggest concern is that there are ongoing changes for a Soul Blade artifact where the object gains experience, and I wouldn't want to mess that up without some degree of coordination. Thanks for explaining that Preston. My only suggestion would be to be mindful that some people (like me!) modify the default settings. I can't see how this would be an issue but I'll paste the relevant settings I use: stat_loss_on_death false balanced_stat_loss false permanent_experience_percentage 100 death_penalty_percentage 0 death_penalty_levels 0 As you can see I've eliminated most of the penalties for death. I run a child friendly server which is very forgiving of mistakes. I've turned down 'death penalties' for both Crossfire and Minecraft and we've found that players (adults and children alike) still take character death seriously and try to avoid it. IE removing the penalties did not appreciably modify player behaviour. I suspect most people seem to view character death as a personal failure regardless of whether the game imposes a penalty or not. Thus character death on my server involves depleted stats only. For most cults some in the temple will sort that out. That's fascinating. And no, my changes wouldn't impact that at all. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Compiler warnings
I've just committed a bunch of minor changes that eliminate all the compiler warnings I'm seeing with gcc 9.3 and 10.2 There is one linker warning: common/map.c:1485: warning: the use of `tempnam' is dangerous, better use `mkstemp' The way this is used, fixing it will be a pain, so I'm not going to do it right now. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Permanent Experience
On 2020-08-17 12:44, Kevin Zheng wrote: On 8/14/20 12:32 PM, Preston Crow wrote: I'm interested in changing the server to replace tracking of permanent experience with tracking of total experience. This would work out to be almost exactly the same, except it eliminates any rounding. For example, if you had some skill (say hiding) that always gave out 1xp at a time, you would never be able to have permanent experience exceed 50% of the high-water mark on current experience (or whatever percentage threshold you're using). I have this working on my Crowcastle server, but I want to clean up the patch a bit before pushing it, and I want to check if anyone has any objections to this design change. I'll have it so that if it loads a character with perm_exp, it will adjust it up to the total_exp value that gives the same effective perm_exp, so it should be a transparent upgrade. I'm not very familiar with how permanent experience is currently tracked, but it sounds like you're familiar or have worked it out. Would you mind briefly explaining how the current system works? When you earn experience, it gets added to your regular experience (up to the maximum), and some percentage (default 50%) added to your permanent experience. When you die or are drained, your current experience never drops below the permanent experience. My proposal is to instead of tracking permanent experience, track total experience. This means applying the permanent ratio (50%) to the total when using it instead of when adding to it. Mathematically it's all the same, but the change eliminates rounding errors. It also would in theory let you change the permanent experience ratio on a server, though I see no value in that. My biggest concern is that there are ongoing changes for a Soul Blade artifact where the object gains experience, and I wouldn't want to mess that up without some degree of coordination. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] r21264 broke the server build
Oops. Stupid partial commit. I'll revert that. Sorry!
On 2020-08-13 16:51, Kevin Zheng wrote:
Hi there,
It looks like r21264 broke the server build for several of us. The
offending part of the diff is:
diff --git a/common/map.c b/common/map.c
index 724cbccc..7175f3d0 100644
--- a/common/map.c
+++ b/common/map.c
@@ -652,6 +652,21 @@ static void load_objects(mapstruct *m, FILE *fp,
int mapflags) {
continue;
}
+/*
+ * Generators normally start with a speed_left of -0.1. They
+ * trigger as soon as they go positive, then get 1 subtracted from
+ * their speed_left. If asked to randomize the times to avoid
+ * waves of monsters from identical generators, we set the
+ * speed_left to a random value between -0.6 and +0.4, so the
+ * average is still the same.
+ *
+ * Note the comparison is tricky, as it has to be cast exactly the
+ * same way it's set in arch.c:first_arch_pass()
+ */
+if ( settings.generator_init_time_random && QUERY_FLAG(op,
FLAG_GENERATOR) && op->speed_left == (float)-0.1 ) {
+op->speed_left = (cf_random() % 10) / 10. - 0.6;
+}
+
Specifically, there's no settings.generator_init_time_random.
Did you mean to have this change in a separate commit?
Thanks,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Minor issues
I committed the second two, but the change to configure.ac didn't work for me. I found an example online of using a fallback with nested PKG_CHECK_MODULES calls, so I did that, and it works, so I committed that, too. On 2020-08-09 17:40, Kevin Zheng wrote: On 8/9/20 1:08 PM, Preston Crow wrote: In configure.ac, it is looking python2 instead of python-2.7. On my system it fails to detect with python2, but with a check for python-2.7, it works. I'm not an expert on autoconf, so I don't know if there's an easy way to check for either. (Of course, moving to python 3 would make all kinds of sense, but that's another topic.) This seems to have something to do with the pkg-config name for your Python 2 installation. pkg-config can be instructed to check both by changing [python2] to [python2 python-2.7]. Enough things have changed that replacing python2 with python3 will get you a working build with Python 3. It's the scripts that still need to be converted to Python 3. In common/init.c, things break badly if someone adds a field in the middle of include/global.h. This can easily be fixed by assigning specific field names, though that would move us up to a minimum of C99. The code is already C99; that's fine. Patch welcome. With gcc 10, you get multiple definition errors on shutdown_flag. This should be declared extern in the .h and also declared in one C file. Patch welcome here; it's only not already there because I don't think my Clang warns about the same issue? I'm happy to push commits for the second two issues, but I don't trust that my fix for the first one wouldn't break things for other people. (I'm not sure if I have permission to push, though.) If not, a patch to the mailing list (here) is welcome. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Minor issues
I've noticed a few minor issues with building the server: In configure.ac, it is looking python2 instead of python-2.7. On my system it fails to detect with python2, but with a check for python-2.7, it works. I'm not an expert on autoconf, so I don't know if there's an easy way to check for either. (Of course, moving to python 3 would make all kinds of sense, but that's another topic.) In common/init.c, things break badly if someone adds a field in the middle of include/global.h. This can easily be fixed by assigning specific field names, though that would move us up to a minimum of C99. With gcc 10, you get multiple definition errors on shutdown_flag. This should be declared extern in the .h and also declared in one C file. I'm happy to push commits for the second two issues, but I don't trust that my fix for the first one wouldn't break things for other people. (I'm not sure if I have permission to push, though.) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Useless rods
I've noticed that some rods can never be used. I'm under the impression that rods are implemented with a given number of spell points that regenerate quickly for casting the specified spell. Some spells require more points at higher levels. In some cases, this results in a rod where the spell at that level requires more points than the rod has at full charge. I'm playing on Metalforge, so it's possible that this has been addressed in newer code, but I would think there should be a check somewhere to either not generate these rods or to increase the maximum sp for a rod to match the sp required to cast if that is higher. A good example is that a 'rod of turn undead' above level 53 will never work. Likewise a 'rod of word of recall' above level 90 is useless. I haven't checked heavy rods; I'm under the impression that they have a lot more sp, so it's unlikely to be a problem there. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map changes?
Metalforge is running a very old server and map set. It would be great if it could be updated. I'm not aware of anything that would break; perhaps making a copy and testing it with updated maps and server would be a good approach. I think they want to avoid a reset of characters that have been playing for years. On 4/9/19 5:47 AM, Otto J. Makela wrote: Several years ago (details escape me, it was so long ago) I submitted a change to the map to prevent players getting stuck in the temple of Devourers cellar because nosy vampires always pull all the levers they can. Checking just today on Metalforge, it seems my change did not end up in the current release? Could someone give me a pointer on how and where I should resubmit? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Simple ideas
No, I'm thinking that the max level for skills would be lower than the overall max level, so the ratio would stay 1:1. On 2/7/19 3:32 PM, bill billy wrote: So instead of skill and general exp being gained at a rate of 1 : 1 you're thinking more like 1 : 0.08? that would cause a player to see max level after about a dozen levels I think. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Simple ideas
Maybe all of them? I have a character with 13 skills at or above level 110 on Metalforge. I get the feeling that I'm never going to get there in lockpicking or sense curse, but I could conceive of getting several more up there. Of course, "all of them" depends on the character, as I don't have meditation, flametouch, clawing, etc., but I am allowed weapons. So if we want people to reach a cap, then either 8 or 16 would seem reasonable to me. On 2/7/19 2:35 PM, bill billy wrote: I agree to your second point. How many skills should a player have to max before it equals max level in your opinion? On Thursday, February 7, 2019, 2:30:41 PM EST, Preston Crow wrote: What about setting a higher maximum overall level than the per-skill maximum level? Then to max out your character, you would have to master many different skills. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Simple ideas
A pair of simple ideas: How about a per-skill high score list? What about setting a higher maximum overall level than the per-skill maximum level? Then to max out your character, you would have to master many different skills. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Spellcasting skills definition
I like those definitions a lot. However, we might want to keep the exceptions or at least give some good thought to how moving them would impact the balance of the skills. On 08/20/17 02:53, David Hurst wrote: Hi all, I'm working on improving the messages that players get in general. Today I was working on spell messages which are provided when learning spells (new) and viewing learnt spells via the spell menu (commit #20501). While working on this I noticed some odd places for spells such as ball lightning in evocation (all other lightning is in pyromancy) and large bullet in evocation while bullet is in sorcery. These may simply be typos but I noticed that we don't appear to have defined what these skills actually represent anywhere server side (there might be some definitions client side I haven't noticed?). I also notice that the current information on our website is very out of date and doesn't include skills like pyromancy. I am thinking about adding these definitions to the skills and presenting them to players when they learn the skills and updating all relevant documentation (in game, wiki, website). Based on the way spells are currently classified, and without getting too academic, I thought the following broad definitions might work: Evocation - Spells that remove energy (cold spells, poison, draining?, depletion?) Sorcery - Spells that create things (physical damage, food, strengthening) Pyromancy - Spells that add energy (fire, lightning, light) Summoning - Spells that call and control monsters (golems, pets, etc) Praying - Spells gifted by channeling your gods wishes through prayer Thoughts? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Client 1.72.0 is available
That would be a great solution. On 08/19/17 12:10, Kevin Zheng wrote: On 08/19/2017 04:59, Preston Crow wrote: What would be really cool is a command-line option to start a client script, especially if it could be used multiple times for multiple scripts. (I normally launch two.) Maybe like a login.rc file that gets read as soon as the character enters the game? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Client 1.72.0 is available
What would be really cool is a command-line option to start a client script, especially if it could be used multiple times for multiple scripts. (I normally launch two.) On 08/19/17 01:26, Kevin Zheng wrote: On 08/18/2017 20:28, Preston Crow wrote: The "cleanup" of command line options seems to have removed almost all of them, including many useful ones. There isn't even an option for selecting the server anymore! I really need the mapscale and iconscale options for high DPI displays--those have also been removed from the UI settings. Sorry about that; I'll work on adding them back. In the meantime, edit ~/.config/crossfire/client.ini ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Client scaling for High DPI
When playing on my laptop with a 283-dpi 4K display, I have to use the client options to scale the map and icons. Would it make sense to check the DPI of the display and scale them automatically unless a manual scaling is specified on the command line? The rest of the display seems to scale based on the Xft.dpi resource (probably something we get for free from GTK). It does seem to push the decimal place on item weights out of the window, but besides that it's perfect. If we could read that same resource and generate a default scaling, the client would adjust seamlessly. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Client 1.72.0 is available
If it also checks in ~/.crossfire/ so that old configs are picked up, it shouldn't be a problem. If it finds something in the old location, it should use that, but if it has to create a directory, I don't mind if it puts it under ~/.config/crossfire/. On 08/14/17 11:03, Ruben Safir wrote: the new location. For Unix-like systems, the new location is *~/.config/crossfire*. This is a drag and moving my keys around is why I stopped playing the last time. Things should have remained under ./.crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Best map editor?
If I want to play around with creating maps, what is the best program to use? (In my case, I prefer running Linux.) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Ideas for balancing tweaks for next release
I like your thinking on this. You have a place for monsters, but didn't put any on the list. I've been playing on Metalforge recently, and I've found pixies to be worthless monsters. They seem to usually have wands but never use them. I seem to recall they used their wands at one point in the past, making them randomly dangerous. On 07/30/17 00:05, David Hurst wrote: Hi guys and gals, I've been spending a lot of time playing crossfire lately and the discussion around a new release prompted me to think about some potential balance improvements that could be made. I am thinking about some of the more fundamental aspects of the game such as player race attributes which do have wider ramifications that adjusting maps, therefore, I have created a table on the wiki to document these potential changes and provided a little description around the rationale. http://wiki.cross-fire.org/dokuwiki/doku.php/user:saru:new_release_balance I'm not suggesting they are perfect or that there isn't better ways to address some of these issues, but i'm really focusing on the low hanging fruit that I can actually assist with. I welcome any additions to these balance changes and I might suggest a poll of some description as we approach release to confirm any specific changes. Thoughts? Regards, Saru ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Minor bugs
I'm running 1.71.0 on Linux (Gentoo). On 07/11/17 00:37, Kevin Zheng wrote: On 07/10/2017 07:03, Preston Crow wrote: Resizing the map in the client will occasionally cause things on the other side of walls to show up. The "unidentified" tab in the client doesn't seem to work. It's always blank, even when I have unidentified items. Sometimes I have to shift-click twice to lock or unlock an item. (I'm using pointer focus, so I shouldn't lose the first click to get focus.) What version of the client are you using? On what OS? When I walk away from an open container on the floor, occasionally the code still behaves as if I'm on top of the open container, even if I move to another map. I've been able to drink a potion from a container in my apartment when in another map. I think this has something to do with opening and closing containers in my inventory and in the square, but I'm not sure how I've triggered this glitch. I believe this is fixed on recent servers. I don't remember if this is fixed on Metalforge or not. The -split option on the client doesn't seem to work anymore. No separate windows for me. (I'm not sure it's really useful, though.) I also note that the subwindows don't start up in the same place each time, which would be convenient. I keep having to resize things or the experience window is squished to nothing. This must be an old client. I haven't encountered a scroll of sense curse yet--probably just my luck. It's also the only skill scroll not in the permanent store in Scorn on Metalforge, which makes me suspicious that something's up. Grepping in the source indicates that it is referenced in various places, so it's probably just bad luck. Those are definitely available in newer servers; Metalforge I'm not sure but I don't imagine why not. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Minor bugs
I've started playing again on Metalforge after a break of a dozen years or so. I've noticed a few minor bugs. Some of them might just be me, but I'll toss them out here in case someone wants to fix them: It appears that the spell "magehound" is not possible to obtain. It is not in any of the treasure lists, so it doesn't ever appear in stores. Resizing the map in the client will occasionally cause things on the other side of walls to show up. The "unidentified" tab in the client doesn't seem to work. It's always blank, even when I have unidentified items. Sometimes I have to shift-click twice to lock or unlock an item. (I'm using pointer focus, so I shouldn't lose the first click to get focus.) When I walk away from an open container on the floor, occasionally the code still behaves as if I'm on top of the open container, even if I move to another map. I've been able to drink a potion from a container in my apartment when in another map. I think this has something to do with opening and closing containers in my inventory and in the square, but I'm not sure how I've triggered this glitch. I've never seen a quiver of bolts, only a quiver of holding bolts. I think this is an oversight. The -split option on the client doesn't seem to work anymore. No separate windows for me. (I'm not sure it's really useful, though.) I also note that the subwindows don't start up in the same place each time, which would be convenient. I keep having to resize things or the experience window is squished to nothing. I haven't encountered a scroll of sense curse yet--probably just my luck. It's also the only skill scroll not in the permanent store in Scorn on Metalforge, which makes me suspicious that something's up. Grepping in the source indicates that it is referenced in various places, so it's probably just bad luck. The web documentation indicates that I can get jumping experience by jumping into monsters, but I can't seem to even kill a kobold, so I'm not sure that's correct. Not like I'm going to spend my life jumping at monsters, though. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire maps idea
Seeing the discussion on this list, I thought I should toss out an idea I had. Some time ago, I was thinking about creating a set of underworld maps, tiled together much like the surface world maps. The difference is that they wouldn't necessarily be completely two-dimensional. You might have a set of maps tiled such that you could move in a spiral, entering maps that go underneath the map you were on four maps ago. I would want the main entrance to be a tile on the main world map where high mountains prevent access except through a canyon. The same idea could be used for a tower going up. I wanted to play with the idea and see how the client would react with the fog of war memory when you enter a map beneath the one you were recently on. Anyway, I never got around to implementing it, but I thought I would toss out the idea in case someone is inspired. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Quest/Maps idea
I was just thinking that it might be cool to be able to set an entrance to point to a different map if you've completed a quest. For example, once you've completed the old Scorn undercity quest, the next time you enter those maps, it could be a happy under construction place. (Or perhaps, the hole was re-opened, and there is a fresh horde of much nastier monsters this time...) Not that I have time to make such maps. --PC ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
On Thu, 2005-08-25 at 18:57, Anton Oussik wrote: When the server comes across maps containing large amounts of items it takes a long time to load. While it is loading the whole server freezes for other players, and on very large maps (like the scorn sale shop or some apartments) this can take in excess of 10 seconds on metalforge. The way I would solve this is to have the map loader count how many objects it has loaded. After some fixed number, it would stop until the next time tick. There would be no processing of objects, including players, on a partially-loaded map. This would eliminate the lag for everyone except the player entering the cluttered map. I'm just not sure if this is less work than the other approaches to solving the problem that have been suggested. --PC ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
