From nicolas.weeger at laposte.net Tue Apr 6 07:46:38 2021 From: nicolas.weeger at laposte.net (nicolas.weeger at laposte.net) Date: Tue, 06 Apr 2021 14:46:38 +0200 Subject: [crossfire] Handling massive loot In-Reply-To: <1182030941.156811.1617036142574@wlpnf0218> References: <1399262968.156683.1617036128833@wlpnf0218> <1182030941.156811.1617036142574@wlpnf0218> Message-ID: <6865199.h8nFJo5YUy@gros> Hello. Slightly old thread, but well. The problem, as I see it, is that there is a need for scripting on the client in the first place... CF is, for me at least, a RPG game, not a script-making game... So let's figure WHY we need scripting, to fix that, instead of fixing the lack of documentation. Proposal around that, unrelated to loot handling but well: there is the "knowledge attempt " command, to have the player attempt a recipe when having ingredients in inventory and standing on the correct crafting tool (workbench and such) I was thinking of extending to "knowledge attempt* " to attempt as long as the player got ingredients in stock. This way, no need for scripting... This would though first require the server architecture change I proposed at the start of the thread. Nicolas‌ De : "Robert Brockway"A : "Crossfire Discussion Mailing List"Envoyé: samedi 27 Mars 2021 14:32Objet : Re: [crossfire] Handling massive loot On Sat, 27 Mar 2021, Nathaniel Kipps wrote: > Case in point, I've played the game off and on for years, and still > haven't figured out how to script properly. This is the problem. Even experienced players have issues with Crossfire scripting. My concern is that scripting is under-documented. Scouring the Internet years ago I found that some people had developed some quite sophisticated Crossfire scripts but almost none of them had been distributed beyond being mentioned in blog posts and the like. Everyone is welcome to any scripts I've developed. None of them are particularly complex. A few more complex examples can be found at the link below. http://murga-linux.com/puppy/viewtopic.php?t=80525 Rob _______________________________________________ crossfire mailing list crossfire at metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From robert at timetraveller.org Tue Apr 6 23:48:29 2021 From: robert at timetraveller.org (Robert Brockway) Date: Wed, 7 Apr 2021 14:48:29 +1000 (AEST) Subject: [crossfire] Handling massive loot In-Reply-To: <6865199.h8nFJo5YUy@gros> References: <1399262968.156683.1617036128833@wlpnf0218> <1182030941.156811.1617036142574@wlpnf0218> <6865199.h8nFJo5YUy@gros> Message-ID: On Tue, 6 Apr 2021, nicolas.weeger at laposte.net wrote: > The problem, as I see it, is that there is a need for scripting on the > client in the first place... > > CF is, for me at least, a RPG game, not a script-making game... > > > So let's figure WHY we need scripting, to fix that, instead of fixing > the lack of documentation. Hi Nicholas. I'd like to highlight the difference between *writing* scripts and *using* scripts. I agree that no one should have to write scripts in order to play. That you can write scripts is a feature but it should never be required. Using scripts though could be transparent to the user. Perhaps the client could maintain a standard location for scripts and automatically install a series of scripts there the first time it starts. These scripts would essentially be transparent to the user but power users would still have the ability to extend the scripts or produce new ones. > I was thinking of extending to "knowledge attempt* " to attempt as > long as the player got ingredients in stock. This way, no need for > scripting... To the extent that you can predict how scripting will be used. Even if you make the extensions you're talking about I'd urge the devs to retain client side scripting. Some of us find it very useful. Rob From nicolas.weeger at laposte.net Sun Apr 11 06:11:14 2021 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 11 Apr 2021 13:11:14 +0200 Subject: [crossfire] Plugins Message-ID: <6669592.F6qTJFWPzN@gros> Hello. I'd like to move some plugins to the server "core" itself, possibly with option to disable the relevant code at startup (and if required, disabling/ enabling by a DM, like plugins). The rationale is that the plugin code adds some overhead, and having code dynamically loaded isn't that important, I think. I'm thinking of converting the city bells plugin, then the city life one. One benefit is that it'll allow those code chunks ("modules", I guess) to hook into the asset collecting process, and use split files for eg bell definitions, instead of hardcoding things. Maybe later the Python plugin too could be more integrated (with optional compilation depending on Python detection). Opinions? 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 Sun Apr 11 13:33:59 2021 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 11 Apr 2021 11:33:59 -0700 Subject: [crossfire] Plugins In-Reply-To: <6669592.F6qTJFWPzN@gros> References: <6669592.F6qTJFWPzN@gros> Message-ID: <549a2277-9e2d-2370-2f3d-70a7bb3bad9b@gmail.com> Hi Nicolas, On 4/11/21 4:11 AM, Nicolas Weeger wrote: > I'd like to move some plugins to the server "core" itself, possibly with > option to disable the relevant code at startup (and if required, disabling/ > enabling by a DM, like plugins). > > The rationale is that the plugin code adds some overhead, and having code > dynamically loaded isn't that important, I think. I'd agree with merging the plugins in with the core. To clarify, I don't think there's appreciable performance overhead, but there is a lot of overhead having to shim all server calls through CFAPI. This makes it difficult to use functions and data structures in the server. > I'm thinking of converting the city bells plugin, then the city life one. I think this is a great way to get this started. Regards, Kevin From nicolas.weeger at laposte.net Tue Apr 20 13:07:17 2021 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 20 Apr 2021 20:07:17 +0200 Subject: [crossfire] Plugins In-Reply-To: <6669592.F6qTJFWPzN@gros> References: <6669592.F6qTJFWPzN@gros> Message-ID: <1866606.TvQuhH9Z8v@gros> Hello. I committed the changes for citybell and citylife. I also moved from a hardcoded configuration to a file-based configuration for those 2 modules, with files in the "maps" repository (since bells and NPCs are linked to maps, obviously :)). And I migrated the 2 files to C++ during the process. The 2 former plugins are automatically disabled, but server admins should probably do some cleaning in ~prefix/lib/crossfire/plugins anyway :) Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: