De:Chapter 3

Help

Available languages

Missing languages

NPC Evolution

Erinnerst du dich an das grundlegende NPC Script aus Kapitel 1? Es war ein sehr allgemeines Script um einen nackten Mann (oder Spieler) zu erstellen. Es sah in etwa so aus:

[CHARDEF 0190]
DEFNAME=c_man
Name=Man
ICON=i_pet_MAN
CAN=MT_EQUIP|MT_WALK|MT_RUN|MT_USEHANDS
RESOURCES=i_flesh_head, i_flesh_torso, i_flesh_right_arm, i_flesh_left_arm
FOODTYPE=15 t_food, t_fruit
DESIRES=i_gold,e_notoriety
AVERSIONS=t_TRAP,t_eerie_stuff
SHELTER=r_house
BLOODCOLOR=0

TSPEECH=spk_human_prime
TSPEECH=spk_human_default
TEVENTS=e_Human_HearUnk
DESCRIPTION=Man
SUBSECTION=Miscellaneous
CATEGORY=Civilized

Wie du sehen kannst ist es ein eher unfertiges Script. Von allen Scripts in den spherechar_*.scp Dateien ist dies eines der Unvollständigsten. Hier ein etwas vollständigeres Beispiel eines NPC Scripts:

[CHARDEF 0490]
DEFNAME=C_H_ALCHEMIST
NAME=#NAMES_HUMANMALE the Alchemist
ID=C_MAN

DESIRES=i_gold,e_notoriety,t_magic
AVERSIONS=t_TRAP,t_eerie_stuff

TSPEECH=spk_human_prime
TSPEECH=jobalchemist
TSPEECH=spk_shopkeep
TSPEECH=spk_needs
TSPEECH=spk_rehello
TSPEECH=spk_human_default

TEVENTS=e_Human_HearUnk
TEVENTS=e_Human_ConvInit
TEVENTS=e_Human_Greet
TEVENTS=e_Human_Space
TEVENTS=e_Human_Needs
TEVENTS=e_Human_Refuse
TEVENTS=e_Human_Environ

CATEGORY=Civilized
SUBSECTION=Tradesmen
DESCRIPTION=Alchemist (male)

ON=@Create

NPC=brain_vendor

COLOR=colors_skin

STR={36 50}

DEX={36 50}

INT={51 65}

ALCHEMY={55.0 78.0}

TASTEID={55.0 78.0}

WRESTLING={15.0 38.0}

MAGICRESISTANCE={25.0 48.0}

TACTICS={15.0 38.0}

POISONING={35.0 55.0}

ITEMNEWBIE=random_male_hair

COLOR=colors_hair

ITEMNEWBIE=random_facial_hair

COLOR=match_hair

ON=@NPCRestock

ITEM=i_expcoin,3

ITEM=i_shirt_plain

COLOR=colors_all

ITEM=random_pants

COLOR=colors_all

ITEM=i_robe

COLOR=colors_red

ITEM=random_shoes

COLOR=colors_neutral

ITEM=random_coin_purse

SELL=VENDOR_S_ALCHEMIST

BUY=VENDOR_B_ALCHEMIST

[CHARDEF 0490] Wir haben das schon einmal gesehen. Es sagt quasi "Hey SPHERE! Alles nach dieser Zeile bis zum nächsten Header definiert einen Charakter!" Was wird dieser Charakter sein? Nun, im Moment wissen wir das noch nicht, für SPHERE ist das einfach nur ein Char mit der Nummer 0490. Diese 0490 sagt dem Client auch welche Animation er zeigen soll (das gilt nicht für Monster mit einem ID Feld, bei diesen wird die Animation aus dem ID Feld angezeigt). Statt einer Nummer kannst du auch den Char Defname im [CHARDEF x] Feld verwenden (was für neue NPCs besser ist). Zum Beispiel: [CHARDEF c_new_monster]

