The Final Challenge Wiki - User contributions [en]

Comment Reset

2016-08-27T00:49:56Z

Thor:

This reset does nothing except allow for extended comments.

A: This must be a <nowiki>*</nowiki>.

F: This is a line of information about the resets or area.

Some sample resets follow:

<nowiki>*</nowiki> The resets that follow put Herman into his hut, and give him his

<nowiki>*</nowiki> hammer, and shut the hut's door.

M 0 4710    1 4710

E 0 4710 999   16

D 0 4710   0    1

Comment Reset

2016-08-27T00:43:18Z

Thor:

This reset does nothing except allow for extended comments.

A: This must be a *.
F: This is a line of information about the resets or area.

Some sample resets follow:

<nowiki>
* The resets that follow put Herman into his hut, and give him his
* hammer, and shut the hut's door.
M 0 4710 1 4710
E 0 4710 999 16
D 0 4710 0 1
</nowiki>

Comment Reset

2016-08-27T00:42:04Z

Thor: Created page with "This reset does nothing except allow for extended comments. A: This must be a *. F: This is a line of information about the resets or area. Some sample resets follow: * The..."

This reset does nothing except allow for extended comments.

A: This must be a *.
F: This is a line of information about the resets or area.

Some sample resets follow:

* The resets that follow put Herman into his hut, and give him his
* hammer, and shut the hut's door.
M 0 4710 1 4710
E 0 4710 999 16
D 0 4710 0 1

Equip Reset

2011-02-13T21:42:39Z

Thor: Created page with "This reset loads an object on a mob. This reset must be preceded by a mob reset, an equip reset, or a give reset. A B C D E F A: This must be a E. B: This is a 1 or a 0. 1 ..."

This reset loads an object on a mob. This reset must be preceded by a mob reset, an equip reset, or a give reset.

A B C D E F

A: This must be a E.

B: This is a 1 or a 0. 1 signifies that the MUD should run this reset every reset cycle, a 0 signifies that the MUD should run this reset only if the area is deserted. In theory anyhow. Merc tends to ignore the setting and resets according to its own built in methods. Use the specs, though, when writing the resets - it makes them easier for me to debug.

C: This is the vnum of the object to load.

D: This is the TOTAL number of this object type allowed in THE GAME. Object type is defined as "unique object vnum" for our purposes. If this type of object totals more than or equal to the number, none will load. If there is less, one will load.

E: This is the wear location on the mob that the MUD will load the object to. The list of wear locations is in the flags list.

F: Commonly, this comment would say the object's name.

User talk:Tambalor

2011-02-13T00:25:36Z

Thor:

* Thanks for making tables of the spell numbers. I didn't know how to do that. [[User:Thor|Thor]] 17:25, 12 February 2011 (MST)
* Thanks for contributing. [[User:Tynian|Tynian]] 21:37, 20 January 2011 (MST)
* Thanks for updating the abbreviations page! [[User:Cordir|Cordir]] 11:35, 21 January 2011 (MST)
* Saw the uploaded pic. Who in the heck are those people?! :-) [[User:Tynian|Tynian]] 15:13, 22 January 2011 (MST)

User talk:Tambalor

2011-02-13T00:20:00Z

Thor:

* Thanks for making tables of the spell numbers. I didn't know how to do that. ~Thor
* Thanks for contributing. [[User:Tynian|Tynian]] 21:37, 20 January 2011 (MST)
* Thanks for updating the abbreviations page! [[User:Cordir|Cordir]] 11:35, 21 January 2011 (MST)
* Saw the uploaded pic. Who in the heck are those people?! :-) [[User:Tynian|Tynian]] 15:13, 22 January 2011 (MST)

Spell Numbers

2011-02-13T00:18:00Z

Thor:

{|class="wikitable sortable"
!Spell Number!!Spell Name
|-
|70||Acid Blast
|-
|48||Alarm
|-
|97||Animate Dead
|-
|1||Armor
|-
|125||Attunement
|-
|127||Bear Totem
|-
|3||Bless
|-
|4||Blindness
|-
|126||Boar Totem
|-
|5||Burning Hands
|-
|6||Call Lightning
|-
|63||Cause Critical Wounds
|-
|105||Cause Disease
|-
|62||Cause Light Wounds
|-
|64||Cause Serious Wounds
|-
|82||Change Sex
|-
|7||Charm Person
|-
|8||Chill Touch
|-
|118||Cloak of Protection
|-
|10||Colour Spray
|-
|46||Comprehend
|-
|113||Confusion
|-
|57||Continual Light
|-
|11||Control Weather
|-
|12||Create Food
|-
|80||Create Spring
|-
|13||Create Water
|-
|14||Cure Blindness
|-
|15||Cure Critical Wounds
|-
|99||Cure Deafness
|-
|104||Cure Disease
|-
|16||Cure Light Wounds
|-
|139||Cure Mute
|-
|43||Cure Poison
|-
|61||Cure Serious Wounds
|-
|17||Curse
|-
|86||Darkness
|-
|52||Deafness
|-
|117||Detect Disease
|-
|18||Detect Evil
|-
|9||Detect Good
|-
|44||Detect Hidden
|-
|19||Detect Invisibility
|-
|20||Detect magic
|-
|21||Detect Poison
|-
|22||Dispel Evil
|-
|37||Dispel Good
|-
|59||Dispel Magic
|-
|23||Earthquake
|-
|24||Enchant Weapon
|-
|25||Energy Drain
|-
|57||Exclude
|-
|72||Faerie Fire
|-
|73||Faerie Fog
|-
|106||Fear
|-
|26||Fireball
|-
|65||Flamestrike
|-
|56||Fly
|-
|83||Gate a Vampire
|-
|120||Give Health
|-
|121||Give Mana
|-
|122||Give Moves
|-
|134||Hailstorm
|-
|27||Harm
|-
|28||Heal
|-
|135||Hurricane
|-
|53||Identify
|-
|116||Immunity
|-
|55||Improved Identify
|-
|142||Improved Invisibility
|-
|77||Infravision
|-
|29||Invisibility
|-
|47||Jump
|-
|58||Know Alignment
|-
|30||Lightning Bolt
|-
|31||Locate Object
|-
|32||Magic Missile
|-
|131||Magic Stone
|-
|69||Mass Invisibility
|-
|95||Meteor Swarm
|-
|138||Mute
|-
|95||Naturalize
|-
|115||Onset of Disease
|-
|129||Owl Totem
|-
|74||Pass Door
|-
|100||Pass Without Trace
|-
|124||Phosphate
|-
|33||Poison
|-
|88||Portal
|-
|34||Protection from Evil
|-
|45||Protection from Good
|-
|108||Quiet
|-
|81||Refresh
|-
|35||Remove Curse
|-
|107||Remove Fear
|-
|119||Rift Souls
|-
|36||Sanctuary
|-
|67||Shield
|-
|51||Shocking Grasp
|-
|112||Silence
|-
|38||Sleep
|-
|123||Soul Sense
|-
|132||Spiritual Hammer
|-
|66||Stone Skin
|-
|39||Strength
|-
|40||Summon
|-
|140||Sunlight
|-
|137||Survey
|-
|2||Teleport
|-
|136||Thunderclap
|-
|98||Tongues
|-
|103||True Seeing
|-
|130||Unicorn Totem
|-
|85||Vampiric Touch
|-
|41||Ventriloquate
|-
|133||Water Breathing
|-
|68||Weaken
|-
|128||Weasel Totem
|-
|49||Wizard Mark
|-
|42||Word of Recall
|}

Object Reset

2011-02-12T22:28:52Z

Thor: Created page with "This reset loads an object into a room, leaving it on the ground. A B C D E F A: This must be a O. B: This is a 1 or a 0. 1 signifies that the MUD should run this reset eve..."

This reset loads an object into a room, leaving it on the ground.

A B C D E F

A: This must be a O.

B: This is a 1 or a 0. 1 signifies that the MUD should run this reset every reset cycle, a 0 signifies that the MUD should run this reset only if the area is deserted. In theory anyhow. Merc tends to ignore the setting and resets according to its own built in methods. Use the specs, though, when writing the resets - it makes them easier for me to debug.

C: This is the vnum of the object to load.

D: This is the TOTAL number of this object type allowed in THE GAME. Object type is defined as "unique object vnum" for our purposes. If this type of object totals more than or equal to the number, none will load. If there is less, one will load ONLY if there is no other object with the same vnum already loaded to the room. In other words, and as an example, if you want two desks to load in the room, EACH must have a separate vnum.

E: This is the vnum of the room the object will load into.

F: Commonly, this comment would say the object's name and the room name it was loaded into.

Place Reset

2011-02-12T22:16:43Z

Thor:

This reset loads an object into another object, placing it inside. This reset must be preceded by the object reset for the object it is being loaded into, or another P reset that is loading into that same object. This this rule is not followed, the P reset will NOT work.

A B C D E F

A: This must be a P.

B: This is a 1 or a 0. 1 signifies that the MUD should run this reset every reset cycle, a 0 signifies that the MUD should run this reset only if the area is deserted. In theory anyhow. Merc tends to ignore the setting and resets according to its own built in methods. Use the specs, though, when writing the resets - it makes them easier for me to debug.

C: This is the vnum of the object to load.

D: This is the TOTAL number of this object type allowed in THE GAME. Object type is defined as "unique object vnum" for our purposes. If this type of object totals more than or equal to
the number, none will load. If there is less, one will load.

E: This is the vnum of the object the object will load into.

F: Commonly, this comment would say the object's name and the name of the object it was loaded into.

Place Reset

2011-02-12T22:16:00Z

Thor: Created page with "This reset loads an object into another object, placing it inside. This reset must be preceded by the object reset for the object it is being loaded into, or another P reset that..."

