From nicolas.weeger at laposte.net Sat Dec 2 12:04:57 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 2 Dec 2006 19:04:57 +0100 Subject: [crossfire] Curse bug In-Reply-To: <45628E09.7060205@sonic.net> References: <200611170048.26753.nicolas.weeger@laposte.net> <200611202345.10196.nicolas.weeger@laposte.net> <45628E09.7060205@sonic.net> Message-ID: <200612021904.57136.nicolas.weeger@laposte.net> Reading fix_object (former fix_player), it seems to be there's a big mess waiting to happen (or already happened?) :) Basically, fix_object resets many many things, including all special flags (see in dark, stealth, ...), resistances, ... This means all those custom values will simply disappear whenever a monster will drink a potion, be hit by a curse or a disease, things like that :) Of course fix_object works fine when called with a player, but will horribly alter things for a customized monster. I can see a few possible fixes: * fix fix_object so it handles things correctly * don't call fix_object except when absolutely required. Recode eg curse to simply decrease wc, and restore it later when the force expires. Of course it's a mess with other things modifying wc * we could store all modified values so fix_object knows what to search for. An overkill solution is to temporarily create an artifact for each customized monster, and free it when monster diseappears. At first glance, I'd say we should create a temporarily artifact. It's the only way to be totally and definitely sure we never have any issue and keep all intended values - after all, at some point monsters will drink potions, or wear armor, or whatever. What do you think? Nicolas From nicolas.weeger at laposte.net Sat Dec 2 13:11:39 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 2 Dec 2006 20:11:39 +0100 Subject: [crossfire] Player file corruption In-Reply-To: <200610221911.14981.nicolas.weeger@laposte.net> References: <200610221911.14981.nicolas.weeger@laposte.net> Message-ID: <200612022011.39767.nicolas.weeger@laposte.net> > Fixing code should be easy, but fixing players will probably require a > script to strip the last_grace/last_sp/last_eat fields from players's > spells. Another messy option is to reset at loading fields, but i'm not > that eager to do that, as it's a ponctual fix... Ok, fixed the code by adding a structure storing spell state sent to server. Since this is an internal information, not stored, it'd be easy to change should the need arise. Now we should fix player files, so probably a script. Anyone feeling like doing that? :) Affected values that should be removed are last_grace, last_sp and last_eat Basically we should: * check maps for special spells with special values for those * strip information from player files, unless it's that special spell :) Note that spells which normally have such a field set will simply reset to normal value through the archetype being all right. Nicolas From mwedel at sonic.net Sun Dec 3 00:11:24 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 02 Dec 2006 22:11:24 -0800 Subject: [crossfire] Curse bug In-Reply-To: <200612021904.57136.nicolas.weeger@laposte.net> References: <200611170048.26753.nicolas.weeger@laposte.net> <200611202345.10196.nicolas.weeger@laposte.net> <45628E09.7060205@sonic.net> <200612021904.57136.nicolas.weeger@laposte.net> Message-ID: <45726A8C.8050000@sonic.net> Nicolas Weeger (Laposte) wrote: > Reading fix_object (former fix_player), it seems to be there's a big mess > waiting to happen (or already happened?) :) > > Basically, fix_object resets many many things, including all special flags > (see in dark, stealth, ...), resistances, ... > This means all those custom values will simply disappear whenever a monster > will drink a potion, be hit by a curse or a disease, things like that :) > Of course fix_object works fine when called with a player, but will horribly > alter things for a customized monster. > > I can see a few possible fixes: > * fix fix_object so it handles things correctly It's unclear how one can simply fix fix_object(), because as you describe, there are lots of values modified, so you basically need to know what those are (fix_object has to start with some baseline of what the initial values are supposed to be). > * don't call fix_object except when absolutely required. Recode eg curse to > simply decrease wc, and restore it later when the force expires. Of course > it's a mess with other things modifying wc Yes - especially if the monster has already been modified so some attributes are near maximums. Eg, if a creature has fire_resistance 100, anything that adds fire resistance won't have any effect. But if a player cast a fire resistance spell on the monster, when that spells ends, the monster still needs to have fire resistance 100 (you can't take away the resistance the spell would give). There may be osme other cases like that - the way the bonuses stack, max/worse bonuses (if wc is -120, nothing can improve it further, but if the monster unequips it, his wc should still be wc -120 if that is what the map set it to, etc). Plus, it means you have places all in the code to handle this. I suppose the right approach would be to have a function for applying/unapplying these force objects to the monster, but there are so many odd cases. > * we could store all modified values so fix_object knows what to search for. > An overkill solution is to temporarily create an artifact for each customized > monster, and free it when monster diseappears. Do you mean artifact or archetype? I'd think archetype would be easier - you could update op->arch with the new archetype (but really, you just chare about op->arch.clone). You could even store away the original archetype is op->arch.clone->arch This might be one of the simplest things to do - fix_player() really wouldn't need to be modified, because it already looks at op->arch for the initial starting values. What would need to be modified is the load code (to know when to create a new archtype) and the save code (need to go back to op->arch.clone->arch to get the differences, since the load code would go back to the original archetype for starting values). There is still a little complication - take this situation: Have modified monster, including say wc. Spell is cast on monster, modifying its wc Player leaves map, and map gets swapped out, so wc needs to be saved. You probably don't want to save the wc as modified by the spell, because then when the map is swapped back in, we no longer know what the original (modified) value is. You need to save the wc as specified in the original map (op->clone), and then when loaded back in, know to call fix_player() to get values back to normal (spell effect would be saved in the inventory, so doing this should get the same value back that was there before it was swapped out). That doesn't sound very complicated, but there are some values where you always want to save the op-> values and not the op->arch values (hp, sp, grace) - I'm not sure if there are any others - everything else I think could be derived from the temporary archetype values. One other complication is this: Standard orc on a map orc equips some armor map is swapped out - orc now has different AC So in this case, you once again want to do the same thing above - save the orcs original values and mark it to re-run fix_player() at load. Otherwise, it looks like a modified value, and you don't want to create an archetype from that. The extra memory for the archetypes isn't likely to be that big a deal - crossfire as it is right now doesn't use a whole lot of memory given how much memory modern systems have, and if limited to modified monsters, that is a pretty low impact. One other method that could be used to fix the problem: For modified monsters, instead of modifying the values and saving those values on the map, instead create a permanent force object with the modified values (or more likely, the values necessarily to modify the standard archetype to get the modified values). In this way, when fix_player() is called, it finds this archetype, and everything works out. That would require a lot of maps to be updated. Ideally, the editor would be modified so that this is invisible to the map designer - the problem here is that it means that the editor would have to have a lot of smarts (know how those values are calculated, etc). And if the method of calculation ever changes, or new things added, then that probably breaks that change. I think temporary archetype is really the best way to go. From nicolas.weeger at laposte.net Sun Dec 3 04:17:16 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 3 Dec 2006 11:17:16 +0100 Subject: [crossfire] Documentation / wiki In-Reply-To: <200611162304.49822.nicolas.weeger@laposte.net> References: <200611162304.49822.nicolas.weeger@laposte.net> Message-ID: <200612031117.17054.nicolas.weeger@laposte.net> As a test bed, I've put doc/Developers/objects on the wiki, you can see it at http://wiki.metalforge.net/doku.php/dev:objects (not yet totally formatted, and dokuwiki is running out of memory caching it sometimes :)) Does that look good? Nicolas From nicolas.weeger at laposte.net Sun Dec 3 05:50:07 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 3 Dec 2006 12:50:07 +0100 Subject: [crossfire] Show invisible behaviour Message-ID: <200612031250.07338.nicolas.weeger@laposte.net> Hello. With relation to bug https://sourceforge.net/tracker/index.php?func=detail&aid=1556723&group_id=13833&atid=113833 about broken show invisible, i've changed the behaviour for that spell: chance to show a hidden item is now (casting level-1) on (item's level). This just means monsters over 110 will never be shown :) If anyone has another idea, feel free to explain it ;) Nicolas From nicolas.weeger at laposte.net Sun Dec 3 06:09:28 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 3 Dec 2006 13:09:28 +0100 Subject: [crossfire] Curse bug In-Reply-To: <45726A8C.8050000@sonic.net> References: <200611170048.26753.nicolas.weeger@laposte.net> <200612021904.57136.nicolas.weeger@laposte.net> <45726A8C.8050000@sonic.net> Message-ID: <200612031309.28719.nicolas.weeger@laposte.net> > It's unclear how one can simply fix fix_object(), because as you > describe, there are lots of values modified, so you basically need to know > what those are (fix_object has to start with some baseline of what the > initial values are supposed to be). Agreed, not that easy to avoid, specially for resistances and such. > Eg, if a creature has fire_resistance 100, anything that adds fire > resistance won't have any effect. But if a player cast a fire resistance > spell on the monster, when that spells ends, the monster still needs to > have fire resistance 100 (you can't take away the resistance the spell > would give). Note that we may think later of "lower resistance"-type spells, which will need to tweak values, too. > Do you mean artifact or archetype? I'd think archetype would be easier - > you could update op->arch with the new archetype (but really, you just > chare about op->arch.clone). You could even store away the original > archetype is op->arch.clone->arch I did mean archetype, indeed :) > I think temporary archetype is really the best way to go. Me too. We'll have to take special care for loading/saving handling, though. Of course, players are easy because they are always starting from their archetype (and also we probably never load/save one) :) If I do get enough motivation, I'll look at that issue sometime, but if someone else fixes, that's fine by me too ;) Nicolas From mwedel at sonic.net Mon Dec 4 02:20:48 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Dec 2006 00:20:48 -0800 Subject: [crossfire] Documentation / wiki In-Reply-To: <200612031117.17054.nicolas.weeger@laposte.net> References: <200611162304.49822.nicolas.weeger@laposte.net> <200612031117.17054.nicolas.weeger@laposte.net> Message-ID: <4573DA60.6010407@sonic.net> Nicolas Weeger (Laposte) wrote: > As a test bed, I've put doc/Developers/objects on the wiki, you can see it at > http://wiki.metalforge.net/doku.php/dev:objects (not yet totally formatted, > and dokuwiki is running out of memory caching it sometimes :)) > > Does that look good? Looks good - a few notes: > 3. Create a bitmap. It must be dividable by 32 in both height and width. The > file format should be .PNG 256 colour and use transparancy. IMO, that is no longer really accurate - pixmaps can be odd sizes (32x40). Some clients may have issues drawing it (I think I fixed it recently for the gtk and gtk2 client). Now there may not be a lot of reason to use odd sizes, but it should be supported. > 5. split the bitmaps up into 32?32 bitmaps and named according to the > naming.doc conventions in the arch tar package. Note, this is not really > necessary at current time - non splitted images should work properly, but some > older clients may have problems with it. (you can use the script ?splitxbm? > which is included below). That should be removed - if anything, we are going in the opposite direction of merging these cut up images into one big image. All clients should support it now days. Likewise, with that, some of the points in point 6 could be removed. can_pass_thru further down should be removed - IIRC, when I redid the movement code, that disappeared (it wasn't used by anything anyways) From aaron_baugher at yahoo.com Mon Dec 4 17:51:20 2006 From: aaron_baugher at yahoo.com (Aaron Baugher) Date: Mon, 4 Dec 2006 15:51:20 -0800 (PST) Subject: [crossfire] Documentation / wiki In-Reply-To: <4573DA60.6010407@sonic.net> Message-ID: <230554.86928.qm@web55212.mail.re4.yahoo.com> I'm a relative newbie to Crossfire, playing as 'Mhoram' on metalforge these days. I played it several years ago, but my Internet connection was poor, so I was stuck playing alone on my own server, and was never part of the Crossfire "community." Since my C is too rusty to help much with the code, and I'm not artistic enough to make maps, I'd like to help add documentation to the wiki, and I'd be interested in opinions from more experienced folks here on what it could use. Any suggestions on what documentation most needs to be written, updated, or improved? I'll start a wish-list of things to work on. In the meantime, I thought I'd start on the list of spells, since that's not on the wiki yet. I'd like to do it differently than the web site. Instead of all the spells broken up alphabetically, A-D and so on, I thought I'd split them up according to skill -- a page of summoning spells, a page of pyromancy, and so on. Then there would be an alphabetical index page of all spells with links into those pages. I'm finding that when I play a spellcaster, I'm usually not interested in every discipline (and may be banned from some by my god) so this way I wouldn't have to scroll past spells I can't use to find the ones I can. It would also let me easily see what my next available spells are as I increase level in a particular skill. What do you think? I suppose I can go ahead and do up a sample, and trash it if that doesn't work. Also, I was wondering about the organization of the wiki. (I hope this is the right place to discuss it.) I've noticed that most of the pages are 'top-level'. For example, Lore is a top-level page, but then the pages under it, like Book of Valriel are also top-level, instead of having a link like lore:book_of_valriel. Does this matter? For the sake of organization, should I have links like magic:spells:pyromancy? I want to make sure my links fit into any future organizational plans for the wiki. Thanks, Aaron --------------------------------- Any questions? Get answers on any topic at Yahoo! Answers. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20061204/d6087bfe/attachment.htm From leaf at real-time.com Tue Dec 5 12:45:35 2006 From: leaf at real-time.com (Rick Tanner) Date: Tue, 05 Dec 2006 12:45:35 -0600 Subject: [crossfire] Documentation / wiki In-Reply-To: <230554.86928.qm@web55212.mail.re4.yahoo.com> References: <230554.86928.qm@web55212.mail.re4.yahoo.com> Message-ID: <4575BE4F.3020307@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Baugher wrote: > > Any suggestions on what documentation most needs to be written, updated, > or improved? I'll start a wish-list of things to work on. > > In the meantime, I thought I'd start on the list of spells, since that's > not on the wiki yet. I'd like to do it differently than the web site. > Instead of all the spells broken up alphabetically, A-D and so on, I > thought I'd split them up according to skill -- a page of summoning > spells, a page of pyromancy, and so on. Please continue to work on the spell list. =-) Thank you for all that you have contributed to! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdb5PhHyvgBp+vH4RAlvJAJ95wvfRfuS2jzj/npWQ8IQoTzCnzwCeNkAO ggWZMJq6LRbxyyaEzs3K35w= =mt4u -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Sat Dec 9 12:10:41 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 9 Dec 2006 19:10:41 +0100 Subject: [crossfire] Documentation / wiki In-Reply-To: <4573DA60.6010407@sonic.net> References: <200611162304.49822.nicolas.weeger@laposte.net> <200612031117.17054.nicolas.weeger@laposte.net> <4573DA60.6010407@sonic.net> Message-ID: <200612091910.41256.nicolas.weeger@laposte.net> > IMO, that is no longer really accurate - pixmaps can be odd sizes (32x40). > Some clients may have issues drawing it (I think I fixed it recently for > the gtk and gtk2 client). Now there may not be a lot of reason to use odd > sizes, but it should be supported. > > That should be removed - if anything, we are going in the opposite > direction of merging these cut up images into one big image. All clients > should support it now days. Likewise, with that, some of the points in > point 6 could be removed. > > can_pass_thru further down should be removed - IIRC, when I redid the > movement code, that disappeared (it wasn't used by anything anyways) Well, do you see that nice "edit page" button? :) More seriously the page could sure use some updating & proof-reading. The thing i'd really like to do is actually document what the code does (not how it does) for each item type, what options, and such. This would make checking for bugs much easier. Nicolas From nicolas.weeger at laposte.net Sat Dec 9 12:14:43 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 9 Dec 2006 19:14:43 +0100 Subject: [crossfire] Curse bug In-Reply-To: <200612031309.28719.nicolas.weeger@laposte.net> References: <200611170048.26753.nicolas.weeger@laposte.net> <45726A8C.8050000@sonic.net> <200612031309.28719.nicolas.weeger@laposte.net> Message-ID: <200612091914.43220.nicolas.weeger@laposte.net> > If I do get enough motivation, I'll look at that issue sometime, but if > someone else fixes, that's fine by me too ;) I did find enough time, and committed a fix to SVN with the behaviour described in this thread. Note that it's been roughly tested, but could sure use more testing. Nicolas From leaf at real-time.com Thu Dec 14 16:44:54 2006 From: leaf at real-time.com (Rick Tanner) Date: Thu, 14 Dec 2006 16:44:54 -0600 Subject: [crossfire] Curse bug In-Reply-To: <200612091914.43220.nicolas.weeger@laposte.net> References: <200611170048.26753.nicolas.weeger@laposte.net> <45726A8C.8050000@sonic.net> <200612031309.28719.nicolas.weeger@laposte.net> <200612091914.43220.nicolas.weeger@laposte.net> Message-ID: <4581D3E6.3070203@real-time.com> Nicolas Weeger (Laposte) wrote: >> If I do get enough motivation, I'll look at that issue sometime, but if >> someone else fixes, that's fine by me too ;) > > I did find enough time, and committed a fix to SVN with the behaviour > described in this thread. > > Note that it's been roughly tested, but could sure use more testing. Reference: https://sourceforge.net/tracker/?func=detail&atid=113833&aid=1551398&group_id=13833 From a player or in-game standpoint - what should they watch for to see if this works? Or, will this require DM/Server admin interaction? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061214/2457414a/attachment.pgp From alex_sch at telus.net Thu Dec 14 17:07:35 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 14 Dec 2006 16:07:35 -0700 Subject: [crossfire] Curse bug In-Reply-To: <4581D3E6.3070203@real-time.com> References: <200611170048.26753.nicolas.weeger@laposte.net> <45726A8C.8050000@sonic.net> <200612031309.28719.nicolas.weeger@laposte.net> <200612091914.43220.nicolas.weeger@laposte.net> <4581D3E6.3070203@real-time.com> Message-ID: <4581D937.8030204@telus.net> Rick Tanner wrote: > Reference: > https://sourceforge.net/tracker/?func=detail&atid=113833&aid=1551398&group_id=13833 > > From a player or in-game standpoint - what should they watch for to see > if this works? > > Or, will this require DM/Server admin interaction? The easiest example for a player to see in game, is that curse will no longer make the "rock crushers" in ancient pupland so drastically weak. It would also apply to using curse on some other 'boss' monsters, but is probably most dramatic on the rock crushers. However if one wants more solid evidence it's working, a DM/admin would indeed have to look at the monster dump after it's been cursed. Alex Schultz From alex_sch at telus.net Fri Dec 15 01:20:16 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 15 Dec 2006 00:20:16 -0700 Subject: [crossfire] Code refactoring framework commited Message-ID: <45824CB0.3030703@telus.net> Hi, A couple of days ago, I finally got the framework for object-type specific code committed, though no code refactored into it yet. I hope I didn't horribly mess up anything :) Below is a copy of the README file that I put in the new types/ directory for it. Alex -------------------------------------------------------------------------- This directory is for the object-type dependent code, in addition to also storing some generic methods for objects which an object-type may want to override. ==Organization== -Place object-type specific code in this directory either as "foobar.c" or in a directory, as "foobar/*.c" with logical and clear individual file names. Use your discretion on if the code for the type should be split across multiple C files or not -If multiple type numbers are the same in behavior (i.e. armor types, though those should be fixed later), it is fine to put them in the same grouping of code. -Code used by multiple types, that is specific to an action controlled by this subsystem is put in "common/*.c" under a logical filename. This includes generic code for dropping, picking up, etc. -Code for an action controlled by this system, but not yet split in to type-specific segments may be stored in "legacy/*.c" for the moment. This will obviously be removed after refactoring is complete. ==API== -The api for this system is in "server/ob_types.c" and "server/ob_methods.c" at the top level. Read the comments in those files for more complete documentation. -The following types are initialized and defined in init_ob_methods(), which you should edit to modify. -The base_type is for defining default actions for all object types. It inherits from legacy_type. -legacy_type is for references to code in "legacy/*.c", and does not have a fallback. It will be removed when the refactoring is complete. -Functions: -The function, init_ob_method_struct(ob_method *methods, ob_methods *fallback) initializes an ob_method struct and sets it's fallback to fallback. -All functions in the form of ob_foobar(object *ob, ...) are for calling object methods. They search though fallbacks when the object's type. -All functions named register_foobar(int ob_type, ...) are for registering a callback with the array storing object methods for different types. Use this to register object_type_specific callbacks -Defined types: -Always make sure your callback functions match the typedefs such as apply_func, as defined in ob_methods.h ==Adding new object methods== As a quick reference, here is a checklist for adding a new object method for use in this section of the code. 1) Define "foobar_func" in ob_methods.h 2) Add "foobar" to the "ob_methods" struct in ob_methods.h 3) Add a line to set it to NULL in init_ob_method_struct() in ob_methods.c 4) Add the boring handler function, "ob_foobar(object *ob, ...)" in ob_methods.c 5) Add the boring "register_foobar(int ob_type, foobar_func *methodptr)" function in ob_types.c 6) Add handler functions for base_type and/or legacy_type if applicable. Reference to in init_ob_methods() in ob_methods.c 7) Add type-specific methods and register them in an init function for the type, using register_foobar(). Call this init function in init_ob_types() in ob_types.c ==Notes on refactoring into here== -Always make a note in the ChangeLog file in this directory, but don't neglect the top level ChangeLog either when making changes here. -Try to refactor one whole object type at a time, adding whatever object methods are required. -Commit often, in fact, as often as you can so long as things don't break -Try not to change in-game behavior here; unless it's a really obvious bug, try to leave that for separate commits either before or after moving the code. -When moving code here, always review it entirely, clean up the comments, and code style. From alex_sch at telus.net Fri Dec 15 01:31:08 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 15 Dec 2006 00:31:08 -0700 Subject: [crossfire] LF vs CRLF Message-ID: <45824F3C.9050203@telus.net> Hi, Due to some issues that bencha (from IRC) had when trying to do a checkout of the map tree on win32, I removed the svn property "svn:eol-style" which was set to "native" from all map and archetype files. This solution worked however I think the issue should be brought up here. As I see it there are three possible long term solutions: Make a rule of always making sure svn:eol-style is set to LF or not set (preferably not set as to match what I have done already IMHO). The drawback of this is that there are bound to be some mistakes in following this rule, though on the other hand a script to check it would be simple. There is also the option of seeing if we could get sf.net to place an approved post-commit hooked script in which makes sure it's unset for all maps and arches. This would be safer than the above, but there's a high chance we wouldn't be able to get sf.net to approve such a script for usage. Finally, there is also the option of making the server handle both LF and CRLF style line endings. IMHO this is the best option for a long term and proper solution. I'm not sure off hand how easy this would be with lex though. Alex From mwedel at sonic.net Sat Dec 16 23:43:53 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 16 Dec 2006 21:43:53 -0800 Subject: [crossfire] LF vs CRLF In-Reply-To: <45824F3C.9050203@telus.net> References: <45824F3C.9050203@telus.net> Message-ID: <4584D919.4060108@sonic.net> Alex Schultz wrote: > Finally, there is also the option of making the server handle both LF > and CRLF style line endings. IMHO this is the best option for a long > term and proper solution. I'm not sure off hand how easy this would be > with lex though. The lex code probably has an option to say what the line separator are. However, that is only 1 piece of the puzzle: - load_map_header uses fgets and has various bits of code that looks for newline - that may need to be modified. - The java editor would have to be modified, as it has its own loader logic (maybe that handles either way by default - don't know. - There may be other bits of code here and there that would have issues. Off the top of my head, anything that reads data from files might have issues - this would include the treasure code, artifacts code, messages, settings, etc. While a CRLF style will be read in correctly, it may mean that strings would have tailing CR's when they should (the load code removes the LF, but would have to be modified to also potentially remove the CR). In some cases, that wouldn't be a big deal (code is just doing an atoi on the string, so if it has a newline, not a big deal). However, if that isn't removed for things like object names, then it wouldn't be able to find archetypes, etc. - Even if the code is modified, still have to make sure that things don't change to quickly - if code changes are made, and then immediately some CRLF things are checked in, then people that update the maps but not the server could have problems, etc. From alex_sch at telus.net Sun Dec 17 00:05:57 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 16 Dec 2006 23:05:57 -0700 Subject: [crossfire] LF vs CRLF In-Reply-To: <4584D919.4060108@sonic.net> References: <45824F3C.9050203@telus.net> <4584D919.4060108@sonic.net> Message-ID: <4584DE45.605@telus.net> For now at least, I just changed the svn:eol-style for the arches and maps to "LF" (as opposed to deleting the property), as that more accurately reflects the nature of the files and how they are currently read. Also, I've made a quick bash script (to be run from the root of the whole repository) that can verify that all map/arch files are set to that properly, and if not, set them. It might be good to be run every so often just to check for newly added maps without the eol-style set properly. Alex ---- #!/bin/sh maindir=`pwd` cd "$maindir"/arch for foo in `find \( -not -wholename "*/.svn*" \) -and -type f -and -name "*.arc"` do output=`svn propget --strict svn:eol-style $foo` if [ "$output"x != "LF"x ]; then echo "Arch file $foo not set to LF ($output)" svn propset svn:eol-style LF "$foo" fi done cd "$maindir"/maps for foo in `find \( -not -wholename "*/.svn*" \) -and -type f` do startline=`head -n1 $foo` if [ "$startline"x = "arch map"x ]; then output=`svn propget --strict svn:eol-style $foo` if [ "$output"x != "LF"x ]; then echo "Map file $foo not set to LF ($output)" svn propset svn:eol-style LF "$foo" fi fi done -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3501 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061216/1942f32e/attachment.bin From cher at riedquat.de Wed Dec 20 16:39:21 2006 From: cher at riedquat.de (Christian Hujer) Date: Wed, 20 Dec 2006 23:39:21 +0100 (MET) Subject: [crossfire] LF vs CRLF In-Reply-To: <4584D919.4060108@sonic.net> References: <45824F3C.9050203@telus.net> <4584D919.4060108@sonic.net> Message-ID: <200612202256.14292.cher@riedquat.de> Hi, On Sunday 17 December 2006 06:43 Mark Wedel wrote: > Alex Schultz wrote: > - The java editor would have to be modified, as it has its own loader logic > (maybe that handles either way by default - don't know. officially we support LF only. We have some undocumented CRLF support but wouldn't rely on it. If you need CRLF support, just tell us. (Though I personally prefer LF-only even on DOS/Windows) If this is changed, I think it'd make sense to do this synchronuous in crossfire as well in daimonin. Note: Supporting only CRLF or LF will still leave some Mac users with no support for their native line ending: CR only. -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061220/692745c1/attachment.pgp From cher at riedquat.de Wed Dec 20 16:57:28 2006 From: cher at riedquat.de (Christian Hujer) Date: Wed, 20 Dec 2006 23:57:28 +0100 (MET) Subject: [crossfire] Merry Christmas and a Happy New Year from the Gridarta Team Message-ID: <200612202336.07375.cher@riedquat.de> Dear co-developers, Dear Crossfire developers, Dear Daimonin developers, merry christmas and a happy new year to all of you! Year 2006 has been a very interesting year for all of us. At the crossfire and daimonin g2g's I've met new friends and we've exchanged many interesting ideas. I've seen new activities and new spirit for both of these projects. And it was the year Gridarta was founded. We still have a long way to go rejoining the crossfire and daimonin editors into a common code base. But we're also making good progress, and with every commit the code becomes more mature. We're getting closer to some substantial changes to both of the editors. Let me take this chance to announce a set of new features that I'm planning for 2007: * The first public releases plus the corresponding branches to separate potentially unstable feature implementations from bug fixing for existing versions. * Gridarta Webstart, which should reduce michtoen's burden with creating update releases of the map maker package and might also make the life easier for windows users of gridarta for crossfire (are there any?). * A plugin and scripting interface for gridarta (not only for cfeditor - note: I'm planning to use Java 6.0 for it). * Configurable map validation (not only for daieditor). * User interfaces for more comfortable editing of @match texts (magic mouths) and daimonin's book ui. * An integrated archetype editor incl. animation handler. * Plus of course all features that you, the users, like. Only limitation: Our free time ;-) Also let me use this occasion to express my thanks to all of you in many ways. First of all, special thanks go to Ragnor and zergus for their valueable contributions. Without them, gridarta wouldn't even be half as far as it is. In fact, during the last few weeks, most substantial merge progress was due to Ragnor's many commits. And many thanks to everybody who put trust in Gridarta, and to the patient users on both sides, crossfire and daimonin, that willingly accept that such a merger first slows down implementation of new features. Also thank you all for all your input and exchange of ideas to improve Gridarta. Last but not least thanks to all "little helpers" like Rednaxela who started publishing some interesting metrics in the crossfire wiki or all the bug and feature request reporters like naomeire, ryo and smacky (list definitely incomplete ;-). Merry christmas and a happy new year to all of you! Cher and the Gridarta project team -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061220/22bd1566/attachment.pgp From nicolas.weeger at laposte.net Thu Dec 21 15:45:36 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 21 Dec 2006 22:45:36 +0100 Subject: [crossfire] LF vs CRLF In-Reply-To: <45824F3C.9050203@telus.net> References: <45824F3C.9050203@telus.net> Message-ID: <200612212245.37024.nicolas.weeger@laposte.net> Hello. (sent with delay due to mail issues) > Make a rule of always making sure svn:eol-style is set to LF or not set > (preferably not set as to match what I have done already IMHO). The > drawback of this is that there are bound to be some mistakes in > following this rule, though on the other hand a script to check it would > be simple. Since the server currently only support LF (loader.l will choke horribly, as wekk as most parts of the code), I think we should set that property to LF. It will avoid issues with Windows users not manually setting that flag, also makes it coherent with the rest. > There is also the option of seeing if we could get sf.net to place an > approved post-commit hooked script in which makes sure it's unset for > all maps and arches. This would be safer than the above, but there's a > high chance we wouldn't be able to get sf.net to approve such a script > for usage. If set to LF, I think SVN converts automatically at commit time (except binary files, of course). > Finally, there is also the option of making the server handle both LF > and CRLF style line endings. IMHO this is the best option for a long > term and proper solution. I'm not sure off hand how easy this would be > with lex though. Probably, yes, but a long-time goal I think :) Nicolas From nicolas.weeger at laposte.net Thu Dec 21 15:45:47 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 21 Dec 2006 22:45:47 +0100 Subject: [crossfire] Item power/enchantment question Message-ID: <200612212245.47644.nicolas.weeger@laposte.net> Hello. Regarding bug https://sourceforge.net/tracker/index.php?func=detail&aid=1612838&group_id=13833&atid=113833 (Problem with item_power code), I'm wondering if there is somewhere documentation about what item power and enchantment are supposed to do? :) So we can fix as the documentation says it should work, or fix the documentation ^_- Nicolas From nicolas.weeger at laposte.net Thu Dec 21 15:45:42 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 21 Dec 2006 22:45:42 +0100 Subject: [crossfire] Code refactoring framework commited In-Reply-To: <45824CB0.3030703@telus.net> References: <45824CB0.3030703@telus.net> Message-ID: <200612212245.42347.nicolas.weeger@laposte.net> > A couple of days ago, I finally got the framework for object-type > specific code committed, though no code refactored into it yet. I hope I > didn't horribly mess up anything :) Yeah for the framework! :) Now if you could do a small example, so we see exactly how it works? :) (one example is worth 100 READMEs, imo ^_-) Nicolas From leaf at real-time.com Thu Dec 21 16:16:31 2006 From: leaf at real-time.com (Rick Tanner) Date: Thu, 21 Dec 2006 16:16:31 -0600 Subject: [crossfire] Item power/enchantment question In-Reply-To: <200612212245.47644.nicolas.weeger@laposte.net> References: <200612212245.47644.nicolas.weeger@laposte.net> Message-ID: <458B07BF.4090909@real-time.com> Nicolas Weeger (Laposte) wrote: > I'm wondering if there is somewhere > documentation about what item power and enchantment are supposed to do? :) > > So we can fix as the documentation says it should work, or fix the > documentation ^_- This? http://crossfire.svn.sourceforge.net/viewvc/crossfire/server/branches/1.x/doc/Developers/objects?revision=5018&view=markup Section 3G Item Power (item_power) item_power measures how powerful and item is. This information is only relevant for items that are equipped - one time use items, monsters, walls, floors, do not use this. When a player tries to equip something, the code goes through all the objects the player currently has equipped and sums up their item_power. The item_power of the object the player is trying to equip is also added. If this total exceeds the characters level, he is not allowed to equip the item. In simple terms, the sum of all the players equip items item_power must be less than the characters level. Powerful items should have a higher item_power value. This basically acts as a way to balance the items. It also prevents gifts from high level characters to newbies from being very useful - the item_power may prevent the low level character from equipping this items. For items automatically generated by the treasure code, the following formula is used: # enchantments power 0 0 1 0 2 1 3 2 4 3 5 5 6 8 7 11 An enchantment is: Each plus an item has. Each point an item increases an ability. Each 20% protection an item gives (rounded normally, eg 0-9 counts as nothing, 10-29 counts as one, etc) Each attacktype a weapon has. Spell path adjustments This same formula can be used for custom objects to figure out their item power. While the item_power field in the object structure is signed, in general, there should not be objects with a negative item power. However, negative effects an item has may reduce the item power. Eg, a 'sword +4 (str +2)(wis -3)' would really be 3 enchantments. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061221/b3aaf9cb/attachment.pgp From mwedel at sonic.net Fri Dec 22 00:15:48 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 21 Dec 2006 22:15:48 -0800 Subject: [crossfire] Item power/enchantment question In-Reply-To: <200612212245.47644.nicolas.weeger@laposte.net> References: <200612212245.47644.nicolas.weeger@laposte.net> Message-ID: <458B7814.80205@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > Regarding bug > https://sourceforge.net/tracker/index.php?func=detail&aid=1612838&group_id=13833&atid=113833 > (Problem with item_power code), I'm wondering if there is somewhere > documentation about what item power and enchantment are supposed to do? :) > > So we can fix as the documentation says it should work, or fix the > documentation ^_- The armor improvement code appears to be broken. IIRC, the weapon improvement codes does this more properly - each time an item is further enchanted, it just adds one to the items current item power. This perhaps isn't perfect (since the automatic method is sort of exponential), but seems fair. It could be reasonable that some forms of enchantment are more valuable than others, and so should perhaps increase the item power by more than one. From nicolas.weeger at laposte.net Sat Dec 23 15:27:41 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 23 Dec 2006 22:27:41 +0100 Subject: [crossfire] Merry Christmas and a Happy New Year from the Gridarta Team In-Reply-To: <200612202336.07375.cher@riedquat.de> References: <200612202336.07375.cher@riedquat.de> Message-ID: <200612232227.41714.nicolas.weeger@laposte.net> Le Mercredi 20 D?cembre 2006 23:57, Christian Hujer a ?crit?: > Dear co-developers, > Dear Crossfire developers, > Dear Daimonin developers, > > merry christmas and a happy new year to all of you! Merry Christmas everyone on all those lists :) Nicolas From alex_sch at telus.net Sat Dec 23 20:21:16 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 23 Dec 2006 19:21:16 -0700 Subject: [crossfire] Code Doxygenification Message-ID: <458DE41C.3070106@telus.net> Hi everyone, So does anyone have any objections to 'doxygenificaiton' of the code? :) Also, we need to agree on a standard form of doxygen comments to use as there are a few different syntax variations it accepts. In addition, if we do agree that the code should be 'doxygenificatated', I think it would be a good idea to document this in the coding style docs. Personally I'd advocate the following commenting style: ------- Use Javadoc style comments as opposed to QT style comments. IMHO it's easier on the eyes. For example: /** * This does foobar */ and *not*: /*! * This does foobar */ ------- Doxygen accepts commands in both the forms "\foobar" or "@foobar". I believe that "@foobar" is easier to read as it stands out more (from things like escape characters and the / character used in commenting) without being an eyesore either. For example /** * This function does foobar * @param ob The object to foobar * @todo Handle multitile objects */ as opposed to /** * This function does foobar * \param ob The object to foobar * \todo Handle multitile objects */ ------- Make use of the "@file foobar.c" directive at the top of code files. I think files should have their purpose clearly outlined in order to keep code organized. For example: /** @file foobar.c * Handle foobaring. * @note Don't put baz here. */ at the start of the file ------- Have JAVADOC_AUTOBRIEF set to TRUE and comment appropriately. Doxygen supports both full and brief descriptions. Explicitly specifying each tends to look poor when looking at the comment manually, however by using JAVADOC_AUTOBRIEF, it automatically makes the first sentence of the description the brief description. This requires comments to be written to fit this, with the first sentence of the description being a summary of what the function/etc. does. (see: http://www.stack.nl/~dimitri/doxygen/config.html#cfg_javadoc_autobrief ) ------- Another thing, is that in order to link to global variables or global typedefs in doxygen comments, one needs to write it as either "::foobar" or as "#foobar". Personally I don't like either much, but we should decide which to use. I suggest one looks at http://www.stack.nl/~dimitri/doxygen/docblocks.html for more information on what doxygen accepts. Alex Schultz From nicolas.weeger at laposte.net Sun Dec 24 03:09:41 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 24 Dec 2006 10:09:41 +0100 Subject: [crossfire] Code Doxygenification In-Reply-To: <458DE41C.3070106@telus.net> References: <458DE41C.3070106@telus.net> Message-ID: <200612241009.41951.nicolas.weeger@laposte.net> Hi :) > So does anyone have any objections to 'doxygenificaiton' of the code? :) None here, quite the opposite :) > Use Javadoc style comments as opposed to QT style comments. IMHO it's > easier on the eyes. For example: > /** > * This does foobar > */ > and *not*: > /*! > * This does foobar > */ Agreed to that (first proposal). > Doxygen accepts commands in both the forms "\foobar" or "@foobar". I > believe that "@foobar" is easier to read as it stands out more (from > things like escape characters and the / character used in commenting) > without being an eyesore either. For example > /** > * This function does foobar > * @param ob The object to foobar > * @todo Handle multitile objects > */ > as opposed to > /** > * This function does foobar > * \param ob The object to foobar > * \todo Handle multitile objects > */ Agreed to first proposal too. > Make use of the "@file foobar.c" directive at the top of code files. I > think files should have their purpose clearly outlined in order to keep > code organized. For example: > /** @file foobar.c > * Handle foobaring. > * @note Don't put baz here. > */ > at the start of the file Idem. > Have JAVADOC_AUTOBRIEF set to TRUE and comment appropriately. > Doxygen supports both full and brief descriptions. Explicitly specifying > each tends to look poor when looking at the comment manually, however by > using JAVADOC_AUTOBRIEF, it automatically makes the first sentence of > the description the brief description. This requires comments to be > written to fit this, with the first sentence of the description being a > summary of what the function/etc. does. Nice feature, yeah, agreed we should use it. > Another thing, is that in order to link to global variables or global > typedefs in doxygen comments, one needs to write it as either "::foobar" > or as "#foobar". Personally I don't like either much, but we should > decide which to use. Maybe "::foobar"? It's coherent with namespace naming. I'd say we should do that progressively, while changing functions and such, instead of everything in one time. Nicolas From cher at riedquat.de Mon Dec 25 09:31:09 2006 From: cher at riedquat.de (Christian Hujer) Date: Mon, 25 Dec 2006 16:31:09 +0100 (MET) Subject: [crossfire] Code Doxygenification In-Reply-To: <200612241009.41951.nicolas.weeger@laposte.net> References: <458DE41C.3070106@telus.net> <200612241009.41951.nicolas.weeger@laposte.net> Message-ID: <200612251609.03249.cher@riedquat.de> Hi, On Sunday 24 December 2006 10:09 Nicolas Weeger (Laposte) wrote: > > Another thing, is that in order to link to global variables or global > > typedefs in doxygen comments, one needs to write it as either "::foobar" > > or as "#foobar". Personally I don't like either much, but we should > > decide which to use. > > Maybe "::foobar"? It's coherent with namespace naming. OTOH, #foobar is coherent with URI (HTML etc.) and Javadoc. My 2 cents :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061225/4a14d92c/attachment.pgp From nicolas.weeger at laposte.net Tue Dec 26 11:35:40 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 26 Dec 2006 18:35:40 +0100 Subject: [crossfire] Player file corruption In-Reply-To: <200612022011.39767.nicolas.weeger@laposte.net> References: <200610221911.14981.nicolas.weeger@laposte.net> <200612022011.39767.nicolas.weeger@laposte.net> Message-ID: <200612261835.40394.nicolas.weeger@laposte.net> Hello. Attached is a Python script that will reset spell's last_eat / last_gr / last_sp for players when they connect. Value is archetype's one. Logfile is created, named fix_spells_1569017.log, in datafiles directory. Also avoids resetting 2 times. Just put the .py file in the "python/events/login" subdirectory of the maps directory. Note that I did *not* check whether there were maps with customized spells modifying those values. IMO there shouldn't be, but you can never be sure :) Disclaimer: this script shouldn't mess with players, but since we never know make sure you got backups :) Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_spells_1569017.py Type: application/x-python Size: 679 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061226/f3ffd380/attachment.bin From nicolas.weeger at laposte.net Tue Dec 26 16:48:22 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 26 Dec 2006 23:48:22 +0100 Subject: [crossfire] Player file corruption In-Reply-To: <200612261835.40394.nicolas.weeger@laposte.net> References: <200610221911.14981.nicolas.weeger@laposte.net> <200612022011.39767.nicolas.weeger@laposte.net> <200612261835.40394.nicolas.weeger@laposte.net> Message-ID: <200612262348.22151.nicolas.weeger@laposte.net> I just changed Archetype.Clone from a method to a property (for coherence), so attached is an updated script that'll work if you updated your server before running it :) Nicolas Le Mardi 26 D?cembre 2006 18:35, Nicolas Weeger (Laposte) a ?crit?: > Hello. > > Attached is a Python script that will reset spell's last_eat / last_gr / > last_sp for players when they connect. Value is archetype's one. > Logfile is created, named fix_spells_1569017.log, in datafiles directory. > Also avoids resetting 2 times. > > Just put the .py file in the "python/events/login" subdirectory of the maps > directory. > > Note that I did *not* check whether there were maps with customized spells > modifying those values. IMO there shouldn't be, but you can never be sure > :) > > > Disclaimer: this script shouldn't mess with players, but since we never > know make sure you got backups :) > > Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_spells_1569017.py Type: application/x-python Size: 673 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061226/75e87239/attachment.bin From mwedel at sonic.net Tue Dec 26 18:49:23 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 26 Dec 2006 16:49:23 -0800 Subject: [crossfire] Code Doxygenification In-Reply-To: <458DE41C.3070106@telus.net> References: <458DE41C.3070106@telus.net> Message-ID: <4591C313.2030601@sonic.net> I think that the proposed changes are fine. Updating the functions as they are changed or other nearby functions are changed works, but the end result is that it means it can take a very long time for all the functions to be documented. And if the goal/hope is to have some coherent documentation available, getting it done sooner vs later is probably good. We can sort of look at the other various code cleanups going on - fixing indentation has been going on for quite a while, and still not done. Some functions really are not changing much (the arch.c file gets occasional new function added, but I don't think some of the functions in there have been modified for years), so it could be a very long wait for change to happen. OTOH, doing this cleanup or indentation fixes is something that can be done in small doses. I know that for myself, if I only have 30 minutes to spend, I may not going on a coding project, knowing I will be unable to finish it in that time. However, I could certainly document several functions in that time period, etc. Also, do we have any plans for putting this doxygenification online anyplace? I imagine this could be done automatically (have a cron job that generates the documents and then upload them to some server nightly or something). One nice thing about doing something like that is that then the results are more visible From alex_sch at telus.net Tue Dec 26 19:51:51 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 26 Dec 2006 18:51:51 -0700 Subject: [crossfire] Code Doxygenification In-Reply-To: <4591C313.2030601@sonic.net> References: <458DE41C.3070106@telus.net> <4591C313.2030601@sonic.net> Message-ID: <4591D1B7.1000102@telus.net> Mark Wedel wrote: > OTOH, doing this cleanup or indentation fixes is something that can be done in > small doses. I know that for myself, if I only have 30 minutes to spend, I may > not going on a coding project, knowing I will be unable to finish it in that > time. However, I could certainly document several functions in that time > period, etc. > This sort of thing is part of the reason I was thinking about doxygenification myself, as I was finding I had numerous short periods of time that I wouldn't be able to get code done it but could do a little documentation or something in. :-) > Also, do we have any plans for putting this doxygenification online anyplace? > I imagine this could be done automatically (have a cron job that generates the > documents and then upload them to some server nightly or something). One nice > thing about doing something like that is that then the results are more visible Agreed. One thing we should perhaps check is if the terms of use for the sf.net compile farm/shell server allows us to run doxygen on it, not really sure it would but it would be nice if we could. If nobody else is able to, I could run a nightly cron job (which won't run unless the doxygen config or a code file changes in the 24 hour period) for it around 10:00 UTC or so, however I wouldn't be able to host it myself so I would need to upload it somewhere else. Anyone have any suggestions for options for this? Alex Schultz From nicolas.weeger at laposte.net Wed Dec 27 03:08:07 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Wed, 27 Dec 2006 10:08:07 +0100 Subject: [crossfire] Code Doxygenification In-Reply-To: <4591D1B7.1000102@telus.net> References: <458DE41C.3070106@telus.net> <4591C313.2030601@sonic.net> <4591D1B7.1000102@telus.net> Message-ID: <200612271008.07955.nicolas.weeger@laposte.net> > Agreed. One thing we should perhaps check is if the terms of use for the > sf.net compile farm/shell server allows us to run doxygen on it, not > really sure it would but it would be nice if we could. > If nobody else is able to, I could run a nightly cron job (which won't > run unless the doxygen config or a code file changes in the 24 hour > period) for it around 10:00 UTC or so, however I wouldn't be able to > host it myself so I would need to upload it somewhere else. > Anyone have any suggestions for options for this? Shouldn't that documentation be on the website? *grins evilly towards poor Rick* But I do agree having documentation online would be nice. Nicolas From mwedel at sonic.net Wed Dec 27 13:57:54 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 27 Dec 2006 11:57:54 -0800 Subject: [crossfire] Code Doxygenification In-Reply-To: <200612271008.07955.nicolas.weeger@laposte.net> References: <458DE41C.3070106@telus.net> <4591C313.2030601@sonic.net> <4591D1B7.1000102@telus.net> <200612271008.07955.nicolas.weeger@laposte.net> Message-ID: <4592D042.6040301@sonic.net> Nicolas Weeger (Laposte) wrote: >> Agreed. One thing we should perhaps check is if the terms of use for the >> sf.net compile farm/shell server allows us to run doxygen on it, not >> really sure it would but it would be nice if we could. >> If nobody else is able to, I could run a nightly cron job (which won't >> run unless the doxygen config or a code file changes in the 24 hour >> period) for it around 10:00 UTC or so, however I wouldn't be able to >> host it myself so I would need to upload it somewhere else. >> Anyone have any suggestions for options for this? > IIRC, the sourceforge folks only want the compile farm used for interactive use - no cron jobs, etc. Plus I seem to recall some odd things regarding access to web area (or maybe it was SVN) from the compile farm itself - something with it being inside the sourceforge network/firewall made things different. I'd have no problem setting up a cron job on my home system and copying the data somewhere, but that somewhere is a trickier issue. sourceforge provides web space, but also requires that every web page for the project has the sourceforge logo. I'm not sure if there is an easy way to modify doxygen to include that. I could host the data myself, but it would be better for it to be on one of the more official crossfire sites. From alex_sch at telus.net Wed Dec 27 16:03:01 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 27 Dec 2006 15:03:01 -0700 Subject: [crossfire] Code Doxygenification In-Reply-To: <4592D042.6040301@sonic.net> References: <458DE41C.3070106@telus.net> <4591C313.2030601@sonic.net> <4591D1B7.1000102@telus.net> <200612271008.07955.nicolas.weeger@laposte.net> <4592D042.6040301@sonic.net> Message-ID: <4592ED95.9080205@telus.net> Mark Wedel wrote: > IIRC, the sourceforge folks only want the compile farm used for > interactive > use - no cron jobs, etc. Plus I seem to recall some odd things regarding access > to web area (or maybe it was SVN) from the compile farm itself - something with > it being inside the sourceforge network/firewall made things different. > Actually, they do at least currently allow cron jobs: http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1#cron And in fact some of their servers (/x86-linux2 and //x86-freebsd1/) do have doxygen installed already: http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1#devel_tools The real issue with using the sf.net compile farm to my understanding is outbound connectivity as it has no real way to automatically send it to whatever is hosting it. Therefore I'm thinking we'd just have to do it on one of our own boxes. > sourceforge provides web space, but also requires that every web page for the > project has the sourceforge logo. I'm not sure if there is an easy way to > modify doxygen to include that. > Doxygen does allow manual modification of the html headers :) See: http://www.stack.nl/~dimitri/doxygen/config.html#cfg_html_header and: http://www.stack.nl/~dimitri/doxygen/doxygen_usage.html Alex Schultz From nicolas.weeger at laposte.net Fri Dec 29 12:18:13 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 29 Dec 2006 19:18:13 +0100 Subject: [crossfire] Code Doxygenification In-Reply-To: <458DE41C.3070106@telus.net> References: <458DE41C.3070106@telus.net> Message-ID: <200612291918.14054.nicolas.weeger@laposte.net> Hello. I just did all files in the common/ subdirectory :) (fixed indent and comments) Ok, i didn't comment *all* parameters, i did feel stupid for writing obvious things. But resulting documentation looks nice ^_- Now, I warn you: I will track and hang, after some smacking, anyone committing code not indented correctly, and/or without comments *evil grin* Nicolas From mwedel at sonic.net Fri Dec 29 16:08:45 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 29 Dec 2006 14:08:45 -0800 Subject: [crossfire] Release of 1.10 soon. Message-ID: <459591ED.6040504@sonic.net> I'd like to make a 1.10 release of crossfire sometime soon. So if you have bugs you're currently fixing, getting those fixes in now would be good. If you are aware of any unreported bugs, please report them now. If you need time to fix some bugs, please also let me know. From yann.chachkoff at myrealbox.com Fri Dec 29 17:26:53 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 30 Dec 2006 00:26:53 +0100 Subject: [crossfire] Release of 1.10 soon. Message-ID: <1167434813.c7d45b5cyann.chachkoff@myrealbox.com> > I'd like to make a 1.10 release of crossfire sometime soon. So if you have bugs you're currently fixing, getting those fixes in now would be good. > Hrem, I don't think people keep fixes for ages in their local hard disks before submitting them :). > If you are aware of any unreported bugs, please report them now. > If you need time to fix some bugs, please also let me know. > I do. I'd like to have enough time to solve at least the following bugs before the next release: - #1612838 : Problem with item_power code; - #1539120 : Talisman of Evocation grants wrong skill; - #1528525 : Sometimes "bad" initial items are created. I think it would also be nice to wait until #1522796, #1551398, #1556723 and #1605033, which are all marked as probably fixed, are verified and closed. Given that a significant amount of bugs can be adressed in a relatively short time, and that the GTK2 client as only 5 "priority 5" bugs pending, none of which being overly difficult to solve, I think it is best to wait until those are pushed into the Pit of Oblivion before making a release. After all, there is no deadline to follow, no need to rush something out - so trading one week or two for a cleaner result would definitely be a good choice, IMHO. From fuchs.andy at gmail.com Sat Dec 30 14:19:34 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 30 Dec 2006 15:19:34 -0500 Subject: [crossfire] Release of 1.10 soon. In-Reply-To: <1167434813.c7d45b5cyann.chachkoff@myrealbox.com> References: <1167434813.c7d45b5cyann.chachkoff@myrealbox.com> Message-ID: <1167509975.9882.9.camel@outhouse> On Sat, 2006-12-30 at 00:26 +0100, Yann Chachkoff wrote: > I do. I'd like to have enough time to solve at least the following > bugs before the next release: > - #1612838 : Problem with item_power code; > - #1539120 : Talisman of Evocation grants wrong skill; > - #1528525 : Sometimes "bad" initial items are created. > > I think it would also be nice to wait until #1522796, #1551398, > #1556723 and #1605033, which are all marked as probably fixed, are > verified and closed. > > Given that a significant amount of bugs can be adressed in a > relatively short time, and that the GTK2 client as only 5 "priority 5" > bugs pending, none of which being overly difficult to solve, I think > it is best to wait until those are pushed into the Pit of Oblivion > before making a release. After all, there is no deadline to follow, no > need to rush something out - so trading one week or two for a cleaner > result would definitely be a good choice, IMHO. Agreed, we could put more focus on fixing known bugs, IMO. -- Andrew Fuchs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061230/68ad0653/attachment.pgp From bogus@does.not.exist.com Wed Dec 27 12:41:18 2006 From: bogus@does.not.exist.com () Date: Wed, 27 Dec 2006 18:41:18 -0000 Subject: No subject Message-ID: displayed as possible, with often needed info in easy to look at locations, and less often needed info in less easy to look at locations. Perhaps some often unused inventory tabs could be converted to a "body" tab, which graphically shows what equipment is worn and what slots are free? Or a resistances tab that shows slidebars of the resistances from 0 on a scale between -100 and 100?