DEFNAME=C_H_ALCHEMIST Wer hätte es geglaubt: Das ist der Defname für dieses Script. Wir haben so etwas schon so oft gesehen, dass ich nicht glaube, dass ich es nochmal erklären muss. Letztendlich haben wir jetzt einen leichter zu merkenden Namen für dieses Script. Es ist offensichtlich ein Charakter (C), ein Mensch (H) (Englisch: human), und ein Alchemist (C_H_ALCHEMIST). Versuche deine DEFNAMEs sinnvoll nach dem zu benennen was der Charakter ist. Dieses Script z.B. "c_robed_man" zu nennen hätte keinen Sinn, da man es kaum zuordnen und sich auch schlecht merken könnte. :)

NAME=#NAMES_HUMANMALE the Alchemist Hier macht SPHERE ein paar irre Sachen. Als erstes, wie du vielleicht noch aus der Lektion SPHERE_NAME.SCP in Kapitel 2 weisst, ersetzt es #NAMES_HUMANMALE durch einen richtigen Namen für diesen NPC, wie z.B. "Fritz", "Bob" oder den immer wieder beliebten "Roderick". Als Zweites teilt es den Namen in ein NAME und ein TITLE. Aber wo wird der Name geteilt? Ganz einfach: Bei dem Wort "the". Das Schreiben dieser Zeile ist also gleichbedeutend mit der folgenden Schreibweise:

NAME=#NAMES_HUMANMALE
TITLE=the Alchemist

ID=C_MAN Hier sagen wir SPHERE was dieses Ding ist. Was ist C_MAN? Es ist natürlich ein DEFNAME, aber für was steht er? Schau einfach an den Anfang dieser Seite, dort wirst du die Definition eines C_MAN-Charakters finden.

Und so weiter. Wie du siehst haben wir einfach all das nochmal geschrieben was wir in dem vorherigen Abschnitt bereits hatten. Aber mit den neueren Versionen von SPHERE müssen wir das gar nicht mehr. Sofern wir nichts anderes sagen bekommt unser Charakter 0490 automatisch alles was auch standardmäßig bei einem C_MAN vorhanden ist, auch Fähigkeiten, Icons und Sounds. Beim Programmieren wird das Vererbung genannt. Der neue, spezifischere Charakter erbt die Eigenschaften des weniger Spezifischen.

Du hast sicher bemerkt, dass wir DESIRES (Wünsche, etw. begehren) und AVERSIONS (Abneigungen) noch einmal angegeben haben. Warum haben wir das wenn C_MAN uns durch die Vererbung doch bereits sagt was diese Art von Charakter will und nicht will? Nun, ich bin mir im Fall von AVERSIONS nicht sicher, denn beide sind gleich. Aber die Wünsche und Begehren (DESIRES) eines Alchemisten sind natürlich andere als die eines "gewöhnlichen" Mannes, deshalb sagen wir SPHERE: "Hey, ersetze die Wünsche des C_MAN mit unseren Neuen!"

TSPEECH= Was meinst du sind die kryptischen Namen die dieser Anweisung folgen? Natürlich, es sind DEFNAMES, aber was machen sie? Beim Durchsuchen deiner Dateien, wirst du die Definitionen dieser Namen wahrscheinlich nirgendwo finden.. Aber was ist das? Da ist ein Ordner "Speech" der bereits in der ZIP-Datei mit dabei ist (Anm. d. Ü.: Bei neuen Sphere Versionen im Community Script Pack). Wenn du dir diese Dateien anschaust, wirst du eine Menge [SPEECH] Block Definitionen sehen. Die Standarddefinitionen liegen im SPEECH Ordner unterhalb deines Script-Ordners.

Hier haben wir ein sehr einfaches Speech-Script. Das habe ich diesmal nicht aus den Scriptdateien.

[SPEECH spk_human_test]
ON=*hallo*
SAY Cheese!

Würden wir nun in unser obiges NPC-Script TSPEECH=spk_human_test einfügen, würde unser NPC mit "Cheese!" antworten, wenn wir ihn mit "hallo" ansprechen. Du wunderst dich vielleicht wieso ich im Script vor und hinter das "hallo" ein Sternchen (*) gesetzt habe. Im Programmierfachjargon bedeutet ein Sternchen "IRGENDETWAS". Du könntest also sagen "Ich möchte dich fressen hallo und auf Wiedersehen" und der NPC würde dir immernoch antworten: "Cheese!", weil das Wort "hallo" im Satz vorhanden ist.

SPEECH ist natürlich noch um einiges komplexer als das hier gezeigte, deshalb werden wir es uns noch einmal anschauen wenn wir das Kapitel des Basic Event Scriptings (Grundlagen des ereignisgesteuerten Scripings) erreichen. Für jetzt reicht es erst einmal noch zu wissen, dass du innerhalb des CHARDEF Bereichs so viele TSPEECH-Zeilen einfügen kannst wie du willst.

TEVENTS= Das haben wir bereits in Kapitel 1 behandelt, sind dabei aber nur sehr sehr wenig ins Detail gegangen. Hier werden die Events für die NPCs definiert. Wie du sehen kannst besitzt dieser NPC eine ganze Menge Events. Diese definieren alle seine Reaktionen, angefangen bei dem was er sagt wenn er ein unbekanntes Wort hört ("Huh?") bis hin zu dem was er macht wenn er einen neuen Spieler sieht. In Kapitel 8 werden wir uns solch ein Event Script einmal ansehen. Bevor du das Event Scripting versuchst solltest du aber erst die Grundlagen des Item Scriptings lernen. Für jetzt musst du erst einmal nur noch wissen, dass du alle TEVENTS eines NPCs mit Hilfe von <[REF].TEVENTS> abfragen kannst.

ON=@Create Genau genommen habe ich gelogen. @Create ist ein Event, und über das werden wir nun reden. Es ist es ein sehr spezielles Event, was daran so speziell ist werden wir auch gleich erörtern. Grundsätzlich bewirkt @Create, dass jede danach folgende Zeile verarbeitet wird (der gesamte rot markierte Bereich) sobald ein Objekt erstellt wird. Kreativ, was? (Ha, ha.) Auf die meisten der danach folgenden Zeilen werde ich dieses mal nicht eingehen, da sie für dich inzwischen alle einen Sinn ergeben sollten. Alles was du zu diesem Zeitpunkt wissen musst ist, dass die Sachen die du IN GAME ändern kannst, auf das Konto von @Create gehen. Das beinhaltet Stats, Skills, Nicht lootbare Items, Farben, Brain Types und TAGs (Obwohl Tags auch im CHARDEF definiert werden können. Das ist ein guter Weg um ein Tag auf alle NPCs mit diesem Chardef zu setzen ohne einen Restock anstoßen oder jeden einzelnen NPC ändern zu müssen) (Du weißt nicht was ein TAG ist? Gut so, das habe ich dir auch noch nicht erklärt.).

ALCHEMY={55.0 77.0} Diese Zeile kann sehr täuschen. Der Grund für die Täuschung ist die Art und Weise wie SPHERE Zahlen verarbeitet. SPHERE kann keine Dezimalzahlen lesen. 55.0 bedeutet nichts für SPHERE, es entfernt einfach das Dezimalzeichen. Ist es nicht praktisch, dass Skills intern als große Zahlen gespeichert werden? Sieh dir jetzt mal deine Skills im Ingame Menü an und suche einen Skill aus der nicht Null ist.

Er wird in etwa so aussehen: 42.0

Fuehre Ingame dieses Kommando aus: .set [Skillname] 42 (Natürlich musst du [Skillname] mit dem Skill deiner Wahl ersetzen. Schau in der spheretables.scp nach wenn der von dir verwendete Skillname nicht funktioniert) (Anm. d. Ueb.: Die Skillnamen sind Standardmäßig in Englisch, auch wenn eure Skillnamen im Skillmenü Deutsch aind). Was passiert nun? Dein Skill ist plötzlich auf 4.2 gesunken!! Ist das ein Fehler im Spiel? Nein, eigentlich passiert das weil beim Speichern der Skills der Dezimalpunkt entfernt wird. Wenn du 100.0 in Blacksmithing hast ist dein Skill in Wirklichkeit 1000. Wenn du 75.2 in einem Skill hast, ist er in Wirklichkeit 752.

Das scheint ein einfaches Konzept zu sein, deshalb gilt es auch fuer alle anderen Bereiche beim Scripten. Jedes mal wenn du eine Zahl wie 55.0 eingibst, entfernt SPHERE das Dezimalzeichen. D.h. unser obiges Beispiel ist eigentlich das selbe wie:

ALCHEMY={550 770}

Ist das nicht fies?

Spätestens wenn es um die Multiplikation von Zahlen geht, wirst du dir dieses Thema wieder in Erinnerung rufen müssen:

4 * 0.5

Sphere übersetzt das mit "4 mal 5" und anders als erwartet wird dein Ergebnis 20 statt 2 sein. Wie du dir sicher denken kannst, kann das massive Probleme verursachen. An dieser Stelle möchte ich erstmal nur auf dieses Problem hinweisen. In späteren Kapiteln werden ich dann zeigen wie man dieses Problem umgehen kann. (Schau dir für weitere Beispiele in denen diese fiesen Dezimalpunkte verwendet werden mal die Resource Table in der sphereregion.scp an.)

NPC=brain_vendor Ok, so I'm out of order. Deal with it. (Anm. v. Übersetzer: Hat jemand eine Idee wie man das ins deutsche übersetzen soll?) brain=Gehirn, vendor=Verkäufer

Alle NPCs im Spiel werden durch spezielle Intelligenzen kontrolliert welche bestimmen wie sie sich in bestimmten Situationen verhalten. Zum Beispiel ist dieser Alchemist ein "brain_vendor", das heisst er reagiert auf Kommandos wie "buy" oder "sell" indem er ein Verkaufsmenü öffnet. Es bedeutet auch dass er mehr Speicherplatz erhält um zusätzliche Informationen zu den Items die er an- und verkauft zu speichern. (Eigentlich sind es nur zusätzliche Container die zu diesem NPC gespeichert werden, aber mehr dazu später) Hier eine Liste aller verfügbaren Intelligenzen (Ich wette du errätst nie aus welcher Datei ich die habe):

[DEFNAME brains]
BRAIN_NONE 0 // Spieler: Kein Hirn. Passend, was? :)
BRAIN_ANIMAL 1 // Tiere: wander (herumlaufend), attack (attackierend) nur wenn es angegriffen wurde
BRAIN_HUMAN 2 // Mensch: wander (herumlaufend) und speak (sprechend)
BRAIN_HEALER 3 // Heiler: Heilt Geister in seiner Nähe
BRAIN_GUARD 4 // Wache: Attackiert böse Jungs (Spieler/NPCs mit negativem Karma) die du siehst
BRAIN_BANKER 5 // Bänker: Öffnet dir auf Wunsch dein Bankfach
BRAIN_VENDOR 6 // Verkäufer: Kauft und verkauft Sachen
BRAIN_BEGGAR 7 // Bettler: Folgt Spielern und stellt irritierende Fragen.
BRAIN_ANIMAL_TRAINER 8 // Trainer: Kann Tiere verwahren
BRAIN_THIEF 9 // Dieb: Kein Effekt bisher
BRAIN_MONSTER 10 // Böse: Attackiere jeden Spieler den du siehst
BRAIN_BERSERK 11 // Rasend: Attackiere alles was du siehst
BRAIN_UNDEAD 12 // Untot: Das gleiche wie bei Böse. Wird nur zur Unterscheidung verwendet.
BRAIN_DRAGON 13 // Drache: Speiht Feuer(setz das mal auf ein Kaninchen)
BRAIN_VENDOR_OFFDUTY 14 // Keine Ahnung was hier der Unterschied zu BRAIN_VENDOR ist
BRAIN_TOWNCRIER 2 // Gleiche Nummer wie brain_human, gleicher Effekt
brain_beserk brain_berserk // Das gleiche wie brain_berserk, nur um einige Fehler durch Tippfehler zu vermeiden

ITEMNEWBIE= Erstellt auf dem Char das entsprechende Item mit gesetztem attr_newbie.

ON=@NPCRestock Ich hab ein zweites mal gelogen! Das ist das zweite Event das du in diesem Script kennen lernst. Dieses Event wird angestoßen wenn Ingame ein "restock" ausgeführt wird. Das passiert alle paar Realtimestunden einmal oder wenn ein Staffler ".sector.restock" eingibt. Eingetragen wird hier alles Lootbare und was der NPC kaufen bzw. verkaufen können soll. In den meisten Fällen wird hier wieder einmal nur eine Vorlage (ein Template) eingetragen, du müsstest inzwischen also wissen was du machen musst. Aber ich erkläre es trotzdem nochmal anhand von zwei Zeilen:

SELL=VENDOR_S_ALCHEMIST
BUY=VENDOR_B_ALCHEMIST

Das definiert was ein Vendor kauft und verkauft? Aber woher kommen diese mysteriösen Listen mit den ganzen Items? Das sind natürlich Templates (Vorlagen) aus der Datei spheretemp_vend.scp. (Templates für Vendoren. Entwickler sind so kreativ.) Es ist natürlich immer eine gute Idee Dateien nach ihrem Inhalt zu benennen!  :)

--
Die Übersetzung endet hier. Wir wären für weitere Hilfe bei der Übersetzung sehr Dankbar. Hilf mit und Übersetze den nächsten Absatz :)
Mehr Infos wie man Übersetzt findest du auf dieser Seite: Wiki Übersetzung
--

Price is not defined anywhere on these BUY and SELL lines. Price is defined in a VALUE= line in an individual item script. If an item script does not have a VALUE= line, price is determined by multiplying the value of the resources in that item by the number of resources required. For example, if an item takes 8 iron ingots to make, and each ingot has a VALUE of 8 gold pieces, the entire item is going to be worth 64 gold. By default, things sell for half of the price you can buy them for.

I think that's all you need to know for now about scripting a new NPC. Right now, with your abilities, you can create new vendors, new monsters, and new animals that wander your world. But they don't do anything unique yet. They just behave like stronger or weaker versions of the same monsters. And they're probably pretty colors, too, judging from the recent use of my hues.mul file for colors 077a and 07a1. (I really should release a DEFNAME script for those.)

Now that you know how to make a decent NPC, let's explore ways to make unique items to put on him as loot. In the next section, we're going to make a SUPER DUPER BOW OF FIRE AND BRIMSTONE! *trumpet fanfare*

Advanced Item Scripting

The Super Duper Wand of Fire and Brimstone!

[ITEMDEF i_wand_sdwfb]
NAME=Super Duper Wand of Fire and Brimstone
ID=i_wand_1
TYPE=t_wand
RESOURCES=i_wand,10 i_scroll_flamestrike

ON=@Create

ATTR=attr_magic

MOREX=s_flamestrike

MOREY=50.0

MORE2=10

I tricked you that time! We STARTED with the script. No funny introductions. No livening up the article. Just a script. And a very interesting script it is too. You won't find it in any of your files. (In case you're wondering, SDBFB stands for "Super Duper Wand of Fire and Brimstone").

Now, what does this thing do? Well it's one of those handy predefined types that makes it do what it's supposed to do. Actually, it's not the only thing here that makes it do what it's supposed to do, but we'll see that in a moment!

[ITEMDEF i_wand_sdwfb] You should be able to tell me what this does by now. We're making a new item with DEFNAME i_wand_sdwfb.

Notice that we don't explicitly declare the DEFNAME, but put it in the ITEMDEF. It's the same thing.

NAME=

Duh.  :)

ID=i_wand_1

Once again, we're inheriting some properties here, including animation, skill type (macefighting oddly enough), etc from the definition of i_wand_1.

TYPE=t_wand

Remember in our NPC script, I said that the different brain types caused the NPCs to act different ways in certain situations. Well, in items, TYPE does the same thing. Only there are more of them. A lot more. Here are the specifications of the "t_wand" type. As you can see, we use all of them in the @Create section. Note: this line wouldn't be necessary since we're getting type=t_wand from the itemdef i_wand_1 too.

MOREX = the spell this wand will cast MOREY = the skill with which the spell will be cast MORE2 = the number of charges this wand has left

Every item does something different with the MOREs. Actually this is a good time to go through the variables available to you on an item. In a simple list:

• MORE1 (or MORE)
• MORE2
• MOREP
• COLOR
• TYPE
• CREATE
• LAYER
• ATTR
• LINK
• CONT
• TOPOBJ
• LINK

As we'll see, a few of these have special functions that will allow us to do a lot more. But that doesn't come until advanced scripting. And there are also a lot more things which you'll know in future chapters.

One of these properties (MOREP) has the weirdness that it can hold a coordinate of the form (x, y, z, m). Which means that it can be broken down into MOREX, MOREY, MOREZ, and MOREM. For example, if you write this line:

MOREP=1,2,3,4

It is exactly the same as writing:

MOREX=1
MOREY=2
MOREZ=3
MOREM=4

This is what you call in C++ programming a "union", basically meaning there are going to be restrictions on the amount of data you can store in each of these variables. MOREX and MOREY can both hold numbers up to 0FFFF. MOREZ can hold numbers from -128 to 127, and is always displayed in decimal. MOREM can hold numbers from 0 to 255, and is also always displayed in decimal.

Be sure that when you're writing a script, or an item, you don't use both MOREP and one of the other MOREP pieces (MOREX, etc). It won't work together, since one will overwrite the other.

MOREP=10,42,51,53
MOREX=78
MOREY=89
MOREM=56

MOREP now is equal to 78,89,51,56.

So you see, it doesn't work to use these together.

Another strangeness of SPHERE is that they have given us the properties MORE1L, MORE1H, MORE2L, and MORE2H. These are not entirely visible to you, but just know that they are pieces of the MORE1 and MORE2 properties. As such, you should not be using both MORE1 and either of the MORE1 properties, or the same for the MORE2 properties, on a single item.

MORE1=0FFFFFFFF
MORE1L=01234
MORE1H=0F0

Now MORE1 is 000F01234. Which would totally screw up any script you were writing involving the MORE1 property. So don't use both in the same script. (If you don't understand where that number came from, don't worry about it. I've never used MORE1L and MORE1H in a script, and chances are neither will you.)

We'll also see later how to use the ATTR property to give your item special properties (like being unmovable, or magical, or blessed). I'll put that in my massive chart that's going in the next section, which lists all the TYPEs and all of the ATTR values.

From what I've just explained to you, the rest of the item script, after the @Create event, should be obvious. We're setting the pieces of MOREP to be what we need them to be so our wand functions properly. And if you create this item in the game, and double-click it, you'll get a target to cast Flamestrike. That's all you need to do.

By the way, you could just as easily have written:

MOREP=s_flamestrike,50.0
MORE2L=10

Think about it.  :)

(Anyone know why the developers decided to have 10 variables named MORE? Standing for "MORE information about an item" perhaps?)

Understanding the @Create trigger

You're probably wandering why I didn't set the item properties (such as the mores) directly on the itemdef, that's because not everything can be set there, only general properties for the items with that id.

"But hey, I can set different names for an item with the same id"

Yes you can, but mostly you won't, another thing that can be set there but you can also change are TAGs (you'll see more on other chapters).

Things that you can't change for example are WEIGHT, VALUE, RESOURCES and of course the DEFNAME. There are more, but just to make you get the idea.

TYPEs

This section explains how you can use built-in item types, how to override the built-in types, and how you can make your own.

If you want to override a built-in typedef, that is indeed possible, just define its new behavior it in a script and since the scripts are loaded after the server starts, your new definition will take precedence.

A TYPEDEF is essentially a collection of triggers, and can be written to reference other aspects of the ITEMDEF, CHARDEF, or REGION that it is assigned to. To assign a TYPEDEF to an item, you can simply set TYPE=t_mytype in the ITEMDEF (Note: An item can only have one TYPE.)

Here is an example TYPEDEF:

[TYPEDEF t_horseshoes]
ON=@DClick
   TARGET What animal needs this item?
   RETURN 1
ON=@Targon_Char
   IF (<SRC.TARG.DEX> > 100)
      SRC.SYSMESSAGE @032 That animal does not need this item.
      RETURN 1
   ENDIF
   IF (<SRC.TARG.OBODY>==(c_horse_pack|c_llama_pack|c_horse_gray|c_horse_brown_dk|c_horse_brown_lt|c_llama))
      SRC.SYSMESSAGE @032 Now the animal is faster.
      SRC.TARG.MODDEX += <MORE1>
      SRC.EFFECT=3,0374a,6,15,1
      REMOVE
   ELSE
      SRC.SYSMESSAGE @032 That animal can not wear this item.
   ENDIF
   RETURN 1

Here is an example item that uses the t_horseshoes TYPEDEF shown above:

[ITEMDEF i_horse_shoes_magic]
ID=0fb6
NAME=magic horseshoes
TYPE=t_horseshoes
VALUE=35
WEIGHT=8.0
RESOURCES=8 i_ingot_iron
SKILLMAKE=Blacksmithing 30.0
CATEGORY=Items by Professions
SUBSECTION=Blacksmiths
DESCRIPTION=Magic Horse Shoes
ON=@Create
   MORE1={10 15}
   ATTR=attr_magic

ATTRs

This is a list of the ATTR flags available and what they do. I pulled it right out of spheredefs.scp

Value	DEFNAME	Description
01	attr_identified	Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
02	attr_decay	The item will decay when the internal decay timer, or the item's TIMER reaches zero.
04	attr_newbie	The item will not be placed in a corpse upon death.
08	attr_move_always	Anyone can pick this up, even if they shouldn't be able to normally. The item will not decay unless the decay flag is also set.
010	attr_move_never	Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
020	attr_magic	This item has been enchanted
040	attr_owned	This is owned by the town, and trying to pick it up will count as stealing. You will be flagged criminal if you try to use the Stealing skill on this item. It will never decay.
080	attr_invis	Invisible to non-GM clients
0100	attr_cursed	Cursed item, casts curse on the wearer while it's equipped
0200	attr_cursed2	I have no idea what the difference is.. strength maybe?
0400	attr_blessed	Casts bless on the person who is equipping it (stat gain)
0800	attr_blessed2	?
01000	attr_forsale	In a vendor's sell-box or buy-box.
02000	attr_stolen	This item has been stolen (from the town probably)
04000	attr_can_decay	I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
08000	attr_static	Makes it so an item doesn't highlight when a player passes the mouse over it. (Items will still highlight for GMs no matter what.)

You can, of course, have multiple ATTRs on a single item like this:

ATTR=attr_magic|attr_decay|attr_move_never

If you have a @Timer script on an item, you must have an attr_decay on that item. Otherwise you will get scary errors. You can always RETURN 1 from the @Timer script to prevent decay, but the flag must still be there.

Cool Commands

Or, how to make a huge number of NPCs die at once

There are a few often overlooked commands in the SPHERE scripting language, and the in-game command set. These are:

• .nuke
• .nukechar
• .region.sectors restock

You may not understand the format of the last command yet, but I will tell you how to use it anyway.

One thing that make SPHERE scripters do not realize is that the .nuke and .nukechar commands can take parameters, and that those parameters will be applied to any items within the targetted area.

Type .nuke and target a box. All the items disappear.

Now type .nuke color 02 and target a box. All the items in the box turn blue.

.nuke dupe is an interesting command that creates a duplicate of any item in the box.

.nukechar works the same way:

.nukechar kill will kill any NPC you target inside of the box.

Note: BOX can mean the world too, but if you target the ground it'll ask for a second targetting and will peform the actions in all chars/items in the area you selected)

Now, after you have spawned your world, if you make massive changes to your Vendor files, the changes WILL NOT take effect on already-spawned NPCs. And I'm sure you don't want to go around the world resetting every single vendor. But there's an easier way. Do these two commands in order:

.go 11 11 .region.sectors restock or just .region.restock

(since from 56b region.X will automatically access all the sectors of this region too)

Magically, all your Vendors will be restocked!

NOTE TO VETERANS: NEVER, EVER TYPE .region.restock all!!! It will freeze the server!

Extra: If you want to respawn all of your npcs across all maps you need to create a function to do that, here's an example:

[FUNCTION redospawns]
GO 1,1
FOR 0 4 //make loop through all 5 maps
    MAP = <LOCAL._FOR> //set the map
    FORCHARS 8000 //loop through all chars in the world (unless EA makes a map bigger than 8000x8000 squares)
        REF1 = <MEMORYFINDTYPE.memory_ispawned.LINK> //set REF1 to the spawngem of that npc
        IF (<REF1>) //checks if the npc has the spawn memory
            REF1.TIMER = <EVAL {<REF1.MOREX> <REF1.MOREY>} * 60> //set the spawn memory timer to the values specified when creating it
        ENDIF
    ENDFOR
ENDFOR