This reset loads an object into another object, placing it inside. This reset must be preceded by the object reset for the object it is being loaded into, or another P reset that is loading into that same object. This this rule is not followed, the P reset will NOT work.

A: This must be a P.

B: This is a 1 or a 0. 1 signifies that the MUD should run this reset every reset cycle, a 0 signifies that the MUD should run this reset only if the area is deserted. In theory anyhow. Merc tends to ignore the setting and resets according to its own built in methods. Use the specs, though, when writing the resets - it makes them easier for me to debug.

C: This is the vnum of the object to load.

D: This is the TOTAL number of this object type allowed in THE GAME. Object type is defined as "unique object vnum" for our purposes. If this type of object totals more than or equal to
the number, none will load. If there is less, one will load.

E: This is the vnum of the object the object will load into.

F: Commonly, this comment would say the object's name and the name of the object it was loaded into.

TFC Area Writer's Guide

2011-02-12T21:49:43Z

Thor:

Writing areas for The Final Challenge is a complex task. To simplify the process as much as possible, the Area Writer's Guide was created. This document describes the rules of area building, the guidelines for submission, the general themes that can be used, and the area file format that TFC uses.

'''General Overview of Area Building'''

[[The Rules of Area Building for TFC]]

[[Guidelines for Submitting Areas for TFC Inclusion]]

[[The TFC World View]]

[[Area Building Tools]]

[[Area Building Hints]]

[[Definition of Terms]]

[[The Layout of an Area File]]

[[The Area Header]]

[[The Helps Block]]

[[The Mobiles Block]]

[[The Objects Block]]

[[The Rooms Block]]

[[The Resets Block]]

[[The Shops Block]]

[[The Specials Block]]

[[The Triggers Block]]

[[The Rspecs Block]]

'''Types of Records'''

[[A Help Record]]

[[A Mob Record]]

[[An Object Record]]

[[A Room Record]]

[[A Reset Record]]

[[A Shop Record]]

[[Special, Trigger, and Rspec Records]]

'''Appendices'''

[[Appendix A: Aproved Spell Numbers]]

[[Appendix B: The Flag List]]

[[Appendix C: Item Type Value Specifications]]

[[Appendix D: Approved Specfuns]]

Spell Numbers

2011-02-12T20:49:33Z

Thor: Created page with "70 Acid Blast 48 Alarm 97 Animate Dead 1 Armor 125 Attunement 127 Bear Totem 3 Bless 126 Boar Totem 4 Blindness 5 Burning Hands 6 Call Lightning ..."

70 Acid Blast

48 Alarm

97 Animate Dead

1 Armor

125 Attunement

127 Bear Totem

3 Bless

126 Boar Totem

4 Blindness

5 Burning Hands

6 Call Lightning

63 Cause Critical Wounds

105 Cause Disease

62 Cause Light Wounds

64 Cause Serious Wounds

82 Change Sex

7 Charm Person

8 Chill Touch

118 Cloak of Protection

10 Colour Spray

46 Comprehend

113 Confusion

57 Continual Light

11 Control Weather

12 Create Food

80 Create Spring

13 Create Water

14 Cure Blindness

15 Cure Critical Wounds

99 Cure Deafness

104 Cure Disease

16 Cure Light Wounds

139 Cure Mute

43 Cure Poison

61 Cure Serious Wounds

17 Curse

86 Darkness

52 Deafness

117 Detect Disease

18 Detect Evil

9 Detect Good

44 Detect Hidden

19 Detect Invisibility

20 Detect magic

21 Detect Poison

22 Dispel Evil

37 Dispel Good

59 Dispel Magic

23 Earthquake

24 Enchant Weapon

25 Energy Drain

72 Faerie Fire

73 Faerie Fog

106 Fear

26 Fireball

65 Flamestrike

56 Fly

83 Gate a Vampire

120 Give Health

121 Give Mana

122 Give Moves

134 Hailstorm

27 Harm

28 Heal

135 Hurricane

53 Identify

116 Immunity

55 Improved Identify

142 Improved Invisibility

77 Infravision

29 Invisibility

47 Jump

58 Know Alignment

30 Lightning Bolt

31 Locate Object

32 Magic Missile

131 Magic Stone

69 Mass Invisibility

95 Meteor Swarm

138 Mute

115 Onset of Disease

129 Owl Totem

74 Pass Door

100 Pass Without Trace

124 Phosphate

33 Poison

88 Portal

34 Protection from Evil

45 Protection from Good

108 Quiet

81 Refresh

35 Remove Curse

107 Remove Fear

119 Rift Souls

36 Sanctuary

67 Shield

51 Shocking Grasp

112 Silence

38 Sleep

123 Soul Sense

132 Spiritual Hammer

66 Stone Skin

39 Strength

40 Summon

140 Sunlight

137 Survey

2 Teleport

136 Thunderclap

98 Tongues

103 True Seeing

130 Unicorn Totem

85 Vampiric Touch

41 Ventriloquate

68 Weaken

128 Weasel Totem

49 Wizard Mark

42 Word of Recall

133 Water Breathing

Special, Trigger, and Rspec Records

2011-02-12T20:45:11Z

Thor: Created page with "Mobs, Rooms, and Doors can have special code attached to them. The general layout of assigning what are called specfuns to one of these is: A B C D E A: This is the specfun t..."

Mobs, Rooms, and Doors can have special code attached to them. The general layout of assigning what are called specfuns to one of these is:

A B C D E

A: This is the specfun type.

B-D: These are various values associated with the specfun. B and C are always required, D is only required in certain cases.

E: This is a optional comment.

There are 4 types of specfuns. Each will be discussed separately:

*[[The Mob Specfun]]
*[[The Prevent Specfun]]
*[[The Allow Specfun]]
*[[The Room Affect Specfun]]

Shop Record

2011-02-12T20:43:03Z

Thor: Created page with "Each mob designated as a shopkeeper will get an information line in the area section on shops. A shopkeeper information line is laid out as: A B C D E F G H I J K ..."

Each mob designated as a shopkeeper will get an information line in the area section on shops. A shopkeeper information line is laid out as:

A B C D E F G H I J K L

A: This is the vnum of the mob who is being identified as a shopkeeper.

B-F: These are the item types the mob will BUY. If a value is not used, enter a 0 in the field.
*Note: A mob will SELL whatever he has in inventory as given to him by "The Give Reset," things he has bought, or things any character has given him.

G: Set this to 100. Don't ask why, just do it.

H: Set this to 100. Don't ask why, just do it.

I: This is the hour the mob opens for business, 0 to 23.

J: This is the hour the mob closes up business, 0 to 23.

K: This is the mobs race number from the flag list. To those of his race, he gives a price break. To those of a different race, he jacks up the price. Use -1 to have the price break scheme ignored.

L: This is a space for a comment, usually containing the mob's name.

A sample shop record follows:

4710 5 0 0 0 0 100 100 6 20 9 This makes Herman a shop who will buy weapons.

Reset Record

2011-02-12T20:41:48Z

Thor: Created page with "Resets come in several different types, each fulfilling a separate need to keep the MUD "alive." All resets have the same basic form: A B C D E F A: This is the reset type. ..."

Resets come in several different types, each fulfilling a separate need to keep the MUD "alive." All resets have the same basic form:

A B C D E F

A: This is the reset type.

B-E: These are the values associated with A, and they are ALWAYS numeric. B through D are required on all resets. E is only required on some resets, and is omitted if not used.

F: This is where a optional comment may be placed explaining the reset.

There are 8 types of resets, and each will be dealt with separately:

*[[The Mob Reset]]
*[[The Equip Reset]]
*[[The Give Reset]]
*[[The Object Reset]]
*[[The Place Reset]]
*[[The Door Reset]]
*[[The Randomize Doors Reset]]
*[[The Comment Reset]]

Room Record

2011-02-12T20:39:52Z

Thor: Created page with "An individual room is laid out in the following format: A B C D E F G H I J K L M N A: The room's vnum. B: The room's name. C: The room's description...."

An individual room is laid out in the following format:

A

B

C

D E F

G

H

I

J

K

L

M

N

A: The room's vnum.

B: The room's name.

C: The room's description.

D: The room's area number.

E: The room's set of flags.

F: The room's terrain type.

G: This is the room's north exit.

H: This is the room's east exit.

I: This is the room's south exit.

J: This is the room's west exit.

K: This is the room's up exit.

L: This is the room's down exit.

M: This is the room's extra description.

N: This must be an S.

A: The room's vnum

This number identifies the room to the MUD for loading purposes and other functions. The Syntax is:

<nowiki>#XXYY</nowiki>

XX is the number assigned to your area. YY is a number between 00 and 99 identifying a particular room in the area. No duplicates vnum's are allowed.

Example: #4710

This is room 10 in area 47.

B: The room's name

This is the title of the room. Make it a short, descriptive phrase, with a tilde at the end.

C: The room's description

This is the description of the room. It is often many lines long, but please limit it to less than 15 if at all possible. Each line should have only 75 characters in it to avoid line wrap problems. Following the block of text is a tilde on a line all by itself. If you are planning on having extra description in the room, then this description should have some hint for the player to look for one.

D: The room's area number

This is identical to the number that was assigned to your area. Fundamentally, it means nothing, but fill it in anyhow.

E: The room's set of flags

Get the numbers from the appropriate part of the flag list. If none are chosen, enter a 0.

F: The room's terrain type

You must choose one, and only one, type. Chose it from the appropriate part of the flag list. If you choose Underwater, you MUST flag it No-Transport.

G: This is the room's north exit.

H: This is the room's east exit.

I: This is the room's south exit.

J: This is the room's west exit.

K: This is the room's up exit.

L: This is the room's down exit.

All doors are coded using the same format. You may NOT have more than one exit in a direction (meaning you cannot have, say, 2 north exits), and for ease of reading, please list them in the order given above. If a door is NOT used, do not put in blank lines. If, however, you wish to describe a wall, a door to nowhere is allowed if properly coded. It is allowed to make a room with no exits.

A door follows this format:

1

2

3

4 5 6

7

1: This is the door number. Choose from the following list for correct values:

north: D0

east: D1

south: D2

west: D3

up : D4

down: D5

2: This is the description of the wall/door. Generally it should be only one line long, although multiple lines are allowed. Each line, however, must be only 75 characters long to avoid line wrap problems. Following it should be a tilde on a line all by itself. If there is no description, a tilde still is required.

If you are placing the "exit description" with a door, remember if the door is closed they will still see the exit description. You don't want this when someone looks at the door/exit:

You see a room full of orcs.

The door is closed.

3: This is the name and list of keywords for interacting with the door. The first in the list is the door name which appears in the "The DOORNAME is closed" messages if you do not specify a separate description (number field 7). The others are synonyms. Directions are not required in this list - they are default synonyms. If there is no name used, a tilde is still required.

The first word in this line is what players in the room will see when someone opens or closes the door and you have not specified something in field 7. For example do not put "wooden door", use "door wooden". The reason for this is that if wooden is used, then players will see this: Player opens the wooden.

4: This is the door type. The following values are allowed:

-1 : This door goes nowhere. This setting is commonly used when you want to have a description for a wall/direction, but do not want it to actually be a connection point to another room.

0 : It is not a door but might go somewhere, such as a street.

1 : This is a door. If locked, passdoor and pick will open it.

2 : This is a door. If locked, a key is required to open it.

3 : This is a trap. Used in conjunction with spec_collapse. Must be a down.

5: This is the vnum of the key that opens the door, if it is locked. If the door has no lock, use 0 or -1 for the key number.

6: This is the room the door leads to. If the door is included merely for a wall description or effect and leads nowhere, use -1 or 0. If -1 or 0 are used, you must use -1 or 0 for the

value in field 4.

7: This is a optional field for specify the name of the door that would bedisplayed when someone opens it, closes it, and so on. If this is omitted, the keywords are used instead. The

syntax for this field is:

O

name of door~

The syntax must be exactly as shown with an O on the first line, and the string on the second line followed immediately by a tilde. Do NOT start the string with "a" or "the" or any variants like that...the Mud will add "the" to the front of this string before displaying it.

M: The room's extra descriptions

These are coded EXACTLY like the extra description for objects. You may have none, one, or multiple extra descriptions. Repeat this block as needed, but do not include blank lines if there are no extra descriptions.

The extra description is laid out as:

1

2

3

4

1: The letter "E" is placed on a line by itself.

2: This is the list of keywords that identify this description. The syntax follows the same rules as all other names and keywords.

3: This is the description. It should contain lines no longer than 75 or so characters so that no line wrap problems occur.

4: This must be a tilde. Nothing else can go on the line.

N: This field MUST be an S

There is no why. An S and nothing but an S is acceptable.

An example of a room record follows:

<nowiki>#4710</nowiki>

The Hut of Herman~

You stand in Herman's hut...and if you have any brains, you will leave

before Herman finds you here.

~

47 8 0

D0

The door serves as an exit to the street.

~

door~

1 0 4711

S

Object Record

2011-02-12T20:31:30Z

Thor: Created page with "An individual object is laid out in the following format: A B C D E F G H I J K L M N O P Q R S T U Required Information A: The object's vnum. B:..."

An individual object is laid out in the following format:

A

B

C

D

E

F G H

I J K L

M N O

P

Q

R

S

T

U

Required Information

A: The object's vnum.

B: The object's name.

C: The object's short description.

D: The object's long description.

E: Set this to a tilde.

F: The object's type.

G: The object's extra flags.

H: The object's wear flags.

I: The object's value0.

J: The object's value1.

K: The object's value2.

L: The object's value3.

M: The object's weight.

N: The object's cost.

O: Set this to 0.

Optional Information

P: The object's bonuses.

Q: The object's extra des.

R: The flammable item flag.

Conditional Information

S: The metallic item flag.

T: The two-handed weapon flag.

U: The underwater breath item flag.

A: The object's vnum

This number identifies the object to the MUD for loading purposes and other functions. The Syntax is:

<nowiki>#XXYY</nowiki>

XX is the number assigned to your area. YY is a number between 00 and 99 identifying a particular object in the area. No duplicates vnum's are allowed.

Example: #4710

This is object 10 in area 47.

B: The object's name

This is the keyword (or words) used by mortals to interact with a object. Generally, the name field should have no more than 2 or 3 words in it. The field should be all in lower case, and the last character must be a tilde (the squiggly hyphen). If the object is "a stone hammer", "hammer" and "stone" are the 2 words you would put in the name field. Do not put articles or prepositions in this field, and at least ONE keyword should appear in the object's long description.

C: The object's short description

This is the phrase the MUD uses when the object does something. If the object's short description is "a stone hammer", then if you pick it up, it might read as:

You pick up a stone hammer.

The short description should be a phrase that makes grammatical sense, and it must be followed by the tilde. Avoid capitalizing leading prepositions such as in "A stone hammer". Instead use "a stone hammer". This allows the messages the mud makes from this description to look right, such as: You get a stone hammer from a bag.

Also be aware that using capitals to describe an item indicates, in most cases, that the item is considered unique and one of a kind, such as the "Holy Avenger".

D: The object's long description

This is the sentence that the MUD displays for objects standing in a room. If a object has the long description "A heavy stone hammer lies here.", then when you enter the room, following the room description the MUD would display:

A heavy stone hammer lies here.

If there is no extra description on the object, the long description is also used when a "look" or "examine" command is used on the object.

The long description gets preceded by things like aura's and other spell effects, so take that into account when you write the description. In general, this sentence should be approximately 70 characters in maximum length if the object has no affects on it. If the object does have affects, make sure that you take auras and spell affects into consideration. Make sure the auras and description all fit on ONE line, like this:

(Invis)(Magical)(Humming)(Glowing)(Red Aura) A heavy stone hammer is here.]]

The sentence should be grammatically correct and following it, on a the SAME line, should be a tilde.

E: Set this to a tilde

No whys, just set it to the tilde.

F: The object's type

Refer to the flag list for valid types. One, and only one, MUST be chosen.

G: The object's extra flags

Refer to the flag list for valid flags. A combined value is allowed. If you don't want to use any, enter a 0.

H: The object's wear flags

This is a very important flag, and coding it wrong causes strange problems. Follow these guidelines when choosing values from the flag list:
#If you want the object to be worn, you must combine the wear location AND the take-able flag.
#Do NOT combine two wear locations.
#If you do not want the item to be picked up, enter a 0.
#For items of type light, ONLY set the take-able flag. Do NOT set a wear location.

In short, you enter a 0, the value of the take-able flag, or the value of the take-able flag combined with a wear location.

I through L: The object's value0 through value3

These values are determined by the object type. The specifications are listed under the various item types in the item type value specifications list.

M: The object's weight

This is how much the item weighs. With the exception of items which are flagged NO_TAKE, such as fountains, this value should be realistic. A mace might weigh in at 8-12 and a dagger only 2 or 3. Any weight that is warped must be approved.

Items that are NO_TAKE can be any weight you choose unless they are a container. In general, a value of 1 or 0 is used.

If the item is of type container, it is IMPERATIVE this weight value be less than the object's value0 or it will cause errors and/or problems.

Items with a take flag that are reset on the ground will disintegrate over time, only items that are notake will remain.

N: The objects cost

If you have set the extra flag USE COST, indicating the object has a base cost, enter the base cost here. If there is no base cost, enter 0. In general, this field should be 0 unless you have had the item approved to use a base cost. If you wish to use this feature, contact the Area Coordinator for a complete explanation of how this field works.

O: Set this to 0

No whys, just set it to 0.

P: The object's bonuses

Bonuses, also called "Applies," are different good or bad affects an object gives to the player using it. The syntax is:

1

2 3

1: This is the letter A.

2: This is the number of an Apply. See the flag list for legal values.

3: This is the amount of the Apply - it may be positive or negative.

If you do not have bonuses on an item, do NOT put in blank lines. It is technically allowable to put in multiple bonuses by repeating this block format. As a general rule, bonuses should be used SPARINGLY! Becoming bonus happy is a good way to have an area rejected.

Q: The object's extra description

If this description exists, then it is used when someone does a "look" or "examine" command on the object. If the extra description of the hammer is "The hammer is old and has a split shaft.", then if you type "LOOK HAMMER" the MUD would display:

The hammer is old and has a split shaft.

A object may have none, one, or multiple extra descriptions, each coded following this format:

1

2

3

4

1: The letter "E" is placed on a line by itself.

2: This is the list of keywords that identify this description. The syntax follows the same rules as all other names and keywords - see B above.

3: This is the description. It should contain lines no longer than 75 or so characters so that no line wrap problems occur.

4: This must be a tilde. Nothing else can go on the line.

If the extra description is omitted, do NOT put in blank lines.

R: The flammable item flag

Set this on any item type. If the object should be subjected to INSTANT burning in a fight, such as a scrap of paper, set this flag. The syntax is a single "F" on a line all by itself. If omitted, do NOT put in a blank line.

S: The metallic item flag

Set this only on object's that are item type armor. If the object AC is more than 5, then this flag MUST be set. The syntax is a single "M" on a line all by itself. If omitted, do NOT put in a blank line.

T: The two-handed weapon flag

Set this only on object's that are item type weapon. If the object weight is more than 9, then this flag MUST be set. The syntax is a single "T" on a line all by itself. If omitted, do NOT put in a blank line.

U: The underwater breath item flag

Set this only on object's that are item type armor. The syntax is a single "U" on a line all by itself. If omitted, do NOT put in a blank line. Special approval is required if using this flag.

An example of an object record follows:

<nowiki>#4710</nowiki>

stone hammer~

a stone hammer~

A heavy stone hammer lies here.~

~

5 0 8193

0 3 7 7

10 0 0

E

stone hammer~

The hammer is old and has a split shaft.

~

T

Mob Record

2011-02-12T20:24:12Z

Thor: Created page with "An individual mob is laid out in the following format: A B C D E F G H I J K L M N O P Q R S T U V W A: The mob's vnum. B: The mob's name. C: The mo..."

An individual mob is laid out in the following format:

A

B

C

D

E

F G H I

J K L M N

O P

Q R S

T

U

V

W

A: The mob's vnum.

B: The mob's name.

C: The mob's short description.

D: The mob's long description.

E: The mob's look description.

F: The mob's actions.

G: Things affecting the mob.

H: The mob's alignment.

I: This must be an S.

J: The mob's level.

K: Set this to 0.

L: Set this to 0.

M: Set this to 0d0+0.

N: Set this to 0d0+0.

O: Set this to 0.

P: Set this to 0.

Q: Set this to 8.

R: Set this to 8.

S: The mob's sex.

T: The mob's language. [Optional]

U: The Animal flag.

V: The No-Wear flag.

W: The spec_one_spell entry

A: The mob's vnum

This number identifies the mob to the MUD for loading purposes and other functions. The Syntax is:

<nowiki>#XXYY</nowiki>

XX is the number assigned to your area. YY is a number between 00 and 99 identifying a particular mob in the area. No duplicates vnum's are allowed.

Example: #4710

This is mob 10 in area 47.

B: The mob's name

This is the keyword (or words) used by mortals to interact with a mob. Generally, the name field should have no more than 2 or 3 words in it. The field should be all in lower case, and the last character must be a tilde (the squiggly hyphen).

If the mob is an ogre named herman, "herman" and "ogre" are the 2 words you would put in the name field. Do not put articles or prepositions in this field, and make sure one of the keywords is also used in the long description.

C: The mob's short description

This is the phrase the MUD uses when the mob does something. If the mob's short description is "herman", then if it bows it might read as:
Herman bows in your presence.

The short description should be a phrase that makes grammatical sense, and it must be followed by the tilde. Also make sure you do NOT capitalize leading prepositions, such as in "The ogre". Instead use "the ogre". This allows the messages the mud generates using this description to look right, such as "Your slash hits the ogre."

D: The mob's long description

This is the sentence that the MUD displays for mobs standing in a room. If a mob has the long description "Herman stands here idly.", then when you enter the room, following the room description the MUD would display:

Herman stands here idly.

The long description gets preceded by things like aura's and other spell effects, so take that into account when you write the description. In general, this sentence should be approximately 70 characters in maximum length if the mob has no affects on him. If the mob has affects, take the auras into consideration, making sure the description and auras all fit on ONE line, like this:

(Hide)(Invis)(Sanctuary)(Translucent)(Red Aura) An ogre stands here.

The sentence should be grammatically correct and following it, on a separate line by itself, should be a tilde.

E: The mob's look description

This is the paragraph describing the mob that you would see when you look at him. If the mob had the name "herman" and the look description of "Herman is a fat, ugly ogre. He stands here swatting flies, picking his nose, and wondering whether you would make a good lunch.", then when you type LOOK HERMAN, the MUD would display:

Herman is a fat, ugly ogre. He stands here swatting flies, picking
his nose, and wondering whether you would make a good lunch.

The lines in the paragraph should be no more than 70-75 characters in length so line wrap problems don't occur. On a separate line following the paragraph should be a tilde.

F: The mob's actions

Refer to the flag list for legal values which are used to define how a mob interacts with the world. If you use nothing out of the list, enter a 0.

G: Things affecting the mob

Refer to the flag list for legal values which are used to define what things are affecting the mob. If you use nothing out of the list, enter a 0.

H: The mob's alignment

This is a number between -1000 (super evil) and 1000 (super good). For a mob to register as either evil or good, the absolute value of the alignment must be at least 350.

I: This field MUST be an S

There is no why. An S and nothing but an S is acceptable.

J: The mob's level

This is the level of the mob, a non-negative number. Maximum level should generally be 50. Remember that mob levels differ from player levels, with a mob's level equating to a player's level some 3 to 10 player levels higher. Also remember that specfuns often cause a mob to be capable of fighting several levels above their own level. Consider thesr facts when designing mob levels with respect to your assigned/chosen area level range.

K through R: Set these to "whatever" is listed in the diagram legend.

There is no why. Just set them to what is indicated.

S: The mob's sex

This number indicates if the mob is male(1), female(2), or an it(0).

T: The mob's language (optional)

Mobs can be set to speak a language. If none is set, they speak the universal god-tongue. Language has the format:

1

2 3

1: This is a L.

2: This is the languages a mob KNOWS. Refer to the flag list for values.

3: This is the what the mob prefers speaking. Refer to the list for values. Only ONE value is allowed - do NOT combine values in this field.

U: The Animal flag (optional)

If the mob is a animal, put a single A on this line. If this is omitted, do NOT put in a blank line.

V: The No-Wear flag (optional)

If the mob is not allowed to wear equipment, enter a N on this line. If this is omitted, do NOT put in a blank line. Most animals should receive this flag with dragons being a notable exception to that rule.

W. The spec_one_spell block (optional) (requires *Special Permission*)

The spec_one_spell block sets the single spell a mob knows. To use a spec_one_spell in an area, the mob must have this block AS WELL AS an associated entry in the #SPECIALS section. If a mob is not receiving this specfun, do NOT put in blank lines. The block has the format:

1

23

1. This is the letter O.

2. This is the NAME of the spell being given to the mob.

3. This is a tilde. It must be on the same line as, and begin immediately after, the spell text with NO spaces.

An example of a Mobile record follows:

<nowiki>#4710</nowiki>

herman ogre~

Herman~

Herman stands here idly.

~

Herman is a fat, ugly ogre. He stands here swatting flies, picking

his nose, and wondering whether you would make a good lunch.

~

96 0 -350 S

21 0 0 0d0+0 0d0+0

0 0

8 8 1

L

256 256

Help Record

2011-02-12T20:12:31Z

Thor: Created page with "A help record is laid out as follows: A B C D E A: This is the lowest level player that can read the help. A 0 means everyone can read it. B: This is a list of keywords ..."

A help record is laid out as follows:

A B C

D

E

A: This is the lowest level player that can read the help. A 0 means everyone can read it.

B: This is a list of keywords that are used to reference the help.

C: This is a tilde (the squiggly hyphen).

D: This is the text of the help. If you wish to start the help with a blank line, put a single "." as the first line of the text (all by itself). The text should be composed of lines no longer than 75 characters, and do NOT use tabs to align things as they cause weird problems.

E: This is a tilde.

An example of a help record is show below:

0 SAMPLE~

This is a sample help to show you what a help would look like. Had this been a real help, there theoretically would be useful, informative, or otherwise beneficial information contained herein.

~

TFC Area Writer's Guide

2011-02-12T20:10:46Z

Thor:

'''The TFC Area Writer's Guide'''

Writing areas for The Final Challenge is a complex task. To simplify the process as much as possible, the Area Writer's Guide was created. This document describes the rules of area building, the guidelines for submission, the general themes that can be used, and the area file format that TFC uses.

'''General Overview of Area Building'''

[[The Rules of Area Building for TFC]]

[[Guidelines for Submitting Areas for TFC Inclusion]]

[[The TFC World View]]

[[Area Building Tools]]

[[Area Building Hints]]

[[Definition of Terms]]

[[The Layout of an Area File]]

[[The Area Header]]

[[The Helps Block]]

[[The Mobiles Block]]

[[The Objects Block]]

[[The Rooms Block]]

[[The Resets Block]]

[[The Shops Block]]

[[The Specials Block]]

[[The Triggers Block]]

[[The Rspecs Block]]

'''Types of Records'''

[[A Help Record]]

[[A Mob Record]]

[[An Object Record]]

[[A Room Record]]

[[A Reset Record]]

[[A Shop Record]]

[[Special, Trigger, and Rspec Records]]

'''Appendices'''

[[Appendix A: Aproved Spell Numbers]]

[[Appendix B: The Flag List]]

[[Appendix C: Item Type Value Specifications]]

[[Appendix D: Approved Specfuns]]

The Rspecs Block

2011-02-12T20:10:03Z

Thor: Created page with "The block start with the string "#RSPECS" without quotes, followed by one or more rspec records, and ending with the string "S" without quotes. This is an example of a rspec..."

The block start with the string "#RSPECS" without quotes, followed by one
or more rspec records, and ending with the string "S" without quotes.

This is an example of a rspecs block:

<nowiki>#RSPECS</nowiki>

rspec 1: see syntax for a rspec record for layout

rspec 2: see syntax for a rspec record for layout

rspec 3: see syntax for a rspec record for layout

.

.

.

S

The Triggers Block

2011-02-12T20:09:14Z

Thor: Created page with "The block start with the string "#TRIGGERS" without quotes, followed by one or more trigger records, and ending with the string "S" without quotes. This is an example of a ..."

The block start with the string "#TRIGGERS" without quotes, followed by
one or more trigger records, and ending with the string "S" without
quotes.

This is an example of a triggers block:

<nowiki>#TRIGGERS</nowiki>

trigger 1: see syntax for a trigger record for layout

trigger 2: see syntax for a trigger record for layout

trigger 3: see syntax for a trigger record for layout

.

.

.

S

The Specials Block

2011-02-12T20:08:31Z

Thor: Created page with "The block start with the string "#SPECIALS" without quotes, followed by one or more special records, and ending with the string "S" without quotes. This is an example of a ..."

The block start with the string "#SPECIALS" without quotes, followed by
one or more special records, and ending with the string "S" without
quotes.

This is an example of a specials block:

<nowiki>#SPECIALS</nowiki>

special 1: see syntax for a special record for layout

special 2: see syntax for a special record for layout

special 3: see syntax for a special record for layout

.

.

.

S

The Shops Block

2011-02-12T20:07:57Z

Thor: Created page with "The block start with the string "#SHOPS" without quotes, followed by one or more shop records, and ending with the string "0" without quotes. This is an example of a shops b..."

The block start with the string "#SHOPS" without quotes, followed by one
or more shop records, and ending with the string "0" without quotes.

This is an example of a shops block:

<nowiki>#SHOPS</nowiki>

shop 1: see syntax for a shop record for layout

shop 2: see syntax for a shop record for layout

shop 3: see syntax for a shop record for layout

.

.

.

0

The Resets Block

2011-02-12T20:07:08Z

Thor: Created page with "The block start with the string "#RESETS" without quotes, followed by one or more reset records, and ending with the string "S" without quotes. This is an example of a reset..."

The block start with the string "#RESETS" without quotes, followed by one
or more reset records, and ending with the string "S" without quotes.

This is an example of a resets block:

<nowiki>#RESETS</nowiki>

reset 1: see syntax for a reset record for layout

reset 2: see syntax for a reset record for layout

reset 3: see syntax for a reset record for layout

.

.

.

S

The Rooms Block

2011-02-12T20:06:18Z

Thor: Created page with "The block start with the string "#ROOMS" without quotes, followed by one or more room records, and ending with the string "#0" without quotes. This is an example of a rooms ..."

The block start with the string "#ROOMS" without quotes, followed by one
or more room records, and ending with the string "#0" without quotes.

This is an example of a rooms block:

<nowiki>#ROOMS</nowiki>
room 1: see syntax for a room record for layout

room 2: see syntax for a room record for layout

room 3: see syntax for a room record for layout

.

.

.

<nowiki>#0</nowiki>

The Objects Block

2011-02-12T20:05:02Z

Thor: Created page with "The block start with the string "#OBJECTS" without quotes, followed by one or more object records, and ending with the string "#0" without quotes. This is an example of a ob..."

The block start with the string "#OBJECTS" without quotes, followed by
one or more object records, and ending with the string "#0" without
quotes.

This is an example of a objects block:

<nowiki>#OBJECTS</nowiki>
object 1: see syntax for a object record for layout

object 2: see syntax for a object record for layout

object 3: see syntax for a object record for layout

.

.

.

<nowiki>#0</nowiki>

Mobiles Block

2011-02-12T20:03:32Z

Thor: Created page with "The block start with the string "#MOBILES" without quotes, followed by one or more mob records, and ending with the string "#0" without quotes. This is an example of a mobi..."

The block start with the string "#MOBILES" without quotes, followed by
one or more mob records, and ending with the string "#0" without quotes.

This is an example of a mobiles block:

<nowiki>#MOBILES</nowiki>

mob 1: see syntax for a mob record for layout

mob 2: see syntax for a mob record for layout

mob 3: see syntax for a mob record for layout

.

.

.

<nowiki>#0</nowiki>

Area Header

2011-02-12T19:57:04Z

Thor: Created page with "The syntax for the header is: A B C DE F A: This is the string "#AREA " without the quotes. Following the string, on the same line, is a bunch of text which MUST be laid o..."

The syntax for the header is:

A B C DE F

A: This is the string "#AREA " without the quotes. Following the string,
on the same line, is a bunch of text which MUST be laid out precisely in
order to keep the area list in neat columns.

B: This is the level range. It starts with a { followed by the low range
followed by the high range followed by a }. The field with is 7 positions,
and all must be used with { in the first position and } in the 7th.

C: This is the author's name. It starts with a space in position 8,
followed by up to 8 characters for the name. Unused character places
should be padded with spaces. Position 17 must be a space.

D: This is the name of the area. It starts in position 18. You are
allowed up to 20 characters for the name, but you do not have to pad the
unused positions with spaces.

E: This is the tilda (the squiggly hyphen).

F: This is the area wide flag denoting the kind of area it is. It is a
letter "F" followed by a space followed by a value. The value is chosen
from the appropriate part of the flag list, and these values may be
combined.

This an example of an area header:

<nowiki>#AREA { 1 2} Author Area_Name~ F 1</nowiki>

If this block is used, it is IMPERATIVE it is the FIRST line of the file.

Area File Layout

2011-02-12T19:55:25Z

Thor:

An area file is laid out using a series of BLOCKS. Each block starts with a control structure that tells the MUD what kind of data is contained in the block. Following the control structure are the records holding the data. After the final record in a block, a control marker occurs indicating the block is finished.

All blocks are optional, and you may have only ONE of each type. However, some blocks force the use of other blocks. For example, if you have a block of mobs or objects, you are forced to have a block of the resets to load them into the area. Or if you have rooms in the file, you MUST have an area header block.

There are 10 kinds of blocks:
*[[The Area Header]]
*[[The Helps Block]]
*[[The Mobiles Block]]
*[[The Objects Block]]
*[[The Rooms Block]]
*[[The Resets Block]]
*[[The Shops Block]]
*[[The Specials Block]]
*[[The Triggers Block]]
*[[The Rspecs Block]]

For ease of reading, they MUST be used in the order listed above.

Following all the blocks, the last line of the area file must contain the control marker signifying the "end of file". This is the string "#$" on a line all by itself. If this is omitted, the area will NOT load.

An area file is laid out like this, then:

BLOCK

BLOCK

BLOCK

BLOCK

.

.

.

<nowiki>#$</nowiki>

Area File Layout

2011-02-12T19:54:25Z

Thor:

An area file is laid out using a series of BLOCKS. Each block starts with a control structure that tells the MUD what kind of data is contained in the block. Following the control structure are the records holding the data. After the final record in a block, a control marker occurs indicating the block is finished.

All blocks are optional, and you may have only ONE of each type. However, some blocks force the use of other blocks. For example, if you have a block of mobs or objects, you are forced to have a block of the resets to load them into the area. Or if you have rooms in the file, you MUST have an area header block.

There are 10 kinds of blocks:
*The Area Header
*The Helps Block
*The Mobiles Block
*The Objects Block
*The Rooms Block
*The Resets Block
*The Shops Block
*The Specials Block
*The Triggers Block
*The Rspecs Block

For ease of reading, they MUST be used in the order listed above.

Following all the blocks, the last line of the area file must contain the control marker signifying the "end of file". This is the string "#$" on a line all by itself. If this is omitted, the area will NOT load.

An area file is laid out like this, then:

BLOCK

BLOCK

BLOCK

BLOCK

.

.

.

<nowiki>#$</nowiki>

Area File Layout

2011-02-12T19:53:21Z

Thor: Created page with "An area file is laid out using a series of BLOCKS. Each block starts with a control structure that tells the MUD what kind of data is contained in the block. Following the contro..."

An area file is laid out using a series of BLOCKS. Each block starts with a control structure that tells the MUD what kind of data is contained in the block. Following the control structure are the records holding the data. After the final record in a block, a control marker occurs indicating the block is finished.

All blocks are optional, and you may have only ONE of each type. However, some blocks force the use of other blocks. For example, if you have a block of mobs or objects, you are forced to have a block of the resets to load them into the area. Or if you have rooms in the file, you MUST have an area header block.

There are 10 kinds of blocks:
*The area header
*The helps block
*The mobiles block
*The objects block
*The rooms block
*The resets block
*The shops block
*The specials block
*The triggers block
*The rspecs block

For ease of reading, they MUST be used in the order listed above.

Following all the blocks, the last line of the area file must contain the control marker signifying the "end of file". This is the string "#$" on a line all by itself. If this is omitted, the area will NOT load.

An area file is laid out like this, then:

BLOCK

BLOCK

BLOCK

BLOCK

.

.

.

<nowiki>#$</nowiki>

TFC Area Writer's Guide

2011-02-12T19:51:03Z

Thor:

'''The TFC Area Writer's Guide'''

Writing areas for The Final Challenge is a complex task. To simplify the process as much as possible, the Area Writer's Guide was created. This document describes the rules of area building, the guidelines for submission, the general themes that can be used, and the area file format that TFC uses.

'''General Overview of Area Building'''

[[The Rules of Area Building for TFC]]

[[Guidelines for Submitting Areas for TFC Inclusion]]

[[The TFC World View]]

[[Area Building Tools]]

[[Area Building Hints]]

[[Definition of Terms]]

[[The Layout of an Area File]]

[[The Area Header]]

[[The Helps Block]]

[[The Mobiles Block]]

[[The Objects Block]]

[[The Rooms Block]]

[[The Resets Block]]

[[The Shops Block]]

[[The Specials Block]]

[[The Triggers Block]]

[[The Rspecs Block]]

[[Types of Records]]

[[A Help Record]]

[[A Mob Record]]

[[An Object Record]]

[[A Room Record]]

[[A Reset Record]]

[[A Shop Record]]

[[Special, Trigger, and Rspec Records]]

'''Appendices'''

[[Appendix A: Aproved Spell Numbers]]

[[Appendix B: The Flag List]]

[[Appendix C: Item Type Value Specifications]]

[[Appendix D: Approved Specfuns]]

Definition of Terms

2011-02-12T19:49:47Z

Thor: Created page with "'''NPC, mob, mobile, creature, monster:''' These are used somewhat interchangeably to identify a character in the game which is being run by the MUD and not by a player. In this..."

'''NPC, mob, mobile, creature, monster:'''
These are used somewhat interchangeably to identify a character in the game which is being run by the MUD and not by a player. In this work, mob is the normal term used.

