From nicolas.weeger at laposte.net Fri Dec 4 13:09:44 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 04 Dec 2020 20:09:44 +0100 Subject: [crossfire] Archetypes collection changes proposal In-Reply-To: <3256487.CeY3E2ERJf@gros> References: <1906015.4M1vBobDh4@gros> <19358184.cMnRteQz4t@gros> <3256487.CeY3E2ERJf@gros> Message-ID: <3004983.JRZfZWEfu8@gros> Hello. For information, the patch is being tested (and bugs ironed out :)) on invidious. Best regards Nicolas Le lundi 30 novembre 2020, 19:28:29 CET Nicolas Weeger a écrit : > Hello. > > > So, anyone courageous (or crazy? :)) enough to have looked at my patch? :) > > > Best regards > > > Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Wed Dec 9 11:39:45 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 09 Dec 2020 18:39:45 +0100 Subject: [crossfire] Archetypes collection changes proposal In-Reply-To: <1906015.4M1vBobDh4@gros> References: <1906015.4M1vBobDh4@gros> Message-ID: <1965578.6Np48SYa15@gros> Hello. I think my code works nicely now :) It's been running on invidious for some days, no crash as far as I can tell. What I added as support: - of course, ability to run the server with a simple "arch" directory, without any collect to do :) - ability of the server to read .tar files with .png image files (only png for now because of loading routines using FILE* directly - will be changed ultimately) - ability to create "packed" archetypes, treasures, faces, png, and such things. Again this is done by the server directly. When everything is packed in a single file per asset, loading is quite fast :) I did not add gz support, I'm not sure it's worth it (we're talking about some MB of data only), but once .tar support is complete it shouldn't be too hard to add. What I plan to change/fix: - move "smoothface" stuff from .arc to .face files - change the "image_info" file format (removing the index and using the prefix for fallback) - probably add some extensions to various files, to not rely on the name only (artifacts, messages, attackmess, image_info, formulae notably) - while I'm at it, I'll also remove the "race reset" functionality from the races file, it is not used at all - besides, what's the point since one can simply change the archetype directly?) - also, when "packing" archetypes or treasures or ..., comments are not stored (as opposed to the current collect system). This may be fixed if I'm courageous enough ;) So, should I just commit to trunk? :D Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Thu Dec 10 11:06:07 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 10 Dec 2020 18:06:07 +0100 Subject: [crossfire] Server code structure Message-ID: <2197076.PRbbK30aAL@gros> Hello. The server code is currently divided in libraries, but without a clean separation IMO. For instance why is "rod_adjust" in server and not in "common"? (forcing users of common to declare a stub) Should we just decide to put all code together and forget the 4 or 5 libraries, or on the opposite try to really separate things? I was planning (someday :)) to tackle the events system, and move it to common, probably, that could help separate the logic - event "item_created" that the server could hook for rod adjustment. This would enable to remove the various stubs. But if we decide it's ok to keep libraries separate, that's fine by me too :) Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From kevinz5000 at gmail.com Thu Dec 10 12:17:51 2020 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Thu, 10 Dec 2020 10:17:51 -0800 Subject: [crossfire] Archetypes collection changes proposal In-Reply-To: <1965578.6Np48SYa15@gros> References: <1906015.4M1vBobDh4@gros> <1965578.6Np48SYa15@gros> Message-ID: <32e5ace1-64b0-1316-c737-63721b0f2f10@gmail.com> Hi Nicolas, Thank you for working on this. As we've discussed, this code is already running on Invidious and seems to be in working order. I think this is ready to be committed to trunk. Regards, Kevin From mwedel at sonic.net Fri Dec 11 00:57:17 2020 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 10 Dec 2020 22:57:17 -0800 Subject: [crossfire] Server code structure In-Reply-To: <2197076.PRbbK30aAL@gros> References: <2197076.PRbbK30aAL@gros> Message-ID: <687bf549-43e7-e545-6c88-4b7791482908@sonic.net> On 12/10/20 9:06 AM, Nicolas Weeger wrote: > Hello. > > > The server code is currently divided in libraries, but without a clean > separation IMO. > > For instance why is "rod_adjust" in server and not in "common"? (forcing users > of common to declare a stub) > > > Should we just decide to put all code together and forget the 4 or 5 > libraries, or on the opposite try to really separate things? > > > I was planning (someday :)) to tackle the events system, and move it to > common, probably, that could help separate the logic - event "item_created" > that the server could hook for rod adjustment. This would enable to remove the > various stubs. > > But if we decide it's ok to keep libraries separate, that's fine by me too :) Now days, it may not make that much sense. Back when crossedit existed, it used the common to deal with the loading & saving of maps and archetypes, and more or less, stuff not related to that was in the server directory. But crossedit is long since gone. At this point, some of the directories (socket, random_maps, etc) make sense in that it puts all the related code in one place. But common is a bit of a mix. Its a somewhat tricky balance - common was originally related to the load/save logic (and actual common things, like object handling, etc). But then you get the case of having the logic to load the data file, doesn't it make sense to have the logic that uses that data to be in the same file, and then it becomes less clear where that line between common and server is. From nicolas.weeger at laposte.net Sun Dec 13 04:25:54 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 13 Dec 2020 11:25:54 +0100 Subject: [crossfire] Game play thoughts, ideas, ramblings :) Message-ID: <2545708.UW7pVUQ2zZ@gros> Hello. Been thinking of the game play lately, so I figured I'd share some ideas, ramblings, thoughts about that :) I'm not saying I'll change the game to match what I say in this mail, I merely want to share ideas & such to see what other opinions exist :) I'm not either saying I'll fight against patches going in another direction :) Everything reflects my opinions and tastes, even if I write it as an affirmation for simplicity, and nothing is an absolute truth of course :p And I may be wrong or forget things, feel free to correct :) And I of course may be influenced by other games, hack & slash ones, quite possibly :) First and foremost, CF is a keyboard-based game. Yes it's possible to use the mouse for some things, but mostly the game uses the keyboard. Therefore it is not a point-and-click, and I for one don't want CF to become one - keyboard is fine. In the same way, the game is tile-based, not a discrete grid. About the world, it's mostly fantasy-based. There are hints about mechanical- like things (in Euthville notably), and maybe we could add some items or maps in this taste, but I'd rather not be going into a real cyberpunk universe, or a science-fiction one. So magic, monsters, gods, maybe some mechanical, but no spaceships, no planes, or such :) There is much content, scattered in the world. Many maps have no hints so one has to just wander around to find'em, others are linked to quests or texts or such. I'm not for a guide-based game where every & all maps have hints pointing to their existence, having to move around to explore is fine, but maybe right now there aren't enough hints or such... Random maps aren't that interesting. They are mostly experience source, or a filler between handmade maps. Maybe we could try to generate dungeons with eg a final boss, some special reward, and reduce "filler" maps (like Valriel's or Gorokh's temples which have like 100 levels...). And random maps look too similar, too small for many monsters... Currently, the game is based on D&D rules, with AC/WC, classes, races, and such. With our current implementation, characters can't really be customized, they all tend to be similar. Classes don't really have much sense, except the monk with meditation. Races have slightly more meaning, with restrictions on weapons or armour or things like that. I think I would prefer having more distinct playing styles, so not jack-of- all-traces characters but ones with real distinctions, maybe special skills for some classes or races, real skills to kill monsters that make a difference in how we play. One consequence of the D&D rules is that attribute points don't really matter soon after starting playing - once you reach 25+ in all stats (except cha), not much else to do... I'm not sure whether I like this system or if I prefer gaining points for each level that you can position on stats like you want (eg gain 2 points per level that you can inject in str or dex or wis). This would allow customizing the character more. But this means we have to figure how those points affect eg damage, ac/wc, and such. About items, I think there are waaaaaaaayyyy too many. Junk given by monsters is just too much, it takes a while to sort items. Yes it makes for more realistic stuff (why would only 1 goblin on 10 have a sword?), but it becomes quite a chore to sort. I was thinking about the possibility of giving treasure items a chance to be god-given. Eg a goblin would have a sword and a shield, each having a 70% chance of being god-given. Thus the goblin would be equipped to fight, but wouldn't drop so much junk. Or the item would break and become a dust pile, something like that. I like the idea of being able to customize weapons or armour (maybe other items?), with scrolls or spells, but that needs to be balanced to not push towards the same customization. Ha, and I'd really love fun items to change the game play - a sword that randomly bites you or cast a spell? A powerful armor that randomly teleports you a few cases away? An amulet that sucks your sp to give fire resist? About spells, I think there are too many, and many useless. Why the need to have "small fireball", "medium fireball", and "large fireball"? Why not having it scale better, or the medium replacing the small and such? Or allowing the player to balance the spell's effects between duration, range, damage? Some spells like poison cloud don't seem really useful... Some skills are way too slow to level. Summoning is quite bad, summoned monsters are just too weak. They definitely need a big boost, to make it more interesting. Resistances are too numerous, and messy - 50% for acid is enough to protect your items, but eg confusion at 70% may lead to being confused. So some rethinking may be in order. About character leveling, I think the "speed to level" really depends on the "endgame" we wish to have. Is the aim of the game to become a really powerful character who can slay anything? Is the aim to just explore and find interesting maps/items, leveling being a side-effect? Both have drawbacks, mostly the need to create content or the need to balance monsters :) Given the game style, aiming for a "all-monsters-slayer" doesn't sound that great to me, I think I'd rather aim for "explore the world to find good and interesting items or maps". Which of course requires to add content... We don't have a "final boss to kill", and I don't wish to have such endgame :) Sorry for the long mail :) Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Mon Dec 14 01:14:55 2020 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 13 Dec 2020 23:14:55 -0800 Subject: [crossfire] Game play thoughts, ideas, ramblings :) In-Reply-To: <2545708.UW7pVUQ2zZ@gros> References: <2545708.UW7pVUQ2zZ@gros> Message-ID: <398e04c9-cdb6-1302-d062-e390648f8a78@sonic.net> In general, I agree with much of what you say, and will only discuss points where I have something to add or differ. I reference different versions of D&D here, partly because that is what the game is seemingly based on, but also because looking at what other have done may be useful Scattered content: I agree with this, and will note that while information on some maps may have hints provided elsewhere, then it becomes the question of 'How was I suppose to know I had to talk to X to find out about this?' And there is something of a fine line between having enough hints vs so many that it becomes over advertised. I guess other games make this a little easier by making NPCs that have something useful to say be highlight or something. Random maps, from my recollection, really were meant as something of a filler, as well as ways to have some variety - the final map may be set up, but the path to get there varies. But really deep random maps more seem to be a way to get lots of items. Game rules/races/classes - agree here, some attempts were made in the past in the past to add differentiation, but one problem is that the game is largely hack and slash, and that mage ends up behaving a lot like a fighter in order to regain sp. I think some thought would have to be given on what changes may be necessary to let someone play as a pure spellcaster. That concept exists in D&D because they are part of a party. In crossfire, where they may be on their own, how does that exist? And how to balance all of this. One thing D&Dv5 did was give spellcasters OK damage cantrips that they can cast at well - maybe something like a 0 sp magic bullet spell. The attribute system also follows the D&Dv1 where the bonus from stats gets a lot better as they go up (at 24 -> 25 is a lot bigger bonus than a 14->15). D&Dv3 basically changed that to a linear system - in such a system, letting characters raise stats now and again as they level (and make weapons that improve stats) less an issue. Items: Some games behave as crossfire (every item that the monster had drops) and other only drop a subset. One thing that makes crossfire worse is that there are so many variation, and a lot more things are killed. So you don't get a stack of 10 short swords from killing 10 goblins, you get 5 normal ones, 2 -1, 1 +1, a few different 'shortsword of X' where X is different, etc. Spells: Agree there are too many. Being able to do something like 'cast fireball of radius X' would be one way to reduce the number of spells, as small/medium/large variations go away. X would depend on level of the caster, and perhaps keep gong up, so at level 100, you could cast massive fireballs. Maybe as balance, if radius is large, damage goes down, but how to exactly balance is hard. One of the elder scrolls games allowed one to make custom spells (I'm think 3- morrowind), and that did not show up in subsequent games. But I quickly learned how you min/max spell creation, so I sort of think adding it to crossfire would create a new set of balancing headaches. The fact that there are a huge number of spells is what led me to create different spellcasting schools - it just seemed a bit over powered that one would get access to hundreds of spells (this sort of relates to the skills). Going to stricter classes above, if one made it not possible to learn new spellcasting skills, one could differentiate classes some by each having a unique spellcasting skill, and the spells for each skill is different (there would be some overlap, but not every one would have fireball). This could allow for more balance spellcasting classes, which at the same time are different. Skills could probably be revisited - some may not be interesting enough to really warrant keeping around - some were also made when character level == effective level for skills, so how to level them was not a concern, but leveling them where you have to earn experience in the skill is a problem. Resistances & attacktypes: There probably are too many. And some are more effect than damage. From kevinz5000 at gmail.com Sat Dec 19 00:35:32 2020 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 19 Dec 2020 00:35:32 -0600 Subject: [crossfire] Python 3 conversion for trunk server users Message-ID: Hi folks, With Python 3's end-of-life nearly upon us, it is time to make the great leap and switch to Python 3. Thanks to the work of many others, the switch now is relatively small. Those who are running servers tracking trunk: after r21626, you should run cfdb_convert on existing databases. Some additional details about cfdb_convert are in the commit message, copied here: This Python 3 utility converts Python 2 bsddb 'shelve' databases to the default Python 3 'shelve' format. Server operators running existing servers should convert existing databases after switching to Python 3. Running cfdb_convert with the '--auto' flag in the 'var/crossfire' directory will automatically convert a list of standard databases with known names. We anticipate minor fall-out from existing scripts that still use Python 2 syntax, or result in run-time errors due to semantic changes in Python 3. Please report them here, or on the list, so that they can be fixed as quickly as possible. Regards, Kevin From nicolas.weeger at laposte.net Mon Dec 28 13:32:54 2020 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 28 Dec 2020 20:32:54 +0100 Subject: [crossfire] Events, plugins rework Message-ID: <1891713.liGFtJbjzd@gros> Hello. I was thinking of reworking the events system, as well as the plugin one. Currently, "events", events linked to specific objects (through the archetype in inventory trick) and global events (clock, map loading and such) are in the plugin system. I'd like to move the event system to the common library, independently of the plugins. Then I'd like to change the current plugins (especially the Python one) to be "modules", that is "code that may conditionally be compiled [if requirements are met], is statically linked to the server, and may be enabled/disabled at startup or during the server run". Basically, like the current plugins, but not as a dynamic library. My rationale is that having such a dynamic system is overkill for eg Python, and adds some overhead (as well as code complexity). Was there a real use case for unloading the Python plugin, changing it, and reloading? [note: with the Python3 migration, it seems our modules imported through "import" in the Python code aren't updated when the .py file changes, that is if CFDialog.py is updated, changes don't seem to be taken into account. This is why enabling/disabling modules seems a good idea too. Of course that bug(?) can probably be fixed :)] I intend "modules" to only consist of a few pre-init, post-init and such functions, with the rule that no other module function is to be called directly outside a plugin. Basically, like the "quests" or "knowledge" code, replacing direct function calls to use events. I don't plan to remove the plugin system per se, but move plugins to modules, and leave the plugin system as-is, without any actual plugin. And I intend to use C++ for that, too, you've been warned :) Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: