From pc-crossfire06 at crowcastle.net Sun Aug 9 15:08:07 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Sun, 9 Aug 2020 16:08:07 -0400 Subject: [crossfire] Minor issues Message-ID: 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.) From kevinz5000 at gmail.com Sun Aug 9 16:40:49 2020 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 9 Aug 2020 14:40:49 -0700 Subject: [crossfire] Minor issues In-Reply-To: References: Message-ID: <55687a09-072c-a386-8f27-fc44fb478c1d@gmail.com> 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. From pc-crossfire06 at crowcastle.net Sun Aug 9 17:51:43 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Sun, 9 Aug 2020 18:51:43 -0400 Subject: [crossfire] Minor issues In-Reply-To: <55687a09-072c-a386-8f27-fc44fb478c1d@gmail.com> References: <55687a09-072c-a386-8f27-fc44fb478c1d@gmail.com> Message-ID: <21c13274-0395-9329-0b39-88f4ca2c60aa@crowcastle.net> 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. From pc-crossfire06 at crowcastle.net Thu Aug 13 15:55:35 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Thu, 13 Aug 2020 16:55:35 -0400 Subject: [crossfire] r21264 broke the server build In-Reply-To: <8ba91d6f-ae46-9abe-b34f-bdc9eb6f94c7@gmail.com> References: <8ba91d6f-ae46-9abe-b34f-bdc9eb6f94c7@gmail.com> Message-ID: 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() % 100000) / 100000. - 0.6; > + } > + > > Specifically, there's no settings.generator_init_time_random. > > Did you mean to have this change in a separate commit? > > Thanks, > Kevin From kevinz5000 at gmail.com Thu Aug 13 15:51:21 2020 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Thu, 13 Aug 2020 13:51:21 -0700 Subject: [crossfire] r21264 broke the server build Message-ID: <8ba91d6f-ae46-9abe-b34f-bdc9eb6f94c7@gmail.com> 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() % 100000) / 100000. - 0.6; + } + Specifically, there's no settings.generator_init_time_random. Did you mean to have this change in a separate commit? Thanks, Kevin From pc-crossfire06 at crowcastle.net Fri Aug 14 14:32:31 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Fri, 14 Aug 2020 15:32:31 -0400 Subject: [crossfire] Permanent Experience Message-ID: <2f7efc81-d750-816c-3f47-e721187a55cc@crowcastle.net> 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. Any thoughts? From kevinz5000 at gmail.com Mon Aug 17 11:44:19 2020 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 17 Aug 2020 09:44:19 -0700 Subject: [crossfire] Permanent Experience In-Reply-To: <2f7efc81-d750-816c-3f47-e721187a55cc@crowcastle.net> References: <2f7efc81-d750-816c-3f47-e721187a55cc@crowcastle.net> Message-ID: <2908dabe-4dbe-c10e-c9f3-d5cc189e9810@gmail.com> 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? Thanks, Kevin From pc-crossfire06 at crowcastle.net Mon Aug 17 12:08:46 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Mon, 17 Aug 2020 13:08:46 -0400 Subject: [crossfire] Permanent Experience In-Reply-To: <2908dabe-4dbe-c10e-c9f3-d5cc189e9810@gmail.com> References: <2f7efc81-d750-816c-3f47-e721187a55cc@crowcastle.net> <2908dabe-4dbe-c10e-c9f3-d5cc189e9810@gmail.com> Message-ID: <5c449258-6d86-65a5-dda9-c5a469f3680c@crowcastle.net> 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. From pc-crossfire06 at crowcastle.net Mon Aug 17 17:43:16 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Mon, 17 Aug 2020 18:43:16 -0400 Subject: [crossfire] Compiler warnings Message-ID: <0e71c72d-4604-1da9-a656-6054d2dc5870@crowcastle.net> 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. From aeonoris at gmail.com Mon Aug 17 22:11:32 2020 From: aeonoris at gmail.com (Aeon) Date: Mon, 17 Aug 2020 21:11:32 -0600 Subject: [crossfire] Python 2 to 3 database conversion Message-ID: This is for helping to get CF on Python 3. There is an incompatibility between the ways that Python 2 and 3 handle database files. Because of this, an existing server that updates to Python 3 will need to convert those database files as part of the update. I assembled a list of database files that might be created by CF's Python scripts. This script (attached) should convert each database on that list, and skip anything that either doesn't exist or already has a converted database. The new database files have ".db" appended to the end of them, which Python3 should automatically give priority over the old database files. The old database files are untouched. To use, you just put the file in the same directory as the databases (default is the CF server's var/crossfire directory), and run it with Python 2.7. As a cautious person, I always recommend backups directly before conversions like this, even though the old files are intended to remain intact. Let me know if it needs anything! -------------- next part -------------- A non-text attachment was scrubbed... Name: py2-to-3_db-conversion_cf-rpg.py Type: text/x-python Size: 1862 bytes Desc: not available URL: From robert at timetraveller.org Tue Aug 18 02:18:03 2020 From: robert at timetraveller.org (Robert Brockway) Date: Tue, 18 Aug 2020 17:18:03 +1000 (AEST) Subject: [crossfire] Permanent Experience In-Reply-To: <5c449258-6d86-65a5-dda9-c5a469f3680c@crowcastle.net> References: <2f7efc81-d750-816c-3f47-e721187a55cc@crowcastle.net> <2908dabe-4dbe-c10e-c9f3-d5cc189e9810@gmail.com> <5c449258-6d86-65a5-dda9-c5a469f3680c@crowcastle.net> Message-ID: 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. Rob From pc-crossfire06 at crowcastle.net Tue Aug 18 08:22:59 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Tue, 18 Aug 2020 09:22:59 -0400 Subject: [crossfire] Permanent Experience In-Reply-To: References: <2f7efc81-d750-816c-3f47-e721187a55cc@crowcastle.net> <2908dabe-4dbe-c10e-c9f3-d5cc189e9810@gmail.com> <5c449258-6d86-65a5-dda9-c5a469f3680c@crowcastle.net> Message-ID: <955052a6-c1fe-2d9e-66e5-f0cbcd65e0e6@crowcastle.net> 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. From pc-crossfire06 at crowcastle.net Thu Aug 27 15:20:50 2020 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Thu, 27 Aug 2020 16:20:50 -0400 Subject: [crossfire] Mapbuilding issues Message-ID: I'm trying to build a map, and I have a button that triggers when a player moves onto it as expected, but it doesn't trigger if the player appears on top of it because it's the starting square on the map.  I also can't get a button to trigger on a bed to reality when a player returns to the map, which I assume is the same thing. In some case I can do a workaround by having the player appear on square off in the map with a player mover to push them onto the button, but in another case this won't work. Is there a solution? From kevinz5000 at gmail.com Thu Aug 27 16:07:31 2020 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Thu, 27 Aug 2020 14:07:31 -0700 Subject: [crossfire] Mapbuilding issues In-Reply-To: References: Message-ID: <6387db67-f2fc-d477-1bbb-42ed4738bac0@gmail.com> On 8/27/20 1:20 PM, Preston Crow wrote: > I'm trying to build a map, and I have a button that triggers when a > player moves onto it as expected, but it doesn't trigger if the player > appears on top of it because it's the starting square on the map.  I > also can't get a button to trigger on a bed to reality when a player > returns to the map, which I assume is the same thing. Thanks for the observation. I think this is a server bug. I can probably take a look next week. Cheers, Kevin