'''combined value:'''
This is the summing of discrete flag values into a single number. For instance, if you want the flag values of 1, 8, and 256, you enter them as a combined value. This is done in two different ways, whichever the author chooses. The first is to just add them together. 1+8+256 which is 265. You would then enter 265 in the field. The second method is called "or'ing the values". You would enter each number in the field and separate them with the "|" character. In this case, 1|8|256 would be entered in the field. Sirak's Muditor always sums the values. If for some reason you are manually editing the values, please use the or format for clarity and ease of future manual editing.

'''specfun, special function:'''
This is a piece of C program code which a mob, door, or room is "attached" to, giving it additional properties to spice up the game. When we speak of NEW CODE, we are talking about these functions and are discussing the request for a new specfun to be written specifically for your area.

'''vnum:'''
This has 2 meanings. First, it is the number assigned to your area. But, when talking about a specific area component (a mob, room, or object), it is the specific number assigned to that room. Both are referring to the unique identifier assigned to something so that both the MUD and the gods can keep track of things.

Area Building Hints

2011-02-12T19:48:08Z

Thor: Created page with "Area writing is much like writing a short story or a novel in that you must create characters, objects, and an environment by words alone. A story of sorts arises from these item..."

Area writing is much like writing a short story or a novel in that you must create characters, objects, and an environment by words alone. A story of sorts arises from these items each and every time the area is played. What you are writing, then, is the stage on which these stories are played out and the characters who come alive in the story. The good thing is that even if one doesn't have great writing talent, they can still make a fine area. What it all comes down to is planning and thinking things through BEFORE starting the area. To aid you, here are some helpful hints to follow when writing an area, but most especially for when writing your first one.

#Make a map. Not in your head, but on paper. It doesn't have to be to scale, but a diagram showing what room is where and how things connect will save you a world of pain in first writing the links and in debugging them later. The map of an area is the NUMBER ONE best aid you can create. Each room on the map should contain its vnum for best results.
#Make a list of the objects and mobs with their vnums along side them. When writing the resets for the area, such a list will be invaluable. Or print out those sections of the area file before starting the resets.
#Resets will take at least 1/4 of the writing time of your area - they look deceptively easy but they are the primary thing people screw up. A way to speed them up is to xerox your map and write in each room what mobs and objects go in it. If you are unclear as to how to reset something, ASK first - it is better to ask and get help before hand than to try and undo/fix resets later.
#The rooms of your area will take the bulk of the writing time. At least 50% if not more of your time will be spent working directly on them. And a lot of this will not be in the description writing, but in the exits and doors making sure they are correctly set. Plan accordingly.
#DON'T RUSH IT. It takes many hours to write an area, check it, get it approved, get it tested, and finally get it into play. Don't be discouraged if you catch on slow or it seems to be taking a long time. I have spent as few as 2 hours on an area and as many as 50, and have one in development that will probably take me 100 hours of coding and writing to complete (it is quite complicated). The idea is to start off with a simple area for your first one and grow from there...starting with a wicked and wild area as your first one will most probably raise your blood pressure, heighten your frustration, and totally discourage you. My best advice is to take is slow.
#Learn to use a ASCII editor. You will need it and it will pay off in time saved. Learning one that has a built in spell checker (like pico) will kill two birds with one stone.

Rules of Area Building for TFC

2011-02-12T19:46:20Z

Thor:

#Anyone with a character in their stable that is level 20 or higher may request permission to author an area. This is NOT a short cut to going immortal. Immortality just is not a requirement to authoring an area.
#Anyone writing an area will submit themselves to the following rules on the conduct of ALL their characters on the MUD:
##At no time will the nature of the items in your area be revealed to mortals. Make them find out what they do themselves.
##At no time will you collect items in your area and distribute them to mortals. Make them find where they are themselves.
##At no time will you give information on mob levels, traps, tricks, or any other feature of the area to mortals. Make them discover it for themselves.
##At no time will any other confidential information regarding your area, or any area or feature of TFC, be given out to mortals.
##For the first two months of your area's existence on the LIVE server of TFC you will not lead adventurers in your area.
##Violation of these rules (a subset of the wizrules) will be grounds for disciplinary action, up to and including deletion of characters.
#Areas written must be exclusive to TFC and not be run on any other MUD. If any area you write is found running on another MUD, all your areas will be removed from TFC. It may take us some time to replace them, and it will be painful for us to do so, but we WILL do it. Should we be forced to exercise this rule, the author in question will also be disallowed from writing any future areas for TFC.
#The theme of the area must fit the TFC World View. See the separate listing for what that is.
#The submission procedures will be followed EXACTLY.
#The Area Coordinator withholds the right to place, balance, or otherwise edit the area to make it fit in TFC. Authors will make all changes that are ordered, but may discuss any change requested in a ONE time appeal. If the appeal fails, the change must be made. Once an area is submitted, it belongs to The Final Challenge. The Area Coordinator, or future Area Coordinators, are free to make any changes they desire, and you do not retain possession of creative control.
#No area may have more than 100 rooms, 100 objects, and 100 mobs. These will be numbered from XX00 to XX99 inclusive, where XX is the assigned area vnum. Areas should be between 90-95 rooms, which gives the Area Coordinator a few rooms to use for later additions to the area, such as rooms connecting future areas to the area. You may be asked to write the connect rooms yourself. For large projects, a set of related areas may be done, but no single area can exceed these limits.
#Help in writing is available online in the HELPS or in hardcopy form from the Area Coordinator. If your question is answered in the TFC Area Writer's Guide, you will be directed to it...if not, the issue will be examined and handled when asked. The Guide is your first line of help...use it well. First time authors will receive special assistance...all others shall handle things themselves.

Guidelines for Submitting Areas for TFC Inclusion

2011-02-12T19:45:49Z

Thor:

'''The Ultimate Rule''' - Areas will be written within the TFC spirit from the outset - no huge hoards of cash, no 100-150 damage super weapons, and so on... Writing such things just wastes everyone's time.

'''Submission Guidelines'''

All initial proposals and work are sent to the Co-Area Coordinators, Tokuagwa and Tamar. They should be mailed to mbeck@fastq.com and should cc Tynian at tynian@finalchallenge.net. The submission guidelines are as follows:

a1. Mortals considering writing an area must contact the Area Coordinator and have a level range assigned to them. Mortals must write the area to that level range - they do not have a choice on it.

a2. Mortals considering writing an area must be in good standing on the MUD. If they are not, they must wait.

a3. Mortals are limited to working on ONE area at a time.

a4. Mortals may submit areas under only ONE character name. At the time of writing an area, disclosure of ALL characters in your stable must be made. New characters made in the future must be reported as well. Refusal to do so, or incomplete disclosure, can lead to rejection of any and all areas. (There is no character flag involved so do not let that worry bother you.)

b1. Authors must submit a proposal of the area PRIOR to starting writing it. This proposal MUST include:

*The name of the area
*What level range you are targeting
*What location you are thinking of
*What theme you are thinking of
*Any special objects you want to include
*Any special tricks/traps/sneakiness involved

In short, the proposal should be about a page long and give me a broad overview of what I should expect. If it is omitted, the area will not be considered. Do not work on your proposed area until/unless it is accepted.

Proposals should be mailed to mbeck@fastq.com, and should cc Tynian at tynian@finalchallenge.net as mentioned above.

NO NEW CODE will be allowed. In other words, you are limited to the special functions in the approved lists. If there is an exceptional idea, this rule might be overlooked, but consider the fact that in all the first time author situations, only ONE ever received the approval for new code.

NO ILLOGICAL LINKS will be allowed without EXPRESSED prior approval. An illogical link is defined as a link that combines 2 directions (north+west
up+south), one that links an area in a loop (4 norths take you back to the same spot), or one that folds back on itself in some other way. A lot of time was spent laying the map out logically. Portals and things like mazes are fine, but they MUST be approved or the bug hunters will rip the area to shreds.

NO WWP ITEMS WITH AFFECTS are allowed in new areas.

b2. If the proposal is accepted, you will then be assigned a Vnum range to work with, and a base filename. This will be the final filename (e.g. midgaard.are). You will not use this base filename directly, instead, each version you create and send to the Area Coordinator will use the base filename with a letter appended. The first draft would be midgaardA.are, the second would be midgaardB.are, etc. This allows the Area Coordinator to keep an archive of your progress. You are likely to get to around G.

c. You must submit ALL objects in the area for prior review. All changes requested by the Area Coordinator will be governed by rule 6 above.

d. ALL authors will spell check their areas prior to each submission. A makeshift way to do this is to load a copy of the .are file into a program that spellchecks such as Word, allow it to find errors, and then make the changes in the real file in the Muditor. It is generally a bad idea to let the program do the spellchecking automatically, as small changes in the .are file will cause the area not to load (And thus crash the test mud).

e. ALL authors will include a comment block in the Resets, or in a separate email at the time of submission. This comment block will list the following information:
*Where the area connects to the outside world - room numbers AND door directions. Mortals can get the vnum of the connection room from a God+.
*A short statement on the theme of the area. This will be used as what your "intent" was should problems arise later on in the area's lifecycle.
*Any special details you wish to pass on to the Area Coordinator so he doesn't take them out during some wild edit spree.

f. Any authors wanting new code will confer with the Area Coordinator as to what they want, and if it is approved, will work with the Area Coordinator to write it. (Read that as you will write your own 90% of the time.) Remember that for mortals and first time authors, new code is at best a long shot, and continues to be so until someone has written several areas or has reached God+ status.

g. When the area is approved, it will enter testing. Any bugs that are found in initial testing will be the author's responsibility to find and fix unless they bribe the Area Coordinator to do it (Elf maidens, pitiful looks, etc). The author is obliged, in this test phase, to give any and all immortals who care a tour of the area and its high points. During this initial tour and while testing is underway, the bug hunters will scour the area for blown exits, typos, and other problems which the author will fix unless, as stated before, he/she successfully bribes the Area Coordinator.

