From tchize at myrealbox.com Sat Jun 3 14:37:46 2006 From: tchize at myrealbox.com (tchize) Date: Sat, 03 Jun 2006 21:37:46 +0200 Subject: [crossfire] [Humour] Have fun moments with crossfire code Message-ID: <4481E50A.4000203@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While writing some test i came accross this line of code in sum_weight() (object.c) if(op->carrying != sum) op->carrying = sum; I suppose whoever wrote this had in mind that some memory chips are faster at ready data than writing them. I guess it make sense for very slow memory. PS: it might be interresting to write some wiki page with all strange code we find :D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEgeUKHHGOa1Q2wXwRAsLbAJ9mVYcvJYTXVVKkL5p/2DTInx0R/QCffwru c9fKZt8B4hJeL42iG9TsBZk= =EnHA -----END PGP SIGNATURE----- From mwedel at sonic.net Mon Jun 5 01:35:11 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 04 Jun 2006 23:35:11 -0700 Subject: [crossfire] [Humour] Have fun moments with crossfire code In-Reply-To: <4481E50A.4000203@myrealbox.com> References: <4481E50A.4000203@myrealbox.com> Message-ID: <4483D09F.6040205@sonic.net> tchize wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > While writing some test i came accross this line of code in > sum_weight() (object.c) > > if(op->carrying != sum) > op->carrying = sum; > > I suppose whoever wrote this had in mind that some memory chips are > faster at ready data than writing them. I guess it make sense for very > slow memory. Or more likely, it used to do something more which was removed, and the person removing it wasn't paying much attention to what was left. Another oddity is that the banner copyright for all the files says this: CrossFire, A Multiplayer game for X-windows I just noticed that when updating a few copyright notices (don't read anything into me doing that - I just noticed they were all out of date, and figured since I was checking the file anyways, might as well update them). While such a comment may be somewhat appropriate for the client, on the server side, that is pretty inaccurate, and has been for quite a while/ From mwedel at sonic.net Mon Jun 5 02:01:37 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 05 Jun 2006 00:01:37 -0700 Subject: [crossfire] code cleanup commit. Message-ID: <4483D6D1.4050405@sonic.net> I just did a commit which really doesn't change any code, but does clean up some compiler warnings (now the core area compiles without warnings when compiled with gcc -Wall -Wno-char-subscripts). As part of that, I removed a bunch of functions that were not being used (with #if 0/#endif blocks). In some cases, I'm not sure if some may be work in progress or plan to be used, and thus not ripped out. That said, my belief would be that if there are no indications that they are needed, those blocks of codes should just get removed in a couple months - no reason to have code around that no one is using (and if someone really wants it again, it is in CVS). But just looking for #if 0 within the code, there are about 90 such uses. Most are of the nature: #if 0 LOG(...) #endif Which are harmless, but I think we should do a real logging system so that isn't needed - instead, pass in the type of log message (object, map, player, spell) to the log function, and then be able to specify what log messages we want via command like, like 'crossfire -debugmsg +map,+player' - that is what a lot of other programs do, and to me makes a lot more sense. A fair number of other #if 0 are disabling small portions of code to turn off some undesirable behaviour. I'm thinking that these should either be just pulled out, or if they might be useful, should be enabled either via real #ifdefs or settings. Thoughts? From nicolas.weeger at laposte.net Mon Jun 5 15:54:39 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 5 Jun 2006 22:54:39 +0200 Subject: [crossfire] code cleanup commit. In-Reply-To: <4483D6D1.4050405@sonic.net> References: <4483D6D1.4050405@sonic.net> Message-ID: <200606052254.39970.nicolas.weeger@laposte.net> > I just did a commit which really doesn't change any code, but does clean > up some compiler warnings (now the core area compiles without warnings when > compiled with gcc -Wall -Wno-char-subscripts). Hum, I see no commit mail from you, probably lost in SF's abyssal system :) > That said, my belief would be that if there are no indications that they > are needed, those blocks of codes should just get removed in a couple > months - no reason to have code around that no one is using (and if someone > really wants it again, it is in CVS). Agreed here. Old code should just go, CVS is here for history :) > Which are harmless, but I think we should do a real logging system so that > isn't needed - instead, pass in the type of log message (object, map, > player, spell) to the log function, and then be able to specify what log > messages we want via command like, like 'crossfire -debugmsg +map,+player' > - that is what a lot of other programs do, and to me makes a lot more > sense. Would require a rewrite of log stuff, and many call. I'd say we should do it at once though, it will avoid having deprecated LOG and new LOG2 around :) > A fair number of other #if 0 are disabling small portions of code to turn > off some undesirable behaviour. I'm thinking that these should either be > just pulled out, or if they might be useful, should be enabled either via > real #ifdefs or settings. Agreed on that. If something is disabled, either it's broken and should go, or should be compilable through settings. Maybe though as many things as possible should be settings, not #define. Simply because Crossfire is not too easy to compile under Windows, so I'd rather have people use settings than say ? please recompile with --enable-obscure-feature ? :) Nicolas From mwedel at sonic.net Mon Jun 5 23:51:13 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 05 Jun 2006 21:51:13 -0700 Subject: [crossfire] code cleanup commit. In-Reply-To: <200606052254.39970.nicolas.weeger@laposte.net> References: <4483D6D1.4050405@sonic.net> <200606052254.39970.nicolas.weeger@laposte.net> Message-ID: <448509C1.8060304@sonic.net> Nicolas Weeger (Laposte) wrote: >> Which are harmless, but I think we should do a real logging system so that >> isn't needed - instead, pass in the type of log message (object, map, >> player, spell) to the log function, and then be able to specify what log >> messages we want via command like, like 'crossfire -debugmsg +map,+player' >> - that is what a lot of other programs do, and to me makes a lot more >> sense. > > Would require a rewrite of log stuff, and many call. I'd say we should do it > at once though, it will avoid having deprecated LOG and new LOG2 around :) My thought to make this easier is to make a bitmasks (since one log message could be about several thing anyways), and then just or that with the current passed log level (llevDebug, llevError, etc). In this way, it can be done piecemeal. If no functionality is passed (eg, just a llevDebug, because the code is old), it would be treated as either it matches everything, or it defaults into some generic case. In this way, these can be cleaned up on a case by case basis. There are apparantly 1012 LOG calls within the code, so cleaning them all up would be a big process. There are currently 4 log levels - error, info, debug, and monster. Monster is used in just a few place. info is used in about 30 places. I'm not quite sure how info and debug differ right now. I'd suggest 3 notification levels: Error: Something is clearly wrong, and this typically means that operation can not complete (eg, function returns when detecting this instead of doing what it was requested). This would be the default log level. All errors generated are things that should be fixed - under normal operation, crossfire should not generate things at the error level. Warning: something in the data looks suspect, but that doesn't prevent the operation from completing. An example of this right now is the loading of objects - it prints a message about anything being put in a key-value list - that is generally fine, but could be cases of a typo and maybe something to pay attention to (eg, someone does max_grce instead of max_grace). Running at the warning level would show more messages, but these may or may not be messages. Debug: Purely for debugging purposes - these are only here to be useful when trying to track down a problem, and would not have any value to be used during normal operation. Then on top of this, the different categories would be added. Those categories would need to be discussed - one message could belong to several categories, so would be good to sort that out before this got too far along. > >> A fair number of other #if 0 are disabling small portions of code to turn >> off some undesirable behaviour. I'm thinking that these should either be >> just pulled out, or if they might be useful, should be enabled either via >> real #ifdefs or settings. > > Agreed on that. If something is disabled, either it's broken and should go, or > should be compilable through settings. > Maybe though as many things as possible should be settings, not #define. > Simply because Crossfire is not too easy to compile under Windows, so I'd > rather have people use settings than say ? please recompile with > --enable-obscure-feature ? :) Yes - there really shouldn't be any code that is selected by compile time options (or very few). Aside from difficulty on windows for that, the problem is that if those are normally turned off, the code can be broken (compile wise) for quite a while before anyone notices. However, even with run time defaults, that is somewhat the cases - sure, the code compiles, but if it is never executed, it can still be broken. The new test framework can probably help in this. But if there are options that no one ever uses, better to remove that code and not have to worry about that potential support problem. I'd argue that anything that is an #if 0 right now falls into the 'never used category'. From tchize at myrealbox.com Tue Jun 6 04:18:21 2006 From: tchize at myrealbox.com (Tchize) Date: Tue, 06 Jun 2006 11:18:21 +0200 Subject: [crossfire] code cleanup commit. In-Reply-To: <448509C1.8060304@sonic.net> References: <4483D6D1.4050405@sonic.net> <200606052254.39970.nicolas.weeger@laposte.net> <448509C1.8060304@sonic.net> Message-ID: <4485485D.9040506@myrealbox.com> Sorry, jumping in Thread a bit late. I have quite a few experience with logging mecanism, here is my suggestion Arrange log entries in a hierarchy (scopes) like is done in java logging mecanisms: example: common.object (for everything related to object) Provide different levels of logging (idea: finest, fine, info, warning, error, critical), default visible level would be info Then you can say in config (or command line) default=warning common.object=finest server.monster=finest server=info random_maps=info socket=info Provide with the possibility to check if a specific level is enabled if (loglevel_enabled(scope,LOG_FINEST)){ /* do very complex operations here that can not be easily resumed in a function call */ /* optionally at end issue a log call */ LOG(scope,LOG_FINEST,result_of_complex_logging_operations) } Use also as information the line,file,function information, as preprocessor provide them , but do not use them for filtering, use them only when analysing a log to know where a problem occurs Cherry on the cake: provide ASSERT statements derived from logging mecanism that could issue warning/error if assertions fails This way, log call are only made when necessary and are very fast if not activated. There are two critical points if we want usefull debugs, - performance loss when logging is not usefull should be minimal (no unneeded operation) - should be able to enable / disable by whole tree or by single elements depending on what you need I think the idea of bitmask to tell a log call is part of several section at same time is useless. A log call should always be localized easily to activate / deactivate in config. Note i have used the above described mecanism in java for 1 year, this is very flexible, powerfull and suffer no noticeable performance loss while there are tons of log messages. I suggest you take a look at how log4j works. Also, i checked log4c, but unfortunately, it use gcc specific features (like __attributes__) From alex_sch at telus.net Tue Jun 6 19:04:19 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 06 Jun 2006 18:04:19 -0600 Subject: [crossfire] [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <44861803.5060801@telus.net> Crossfire CVS repository messages. wrote: >Module Name: crossfire >Committed By: ryo_saeba >Date: Tue Jun 6 22:16:25 UTC 2006 > >Modified Files: > crossfire/common: loader.c > crossfire/make_win32: crossfire32.dsp > >Log Message: >Fix Win32 compilation > > > >*** 9,15 **** >--- 9,17 ---- > #define YY_FLEX_MINOR_VERSION 5 > > #include >+ #ifndef WIN32 > #include >+ #endif > I'm not sure this is the best fix for it as loader.c is code generated from loader.l by flex. Next time someone updates loader.l and regenerates loader.c this change will be undone. As this include is made by flex and not from loader.l, it would be best to see what options for regenerating that flex might have that might help this. Alex Schultz From bortweb at yahoo.com Tue Jun 6 21:11:08 2006 From: bortweb at yahoo.com (Brad Reilly) Date: Tue, 6 Jun 2006 19:11:08 -0700 (PDT) Subject: [crossfire] [CF-maps] New Maps Update Message-ID: <20060607021108.11953.qmail@web34010.mail.mud.yahoo.com> Here is the world map in Scorn. The new map is next to the newbie tower. At the moment I am running the windows server snapshot v.1.8.0. Thanks for your time, Brad __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060606/6fdb82e5/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: world_105_116 Type: application/octet-stream Size: 117006 bytes Desc: 1080120650-world_105_116 Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060606/6fdb82e5/attachment-0001.obj From mwedel at sonic.net Tue Jun 6 23:22:27 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 06 Jun 2006 21:22:27 -0700 Subject: [crossfire] [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <44861803.5060801@telus.net> References: <44861803.5060801@telus.net> Message-ID: <44865483.4060401@sonic.net> Alex Schultz wrote: > Crossfire CVS repository messages. wrote: > >> Module Name: crossfire >> Committed By: ryo_saeba >> Date: Tue Jun 6 22:16:25 UTC 2006 >> >> Modified Files: >> crossfire/common: loader.c >> crossfire/make_win32: crossfire32.dsp >> >> Log Message: >> Fix Win32 compilation >> >> >> > > >> *** 9,15 **** >> --- 9,17 ---- >> #define YY_FLEX_MINOR_VERSION 5 >> >> #include >> + #ifndef WIN32 >> #include >> + #endif >> > I'm not sure this is the best fix for it as loader.c is code generated > from loader.l by flex. Next time someone updates loader.l and > regenerates loader.c this change will be undone. As this include is made > by flex and not from loader.l, it would be best to see what options for > regenerating that flex might have that might help this. I think I looked, and flex doesn't have any option (the presumption probably being that you could just use flex to generate a proper .c file on whatever system). The only thing that could perhaps be done is to add some shell script commands to the makefile to put in the #ifndef and #endif lines (probably could be done by sed). Other possibility, which I'm not sure how easy it would be to do, would be to have an empty unistd.h file someplace in the code that the windows build uses (-Iwindows_includes) so it finds the file, but nothing of use in it. I believe this unistd.h also would happen with the other lex files, but the only other one is probably the random map code. From nicolas.weeger at laposte.net Fri Jun 9 13:27:54 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 9 Jun 2006 20:27:54 +0200 Subject: [crossfire] Quest management system proposal Message-ID: <200606092027.54507.nicolas.weeger@laposte.net> Hello. I'm feeling ambitious, so here's a quest management system proposal :) Of course, whether I (or someone) will actually implement it isn't yet sure ^_- Quests should be finite state automates. Meaning different states, with transitions between states, with conditions for those transitions, etc. Each state would specify special behaviour for NPCs, texts so the player knows the quest status and what to do (or at least some hints). Also there would be the rewards for completing that state, everything needed. Transitions should describe what the player should do to actually change states. My idea is to have quest files. Each quest would be one file, describing all states, transitions, including all information on what NPC's behaviour to change, rewards, and so on. If required, a quest file could be accompanied by some special maps, archetypes, anything specific. The quest engine would, at start time, read those files, and process them. It would then, at map loading time, add revelant hooks to NPCs, or track global events (for instance follow player movement to know if they do what is required to complete a task). It would also keep, for each player, quest status, and such. Advantages I see: * quest's information is in one file, it's easy to see globally how it works, versus today's dispatched in maps, making it hard to look at, and check whether it's broken or not * as a correlary, adding/turning off a quest means moving one file (or a directory) * it wouldn't not rely on the hacks i did for the first basic quest system. I don't really like'em anyway :) * we can think of DM commands to look at quests, know what quest a player did, reset quest status. Maybe even dynamically alter quests! *g* * we can add a quest editor, probably included in the map one :) Drawbacks, opened questions: * one could change a map without updating a quest, thus it could be become broken - server should try to handle that graciously, and report it in any case * to have a really powerful quest system, and fun transitions (from bashing a specific monster to having 3 players do a special dance at a certain time), the conditions / transitions will require a full scripting language. So either reuse an existing one (Python, maybe? Or LUA? Or anything else?), or make our own - I'd favor reuing existing one, to avoid making Yet Another Script Language. Though of course if we use Python the Python plugin would become mandatory. * this quest system could be done either at server's core level, or as a plugin. Last option would require some changes in plugin architecture (basically move plugin handling from server part to common lib part, to add hooks at a basic level. Also add interplugin communication). * tracking player behaviour could be resource intensive - that will need testing and addressing if required :) Heck, I may just start working on that soon if I'm feeling in a good mood :) I'll add that proposal to the wiki when it's back up, of course, so everyone can poke it ^_- Nicolas From fuchs.andy at gmail.com Fri Jun 9 15:24:55 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri, 9 Jun 2006 16:24:55 -0400 Subject: [crossfire] Quest management system proposal In-Reply-To: <200606092027.54507.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> Message-ID: On 6/9/06, Nicolas Weeger (Laposte) wrote: > Hello. > > I'm feeling ambitious, so here's a quest management system proposal :) > Of course, whether I (or someone) will actually implement it isn't yet sure > ^_- > > > Quests should be finite state automates. Meaning different states, with > transitions between states, with conditions for those transitions, etc. > Each state would specify special behaviour for NPCs, texts so the player knows > the quest status and what to do (or at least some hints). Also there would be > the rewards for completing that state, everything needed. > Transitions should describe what the player should do to actually change > states. Good idea to keep branches, and subquests (which you can't do after the quest is over), etc. > My idea is to have quest files. Each quest would be one file, describing all > states, transitions, including all information on what NPC's behaviour to > change, rewards, and so on. > If required, a quest file could be accompanied by some special maps, > archetypes, anything specific. > > The quest engine would, at start time, read those files, and process them. It > would then, at map loading time, add revelant hooks to NPCs, or track global > events (for instance follow player movement to know if they do what is > required to complete a task). > It would also keep, for each player, quest status, and such. > > Advantages I see: > * quest's information is in one file, it's easy to see globally how it works, > versus today's dispatched in maps, making it hard to look at, and check > whether it's broken or not > * as a correlary, adding/turning off a quest means moving one file (or a > directory) Can get a bit wierd if done just on one server. > * it wouldn't not rely on the hacks i did for the first basic quest system. I > don't really like'em anyway :) > * we can think of DM commands to look at quests, know what quest a player did, > reset quest status. Maybe even dynamically alter quests! *g* > * we can add a quest editor, probably included in the map one :) > > Drawbacks, opened questions: > * one could change a map without updating a quest, thus it could be become > broken - server should try to handle that graciously, and report it in any > case > * to have a really powerful quest system, and fun transitions (from bashing a > specific monster to having 3 players do a special dance at a certain time), > the conditions / transitions will require a full scripting language. So > either reuse an existing one (Python, maybe? Or LUA? Or anything else?), or > make our own - I'd favor reuing existing one, to avoid making Yet Another > Script Language. Though of course if we use Python the Python plugin would > become mandatory. Some sort of scripting language being mandatory on the server side will probably encourage it's use by mapers. It may be a good idea to discuss implimenting LUA, since it has a smaller footprint, over using the existing python plugin. > * this quest system could be done either at server's core level, or as a > plugin. Last option would require some changes in plugin architecture > (basically move plugin handling from server part to common lib part, to add > hooks at a basic level. Also add interplugin communication). > * tracking player behaviour could be resource intensive - that will need > testing and addressing if required :) I like the idea of using it as a plugin. > Heck, I may just start working on that soon if I'm feeling in a good mood :) > > I'll add that proposal to the wiki when it's back up, of course, so everyone > can poke it ^_- -- Andrew Fuchs From leaf at real-time.com Fri Jun 9 17:11:55 2006 From: leaf at real-time.com (Rick Tanner) Date: Fri, 09 Jun 2006 17:11:55 -0500 Subject: [crossfire] Crossfire Wiki offline In-Reply-To: <446CEB73.0@real-time.com> References: <446CEB73.0@real-time.com> Message-ID: <4489F22B.3070409@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rick Tanner wrote: > > The Crossfire Wiki will be offline for the next few days due to > unplanned maintenance (AKA: borked dokuwiki upgrade) > > I'll post again when the wiki is back online. The wiki is back online, http://wiki.metalforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEifIqhHyvgBp+vH4RAgbBAJ9i9NI/Nq+5jYJ9lsyJyR8MHKZiCwCbBwvv 9syozTLH7JtHAvvG30h3OaM= =TgRs -----END PGP SIGNATURE----- From antonoussik at gmail.com Sat Jun 10 01:37:39 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Sat, 10 Jun 2006 07:37:39 +0100 Subject: [crossfire] Quest management system proposal In-Reply-To: References: <200606092027.54507.nicolas.weeger@laposte.net> Message-ID: You need to also consider inter-quest relationships. Completion of one quest may be necessary pre-condition for starting another quest, or could deny you a quest alltogether. You could make all related quests fit into one file I guess as one big quest, or add a way to add FA links across quests, which would be nicer. Another proposal related to quests I was thinking of for some time now is randomly generated quests (dynamic quests?). A random map generator is already present, so it is possible to produce random dungeons. An interesting extension to that would be to produce random quests. They would hugely extend the size of CF, and overcome the map contention issue, since there would be an almost limitless supply of maps and quests of all kinds and levels open to players. Random quests would work by linking the to several NPCs (in taverns, inns, etc. throughout the world), and by talking to an NPC a random quest gets generated on big world suitable for the player level, with an appropriate reward item at the end, and a randomly generated storyline. The players are told by the NPC how to find the entrance. To control access the NPC would give player(s) taking part the key(s) to the entrance. Quest types I can think of right now are: - Kill something - powerful boss at the end, drops the reward loot - Find something - useless (randomly generated?) item somewhere in the dungeon, need to find and bring back to NPC to get the quest reward item or experience. You can also have non-fighting oriented quests, but ones encouraging exploration, by making the player go to a remote part of the world. - Deliver something - give item (letter) to another NPC somewhere in CF - Deliver something and bring back something else - extension of previous one Another quest class could be quests that develop secondary skills: - Sneak into a dungeon and steal something (NPC awards stealing/hiding xp) - Bring back a rare useless item (NPC awards some alchemy-like xp) - Get an item from a dungeon full of traps (NPC awards finding and disarming traps xp) Finally you can have thinking (puzzle solving) oriented quests: - Move the boulders to get past and get to the item - Arrange boulders in the right places to open the door to the item - Pull the right levers - similar to above - Step on the right floor tiles From mwedel at sonic.net Sat Jun 10 02:06:17 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 10 Jun 2006 00:06:17 -0700 Subject: [crossfire] Quest management system proposal In-Reply-To: <200606092027.54507.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> Message-ID: <448A6F69.5010501@sonic.net> I don't really have time to go into all the details, but have some quick thoughts: Having the server of a plugin 'patch' objects loaded from the map itself seems to me to be a pretty horrible hack. I know from a debugging side of thing, having a bug with an object in some odd state, and not even being sure how it got that way is a pain. This also seems to be pretty problematic in terms of specific objects on specific maps (the NPC that gives out the quest info, for example). but I do then wonder if some hybrid approach could work better. For objects that need to be modified, have them modified in the map. But that doesn't prevent the use of a quest file like: bunch of question info # # npc A,B on map ... will say "blah blah" to the player, and will update # the quest state # .. .. So that one file will show all the details of the quest info without needing to try and patch the objects. I personally don't think the ability to turn on/off quests should really be a design concern right now - or if so, this is a bigger project in terms of map options - there is no convenient way to change passwords, disable some set of maps, etc right now. My thought is that if we want to do that, we should perhaps look into some macro processing language - as an example, with C preprocessor, you'd do something like: #ifdef QUEST_ENABLE .. #endif (not saying CPP should be used, but there are numerous macro processing languages that would probably do the job) In terms of script language, I think that is almost a different discussion - if python isn't sufficient or overly bloated, and we should move to something else, we should do that, but I don't think that should be an immediate design concern either. I forsee that if lua (or other language) is added as a quest specific script language, it wouldn't be long before it probably would turn into a full blown scripting language. I do think that we should find one (or worse case, a very select few) scripting language and stick with it - having a bunch of different script languages is just going to make things harder to maintain (now have several plugins codewise to support, and also harder from a script writer point of view - if all the scripts are in the same language, I can look at any of them to see how to do something, etc. If they are in a mix of different languages, that makes things more difficult. while I'm not that familiar with python, we already have it, and it seems to be a pretty widely used language. I normally can't envision the heaviness of the scripting language causing many problems as most plugins are not getting called enough that this should be a big issue. From nicolas.weeger at laposte.net Sat Jun 10 02:32:16 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 10 Jun 2006 09:32:16 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <448A6F69.5010501@sonic.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <448A6F69.5010501@sonic.net> Message-ID: <200606100932.16899.nicolas.weeger@laposte.net> > Having the server of a plugin 'patch' objects loaded from the map itself > seems to me to be a pretty horrible hack. I know from a debugging side of > thing, having a bug with an object in some odd state, and not even being > sure how it got that way is a pain. This also seems to be pretty > problematic in terms of specific objects on specific maps (the NPC that > gives out the quest info, for example). Just a precision: not talking about "patching" / "modifying" objects, just adding event handlers in inventory. > In terms of script language, I think that is almost a different > discussion - if python isn't sufficient or overly bloated, and we should > move to something else, we should do that, but I don't think that should be > an immediate design concern either. > > I forsee that if lua (or other language) is added as a quest specific > script language, it wouldn't be long before it probably would turn into a > full blown scripting language. Yes, that's another discussion :) But for instance Windows users don't always have Python installed, thus requiring it needs adding and maintaining links to Python packages, things like that. Nicolas From nicolas.weeger at laposte.net Sat Jun 10 02:33:36 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 10 Jun 2006 09:33:36 +0200 Subject: [crossfire] Crossfire Wiki offline In-Reply-To: <4489F22B.3070409@real-time.com> References: <446CEB73.0@real-time.com> <4489F22B.3070409@real-time.com> Message-ID: <200606100933.36902.nicolas.weeger@laposte.net> > The wiki is back online, http://wiki.metalforge.net/ Yeah! Thanks :) Nicolas From nicolas.weeger at laposte.net Sat Jun 10 03:01:29 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 10 Jun 2006 10:01:29 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <200606092027.54507.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> Message-ID: <200606101001.30048.nicolas.weeger@laposte.net> Copied my proposal to http://wiki.metalforge.net/doku.php/dev_toto:quest_management_system *does the wiki back up dance* :) Nicolas From raphael at gimp.org Mon Jun 12 09:14:37 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 12 Jun 2006 16:14:37 +0200 Subject: [crossfire] destructor archetype? Message-ID: <20060612161437.5a4fc3d0.raphael@gimp.org> Unless I am mistaken, there is no arch that can act as the opposite of the "creator" arch. Or at least I could not find one. The "creator" creates a new object when it is triggered. I would like to have a "destructor" that can remove a specific object when it is triggered. If such a thing does not exist yet, I would like to create it. Here are several cases in which a "destructor" could be useful: - A detector/check_inv connected to a destructor can have the same effect as an altar, except that it is possible to introduce a delay between dropping the item and destroying it (using the well-known hidden machinery with spikes and boulders or other objects), or to add additional conditions such as requiring the player to move away from the altar before the sacrifice is accepted. - With a creator and a destructor at the same location, it would be possible to make some object appear or disappear using the appropriate triggers. - The creation/destruction could be done in a cyclic way (using external machinery providing the timers). This could be fun if the blinking object is a light source. - If the object that is created/destroyed is a mover, it would be possible to make some NPCs follow some specific paths and stop or go depending on the actions of the player: create the movers when the NPC should move, then destroy them afterwards. - A destructor can also be used to make the NPC fetch and accept a gift: detect that a gift has been dropped (standard detector), move the NPC towards the player (creators + movers), then destroy the gift once the NPC is close to the player (destructor). The existing archetypes that could serve similar purposes are the altars and teleporters. The problem with the altars is that they work as soon as the object is dropped and cannot be triggered by some other event. The teleporters can be triggered via some external action and are used in some maps to move objects out of the visible map, but this is not a very good solution because these teleporters are not very selective about what they teleport (so you may end up teleporting the wrong object). So if nobody can suggest a better solution, I will write the code for this new archetype because I already have some maps (alchemy quests) in which I would like to use "destructors" for NPC movement and actions. My current plan is to have something very similar to the "creator" (including the parameters such as the "slaying" field, the number of uses, etc.) except that it would do exactly the opposite of the creator. -Rapha?l From wim-cf at villerius.nl Mon Jun 12 09:28:11 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Mon, 12 Jun 2006 16:28:11 +0200 Subject: [crossfire] destructor archetype? In-Reply-To: <20060612161437.5a4fc3d0.raphael@gimp.org> References: <20060612161437.5a4fc3d0.raphael@gimp.org> Message-ID: <1150122491.20848.17.camel@localhost.localdomain> Seems you're mistaken ;-) see the attached file for an example use of 'destructors' (or rather: using a duplicator as a destructor by setting the multiply factor to zero) Thanks to whoever made this map, I unfortunately forgot it's source. On Mon, 2006-06-12 at 16:14 +0200, Rapha?l Quinet wrote: > Unless I am mistaken, there is no arch that can act as the opposite of the > "creator" arch. Or at least I could not find one. The "creator" creates a > new object when it is triggered. I would like to have a "destructor" that > can remove a specific object when it is triggered. If such a thing does not > exist yet, I would like to create it. > > Here are several cases in which a "destructor" could be useful: > - A detector/check_inv connected to a destructor can have the same effect > as an altar, except that it is possible to introduce a delay between > dropping the item and destroying it (using the well-known hidden machinery > with spikes and boulders or other objects), or to add additional > conditions such as requiring the player to move away from the altar before > the sacrifice is accepted. > - With a creator and a destructor at the same location, it would be possible > to make some object appear or disappear using the appropriate triggers. > - The creation/destruction could be done in a cyclic way (using external > machinery providing the timers). This could be fun if the blinking object > is a light source. > - If the object that is created/destroyed is a mover, it would be possible > to make some NPCs follow some specific paths and stop or go depending on > the actions of the player: create the movers when the NPC should move, > then destroy them afterwards. > - A destructor can also be used to make the NPC fetch and accept a gift: > detect that a gift has been dropped (standard detector), move the NPC > towards the player (creators + movers), then destroy the gift once the NPC > is close to the player (destructor). > > The existing archetypes that could serve similar purposes are the altars and > teleporters. The problem with the altars is that they work as soon as the > object is dropped and cannot be triggered by some other event. The > teleporters can be triggered via some external action and are used in some > maps to move objects out of the visible map, but this is not a very good > solution because these teleporters are not very selective about what they > teleport (so you may end up teleporting the wrong object). > > So if nobody can suggest a better solution, I will write the code for this > new archetype because I already have some maps (alchemy quests) in which I > would like to use "destructors" for NPC movement and actions. My current > plan is to have something very similar to the "creator" (including the > parameters such as the "slaying" field, the number of uses, etc.) except that > it would do exactly the opposite of the creator. > > -Rapha?l > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -------------- next part -------------- arch map name benches msg Creator: CF Java Map Editor Date: 10/25/2004 endmsg width 15 height 15 end arch woodfloor x 3 y 3 end arch woodfloor x 3 y 4 end arch woodfloor x 3 y 5 end arch woodfloor x 3 y 6 end arch woodfloor x 3 y 7 end arch woodfloor x 3 y 8 end arch woodfloor x 3 y 9 end arch woodfloor x 3 y 10 end arch woodfloor x 3 y 11 end arch woodfloor x 4 y 3 end arch woodfloor x 4 y 4 end arch woodfloor x 4 y 5 end arch woodfloor x 4 y 6 end arch platinacoin nrof 10000 x 4 y 6 end arch woodfloor x 4 y 7 end arch woodfloor x 4 y 8 end arch woodfloor x 4 y 9 end arch woodfloor x 4 y 10 end arch woodfloor x 4 y 11 end arch woodfloor x 5 y 3 end arch woodfloor x 5 y 4 end arch woodfloor x 5 y 5 end arch woodfloor x 5 y 6 end arch woodfloor x 5 y 7 end arch woodfloor x 5 y 8 end arch woodfloor x 5 y 9 end arch woodfloor x 5 y 10 end arch woodfloor x 5 y 11 end arch woodfloor x 6 y 3 end arch woodfloor x 6 y 4 end arch woodfloor x 6 y 5 end arch woodfloor x 6 y 6 end arch woodfloor x 6 y 7 end arch woodfloor x 6 y 8 end arch woodfloor x 6 y 9 end arch woodfloor x 6 y 10 end arch woodfloor x 6 y 11 end arch woodfloor x 7 y 3 end arch woodfloor x 7 y 4 end arch woodfloor x 7 y 5 end arch woodfloor x 7 y 6 end arch woodfloor x 7 y 7 end arch woodfloor x 7 y 8 end arch woodfloor x 7 y 9 end arch woodfloor x 7 y 10 end arch woodfloor x 7 y 11 end arch woodfloor x 8 y 3 end arch woodfloor x 8 y 4 end arch woodfloor x 8 y 5 end arch woodfloor x 8 y 6 end arch woodfloor x 8 y 7 end arch woodfloor x 8 y 8 end arch woodfloor x 8 y 9 end arch woodfloor x 8 y 10 end arch woodfloor x 8 y 11 end arch woodfloor x 9 y 3 end arch woodfloor x 9 y 4 end arch woodfloor x 9 y 5 end arch woodfloor x 9 y 6 end arch woodfloor x 9 y 7 end arch woodfloor x 9 y 8 end arch woodfloor x 9 y 9 end arch woodfloor x 9 y 10 end arch woodfloor x 9 y 11 end arch woodfloor x 10 y 3 end arch woodfloor x 10 y 4 end arch duplicator other_arch cauldron connected 10 x 10 y 4 end arch creator other_arch cauldron connected 20 lifesave 1 hp 0 x 10 y 4 end arch cauldron no_pick 1 identified 1 x 10 y 4 end arch woodfloor x 10 y 5 end arch woodfloor x 10 y 6 end arch woodfloor x 10 y 7 end arch woodfloor x 10 y 8 end arch woodfloor x 10 y 9 end arch woodfloor x 10 y 10 end arch woodfloor x 10 y 11 end arch woodfloor x 11 y 3 end arch woodfloor x 11 y 4 end arch woodfloor x 11 y 5 end arch woodfloor x 11 y 6 end arch woodfloor x 11 y 7 end arch altar slaying platinum coin food 1 connected 10 x 11 y 7 end arch woodfloor x 11 y 8 end arch woodfloor x 11 y 9 end arch woodfloor x 11 y 10 end arch woodfloor x 11 y 11 end arch blocked x 12 y 6 end arch blocked x 12 y 7 end arch blocked x 12 y 8 end arch blocked x 12 y 9 end arch blocked x 13 y 6 end arch cobblestones2 x 13 y 7 end arch button_plate connected 20 x 13 y 7 end arch cobblestones2 x 13 y 8 end arch grate_open_1 connected 10 x 13 y 8 end arch boulder no_pass 0 x 13 y 8 end arch blocked x 13 y 9 end arch blocked x 14 y 6 end arch blocked x 14 y 7 end arch blocked x 14 y 8 end arch blocked x 14 y 9 end From tchize at myrealbox.com Mon Jun 12 09:39:39 2006 From: tchize at myrealbox.com (Tchize) Date: Mon, 12 Jun 2006 16:39:39 +0200 Subject: [crossfire] destructor archetype? In-Reply-To: <20060612161437.5a4fc3d0.raphael@gimp.org> References: <20060612161437.5a4fc3d0.raphael@gimp.org> Message-ID: <448D7CAB.4030009@myrealbox.com> Hi, looking at your mail, if think several things need improvement and might be worth a RFE - creator should be extended to behave the opposite way depending on a flag - note the chek_inv can already destroy the checked item depending on a flag - altar should be extend to accept a 'delay' or event to be triggered - teleporter and other thingies interacting with object 'on top of them' should be extended to restrict the object they can interact on - mover should be triggerable if not yet done, and should also be modified to accept some 'filter' to apply to objects it apply to (same as teleporter above). Rapha?l Quinet wrote: > Unless I am mistaken, there is no arch that can act as the opposite of the > "creator" arch. Or at least I could not find one. The "creator" creates a > new object when it is triggered. I would like to have a "destructor" that > can remove a specific object when it is triggered. If such a thing does not > exist yet, I would like to create it. > > Here are several cases in which a "destructor" could be useful: > - A detector/check_inv connected to a destructor can have the same effect > as an altar, except that it is possible to introduce a delay between > dropping the item and destroying it (using the well-known hidden machinery > with spikes and boulders or other objects), or to add additional > conditions such as requiring the player to move away from the altar before > the sacrifice is accepted. > - With a creator and a destructor at the same location, it would be possible > to make some object appear or disappear using the appropriate triggers. > Same effect can be achieved with a pair of teleporters > - The creation/destruction could be done in a cyclic way (using external > machinery providing the timers). This could be fun if the blinking object > is a light source. > - If the object that is created/destroyed is a mover, it would be possible > to make some NPCs follow some specific paths and stop or go depending on > the actions of the player: create the movers when the NPC should move, > then destroy them afterwards. > I think you can 'trigger' the mover, but not sure. > - A destructor can also be used to make the NPC fetch and accept a gift: > detect that a gift has been dropped (standard detector), move the NPC > towards the player (creators + movers), then destroy the gift once the NPC > is close to the player (destructor). > > The existing archetypes that could serve similar purposes are the altars and > teleporters. The problem with the altars is that they work as soon as the > object is dropped and cannot be triggered by some other event. The > teleporters can be triggered via some external action and are used in some > maps to move objects out of the visible map, but this is not a very good > solution because these teleporters are not very selective about what they > teleport (so you may end up teleporting the wrong object). > > So if nobody can suggest a better solution, I will write the code for this > new archetype because I already have some maps (alchemy quests) in which I > would like to use "destructors" for NPC movement and actions. My current > plan is to have something very similar to the "creator" (including the > parameters such as the "slaying" field, the number of uses, etc.) except that > it would do exactly the opposite of the creator. > > -Rapha?l > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From raphael at gimp.org Mon Jun 12 13:50:47 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 12 Jun 2006 20:50:47 +0200 Subject: [crossfire] destructor archetype? In-Reply-To: <1150122491.20848.17.camel@localhost.localdomain> References: <20060612161437.5a4fc3d0.raphael@gimp.org> <1150122491.20848.17.camel@localhost.localdomain> Message-ID: <20060612205047.6ec81a2b.raphael@gimp.org> On Mon, 12 Jun 2006 16:28:11 +0200, Wim Villerius wrote: > Seems you're mistaken ;-) > > see the attached file for an example use of 'destructors' (or rather: > using a duplicator as a destructor by setting the multiply factor to > zero) Yes. About one hour after posting my message (while I was off the 'net), I discovered that the duplicator could be used as a "destructor" by setting the factor to 0. How could I miss something that obvious? :-) So you can forget about what I wrote in my previous message. I will not implement this new archetype if the functionality is already there. I have already started using the duplicator/destructor in my maps... -Rapha?l From raphael at gimp.org Mon Jun 12 14:03:27 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 12 Jun 2006 21:03:27 +0200 Subject: [crossfire] destructor archetype? In-Reply-To: <448D7CAB.4030009@myrealbox.com> References: <20060612161437.5a4fc3d0.raphael@gimp.org> <448D7CAB.4030009@myrealbox.com> Message-ID: <20060612210327.598a481e.raphael@gimp.org> On Mon, 12 Jun 2006 16:39:39 +0200, Tchize wrote: > Hi, > looking at your mail, if think several things need improvement and might > be worth a RFE > - creator should be extended to behave the opposite way depending on a flag This is probably not necessary if the duplicator can already do that. Having a flag in the creator would be more discoverable (at least I think that I would have found it much faster) but I do not know if it is worth the trouble. > - note the chek_inv can already destroy the checked item depending on a flag Sure. However, like the altar, the check_inv can only trigger an event and cannot be triggered (which is what I was looking for). > - altar should be extend to accept a 'delay' or event to be triggered I think that the duplicator can already handle all cases in which an altar with a delay or external trigger could be used. > - teleporter and other thingies interacting with object 'on top of them' > should be extended to restrict the object they can interact on Yes. Teleporters could use "other_arch". > - mover should be triggerable if not yet done, and should also be > modified to accept some 'filter' to apply to objects it apply to (same > as teleporter above). Yes, both of these could be useful: "connected" and "other_arch". Movers could also use the "slaying" field if we want to filter on other things than the archetype, such as the object's name. -Rapha?l From alex_sch at telus.net Mon Jun 12 17:47:18 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 12 Jun 2006 16:47:18 -0600 Subject: [crossfire] destructor archetype? In-Reply-To: <448D7CAB.4030009@myrealbox.com> References: <20060612161437.5a4fc3d0.raphael@gimp.org> <448D7CAB.4030009@myrealbox.com> Message-ID: <448DEEF6.6010802@telus.net> Tchize wrote: > - mover should be triggerable if not yet done, and should also be > modified to accept some 'filter' to apply to objects it apply to (same > as teleporter above). I already implemented a filter on both movers and directors and that has been in CVS for a while. It is capable of searching any combination of arch, name, and/or race via a bitmask. Here's a quote from my documentation in doc/Developers/object: subtype: a bitmask that specifies which of arch, name, and race affect the race and slaying flags. If unspecified (or zero), all will be searched. The LSB is arch, the next bit is name, and the third bit is for race. Table for the lazy: subtype 1: only arch subtype 2: only name subtype 3: arch or name subtype 4: only race subtype 5: arch or race subtype 6: name or race subtype 7: all three race: only affect objects with a arch/name/race matching this. slaying: don't affect objects with a arch/name/race matching this. Alex Schultz From mwedel at sonic.net Sat Jun 17 22:43:12 2006 From: mwedel at sonic.net (mwedel at sonic.net) Date: Sat, 17 Jun 2006 20:43:12 -0700 (PDT) Subject: [crossfire] destructor archetype? In-Reply-To: <20060612161437.5a4fc3d0.raphael@gimp.org> References: <20060612161437.5a4fc3d0.raphael@gimp.org> Message-ID: <12449.71.32.138.59.1150602192.squirrel@webmail.sonic.net> Couple quick thoughts on this: Rather than using a flag to denote 'destructor' abilities, I think it would be better to make it a subtype. In fact, in an ideal world, anything that looks for objects being dropped on the space would have the same object type, but then different subtypes based on what it does (duplicate, destroy, sacrifice, etc). In that way, the 'check if on space' logic becomes the same for all the objects, which is probably a good thing and would simplify the code, and documentatin becomes 'if subtype is ABC, it does this, using these fields'. From mwedel at sonic.net Sat Jun 17 22:51:14 2006 From: mwedel at sonic.net (mwedel at sonic.net) Date: Sat, 17 Jun 2006 20:51:14 -0700 (PDT) Subject: [crossfire] destructor archetype? In-Reply-To: <448D7CAB.4030009@myrealbox.com> References: <20060612161437.5a4fc3d0.raphael@gimp.org> <448D7CAB.4030009@myrealbox.com> Message-ID: <20095.71.32.138.59.1150602674.squirrel@webmail.sonic.net> > - altar should be extend to accept a 'delay' or event to be triggered Arguably, most objects that check for inventory or otherwise operate should have the ability to specify a delay. However, I'm not sure the best way to do it. The object doing the checking could be set to have some speed based on the delay, and then turn it off when it does it action (eg, speed 0.5 basically amounts to a delay of 2 ticks). That basically works, except for checkers that already have a speed and only check when they get an action (like many teleporters). An alternative method would be for the checker to create a force like object, put it into its inventory and give that the speed. That force would then expire at some time, at which point it does the action (ideally the force has all the info it needs to do operation, so the same force logic could be used for a bunch of different checkers) From nicolas.weeger at laposte.net Sat Jun 24 05:53:42 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 24 Jun 2006 12:53:42 +0200 Subject: [crossfire] requestable party lists In-Reply-To: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> References: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> Message-ID: <200606241253.43025.nicolas.weeger@laposte.net> Hello. > I have uploaded a patch to the sourceforge tracker which forms an > initial proposal for requestable party lists. > > https://sourceforge.net/tracker/index.php?func=detail&aid=1475202&group_id= >13833&atid=313833 This patch has been opened for some time, and didn't receive much flame, just a few comments :) Should I commit it? Nicolas From mwedel at sonic.net Sun Jun 25 00:21:01 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 24 Jun 2006 22:21:01 -0700 Subject: [crossfire] requestable party lists In-Reply-To: <200606241253.43025.nicolas.weeger@laposte.net> References: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> <200606241253.43025.nicolas.weeger@laposte.net> Message-ID: <449E1D3D.2070508@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > >> I have uploaded a patch to the sourceforge tracker which forms an >> initial proposal for requestable party lists. >> >> https://sourceforge.net/tracker/index.php?func=detail&aid=1475202&group_id= >> 13833&atid=313833 > > This patch has been opened for some time, and didn't receive much flame, just > a few comments :) > Should I commit it? I don't see any real problems with it. From mwedel at sonic.net Sun Jun 25 00:39:56 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 24 Jun 2006 22:39:56 -0700 Subject: [crossfire] Quest management system proposal In-Reply-To: <200606100932.16899.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <448A6F69.5010501@sonic.net> <200606100932.16899.nicolas.weeger@laposte.net> Message-ID: <449E21AC.1000407@sonic.net> Nicolas Weeger (Laposte) wrote: >> Having the server of a plugin 'patch' objects loaded from the map itself >> seems to me to be a pretty horrible hack. I know from a debugging side of >> thing, having a bug with an object in some odd state, and not even being >> sure how it got that way is a pain. This also seems to be pretty >> problematic in terms of specific objects on specific maps (the NPC that >> gives out the quest info, for example). > > Just a precision: not talking about "patching" / "modifying" objects, just > adding event handlers in inventory. Which is still patching/modifying objects. Perhaps not in a huge way, but still, to me, it would seem better for the object in the map to be modified, and not have post processing done later. Some of this concern may be unwarranted, but I always fear the 'its only plugins now, but down the road, it could be other things modified, like say msg/endmsg data'. And even with just plugins, there is always the potential that the object might be modified to have that event set. What happens then when the loader wants to use that same event for a different script. I still think it would be better for the script control file to mention the different objects (map, x,y) that are tied to the quest, but actually have the objects modified in the map. That is simpler (all the code to handle that already exists) and prevents possible problems. The only disadvantage is that if someone wants to disable a quest, there are now a bunch of objects to modify in maps. However, that really isn't any different than things are right now with most of the basic quests out there (to disable them would mean removing maps, modifying them, whatever). But one thought on this to make it eaiser - in the quest control file, you could have some line like: bunch of quest related to delivering a message message_delivery_quest_enable=1 (or 0 to disable it) So instead of having to comment a bunch of lines out, it is just one line to change (and in fact, may make sense to have 2 files - one with all the quest related info, and another that describes if the quests are enabled or not - in this way, just a quick perusal of one file to decide what to enable/disable. I think the scripts could pretty easily be modified to have something like 'if quest_enabled(message_delivery)==0 { do nothing}' This does mean that the scripts may be getting called unneccessary, but I don't think that is a big deal. As I think about it, having such checks could be really nice. I could envision an NPC that wants a dozen things delivered. The script is in place to handle all those different things. Instead of having an all or nothing for that npc, those different quests could be enabled/disabled, and the scripting language can check for that. > >> In terms of script language, I think that is almost a different >> discussion - if python isn't sufficient or overly bloated, and we should >> move to something else, we should do that, but I don't think that should be >> an immediate design concern either. >> >> I forsee that if lua (or other language) is added as a quest specific >> script language, it wouldn't be long before it probably would turn into a >> full blown scripting language. > > Yes, that's another discussion :) > But for instance Windows users don't always have Python installed, thus > requiring it needs adding and maintaining links to Python packages, things > like that. But if that is the issue, then requiring that python be installed I think would be perfectly reasonable. Or if python isn't available, then of course none of the quests are available. I don't particularly think we should base design on having people who run a server to install some software. If they want to run a server, they should be able to go through and install that software - it shouldn't be very hard. If they don't want to, then don't run the server. From nicolas.weeger at laposte.net Sun Jun 25 09:56:21 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 25 Jun 2006 16:56:21 +0200 Subject: [crossfire] Attribution for patches Message-ID: <200606251656.22067.nicolas.weeger@laposte.net> Hello. There was some exchange with Schmorp on IRC. He claims we copied patches/things from CF+ without any attribution. Anyone remembers one/more patch/pic/map we got/copied from Schmorp for which we didn't attribute correctly, so we could fix that mistake? Nicolas From alex_sch at telus.net Sun Jun 25 10:52:41 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 25 Jun 2006 09:52:41 -0600 Subject: [crossfire] Attribution for patches In-Reply-To: <200606251656.22067.nicolas.weeger@laposte.net> References: <200606251656.22067.nicolas.weeger@laposte.net> Message-ID: <449EB149.1060407@telus.net> Nicolas Weeger (Laposte) wrote: >Hello. > >There was some exchange with Schmorp on IRC. He claims we copied >patches/things from CF+ without any attribution. > >Anyone remembers one/more patch/pic/map we got/copied from Schmorp for which >we didn't attribute correctly, so we could fix that mistake? > Everything I know of, is attributed in the cvs commit comments, however I am not sure he is aware of them or considers them proper attribution. Alex Schultz From nicolas.weeger at laposte.net Sun Jun 25 11:35:07 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 25 Jun 2006 18:35:07 +0200 Subject: [crossfire] Attribution for patches In-Reply-To: <449EB149.1060407@telus.net> References: <200606251656.22067.nicolas.weeger@laposte.net> <449EB149.1060407@telus.net> Message-ID: <200606251835.07941.nicolas.weeger@laposte.net> > Everything I know of, is attributed in the cvs commit comments, however > I am not sure he is aware of them or considers them proper attribution. There are AFAIK 4 patches on the tracker (closed, by elmex), and they all got (what i deem) proper attribution in the Changelog ("courtesy CF+ development team" or equivalent). Nicolas From mwedel at sonic.net Mon Jun 26 02:39:43 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 26 Jun 2006 00:39:43 -0700 Subject: [crossfire] Attribution for patches In-Reply-To: <200606251835.07941.nicolas.weeger@laposte.net> References: <200606251656.22067.nicolas.weeger@laposte.net> <449EB149.1060407@telus.net> <200606251835.07941.nicolas.weeger@laposte.net> Message-ID: <449F8F3F.20508@sonic.net> Nicolas Weeger (Laposte) wrote: >> Everything I know of, is attributed in the cvs commit comments, however >> I am not sure he is aware of them or considers them proper attribution. > > There are AFAIK 4 patches on the tracker (closed, by elmex), and they all got > (what i deem) proper attribution in the Changelog ("courtesy CF+ development > team" or equivalent). Which IMO is fine (and in fact, I just did something like this). I suppose what they could be wanting is that in the code itself (where the patch/change is located) to have an attribution (fix to prevent crashing here courtesy of schmorp). That has never been the practice in crossfire before (there are some places that sort of happens, but more to describe the behavior of the code, and the author of the change put their name in place). I personally think the code would become very cluttered with comments if this is done. And then you get the case that the attribution itself is bigger than the change itself. Some number of bugs are single line fixes (or a variable/value within the line) - to include attribution for those types of changes seems silly. From alex_sch at telus.net Mon Jun 26 10:40:39 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 26 Jun 2006 09:40:39 -0600 Subject: [crossfire] Attribution for patches In-Reply-To: <449F8F3F.20508@sonic.net> References: <200606251656.22067.nicolas.weeger@laposte.net> <449EB149.1060407@telus.net> <200606251835.07941.nicolas.weeger@laposte.net> <449F8F3F.20508@sonic.net> Message-ID: <449FFFF7.9080203@telus.net> Mark Wedel wrote: > I suppose what they could be wanting is that in the code itself (where the >patch/change is located) to have an attribution (fix to prevent crashing here >courtesy of schmorp). > > That has never been the practice in crossfire before (there are some places >that sort of happens, but more to describe the behavior of the code, and the >author of the change put their name in place). > > I personally think the code would become very cluttered with comments if this >is done. And then you get the case that the attribution itself is bigger than >the change itself. Some number of bugs are single line fixes (or a >variable/value within the line) - to include attribution for those types of >changes seems silly. > And if someone does want to look up a particular line or part, the cvs logs are where they would go, and that does include proper attribution, hence even if someone did want that granularity of attribution, the cvs logs do the job well. Alex Schultz From fuchs.andy at gmail.com Mon Jun 26 12:59:15 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 26 Jun 2006 13:59:15 -0400 Subject: [crossfire] Attribution for patches In-Reply-To: <449FFFF7.9080203@telus.net> References: <200606251656.22067.nicolas.weeger@laposte.net> <449EB149.1060407@telus.net> <200606251835.07941.nicolas.weeger@laposte.net> <449F8F3F.20508@sonic.net> <449FFFF7.9080203@telus.net> Message-ID: I'm thinking that a policy should be made, and put up somewhere. Possibly use these main points: - commiter SHOULD attribute in cvs commit message. - someone WILL attribute in the changelog (one with the code, not the one cvs keeps) - unless it is a huge change, do not expect attribution in the form of a comment in the code - if you feel that something was improperly attributed, bring it up on the mailing list to get it fixed -- Andrew Fuchs From leaf at real-time.com Mon Jun 26 13:38:26 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 26 Jun 2006 13:38:26 -0500 Subject: [crossfire] Attribution for patches In-Reply-To: References: <200606251656.22067.nicolas.weeger@laposte.net> <449EB149.1060407@telus.net> <200606251835.07941.nicolas.weeger@laposte.net> <449F8F3F.20508@sonic.net> <449FFFF7.9080203@telus.net> Message-ID: <44A029A2.6050703@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Fuchs wrote: > > - if you feel that something was improperly attributed, bring it up > on the mailing list to get it fixed I would suggest the following as well: When making such a request to the mailing list, please be sure to include a reference & details to the exact checkin(s) in question. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEoCmhhHyvgBp+vH4RAv2JAJ4lJm5Ie8WgETUq0icUhaBgcBn8OgCZAS/r RdtHomJJDexumwhdHjwyWOk= =oDWU -----END PGP SIGNATURE----- From leaf at real-time.com Mon Jun 26 14:06:04 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 26 Jun 2006 14:06:04 -0500 Subject: [crossfire] Easy House map set - missing easy_house.1.a in CVS In-Reply-To: References: Message-ID: <44A0301C.1010702@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Crossfire CVS repository messages. wrote: > > Modified Files: > maps-bigworld/world: world_105_116 > Added Files: > maps-bigworld/scorn/houses: easy_house.1.b easy_house.1.c > > Log Message: > Add new easy house maps. A map was missed with this checkin - easy_house.1.a I can provide the file if necessary; it would appear that the mailing list[1] archive didn't (or doesn't) save message attachments. [1] - http://sourceforge.net/mailarchive/message.php?msg_id=17137298 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEoDAbhHyvgBp+vH4RAop9AKC48URBYvxmApTZh88G5xbefbYExACggXM2 gQfR4t7g7bAf6PumMNCORD8= =vANq -----END PGP SIGNATURE----- From brenlally at gmail.com Mon Jun 26 17:32:29 2006 From: brenlally at gmail.com (Brendan Lally) Date: Mon, 26 Jun 2006 23:32:29 +0100 Subject: [crossfire] requestable party lists In-Reply-To: <200606241253.43025.nicolas.weeger@laposte.net> References: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> <200606241253.43025.nicolas.weeger@laposte.net> Message-ID: <7903f03c0606261532l17eea165n733e842b5cb66252@mail.gmail.com> On 6/24/06, Nicolas Weeger (Laposte) wrote: > Hello. > > > I have uploaded a patch to the sourceforge tracker which forms an > > initial proposal for requestable party lists. > > > > https://sourceforge.net/tracker/index.php?func=detail&aid=1475202&group_id= > >13833&atid=313833 > > This patch has been opened for some time, and didn't receive much flame, just > a few comments :) > Should I commit it? Honestly, I don't recall what needs done with this, I have been meaning to go back and finish it for a while, but haven't had the time to do so. I seem to remember it worked whilst I was testing it, but this doesn't mean it is of quality suitable for inclusion in CVS as is (and indeed it probably isn't) I'd like to be able to say that I would definatly get the time to sit down and finish this in the next week or so, but I can't honestly claim that to be the case. From nicolas.weeger at laposte.net Tue Jun 27 12:00:57 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 27 Jun 2006 19:00:57 +0200 Subject: [crossfire] requestable party lists In-Reply-To: <7903f03c0606261532l17eea165n733e842b5cb66252@mail.gmail.com> References: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> <200606241253.43025.nicolas.weeger@laposte.net> <7903f03c0606261532l17eea165n733e842b5cb66252@mail.gmail.com> Message-ID: <200606271900.57450.nicolas.weeger@laposte.net> > I'd like to be able to say that I would definatly get the time to sit > down and finish this in the next week or so, but I can't honestly > claim that to be the case. Ok, guess I'll wait for your clearance before committing :) Nicolas From nicolas.weeger at laposte.net Tue Jun 27 12:04:20 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 27 Jun 2006 19:04:20 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <449E21AC.1000407@sonic.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200606100932.16899.nicolas.weeger@laposte.net> <449E21AC.1000407@sonic.net> Message-ID: <200606271904.20281.nicolas.weeger@laposte.net> > Which is still patching/modifying objects. Perhaps not in a huge way, > but still, to me, it would seem better for the object in the map to be > modified, and not have post processing done later. > > Some of this concern may be unwarranted, but I always fear the 'its only > plugins now, but down the road, it could be other things modified, like say > msg/endmsg data'. Well, for quest to work correctly, quest system will need to "override" current NPC system anyway, I think. So extend the syntax, to add quest-dependant information, probably. > I still think it would be better for the script control file to mention > the different objects (map, x,y) that are tied to the quest, but actually > have the objects modified in the map. That is simpler (all the code to > handle that already exists) and prevents possible problems. Possibly. In which case quest system should check item still exists at map loading :) > I don't particularly think we should base design on having people who run > a server to install some software. If they want to run a server, they > should be able to go through and install that software - it shouldn't be > very hard. If they don't want to, then don't run the server. True. But remember, for Windows for instance, it isn't as easy to compile the server. So people will need a specific Python version, leading to possible collisions with required versions for other things. But globally I agree. People want all features? Then install what's required :) I think someday I'll just, if I can find the willpower, start coding, keeping all that in head, and change during the course of different versions :) Nicolas From kirschbaum at myrealbox.com Tue Jun 27 15:41:40 2006 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue, 27 Jun 2006 22:41:40 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20060627204139.GA8200@localhost.localdomain> Crossfire CVS repository messages. wrote: > Module Name: crossfire > Committed By: ryo_saeba > Date: Sat Jun 24 10:41:44 UTC 2006 > > Modified Files: > crossfire: ChangeLog > crossfire/common: object.c > > Log Message: > Fix merging bug. [...] > + common/object.c: don't consider FLAG_INV_LOCKED for can_merge. This definitely is not a "bug" but a feature (see my previous ChangeLog entry "Do not merge locked and unlocked items." from 2006-06-01). In fact, we (mwedel, gros and me IIRC) did agree (on IRC) that locked items should not merge. The reason is that a player normally locks the gear he regularly uses. This includes items (rings/armour/weapons/cloaks/etc.) which are only temporarily worn/wielded. The previous (and now again active) behavior makes the character accumulate locked items. If you do not always watch your items, you end with multiple copies of locked items in your inventory. This normally is not intended since it adds useless weight to your character. (This argument maybe does not hold that much for dragon players for their lack of usable items, but my human character(s) usually have more than 50(!) locked items in inventory. Thus it is virtually impossible to notice such unintentionally merged items.) From nicolas.weeger at laposte.net Tue Jun 27 16:00:18 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 27 Jun 2006 23:00:18 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20060627204139.GA8200@localhost.localdomain> References: <20060627204139.GA8200@localhost.localdomain> Message-ID: <200606272300.19042.nicolas.weeger@laposte.net> > This definitely is not a "bug" but a feature (see my previous ChangeLog > entry "Do not merge locked and unlocked items." from 2006-06-01). Oh, didn't remember that :) Sorry, noticed the behaviour changed, and just assumed was a bug introduced by mistake. I'll have tp change how i do alchely, then ;) Nicolas From tchize at myrealbox.com Wed Jun 28 02:10:03 2006 From: tchize at myrealbox.com (Tchize) Date: Wed, 28 Jun 2006 09:10:03 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20060627204139.GA8200@localhost.localdomain> References: <20060627204139.GA8200@localhost.localdomain> Message-ID: <44A22B4B.9080808@myrealbox.com> Andreas Kirschbaum wrote: > Crossfire CVS repository messages. wrote: > >> Module Name: crossfire >> Committed By: ryo_saeba >> Date: Sat Jun 24 10:41:44 UTC 2006 >> >> Modified Files: >> crossfire: ChangeLog >> crossfire/common: object.c >> >> Log Message: >> Fix merging bug. >> > [...] > >> + common/object.c: don't consider FLAG_INV_LOCKED for can_merge. >> > > This definitely is not a "bug" but a feature (see my previous ChangeLog > entry "Do not merge locked and unlocked items." from 2006-06-01). > Guess i need to add this to unit test for future :) From mwedel at sonic.net Thu Jun 29 00:35:17 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 28 Jun 2006 22:35:17 -0700 Subject: [crossfire] Attribution for patches In-Reply-To: <44A029A2.6050703@real-time.com> References: <200606251656.22067.nicolas.weeger@laposte.net> <449EB149.1060407@telus.net> <200606251835.07941.nicolas.weeger@laposte.net> <449F8F3F.20508@sonic.net> <449FFFF7.9080203@telus.net> <44A029A2.6050703@real-time.com> Message-ID: <44A36695.5010607@sonic.net> Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Fuchs wrote: >> - if you feel that something was improperly attributed, bring it up >> on the mailing list to get it fixed > > I would suggest the following as well: > > When making such a request to the mailing list, please be sure to > include a reference & details to the exact checkin(s) in question. All of that looks good to me. From mwedel at sonic.net Thu Jun 29 00:45:07 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 28 Jun 2006 22:45:07 -0700 Subject: [crossfire] code cleanup commit. In-Reply-To: <4485485D.9040506@myrealbox.com> References: <4483D6D1.4050405@sonic.net> <200606052254.39970.nicolas.weeger@laposte.net> <448509C1.8060304@sonic.net> <4485485D.9040506@myrealbox.com> Message-ID: <44A368E3.1030407@sonic.net> Tchize wrote: > Sorry, jumping in Thread a bit late. > > I have quite a few experience with logging mecanism, here is my suggestion > > Arrange log entries in a hierarchy (scopes) like is done in java logging > mecanisms: > > example: > common.object (for everything related to object) > > Provide different levels of logging > (idea: finest, fine, info, warning, error, critical), default visible > level would be info > > Then you can say in config (or command line) > default=warning > common.object=finest > server.monster=finest > server=info > random_maps=info > socket=info > > > Provide with the possibility to check if a specific level is enabled > if (loglevel_enabled(scope,LOG_FINEST)){ > /* do very complex operations here that can not be easily resumed in > a function call */ > /* optionally at end issue a log call */ > LOG(scope,LOG_FINEST,result_of_complex_logging_operations) > } > > Use also as information the line,file,function information, as > preprocessor provide them , but do not use them for filtering, use them > only when analysing a log to know where a problem occurs That all looks good. But one question this - is it possible for a single log method to belong to several categories? I can see lots of things within the game where it is a question of 'is this a map related log message? object? monster?' Since they all interact, it becomes tricky. I suppose this could perhaps get sorted out by clearly defining what categories something should be logged based on the operation in question. And I agree that log statements should generally always be enabled. But often times, if you look at the log messages, the detail is just way too much to enable them all, even within a category, unless subcategories are defined or there are lots of category. A case I can think of here is the socket stuff. I could see that if I'm writing a new socket command, I may want to have lots of logging info (at most detailed level) on what is going on. But I don't want that high level of logging for the rest of the socket code (item, map, whatever else) as it then likely makes it too hard for me to find my own log information (oftentimes, you want to see those log messages as the program is running, not to look over the logs after the run). So I'm not sure how to best handle that. I do agree that if there are portable logging solutions already out there, that it makes sense to use them vs writing out own. From tchize at myrealbox.com Thu Jun 29 03:07:08 2006 From: tchize at myrealbox.com (Tchize) Date: Thu, 29 Jun 2006 10:07:08 +0200 Subject: [crossfire] code cleanup commit. In-Reply-To: <44A368E3.1030407@sonic.net> References: <4483D6D1.4050405@sonic.net> <200606052254.39970.nicolas.weeger@laposte.net> <448509C1.8060304@sonic.net> <4485485D.9040506@myrealbox.com> <44A368E3.1030407@sonic.net> Message-ID: <44A38A2C.6060705@myrealbox.com> In fact, That's somehow a bad idea to want some kind of multicategories logs. At the moment you write you code and decide to put some logging inside it, you must know exactly where this log call belongs to. Let's assume you know a specific log message X at a specific place in code belongs to 'map handling and monster handling', you write your log call with categories 'map & monster'. 6 month later, someone decide we need an additional category for everything related to Traps, perhaps because we have lots of traps issue (just an example). You have to go thru all the code, analyse all the log calls and for each of them decide if you want to add the Traps category. Nobody will do it, and it will end up in a state where not all logs call that should go in a specfic category are in it. Moreover, everytime someone will want to write a log call , he will have to scrap his head to list the categories it should fit in. At that time there are 2 possibilities - either he does it fast and quickly decide what categories it is in -> you end up with hih risk to forget some of them - either he does it the slow way an check everyt category to see if it fits in -> you end up with a bored coder and a risk for a log call to be in too much categorie Last but not least, with a categories system, you still have the risk to be over informed when you enable the category, so much log call will be enabled when you enable a category you risk to have so much information that you can't find what you need inside. On the other hand, if you assume a log hierarchy, like this one crossfire.objects.monster.movement crossfire.objects.player.movement crossfire.map.load you can * enable everything related to object manipulation as a whole * enable everything related to monster handling * enable everything related to maps * enable everything related to crossfire :p Last but not least, i point you to this: http://log4c.sourceforge.net/ according to their mailing list there has been success in compiling for windows too, it might be worth an attempt by a window guy and a linux guy to see if we can use this a crossfplatform way (either as a lib, either incode). On last ressort we probably can also try to map log4cpp Mark Wedel wrote: > Tchize wrote: > >> Sorry, jumping in Thread a bit late. >> >> I have quite a few experience with logging mecanism, here is my suggestion >> >> Arrange log entries in a hierarchy (scopes) like is done in java logging >> mecanisms: >> >> example: >> common.object (for everything related to object) >> >> Provide different levels of logging >> (idea: finest, fine, info, warning, error, critical), default visible >> level would be info >> >> Then you can say in config (or command line) >> default=warning >> common.object=finest >> server.monster=finest >> server=info >> random_maps=info >> socket=info >> >> >> Provide with the possibility to check if a specific level is enabled >> if (loglevel_enabled(scope,LOG_FINEST)){ >> /* do very complex operations here that can not be easily resumed in >> a function call */ >> /* optionally at end issue a log call */ >> LOG(scope,LOG_FINEST,result_of_complex_logging_operations) >> } >> >> Use also as information the line,file,function information, as >> preprocessor provide them , but do not use them for filtering, use them >> only when analysing a log to know where a problem occurs >> > > That all looks good. But one question this - is it possible for a single log > method to belong to several categories? > > I can see lots of things within the game where it is a question of 'is this a > map related log message? object? monster?' Since they all interact, it > becomes tricky. > > I suppose this could perhaps get sorted out by clearly defining what > categories something should be logged based on the operation in question. > > And I agree that log statements should generally always be enabled. But often > times, if you look at the log messages, the detail is just way too much to > enable them all, even within a category, unless subcategories are defined or > there are lots of category. > > A case I can think of here is the socket stuff. I could see that if I'm > writing a new socket command, I may want to have lots of logging info (at most > detailed level) on what is going on. But I don't want that high level of > logging for the rest of the socket code (item, map, whatever else) as it then > likely makes it too hard for me to find my own log information (oftentimes, you > want to see those log messages as the program is running, not to look over the > logs after the run). > > So I'm not sure how to best handle that. > > I do agree that if there are portable logging solutions already out there, > that it makes sense to use them vs writing out own. > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From mwedel at sonic.net Fri Jun 30 00:48:43 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 29 Jun 2006 22:48:43 -0700 Subject: [crossfire] race/class lacks distinctions Message-ID: <44A4BB3B.5070709@sonic.net> It has long been discussed that with a few exception (the non humanoid races and the classes that prohibit weapons/armors), a lot of race/classes tend to blur together. There are several reasons for this: - There are not really any race/class restrictions for objects (or conversely, not any objects that only clerics can use, or that only fighters can use, etc). While there is a 'ring of the paladin', you don't need to be a paladin to use it for example. - Pretty much all the skills are learnable, so what skills you start out with are not very important - you can learn everything else later. - Most differences in stats can be overcome fairly easily by use of items that improve your stats. In terms of these issues, I think the first could be fixed by adding new items and a little code - use a key/value to store what class/race can use an object, and add some code in the apply logic to check for it. For the skills, my thought would be there should be different levels (for lack of better term) of skills. For example, there may be 4 different skills of sorcery - basic, expert, advanced, mastery. However, these all tie in with the same skill. The sorcery class starts with the mastery skill. Some of the other classes (if they get several casting skills) maybe get those at advanced. Skill scrolls would give you basic skill, and perhaps quests or other harder to do things give you expert. What exactly these differences mean would have to be worked out. At a most basic level, it could determine the rate of exp you gain in the skill (basic gets 25% of normal or something). There could also be level caps - mastery caps at 110, advanced 75, expert 50, basic 25 (however, the fact there really aren't many spells above level 20, this may not mean a lot). Maybe for fighting skills, it means you get some extra hp (1/x skill levels?) Maybe only experts/masters get that bonus? Or get a better bonus? I think various cool bonuses for different skills could probably get worked out. But what this does it make your class selection more important - you can choose a wizard and really play them as a fighter - sure, you can still fight, but a person who plays a fighter will become a much better fighter. I don't really have any good solution to the stat problem - I don't think that is really solvable. From tchize at myrealbox.com Fri Jun 30 02:21:28 2006 From: tchize at myrealbox.com (Tchize) Date: Fri, 30 Jun 2006 09:21:28 +0200 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <44A4BB3B.5070709@sonic.net> References: <44A4BB3B.5070709@sonic.net> Message-ID: <44A4D0F8.6010305@myrealbox.com> Hello, This has also been discussed during the g2g night brainstormings. We have come up with an interesting way to circuvent the general problem of 'all character are the same at high level'. We applied a similar view to your 'different skill level' but better at the 'class' level. In essence, uou have class skills, and you get an artificial bonus level in the skills associated to the class. A character that has spend most of his life as a warrior, for example, has a 1 handed weapon level of, let's say, 100 and a class level of 80 granting him a +15 level bonus in one handed weapons. There are lots of other things around this, we went even further in this system to force player to priviledge some path of development and end up with different characters. It's quite an interresting idea, but i don't plan to explain this to mailing list for now, it will be detailed in the g2g meeting result document. I am waiting for the g2g attendees to revise the draft i wrote before publishing it. However, i hope to send to result document to the mailing list for mid-july. Mark Wedel wrote: > It has long been discussed that with a few exception (the non humanoid races > and the classes that prohibit weapons/armors), a lot of race/classes tend to > blur together. > > There are several reasons for this: > > - There are not really any race/class restrictions for objects (or conversely, > not any objects that only clerics can use, or that only fighters can use, etc). > While there is a 'ring of the paladin', you don't need to be a paladin to use > it for example. > > - Pretty much all the skills are learnable, so what skills you start out with > are not very important - you can learn everything else later. > > - Most differences in stats can be overcome fairly easily by use of items that > improve your stats. > > In terms of these issues, I think the first could be fixed by adding new items > and a little code - use a key/value to store what class/race can use an object, > and add some code in the apply logic to check for it. > > For the skills, my thought would be there should be different levels (for lack > of better term) of skills. > > For example, there may be 4 different skills of sorcery - basic, expert, > advanced, mastery. However, these all tie in with the same skill. > > The sorcery class starts with the mastery skill. Some of the other classes > (if they get several casting skills) maybe get those at advanced. Skill scrolls > would give you basic skill, and perhaps quests or other harder to do things give > you expert. > > What exactly these differences mean would have to be worked out. At a most > basic level, it could determine the rate of exp you gain in the skill (basic > gets 25% of normal or something). There could also be level caps - mastery caps > at 110, advanced 75, expert 50, basic 25 (however, the fact there really aren't > many spells above level 20, this may not mean a lot). > > Maybe for fighting skills, it means you get some extra hp (1/x skill levels?) > Maybe only experts/masters get that bonus? Or get a better bonus? > > I think various cool bonuses for different skills could probably get worked > out. But what this does it make your class selection more important - you can > choose a wizard and really play them as a fighter - sure, you can still fight, > but a person who plays a fighter will become a much better fighter. > > I don't really have any good solution to the stat problem - I don't think that > is really solvable. > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From alex_sch at telus.net Fri Jun 30 10:06:24 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 30 Jun 2006 09:06:24 -0600 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <44A4BB3B.5070709@sonic.net> References: <44A4BB3B.5070709@sonic.net> Message-ID: <44A53DF0.6070808@telus.net> Mark Wedel wrote: > It has long been discussed that with a few exception (the non humanoid races > and the classes that prohibit weapons/armors), a lot of race/classes tend to > blur together. > > There are several reasons for this: > > - There are not really any race/class restrictions for objects (or conversely, > not any objects that only clerics can use, or that only fighters can use, etc). > While there is a 'ring of the paladin', you don't need to be a paladin to use > it for example. > > - Pretty much all the skills are learnable, so what skills you start out with > are not very important - you can learn everything else later. > > - Most differences in stats can be overcome fairly easily by use of items that > improve your stats. > > In terms of these issues, I think the first could be fixed by adding new items > and a little code - use a key/value to store what class/race can use an object, > and add some code in the apply logic to check for it. > > For the skills, my thought would be there should be different levels (for lack > of better term) of skills. > > For example, there may be 4 different skills of sorcery - basic, expert, > advanced, mastery. However, these all tie in with the same skill. > > The sorcery class starts with the mastery skill. Some of the other classes > (if they get several casting skills) maybe get those at advanced. Skill scrolls > would give you basic skill, and perhaps quests or other harder to do things give > you expert. One little note, is personally I don't think any such quests should allow one to go beyond expert. Perhaps make one *extremely* high level quest that could only be done once per player, that would allow one skill of the player's choice to be put to advanced, but I think that nothing should ever allow one not in a class native to the skill, to advance to mastery, and advancing to advanced should be something that should be so rare, that a given character could only do once for one skill ever IMHO. > > What exactly these differences mean would have to be worked out. At a most > basic level, it could determine the rate of exp you gain in the skill (basic > gets 25% of normal or something). There could also be level caps - mastery caps > at 110, advanced 75, expert 50, basic 25 This seems like a good idea to me. > (however, the fact there really aren't > many spells above level 20, this may not mean a lot). This I believe is a separate problem, personally I think that both more spells are needed, and the level on many of them needs to be increased very significantly (i.e. meteor swarm I would put at level 50 to 60 or perhaps even higher, and would put comet around 30 or 40). Also, I think this is a rather important problem to deal with, though being a separate one from the rest of this post. > > Maybe for fighting skills, it means you get some extra hp (1/x skill levels?) > Maybe only experts/masters get that bonus? Or get a better bonus? > > I think various cool bonuses for different skills could probably get worked > out. But what this does it make your class selection more important - you can > choose a wizard and really play them as a fighter - sure, you can still fight, > but a person who plays a fighter will become a much better fighter. Little bonuses seem like a good idea to me, perhaps even allow those with a high level of pyromancery skill very small fire resist bonuses. Actually, a few times I have mentioned a little idea I had that was essentially the same as this, calling it a sort of, 'attunement for skills', as it would be sort of similar to spell attunements in some ways. Personally I think this idea is a very good one, and the details of your proposal I like better than the details of my old 'attunement for skills' idea. Also, I personally believe, that the skills need to be rebalanced such that there is not such a desire to want every skill. I believe these things would make classes actually matter, however I believe that too many maps and monsters, are vastly easier to do by spellcasting, or in some cases, vastly easier to do by melee. I believe there should be some variation, however I believe the variation currently would be too extreme once classes were made to matter. > > I don't really have any good solution to the stat problem - I don't think that > is really solvable. Well, adjusting or removing the stat limit of 30 would allow those base stat differences to matter more at higher levels, however doing that may cause more problems than it solves. Also, something I've saw some muds do, that might deal with that, is when one gains a level, randomly, some stats will increase depending on the class. Of course, those muds did have their stats on a different scale (starting stats ranged from 7 to 30 or so depending on race and class, with stats of the very very very high level players getting to like 500 even). Alex Schultz From mwedel at sonic.net Fri Jun 30 22:29:08 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 30 Jun 2006 20:29:08 -0700 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <44A53DF0.6070808@telus.net> References: <44A4BB3B.5070709@sonic.net> <44A53DF0.6070808@telus.net> Message-ID: <44A5EC04.5040507@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> For example, there may be 4 different skills of sorcery - basic, expert, >> advanced, mastery. However, these all tie in with the same skill. >> >> The sorcery class starts with the mastery skill. Some of the other classes >> (if they get several casting skills) maybe get those at advanced. Skill scrolls >> would give you basic skill, and perhaps quests or other harder to do things give >> you expert. > One little note, is personally I don't think any such quests should > allow one to go beyond expert. Perhaps make one *extremely* high level > quest that could only be done once per player, that would allow one > skill of the player's choice to be put to advanced, but I think that > nothing should ever allow one not in a class native to the skill, to > advance to mastery, and advancing to advanced should be something that > should be so rare, that a given character could only do once for one > skill ever IMHO. yes - getting advanced skills should not really be possible. I'm not sure a mechanism to prevent a player from only getting one master level skill. I suppose scripts could be used to store a value in the player denoting they have gotten it, and if so, then they can't get an expert skill (this would have to be tied to an NPC). But like everything in the maps, this sort of falls to the map developers. Just like it is up to standards that a good map shouldn't have ?ber items in it, etc. >> What exactly these differences mean would have to be worked out. At a most >> basic level, it could determine the rate of exp you gain in the skill (basic >> gets 25% of normal or something). There could also be level caps - mastery caps >> at 110, advanced 75, expert 50, basic 25 > This seems like a good idea to me. >> (however, the fact there really aren't >> many spells above level 20, this may not mean a lot). > This I believe is a separate problem, personally I think that both more > spells are needed, and the level on many of them needs to be increased > very significantly (i.e. meteor swarm I would put at level 50 to 60 or > perhaps even higher, and would put comet around 30 or 40). Also, I think > this is a rather important problem to deal with, though being a separate > one from the rest of this post. Yes, and also one that sort of breaks compatibility - you almost need to do a fresh server start. However, this reshuffling is still a little tricky. IIRC, the quest for the comet spell is a level 15 quest. If the comet becomes a level 30 spell, that is sort annoying - you do the quest, get a new spell, but can't use it for a really long time. > > Also, I personally believe, that the skills need to be rebalanced such > that there is not such a desire to want every skill. I believe these > things would make classes actually matter, however I believe that too > many maps and monsters, are vastly easier to do by spellcasting, or in > some cases, vastly easier to do by melee. I believe there should be some > variation, however I believe the variation currently would be too > extreme once classes were made to matter. That is also a different problem - balance of monsters. Some of this could probably be fixed by balancing the resistances of the monsters more - there are some monsters virtually impervious to melee because it can only be hit by one attacktype (you may be luck to have that attacktype in a weapon). However, spellcasters can almost have every attacktype, so it is just a matter of choosing the right spell. Monsters should get balanced better so sure, it may be easier to kill them via spells or weapon, but shouldn't be impossible to do so by the other method. But a lot is also the speed of combat. IMO, combat is often so fast that it is difficult to have much strategy. > >> I don't really have any good solution to the stat problem - I don't think that >> is really solvable. > Well, adjusting or removing the stat limit of 30 would allow those base > stat differences to matter more at higher levels, however doing that may > cause more problems than it solves. Also, something I've saw some muds > do, that might deal with that, is when one gains a level, randomly, some > stats will increase depending on the class. Of course, those muds did > have their stats on a different scale (starting stats ranged from 7 to > 30 or so depending on race and class, with stats of the very very very > high level players getting to like 500 even). But there is always some issue. If we say stats go up to 100, then a couple point swing at first level isn't likely to make much difference. You now need to make the differences for race/class like ?5. But even then, presumably the bonuses tend to get flattened out, so a +5 is like a +1 right now. It may mean a character has a 45 vs 40 strength based on race, but that may not mean a whole much. However, the idea of stat increases as you gain level is interesting. If we say stats go to 100, you could have some logic that each race has a difference balance on what stat will increase. Eg, for a troll, might be 75% that str, con, dex get increased (one of those), and 25% for the rest of the stats. Thus, a high level troll would have a high natural str, dex, and con, and still pretty crummy pow, wis, cha, int. If such a redoing of stats was done, would have to figure out how to deal with stat potions (maybe make it so that drinking one only has some % of increasing that stat or just do nothing, so same thing happy - if you play a fighter class/race, you will have good stats). Or maybe just make generic 'improve stat potions', which sort of act like what happens when you gain a level From mwedel at sonic.net Fri Jun 30 22:50:22 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 30 Jun 2006 20:50:22 -0700 Subject: [crossfire] player character creation/login redo. Message-ID: <44A5F0FE.2020502@sonic.net> Looking at the 2.0 TODO list: http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 (as an aside, I'd hope to make the 2.0 release by end of year, which might limit it to the 'High' and perhaps some 'medium' items on the list) One of the high priority items is character creation todo. That's been on the list for a long time, and I think is one of the best things to change for initial player experience. Below is basically my general outline. It doesn't go into the technical details much, but general flow. First, the client would have to negotiate that it uses the new login method - probably via setup. Client would prompt player for both name and password in a nice pop up box, which should display the motd and any other pre login information. The client would then send this information to the server in one packet. The server could then return 1 of 3 results: 1) login success, and loads the player up, starts playing with previously saved password. 2) invalid password - retry login. 3) no such player - go to new password creation method (ask player if he really wants to create a new character, confirm password). For new players, I see a pop up window with all the selections (stat adjustment, race & class selection). The client could get the available races and classes via requestinfo commands. For stats, I personally like the idea of giving the player X number of points to distribute between his stats. This removes the need to keep re-rolling until you get a good character, and after all, the client could be hacked to basically do that - re-roll until it gets the best character possible. The number of points would just be an option in the settings file, so easy to tune. (alternatively, stats could be rolled by the server, but instead of anything within a stat total range be valid, should always return characters that match the best). The player then makes his selections. When all done, they click done, and the client sends the selection back to the server (player is an elf fighter, stats ...). Play then begins at what is considered the starting map. I think this would provide the best experience, and at least for the gtkv2 client, wouldn't be hard to do that window in glade. I think this is much better than having an in-game mechanism of moving between maps, etc. For compatibility, the existing method can continue to be used for a while (until at least it seems to have been long enough that clients that support this new interface are widely used). This new method isn't requiring any information that isn't currently asked for - it is just providing a nicer interface (for that matter, if using the old logic, maybe you won't have a choice but to roll stats). This also has to me the following long term benefits: 1) the classes will need to be made fully stand along archetypes (if not already). I'm not sure if the current hall of selection map has customized archetypes. 2) All new player information is dynamically generated (stats from settings file, race from archetypes (same as right now), class from archetypes (not map). This means that new classes or other customizations can be easily made without needing to update maps. 3) This should lead to the eventual removal of the ST_ input states - shouldn't ever be a need for the server to have to wait for input of a specific nature for the client - the server can know if a player is logged in or not, but otherwise, it just gets a bulk of data (there might need to be the addition of some new Ns_.. socket states, but I'd rather have state data in only 1 place, not 2).