From no-reply_wiki at metalforge.org Tue Jan 1 22:44:22 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 01 Jan 2008 22:44:22 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: cfdialog Message-ID: <1199249062.121527.17085.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/01 22:44 User : kbulgrien Edit Summary: Note \n usable in NPC message text. @@ -5,8 +5,9 @@ complex dialogs. It is made for those who do not want to bother about complex programming, but just want to make a few dialogs that are better than the @match system used in the server. + ==== How to use this. ==== First, you need to import DialogRule and Dialog classes. Add the @@ -20,8 +21,9 @@ * **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. + * Insert newlines in an answer with **\n**. * **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. IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/cfdialog?rev=1193583465 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 Thu Jan 3 18:04:06 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 03 Jan 2008 18:04:06 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: guides Message-ID: <1199405046.386129.5879.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/03 18:04 User : eracc Edit Summary: @@ -116,8 +116,9 @@ * [[DM Commands]] ===== Dev Guides ===== This information is not exactly meant for most players, just people making their own maps, or modifications to crossfire. This section is more likely to get outdated. + ==== Maps and Archetypes ==== @@ -127,10 +128,13 @@ * [[Custom Creature Creation]] - Information and guidelines about creating custom creatures. * [[Graphics Guide]] - Information to aid the creation of achetypical art. * [[Item Type Guide]] - Information about how different types and attributes affect objects. * [[Map Scale]] - A note about the scale of maps - * [[Map-Making Guide]] - Notes, details and suggestions on making maps * [[Spell Numbers]] - The "spellnumber" works like an ID, it is needed to specify spells in various object-types. E.g. spellbooks, rods/wands/scrolls, firewalls... etc. + + === Contributing Maps === + * [[Map Making]] - This is a guide on what is an acceptable map and what is unacceptable. Also, how/where to contribute maps. + * [[Map-Making Guide]] - Notes, details and suggestions on making maps ==== Code ==== Documentation on the code and coding. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/guides?rev=1197728192 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 Thu Jan 3 18:06:46 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 03 Jan 2008 18:06:46 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map_making Message-ID: <1199405206.966956.5888.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/03 18:06 User : eracc Edit Summary: @@ -3,10 +3,11 @@ Without Maps, there would be nowhere to put monsters now would there. Map making is a rewarding task but there are some things to be aware of... + ===== Map Guide ===== - This is a guide on what is an acceptable map and what is unacceptable. Only acceptable maps will be put in the official Crossfire map distribution + This is a guide on what is an acceptable map and what is unacceptable. Only acceptable maps will be put in the official Crossfire map distribution. Please use the latest release of [[Gridarta]] when making maps to contribute. ==== Entrances and Exits ==== - Check that all exits lead where they are supposed to. Unless there is a specific reason an exit leads only one direction (like a trap door or perhaps a teleporter), players should be able to exit back from where they came from right when they enter the map. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/map_making?rev=1182380536 New Revision: http://wiki.metalforge.net/doku.php/map_making -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 3 18:20:23 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 03 Jan 2008 18:20:23 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map_making Message-ID: <1199406023.599334.5921.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/03 18:20 User : eracc Edit Summary: @@ -6,8 +6,15 @@ ===== Map Guide ===== This is a guide on what is an acceptable map and what is unacceptable. Only acceptable maps will be put in the official Crossfire map distribution. Please use the latest release of [[Gridarta]] when making maps to contribute. + + ==== Directory Structure ==== + + * If a quest is started from a city/town then it should be placed in the city/town directory. + * The dungeons directory would be for non-quests that are not linked to a specific city/town region and that are just experience grinds. + * The quests directory should be used if the quest is not liked to a specific city/town. + ==== Entrances and Exits ==== - Check that all exits lead where they are supposed to. Unless there is a specific reason an exit leads only one direction (like a trap door or perhaps a teleporter), players should be able to exit back from where they came from right when they enter the map. @@ -135,4 +142,7 @@ - Compose an email to crossfire-maps at lists.sourceforge.net and include the map file as an attachment * Try to keep the attachment at 1MB or less in size * If possible, avoid composing the message in HTML format -- this helps keep the mail archives "looking nice" and consistant * If you would like to sign up for the Crossfire Maps mailing list, visit https://lists.sourceforge.net/lists/listinfo/crossfire-maps + + ==== Trunk or Branch ? ==== + Brand new content that has never been seen before and is not an update or patch of existing maps should go into trunk. Updates and patches to existing maps should go into trunk and branch. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/map_making?rev=1199405204 New Revision: http://wiki.metalforge.net/doku.php/map_making -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 3 18:23:20 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 03 Jan 2008 18:23:20 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map_making Message-ID: <1199406200.974904.5924.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/03 18:23 User : eracc Edit Summary: @@ -6,11 +6,13 @@ ===== Map Guide ===== This is a guide on what is an acceptable map and what is unacceptable. Only acceptable maps will be put in the official Crossfire map distribution. Please use the latest release of [[Gridarta]] when making maps to contribute. + ==== Directory Structure ==== + * Maps contained within a city/town should be placed in the city/town directory in the maps tree. * If a quest is started from a city/town then it should be placed in the city/town directory. * The dungeons directory would be for non-quests that are not linked to a specific city/town region and that are just experience grinds. * The quests directory should be used if the quest is not liked to a specific city/town. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/map_making?rev=1199406021 New Revision: http://wiki.metalforge.net/doku.php/map_making -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 3 18:38:09 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 03 Jan 2008 18:38:09 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map_making Message-ID: <1199407089.714528.5945.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/03 18:38 User : eracc Edit Summary: @@ -14,8 +14,47 @@ * Maps contained within a city/town should be placed in the city/town directory in the maps tree. * If a quest is started from a city/town then it should be placed in the city/town directory. * The dungeons directory would be for non-quests that are not linked to a specific city/town region and that are just experience grinds. * The quests directory should be used if the quest is not liked to a specific city/town. + + ==== Regions ==== + Maps that are not wilderness should be assigned a region. Current defined regions are: + + * wilderness + * world + * creation + * highway + * greenway + * scorn + * scorncounty + * streetsofscorn + * scornarena + * scornoldcity + * navar + * brest + * darcap + * darcapcircus + * wolfsburg + * santodominion + * lakecountry + * portjoseph + * pupland + * ancientpupland + * nurnberg + * lonetown + * stoneville + * firevolcano + * azumauindo + * dream + * citydeclouds + * theabyss + * dis + * kingdomofsaints + * kingdomofsaintsborder + * stjohns + * strose + * stbartholomew + * euthville ==== Entrances and Exits ==== IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/map_making?rev=1199406198 New Revision: http://wiki.metalforge.net/doku.php/map_making -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 3 20:23:15 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 03 Jan 2008 20:23:15 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user:leaf Message-ID: <1199413395.548200.6427.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/03 20:23 User : leaf Edit Summary: Removed a feature that is already in place for the python based guilds @@ -39,15 +39,15 @@ * I am focusing mostly on fixing issues and improving existing maps * I also review new maps that are submitted to the Maps mailing list or uploaded to SourceForge's Patch area While I may provide feedback and comments and coding direction on actual code - I'm not a developer in that sense. I do not have the necessary coding background. I do not see that changing in the forseeable future either. ;-P + ===== My TODO List ===== In no particular order... * Add more features to the Python based Guild Templates - * Made the craft tables individual rooms for space purposes and so that the craft "table" (workbench, cauldron, et al) can be swapped out during a map reset if/when it because broken or cursed * Add a new level or area that contains teleporters to other areas within the game * Add a new level or area that is themed or unique to each cult's altar (ex: underground theme for Mostrai's altar) * Improve the basement map since it contains features no one has been able to understand their intent (ex: kennels) IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/user:leaf?rev=1176829469 New Revision: http://wiki.metalforge.net/doku.php/user:leaf -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 3 20:28:30 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 03 Jan 2008 20:28:30 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:python_guilds Message-ID: <1199413710.997925.6436.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/03 20:28 User : leaf Edit Summary: Text and format updates @@ -113,44 +113,36 @@ 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// + ===== Issues related to the Laughing Skull deployment of MF ==== - * buy guild house : - *sign wants 1000 imperials, alter wants 100 amber - - * guildmaster / oracle - *the oracle promote script does not add the guildmaster - object to the player who has been promoted to guildmaster - - - * main floor - *the guild dues script adds the dues to the guild coffers even - when they dues are not taken from the player for insuficent funds - - *"Jack says: Let me know how many imperial you want to pay. Say pay " - needs to be changed to jade , and does not accept jade payments - - *morning after buying the stairs down to the kennel are missing + * buy guild house : + * sign wants 1000 imperials, alter wants 100 amber - *cosmetic : That is You must capture a Hellhound for a basement - remains after buying the stairs to the basement + * guildmaster / oracle + * the oracle promote script does not add the guildmaster object to the player who has been promoted to guildmaster + * main floor + * the guild dues script adds the dues to the guild coffers even when they dues are not taken from the player for insuficent funds + * "Jack says: Let me know how many imperial you want to pay. Say pay " needs to be changed to jade , and does not accept jade payments + * morning after buying the stairs down to the kennel are missing + * cosmetic : That is You must capture a Hellhound for a basement remains after buying the stairs to the basement - *second floor - - * guild dues level / room can not be exited from no WOR ( needed DM help ) - * morning after buying second floor the stairs are closed - blocking further testing of second floor + * second floor - + * guild dues level / room can not be exited from no WOR ( needed DM help ) + * morning after buying second floor the stairs are closed blocking further testing of second floor - *big chest - * exits in the big chest go back to the orginal LS guild (old unique maps ) + * big chest + * exits in the big chest go back to the orginal LS guild (old unique maps ) - *toolshed - *You can dimension door through the windows, granting you free use of the services, and access to the grass outside and across the river even. Just need to make the tiles under the windows deny magic. + * toolshed + * You can dimension door through the windows, granting you free use of the services, and access to the grass outside and across the river even. Just need to make the tiles under the windows deny magic. + * /pup_land/guilds/laughing_skull/guild_toolshed 100pp for entry alters are missing ? (yesterday they where there) - */pup_land/guilds/laughing_skull/guild_toolshed 100pp for entry alters are missing ? ( yesterday they where there + * Unordered List Item IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:python_guilds?rev=1199123935 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 Thu Jan 3 20:34:06 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 03 Jan 2008 20:34:06 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:python_guilds Message-ID: <1199414046.835118.6445.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/03 20:34 User : leaf Edit Summary: Text updates, and replies @@ -113,36 +113,33 @@ 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// + ===== Issues related to the Laughing Skull deployment of MF ==== - * buy guild house : - * sign wants 1000 imperials, alter wants 100 amber + * Buying a guild house + * Sign wants 1000 imperials, alter wants 100 amber - * guildmaster / oracle - * the oracle promote script does not add the guildmaster object to the player who has been promoted to guildmaster + * Guildmaster / oracle + * The oracle promote script does not add the guildmaster object to the player who has been promoted to guildmaster - * main floor - * the guild dues script adds the dues to the guild coffers even when they dues are not taken from the player for insuficent funds + * Main Floor + * The guild dues script adds the dues to the guild coffers even when they dues are not taken from the player for insuficent funds * "Jack says: Let me know how many imperial you want to pay. Say pay " needs to be changed to jade , and does not accept jade payments - * morning after buying the stairs down to the kennel are missing - * cosmetic : That is You must capture a Hellhound for a basement remains after buying the stairs to the basement + * Morning after buying the stairs down to the kennel are missing + * Cosmetic : That is You must capture a Hellhound for a basement remains after buying the stairs to the basement - * second floor - - * guild dues level / room can not be exited from no WOR ( needed DM help ) - * morning after buying second floor the stairs are closed blocking further testing of second floor + * Second Floor - + * Guild dues level / room can not be exited from (no WOR - needed DM help) + * Morning after buying second floor the stairs are closed blocking further testing of second floor - * big chest - * exits in the big chest go back to the orginal LS guild (old unique maps ) + * Bigchest + * Exits in the big chest go back to the orginal LS guild (old unique maps ) + * REPLY: This is a server admin role - they need to remove all "old" bigchest maps from each player file directory (Make sure each player clears out their bigchest maps first) - * toolshed + * Toolshed * You can dimension door through the windows, granting you free use of the services, and access to the grass outside and across the river even. Just need to make the tiles under the windows deny magic. * /pup_land/guilds/laughing_skull/guild_toolshed 100pp for entry alters are missing ? (yesterday they where there) - - - - * Unordered List Item - - + * REPLY: These maps are not unique maps, they reset on the 2-hour(?) cycle making the rooms a pay to use and giving the maps a chance to remove cursed smithery anvils and workbenches IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:python_guilds?rev=1199413707 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 Fri Jan 4 13:03:09 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 04 Jan 2008 13:03:09 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:python_guilds Message-ID: <1199473389.639455.8408.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/04 13:03 User : meflin Edit Summary: @@ -113,10 +113,8 @@ 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// - - ===== Issues related to the Laughing Skull deployment of MF ==== * Buying a guild house @@ -127,8 +125,9 @@ * Main Floor * The guild dues script adds the dues to the guild coffers even when they dues are not taken from the player for insuficent funds * "Jack says: Let me know how many imperial you want to pay. Say pay " needs to be changed to jade , and does not accept jade payments + * guild dues generates free jade , pull the handle wait 5 sec pull the handle again and there is free money * Morning after buying the stairs down to the kennel are missing * Cosmetic : That is You must capture a Hellhound for a basement remains after buying the stairs to the basement * Second Floor - IP-Address : 71.229.157.100 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:python_guilds?rev=1199414045 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 Fri Jan 4 13:16:04 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 04 Jan 2008 13:16:04 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:python_guilds Message-ID: <1199474164.740741.8438.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/04 13:16 User : meflin Edit Summary: @@ -125,9 +125,9 @@ * Main Floor * The guild dues script adds the dues to the guild coffers even when they dues are not taken from the player for insuficent funds * "Jack says: Let me know how many imperial you want to pay. Say pay " needs to be changed to jade , and does not accept jade payments - * guild dues generates free jade , pull the handle wait 5 sec pull the handle again and there is free money + * guild dues generates free jade , pull the handle wait 5 sec pull the handle again and there is free money, usualy * Morning after buying the stairs down to the kennel are missing * Cosmetic : That is You must capture a Hellhound for a basement remains after buying the stairs to the basement * Second Floor - IP-Address : 71.229.157.100 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:python_guilds?rev=1199473387 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 Fri Jan 4 16:15:30 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 04 Jan 2008 16:15:30 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map_making Message-ID: <1199484930.030121.9999.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/04 16:15 User : eracc Edit Summary: Fix typographical errors, change to bullet list from number list. @@ -74,16 +74,17 @@ - Extremely valuable treasure right next to the entrance, or nearby. Players should need to work to get treasure. If the treasure is fairly worthless (food, or non magical items), this would be acceptable.But a character should not be able to pop in, pick up a potion, spell book,or a lot of diamonds, and then pop out again, without ever meeting monster. - Don't put monsters of high experience point near to entrance where they are trapped. Low level player could boost their experience high by using some weapons or spells from distance without danger. For example find a trapped troll and get wand of fireball. - Monsters on top of other monsters. A troll should not be sitting on top of an oriental dragon. The only exception to this would be if a monster could be on top of another monster (making sense) and hiding it at the same time. A troll on top of an oriental dragon does not make sense (could not fit), nor can the troll hide the oriental dragon. Using tricks like these which are only applicable due to display limitations is something that should not be done, nor should the player need to click on every monster he encounters to see if something is below it. (as a side note, doing this will tend to lock the monsters into position, making them unable to move.) - Large groups of monsters that can be killed quickly with spells. Affair popular tactic to make high level maps is just to put 30 dragons (or other tough monsters) in a big room. Do not do this. All the player needs to do is cast a dozen ice storms, and quickly gets millions of experience .Likewise, it is unlikely that any more than 2 or 3 large (multi square) monsters will be able to attack a player or party at once - the remaining 25will be blocked from doing anything. This then makes it so that having 30dragons is not any tougher than having 3. + ==== General Suggestions ==== - - If you want to make a high level map, instead of tossing a lot of monster son it, take existing monsters and make them tougher. Increase their hit points, level (which then means spells they use do more damage), add immunities or protections, remove vulnerabilities, change attack types, etc.Try not to totally change the characteristics of a known monster - a normal dragon should still be dragon like. Also, remember to adjust experience that the monster gives. - - Try to keep the treasure in line with the difficulty. 5 potions should not be given out for defeating orcs or gnolls (even if there are a lot of them), but if you need to defeat several dragons to get to the potions, that is fine. Likewise, if it is likely a lot of spells will be needed to defeat the monster, and those spells have a chance of destroying the items, then perhaps a few extra items to take this into considerations not a bad idea. - - If use of a specific skill/class/spell is needed to complete the map,that should be stated near the map entrance. How clearly this is stated depends on the circumstance. If use of a certain skill is needed, there is probably no good way other than to state that a skill is needed. If use of a certain spell is needed, stating that a spell caster of XX level might be sufficient, with the assumption that a spell caster of that level would have the spell. It is safe to assume that all characters can fight, but spell (especially certain spells) should not be assumed, and thus should be stated. - - Also, don't put in hidden rooms requiring dimension door if the only real way to know about them is pure luck or looking at the map. If you want to do something like that, at least put some clues in. - - If a certain skill would make a map easier, but is not required, you don't need to necessary state it. The idea of this is that it can be frustrating to wander into some map, complete most of it, but find out you can't finish the map because you lack some skill or spell. + * If you want to make a high level map, instead of tossing a lot of monsters on it, take existing monsters and make them tougher. Increase their hit points, level (which then means spells they use do more damage), add immunities or protections, remove vulnerabilities, change attack types, etc. Try not to totally change the characteristics of a known monster - a normal dragon should still be dragon like. Also, remember to adjust experience that the monster gives. + * Try to keep the treasure in line with the difficulty. 5 potions should not be given out for defeating orcs or gnolls (even if there are a lot of them), but if you need to defeat several dragons to get to the potions, that is fine. Likewise, if it is likely a lot of spells will be needed to defeat the monster, and those spells have a chance of destroying the items, then perhaps a few extra items to take this into consideration not a bad idea. + * If use of a specific skill/class/spell is needed to complete the map,that should be stated near the map entrance. How clearly this is stated depends on the circumstance. If use of a certain skill is needed, there is probably no good way other than to state that a skill is needed. If use of a certain spell is needed, stating that a spell caster of XX level might be sufficient, with the assumption that a spell caster of that level would have the spell. It is safe to assume that all characters can fight, but spell (especially certain spells) should not be assumed, and thus should be stated. The reason for this is that it can be frustrating to wander into some map, complete most of it, but find out you can't finish the map because you lack some skill or spell. + * Also, don't put in hidden rooms requiring dimension door if the only real way to know about them is pure luck or looking at the map. If you want to do something like that, at least put some clues in. + * If a certain skill would make a map easier, but is not required, you don't need to necessary state it. ==== Features to Avoid ==== - A map should be designed so that a character can never be trapped in a room (except via other player interaction.) A character should never be forced to dimension door or word of recall out of a map because some gate closed behind him. For a character without these spells,it would mean death. A simple method around this is put a lever on both sides of the door. If the door is opened by special actions (saying things, dropping things), just put the lever on the hard to get side of the gate. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/map_making?rev=1199407087 New Revision: http://wiki.metalforge.net/doku.php/map_making -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Fri Jan 4 16:17:47 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 04 Jan 2008 16:17:47 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map_making Message-ID: <1199485067.422144.10005.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/04 16:17 User : eracc Edit Summary: Bold the information about Gridarta @@ -3,11 +3,12 @@ Without Maps, there would be nowhere to put monsters now would there. Map making is a rewarding task but there are some things to be aware of... + ===== Map Guide ===== - This is a guide on what is an acceptable map and what is unacceptable. Only acceptable maps will be put in the official Crossfire map distribution. Please use the latest release of [[Gridarta]] when making maps to contribute. + This is a guide on what is an acceptable map and what is unacceptable. Only acceptable maps will be put in the official Crossfire map distribution. **Please use the latest release of [[Gridarta]] when making maps to contribute.** ==== Directory Structure ==== IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/map_making?rev=1199484927 New Revision: http://wiki.metalforge.net/doku.php/map_making -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sat Jan 5 00:46:33 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 05 Jan 2008 00:46:33 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: world:scorn:easy_house Message-ID: <1199515593.822205.12821.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/05 00:46 User : Edit Summary: @@ -1,3 +1,4 @@ ====== Easy House ====== - Easy House (Mr. & Mrs. G's) is located South of Patches House or West of Newbie Tower. Easy House consists of three maps. Kolbolds, Goblins, and Orcs infested the house. Some monsters have enhanced or special abilities. + Easy House (Mr. & Mrs. G's) is located South of Patches House or West of Newbie Tower. Easy House consists of three maps. Kolbolds, goblins, and Orcs infested the house. Some monsters have enhanced or special abilities. + IP-Address : 59.167.136.149 Old Revision: http://wiki.metalforge.net/doku.php/world:scorn:easy_house?rev=1160945293 New Revision: http://wiki.metalforge.net/doku.php/world:scorn:easy_house -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sat Jan 5 17:00:11 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 05 Jan 2008 17:00:11 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:objects Message-ID: <1199574011.460021.14749.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/05 17:00 User : ryo Edit Summary: fix format @@ -1823,38 +1823,28 @@ to the code from lighting. Also, some new archs instroduced, namely "flint and steel" for lighting stuff on fire and "torch" a source of light. - ====== How to add new values ====== This section details how to add new fields/flags to an object structure. - 1) Send mail to the development list to make sure that a new element is really - added. + 1) Send mail to the development list to make sure that a new element is really added. For flags: - 2) Update the FLAG_.. entries in include/define.h for your new flag. Recycle unused - values if possible - there may be cases where you want to group the new flags together. - If you are adding beyond the end of the existing values, update the NUM_FLAGS entry + 2) Update the FLAG_.. entries in include/define.h for your new flag. Recycle unused values if possible - there may be cases where you want to group the new flags together. If you are adding beyond the end of the existing values, update the NUM_FLAGS entry - 3) Decide the name of your flag as loaded/saved in objects. The default syntax is - the name you assigned in step 2 above, minus the leading flag_ part. + 3) Decide the name of your flag as loaded/saved in objects. The default syntax is the name you assigned in step 2 above, minus the leading flag_ part. - 4) In the common/loader.l, update the load section (where the code is mostly ^value - SET_OR_CLEAR(...)) add your entries in. + 4) In the common/loader.l, update the load section (where the code is mostly ^value SET_OR_CLEAR(...)) add your entries in. - 5) update the flag_names in common/loader.l. The location of your names _must_ be - in the same array location as the FLAG_ value. + 5) update the flag_names in common/loader.l. The location of your names _must_ be in the same array location as the FLAG_ value. - 6) Update other areas of the code that you presumably know about that will use these - flag values. + 6) Update other areas of the code that you presumably know about that will use these flag values. 7) As appropriate, update the arch files and rebuild. - - ====== Programming notes ====== This section provides some specific programming notes about objects. If IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev:objects?rev=1198883892 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 Sat Jan 5 17:04:04 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 05 Jan 2008 17:04:04 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:objects Message-ID: <1199574244.500727.14752.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/05 17:04 User : ryo Edit Summary: fix format @@ -1785,9 +1785,8 @@ If the follower doesn't already have it this item, gives it, similar to visible items. Except, it ALWAYS gives it, upon conversion. And on conversion to another religion, it is ALWAYS removed. Signs and forces and skills may not be given/taken this way. - ====== Misc change description: ====== The following area describes various comments about various pieces of @@ -1795,36 +1794,12 @@ work. The following may not really be necessary, but I figure that it is probably worth saving, and this seemed to be as good as place as any. LIGHTING CODE (by Brian Thomas): - - fast calculation of lighting. For players los (line- of - sight)is calculated from a linked list of nearby lights. - For monsters, no los is calculated, rather a modified - check_wakeup routine is used to see if they will - follow/attack players. Monsters with can_see_in_dark act - normally in dark areas. - - - New attacktype -AT_BLIND. This is a pretty severe penalty - for monsters and players alike. Players cant see any square - but thier own, monsters can only attack/follow players who - are in an adjacent square. Need to make the monsters stumble - around when no player is near, rather than the current way - in which they stand around waiting to get "ace'd". Undead - cannot be blinded, nor should be effected by darkness. For - other monsters, if they have immunity to blindness or can - see invisible, they are uneffected by AT_BLIND attacks. - - - New spells. Some magician, some clerical. They work, but - may need to be adjusted for playbalance. Normal spells - available include: "light", "darkness", "sunspear", "faery - fire" and "dark vision". All spells (but darkvision) work - (do something) whether the lighting code is used or not. - - - Modified archetypes and artifacts list to encompass changes - to the code from lighting. Also, some new archs instroduced, - namely "flint and steel" for lighting stuff on fire and - "torch" a source of light. - + - fast calculation of lighting. For players los (line- of sight) is calculated from a linked list of nearby lights. For monsters, no los is calculated, rather a modified check_wakeup routine is used to see if they will follow/attack players. Monsters with can_see_in_dark act normally in dark areas. + - New attacktype -AT_BLIND. This is a pretty severe penalty for monsters and players alike. Players cant see any square but thier own, monsters can only attack/follow players who are in an adjacent square. Need to make the monsters stumble around when no player is near, rather than the current way in which they stand around waiting to get "ace'd". Undead cannot be blinded, nor should be effected by darkness. For other monsters, if they have immunity to blindness or can see invisible, they are uneffected by AT_BLIND attacks. + - New spells. Some magician, some clerical. They work, but may need to be adjusted for playbalance. Normal spells available include: "light", "darkness", "sunspear", "faery fire" and "dark vision". All spells (but darkvision) work do something) whether the lighting code is used or not. + - Modified archetypes and artifacts list to encompass changes to the code from lighting. Also, some new archs introduced, namely "flint and steel" for lighting stuff on fire and "torch" a source of light. ====== How to add new values ====== This section details how to add new fields/flags to an object structure. IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev:objects?rev=1199573998 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 Sat Jan 5 23:29:22 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 05 Jan 2008 23:29:22 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:object_types Message-ID: <1199597362.216701.16230.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/05 23:29 User : kbulgrien Edit Summary: Put more detail on HOLE object attributes. @@ -10,8 +10,9 @@ * SVN * [[http://crossfire.svn.sourceforge.net/viewvc/crossfire/server/trunk/include/define.h|server/include/define.h]] ======Type Information====== + =====HOLE (94)===== Holes send objects that fall through them to a new location on the current map. @@ -20,15 +21,18 @@ * Become "full" (Can stop working) if destination is blocked. * May be opened and closed via connection. * Monsters, spells, etc. can fall through. * Can trigger on all movement types. + * Example: [[http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/connect/Hole/pit.arc|connect/Hole/pit.arc]] **Special Object Attributes** - | connection | When a connection value is set, the pit can be opened/closed by activating the connection. | - | destination X \\ destination Y | The pit will transport creatures (and items) randomly into a two-square radius of the destination coordinates. If the destination square becomes blocked, the pit will act like it is filled up and will not work any more. | - | position state | The position state defines the position of the gate: Zero means completely open/down, the "number of animation-steps" (usually about 6 or 7) means completely closed/up state. The default value is usually recommended. | - | affected movement | Make creatures using these movement types fall into the pit. Movement types other than walking is not the behavior expected from a pit, and other settings should only be used for map-mechanisms (e.g. for transporting flying monsters). An interesting side-effect is if this flag is enabled, spell effects like fire/snow also make their way through the pit. | + ^ CrossfireEditor ^ arch ^ map ^ Description ^ + | connection | | connected | When a connection value is set, the pit can be opened/closed by activating the connection. | + | destination X \\ destination Y | | hp \\ sp | The pit will transport creatures (and items) randomly into a two-square radius of the destination coordinates. If the destination square becomes blocked, the pit will act like it is filled up and will not work any more. | + | position state | wc | | The position state defines the position of the gate: Zero means completely open/down, the "number of animation-steps" (usually about 6 or 7) means completely closed/up state. The default value is usually recommended. | + | affected movement | move_on | move_on | Make creatures using these movement types fall into the pit. Movement types other than walking is not the behavior expected from a pit, and other settings should only be used for map-mechanisms (e.g. for transporting flying monsters). An interesting side-effect is if this flag is enabled, spell effects like fire/snow also make their way through the pit. | + | | maxsp | | Whether the initial state is open (1) or closed (0). | =====Common Object Attributes===== | name | The name of the object displayed to players. | IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/dev:object_types?rev=1198904908 New Revision: http://wiki.metalforge.net/doku.php/dev:object_types -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 6 13:17:31 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 06 Jan 2008 13:17:31 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: crossfire_compile_guide Message-ID: <1199647051.265335.17873.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/06 13:17 User : ryo Edit Summary: update @@ -203,19 +203,26 @@ What that command will do is run the Crossfire server and return you back to bash or shell prompt FIXME -- How to use crossloop for running the server; crossloop is a script that automatically restarts the server if/when it crashes and can also provide useful debugging or error information from the crash event - ===== Microsoft (c) Windows ===== The following tools are used to compile the server: * Microsoft Visual Studio 6 (service pack 4 probably). Server has not been tested with other versions. * flex, from [[http://gnuwin32.sourceforge.net/packages/flex.htm]]. * you need it to build ''common/loader.c'' and ''random_maps/reader.c'' from their respective .l. Syntax is: ''flex -oloader.c -i loader.l'', ''flex -oreader.c -i -P rm reader.l'' respectively. The ''-P rm'' seems to be required to not have duplicate symbol issues * [[http://www.python.org|Python]] to build the Python plugin. Any version starting from 2.3 should do the trick, if not [[http://sourceforge.net/tracker/?func=add&group_id=13833&atid=113833|report a bug please]] + * if you want metaserver2 support, you'll need: + * libcurl, from [[http://http://curl.haxx.se/]]. You probably want [[http://curl.haxx.se/download/libcurl-7.17.1-win32-nossl-sspi.zip|this file]]. + * pthread, obtained from [[http://www.sourceware.org/pthreads-win32/]]. Tested with pthreads-w32-2-8-0-release.exe + * zlib, file ''zlib123-dll.zip'' from [[http://www.zlib.net/]] ([[http://prdownloads.sourceforge.net/libpng/zlib123-dll.zip?download|direct link]]) + * copy the following files to the directory you'll run Crossfire from: ''pthreadVC2.dll'', ''zlib1.dll'', ''libcurl.dll'' + * define ''HAVE_CURL_CURL_H'' in the projects settings (project settings -> C/C++ -> general -> preprocessor definitions) + * link the executable to ''libcurl.lib'' and ''pthreadVC2.lib'' (project settings -> link -> general -> object/library modules) * to build the installer, you need [[http://nsis.sourceforge.net|NSIS]], and [[http://www.perl.org|PERL]] (for maps installer). * to build archetypes, you need PERL * once you got the server sources, open a command prompt, go to ''make_win32'' directory, run the ''installwin32.bat'' file. It will create required directories The following tools are used to compile the client: * [[http://www.gtk.org|GTK]]. An installer with all required dependencies can be found at the [[http://gladewin32.sourceforge.net/modules/news/|Glade/GTK+ project]]. **Warning**: you'll need to add ~10 directories to include list, and rename some files around (like copy ''libpng.lib'' to ''png.lib''). Don't ask why here, ask Glade/GTK+ project instead :) * current SVN (end of 2006) is somewhat broken, and requires some tweaking to build (need to ''undef HAVE_SDL'', comment out lines, add files, and such). That may be fixed or not eventually. + * if you want metaserver2 support, follow the same instructions as for the server. IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/crossfire_compile_guide?rev=1198888419 New Revision: http://wiki.metalforge.net/doku.php/crossfire_compile_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 6 14:52:59 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 06 Jan 2008 14:52:59 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map_making Message-ID: <1199652779.463625.18212.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/06 14:52 User : kbulgrien Edit Summary: Typo and miscellaneous rewording. @@ -14,9 +14,9 @@ * Maps contained within a city/town should be placed in the city/town directory in the maps tree. * If a quest is started from a city/town then it should be placed in the city/town directory. * The dungeons directory would be for non-quests that are not linked to a specific city/town region and that are just experience grinds. - * The quests directory should be used if the quest is not liked to a specific city/town. + * The quests directory should be used if the quest is not linked to a specific city/town. ==== Regions ==== Maps that are not wilderness should be assigned a region. Current defined regions are: @@ -65,106 +65,106 @@ ==== Hallways, Roads, Paths, etc. ==== - Try to make sure the maps are multi player accessible. In towns, this means the road should be at least a couple squares wide, buildings should not be trapped in corners in which case one character standing in front blocks access, etc. - Try to make corridors in dungeons or mazes a few squares wide -especially if there is only a single path. If it is a maze with several different paths, single width corridors are acceptable. The main problem here are big labyrinths in which only one monster attacks at a time, and which there is only 1 or two routes. If two players enter such a map, the one that went in first will be in the lead the entire time. - - Avoid spiral or single path mazes that just have monsters lining the corridor. These are not very good for multiple players, not particularly interesting (map just's consists of killing all the monsters), and tend to bean easy and safe way to gain experience. + - Avoid spiral or single path mazes that just have monsters lining the corridor. These are not very good for multiple players, not particularly interesting (map just consists of killing all the monsters), and tend to be an easy and safe way to gain experience. ==== Don't Put ==== - Do not create weapons or other items with the attack_type godpower or protection/resistance to godpower - In order to maintain the challenge level of Crossfire, the attacktype godpower is used. Since it's possible to gain resistances and protection to all all other attack_types certain monsters have godpower which will cause damage to player character. I know, it doesn't seem fair - but it's no fun when the game is easy, either. - Extremely valuable treasure right next to the entrance, or nearby. Players should need to work to get treasure. If the treasure is fairly worthless (food, or non magical items), this would be acceptable.But a character should not be able to pop in, pick up a potion, spell book,or a lot of diamonds, and then pop out again, without ever meeting monster. - - Don't put monsters of high experience point near to entrance where they are trapped. Low level player could boost their experience high by using some weapons or spells from distance without danger. For example find a trapped troll and get wand of fireball. - - Monsters on top of other monsters. A troll should not be sitting on top of an oriental dragon. The only exception to this would be if a monster could be on top of another monster (making sense) and hiding it at the same time. A troll on top of an oriental dragon does not make sense (could not fit), nor can the troll hide the oriental dragon. Using tricks like these which are only applicable due to display limitations is something that should not be done, nor should the player need to click on every monster he encounters to see if something is below it. (as a side note, doing this will tend to lock the monsters into position, making them unable to move.) - - Large groups of monsters that can be killed quickly with spells. Affair popular tactic to make high level maps is just to put 30 dragons (or other tough monsters) in a big room. Do not do this. All the player needs to do is cast a dozen ice storms, and quickly gets millions of experience .Likewise, it is unlikely that any more than 2 or 3 large (multi square) monsters will be able to attack a player or party at once - the remaining 25will be blocked from doing anything. This then makes it so that having 30dragons is not any tougher than having 3. + - Don't put monsters of high experience points near to entrance where they are trapped as this might allow low level players to boost their experience high by using some weapons or spells from distance, but without danger. For example find a trapped troll and get wand of fireball. + - Monsters on top of other monsters. A troll should not be sitting on top of an oriental dragon. The only exception to this would be if a monster could be on top of another monster (making sense) and hiding it at the same time. A troll on top of an oriental dragon does not make sense (could not fit), nor can the troll hide the oriental dragon. Using tricks like these which are only applicable due to display limitations is something that should not be done, nor should the player need to click on every monster he encounters to see if something is below it. (As a side note, doing this will tend to lock the monsters into position, making them unable to move.) + - Large groups of monsters that can be killed quickly with spells. A fairly popular tactic to make high level maps is just to put 30 dragons (or other tough monsters) in a big room. Do not do this. All the player needs to do is cast a dozen ice storms, and quickly gets millions of experience. Likewise, it is unlikely that any more than 2 or 3 large (multi square) monsters will be able to attack a player or party at once - the remaining 25 will be blocked from doing anything. This then makes it so that having 30 dragons is not any tougher than having 3. ==== General Suggestions ==== * If you want to make a high level map, instead of tossing a lot of monsters on it, take existing monsters and make them tougher. Increase their hit points, level (which then means spells they use do more damage), add immunities or protections, remove vulnerabilities, change attack types, etc. Try not to totally change the characteristics of a known monster - a normal dragon should still be dragon like. Also, remember to adjust experience that the monster gives. - * Try to keep the treasure in line with the difficulty. 5 potions should not be given out for defeating orcs or gnolls (even if there are a lot of them), but if you need to defeat several dragons to get to the potions, that is fine. Likewise, if it is likely a lot of spells will be needed to defeat the monster, and those spells have a chance of destroying the items, then perhaps a few extra items to take this into consideration not a bad idea. - * If use of a specific skill/class/spell is needed to complete the map,that should be stated near the map entrance. How clearly this is stated depends on the circumstance. If use of a certain skill is needed, there is probably no good way other than to state that a skill is needed. If use of a certain spell is needed, stating that a spell caster of XX level might be sufficient, with the assumption that a spell caster of that level would have the spell. It is safe to assume that all characters can fight, but spell (especially certain spells) should not be assumed, and thus should be stated. The reason for this is that it can be frustrating to wander into some map, complete most of it, but find out you can't finish the map because you lack some skill or spell. + * Try to keep the treasure in line with the difficulty. 5 potions should not be given out for defeating orcs or gnolls (even if there are a lot of them), but if you need to defeat several dragons to get to the potions, that is fine. Likewise, if it is likely a lot of spells would be needed to defeat the monster, and those spells have a chance of destroying the items, then perhaps a few extra items to take this into consideration not a bad idea. + * If use of a specific skill/class/spell is needed to complete the map, that should be stated near the map entrance. How clearly this is stated depends on the circumstance. There is probably no good way other than to state that a skill is needed, but, stating, for example, that a spell caster of XX level might be sufficient, with the assumption that a spell caster of that level would have the spell. It is safe to assume that all characters can fight, but magic use (especially certain spells) should not be assumed, and thus should be stated. The reason for this is that it can be frustrating to wander into some map, complete most of it, but find out you can't finish the map because you lack some skill or spell. * Also, don't put in hidden rooms requiring dimension door if the only real way to know about them is pure luck or looking at the map. If you want to do something like that, at least put some clues in. - * If a certain skill would make a map easier, but is not required, you don't need to necessary state it. + * If a certain skill makes a map easier, it is not necessary state that. ==== Features to Avoid ==== - - A map should be designed so that a character can never be trapped in a room (except via other player interaction.) A character should never be forced to dimension door or word of recall out of a map because some gate closed behind him. For a character without these spells,it would mean death. A simple method around this is put a lever on both sides of the door. If the door is opened by special actions (saying things, dropping things), just put the lever on the hard to get side of the gate. - - If a map require multiple players to simultaneous be on it to solve the map, put a sign or message so players know. Such maps would be those that require manipulation of levers or buttons in certain sequences in order to get through gates. - - Don't make ends of maps require multi users. This ruins that map for single players (not able to complete it), and makes a map that requires multiple players for only a small portion. - - Try not to make the maps too many levels deep. To get to the goal,it should not require a 6 hour continuous sitting, as the player works through each map to get to the next. Multi level maps are fine - just don't over do it. One way to do this is have several maps with a key or other special item at the end. The final map could have the various battles, and then a series of gates/altars which uses up these keys. + - A map should be designed so that a character can never be trapped in a room (except via other player interaction.) A character should never be forced to dimension door or word of recall out of a map because some gate closed behind him. For a character without these spells, being trapped means death. A simple method around this is put a lever on both sides of the door. If the door is opened by special actions (saying things, dropping things), just put the lever on the hard to get side of the gate. + - If a map requires simultaneous use of multiple players to solve the map, put a sign or message so players know. Such maps would be those that require manipulation of levers or buttons in certain sequences in order to get through gates. + - Don't make ends of maps require multiple users. This ruins that map for single players (not able to complete it), and makes a map that requires multiple players for only a small portion. + - Try not to make the maps too many levels deep. To get to the goal, it should not require a 6 hour continuous sitting, as the player works through each map to get to the next. Multi-level maps are fine - just don't over do it. One way to do this is to have several maps with a key or other special item at the end. The final map could have the various battles, and then a series of gates/altars that uses up these keys. ==== Shops ==== - - Don't put super stores in any towns or villages you create. With the growing number of maps, players can already make a trip to all the different towns to try and find certain items. A one stop find all shop is not interesting. A good maximum size is about the same size of the shop sin the starting village. - - Also, making six magic shops of that size and putting them in the same town is not any better than one large magic shop. If you want to have specialized shops, then make each shop smaller. If you just want one shop that sells every type of item (magic, armor, weapons, food, etc), Athena large shop is permissible. - - Make sure the entire interior the shop is covered with tiles. Likewise,don't put shops that lead to areas without tiles without going over one of the magic doormats. A player should never be able to get an unpaid item out of a shop, whether via exit that does not go over the magic doormat, or through spells. + - Do not put super stores in any towns or villages you create. With the growing number of maps, players can already make a trip to all the different towns to try and find certain items. A one stop shop of every conceivable item is not interesting. A good maximum size is about the same size of the shops in the starting village. + - Also, making six magic shops of that size and putting them in the same town is not any better than one large magic shop. If you want to have specialized shops, then make each shop smaller. If you just want one shop that sells every type of item (magic, armor, weapons, food, etc), then a large shop is permissible. + - Make sure the entire interior the shop is covered with tiles. Likewise, do not put shops that lead to areas without going over one of the magic doormats. A player should never be able to get an unpaid item out of a shop, whether by exiting without going over the magic doormat, or through the use of spells. ==== Map Layout and Placement Suggestions ==== - Don't make maps which require high level characters that low level characters can wonder into without warning. Put a warning sign nearby,or gates or doors so the player can see they are in over their head, instead of instantly getting toasted the second they enter the map. - The structure of the map should make sense. That is to say, if you enter a house, the house should then not have a tower or a door to a shop inside. In other words, if a map has an exit to another map,that exit should make sense (ie, another level, tunnels, dungeons all make sense. However, another building the size of the original does not make sense. - - Try to keep the difficulty throughout the map(s) about the same.The first monster in the map should not be the most difficult monster,nor should the last monster be orders of magnitude more difficult than anything before it. - - It is very frustrating to play a map, killing most every monster without much difficulty, only to find that last monster unkillable. + - Try to keep the difficulty throughout the map(s) about the same.The first monster in the map should not be the most difficult monster, nor should the last monster be orders of magnitude more difficult than anything before it. + - It is very frustrating to play a map, killing most every monster without much difficulty, only to find the last monster invincible to the character that just made it through the rest of the map just fine. - It is reasonable to have the monsters increase in difficulty. Also, if the map has no quest or end goal, then having a very difficult monster around is not unreasonable, as long as it does prevent the player from progressing to the next map. - - Do not put directors with bullet, lightning, fireball, etc. that are a loop or continuous. Example: Do not have two directors, each facing each other, with a bullet wall firing into them at the side. - - Having numerous directors is fine. But make sure that eventually,there will be an exit/detonation point for the fired spell. Having loops that go for over typically bring the game to a halt, as the objects just multiply and the game consumes more and more cpu time. + - Do not place directors with bullet, lightning, fireball, etc. that are a loop or continuous. Example: Do not have two directors, each facing each other, with a bullet wall firing into them at the side. + - Having numerous directors is fine. But make sure that eventually, there will be an exit/detonation point for the fired spell. Having loops that go for over typically bring the game to a halt, as the objects just multiply and the game consumes more and more CPU time. ==== Technical Map Hints ==== - * If you are creating a new archetype, it only needs to go into the general archetype distribution if it has an image associated with it, or it has general use (a new monster). Something that uses already existing image scan be set up in the map file itself (through setting various variables). + * If you are creating a new archetype, it only needs to go into the general archetype distribution if it has a unique image associated with it, or it has general use (a new monster). Something that uses already existing image scan be set up in the map file itself (through setting various variables). * When modifying an existing archetype into a new one (either new face or new type), use the archetype that has the most variables in common.Thus, if you want to create a monster called a boulder, it is probably best to take a monster of some sort and change its face instead of taking the existing boulder archetype and changing its type, hit points, speed,etc. * Changing color is no longer possible in maps - instead, a new face and image must be created, and then put in the standard distribution.The archetype collection script will automatically pull out face information from archetype files. - * Try to keep maps readable by other people who might edit them. Thus,instead of modifying a woods space so it also acts as an exit, just put an invisible exit under the woods space. This has the same functionality, but it makes it much easier for other players to see what this space does. (Side note - if you want it so that players actually need to apply the space to enter, you will need to change the face of exit for this to work. If you do this, you should also accompany it with a magic mouth.) + * Try to keep maps readable by other people who might edit them. Thus, instead of modifying a woods space so it also acts as an exit, just put an invisible exit under the woods space. This has the same functionality, but it makes it much easier for other players to see what this space does. (Side note - if you want it so that players actually need to apply the space to enter, you will need to change the face of the exit for this to work. If you do this, you should also accompany it with a magic mouth.) * Make sure you set the difficulty field in the map attributes to something meaningful. Crossfire will calculate a default difficulty, but its formula is hardly ideal. The difficulty of a map determines how magical the treasure will be (and some treasure types won't show up unless the map has a certain difficulty level.) - * Don't be too intimidated about writing new code if there is something you would like to be able to do, but it just isn't supported. If you are not the code writing type, make a suggestion. Worst case is it gets ignored. But many times, I have written code because I had some idea which just was not possible at the time (ie, the apartment in the starting town required an expansion/change of the unique item code.) + * Don't be too intimidated about writing new code if there is something you would like to be able to do and it isn't currently supported. If you are not the code writing type, make a suggestion. Worst case is it gets ignored. But many times, someone has written code because a mapmaker had some idea which just was not possible at the time (ie, the apartment in the starting town required an expansion/change of the unique item code.) On the other hand, please don't ask for new code and then bail out before adding a map that uses the new feature since that tends to make a developer less likely to want to write code the next time someone asks. ==== Other Suggestions ==== The following are various suggestions for making good or interesting maps. A map that does not need to follow all these hints to be accepted,but following these hints will make for more interesting or playable maps. - * Try to create only small maps. If you have a large map in mind, try to see if you can possible split it up in several separate sections, and place those sections in different maps. Many small maps use much less memory than one large map, since crossfire doesn't yet support swapping of portions of maps. Also, with small maps, the time to load it from and store it to disc becomes so short that it's impossible to notice. In this context, small means about 32x32, though it's actually the number of objects in the map which count. - * What is potentially more critical than the size of the map is the number of objects (memory usage), and live objects (cpu usage, as each would need to be processed.) - * Also, remember that if you make very large maps, all generators will be cranking out monsters whenever anyone is on it. This could mean that a lot of monsters have been generated before a player even gets to the area where they are being created. - * Related to this: If a map contains multiple levels, make multiple maps.Many times, if the level is small, the mapmaker may think I will just put all the levels on one larger map. This makes the map a little less readable to others. Also, things like magic mapping and dimension door can lead to unexpected results. - * Make a plot! A map without a plot becomes just another mindless"Kill all". For instance, create a story which explains why there are npc's here and monsters there, fragment the story up and put bits and hints of it in various worktables (books) and npc-conversations. - * If you are going to make a mindless kill them all map, at least put some reward in the map that can only be accessed after all the monsters have been killed. The only thing worse than a kill them all map is a kill them all map which you get nothing out of. - * Avoid maps where all the monsters are lined up, and only one can attack you at a time. This just makes an easy (and relatively safe) way foray character to gain experience and treasure, and is not especially interesting or challenging. - * A good idea for the rewards at the end of quests are specific items (luggage, spell book of some otherwise not available spell,special weapon, spell crystal, etc.) It is much more interesting to put a specific item instead of something like a random artifact. Feel free to mutate or otherwise change existing artifacts to create your own. - * This has two advantages: one, the player will get to know where certain items are. Having to search endlessly for a specific item gets tedious.Two, it reduces the incentive to keep repeating the quest (repeating quests is not inherently bad) If the reward is a random artifact, a player may very well keep repeating the quest until the item he looks for comes up.By doing specific items, this will not happen. - * Make puzzles! Use all those different object types: buttons, handles,doors, altars, pedestals, triggers, timed gates, etc... Hide special "keys" needed to get further in special places, and use text-puzzles to describe where they are hidden and how they must be used. The possibilities are endless! Remember, you can also hide buttons under floors, making it more difficult for the character to find the trigger points. - * But don't make too much big labyrinths. Making of labyrinths is (too)easy with cross edit, just select auto-joining and make zigzag with mouse. But the results of these are quite tiring. If you make ones, try make some idea into it. - * Related: Don't make maps where the only way to find something is examination of each and every wall. For example, don't have a big map with lots of walls,but the key to moving onward is to find the weak wall and pass through it.Nor should big mazes full of invisible walls be made where the way to get through it is just by going in some direction, finding out you can't move anymore in that direction, go some other one, etc. * Give the npc's information! An npc's knowledge about hidden treasure surely makes it interesting to have a conversation with it. - * Feel free to add some traps, but be careful to not make them too deadly without adequate warning. - * Don't mix the monsters too badly. Let there be at least some logic behind why they are grouped in a single room. Undead together with undead, for instance, but not together with kobolds...Big dragons usually don't live together with mice... Fire immune creatures generally dislike ice immune creatures. - * Also, limit use of monsters that multiply rapidly (mice, slimes). A map that is easily overwhelmed with these creatures quickly becomes useless. - * Give your maps a meaningfully name (like John's tower, level 1).This way, these can be used instead of the map paths in the highs. Also, in terms of the actual file name, try to use numeric level identifiers (ie, maze.1, maze.2, ... instead of maze.first, maze.second,etc.) The former maps the levels sorted a little bit nicer in the directory. - * Try to make the map so that it links in with the existing world. Most people want to make their own continent, which is then accessed by ship or other fast means. While convenient, this creates many island continents. The problems with this are that any feeling of relation is lost(where is that island continent), and it makes item searching in shops very easy - if you can access half a dozen shops quickly and safely by taking boats, you have a decent chance of finding the item you want. - * Also, it seems that when most people start making maps, the first thing they do is create a new town or village. There are already a lot of towns and villages out there. If you are just going to create a few new buildings,instead of going to the effort and time of creating your own island with at own, just create the buildings, and plug them into one of the existing towns or the terrain someplace. Many of the towns right now have many unused buildings. + * Try to create only small maps. If you have a large map in mind, try to see if you can possibly split it up into several separate sections, and place those sections in different maps. Many small maps use much less memory than one large map since Crossfire doesn't yet support swapping of portions of maps. Also, with small maps, the time to load and store becomes so short that it's impossible to notice. In this context, small means about 32x32, though it's actually the number of objects in the map that count. + * What is potentially more critical than the size of the map is the number of objects (memory usage), and live objects (CPU usage, as each needs to be actively managed). + * Remember that with large maps, all generators crank out monsters whenever anyone is on it. This could mean that a lot of monsters have been generated before a player even gets to the area where they are being created. + * Related to this: If a map contains multiple levels, make multiple maps. Many times, if the level is small, the mapmaker may think I will just put all the levels on one larger map. This makes the map a little less readable to others. Also, things like magic mapping and dimension door can lead to unexpected results. + * Make a plot! A map without a plot becomes just another mindless "Kill all". For instance, create a story which explains why there are NPC's here and monsters there, fragment the story up and put bits and hints of it in various worktables (books) and NPC-conversations. + * If you are going to make a mindless kill-them-all map, at least put some reward in the map that can only be accessed after all the monsters have been killed. The only thing worse than a hack-and-slash map is one that you get nothing out of. + * Avoid maps where all the monsters are lined up and can only attack you one at a time. This just makes an easy (and relatively safe) way for a character to gain experience and treasure, while not being especially interesting or challenging. + * A good idea for the rewards at the end of quests are specific items (luggage, spell book of some otherwise not available spell, special weapon, spell crystal, etc.) It is much more interesting to put a specific item instead of something like a random artifact. Feel free to mutate or otherwise change existing artifacts to create your own. + * This has two advantages: one, the player will get to know where certain items are. Having to search endlessly for a specific item gets tedious. Two, it reduces the incentive to keep repeating the quest (repeating quests is not inherently bad). If the reward is a random artifact, a player may very well keep repeating the quest until the item he looks for comes up. By doing specific items, this will not happen. + * Make puzzles! Use all those different object types: buttons, handles,doors, altars, pedestals, triggers, timed gates, etc... Hide special "keys" needed to get further in special places, and use text-puzzles to describe where they are hidden and how they must be used. The possibilities are endless! Remember, you can also hide buttons under floors, making it more difficult for the character to find the trigger points. At the same time, try not to make puzzles that have no clues so that players never realize there is a puzzle on the map. + * Do not make too many big labyrinths. Making of labyrinths is (too) easy with a map editor as you just select auto-joining and make zig-zags with the mouse. But the results of these are quite tiring. If you make ones, try bring some unique aspect into it. + * Related: Don't make maps where the only way to find something is examination of each and every wall. For example, don't have a big map with lots of walls, but the key to moving onward is to find the weak wall and pass through it. Nor should big mazes full of invisible walls be made where the way to get through it is just by going in some direction, finding out you can't move anymore in that direction, go some other one, etc. * Give the NPC's information! An NPC's knowledge about hidden treasure surely makes it interesting to have a conversation with it. + * Feel free to add traps, but be careful to not make them too deadly without adequate warning. + * Do not mix the monsters too badly. Let there be at least some logic behind why they are grouped in a single room. Undead together with undead, for instance, but not together with kobolds... Big dragons usually don't live together with mice... Fire-immune creatures generally dislike ice-immune creatures. + * Also, limit use of monsters that multiply rapidly (mice, slimes). A map that is easily overwhelmed with these creatures quickly becomes useless and frustrating. + * Give your maps a meaningful name (like John's tower, level 1). This way, these can be used instead of the map paths in the highs. Also, in terms of the actual file name, try to use numeric level identifiers (ie, maze.1, maze.2, ... instead of maze.first, maze.second,etc.) The number in the name helps map levels sort a little bit nicer in the directory. + * Try to make the map so that it links in with the existing world. Most people want to make their own continent, which is then accessed by ship or other fast means. While convenient, this creates many island continents. The problem with this is that any feeling of relation is lost (where is that island continent), and it makes item searching in shops very easy - if you can access half a dozen shops quickly and safely by taking boats, you have a decent chance of finding the item you want. + * Also, it seems that when most people start making maps, the first thing they do is create a new town or village. There are already a lot of towns and villages out there. If you are just going to create a few new buildings, instead of going to the effort and time of creating your own island with at own, just create the buildings, and plug them into one of the existing towns or the terrain someplace. Many of the towns right now have many unused buildings. ---- ===== Map Contributions ===== - Once a map has been created, you have the option of contributing it back to the Crossfire project. Here's a few ways on how to do that. + Once a map has been created, you have the option of contributing it back to the Crossfire project. Here are a few ways on doing that. - **NOTE** In all cases, we ask that you compress the map file(s) first by using either WinZip (for .zip files) or tar (for .tgz files); this helps to save on bandwidth, disk space and overall time to "handle" the files. + **NOTE** In all cases, compress the map file(s) first by using either WinZip (for .zip files) or tar (for .tgz files) as this helps to save bandwidth, disk space and overall time to "handle" the files. ==== Creating a "diff" ==== - There are all kinds of technical reasons for using a "diff" file to merge in file updates. The biggest reason is it gives whom ever else is working with your map changes an easy to read file comparison to see what has changed, exactly. One will need Subversion (SVN) installed and setup before attempting to create a diff. + There are all kinds of technical reasons for using a "diff" file to merge in file updates. The biggest reason is it gives the person working with your map changes an easy to read a file comparison to see what has changed, exactly. One needs Subversion (SVN) installed and set up before attempting to create a diff. SVN diff from the command line: $ svn diff > patchfile - This run a comparison (or difference) between your local files to what is in place in the Crossfire Subversion repository at SourceForge. It is advised to use a more descriptive name for the patchfile - since that is just an example. + This runs a comparison (or difference) between your local files to what is in place in the Crossfire Subversion repository at SourceForge. It is advisable to use a descriptive name for the patchfile, as that is just an example. - Now, use the tar command to compress the patchfile + Next, use the tar command to compress the patchfile. $ tar czvf mypatchfile.tgz patchfile - This will take all the contents of patchfile and compress it in to mypatchfile.tgz + This takes the contents of patchfile and compresses it into mypatchfile.tgz The command to uncompress said file is $ tar xzvf mypatchfile.tgz @@ -172,20 +172,21 @@ Remember, c = compress while x = extract FIXME - Document how to create a diff against SVN using TortoiseSVN and TortoiseMerge - Once you have your diff file, see the options below for submitting them or making others aware of your new map or map updates. + Once you have a diff or patch file, see the options below for submitting them or making others aware of your new map or map updates. ==== Submit the map as a "patch" on SourceForge ==== - Visit the SourceForge patch upload page at https://sourceforge.net/tracker/?func=add&group_id=13833&atid=313833 - Follow the online instructions for submitting the patch - please be thorough on filling out the online submit form - * Keep in mind their is a maximum file size for the file upload (around 200KB) so you may need to submit multiple patches or make the maps available via other means (personal web area, etc.) + * Keep in mind there is a maximum file size for the file upload (around 200KB) so you may need to submit multiple patches or make the maps available via other means (personal web area, etc.) * Please check back to the Patch page for any follow up questions and feedback in regards to your map(s) ==== Submit the map through the mailing list ==== - Compose an email to crossfire-maps at lists.sourceforge.net and include the map file as an attachment * Try to keep the attachment at 1MB or less in size - * If possible, avoid composing the message in HTML format -- this helps keep the mail archives "looking nice" and consistant + * If possible, avoid composing the message in HTML format -- this helps keep the mail archives "looking nice" and consistent * If you would like to sign up for the Crossfire Maps mailing list, visit https://lists.sourceforge.net/lists/listinfo/crossfire-maps ==== Trunk or Branch ? ==== Brand new content that has never been seen before and is not an update or patch of existing maps should go into trunk. Updates and patches to existing maps should go into trunk and branch. + IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/map_making?rev=1199485065 New Revision: http://wiki.metalforge.net/doku.php/map_making -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 6 15:02:11 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 06 Jan 2008 15:02:11 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map-making_guide Message-ID: <1199653331.412149.18346.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/06 15:02 User : kbulgrien Edit Summary: Link dev:object_types; add fixme to chapter 2 reference. @@ -39,18 +39,22 @@ === What is an "NPC"? === NPC means "Non Player Character". That are typically friendly guys hanging around in towns, willing to talk to you or help you in other forms. Like in most roleplay games, these folks are commonly used in Crossfire to provide the player with information about quests. + ==== Object types - Adding functionality to an object ==== - The most important attribute of an object is the "type" (a number from 1-159). The object-type determines the "purpose" of the object, the object's "functionality". Is it eatable? is it a teleporter? a rune? a key? This is set by the type of the object. + The most important attribute of an object is the "[[dev:object types|type]]" (presently a number from 1-161). The object-type determines the "purpose" of the object, the object's "functionality". Is it eatable? is it a teleporter? a rune? a key? This is set by the type of the object. Very important: The ARCHETYPE DOES NOT AFFECT the PURPOSE of an object! I can take the food arch and make it work as teleporter, by setting "type 41". I can also take a teleporter- or door arch and make it eatable by setting "type 6". - + In chapter 2. there is a list of all types that are involved in map-making. Descriptions of their most important attributes and how to use them. For creating simple maps, you can use the predefined arches mostly as they are. But when you want to make some really cool maps, there is no other way but to read chapter 2. carefully. + + \\ \\ FIXME Link/create "Chapter 2". + ==== Commonly used attributes ==== The following attributes are used for many different object-types: (These are only mentioned here, not in the detailed list of object-types later. Apply them to all objects where they make any "sense".) IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/map-making_guide?rev=1164519660 New Revision: http://wiki.metalforge.net/doku.php/map-making_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 6 15:46:52 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 06 Jan 2008 15:46:52 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:object_types Message-ID: <1199656012.582157.18424.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/06 15:46 User : kbulgrien Edit Summary: Merge object type information from map-making_guide. @@ -11,10 +11,471 @@ * [[http://crossfire.svn.sourceforge.net/viewvc/crossfire/server/trunk/include/define.h|server/include/define.h]] ======Type Information====== + ===== List of object types, their attributes and functionality:= ==== - =====HOLE (94)===== + ==== type 0: misc ==== + + Type 0 means: The object has no special functionality. + This usually applies for walls, floors and monsters. + + === floors: === + + * "is_floor 1" marks the object as floor. Any objects below will be invisible to the player. Never use a partly transparent pic for an object with is_floor! Every square visible to the player should contain a floor. Don't forget to put floors below walls and monsters! + * "no_pick 1" should be set for all floors. Prevents the player from picking the floor up. + * "unique 1": If this attribute is set to a floor tile, this square is treated as a "unique map". That means this part of the map doesn't get resetted like normal maps. Thus, when a player drops items to this square, they'll stay there forever, unless picked up again. + All the unique and permanent apartments have this flag set to every floor tile. + + === walls: === + + * "blocksview 1" makes the wall blocking a player's view. Keep in mind that the player might still be able to look behind it with xrays. If necessary, make the wall two squares wide for perfect blocking view. It is very bad style when a player can see map-mechanisms with xray. If using a wall with "blocksview 0" (like fence/gates), be aware that the player can jump through it via dimension door. You must set "no_magic 1" and "damned 1" to prevent this. + * "no_pass 1" makes the wall non-passable. The player cannot walk through. You can create a secret passage by setting "no_pass 0" (and "no_pick 1"). Remember to put a hint somewhere so the player can find that spot! A huge room with a secret passage and no hint, that SUUUCKS. + * "tear_down 1", "alive 1", "hp/maxhp/level > 0" and some animation: This creates another form of secret passage - The break-away-walls. + + === monsters/ NPCs: === + + * "alive 1" and "monster 1" turns an object into a basic monster: It blocks the way, (per default) attacks the player and usually it can be killed. + * "unaggressive 1" makes the monster stand still, not attacking the player until being attacked first. Should not be used for NPCs since the chance for accidentally killing an unaggressive creature is rather high. + * "friendly 1" should be used for all NPCs. When set to peaceful mode, a player won't attack such an NPC but push him instead. However, it is still possible to kill it. If your NPC plays a very important role in a quest, it might be useful to set immunity to all attacktypes (see "resist_ "). + * "Pow ": If the creature can cast spells, this is how many spell points are regenerated each move. + * "Con ": Monsters regenerate this many hit points each move. This is each time the monster has a move (same for Pow). So two monsters with the same Con can regenerate at different rates if their speeds are different. + * "Wis ": Determines how close a player needs to be before the creature wakes up. This is done as a square, for reasons of speed. Thus, if the wisdom is 11, any player that moves within the 11x11 square of the monster will wake the monster up. If the player has stealth, the size of this square is reduced in half plus 1. + * "hp > 0": The monster's hitpoints + * "maxhp > 0": The monsters maximum hitpoints (very important since most monsters regenerate hp fast). + * "resist_ " rises the monster's resistance from by percent. 100 means perfect immunity. When set to -100, the monster will receive double damage from this attacktype. + * "attacktype <[[number]]>": the bitmask determines the monster's attacktypes. Attacktypes are: physical, magical, fire, cold.. etc. Read the details about attacktypes [[here]]. + * "exp " defines the amount of experience a player will get for killing the monster. You should be very careful with setting exp values. Take a good look at existing arches and try to adopt the "overall power/exp"-ratio of monsters. Note that non-spellcasting monsters in general are *much* easier to kill, thus deserve lower exp. + + ==== type 3: Rod ==== + + Functionality of rods: + A rod contains a spell. The player can use this spell by applying and firing the rod. Rods need time to regenerate their "internal" spellpoints, lowering the effectiveness in combat. But unlike wands/scrolls, rods can be used endlessly. + + * "sp <[[spellnumber]]>" sets the spell of the rod. A list of all spellnumbers can be viewed [[here]]. Consider twice before handing out special rods to players, since they can be used endlessly without any mana cost! Rods with heal/ restoration/ protection spells, IF available, MUST be very very VERY hard to get! + * "level " is the casting level for the spell of that rod. For attack spells, level should be set to something reasonable. + * "hp " is the initial amount of spellpoints in the rod. + * "maxhp ": is the maximum amount of spellpoints the rod can hold. Make sure it is enough to cast the contained spell at least once. But don't set the value too high, that would make the rod too effective. + + see also: [[horn]] (35), [[wand]] (109) + + ==== type 4: Treasure ==== + + Functionality of treasure: A treasure-object turns into certain randomitems when the map is loaded into the game. + + * "randomitems " determines what kind of treasure will appear. Look into /crossfire/share/crossfire/treasures for details about existing treasurelists. + * "auto_apply 1" must be set in order to have the treasure be created when the map is loaded. If you want to create a random treasure chest, you set "auto_apply 0". That way, the player has to apply the object (the chest), then the treasure is generated. + * "hp ": pieces of the given treasurelist will appear. Note that for every piece there is a chance that nothing is generated. Also, sometimes there can be stacks of items generated, like for gems/money. (Setting "nrof" for treasure - objects doesn't have any effect!) + + About usage of the random-artifact treasurelist: + This will generate powerful stuff like girdles, xray helmets, special swords etc. If you put this as reward to your quest, players might be motivated to do it more than once. BUT, by doing so they will get a huge number of different artifacts! Besides, players will always seek the place with the most easy-to-get random artifact and ignore all others. My advice: Don't use it! Attract players with good fighting experience (from monsters), potions, spellbooks, money, and non-random artifacts. + + ==== type 5: potion ==== + + Functionality of potions: + The player can drink these and gain various kinds of benefits (/penalties) by doing so. + + * "level ": If the potion contains a spell, the spell is cast at level . For other potions it should be set at least to 1. + * "cursed 1" generally turns benefits into penalties (see below). Note that potions can be "uncursed" by praying over an altar, with relative ease. *But* the potion must be identified to notice that it is cursed >:) + * "Str/Dex/Con/Int/Wis/Pow/Cha " makes a stat-potion. The player's stat will rise/fall by value for permanent (of course there is an upper limit). Generally there shouldn't be stat potions granting more than one stat. Cursed potions will subtract the stats if positive. + * "resist_ " makes a resistance potion. Resistance from by percent. The effect is only temporary, and it does NOT add on the values from the player's equipment. Cursed potions will make negative resistance.. very nasty in combat! + * "sp ": When a player drinks this potion, the spell of number will be casted (once). This should work for any given spell. Look for spellnumbers here. E.g. heal is "sp 35", magic power is "sp 67". + * "attacktype 1048576" makes an improvement potion. (I know, using attacktype for this is very ugly, bleah!!) If your potion is NOT supposed to be an improvement potion, leave attacktype zero. + + ==== type 6: food ==== + + Functionality of food: + By eating/drinking food-objects, the player can fill his stomach and gain a little health. + + * "food ": The player's stomach will get filled with of foodpoints. The player's health will increase by /50 hp. + + see also: [[flesh]] (72) + + ==== type 7: poison food ==== + + Functionality of poison food: + When eating, the player's stomach is drained by 1/4 of food. If his food drops to zero, the player might even die. + + ==== type 8: books ==== + + Functionality of books: + Applying a book, the containing message is displayed to the player. + + * "msg endmsg": is the text "written" in the book. + * "level ": If is greater zero, the player needs a certain literacy level to succeed reading the book. The book can be read if: mental_level greater - 5. Adding level to a book can be a nice idea, personally I like it when a player needs more than his fighting skills to solve a quest. However, keep the booklevel at least below 15 because it is quite hard to gain high mental levels. + + see also: [[spellbook]] (85), [[sign]] (98), [[scroll]] (111) + + ==== type 9: clock ==== + + Functionality of clocks: + Applying a clock, the time is displayed to the player + + ==== type 13: arrow/bolt ==== + + Functionality of arrows/bolts: + Arrows can be shot with bows, bolts with crossbows. They are usually weaker than melee but players can shoot from a safe distance. + + * "race " should be set to either "race arrows" or "race crossbow bolts". If not, they won't work with bows/crossbows. + * "dam " is the damage the projectile can inflict. + * "wc ": weapon-class bonus + * "attacktype <[[attack_num]]>": the bitmask determines the weapon's attacktypes. Read a more detailed description about attacktypes [[here]]. + * "food " is the percentage chance of the projectile to break after hitting. "food 0" means it won't ever break, "food 100" means it will always break at first hit. + + ==== type 14: shooting weapon ==== + + Functionality of Shooting Weapons: + Bows can fire arrows, crossbows can fire bolts. You could also create your own pair of projectile & shooting weapon. When the "race"-attribute of both matches, it should work. + + * "race " should be set to either "race arrows" or "race crossbow bolts". If not, they won't work with bows/crossbows. + * "sp ": After shooting a projectile, the player is frozen for a short period of time (to prevent shooting arrows machine-gun-like). The greater , the shorter this period of time. "sp 1" means the player is frozen for a looong time. "sp 0" means the player is turned to stone forever. Nice, hum? =P + + see also: [[weapon]] (15) + + ==== type 15: weapon ==== + + Functionality of weapons: + Wielding a weapon, the object's stats will directly be inherited to the player. Usually enhancing his fighting-abilities. Non-magical weapons can be improved with scrolls. + + * "dam " is the damage this weapon does per hit. will add to the base damage of the player. + * "attacktype <[[attack_num]]>": the bitmask determines the weapon's attacktypes. Attacktypes are: physical, magical, fire, cold.. etc. Read a more detailed description about attacktypes [[here]]. Most artifact weapons have no more than one or two attacktypes. Keep in mind that all weapons can be blessed by the player's deity, thus adding an additional attacktype. When a player hits a monster with a weapon that has more than one attacktype, then he will do as much damage as the "best" of his attacktypes does. So, the more attacktypes you've got, the better your chance to take advantage of a monster's vulnerabilities. (Btw: Same rule applies for monster vs. player.). Attacktypes "magic" and "chaos" are somehow exceptions. + * "resist_ " adds resistance to the weapon. Resistance from by percent. Treat this with CARE. Look at other maps and what they require to do for getting this-and-that artifact. + * "Str/Dex/Con/Int/Wis/Pow/Cha ": The wielder's stat(s) will rise/fall by value for permanent. Again, don't mess around with this! Stats-bonus is very powerful. (Stat bonus does not mark a weapon being "magical") + * "slaying ": The weapon does triple damage to monsters of this category. On the other hand, no god blessings are possible for such weapons. + * "last_sp " determines the weapon-speed. The lower the faster, "last_sp 1" is best (that is lightning- fast). A typical average value is 8. Speed and damage should be kept in reasonable relation. + * "path_attuned/repelled/denied <[[spellpath]]>": This modifies the player's attunement to certain spellpaths. Attunes are more a matter of rings/amulets, while repels/denies are quite common. Remember that weapons are in general the barbarians' tools, not the wizards'. Read the details about spellpaths [[here]]. + * "wc ": weapon-class bonus + * "magical " sets the weapon's magic bonus. It works just like wc, except that magic bonus can be improved by the gods or reduced by acid. Hence, it is less useful than direct wc on a weapon. + + General notes on artifacts (equipment) with stats- or resistance-bonus: + Keep playbalance in mind! Such items mustn't be reachable without hard fighting AND questing. + See "[[golden rules of map-making]]". + + ==== type 16: (brestplate) armour ==== + + Functionality of armour: + Wearing an armour, the object's stats will directly be inherited to the player. Usually enhancing his defense. + + * "resist_ " adds resistance to the armour. Resistance from by percent. "physical protection" (= armour) is referred to as resist_physical. + * "Str/Dex/Con/Int/Wis/Pow/Cha ": The wielder's stat(s) will rise/fall by value for permanent. + * "path_attuned/repelled/denied <[[spellpath]]>": This modifies the player's attunement to certain spellpaths. + * "last_heal " poses a penalty to spell regeneration speed, for wearing the armour. The bigger , the worse. + * "last_sp " reduces the player's walking speed when wearing the armour. The bigger , the worse. + * "sp " speeds up the players mana-regen. rate by . (negative values reduce mana-regen). + * "ac ": armour-class bonus + * "magical " sets the armour's magic bonus. It works just like ac, except that magic bonus can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct ac on the armour. + * "xrays 1" enables xray-vision for the player, while wearing this armour. + + see also: [[shield]] (33), [[helmet]] (34), [[amulet]] (39), [[ring]] (70), [[cloak]] (87), [[boots]] (99), [[gloves]] (100), [[bracers]] (104), [[girdle]] (113) + + These all work more or less exactly like brestplate armour. + + ==== type 17: pedestal==== + + Functionality of pedestals: + Pedestals are designed to detect certain types of living objects. When a predefined type of living creature steps on the pedestal, the connected value is triggered. + + * "slaying " specifies the object we're looking for. If matches the monster's or the player's race, we have a match. Yes, pedestals can detect a player's race! E.g. you could create a place where only fireborns can enter, by setting "slaying unnatural". If "slaying player" is set, any player stepping on the pedestal is a match. Very useful if you want to open a gate for players but not for monsters. + * "connected " defines the connector value to be activated when the pedestal is triggered. + * "walk_on 1", "walk_off 1" should both be set or it won't work. + + Notes on usage: + If you want to create a place where only players of a certain race can enter, put a [[teleporter]] over your pedestal. So the [[teleporter]] is only activated for players of the matching race. Do not use gates, because many other players could sneak in. If you put powerful artifacts into such places, generally set "startequip 1", so that they are preserved for that one race and can't be traded to others. + + see also: [[detector]] (51), [[inv. checker]] (64), [[altar]] (18) + + ==== type 18: altar ==== + + Functionality of altars: + When a player puts a defined number of certain items on the altar, then either a spell is casted (on the player) or a connector is triggered. If the latter is the case, the altar works only once. Either way, the sacrificed item dissapears. + + * "slaying " specifies the item that must be put on the altar to activate it. can either be the name of an archetype, or directly the name of an object. Yet, titles are not recognized by altars. Remember to put a note somewhere, telling the player what he is expected to drop on the altar. (Often this is put in the altar's name: E.g. "drop 100 platinums") + * "food " is the amount of items (specified as above) that must be dropped to activate the altar. If "slaying money" is set, then the value of the sacrificed money must be equal to (ie, if food=200, then 200 silver, 20 gold, or 4 platinum will all work.) Note that the maximum possible for is 32767. + * "walk_on 1" must be set or it won't work. + * "connected ": If is set, the altar will trigger all objects connected to it, when activated. This will only work once. + * "sp <[[spell_number]]>": When activated, the spell of number will be casted (once, on the player). This should work for any given spell. Look for spellnumbers [[here]]. The altar will work infinitely in this way. Don't set both "sp > 0" and "connected > 0" for one altar. + + see also: [[altar_trigger]] (31), [[holy altar]] (56) + + ==== type 20: locked door ==== + + Functionality of locked doors: + A locked door can be opened only when carrying the appropriate [[special key]]. + + * "slaying " must be identical with the slaying in the special key, then door is unlocked. It is VERY important to set to something that is unique among the CF mapset. DONT EVER USE the default string "set_individual_value". + * "msg endmsg": When a player is trying to open the door without carrying the appropriate key, is displayed to the player. This is a good opportunity to place hints about the special key needed to unlock the door. + * "no_magic 1", "damned 1" should always be set to prevent players passing through the door by dimension door spell. + + Notes on usage: + If you want to create a locked door that cannot be opened (no key), set a slaying like "no_key_available". This will clarify things and only a fool would create a key matching that slaying. Door-objects can not only be used for "doors". In many maps these are used with all kinds of faces/names, especially often as "magic force". A good example is the map "Lake_Country/ebony/masterlev". There you have magic forces (door objects) put under certain artifact items. To get your hands on the artifacts, you need to bring up the appropriate quest items (key objects). + + see also: [[special key]] (21) + + ==== type 21: special key ==== + + Functionality of special keys: + When carrying the appropriate special key, a locked door can be opened. The key will disappear. + This object-type can also be used for "passport"-like items: When walking onto an [[inventory checker]], a gate for example might get opened. The "passport" will stay in the player's inventory. + + * "slaying " must be identical with the slaying in the locked door, then it can be unlocked. It can also be used to trigger [[inventory checkers]]. + * "material 0" (no material) or "material 256" (adamantite) should be set. This prevents the key from getting burned or otherwise destroyed. + * "msg endmsg": This will add a description to the object. The player can read by clicking on the item in his inventory. Use this message to describe what the key/passport is good for. A player might have 50 different keys on his key-ring. Don't expect players to recall their purpose just by their names. + + Notes on usage: + How to make a "passport": You take the special key arch (archetype name is "key2"), set the face to something like card.111 and the name to "passport" - that's all. The slaying certainly must match with the appropriate [[inventory checker]]. + + Of course you can be creative with names and faces of key-objects. A "mysterious crystal" or a "big dragon claw" (with appropriate faces) appear more interesting than just a "strange key", or "passport". + + see also: [[locked door]] (20), [[inventory checker]] (64) + + ==== type 29: magic ear ==== + + Functionality of magic_ears: + Magic_ears trigger a connected value when the player speaks a specific keyword. + + * "msg endmsg" contains the keyword-matching-syntax. should have the following format: "@match ||... ". Any number of keywords from one to infinite is allowed. Make sure they are seperated by a '|'. Examples: "@match yes", "@match gold|treasure". The connected value will be triggered when the player speaks any of the given keywords. IMPORTANT: Upper/lower case does not make a difference! + * "invisible 1" should always be set for magic_ears. They cannot be discovered by the show invisible spell, so it doesn't matter if you put them above or below the floor. + + Notes on usage: + Whenever you put magic_ears on your maps, make sure there are CLEAR and RELIABLE hints about the keywords somewhere. Don't make something + like a gate that is opened by speaking "open" or "sesame", expecting the player to figure this out all by himself. + + Magic_ears are typically used for interaction with NPCs. You can create the impression that the NPC actually *does* something according to his conversation with a player. Mostly this means opening a gate or handing out some item, but you could be quite creative here. + + ==== type 31: altar_trigger ==== + + Functionality of altar_triggers: + Altar_triggers work pretty much like [[normal altars]] (drop sacrifice -> connection activated), except for the fact that they reset after usage. Hence, altar_triggers can be used infinitely. + + * "slaying " specifies the item that must be put on the altar to activate it. can either be the name of an archetype, or directly the name of an object. Yet, titles are not recognized by altars. Remember to put a note somewhere, telling the player what he is expected to drop on the altar. (Often this is put in the altar's name: E.g. "drop 100 platinums") + * "food " is the amount of items (specified as above) that must be dropped to activate the altar. + If "slaying money" is set, then the value of the sacrificed money must be equal to (ie, if food=200, then 200 silver, 20 gold, or 4 platinum will all work.) Note that the maximum possible for is 32767. + * "walk_on 1" must be set or it won't work. + * "connected ": If is set, the altar will trigger all objects connected to it, when activated. (With "last_sp 0", it triggers again when the altar is reset.) + * "last_sp 1": If set, the altar_trigger won't push the connected value by altar reset. Only ONCE by dropping the sacrifice. This is typically used when the altar is connected to a [[creator]], e.g. for selling tickets. If "last_sp 0" is set (default), the altar_trigger will push the connected value TWICE per sacrifice: First by dropping sacrifice, second by reset. This mode is typically used for altars being connected to gates, resulting in the gate being opened and closed again. + + Hints on usage: + Altar_triggers are very useful if you want to charge a price for... + + * ...an item. -> Connect the altar_trigger (set "last_sp 1") to a [[creator]]. See also: [[converters]]. + * ...opening a gate. -> Connect the altar_trigger (set "last_sp 0") to the gate. + * ...information. -> Connect the altar_trigger (set "last_sp 1") to a [[magic_mouth]]. + + The big advantage over [[normal altars]] is the infinite usability of altar_triggers! If there are ten players on one server, they're quite grateful if things work more than once. =) + + see also: [[altar]] (18) + + ==== type 40: mover ==== + + Functionality of movers: + Movers move the objects above them. However, only living objects are affected (monsters/NPCs always, players optional). Movers have a direction, so players can be made to move in a pattern, and so can monsters. Motion is involuntary. Additionally, players or monsters can be "frozen" while ontop of movers so that they MUST move along a chain of them. + + Multisquare monsters can be moved as well, given enough space. Movers are usually invisible. + + * "attacktype 1": If attacktype is nonzero, the mover "freezes" anyone it moves (so they are forced to move along a chain). However, this has nothing to do with the common in-game attacktypes. Default is "attacktype 1". + * "maxsp ": The player will be "frozen" for moves. If unset, and "attacktype 1", maxsp becomes 2. Otherwise it is zero by default. + * "walk_on 1" must be set or it won't work properly. + * "fly_on 1" means all flying (living) objects will get moved as well. A mover with "fly_on 0" will move only walking (non-flying) creatures. + * "speed " determines how fast a chain of these movers will push a player along (default -0.2). + * "sp " specifies the mover's direction. 1=up, 3=right, 5=down, 7=left. A mover with "sp 8" will spin clockwise. + * "level 1": If this is set, both players and monsters will be moved. The arches' default is "level 0", ONLY monsters get moved. Remember that "monsters" includes NPCs! This feature provides you with the possibility to make NPCs literally "come to life". Example: The player is talking with an NPC, speaking a certain keyword. This triggers a magic_ear and activates creators, creating (per default: monster-only) movers under the NPC's feet. The NPC starts "walking" on a predefined route! Note that it's useful to set this NPC immune to everything, preventing the player to push the NPC off his trace. + * "lifesave 1" means the mover can be "used up" after a certain number of moves (-> hp). A mover of "lifesave 0" works infinitely. (I know this is opposite to the common sense of "lifesave", but we gotta accept it) + * "hp " has only a meaning if lifesave is set: is the number of times minus one, that it will move a player before disappearing. (It will move someone +1 times, then vanish). + + Notes on usage: + NEVER EVER consider a mover to be impassable in the backwards direction. Setting "attacktype 1" makes it seemingly impossible but there is still a trick: One player can push a second player past the mover, in opposite to the mover's direction! The more movers, the more players needed. Hence, don't make a treasure room that is surrounded by movers instead of solid walls/gates. It should be noted though that this behavior can be used for intentionally multi-player maps, and there is one such example in pupland, however it should be noted that forcing players to use that to get through would usually be considered a bit too counterintuitive unless it is hinted to. + + Btw, it does not make a difference putting movers above or below the floor. Moreover, movers that are "invisible 1" cannot be discovered with the show_invisible spell. + + Note on directors: + Movers and Directors are separate objects, even though they look and act similar. Directors only do spells/missiles, while movers only do living creatures (depending on how it is set: monsters and players). + + see also: [[director]] (112) + + ==== type 41: teleporter ==== + + Functionality of teleporters: + When the player walks into a teleporter, he is transferred to a different location. The main difference to the object-type [[exit]] is the possibility to have teleporters connected to levers/buttons/etc. Sometimes teleporters are activated even against the players will. + + Unlike [[exits]], teleporters can transfer also items and monsters to different locations on the same map. + + * "slaying " defines the map that the player is transferred to. can be an absolute path, beginning with '/' (for example "/peterm/FireTemple/fire1"). It can also be a relative path, not beginning with '/' (On the map "/peterm/FireTemple/Fire2" for example I could use the relative path "Fire1"). Use relative paths whenever possible! Note that upper/lower case must always be set correctly. However, please use lower case only. If the slaying is set, ONLY players can get teleported. If slaying is unset ("slaying 0"), anything can get teleported: Players, monsters and items. In this case, the destined map is automatically the same map the teleporter is on. + * "hp ", "sp ": hp, sp define the (x, y)- coordinates of the exit's destination. If both are set to zero and "slaying 0" is set, the player will get teleported to another, randomly chosen teleporter on the same map (Slightly confusing for the player though). Make sure there actually *is* a second one in that case. If both (sp,hp) are zero but slaying is set, the player will be transferred to the "default enter location" of the destined map. The latter can be set in the map's attributes as "hp"/"sp", with crossedit there are input masks labeled "Start X"/"Start Y". Though, please DO NOT use that. I wrote it here only so that you understand some existing maps. It turned out to be a source for numerous map-bugs. + * "speed ": If speed is nonzero, the teleporter will automatically be activated in regular time-intervals. Hence, the player can just step on it and gets teleported sooner or later. The duration between two activates depends on . Default in the teleporter arch is "speed 0.1". VERY IMPORTANT: If you want to have your teleporter activated via button/handle/magic_ear/etc, you must set "speed 0"! + * "connected ": If set, the teleporter will be activated when the connection is triggered. As stated above, to use this, speed must be zero. + + Notes on usage: + Teleporters must always be placed above the floor in order to work correctly! + + When creating maps, I guess sooner or later you'll want to have an invisible teleporter. If using "invisible 1", the teleporter can still be discovered with the show_invisible spell. And you can't place it under the floor to prevent this. Fortunately, there is a cool trick to make a perfectly invisible teleporter: You simply add teleporter functionality to the floor itself. That means: You take the floor arch (e.g. "flagstone"), set "type 41", and add slaying/hp/sp/connected... everything you need. + + see also: [[exit]] (66) + + ==== type 42: creator ==== + + Functionality of creators: + A creator is an object which creates another object when it is triggered. The child object can be anything. Creators are VERY useful for all kinds of map-mechanisms. + + * "other_arch " defines the object that will be created. You can choose any of the existing arches. + * "connected ": If is activated, the creator is triggered. + * "hp ": The creator can be triggered times, thus creating objects, before it disappears. Default is "hp 1" (-> one-time usage). + * "lifesave 1" means the creator will work infinitely, regardless of hp. + * "slaying ": The created object will bear the name . If no slaying is set, the standard name of the archetype is used. + * "level : The created object will be of level . Again, if not set, the standard level of the archetype is used. + + Notes on usage: + Don't hesitate to hide your creators under the floor. The created items will still always appear ontop of the floor. + + see also: [[rune]] (154) + + ==== type 51: detectors ==== + + Functionality of detectors: + Detectors work quite much like [[inv. checkers]]/[[pedestals]]: If the detector finds a specific object, it toggles its connected value. + + What is "unique" about them, compared to [[inv. checkers]]/ [[pedestals]]? - First, detectors check their square for a match periodically, not instantly. Second, detectors check directly for object names. Third, detectors do not check the inventory of players/monsters. + + * "slaying " specifies the name of the object we are looking for. Actually it does also check for slayings in key-objects, but for this case inv. checkers are often more powerful to use. + * "speed " sets the time between two detector-checks. If you want the detector to behave almost like pedestals/buttons, set speed rather high, like "speed 1.0". + + Notes on usage: + There is one major specialty about detectors: You can detect spells blown over a detector! To detect a lightning bolt for example, set "slaying lightning" and "speed 1.0". In combination with [[spellcasting walls]], this can be very useful for map-mechanisms. + + see also: [[pedestal]] (17), [[inv. checker]] (64), [[altar]] (18) + + ==== type 55: marker ==== + + Functionality of markers: + A marker is an object that inserts an invisible force (a mark) into a player stepping on it. This force does nothing except contain a string in its slaying field which can be discovered by detectors or [[inv. checkers]]. It is also possible to use markers for removing marks again. + Note that the player has no possibility to "see" his own marks, except by the effect that they cause on the maps. + + * "slaying " is the "lockcode" that can be detected by inv. checkers/detectors. If the player already has a force with that slaying, there won't be inserted a second one. + * "speed " defines how quickly it will mark something standing on the marker. Set rather high to make sure the player really gets his mark. I think "speed 1.0" should do fine. + * "food " sets the duration of the force it inserts. If nonzero, the duration of the player's mark is finite: about 1 food per 10 seconds. "food 0" means the mark will stay on the player forever. + * "name ": When the player steps onto the marker, all existing forces in the players inv. with slaying will be removed. If you don't want to remove any marks, simply name your object "marker". I know, involving an object's name in it's functionalities is rather uncommon and irritating... but hey, we gotta deal with it. =) + * "msg endmsg": In the moment when the player gets marked, the message is displayed to him. You should usually set a message in any marker you create, because it's the only way for the player to notice what's going on. + + Notes on usage: + Markers hold real cool possibilities for map-making. I encourage you to use them frequently. However there is one negative point about markers: Players don't "see" what's going on with them. It is your task, as map-creator, to make sure the player is always well informed and never confused. + + Please avoid infinite markers when they aren't needed. They're using a little space in the player file after all, so if there is no real purpose, set an expire time. + + see also: [[inventory checker]] (64) + + ==== type 56: holy altar ==== + + Functionality of holy_altars: + Holy_altars are altars for the various religions. Praying at a holy_altar will make you a follower of that god, and if you already follow that god, you may get some extra bonus. (See: [[god intervention]]) + + * "other_arch " specifies the god that the altar belongs to. Possible options for are: Devourers, Lythander, Mostrai, Gaea, Ruggilli, Gnarg, Gorokh, Valriel and Sorig. If you want to have an unconsecrated altar, set "other_arch 0" and "level 0". + * "level ": To re-consecrate an altar, the players skill level (wisdom level) must be as high or higher than the level field. In this way, some altars can not be re-consecrated, while other altars, like those in dungeons, could be. + Altars located in temples should have at least "level 100". Some characters might need those altars, they would be very unhappy to see them re-consecrated to another cult. + + see also: [[altar]] (18) + + ==== type 62: magic wall ==== + + Functionality of magic walls: + Magic walls fire spells in a given direction, in regular intervals. Magic walls can contain any spell. However, some spells do not operate very successfully in them. The only way to know is to test the spell you want to use with a wall. + + Several types of magical walls are predefined for you in the archetypes, and can be found on a pick-map available in crossedit. + + * "dam <[[spellnumber]]>" specifies the spell the wall will cast. You can find a list of spellnumbers [[here]]. + * "level ": The wall will cast it's spells at level . "level 1" walls cast spells at minimal strength. "level 100" walls cast deadly spells. Arch default is level 1 - you should rise it to meet the overall difficulty of your map. + * "sp " holds the direction in which the wall will cast the spell. 1=north, 2=northeast, 3=east,... , 8=northwest. A magic wall with "sp 0" will always fire in a random direction. + * "speed " defines the spellcasting speed of the wall. You can fine-tune how long the duration between two casts shall be. If you want to create a wall that can be activated (cast per trigger) via connected lever/button/etc, you must set "speed 0". + * "connected " means the wall will cast a spell when it is triggered via . Set "speed 0" or it won't have much visible effect. + * "no_pass 1", "blocksview 1" should be set for "normal" wall-behavior: blocking view and non-passable. Yet, this is not a rule written in stone. You could make invisible, passable magic walls... the spells will then seemingly appear out of nowhere. + * "alive 1" means the wall can be attacked and destroyed. If set, you must also set the common monster-attributes: hp, maxhp, resistances. See description of [[monsters]]. + + Notes on usage: + Spellcasting walls pose an interesting alternative to monsters. Usually they are set to be undestroyable ("alive 0"). Thus, while monsters in a map can be cleared out, the magic walls remain. Low level characters for example will not be able to pass through their spell-area, hence they cannot loot a map that a high level character might have cleared out. + + Another point of magic walls is that if the player dies, he has to face them all again. Magic walls can add a kind of "permanent thrill" to your maps. + + Be careful that your magic walls don't kill the monsters on a map. If placing monsters, eventually take ones that are immune to the walls' spell(s). + + It is possible to make walls rotate when triggered. But that is so confusing (and useless IMHO) that I did not mention it above. You can find a working example on the map "/pup_land/castle_eureca/castle_eureca8". + + ==== type 64: inventory checker ==== + + Functionality of inventory checkers: + Inventory checkers passively check the players inventory for a specific object. You can set a connected value that is triggered either if that object is present or missing (-> "last_sp") when a player walks over the inv. checker. A valid option is to remove the matching object (usually not recommended, see "last_heal"). + + Alternatively, you can set your inv. checker to block all players that do/don't carry the matching object (-> "no_pass"). + As you can see, inv. checkers are quite powerful, holding a great variety of possibilities. + + * "slaying " specifies the object we are looking for: We have a match if the player does/don't carry a [[key object]] or a mark (-> see [[marker]]) with identical slaying . Note that [[key objects]] usually appear as "passports" in this context. A typical example is the city gate mechanism of scorn. + * "race " specifies the object we are looking for: We have a match if the player does/don't carry an object of archetype . + * "hp " specifies the object we are looking for: We have a match if the player does/don't carry an object that is of type . Example: Set "hp 15" ([[type 15 => weapon]]) and "no_pass 1". Now you have an inv. checker blocking all players that carry any kind of melee weapon. To pass, a player is forced to leave behind all his weaponry... bad news for a warrior. Nice, hum? :) + * "last_heal 1": Remove object if found. This is usually not recommended because inv. checkers are in general invisible. So, unlike for altars/ locked doors, the player won't expect to lose an object when walking over that square. And he doesn't even get a message either. + So, *if* you set last_heal, make sure to inform the player what's going on! + * "no_pass 1": If set, only players meeting the match criteria can pass through that space. If "no_pass 0" (default), then the inv. checker acts like a trigger/button. + * "last_sp 1" means having that object is a match. "last_sp 0" means not having that object is a match. + * "connected " specifies the connector value to be activated if the inv. checker is triggered. This only makes sense along with "no_pass 0". + + General usage notes: + Putting a check_inventory space in front of a gate (one below) and one on the opposite side works reasonably well as a control mechanism. Unlike the [[key]]/[[door-combo]], this one works infinite since it is independent from map reset. Use it to put a "structure" into your maps: Player must solve area A to gain access to area B. This concept can be found in nearly every RPG - simple but effective. + + see also: [[special key]] (21), [[marker]] (55), [[pedestal]] (17), [[detector]] (51) + + ==== type 65: mood floor ==== + + Functionality of mood floors: + As the name implies, mood floors can change the "mood" of a monsters/NPC. For example, an unaggressive monster could be turned mad to start attacking. Similar, an aggressive monster could be calmed. + + * "last_sp " is used to determine what will happen to the monster when affected by the mood floor: + * "last_sp 0": 'furious' Makes all monsters aggressive + * "last_sp 1": 'angry' As above but pets are unaffected + * "last_sp 2": 'calm' Makes all monsters unaggressive + * "last_sp 3": 'sleep' Puts all monsters to sleep + * "last_sp 4": 'charm' Makes monster into a pet of person who triggers the square. This setting is not enabled for continuous operation, you need to insert a connected value! + * "connected ": This should only be set in combination with "last_sp 4". Normally, monsters are affected by the mood floor as soon as they step on it. But charming (monster -> pet) is too powerful, so it needs to be activated. Typically it is connected to an altar, for buying a "hireling". But a powerful pet could as well be the reward for solving a quest. Or even better: It could be *part* of a quest! + + Notes on usage: + Notes on usage: Mood floors are absolutely cool for NPC interaction. To make an unaggressive monster/NPC attack, put a [[creator]] with + "other_arch furious_floor" under it. Connect the creator to a [[magic_ear]], so the player speaks a keyword like "stupid sucker" - and the monster attacks. + + To turn an NPC into a pet, put a charm_floor under it and connect it directly to a [[magic_ear]]. Then the player speaks a keyword like "help me" - and the NPC joins him as pet. + + (Of course you must always give clear hints about keywords! And there is no reason why you couldn't use a button/lever/[[pedestal]] etc. instead of a [[magic_ear]].) + + ==== type 66: exit ==== + + Functionality of exits: + When the player applies an exit, he is transferred to a different location. (Monsters cannot use exits.) Depending on how it is set, the player applies the exit just by walking into it, or by pressing pply when standing on the exit. + + * "slaying " defines the map that the player is transferred to. can be an absolute path, beginning with '/' (for example "/peterm/FireTemple/fire1"). It can also be a relative path, not beginning with '/' (On the map "/peterm/FireTemple/Fire2" for example I could use the relative path "Fire1"). Use relative paths whenever possible! Note that upper/lower case must always be set correctly. However, please use lower case only. It is well possible to have an exit pointing to the same map that the exit is on. If slaying is not set in an exit, the player will see a message like "the exit is closed". + * "hp ", "sp ": hp, sp define the (x, y)- coordinates of the exit's destination. If both are set to zero, the player will be transferred to the "default enter location" of the destined map. The latter can be set in the map's attributes as "hp"/"sp", with crossedit there are input masks labeled "Start X"/"Start Y". Though, please DO NOT use that. I wrote it here only so that you understand some existing maps. It turned out to be a source for numerous map-bugs. + * "walk_on 1": If set, the player will apply the exit by just walking into it. This must be set for the invisible exits for example. If "walk_on 0", the player has to step onto the exit and press to get transferred. + * "fly_on 1": If set, the player will apply the exit by "flying into it". Flying means the player is levitating. E.g. he might wear the levitation boots. + * "msg endmsg": If set, will be displayed to the player when he applies the exit. This is quite useful to throw in some "role-play feeling": "As you enter the dark cave you hear the sound of rustling dragonscales...". Well, my english is poor, but you got the point. =) + * "unique 1" defines the destined map as "personal unique map". That means there will be a separate version of that map for every player out there. This feature is used for the permanent apartments (in Scorn/Nuernberg/Caterham...). It should not be used for anything else than apartments, since Crossfire is a *multi*player game. In such a permanent apartment don't forget to set "unique 1" for all floor tiles too (see [[floors]]). An exit pointing outside of a "personal unique map" must be "unique 0". + + Notes on usage: + If you want to have an invisible exit, set "invisible 1" (, of course "walk_on 1"), and put it *under* the floor. Otherwise it could be detected with the show_invisible spell. + + You can be quite creative with the outlook of secret exits (their "face"). Don't forget to give the player relyable hints about them though. + + see also: [[teleporter]] (41) + + ==== type 85: spellbook ==== + + Functionality of spellbooks: + By reading a spellbook, the player has a chance of learning the contained spell. Once learned from a book, the spell is available forever. Spellbooks with high level spells require some skill-level to read. + + * "sp <[[spellnum]]>" defines the contained spell. You can look up the spellnumbers [[here]]. You could alternatively use the slaying. + * "slaying <[[spell_name]]>" also defines the contained spell, just like sp, but here you write the spell's name instead of it's number. Saves you the hassle to look it up, and makes your stuff more readable to others. + * "msg endmsg" could contain a nice description of the spellbook's cover or something. + + Notes on usage: + Don't put any of the godgiven spells into a spellbook! These are reserved for the followers of the appropriate cults. Handing them out in a spellbook would violate the balance between different religions. + + If you want to have a random spellbook, you must use the arch "random_spells" ([[type 4]]) instead. + + see also: [[book]] (8) + + ==== type 94: hole ==== Holes send objects that fall through them to a new location on the current map. * The destination after falling through the hole is random. @@ -32,19 +493,138 @@ | position state | wc | | The position state defines the position of the gate: Zero means completely open/down, the "number of animation-steps" (usually about 6 or 7) means completely closed/up state. The default value is usually recommended. | | affected movement | move_on | move_on | Make creatures using these movement types fall into the pit. Movement types other than walking is not the behavior expected from a pit, and other settings should only be used for map-mechanisms (e.g. for transporting flying monsters). An interesting side-effect is if this flag is enabled, spell effects like fire/snow also make their way through the pit. | | | maxsp | | Whether the initial state is open (1) or closed (0). | - =====Common Object Attributes===== + ==== type 98: sign/ magic mouth ==== + + Functionality of signs/ magic_mouths: + The purpose of a sign or magic_mouth is to display a certain message to the player. There are three ways to have the player get this message: The player walking onto it (-> magic_mouth), the player pressing pply (-> sign) or the player triggering a button/handle/etc (-> magic_mouth). + + * "msg endmsg" contains the that will be displayed to the player. + * "invisible 1" should always be set if you want to have the object work as magic_mouth. Put magic_mouths *under* the floor, to prevent them being affected by the show_invisible spell. If you want to have a sign, set "invisible 0". That way the player can see the object, thus apply it, and get the message. + * "walk_on 1": If set, the player gets the message when walking ontop of the object. "invisible 1" should be set in this case. This is the typical configuration for a "magic_mouth": The player walks through a dungeon and suddenly he gets a message. Use this to create some roleplay atmosphere, and to inform the player about possible dangers or secrets. + * "fly_on 1": If set, the player gets the message when flying (=levitating) ontop of the object. Usually this should be set together with walk_on. + * "connected " means the message will be printed when the object is triggered via . This should be used in combination with "invisible 1" and "walk/fly_on 0". If activating your magic_mouth this way, the message will not only be printed to one player, but all players on the current map! + * "food ": If "food" is set, the sign/magic_mouth can be applied (printing the message) only times. For signs this really shouldn't be used, while for magic_mouths it is extremely helpful. Often, you might want to have a message displayed only one time. For example: The player enters your map and you put a magic_mouth to tell him about the monsters and how dangerous they look and all. Later, when all the monsters are killed and the player leaves the map, displaying the same message a second time would be silly. "food 1" does a perfect job in such cases. Otherwise set "food 0" for infinite use (that is the default). + + Notes on usage: + Use signs and magic_mouths, plenty of them! Place magic_mouths to add some true roleplay feeling to your maps, support your storyline or give hints about hidden secrets/dangers. Place signs to provide the player with all kinds of useful information for getting along in your maps. + + see also: [[book]] (8) + + ==== type 103: converter ==== + + Functionality of converters: + Converters are like "exchange tables". When the player drops a specific type of items, they get converted into other items, at a predefined exchange-ratio. + + * "slaying ": is the name of the archetype to convert from. + * "other_arch ": is the name of the archetype to convert into. + * "sp ", "food " defines the exchange-ratio: For pieces of the player will get pieces of . + * "walk_on 1" and "no_pick 1" must always be set for converters. + + Notes on usage: + Converters are better than shopping with doormats, because the converters never get sold out. For some items like food or jewels those "exchange tables" are really nice, while for the more important stuff like potions converters should not exist. + + VERY IMPORTANT: Be careful with the exchange-ratio! When you drop items on a converter, the stuff you get must be of equal or lesser value than before! (Except if you are using "rare" items like dragonscales for payment). The code will not check if your ratio is sane, so the player could gain infinite wealth by using your converter. + + See also: [[creator]] (42) + + ==== type 106: savebed ==== + + Functionality of savebeds: + When the player applies a savebed, he is not only saved. Both his respawn-after-death and his word-of-recall positions are pointing to the last-applied savebed. + + * "no_pick 1" makes sure the savebed is non-pickable. DO NOT CHANGE THIS! + * "no_magic 1", "damned 1" marks the savebed as no-spell-area. Again, DO NOT CHANGE THIS. Sometimes players die in auto fire mode... + + Notes on usage: + Put savebed locations in towns, do not put them into dungeons. It is absolutely neccessary that a place with savebeds is 100% secure. That means: + + * Monsters must not be able to reach the savebeds under any circumstances! + * If there are NPCs around, make sure they have "friendly 1" set. + * Insert a relyable exit! Make sure there is no possibility that players get trapped in a savebed location. + * If possible, mark the whole site as no-spell area (Insert this arch called "dungeon_magic" everywhere). This is not required, but it makes the place much more safe. + + ==== type 109: wand/staff ==== + + Functionality of wands/staves: + Wands contain a certain spell. The player can apply (ready) and fire the wand. After a defined number of casts, the wand is "used up". It is possible to recharge a wand with scrolls of charging, but usually that isn't worth the cost. + + * "sp <[[spellnum]]>" specifies the contained spell. You can look up the spellnumbers [[here]]. + * "level ": The wand/staff will cast at level . An average level for wands in shops is about 10. + * "food " is the number of charges left before it is used up. + + Notes on usage: + Wands are quite seldomly used. The reason prolly is that they're generally not cost-efficient. Handing out high-level wands with powerfull special spells isn't a good idea either, because of the recharge ability. + + For low levels, staffs of healing/cure and word of recall are quite desireable though. + + see also: [[rod]] (3), [[potion]] (5), [[scroll]] (111) + + ==== type 122: container ==== + + Functionality of containers: + A player can put (certain kinds of) items in the container. The overall weight of items is reduced when put inside a container, depending on the settings. + + A special feature of containers is the "cauldron", capable of mixing alchemical receipes. + + * "container ": The container can hold a maximum total weight of gram. Note that this weight limit is calculated *after* the weight reduction (-> Str) has been applied. + * "Str " determines how much the weight of items is reduced in percent, when put inside the container. "Str 0" means no reduction, "Str 100" means items are weightless inside. Most default values are in the range of ten. + * "race ": If set, the container will hold only certain types of objects. Possible choices for are: "gold and jewels", "arrows" and "keys". Unfortunately it is not easy to create new container types, because they are hardcoded. + * "is_cauldron 1": If set, the container can be used as alchemy-cauldron. The player can put ingredients inside, close it, cast alchemy and if his formulae is true, he'll get what he longed for. + * "other_arch " is used for a certain kind of... "animation" when opening the container. Stick to the default arches here and you won't get into trouble. + * "no_pick 1" should be set for all containers that you're using as map-decoration/furniture, like bookshelves, (permanent) chests or deposit boxes. For the ones you want the player to have, set "no_pick 0". + + Note on chests: + There are two types of chests: + First the random treasure chests - Those are NOT containers (but object type 4), they create random treasures when applied. Archetype name is "chest". Second there are the permanent chests - Those are containers, they can be opened and closed again. Archetype name is "chest_2". + + ==== type 154: rune/trap ==== + + Functionality of runes/ traps: + A rune is a magical enscription on the dungeon floor. Traps are just like runes except they are not magical in nature, and generally have a physical attack. + + Runes hit any monster or person who steps on them for 'dam' damage in 'attacktype' attacktype. Alternatively, the rune could contain any spell, and will cast this spell when it detonates. Yet another kind is the "summoning rune", summoning predefined monsters of any kind, at detonation. + + Many traps and runes are already defined in the archetypes. + + * "level ": Level the rune will cast the spell it contains at, if applicable. A level 99 rune casts a very, very mean spell of whatever. ("level 0" runes won't detonate at all!) Level Also effects how easily a trap may be found and disarmed, and how much experience the player gets for doing so. Beware: High level runes can be quite a cheap source of experience! So either make them tough, or keep the level low. + * "Cha " determines what fraction of the time the rune is visible: It'll be randomly visible 1/Cha of the time. Also effects how easily the trap may be found. + * "sp <[[spellnum]]>" defines the spell in the rune, if any. (Many runes and all traps do direct damage). + * "slaying <[[spell_name]]>": Name of the spell in the rune, if any. Slaying is optional, but if present, overrides sp. Recommended for use by mapmakers to ensure portability. + * "hp ": The rune will detonate times before disappearing. + * "attacktype <[[attack_num]]>": If there isn't any spell (and race is unset), this attribute defines what attacktype to use for direct damage when the rune detonates. + * "msg endmsg": When the rune detonates, is displayed to the victim. For especially powerful runes, create an appropriate thrilling description. ;) + * "dam " specifies how much damage is done by the rune, if it doesn't contain a spell. This should be set in reasonable relation to the rune's level. + * "maxsp " sets the direction to cast the spell the rune contains, if any. 1=north, 2=northeast, 3=east, ..., 8=northwest. In most cases this appears useless since the spell directly hits the player. + * "race ": If this is set to the arch name of any monster, together with "slaying summon evil monster", the rune will summon a bunch of those on detonation. (dam and attacktype will still be ignored in this case). In theory, runes are even capable of summoning multi-square monsters, given enough space. You'd better test it though. + * "maxhp " should only be set to a summoning rune. It will then summon creatures of . + + Notes on usage: + Avoid monsters stepping on your runes. For example, summoning runes together with spellcasting- and attack-runes is usually a bad idea. One can use this feature intentionally though to create chain-reactions of summoning runes and such things, however one should be careful about doing this. + + ===== Common Object Attributes ===== + + The following attributes are used for many different object-types: (These are only mentioned here, not in the detailed list of object-types later. Apply them to all objects where they make any "sense".) + + ^ CrossfireEditor ^ Map field ^ Description ^ + | name | name | The name of the object displayed to players. | + | title | title | An object's title. Once the object is identified the title is attached to the name. Typical titles are "of mostrai", "of xray vision" etc. | + | image | face <name_of_face> | The image name defines what picture is displayed for the object. Look through the arches to get an idea of existing faces. | + | | nrof <number | The number of objects in one stack (for example: 100 goldcoins => "nrof 100"). You should set at least "nrof 1" for any pickable object, otherwise it won't be mergeable! | + | | weight <grams> | Makes an object weigh <grams> grams (1000g is 1kg). Objects with "weight 0" are not pickable for players. Still, set "no_pick 1" for explicitly non-pickable objects. | + | | value <num> | Adds a certain value to the object: It will be worth <num> times the default value from it's archetype. Value for buying/selling will be further modified by various factors. Hence, testing values in-game is usually inevitable. + | | material <number> | <number> is a bitmask, containing the information of what material the object is made of. An object's material affects its likelihood to get destroyed by certain hazards (fire/cold/acid..). Material 0 or 256 means the object cannot be destroyed at all (this is VERY important for special keys!). Read more about materials here. | + | | msg \\ <text> \\ endmsg | <text> is the "story" or description of the object (for the players). This should work for all pickable items in some way. For other object-types (living creatures/magic mouth..) this message has special meanings. In crossedit you can write this kind of message into the big text-frame in an object's attribute window. Add stories to all the special artifacts you create! | + | invisible | invisible 1 | Makes the object invisible. Depending on the object-type, some can be made visible by the show_invisible spell. If in doubt, test it. Putting an invisible object under the floor always prevents it from being shown, but, in some cases, might cause malfunction to the object. You may find more detailed info about this matter in the description of the affected object types. | + | glow\ radius | | If glow radius is set to a value greater than zero, the object appears lit up on dark maps. It can be a value between 0 and 4 with higher values emitting greater amounts of light. | + | smooth level | | If smooth level is set to a value greater than zero, the object will be drawn partially over adjacent squares having a lower smooth level. The value must be between 0 and 255 (inclusive) where 0 means "never overlap adjacent squares". | + | elevation | | The elevation, or height above sea level) of this tile. It is used for weather calculations and should be in the range -32000 to 32000. The elevation of a tile must be set in the bottom-most game object; elevation values for non-bottom-most game objects are ignored by the Crossfire server. | + | block view | | If set, players (and monsters) cannot see beyond the object unless they cross it or manage to stand on top of it. | - | name | The name of the object displayed to players. | - | image | The image name defines what image is displayed for this object. | - | glow radius | If glow radius is set to a value greater than zero, the object appears lit up on dark maps. It can be a value between 0 and 4 with higher values emitting greater amounts of light. | - | smooth level | If smooth level is set to a value greater than zero, the object will be drawn partially over adjacent squares having a lower smooth level. The value must be between 0 and 255 (inclusive) where 0 means "never overlap adjacent squares". | - | elevation | The elevation, or height above sea level) of this tile. It is used for weather calculations and should be in the range -32000 to 32000. The elevation of a tile must be set in the bottom-most game object; elevation values for non-bottom-most game objects are ignored by the Crossfire server. | - | invisible | Makes the object invisible. Depending on the object type, some can be made visible by the show_invisible spell. If in doubt, test it. Putting an invisible object under the floor always prevents it from being shown. | - | block view | If set, players (and monsters) cannot see beyond the object unless they cross it or manage to stand on top of it. | ======Server define.h Object Type Excerpt====== + /** * @defgroup OBJECT_TYPE Object types. * * Only add new values to this list if somewhere in the program code, it is @@ -249,6 +829,5 @@ #define OBJECT_TYPE_MAX 161 /* Update if you add new types */ /* END TYPE DEFINE */ /*@}*/ - IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/dev:object_types?rev=1199597359 New Revision: http://wiki.metalforge.net/doku.php/dev:object_types -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 6 15:49:26 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 06 Jan 2008 15:49:26 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map-making_guide Message-ID: <1199656166.689226.18427.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/06 15:49 User : kbulgrien Edit Summary: Object type information now in dev:object_types as it is not suited to the "Introduction" section it was in. @@ -33,608 +33,22 @@ Every line contains an attribute of this goblin object. "face", "name", "hp"... those are all attributes. There are HEAPS of attributes. And to make things even worse: they usually have different meanings for different object-types. Knowing about all the attributes is the key for creating cool maps. The main purpose of this tutorial is to explain every attribute out there, in any kind of functionality. === What is a "map-mechanism"? === - + Okay, I made this word up. What I mean with "map-mechanism" is creating "special effects", usually with combinations of buttons/levers/altars, gates/boulders, creators.. etc. The player pulls a lever and one gate out of three opens at random. That is what I call a map-mechanism. - + === What is an "NPC"? === - + NPC means "Non Player Character". That are typically friendly guys hanging around in towns, willing to talk to you or help you in other forms. Like in most roleplay games, these folks are commonly used in Crossfire to provide the player with information about quests. - ==== Object types - Adding functionality to an object ==== + ==== Object types - Adding functionality to an object ==== The most important attribute of an object is the "[[dev:object types|type]]" (presently a number from 1-161). The object-type determines the "purpose" of the object, the object's "functionality". Is it eatable? is it a teleporter? a rune? a key? This is set by the type of the object. Very important: The ARCHETYPE DOES NOT AFFECT the PURPOSE of an object! I can take the food arch and make it work as teleporter, by setting "type 41". I can also take a teleporter- or door arch and make it eatable by setting "type 6". - In chapter 2. there is a list of all types that are involved in map-making. Descriptions of their most important attributes and how to use them. - - For creating simple maps, you can use the predefined arches mostly as they are. But when you want to make some really cool maps, there is no other way but to read chapter 2. carefully. - - \\ \\ FIXME Link/create "Chapter 2". + On the [[dev:object types|object types]] page there is a list of all types that are involved in map-making. Each listed type has a description of their most important attributes and how to use them. + For creating simple maps, you can use the predefined arches mostly as they are. But when you want to make some really cool maps, there is no other way but to read the object type information carefully. - ==== Commonly used attributes ==== - - The following attributes are used for many different object-types: (These are only mentioned here, not in the detailed list of object-types later. Apply them to all objects where they make any "sense".) - - * "name <name>": <name> will be the name of the object, displayed to the player. - * "title <title>": will be an object's title. Once the object is identified the title is attached to the name. Typical titles are "of mostrai", "of xray vision" etc. - * "face <name_of_face>" selects the picture displayed for the object. Look through the arches to get an idea of existing faces. - * "nrof <number>" determines the number of objects in one stack (for example: 100 goldcoins => "nrof 100"). You should set at least "nrof 1" for any pickable object, otherwise it won't be mergeable! - * "weight <grams>" makes an object weigh <grams> grams (1000g is 1kg). Objects with "weight 0" are not pickable for players. Still, set "no_pick 1" for explicitly non-pickable objects (hey, this is opensource.. you never know ;) ). - * "value <num>" adds a certain value to the object: It will be worth <num> times the default value from it's archetype. Value for buying/selling will be further modified by various factors. Hence, testing values in-game is usually inevitable. - * "material <number>": <number> is a bitmask, containing the information of what material the object is made of. An object's material affects its likelihood to get destroyed by certain hazards (fire/cold/acid..). Material 0 or 256 means the object cannot be destroyed at all (this is VERY important for special keys!). Read more about materials here. - * "msg <text> endmsg": <text> is the "story" or description of the object (for the players). This should work for all pickable items in some way. For other object-types (living creatures/magic mouth..) this message has special meanings. In crossedit you can write this kind of message into the big text-frame in an object's attribute window. Add stories to all the special artifacts you create! - * "invisible 1" generally makes the object invisible. Depending on the object-type, some can be made visible by the show_invisible spell. If in doubt, test it. Putting an invisible object under the floor always prevents it from being shown, but, in some cases, might cause malfunction to the object. You may find more detailed info about this matter in the description of the affected object types. - - ==== List of object types, their attributes and functionality: ==== - - === type 0: misc === - - Type 0 means: The object has no special functionality. - This usually applies for walls, floors and monsters. - - == floors: == - - * "is_floor 1" marks the object as floor. Any objects below will be invisible to the player. Never use a partly transparent pic for an object with is_floor! Every square visible to the player should contain a floor. Don't forget to put floors below walls and monsters! - * "no_pick 1" should be set for all floors. Prevents the player from picking the floor up. - * "unique 1": If this attribute is set to a floor tile, this square is treated as a "unique map". That means this part of the map doesn't get resetted like normal maps. Thus, when a player drops items to this square, they'll stay there forever, unless picked up again. - All the unique and permanent apartments have this flag set to every floor tile. - - == walls: == - - * "blocksview 1" makes the wall blocking a player's view. Keep in mind that the player might still be able to look behind it with xrays. If necessary, make the wall two squares wide for perfect blocking view. It is very bad style when a player can see map-mechanisms with xray. If using a wall with "blocksview 0" (like fence/gates), be aware that the player can jump through it via dimension door. You must set "no_magic 1" and "damned 1" to prevent this. - * "no_pass 1" makes the wall non-passable. The player cannot walk through. You can create a secret passage by setting "no_pass 0" (and "no_pick 1"). Remember to put a hint somewhere so the player can find that spot! A huge room with a secret passage and no hint, that SUUUCKS. - * "tear_down 1", "alive 1", "hp/maxhp/level > 0" and some animation: This creates another form of secret passage - The break-away-walls. - - == monsters/ NPCs: == - - * "alive 1" and "monster 1" turns an object into a basic monster: It blocks the way, (per default) attacks the player and usually it can be killed. - * "unaggressive 1" makes the monster stand still, not attacking the player until being attacked first. Should not be used for NPCs since the chance for accidentally killing an unaggressive creature is rather high. - * "friendly 1" should be used for all NPCs. When set to peaceful mode, a player won't attack such an NPC but push him instead. However, it is still possible to kill it. If your NPC plays a very important role in a quest, it might be useful to set immunity to all attacktypes (see "resist_<attacktype> <number>"). - * "Pow <number>": If the creature can cast spells, this is how many spell points are regenerated each move. - * "Con <number>": Monsters regenerate this many hit points each move. This is each time the monster has a move (same for Pow). So two monsters with the same Con can regenerate at different rates if their speeds are different. - * "Wis <number>": Determines how close a player needs to be before the creature wakes up. This is done as a square, for reasons of speed. Thus, if the wisdom is 11, any player that moves within the 11x11 square of the monster will wake the monster up. If the player has stealth, the size of this square is reduced in half plus 1. - * "hp > 0": The monster's hitpoints - * "maxhp > 0": The monsters maximum hitpoints (very important since most monsters regenerate hp fast). - * "resist_<attacktype> <number>" rises the monster's resistance from <attacktype> by <number> percent. 100 means perfect immunity. When set to -100, the monster will receive double damage from this attacktype. - * "attacktype <[[number]]>": the bitmask <number> determines the monster's attacktypes. Attacktypes are: physical, magical, fire, cold.. etc. Read the details about attacktypes [[here]]. - * "exp <value>" defines the amount of experience a player will get for killing the monster. You should be very careful with setting exp values. Take a good look at existing arches and try to adopt the "overall power/exp"-ratio of monsters. Note that non-spellcasting monsters in general are *much* easier to kill, thus deserve lower exp. - - === type 3: Rod === - - Functionality of rods: - A rod contains a spell. The player can use this spell by applying and firing the rod. Rods need time to regenerate their "internal" spellpoints, lowering the effectiveness in combat. But unlike wands/scrolls, rods can be used endlessly. - - * "sp <[[spellnumber]]>" sets the spell of the rod. A list of all spellnumbers can be viewed [[here]]. Consider twice before handing out special rods to players, since they can be used endlessly without any mana cost! Rods with heal/ restoration/ protection spells, IF available, MUST be very very VERY hard to get! - * "level <number>" is the casting level for the spell of that rod. For attack spells, level should be set to something reasonable. - * "hp <number>" is the initial amount of spellpoints in the rod. - * "maxhp <number>": <number> is the maximum amount of spellpoints the rod can hold. Make sure it is enough to cast the contained spell at least once. But don't set the value too high, that would make the rod too effective. - - see also: [[horn]] (35), [[wand]] (109) - - === type 4: Treasure === - - Functionality of treasure: A treasure-object turns into certain randomitems when the map is loaded into the game. - - * "randomitems <treasurelist>" determines what kind of treasure will appear. Look into /crossfire/share/crossfire/treasures for details about existing treasurelists. - * "auto_apply 1" must be set in order to have the treasure be created when the map is loaded. If you want to create a random treasure chest, you set "auto_apply 0". That way, the player has to apply the object (the chest), then the treasure is generated. - * "hp <number>": <number> pieces of the given treasurelist will appear. Note that for every piece there is a chance that nothing is generated. Also, sometimes there can be stacks of items generated, like for gems/money. (Setting "nrof" for treasure - objects doesn't have any effect!) - - About usage of the random-artifact treasurelist: - This will generate powerful stuff like girdles, xray helmets, special swords etc. If you put this as reward to your quest, players might be motivated to do it more than once. BUT, by doing so they will get a huge number of different artifacts! Besides, players will always seek the place with the most easy-to-get random artifact and ignore all others. My advice: Don't use it! Attract players with good fighting experience (from monsters), potions, spellbooks, money, and non-random artifacts. - - === type 5: potion === - - Functionality of potions: - The player can drink these and gain various kinds of benefits (/penalties) by doing so. - - * "level <number>": If the potion contains a spell, the spell is cast at level <number>. For other potions it should be set at least to 1. - * "cursed 1" generally turns benefits into penalties (see below). Note that potions can be "uncursed" by praying over an altar, with relative ease. *But* the potion must be identified to notice that it is cursed >:) - * "Str/Dex/Con/Int/Wis/Pow/Cha <num>" makes a stat-potion. The player's stat will rise/fall by value <num> for permanent (of course there is an upper limit). Generally there shouldn't be stat potions granting more than one stat. Cursed potions will subtract the stats if positive. - * "resist_<attacktype> <number>" makes a resistance potion. Resistance from <attacktype> by <number> percent. The effect is only temporary, and it does NOT add on the values from the player's equipment. Cursed potions will make negative resistance.. very nasty in combat! - * "sp <spellnum>": When a player drinks this potion, the spell of number <spellnum> will be casted (once). This should work for any given spell. Look for spellnumbers here. E.g. heal is "sp 35", magic power is "sp 67". - * "attacktype 1048576" makes an improvement potion. (I know, using attacktype for this is very ugly, bleah!!) If your potion is NOT supposed to be an improvement potion, leave attacktype zero. - - === type 6: food === - - Functionality of food: - By eating/drinking food-objects, the player can fill his stomach and gain a little health. - - * "food <number>": The player's stomach will get filled with <number> of foodpoints. The player's health will increase by <number>/50 hp. - - see also: [[flesh]] (72) - - === type 7: poison food === - - Functionality of poison food: - When eating, the player's stomach is drained by 1/4 of food. If his food drops to zero, the player might even die. - - === type 8: books === - - Functionality of books: - Applying a book, the containing message is displayed to the player. - - * "msg <text> endmsg": <text> is the text "written" in the book. - * "level <number>": If <number> is greater zero, the player needs a certain literacy level to succeed reading the book. The book can be read if: mental_level greater <number> - 5. Adding level to a book can be a nice idea, personally I like it when a player needs more than his fighting skills to solve a quest. However, keep the booklevel at least below 15 because it is quite hard to gain high mental levels. - - see also: [[spellbook]] (85), [[sign]] (98), [[scroll]] (111) - - === type 9: clock === - - Functionality of clocks: - Applying a clock, the time is displayed to the player - - === type 13: arrow/bolt === - - Functionality of arrows/bolts: - Arrows can be shot with bows, bolts with crossbows. They are usually weaker than melee but players can shoot from a safe distance. - - * "race <name>" should be set to either "race arrows" or "race crossbow bolts". If not, they won't work with bows/crossbows. - * "dam <number>" is the damage the projectile can inflict. - * "wc <number>": weapon-class bonus - * "attacktype <[[attack_num]]>": the bitmask <attack_num> determines the weapon's attacktypes. Read a more detailed description about attacktypes [[here]]. - * "food <number>" is the percentage chance of the projectile to break after hitting. "food 0" means it won't ever break, "food 100" means it will always break at first hit. - - === type 14: shooting weapon === - - Functionality of Shooting Weapons: - Bows can fire arrows, crossbows can fire bolts. You could also create your own pair of projectile & shooting weapon. When the "race"-attribute of both matches, it should work. - - * "race <name>" should be set to either "race arrows" or "race crossbow bolts". If not, they won't work with bows/crossbows. - * "sp <number>": After shooting a projectile, the player is frozen for a short period of time (to prevent shooting arrows machine-gun-like). The greater <number>, the shorter this period of time. "sp 1" means the player is frozen for a looong time. "sp 0" means the player is turned to stone forever. Nice, hum? =P - - see also: [[weapon]] (15) - - === type 15: weapon === - - Functionality of weapons: - Wielding a weapon, the object's stats will directly be inherited to the player. Usually enhancing his fighting-abilities. Non-magical weapons can be improved with scrolls. - - * "dam <number>" is the damage this weapon does per hit. <number> will add to the base damage of the player. - * "attacktype <[[attack_num]]>": the bitmask <attack_num> determines the weapon's attacktypes. Attacktypes are: physical, magical, fire, cold.. etc. Read a more detailed description about attacktypes [[here]]. Most artifact weapons have no more than one or two attacktypes. Keep in mind that all weapons can be blessed by the player's deity, thus adding an additional attacktype. When a player hits a monster with a weapon that has more than one attacktype, then he will do as much damage as the "best" of his attacktypes does. So, the more attacktypes you've got, the better your chance to take advantage of a monster's vulnerabilities. (Btw: Same rule applies for monster vs. player.). Attacktypes "magic" and "chaos" are somehow exceptions. - * "resist_<attacktype> <number>" adds resistance to the weapon. Resistance from <attacktype> by <number> percent. Treat this with CARE. Look at other maps and what they require to do for getting this-and-that artifact. - * "Str/Dex/Con/Int/Wis/Pow/Cha <number>": The wielder's stat(s) will rise/fall by value <number> for permanent. Again, don't mess around with this! Stats-bonus is very powerful. (Stat bonus does not mark a weapon being "magical") - * "slaying <race>": The weapon does triple damage to monsters of this <race> category. On the other hand, no god blessings are possible for such weapons. - * "last_sp <number>" determines the weapon-speed. The lower the faster, "last_sp 1" is best (that is lightning- fast). A typical average value is 8. Speed and damage should be kept in reasonable relation. - * "path_attuned/repelled/denied <[[spellpath]]>": This modifies the player's attunement to certain spellpaths. Attunes are more a matter of rings/amulets, while repels/denies are quite common. Remember that weapons are in general the barbarians' tools, not the wizards'. Read the details about spellpaths [[here]]. - * "wc <number>": weapon-class bonus - * "magical <number>" sets the weapon's magic bonus. It works just like wc, except that magic bonus can be improved by the gods or reduced by acid. Hence, it is less useful than direct wc on a weapon. - - General notes on artifacts (equipment) with stats- or resistance-bonus: - Keep playbalance in mind! Such items mustn't be reachable without hard fighting AND questing. - See "[[golden rules of map-making]]". - - === type 16: (brestplate) armour === - - Functionality of armour: - Wearing an armour, the object's stats will directly be inherited to the player. Usually enhancing his defense. - - * "resist_<attacktype> <number>" adds resistance to the armour. Resistance from <attacktype> by <number> percent. "physical protection" (= armour) is referred to as resist_physical. - * "Str/Dex/Con/Int/Wis/Pow/Cha <number>": The wielder's stat(s) will rise/fall by value <number> for permanent. - * "path_attuned/repelled/denied <[[spellpath]]>": This modifies the player's attunement to certain spellpaths. - * "last_heal <number>" poses a penalty to spell regeneration speed, for wearing the armour. The bigger <number>, the worse. - * "last_sp <number>" reduces the player's walking speed when wearing the armour. The bigger <number>, the worse. - * "sp <number>" speeds up the players mana-regen. rate by <number>. (negative values reduce mana-regen). - * "ac <number>": armour-class bonus - * "magical <number>" sets the armour's magic bonus. It works just like ac, except that magic bonus can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct ac on the armour. - * "xrays 1" enables xray-vision for the player, while wearing this armour. - - see also: [[shield]] (33), [[helmet]] (34), [[amulet]] (39), [[ring]] (70), [[cloak]] (87), [[boots]] (99), [[gloves]] (100), [[bracers]] (104), [[girdle]] (113) - - These all work more or less exactly like brestplate armour. - - === type 17: pedestal=== - - Functionality of pedestals: - Pedestals are designed to detect certain types of living objects. When a predefined type of living creature steps on the pedestal, the connected value is triggered. - - * "slaying <race_type>" specifies the object we're looking for. If <race_type> matches the monster's or the player's race, we have a match. Yes, pedestals can detect a player's race! E.g. you could create a place where only fireborns can enter, by setting "slaying unnatural". If "slaying player" is set, any player stepping on the pedestal is a match. Very useful if you want to open a gate for players but not for monsters. - * "connected <connector_value>" defines the connector value to be activated when the pedestal is triggered. - * "walk_on 1", "walk_off 1" should both be set or it won't work. - - Notes on usage: - If you want to create a place where only players of a certain race can enter, put a [[teleporter]] over your pedestal. So the [[teleporter]] is only activated for players of the matching race. Do not use gates, because many other players could sneak in. If you put powerful artifacts into such places, generally set "startequip 1", so that they are preserved for that one race and can't be traded to others. - - see also: [[detector]] (51), [[inv. checker]] (64), [[altar]] (18) - - === type 18: altar === - - Functionality of altars: - When a player puts a defined number of certain items on the altar, then either a spell is casted (on the player) or a connector is triggered. If the latter is the case, the altar works only once. Either way, the sacrificed item dissapears. - - * "slaying <item_name>" specifies the item that must be put on the altar to activate it. <item_name> can either be the name of an archetype, or directly the name of an object. Yet, titles are not recognized by altars. Remember to put a note somewhere, telling the player what he is expected to drop on the altar. (Often this is put in the altar's name: E.g. "drop 100 platinums") - * "food <value>" is the amount of items (specified as above) that must be dropped to activate the altar. If "slaying money" is set, then the value of the sacrificed money must be equal to <value> (ie, if food=200, then 200 silver, 20 gold, or 4 platinum will all work.) Note that the maximum possible for <value> is 32767. - * "walk_on 1" must be set or it won't work. - * "connected <activate_num>": If <activate_num> is set, the altar will trigger all objects connected to it, when activated. This will only work once. - * "sp <[[spell_number]]>": When activated, the spell of number <spellnum> will be casted (once, on the player). This should work for any given spell. Look for spellnumbers [[here]]. The altar will work infinitely in this way. Don't set both "sp > 0" and "connected > 0" for one altar. - - see also: [[altar_trigger]] (31), [[holy altar]] (56) - - === type 20: locked door === - - Functionality of locked doors: - A locked door can be opened only when carrying the appropriate [[special key]]. - - * "slaying <unique_string>" must be identical with the slaying in the special key, then door is unlocked. It is VERY important to set <unique_string> to something that is unique among the CF mapset. DONT EVER USE the default string "set_individual_value". - * "msg <text> endmsg": When a player is trying to open the door without carrying the appropriate key, <text> is displayed to the player. This is a good opportunity to place hints about the special key needed to unlock the door. - * "no_magic 1", "damned 1" should always be set to prevent players passing through the door by dimension door spell. - - Notes on usage: - If you want to create a locked door that cannot be opened (no key), set a slaying like "no_key_available". This will clarify things and only a fool would create a key matching that slaying. Door-objects can not only be used for "doors". In many maps these are used with all kinds of faces/names, especially often as "magic force". A good example is the map "Lake_Country/ebony/masterlev". There you have magic forces (door objects) put under certain artifact items. To get your hands on the artifacts, you need to bring up the appropriate quest items (key objects). - - see also: [[special key]] (21) - - === type 21: special key === - - Functionality of special keys: - When carrying the appropriate special key, a locked door can be opened. The key will disappear. - This object-type can also be used for "passport"-like items: When walking onto an [[inventory checker]], a gate for example might get opened. The "passport" will stay in the player's inventory. - - * "slaying <unique_string>" must be identical with the slaying in the locked door, then it can be unlocked. It can also be used to trigger [[inventory checkers]]. - * "material 0" (no material) or "material 256" (adamantite) should be set. This prevents the key from getting burned or otherwise destroyed. - * "msg <text> endmsg": This will add a description to the object. The player can read <text> by clicking on the item in his inventory. Use this message to describe what the key/passport is good for. A player might have 50 different keys on his key-ring. Don't expect players to recall their purpose just by their names. - - Notes on usage: - How to make a "passport": You take the special key arch (archetype name is "key2"), set the face to something like card.111 and the name to "passport" - that's all. The slaying certainly must match with the appropriate [[inventory checker]]. - - Of course you can be creative with names and faces of key-objects. A "mysterious crystal" or a "big dragon claw" (with appropriate faces) appear more interesting than just a "strange key", or "passport". - - see also: [[locked door]] (20), [[inventory checker]] (64) - - === type 29: magic ear === - - Functionality of magic_ears: - Magic_ears trigger a connected value when the player speaks a specific keyword. - - * "msg <text> endmsg" contains the keyword-matching-syntax. <text> should have the following format: "@match <keyword1>|<keyword2>|... ". Any number of keywords from one to infinite is allowed. Make sure they are seperated by a '|'. Examples: "@match yes", "@match gold|treasure". The connected value will be triggered when the player speaks any of the given keywords. IMPORTANT: Upper/lower case does not make a difference! - * "invisible 1" should always be set for magic_ears. They cannot be discovered by the show invisible spell, so it doesn't matter if you put them above or below the floor. - - Notes on usage: - Whenever you put magic_ears on your maps, make sure there are CLEAR and RELIABLE hints about the keywords somewhere. Don't make something - like a gate that is opened by speaking "open" or "sesame", expecting the player to figure this out all by himself. - - Magic_ears are typically used for interaction with NPCs. You can create the impression that the NPC actually *does* something according to his conversation with a player. Mostly this means opening a gate or handing out some item, but you could be quite creative here. - - === type 31: altar_trigger === - - Functionality of altar_triggers: - Altar_triggers work pretty much like [[normal altars]] (drop sacrifice -> connection activated), except for the fact that they reset after usage. Hence, altar_triggers can be used infinitely. - - * "slaying <item_name>" specifies the item that must be put on the altar to activate it. <item_name> can either be the name of an archetype, or directly the name of an object. Yet, titles are not recognized by altars. Remember to put a note somewhere, telling the player what he is expected to drop on the altar. (Often this is put in the altar's name: E.g. "drop 100 platinums") - * "food <value>" is the amount of items (specified as above) that must be dropped to activate the altar. - If "slaying money" is set, then the value of the sacrificed money must be equal to <value> (ie, if food=200, then 200 silver, 20 gold, or 4 platinum will all work.) Note that the maximum possible for <value> is 32767. - * "walk_on 1" must be set or it won't work. - * "connected <activate_num>": If <activate_num> is set, the altar will trigger all objects connected to it, when activated. (With "last_sp 0", it triggers again when the altar is reset.) - * "last_sp 1": If set, the altar_trigger won't push the connected value by altar reset. Only ONCE by dropping the sacrifice. This is typically used when the altar is connected to a [[creator]], e.g. for selling tickets. If "last_sp 0" is set (default), the altar_trigger will push the connected value TWICE per sacrifice: First by dropping sacrifice, second by reset. This mode is typically used for altars being connected to gates, resulting in the gate being opened and closed again. - - Hints on usage: - Altar_triggers are very useful if you want to charge a price for... - - * ...an item. -> Connect the altar_trigger (set "last_sp 1") to a [[creator]]. See also: [[converters]]. - * ...opening a gate. -> Connect the altar_trigger (set "last_sp 0") to the gate. - * ...information. -> Connect the altar_trigger (set "last_sp 1") to a [[magic_mouth]]. - - The big advantage over [[normal altars]] is the infinite usability of altar_triggers! If there are ten players on one server, they're quite grateful if things work more than once. =) - - see also: [[altar]] (18) - - === type 40: mover === - - Functionality of movers: - Movers move the objects above them. However, only living objects are affected (monsters/NPCs always, players optional). Movers have a direction, so players can be made to move in a pattern, and so can monsters. Motion is involuntary. Additionally, players or monsters can be "frozen" while ontop of movers so that they MUST move along a chain of them. - - Multisquare monsters can be moved as well, given enough space. Movers are usually invisible. - - * "attacktype 1": If attacktype is nonzero, the mover "freezes" anyone it moves (so they are forced to move along a chain). However, this has nothing to do with the common in-game attacktypes. Default is "attacktype 1". - * "maxsp <number>": The player will be "frozen" for <number> moves. If unset, and "attacktype 1", maxsp becomes 2. Otherwise it is zero by default. - * "walk_on 1" must be set or it won't work properly. - * "fly_on 1" means all flying (living) objects will get moved as well. A mover with "fly_on 0" will move only walking (non-flying) creatures. - * "speed <speed_value>" determines how fast a chain of these movers will push a player along (default -0.2). - * "sp <number>" specifies the mover's direction. 1=up, 3=right, 5=down, 7=left. A mover with "sp 8" will spin clockwise. - * "level 1": If this is set, both players and monsters will be moved. The arches' default is "level 0", ONLY monsters get moved. Remember that "monsters" includes NPCs! This feature provides you with the possibility to make NPCs literally "come to life". Example: The player is talking with an NPC, speaking a certain keyword. This triggers a magic_ear and activates creators, creating (per default: monster-only) movers under the NPC's feet. The NPC starts "walking" on a predefined route! Note that it's useful to set this NPC immune to everything, preventing the player to push the NPC off his trace. - * "lifesave 1" means the mover can be "used up" after a certain number of moves (-> hp). A mover of "lifesave 0" works infinitely. (I know this is opposite to the common sense of "lifesave", but we gotta accept it) - * "hp <value>" has only a meaning if lifesave is set: <value> is the number of times minus one, that it will move a player before disappearing. (It will move someone <value>+1 times, then vanish). - - Notes on usage: - NEVER EVER consider a mover to be impassable in the backwards direction. Setting "attacktype 1" makes it seemingly impossible but there is still a trick: One player can push a second player past the mover, in opposite to the mover's direction! The more movers, the more players needed. Hence, don't make a treasure room that is surrounded by movers instead of solid walls/gates. It should be noted though that this behavior can be used for intentionally multi-player maps, and there is one such example in pupland, however it should be noted that forcing players to use that to get through would usually be considered a bit too counterintuitive unless it is hinted to. - - Btw, it does not make a difference putting movers above or below the floor. Moreover, movers that are "invisible 1" cannot be discovered with the show_invisible spell. - - Note on directors: - Movers and Directors are separate objects, even though they look and act similar. Directors only do spells/missiles, while movers only do living creatures (depending on how it is set: monsters and players). - - see also: [[director]] (112) - - === type 41: teleporter === - - Functionality of teleporters: - When the player walks into a teleporter, he is transferred to a different location. The main difference to the object-type [[exit]] is the possibility to have teleporters connected to levers/buttons/etc. Sometimes teleporters are activated even against the players will. - - Unlike [[exits]], teleporters can transfer also items and monsters to different locations on the same map. - - * "slaying <map_path>" defines the map that the player is transferred to. <map_path> can be an absolute path, beginning with '/' (for example "/peterm/FireTemple/fire1"). It can also be a relative path, not beginning with '/' (On the map "/peterm/FireTemple/Fire2" for example I could use the relative path "Fire1"). Use relative paths whenever possible! Note that upper/lower case must always be set correctly. However, please use lower case only. If the slaying is set, ONLY players can get teleported. If slaying is unset ("slaying 0"), anything can get teleported: Players, monsters and items. In this case, the destined map is automatically the same map the teleporter is on. - * "hp <number>", "sp <number>": hp, sp define the (x, y)- coordinates of the exit's destination. If both are set to zero and "slaying 0" is set, the player will get teleported to another, randomly chosen teleporter on the same map (Slightly confusing for the player though). Make sure there actually *is* a second one in that case. If both (sp,hp) are zero but slaying is set, the player will be transferred to the "default enter location" of the destined map. The latter can be set in the map's attributes as "hp"/"sp", with crossedit there are input masks labeled "Start X"/"Start Y". Though, please DO NOT use that. I wrote it here only so that you understand some existing maps. It turned out to be a source for numerous map-bugs. - * "speed <speed_value>": If speed is nonzero, the teleporter will automatically be activated in regular time-intervals. Hence, the player can just step on it and gets teleported sooner or later. The duration between two activates depends on <speed_value>. Default in the teleporter arch is "speed 0.1". VERY IMPORTANT: If you want to have your teleporter activated via button/handle/magic_ear/etc, you must set "speed 0"! - * "connected <connector_value>": If set, the teleporter will be activated when the connection is triggered. As stated above, to use this, speed must be zero. - - Notes on usage: - Teleporters must always be placed above the floor in order to work correctly! - - When creating maps, I guess sooner or later you'll want to have an invisible teleporter. If using "invisible 1", the teleporter can still be discovered with the show_invisible spell. And you can't place it under the floor to prevent this. Fortunately, there is a cool trick to make a perfectly invisible teleporter: You simply add teleporter functionality to the floor itself. That means: You take the floor arch (e.g. "flagstone"), set "type 41", and add slaying/hp/sp/connected... everything you need. - - see also: [[exit]] (66) - - === type 42: creator === - - Functionality of creators: - A creator is an object which creates another object when it is triggered. The child object can be anything. Creators are VERY useful for all kinds of map-mechanisms. - - * "other_arch <arch_name>" defines the object that will be created. You can choose any of the existing arches. - * "connected <connector_value>": If <connector_value> is activated, the creator is triggered. - * "hp <number>": The creator can be triggered <number> times, thus creating <number> objects, before it disappears. Default is "hp 1" (-> one-time usage). - * "lifesave 1" means the creator will work infinitely, regardless of hp. - * "slaying <name>": The created object will bear the name <name>. If no slaying is set, the standard name of the archetype is used. - * "level <number>: The created object will be of level <number>. Again, if not set, the standard level of the archetype is used. - - Notes on usage: - Don't hesitate to hide your creators under the floor. The created items will still always appear ontop of the floor. - - see also: [[rune]] (154) - - === type 51: detectors === - - Functionality of detectors: - Detectors work quite much like [[inv. checkers]]/[[pedestals]]: If the detector finds a specific object, it toggles its connected value. - - What is "unique" about them, compared to [[inv. checkers]]/ [[pedestals]]? - First, detectors check their square for a match periodically, not instantly. Second, detectors check directly for object names. Third, detectors do not check the inventory of players/monsters. - - * "slaying <name>" specifies the name of the object we are looking for. Actually it does also check for slayings in key-objects, but for this case inv. checkers are often more powerful to use. - * "speed <speed_value>" sets the time between two detector-checks. If you want the detector to behave almost like pedestals/buttons, set speed rather high, like "speed 1.0". - - Notes on usage: - There is one major specialty about detectors: You can detect spells blown over a detector! To detect a lightning bolt for example, set "slaying lightning" and "speed 1.0". In combination with [[spellcasting walls]], this can be very useful for map-mechanisms. - - see also: [[pedestal]] (17), [[inv. checker]] (64), [[altar]] (18) - - === type 55: marker === - - Functionality of markers: - A marker is an object that inserts an invisible force (a mark) into a player stepping on it. This force does nothing except contain a string in its slaying field which can be discovered by detectors or [[inv. checkers]]. It is also possible to use markers for removing marks again. - Note that the player has no possibility to "see" his own marks, except by the effect that they cause on the maps. - - * "slaying <unique_string>" is the "lockcode" that can be detected by inv. checkers/detectors. If the player already has a force with that slaying, there won't be inserted a second one. - * "speed <speed_value>" defines how quickly it will mark something standing on the marker. Set <speed_value> rather high to make sure the player really gets his mark. I think "speed 1.0" should do fine. - * "food <number>" sets the duration of the force it inserts. If nonzero, the duration of the player's mark is finite: about 1 food per 10 seconds. "food 0" means the mark will stay on the player forever. - * "name <unique_string>": When the player steps onto the marker, all existing forces in the players inv. with slaying <unique_string> will be removed. If you don't want to remove any marks, simply name your object "marker". I know, involving an object's name in it's functionalities is rather uncommon and irritating... but hey, we gotta deal with it. =) - * "msg <text> endmsg": In the moment when the player gets marked, the message <text> is displayed to him. You should usually set a message in any marker you create, because it's the only way for the player to notice what's going on. - - Notes on usage: - Markers hold real cool possibilities for map-making. I encourage you to use them frequently. However there is one negative point about markers: Players don't "see" what's going on with them. It is your task, as map-creator, to make sure the player is always well informed and never confused. - - Please avoid infinite markers when they aren't needed. They're using a little space in the player file after all, so if there is no real purpose, set an expire time. - - see also: [[inventory checker]] (64) - - === type 56: holy altar === - - Functionality of holy_altars: - Holy_altars are altars for the various religions. Praying at a holy_altar will make you a follower of that god, and if you already follow that god, you may get some extra bonus. (See: [[god intervention]]) - - * "other_arch <god_name>" specifies the god that the altar belongs to. Possible options for <god_name> are: Devourers, Lythander, Mostrai, Gaea, Ruggilli, Gnarg, Gorokh, Valriel and Sorig. If you want to have an unconsecrated altar, set "other_arch 0" and "level 0". - * "level <number>": To re-consecrate an altar, the players skill level (wisdom level) must be as high or higher than the level field. In this way, some altars can not be re-consecrated, while other altars, like those in dungeons, could be. - Altars located in temples should have at least "level 100". Some characters might need those altars, they would be very unhappy to see them re-consecrated to another cult. - - see also: [[altar]] (18) - - === type 62: magic wall === - - Functionality of magic walls: - Magic walls fire spells in a given direction, in regular intervals. Magic walls can contain any spell. However, some spells do not operate very successfully in them. The only way to know is to test the spell you want to use with a wall. - - Several types of magical walls are predefined for you in the archetypes, and can be found on a pick-map available in crossedit. - - * "dam <[[spellnumber]]>" specifies the spell the wall will cast. You can find a list of spellnumbers [[here]]. - * "level <number>": The wall will cast it's spells at level <number>. "level 1" walls cast spells at minimal strength. "level 100" walls cast deadly spells. Arch default is level 1 - you should rise it to meet the overall difficulty of your map. - * "sp <number>" holds the direction in which the wall will cast the spell. 1=north, 2=northeast, 3=east,... , 8=northwest. A magic wall with "sp 0" will always fire in a random direction. - * "speed <speed_value>" defines the spellcasting speed of the wall. You can fine-tune how long the duration between two casts shall be. If you want to create a wall that can be activated (cast per trigger) via connected lever/button/etc, you must set "speed 0". - * "connected <connector_value>" means the wall will cast a spell when it is triggered via <connector_value>. Set "speed 0" or it won't have much visible effect. - * "no_pass 1", "blocksview 1" should be set for "normal" wall-behavior: blocking view and non-passable. Yet, this is not a rule written in stone. You could make invisible, passable magic walls... the spells will then seemingly appear out of nowhere. - * "alive 1" means the wall can be attacked and destroyed. If set, you must also set the common monster-attributes: hp, maxhp, resistances. See description of [[monsters]]. - - Notes on usage: - Spellcasting walls pose an interesting alternative to monsters. Usually they are set to be undestroyable ("alive 0"). Thus, while monsters in a map can be cleared out, the magic walls remain. Low level characters for example will not be able to pass through their spell-area, hence they cannot loot a map that a high level character might have cleared out. - - Another point of magic walls is that if the player dies, he has to face them all again. Magic walls can add a kind of "permanent thrill" to your maps. - - Be careful that your magic walls don't kill the monsters on a map. If placing monsters, eventually take ones that are immune to the walls' spell(s). - - It is possible to make walls rotate when triggered. But that is so confusing (and useless IMHO) that I did not mention it above. You can find a working example on the map "/pup_land/castle_eureca/castle_eureca8". - - === type 64: inventory checker === - - Functionality of inventory checkers: - Inventory checkers passively check the players inventory for a specific object. You can set a connected value that is triggered either if that object is present or missing (-> "last_sp") when a player walks over the inv. checker. A valid option is to remove the matching object (usually not recommended, see "last_heal"). - - Alternatively, you can set your inv. checker to block all players that do/don't carry the matching object (-> "no_pass"). - As you can see, inv. checkers are quite powerful, holding a great variety of possibilities. - - * "slaying <name>" specifies the object we are looking for: We have a match if the player does/don't carry a [[key object]] or a mark (-> see [[marker]]) with identical slaying <name>. Note that [[key objects]] usually appear as "passports" in this context. A typical example is the city gate mechanism of scorn. - * "race <archetype_name>" specifies the object we are looking for: We have a match if the player does/don't carry an object of archetype <archetype_name>. - * "hp <type_value>" specifies the object we are looking for: We have a match if the player does/don't carry an object that is of type <type_value>. Example: Set "hp 15" ([[type 15 => weapon]]) and "no_pass 1". Now you have an inv. checker blocking all players that carry any kind of melee weapon. To pass, a player is forced to leave behind all his weaponry... bad news for a warrior. Nice, hum? :) - * "last_heal 1": Remove object if found. This is usually not recommended because inv. checkers are in general invisible. So, unlike for altars/ locked doors, the player won't expect to lose an object when walking over that square. And he doesn't even get a message either. - So, *if* you set last_heal, make sure to inform the player what's going on! - * "no_pass 1": If set, only players meeting the match criteria can pass through that space. If "no_pass 0" (default), then the inv. checker acts like a trigger/button. - * "last_sp 1" means having that object is a match. "last_sp 0" means not having that object is a match. - * "connected <connector_value>" specifies the connector value to be activated if the inv. checker is triggered. This only makes sense along with "no_pass 0". - - General usage notes: - Putting a check_inventory space in front of a gate (one below) and one on the opposite side works reasonably well as a control mechanism. Unlike the [[key]]/[[door-combo]], this one works infinite since it is independent from map reset. Use it to put a "structure" into your maps: Player must solve area A to gain access to area B. This concept can be found in nearly every RPG - simple but effective. - - see also: [[special key]] (21), [[marker]] (55), [[pedestal]] (17), [[detector]] (51) - - === type 65: mood floor === - - Functionality of mood floors: - As the name implies, mood floors can change the "mood" of a monsters/NPC. For example, an unaggressive monster could be turned mad to start attacking. Similar, an aggressive monster could be calmed. - - * "last_sp <number>" is used to determine what will happen to the monster when affected by the mood floor: - * "last_sp 0": 'furious' Makes all monsters aggressive - * "last_sp 1": 'angry' As above but pets are unaffected - * "last_sp 2": 'calm' Makes all monsters unaggressive - * "last_sp 3": 'sleep' Puts all monsters to sleep - * "last_sp 4": 'charm' Makes monster into a pet of person who triggers the square. This setting is not enabled for continuous operation, you need to insert a connected value! - * "connected <connector_value>": This should only be set in combination with "last_sp 4". Normally, monsters are affected by the mood floor as soon as they step on it. But charming (monster -> pet) is too powerful, so it needs to be activated. Typically it is connected to an altar, for buying a "hireling". But a powerful pet could as well be the reward for solving a quest. Or even better: It could be *part* of a quest! - - Notes on usage: - Notes on usage: Mood floors are absolutely cool for NPC interaction. To make an unaggressive monster/NPC attack, put a [[creator]] with - "other_arch furious_floor" under it. Connect the creator to a [[magic_ear]], so the player speaks a keyword like "stupid sucker" - and the monster attacks. - - To turn an NPC into a pet, put a charm_floor under it and connect it directly to a [[magic_ear]]. Then the player speaks a keyword like "help me" - and the NPC joins him as pet. - - (Of course you must always give clear hints about keywords! And there is no reason why you couldn't use a button/lever/[[pedestal]] etc. instead of a [[magic_ear]].) - - === type 66: exit === - - Functionality of exits: - When the player applies an exit, he is transferred to a different location. (Monsters cannot use exits.) Depending on how it is set, the player applies the exit just by walking into it, or by pressing <a>pply when standing on the exit. - - * "slaying <map_path>" defines the map that the player is transferred to. <map_path> can be an absolute path, beginning with '/' (for example "/peterm/FireTemple/fire1"). It can also be a relative path, not beginning with '/' (On the map "/peterm/FireTemple/Fire2" for example I could use the relative path "Fire1"). Use relative paths whenever possible! Note that upper/lower case must always be set correctly. However, please use lower case only. It is well possible to have an exit pointing to the same map that the exit is on. If slaying is not set in an exit, the player will see a message like "the exit is closed". - * "hp <number>", "sp <number>": hp, sp define the (x, y)- coordinates of the exit's destination. If both are set to zero, the player will be transferred to the "default enter location" of the destined map. The latter can be set in the map's attributes as "hp"/"sp", with crossedit there are input masks labeled "Start X"/"Start Y". Though, please DO NOT use that. I wrote it here only so that you understand some existing maps. It turned out to be a source for numerous map-bugs. - * "walk_on 1": If set, the player will apply the exit by just walking into it. This must be set for the invisible exits for example. If "walk_on 0", the player has to step onto the exit and press <a> to get transferred. - * "fly_on 1": If set, the player will apply the exit by "flying into it". Flying means the player is levitating. E.g. he might wear the levitation boots. - * "msg <text> endmsg": If set, <text> will be displayed to the player when he applies the exit. This is quite useful to throw in some "role-play feeling": "As you enter the dark cave you hear the sound of rustling dragonscales...". Well, my english is poor, but you got the point. =) - * "unique 1" defines the destined map as "personal unique map". That means there will be a separate version of that map for every player out there. This feature is used for the permanent apartments (in Scorn/Nuernberg/Caterham...). It should not be used for anything else than apartments, since Crossfire is a *multi*player game. In such a permanent apartment don't forget to set "unique 1" for all floor tiles too (see [[floors]]). An exit pointing outside of a "personal unique map" must be "unique 0". - - Notes on usage: - If you want to have an invisible exit, set "invisible 1" (, of course "walk_on 1"), and put it *under* the floor. Otherwise it could be detected with the show_invisible spell. - - You can be quite creative with the outlook of secret exits (their "face"). Don't forget to give the player relyable hints about them though. - - see also: [[teleporter]] (41) - - === type 85: spellbook === - - Functionality of spellbooks: - By reading a spellbook, the player has a chance of learning the contained spell. Once learned from a book, the spell is available forever. Spellbooks with high level spells require some skill-level to read. - - * "sp <[[spellnum]]>" defines the contained spell. You can look up the spellnumbers [[here]]. You could alternatively use the slaying. - * "slaying <[[spell_name]]>" also defines the contained spell, just like sp, but here you write the spell's name instead of it's number. Saves you the hassle to look it up, and makes your stuff more readable to others. - * "msg <text> endmsg" could contain a nice description of the spellbook's cover or something. - - Notes on usage: - Don't put any of the godgiven spells into a spellbook! These are reserved for the followers of the appropriate cults. Handing them out in a spellbook would violate the balance between different religions. - - If you want to have a random spellbook, you must use the arch "random_spells" ([[type 4]]) instead. - - see also: [[book]] (8) - - === type 98: sign/ magic mouth === - - Functionality of signs/ magic_mouths: - The purpose of a sign or magic_mouth is to display a certain message to the player. There are three ways to have the player get this message: The player walking onto it (-> magic_mouth), the player pressing <a>pply (-> sign) or the player triggering a button/handle/etc (-> magic_mouth). - - * "msg <text> endmsg" contains the <text> that will be displayed to the player. - * "invisible 1" should always be set if you want to have the object work as magic_mouth. Put magic_mouths *under* the floor, to prevent them being affected by the show_invisible spell. If you want to have a sign, set "invisible 0". That way the player can see the object, thus apply it, and get the message. - * "walk_on 1": If set, the player gets the message when walking ontop of the object. "invisible 1" should be set in this case. This is the typical configuration for a "magic_mouth": The player walks through a dungeon and suddenly he gets a message. Use this to create some roleplay atmosphere, and to inform the player about possible dangers or secrets. - * "fly_on 1": If set, the player gets the message when flying (=levitating) ontop of the object. Usually this should be set together with walk_on. - * "connected <connector_number>" means the message will be printed when the object is triggered via <connector_value>. This should be used in combination with "invisible 1" and "walk/fly_on 0". If activating your magic_mouth this way, the message will not only be printed to one player, but all players on the current map! - * "food <number>": If "food" is set, the sign/magic_mouth can be applied (printing the message) only <number> times. For signs this really shouldn't be used, while for magic_mouths it is extremely helpful. Often, you might want to have a message displayed only one time. For example: The player enters your map and you put a magic_mouth to tell him about the monsters and how dangerous they look and all. Later, when all the monsters are killed and the player leaves the map, displaying the same message a second time would be silly. "food 1" does a perfect job in such cases. Otherwise set "food 0" for infinite use (that is the default). - - Notes on usage: - Use signs and magic_mouths, plenty of them! Place magic_mouths to add some true roleplay feeling to your maps, support your storyline or give hints about hidden secrets/dangers. Place signs to provide the player with all kinds of useful information for getting along in your maps. - - see also: [[book]] (8) - - === type 103: converter === - - Functionality of converters: - Converters are like "exchange tables". When the player drops a specific type of items, they get converted into other items, at a predefined exchange-ratio. - - * "slaying <give_item>": <give_item> is the name of the archetype to convert from. - * "other_arch <get_item>": <get_item> is the name of the archetype to convert into. - * "sp <sp_value>", "food <food_value>" defines the exchange-ratio: For <food_value> pieces of <give_item> the player will get <sp_value> pieces of <get_item>. - * "walk_on 1" and "no_pick 1" must always be set for converters. - - Notes on usage: - Converters are better than shopping with doormats, because the converters never get sold out. For some items like food or jewels those "exchange tables" are really nice, while for the more important stuff like potions converters should not exist. - - VERY IMPORTANT: Be careful with the exchange-ratio! When you drop items on a converter, the stuff you get must be of equal or lesser value than before! (Except if you are using "rare" items like dragonscales for payment). The code will not check if your ratio is sane, so the player could gain infinite wealth by using your converter. - - See also: [[creator]] (42) - - === type 106: savebed === - - Functionality of savebeds: - When the player applies a savebed, he is not only saved. Both his respawn-after-death and his word-of-recall positions are pointing to the last-applied savebed. - - * "no_pick 1" makes sure the savebed is non-pickable. DO NOT CHANGE THIS! - * "no_magic 1", "damned 1" marks the savebed as no-spell-area. Again, DO NOT CHANGE THIS. Sometimes players die in auto fire mode... - - Notes on usage: - Put savebed locations in towns, do not put them into dungeons. It is absolutely neccessary that a place with savebeds is 100% secure. That means: - - * Monsters must not be able to reach the savebeds under any circumstances! - * If there are NPCs around, make sure they have "friendly 1" set. - * Insert a relyable exit! Make sure there is no possibility that players get trapped in a savebed location. - * If possible, mark the whole site as no-spell area (Insert this arch called "dungeon_magic" everywhere). This is not required, but it makes the place much more safe. - - === type 109: wand/staff=== - - Functionality of wands/staves: - Wands contain a certain spell. The player can apply (ready) and fire the wand. After a defined number of casts, the wand is "used up". It is possible to recharge a wand with scrolls of charging, but usually that isn't worth the cost. - - * "sp <[[spellnum]]>" specifies the contained spell. You can look up the spellnumbers [[here]]. - * "level <number>": The wand/staff will cast at level <number>. An average level for wands in shops is about 10. - * "food <number>" is the number of charges left before it is used up. - - Notes on usage: - Wands are quite seldomly used. The reason prolly is that they're generally not cost-efficient. Handing out high-level wands with powerfull special spells isn't a good idea either, because of the recharge ability. - - For low levels, staffs of healing/cure and word of recall are quite desireable though. - - see also: [[rod]] (3), [[potion]] (5), [[scroll]] (111) - - === type 122: container === - - Functionality of conatiners: - A player can put (certain kinds of) items in the container. The overall weight of items is reduced when put inside a container, depending on the settings. - - A special feature of containers is the "cauldron", capable of mixing alchemical receipes. - - * "container <value>": The container can hold a maximum total weight of <value> gram. Note that this weight limit is calculated *after* the weight reduction (-> Str) has been applied. - * "Str <value>" determines how much the weight of items is reduced in percent, when put inside the container. "Str 0" means no reduction, "Str 100" means items are weightless inside. Most default values are in the range of ten. - * "race <container_type>": If set, the container will hold only certain types of objects. Possible choices for <container_type> are: "gold and jewels", "arrows" and "keys". Unfortunately it is not easy to create new container types, because they are hardcoded. - * "is_cauldron 1": If set, the container can be used as alchemy-cauldron. The player can put ingredients inside, close it, cast alchemy and if his formulae is true, he'll get what he longed for. - * "other_arch <arch_name>" is used for a certain kind of... "animation" when opening the container. Stick to the default arches here and you won't get into trouble. - * "no_pick 1" should be set for all containers that you're using as map-decoration/furniture, like bookshelves, (permanent) chests or deposit boxes. For the ones you want the player to have, set "no_pick 0". - - Note on chests: - There are two types of chests: - First the random treasure chests - Those are NOT containers (but object type 4), they create random treasures when applied. Archetype name is "chest". Second there are the permanent chests - Those are containers, they can be opened and closed again. Archetype name is "chest_2". - - === type 154: rune/trap == - - Functionality of runes/ traps: - A rune is a magical enscription on the dungeon floor. Traps are just like runes except they are not magical in nature, and generally have a physical attack. - - Runes hit any monster or person who steps on them for 'dam' damage in 'attacktype' attacktype. Alternatively, the rune could contain any spell, and will cast this spell when it detonates. Yet another kind is the "summoning rune", summoning predefined monsters of any kind, at detonation. - - Many traps and runes are already defined in the archetypes. - - * "level <number>": Level the rune will cast the spell it contains at, if applicable. A level 99 rune casts a very, very mean spell of whatever. ("level 0" runes won't detonate at all!) Level Also effects how easily a trap may be found and disarmed, and how much experience the player gets for doing so. Beware: High level runes can be quite a cheap source of experience! So either make them tough, or keep the level low. - * "Cha <value>" determines what fraction of the time the rune is visible: It'll be randomly visible 1/Cha of the time. Also effects how easily the trap may be found. - * "sp <[[spellnum]]>" defines the spell in the rune, if any. (Many runes and all traps do direct damage). - * "slaying <[[spell_name]]>": Name of the spell in the rune, if any. Slaying is optional, but if present, overrides sp. Recommended for use by mapmakers to ensure portability. - * "hp <number>": The rune will detonate <number> times before disappearing. - * "attacktype <[[attack_num]]>": If there isn't any spell (and race is unset), this attribute defines what attacktype to use for direct damage when the rune detonates. - * "msg <text> endmsg": When the rune detonates, <text> is displayed to the victim. For especially powerful runes, create an appropriate thrilling description. ;) - * "dam <value>" specifies how much damage is done by the rune, if it doesn't contain a spell. This should be set in reasonable relation to the rune's level. - * "maxsp <rotation_num>" sets the direction to cast the spell the rune contains, if any. 1=north, 2=northeast, 3=east, ..., 8=northwest. In most cases this appears useless since the spell directly hits the player. - * "race <monster_arch_name>": If this is set to the arch name of any monster, together with "slaying summon evil monster", the rune will summon a bunch of those on detonation. (dam and attacktype will still be ignored in this case). In theory, runes are even capable of summoning multi-square monsters, given enough space. You'd better test it though. - * "maxhp <number>" should only be set to a summoning rune. It will then summon <number> creatures of <monster_arch_name>. - - Notes on usage: - Avoid monsters stepping on your runes. For example, summoning runes together with spellcasting- and attack-runes is usually a bad idea. One can use this feature intentionally though to create chain-reactions of summoning runes and such things, however one should be careful about doing this. IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/map-making_guide?rev=1199653326 New Revision: http://wiki.metalforge.net/doku.php/map-making_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 6 16:19:38 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 06 Jan 2008 16:19:38 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:object_types Message-ID: <1199657978.353342.19445.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/06 16:19 User : kbulgrien Edit Summary: Change structure of type 94: hole. @@ -472,8 +472,9 @@ If you want to have a random spellbook, you must use the arch "random_spells" ([[type 4]]) instead. see also: [[book]] (8) + ==== type 94: hole ==== Holes send objects that fall through them to a new location on the current map. @@ -482,9 +483,12 @@ * Become "full" (Can stop working) if destination is blocked. * May be opened and closed via connection. * Monsters, spells, etc. can fall through. * Can trigger on all movement types. - * Example: [[http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/connect/Hole/pit.arc|connect/Hole/pit.arc]] + + **Examples** + + * [[http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/connect/Hole/pit.arc|connect/Hole/pit.arc|pit.arc]] **Special Object Attributes** ^ CrossfireEditor ^ arch ^ map ^ Description ^ IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/dev:object_types?rev=1199656005 New Revision: http://wiki.metalforge.net/doku.php/dev:object_types -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 10 18:32:09 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 10 Jan 2008 18:32:09 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:object_fields Message-ID: <1200011529.902950.7804.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/10 18:32 User : kbulgrien Edit Summary: Add content for move_block. @@ -564,13 +564,16 @@ ==== move_type ==== Type: MoveType Meaning: + ==== move_block ==== Type: MoveType - Meaning: + Meaning: Prevents a character or monster from moving onto a tile occupied by the object. + + * Each part of a multi-tile object may have a unique setting, unlike many other modifiers that are omitted or ignored in non-head parts. ==== move_allow ==== Type: MoveType IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/dev:object_fields?rev=1198909652 New Revision: http://wiki.metalforge.net/doku.php/dev:object_fields -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 10 19:14:06 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 10 Jan 2008 19:14:06 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:object_types Message-ID: <1200014046.475586.7992.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/10 19:14 User : kbulgrien Edit Summary: Add notes on blocksview. @@ -604,14 +604,15 @@ * "maxhp <number>" should only be set to a summoning rune. It will then summon <number> creatures of <monster_arch_name>. Notes on usage: Avoid monsters stepping on your runes. For example, summoning runes together with spellcasting- and attack-runes is usually a bad idea. One can use this feature intentionally though to create chain-reactions of summoning runes and such things, however one should be careful about doing this. + ===== Common Object Attributes ===== The following attributes are used for many different object-types: (These are only mentioned here, not in the detailed list of object-types later. Apply them to all objects where they make any "sense".) - ^ CrossfireEditor ^ Map field ^ Description ^ + ^ CrossfireEditor ^ arch/map field ^ Description ^ | name | name <name> | The name of the object displayed to players. | | title | title <title> | An object's title. Once the object is identified the title is attached to the name. Typical titles are "of mostrai", "of xray vision" etc. | | image | face <name_of_face> | The image name defines what picture is displayed for the object. Look through the arches to get an idea of existing faces. | | | nrof <number | The number of objects in one stack (for example: 100 goldcoins => "nrof 100"). You should set at least "nrof 1" for any pickable object, otherwise it won't be mergeable! | @@ -622,9 +623,9 @@ | invisible | invisible 1 | Makes the object invisible. Depending on the object-type, some can be made visible by the show_invisible spell. If in doubt, test it. Putting an invisible object under the floor always prevents it from being shown, but, in some cases, might cause malfunction to the object. You may find more detailed info about this matter in the description of the affected object types. | | glow\ radius | | If glow radius is set to a value greater than zero, the object appears lit up on dark maps. It can be a value between 0 and 4 with higher values emitting greater amounts of light. | | smooth level | | If smooth level is set to a value greater than zero, the object will be drawn partially over adjacent squares having a lower smooth level. The value must be between 0 and 255 (inclusive) where 0 means "never overlap adjacent squares". | | elevation | | The elevation, or height above sea level) of this tile. It is used for weather calculations and should be in the range -32000 to 32000. The elevation of a tile must be set in the bottom-most game object; elevation values for non-bottom-most game objects are ignored by the Crossfire server. | - | block view | | If set, players (and monsters) cannot see beyond the object unless they cross it or manage to stand on top of it. | + | block view | blocksview <0/1> | If set, players (and monsters) cannot see beyond the object unless they cross it or manage to stand on top of it. For multi-tile objects, this flag may be set uniquely for each part. | ======Server define.h Object Type Excerpt====== IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/dev:object_types?rev=1199657970 New Revision: http://wiki.metalforge.net/doku.php/dev:object_types -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 10 19:17:57 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 10 Jan 2008 19:17:57 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:objects Message-ID: <1200014277.768488.8004.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/10 19:17 User : kbulgrien Edit Summary: Add note to blocksview. @@ -1478,8 +1478,9 @@ When hit_map() hits the transport, we examine look for all players in the transport and damage them as appropriate. Note that items are not damaged. As of this writing, transports are non living creatures, and thus can't be damaged. + ====== Flags & specifications: (usage: flag value) ====== @@ -1554,9 +1555,9 @@ | reflecting <1> | set if O is reflective | | changing <1> | set if O will change appearance | | splitting <1> | set if O will divide | | hitback <1> | set if O hits when being hit | - | blocksview <1> | set if O blocks line of sight | + | blocksview <1> | set if O blocks line of sight. For multi-tile objects, this flag may be set uniquely for each part. | | undead <1> | set if O is undead | | scared <1> | internal (O is running away from players right now) | | unaggressive <1> | internal (not used yet) FIXME isn't is used | | color_fg <no> | foreground color of O. Remember to set face/anim first! | IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/dev:objects?rev=1199574232 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 Thu Jan 10 19:49:55 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 10 Jan 2008 19:49:55 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:object_types Message-ID: <1200016195.322577.8052.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/10 19:49 User : kbulgrien Edit Summary: Add 'identified' to the common list; adjust some wording. @@ -604,13 +604,14 @@ * "maxhp <number>" should only be set to a summoning rune. It will then summon <number> creatures of <monster_arch_name>. Notes on usage: Avoid monsters stepping on your runes. For example, summoning runes together with spellcasting- and attack-runes is usually a bad idea. One can use this feature intentionally though to create chain-reactions of summoning runes and such things, however one should be careful about doing this. + ===== Common Object Attributes ===== - The following attributes are used for many different object-types: (These are only mentioned here, not in the detailed list of object-types later. Apply them to all objects where they make any "sense".) + The following attributes are used for many different object-types: (These are only mentioned here, not in the detailed list of object-types above. Apply them to all objects where they make any "sense".) ^ CrossfireEditor ^ arch/map field ^ Description ^ | name | name <name> | The name of the object displayed to players. | | title | title <title> | An object's title. Once the object is identified the title is attached to the name. Typical titles are "of mostrai", "of xray vision" etc. | @@ -619,14 +620,16 @@ | | weight <grams> | Makes an object weigh <grams> grams (1000g is 1kg). Objects with "weight 0" are not pickable for players. Still, set "no_pick 1" for explicitly non-pickable objects. | | | value <num> | Adds a certain value to the object: It will be worth <num> times the default value from it's archetype. Value for buying/selling will be further modified by various factors. Hence, testing values in-game is usually inevitable. | | material <number> | <number> is a bitmask, containing the information of what material the object is made of. An object's material affects its likelihood to get destroyed by certain hazards (fire/cold/acid..). Material 0 or 256 means the object cannot be destroyed at all (this is VERY important for special keys!). Read more about materials here. | | | msg \\ <text> \\ endmsg | <text> is the "story" or description of the object (for the players). This should work for all pickable items in some way. For other object-types (living creatures/magic mouth..) this message has special meanings. In crossedit you can write this kind of message into the big text-frame in an object's attribute window. Add stories to all the special artifacts you create! | - | invisible | invisible 1 | Makes the object invisible. Depending on the object-type, some can be made visible by the show_invisible spell. If in doubt, test it. Putting an invisible object under the floor always prevents it from being shown, but, in some cases, might cause malfunction to the object. You may find more detailed info about this matter in the description of the affected object types. | | glow\ radius | | If glow radius is set to a value greater than zero, the object appears lit up on dark maps. It can be a value between 0 and 4 with higher values emitting greater amounts of light. | + | identified | identified <0/1> | Whether the item is identified or not. If it is, both the name and title are shown to the player. | + | invisible | invisible 1 | Makes the object invisible. Depending on the object-type, some can be made visible by the show_invisible spell. If in doubt, test it. Putting an invisible object under the floor always prevents it from being shown, but, in some cases, might cause malfunction to the object. You may find more detailed info about this matter in the description of the affected object types. | | smooth level | | If smooth level is set to a value greater than zero, the object will be drawn partially over adjacent squares having a lower smooth level. The value must be between 0 and 255 (inclusive) where 0 means "never overlap adjacent squares". | | elevation | | The elevation, or height above sea level) of this tile. It is used for weather calculations and should be in the range -32000 to 32000. The elevation of a tile must be set in the bottom-most game object; elevation values for non-bottom-most game objects are ignored by the Crossfire server. | | block view | blocksview <0/1> | If set, players (and monsters) cannot see beyond the object unless they cross it or manage to stand on top of it. For multi-tile objects, this flag may be set uniquely for each part. | + Note: When attributes are specified in multi-tile arch, most attributes need only be set in the head part, though there are some which may be uniquely set for each non-head part. ======Server define.h Object Type Excerpt====== /** IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/dev:object_types?rev=1200014039 New Revision: http://wiki.metalforge.net/doku.php/dev:object_types -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 12:36:45 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 12:36:45 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:misc Message-ID: <1200249405.532123.19495.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 12:36 User : ryo Edit Summary: first map info @@ -3,4 +3,5 @@ FIXME should be put in other pages, more adapted to the subject :) * to make the client-side images archives: in server sources, run ''adm/lib/collect_images.pl -archive''. This will generate ''crossfire-images.tar'' in the server root, containing wanted files. * if making new archetypes and faces, remember your face must be called ''myface.base.111.png'', not ''myface.111.png'' (''base'' is the image set) + * first map is known through the special ''system/map.arc'' archetype, which contains the initial map path (''slaying'') and location (''sp'', ''hp''), like another exit IP-Address : 82.236.87.204 Old Revision: http://wiki.metalforge.net/doku.php/dev:misc?rev=1174564588 New Revision: http://wiki.metalforge.net/doku.php/dev:misc -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 17:16:46 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 17:16:46 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200266206.868763.21483.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 17:16 User : eracc Edit Summary: @@ -269,15 +269,18 @@ sends messsage to party members party leave takes you out of current party + ==== peaceful ==== The 'peaceful' command will switch you between peaceful and hostile attack modes. When peaceful is on you will not automatically attack other player when bumping into them and will do reduced damage against other players if you do attack them (friendly fire). Having peaceful mode on only lowers damage against other players, it has no effect on damage done to monsters or other NPCs, so it is generally advisable to remain in peaceful mode unless you are looking for trouble. It is still entirely possible to kill other players when in peaceful mode so you should still be careful when interacting with other players. Hostile mode (peaceful off) will enable melee combat when bumping into other players and does normal damage for other attacks as well. Damage done by area effect attacks like cone spells, explosive detonations, fireballs, poisons, cloud or swarm attacks, runes or disease are not modified by peaceful/hostile mode. + + **WARNING: Running around with hostile on means other players AUTOMATICALLY hit back when you bump them. If your low level character bumps into a high enough level melee character your character //will// die. Using hostile on servers that frown on player killing (PK) is just not smart and will likely result in your being banned from that server.** ==== petmode ==== Petmode controls how your pets (charmed monsters) will behave. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1164396189 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 19:25:45 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 19:25:45 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200273945.956814.22000.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 19:25 User : eracc Edit Summary: @@ -167,11 +167,15 @@ ==== killpets ==== The killpets command is a quick and convenient way to get rid of all your pets when they are no longer useful or are getting in the way. Any equipment they had will be left behind, but you will get no experience for their death. However, it kills them instantaneously. If a name is specified then only pets with that name will be killed, eg killpets bat will kill bats but not bees. If a number is specified, the pet corresponding to that number is killed. + ==== listen ==== Listen, sets the level of messages you will hear. + + 'listen 0 - turns off listen and shows **no** messages.\\ + 'listen 10 - default listen level on modern Crossfire servers. ==== mark ==== mark is used to mark items for items that apply other items. Examples of these are flint & steel marked for apply torches, a weapon marked for improve weapon scrolls. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1200266204 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 19:29:40 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 19:29:40 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200274180.264773.22003.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 19:29 User : eracc Edit Summary: @@ -319,10 +319,14 @@ Parameters are: * nothing: displays current quests. * finished: displays finished quests; * xxx: displays details for quests (finished or not) with name containing xxx + ==== quit ==== + + **WARNING: The //'quit// command will delete your character!** + If you want to quit without deleting your character, you must use a 'Bed to Reality'. Find a bed (probably in a building close to where you entered the game), get on top of it, and Apply it using shift-A (capital A). ==== range ==== Your range weapon can be one of several weapons, a spell you cast, a bow-and-arrow, a rod, or a wand, to name a few. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1200273942 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 19:37:06 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 19:37:06 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200274626.544081.22018.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 19:37 User : eracc Edit Summary: @@ -88,13 +88,20 @@ It is helpful to bind strings like 'cast burning hands' to keys. see 'help bind' 'help [[player_commands#range]] for more information on range weapons. + + ==== chat ==== + Chat sends a message to the chat channel on the current server. Anyone with '[[player_commands#listen]] 10 enabled will see your message. On some servers 'chat is preferable over '[[player_commands#shout]] as a way to communicate with all players. + + Chat usage: + + 'chat [insert a message that you want everyone to see] ==== drop ==== Drop usage: - drop [number] name + 'drop [number] name name is the name of the item(s) to drop. It may match multiple items. The name is matched against the start of the objects in your inventory. The name matching is case insensitive. == There are a few special name values: == IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1200274178 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 19:37:57 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 19:37:57 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200274677.340011.22021.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 19:37 User : eracc Edit Summary: @@ -174,15 +174,16 @@ ==== killpets ==== The killpets command is a quick and convenient way to get rid of all your pets when they are no longer useful or are getting in the way. Any equipment they had will be left behind, but you will get no experience for their death. However, it kills them instantaneously. If a name is specified then only pets with that name will be killed, eg killpets bat will kill bats but not bees. If a number is specified, the pet corresponding to that number is killed. + ==== listen ==== Listen, sets the level of messages you will hear. 'listen 0 - turns off listen and shows **no** messages.\\ - 'listen 10 - default listen level on modern Crossfire servers. + 'listen 10 - default listen level on modern Crossfire servers. This enables seeing messages on the [[player_commands#chat]] channel. ==== mark ==== mark is used to mark items for items that apply other items. Examples of these are flint & steel marked for apply torches, a weapon marked for improve weapon scrolls. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1200274623 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 19:38:47 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 19:38:47 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200274727.712285.22024.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 19:38 User : eracc Edit Summary: @@ -174,16 +174,18 @@ ==== killpets ==== The killpets command is a quick and convenient way to get rid of all your pets when they are no longer useful or are getting in the way. Any equipment they had will be left behind, but you will get no experience for their death. However, it kills them instantaneously. If a name is specified then only pets with that name will be killed, eg killpets bat will kill bats but not bees. If a number is specified, the pet corresponding to that number is killed. + ==== listen ==== Listen, sets the level of messages you will hear. - 'listen 0 - turns off listen and shows **no** messages.\\ - 'listen 10 - default listen level on modern Crossfire servers. This enables seeing messages on the [[player_commands#chat]] channel. + Listen usage:\\ + 'listen 0 - turns off listen and shows **no** messages.\\ + 'listen 10 - default listen level on modern Crossfire servers. This enables seeing messages on the [[player_commands#chat]] channel. ==== mark ==== mark is used to mark items for items that apply other items. Examples of these are flint & steel marked for apply torches, a weapon marked for improve weapon scrolls. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1200274675 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 19:40:16 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 19:40:16 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200274816.306975.22042.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 19:40 User : eracc Edit Summary: @@ -174,18 +174,19 @@ ==== killpets ==== The killpets command is a quick and convenient way to get rid of all your pets when they are no longer useful or are getting in the way. Any equipment they had will be left behind, but you will get no experience for their death. However, it kills them instantaneously. If a name is specified then only pets with that name will be killed, eg killpets bat will kill bats but not bees. If a number is specified, the pet corresponding to that number is killed. + ==== listen ==== Listen, sets the level of messages you will hear. Listen usage:\\ - 'listen 0 - turns off listen and shows **no** messages.\\ - 'listen 10 - default listen level on modern Crossfire servers. This enables seeing messages on the [[player_commands#chat]] channel. + * 'listen 0 - turns off listen and shows **no** messages.\\ + * 'listen 10 - default listen level on modern Crossfire servers. This enables seeing messages on the [[player_commands#chat]] channel. ==== mark ==== mark is used to mark items for items that apply other items. Examples of these are flint & steel marked for apply torches, a weapon marked for improve weapon scrolls. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1200274725 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 19:42:55 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 19:42:55 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200274975.196742.22045.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 19:42 User : eracc Edit Summary: @@ -255,8 +255,9 @@ see [[player_commands#output]] === output-sync === see [[player_commands#output]] + ==== party ==== party join partyname @@ -280,9 +281,9 @@ lists the members of the party you are in party say <msg> - sends messsage to party members + sends messsage to party members. One may also use [[player_commands#gsay]] instead. party leave takes you out of current party IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1200274814 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 13 19:49:06 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 13 Jan 2008 19:49:06 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: player_commands Message-ID: <1200275346.209733.22054.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/13 19:49 User : eracc Edit Summary: @@ -135,8 +135,14 @@ To control your golem, just press the fire key in the direction you want your golem to move. Your golem will then start moving in that direction, and keep moving in that direction until you change its direction. Note that once you leave the map that the golem is on, the golem will disappear. Also, once you select another spell to cast, or change your range type, your golem will disappear. + + ==== gsay ==== + Gsay sends a message to all members of your current [[player_commands#party]]. + + Gsay usage: + * 'gsay [Message that you want all party members to see] ==== invoke ==== The invoke command is used to cast a spell immediately, or when it is necessary to give a parameter to the spell. Invoke will not set the range weapon. @@ -193,13 +199,11 @@ mark without options shows your currently marked item. usage is as follows: - mark sword +3 - - mark three torches - - mark sword + * mark sword +3 + * mark three torches + * mark sword mark will look for best match first, and then look for matches based on shortened name, object name, archetype name. It prints the match it finds. ==== melee ==== @@ -259,35 +263,35 @@ ==== party ==== - party join partyname + * party join partyname Puts you in a party, prompts you for a passwd if there is one - party form partyname + * party form partyname Forms a party and puts you as leader, 32 character max. At the moment, being party leader does nothing. May be used in the future. - party list + * party list Lists currently formed parties and their 'leader' - party passwd <password> + * party passwd <password> Changes the passwd for the party you are in, 8 character max. - party who + * party who lists the members of the party you are in - party say <msg> + * party say <msg> sends messsage to party members. One may also use [[player_commands#gsay]] instead. - party leave - takes you out of current party + * party leave + takes you out of current party ==== peaceful ==== The 'peaceful' command will switch you between peaceful and hostile attack modes. IP-Address : 72.4.41.2 Old Revision: http://wiki.metalforge.net/doku.php/player_commands?rev=1200274971 New Revision: http://wiki.metalforge.net/doku.php/player_commands -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 14 15:57:12 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 14 Jan 2008 15:57:12 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: crossfire_compile_guide Message-ID: <1200347832.856444.26378.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/14 15:57 User : Edit Summary: Added autoconf to the quick reference list @@ -43,9 +43,9 @@ * libsvn-dev - Development files for Subversion libraries (required for Subversion revision number reporting in metaserver2) As a quick reference: - sudo apt-get install check libsqlite3-0 libcurl3 libcurl3-dev libsvn-dev + sudo apt-get install check autoconf2.5 libsqlite3-0 libcurl3 libcurl3-dev libsvn-dev Installing Python and which version is still under investigation/discussion * lib64python2.4-2.4.3 is known to work on Mandriva 2007.0 x86_64 IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/crossfire_compile_guide?rev=1199647049 New Revision: http://wiki.metalforge.net/doku.php/crossfire_compile_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 17 03:32:57 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 17 Jan 2008 03:32:57 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: ui_proposals Message-ID: <1200562377.986377.30962.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/17 03:32 User : Edit Summary: jxkrntaf @@ -1,40 +1 @@ - ====== Crossfire UI Proposals ====== - - As of late there seems to have be alot of discussion on IRC about how the user interface should be changed. It certainly seems many are dissatisfied with the current user interfaces and believe much better could be done, therefore I am creating this page for people to post their own UI proposals and comment on those of others. When putting things here, remember it doesn't have to be a full mockup, in fact I suggest you don't make it a full mockup, as all we're looking at for now here is a sketch for the basic UI concept would work best. When commenting on UI designs of others, remember that these are just rough sketches and that specifics such as the relative sizing of things and the number of rows in an inventory view are probably not exact. Most importantly: Have fun :-) \\ - --- //[[user:Rednaxela|Alex Schultz]] 2007/02/25 10:17// - - ===== ===== - ==== Sketch ==== - - {{http://lauwenmark.ailesse.be/new/images/gallery/dirty/cfidea.png?200}} \\ - **Created by:** Lauwenmark/Gros - ==== Author's Notes ==== - top half: the "stats screen", displayed by a push on a single key/button. \\ bottom half: the playing screen. \\ The text area to enter commands appears between the fastbelt and the log area, only when Enter has been pressed, and text entry is thus active. The fastbelt - numbered F1-F12 - can contain spells, inventory objects, or maybe even batches of actions (arbitrary commands, as keybindings have). They are filled by using the "stats screen", by drag-n-dropping elements from the inv, the spell list, etc. on the Fx slots. The stats screen also displays the complete character stats, the skills/experience scores, and has an area which describes a currently selected element in one of the lists below. It is of course possible to apply, drop, or get objects from the stats screen. The objects on the floor appear on the main screen, in the bottom-right corner. Only two items visible at a time, with arrows to browse through them. - - ==== Comments ==== - - It looks like a good design to me. Some things that concern me a little, is that the inventory, spells, and skills lists on the stats screen seem to me like they might be a little bit squished. Also it might be helpful to have a floor view in the stats screen. I also think it would be a good addition, to have separate full screen views for inventory, spells, and skills, for cases where one is doing more manipulation within there instead of between the areas. --- //[[user:Rednaxela|Alex Schultz]] 2007/02/27 11:15// - - - I like the design. Focus should indeed be on play area, with other zones simply there when needed. Red's suggestion to have full screen / maximized for manipulation is nice. Ideally, the interface could be defined through a configuration file so it can be adjusted by players to their wish. But that may be overkill :) --- //[[user:ryo|Ryo Saeba]] 2007/06/10 03:00// - - ===== ===== - ==== Sketch ==== - {{user:rednaxela:cflayout.png?300|}} \\ - **Created by:** Rednaxela - ==== Author's Notes ==== - Here's a bit of an idea I have for one possible way to lay out a client interface, with four panels as shown, which are normally small providing a "summary" of the most important parts to be accessible, which can expand out to give full menus for things. Comments/criticisms/bashing welcome. :) - - ==== Comments ==== - - I like the idea, but there should be: - * a way to display both ground and inventory, for fast manipulation - * at least the last messages should be displayed, so player knows what happens (resistance change & such) - - --- //[[user:Ryo|Ryo Saeba]] 2007/06/18 13:04// - - > Well in terms of displaying the ground and inventory, I was thinking of having the menu (slightly misleadingly) labeled "inventory" include both of those. The last messages would indeed be displayed, as the 'tabs' would generally contain a 'summary' of their contents. Another elaboration that isn't in the design above that I was thinking about which may help with equipping, would be making fading messages of recent stat changes (not including hp, food, etc.) as they happen, in the form of an on-screen-display. - > - > --- //[[user:Rednaxela|Alex Schultz]] 2007/06/18 13:16// - - ===== ===== + [URL=http://whvfhqqu.com]citcsoap[/URL] pwvfxuxv http://njbmvowy.com vdglbrbe uutovdku <a href="http://mkpwxofd.com">izhytehn</a> IP-Address : 87.98.217.43 Old Revision: http://wiki.metalforge.net/doku.php/ui_proposals?rev=1189008616 New Revision: http://wiki.metalforge.net/doku.php/ui_proposals -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 17 10:38:53 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 17 Jan 2008 10:38:53 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: ui_proposals Message-ID: <1200587933.249054.2269.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/17 10:38 User : Edit Summary: old revision restored due to link spammer @@ -1 +1,40 @@ - [URL=http://whvfhqqu.com]citcsoap[/URL] pwvfxuxv http://njbmvowy.com vdglbrbe uutovdku <a href="http://mkpwxofd.com">izhytehn</a> + ====== Crossfire UI Proposals ====== + + As of late there seems to have be alot of discussion on IRC about how the user interface should be changed. It certainly seems many are dissatisfied with the current user interfaces and believe much better could be done, therefore I am creating this page for people to post their own UI proposals and comment on those of others. When putting things here, remember it doesn't have to be a full mockup, in fact I suggest you don't make it a full mockup, as all we're looking at for now here is a sketch for the basic UI concept would work best. When commenting on UI designs of others, remember that these are just rough sketches and that specifics such as the relative sizing of things and the number of rows in an inventory view are probably not exact. Most importantly: Have fun :-) \\ + --- //[[user:Rednaxela|Alex Schultz]] 2007/02/25 10:17// + + ===== ===== + ==== Sketch ==== + + {{http://lauwenmark.ailesse.be/new/images/gallery/dirty/cfidea.png?200}} \\ + **Created by:** Lauwenmark/Gros + ==== Author's Notes ==== + top half: the "stats screen", displayed by a push on a single key/button. \\ bottom half: the playing screen. \\ The text area to enter commands appears between the fastbelt and the log area, only when Enter has been pressed, and text entry is thus active. The fastbelt - numbered F1-F12 - can contain spells, inventory objects, or maybe even batches of actions (arbitrary commands, as keybindings have). They are filled by using the "stats screen", by drag-n-dropping elements from the inv, the spell list, etc. on the Fx slots. The stats screen also displays the complete character stats, the skills/experience scores, and has an area which describes a currently selected element in one of the lists below. It is of course possible to apply, drop, or get objects from the stats screen. The objects on the floor appear on the main screen, in the bottom-right corner. Only two items visible at a time, with arrows to browse through them. + + ==== Comments ==== + + It looks like a good design to me. Some things that concern me a little, is that the inventory, spells, and skills lists on the stats screen seem to me like they might be a little bit squished. Also it might be helpful to have a floor view in the stats screen. I also think it would be a good addition, to have separate full screen views for inventory, spells, and skills, for cases where one is doing more manipulation within there instead of between the areas. --- //[[user:Rednaxela|Alex Schultz]] 2007/02/27 11:15// + + + I like the design. Focus should indeed be on play area, with other zones simply there when needed. Red's suggestion to have full screen / maximized for manipulation is nice. Ideally, the interface could be defined through a configuration file so it can be adjusted by players to their wish. But that may be overkill :) --- //[[user:ryo|Ryo Saeba]] 2007/06/10 03:00// + + ===== ===== + ==== Sketch ==== + {{user:rednaxela:cflayout.png?300|}} \\ + **Created by:** Rednaxela + ==== Author's Notes ==== + Here's a bit of an idea I have for one possible way to lay out a client interface, with four panels as shown, which are normally small providing a "summary" of the most important parts to be accessible, which can expand out to give full menus for things. Comments/criticisms/bashing welcome. :) + + ==== Comments ==== + + I like the idea, but there should be: + * a way to display both ground and inventory, for fast manipulation + * at least the last messages should be displayed, so player knows what happens (resistance change & such) + + --- //[[user:Ryo|Ryo Saeba]] 2007/06/18 13:04// + + > Well in terms of displaying the ground and inventory, I was thinking of having the menu (slightly misleadingly) labeled "inventory" include both of those. The last messages would indeed be displayed, as the 'tabs' would generally contain a 'summary' of their contents. Another elaboration that isn't in the design above that I was thinking about which may help with equipping, would be making fading messages of recent stat changes (not including hp, food, etc.) as they happen, in the form of an on-screen-display. + > + > --- //[[user:Rednaxela|Alex Schultz]] 2007/06/18 13:16// + + ===== ===== IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/ui_proposals?rev=1200562374 New Revision: http://wiki.metalforge.net/doku.php/ui_proposals -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sat Jan 19 14:34:16 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 19 Jan 2008 14:34:16 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: coding_style_guide Message-ID: <1200774856.746092.14299.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/19 14:34 User : kbulgrien Edit Summary: No indentation of # directives; More doxygen style; Major reformat. @@ -1,32 +1,32 @@ - The following is a wiki-fied mirror of //crossfire/doc/Developers/programming_guide// from the server source. + The following is a wiki-fied reorganization of of //crossfire/doc/Developers/programming_guide// from the server source. - ====== Section 1 - Currently used conventions/hints for new code writers: ====== + ====== Currently used conventions ====== + + =====Naming===== - Variable abbreviations - ''op'' is short for object pointer, ''ob'' is for object, and ''pl'' is for player. - Some functions are named using the conventions above - the naming effects what options they take (''insert_ob_in_ob'' takes 2 object structures) - - Indentation is 4 spaces. This can be a pain to read, but most functions should be consistent through the function. + - Use descriptive variable names. + * ''op'' and ''pl'' should only be used for temporary variables (cycling through the list or the like). + * For variables well defined, use an accurate name (ie, hitter, sack, etc). + - Local variable names. Just a rules of thumb. These are ok:<code> + int mylongvarname; + int my_long_var_name; + </code> + * Do NOT use caps except for typedefs, enums and defines. + + =====Using Objects===== + - Some structure elements should never be accessed directly - rather, there are other functions to use the values. * ''object->owner'': This contains the owner id for this object. Use ''set_owner'' and ''get_owner'' instead. Directly using object->owner is likely to get unpredictable results. * ''object->nrof'': This contains the number of an object. Since changing this will change the weight of an object, direct access should also be avoided. Use ''decrease_ob_nr'', ''split_ob'', ''and insert_ob_in_...'' - the later will merge the objects if applicable. - If using ''insert_ob_in_map'' and plan to do further actions with the object, check and make sure the object still exists after insertion - it is possible that the object gets destroyed while being inserted (eaten by an altar or such). + =====Code Layout===== + ====File Header==== - ====== Section 2 - Style guide for new additions: ====== - - - Use descriptive variable names. ''op'' and ''pl'' should only be used for temporary variables (cycling through the list or the like). For variables well defined, use an accurate name (ie, hitter, sack, etc). - - Only add name options with //#ifdef'//s to the ''config'' file if the behaviour seriously changes the game. Adding a new spell does not warrant an //#ifdef//. There are already too many options in the ''config.h'' file. - - Log errors/diagnostics with the LOG function. When doing so, please include the function name - this is especially true for errors. - - If you want to add special debug code for certain compiles, generate a unique //#define// for it - don't use the global DEBUG. For example, NEWCS_DEBUG. - - Try to use the [s/u]int[8/16/32] whenever possible. Use the one of appropriate size/type. If not sure, go for the next size up. Do not ever write code assuming that any of those will have an exact number of bits - those types only mean that you will get at least that many bits - you may get more. - - The exception to #5 above is strings. Continue to use //char//, since the signed-ness of functions that take string options can differ system to system, and generate excessive warnings if the wrong sign is used. - - When adding new function, include a comment of what the function is supposed to do, what options it takes, and what if any value it returns. This makes debugging of such functions easier, and also makes it better known to other developers if that function might be useful to them. - - Try to keep lines to less than 80 columns when possible. This is not a strict requirement - don't break up some complex comparison because the line would otherwise be 83 characters long. Xterms can be resized to most any width. However, use your judgment on whether breaking up a long line would make something more or less readable. - - Assume all names use one name space. For example, if there is a //struct// called ''spell'', don't make the name of an optional parameter spell. This will break on ANSI C compilers that follow the spec strictly (gcc does not, even with -strict -ansi) - - As a followup on 9 above, do not use non-standard gcc extensions (%%//%% for comment lines, ability to nest functions, declare arrays with variable bounds, etc.) Likewise, do not use special system functions, for example, do not assume the target is a BSD or SVR4 system. If a potentially non-standard function must be used, add checks in the autoconf script and include a version of the function in case it is not on that system. The keyword here is portability; do not assume everyone else has the same system you have. - - Write code that can easily be maintained in the future, not code that is easiest to write quickly. In other words, do not do the quick and dirty hack, but instead always write code with maintainability and clarity in mind. - - Use 4 space indentation. While a lot of old code may use 2 spaces, a move to 4 spaces makes readability easier. - Files are created with standard content blocks.<code>char *rcsid_component_file_ext = "$Id: file.ext$"; /* * Project name, brief description @@ -46,31 +46,32 @@ * The @file path is important when multiple files in the project may have the same name in different directories. * Do not include //trunk// or //branches/1.x// in the @file comment header path. * The @file comment block helps doxygen create meaningful output. * The license block requirement is obvious. - - Functions are documented like this.<code>/** - * A brief descriptive sentence summarizes the function. An overview ends - * at the first period and space, then the detailed information follows. - * - * @param bla - * This is a parameter - * @return - * returns NULL - */</code> - * This lets doxygen generate nice documentation. - - Use the following block commenting style.<code>/* - * Do block comments like this. - * Get in the habit of using a - * brief and detailed style. - */ - /* - and not - like this - */ + ====Directives==== + + - Only add name options with //#ifdef'//s to the ''config'' file if the behaviour seriously changes the game. Adding a new spell does not warrant an //#ifdef//. There are already too many options in the ''config.h'' file. + - If you want to add special debug code for certain compiles, generate a unique //#define// for it - don't use the global DEBUG. For example, NEWCS_DEBUG. + + ====General==== + + - Try to keep lines to less than 80 columns when possible. This is not a strict requirement - don't break up some complex comparison because the line would otherwise be 83 characters long. Xterms can be resized to most any width. However, use your judgment on whether breaking up a long line would make something more or less readable. + - Write code that can easily be maintained in the future, not code that is easiest to write quickly. In other words, do not do the quick and dirty hack, but instead always write code with maintainability and clarity in mind. + + ===Indentation=== + + - Indentation is 4 spaces. This can be a pain to read, but most functions should be consistent through the function. + * While a lot of old code may use 2 spaces, a move to 4 spaces makes readability easier. + - #if directives and friends are not indented. + + ===Data Types=== + + - Try to use the [s/u]int[8/16/32] whenever possible. Use the one of appropriate size/type. If not sure, go for the next size up. Do not ever write code assuming that any of those will have an exact number of bits - those types only mean that you will get at least that many bits - you may get more. + * The exception to this are strings. Continue to use //char//, since the signed-ness of functions that take string options can differ system to system, and generate excessive warnings if the wrong sign is used. + + ===Statements=== - /* but single line comment using this method is fine */</code> - * It is much easier to spot the block comments if they all start with *, and they tend to be worth noticing. - As discussed on irc, the preferred style for expressions is like this:<code> if (expression) { statement; statement; @@ -90,19 +91,74 @@ * No space after the left parenthesis * No space before the right parenthesis * Comma right after the formal parameters * Space after the commas. - - Local variable names. Just a rules of thumb. These are ok:<code> - int mylongvarname; - int my_long_var_name; - </code> - * Do NOT use caps except for typedefs, enums and defines. - - To document variables in doxygen, format the comment as shown below:<code> - int my_var_name; /**< Raison d'etre.. */ - </code> + ===Comments=== + + - When adding new function, include a comment of what the function is supposed to do, what options it takes, and what if any value it returns. This makes debugging of such functions easier, and also makes it better known to other developers if that function might be useful to them. + - Do not use C++ style comments (%%//%%). + - Functions are documented like this.<code>/** + * A brief descriptive sentence summarizes the function. An overview ends + * at the first period and space, then the detailed information follows. + * + * @param bla + * This is a parameter + * @return + * returns NULL + */</code> + * This lets doxygen generate nice documentation. + - Use the following block commenting style.<code>/* + * Do block comments like this. + * Get in the habit of using a + * brief and detailed style. + */ + + /* + and not + like this + */ + + /* but single line comment using this method is fine */</code> + * It is much easier to spot the block comments if they all start with *, and they tend to be worth noticing. + - To document variables in doxygen, format the comment as shown below: + * Simple<code> + int a_var_name; /**< Raison d'etre.. */</code> + * Multi-line<code> + int my_var_name; /**< A very long + * Raison d'etre.. */</code> + * Large group summary, with individuals commented also.<code> + /**@{ + * @name UI Widgets + * Widgets for the keybinding dialog + */ + static GtkWidget *fire_label, *run_label, *keybinding_window, + *keybinding_button_bind; + static GtkListStore *keybinding_store; /**<Bound key list for bind dialog.*/ + static GtkTreeSelection *keybinding_selection; + /* @} EndOf UI Widgets */</code> + + =====Portability===== + + This is a cross-platform project. Do not assume everyone else has the same system you have: + + - Do not use non-standard gcc extensions + * %%//%% for comment lines + * Nested functions + * Declaration of arrays with variable bounds + * Etc. + - Do not use special system functions + * Do not assume the target is a BSD, SVR4 system, etc. + * If a potentially non-standard function must be used: + * Add checks in the autoconf script. + * Include a version of the function in case it is not on that system. + - Assume all names use one name space. For example, if there is a //struct// called ''spell'', don't make the name of an optional parameter spell. This will break on ANSI C compilers that follow the spec strictly (gcc does not, even with -strict -ansi) + + =====Diagnostics and Error Handling===== + + - Log errors/diagnostics with the LOG function. When doing so, please include the function name - this is especially true for errors. - ====== Section 3 - Sending in patches: ====== + ====== Sending in Patches: ====== - Send patches on a bug fix or feature enhancement basis individually, and do not make mega-patches. A diff that changes 10 things is more difficult for developers to review and understand as unrelated changes might be going on. It is also harder to reject part of a patch (feature X is nice, but Y doesn't work). - Please state in the message included with the patch what it fixes/changes. Too often, patches are just a bunch of source code, with no indication why it should be incorporated. Without such commentary, it may be difficult to even determine if the bug it fixes is still there in the source it patches. Please also state what version of crossfire the diff is for. - I will assume any patches mailed directly to me are to be included. If posting a patch on the mailing list (either source or ftp location), please explicitly state whether or not you want that patch incorporated into the master source. Many times, a patch may be made available on an expirimental basis which is not ready for widespread distribution. IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/coding_style_guide?rev=1189309146 New Revision: http://wiki.metalforge.net/doku.php/coding_style_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sat Jan 19 14:39:18 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sat, 19 Jan 2008 14:39:18 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: coding_style_guide Message-ID: <1200775158.776413.14317.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/19 14:39 User : kbulgrien Edit Summary: Reduce outline depth under General so sidebar index lists all sections. @@ -1,5 +1,5 @@ - The following is a wiki-fied reorganization of of //crossfire/doc/Developers/programming_guide// from the server source. + The following is a wiki-fied reorganization of //crossfire/doc/Developers/programming_guide// from the server source. ====== Currently used conventions ====== =====Naming===== @@ -52,25 +52,25 @@ - Only add name options with //#ifdef'//s to the ''config'' file if the behaviour seriously changes the game. Adding a new spell does not warrant an //#ifdef//. There are already too many options in the ''config.h'' file. - If you want to add special debug code for certain compiles, generate a unique //#define// for it - don't use the global DEBUG. For example, NEWCS_DEBUG. - ====General==== + ====General Guidelines==== - Try to keep lines to less than 80 columns when possible. This is not a strict requirement - don't break up some complex comparison because the line would otherwise be 83 characters long. Xterms can be resized to most any width. However, use your judgment on whether breaking up a long line would make something more or less readable. - Write code that can easily be maintained in the future, not code that is easiest to write quickly. In other words, do not do the quick and dirty hack, but instead always write code with maintainability and clarity in mind. - ===Indentation=== + ====Indentation==== - Indentation is 4 spaces. This can be a pain to read, but most functions should be consistent through the function. * While a lot of old code may use 2 spaces, a move to 4 spaces makes readability easier. - #if directives and friends are not indented. - ===Data Types=== + ====Data Types==== - Try to use the [s/u]int[8/16/32] whenever possible. Use the one of appropriate size/type. If not sure, go for the next size up. Do not ever write code assuming that any of those will have an exact number of bits - those types only mean that you will get at least that many bits - you may get more. * The exception to this are strings. Continue to use //char//, since the signed-ness of functions that take string options can differ system to system, and generate excessive warnings if the wrong sign is used. - ===Statements=== + ====Statements==== - As discussed on irc, the preferred style for expressions is like this:<code> if (expression) { statement; @@ -92,9 +92,9 @@ * No space before the right parenthesis * Comma right after the formal parameters * Space after the commas. - ===Comments=== + ====Comments==== - When adding new function, include a comment of what the function is supposed to do, what options it takes, and what if any value it returns. This makes debugging of such functions easier, and also makes it better known to other developers if that function might be useful to them. - Do not use C++ style comments (%%//%%). - Functions are documented like this.<code>/** IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/coding_style_guide?rev=1200774853 New Revision: http://wiki.metalforge.net/doku.php/coding_style_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Sun Jan 20 15:31:25 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Sun, 20 Jan 2008 15:31:25 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: linux Message-ID: <1200864685.566068.20345.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/20 15:31 User : Edit Summary: X11 client is in crossfire-client-x11, not in crossfire-client @@ -2,8 +2,9 @@ Crossfire should install and run on any Linux variant that supports [[wp>X_Window_System|X]] and has the libraries which Crossfire requires. ===== Debian ===== Crossfire is available in all Debian distributions; oldstable, stable, testing and unstable. + ==== Installation ==== The easiest way to install Crossfire on [[wp>Debian]] is to use the Debian package system and repository. The version there may lag somewhat behind the latest release, but it will be tested for Debian and automatically install any needed dependencies. @@ -40,9 +41,9 @@ === Client === Installation of the client has a similar syntax. You'll need to chose which client you want to install, or if you install any (or all of) the three - which one you'll actually use for game play. - $ apt-get install crossfire-client + $ apt-get install crossfire-client-x11 $ apt-get install crossfire-client-gtk $ apt-get install crossfire-client-gtk2 @@ -50,9 +51,9 @@ === Launch Client === To launch the client, hit alt+f2 and then enter any of the following (shown in bold text): - * For crossfire-client: **cfclient** + * For crossfire-client-x11: **cfclient** * For crossfire-client-gtk: **gcfclient** * For crossfire-client-gtk2: **gcfclient2** (Minor Note: gcfclient stands for **G**TK **C**ross**F**ire **client**) IP-Address : 88.193.191.125 Old Revision: http://wiki.metalforge.net/doku.php/linux?rev=1197739331 New Revision: http://wiki.metalforge.net/doku.php/linux -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 21 23:47:12 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 21 Jan 2008 23:47:12 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: world:santodominion Message-ID: <1200980832.315044.30289.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/21 23:47 User : leaf Edit Summary: Updated the SD summary @@ -1,6 +1,6 @@ ====== Santo Dominion ====== - Santo Dominion sits in a small bay to the north of Scorn. It is an important port of call for ships travelling to and from scorn. + Santo Dominion sits in a small bay to the north of Scorn. It is an important port of call for ships traveling to and from Scorn and the town of Stoneville, which is located on Dragon Island. ===== Places in Santo Dominion ===== ==== Dungeons ==== * [[world:santodominion:A little opara]] IP-Address : 216.243.156.5 Old Revision: http://wiki.metalforge.net/doku.php/world:santodominion?rev=1160938454 New Revision: http://wiki.metalforge.net/doku.php/world:santodominion -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 17:24:57 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 17:24:57 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: start Message-ID: <1201130697.955194.7514.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 17:24 User : leaf Edit Summary: New page - Missing and Orphaned Pages @@ -52,4 +52,8 @@ * 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. * Get together ([[g2g]]) meeting notes, summary, proposal(s) * [[Content migration]] TODO list + + ===== Wiki Content Editors ===== + + * [[orphans and missing | Missing and Orphaned Pages]] IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/start?rev=1197748218 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 Jan 23 17:29:10 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 17:29:10 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page added: orphans_and_missing Message-ID: <1201130950.585106.7523.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 17:29 User : leaf Edit Summary: Ccreated index page for Missing, Orphaned and Valid wiki pages ~~NOCACHE~~ ====== Missing & Orphaned Pages ====== ===== Missing Pages ===== These pages have references, but do not yet exist. ~~ORPHANSWANTED:wanted!wiki~~ ===== Orphaned Pages ===== These pages exist, but the only way to find them is using the index tree. ~~ORPHANSWANTED:orphans!wiki~~ ===== Valid Pages ===== These pages exist and are valid. ~~ORPHANSWANTED:valid!wiki~~ IP-Address : 65.193.16.100 Old Revision: none New Revision: http://wiki.metalforge.net/doku.php/orphans_and_missing -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 17:37:34 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 17:37:34 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: people Message-ID: <1201131454.666639.7546.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 17:37 User : meflin Edit Summary: @@ -25,13 +25,13 @@ | Mats Rauhala | | MasseR | | | | | Aaron Baugher | [[user:mhoram]] | Mhoram | [[http://sourceforge.net/users/aaron_baugher|aaron_baugher]] | | [[http://aaron.baugher.biz/|aaron.baugher.biz]] | | Kevin Bulgrien | [[user:kbulgrien]] | kbulgrien | [[http://sourceforge.net/users/kbulgrien|kbulgrien]] | | [[http://kbulgrien.home.att.net/|kbulgrien.home.att.net]] | | Anthony Wyatt | [[user:buzzsaw]] | buzzsaw | | | | - + | James Lopeman | [[user:meflin]] | meflin | | | http://home.comcast.net/~meflin/ | ===== Package Maintainers ===== ^ Full Name ^ irc ^ Distribution ^ | Kari Pahula | kaol | Debian| | Michael Thomas | _wart_ | Fedora| | Ketche | Ketche | Mac OS X(ppc-X11) | | Ketche | Ketche | SPARC Solaris | | Ryo | ryo_ | Windows | IP-Address : 71.229.157.100 Old Revision: http://wiki.metalforge.net/doku.php/people?rev=1198194560 New Revision: http://wiki.metalforge.net/doku.php/people -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 18:56:05 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 18:56:05 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: unlinked_test_page Message-ID: <1201136165.482849.7893.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 18:56 User : Edit Summary: Removing empty test page @@ -1 +1 @@ - This is a test page that should be an orphan (no links to it) so I can make sure my orphan-finding script works. + IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/unlinked_test_page?rev=1166641931 New Revision: http://wiki.metalforge.net/doku.php/unlinked_test_page -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 19:44:45 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 19:44:45 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: start Message-ID: <1201139085.659650.8090.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 19:44 User : leaf Edit Summary: Link to the playground testing page @@ -42,18 +42,20 @@ * [[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. * Get together ([[g2g]]) meeting notes, summary, proposal(s) + * **Important**: If you want to test things please use the [[playground:playground]]. * [[Content migration]] TODO list ===== Wiki Content Editors ===== * [[orphans and missing | Missing and Orphaned Pages]] IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/start?rev=1201130695 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 Jan 23 19:47:10 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 19:47:10 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: start Message-ID: <1201139230.740290.8107.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 19:47 User : leaf Edit Summary: Fixed typo in the link to the playground page @@ -51,11 +51,11 @@ * 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. * Get together ([[g2g]]) meeting notes, summary, proposal(s) - * **Important**: If you want to test things please use the [[playground:playground]]. + * **Important**: If you want to test things please use the [[playground]]. * [[Content migration]] TODO list ===== Wiki Content Editors ===== * [[orphans and missing | Missing and Orphaned Pages]] IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/start?rev=1201139082 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 Jan 23 19:59:51 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 19:59:51 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: map-making_guide Message-ID: <1201139991.194688.8122.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 19:59 User : leaf Edit Summary: Link from Map-Making Guide to Technical Information About Maps page @@ -51,4 +51,7 @@ On the [[dev:object types|object types]] page there is a list of all types that are involved in map-making. Each listed type has a description of their most important attributes and how to use them. For creating simple maps, you can use the predefined arches mostly as they are. But when you want to make some really cool maps, there is no other way but to read the object type information carefully. + ===== Technical Information About Maps ===== + + This documented is intended to convey [[map-technical|technical information]] on how crossfire deals with the map objects and objects placed on the maps. IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/map-making_guide?rev=1199656164 New Revision: http://wiki.metalforge.net/doku.php/map-making_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 20:04:15 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 20:04:15 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user_cavesomething_todo_spelldescriptions Message-ID: <1201140255.296204.8323.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 20:04 User : leaf Edit Summary: @@ -3 +3,5 @@ [[http://crossfire.real-time.com/spells/magic.html]] + + This page appears to replace this current page + + http://wiki.metalforge.net/doku.php/user:cavesomething:todo:spelldescriptions IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/user_cavesomething_todo_spelldescriptions?rev=1153392821 New Revision: http://wiki.metalforge.net/doku.php/user_cavesomething_todo_spelldescriptions -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 20:05:01 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 20:05:01 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user_cavesomething_todo_spelldescriptions Message-ID: <1201140301.164397.8326.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 20:05 User : leaf Edit Summary: Removing this page as it's content is elsewhere @@ -1,7 +1 @@ - Go there and there is a huge list of spells: - [[http://crossfire.real-time.com/spells/magic.html]] - - This page appears to replace this current page - - http://wiki.metalforge.net/doku.php/user:cavesomething:todo:spelldescriptions IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/user_cavesomething_todo_spelldescriptions?rev=1201140252 New Revision: http://wiki.metalforge.net/doku.php/user_cavesomething_todo_spelldescriptions -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 20:10:53 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 20:10:53 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user:mhoram Message-ID: <1201140653.398030.8354.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 20:10 User : leaf Edit Summary: Link to Build Wiki Pages also developed by Mhoram @@ -42,8 +42,9 @@ * [[.mhoram:scripts:healup]] -- Bring grace and hit points to maximum. * [[.mhoram:scripts:subs.pl]] -- Subroutines used by most of my other scripts. + ==== Other Scripts ==== @@ -51,12 +52,14 @@ * [[.mhoram:scripts:indent_a_file]] -- Lisp function for correctly indenting and untabifying code with Emacs. * [[.mhoram:scripts:attacktype]] -- Perl script to list the attack types corresponding to a number. + + * [[.mhoram:code:bwp]] -- Build Wiki Pages: This is a program I?m working on to automate the building of pages for the wiki from the monster archetypes (and eventually other categories, perhaps). ===== My Contacts ===== ^ Email: | aaron at baugher daht biz | ^ IRC: | Mhoram (on freenode) | ^ Website: | http://aaron.baugher.biz/ | ^ Myspace: | www.myspace.com/aaronbaugher | ^ Yahoo Messenger: | aaron_baugher | IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/user:mhoram?rev=1173198117 New Revision: http://wiki.metalforge.net/doku.php/user:mhoram -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 20:16:49 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 20:16:49 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo Message-ID: <1201141009.781413.8363.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 20:16 User : leaf Edit Summary: Merge in dev_todo:cf2.0:roadmap and related links @@ -9,11 +9,26 @@ ===== General TODO ===== Dump information about large projects and ideas here. * Should this be broken into "pending" and "proposed" categories? + ==== Major Releases ==== * [[dev_todo:CF2.0|Crossfire 2.0]] - List of things to do before the big 2.0 release + + === CF2 Roadmap === + + On the //Crossfire Discussion Mailing List// was talked about the following topics: + + * [[dev_todo:cf2.0:races]] + * [[dev_todo:cf2.0:classes]] + * [[dev_todo:cf2.0:skills]] + * [[dev_todo:cf2.0:guilds]] + * [[dev_todo:cf2.0:combat]] + * [[dev_todo:cf2.0:magic]] + * [[dev_todo:cf2.0:party]] + * [[dev_todo:cf2.0:world]] + * [[dev_todo:cf2.0:alchemy]] ==== Fixes/Revamps ==== Stuff that needs to be fixed, seriously overhauled, or improved * [[dev_todo:fix_sound|Fix/Revamp sound]] - Fix and improve the sound system. IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo?rev=1197730930 New Revision: http://wiki.metalforge.net/doku.php/dev_todo -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 20:17:19 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 20:17:19 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:cf2.0:roadmap Message-ID: <1201141039.448412.8369.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 20:17 User : leaf Edit Summary: Removing this page as the content has been moved to dev_todo @@ -1,14 +1,2 @@ - ====== CF2 Roadmap ====== - On the //Crossfire Discussion Mailing List// was talked about the following topics: - - * [[dev_todo:cf2.0:races]] - * [[dev_todo:cf2.0:classes]] - * [[dev_todo:cf2.0:skills]] - * [[dev_todo:cf2.0:guilds]] - * [[dev_todo:cf2.0:combat]] - * [[dev_todo:cf2.0:magic]] - * [[dev_todo:cf2.0:party]] - * [[dev_todo:cf2.0:world]] - * [[dev_todo:cf2.0:alchemy]] IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:cf2.0:roadmap?rev=1187294793 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:cf2.0:roadmap -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 20:22:07 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 20:22:07 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:cf2.0:roadmap Message-ID: <1201141327.761327.8378.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 20:22 User : leaf Edit Summary: removed @@ -1,2 +1 @@ - IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:cf2.0:roadmap?rev=1201141037 New Revision: http://wiki.metalforge.net/doku.php/dev_todo:cf2.0:roadmap -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 20:29:50 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 20:29:50 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: client_side_scripting:scripts:python Message-ID: <1201141790.202988.8387.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 20:29 User : leaf Edit Summary: Adding author credits (and link to formerly orphaned page) @@ -1,6 +1,6 @@ ==== Python Scripts ==== The scripts on this page or linked to from this page are working scripts that players have actually used. Feel free to contribute your own Python script(s) here. If you do not have wiki edit access then send your script to (poof at eracc dot com) for consideration. === The Scripts === * [[:book.py]] - A script that inscribes a book from a text file. (must have the "inscription" skill, along with something to write on) - * [[:user:eadmund:scripts:crossfire.py]] - A library of convenient functions for writing client scripts in Python (a rip-off of [[:user:mhoram:scripts:subs.pl]]) - * [[:user:eadmund:scripts:altar-pray]] - A port of [[user:mhoram:scripts:altar_pray]] to Python + * [[:user:eadmund:scripts:crossfire.py]] - A library of convenient functions for writing client scripts in Python (a rip-off of [[:user:mhoram:scripts:subs.pl]]) contributed by [[user:eadmund|Eadmund]] + * [[:user:eadmund:scripts:altar-pray]] - A port of [[user:mhoram:scripts:altar_pray]] to Python by [[user:eadmund|Eadmund]] IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/client_side_scripting:scripts:python?rev=1188061091 New Revision: http://wiki.metalforge.net/doku.php/client_side_scripting:scripts:python -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 23 20:47:26 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 23 Jan 2008 20:47:26 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: lore Message-ID: <1201142846.136287.8423.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/23 20:47 User : leaf Edit Summary: Link to scratch page for listing NPC and similar names found in game that are missing background or reference @@ -1,8 +1,9 @@ ===== Lore ===== * Names for the [[Bigworld]] * [[backstory development]] - whenever someone posts a story on IRC (or elsewhere), it should go here to be later combined with the rest of the lore + * [[story_people|Famous Names]] - NPC and similar names found while playing that are missing a background or reference == These are legends told by the inhabitants of Bigworld == * The [[Legend Of Creation]] (legend of creation according to Gaean priests) IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/lore?rev=1170880360 New Revision: http://wiki.metalforge.net/doku.php/lore -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Fri Jan 25 01:44:24 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Fri, 25 Jan 2008 01:44:24 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page added: osx Message-ID: <1201247064.048833.11651.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/25 01:44 User : buzzsaw Edit Summary: created Ok there are a few ways to get the crossfire client to work on OSX. Fink is a good friend of mine :-) http://www.finkproject.org/ Fink is working on bringing opensource to Darwin/OSX. There is a version of the the cfclient on fink but it is version 1.7 which does not have the bells and whistles that are included in 1.10 besides why run 1.7 when you can just run 1.10. Your going to have to compile 1.10 from source until some one (don't know who) updates the fink database. Go to your local neighborhood crossfire-client download site and grab 1.10. Just about all of your errors from ./configure can be fixed by installing the fink packages for them, not including the libpng. I tried and tried (so did leaf) but we cant get the ./configure to recognize the libpng from fink so you have to compile libpng from source too. Go to http://www.libpng.org/pub/png/libpng.html and grab the SOURCE CODE (I used the one with the configure script) and compile it. After installing the libpng crossfire-client can be compiled and run. IP-Address : 69.92.59.77 Old Revision: none New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 11:52:19 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 11:52:19 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: crossfire_compile_guide Message-ID: <1201542739.567496.2947.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 11:52 User : lauwenmark Edit Summary: updated the reference to the autoconf package @@ -43,9 +43,9 @@ * libsvn-dev - Development files for Subversion libraries (required for Subversion revision number reporting in metaserver2) As a quick reference: - sudo apt-get install check autoconf2.5 libsqlite3-0 libcurl3 libcurl3-dev libsvn-dev + sudo apt-get install check autoconf libsqlite3-0 libcurl3 libcurl3-dev libsvn-dev Installing Python and which version is still under investigation/discussion * lib64python2.4-2.4.3 is known to work on Mandriva 2007.0 x86_64 IP-Address : 80.201.226.125 Old Revision: http://wiki.metalforge.net/doku.php/crossfire_compile_guide?rev=1200347830 New Revision: http://wiki.metalforge.net/doku.php/crossfire_compile_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 12:29:18 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 12:29:18 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: crossfire_compile_guide Message-ID: <1201544958.203052.3123.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 12:29 User : Edit Summary: @@ -177,8 +177,9 @@ $ sh autogen.sh && make && sudo make install autogen.sh script re-creates the configure (./configure) script while the rest of the command starts the compile (build) process. Pass the same options to autogen.sh as you would normally pass to ./configure since autogen.sh calls ./configure. This command requires both autoconf and automake to be installed. + ==== LAUNCH ==== Once the server has been successfully built (aka compiled), you need to launch the Crossfire Server application @@ -202,9 +203,9 @@ $ ./crossfire-server & What that command will do is run the Crossfire server and return you back to bash or shell prompt - FIXME -- How to use crossloop for running the server; crossloop is a script that automatically restarts the server if/when it crashes and can also provide useful debugging or error information from the crash event + FIXME -- How to use crossloop for running the server; crossloop is a script that automatically restarts the server if/when it crashes and can also provide useful debugging or error information from the crash event. ===== Microsoft (c) Windows ===== The following tools are used to compile the server: * Microsoft Visual Studio 6 (service pack 4 probably). Server has not been tested with other versions. IP-Address : 12.76.150.119 Old Revision: http://wiki.metalforge.net/doku.php/crossfire_compile_guide?rev=1201542736 New Revision: http://wiki.metalforge.net/doku.php/crossfire_compile_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 18:45:42 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 18:45:42 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201567542.405517.5461.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 18:45 User : Edit Summary: Update page formatting @@ -1,10 +1,22 @@ + ====== Crossfire on MacOS X ====== + + ===== Client ===== + + ==== Installation ==== + + There are two ways to install the Crossfire clients, one is Fink which is a project that ports Unix software to Mac OS X. The other option is to compile Crossfire via source code. + + === Fink === + Ok there are a few ways to get the crossfire client to work on OSX. Fink is a good friend of mine :-) http://www.finkproject.org/ Fink is working on bringing opensource to Darwin/OSX. There is a version of the the cfclient on fink but it is version 1.7 which does not have the bells and whistles that are included in 1.10 besides why run 1.7 when you can just run 1.10. + + === Compile via Source Code === Your going to have to compile 1.10 from source until some one (don't know who) updates the fink database. Go to your local neighborhood crossfire-client download site and grab 1.10. @@ -16,4 +28,7 @@ Go to http://www.libpng.org/pub/png/libpng.html and grab the SOURCE CODE (I used the one with the configure script) and compile it. After installing the libpng crossfire-client can be compiled and run. + ===== Server ===== + + Server installation or build is currently being tested and under development. IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201247061 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 19:23:26 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 19:23:26 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201569806.461385.5637.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 19:23 User : leaf Edit Summary: More info on MacOS X Client installation @@ -1,5 +1,7 @@ ====== Crossfire on MacOS X ====== + + FIXME -- Instructions are still under development, use with caution ===== Client ===== ==== Installation ==== @@ -9,26 +11,51 @@ === Fink === Ok there are a few ways to get the crossfire client to work on OSX. - Fink is a good friend of mine :-) http://www.finkproject.org/ - Fink is working on bringing opensource to Darwin/OSX. + * Follow the install instructions found at the Fink website, http://www.finkproject.org/download/index.php + + Quick Instructions: + + - Download the installer disk image: + - Double-click the .dmg to mount the disk image + - Double-click the "Fink Installer.pkg" package inside. Follow the instructions on screen. + - Open a new Terminal.app window and run the following: **fink scanpackages; fink index** + - Once that is finished, install any updates available for Fink. In the same Terminal.app window enter the following: **sudo apt-get update ; sudo apt-get install fink** + - Another option for updating: **fink selfupdate;fink update-all** + + + Note: Leopard Users will need to compile from source as there is binary release available There is a version of the the cfclient on fink but it is version 1.7 which does not have the bells and whistles that are included in 1.10 besides why run 1.7 when you can just run 1.10. === Compile via Source Code === - Your going to have to compile 1.10 from source until some one (don't know who) updates the fink database. + Compiling from source code requires some additional files to be downloaded. - Go to your local neighborhood crossfire-client download site and grab 1.10. + - You should have Subversion installed by default. You can check with this command in a Terminal.app window: ** svn --help** + - Run Subversion to download the latest snapshot of the client source code. + - For trunk: **svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/client/trunk client.svn** + - For branch/1.x: **svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/client/branches/1.x client.svn** + - For 1.10.0 release: **svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/client/tags/1.10.0 client.svn** + - You will need //libpng// to compile the client + - Download [[http://ethan.tira-thompson.com/Mac OS X Ports_files/libpng (universal).dmg]] the libpng individual installer + - Double click the .dmg package and follow the on screen prompts and instructions + - Change directories to **client.svn** and run the following commands: + - **./configure** + - Just about all of your errors from ./configure can be fixed by installing the fink packages for them, not including the libpng. - Just about all of your errors from ./configure can be fixed by installing the fink packages for them, not including the libpng. + == GTKv1 Client == - I tried and tried (so did leaf) but we cant get the ./configure to recognize the libpng from fink so you have to compile libpng from source too. + - Change directories to the gtk directory + - Make sure you are in the correct directory by using the **pwd** command - it should be: **/Users/<user_name>/client.svn/gtk** + - Run this command: **./crossfire-client-gtk &** - Go to http://www.libpng.org/pub/png/libpng.html and grab the SOURCE CODE (I used the one with the configure script) and compile it. + == GTKv2 Client == - After installing the libpng crossfire-client can be compiled and run. + - Change directories to the gtk directory + - Make sure you are in the correct directory by using the **pwd** command - it should be: **/Users/<user_name>/client.svn/gtk-v2/src** + - Run this command: **./crossfire-client-gtk2 &** ===== Server ===== Server installation or build is currently being tested and under development. IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201567540 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 19:34:33 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 19:34:33 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201570473.270861.5652.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 19:34 User : leaf Edit Summary: More information for the experimental .dmg file @@ -26,8 +26,26 @@ Note: Leopard Users will need to compile from source as there is binary release available There is a version of the the cfclient on fink but it is version 1.7 which does not have the bells and whistles that are included in 1.10 besides why run 1.7 when you can just run 1.10. + + === Experimental Package === + + Once the client has been successfully installed, there is a .dmg file available for download that will let you run any of the three clients (crossfire-client-x11, crossfire-client-gtk and crossfire-client-gtk2) + + * Download Mirror: http://crossfire.real-time.com/download/macosx/crossfire-client1.10.dmg + + Installation instructions: + + - Wait for the file to download and follow the screen prompts + - Accept the prompts about installing the package + - In a new window, click on the client you wish to run + - For crossfire-client-x11 client: cfclient + - For crossfire-client-gtk: gcfclient + - For crossfire-client-gtk2: gcfclient2 + + Note: With the GTKv2 client, after first launching click on the green "+" which will then let you resize the client window + === Compile via Source Code === Compiling from source code requires some additional files to be downloaded. IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201569803 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 20:33:41 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 20:33:41 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201574021.375320.5944.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 20:33 User : leaf Edit Summary: Full list of gclient2 dependencies @@ -76,4 +76,41 @@ ===== Server ===== Server installation or build is currently being tested and under development. + + ===== Dependencies ===== + + Full list of gclient2 dependencies: + + $ otool -L /usr/local/bin/gcfclient2 + /usr/local/bin/gcfclient2: + /sw/lib/libgtk-x11-2.0.0.dylib (compatibility version 601.0.0, current version 601.10.0) + /sw/lib/libgdk-x11-2.0.0.dylib (compatibility version 601.0.0, current version 601.10.0) + /usr/X11/lib/libXrandr.2.dylib (compatibility version 3.0.0, current version 3.0.0) + /usr/X11/lib/libXinerama.1.dylib (compatibility version 2.0.0, current version 2.0.0) + /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0) + /usr/X11/lib/libXfixes.3.dylib (compatibility version 5.0.0, current version 5.0.0) + /usr/X11/lib/libXcursor.1.dylib (compatibility version 2.0.0, current version 2.2.0) + /sw/lib/libatk-1.0.0.dylib (compatibility version 1215.0.0, current version 1215.0.0) + /sw/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 601.0.0, current version 601.10.0) + /sw/lib/libpangoxft-1.0.0.dylib (compatibility version 1002.0.0, current version 1002.0.0) + /usr/X11/lib/libXft.2.dylib (compatibility version 4.0.0, current version 4.2.0) + /usr/X11/lib/libXrender.1.dylib (compatibility version 5.0.0, current version 5.0.0) + /sw/lib/libpangox-1.0.0.dylib (compatibility version 1002.0.0, current version 1002.0.0) + /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0) + /sw/lib/libpangoft2-1.0.0.dylib (compatibility version 1002.0.0, current version 1002.0.0) + /usr/X11/lib/libfontconfig.1.dylib (compatibility version 3.0.0, current version 3.0.0) + /usr/X11/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.16.0) + /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) + /sw/lib/libpango-1.0.0.dylib (compatibility version 1002.0.0, current version 1002.0.0) + /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) + /sw/lib/libgobject-2.0.0.dylib (compatibility version 1201.0.0, current version 1201.12.0) + /sw/lib/libgmodule-2.0.0.dylib (compatibility version 1201.0.0, current version 1201.12.0) + /sw/lib/libglib-2.0.0.dylib (compatibility version 1201.0.0, current version 1201.12.0) + /sw/lib/libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) + /sw/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) + /sw/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.2.0) + /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0) + /sw/lib/libSDL_image-1.2.0.dylib (compatibility version 2.0.0, current version 2.5.0) + /sw/lib/libpng12.0.dylib (compatibility version 19.0.0, current version 19.0.0) + /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201570471 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 20:50:07 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 20:50:07 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201575007.647698.5980.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 20:50 User : leaf Edit Summary: Instructions are specific for Intel Macs (untested on PPC) @@ -1,5 +1,5 @@ - ====== Crossfire on MacOS X ====== + ====== Crossfire on MacOS X - Intel ====== FIXME -- Instructions are still under development, use with caution ===== Client ===== IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201574018 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 20:57:56 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 20:57:56 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201575476.129519.5989.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 20:57 User : buzzsaw Edit Summary: added note about 10.5 @@ -42,9 +42,11 @@ - For crossfire-client-x11 client: cfclient - For crossfire-client-gtk: gcfclient - For crossfire-client-gtk2: gcfclient2 - Note: With the GTKv2 client, after first launching click on the green "+" which will then let you resize the client window + Note: With the GTKv2 client, after first launching click on the green "+" which will then let you resize the client window. + + Note: The binary files where compiled on Os X 10.5, I don't know as of now if they will work on latter versions. === Compile via Source Code === IP-Address : 207.225.37.112 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201575005 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 21:07:16 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 21:07:16 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201576036.421915.6123.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 21:07 User : leaf Edit Summary: Corrected URL for the 1.10 svn download @@ -55,9 +55,9 @@ - You should have Subversion installed by default. You can check with this command in a Terminal.app window: ** svn --help** - Run Subversion to download the latest snapshot of the client source code. - For trunk: **svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/client/trunk client.svn** - For branch/1.x: **svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/client/branches/1.x client.svn** - - For 1.10.0 release: **svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/client/tags/1.10.0 client.svn** + - For 1.10.0 release: **svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/client/tags/1.10/ client.svn** - You will need //libpng// to compile the client - Download [[http://ethan.tira-thompson.com/Mac OS X Ports_files/libpng (universal).dmg]] the libpng individual installer - Double click the .dmg package and follow the on screen prompts and instructions - Change directories to **client.svn** and run the following commands: IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201575473 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 21:10:25 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 21:10:25 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201576225.344791.6141.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 21:10 User : buzzsaw Edit Summary: @@ -2,8 +2,9 @@ FIXME -- Instructions are still under development, use with caution ===== Client ===== + ==== Installation ==== There are two ways to install the Crossfire clients, one is Fink which is a project that ports Unix software to Mac OS X. The other option is to compile Crossfire via source code. @@ -32,8 +33,9 @@ Once the client has been successfully installed, there is a .dmg file available for download that will let you run any of the three clients (crossfire-client-x11, crossfire-client-gtk and crossfire-client-gtk2) * Download Mirror: http://crossfire.real-time.com/download/macosx/crossfire-client1.10.dmg + * Download Mirror: http://crossfire.ailesse.com/downloads/osx/crossfire-client1.10.dmg Installation instructions: - Wait for the file to download and follow the screen prompts IP-Address : 207.225.37.112 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201576034 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 21:12:34 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 21:12:34 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201576354.131369.6144.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 21:12 User : buzzsaw Edit Summary: @@ -2,8 +2,9 @@ FIXME -- Instructions are still under development, use with caution ===== Client ===== + ==== Installation ==== @@ -46,9 +47,9 @@ - For crossfire-client-gtk2: gcfclient2 Note: With the GTKv2 client, after first launching click on the green "+" which will then let you resize the client window. - Note: The binary files where compiled on Os X 10.5, I don't know as of now if they will work on latter versions. + Note: The binary files where compiled on Os X 10.5, I don't know as of now if they will work on past versions. === Compile via Source Code === IP-Address : 207.225.37.112 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201576222 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 21:16:10 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 21:16:10 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user:leaf Message-ID: <1201576570.289755.6153.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 21:16 User : leaf Edit Summary: Update roles with Metalforge server @@ -14,10 +14,12 @@ * Wiki * One of the wiki Admins and server host * Webforum * Webmaster, one of the forum Admins and server host - * Server crossfire.metalforge.net - * One of the server DMs and server host, map updates (only..) + * Server crossfire.metalforge.net (aka Metalforge) + * One of the server DMs and server host + * Server admin + * One of the map, archetype and server update managers * Admin and host for server bots Scribe and Seer * Websites * crossfire.real-time.com -- Webmaster and server host * www.metalforge.net -- Webmaster and server host IP-Address : 65.193.16.100 Old Revision: http://wiki.metalforge.net/doku.php/user:leaf?rev=1199413392 New Revision: http://wiki.metalforge.net/doku.php/user:leaf -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Mon Jan 28 21:20:03 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Mon, 28 Jan 2008 21:20:03 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user:buzzsaw Message-ID: <1201576803.370339.6159.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/28 21:20 User : buzzsaw Edit Summary: @@ -3,5 +3,7 @@ I relay don't have skills other that stumbling across dumb stuff. + + Working with making CF work on OS X :-) Nothing fancy yet but got cfclient, gcfclient, gcfclient2 to compile and providing binary's for it. Working on testing on other versions of OS X. Ok here we go I am creating a todo list for myself: 1 Create ideas for basic sounds * Skills: Find traps, disarm traps, jeweler, lock picking, oratary, evocation, karate, praying, inscription, x handed weapons IP-Address : 207.225.37.112 Old Revision: http://wiki.metalforge.net/doku.php/user:buzzsaw?rev=1198633675 New Revision: http://wiki.metalforge.net/doku.php/user:buzzsaw -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 03:59:38 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 03:59:38 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201600778.309801.4933.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 03:59 User : buzzsaw Edit Summary: @@ -77,12 +77,131 @@ - Change directories to the gtk directory - Make sure you are in the correct directory by using the **pwd** command - it should be: **/Users/<user_name>/client.svn/gtk-v2/src** - Run this command: **./crossfire-client-gtk2 &** + ===== Server ===== + + Please note. This is very experimental and not even hardly tested at all but I will post what we had to do so that other can play with :-) + + Please note the dep files needed from http://wiki.metalforge.net/doku.php/crossfire_compile_guide?s=server Server installation or build is currently being tested and under development. + + I was able to build a trunk server on 01/29/2008 doing the following: + + ==== Start Here==== + + $ pwd + /Users/<username> + + ==== Download ==== + + + + === Trunk === + + $ svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/server/trunk server.svn + $ svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/maps/trunk maps.svn + $ svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/arch/trunk arch.svn + + ==== SETUP ==== + + This confirms that you are still in your home directory + + $ pwd + /Users/<username> + + Now change directory (hence the cd) to the directory that contains the server files + + $ cd server.svn + + This confirms that you are in the server directory + + $ pwd + /Users/<username>/server.svn + + This step "links" two directories to each other which makes the compile process more automated + + $ sudo ln -s /Users/<username>/maps.svn maps + + This step "links" two directories to each other which makes the compile process more automated and is used by the server once Crossfire server is up and running. This links the server to the map files which you downloaded earlier. + + First, create the necessary directory tree for the map files with this command: + + $ sudo mkdir /usr/games/crossfire;sudo mkdir /usr/games/crossfire/share; sudo mkdir /usr/games/crossfire/share/crossfire + + What that does, is it creates a directory located here: /usr/games/crossfire/share/crossfire + + Now this step "links" two directories to each other which makes the compile process more automated + + $ sudo ln -s /Users/<username>/maps.svn /usr/games/crossfire/share/crossfire/maps + + Now change directory (hence the cd) to the directory that contains the library files + + $ cd lib + + Double check that you are in the correct directory + + $ pwd + /Users/<username>/server.svn/lib + + This step "links" two directories to each other which makes the compile process more automated. This links the arch or archetype files to the server files which you downloaded earlier. + + $ ln -s /Users/<username>/arch.svn ./arch + + Go back another directory + + $ cd .. + + Double check that you are in the correct directory which is the server directory + + $ pwd + /Users/<username>/server.svn + + ==== Compile ==== + + This section may be easy but it also may not be easy. NOTE: This process has only been tested on one computer and the server stability HAS NOT BEEN TESTED. + + First off we need to build our configure script. From /Users/<username>/server.svn + + $ automake + $ ./configure --enable-static --disable-shared CFLAGS=-ste=c99 --disable-check + + Note you may have a problem with echo so to avoid the problem lets go ahead and make a change to include/Makefile.am + + with svnversion.h change so that the echo looks like /bin.echo + + svnversion.h: FORCE + OUTPUT_DATA='/* Auto-generated at build time. */'; \ + if test -n "$(SVNVERSION)" -a -d .svn; then \ + OUTPUT_DATA=`echo "$$OUTPUT_DATA"; /bin/echo -n '#define SVN_REV "'; $(SVNVERSION) -n`'"'; \ + fi; \ + if test ! -e svnversion.h; then \ + /bin/echo "$$OUTPUT_DATA" > svnversion.h; \ + elif test "$$OUTPUT_DATA" != "`cat svnversion.h`"; then \ + /bin/echo "$$OUTPUT_DATA" > svnversion.h; \ + fi + + + Now we will run the rest + + $ make + $ make install + + ---- + + There are a few depends for the server to run + + $ otool -L /Users/anthonyswyatt/server.svn/server/crossfire-server + /Users/anthonyswyatt/server.svn/server/crossfire-server: + /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) + /sw/lib/libcurl.3.dylib (compatibility version 4.0.0, current version 4.0.0) + /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) + /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) + /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) + /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) ===== Dependencies ===== Full list of gclient2 dependencies: IP-Address : 69.92.59.77 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201576352 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 07:38:00 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 07:38:00 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user:buzzsaw Message-ID: <1201613880.360826.6760.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 07:37 User : kbulgrien Edit Summary: Link OSX page from references to it here. @@ -1,9 +1,9 @@ Um I am buzzsaw the only thing that I have realy contributed thus far would be the cool looking books for the spells. I plan on creating music and such. I relay don't have skills other that stumbling across dumb stuff. - Working with making CF work on OS X :-) Nothing fancy yet but got cfclient, gcfclient, gcfclient2 to compile and providing binary's for it. Working on testing on other versions of OS X. + Working with making CF work on [[:OSX |OS X]] :-) Nothing fancy yet but got cfclient, gcfclient, gcfclient2 to compile and providing binary's for it. Working on testing on other versions of [[:OSX|OS X]]. Ok here we go I am creating a todo list for myself: 1 Create ideas for basic sounds * Skills: Find traps, disarm traps, jeweler, lock picking, oratary, evocation, karate, praying, inscription, x handed weapons IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/user:buzzsaw?rev=1201576800 New Revision: http://wiki.metalforge.net/doku.php/user:buzzsaw -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 07:47:25 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 07:47:25 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201614445.746560.6784.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 07:47 User : kbulgrien Edit Summary: Makefile.am edit before automake @@ -162,16 +162,9 @@ ==== Compile ==== This section may be easy but it also may not be easy. NOTE: This process has only been tested on one computer and the server stability HAS NOT BEEN TESTED. - First off we need to build our configure script. From /Users/<username>/server.svn - - $ automake - $ ./configure --enable-static --disable-shared CFLAGS=-ste=c99 --disable-check - - Note you may have a problem with echo so to avoid the problem lets go ahead and make a change to include/Makefile.am - - with svnversion.h change so that the echo looks like /bin.echo + Note you may have a problem with echo so to avoid the problem lets go ahead and make a change to include/Makefile.am for svnversion.h so that the echo looks like /bin.echo svnversion.h: FORCE OUTPUT_DATA='/* Auto-generated at build time. */'; \ if test -n "$(SVNVERSION)" -a -d .svn; then \ @@ -182,8 +175,12 @@ elif test "$$OUTPUT_DATA" != "`cat svnversion.h`"; then \ /bin/echo "$$OUTPUT_DATA" > svnversion.h; \ fi + Next, build the configure script. From /Users/<username>/server.svn + + $ automake + $ ./configure --enable-static --disable-shared CFLAGS=-ste=c99 --disable-check Now we will run the rest $ make IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201600773 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 12:13:12 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 12:13:12 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201630392.995032.8726.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 12:13 User : buzzsaw Edit Summary: Fixing Typos @@ -157,14 +157,15 @@ Double check that you are in the correct directory which is the server directory $ pwd /Users/<username>/server.svn + ==== Compile ==== This section may be easy but it also may not be easy. NOTE: This process has only been tested on one computer and the server stability HAS NOT BEEN TESTED. - Note you may have a problem with echo so to avoid the problem lets go ahead and make a change to include/Makefile.am for svnversion.h so that the echo looks like /bin.echo + Note you may have a problem with echo so to avoid the problem lets go ahead and make a change to include/Makefile.am for svnversion.h so that the echo looks like /bin/echo svnversion.h: FORCE OUTPUT_DATA='/* Auto-generated at build time. */'; \ if test -n "$(SVNVERSION)" -a -d .svn; then \ IP-Address : 69.92.59.77 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201614442 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 16:06:52 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 16:06:52 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201644412.557526.10483.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 16:06 User : kbulgrien Edit Summary: The include/Makefile.am edit is no longer necessary. @@ -163,22 +163,9 @@ ==== Compile ==== This section may be easy but it also may not be easy. NOTE: This process has only been tested on one computer and the server stability HAS NOT BEEN TESTED. - Note you may have a problem with echo so to avoid the problem lets go ahead and make a change to include/Makefile.am for svnversion.h so that the echo looks like /bin/echo - - svnversion.h: FORCE - OUTPUT_DATA='/* Auto-generated at build time. */'; \ - if test -n "$(SVNVERSION)" -a -d .svn; then \ - OUTPUT_DATA=`echo "$$OUTPUT_DATA"; /bin/echo -n '#define SVN_REV "'; $(SVNVERSION) -n`'"'; \ - fi; \ - if test ! -e svnversion.h; then \ - /bin/echo "$$OUTPUT_DATA" > svnversion.h; \ - elif test "$$OUTPUT_DATA" != "`cat svnversion.h`"; then \ - /bin/echo "$$OUTPUT_DATA" > svnversion.h; \ - fi - - Next, build the configure script. From /Users/<username>/server.svn + First, build the configure script. From /Users/<username>/server.svn $ automake $ ./configure --enable-static --disable-shared CFLAGS=-ste=c99 --disable-check IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201630390 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 16:29:35 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 16:29:35 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user:kbulgrien Message-ID: <1201645776.014991.10522.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 16:29 User : kbulgrien Edit Summary: Add some portability references. @@ -6,4 +6,10 @@ * Long-time player, patcher, documenter, coder... * Non-prolific contributor with primarily low-profile changes, but a long-standing fan and contributor... + ======Portability WIP====== + + * Portable Shell Programming + * [[http://www.gnu.org/software/automake/manual/autoconf/Portable-Shell.html#Portable-Shell|Automake Manual]] + * Various topics, good workaround for echo -n @ [[http://www.in-ulm.de/~mascheck/various/|#! aribtrary unix stuff]] + * [[http://www.linux.com/articles/34658|What to watch out for when writing portable shell scripts]] IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/user:kbulgrien?rev=1197740171 New Revision: http://wiki.metalforge.net/doku.php/user:kbulgrien -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 16:37:29 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 16:37:29 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user:kbulgrien Message-ID: <1201646249.369798.10539.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 16:37 User : kbulgrien Edit Summary: Better outline for portability stuff; add automake manual link. @@ -6,10 +6,17 @@ * Long-time player, patcher, documenter, coder... * Non-prolific contributor with primarily low-profile changes, but a long-standing fan and contributor... - ======Portability WIP====== + ======Build Resources====== + * [[http://www.gnu.org/software/automake/manual/autoconf/index.html#Top Automake Manual]] + =====Portability===== - * Portable Shell Programming - * [[http://www.gnu.org/software/automake/manual/autoconf/Portable-Shell.html#Portable-Shell|Automake Manual]] + ====Shell Programming==== + * [[http://www.gnu.org/software/automake/manual/autoconf/Portable-Shell.html#Portable-Shell|Automake Manual Chapter]] * Various topics, good workaround for echo -n @ [[http://www.in-ulm.de/~mascheck/various/|#! aribtrary unix stuff]] * [[http://www.linux.com/articles/34658|What to watch out for when writing portable shell scripts]] + ====make==== + * [[http://www.gnu.org/software/automake/manual/autoconf/Portable-Make.html#Portable-Make|Automake Manual Chapter]] + ====Portable C/C++==== + * [[http://www.gnu.org/software/automake/manual/autoconf/Portable-C-and-C_002b_002b.html#Portable-C-and-C_002b_002b|Automake Manual Chapter]] + IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/user:kbulgrien?rev=1201645772 New Revision: http://wiki.metalforge.net/doku.php/user:kbulgrien -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 16:40:20 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 16:40:20 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: user:kbulgrien Message-ID: <1201646420.779333.10557.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 16:40 User : kbulgrien Edit Summary: Add to introduction. @@ -5,8 +5,11 @@ ======Introduction====== * Long-time player, patcher, documenter, coder... * Non-prolific contributor with primarily low-profile changes, but a long-standing fan and contributor... + * Notable contributions + * GTK V2 client retrofit for libglade, plus numerous alternate main window layouts. + * Doxygen markup for the client code base. ======Build Resources====== * [[http://www.gnu.org/software/automake/manual/autoconf/index.html#Top Automake Manual]] =====Portability===== IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/user:kbulgrien?rev=1201646246 New Revision: http://wiki.metalforge.net/doku.php/user:kbulgrien -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 18:40:22 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 18:40:22 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: fire_hatchling Message-ID: <1201653622.542821.11057.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 18:40 User : kbulgrien Edit Summary: Typo fix. @@ -82,9 +82,9 @@ When going against creatures that are not immune to physical attack or are not vulnerable to one of your claw attack types, then use the skill Karate. You will attack quicker and have more damage. When eating flesh, if it doesn't list a resistance it will have no taste, if it doesn't list food+(some amount) then it is poisonous. - Any god can be used when using the Dragon race. I like [[gods:Gaea]], [[gods:Ruggeli]], and strange but true, good ol [[gods:Mostrai]] (Holy word kills titans without destroying their flesh) + Any god can be used when using the Dragon race. I like [[gods:Gaea]], [[gods:Ruggilli]], and strange but true, good ol [[gods:Mostrai]] (Holy word kills titans without destroying their flesh) Face of death is the best spell to have as it also kills creatures without destroying flesh, unfortunately it is denied by Gaea. At high resistance levels I have found that the chaos lair, wizards tower (Dragon man Red/White/Blue/Highlord), warrior proving grounds (chaos pit), Butakis prison (underground), Butakis royal church (underground), and The Ice/Electric/Fire Antechambers in the wyvern's nest are the best places for food. IP-Address : 70.254.39.97 Old Revision: http://wiki.metalforge.net/doku.php/fire_hatchling?rev=1166808154 New Revision: http://wiki.metalforge.net/doku.php/fire_hatchling -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Tue Jan 29 23:39:51 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Tue, 29 Jan 2008 23:39:51 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: gridarta Message-ID: <1201671591.174847.12192.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/29 23:39 User : leaf Edit Summary: New content and updates - troubleshooting and other info @@ -33,13 +33,93 @@ ant ==== Running Gridarta ==== + Gridarta can be run or launched through the following methods: + + === CLI (Command Line Interface) === For Gridarata4Crossfire run: java -jar CrossfireEditor.jar or for Gridarta4Daimonin run: java -jar DaimoninEditor.jar Also, it is possible java may not allocated enough memory defaultly, in which case use "//-Xmx128M//" or similar in the parameters to Java. For larger machines, explicitely requesting a client type VM can significantly speedup gridarta, so consider using "//-client//". + + === GUI (Graphical User Interface) === + + Double click on the .jar file - this is the case for Windows based systems and also applies for MacOS X. + + ===== Special Instructions & Troubleshooting ===== + + ==== JRE Update ==== + + === *nix Based === + + If you recently upgraded your Java JRE or having problems launching the editor, or would like to specify a particular version of Java, run this command: + + $ update-alternatives --config java + + Follow the instructions that appear: + NOTE: actual output, contents and options will vary, you'll want to use: /usr/lib/j2re1.5-sun/bin/java + + <code> + There are 6 alternatives which provide `java'. + + Selection Alternative + ----------------------------------------------- + 1 /usr/lib/j2re1.4-sun/bin/java + * 2 /usr/lib/jvm/java-1.5.0-sun/jre/bin/java + 3 /usr/bin/gij-wrapper-4.0 + + 4 /usr/lib/jvm/java-gcj/jre/bin/java + 5 /usr/bin/gij-wrapper-4.1 + 6 /usr/lib/j2re1.5-sun/bin/java + Press enter to keep the default[*], or type selection number: 6 + Using `/usr/lib/j2re1.5-sun/bin/java' to provide `java'. + </code> + + Then try launching the editor again. + + === MacOS X Based === + + * If you want to switch between '''released''' version of java, just run the 'Java Preference.app', spotlight Java and you'll get a hit. + * If you want to run a Developer Preview (DP) release you'll need to do some tweaking. See below. + * You can get [[http://lists.apple.com/archives/java-dev/2005/Aug/msg00506.html|Fancy]] with some bash scripting + + == Developer Preview of Java == + + Apple does not want the normal user to run a DP version of java, so the pretty GUI and neat way of switching releases is disabled. Apple's official mechanism is to use full path to the release of java you want to run. + + * Command line example to run 1.6 + + $ /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Commands/java -version + + This should display something like the following: + <code> + java version "1.6.0_01-dp" + Java(TM) SE Runtime Environment (build 1.6.0_01-dp-b06-101) + Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_01-41-release, mixed mode) + </code> + + * Make 1.6 your "default" for the command line + <code> + $ vi ~/.bash_profile + PATH="/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Commands:${PATH}" + export PATH + </code> + + FIXME-- * Make 1.6 your "default" for the GUI '''UNTESTED''' + - Open the Finder and navigate to a .class and/or .jar file + - Right click on the file and select 'Get Info' + - Expand the 'Open With:' option + - Change 'Jar Launcher (default)' to your preferred version of java + - Be bold and click 'Change All...' + + === Blank Editor Screen === + + Enter the following command in the same terminal or shell window and then try running the client: + + $ export AWT_TOOLKIT=MToolkit + + ===== Links ===== * http://gridarta.sourceforge.net/ Gridarta Website IP-Address : 216.243.156.5 Old Revision: http://wiki.metalforge.net/doku.php/gridarta?rev=1170263301 New Revision: http://wiki.metalforge.net/doku.php/gridarta -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 30 17:02:10 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 30 Jan 2008 17:02:10 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: servers Message-ID: <1201734130.710847.16260.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/30 17:02 User : Edit Summary: @@ -1,15 +1,16 @@ ====== Crossfire Servers ====== //This information may or may not be accurate.// This section will hopefully contain a useful collection of information about running and historical crossfire servers. Please keep this limited to public servers, or private ones which have been historically significant. + ===== Presently Running Crossfire Servers ===== ^ Server ^ Address ^ Version ^ Mapset ^ Lifespan ^ Description ^ | [[servers:MetalForge]]| crossfire.metalforge.net | 1.10.0 | bigworld(official)((Sometimes maps are included for testing before in SVN)) | 2003-May-12 to current | Currently has the most actual players, enforced rules. Around late August 2006, ~6-19 players online at a time. | | Zeus | zeus.fh-brandenburg.de | 1.9.0 | bigworld | unknown to current | Rarely active. | | Kobold | crossfire.kobold.org | 1.9.1 | bigworld | unknown to current | Rarely active. | - | Netarbeiter | crossfire.netarbeiter.com | 1.9.1 | bigworld | unknown to current | Rarely active. | + | Netarbeiter | crossfire.netarbeiter.com | 1.9.1 | bigworld | January 2003 to current | Rarely active. | | Bratwurst| bratwurst.unix-ag.uni-kl.de | 1.8.0 | bigworld | unknown to current | Rarely active. | | Tuxhilfe | crossfire.tuxhilfe.de | 1.9.1 | bigworld | unknown to current | Rarely active. | | Bksys | bksys.at | 1.5.0 | smallworld | unknown to current | Rarely active. | | Penbrock | penbrock.com | 1.9.1 | bigworld | unknown to current | Rarely active. | IP-Address : 12.176.155.67 Old Revision: http://wiki.metalforge.net/doku.php/servers?rev=1176003185 New Revision: http://wiki.metalforge.net/doku.php/servers -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 30 17:05:53 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 30 Jan 2008 17:05:53 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: servers Message-ID: <1201734353.761232.16269.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/30 17:05 User : Edit Summary: @@ -1,16 +1,17 @@ ====== Crossfire Servers ====== //This information may or may not be accurate.// This section will hopefully contain a useful collection of information about running and historical crossfire servers. Please keep this limited to public servers, or private ones which have been historically significant. + ===== Presently Running Crossfire Servers ===== ^ Server ^ Address ^ Version ^ Mapset ^ Lifespan ^ Description ^ | [[servers:MetalForge]]| crossfire.metalforge.net | 1.10.0 | bigworld(official)((Sometimes maps are included for testing before in SVN)) | 2003-May-12 to current | Currently has the most actual players, enforced rules. Around late August 2006, ~6-19 players online at a time. | | Zeus | zeus.fh-brandenburg.de | 1.9.0 | bigworld | unknown to current | Rarely active. | | Kobold | crossfire.kobold.org | 1.9.1 | bigworld | unknown to current | Rarely active. | - | Netarbeiter | crossfire.netarbeiter.com | 1.9.1 | bigworld | January 2003 to current | Rarely active. | + | Netarbeiter | crossfire.netarbeiter.com | 1.10.0 | bigworld | January 2003 to current | Rarely active. | | Bratwurst| bratwurst.unix-ag.uni-kl.de | 1.8.0 | bigworld | unknown to current | Rarely active. | | Tuxhilfe | crossfire.tuxhilfe.de | 1.9.1 | bigworld | unknown to current | Rarely active. | | Bksys | bksys.at | 1.5.0 | smallworld | unknown to current | Rarely active. | | Penbrock | penbrock.com | 1.9.1 | bigworld | unknown to current | Rarely active. | IP-Address : 12.176.155.67 Old Revision: http://wiki.metalforge.net/doku.php/servers?rev=1201734127 New Revision: http://wiki.metalforge.net/doku.php/servers -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Wed Jan 30 17:23:02 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Wed, 30 Jan 2008 17:23:02 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: faq Message-ID: <1201735382.404118.16302.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/30 17:23 User : Edit Summary: re-ordered list and added OpenBSD @@ -5,8 +5,9 @@ ===== Chapter 1 - Introduction ===== Crossfire is a multiplayer graphical arcade and adventure game made for the X-Windows environment. It has certain flavours from other games, especially Gauntlet (TM) and Nethack/Moria. Any number of players can move around in their own window, finding and using items and battle monsters. They can choose to cooperate or compete in the same "world." ===== Chapter 2 - Installation Questions ===== + ==== 2.1 What do I need to run Crossfire? ==== You will need UNIX, X-windows and an ANSI C compiler to compile this game. @@ -14,21 +15,22 @@ Crossfire has been known to compile on the following systems (latest known version number of Crossfire that compiled on these systems is included in parentheses): FIXME - this section needs updating + * DEC with OSF1 + * DEC 300AXP-500 (Alpha with OSF1 1.3) (0.90.3) + * DEC 3100 and DEC 5000 with ULTRIX BSD 4.2 + * HP735, HPUX, X11R5 (0.90.2) + * HP9000-series (HP-UX) (very old versions of HP-UX might barf on stdarg.h) + * IBM RS/6000 with AIX 1.2, X11R4/5 (0.91.4) + * IBM RT with BSD4.3 + * MIPS with RISC/os + * PC Compatible, with Linux (0.89.3) + * PC Compatible, with OpenBSD (4.2) * Sun3, SunOs 4.1.1, gcc (0.90.3) - * DEC300AXP-500 (Alpha with OSF1 1.3) (0.90.3) * Sun4 with SunOS 4.1.3 (0.90.2) * Ultrix 4.2a (0.90.1) - * PC Compatiable, with Linux (0.89.3) - * IBM RS/6000 with AIX 1.2, X11R4/5 (0.91.4) - * HP735, HPUX, X11R5 (0.90.2) - * DEC 3100 and DEC 5000 with ULTRIX BSD 4.2 - * DEC with OSF1 * VAX3100 with BSD 4.3 - * IBM RT with BSD4.3 - * HP9000-series (HP-UX) (very old versions of HP-UX might barf on stdarg.h) - * MIPS with RISC/os * (UMIPS) 4.52 (?) It has been compiled with X11R3, X11R4 and X11R5 (the editor requires X11R5). IP-Address : 12.176.155.67 Old Revision: http://wiki.metalforge.net/doku.php/faq?rev=1198132785 New Revision: http://wiki.metalforge.net/doku.php/faq -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 31 21:42:40 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 31 Jan 2008 21:42:40 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201837360.315813.22869.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/31 21:42 User : Edit Summary: @@ -157,8 +157,9 @@ Double check that you are in the correct directory which is the server directory $ pwd /Users/<username>/server.svn + ==== Compile ==== @@ -166,9 +167,10 @@ First, build the configure script. From /Users/<username>/server.svn $ automake - $ ./configure --enable-static --disable-shared CFLAGS=-ste=c99 --disable-check + $ chmod +x autogen.sh + $ ./autogen.sh --enable-static --disable-shared CFLAGS=-ste=c99 --disable-check Now we will run the rest $ make IP-Address : 69.92.59.77 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201644409 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 31 21:56:17 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 31 Jan 2008 21:56:17 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201838177.595202.22890.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/31 21:56 User : buzzsaw Edit Summary: moving dep list changed ./configure to ./autogen.sh @@ -157,8 +157,9 @@ Double check that you are in the correct directory which is the server directory $ pwd /Users/<username>/server.svn + ==== Compile ==== @@ -174,21 +175,8 @@ Now we will run the rest $ make $ make install - - ---- - - There are a few depends for the server to run - - $ otool -L /Users/anthonyswyatt/server.svn/server/crossfire-server - /Users/anthonyswyatt/server.svn/server/crossfire-server: - /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) - /sw/lib/libcurl.3.dylib (compatibility version 4.0.0, current version 4.0.0) - /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) - /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) - /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) - /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) ===== Dependencies ===== Full list of gclient2 dependencies: IP-Address : 69.92.59.77 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201837356 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 31 21:59:53 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 31 Jan 2008 21:59:53 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201838393.996830.22893.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/31 21:59 User : buzzsaw Edit Summary: @@ -175,10 +175,23 @@ Now we will run the rest $ make $ make install + ===== Dependencies ===== + + List of crossfire-server dependencies: + + $ otool -L /Users/<username>/server.svn/server/crossfire-server + /Users/<username>/server.svn/server/crossfire-server: + /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) + /sw/lib/libcurl.3.dylib (compatibility version 4.0.0, current version 4.0.0) + /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) + /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) + /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) + /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) + Full list of gclient2 dependencies: $ otool -L /usr/local/bin/gcfclient2 IP-Address : 69.92.59.77 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201838174 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 31 22:03:28 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 31 Jan 2008 22:03:28 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201838608.301751.23021.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/31 22:03 User : buzzsaw Edit Summary: @@ -77,19 +77,16 @@ - Change directories to the gtk directory - Make sure you are in the correct directory by using the **pwd** command - it should be: **/Users/<user_name>/client.svn/gtk-v2/src** - Run this command: **./crossfire-client-gtk2 &** + ===== Server ===== - Please note. This is very experimental and not even hardly tested at all but I will post what we had to do so that other can play with :-) - - Please note the dep files needed from http://wiki.metalforge.net/doku.php/crossfire_compile_guide?s=server - - Server installation or build is currently being tested and under development. - - I was able to build a trunk server on 01/29/2008 doing the following: + Please note. This is very experimental and not even hardly tested at all but I will post what we had to do so that other can play with :-) + + Please note the dep files needed from http://wiki.metalforge.net/doku.php/crossfire_compile_guide?s=server ==== Start Here==== $ pwd IP-Address : 69.92.59.77 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201838390 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 31 22:05:22 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 31 Jan 2008 22:05:22 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: osx Message-ID: <1201838722.715671.23030.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/31 22:05 User : buzzsaw Edit Summary: @@ -77,16 +77,15 @@ - Change directories to the gtk directory - Make sure you are in the correct directory by using the **pwd** command - it should be: **/Users/<user_name>/client.svn/gtk-v2/src** - Run this command: **./crossfire-client-gtk2 &** + ===== Server ===== - Please note. This is very experimental and not even hardly tested at all but I will post what we had to do so that other can play with :-) - - Please note the dep files needed from http://wiki.metalforge.net/doku.php/crossfire_compile_guide?s=server + Please note. The server will compile and run but stability as not been tested. Please let us know what you find out with it. ==== Start Here==== $ pwd IP-Address : 69.92.59.77 Old Revision: http://wiki.metalforge.net/doku.php/osx?rev=1201838604 New Revision: http://wiki.metalforge.net/doku.php/osx -- This mail was generated by DokuWiki at http://wiki.metalforge.net/ From no-reply_wiki at metalforge.org Thu Jan 31 22:07:28 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 31 Jan 2008 22:07:28 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: start Message-ID: <1201838848.824008.23033.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/31 22:07 User : buzzsaw Edit Summary: updated status of Mac OS X @@ -15,8 +15,9 @@ While the wiki is useful for brainstorming, archiving or listing ideas & suggestions; any and all code changes and proposals need to be sent to the [[http://mailman.metalforge.org/mailman/listinfo/crossfire|discussion mailing list]] before implementation. So, what's here?\\ There is the Crossfire Wiki, a communal edit pad and place to kick off new documents and related type content. There is the [[Document Repository|Document repository]] where you can read and comment on some of the existing documentation. Finally there's the latest [[Crossfire Traffic]] which contains information about what's happening in the community. + ==== TOC ==== * [[history_of_crossfire|The History of Crossfire]] - The history of the Crossfire world, both technical and role-playing. @@ -41,9 +42,9 @@ [[crossfire|Crossfire]] works on: * [[Linux]] * [[Windows]] * All *[[BSD]]'s - * Mac [[OSX]] (in development) + * Mac [[OSX]] (Server and clients compile, in testing) ====== 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 IP-Address : 69.92.59.77 Old Revision: http://wiki.metalforge.net/doku.php/start?rev=1201139229 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 Thu Jan 31 23:58:38 2008 From: no-reply_wiki at metalforge.org (no-reply_wiki at metalforge.org) Date: Thu, 31 Jan 2008 23:58:38 -0600 Subject: [Crossfire-wiki] [Crossfire DokuWiki] page changed: crossfire_release_guide Message-ID: <1201845518.346415.23329.nullmailer@wiki.metalforge.net> A page in your DokuWiki was added or changed. Here are the details: Date : 2008/01/31 23:58 User : Edit Summary: minor formatting fixes related to server steps. @@ -169,12 +169,14 @@ * Clean up ChangeLog - remove top of SVN line, instead just have ''Changes for 1.10.0'' be at the top. * Run configure. Options are not really important. * Since distributions include prebuilt archetypes, need to rebuild them: + cd lib ln -s ../../../../arch/tags/1.10.0 arc make collect - * Run ''make distcheck''. This will pack up the distribution and then unpack it and compile it - a pretty good complete test. + + * Run ''make distcheck'' from top level directory. This will pack up the distribution and then unpack it and compile it - a pretty good complete test. * Unpack the archive, and verify it works: gtar xvfz crossfire-1.10.0.tar.gz IP-Address : 209.204.178.229 Old Revision: http://wiki.metalforge.net/doku.php/crossfire_release_guide?rev=1174975944 New Revision: http://wiki.metalforge.net/doku.php/crossfire_release_guide -- This mail was generated by DokuWiki at http://wiki.metalforge.net/