h. Once the area is out of testing, the Area Coordinator is free to make adjustments as necessary to fix problems that crop up, or upgrade it to new TFC standards. The area belongs to TFC, and you do not retain possession.

i. Installed areas will have your name in the author spot of the area list, and on the boot installing it there is a 90% chance an associated quest will be run for players to find it. Rule 2 governs your actions in this quest and in people later asking directions to it - if you reveal its location, the area will be instantly gone and deleted from TFC.

TFC World View

2011-02-12T19:45:30Z

Thor:

'''What kind of areas are allowed on TFC?'''

What is the "world view" of The Final Challenge? Basically, it is the world view of DnD - gnomes, giants, giant-kin, ogres, aarakocrans, and so on. Each race has racial "hometowns" and they are arrayed around the map. Each race further has its own "natural" enemies - gnomes hate goblins and kobolds, and so on. For more information on the races, visit the [http://www.tfcmud.com TFC web page].

On the northern continent using Midgaard as a reference, far to the north are the cold mountains, east and west (as well as immediately north and south) are forests, far to the south are the deserts and the seas. There is some variation here and there, but that is the general geography in the defined zones.

South of the northern continent are the vast waters of the Maelmordian Seas. This is a very dangerous area with several sea monsters roaming about that could easily take down even a level 50 player. Scattered around the seas are islands, amoung them Mithas, Molotov Island, The Isle, Cannibal Island, Tier Sh'Halen, Skelos, and the Pirate Island. Most of the known island spots are claimed by authors, but the seas will be expanding along the northern and southern continent coastlines from time to time, and when that happens, new spaces for islands do emerge. There is also the possibility of writing undersea areas like the Sahuagin City.

On the far side of the seas from the northern continent lies the dark unknown...the southern continent. Starting from a coastline and moving inward to the mostly uncharted interiors, the south is a much wilder and less civilized place than the northern continent. The western side of the southern continent is the high ranges of the Oort mountains, and on the east are the forests and plains. Several rivers and lakes are to be found, and a scattering of towns and villages exist. There is only one large city, that of Safehaven on the coast where the Tiber meets the Maelmordian Seas. The landmass of the southern continent as currently laid out with connect zones is roughly six times the size of the northern continent, but it has half the areas within it, and therefore is open to quite a bit of development. We will not pile areas on top of areas, though, on the south, and areas that are proposed are reviewed not only for theme, but for the impact on the areas that would be adjacent to them.

Areas should be designed to fit in this world - both geographically and with respect to theme/genre. If they do not fit they won't go in...and making a fit is an integral part of the proposal process. Currently, the central corridor from the Whitefrost forest south through Midgaard to the oceans is closed to area development. Any areas designed must be placed elsewhere. Exceptions will only be made in cases where the author can show extreme need or usefulness. There will be opportunity to write areas to replace existing non-TFC specific areas. Should you be interested in doing this contact the Area Coordinator for the specific conditions and requirements involved.

Things that don't fit: Futuristic Areas, Modern 20th Century Areas, Areas that are illogically laid out, Areas that unbalance the game or are mis-rated, Areas that duplicate to a large extent other areas, and by ALL means NO SMURFS! You get the idea. Again, these things are determined as an integral part of the proposal process.

Area Building Tools

2011-02-12T19:45:05Z

Thor: Created page with "The offical editor for TFC is Sirak's Muditor, which can be found at [http://www.nashite.org/muditor.html http://www.nashite.org/muditor.html]. This was written by TFC's own Sira..."

The offical editor for TFC is Sirak's Muditor, which can be found at [http://www.nashite.org/muditor.html http://www.nashite.org/muditor.html]. This was written by TFC's own Sirak, and supports almost all of TFC's unique features. Over ninety percent of your development can be done within the editor, but you should still be able to read through the resulting .are file to make changes if needed. When submitting a draft or final version, only submit the .are file. The .srk file is simply a backup copy.

If you are editing the area file in anything other than the Muditor, be sure to save it as pure ASCII text. Notepad works well for this on Windows platforms, although older versions of Notepad will not be able to handle the entire file if you are a verbose author.

TFC World View

2011-02-12T19:43:34Z

Thor: Created page with "'''The TFC world view: what kind of areas are allowed on TFC?''' What is the "world view" of The Final Challenge? Basically, it is the world view of DnD - gnomes, giants, giant..."

'''The TFC world view: what kind of areas are allowed on TFC?'''

What is the "world view" of The Final Challenge? Basically, it is the world view of DnD - gnomes, giants, giant-kin, ogres, aarakocrans, and so on. Each race has racial "hometowns" and they are arrayed around the map. Each race further has its own "natural" enemies - gnomes hate goblins and kobolds, and so on. For more information on the races, visit the [http://www.tfcmud.com TFC web page].

On the northern continent using Midgaard as a reference, far to the north are the cold mountains, east and west (as well as immediately north and south) are forests, far to the south are the deserts and the seas. There is some variation here and there, but that is the general geography in the defined zones.

South of the northern continent are the vast waters of the Maelmordian Seas. This is a very dangerous area with several sea monsters roaming about that could easily take down even a level 50 player. Scattered around the seas are islands, amoung them Mithas, Molotov Island, The Isle, Cannibal Island, Tier Sh'Halen, Skelos, and the Pirate Island. Most of the known island spots are claimed by authors, but the seas will be expanding along the northern and southern continent coastlines from time to time, and when that happens, new spaces for islands do emerge. There is also the possibility of writing undersea areas like the Sahuagin City.

On the far side of the seas from the northern continent lies the dark unknown...the southern continent. Starting from a coastline and moving inward to the mostly uncharted interiors, the south is a much wilder and less civilized place than the northern continent. The western side of the southern continent is the high ranges of the Oort mountains, and on the east are the forests and plains. Several rivers and lakes are to be found, and a scattering of towns and villages exist. There is only one large city, that of Safehaven on the coast where the Tiber meets the Maelmordian Seas. The landmass of the southern continent as currently laid out with connect zones is roughly six times the size of the northern continent, but it has half the areas within it, and therefore is open to quite a bit of development. We will not pile areas on top of areas, though, on the south, and areas that are proposed are reviewed not only for theme, but for the impact on the areas that would be adjacent to them.

Areas should be designed to fit in this world - both geographically and with respect to theme/genre. If they do not fit they won't go in...and making a fit is an integral part of the proposal process. Currently, the central corridor from the Whitefrost forest south through Midgaard to the oceans is closed to area development. Any areas designed must be placed elsewhere. Exceptions will only be made in cases where the author can show extreme need or usefulness. There will be opportunity to write areas to replace existing non-TFC specific areas. Should you be interested in doing this contact the Area Coordinator for the specific conditions and requirements involved.

Things that don't fit: Futuristic Areas, Modern 20th Century Areas, Areas that are illogically laid out, Areas that unbalance the game or are mis-rated, Areas that duplicate to a large extent other areas, and by ALL means NO SMURFS! You get the idea. Again, these things are determined as an integral part of the proposal process.

Guidelines for Submitting Areas for TFC Inclusion

2011-02-12T19:41:10Z

Thor: Created page with "'''Guidelines for Submitting Areas for TFC Inclusion''' '''The Ultimate Rule''' - Areas will be written within the TFC spirit from the outset - no huge hoards of cash, no 100-1..."

'''Guidelines for Submitting Areas for TFC Inclusion'''

'''The Ultimate Rule''' - Areas will be written within the TFC spirit from the outset - no huge hoards of cash, no 100-150 damage super weapons, and so on... Writing such things just wastes everyone's time.

'''Submission Guidelines'''

All initial proposals and work are sent to the Co-Area Coordinators, Tokuagwa and Tamar. They should be mailed to mbeck@fastq.com and should cc Tynian at tynian@finalchallenge.net. The submission guidelines are as follows:

a1. Mortals considering writing an area must contact the Area Coordinator and have a level range assigned to them. Mortals must write the area to that level range - they do not have a choice on it.

a2. Mortals considering writing an area must be in good standing on the MUD. If they are not, they must wait.

a3. Mortals are limited to working on ONE area at a time.

a4. Mortals may submit areas under only ONE character name. At the time of writing an area, disclosure of ALL characters in your stable must be made. New characters made in the future must be reported as well. Refusal to do so, or incomplete disclosure, can lead to rejection of any and all areas. (There is no character flag involved so do not let that worry bother you.)

b1. Authors must submit a proposal of the area PRIOR to starting writing it. This proposal MUST include:

*The name of the area
*What level range you are targeting
*What location you are thinking of
*What theme you are thinking of
*Any special objects you want to include
*Any special tricks/traps/sneakiness involved

In short, the proposal should be about a page long and give me a broad overview of what I should expect. If it is omitted, the area will not be considered. Do not work on your proposed area until/unless it is accepted.

Proposals should be mailed to mbeck@fastq.com, and should cc Tynian at tynian@finalchallenge.net as mentioned above.

NO NEW CODE will be allowed. In other words, you are limited to the special functions in the approved lists. If there is an exceptional idea, this rule might be overlooked, but consider the fact that in all the first time author situations, only ONE ever received the approval for new code.

NO ILLOGICAL LINKS will be allowed without EXPRESSED prior approval. An illogical link is defined as a link that combines 2 directions (north+west
up+south), one that links an area in a loop (4 norths take you back to the same spot), or one that folds back on itself in some other way. A lot of time was spent laying the map out logically. Portals and things like mazes are fine, but they MUST be approved or the bug hunters will rip the area to shreds.

NO WWP ITEMS WITH AFFECTS are allowed in new areas.

b2. If the proposal is accepted, you will then be assigned a Vnum range to work with, and a base filename. This will be the final filename (e.g. midgaard.are). You will not use this base filename directly, instead, each version you create and send to the Area Coordinator will use the base filename with a letter appended. The first draft would be midgaardA.are, the second would be midgaardB.are, etc. This allows the Area Coordinator to keep an archive of your progress. You are likely to get to around G.

c. You must submit ALL objects in the area for prior review. All changes requested by the Area Coordinator will be governed by rule 6 above.

d. ALL authors will spell check their areas prior to each submission. A makeshift way to do this is to load a copy of the .are file into a program that spellchecks such as Word, allow it to find errors, and then make the changes in the real file in the Muditor. It is generally a bad idea to let the program do the spellchecking automatically, as small changes in the .are file will cause the area not to load (And thus crash the test mud).

e. ALL authors will include a comment block in the Resets, or in a separate email at the time of submission. This comment block will list the following information:
*Where the area connects to the outside world - room numbers AND door directions. Mortals can get the vnum of the connection room from a God+.
*A short statement on the theme of the area. This will be used as what your "intent" was should problems arise later on in the area's lifecycle.
*Any special details you wish to pass on to the Area Coordinator so he doesn't take them out during some wild edit spree.

f. Any authors wanting new code will confer with the Area Coordinator as to what they want, and if it is approved, will work with the Area Coordinator to write it. (Read that as you will write your own 90% of the time.) Remember that for mortals and first time authors, new code is at best a long shot, and continues to be so until someone has written several areas or has reached God+ status.

g. When the area is approved, it will enter testing. Any bugs that are found in initial testing will be the author's responsibility to find and fix unless they bribe the Area Coordinator to do it (Elf maidens, pitiful looks, etc). The author is obliged, in this test phase, to give any and all immortals who care a tour of the area and its high points. During this initial tour and while testing is underway, the bug hunters will scour the area for blown exits, typos, and other problems which the author will fix unless, as stated before, he/she successfully bribes the Area Coordinator.

h. Once the area is out of testing, the Area Coordinator is free to make adjustments as necessary to fix problems that crop up, or upgrade it to new TFC standards. The area belongs to TFC, and you do not retain possession.

i. Installed areas will have your name in the author spot of the area list, and on the boot installing it there is a 90% chance an associated quest will be run for players to find it. Rule 2 governs your actions in this quest and in people later asking directions to it - if you reveal its location, the area will be instantly gone and deleted from TFC.

Rules of Area Building for TFC

2011-02-12T19:32:17Z

Thor: Created page with "'''The rules of area building for TFC''' #Anyone with a character in their stable that is level 20 or higher may request permission to author an area. This is NOT a short cut to..."

'''The rules of area building for TFC'''

#Anyone with a character in their stable that is level 20 or higher may request permission to author an area. This is NOT a short cut to going immortal. Immortality just is not a requirement to authoring an area.
#Anyone writing an area will submit themselves to the following rules on the conduct of ALL their characters on the MUD:
##At no time will the nature of the items in your area be revealed to mortals. Make them find out what they do themselves.
##At no time will you collect items in your area and distribute them to mortals. Make them find where they are themselves.
##At no time will you give information on mob levels, traps, tricks, or any other feature of the area to mortals. Make them discover it for themselves.
##At no time will any other confidential information regarding your area, or any area or feature of TFC, be given out to mortals.
##For the first two months of your area's existence on the LIVE server of TFC you will not lead adventurers in your area.
##Violation of these rules (a subset of the wizrules) will be grounds for disciplinary action, up to and including deletion of characters.
#Areas written must be exclusive to TFC and not be run on any other MUD. If any area you write is found running on another MUD, all your areas will be removed from TFC. It may take us some time to replace them, and it will be painful for us to do so, but we WILL do it. Should we be forced to exercise this rule, the author in question will also be disallowed from writing any future areas for TFC.
#The theme of the area must fit the TFC World View. See the separate listing for what that is.
#The submission procedures will be followed EXACTLY.
#The Area Coordinator withholds the right to place, balance, or otherwise edit the area to make it fit in TFC. Authors will make all changes that are ordered, but may discuss any change requested in a ONE time appeal. If the appeal fails, the change must be made. Once an area is submitted, it belongs to The Final Challenge. The Area Coordinator, or future Area Coordinators, are free to make any changes they desire, and you do not retain possession of creative control.
#No area may have more than 100 rooms, 100 objects, and 100 mobs. These will be numbered from XX00 to XX99 inclusive, where XX is the assigned area vnum. Areas should be between 90-95 rooms, which gives the Area Coordinator a few rooms to use for later additions to the area, such as rooms connecting future areas to the area. You may be asked to write the connect rooms yourself. For large projects, a set of related areas may be done, but no single area can exceed these limits.
#Help in writing is available online in the HELPS or in hardcopy form from the Area Coordinator. If your question is answered in the TFC Area Writer's Guide, you will be directed to it...if not, the issue will be examined and handled when asked. The Guide is your first line of help...use it well. First time authors will receive special assistance...all others shall handle things themselves.

TFC Area Writer's Guide

2011-02-12T19:27:24Z

Thor:

'''The TFC Area Writer's Guide'''

Writing areas for The Final Challenge is a complex task. To simplify the process as much as possible, the Area Writer's Guide was created. This document describes the rules of area building, the guidelines for submission, the general themes that can be used, and the area file format that TFC uses.

'''General Overview of Area Building'''

[[The Rules of Area Building for TFC]]

[[Guidelines for Submitting Areas for TFC Inclusion]]

[[The TFC World View]]

[[Area Building Tools]]

[[Area Building Hints]]

[[Definition of Terms]]

'''The Layout of an Area File'''

[[The Area Header]]

[[The Helps Block]]

[[The Mobiles Block]]

[[The Objects Block]]

[[The Rooms Block]]

[[The Resets Block]]

[[The Shops Block]]

[[The Specials Block]]

[[The Triggers Block]]

[[The Rspecs Block]]

[[Types of Records]]

[[A Help Record]]

[[A Mob Record]]

[[An Object Record]]

[[A Room Record]]

[[A Reset Record]]

[[A Shop Record]]

[[Special, Trigger, and Rspec Records]]

'''Appendices'''

[[Appendix A: Aproved Spell Numbers]]

[[Appendix B: The Flag List]]

[[Appendix C: Item Type Value Specifications]]

[[Appendix D: Approved Specfuns]]

TFC Area Writer's Guide

2011-02-12T19:22:28Z

Thor: Created page with "'''The TFC Area Writer's Guide''' Writing areas for The Final Challenge is a complex task. To simplify the process as much as possible, the Area Writer's Guide was created. This..."

'''The TFC Area Writer's Guide'''

Writing areas for The Final Challenge is a complex task. To simplify the process as much as possible, the Area Writer's Guide was created. This document describes the rules of area building, the guidelines for submission, the general themes that can be used, and the area file format that TFC uses.

Table of Contents

[[General Overview of Area Building]]

[[The Rules of Area Building for TFC]]

[[Guidelines for Submitting Areas for TFC Inclusion]]

[[The TFC World View]]

[[Area Building Tools]]

[[Area Building Hints]]

[[Definition of Terms]]

The Layout of an Area File

[[The Area Header]]

[[The Helps Block]]

[[The Mobiles Block]]

[[The Objects Block]]

[[The Rooms Block]]

[[The Resets Block]]

[[The Shops Block]]

[[The Specials Block]]

[[The Triggers Block]]

[[The Rspecs Block]]

[[Types of Records]]

[[A Help Record]]

[[A Mob Record]]

[[An Object Record]]

[[A Room Record]]

[[A Reset Record]]

[[A Shop Record]]

[[Special, Trigger, and Rspec Records]]

Appendices

[[Appendix A: Aproved Spell Numbers]]

[[Appendix B: The Flag List]]

[[Appendix C: Item Type Value Specifications]]

[[Appendix D: Approved Specfuns]]

Area Writing Procedure

2011-02-12T19:13:43Z

Thor:

The general procedure for completing an area is as follows:

#Submit proposal to [mailto:tokugawatfc@gmail.com Tokugawa]. Please submit proposal as text within the email, ''not'' as an attachment.
#Proposal received and reviewed by [[Tokugawa]].
#Proposal returned for revisions or clarifications and resubmitted OR proposal accepted.
#[[Tynian]] creates area forum for author. Communication now takes place on forum.
#Author reads [http://mud.finalchallenge.net/tfc/world/style.shtml TFC Style Guide] and begins work on the area.
#Author submits vnum map, 3 sample rooms, mobs, and objects. (See sample.zip [http://forums.tfcmud.com/attachment.php?attachmentid=218&d=1255277371 here] for vnum map example.)
#Vnum map and samples are approved OR returned for editing.
#Vnum range is assigned.
#Author continues working on area, and then submits first draft.
#First draft is reviewed, and any changes necessary are made by the author.
#If necessary, second draft is submitted and reviewed, and any changes necessary are made by the author and/or [[Tamar]].
#Area is installed on test port for walk-through(s).
#Final editing is completed by Tokugawa & Tamar.
#Area is installed on TFC.

Additional information for writing areas can be found in the following locations:

* [http://forums.tfcmud.com/showthread.php/1127-Area-Status Area Status & Proposal Information]
* [http://mud.finalchallenge.net/tfc/world/style.shtml TFC Style Guide]
* [http://www.tfcmud.com/tfc/world/awg.shtml TFC Area Writer's Guide] (website)
* [[TFC Area Writer's Guide]] (wiki)
* [http://forums.tfcmud.com/showthread.php/1131-Things-to-check-before-first-draft-submission. Things to check before first draft submission].
* Download the [http://www.tfcmud.com/tfc/world/Muditor10272007.zip Muditor], an old DOS-based area editor.
* '''Or''', you can try [[Thor]]'s [http://forums.tfcmud.com/showthread.php/1700-Latest-version-of-Thor-s-Area-Creator Area Creator]. As of January 2011, it is considered "alpha" quality software. You'll want to save often and keep a periodic backup for your area file, as problems have been known to arise.
* [[Area Special Functions]] documentation.