From no-reply_wiki at metalforge.org Fri Oct 12 04:29:01 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 12 Oct 2007 04:29:01 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: guides Message-ID: <1192181341.824168.11233.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/12 04:28 User : lalomartins Edit Summary: Valkyrie doc @@ -93,8 +93,13 @@ * [[skills:Use Magic Item]] * [[skills:Wizardry]] * [[skills:Woodsman]] * [[skills:Writing]] + + ===== Gods ===== + Guides on worshipping + + * [[gods:Valkyrie]] ===== Doing things ===== Tutorials and information about various things you can do in crossfire. IP-Address : 61.51.219.208 Old Revision: http://wiki.metalforge.net/doku.php/guides?rev=1185302121 New Revision: http://wiki.metalforge.net/doku.php/guides -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Fri Oct 12 04:41:19 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 12 Oct 2007 04:41:19 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: gods:valkyrie Message-ID: <1192182079.941192.11266.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/12 04:41 User : lalomartins Edit Summary: updating doc @@ -1,14 +1,7 @@ - //Copy/paste from a mail by Lalo Martins// + {{:images:altarvalk.base.111.png}} - I'm working occasionally on porting the "new gods" I wrote years ago to - the current crossfire codebase, then fixing them for balance. I call it - "the Kirby project" ;-) - - The easiest one was one of my favourites: Valkyrie, goddess of war and - warriors, which I just committed. It's far from perfect balance-wise - right now, but it's good enough to get other people test and suggest how - to fine-tune it. + ====== Valkyrie, goddess of war and warriors ====== Valkie calls for a different gameplay style; or alternatively, it legitimates the style of not using magic. She hates all kinds of magic, and "slays" creatures strong in magic. On the other hand, she denies all @@ -20,30 +13,14 @@ The slaying thing will only affect enchanted weapons, and she gives them rather frequently (as weapons are sacred to her). - As for levelling up, that's the fun part. The reason I started with - Valkie is that I figured this one out, after a recent irc chat about - classes. Valkyrie will accept sacrifices on her altar; you should pick up - flesh, bring it to the altar, and then pray. You'll gain praying exp - depending on the difference between your level and the dead creature's, - and on the flesh resistances. Head and heart are worth slightly more. - - This is not very fine-tuned yet; as the values are more or less fixed, I'm - afraid it would take horrendous piles of flesh to climb a really really - high level. - - One alternative idea is to change the flesh code to fill the exp field of - flesh objects with the exp of the originating monster; would that have any - unexpected side-effects? Then of course the altar wouldn't give the whole - exp, just a fraction depending on some factors yet to be defined. - - (On an unrelated note, if I do change the flesh code, I'd like to add the - archetype of the original monster in the other_arch field, for the purpose - of a spell I'm thinking about; any problem with that?) + As for levelling up, that's the fun part. Valkyrie will accept sacrifices on her altar; you should pick up + flesh, bring it to the altar, and then pray. You'll gain praying exp as a fraction of the monster's exp (which is stored as + an attribute in the flesh object). Heads and hearts are worth slightly more. For the sake of testing, I put an altar on the last basement of the abandoned church north of Mostrai in Scorn. This is *NOT* where I intend it to be in the long term, I just want people to help me test it, and that seemed like a good temporary place for it. If you want to test it, have fun, and have a nice carnage! ;-) IP-Address : 61.51.219.208 Old Revision: http://wiki.metalforge.net/doku.php/gods:valkyrie?rev=1172416880 New Revision: http://wiki.metalforge.net/doku.php/gods:valkyrie -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Fri Oct 12 04:44:53 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 12 Oct 2007 04:44:53 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: gods:valkyrie Message-ID: <1192182293.722290.11269.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/12 04:44 User : lalomartins Edit Summary: @@ -1,7 +1,7 @@ - {{:images:altarvalk.base.111.png}} - ====== Valkyrie, goddess of war and warriors ====== + + {{:images:altarvalk.base.111.png}} Valkie calls for a different gameplay style; or alternatively, it legitimates the style of not using magic. She hates all kinds of magic, and "slays" creatures strong in magic. On the other hand, she denies all IP-Address : 61.51.219.208 Old Revision: http://wiki.metalforge.net/doku.php/gods:valkyrie?rev=1192182078 New Revision: http://wiki.metalforge.net/doku.php/gods:valkyrie -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Fri Oct 12 04:48:27 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 12 Oct 2007 04:48:27 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: gods:valkyrie Message-ID: <1192182507.411639.11279.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/12 04:48 User : lalomartins Edit Summary: @@ -1,7 +1,5 @@ ====== Valkyrie, goddess of war and warriors ====== - - {{:images:altarvalk.base.111.png}} Valkie calls for a different gameplay style; or alternatively, it legitimates the style of not using magic. She hates all kinds of magic, and "slays" creatures strong in magic. On the other hand, she denies all @@ -13,9 +11,9 @@ The slaying thing will only affect enchanted weapons, and she gives them rather frequently (as weapons are sacred to her). - As for levelling up, that's the fun part. Valkyrie will accept sacrifices on her altar; you should pick up + {{:images:altarvalk.base.111.png }}As for levelling up, that's the fun part. Valkyrie will accept sacrifices on her altar; you should pick up flesh, bring it to the altar, and then pray. You'll gain praying exp as a fraction of the monster's exp (which is stored as an attribute in the flesh object). Heads and hearts are worth slightly more. For the sake of testing, I put an altar on the last basement of the IP-Address : 61.51.219.208 Old Revision: http://wiki.metalforge.net/doku.php/gods:valkyrie?rev=1192182292 New Revision: http://wiki.metalforge.net/doku.php/gods:valkyrie -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Oct 14 12:16:40 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 14 Oct 2007 12:16:40 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:gfx_needing_fixing Message-ID: <1192382200.094188.23920.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/14 12:16 User : ryo Edit Summary: update @@ -101,9 +101,9 @@ == Opened Containers == These are ugly, and don't look like their closed counterpart. ^ face/animation ^ - | closechest.111 | + | closechest.111 | | close_dbox.111 | | close_bag.111 | | close_pouc.111 | | close_quiv.111 | IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing?rev=1150035533 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Oct 14 15:15:30 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 14 Oct 2007 15:15:30 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:gfx_needing_fixing Message-ID: <1192392930.335580.24635.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/14 15:15 User : ryo Edit Summary: update @@ -102,12 +102,12 @@ == Opened Containers == These are ugly, and don't look like their closed counterpart. ^ face/animation ^ | closechest.111 | - | close_dbox.111 | - | close_bag.111 | - | close_pouc.111 | - | close_quiv.111 | + | close_dbox.111 | + | close_bag.111 | + | close_pouc.111 | + | close_quiv.111 | | close_rsack.111 | | close_sack.111 | | closemail.111 | IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing?rev=1192382197 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Oct 15 16:59:55 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 15 Oct 2007 16:59:55 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: start Message-ID: <1192485595.280642.31832.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/15 16:59 User : Edit Summary: @@ -41,14 +41,16 @@ * [[Linux]] * [[Windows]] * All *[[BSD]]'s * Mac [[OSX]] (in development) + ====== Helpful Link(s) ====== * http://wiki.splitbrain.org/wiki:markup_compare - Helpful conversion guide for text formatting in dokuwiki if you are familiar with other wikis * http://crossfire.real-time.com/ - The "Official" Crossfire Website. * http://dooler.woosworld.net/cf_map/ - CFWorldView, world map viewer. * http://mids.student.utwente.nl/~avogl/map_guide/ - Semi-Obsolete guide to making maps (with [[crossedit]]). [[CFJavaEditor]] (soon to be replaced with [[Gridarta]]) is used more often now. + * http://www.deliantra.net/ deliantra is a fork of crossfire with many improvements, although its not 100% compatible with the old cf. * Get together ([[g2g]]) meeting notes, summary, proposal(s) * [[Content migration]] TODO list IP-Address : 87.78.116.41 Old Revision: http://wiki.metalforge.net/doku.php/start?rev=1176661660 New Revision: http://wiki.metalforge.net/doku.php/start -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Oct 15 17:19:23 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 15 Oct 2007 17:19:23 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: start Message-ID: <1192486763.035476.32001.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/15 17:19 User : leaf Edit Summary: old revision restored @@ -41,16 +41,14 @@ * [[Linux]] * [[Windows]] * All *[[BSD]]'s * Mac [[OSX]] (in development) - ====== Helpful Link(s) ====== * http://wiki.splitbrain.org/wiki:markup_compare - Helpful conversion guide for text formatting in dokuwiki if you are familiar with other wikis * http://crossfire.real-time.com/ - The "Official" Crossfire Website. * http://dooler.woosworld.net/cf_map/ - CFWorldView, world map viewer. * http://mids.student.utwente.nl/~avogl/map_guide/ - Semi-Obsolete guide to making maps (with [[crossedit]]). [[CFJavaEditor]] (soon to be replaced with [[Gridarta]]) is used more often now. - * http://www.deliantra.net/ deliantra is a fork of crossfire with many improvements, although its not 100% compatible with the old cf. * Get together ([[g2g]]) meeting notes, summary, proposal(s) * [[Content migration]] TODO list IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/start?rev=1192485593 New Revision: http://wiki.metalforge.net/doku.php/start -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Oct 17 21:35:13 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 17 Oct 2007 21:35:13 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page added: map-technical Message-ID: <1192674913.896457.9684.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/17 21:35 User : kbulgrien Edit Summary: Created from trunk server/doc/Developers/map-technical ======TECHNICAL INFORMATION ABOUT MAPS====== This documented is intended to convey technical information on how crossfire deals with the map objects and objects placed on the maps. For the most part, I only intend document how the new code works, and not go too much into history on the older methods. A lot of the map code was re-written in early July 2001, which changed how many things are dealt with. Mark Wedel July 7, 2001 =====1. Map Header===== The map header is the section at the start of the map file that describes the maps characteristics. The values are described below. The map variables now make some sense, and are only stored in the map structure itself. I still include the old value (the 'was') so if you are looking at old maps, you know what they mean. Generally speaking, the values in the map files themselves match the same element name in the map structure. 'width','height', was 'x','y': Size of the map. 'enter_x', 'enter_y', was ('hp','sp') = (x,y) of the destination on the new map. These are only used if the exit does not have a specific location set. 'reset_timeout', was 'weight': stores the number of seconds that need to elapse before this map will be reset. Ie, if 1800, it means this map expires after 30 minutes. This value is not modified once loaded - instead reset_time is used to track this. The value 0 means to use a default timeout (MAP_DEFAULTRESET). 'swap_time', was 'value': This controls how many ticks must elapse after the map has not been used before it gets swapped out. Swapping out is different than reset, as a swapped out map will get loaded back into memory if someone re-visits it before it is due to reset. 'difficulty', was 'level' stores the map difficulty. If not set to anything, the server code will try to come up with some difficulty value. 'fixed_resettime', was 'stand_still': If nonzero, the map reset time will not be updated when someone enters/exits the map. Thus, once the map has been loaded, it will reset in 'reset time' no matter what access happen. This is useful for shops and towns, which are constantly accessed, but should be reset periodically. 'darkness', was 'invisible'. Light/darnkess of map (overall). If 0, all of map is fully bright. 'unique' - if set, this entire map is unique. Exactly unique to what will depend on how it was created (it could be a per player unique map, or maybe a common map that is just permanent for all the players. 'nosmooth' - if set, no faces in this map will be smoothed. 'outdoor' - if set, this is a hint that this is an outdoor map. If this is not set, weather and dawn/dusk will not occur on this map. It is highly advised that this be set appropriately. tile_path_ - Used with map tiling. is a number, 1 is north, 2 is east, 3 south, 4 west. This determines what map is tiled in that direction. See the section below for more information about map tiling. 'shopitems', 'shopgreed', 'shoprace', 'shopmin', 'shopmax' - the type of thing the shop trades in, see doc/Developers/shops for more details 'temp' - The base temperature in farenhiet for this map. The temperature is modified by the season and weather conditions. In a map without weather effects, this temperature will be used as the static temperature for the entire map. This can be useful to make an ice cave actually cold. 'pressure' - This should really never be set on a map. The pressure in millibars. 'humid' - Again, should rarely be set on a map. The humidity in percent. 'windspeed' - Rarely set. The windspeed in kph/h. 'winddir' - Rarely set. Direction of wind, 1-8, 1 is north, clockwise. 'sky' - The sky conditions for this map. See weather.h. Don't set this unless you really know what you are doing. =====2. Map Objects===== The objects within the map are saved in standard 'object save' form (same as is used for the players objects). Other files document the actual meaning, but the general form is: arch x y end Note that x and y are in fact optional. If not present, the values default to zero. ====Multipart objects==== Multipart objects pose a tricky problem, in that they have to appear together in the map file - this makes proper handling of layers hard to deal with. In old map code, all the single spaces objects were saved, and then all the multi part objects were saved. This effectively means that the multi part objects always ended up on top. The multipart objects were saved with all their parts. For example: slaying shops/magicshop hp 14 sp 14 x 1 y 13 end More arch store_magic_2 name Magic Shop slaying shops/magicshop hp 14 sp 14 x 2 y 13 end This method does not work very well with the map tiling however (how do you reasonably deal with a monster that may be straddling the two maps?) Current code now only saves the head of the object. When the map is loaded, the objects on the map are examined to see what objects need to have more objects added on. Additional parts linked in are put just above floor level when linked in, so things like shops won't hide items that someone drops on them. For monsters, this linking shouldn't be a problem - once they start moving, they will get relinked as normal (on top). The effect of saving only the head does have the effect of not being able to customize the non head parts of the object. This generally should not be a problem (in the case of shops/building, the exit code now knows to look only at the head for valid information). The case where this may not work as well as expected is for buildings where setting the move_block to non-archetype defaults will get lost. =====3. Map Tiling====== Map tiling is a feature that lets multiple maps be connected, effectively forming a much larger single map. This is most useful for the outdoor world maps, where it is not practical to have on massive map, but the old style tiling method (copying areas of the adjoining map to the next one) are not very efficient. The transfer of objects from one map to another tiled map are automatic. Presuming the proper macros are used (out_of_map, get_map_..), minimal extra work is necessary for everything to work right. Notes: Tiled maps must be the same width/height along the side they are tiled with. If map1 has a height of 15, and you want to tile along one of the sides, the map(s) it gets tiled with along that side should also be 15. Given the following diagram (not to scale): +---x1----+----x2---+ | | | | map1 | map2 y2 y1 | | | | | +---------+---------+ x1 is the width of map1, y1 is its height. x2 is the width of map2, y2 is its height. map1 will tile map2 as indicated in the above diagram. Given that, the following must be true: y1 must equal y2 x1 must be greater than 12 x2 must be greater than 12 x1 and x2 do not need to be equal The value is derived as being half the maximum viewable area. The reason for this is that the line of sight code (and likely some other code) will only look one map away from a source coordinate. While the values can be less than 12, they should be at least 12 if the map tiles with another one in that direction. If the map is an 'end' map (ie, no further tiling in a specific direction), then having a value less than 12 should work just fine. Note that tiles maps do not have to be symmetric - several maps could tile to a common map. That common map can only tile back to one of those. And example of where this might be used is for a courtyard of a multi floor house - that courtyard should be visible (and be the same) from all the levels, but you can only go from the courtyard to first floor rooms off the courtyard. This may not be ideal (ie, if flying, you should be able to go to any floor), but this tiling for elevation is just an example that can be used. =====4. Stacking of Objects on the Map===== The stacking of objects on a map is somewhat confusing. This is because there are really two stacks a designer may care about - the actual stacking of objects on the map (as op->above points to) and the stacking of objects as they appear to the client. It is usually the appearance in the client the designers care most about. However, actual stacking in the code can be important - some objects only look for objects above them - if you put a teleporter above a sword, that is different than if you put the teleporter below the sword. When loading a map from disk, the server will keep the same stacking order as set in the map. Note however that multipart (big) objects are handled specially - because only the head of the object is saved, the stacking for the non head objects is always right above the floor. So if you put a troll down, with its head above a sword, when the rest of it is linked in, those other parts will be below any items on the ground. Additional objects put on the space during play will generally be in stack order - newest object is on top. The one real exception is that flying objects (spells typically) will always be put on the top of the space, and then followed by non flying objects. So if a sword is dropped on a space with a bunch of active spell objects, within the server stacking, the sword will be below the spell objects, but above other objects on the space. This ordering of objects in the server has little relation to how things appear in the client. With the client (and map2 protocol command), there are 10 visible layers, displayed in following order (from bottom up): Floor (by definition, nothing beneath a floor is visible) no_pick (2) - things like signs, savebeds, runes item (3) - swords, armor, scrolls, arrows, etc living (2) - monsters fly (2) - spells, arrows, some monsters The number in parentheses are the number of layers for those type of objects. So while there are 10 visible layers, in most cases, at least a few will not be used. If there are 50 items (swords, bows) on a space, the client will still only be sent information on 3 of them. It will not use the other layers, as only items will be sent in the items layer. In most all cases, the server automatically figures out what layer an object belongs to based on various flags (FLAG_IS_FLOOR, FLAG_NO_PICK, etc). An object/map maker can override these values with the 'map_layer' object parameter. For example, if a map maker wanted to make what appears to be a flying statue, they would just put in 'map_layer fly' in the object definition. The names listed above are the correct names used for the loading of objects. There can be other cases where map maker want to change layering. A current case is levitation boots - because they seem to fly, they would normally always be drawn on top of other objects. The archetype sets the map_layer flag to item, so that they will be drawn with the rest of the pickable objects. In cases of there being more objects of a type than can be displayed on a space, the first fallback is to look at the visibility of the defined face. Visibility is a face, not object, attribute, but is used when certain objects should take viewing precedence over others. An example of its use is buildings and exits - you pretty much always want those visible, even if there are other non-pickable objects on the space (or a player casts some runes). If the visibility for the face is the same, the last fallback is server (map) stacking. In this case, the object on the top of the stack will take precedence of objects further down. Note however that visibility is always used to put important objects higher on the space as far as the clients sees them. For example, suppose we have the following space with objects with the hypothetical visibilities: mace (50) sword (50) bow (100) shield (50) floor (50) (this is included just to make stacking order clear). One might look at that and think that since shield is at the bottom and doesn't have high visibility, order would be mace, sword, bow, floor (shield getting dropped). But that is not the case - the high visibility of the bow causes it to be virtually placed above the other objects in the map view, so actual view would be bow, mace, sword, floor. Because visibility is not an object attribute, there is generally little that can be done to control this, other than to set up the appropriate stacking. IP-Address : 70.254.34.228 Old Revision: none New Revision: http://wiki.metalforge.net/doku.php/map-technical -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Oct 17 21:38:20 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 17 Oct 2007 21:38:20 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map-technical Message-ID: <1192675100.334974.9687.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/17 21:38 User : kbulgrien Edit Summary: Add a couple section headings for Layers and Visibility @@ -127,8 +127,10 @@ When loading a map from disk, the server will keep the same stacking order as set in the map. Note however that multipart (big) objects are handled specially - because only the head of the object is saved, the stacking for the non head objects is always right above the floor. So if you put a troll down, with its head above a sword, when the rest of it is linked in, those other parts will be below any items on the ground. Additional objects put on the space during play will generally be in stack order - newest object is on top. The one real exception is that flying objects (spells typically) will always be put on the top of the space, and then followed by non flying objects. So if a sword is dropped on a space with a bunch of active spell objects, within the server stacking, the sword will be below the spell objects, but above other objects on the space. + + ====Layers==== This ordering of objects in the server has little relation to how things appear in the client. With the client (and map2 protocol command), there are 10 visible layers, displayed in following order (from bottom up): Floor (by definition, nothing beneath a floor is visible) @@ -145,8 +147,10 @@ There can be other cases where map maker want to change layering. A current case is levitation boots - because they seem to fly, they would normally always be drawn on top of other objects. The archetype sets the map_layer flag to item, so that they will be drawn with the rest of the pickable objects. In cases of there being more objects of a type than can be displayed on a space, the first fallback is to look at the visibility of the defined face. Visibility is a face, not object, attribute, but is used when certain objects should take viewing precedence over others. An example of its use is buildings and exits - you pretty much always want those visible, even if there are other non-pickable objects on the space (or a player casts some runes). + + ====Visibility==== If the visibility for the face is the same, the last fallback is server (map) stacking. In this case, the object on the top of the stack will take precedence of objects further down. Note however that visibility is always used to put important objects higher on the space as far as the clients sees them. For example, suppose we have the following space with objects with the hypothetical visibilities: mace (50) IP-Address : 70.254.34.228 Old Revision: http://wiki.metalforge.net/doku.php/map-technical?rev=1192674911 New Revision: http://wiki.metalforge.net/doku.php/map-technical -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Oct 17 22:04:43 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 17 Oct 2007 22:04:43 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map-technical Message-ID: <1192676683.582757.9848.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/17 22:04 User : kbulgrien Edit Summary: Pull in trunk/server/doc/Developers/Smooth.tex and de-tex (mostly). @@ -1,12 +1,12 @@ - ======TECHNICAL INFORMATION ABOUT MAPS====== + ======Technical Information About Maps====== This documented is intended to convey technical information on how crossfire deals with the map objects and objects placed on the maps. For the most part, I only intend document how the new code works, and not go too much into history on the older methods. A lot of the map code was re-written in early July 2001, which changed how many things are dealt with. Mark Wedel July 7, 2001 - =====1. Map Header===== + ======1. Map Header====== The map header is the section at the start of the map file that describes the maps characteristics. The values are described below. The map variables now make some sense, and are only stored in the map structure itself. I still include the old value (the 'was') so if you are looking at old maps, you know what they mean. Generally speaking, the values in the map files themselves match the same element name in the map structure. @@ -46,9 +46,9 @@ 'winddir' - Rarely set. Direction of wind, 1-8, 1 is north, clockwise. 'sky' - The sky conditions for this map. See weather.h. Don't set this unless you really know what you are doing. - =====2. Map Objects===== + ======2. Map Objects====== The objects within the map are saved in standard 'object save' form (same as is used for the players objects). Other files document the actual meaning, but the general form is: arch @@ -58,9 +58,9 @@ end Note that x and y are in fact optional. If not present, the values default to zero. - ====Multipart objects==== + =====Multipart objects===== Multipart objects pose a tricky problem, in that they have to appear together in the map file - this makes proper handling of layers hard to deal with. In old map code, all the single spaces objects were saved, and then all the multi part objects were saved. This effectively means that the multi part objects always ended up on top. The multipart objects were saved with all their parts. For example: @@ -85,9 +85,9 @@ This method does not work very well with the map tiling however (how do you reasonably deal with a monster that may be straddling the two maps?) Current code now only saves the head of the object. When the map is loaded, the objects on the map are examined to see what objects need to have more objects added on. Additional parts linked in are put just above floor level when linked in, so things like shops won't hide items that someone drops on them. For monsters, this linking shouldn't be a problem - once they start moving, they will get relinked as normal (on top). The effect of saving only the head does have the effect of not being able to customize the non head parts of the object. This generally should not be a problem (in the case of shops/building, the exit code now knows to look only at the head for valid information). The case where this may not work as well as expected is for buildings where setting the move_block to non-archetype defaults will get lost. - =====3. Map Tiling====== + ======3. Map Tiling======= Map tiling is a feature that lets multiple maps be connected, effectively forming a much larger single map. This is most useful for the outdoor world maps, where it is not practical to have on massive map, but the old style tiling method (copying areas of the adjoining map to the next one) are not very efficient. The transfer of objects from one map to another tiled map are automatic. Presuming the proper macros are used (out_of_map, get_map_..), minimal extra work is necessary for everything to work right. @@ -118,9 +118,9 @@ The value is derived as being half the maximum viewable area. The reason for this is that the line of sight code (and likely some other code) will only look one map away from a source coordinate. While the values can be less than 12, they should be at least 12 if the map tiles with another one in that direction. If the map is an 'end' map (ie, no further tiling in a specific direction), then having a value less than 12 should work just fine. Note that tiles maps do not have to be symmetric - several maps could tile to a common map. That common map can only tile back to one of those. And example of where this might be used is for a courtyard of a multi floor house - that courtyard should be visible (and be the same) from all the levels, but you can only go from the courtyard to first floor rooms off the courtyard. This may not be ideal (ie, if flying, you should be able to go to any floor), but this tiling for elevation is just an example that can be used. - =====4. Stacking of Objects on the Map===== + ======4. Stacking of Objects on the Map====== The stacking of objects on a map is somewhat confusing. This is because there are really two stacks a designer may care about - the actual stacking of objects on the map (as op->above points to) and the stacking of objects as they appear to the client. It is usually the appearance in the client the designers care most about. However, actual stacking in the code can be important - some objects only look for objects above them - if you put a teleporter above a sword, that is different than if you put the teleporter below the sword. @@ -128,9 +128,9 @@ When loading a map from disk, the server will keep the same stacking order as set in the map. Note however that multipart (big) objects are handled specially - because only the head of the object is saved, the stacking for the non head objects is always right above the floor. So if you put a troll down, with its head above a sword, when the rest of it is linked in, those other parts will be below any items on the ground. Additional objects put on the space during play will generally be in stack order - newest object is on top. The one real exception is that flying objects (spells typically) will always be put on the top of the space, and then followed by non flying objects. So if a sword is dropped on a space with a bunch of active spell objects, within the server stacking, the sword will be below the spell objects, but above other objects on the space. - ====Layers==== + =====Layers===== This ordering of objects in the server has little relation to how things appear in the client. With the client (and map2 protocol command), there are 10 visible layers, displayed in following order (from bottom up): Floor (by definition, nothing beneath a floor is visible) @@ -148,9 +148,9 @@ There can be other cases where map maker want to change layering. A current case is levitation boots - because they seem to fly, they would normally always be drawn on top of other objects. The archetype sets the map_layer flag to item, so that they will be drawn with the rest of the pickable objects. In cases of there being more objects of a type than can be displayed on a space, the first fallback is to look at the visibility of the defined face. Visibility is a face, not object, attribute, but is used when certain objects should take viewing precedence over others. An example of its use is buildings and exits - you pretty much always want those visible, even if there are other non-pickable objects on the space (or a player casts some runes). - ====Visibility==== + =====Visibility===== If the visibility for the face is the same, the last fallback is server (map) stacking. In this case, the object on the top of the stack will take precedence of objects further down. Note however that visibility is always used to put important objects higher on the space as far as the clients sees them. For example, suppose we have the following space with objects with the hypothetical visibilities: mace (50) @@ -163,5 +163,86 @@ But that is not the case - the high visibility of the bow causes it to be virtually placed above the other objects in the map view, so actual view would be bow, mace, sword, floor. Because visibility is not an object attribute, there is generally little that can be done to control this, other than to set up the appropriate stacking. + + ======5. Smoothing====== + + Author Tchize + Date: Seven of July 2003 + + =====Introduction to Smoothing===== + + The crossfire graphical interface and internal map handling relies on a map made of square. No object can lies between squares. A typical square has the size of a standing player or other humano?d sized creature (Goblins, Orcs, Gnolls, Dwarvens, Elves, ...). This lead to an awful interface concerning terrains transitions (Sea shores, road borders, mountains, a.s.o) + + There are 2 ways to get rid of this problem: + + * Suppress the square by square behavior of map handling. This means rework half of Crossfire code and redraw all maps + * Use some magic illusion. + + =====What is Smoothing===== + + Large discussions in the cf-devel mailing list was around a document on terrain transitions available on [http://www.gamedev.net/reference/articles/article934.asp]. + It explains a way of handling terrain transition in cases like the one of Crossfire. + + Consider the smoothing in Crossfire as the ability for an object to draw itself partially above the surrounding squares. For example, grass could overlap just a bit the road next to it, a mountain would not end abruptly but instead would have some hills above the neighbor sand. + + =====How to Smooth?===== + + Next of this document is divided in 2 parts. Drawers should be interested only in first part while developers may be interested in both parts. + + ====Basic Smoothing==== + + Basically, there need to be some order for smoothing. If everything draws itself above every surrounding square, we would end up with some awful bunch of crappy disgusting mixture of color (a Picasso or alike). + + So, we come to the... + + ===First Rule of Smoothing=== + + An object O may draw itself above a neighbor object V if, and only if, 0 as a <> higher than V. See the things like that: + + {img/smoothlevel.eps} + + O in the example picture has a higher priority than V so O will overlap V a bit but V will not overlap O. + + The smoothlevel is an integer value ranging from 0 (overlap nothing) to 255 (overlap above everything except other objects having also smoothlevel of 255). This is important to consider when you are going to give the smoothing ability to new objects. Let's say, for example, you want to add this ability to mountains. Let's imagine has a smoothlevel of 10 and trees have a smoothlevel 100 (just imagine, at time writing this doc, nothing fixed yet). Now let's say you want the mountains above the grass but, for graphical reasons, you want the trees above the mountains. You Choose a value between 10 and 100, not included. But mountains is a thing that goes above a lot of thing (grass, hills, swamps, brush, rocks, desert,...). So to keep the place for adding new elements in the future, you rather choose a high value for mountains (90 seems a good value according to these conditions). + + So now you have chosen the smoothlevel for the mountain. What are you supposed to draw? You know what overlap what is decided by smoothlevel. But the graphics used during the smoothing is the... + + ===Second Rule of Smoothing=== + + The picture used to draw a given object depend on the face of the object. All objects using the grass face, for example, if they have a smoothlevel higher than 0, will be smooth using the same pictures. So you will bind with the picture grass.111 a set of pictures telling the client what to draw when smoothing an object having the face grass.111. + + Take a look at the canvas below: + + {img/canvas_smooth.eps} + + Each square have a size of 32x32, which is the size used by the current image sets. This canvas handles all cases of corner, borders, L shaped, U shaped and O shaped transitions. The picture is made of 16 elements by 2. The first line is all broder related transition. The second line is corner related transitions. Here is an example picture for grass (yeah really need someone to rework it): + + {img/sgrass.base.111.eps} + + The picture is named sgrass.base.111.png and located in the ground/smooth/grasslike directory of archetype. Ok, now you have a picture for smoothing grass, you have a smoothlevel for grass. There is only one last thing to do: + + ===Final Rule of Smoothing=== + + Tell the server which picture to send the client. There is, in the server SVN directory a file named lib/smooth. This file is where you set this information. Each line in the file beginning with \emph{\#} is a comment. Other line should be made of 2 elements: + + The first is the picture you want to smooth (here it is grass.111% + + \footnote{Please note we suppressed the .png and the .base. elements of grass.base.111.png filename. Since what the server needs is the internal names. Take care of this. If the new picture you drawn didn't appear on the GUI, this is perhaps due to error in this file. And don't forget to copy this file, afterwards, to the install directory of server, using a make~install.% + + }) the second is the 512x64 picture drawn at rule 2 and used when smoothing. + + And example line might be as follows: + + grass.111 sgrass.111 + + The entry default\_smoothed.111 is used when the server can not find an appropriate entry for an object. This correspond to the black canvas above so mapmakers or drawers can see immediately there is a problem. + + Now, drawers know everything. Coders might want to read following part. + + ====Smoothing in the Code==== + + Guess what... + + TODO IP-Address : 70.254.34.228 Old Revision: http://wiki.metalforge.net/doku.php/map-technical?rev=1192675098 New Revision: http://wiki.metalforge.net/doku.php/map-technical -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Oct 17 22:11:07 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 17 Oct 2007 22:11:07 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map-technical Message-ID: <1192677067.628055.9872.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/17 22:11 User : kbulgrien Edit Summary: Type fixes and more de-texing. @@ -197,9 +197,9 @@ So, we come to the... ===First Rule of Smoothing=== - An object O may draw itself above a neighbor object V if, and only if, 0 as a <> higher than V. See the things like that: + An object O may draw itself above a neighbor object V if, and only if, O has a <> higher than V. See the things like that: {img/smoothlevel.eps} O in the example picture has a higher priority than V so O will overlap V a bit but V will not overlap O. @@ -215,29 +215,27 @@ Take a look at the canvas below: {img/canvas_smooth.eps} - Each square have a size of 32x32, which is the size used by the current image sets. This canvas handles all cases of corner, borders, L shaped, U shaped and O shaped transitions. The picture is made of 16 elements by 2. The first line is all broder related transition. The second line is corner related transitions. Here is an example picture for grass (yeah really need someone to rework it): + Each square have a size of 32x32, which is the size used by the current image sets. This canvas handles all cases of corner, borders, L shaped, U shaped and O shaped transitions. The picture is made of 16 elements by 2. The first line is all border related transition. The second line is corner related transitions. Here is an example picture for grass (yeah really need someone to rework it): {img/sgrass.base.111.eps} The picture is named sgrass.base.111.png and located in the ground/smooth/grasslike directory of archetype. Ok, now you have a picture for smoothing grass, you have a smoothlevel for grass. There is only one last thing to do: ===Final Rule of Smoothing=== - Tell the server which picture to send the client. There is, in the server SVN directory a file named lib/smooth. This file is where you set this information. Each line in the file beginning with \emph{\#} is a comment. Other line should be made of 2 elements: + Tell the server which picture to send the client. There is, in the server SVN directory a file named lib/smooth. This file is where you set this information. Each line in the file beginning with ''#'' is a comment. Other lines should be made of 2 elements: - The first is the picture you want to smooth (here it is grass.111% + The first is the picture you want to smooth (here it is grass.111), and the second is the 512x64 picture drawn at rule 2 and used when smoothing. - \footnote{Please note we suppressed the .png and the .base. elements of grass.base.111.png filename. Since what the server needs is the internal names. Take care of this. If the new picture you drawn didn't appear on the GUI, this is perhaps due to error in this file. And don't forget to copy this file, afterwards, to the install directory of server, using a make~install.% - - }) the second is the 512x64 picture drawn at rule 2 and used when smoothing. + * Note Please note we suppressed the .png and the .base. elements of grass.base.111.png filename. Since what the server needs is the internal names. Take care of this. If the new picture you drawn didn't appear on the GUI, this is perhaps due to an error in this file. And don't forget to copy this file, afterwards, to the install directory of server, using a make~install. And example line might be as follows: grass.111 sgrass.111 - The entry default\_smoothed.111 is used when the server can not find an appropriate entry for an object. This correspond to the black canvas above so mapmakers or drawers can see immediately there is a problem. + The entry default ''smoothed.111'' is used when the server can not find an appropriate entry for an object. This correspond to the black canvas above so mapmakers or drawers can see immediately there is a problem. Now, drawers know everything. Coders might want to read following part. ====Smoothing in the Code==== IP-Address : 70.254.34.228 Old Revision: http://wiki.metalforge.net/doku.php/map-technical?rev=1192676681 New Revision: http://wiki.metalforge.net/doku.php/map-technical -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sat Oct 20 05:26:12 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 20 Oct 2007 05:26:12 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:python_guilds Message-ID: <1192875972.417834.18282.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/20 05:26 User : ryo Edit Summary: update @@ -3,5 +3,14 @@ Quite a bit of framework is already in place to add new features to the Crossfire guild system. However, this functions hasn't seen any development or updates for quite some time. This TODO was setup to re-implement and update what has been started. + + Update 2007-10-20: guilds should be ok, minor bugs may be left. + + Hint for guild installation: + * ''cd /path/to/guild/to/create'' + * ''cp /maps/templates/guild/* .'' + * ''sed -i s/GUILD_TEMPLATE/guildname *'' + * ''vi /maps/templates/GuildList'' and add ''guildname'' to the end + ===== Features ===== Here's a summary of what features are available, but listed as what works and what does not work. @@ -9,11 +18,11 @@ ==== What is Broken ==== These are showstopper|critical bugs - - (MAJOR) Python script or function to track, update and maintain member management; this includes the guard at the entrance to keep non-members out of the guild - - (MEDIUM) Guild Oracle - a nice feature, but useless unless the bug listed above is fixed - - (MEDIUM) Guild Dues - a nice feature, but useless unless the bug listed above is fixed + - (MAJOR) Python script or function to track, update and maintain member management; this includes the guard at the entrance to keep non-members out of the guild + - (MEDIUM) Guild Oracle - a nice feature, but useless unless the bug listed above is fixed + - (MEDIUM) Guild Dues - a nice feature, but useless unless the bug listed above is fixed - should be ok, to check ==== What Works ==== * Python script or function for initial purchase of guild @@ -45,44 +54,46 @@ * basement, drop a Firestar named Fearless for the Big Chest * Other areas have not been tested ==== Incomplete ==== + + This is probably not uptodate --- //[[nicolas.weeger at laposte.net|Ryo Saeba]] 2007/10/20 05:18// "Broken Altars" - it appears that it has been undecided on what exactly should be used or dropped to gain access to the following: - * mainfloor, drop x for a mailbox + * mainfloor, drop x for a mailbox * This works, just need to determine what "x" is - * mainfloor, drop x for basement stairs + * mainfloor, drop x for basement stairs * This works, just need to determine what "x" is - * mainfloor, drop x for a forge + * mainfloor, drop x for a forge * Requires the "connection" to be re-matched between the altar <-> creator and then between the check inventory <-> gate, the keystring is already matched correctly * Forge room works now, just need to determine what "x" is - * mainfloor, drop x for workbench + * mainfloor, drop x for workbench * Requires the "connection" to be re-matched between the altar <-> creator and then between the check inventory <-> gate, the keystring has to be updated as well between the creator <-> check inventory * Workbench room works now, just need to determine what "x" is - * mainfloor, drop x for a message board - * mainfloor, drop x for stove + * mainfloor, drop x for a message board + * mainfloor, drop x for stove * Requires the "connection" to be re-matched between the altar <-> creator, inventory check between inventory <-> gate worked * after purchasing the altar, a woodfloor tile drops in it's place and surrounded by grass; this is still a problem * after dropping the token to gain access to the stove area, a woodfloor now appears which is intended (fixed) - * mainfloor, Toolshed Token (found in Guild_HQ) + * mainfloor, Toolshed Token (found in Guild_HQ) * Note: the first gate opens for everyone, it's the second gate that requires the Toolshed token to be turned in for it to open * mis-matched slaying field on the altar (slaying Toolshed_token) and the name of the Token (Toolshed Token)- now fixed * Fixed the problem where othe rnearby pay altars would disappear when the toolshed was "purchased" - * mainfloor, Garden Token (found in Guild_HQ) + * mainfloor, Garden Token (found in Guild_HQ) * mis-matched slaying field on the altar (slaying garden_token) and the name of the Token (Garden Token) - * mainfloor, drop 5 tissue paper for a portal to the Pupland Terminal - requires bolt_silk instead of tissue paper - * secondfloor, drop 20 amulets of Lifesaving for a portal to ? + * mainfloor, drop 5 tissue paper for a portal to the Pupland Terminal - requires bolt_silk instead of tissue paper + * secondfloor, drop 20 amulets of Lifesaving for a portal to ? * This drop spot disappears and is replaced with a second or additional portal to the Mazes of Menace (when 20 amulets of Lifesaving are dropped on it) - * secondfloor, (x 15 y 7) drop x for Alchemy room + * secondfloor, (x 15 y 7) drop x for Alchemy room * Alchemy room works now, just need to determine what "x" is - * secondfloor, (x 11 y 1) drop x for Glowing Crystal Room + * secondfloor, (x 11 y 1) drop x for Glowing Crystal Room * This was updated to allow access to the Glowing Crystal room (was listed as Alchemy room) * Also, one of the tokens from the Guild_HQ was updated and is required as a turn in to gain access to the Glowing Crystal Room * Glowing Crystal Room works like many of the skill areas, pay a price for "day pass" to access the crystal; also have multiple gates in place to protect players and items from the mana explosion - * secondfloor, drop x for Jewelers room + * secondfloor, drop x for Jewelers room * Jewelers room works now, just need to determine what "x" is - * secondfloor, drop x for Thaumaturgy room + * secondfloor, drop x for Thaumaturgy room * Thaumaturgy room works now, just need to determine what "x" is * basement, drop 10 gold coins (for what?) * basement, dropping the Firestar named fearless allows access to BigChest, but I suspect that the drop location of the chest is not as intended because the player is in the way * bigchest, once you enter the chest the exit back to the basement is broken ("closed") @@ -100,4 +111,6 @@ * Please add your suggestion here These maps are now working, you can download them here https://sourceforge.net/tracker/index.php?func=detail&aid=1782975&group_id=13833&atid=313833. There is still some work to do, the kennel for example is still as it was, it seems pretty well useless, but it wasn't hurting anything so I left it alone. + + > should be mostly fixed --- //[[nicolas.weeger at laposte.net|Ryo Saeba]] 2007/10/20 05:18// IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:python_guilds?rev=1189815669 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:python_guilds -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sat Oct 20 12:36:13 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 20 Oct 2007 12:36:13 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:gfx_needing_fixing Message-ID: <1192901774.009682.20900.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/20 12:36 User : ryo Edit Summary: update @@ -106,33 +106,33 @@ | close_dbox.111 | | close_bag.111 | | close_pouc.111 | | close_quiv.111 | - | close_rsack.111 | - | close_sack.111 | - | closemail.111 | + | close_rsack.111 | + | close_sack.111 | + | closemail.111 | === Doesn't represent what it is === Faces that do not look like the object they represent, or archetypes using a face as a placeholder. == Needs to be opened == The following containers' faces should appear to be open, and need a new face. (archetypes listed below) ^ archetype ^ - | close_desk | - | close_wizdesk | - | close_desk_cw | - | close_dresser | - | close_dresser2 | - | close_dresser_cw | - | close_dresser2_cw | - | close_present_box_1 | - | close_present_box_2 | - | close_present_box_3 | - | close_present_box_4 | - | close_present_box_5 | - | close_present_box_6 | - | close_sarcophagus_container | - | close_schest | + | close_desk | + | close_wizdesk | + | close_desk_cw | + | close_dresser | + | close_dresser2 | + | close_dresser_cw | + | close_dresser2_cw | + | close_present_box_1 | + | close_present_box_2 | + | close_present_box_3 | + | close_present_box_4 | + | close_present_box_5 | + | close_present_box_6 | + | close_sarcophagus_container | + | close_schest | ===== Classic Tileset ===== This tileset is missing LOTS of faces, thus people see question marks replacing those faces. IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing?rev=1192392927 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sat Oct 20 15:13:13 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 20 Oct 2007 15:13:13 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:gfx_needing_fixing Message-ID: <1192911193.990317.21580.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/20 15:13 User : ryo Edit Summary: update @@ -96,9 +96,9 @@ === The Ugly === Put stuff here that you think is just plain ugly, thus you think it should be redone. ^ what ^ why ^ - | crea_serp_c | DUDE YOU HAVE TO BE BLIND IF YOU DON'T THINK THIS IS UGLY!!!!!!1111 (Its like it was left over from the monochrome bitmap days of crossfire.) | + | crea_serp_c | DUDE YOU HAVE TO BE BLIND IF YOU DON'T THINK THIS IS UGLY!!!!!!1111 (Its like it was left over from the monochrome bitmap days of crossfire.) | == Opened Containers == These are ugly, and don't look like their closed counterpart. ^ face/animation ^ IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing?rev=1192901770 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Oct 21 14:47:06 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 21 Oct 2007 14:47:06 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:objects Message-ID: <1192996026.480204.26236.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/21 14:47 User : meflin Edit Summary: @@ -753,11 +753,8 @@ type is 0 (no material) or is Adamantite, the object can not be harmed in any way. An object can have multiple material types by adding these values together. - - - ===== Item Power (item_power) ===== item_power measures how powerful and item is. This information is only @@ -796,8 +793,18 @@ * 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 + + These properties have the following enchantment value + *lifesaving 5 + *reflect spells 3 + *reflect missiles 2 + *stealth 1 + *xray vison 2 + *see in dark 1 + *invisibility 1 + 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, @@ -805,8 +812,9 @@ effects an item has may reduce the item power. Eg, a 'sword +4 (str +2)(wis -3)' would really be 3 enchantments. FIXME add settings explanation, ensure information is correct :) + ===== Body Location ===== The body locations information determines where the item is equipped onto IP-Address : 71.229.157.100 Old Revision: http://wiki.metalforge.net/doku.php/dev:objects?rev=1187783223 New Revision: http://wiki.metalforge.net/doku.php/dev:objects -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Oct 24 17:06:49 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 24 Oct 2007 17:06:49 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:gfx_needing_fixing Message-ID: <1193263609.715894.10330.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/24 17:06 User : ryo Edit Summary: update @@ -9,9 +9,9 @@ Graphics that need the angle they appear at to be changed (and possibly other things). Most of these where probably not converted from the classic tileset yet. ^ What ^ Why ^ | bagpipe | Needs new perspective Doesn't fit in, lacks detail, ugly. | - | the cannons (cannon_0.111, etc) | Only left/right facing but archetypes for aiming in every direction, all look flat. | + | the cannons (cannon_0.111, etc) | Only left/right facing but archetypes for aiming in every direction, all look flat. | | chalices (chalice[_*]) | Looks good, but the perspective is messed up (unless it is supposted to be on it's side | | a_bridge1 | too flat | | a_bridge2 | too flat | | ten_kilo | flat | IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing?rev=1192911191 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Oct 25 16:30:21 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 25 Oct 2007 16:30:21 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:functions_implemented_but_not_yet_used Message-ID: <1193347821.748449.14704.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/25 16:30 User : ryo Edit Summary: update @@ -42,4 +42,30 @@ Supposedly used to generate a newspaper. Uses cflogger to find information. Pre-alpha version, doesn't do much. ===== advanced NPC dialogs ===== See [[:cfdialog]] for more info. + + ===== use command ===== + (trunk only) + + Through the ''use'' command, it is possible to define complex item transformations. + + ''use'' will work on 2 items, which will be called ''item1'' and ''item2'.' + + Syntax for command is 'use item1 with item2'. + + item2 is searched for a key/value of the form, in this order: + * on_use_with_ + * on_use_with__ + * on_use_with_ + + If no key is found, use will simply not do anything. + + If a key is found, it's processed to know what to do. + + Syntax of the value is pretty simple: + * add [number] archetype: will give the player [number] items of archetype specified + * remove $1: will remove one item1 + * remove $2: will remove one item2 + + Note that remove can appear multiple times, but you can't specify a precise number to remove. + IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:functions_implemented_but_not_yet_used?rev=1187648303 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:functions_implemented_but_not_yet_used -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Oct 28 09:55:37 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 28 Oct 2007 09:55:37 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: cfdialog Message-ID: <1193583337.392674.26141.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/28 09:55 User : ryo Edit Summary: update @@ -15,17 +15,21 @@ ''from CFDialog import DialogRule, Dialog'' Then, you can go to the dialogs themselves. A dialog is made of several rules. Each rule is made of keywords, preconditions, - postconditions, and answers. + postconditions, answers and pre/postfunction. * **Keywords** are what the rule will be an answer to. For example, if you want a rule to be triggered when the player will say "hi", then "hi" is the keyword to use. You can associate more than a keyword to a rule by concatenating them with the "|" character. Finally, "*" is a special keyword that means: "match everything". "*" is useful to provide generic answers. * **Answers** are what will be said when the rule is triggered. This is what the NPC replies to the player. Answers are stored in a list. When there is more than one answer in that list, one will be selected at random. * **Preconditions** are flags that must match for the rule to be triggered. Each precondition has a name and a value. The default value of a precondition is "0". The flags are stored into each player, and will survive between gaming sessions. They are useful to set the point in a dialog reached by a player - you can see those as an "NPC memory". All conditions must have a name and a value. The ":" and ";" characters are forbidden. For a rule to be triggered, all the player's flags should match the preconditions. If you give "*" as the value for a precondition, it means that there is no need to match it. A precondition is a list in the form: [key, value]. All preconditions are stored in a list. Note that you can use any string you want for the condition values, provided it doesn't contain ";" or ":". * **Postconditions** are the status changes to apply to the player's conditions after the rule has been triggered. Their format is similar to preconditions. A value of "*" means that the condition will not be touched. + + * A **prefunction** is an optional callback function that will be called when a rule's preconditions are all matched, but before the rule is validated. The callback can do additional tests, and should return 1 to allow the rule + to be selected, 0 to block the rule. The function arguments are the player and the actual rule being tested. + * A **postfunction** is an optional callback that is called when a rule has been applied, and after the message is said. It can do additional custom .processing. The function arguments are the player and the actual rule having been used. Once you have defined your rules, you have to assemble them into a dialog. Each dialog involves somebody who triggers it, somebody who answers, and has a unique name so it cannot be confused with other dialogs. Typically, the "one who triggers" will be the player, and the "one who answers" is an NPC the player was taking to. You are free to chose whatever you want for the dialog name, as long as it contains no space or special characters, and is not used by another dialog. You can then add the rules you created to the dialog. Rules are parsed in a given order, so you must add the most generic answer last. @@ -114,5 +118,4 @@ * The conversation state is stored in your player file. For example: $ grep -ri test_grandpa var var/crossfire/players/Player/Player.pl:dialog_test_grandpa_01 hello:1 - IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/cfdialog?rev=1187764447 New Revision: http://wiki.metalforge.net/doku.php/cfdialog -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Oct 28 09:57:46 2007 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 28 Oct 2007 09:57:46 -0500 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: cfdialog Message-ID: <1193583466.646123.26144.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2007/10/28 09:57 User : ryo Edit Summary: update @@ -25,10 +25,9 @@ * **Preconditions** are flags that must match for the rule to be triggered. Each precondition has a name and a value. The default value of a precondition is "0". The flags are stored into each player, and will survive between gaming sessions. They are useful to set the point in a dialog reached by a player - you can see those as an "NPC memory". All conditions must have a name and a value. The ":" and ";" characters are forbidden. For a rule to be triggered, all the player's flags should match the preconditions. If you give "*" as the value for a precondition, it means that there is no need to match it. A precondition is a list in the form: [key, value]. All preconditions are stored in a list. Note that you can use any string you want for the condition values, provided it doesn't contain ";" or ":". * **Postconditions** are the status changes to apply to the player's conditions after the rule has been triggered. Their format is similar to preconditions. A value of "*" means that the condition will not be touched. - * A **prefunction** is an optional callback function that will be called when a rule's preconditions are all matched, but before the rule is validated. The callback can do additional tests, and should return 1 to allow the rule - to be selected, 0 to block the rule. The function arguments are the player and the actual rule being tested. + * A **prefunction** is an optional callback function that will be called when a rule's preconditions are all matched, but before the rule is validated. The callback can do additional tests, and should return 1 to allow the rule to be selected, 0 to block the rule. The function arguments are the player and the actual rule being tested. * A **postfunction** is an optional callback that is called when a rule has been applied, and after the message is said. It can do additional custom .processing. The function arguments are the player and the actual rule having been used. Once you have defined your rules, you have to assemble them into a dialog. Each dialog involves somebody who triggers it, somebody who answers, and has a unique name so it cannot be confused with other dialogs. IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/cfdialog?rev=1193583333 New Revision: http://wiki.metalforge.net/doku.php/cfdialog -- This mail was generated by DokuWiki at http://wiki.metalforge.net/