SphereWiki - User contributions [en]

De:Main Page

2014-04-22T17:32:05Z

Sirius: Removed old announcement

{{Languages|Main Page}}

Willkommen zum Remake von Taran's bekannter Seite: "[http://www.cs.rit.edu/~djr7581/ Sphere Scripting for Dummies tutorials]". Seine Tutorials waren damals für Sphere 55i erstellt worden, mittlerweile ist die aktuelle Version Sphere 56b und deshalb wurde entschieden, hier auf diesen Seiten eine Sammlung aktueller Tutorials und ein Kompendium neuer Funktionen zu bieten.

'''Wo fang ich nun an?'''

Jeder, der sich für die Skriptsprache von Sphere 56b interessiert, sollte hier anfangen: [[#Installation von Sphere|Installation von Sphere]]. Dort findet man die ersten Schritte mit Sphere. Danach empfiehlt es sich alle [[#Tutorials|Tutorials]] durch zu arbeiten, möglichst alles dabei zu verstehen und viel zu lernen.

'''Ich hab jetzt Skripten gelernt! Was nun?'''

Sind die ersten 10 Kapitels durchgearbeitet, dann gibt es hier natürlich noch weitere Artikel und Seiten. Sie erscheinen vielleicht nicht so wichtig, wie die anderen, aber sind dennoch mit weiterführenden und nützlichen Informationen gespickt. Versuche eigene Skripte zu entwickeln, sie vielleicht auch im [http://www.sphereserver.net/index.php SphereServer Forums] zu veröffentlichen. In den Forum erhält man auch weitere Hilfestellungen und Antworten auf Fragen. Des Weiteren ist auch das [[#Referenzkompendium|Referenzkompendium]] sehr nützlich.

'''Ich will mithelfen!'''

Um die Informationen auf diesen Seiten immer möglichst aktuell zu halten, ist natürlich viel Arbeit und Zeit notwendig. Jeder, der mithelfen möchte, diese Seiten zu pflegen, darf sich jederzeit hier anmelden und die Artikel hier überarbeiten. Alles, was man dafür braucht, ist ein [[Special:UserLogin|Wiki-Account]]. Oberhalb jeder Seite ist ein "Edit"-Link. Ausserdem sollte dieser Guide gelesen werden: [[de:Contribution Guide|Leitfaden für das SphereWiki]].

'''Dank geht speziell an:'''

[[WhoIsWho|Ben, Cloud_Br, Ellessar, Jdog, Lord Zerofiz, Mordaunt, Nazghul-ll, RanXerox, Rattlehead, Sandman, Sharlenwar, ShiryuX, thelegbra, Maximus and WarAngel]], für das Hinzufügen von Inhalt.

[[WhoIsWho|Daleth]], für das Erstellen des Sphere Reference Project, and [[WhoIsWho|Mordaunt]] für die Konvertierung ins .chm-Format.

[[WhoIsWho|Tracker]], für das Übertragen von Änderungen in Sphere 56 Tracking Changes.

[[WhoIsWho|Taran]], für die originalen Sphere Scripting for Dummies tutorials und [[WhoIsWho|MrSugarCube]], der ständige Neuerungen aktuell hält.

[[WhoIsWho|Furio, Radiant, Vjaka, Nazghul-ll, Ellessar, Torfo, Shadow Dragon and MrSugarCube]] für kontinuierliche Arbeit an Sphere, wodurch ein sehr mächtiger und an alle möglichen Bedürfnisse anpassbarer Ultima Online Emulator entstand.

[[WhoIsWho|Crius]], der das ursprüngliche Wiki gehostet hat, und [[WhoIsWho|Torfo]], der das Wiki momentan hostet.

----

==Installation von Sphere==

* [[de:Where to get Sphere|Sphere herunterladen]]
* [[de:Installing Sphere|Sphere installieren]]
* [[de:Configuring Sphere.ini|Konfigurationseinstellungen der Sphere.ini]]

==Tutorials==

Die Kapitel von Taran in aktualisierter Version für 56b:

* [[De:Chapter 1|Kapitel 1]] ''(Nummern, DEFNAME, ITEMDEF, CHARDEF)''
* [[De:Chapter 2|Kapitel 2]] ''(Übersicht über die Standardskripte)''
* [[De:Chapter 3|Kapitel 3]] ''(NPC's und Gegenstände, coole Funktionen)''
* [[Chapter 4|Kapitel 4]] ''(Objekte, Operatoren, Sprache)''
* [[Chapter 5|Kapitel 5]] ''(Tags, Vars, Locals, Functions)''
* [[Chapter 6|Kapitel 6]] ''(LINKs, TIMERs, TARGETs)''
* [[Chapter 7|Kapitel 7]] ''(Schleifen und mächtige Funktionen)''
* [[Chapter 8|Kapitel 8]] ''(SKILLMENUs, MENUs, Gumps)''
* [[Chapter 9|Kapitel 9]] ''(Events)''
* [[De:Chapter 10|Kapitel 10]] ''(Strings/Zeichenketten behandeln)''

Zusätzlich gibt es noch einige etwas fortgeschrittenere Tutorials, die von anderen Mitgliedern der Community bereitgestellt wurden. Nachdem man die 10 Kapitel durchgearbeitet hat, bieten sich die folgenden an, wenn man noch mehr lernen möchte:

* [[Common Mistakes|Häufige Fehler]] ''(A revision of Maximus's tutorial on the forums, and continuation of Taran's Misconceptions tutorial)''
* [[Internet and Sphere]] ''(And how to make the right use of them)''
* [[Languages Tutorial]] ''(How to script your own language system)''
* [[Making your own Skills]] ''(How to make and customize your skill)''
* [[Mul Patching Tutorial|Nazghul's Mul Patching Tutorial]] [http://sorea.profitux.cz/patching/ external link] ''(A document about mul patching and customizing your server)''
* [[Overriding Hardcoded Commands]] ''(How to override hardcoded commands and functions)''
* [[Scheduled Reboot]] ''(How to schedule system reboots)''
* [[Using MySQL]] ''(How to use MySQL)''

==Referenzkompendium==

* [[:Category:Definitions|Definitions]]
** [[CHARDEF|Characters]]
** [[DIALOG|Dialogs]]
** [[EVENTS|Events]]
** [[ITEMDEF|Items]]
** [[MENU|Menus]]
** [[REGIONRESOURCE|Region Resources]]
** [[REGIONTYPE|Region Types]]
** [[AREADEF|Regions]]
** [[ROOMDEF|Rooms]]
** [[SKILLCLASS|Skill Classes]]
** [[SKILLMENU|Skill Menus]]
** [[SKILL|Skills]]
** [[SPAWN|Spawn Groups]]
** [[SPELL|Spells]]
** [[TYPEDEF|Types]]
* [[:Category:Objects|Objects]]
** [[Accounts]]
** [[Characters]]
** [[Database]]
** [[Files]]
** [[GM Pages]]
** [[Items]]
*** [[Special Items]]
** [[Map Points]]
** [[Parties]]
** [[Regions]]
** [[Rooms]]
** [[Sectors]]
** [[Server]]
* [[:Category:Scripts|Scripts]]
** [[:Category:Functions|Functions and Triggers]]
** [[:Category:Variables|General Functions, Properties and References]]
** [[Intrinsic Functions]]
** [[:Category:Statements|Statements]]

==Andere Artikel==

* [[Armor Calculation]]
* [[Client Changes]]
* [[Common Scripting Misconceptions]]
* [[Custom Object Properties]]
* [[Error Codes]]
* [[Experience System]]
* [[How Combat Works]]
* [[Occam's Razor]]
* [[Optimization|Optimization Theory]]
* [[Override TAGs]]
* [[Revisions Changelog]]
* [[Sendpacket]]
* [[Skill Gain Theory]]
* [[The Process of Scripting]]

==External Links==

* [http://www.sphereserver.net/ Offizielle SphereServer Webseite]
* [http://forum.spherecommunity.net/ Alternatives SphereServer Forum]
* [http://prerelease.sphere.torfo.org/ Offizielle Sphere 56b Downloads]
* [http://nightly.prerelease.sphere.torfo.org/ Offizielle Sphere 56b Nightly Builds]
* [http://scriptsharing.dv-team.de/ ScriptSharing]
* [http://www.cs.rit.edu/~djr7581/ Taran's Scripting for Dummies (Sphere 55i)]
* [http://uo.torfo.org/packetguide/ Jerrith's UO Packet Guide]
* [http://uo.torfo.org/packetguideKR/ Wyatt&Kons's UOKR Packet Guide]

[[Category: Navigation]]

De:Chapter 3

2014-01-08T09:26:02Z

Sirius: /* NPC Evolution */ slightly better translation of a single word ;)

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

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):

<tt>[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 </tt>

'''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: [[De:Wiki_Translation|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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2013-06-07T17:21:11Z

Sirius: /* NPC Evolution */ German Translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

Ist das nicht hinterhältig?

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 hinterhältigen 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):

<tt>[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 </tt>

'''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: [[De:Wiki_Translation|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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2013-06-01T08:01:40Z

Sirius: /* NPC Evolution */ German translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

Ist das nicht hinterhältig?

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 hinterhältigen 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):

<tt>[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 </tt>

'''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'''

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2013-05-31T22:29:13Z

Sirius: /* NPC Evolution */ German Translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

Ist das nicht hinterhältig?

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 hinterhältigen 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):

<tt>[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 </tt>

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

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

Chapter 3

2013-05-30T14:08:10Z

Sirius: /* NPC Evolution */ Correct a logical mistake in coherence with the explanation of brain_beserk

{{Languages|Chapter_3}}

==NPC Evolution==
Remember in Chapter 1 when we looked at that basic NPC script? It was a generic script to create a naked man (or a naked player). And it looked something like this:

<tt>[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 </tt>

As you can see, this is a rather incomplete script. It's actually one of the least complete of any of the scripts available in the spherechar_*.scp files. Here is a more complete example of an NPC script:

<tt>[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 </tt>

'''[CHARDEF 0490]''' We've seen this before. It says "Hey SPHERE! Everything after this line until the next header is going to define a character!" What is this character going to be? Well, right now we have no idea, it's just 0490 to SPHERE. The 0490 also shows the client what anim to show (except for monsters with the ID field, which will show the ID field anim). You can also use the char defname in the [CHARDEF x] field instead of a number (which is better for new npcs), for example: [CHARDEF c_new_monster]

'''DEFNAME=C_H_ALCHEMIST''' This is the '''defname''' for this script, obviously. We've seen things like this so many times, I don't believe I need to go over it. But now at least we have a more memorable name for this script. It's obviously a character (C), a human (H), and an alchemist ('''C_H_ALCHEMIST'''). Try to make your '''DEFNAMEs''' make sense based on what the character is. Calling this c_robed_man would have absolutely no memorable qualities. :)

'''NAME=#NAMES_HUMANMALE the Alchemist''' This is where SPHERE does some funky stuff. First of all, if you remember from the SPHERE_NAME.SCP lesson in [[Chapter 2]], it is going to replace #NAMES_HUMANMALE with an actual name for this NPC, such as "Fritz", "Bob" or the ever popular "Roderick". The second thing it is going to do is divide this name into a NAME and a TITLE. Where does it do this division? At the word "the". So writing this line is equivalent to:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BERSERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2013-05-30T14:05:08Z

Sirius: /* NPC Evolution */ German Translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

Ist das nicht hinterhältig?

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 hinterhältigen 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):

<tt>[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 </tt>

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2013-05-30T14:00:52Z

Sirius: /* NPC Evolution */ German Translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

Ist das nicht hinterhältig?

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 hinterhältigen 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):

<tt>[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 // Durchgeknallt: 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 </tt>

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2013-05-30T08:58:43Z

Sirius: /* NPC Evolution */ Translation into German ... Please help me to translate one sentence I don`t know how I should translate.

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

Ist das nicht hinterhältig?

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 hinterhältigen 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 diese habe):

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2013-05-22T12:02:17Z

Sirius: /* NPC Evolution */ Translation into German and little correction in previous translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

Ist das nicht hinterhältig?

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 hinterhältigen Dezimalpunkte verwendet werden mal die Resource Table in der sphereregion.scp an.)

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-12-14T15:35:04Z

Sirius: /* NPC Evolution */ Translation into german

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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:

<tt>ALCHEMY={550 770}</tt>

Ist das nicht raffiniert?

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-12-13T06:29:46Z

Sirius: /* NPC Evolution */ German Translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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.

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-12-10T06:47:55Z

Sirius: /* NPC Evolution */ German translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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.

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-12-08T12:34:39Z

Sirius: /* NPC Evolution */ Translation into german

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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 mich dieses mal nicht konzentrieren, 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.).

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-05-05T07:20:33Z

Sirius: /* NPC Evolution */ More German translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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.

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-05-04T05:02:47Z

Sirius: /* NPC Evolution */ More German translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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.

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-04-22T07:04:28Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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.

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-04-22T06:39:54Z

Sirius: /* NPC Evolution */ More translation into German

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hallo*'' 
''SAY Cheese!'' </tt>

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 "hello" 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.

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-04-18T08:29:10Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-04-18T08:14:56Z

Sirius: /* NPC Evolution */ More German Translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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 denkst du bedeuten 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.

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Main Page

2012-03-13T11:46:04Z

Sirius: /* External Links */ Added alternate SpgereServer Forum

{{Languages|Main Page}}

'''Achtung Sphere Member (13/03/2012):''' Wir verwenden zur Zeit (http://spherecommunity.net), da "sphereserver.net" aus uns unbekannten Gründen seit einigen Wochen nicht mehr erreichbar ist. Die Seite ist KEIN Ersatz für die Originalseite, es ist lediglich eine Alternative wie SShare oder andere ähnliche Seiten auf denen sich unsere Community trifft und sich austauscht. Sphere kann weiterhin hier heruntergeladen werden (http://sphere.torfo.org/). Bitte gebt diese Info auch an andere weiter!

_________________________________________

Willkommen zum Remake von Taran's bekannter Seite: "[http://www.cs.rit.edu/~djr7581/ Sphere Scripting for Dummies tutorials]". Seine Tutorials waren damals für Sphere 55i erstellt worden, mittlerweile ist die aktuelle Version Sphere 56b und deshalb wurde entschieden, hier auf diesen Seiten eine Sammlung aktueller Tutorials und ein Kompendium neuer Funktionen zu bieten.

'''Wo fang ich nun an?'''

Jeder, der sich für die Skriptsprache von Sphere 56b interessiert, sollte hier anfangen: [[#Installation von Sphere|Installation von Sphere]]. Dort findet man die ersten Schritte mit Sphere. Danach empfiehlt es sich alle [[#Tutorials|Tutorials]] durch zu arbeiten, möglichst alles dabei zu verstehen und viel zu lernen.

'''Ich hab jetzt Skripten gelernt! Was nun?'''

Sind die ersten 10 Kapitels durchgearbeitet, dann gibt es hier natürlich noch weitere Artikel und Seiten. Sie erscheinen vielleicht nicht so wichtig, wie die anderen, aber sind dennoch mit weiterführenden und nützlichen Informationen gespickt. Versuche eigene Skripte zu entwickeln, sie vielleicht auch im [http://www.sphereserver.net/index.php SphereServer Forums] zu veröffentlichen. In den Forum erhält man auch weitere Hilfestellungen und Antworten auf Fragen. Des Weiteren ist auch das [[#Referenzkompendium|Referenzkompendium]] sehr nützlich.

'''Ich will mithelfen!'''

Um die Informationen auf diesen Seiten immer möglichst aktuell zu halten, ist natürlich viel Arbeit und Zeit notwendig. Jeder, der mithelfen möchte, diese Seiten zu pflegen, darf sich jederzeit hier anmelden und die Artikel hier überarbeiten. Alles, was man dafür braucht, ist ein [[Special:UserLogin|Wiki-Account]]. Oberhalb jeder Seite ist ein "Edit"-Link. Ausserdem sollte dieser Guide gelesen werden: [[de:Contribution Guide|Leitfaden für das SphereWiki]].

'''Dank geht speziell an:'''

[[WhoIsWho|Ben, Cloud_Br, Ellessar, Jdog, Lord Zerofiz, Mordaunt, Nazghul-ll, RanXerox, Rattlehead, Sandman, Sharlenwar, ShiryuX, thelegbra, Maximus and WarAngel]], für das Hinzufügen von Inhalt.

[[WhoIsWho|Daleth]], für das Erstellen des Sphere Reference Project, and [[WhoIsWho|Mordaunt]] für die Konvertierung ins .chm-Format.

[[WhoIsWho|Tracker]], für das Übertragen von Änderungen in Sphere 56 Tracking Changes.

[[WhoIsWho|Taran]], für die originalen Sphere Scripting for Dummies tutorials und [[WhoIsWho|MrSugarCube]], der ständige Neuerungen aktuell hält.

[[WhoIsWho|Furio, Radiant, Vjaka, Nazghul-ll, Ellessar, Torfo, Shadow Dragon and MrSugarCube]] für kontinuierliche Arbeit an Sphere, wodurch ein sehr mächtiger und an alle möglichen Bedürfnisse anpassbarer Ultima Online Emulator entstand.

[[WhoIsWho|Crius]], der das ursprüngliche Wiki gehostet hat, und [[WhoIsWho|Torfo]], der das Wiki momentan hostet.

----

==Installation von Sphere==

* [[de:Where to get Sphere|Sphere herunterladen]]
* [[de:Installing Sphere|Sphere installieren]]
* [[de:Configuring Sphere.ini|Konfigurationseinstellungen der Sphere.ini]]

==Tutorials==

Die Kapitel von Taran in aktualisierter Version für 56b:

* [[De:Chapter 1|Kapitel 1]] ''(Nummern, DEFNAME, ITEMDEF, CHARDEF)''
* [[De:Chapter 2|Kapitel 2]] ''(Übersicht über die Standardskripte)''
* [[De:Chapter 3|Kapitel 3]] ''(NPC's und Gegenstände, coole Funktionen)''
* [[Chapter 4|Kapitel 4]] ''(Objekte, Operatoren, Sprache)''
* [[Chapter 5|Kapitel 5]] ''(Tags, Vars, Locals, Functions)''
* [[Chapter 6|Kapitel 6]] ''(LINKs, TIMERs, TARGETs)''
* [[Chapter 7|Kapitel 7]] ''(Schleifen und mächtige Funktionen)''
* [[Chapter 8|Kapitel 8]] ''(SKILLMENUs, MENUs, Gumps)''
* [[Chapter 9|Kapitel 9]] ''(Events)''
* [[De:Chapter 10|Kapitel 10]] ''(Strings/Zeichenketten behandeln)''

Zusätzlich gibt es noch einige etwas fortgeschrittenere Tutorials, die von anderen Mitgliedern der Community bereitgestellt wurden. Nachdem man die 10 Kapitel durchgearbeitet hat, bieten sich die folgenden an, wenn man noch mehr lernen möchte:

* [[Common Mistakes|Häufige Fehler]] ''(A revision of Maximus's tutorial on the forums, and continuation of Taran's Misconceptions tutorial)''
* [[Internet and Sphere]] ''(And how to make the right use of them)''
* [[Languages Tutorial]] ''(How to script your own language system)''
* [[Making your own Skills]] ''(How to make and customize your skill)''
* [[Mul Patching Tutorial|Nazghul's Mul Patching Tutorial]] [http://sorea.profitux.cz/patching/ external link] ''(A document about mul patching and customizing your server)''
* [[Overriding Hardcoded Commands]] ''(How to override hardcoded commands and functions)''
* [[Scheduled Reboot]] ''(How to schedule system reboots)''
* [[Using MySQL]] ''(How to use MySQL)''

==Referenzkompendium==

* [[:Category:Definitions|Definitions]]
** [[CHARDEF|Characters]]
** [[DIALOG|Dialogs]]
** [[EVENTS|Events]]
** [[ITEMDEF|Items]]
** [[MENU|Menus]]
** [[REGIONRESOURCE|Region Resources]]
** [[REGIONTYPE|Region Types]]
** [[AREADEF|Regions]]
** [[ROOMDEF|Rooms]]
** [[SKILLCLASS|Skill Classes]]
** [[SKILLMENU|Skill Menus]]
** [[SKILL|Skills]]
** [[SPAWN|Spawn Groups]]
** [[SPELL|Spells]]
** [[TYPEDEF|Types]]
* [[:Category:Objects|Objects]]
** [[Accounts]]
** [[Characters]]
** [[Database]]
** [[Files]]
** [[GM Pages]]
** [[Items]]
*** [[Special Items]]
** [[Map Points]]
** [[Parties]]
** [[Regions]]
** [[Rooms]]
** [[Sectors]]
** [[Server]]
* [[:Category:Scripts|Scripts]]
** [[:Category:Functions|Functions and Triggers]]
** [[:Category:Variables|General Functions, Properties and References]]
** [[Intrinsic Functions]]
** [[:Category:Statements|Statements]]

==Andere Artikel==

* [[Armor Calculation]]
* [[Client Changes]]
* [[Common Scripting Misconceptions]]
* [[Custom Object Properties]]
* [[Error Codes]]
* [[Experience System]]
* [[How Combat Works]]
* [[Occam's Razor]]
* [[Optimization|Optimization Theory]]
* [[Override TAGs]]
* [[Revisions Changelog]]
* [[Sendpacket]]
* [[Skill Gain Theory]]
* [[The Process of Scripting]]

==External Links==

* [http://www.sphereserver.net/ Offizielle SphereServer Webseite]
* [http://forum.spherecommunity.net/ Alternatives SphereServer Forum]
* [http://prerelease.sphere.torfo.org/ Offizielle Sphere 56b Downloads]
* [http://nightly.prerelease.sphere.torfo.org/ Offizielle Sphere 56b Nightly Builds]
* [http://scriptsharing.dv-team.de/ ScriptSharing]
* [http://www.cs.rit.edu/~djr7581/ Taran's Scripting for Dummies (Sphere 55i)]
* [http://uo.torfo.org/packetguide/ Jerrith's UO Packet Guide]
* [http://uo.torfo.org/packetguideKR/ Wyatt&Kons's UOKR Packet Guide]

[[Category: Navigation]]

Main Page

2012-03-13T11:45:05Z

Sirius: /* External Links */ Corrected Typo

{{Languages|Main_Page}}

'''Attention Sphere Members (12/03/2012):''' We are using (http://spherecommunity.net) at the moment because "sphereserver.net" has been unavailable for a couple weeks now and we don't know the reasons. This is NOT a replacement for the original site, it's just an alternative link like SShare or other similar ones where our members meet each other and share stuff. You can still get the server files here (http://sphere.torfo.org/). Please spread the word!

_________________________________________

Welcome to the retake of Taran's famous "[http://www.cs.rit.edu/~djr7581/ Sphere Scripting for Dummies tutorials]" and information. His tutorial was made for Sphere 55i, but now that Sphere 56b is about to be released we have decided to rewrite his tutorials and update the information to reflect the latest changes and additions.

'''Where should I start?'''

If you want to learn to script for Sphere 56b you should start by first reading the [[#Setting Up Sphere|Setting Up Sphere]] section. It will teach you how to set up a basic empty world to start your path. After that you should try reading the [[#Tutorials|Tutorials]], go slow, don't try to go through everything in one day as it takes time to read and fully understand everything.

'''I learned how to script! And now?'''

If you have finished the 10 chapters then we encourage you to read the tutortials and other articles below. They may not be as important as the others but they are still quite useful and contain lots of useful information. Try making your own scripts and share with others at the [http://www.sphereserver.net/index.php SphereServer Forums]. You can also ask for help if you can't resolve something by yourself. Remember to use the [[#Reference Compendium|Reference Compendium]] below as it is really useful.

'''I want to contribute!'''

Maintaining the information on this site involves a huge amount of work and not many of us have the time to do it. If you wish to help out then please feel free to do so! All you need to do to get started is [[Special:UserLogin|create an account]] if you haven't done so already. You can then edit any page by using the "Edit" link in the rop right corner. Before you go do this, you may want to start by reading the [[Contribution Guide]].

'''Special thanks to:'''

[[WhoIsWho|Ben, Cloud_Br, Ellessar, Jdog, Lord Zerofiz, Mordaunt, Nazghul-ll, RanXerox, Rattlehead, Sandman, Sharlenwar, ShiryuX, thelegbra, Maximus and WarAngel]], for helping to add content.

[[WhoIsWho|Daleth]], for writing the Sphere Reference Project, and [[WhoIsWho|Mordaunt]] for converting it to .chm format.

[[WhoIsWho|Tracker]], for writing the Sphere 56 Tracking Changes in Sphereserver.net

[[WhoIsWho|Taran]], for writing the original and now famous Sphere Scripting for Dummies tutorials, and [[WhoIsWho|MrSugarCube]] for bringing it up-to-date directly from source.

[[WhoIsWho|Furio, Radiant, Vjaka, Nazghul-ll, Ellessar, Torfo, Shadow Dragon and MrSugarCube]] for continuing to develop Sphere into a powerful and very customizable Ultima Online emulator.

[[WhoIsWho|Crius]], for providing hosting for the original SphereWiki, and [[WhoIsWho|Torfo]] for providing the current hosting.

----

==Setting up Sphere==

* [[Where to get Sphere]]
* [[Installing Sphere]]
* [[Configuring Sphere.ini]]

While the main forum of Sphereserver is currently down , you are welcome to visit this other Sphere forum [http://scriptsharing.dv-team.de ScriptingShare] or [http://forum.spherecommunity.net SphereCommunity.net]. '''Spread the word !'''

==Tutorials==

Here are the chapters of Taran's original compendium, updated for Sphere56b:

* [[Chapter 1]] ''(Numbers, DEFNAME, ITEMDEF, CHARDEF)''
* [[Chapter 2]] ''(Sphere files explained)''
* [[Chapter 3]] ''(Scripting NPC's and items, Cool commands)''
* [[Chapter 4]] ''(Objects, operators, speech)''
* [[Chapter 5]] ''(Tags, Vars, Locals, Functions)''
* [[Chapter 6]] ''(LINKs, TIMERs, TARGETs)''
* [[Chapter 7]] ''(Loops and powerful functions)''
* [[Chapter 8]] ''(SKILLMENUs, MENUs, Gumps)''
* [[Chapter 9]] ''(Events)''
* [[Chapter 10]] ''(String Handling)''

In addition to these there are some more advanced tutorials that have been contributed by other members. Once you have read the above 10 tutorials you may wish to read these to learn more:

* [[Common Mistakes|Common Mistakes Explained]] ''(A revision of Maximus's tutorial on the forums, and continuation of Taran's Misconceptions tutorial)''
* [[Internet and Sphere]] ''(And how to make the right use of them)''
* [[Languages Tutorial]] ''(How to script your own language system)''
* [[Making your own Skills]] ''(How to make and customize your skill)''
* [[Mul Patching Tutorial|Nazghul's Mul Patching Tutorial]] [http://sorea.profitux.cz/patching/ external link] ''(A document about mul patching and customizing your server)''
* [[Overriding Hardcoded Commands]] ''(How to override hardcoded commands and functions)''
* [[Scheduled Reboot]] ''(How to schedule system reboots)''
* [[Using MySQL]] ''(How to use MySQL)''

==Reference Compendium==

* [[:Category:Definitions|Definitions]]
** [[CHARDEF|Characters]]
** [[DIALOG|Dialogs]]
** [[EVENTS|Events]]
** [[ITEMDEF|Items]]
** [[MENU|Menus]]
** [[REGIONRESOURCE|Region Resources]]
** [[REGIONTYPE|Region Types]]
** [[AREADEF|Regions]]
** [[ROOMDEF|Rooms]]
** [[SKILLCLASS|Skill Classes]]
** [[SKILLMENU|Skill Menus]]
** [[SKILL|Skills]]
** [[SPAWN|Spawn Groups]]
** [[SPELL|Spells]]
** [[TYPEDEF|Types]]
* [[:Category:Objects|Objects]]
** [[Accounts]]
** [[Characters]]
** [[Database]]
** [[Files]]
** [[GM Pages]]
** [[Items]]
*** [[Special Items]]
** [[Map Points]]
** [[Parties]]
** [[Regions]]
** [[Rooms]]
** [[Sectors]]
** [[Server]]
* [[:Category:Scripts|Scripts]]
** [[:Category:Functions|Functions and Triggers]]
** [[:Category:Variables|General Functions, Properties and References]]
** [[Intrinsic Functions]]
** [[:Category:Statements|Statements]]

==Other Articles==

* [[Armor Calculation]]
* [[Client Changes]]
* [[Common Scripting Misconceptions]]
* [[Custom Object Properties]]
* [[Error Codes]]
* [[Experience System]]
* [[How Combat Works]]
* [[Occam's Razor]]
* [[Optimization|Optimization Theory]]
* [[Override TAGs]]
* [[Revisions Changelog]]
* [[Sendpacket]]
* [[Skill Gain Theory]]
* [[The Process of Scripting]]

==External Links==

* [http://www.sphereserver.net/ Official SphereServer Website]
* [http://forum.spherecommunity.net/ Alternate SphereServer Forum]
* [http://prerelease.sphereserver.net/ Official Sphere 56b Downloads]
* [http://scriptsharing.dv-team.de/ ScriptSharing]
* [http://www.cs.rit.edu/~djr7581/ Taran's Scripting for Dummies (Sphere 55i)]
* [http://uo.torfo.org/packetguide/ Jerrith's UO Packet Guide]
* [http://uo.torfo.org/packetguideKR/ Wyatt&Kons's UOKR Packet Guide]

[[Category: Navigation]]
[[de:Main Page/de]]

Pag Principal

2012-03-13T11:30:44Z

Sirius: Added correct Laguagebar that contains all languages

{{Languages|Main_Page}}

[[Archivo:http://prerelease.sphere.torfo.org/images/logo4.jpg|border|100px]]
== Breve Introducción ==

Bienvenido a la "SphereWiki". Esta wiki es una recopilación de casi todos, por no decir todos los conocimientos útiles para trabajar con "SphereServer".

SphereServer es un emulador del juego MMORPG "Ultima Online".

== Cómo puedo Empezar ==

Para empezar ve la sección [[Iniciando Sphere]], y revisa como poner en funcionamiento tu versión de este emulador. Luego lee "los 10 Tutoriales de Taran", los cuáles aparecen a continuación.

== Los 10 Tutoriales de Taran ==

Házlos con tranquilidad y paciencia. No intentes comprenderlo todo en un día, es mejor hacerlo tranquila y pausadamente asimilando los conceptos de sintaxis del emulador.

* [[Capítulo 1]]''-Números, DEFNAME, ITEMDEF y CHARDEF''
* [[Capítulo 2]]''-Explicación de los archivos de SphereServer''
* [[Capítulo 3]]''-Scriptar NPCs y Objetos''
* [[Capítulo 4]]''-Objects, Operators y Speech''
* [[Capítulo 5]]''-Tags,Vars,Locals y Functions''
* [[Capítulo 6]]''-LINKs, TIMERs y TARGETs''
* [[Capítulo 7]]''-Bucles y funciones potentes''
* [[Capítulo 8]]''-Menús y Gumps''
* [[Capítulo 9]]''-Eventos''
* [[Capítulo 10]]''-Manejo de Cadenas''

==Otros Tutoriales==

* [[Common Mistakes|Common Mistakes Explained]] ''(A revision of Maximus's tutorial on the forums, and continuation of Taran's Misconceptions tutorial)''
* [[Internet y Sphere]] ''(Y cómo hacer un uso correcto)''
* [[Tutorial de Lenguajes]] ''(Cómo scriptar tu propio sistema de lenguaje)''
* [[Haciendo tus propias skill]] ''(Como hacer y personalizar tus skill)''
* [[Mul Patching Tutorial|Nazghul's Mul Patching Tutorial]] [http://sorea.profitux.cz/patching/ external link] ''(A document about mul patching and customizing your server)''
* [[Overriding Hardcoded Commands]] ''(How to override hardcoded commands and functions)''
* [[Scheduled Reboot]] ''(How to schedule system reboots)''
* [[Usando MySQL]] ''(Como usar MySQL)''

==Referencias==

* [[:Category:Definitions|Definitions]]
** [[CHARDEF|Characters]]
** [[DIALOG|Dialogs]]
** [[EVENTS|Events]]
** [[ITEMDEF|Items]]
** [[MENU|Menus]]
** [[REGIONRESOURCE|Region Resources]]
** [[REGIONTYPE|Region Types]]
** [[AREADEF|Regions]]
** [[ROOMDEF|Rooms]]
** [[SKILLCLASS|Skill Classes]]
** [[SKILLMENU|Skill Menus]]
** [[SKILL|Skills]]
** [[SPAWN|Spawn Groups]]
** [[SPELL|Spells]]
** [[TYPEDEF|Types]]
* [[:Category:Objects|Objects]]
** [[Accounts]]
** [[Characters]]
** [[Database]]
** [[Files]]
** [[GM Pages]]
** [[Items]]
*** [[Special Items]]
** [[Map Points]]
** [[Parties]]
** [[Regions]]
** [[Rooms]]
** [[Sectors]]
** [[Server]]
* [[:Category:Scripts|Scripts]]
** [[:Category:Functions|Functions and Triggers]]
** [[:Category:Variables|General Functions, Properties and References]]
** [[Intrinsic Functions]]
** [[:Category:Statements|Statements]]

==Othes Artículos==

* [[Armor Calculation]]
* [[Client Changes]]
* [[Common Scripting Misconceptions]]
* [[Custom Object Properties]]
* [[Error Codes]]
* [[Experience System]]
* [[How Combat Works]]
* [[Occam's Razor]]
* [[Optimization|Optimization Theory]]
* [[Override TAGs]]
* [[Revisions Changelog]]
* [[Sendpacket]]
* [[Skill Gain Theory]]
* [[The Process of Scripting]]

==External Links==

* [http://www.sphereserver.net/ Official SphereServer Website]
* [http://prerelease.sphere.torfo.org/ Official Sphere 56b Downloads]
* [http://nightly.prerelease.sphere.torfo.org/ Official Sphere 56b Nightly Builds]
* [http://scriptsharing.dv-team.de/ ScriptSharing]
* [http://www.cs.rit.edu/~djr7581/ Taran's Scripting for Dummies (Sphere 55i)]
* [http://uo.torfo.org/packetguide/ Jerrith's UO Packet Guide]
* [http://uo.torfo.org/packetguideKR/ Wyatt&Kons's UOKR Packet Guide]

De:Main Page

2012-03-13T11:27:59Z

Sirius: Added Translation of alternative meeting point for sphereserver.net-community

{{Languages|Main Page}}

'''Achtung Sphere Member (13/03/2012):''' Wir verwenden zur Zeit (http://spherecommunity.net), da "sphereserver.net" aus uns unbekannten Gründen seit einigen Wochen nicht mehr erreichbar ist. Die Seite ist KEIN Ersatz für die Originalseite, es ist lediglich eine Alternative wie SShare oder andere ähnliche Seiten auf denen sich unsere Community trifft und sich austauscht. Sphere kann weiterhin hier heruntergeladen werden (http://sphere.torfo.org/). Bitte gebt diese Info auch an andere weiter!

_________________________________________

Willkommen zum Remake von Taran's bekannter Seite: "[http://www.cs.rit.edu/~djr7581/ Sphere Scripting for Dummies tutorials]". Seine Tutorials waren damals für Sphere 55i erstellt worden, mittlerweile ist die aktuelle Version Sphere 56b und deshalb wurde entschieden, hier auf diesen Seiten eine Sammlung aktueller Tutorials und ein Kompendium neuer Funktionen zu bieten.

'''Wo fang ich nun an?'''

Jeder, der sich für die Skriptsprache von Sphere 56b interessiert, sollte hier anfangen: [[#Installation von Sphere|Installation von Sphere]]. Dort findet man die ersten Schritte mit Sphere. Danach empfiehlt es sich alle [[#Tutorials|Tutorials]] durch zu arbeiten, möglichst alles dabei zu verstehen und viel zu lernen.

'''Ich hab jetzt Skripten gelernt! Was nun?'''

Sind die ersten 10 Kapitels durchgearbeitet, dann gibt es hier natürlich noch weitere Artikel und Seiten. Sie erscheinen vielleicht nicht so wichtig, wie die anderen, aber sind dennoch mit weiterführenden und nützlichen Informationen gespickt. Versuche eigene Skripte zu entwickeln, sie vielleicht auch im [http://www.sphereserver.net/index.php SphereServer Forums] zu veröffentlichen. In den Forum erhält man auch weitere Hilfestellungen und Antworten auf Fragen. Des Weiteren ist auch das [[#Referenzkompendium|Referenzkompendium]] sehr nützlich.

'''Ich will mithelfen!'''

Um die Informationen auf diesen Seiten immer möglichst aktuell zu halten, ist natürlich viel Arbeit und Zeit notwendig. Jeder, der mithelfen möchte, diese Seiten zu pflegen, darf sich jederzeit hier anmelden und die Artikel hier überarbeiten. Alles, was man dafür braucht, ist ein [[Special:UserLogin|Wiki-Account]]. Oberhalb jeder Seite ist ein "Edit"-Link. Ausserdem sollte dieser Guide gelesen werden: [[de:Contribution Guide|Leitfaden für das SphereWiki]].

'''Dank geht speziell an:'''

[[WhoIsWho|Ben, Cloud_Br, Ellessar, Jdog, Lord Zerofiz, Mordaunt, Nazghul-ll, RanXerox, Rattlehead, Sandman, Sharlenwar, ShiryuX, thelegbra, Maximus and WarAngel]], für das Hinzufügen von Inhalt.

[[WhoIsWho|Daleth]], für das Erstellen des Sphere Reference Project, and [[WhoIsWho|Mordaunt]] für die Konvertierung ins .chm-Format.

[[WhoIsWho|Tracker]], für das Übertragen von Änderungen in Sphere 56 Tracking Changes.

[[WhoIsWho|Taran]], für die originalen Sphere Scripting for Dummies tutorials und [[WhoIsWho|MrSugarCube]], der ständige Neuerungen aktuell hält.

[[WhoIsWho|Furio, Radiant, Vjaka, Nazghul-ll, Ellessar, Torfo, Shadow Dragon and MrSugarCube]] für kontinuierliche Arbeit an Sphere, wodurch ein sehr mächtiger und an alle möglichen Bedürfnisse anpassbarer Ultima Online Emulator entstand.

[[WhoIsWho|Crius]], der das ursprüngliche Wiki gehostet hat, und [[WhoIsWho|Torfo]], der das Wiki momentan hostet.

----

==Installation von Sphere==

* [[de:Where to get Sphere|Sphere herunterladen]]
* [[de:Installing Sphere|Sphere installieren]]
* [[de:Configuring Sphere.ini|Konfigurationseinstellungen der Sphere.ini]]

==Tutorials==

Die Kapitel von Taran in aktualisierter Version für 56b:

* [[De:Chapter 1|Kapitel 1]] ''(Nummern, DEFNAME, ITEMDEF, CHARDEF)''
* [[De:Chapter 2|Kapitel 2]] ''(Übersicht über die Standardskripte)''
* [[De:Chapter 3|Kapitel 3]] ''(NPC's und Gegenstände, coole Funktionen)''
* [[Chapter 4|Kapitel 4]] ''(Objekte, Operatoren, Sprache)''
* [[Chapter 5|Kapitel 5]] ''(Tags, Vars, Locals, Functions)''
* [[Chapter 6|Kapitel 6]] ''(LINKs, TIMERs, TARGETs)''
* [[Chapter 7|Kapitel 7]] ''(Schleifen und mächtige Funktionen)''
* [[Chapter 8|Kapitel 8]] ''(SKILLMENUs, MENUs, Gumps)''
* [[Chapter 9|Kapitel 9]] ''(Events)''
* [[De:Chapter 10|Kapitel 10]] ''(Strings/Zeichenketten behandeln)''

Zusätzlich gibt es noch einige etwas fortgeschrittenere Tutorials, die von anderen Mitgliedern der Community bereitgestellt wurden. Nachdem man die 10 Kapitel durchgearbeitet hat, bieten sich die folgenden an, wenn man noch mehr lernen möchte:

* [[Common Mistakes|Häufige Fehler]] ''(A revision of Maximus's tutorial on the forums, and continuation of Taran's Misconceptions tutorial)''
* [[Internet and Sphere]] ''(And how to make the right use of them)''
* [[Languages Tutorial]] ''(How to script your own language system)''
* [[Making your own Skills]] ''(How to make and customize your skill)''
* [[Mul Patching Tutorial|Nazghul's Mul Patching Tutorial]] [http://sorea.profitux.cz/patching/ external link] ''(A document about mul patching and customizing your server)''
* [[Overriding Hardcoded Commands]] ''(How to override hardcoded commands and functions)''
* [[Scheduled Reboot]] ''(How to schedule system reboots)''
* [[Using MySQL]] ''(How to use MySQL)''

==Referenzkompendium==

* [[:Category:Definitions|Definitions]]
** [[CHARDEF|Characters]]
** [[DIALOG|Dialogs]]
** [[EVENTS|Events]]
** [[ITEMDEF|Items]]
** [[MENU|Menus]]
** [[REGIONRESOURCE|Region Resources]]
** [[REGIONTYPE|Region Types]]
** [[AREADEF|Regions]]
** [[ROOMDEF|Rooms]]
** [[SKILLCLASS|Skill Classes]]
** [[SKILLMENU|Skill Menus]]
** [[SKILL|Skills]]
** [[SPAWN|Spawn Groups]]
** [[SPELL|Spells]]
** [[TYPEDEF|Types]]
* [[:Category:Objects|Objects]]
** [[Accounts]]
** [[Characters]]
** [[Database]]
** [[Files]]
** [[GM Pages]]
** [[Items]]
*** [[Special Items]]
** [[Map Points]]
** [[Parties]]
** [[Regions]]
** [[Rooms]]
** [[Sectors]]
** [[Server]]
* [[:Category:Scripts|Scripts]]
** [[:Category:Functions|Functions and Triggers]]
** [[:Category:Variables|General Functions, Properties and References]]
** [[Intrinsic Functions]]
** [[:Category:Statements|Statements]]

==Andere Artikel==

* [[Armor Calculation]]
* [[Client Changes]]
* [[Common Scripting Misconceptions]]
* [[Custom Object Properties]]
* [[Error Codes]]
* [[Experience System]]
* [[How Combat Works]]
* [[Occam's Razor]]
* [[Optimization|Optimization Theory]]
* [[Override TAGs]]
* [[Revisions Changelog]]
* [[Sendpacket]]
* [[Skill Gain Theory]]
* [[The Process of Scripting]]

==External Links==

* [http://www.sphereserver.net/ Offizielle SphereServer Webseite]
* [http://prerelease.sphere.torfo.org/ Offizielle Sphere 56b Downloads]
* [http://nightly.prerelease.sphere.torfo.org/ Offizielle Sphere 56b Nightly Builds]
* [http://scriptsharing.dv-team.de/ ScriptSharing]
* [http://www.cs.rit.edu/~djr7581/ Taran's Scripting for Dummies (Sphere 55i)]
* [http://uo.torfo.org/packetguide/ Jerrith's UO Packet Guide]
* [http://uo.torfo.org/packetguideKR/ Wyatt&Kons's UOKR Packet Guide]

[[Category: Navigation]]

De:Chapter 3

2012-01-13T10:42:11Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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!"

-- 
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: [[De:Wiki_Translation|Wiki Übersetzung]] 
--

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-01-13T10:33:32Z

Sirius: /* NPC Evolution */ German Translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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!"

-- 
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: [http://wiki.sphere.torfo.org/index.php/De:Wiki_Translation Wiki Übersetzung] 
--

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-01-11T10:20:24Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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 dies Vererbung genannt. Der neue, spezifischere Charakter erbt die Eigenschaften des weniger Spezifischen.

-- 
Die Übersetzung endet hier. Wer möchte darf gerne weiter Übersetzen :) 
--

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2012-01-06T14:05:46Z

Sirius: /* NPC Evolution */ German translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''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.

-- 
Die Übersetzung endet hier. Wer möchte darf gerne weiter Übersetzen :) 
--

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2011-09-23T10:20:16Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

-- 
Die Übersetzung endet hier. Wer möchte darf gerne weiter Übersetzen :) 
--

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2011-09-23T10:19:25Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 [[De:Chapter 2|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 er 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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

-- 
Die Übersetzung endet hier. Wer möchte darf gerne weiter Übersetzen :) 
--

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2011-09-23T10:17:22Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 dich vielleicht noch aus der Lektion SPHERE_NAME.SCP in [[De:Chapter 2|Kapitel 2]] erinnern kannst, 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 er 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:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

-- 
Die Übersetzung endet hier. Wer möchte darf gerne weiter Übersetzen :) 
--

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2011-09-20T10:50:16Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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. :)

-- 
Die Übersetzung endet hier. Wer möchte darf gerne weiter Übersetzen :) 
--

'''NAME=#NAMES_HUMANMALE the Alchemist''' This is where SPHERE does some funky stuff. First of all, if you remember from the SPHERE_NAME.SCP lesson in [[Chapter 2]], it is going to replace #NAMES_HUMANMALE with an actual name for this NPC, such as "Fritz", "Bob" or the ever popular "Roderick". The second thing it is going to do is divide this name into a NAME and a TITLE. Where does it do this division? At the word "the". So writing this line is equivalent to:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2011-09-20T10:49:32Z

Sirius: /* NPC Evolution */ German Translation

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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 "c_robed_man" zu nennen hätte keinen Sinn, da man es kaum zuordnen und sich auch schlecht merken könnte. :)

-- 
Die Übersetzung endet hier. Wer möchte darf gerne weiter Übersetzen :) 
--

'''NAME=#NAMES_HUMANMALE the Alchemist''' This is where SPHERE does some funky stuff. First of all, if you remember from the SPHERE_NAME.SCP lesson in [[Chapter 2]], it is going to replace #NAMES_HUMANMALE with an actual name for this NPC, such as "Fritz", "Bob" or the ever popular "Roderick". The second thing it is going to do is divide this name into a NAME and a TITLE. Where does it do this division? At the word "the". So writing this line is equivalent to:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2011-09-19T09:03:01Z

Sirius: /* NPC Evolution */ Translation into German

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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:

<tt>[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 </tt>

'''[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]

-- 
Die Uebersetzung endet hier. Wer moechte darf gerne weiter uebersetzen :) 
--

'''DEFNAME=C_H_ALCHEMIST''' This is the '''defname''' for this script, obviously. We've seen things like this so many times, I don't believe I need to go over it. But now at least we have a more memorable name for this script. It's obviously a character (C), a human (H), and an alchemist ('''C_H_ALCHEMIST'''). Try to make your '''DEFNAMEs''' make sense based on what the character is. Calling this c_robed_man would have absolutely no memorable qualities. :)

'''NAME=#NAMES_HUMANMALE the Alchemist''' This is where SPHERE does some funky stuff. First of all, if you remember from the SPHERE_NAME.SCP lesson in [[Chapter 2]], it is going to replace #NAMES_HUMANMALE with an actual name for this NPC, such as "Fritz", "Bob" or the ever popular "Roderick". The second thing it is going to do is divide this name into a NAME and a TITLE. Where does it do this division? At the word "the". So writing this line is equivalent to:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 2

2011-09-19T08:35:40Z

Sirius: Link to German "Chapter 3"

{{Languages|Chapter_2}}

==spheretables.scp==

Spheretables.scp ist die allererste Datei, die beim Start von Sphere genau nach der Sphere.ini eingelesen wird. Deshalb ist sie äusserst wichtig. Viele weitere Einstellungen werden innerhalb dieser Datei vorgenommen und das macht sie so wichtig. Deshalb wird diese Datei hier nun erklärt und aufgeschlüsselt:

<nowiki>==</nowiki> [RESOURCES] ==

Öffnet man diese Datei, fällt einem als erstes eine Liste von Dateien ins Auge. Diese Liste ist durch das [RESOURCE]-Tag markiert und sieht so aus:

<tt>[RESOURCES] 
scripts/sphere_defs.scp 
scripts/sphere_book.scp 
scripts/sphere_backward_compatibility.scp 
scripts/sphere_events_human.scp 
scripts/sphere_events_npcs.scp 
scripts/npcs/ 
... </tt>

Hier wird eingestellt, welche und in welcher Reihenfolge Skriptdateien von Sphere geladen werden. Manchmal sollten hier Änderungen mit äusserster Vorsicht vorgenommen werden. Dateien mit DEFNAMES, REGIONS und anderen global benutzten Einstellungen sollten als erstes geladen werden, um Fehler beim Start von Sphere zu vermeiden (obgleich diese Fehler oftmals den Server nicht beeinträchtigen). Beispielsweise wurde in [[De:Chapter 1|Kapitel 1]] das Goldskript behandelt:

TYPE=t_gold

Wurde die sphere_defs.scp nicht vor dem Goldskript geladen, weiss Sphere nicht was t_gold bedeutet, dann wird eine Fehlermeldung ausgegeben. Deshalb sollte vor dem Goldskript auf alle Fälle zuerst die sphere_defs.scp geladen werden, in der t_gold definiert wurde.

Skripte mit Itemdefinitionen sollten vor Skripten mit Templatedefinitionen geladen werden und danach dann die Characterdefinitionen. Andere Dateien folgen danach, aber diese Dateien sollten auf jeden Fall in dieser Reihenfolge sein. Der Loot von Monstern benötigt Templates und die wiederum Items und solange Sphere keine Dateien mit Templates oder Items geladen hat, werden hunderte Fehler ausgegeben, die dann korrigiert werden müssen.

'''Anmerkung''': ''Es können ganze Ordner angegeben werden, es muss nicht jede einzelne Datei in der Liste aufgeführt werden. Deshalb enthält die Liste beispielsweise scripts/ am ende von [RESOURCE], damit alle Skripte dieses Ordner geladen werden, die noch nicht aufgeführt wurden.''

<nowiki>==</nowiki> [OBSCENE] ==

Die nächste Sektion ist selbsterklärend: [OBSCENE]. Hier werden unerlaubte Namen aufgeführt. Versucht ein Spieler seinem Charakter einen Namen aus der Liste zu geben, dann wird ihm mitgeteilt, dass er einen anderen wählen soll.

<nowiki>==</nowiki> [NOTOTITLES] ==

Hier werden Titel definiert, die basierend auf dem Karmawert eines Spielers angezeigt werden. Diese Sektion sollte nicht angerührt werden, denn fehlt hier eine Zeile wird Sphere nicht mehr starten - diese Zeilen sollten höchstens geändert werden.

<nowiki>==</nowiki> [PLEVEL X] ==

Dieser Abschnitt legt fest, welche Befehle mit welchen Accountrechten (PLEVEL) ausgeführt werden können. Jeder nichtgelistete Befehl wird automatisch mit PLEVEL 4 eingeordnet. Das gilt auch für selbstgeschriebene Funktionen (siehe [[Chapter 6|Kapitel 6]]). Wie man sieht, gibt es eine große Liste an Befehlen und Funktionen.

'''Anmerkung''': Es muss nicht jede selbstgeschriebene Funktion in diese Liste, da jederzeit weitere [PLEVEL]-Sektionen in anderen Skripten angelegt werden können, obgleich es natürlich organisatorisch besser wäre, diese würden zentral gehalten.

<nowiki>==</nowiki> [RUNES] ==

Das ist die Liste der Worte, die gesagt werden, wenn ein Spruch gezaubert wird (An, Lor, In, usw.). Sie können geändert werden, aber das kann durchaus sehr verwirren. =P

==Sphere.ini==

Sphere.ini enthält alle internen Einstellungen des Sphere Emulators. Um einen Shard zu konfigurieren sollte hier begonnen werden. Um die Datei besser zu erklären, wurden Kommentare in '''fetter Schrift''' eingefügt.

<tt>//**************************************************************************** 
// SPHERE by : Menasoft 1997-2003 
// www.sphereserver.com 
// All SPHERE script files and formats are copyright Menasoft & Partners. 
// This file may be freely edited for personal use, but may not be distributed 
// in whole or in part, in any format without express written permission from 
// Menasoft & Partners. All donations and contributions 
// become the property of Menasoft & Partners. 
//**************************************************************************** 
 
/////////////////////////////////////////////////////////////// 
//////// General Information 
/////////////////////////////////////////////////////////////// 
 
[SPHERE] 
// Name of your Sphere shard 
ServName='''WarAngel's Test Centre''' 
// The IP of your server, this will be 127.0.0.1 almost always 
ServIP=127.0.0.1 
// The port of your server, this is 2593 by default 
ServPort=2593 
 
// Admin's contact email 
AdminEmail='''warangel999@msn.com''' 
// Web page for this server 
URL=www.myshard.com Replace www.myshard.com with your shard's URL' 
// GMT offset, from -12 to +12 [London=0, EST=5, etc] 
TimeZone='''-5 Östliche Zeitzone (US & Canada). Sollte passend eingestellt werden.''' 
 
// Official staff language 
Lang=English 
// Start this as a system service on Win2000, XP, NT 
NTService=0 '''Wird diese Einstellung aktiviert, ist kein Zugriff auf die Konsole mehr möglich.''' 
 
// MySql configuration. 
//MYSQL=0 '''Auf =1 wird MySQL aktiviert.''' 
//MySqlHost='''localhost Wird fast immer localhost sein, ausser MySQL läuft auf einen anderen Rechner als der Shard.''' 
//MySqlUser= 
//MySqlPassword= 
//MySqlDatabase= 
 
/////////////////////////////////////////////////////////////// 
//////// File Locations 
/////////////////////////////////////////////////////////////// 
// Directory where spheretables.scp is located, from there we will 
// load any additional scripts 
ScpFiles=scripts/ 
 
// Where your sphereworld.scp and spherechars.scp are located 
WorldSave=save/ 
 
// Where your sphereaccu.scp and sphereacct.scp is located 
AcctFiles=accounts/ 
 
// Where your UO installation is located. This need: map0.mul, statics0.mul, 
// staidx0.mul, multi.mul, multi.idx, hues.mul, tiledata.mul. 
// Optional files: verdata.mul, mapX.mul/staticsX.mul/staidxX.mul for higher 
// maps support (Malas, etc). 
// 
// Note that if not set, sphere will scan windows registry to auto-detect it 
//MulFiles=mul/ 
 
// Where your log files will be saved by sphere 
Log=logs/ 
 
/////////////////////////////////////////////////////////////// 
//////// World Save Information 
/////////////////////////////////////////////////////////////// 
// How often for Sphere to save your world (minutes) 
SavePeriod=20 
 
// How many backup levels to keep. Each level means 7 backups done for it. 
// So, 10*7 = 70 backup saves will be storied. 
BackupLevels=10 
 
// On would save in the background quietly over a longer period of time, and not interrupt the game 
// Off would notify "World save has been initiated" and save faster, but pause the game momentarily 
SaveBackground=0 
 
/////////////////////////////////////////////////////////////// 
//////// Account Management 
/////////////////////////////////////////////////////////////// 
//Code for servers account application process 
// 0=Closed, // Closed. Not accepting more. 
// 2=Free, // Anyone can just log in and create a full account. 
// 3=GuestAuto, // You get to be a guest and are automatically sent email with u're new password. 
// 4=GuestTrial, // You get to be a guest til u're accepted for full by an Admin. 
// 6=Unspecified, // Not specified. 
// To enable auto account you must set this to 2 
AccApp=0 
 
// Store password hashed with MD5 '''MD5 ist eine Verschlüsselungsmethode zur Speicherung von Passwörtern. Mehr Information: [http://de.wikipedia.org/wiki/MD5 hier]''' 
Md5Passwords=0 
 
// local ip is assumed to be the admin 
LocalIPAdmin=1 
 
// Number of chars allowed per account 
MaxCharsPerAccount=5 
 
// Min time for a char to exist before delete allowed (in seconds) 
MinCharDeleteTime=3*24*60 
 
// Max number of Guest accounts allowed 
GuestsMax=0 
 
/////////////////////////////////////////////////////////////// 
//////// Client Management 
/////////////////////////////////////////////////////////////// 
// What client protocol version used 
// Comment out the ClientVersion line to allow any client that is supported. 
//ClientVersion=2.0.3 
 
// Set this to 0 to block login to encrypted clients '''Normalerweise benutzen Clients Verschlüsselung.''' 
UseCrypt=1 
 
// Set this to 1 to allow login to unencrypted clients '''Klappt mit Tools wie bspw.: [http://stud4.tuwien.ac.at/~e9425109/UO_RICE.htm UO Rice] und [http://www.uogateway.com/ UOGateway] die Verschlüsselung eines Clients zu entfernen''' 
UseNoCrypt=0 
 
// Maximum total open connections to server 
ClientMax=256 
 
// Maximum open connections to server per IP 
ClientMaxIP=16 
 
// Maximum total (not-in-game) connections to server 
ConnectingMax=32 
 
// Maximum total simultaneous (not-in-game) connections to server per IP 
ConnectingMax=8 
 
// How long logged out clients linger in seconds 
ClientLinger=15 
 
// Walk limiting code: buffer size (in tenths of second) 
WalkBuffer=75 
 
// Walk limiting code: regen speed (%) 
WalkRegen=25 
 
// Only commands issued by this plevel and higher will be logged 
CommandLog=0 '''0 bedeutet, dass alle Befehle geloggt werden.''' 
 
// Prefix for ingame commands 
CommandPrefix=. 
 
// Use the built in http server 
UseHttp=1 
 
// Use the built in god port 
UseGodPort=0 '''This is for use with the God client''' 
 
// Default setting for all accounts specifying default resdisp. Recommended 
// specifying at least 1 (T2A) here. 
//AutoResDisp=0 '''0=autmatisch herausfinden, 1=T2A, 2=LBR, 3=AoS, 4=SE, 5=ML''' 
 
// Default setting for new accounts specifying default priv level 
//AutoPrivFlags=010 
 
/////////////////////////////////////////////////////////////// 
//////// Game Mechanics 
/////////////////////////////////////////////////////////////// 
// Do not allow entering under roof being on horse? 
MountHeight=0 
 
// Archery does not work if too close (0 = not checked) 
ArcheryMinDist=2 
 
// Maximum Distance for Archery 
ArcheryMaxDist=15 
 
// Speed scale factor for weapons '''Formel ist: VERZÖGERUNG = SPEEDSCALEFACTOR /((DEX + 100) * SPEED)''' 
SpeedScaleFactor=15000 
 
// This is the percent of max weight at which stamina is lost half the time 
// (200 = no effect) 
StaminaLossAtWeight=150 
 
// Weight penalty for running +N% of max carry weight (0 = no effect) 
RunningPenalty=50 
 
// Show people joining/leaving the server 
ArriveDepartMsg=1 
 
// Are house and boat keys newbied automatically 
AutoNewbieKeys=1 
 
// Maximum number of items allowed in bank 
BankMaxItems=1000 
 
// Maximum weight in stones allowed in bank 
BankMaxWeight=1000 
 
// If 1 vendors will take gold only from backpack 
PayFromPackOnly=0 '''Wenn 0, dann nehmen Händler auch Geld vom Bankfach.''' 
 
// Disable weather effects? 
NoWeather=1 
 
// Default light level in dungeons 
DungeonLight=27 '''0 ist am helssten, 30 ist am dunkelsten''' 
 
// Day light level 0-30 '''0 ist am helssten, 30 ist am dunkelsten''' 
LightDay=0 
 
// Night light level 0-30 
LightNight=25 
 
// Wool Regen Time (in minutes) 
WoolGrowthTime=30 
 
// Suppress player speech with 75% of capital letters 
SuppressCapitals=0 
 
// Extra combat flags to control the fight (default:0, 0.55i compatible) 
// COMBAT_NODIRCHANGE 00001 // not rotate player when fighting (like was in 0.51a) 
// COMBAT_FACECOMBAT 00002 // allow faced combat only (recommended) 
//CombatFlags=0 '''Sind beide aktiviert, dann bedeutet das, dass der Spieler den Gegner ansehen muss, um ihn zu treffen.''' 
 
/////////////////////////////////////////////////////////////// 
//////// NPC/Item/Player Management 
/////////////////////////////////////////////////////////////// 
// Distance in tiles before an NPC that's wandered too far from it's home will teleport back 
LostNPCTeleport=50 
 
// Wether PCs get a resurrection robe when they get resurrected. 
NoResRobe=0 
 
// Time for a NPC corpse to decay mins 
CorpseNPCDecay=10 
 
// Time for a playercorpse to decay mins 
CorpsePlayerDecay=15 
 
// Base decay time in minutes for items 
DecayTimer=30 
 
// Put [NPC] tags over chars '''oder [TAME], wenn der NPC gezähmt wurde''' 
CharTags=0 
 
// Flip dropped items 
FlipDroppedItems=0 
 
// Monsters run when scared of death 
MonsterFear=0 
 
// Monsters may fight each other 
MonsterFight=0 
 
// Percent setting of the all NPC move rate, default 100 
MoveRate=100 
 
// Do players receive sounds 
GenericSounds=1 
 
// Max number of items to sell to one person at once 
VendorMaxSell=255 
 
// Max level npc trainers can go 
NPCTrainMax=300 '''300 ist 30.0 skill''' 
 
// Percent of own ability npcs can train to 
NPCTrainPercent=30 
 
// Max level of skill trainable on dummies, archery butte ect.. 
SkillPracticeMax=300 '''300 ist 30.0 skill''' 
 
// Max skill player's will start with on skills they haven't chosen during char create 
MaxBaseSkill=200 '''Hier eine 0, damit Spieler mit keinen Skills ausser den gewählten beginnen.''' 
 
// Time in seconds for hitpoint regeneration 
Regen0=40 
 
// Time in seconds for mana regeneration 
Regen1=20 
 
// Time in seconds for stamina regeneration 
Regen2=10 
 
// Time in minutes for food regeneration 
// 1*60*24 = 1 day of real life time 
Regen3=1*60*24 
 
// Speech block associated to players 
SpeechSelf=spk_player 
 
// Speech block associated to pets 
SpeechPet=spk_pet 
 
// When player skills/stats goes this times more than skillclass allowed, drop 
// them to skillclass level. Setting this to 0 disables the action. 
OverSkillMultiply=2 
 
// NPC AI settings 
// NPC_AI_PATH 0001 NPC pathfinding 
// NPC_AI_FOOD 0002 NPC food search (objects + grass) '''Sorgt dafür, dass NPCs nach Essen bzw Gras suchen (siehe FOODTYPE)''' 
// NPC_AI_EXTRA 0004 NPC magics, combat, etc 
//NPCAI=0 
 
/////////////////////////////////////////////////////////////// 
//////// Crime/Murder/Karma/Fame/Guard Settings 
/////////////////////////////////////////////////////////////// 
// Karma when player goes from good to neutral (from -10000 to 10000) 
PlayerNeutral=-2000 
 
// How many minutes are criminals flagged for 
CriminalTimer=3 
 
// Times a player can snoop before becoming a criminal 
SnoopCriminal=20 
 
// Seconds time to decay a murder count (default 8*60*60 is 8 hours) 
MurderDecayTime=8*60*60 
 
// Amount of murders before we get title 
MurderMinCount=1 
 
// Looting or carving a blue player is a crime 
LootingIsaCrime=1 
 
// Flag players criminal for helping criminals? 
HelpingCriminalsIsaCrime=1 
 
// How long do guards linger about in minutes 
GuardLinger=3 
 
// Will guards kill instantly or follow normal combat rules 
GuardsInstantKill=1 
 
// Limits the MAXHITS/MAXMANA/MAXSTAM changes 
// STAT_FLAG_NORMAL 0x00 // MAX* status allowed (default) 
// STAT_FLAG_DENYMAX 0x01 // MAX* denied 
// STAT_FLAG_DENYMAXP 0x02 // .. for players 
// STAT_FLAG_DENYMAXN 0x04 // .. for npcs 
StatsFlags=0 
 
/////////////////////////////////////////////////////////////// 
//////// Server Mechanics 
/////////////////////////////////////////////////////////////// 
// Experimental flags 
// Flags for options that affect server behaviour and which might affect compatibility 
// See the revisions.txt file for more details on this 
// EF_DiagonalWalkCheck = 00000001 
// EF_UNICODE = 00000002 // No on Linux '''Bringt UNICODE Korrekturen''' 
// EF_Scripts_Ret_Strings = 00000004 
// EF_New_Triggers = 00000008 
// EF_Scripts_Parse_Verbs = 00000010 
// EF_Intrinsic_Locals = 00000020 //'''Erlaubt locals anders zu nutzen. Beispielsweise kann statt <local.x> auch nur <x> benutzt werden.''' 
// EF_Item_Strict_Comparison = 00000040 //'''Sorgt dafür, dass gleiche Items nicht mehr verglichen werden, wie Stoff, Leder, Fell, Holz, Bretter, Pfeile und Bolzen.''' 
// EF_WalkCheck = 00000100 '''//Behebt viele Hauseinbruchsbugs und ähnliche Probleme.''' 
// EF_Script_Profiler = 00000400 
// EF_Size_Optimise = 00000800 
// EF_Minimize_Triggers = 00001000 //Minimize trigger calls (use only 0.51 triggers) 
Experimental=00000 
 
// Option flags 
// Flags for options that affect server behaviour but not compatibility 
// See the revisions.txt file for more details on this 
// OF_Magic_IgnoreAR = 00000001 //'''Magieschaden ignoriert Rüstung (AR)?''' 
// OF_Magic_CanHarmSelf = 00000002 //'''Kann sich ein Spieler mit Magie selbst verletzen? (einen Magic Arrow auf sich abfeuern, um Lähmung (Paralyze) zu beenden?)''' 
// OF_Magic_StackStats = 00000004 
// OF_Archery_CanMove = 00000010 //'''Kann ein Spieler laufen und schiessen gleichzeitig?''' 
// OF_Magic_PreCast = 00000020 //'''Funktionieren Zauber mit pre-cast oder ist der Spieler solange er zaubert unfähig herumzulaufen?''' 
// OF_Items_AutoName = 00000040 
// OF_FileCommands = 00000080 //'''Aktiviert Befehle zur Dateiverarbeitung, wie writefile usw''' 
// OF_NoItemNaming = 00000100 //'''Verhindert die Benennung von Gegenständen mit "crafted by"''' 
// OF_NoHouseMuteSpeech = 00000200 //'''Können sich spieler in und ausserhalb von Häusern gegenseitig hören?''' 
// OF_Multithreaded = 00000400 //'''Nicht setzen, solange der Server läuft!!! (Macht *Nix Server instabil) Lässt die Verarbeitung von Accounts auf einem anderen Thread laufen''' 
// OF_Advanced_LOS = 00000800 
// OF_Flood_Protection = 00001000 
OptionFlags=0200 
 
// FeatureT2A, used to control T2A expansion features ( default 03 ) 
// FEATURE_T2A_UPDATE 01 // Monster and Lost lands 
// FEATURE_T2A_CHAT 02 // In game chat 
FeatureT2A = 03 
 
// FeatureLBR, used to control LBR expansion features ( default 0 ) 
// FEATURE_LBR_UPDATE 01 // Lbr Monsters 
// FEATURE_LBR_SOUND 02 // MP3 instead of MIDI 
FeatureLBR = 0 
 
// FeatureAOS, used to control AOS expansion features ( default 0 ) 
// Enabling one of them automagically enables AoS basic features 
// FEATURE_AOS_UPDATE 01 // Basic AoS feature 
// FEATURE_AOS_POPUP 02 // Popup infos 
// FEATURE_AOS_DAMAGE 04 // Damage shown on hit 
// FEATURE_AOS_PALNECRO 08 // Fightbook and Paladin/Necro on char creation 
// FEATURE_AOS_TOOLTIP 010 // Tooltips 
FeatureAOS = 0 
 
// FeatureSE, used to control SE expansion features ( default 0 ) 
// FEATURE_SE_UPDATE 01 // Basic SE features 
// FEATURE_SE_NINJASAM 02 // Ninja and Samurai 
FeatureSE = 0 
 
// FeatureML, used to control ML expansion features ( default 0 ) 
// FEATURE_ML_UPDATE 01 // Basic ML features 
FeatureML = 0 
 
// In game effects to turn on and off 
// Messages echoed to the server console while in debug mode 
// DEBUGF_NPC_EMOTE = 0x0001 
// DEBUGF_ADVANCE_STATS = 0x0002 
// DEBUGF_WALKCODES = 0x0080 // try the new walk code checking stuff 
// DEBUGF_NPCAI = 0x0100 // some NPC AI debugging 
// DEBUGF_EXP = 0x0200 // experience gain/loss 
// DEBUGF_LEVEL = 0x0400 // experience level changes 
DebugFlags=0 
 
// Console Hears all that is said on the server 
HearAll=1 
 
// Secure mode attempts to ignore errors, protect from accidently shutdowns 
Secure=1 
 
// Value from 1 to 32, set sectors inactive when unused to conserve resources 
SectorSleep=10 
 
// Disconnect inactive socket in x min 
DeadSocketTime=5 
 
// Always force a full garbage collection on save 
ForceGarbageCollect=1 
 
// Time before restarting when server appears hung (in seconds) 
FreezeRestartTime=60 
 
// Length of the game world minute in real world in seconds 
GameMinuteLength=60 
 
// Bit Mask of the subjects you want to log when logging is on 
// LOGM_ACCOUNTS 0x00080 
// LOGM_SAVE 0x00200 // world save status. 
// LOGM_CLIENTS_LOG 0x00400 // all clients as they log in and out. 
// LOGM_GM_PAGE 0x00800 // player gm pages. 
// LOGM_PLAYER_SPEAK 0x01000 // All that the players say. 
// LOGM_GM_CMDS 0x02000 // Log all GM commands. 
// LOGM_CHEAT 0x04000 // Probably an exploit ! 
// LOGM_KILLS 0x08000 // Log player combat results. 
// LOGM_HTTP 0x10000 
// 01ffff log everything 
LogMask=01ec80 
 
// Amount of time to keep map data cached in sec 
MapCacheTime=120 
 
// Max NPC chars for a sector to prevent lag 
MaxComplexity=32 
 
// Amount of items in one tile so start showing "too many items here" 
MaxItemComplexity=25 
 
// Amount of items in one sector to start showing "x items too complex" 
MaxSectorComplexity=1024 
 
// Limit the number of cycles the while/for loop can proceed. Setting this to 
// zero disables the limitation 
MaxLoopTimes=0 
 
/////////////////////////////////////////////////////////////// 
//////// Magic/Effects Settings 
/////////////////////////////////////////////////////////////// 
 
// Allow casting while equipped 
EquippedCast=1 
 
// Words of power for player using magic 
WOPPlayer=1 
 
// Words of power for staff using magic 
WOPStaff=0 
 
// Reagents lost if magic fails 
ReagentLossFail=0 
 
// Magic requires reagents 
ReagentsRequired=0 
 
// What % of hitpoints players will resurrect with. Note, that if you set this 
// too low, people with little STR will have problems resurrecting. 
HitPointPercentOnRez=33 
 
// How many % of hits will the character loose when starving. 0 disables 
//HitsHungerLoss=0 
 
// Amount of skill of lock picking needed to unlock a magically locked door 
MagicUnlockDoor=900 
 
// Teleport effect for GMs and players. Setting 0 disables the effect 
TeleportEffectStaff=03709 
TeleportEffectPlayers=0372a 
 
/////////////////////////////////////////////////////////////// 
//////// Experience and Level system 
/////////////////////////////////////////////////////////////// 
 
// Enable experience system 
//ExperienceSystem=0 
 
// Experience system settings: 
// 0001 gain experience in combat 
// 0002 gain experience in crafts 
// 0004 allow experience to go down 
// 0008 limit experience decrease by a range witheen a current level 
// 0010 auto-init EXP/LEVEL for NPCs if not set in @Create 
// 0020 allow trigger @ExpChange 
// 0040 allow trigger @ExpLevelChange 
//ExperienceMode=0 
 
// If combat experience gain is allowed, use these percents for gaining exp in 
// Player versus Monster and Player versus Player combats. Value 0 disables gain. 
//ExperienceKoefPVM=100 
//ExperienceKoefPVP=100 
 
// Enable levels system (as a part of experience system) 
//LevelSystem=0 
 
// Level system settings: 
// linear = 0 (each NextLevelAt exp will give a level up) 
// double = 1 (you need (NextLevelAt * (level+1)) to get a level up) 
//LevelMode=1 
 
// Amount of experience to raise to the next level 
//LevelNextAt=0 
 
/////////////////////////////////////////////////////////////// 
//////// Webpage Settings 
/////////////////////////////////////////////////////////////// 
 
// Note, that you can catch error codes by creating sphere404.htm and so on 
// for all HTTP error codes sphere support. 
 
[WEBPAGE 1] 
// Determines what html file is used as base for the status page 
WebPageSrc=scripts\web\spherestatusbase.html 
// Determines where the status page is saved 
WebPageFile=scripts\web\status.html 
// In seconds, how often the status file is updated 
WebPageUpdate=60 
// Required PLevel to view this page (0 = anyone, 6 = admins only) 
PLevel=0 
 
/////////////////////////////////////////////////////////////// 
//////// Abuse Control 
/////////////////////////////////////////////////////////////// 
 
// Block these ips from the server 
// 255 is a wildcard, so 255.255.255.255 disables anyone connecting. 
[BlockIP] 
//123.34.45.56 
//123.45.56.78 
 
/////////////////////////////////////////////////////////////// 
//////// Connection Information 
/////////////////////////////////////////////////////////////// 
 
//First line should be the name of your shard (this is what people see when they connect) 
//Second line should be the IP of your shard (this is almost always 127.0.0.1) 
//Third line should be the port of your shard (this should be whatever ServPort is set to) 
 
//Uncomment next 3 lines below this if you have a router 
//First line should be a name different than your shard name above this 
//Second line should be your real/external IP (www.whatismyip.com) 
//Third line should be the shard port (this should be whatever ServPort is set to) 
[SERVERS] 
'''WarAngel's Test Centre''' 
127.0.0.1 
2593 
 
//External 
//my.ip.goes.here 
//2593 
 
[EOF] </tt>

'''MAPx''' Ist zwar nicht in sphere.ini, kann aber genutzt weden (siehe REVISIONS.txt). Und zwar so:

MAPx=max_x,max_y,sector_size,real_map_number.

Beispiel: MAP1=7168,4096,512,-1

setzt die Größe von map1 auf 7168,4096, die Sektorgröße von map1 auf 512 und die -1 bedeutet, dass die Standarddatei für diese map benutzt wird.

Anderes Beispiel:

MAP50=7168,4096,64,3

Aktiviert die Map mit nummer 50, die eine Größe von 7168,4096, eine Sektorgröße von 64 hat und map3.mul, statics3.mul und staidx3.mul als Dateien benutzt.

==sphere_region.scp==

Dieses Skript stellt Orte auf der Karte ein und defniert, was bspw. dort an Metallen oder Holz abgebaut werden kann, was passiert, wenn diese Orte betreten werden und weiteres. Es enthält zudem Resource-Sektionen, die so aufgebaut sind:

<tt>[REGIONRESOURCE x]</tt>

Diese Sektion enthält den Skill, der benötigt wird, um diese Resource abzubauen, welche Resource der Spieler erhält und wie lange es dauert, damit sie "nachwächst". Ein Beispiel hierfür (es gibt einen Kommentar mit "//t_tree", der aber klar sein sollte, wenn das vorherige Kapitel über defnames gelesen wurde).

<tt>[REGIONRESOURCE mr_tree] 
// lumberjacking default 
// t_tree 
SKILL=1.0,80.0 
AMOUNT=9,30 
REAP=i_log 
REGEN=60*60*10 </tt>

Diese Sektion definiert eine Resource, etwas das gesammelt werden kann. Es vergleicht Skill und Menge. Das bedeutet, dass mit Skill 1.0 maximal 9 i_log und mit Skill 80.ß maximal 30 i_log gesammelt werden können. Alles danach ist nur eine Erhöhung der Chance auf 30 i_log. In der SKILL-Zeile wird also eine Unter- und eine Obergrenze festgelegt, die AMOUNT-Zeile macht selbiges für die Mengen.
Was bringt uns das? Die Zeile: REAP=i_log. Das sagt dem Server, er soll i_log Items erstellen, wenn diese Resource gebraucht wird. Es kann hier alles stehen, was man auf seinem Shard sammelbar machen möchte.
Die nächste Zeile, REGEN, legt in Sekunden fest, wie lange es dauert, damit diese Resource wieder neu abgebaut werden kann. In diesem Beispiel sind das 60*60*10 Sekunden, also 10 Stunden. Als GM können die Punkte wahrgenommen werden, an denen Spieler geschürft oder abgeholz haben, denn dort liegen kleine Kristalle am Boden. Sie sehen wie Spawnpunkte aus, aber sind in Wahrheit Resourcenmarkierungen. Sie markieren, wo eine spezielle Resource geholt werden kann, wie viel geholt werden kann und welchen Typ die Resource hat. Sie haben zudem einen TIMER, der runterzählt (von bspw 36000) und der dann dafür sorgt, dass der Kristall bei 0 gelöscht wird.

<tt>[REGIONTYPE r_default_rock t_rock] 
//Random rocks 
RESOURCES=100.0 mr_nothing 
RESOURCES=500.0 mr_iron 
//RESOURCES=6.0 mr_rusty 
//RESOURCES=6.0 mr_old_copper 
//RESOURCES=6.0 mr_dull_copper 
//RESOURCES=4.5 mr_bronze 
RESOURCES=5.0 mr_copper 
RESOURCES=2.0 mr_gold 
RESOURCES=1.0 mr_rose 
RESOURCES=2.0 mr_agapite 
RESOURCES=1.0 mr_bloodrock 
RESOURCES=1.0 mr_silver 
RESOURCES=0.5 mr_verite 
RESOURCES=0.2 mr_Valorite 
RESOURCES=0.1 mr_mytheril 
RESOURCES=0.1 mr_blackrock 
RESOURCES=0.1 mr_diamond </tt>

Wow? Was sind das für Dinge? mr_iron, mr_agapite? Das ist nirgendwo in der Datei. Auch in sphere_defs.scp findet man diese Definitionen nicht, man muss in sphereitem_ore.scp nachsehen.

<tt>RESOURCES=50.0 mr_iron</tt>

Das sieht irgendwie bekannt aus. Würde es noch mehr, wenns so aussehen würde?

<tt>RESOURCES={ mr_iron 50 mr_copper 5 mr_gold 2 mr_rose 2 ...etc... }</tt>

Möchte wetten, dass es das würde, wenn die vorherigen Lektionen in Kapitel 1 gelesen wurden. Das ist eine gewichtete Liste von Resourcen. In einem etwas anderen Format, als die für Template genutzte Version, aber sie funktioniert genau so. Das ist der einzige Ort in allen Skripten, in denen Kommazahlen genutzt werden können, wie bspw 0.1 und 0.2. Eigentlich stimmt das nur halb, aber Sphere verdeckt erfolgreich, solange in jeder RESOURECE-Zeile eine Kommazahl steht. (Im übrigen sollte nicht ein RESOURCES mit einer Zufallsauswahl geskriptet werden. Sphere wird das nicht richtig auswerten, es sollte dieses Format genutzt werden.)

[REGIONTYPE r_default_rock t_rock] ''Bedeutet:'' r_default t_rock legt einen Defname für einen REGIONTYPE fest, der in anderen Skripten benutzt werden kann (im nächsten Abschnitt bspw. =P). t_rock ist ein Defname (siehe sphere_defs.scp) für Stein, was für Sphere festlegt wo Spieler welche Resource sammeln können (sollte es auf t_water geändert werden, kann im Wasser Erz geschürft werden, was sicher nicht ganz so beabsichtigt ist.)

Hoffentlich erklärt das sphere-resion.scp für jeden. Im nächsten Abschnitt wird gezeigt, wie REGIONTYPE-Einstellungen benutzt werden, damit die Resourcen auch wirklich im Spiel vorhanden sind.

==sphere_mapX.scp==

Willkommen zur einfachsten Datei in Sphere: spheremap.scp. Diese Datei ist vollständig fertiggestellt für die Standardmap. Es ist sehr selten, dass diese Datei verändert werden muss.

Eine Anmerkung, die gleich zu Anfang gesagt werden muss: wird diese Datei verändert, muss der Server neu gestartet werden, damit die Änderung auch übernommen wird. Sollte das innerhalb eine Resyncs passieren, wirds viele Fehler geben.

Diese Sektion zeigt, wie neue Regionen erstellt werden können, zu denen man mit dem .go Befehl reisen kann.

Es gibt momentan 5 Dateien in den Standardskripten, eine für jede Map (Felucca, Trammel, Ilshenar, Malas und Tokuno) die von 0 bis 4 durchnummeriert sind (sphere_map0.scp, sphere_map1.scp usw).

Ich benutze die Region Felucca als ein Beispiel für dieses Tutorial und hier das Skript dafür:

<tt>[AREADEF a_world] 
NAME=Felucca 
EVENTS=r_default,r_default_rock,r_default_water,r_default_tree,r_default_grass 
GROUP=ALLMAP 
P=1323,1624,55,0 
RECT=0,0,6144,4096,0 </tt>

Diese Zeilen bedeuten:

'''[AREADEF somedef]''': Wie in allen anderen Skripten ist das ein Defname - nur hier für eine Region auf dem Server.

'''Name''': Diese Zeile enthält einen Namen für die Region, der angezeigt wird, wenn der .where Befehl im Spiel benutzt wird. Zudem kann .go "Region Name" dafür benutzt werden, um dort hin zu reisen (keine zwei Regionen sollten den selben Namen haben, ansonsten wird hier einiges an Fehlern produziert).

'''Events''': Hier wird festgelegt, was alles in der Regeion passiert und welche Resourcen hier abbaubar sind (siehe den Abschnitt über REGEIONTYPE - diese können hier als EVENT benutzt werden). Neben den Resourcen können hier auch Trigger benutzt werden, die von den EVENTS aufgerufen werden können (wahrscheinlich bemerkt man hier, dass die REGIONTYPE-Sektionen nur Ereignisse für Regionen sind :P), wie beispielsweise @Enter und andere (siehe [[Triggers]]).

'''Group''': Das ist eine Axiseinstellung, die im Travelmenü Regionen gruppiert.

'''P''': Das ist der Ort, an den man mit .go "Region Name" gelangt. Jede Region hat eine solche Angabe und sie liegt normalerweise mitten in der Region oder an einem passenden ort. Wenn eine eigene Region erstellt wird, sollte ein solcher Punkt angegeben werden.

'''RainChance''': Legt die Chance auf Regeion in der Region fest (Rainchance=50 gibt eine 50% Wahrescheinlichkeit) der Rest bedeutet, dass es zu 50% schneit.

'''Rect''': Gibt die Grenzen der Region als Koordinaten an. Die ersten zwei Zahlen sind die Koordinaten des oberen linken Punktes und die zweiten der untere linke Punkt eines Rechtecks. Im Fall von Felucca ist das 0,0 bis 6144,4096 (RECT=0,0,6144,4096). Mit 56b kann auch ein fünfter Wert angegeben werden, nämlich die Karte, auf der die Region liegt, also RECT=0,0,6144,4096,0 (kann auch weggelassen werden, dann wird standardmäßig 0 verwendet - soll das nicht Map 0 sein, dann muss ein Wert angegeben werden, sonst gibts Fehler).

'''Flags''': Regionenflags bestimmen, was in einer Region los ist. Sie beschreiben, ob eine Region bewacht ist, welche Magie genutzt werden kann, wer hier wen verletzen kann und ob es hier regnen kann. Soll das verwendet werden, dann so:

Diese Zeile hinzufügen:

FLAGS=#

Natürlich sollte statt # eine Zahl verwendet werden! Wo diese nummern stehen? Es gibt vordefinierte, aber es gibt eine Liste.

Beispielsweise für eine bewachte und gesicherte Region, sehen sie so aus:

<tt>
::region_flag_safe (02000) 
:+ 
::region_flag_guarded (04000) 
:= 
::06000 </tt>

Das wars. Die FLAGS werden auf 06000 gesetzt. "Aber, aber ... hiess es nicht, dass DEFNAMEs die Eingabe von Zahlen unnötig machen?" (siehe [[De:Chapter 1|Kapitel 1]].) Natürlich, deshalb geht das auch ohne Zahlen und zwar so:

<tt>FLAGS=region_flag_safe|region_flag_guarded</tt>

Das wars. Die Region ist bewacht und sicher.

Aus Sicht eines Admins ist das aber keine gute Idee. Eine derartige Region verhindert, dass Wachen wirklich jemanden töten können, sie rufen sich gegenseitig und werden zu keiner Handlung fähig sein und letztendlich Lag verursachen. Einfach glauben und keine Region mit diesen beiden Flags erstellen.

Hier ist die Liste der möglichen Flags (stehen auch in sphere_defs.scp und können sich von Zeit zu Zeit ändern):

<tt>[DEFNAME region_flags] 
region_antimagic_all 00001 // keine Magie möglich hier. 
region_antimagic_recall_in 00002 // kein Teleport,Recall hier her, keine Markierung von Runen. 
region_antimagic_recall_out 00004 // kein Recall nach draussen von hier aus. 
region_antimagic_gate 00008 // keine Gatezauber hier hin oder hier raus. 
region_antimagic_teleport 00010 // kein Teleport hier her. 
region_antimagic_damage 00020 // Keine "böse" Magie hier. 
region_flag_ship 00040 // Das hier ist ein Schiff - Schiffsbefehle klappen hier. 
region_flag_nobuilding 00080 // kein Gebäude in diesem Areal 
region_flag_globalname 00100 // Sicherstellen, dass der Name global gilt. 
region_flag_announce 00200 // Ankündigung an alle, dass diese Region betreten wird. 
region_flag_insta_logout 00400 // Instant Logout erlaubt. (Hotel?) 
region_flag_underground 00800 // Dungeon Areal. (kein Wetter) 
region_flag_nodecay 01000 // Items am Boden werden nie gelöscht. 
region_flag_safe 02000 // Diese Region sichert vor jedem Schaden. 
region_flag_guarded 04000 // siehe tag.guardowner 
region_flag_no_pvp 08000 // Spieler können sich nicht direkt Schaden. </tt>

Und das wars mit der sphere_mapX.scp Datei.

==sphere_book.scp==
Spherebook.scp ist eine der sinnlosesten Dateien, die zu finden ist. Wie oft liest man schon die Tips auf einem Shard, wenn man einloggt? Ich weiss, dass die meisten Spieler diese Rollen einfach wegklicken. Aber der Inhalt ist in dieser Datei festgelegt. Und Bücher - hab ich die erwähnt? Diese fast-unmöglich-zu-schreiben, selten benutzten Speicherverschwender?

<tt>'''[SCROLL SCROLL_MOTD]''' 
'''[SCROLL SCROLL_NEWBIE]''' 
'''[SCROLL SCROLL_GUEST]''' </tt>

Das sind die Sektionen, die Nachrichten definiert, wenn man einloggt. Alles, das hier nach diesen Tags steht, wird in einer Nachricht auftauchen. Welche Leerzeichen wo gebraucht werden, muss mit vielen Tests herausgefunden werden. Braucht etwas Zeit und es gibt keine echte Möglichkeit das gut zu erklären. Einfach versuchen. Achtung: es gibt hier keine Zeilenumbrüche - oder zumindest gabs in der Vergangenheit keine.

<tt>'''[TIP X]''' </tt>

Richtig. Das sind Tips, die es beim Start gibt. "Krieg ist für Kinder und alles Leben ungesund." ist einer davon. Sehr passend.

<tt>'''[BOOK title]''' 
'''[BOOK title x]''' </tt>

Erstellt ein Buch mit DEFNAME Titel. Es legt eine Seitenzahl x nach dem DEFNAME fest und fügt Text auf einer bestimmten Seite hinzu. Sieht man die Beispielbücher an, kann man erahnen, wie das klappt. Die größte Schwierigkeit dieser Bücher ist die benutzte Schriftart im Spiel, so dass man nicht wirklich weiss, wieviele Zeichen es für eine Zeile oder Seite braucht. Beispielsweise passen mehr 'i's als 'w's oder 'm's in eine Zeile, weil diese Buchstaben größer sind. Ein Absatz kann mit der TAB Taste eingefügt werden.

==sphere_name.scp==

Eine einfache Datei. Es enthält eine Liste von Namen unter Sektionen mit verschiedenen DEFNAMEs. Die Namen sind wichtig, nicht der Inhalt, da man wahrscheinlich nie eine eigene Liste von Namen anlegen wird. Ich benutze diesen Emulator seit Jahren und habe nie diese Datei verändert.

Um auf die Liste der Namen zugreifen zu können, benutzt man das hier:

'''NAME=#NAMES_HUMANMALE'''

Das ersetzt automatisch auf einen Zufallsnamen aus der Liste '''NAMES_HUMANMALE'''.

Um eine Liste von Namen zu erstellen, sieht das so aus:

<tt>[NAMES EIN_DEFNAME] 
ANZAHL_DER_NAMEN 
NAMEN </tt>

Beispielsweise:

<tt>[NAMES NAMES_SPECIAL] 
2 
Hil 
Hol </tt>

Schwierig, hm? Eigentlich wollte ich dafür keinen Abschnitt schreiben ...

==sphere_newb.scp==
Ich habs getan - kein eitler Humor unter diesem Titel! :)

Auf jeden Fall ist diese Datei oft Gegenstand vieler Fragen. "Wie sorge ich dafür, dass meine Spieler mit 10000 Gold anfangen?" oder "Wie gebe ich allen Schmieden 800 Barren?" Ich sag nicht, dass das sinnvoll wäre, aber in dieser Datei können solche Dinge geregelt werden.

<tt>[NEWBIE MALE_DEFAULT] 
// Male Generic Starting Clothes 
ITEMNEWBIE=i_shirt_plain 
COLOR=colors_all 
ITEMNEWBIE=random_pants 
COLOR=colors_neutral 
ITEMNEWBIE=random_shoes 
COLOR=colors_neutral 
ITEMNEWBIE=i_dagger 
ITEMNEWBIE=i_candle 
ITEMNEWBIE=i_book_sm 
ITEMNEWBIE=i_gold,100 </tt>

So sieht ein typisches Skript aus. Wie eine große Template, nicht wahr? Dafür gibts einen Grund. Es ist ein Template, es steht nur '''ITEMNEWBIE''' statt '''ITEM''' drin. In Kapitel 1 steht über Templates alles, was man wissen muss und genau so funktioniert das auch hier.

Das einzige wichtige in diesen Sektionen ist: alles MUSS einen eindeutigen Namen haben, den der Server finden kann. Es kann keine weitere Newbie-Sektion hinzugüfgt werden, so sehr das auch gewollt werden würde - sorry.

==sphere_skill.scp (SKILLCLASSES)==
Skill Klassen legen fest, wie weit Skills/Stats gesteigert werden können und es können zudem Trigger angelegt werden. Ein Skillclass Skript sieht so aus:

<tt>[SKILLCLASS 0] 
// undeclared class. 
// max skills for players of this skill class. 
// might want this to be all 50.0 to make people declare a class? 
DEFNAME=Class_undeclared 
NAME=undeclared 
// EVENTS=e_ClassUndeclared 
STATSUM=300 
SKILLSUM=10000.0 
STR=100 
INT=100 
DEX=100 
ALCHEMY=100.0 
ANATOMY=100.0 
ITEMID=100.0 
ARMSLORE=100.0 
and so on... </tt>

Um es zu verstehen:

'''EVENTS''': Bedeutet, dass jeder mit dieser Skillclass auch die hier angegebenen Ereignisse auslöst. (mehrere EVENTS werden mit Komma getrennt, bspw: EVENTS=e_1,e_2 usw).

'''STATSUM''': Gibt eine Obergrenze für die Summe der Stats an. Bspw: ich hab 100 Str, 100 Dex und 100 Int, dann hab ich 300 und damit STATSUM erreicht, ich kann nicht mehr erreichen (außer mit magischen Gegenständen und sowas).

'''SKILLSUM''': Wie STATSUM, nur für Skills.

'''STR/DEX/INT''': Obergrenze für einen spezifischen Stat (außer mit magischen Gegenständen und sowas).

'''ALCHEMY''': Wie STR/DEX/INT, nur für Skills (in diesem Fall Alchemy, aber kann auch jeder andere sein).

==sphere_serv_triggers.scp==
Diese Datei enthält spezielle Trigger "Functions", die vom Server bei bestimmten Ereignissen aufgerufen werden. Darunter gibt es eine Liste von Funktionen, die in dieser Datei gefunden werden und manche haben auch eine Erklärung dabei:

'''f_onaccount_login'''

Wird aufgerufen, wenn ein Client das Passwort eingegeben hat.

:ARGS --> Benutzername des Clients, der einloggen möchte
:ARGO --> Referenz zum Client selbst
:RETURN 0 --> nichts tun (also Login weiterlaufen lassen)
:RETURN 1 --> die Verbindung zum Client trennen

'''f_onaccount_delete'''

Diese Funktion wird aufgerufen, bevor ein Account gelöscht wird.

:ARGS --> Benutername des Accounts
:RETURN 0 --> Löschen zulassen
:RETURN 1 --> Löschen verhindern

'''f_onchar_create'''

'''f_onchar_delete'''

'''f_onserver_start'''

'''f_onserver_save'''

'''f_onserver_save_ok'''

'''f_onserver_save_fail'''

'''f_onserver_save_finished'''

'''f_onserver_exit'''

'''f_onserver_blockip'''

[[De:Chapter 3|Kapitel 3]]

[[Category:Tutorials]]

De:Main Page

2011-07-29T09:02:02Z

Sirius: Typo und Verlinkung auf Deutsches Kapitel 3

{{Languages|Main Page}}
Willkommen zum Remake von Taran's bekannter Seite: "[http://www.cs.rit.edu/~djr7581/ Sphere Scripting for Dummies tutorials]". Seine Tutorials waren damals für Sphere 55i erstellt worden, mittlerweile ist die aktuelle Version Sphere 56b und deshalb wurde entschieden, hier auf diesen Seiten eine Sammlung aktueller Tutorials und ein Kompendium neuer Funktionen zu bieten.

'''Wo fang ich nun an?'''

Jeder, der sich für die Skriptsprache von Sphere 56b interessiert, sollte hier anfangen: [[#Installation von Sphere|Installation von Sphere]]. Dort findet man die ersten Schritte mit Sphere. Danach empfiehlt es sich alle [[#Tutorials|Tutorials]] durch zu arbeiten, möglichst alles dabei zu verstehen und viel zu lernen.

'''Ich hab jetzt Skripten gelernt! Was nun?'''

Sind die ersten 10 Kapitels durchgearbeitet, dann gibt es hier natürlich noch weitere Artikel und Seiten. Sie erscheinen vielleicht nicht so wichtig, wie die anderen, aber sind dennoch mit weiterführenden und nützlichen Informationen gespickt. Versuche eigene Skripte zu entwickeln, sie vielleicht auch im [http://www.sphereserver.net/index.php SphereServer Forums] zu veröffentlichen. In den Forum erhält man auch weitere Hilfestellungen und Antworten auf Fragen. Des Weiteren ist auch das [[#Referenzkompendium|Referenzkompendium]] sehr nützlich.

'''Ich will mithelfen!'''

Um die Informationen auf diesen Seiten immer möglichst aktuell zu halten, ist natürlich viel Arbeit und Zeit notwendig. Jeder, der mithelfen möchte, diese Seiten zu pflegen, darf sich jederzeit hier anmelden und die Artikel hier überarbeiten. Alles, was man dafür braucht, ist ein [[Special:UserLogin|Wiki-Account]]. Oberhalb jeder Seite ist ein "Edit"-Link. Ausserdem sollte dieser Guide gelesen werden: [[de:Contribution Guide|Leitfaden für das SphereWiki]].

'''Dank geht speziell an:'''

[[WhoIsWho|Ben, Cloud_Br, Ellessar, Jdog, Lord Zerofiz, Mordaunt, Nazghul-ll, RanXerox, Rattlehead, Sandman, Sharlenwar, ShiryuX, thelegbra, Maximus and WarAngel]], für das Hinzufügen von Inhalt.

[[WhoIsWho|Daleth]], für das Erstellen des Sphere Reference Project, and [[WhoIsWho|Mordaunt]] für die Konvertierung ins .chm-Format.

[[WhoIsWho|Tracker]], für das Übertragen von Änderungen in Sphere 56 Tracking Changes.

[[WhoIsWho|Taran]], für die originalen Sphere Scripting for Dummies tutorials und [[WhoIsWho|MrSugarCube]], der ständige Neuerungen aktuell hält.

[[WhoIsWho|Furio, Radiant, Vjaka, Nazghul-ll, Ellessar, Torfo, Shadow Dragon and MrSugarCube]] für kontinuierliche Arbeit an Sphere, wodurch ein sehr mächtiger und an alle möglichen Bedürfnisse anpassbarer Ultima Online Emulator entstand.

[[WhoIsWho|Crius]], der das ursprüngliche Wiki gehostet hat, und [[WhoIsWho|Torfo]], der das Wiki momentan hostet.

----

==Installation von Sphere==

* [[de:Where to get Sphere|Sphere herunterladen]]
* [[de:Installing Sphere|Sphere installieren]]
* [[de:Configuring Sphere.ini|Konfigurationseinstellungen der Sphere.ini]]

==Tutorials==

Die Kapitel von Taran in aktualisierter Version für 56b:

* [[De:Chapter 1|Kapitel 1]] ''(Nummern, DEFNAME, ITEMDEF, CHARDEF)''
* [[De:Chapter 2|Kapitel 2]] ''(Übersicht über die Standardskripte)''
* [[De:Chapter 3|Kapitel 3]] ''(NPC's und Gegenstände, coole Funktionen)''
* [[Chapter 4|Kapitel 4]] ''(Objekte, Operatoren, Sprache)''
* [[Chapter 5|Kapitel 5]] ''(Tags, Vars, Locals, Functions)''
* [[Chapter 6|Kapitel 6]] ''(LINKs, TIMERs, TARGETs)''
* [[Chapter 7|Kapitel 7]] ''(Schleifen und mächtige Funktionen)''
* [[Chapter 8|Kapitel 8]] ''(SKILLMENUs, MENUs, Gumps)''
* [[Chapter 9|Kapitel 9]] ''(Events)''
* [[De:Chapter 10|Kapitel 10]] ''(Strings/Zeichenketten behandeln)''

Zusätzlich gibt es noch einige etwas fortgeschrittenere Tutorials, die von anderen Mitgliedern der Community bereitgestellt wurden. Nachdem man die 10 Kapitel durchgearbeitet hat, bieten sich die folgenden an, wenn man noch mehr lernen möchte:

* [[Common Mistakes|Häufige Fehler]] ''(A revision of Maximus's tutorial on the forums, and continuation of Taran's Misconceptions tutorial)''
* [[Internet and Sphere]] ''(And how to make the right use of them)''
* [[Languages Tutorial]] ''(How to script your own language system)''
* [[Making your own Skills]] ''(How to make and customize your skill)''
* [[Mul Patching Tutorial|Nazghul's Mul Patching Tutorial]] [http://sorea.profitux.cz/patching/ external link] ''(A document about mul patching and customizing your server)''
* [[Overriding Hardcoded Commands]] ''(How to override hardcoded commands and functions)''
* [[Scheduled Reboot]] ''(How to schedule system reboots)''
* [[Using MySQL]] ''(How to use MySQL)''

==Referenzkompendium==

* [[:Category:Definitions|Definitions]]
** [[CHARDEF|Characters]]
** [[DIALOG|Dialogs]]
** [[EVENTS|Events]]
** [[ITEMDEF|Items]]
** [[MENU|Menus]]
** [[REGIONRESOURCE|Region Resources]]
** [[REGIONTYPE|Region Types]]
** [[AREADEF|Regions]]
** [[ROOMDEF|Rooms]]
** [[SKILLCLASS|Skill Classes]]
** [[SKILLMENU|Skill Menus]]
** [[SKILL|Skills]]
** [[SPAWN|Spawn Groups]]
** [[SPELL|Spells]]
** [[TYPEDEF|Types]]
* [[:Category:Objects|Objects]]
** [[Accounts]]
** [[Characters]]
** [[Database]]
** [[Files]]
** [[GM Pages]]
** [[Items]]
*** [[Special Items]]
** [[Map Points]]
** [[Parties]]
** [[Regions]]
** [[Rooms]]
** [[Sectors]]
** [[Server]]
* [[:Category:Scripts|Scripts]]
** [[:Category:Functions|Functions and Triggers]]
** [[:Category:Variables|General Functions, Properties and References]]
** [[Intrinsic Functions]]
** [[:Category:Statements|Statements]]

==Andere Artikel==

* [[Armor Calculation]]
* [[Client Changes]]
* [[Common Scripting Misconceptions]]
* [[Custom Object Properties]]
* [[Error Codes]]
* [[Experience System]]
* [[How Combat Works]]
* [[Occam's Razor]]
* [[Optimization|Optimization Theory]]
* [[Override TAGs]]
* [[Revisions Changelog]]
* [[Sendpacket]]
* [[Skill Gain Theory]]
* [[The Process of Scripting]]

==External Links==

* [http://www.sphereserver.net/ Offizielle SphereServer Webseite]
* [http://prerelease.sphere.torfo.org/ Offizielle Sphere 56b Downloads]
* [http://nightly.prerelease.sphere.torfo.org/ Offizielle Sphere 56b Nightly Builds]
* [http://scriptsharing.dv-team.de/ ScriptSharing]
* [http://www.cs.rit.edu/~djr7581/ Taran's Scripting for Dummies (Sphere 55i)]
* [http://uo.torfo.org/packetguide/ Jerrith's UO Packet Guide]
* [http://uo.torfo.org/packetguideKR/ Wyatt&Kons's UOKR Packet Guide]

[[Category: Navigation]]

De:Chapter 3

2011-06-25T22:19:47Z

Sirius: /* NPC Evolution */

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

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

<tt>[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 </tt>

-- 
Die Uebersetzung endet hier. Wer moechte darf gerne weiter uebersetzen :) 
--

'''[CHARDEF 0490]''' We've seen this before. It says "Hey SPHERE! Everything after this line until the next header is going to define a character!" What is this character going to be? Well, right now we have no idea, it's just 0490 to SPHERE. The 0490 also shows the client what anim to show (except for monsters with the ID field, which will show the ID field anim). You can also use the char defname in the [CHARDEF x] field instead of a number (which is better for new npcs), for example: [CHARDEF c_new_monster]

'''DEFNAME=C_H_ALCHEMIST''' This is the '''defname''' for this script, obviously. We've seen things like this so many times, I don't believe I need to go over it. But now at least we have a more memorable name for this script. It's obviously a character (C), a human (H), and an alchemist ('''C_H_ALCHEMIST'''). Try to make your '''DEFNAMEs''' make sense based on what the character is. Calling this c_robed_man would have absolutely no memorable qualities. :)

'''NAME=#NAMES_HUMANMALE the Alchemist''' This is where SPHERE does some funky stuff. First of all, if you remember from the SPHERE_NAME.SCP lesson in [[Chapter 2]], it is going to replace #NAMES_HUMANMALE with an actual name for this NPC, such as "Fritz", "Bob" or the ever popular "Roderick". The second thing it is going to do is divide this name into a NAME and a TITLE. Where does it do this division? At the word "the". So writing this line is equivalent to:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 3

2011-06-25T22:04:27Z

Sirius: Erstellung der deutschen Uebersetzung des 3. Kapitels (Erst ein kleiner Anfang)

{{Languages|Chapter_3}}

==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:

<tt>[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 </tt>

--
Die Uebersetzung endet hier. Wer moechte darf gerne weiter uebersetzen :)
--

As you can see, this is a rather incomplete script. It's actually one of the least complete of any of the scripts available in the spherechar_*.scp files. Here is a more complete example of an NPC script:

<tt>[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 </tt>

'''[CHARDEF 0490]''' We've seen this before. It says "Hey SPHERE! Everything after this line until the next header is going to define a character!" What is this character going to be? Well, right now we have no idea, it's just 0490 to SPHERE. The 0490 also shows the client what anim to show (except for monsters with the ID field, which will show the ID field anim). You can also use the char defname in the [CHARDEF x] field instead of a number (which is better for new npcs), for example: [CHARDEF c_new_monster]

'''DEFNAME=C_H_ALCHEMIST''' This is the '''defname''' for this script, obviously. We've seen things like this so many times, I don't believe I need to go over it. But now at least we have a more memorable name for this script. It's obviously a character (C), a human (H), and an alchemist ('''C_H_ALCHEMIST'''). Try to make your '''DEFNAMEs''' make sense based on what the character is. Calling this c_robed_man would have absolutely no memorable qualities. :)

'''NAME=#NAMES_HUMANMALE the Alchemist''' This is where SPHERE does some funky stuff. First of all, if you remember from the SPHERE_NAME.SCP lesson in [[Chapter 2]], it is going to replace #NAMES_HUMANMALE with an actual name for this NPC, such as "Fritz", "Bob" or the ever popular "Roderick". The second thing it is going to do is divide this name into a NAME and a TITLE. Where does it do this division? At the word "the". So writing this line is equivalent to:

<tt>''NAME=#NAMES_HUMANMALE'' 
''TITLE=the Alchemist'' </tt>

'''ID=C_MAN''' Here is where we actually tell SPHERE what this thing is. What is C_MAN? It's a '''DEFNAME''' obviously, but for what? Look up toward the top of this file, and you'll see the definition of the ''C_MAN'' character.

And so on. As you can see, we're just duplicating what we've written in the previous section. But with the newer versions of SPHERE we don't need to do that. Our character 0490 automatically gets everything that comes default on a C_MAN, including abilities, icons, and sounds, UNLESS WE SAY OTHERWISE. In programming, this is called inheritance. The new, more specific character inherits the properties of the less specific one.

You'll notice that we respecify DESIRES and AVERSIONS. Why do we do this if '''C_MAN''' has already told us what this type of character wants and doesn't want? Well I'm not sure in the case of AVERSIONS, because, well, they're the same. But the DESIRES of an alchemist are different than the DESIRES of a generic man, so we tell SPHERE, "Hey, replace the '''C_MAN''' desires with our new ones!"

'''TSPEECH=''' What do you suppose those cryptic names are following this statement? Of course, they're DEFNAMEs, but for what? If you look through your files, chances are you won't find those defined anywhere.. But what's this? We have a folder called speech that comes preconstructed in the zip file. Looking through those files reveals a wealth of '''[SPEECH]''' block definitions. The default ones can be found at the SPEECH folder on your scripts folder.

We'll look at a very simple speech script right now. I am not taking this from any file.

<tt>''[SPEECH spk_human_test]'' 
''ON=*hello*'' 
''SAY Cheese!'' </tt>

In our script, if we were to write '''TSPEECH=spk_human_test''', our NPC would respond with "Cheese!" any time we said "hello" to him. You might be wondering why I have surrounded this word with stars '''(*)'''. In programming lingo, a star means ''"ANYTHING"''. So you could say "I want to eat you hello goodbye" and the NPC would still respond with "Cheese!", because the word "hello" was present.

Of course, SPEECH is much more complicated than that and we'll look at it again when we reach the chapter on basic event scripting. Just know for now that you can have as many TSPEECH lines as you wish in a CHARDEF section.

'''TEVENTS=''' We've already covered this in a very very tiny amount of detail in Chapter 1. This is where events for the creature are defined. As you can see, this creature contains a great deal of events. They define everything from what he says when he hears an unknown word ("Huh?"), to what he does when he sees a new player. We'll look at an event script in Chapter 8. You should learn the basics of item scripting before you try NPC event scripting. For now just know that you can retrieve all the TEVENTS of a npc by using <[REF].TEVENTS>.

'''ON=@Create''' Actually, I lied. @Create is an event, and we're going to talk about it right now. But it's a special event, as is the next one we're going to discuss. Basically, @Create causes every line after it to be processed (the entire section highlighted in red) when an object is Created. Creative eh? (Ha, ha.) In this case, I'm not going to concentrate on most of the lines following, as they should all make sense to you now. All you need to know at this point about @Create is that things you can change IN GAME go under this section. This includes stats, skills, unlootable items, colors, brain types, and TAGs (Although tags can be defined on CHARDEF too, it's a great way to set a tag to all npcs with that chardef without needing to do a restock or change one by one) (You don't know what a TAG is? Good, I haven't taught you yet.).

'''ALCHEMY={55.0 77.0}''' This line is very deceiving, and the reason for the deception is the way that SPHERE processes numbers. SPHERE cannot, ever, read a decimal number. 55.0 means nothing to SPHERE, and it simply strips out the decimal point. Now, isn't it convenient that internally, skills are stored as big numbers? Look at your skills menu in-game right now. Find a skill that isn't zero, obviously, and look at the value.

It looks like this: 42.0

Now, in-game again, type this command: .set [skillname] 42 (Of course, replacing [skillname] with the skill of your choice. Refer to spheretables.scp if the name you're typing doesn't work.) What happened? Your skill suddenly went to 4.2!! Is this an error in the game? No, actually it's because skills are stored by removing the decimal point. If you have 100.0 in blacksmithing, your skill is actually set to 1000. If you have 75.2 in a skill, that skill is 752.

This may seem like a simple concept, but it also applies to the REST of scripting as well. Any time you type a number like 55.0, SPHERE eliminates the decimal. So our example line above is actually this:

<tt>ALCHEMY={550 770}</tt>

Isn't that sneaky?

One of the times you might want to remember this is later, if you are multiplying numbers:

4 * 0.5

Sphere translates this as "4 times 5" and you get 20, rather than the 2 you were expecting. As you can see, this may cause serious problems. I'll show in later chapters how to get around this problem. I just wanted to point out here that it exists. (Look back at the resource tables in sphereregion.scp for another example of where sneaky decimal points are used.)

'''NPC=brain_vendor''' Ok, so I'm out of order. Deal with it.

All NPCs in the game are controlled by specific intelligences, which direct the way they act in certain situations. For instance, this alchemist is a brain_vendor, which means he responds to commands like "buy" and "sell" by opening up a trade window. It also means that he is allowed to have extra storage space for information dealing with the items he can buy and sell. (Actually they are additional containers stored on the vendor, but we shall see that later.) Here is a list of the other intelligences available (I bet you can't guess which file I pulled this from):

<tt>[DEFNAME brains] 
BRAIN_NONE 0 // Players: No brain. Convenient eh? :) 
BRAIN_ANIMAL 1 // Animals: wander, attack only if attacked 
BRAIN_HUMAN 2 // Human: wander and speak 
BRAIN_HEALER 3 // Healer: heal ghosts in proximity 
BRAIN_GUARD 4 // Guard: attack bad guys I see 
BRAIN_BANKER 5 // Banker: you can access your bank through him 
BRAIN_VENDOR 6 // Vendor: buys and sells things 
BRAIN_BEGGAR 7 // Beggar: follows players around asking irritating questions 
BRAIN_ANIMAL_TRAINER 8 // Trainer: can stable animals 
BRAIN_THIEF 9 // Thief: no effect right now 
BRAIN_MONSTER 10 // Evil: attack all players we see 
BRAIN_BESERK 11 // Crazy: attack anything we see 
BRAIN_UNDEAD 12 // Undead: same as evil, just used for identification 
BRAIN_DRAGON 13 // Dragon: breathes fire (set this on a rabbit) 
BRAIN_VENDOR_OFFDUTY 14 // No idea what the difference is here 
BRAIN_TOWNCRIER 2 // Same number as brain_human, same effect 
brain_beserk brain_berserk //Same thing as brain_berserk, just to avoid some errors by typos </tt>

'''ITEMNEWBIE=''' This creates the specified item with the attr_newbie on the char.

'''ON=@NPCRestock''' I lied twice! This is the SECOND event you're going to learn in this script. This event is triggered when a "restock" happens in-game. This occurs once every few real-time hours, or if a staff member types ".sector.restock". What you should put here is anything lootable from this NPC, along with the definitions of things they buy and sell. Once again, this is just a template in most cases, so you should know how to deal with it. I'm going to examine two lines though:

'''SELL=VENDOR_S_ALCHEMIST''' 
'''BUY=VENDOR_B_ALCHEMIST'''

This defines what the vendor buys and sells? But where are these mysterious lists of items coming from? Actually, they're templates, in the file spheretemp_vend.scp. (Templates for vendors. Those developers are so creative.) Actually it's a good thing to name files after what's inside of them. :)

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!

<tt>[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 </tt>

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:

<tt>MOREP=1,2,3,4 </tt>

It is exactly the same as writing:

<tt>MOREX=1 
MOREY=2 
MOREZ=3 
MOREM=4 </tt>

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.

<tt>MOREP=10,42,51,53 
MOREX=78 
MOREY=89 
MOREM=56 </tt>

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.

<tt>MORE1=0FFFFFFFF 
MORE1L=01234 
MORE1H=0F0 </tt>

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:

<tt>MOREP=s_flamestrike,50.0 
MORE2L=10 </tt>

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 [[TYPEDEF|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

{| border="1" width="100%" height="400"
! width="15%" | Value
! width="25%" height="16" | DEFNAME
! height="16" | Description
|-
| width="15%" | 01
| width="25%" height="21" | attr_identified
| height="21" | Someone has used the Item ID skill on this item so it will display the full magic name "+7 Sword of Ruin of Flamestrike".
|-
| width="15%" | 02
| width="25%" height="21" | attr_decay
| height="21" | The item will decay when the internal decay timer, or the item's TIMER reaches zero.
|-
| width="15%" | 04
| width="25%" height="21" | attr_newbie
| height="21" | The item will not be placed in a corpse upon death.
|-
| width="15%" | 08
| width="25%" height="21" | attr_move_always
| height="21" | 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.
|-
| width="15%" | 010
| width="25%" height="21" | attr_move_never
| height="21" | Locked down. Probably the one you'll use most often. It will never decay, even if the decay flag is set.
|-
| width="15%" | 020
| width="25%" height="21" | attr_magic
| height="21" | This item has been enchanted
|-
| width="15%" | 040
| width="25%" height="21" | attr_owned
| height="21" | 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.
|-
| width="15%" | 080
| width="25%" height="21" | attr_invis
| height="21" | Invisible to non-GM clients
|-
| width="15%" | 0100
| width="25%" height="21" | attr_cursed
| height="21" | Cursed item, casts curse on the wearer while it's equipped
|-
| width="15%" | 0200
| width="25%" height="21" | attr_cursed2
| height="21" | I have no idea what the difference is.. strength maybe?
|-
| width="15%" | 0400
| width="25%" height="21" | attr_blessed
| height="21" | Casts bless on the person who is equipping it (stat gain)
|-
| width="15%" | 0800
| width="25%" height="21" | attr_blessed2
| height="21" | ?
|-
| width="15%" | 01000
| width="25%" height="21" | attr_forsale
| height="21" | In a vendor's sell-box or buy-box.
|-
| width="15%" | 02000
| width="25%" height="21" | attr_stolen
| height="21" | This item has been stolen (from the town probably)
|-
| width="15%" | 04000
| width="25%" height="21" | attr_can_decay
| height="21" | I think this is used to get rid of those irritating errors "TIMER has expired without decay flag".
|-
| width="15%" | 08000
| width="25%" height="21" | attr_static
| height="21" | 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:

<tt>ATTR=attr_magic|attr_decay|attr_move_never </tt>

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:

<tt>[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 </tt>

[[Category:Tutorials]]

De:Chapter 2

2011-03-12T07:03:24Z

Sirius: /* sphere_serv_triggers.scp */

Chapter 2

2011-03-12T07:03:12Z

Sirius: /* sphere_serv_triggers.scp */

{{Languages|Chapter_2}}

==spheretables.scp==

Spheretables.scp is the very first file read by SPHERE after SPHERE.ini, and therefore it is the most important. Almost all of the secondary settings are contained within this file, wich makes this very important. Now, let's talk about this very important file in topics:

<nowiki>==</nowiki> [RESOURCES] ==

The first thing you'll see when you open this file is a list of resources. This is marked by (SURPRISE!) a [RESOURCE] tag. It looks something like this:

<tt>[RESOURCES] 
scripts/sphere_defs.scp 
scripts/sphere_book.scp 
scripts/sphere_backward_compatibility.scp 
scripts/sphere_events_human.scp 
scripts/sphere_events_npcs.scp 
scripts/npcs/ 
... </tt>

This tells sphere what files to load and in what order to do so. You must change it carefully sometimes, put scripts with a lot of DEFNAMES, REGIONS, and other global used settings first, to avoid errors when sphere starts (although those errors won't harm your server). For example, we looked at a gold script in Chapter 1 that had a line like this:

TYPE=t_gold

Now, unless SPHERE loads sphere_defs.scp before the script containing the gold, it will have no idea what t_gold means, and will give you an error. This is because t_gold is defined within sphere_defs.scp.

Item files should be loaded before template files, and finally character files. Other files may come after this, but these particular files must load in that order. The loot on monsters is comprised of items and templates, and unless SPHERE has already loaded the file containing these items and templates, you will get hundreds of fun errors to track down and correct. Actually, it isn't very hard to correct, but it's irritating to start up the program and have a thousand errors scroll up your screen.

'''Note''': ''You can make sphere load a full folder instead of putting each file, that's why we have this scripts/ as the last file on the [RESOURCES] tag, so sphere loads all other scripts that might have been out of the list.''

<nowiki>==</nowiki> [OBSCENE] ==

The next section is self-explanatory, [OBSCENE]. This defines "illegal names". If a player creates a character with a name on this list, it will tell him that the name is unavailable and to pick another. If you are a punk who enjoys cussing at others, this list might be a good place to expand your knowledge of obscenities.

<nowiki>==</nowiki> [NOTOTITLES] ==

This defines the title that will be shown related to the player's karma. Do not touch this section. If you remove a line inadvertently, your server WILL NOT RUN. Only change them.

<nowiki>==</nowiki> [PLEVEL X] ==

These sections define the commands available to the various account plevels. Any command not listed is automatically assumed to be in the plevel 4 category. This includes self-defined functions (see [[Chapter 6]]). As you can see, there is quite an extensive list of functions and commands.

'''Note''': ''You don't have to put every function you make in this section as you can have various sections in different scripts, although I recommend that you put them here just for organization purposes.''

<nowiki>==</nowiki> [RUNES] ==

This is the list of those words you say when casting a spell (An, Lor, In, etc). You can play with them, but it'll become very confusing. =P

==Sphere.ini==

Sphere.ini contains all of the internal options for the Sphere emulator. In order to configure your shard, this is the file you will start with. In order to explain this better, I'm just going to add more explanatory comments throughout the file. My comments and additions/changes will be in '''bold text'''.

<tt>//**************************************************************************** 
// SPHERE by : Menasoft 1997-2003 
// www.sphereserver.com 
// All SPHERE script files and formats are copyright Menasoft & Partners. 
// This file may be freely edited for personal use, but may not be distributed 
// in whole or in part, in any format without express written permission from 
// Menasoft & Partners. All donations and contributions 
// become the property of Menasoft & Partners. 
//**************************************************************************** 
 
/////////////////////////////////////////////////////////////// 
//////// General Information 
/////////////////////////////////////////////////////////////// 
 
[SPHERE] 
// Name of your Sphere shard 
ServName='''WarAngel's Test Centre''' 
// The IP of your server, this will be 127.0.0.1 almost always 
ServIP=127.0.0.1 
// The port of your server, this is 2593 by default 
ServPort=2593 
 
// Admin's contact email 
AdminEmail='''warangel999@msn.com''' 
// Web page for this server 
URL=www.myshard.com Replace www.myshard.com with your shard's URL' 
// GMT offset, from -12 to +12 [London=0, EST=5, etc] 
TimeZone='''-5 Eastern Time (US & Canada). Change this to fit your timezone''' 
 
// Official staff language 
Lang=English 
// Start this as a system service on Win2000, XP, NT 
NTService=0 '''Enabling this removes the ability to use the console.''' 
 
// MySql configuration. 
//MYSQL=0 '''Set this to =1 to enable MySQL''' 
//MySqlHost='''localhost This will almost always be localhost if the MYSQL host is located on the same computer as your shard''' 
//MySqlUser= 
//MySqlPassword= 
//MySqlDatabase= 
 
/////////////////////////////////////////////////////////////// 
//////// File Locations 
/////////////////////////////////////////////////////////////// 
// Directory where spheretables.scp is located, from there we will 
// load any additional scripts 
ScpFiles=scripts/ 
 
// Where your sphereworld.scp and spherechars.scp are located 
WorldSave=save/ 
 
// Where your sphereaccu.scp and sphereacct.scp is located 
AcctFiles=accounts/ 
 
// Where your UO installation is located. This need: map0.mul, statics0.mul, 
// staidx0.mul, multi.mul, multi.idx, hues.mul, tiledata.mul. 
// Optional files: verdata.mul, mapX.mul/staticsX.mul/staidxX.mul for higher 
// maps support (Malas, etc). 
// 
// Note that if not set, sphere will scan windows registry to auto-detect it 
//MulFiles=mul/ 
 
// Where your log files will be saved by sphere 
Log=logs/ 
 
/////////////////////////////////////////////////////////////// 
//////// World Save Information 
/////////////////////////////////////////////////////////////// 
// How often for Sphere to save your world (minutes) 
SavePeriod=20 
 
// How many backup levels to keep. Each level means 7 backups done for it. 
// So, 10*7 = 70 backup saves will be storied. 
BackupLevels=10 
 
// On would save in the background quietly over a longer period of time, and not interrupt the game 
// Off would notify "World save has been initiated" and save faster, but pause the game momentarily 
SaveBackground=0 
 
/////////////////////////////////////////////////////////////// 
//////// Account Management 
/////////////////////////////////////////////////////////////// 
//Code for servers account application process 
// 0=Closed, // Closed. Not accepting more. 
// 2=Free, // Anyone can just log in and create a full account. 
// 3=GuestAuto, // You get to be a guest and are automatically sent email with u're new password. 
// 4=GuestTrial, // You get to be a guest til u're accepted for full by an Admin. 
// 6=Unspecified, // Not specified. 
// To enable auto account you must set this to 2 
AccApp=0 
 
// Store password hashed with MD5 '''MD5 is a safer encryption method for saving passwords. More information on it [http://en.wikipedia.org/wiki/MD5 here]''' 
Md5Passwords=0 
 
// local ip is assumed to be the admin 
LocalIPAdmin=1 
 
// Number of chars allowed per account 
MaxCharsPerAccount=5 
 
// Min time for a char to exist before delete allowed (in seconds) 
MinCharDeleteTime=3*24*60 
 
// Max number of Guest accounts allowed 
GuestsMax=0 
 
/////////////////////////////////////////////////////////////// 
//////// Client Management 
/////////////////////////////////////////////////////////////// 
// What client protocol version used 
// Comment out the ClientVersion line to allow any client that is supported. 
//ClientVersion=2.0.3 
 
// Set this to 0 to block login to encrypted clients '''Default client uses encryption''' 
UseCrypt=1 
 
// Set this to 1 to allow login to unencrypted clients '''You can use tools such as [http://stud4.tuwien.ac.at/~e9425109/UO_RICE.htm UO Rice] and [http://www.uogateway.com/ UOGateway] to remove encryption on a client''' 
UseNoCrypt=0 
 
// Maximum total open connections to server 
ClientMax=256 
 
// Maximum open connections to server per IP 
ClientMaxIP=16 
 
// Maximum total (not-in-game) connections to server 
ConnectingMax=32 
 
// Maximum total simultaneous (not-in-game) connections to server per IP 
ConnectingMax=8 
 
// How long logged out clients linger in seconds 
ClientLinger=15 
 
// Walk limiting code: buffer size (in tenths of second) 
WalkBuffer=75 
 
// Walk limiting code: regen speed (%) 
WalkRegen=25 
 
// Only commands issued by this plevel and higher will be logged 
CommandLog=0 '''0 means that all commands will be logged''' 
 
// Prefix for ingame commands 
CommandPrefix=. 
 
// Use the built in http server 
UseHttp=1 
 
// Use the built in god port 
UseGodPort=0 '''This is for use with the God client''' 
 
// Default setting for all accounts specifying default resdisp. Recommended 
// specifying at least 1 (T2A) here. 
//AutoResDisp=0 '''0=automatic detect, 1=T2A, 2=LBR, 3=AoS, 4=SE, 5=ML''' 
 
// Default setting for new accounts specifying default priv level 
//AutoPrivFlags=010 
 
/////////////////////////////////////////////////////////////// 
//////// Game Mechanics 
/////////////////////////////////////////////////////////////// 
// Do not allow entering under roof being on horse? 
MountHeight=0 
 
// Archery does not work if too close (0 = not checked) 
ArcheryMinDist=2 
 
// Maximum Distance for Archery 
ArcheryMaxDist=15 
 
// Speed scale factor for weapons '''Formula is now DELAY = SPEEDSCALEFACTOR /((DEX + 100) * SPEED)''' 
SpeedScaleFactor=15000 
 
// This is the percent of max weight at which stamina is lost half the time 
// (200 = no effect) 
StaminaLossAtWeight=150 
 
// Weight penalty for running +N% of max carry weight (0 = no effect) 
RunningPenalty=50 
 
// Show people joining/leaving the server 
ArriveDepartMsg=1 
 
// Are house and boat keys newbied automatically 
AutoNewbieKeys=1 
 
// Maximum number of items allowed in bank 
BankMaxItems=1000 
 
// Maximum weight in stones allowed in bank 
BankMaxWeight=1000 
 
// If 1 vendors will take gold only from backpack 
PayFromPackOnly=0 '''If set to 0, vendors also take gold from the bank''' 
 
// Disable weather effects? 
NoWeather=1 
 
// Default light level in dungeons 
DungeonLight=27 '''0 is brightest, 30 is darkest''' 
 
// Day light level 0-30 '''0 is brightest, 30 is darkest''' 
LightDay=0 
 
// Night light level 0-30 
LightNight=25 
 
// Wool Regen Time (in minutes) 
WoolGrowthTime=30 
 
// Suppress player speech with 75% of capital letters 
SuppressCapitals=0 
 
// Extra combat flags to control the fight (default:0, 0.55i compatible) 
// COMBAT_NODIRCHANGE 00001 // not rotate player when fighting (like was in 0.51a) 
// COMBAT_FACECOMBAT 00002 // allow faced combat only (recommended) 
//CombatFlags=0 '''If both of these are enabled, it means the player has to keep turning to face his opponent in order to strike''' 
 
/////////////////////////////////////////////////////////////// 
//////// NPC/Item/Player Management 
/////////////////////////////////////////////////////////////// 
// Distance in tiles before an NPC that's wandered too far from it's home will teleport back 
LostNPCTeleport=50 
 
// Wether PCs get a resurrection robe when they get resurrected. 
NoResRobe=0 
 
// Time for a NPC corpse to decay mins 
CorpseNPCDecay=10 
 
// Time for a playercorpse to decay mins 
CorpsePlayerDecay=15 
 
// Base decay time in minutes for items 
DecayTimer=30 
 
// Put [NPC] tags over chars '''or [TAME], if the creature is tamed''' 
CharTags=0 
 
// Flip dropped items 
FlipDroppedItems=0 
 
// Monsters run when scared of death 
MonsterFear=0 
 
// Monsters may fight each other 
MonsterFight=0 
 
// Percent setting of the all NPC move rate, default 100 
MoveRate=100 
 
// Do players receive sounds 
GenericSounds=1 
 
// Max number of items to sell to one person at once 
VendorMaxSell=255 
 
// Max level npc trainers can go 
NPCTrainMax=300 '''300 is 30.0 skill''' 
 
// Percent of own ability npcs can train to 
NPCTrainPercent=30 
 
// Max level of skill trainable on dummies, archery butte ect.. 
SkillPracticeMax=300 '''300 is 30.0 skill''' 
 
// Max skill player's will start with on skills they haven't chosen during char create 
MaxBaseSkill=200 '''Set this to 0 for players to start with no skills other than the selected ones''' 
 
// Time in seconds for hitpoint regeneration 
Regen0=40 
 
// Time in seconds for mana regeneration 
Regen1=20 
 
// Time in seconds for stamina regeneration 
Regen2=10 
 
// Time in minutes for food regeneration 
// 1*60*24 = 1 day of real life time 
Regen3=1*60*24 
 
// Speech block associated to players 
SpeechSelf=spk_player 
 
// Speech block associated to pets 
SpeechPet=spk_pet 
 
// When player skills/stats goes this times more than skillclass allowed, drop 
// them to skillclass level. Setting this to 0 disables the action. 
OverSkillMultiply=2 
 
// NPC AI settings 
// NPC_AI_PATH 0001 NPC pathfinding 
// NPC_AI_FOOD 0002 NPC food search (objects + grass) '''This makes npcs look for food (specified on their FOODTYPE sections) and grass to eat''' 
// NPC_AI_EXTRA 0004 NPC magics, combat, etc 
//NPCAI=0 
 
/////////////////////////////////////////////////////////////// 
//////// Crime/Murder/Karma/Fame/Guard Settings 
/////////////////////////////////////////////////////////////// 
// Karma when player goes from good to neutral (from -10000 to 10000) 
PlayerNeutral=-2000 
 
// How many minutes are criminals flagged for 
CriminalTimer=3 
 
// Times a player can snoop before becoming a criminal 
SnoopCriminal=20 
 
// Seconds time to decay a murder count (default 8*60*60 is 8 hours) 
MurderDecayTime=8*60*60 
 
// Amount of murders before we get title 
MurderMinCount=1 
 
// Looting or carving a blue player is a crime 
LootingIsaCrime=1 
 
// Flag players criminal for helping criminals? 
HelpingCriminalsIsaCrime=1 
 
// How long do guards linger about in minutes 
GuardLinger=3 
 
// Will guards kill instantly or follow normal combat rules 
GuardsInstantKill=1 
 
// Limits the MAXHITS/MAXMANA/MAXSTAM changes 
// STAT_FLAG_NORMAL 0x00 // MAX* status allowed (default) 
// STAT_FLAG_DENYMAX 0x01 // MAX* denied 
// STAT_FLAG_DENYMAXP 0x02 // .. for players 
// STAT_FLAG_DENYMAXN 0x04 // .. for npcs 
StatsFlags=0 
 
/////////////////////////////////////////////////////////////// 
//////// Server Mechanics 
/////////////////////////////////////////////////////////////// 
// Experimental flags 
// Flags for options that affect server behaviour and which might affect compatibility 
// See the revisions.txt file for more details on this 
// EF_DiagonalWalkCheck = 00000001 
// EF_UNICODE = 00000002 // No on Linux '''Enables new Unicode fixes''' 
// EF_Scripts_Ret_Strings = 00000004 
// EF_New_Triggers = 00000008 
// EF_Scripts_Parse_Verbs = 00000010 
// EF_Intrinsic_Locals = 00000020 //'''Allows locals to be referenced differently. For example: <local.X> can be referenced as just <X>''' 
// EF_Item_Strict_Comparison = 00000040 //'''Disables similars items being compared instead of specific items, such as cloth, leather, hides, log, boards, arrow, bolt being compared when the server tries to find an arrow.''' 
// EF_WalkCheck = 00000100 '''//Fixes a lot of house looting bugs, and other walkchecking related problems.''' 
// EF_Script_Profiler = 00000400 
// EF_Size_Optimise = 00000800 
// EF_Minimize_Triggers = 00001000 //Minimize trigger calls (use only 0.51 triggers) 
Experimental=00000 
 
// Option flags 
// Flags for options that affect server behaviour but not compatibility 
// See the revisions.txt file for more details on this 
// OF_Magic_IgnoreAR = 00000001 //'''Does magic ignore a players armor statistics?''' 
// OF_Magic_CanHarmSelf = 00000002 //'''Can a player harm himself with magic? (using Magic Arrow to unparalyze oneself, for example)''' 
// OF_Magic_StackStats = 00000004 
// OF_Archery_CanMove = 00000010 //'''Can a player move and shoot at the same time?''' 
// OF_Magic_PreCast = 00000020 //'''Allow pre-casting of spells, or freeze a player in place while they cast?''' 
// OF_Items_AutoName = 00000040 
// OF_FileCommands = 00000080 //'''This enables all file commands, such as writefile, etc.''' 
// OF_NoItemNaming = 00000100 //'''If enabled, prevents Sphere from naming crafted items such as "sword craft by Player''' 
// OF_NoHouseMuteSpeech = 00000200 //'''Can players inside a house hear players outside, and vice-versa?''' 
// OF_Multithreaded = 00000400 //'''Do not set while server is running !!! (Make *Nix server unstable) Puts account handling in a second thread''' 
// OF_Advanced_LOS = 00000800 
// OF_Flood_Protection = 00001000 
OptionFlags=0200 
 
// FeatureT2A, used to control T2A expansion features ( default 03 ) 
// FEATURE_T2A_UPDATE 01 // Monster and Lost lands 
// FEATURE_T2A_CHAT 02 // In game chat 
FeatureT2A = 03 
 
// FeatureLBR, used to control LBR expansion features ( default 0 ) 
// FEATURE_LBR_UPDATE 01 // Lbr Monsters 
// FEATURE_LBR_SOUND 02 // MP3 instead of MIDI 
FeatureLBR = 0 
 
// FeatureAOS, used to control AOS expansion features ( default 0 ) 
// Enabling one of them automagically enables AoS basic features 
// FEATURE_AOS_UPDATE 01 // Basic AoS feature 
// FEATURE_AOS_POPUP 02 // Popup infos 
// FEATURE_AOS_DAMAGE 04 // Damage shown on hit 
// FEATURE_AOS_PALNECRO 08 // Fightbook and Paladin/Necro on char creation 
// FEATURE_AOS_TOOLTIP 010 // Tooltips 
FeatureAOS = 0 
 
// FeatureSE, used to control SE expansion features ( default 0 ) 
// FEATURE_SE_UPDATE 01 // Basic SE features 
// FEATURE_SE_NINJASAM 02 // Ninja and Samurai 
FeatureSE = 0 
 
// FeatureML, used to control ML expansion features ( default 0 ) 
// FEATURE_ML_UPDATE 01 // Basic ML features 
FeatureML = 0 
 
// In game effects to turn on and off 
// Messages echoed to the server console while in debug mode 
// DEBUGF_NPC_EMOTE = 0x0001 
// DEBUGF_ADVANCE_STATS = 0x0002 
// DEBUGF_WALKCODES = 0x0080 // try the new walk code checking stuff 
// DEBUGF_NPCAI = 0x0100 // some NPC AI debugging 
// DEBUGF_EXP = 0x0200 // experience gain/loss 
// DEBUGF_LEVEL = 0x0400 // experience level changes 
DebugFlags=0 
 
// Console Hears all that is said on the server 
HearAll=1 
 
// Secure mode attempts to ignore errors, protect from accidently shutdowns 
Secure=1 
 
// Value from 1 to 32, set sectors inactive when unused to conserve resources 
SectorSleep=10 
 
// Disconnect inactive socket in x min 
DeadSocketTime=5 
 
// Always force a full garbage collection on save 
ForceGarbageCollect=1 
 
// Time before restarting when server appears hung (in seconds) 
FreezeRestartTime=60 
 
// Length of the game world minute in real world in seconds 
GameMinuteLength=60 
 
// Bit Mask of the subjects you want to log when logging is on 
// LOGM_ACCOUNTS 0x00080 
// LOGM_SAVE 0x00200 // world save status. 
// LOGM_CLIENTS_LOG 0x00400 // all clients as they log in and out. 
// LOGM_GM_PAGE 0x00800 // player gm pages. 
// LOGM_PLAYER_SPEAK 0x01000 // All that the players say. 
// LOGM_GM_CMDS 0x02000 // Log all GM commands. 
// LOGM_CHEAT 0x04000 // Probably an exploit ! 
// LOGM_KILLS 0x08000 // Log player combat results. 
// LOGM_HTTP 0x10000 
// 01ffff log everything 
LogMask=01ec80 
 
// Amount of time to keep map data cached in sec 
MapCacheTime=120 
 
// Max NPC chars for a sector to prevent lag 
MaxComplexity=32 
 
// Amount of items in one tile so start showing "too many items here" 
MaxItemComplexity=25 
 
// Amount of items in one sector to start showing "x items too complex" 
MaxSectorComplexity=1024 
 
// Limit the number of cycles the while/for loop can proceed. Setting this to 
// zero disables the limitation 
MaxLoopTimes=0 
 
/////////////////////////////////////////////////////////////// 
//////// Magic/Effects Settings 
/////////////////////////////////////////////////////////////// 
 
// Allow casting while equipped 
EquippedCast=1 
 
// Words of power for player using magic 
WOPPlayer=1 
 
// Words of power for staff using magic 
WOPStaff=0 
 
// Reagents lost if magic fails 
ReagentLossFail=0 
 
// Magic requires reagents 
ReagentsRequired=0 
 
// What % of hitpoints players will resurrect with. Note, that if you set this 
// too low, people with little STR will have problems resurrecting. 
HitPointPercentOnRez=33 
 
// How many % of hits will the character loose when starving. 0 disables 
//HitsHungerLoss=0 
 
// Amount of skill of lock picking needed to unlock a magically locked door 
MagicUnlockDoor=900 
 
// Teleport effect for GMs and players. Setting 0 disables the effect 
TeleportEffectStaff=03709 
TeleportEffectPlayers=0372a 
 
/////////////////////////////////////////////////////////////// 
//////// Experience and Level system 
/////////////////////////////////////////////////////////////// 
 
// Enable experience system 
//ExperienceSystem=0 
 
// Experience system settings: 
// 0001 gain experience in combat 
// 0002 gain experience in crafts 
// 0004 allow experience to go down 
// 0008 limit experience decrease by a range witheen a current level 
// 0010 auto-init EXP/LEVEL for NPCs if not set in @Create 
// 0020 allow trigger @ExpChange 
// 0040 allow trigger @ExpLevelChange 
//ExperienceMode=0 
 
// If combat experience gain is allowed, use these percents for gaining exp in 
// Player versus Monster and Player versus Player combats. Value 0 disables gain. 
//ExperienceKoefPVM=100 
//ExperienceKoefPVP=100 
 
// Enable levels system (as a part of experience system) 
//LevelSystem=0 
 
// Level system settings: 
// linear = 0 (each NextLevelAt exp will give a level up) 
// double = 1 (you need (NextLevelAt * (level+1)) to get a level up) 
//LevelMode=1 
 
// Amount of experience to raise to the next level 
//LevelNextAt=0 
 
/////////////////////////////////////////////////////////////// 
//////// Webpage Settings 
/////////////////////////////////////////////////////////////// 
 
// Note, that you can catch error codes by creating sphere404.htm and so on 
// for all HTTP error codes sphere support. 
 
[WEBPAGE 1] 
// Determines what html file is used as base for the status page 
WebPageSrc=scripts\web\spherestatusbase.html 
// Determines where the status page is saved 
WebPageFile=scripts\web\status.html 
// In seconds, how often the status file is updated 
WebPageUpdate=60 
// Required PLevel to view this page (0 = anyone, 6 = admins only) 
PLevel=0 
 
/////////////////////////////////////////////////////////////// 
//////// Abuse Control 
/////////////////////////////////////////////////////////////// 
 
// Block these ips from the server 
// 255 is a wildcard, so 255.255.255.255 disables anyone connecting. 
[BlockIP] 
//123.34.45.56 
//123.45.56.78 
 
/////////////////////////////////////////////////////////////// 
//////// Connection Information 
/////////////////////////////////////////////////////////////// 
 
//First line should be the name of your shard (this is what people see when they connect) 
//Second line should be the IP of your shard (this is almost always 127.0.0.1) 
//Third line should be the port of your shard (this should be whatever ServPort is set to) 
 
//Uncomment next 3 lines below this if you have a router 
//First line should be a name different than your shard name above this 
//Second line should be your real/external IP (www.whatismyip.com) 
//Third line should be the shard port (this should be whatever ServPort is set to) 
[SERVERS] 
'''WarAngel's Test Centre''' 
127.0.0.1 
2593 
 
//External 
//my.ip.goes.here 
//2593 
 
[EOF] </tt>

'''MAPx''' It isn't present in sphere.ini, but it can be used (just check REVISIONS.txt). You use it like that:

MAPx=max_x,max_y,sector_size,real_map_number.

For example: MAP1=7168,4096,512,-1

will change map 1 size to 7168,4096, the sector sizes of map 1 to 512 tiles and the -1 means it'll call the default mul file for that map.

Another example:

MAP50=7168,4096,64,3

Will activate a map number 50 that has 7168,4096 as size, 64 as sector size and loads map3.mul, statics3.mul and staidx3.mul as it's map file.

==sphere_region.scp==

This script deals with the caracteristics of the places, like what you can mine or lumber, what happens when you enter that place and that kind of things. It also contains most of the resources sections.
Let's start by explaining those:

<tt>[REGIONRESOURCE x]</tt>

This section contains the the skill needed to gather that resource, what resource it gives to the player and the time for it to regen.
Let's take a look at this example (you'll see a commented text "//t_tree" if you have read the previous chapter you'll surelly know what this is, it's a defname)

<tt>[REGIONRESOURCE mr_tree] 
// lumberjacking default 
// t_tree 
SKILL=1.0,80.0 
AMOUNT=9,30 
REAP=i_log 
REGEN=60*60*10 </tt>

Basically this section defines a resource, something that you can gather from the landscape. It compares skill and amount. This particular one says that you may gather a maximum of 9 logs at 1.0 skill and a maximum of 30 logs at 80.0 skill. Anything after that simply increases your chances of getting 30 logs. See that SKILL line? The syntax is SKILL=lower,high. And the AMOUNT line sets the AMOUNT=min,max.
How does it know what to give you? This line: REAP=i_log. This tells the server to create an i_log item if this resource is taken. So you can put anything you want to be gatherable in this REAP setting.
The next line, REGEN, defines how long this resource will take to reappear, in seconds. As we can see here, it's 60*60*10 seconds, or 10 hours. As a GM, if you walk around where players have been chopping wood or mining, you'll see little worldgem bits all over the ground. They look like spawnpoints, but are really resource markers. They mark where a specific resource has been gathered, how much has been gathered, and what type of resource it is. They also have a TIMER which counts down from this very high number (36000) and then decay when it reaches zero.

<tt>[REGIONTYPE r_default_rock t_rock] 
//Random rocks 
RESOURCES=100.0 mr_nothing 
RESOURCES=500.0 mr_iron 
//RESOURCES=6.0 mr_rusty 
//RESOURCES=6.0 mr_old_copper 
//RESOURCES=6.0 mr_dull_copper 
//RESOURCES=4.5 mr_bronze 
RESOURCES=5.0 mr_copper 
RESOURCES=2.0 mr_gold 
RESOURCES=1.0 mr_rose 
RESOURCES=2.0 mr_agapite 
RESOURCES=1.0 mr_bloodrock 
RESOURCES=1.0 mr_silver 
RESOURCES=0.5 mr_verite 
RESOURCES=0.2 mr_Valorite 
RESOURCES=0.1 mr_mytheril 
RESOURCES=0.1 mr_blackrock 
RESOURCES=0.1 mr_diamond </tt>

Wow, you must be saying. What are all these things? mr_iron? mr_agapite? I don't see those anywhere in the file. Now, I bet you'll go to sphere_defs.scp to see if they are DEFNAMEs for something else. And the truth is, they are, but the definitions can be found in sphereitem_ore.scp.

<tt>RESOURCES=50.0 mr_iron</tt>

This should look slightly familiar. Would it look even more familiar if the whole thing looked like this?

<tt>RESOURCES={ mr_iron 50 mr_copper 5 mr_gold 2 mr_rose 2 ...etc... }</tt>

I bet it would, if you were paying attention during the earlier lessons in Chapter 1. This is a weighted list of resources, in a slightly different format than you're used to. But it works exactly the same way. It's also one of the ONLY places in SPHERE scripting that you can use fractional numbers like 0.1 or 0.2. Actually you can't use them here either, but SPHERE successfully hides this as long as you use them in ALL of the RESOURCES. (By the way, do not try to script a RESOURCES identifier as a random selector. SPHERE wont like that. Use the format provided to you.)

[REGIONTYPE r_default_rock t_rock] ''Understanding:'' That r_dafault_rock defines the defname of that REGIONTYPE, which is how you'll access it in other scripts (wait for next section =P). The t_rock is the defname (see sphere_defs.scp for it) of the type of a rock, which shows sphere where your players can gather that resource (you could change it to t_water so they could mine ores on water, which isn't a good idea actually :P)

Hopefully that clears up the sphere_region.scp file for you. We'll tell you in the next section how to use these REGIONTYPE settings to make resources actually available in game.

==sphere_mapX.scp==

Welcome to one of the easiest files in all of SPHERE. This is the spheremap.scp file. It's also the only file that's almost completely done for you. It is a very rare occasion that you need to change this file.

Actually, on that note, I might as well say it from the start. If you change this file, you must restart your server for the changes to take effect. If you do a resync, you'll get over 1000 "Conflicting region" errors.

This section will tell you how to make new regions, like that you go with the .go command.

There are currently 5 files in the default scripts pack, one for each map (Fellucca, Trammel, Ilshenar, Malas and Tokuno) being each one enumerated from 0 to 4 (sphere_map0,sphere_map1,and so on).

I'll use the region of Fellucca as an example for this part of the tutorial, and now here's the script:

<tt>[AREADEF a_world] 
NAME=Felucca 
EVENTS=r_default,r_default_rock,r_default_water,r_default_tree,r_default_grass 
GROUP=ALLMAP 
P=1323,1624,55,0 
RECT=0,0,6144,4096,0 </tt>

Let's understand those lines now:

'''[AREADEF somedef]''': As you have probably noticed a_world is a defname which defines the region for the server so it can be processed.

'''Name''': This line contains the name of the region, which is shown when you do .where inside the region and it also makes you go to that place when doing .go "region name" (do not make 2 regions with the same name, the last that has been loaded will replace the first when you do .go command (which can fuck up a lot of things)).

'''Events''': This defines what will happen in that region and what resources are gatherable here (remember the REGIONTYPE section? It can be used as an event here.). Besides the resources gatherable it'll also show sphere what triggers to call from the events (you've probably realized now that the REGIONTYPE section is an event for regions :P), like the @Enter trigger and the others (see [[Triggers]]).

'''Group''': This is just an axis setting, this separates the regions in groups (duh) when you go to the Travel Menu.

'''P''': This is the place you go when you do .go "region name". Almost all regions will have a P value and it's usually a convenient location in the region to teleport to, or else it's the center of the region. If you are making your own new region, be sure to pick a place you'd like to teleport to.

'''RainChance''': This defines the chance to rain on that region when a weather is called (RainChance=50 means 50% chance of raining), the others 50% means it'll snow.

'''Rect''': This describes the exact boundaries of this region, by coordinates. The first two numbers are the coordinate of the upper left corner of the region, and the second two are the coordinates of the lower right. In the case of Fellucca it stretches from 0,0 to 6144,4096 (RECT=0,0,6144,4096). Since 56B you also need to add a fith argument, the map this region uses so it's RECT=0,0,6144,4096,0 (if the map is 0 you can leave it empty, otherwise you MUST NOT leave it empty or you'll have conflicting regions.

'''Flags''': The region flags allow you to control what goes on in a particular region. They describe whether or not a region is to be guarded, what types of magic are allowed to be cast there, who can be harmed here, or whether or not it is allowed to rain there. Basically anything you could ever want. Here's how you use them:

Just add this line to a region script:

FLAGS=#

Of course you're going to want to replace that # with an actual number! Where do we get those numbers? They're predefined in the game, but they give us a nice handy list. I just showed it to you.

Say we want to make a region that is guarded and safe from harm. We would simply add the two numbers together:

<tt>
::region_flag_safe (02000) 
:+ 
::region_flag_guarded (04000) 
:= 
::06000 </tt>

There you go. Your FLAGS would be set to 06000. "But.. but.." you're saying. "Didn't you tell me that DEFNAMEs were supposed to prevent me from working with scary numbers?" (See [[Chapter 1]].) Of course I did! And there's a way to do this without using any scary number at all. Here it is:

<tt>FLAGS=region_flag_safe|region_flag_guarded</tt>

That's it. Now your region is both safe and guarded.

Which, as you may learn quickly as a new admin, is a big mistake. Making a region safe and guarded at the same time prevents the guards from actually killing anything, so they pile up and call each other, and soon you have a huge laggy mess of guards hacking at something that can't be killed (because it's a safe region). Just take my word for it and don't make a region safe and guarded.

Here's a quick list for the region flags (you should check you sphere_defs.scp for more, cause they may be changed):

<tt>[DEFNAME region_flags] 
region_antimagic_all 00001 // all magic banned here. 
region_antimagic_recall_in 00002 // teleport,recall in to this, and mark 
region_antimagic_recall_out 00004 // can't recall out of here. 
region_antimagic_gate 00008 // can't open gates from or to this place. 
region_antimagic_teleport 00010 // can't teleport into here. 
region_antimagic_damage 00020 // just no bad magic here 
region_flag_ship 00040 // this is a ship region. ship commands 
region_flag_nobuilding 00080 // no building in this area 
region_flag_globalname 00100 // make sure the name is avail globally. 
region_flag_announce 00200 // announce to all who enter. 
region_flag_insta_logout 00400 // instant log out is allowed here. (hotel) 
region_flag_underground 00800 // dungeon type area. (no weather) 
region_flag_nodecay 01000 // things on the ground don't decay here. 
region_flag_safe 02000 // this region is safe from all harm. 
region_flag_guarded 04000 // try tag.guardowner 
region_flag_no_pvp 08000 // players cannot directly harm each other here. </tt>

And that's about it for the sphere_mapX.scp files.

==sphere_book.scp==
Spherebook.scp is one of the most pointless files you will ever encounter. How many times, when you logged onto a shard, did you actually stop to READ those tips, or to READ the updates screen that comes up every time? I know most of my players refused to. But, in any case, that is what's in this file. And books. Did I mention books? Those impossible-to-write-correctly, rarely-used items that waste RAM in-game?

<tt>'''[SCROLL SCROLL_MOTD]''' 
'''[SCROLL SCROLL_NEWBIE]''' 
'''[SCROLL SCROLL_GUEST]''' </tt>

These are the sections that define the messages that pop up when you log in. Anything written after these tags will appear in the appropriate message. You'll have to figure out exactly what spacing is best for those little info boxes. It does take some time, and there's really no way to explain it. Just do it and you'll figure it out. Remember, there is no wordwrap. Or at least there wasn't in the past.

<tt>'''[TIP X]''' </tt>

You guessed it. These are the tips that pop up on startup. "War is unhealthy for children and other living things." is one of them. Very appropriate right now, I would say.

<tt>'''[BOOK title]''' 
'''[BOOK title x]''' </tt>

Creates a book with a DEFNAME of title. Putting a page number x after the DEFNAME will add your text to that particular page. Look at the example books for clues on how to do this. The major difficulty with books is that the game uses a variable-width font, so you don't know an exact number of letters you can have on one line. For example, you can fit more i's on one line than w's or M's, since those letters are bigger. You can start a paragraph by typing a TAB text (clicking yout TAB button :P)

==sphere_name.scp==

This is an easy file. It's just lists of names under sections with various DEFNAMEs. It's these names that are important, not the contents, since you will almost NEVER write your own list of names. I've been using this emulator for two years now, and I have never modified this file once.

To access this list of names, you write this in a script:

'''NAME=#NAMES_HUMANMALE'''

It will automatically replace it with a random name from the '''NAMES_HUMANMALE''' list.

To make a list of names, it'll look like that:

<tt>[NAMES A_DEFNAME_YOU_WANT] 
NUMBER_OF_NAMES 
NAMES </tt>

for example:

<tt>[NAMES NAMES_SPECIAL] 
2 
Hil 
Hol </tt>

Difficult file huh? I almost didn't give it a section to itself.

==sphere_newb.scp==
There! I did it! No vain attempt at humor under the title! :)

In any case, this is another file that a lot of questions are asked about. "How do I make players start with 10000 gold?" people ask. Or, "How do I give all blacksmiths 800 ingots?" Now, I'm not saying I would like to play on a shard where you start with 10000 gold or blacksmiths start with 800 ingots. But this file would be the place to do it.

<tt>[NEWBIE MALE_DEFAULT] 
// Male Generic Starting Clothes 
ITEMNEWBIE=i_shirt_plain 
COLOR=colors_all 
ITEMNEWBIE=random_pants 
COLOR=colors_neutral 
ITEMNEWBIE=random_shoes 
COLOR=colors_neutral 
ITEMNEWBIE=i_dagger 
ITEMNEWBIE=i_candle 
ITEMNEWBIE=i_book_sm 
ITEMNEWBIE=i_gold,100 </tt>

This is what a typical script looks like. It looks kinda like a template doesn't it? Well there's a good reason for that. It really is a template. It just uses the '''ITEMNEWBIE''' tag rather than the '''ITEM''' tag. Look at the section in Chapter 1 on Templates for more information on how to structure this file!

The only real item of note is that these sections MUST have specific names that the server looks for. You cannot add a new newbie section, no matter how much you'd like to. Sorry!

==sphere_skill.scp (SKILLCLASSES)==
Skill classes are what defines how much you can train at each skill/stat and you can also add triggers to it.
A SkillClass script would look like this:

<tt>[SKILLCLASS 0] 
// undeclared class. 
// max skills for players of this skill class. 
// might want this to be all 50.0 to make people declare a class? 
DEFNAME=Class_undeclared 
NAME=undeclared 
// EVENTS=e_ClassUndeclared 
STATSUM=300 
SKILLSUM=10000.0 
STR=100 
INT=100 
DEX=100 
ALCHEMY=100.0 
ANATOMY=100.0 
ITEMID=100.0 
ARMSLORE=100.0 
and so on... </tt>

Now let's understand it:

'''EVENTS''': It means everyone with this skillclass will also call the events specified in this field (to add more events just use a ",", for example: EVENTS=e_1,e_2,and so on)

'''STATSUM''': This is how much the som of your players stats can be, for example, if I have 100 str, 100 dex and 100 int, I've reached 300 stats, so I've reached STATSUM and can't have more (except for magic items and such things)

'''SKILLSUM''': The same thing as STATSUM but for skills.

'''STR/DEX/INT''': This is how much can the player have at this specific stat (except for magic items and such)

'''ALCHEMY''': The same thing as the STR, DEX and INT fields, but for skills (in this case alchemy, but of course you can change to any other)

==sphere_serv_triggers.scp==
This file hold special trigger "functions" that are fired by the server its self at certain times depending on the function, below are a list of the functions found in this file and a breif explain of what the function will do for you.

'''f_onaccount_login'''

This function is called after the client has entered the password.

:ARGS --> username of the client logging in
:ARGO --> the client logging in
:RETURN 0 --> normal action (login)
:RETURN 1 --> disconnect the client

'''f_onaccount_delete'''

This function is called before an account is being deleted.

:ARGS --> username of the account being deleted.
:RETURN 0 --> normal action (delete)
:RETURN 1 --> account not deleted

'''f_onchar_create'''

'''f_onchar_delete'''

'''f_onserver_start'''

'''f_onserver_save'''

'''f_onserver_save_ok'''

'''f_onserver_save_fail'''

'''f_onserver_save_finished'''

'''f_onserver_exit'''

'''f_onserver_blockip'''

[[Chapter 3]]

[[Category:Tutorials]]

Chapter 2

2011-03-12T06:59:41Z

Sirius: /* sphere_serv_triggers.scp */

De:Chapter 1

2011-03-10T06:59:34Z

Sirius: /* Beispiele */

{{Languages|Chapter_1}}

==Zahlen==

Als erstes wird die verschiedenartige Art und Weise zur Verwendung von Zahlen innerhalb der Sphere Skripte behandelt. Da Zahlen naturgemäß sehr wichtig für einen Sphereskripter sind, ist dies der erste Abschnitt überhaupt. Am Ende dieser Einheit wird hoffentlich jeder über ein allgemeines Verständnis über hexadezimale, dezimale und binäre Zahlensysteme und die Verwendung in Sphere Skripten besitzen. Zudem wird noch vermittelt, wie einerseits Zufallszahlen innerhalb eines Zahlenbereichs oder aus einer Liste von Zahlen generiert werden können.

Es muss zunächst verstanden werden: wie wir zählen ist nicht die einzige Art zu zählen. Unser Zahlensystem enthält zehn Ziffern (0, 1, 2, 3, 4, 5, 6, 7, 8, und 9). Ab der zehnten Zahl wird eine weitere Ziffer angehängt und die letzte Stelle auf 0 gesetzt (1, 2, 3, 4, 5, 6, 7, 8, 9, 10). Deshalb funktioniert unser Zahlensystem wie es funktioniert.

Im Dezimalsystem, ohne dass wir davon Notiz nehmen, schreiben wir diese Zahlen immer als Zehnerpotenzen. Beispielsweise die beliebige Zahl 17282 aufgeteilt in Zehnerpotenzen:

{| border="1"
| Zehnerpotenz || 4 || 3 || 2 || 1 || 0
|-
| 10 hoch Zehnerpotenz || 10000 || 1000 || 100 || 10 || 1
|-
| Ziffer || 1 || 7 || 2 || 8 || 2
|}

Um zur Zahl 17282 zu gelangen, wird immer 10 hoch Zehnerpotenz mal der Ziffer in der untersten Zeile berechnet und am Ende alle Ergebnisse addiert. Das Ergebnis: 10000 + 7000 + 200 + 80 + 2. Offensichtlich ist das sehr einfach und jeder tut das ständig ohne davon Notiz zu nehmen. Du fragst dich sicherlich jetzt "Richtig, warum schrieb Taran das alles?" Die Sache ist die, dass unser Zahlensystem nicht das einzige ist.

Computer zählen beispielsweise komplett anders. Sie kennen nur zwei Ziffern (1 und 0) und das wird dann Binärsystem genannt. Binäre Zahlen sehen beispielsweise so aus: 101011101101. Oftmals tauchen sie in der Werbung für Computer auf. Ziffern im Binärsystem werden Bit genannt (kurz für BInary digiT). Binärzahlen im Kopf zu Dezimalzahlen zu berechnen ist meist nicht ohne weiteres möglich, hierfür braucht es ein wenig Mathematik.

Binärsysteme funktionieren wie Dezimalsysteme, es wird eine Potenz einer Zahl addiert. Da Binarzählen nur aus zwei Ziffern bestehen, handelt es sich hierbei um Zweierpotenzen. Manchen wird die folgende Tabelle sicher bekannt vorkommen:

{| border="1"
| Zweierpotenz || Binärzahl || Dezimalzahl
|-
| 0 || 1 || 1
|-
| 1 || 10 || 2
|-
| 2 || 100 || 4
|-
| 3 || 1000 || 8
|-
| 4 || 10000 || 16
|-
| 5 || 100000 || 32
|-
| 6 || 1000000 || 64
|-
| 7 || 10000000 || 128
|-
| 8 || 100000000 || 256
|-
| 9 || 1000000000 || 512
|-
| 10 || 10000000000 || 1024
|}

Spannend oder? :)

Wir brauchen ein besseres System! Der Grund, dass seltsame Ergebnisse auftreten, liegt daran, dasss 10 keine Potenz von 2 ist. Wir brauchen deshalb ein System, das eine Zweierpotenz als Basis hat. Das am meisten genutzte System ist ein 16er System, auch hexadezimal genannt. Im Sphere-Forum sieht man das Wort hex sicherlich an der ein oder andren Stelle, das ist kein Fluch und auch kein böser Zauber. Es ist eine Kurzform für "hexadecimal".

{| border="1"
| Binär || Dezimal || Hexadezimal
|-
| 1 || 1 || 1
|-
| 10 || 2 || 2
|-
| 11 || 3 || 3
|-
| 100 || 4 || 4
|-
| 101 || 5 || 5
|-
| 110 || 6 || 6
|-
| 111 || 7 || 7
|-
| 1000 || 8 || 8
|-
| 1001 || 9 || 9
|-
| 1010 || 10 || A
|-
| 1011 || 11 || B
|-
| 1100 || 12 || C
|-
| 1101 || 13 || D
|-
| 1110 || 14 || E
|-
| 1111 || 15 || F
|-
| 10000 || 16 || 10
|}

Ersichtlich, wie das funktioniert? Es gibt sechs Ziffern, die zusätzlich am Ende des Systems herangezogen werden müssen, es werden üblicherweise hierfür die ersten 6 Buchstaben des Alphabets verwendet.

Innerhalb von Sphere Skripten wird beinahe NIE mit Binärzahlen gearbeitet, die KEINE Potenz von zwei sind und wenn, dann kann jeder herkömmliche Taschenrechner benutzt werden, um sie umzurechnen. Mit Hexadezimalzahlen ist das um einiges einfacher.

(This is the last table, I promise!!)
{| border="1"
| Binär || Hexadezimal
|-
| 000000001 (1) || 01
|-
| 000000010 (2) || 02
|-
| 000000100 (3) || 04
|-
| 000001000 (4) || 08
|-
| 000010000 (5) || 010
|-
| 000100000 (6) || 020
|-
| 001000000 (7) || 040
|-
| 010000000 (8) || 080
|-
| 100000000 (9) || 0100
|}

Wie in der Tabelle ersichtlich gibt es ein Muster in der Hexadezimalspalte. Man könnte meinen, dass da ein Muster in den Zahlen 1, 2, 4 und 8 auftritt. Das stimmt auch. Ein weiteres Detail sind die führenden 0en für Hexadezimalzahlen (0100 statt nur 100). In Sphere bedeutet eine solche führende 0: "Diese Zahl ist eine Hexadezimalzahl!" und dementsprechend sind 100 und 0100 völlig verschiedene Zahlen.

Angenommen in einem Sphere Skript wird das 13. bit in einer Zahl benötigt (FLAGS beispielsweise), dann würde so etwas verwendet werden:

'''SRC.FLAGS |= 8192'''

Allerdings: merkt man sich wirklich, dass 8192 das Ergebnis von 2 hoch 13 ist? Das tut man nicht, es ist viel einfacher diese Liste durch zu gehen, bis man zur 13. Zahl kommt (wichtig: Zählen beginnt immer bei 0!).

{| border="1"
| 01 || 02 || 04 || 08 || 010 || 020 || 040 || 080 || 0100 || 0200 || 0400 || 0800 || 01000 || 02000
|-
| 2^0 || 2^1 || 2^2 || 2^3 || 2^4 || 2^5 || 2^6 || 2^7 || 2^8 || 2^9 || 2^10 || 2^11 || 2^12 || 2^13
|}

Und hier sind sie: die ersten 14 Zweierpotenzen in Hexadezimal.

'''SRC.FLAGS |= 02000'''

Diese Zeile ist identisch zur obigen, nur dass 8192 (dezimal) GLEICH 02000 (hexadezimal) ist.

'''8192 = 02000'''

Nun könnte man sagen "Wie weiß ich, dass das nicht frei erfunden ist?". Nunja, schon der windowseigene Microsofttaschenrechner beherrscht die Umrechnung zwischen Binär-, Hexadezimal-, Dezimal und Oktalzahlen (ein weiteres, aber in Sphere nutzloses Zahlensystem). Der Taschenrechner von Windows befindet sich im Startmenü unter Programme im Zubehör. Im Taschenrechner wird im Menü Ansicht auf Wissenschaftlich umgestellt. Die Oberfläche des Taschenrechners verändert sich dann ziemlich. Um damit eine Zahl zwischen den Systemen umzurechnen, muss nur die originale Zahl eingegeben werden und dann kann zwischen den verschiedenen Zahlensystemen (Hex, Dez, Okt, Bin) umgeschaltet werden. Eine 0 vorne an eine Hexadezimalzahl gehängt und Sphere interpretiert sie als auch als eine hexadezimale Zahl.

Das war vermutlich das schwierigste in allen Sphere Skripten. Glücklicherweise, wegen des nächsten Abschnitts, muss sich ab jetzt niemand mehr mit angsteinflössenden Zahlen beschäftigen. Wenn du nach dieser Einheit noch dabei bist, wird sicher alles gut!

Weiter gehts mit: Skripten für Sphere!

==Defnames==

Hier eine Liste angsteinflössender Zahlen, die man innerhalb von Sphere Skripten antrifft:

{| border="1"
| angsteinflössende Zahl || Was sie bedeutet
|-
| 0eed || ID einer Goldmünze
|-
| 0dda || ID eines roten Moongates
|-
| 1650,1440 || Koordinaten von Britain
|-
| 021 || Farbcode für die Farbe "rot"
|-
| 04000 || Farbcode für unsichtbar
|-
| 04000efad || Eindeutige serielle Nummer eines Gegestands
|-
| 4 || Das PLEVEL eines GMs
|-
| 2048 (oder 0800) || Flag für den Unsichtbarkeitszauber
|-
| 010 (oder 16) || Memory type für Aggressoren
|}

Offensichtlich will solche Zahlen niemand auswendig kennen. Aber in frühesten Versionen, weit vor Sphere und TUS (vor .50 Sphere) und tief im Nebel von Grayworld (vor .41 TUS), musste jeder Skripter diese Zahlen kennen. Ich kenne diese Zahlen (ausser die serielle Nummer, die frei erfunden ist) und noch ein paar weitere, allesamt in- und auswändig. Glücklicherweise hat sich für jeden, der nicht gern Zahlen auswendig lernen will, Sphere dazu entwickelt, dass Namen statt Zahlen verwendet werden können.

Zwar wird alles mögliche immer noch mit Zahlen verknüpft, aber diese Zahlen sind mittlerweile mit Namen verknpft worden.

Gib im Spiel .add 0eed ein und drücke die Returntaste. Ein Zielcursor taucht auf und es kann eine Goldmünze erschaffen werden.

Nun gib .add i_gold ein und drücke Return. Es passiert genau das selbe.

Natürlich kann man sich i_gold leichter als 0eed merken. Aber wie funktioniert das? Dazu muss die Skriptdefinition von einer Goldmünze angesehen werden. Dieses Skript muss an dieser Stelle noch nicht verstanden werden, Itemskripte werden später genauer behandelt. Dieser Skriptausschnitt findet sich in der Datei sphere_item_resources.scp.

<tt>[ITEMDEF 0eed] 
//gold coin 
DEFNAME=i_gold 
TYPE=T_GOLD 
VALUE=1 
CATEGORY=Provisions - Miscellaneous 
SUBSECTION=Coins 
DESCRIPTION=Gold Coin 
DUPELIST=0eee,0eef </tt>

Die rot markierte Zeile ist für diese Lektion von Belang. Ansonsten ist noch die erste Zeile, die 0eed enthält, interessant, aber der Rest kann getrost ignoriert werden vorerst. Die 0eed ist die Nummer des Items, diese Nummern werden im nächsten Abschnitt behandelt.

Wirklich interessant ist allerdings DEFNAME=i_gold. Diese Zeile legt im Server fest: "Ab jetzt wird 0eed mit i_gold identifiziert". Wird vor dieser Zeile irgendwo innerhalb eines Skripts i_gold verwendet, wird der Server einen Fehler melden (siehe [[Chapter 2|Kapitel 2]] über die Reihenfolge von Skripten), aber jetzt ist ihm bekannt, worauf i_gold verweist und es kann in Skripten oder im Spiel frei verwendet werden.

Es sollte IMMER ein solcher Name mit DEFNAME erstellt werden, wenn ein Item geskriptet wird. Normalerweise wird dieser defname in [ITEMDEF] selbst festgelegt (mehr darüber später), aber wenn unbedingt Zahlen verwendet werden sollen, sollte zudem noch ein einfach zu zu merkender Name verwendet werden (bspw nicht goldenes_gulasch für ein Schwert). Es macht das Leben einfacher, als Zahlen zu benutzen.

Eine zweite Möglichkeit, DEFNAME zu nutzen, ist die Nutzung eines [DEFNAME]-Abschnitts. Hier ein Beispiel dafür:

<tt>[DEFNAME colors] 
color_blue 02 
color_red 021 
color_green 041 </tt>

Ein ähnliches Skript steht in spheredefs.scp, eine weitere Datei, die ganz am Anfang geladen werden sollte.

Hier eine Aufschlüsselung dieses Skripts, Zeile für Zeile:

'''Zeile 1''': Hier wird der Typ des Skripts festgelegt und der Name dafür (Colors in diesem Fall). Hier wird dem Server vermittelt, dass von dieser Zeile bis zum nächsten Identifier (das sind die Zeilen die von eckigen Klammern eingerahmt sind) eine bestimmte Art von Skript enthalten ist. Alle Identifier haben dieses Format. Der erste Parameter legt dabei den Skripttyp fest und davon gibt es mehrere, die in den weiteren Kapiteln abgehandelt werden. Der zweite Parameter ist entweder eine Zahl als ID oder ein Defname. In den meisten Fällen wird in selbst geschriebenen Skripten wird hier ein Defname stehen. Die einzige Ausnahme besteht dann, wenn neue Items in die Clientdateien eingefügt werden.

'''Zeilen 2-4''': Diese Zeilen enthalten individuelle Teile. Es wird festgelegt, dass color_blue gleich 02, color_red gleich 021 und color_green gleich 041 ist. Zwischen dem Namen und dem Wert können beliebig viele Leerzeichen enthalten sein. Die Definitionen in spheredefs.scp sind so ziemlich die nützlichsten auf die man treffen kann, da sie es unnötig machen, viele angsteinflössende Zahlen zu verwenden. In spheredefs.scp werden deshalb Namen für Flags, für Attribute von Items, für verschiedene Töne und Klänge, für Memory Types und viele andere Dinge festgelegt. Einen Blick in diese Datei zu werfen ist sicherlich zuweilen ganz ratsam.

Das wars mit DEFNAMES. Weiteres taucht später in allen möglichen Skripten auf.

Jetzt werden Items abgehandelt.

==ITEMDEF==
Oder: wie macht man aus einem Maulwurfshügel einen Berg auf Sphere-Art.

Die meisten machen sich Itemskripte schwieriger, als es nötig ist. Für die Zwecke dieses Tutorials, da es noch ein weit fortgeschritteneres später gibt, werden hier nur einfach die Grundlagen eines ITEM Skripts behandelt, Zeile für Zeile. Wir werden das Goldskript vom vorherigen Absatz verwenden, vorausgesetzt ich finde es ...

Ok, hier ist es, mit Farbe unterlegt, damit es schöner anzusehen ist!

<spherescript>[ITEMDEF 0eed]
//gold coin
DEFNAME=i_gold
TYPE=T_GOLD
VALUE=1
CATEGORY=Provisions - Miscellaneous
SUBSECTION=Coins
DESCRIPTION=Gold Coin
DUPELIST=0eee,0eef</spherescript>

Das ist das einfachste aller Itemskripts, da es kein weiteres Verhalten hat und nichts anderes macht ausser einfach nur zu existieren. Es wird nun jede Zeile erklärt und was es damit auf sich hat:

'''Zeile 1''': [ITEMDEF 0eed]

Die erste Zeile eines Itemskripts ist die wichtigste. Grundsätzlich bedeutet diese Zeile für den Server "Hey, das ist ein Item und es soll 0eed heißen!". Der Server sieht sich dann die Clientdateien an (vor allem art.idx), und gleicht ab, ob das Item eins der eingebauten ist. Ich glaube, alle Items mit Nummern unter 04500 gelten als eingebaut, deshalb sollte nie ein neues Item mit einer Zahl definiert werden, die darunter liegt. Bei Eingabe dieser Zeile, wird der Server wissen, dass ein Itemskript folgt. Außerdem wird 0eed als gültiges Item festgelegt, was später nützlich ist, wenn die Spieler Gold brauchen!

'''Zeile 2''': // gold coin

Das ist die Sphereversion eines Kommentars. C-Programmierer kennen das Format (Anmerkung des Übersetzers: eigentlich kennt man das erst ab C++). Jede Zeile, die mit // beginnt ist eine Kommentarzeile und alles, was in einer Kommentarzeile enthalten ist, wird nicht vom Server interpretiert oder gelesen. Diese Kommentare können aber auch an beliebiger Stelle innerhalb einer Zeile beginnen um am Ende einer Zeile eine Erklärung einzufügen. Auf jeden Fall sind Kommentare nicht für die Funktion des Skriptes relevant, sondern können sie unter Umständen verständlicher machen.

'''Zeile 3''': DEFNAME=i_gold

Du solltest jetzt wissen, was diese Zeile bedeutet. Wenn nicht, dann sollte die vorherige Einheit nochmal wiederholt werden. Es legt im Server fest, dass i_gold und 0eed das selbe sind. In Itemskripten sind alle alle Parameter nach diesem Format spezifiziert:

variable=wert

Später, wenn es um Skripte geht, wird ersichtlicher, dass dieses Format sehr hilfreich ist. Items haben einige Variablen, die belegt werden können, unter anderem:

* DEFNAME
* ID
* TYPE
* VALUE
* RESOURCES
Andere Variablen sind wiederum vom Wert von TYPE abhängig.

'''Zeile 4''': TYPE=t_gold

"Was ist t_gold?" Auch das ist nur ein DEFNAME. Also eine Zahl, in diesem Fall 72. In spheredefs.scp steht diese Zahl, also hätte TYPE=72 den selben Effekt.

Momentan gibt es 183 eingebaute Itemtypen. Sie sind hardcoded (=fest in Sphere implementiert) und enthalten vordefinierte Verwendungszwecke für einen Gegenstand. Hat ein Gegenstand keinen Typ, dann erhält man eine "You cannot think of a way to use that item"-Nachricht, wenn man im Spiel das Item anklickt. Es gibt eine vollständige Liste von Itemtypen und wie sie genutzt werden. Der Typ t_gold hat nur einen Effekt: der Gegenstand wird behandelt wie eine Goldmünze (d.h: es können damit Dinge gekauft werden!). Andere Gegenstände den Typ t_gold zu geben würde den Server dazu veranlassen auch diese Dinge als Währung heran zu ziehen. Ich habe das nie versucht, aber es könnte eine interessanter Weg sein einzigartige Währungen zu haben ...

'''Zeile 5''': VALUE=1

Diese Zeile legt fest, wie viel ein Item wert ist, wenn es gekauft wird - in Gold. Natürlich ist eine Goldmünze eine Goldmünze wert, deshalb wird der Wert hier auf 1 gesetzt.

'''Zeilen 6-8''': CATEGORY, SUBSECTION, DESCRIPTION

Diese Zeilen werden nur von Spheres GM-Tool, Axis, benutzt, das es unnötig macht, im Spiel ".add i_gold" einzugeben. Wichtiger noch, es übernimmt solche Aufgaben auch für Items, die keinen DEFNAME haben, sondern nur eine Nummer.

'''Zeile 9''': DUPEITEM

Es wäre viel Arbeit für das Sphereteam alle 8000 Items im Spiel zu definieren, vor allem, wenn viele eigentlich ein und das selbe sind. (Beispielsweise kann eine Tür mit dem Befehl .xflip gedreht werden. Dieser Befehl läuft durch alle DUPEITEMS, die für ein Item angegeben sind.) Die Liste von Nummern sind Itemnummern, die vielleicht noch nicht definiert wurden. Hier wäre das Skript für 0eee:

<spherescript>[ITEMDEF 0eee]
//gold coins
DUPEITEM=0eed
CATEGORY=Provisions - Miscellaneous
SUBSECTION=Coins
DESCRIPTION=Gold Coins</spherescript>

In diesem Skript gibt es nur einen Parameter für das Item. Es verweist den Server auf das DUPEITEM, das unter 0eed (oder i_gold) angelegt wurde, um die Informationen von dort, wie TYPE und VALUE zu verwenden. DUPEITEM spart Tipparbeit, wahrscheinlich wird es selten benutzt.

==CHARDEF==
Oder was es braucht, einen nackten Mann zu machen, der rumstehen und "Huh?" sagen kann.

NPCs machen die Welt lebendig. Sie sind das, was UO zu einem einzigartigen Multiplayer Spiel macht. Die Monster und NPCs die du skriptest machen den Server einzigartig im Vergleich zu jedem anderen. Dieser Abschnitt des ersten Kapitels wird beinhalten, wie ein einfacher nackter Mann geskriptet wird, der herumwandern und ein wenig mehr als "Huh?" (oder "Halt Dieb!", wenn man so will) sagen kann.

Als erstens sehen wir uns das SKript eines einfachen nackten Mannes an. Es befindet sich in spherechar_human.scp.

<spherescript>[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</spherescript>

Wie ersichtlich sieht es sehr viel anders aus als die Skripte der vorherigen Abschnitte. Es werden eine ganze Menge an Variablen gesetzt, die gleich sind wie der DEFNAME, DESCRIPTION und die anderen Axis Variablen.

Aber es gibt auch eine Menge neuer Dinge hier, die der Reihe nach und Zeile für Zeile betrachtet werden! Und es ist länger diesmal! Let the good times roll! (Entschuldigung an alle Nichtamerikaner, alle amerikanischen Cliches sind vermutlich irritierend!)

'''Zeile 1''': [CHARDEF 0190]

Überraschung! Ein Identifier, der dem Server mitteilt, dass hier ein Charakter bis zum zum nächsten Identifier definiert wird. Und zudem wird für diesen Charakter bzw. NPC die ID 0190 gesetzt. Der Server kennt diese ID, da es eine eingebaute ist. In der Tat gehört diese ID zum nackten Mann. Des weiteren steht 0190 als hexadezimale Zahl natürlich für 400, nicht wahr? :) Warum weißt du das nicht? OK, nur ein Witz, das muss man natürlich nicht wissen.

'''Zeile 2''': DEFNAME=c_man

Nichts neues. c_man entspricht hiermit 0190. Die meisten DEFNAMES für Charaktere beginnen mit c und dann folgt ein _ wie oben.

'''Zeile 3''': Name=Man

Hier ist etwas neues. Items haben einen vorgegebenen Namen, der im Server bekannt ist. Charaktere nicht. Deshalb muss ein Name zugewiesen werden. Es kann im Grunde jeder Name zugewiesen werden, den man hier haben möchte, aber da das kein spezifischer Mann ist, heißt er einfach nur Man.

'''Zeile 4''': ICON=i_pet_man

Ich brauchte eine Weile, um das herauszufinden. ICON legt ein kleines Bildchen fest, das man bei benutzung des Tracking Skills sieht und diese kleinen ICONs tauchen im Menü dort auf. Eigentlich sind diese Bildchen Items. Um herauszufinden, wie dieses Bildchen aussieht, kann der Mann einfach im Spiel mit .addnpc c_man erstellt werden und dann der .shrink Befehl auf ihn angewendet werden. Die ID dieses Items wird dann zum i_pet Item.

'''Zeile 5''': CAN=mt_*

(Falls * nicht bekannt ist: * heisst "alles mögliche" für diejenigen, die Linux nutzen.)

Das ist eine der wichtigsten Zeilen im Character Skript, neben der ID die in der ersten Zeile vergeben wird. Sie lässt uns festlegen, was ein NPC tun kann und was nicht. Es gibt nur ein paar wenige Möglichkeiten für mt_*, die alle in der spheredefs.scp definiert sind. Für unsere Zwecke sind sie hier hin kopiert worden.

<spherescript>MT_NONMOVER 0 // Kann ueberhaupt nicht laufen
MT_GHOST 01 // Kann wie ein Geist durch Tueren und aehnliches laufen
MT_SWIM 02 // Ich kann schwimmen! (Wasser Elementare, Delphine, etc)
MT_WALK 04 // Ich kann laufen! Setze dies wenn deine Kreatur laufen koennen soll.
MT_FLY 010 // Laeuft durch Baeume (soll das darueber Fliegen darstellen)
MT_FIRE_IMMUNE 020 // Ist gegen Feuer Immun. Das sollte man nicht auf einen Spieler setzen. :)
MT_EQUIP 00100 // Kann Sachen anlegen (equip).
MT_USEHANDS 00200 // Kann seine Haende benutzen um Sachen zu tragen (oder Tueren zu oeffnen)
MT_MALE 0 // Ist maennlich
MT_FEMALE 00800 // Ist weiblich
MT_NONHUM 01000 // Kein Mensch. Ich bin mir nicht sicher was es genau bewirkt.
MT_RUN 02000 // Kann wirklich schnell laufen!</spherescript>

Nach dieser Tabelle wird klar, dass ein NPC ohne CAN Flags ein MT_Male und MT_NONMOVER (zweimal 0) ist. Die Flags können durch ein | (Alt Gr + <) getrennt in einer Liste angegeben werden, so dass ein NPC mehrere solcher Flags erhalten kann. In diesem Fall erlauben wir unserem Mann, dass er etwas ausrüsten (oder anziehen), gehen, rennen und seine Hände benutzen kann. (Interessant ist, dass sogar Kreaturen ohne Hände ihre Hände nutzen können und damit bspw. Lichtquellen tragen können. Feuerelementare tun das beispielsweise, deshalb leuchten sie.)

'''Zeile 6''': RESOURCES

Die Resources sind etwas morbide als Bezeichnung. Vor allem für Personen, denn sie enthalten die Items, die herauskommen, wenn man im Spiel eine Leiche aufschneidet. Gruslig, hm?

'''Zeile 7-10''': FOODTYPE, DESIRES, AVERSIONS

'''FOODTYPE''': Legt fest, welche Art von Essen der NPC essen würde und wenn NPC_AI_FOOD aktiviert ist, sucht der NPC nach so einem Essen wenn er hungrig wird.

'''DESIRES''': Legt fest, welche Art von Items ihn interessieren und wenn NPC_AI_EXTRA aktiviert ist, dann wird ein NPC aus Spielerleichen diese Gegenstände holen oder, falls diese Gegenstände am Boden liegen, zu ihnen hingehen.

'''AVERSIONS''': Das ist nicht ganz klar. Ich nehme an, dass diese Option angibt, was der NPC am liebsten angreift. Beispielsweise: Ich habe ein Pferd mit dem Event e_horse und einen Imp mit AVERSIONS=e_horse, dann würde im Falle eines Kampfs der IMP wohl vorziehen gegen das Pferd zu kämpfen.

'''Zeile 11''': BLOODCOLOR

Jemals vorgehabt den Spielern grünes Blut zu verpassen? Das geht hiermit. Eine Nummer für eine Farbe oder ein DEFNAME funktioniert hier. (Für Farben sollte man versuchen die Zahlen zu lernen, das macht es einfacher.)

Der Rest: TSPEECH and TEVENTS

Diese beiden Zeilen erhalten eigene Kapitel. Sie sind sehr komplex und mitunter die komplexesten Dinge beim Skripten! (Wie oft ich das wohl sagen werde, bis das wirklich wahr ist?)

''Einige andere Dinge:''

Auf 56B gibt es weitere Variablen wie MOVERATE, RESLEVEL, RESDISPDNID and RESDISPDNHUE. Sie klingen schwierig und seltsam, aber das sind sie nicht. Hier ist eine Erklärung:

'''MOVERATE''': Diese Einstellung (die nur innerhalb eines CHARDEF Blocks sein kann) legt fest, wie schnell sich ein NPC bewegt. Je kleiner der Wert, desto schneller ist ein NPC. Beispielsweise für ein Pferd mit vorgegebener MOVERATE von 100, wäre ein anderer NPC mit MOVERATE von 60 schneller als das Pferd. Das ist ganz gut, um schwierige Monster zu skripten, die nur schwer zu erlegen sind.

'''RESLEVEL''': Das sagt Sphere aus welcher Version von UO das Monster abstammt, Beispielsweise hat ein "Wanderer of the Void" RESLEVEL=3 (3 ist AOS) (siehe spheredefs.scp für eine Liste), so dass nur Accounts mit RESDISP 3 oder größer das Monster so sehen, wie es wirklich aussieht.

''NOTE'': Setzt man einen zu niedrigen Wert für RESLEVEL und der Spieler hat die passende Animation nicht, führt das zum Absturz seines Clients.

'''RESDISPDNID''': Wie wahrscheinlich bemerkt, sagte ich oft nun "wie er wirklich" ist, genau wegen dieser Einstellung. Das legt fest, wie ein Monster für einen Spieler aussieht, hat er die Animation nicht. Beispielsweise wird der Wanderer of the Void für jeden mit ACCOUNT.RESDISP=3 oder großer auch wie ein Wanderer of the Void aussehen, aber für alle anderen sieht er wie ein c_spectre aus (wenn es so eingestellt wurde).

'''RESDISPDNHUE''': Das legt fest, welche Farbe für den Spieler das Monster hat, wenn die RESDISPDNID angezeigt wird (und sein account.resdisp kleiner als reslevel dieses Charakters ist).

Hier ist ein Beispiel für diese neuen Einstellungen:

<spherescript>[CHARDEF 310]
DEFNAME=c_Wailing_Banshee
NAME=Wailing Banshee
SOUND=snd_monster_zombie1
ICON=i_pet_wailingbanshee
DAM=11,16
RESDISPDNID=c_spectre
RESLEVEL=3
RESDISPDNHUE=01
ARMOR=20
CAN=MT_WALK|MT_FLY
DESIRES=i_gold,e_notoriety,e_horses,c_man,c_woman,t_corpse
CATEGORY=New Monsters
SUBSECTION=AOS
DESCRIPTION=Wailing Banshee

ON=@Create
NPC = brain_monster
FAME = {100 3000}
KARMA = {-5000 -6999}
STR = {126 166}
INT = {86 115}
DEX = {41 75}
MAGICRESISTANCE = {75.0 95.0}
TACTICS = {45.0 75.0}
WRESTLING = {50.0 70.0}

ON=@NpcRestock
ITEM = i_gold, {50 100}
ITEM = i_reag_daemon_bone, {2 6}</spherescript>

Und das wars. Einfache Charakterskripte und ein paar neue Dinge. Es gibt dazu noch ein spezielles Kapitel nur über das Skripten von NPCs später.

==TEMPLATE==
Oder wie man eine große Menge serverbelastender Items in einen nichtserverbelastenden Container packt.

Jeder hat sie schon gesehen. Die Shards, die keine TEMPLATEs benutzen. Wird beispielsweise ein Drache auf diesen Shards erlegt und lootet man ihn dann, dann findet man statt schön abgepackte Behälter ein paar 100 Tränke im Lootfenster verteilt. Nicht nur das, alle magischen Gegenstände sind auch noch darunter vergraben!

Wie wird das Problem gelöst? Sphere hat ein sehr handhabbares Werkzeug: die TEMPLATES. Sie erlauben, dass Container Items definiert werden und die Items in diesen Containern ebenfalls und zwar gleichzeitig. Das ist doch toll? I dachte es mir, als ich heraus fand, was sie sind. Deshalb wieder eine Zeile für Zeile Aufschlüsselung, diesmal mit einem TEMPLATE aus spheretemp_loot.scp.

<tt>[TEMPLATE 101505] 
DEFNAME=backpack_poor 
CATEGORY=Item Templates 
SUBSECTION=Loot Templates 
DESCRIPTION=Poor Backpack 
CONTAINER=i_backpack 
ITEM={ random_food 1 0 3 },{ 1 3 } 
ITEM={ random_bottle 1 0 8 } 
ITEM={ random_light 1 0 8 } 
ITEM={ random_male_tops 1 0 4 } 
COLOR=colors_all 
ITEM={ random_male_pants 1 0 4 } 
COLOR=colors_all 
ITEM=POOR_GOLD_PILE </tt>

Sieht verwirrend aus. Aber kein Problem, das wird schon alles klar werden, was das bedeutet!

[TEMPLATE 101505]: Als erstes wird die Kopfzeile des templates betrachtet. Interessant an Templates ist, dass der Itemname kein DEFNAME sein kann, sondern eine sehr hohe Zahl sein muss.

DEFNAME=backpack_poor: Natürlich sind die Sphere Entwickler nicht bösartig und haben deshalb hier noch die Möglichkeit eines DEFNAMEs eingeführt.

CATEGORY, SUBSECTION, DESCRIPTION: Der übliche Axiskram. Optional natürlich. In den vorherigen Abschnitten wird das genauer erklärt.

CONTAINER=i_backpack: Ok, nun gehts runter bis aufs Eingemachte. Das ist der Container, der benutzt wird und alle anderen Items landen in diesem. Wenn der Container im Spiel erstellt wird, dann sieht man ihn. In diesem Fall ist das ein Rucksack. Ganz einfach. Hier kann nur ein gültiger Container vom Typ t_container oder t_container_locked angegeben werden.

ITEM={ random_food 1 0 3},{1 3} Das sieht ziemlich kryptisch aus. Deshalb wird diese Zeile ein wenig eingehender beleuchtet.

Als erstes muss ZUFALLSAUSWAHL behandelt werden! Klingt nach Spaß, nicht? Nun ja, klingt auch für mich nicht danach, aber es ist unbedingt notwendig, um einen guten Shard zu bauen.

Sie sind einfache grundlegende Mechanismen, um mit einem Befehl eine zufällige Zahl zu erhalten. Was wäre das schon für ein Shard, auf dem jeder getötete Drache auch eine Platemail of Magic Stuff und ein Super Duper Sword of Power liefern würde? Jeder würde damit herumlaufen, deshalb braucht es etwas Variabilität.

Es gibt zwei Arten von Zufallsauswahlen: gewichtete und bereichsweise Auswahl. Gewichtete Auswahlen funktionieren so: "OK, 1 mal von 10 nimm Nummer A, 3 mal von 10 nimm Nummer B und 6 mal von 10 nimm Nummer C". Bereichsweise Auswahlen funktionieren so: "Wähle eine zufällige Zahl zwischen zwei Zahlen, die ich festlege".

Unser Beispiel nutzt beides - sowohl bereichsweisen als auch gewichteten Zufall. Der Reihe nach:

{ random_food 1 0 3}

Das ist eine gewichtete Auswahl. Um das richtig zu verstehen, wird der Ausdruck zwischen den Klammern in zwei Teile zerlegt:

random_food 1 
0 3

Addiert man die zweite Zahl in den beiden Zeilen, erhält man 4. Das sagt Sphere "OK, 1 von 4 Mal, will ich random_food und 3 von 4 Mal wähle ich 0." Man kann auch Zufallsauswahlen verschachteln, aber das wird dann verwirrend.

{ { random_food 1 0 3} 1 random_clothing 1}

Klar, was das heisst?

random_clothing 1
{ random_food 1 0 3} 1

2 ist hier die magische Zahl. Einmal von 2 nimmt Sphere random_clothing und einmal von 2 nimmt Sphere den vorherigen Auswähler, der dann aus seinen eigenen Optionen eins auswählt. Wenn du jetzt schon verwirrt bist, keine Sorge. Das ist sehr selten, aber es wird sich zeigen, wie TEMPLATES diese Probleme lösen können.

Ich habe erwähnt, dass es noch einen weiteren Zufallswähler gibt. Und dieser ist hier:

{1 3}

Anmerkung: Leerzeichen sind hier wichtig. Hier dürfen keine Leerzeichen zwischen { und der ersten Zahl oder } und der letzten Zahl sein. Ansonsten kommt seltsames Verhalten dabei heraus.

Das weist Sphere an "Nimm eine beliebige Zahl zwischen 1 und 3, inklusive". Inklusive heißt, dass Sphere auch 1 und 3 wählen kann oder eben jede Zahl dazwischen. In diesem Fall ist der Bereich sehr beschränkt. Sphere wird eine 1, 2 oder eine 3 liefern. Bereichsweise Auswähler werden oftmals in gewichteten Auswählern benutzt.

{ {1 3} 3 {4 9} 1}

"Einmal aus 4, nimm eine Zahl zwischen 4 und 9. Dreimal von 4, nimm eine Zahl zwischen 1 und 3."

Nachdem wir das nun hinter uns haben, sehen wir uns die Zeile des Skripts von oben an. Der Teil mit ITEM= 
Das legt im Skript fest "Ok, wir werden jetzt ein Item zum Container hinzufügen". Alles nach dem = legt fest, was genau das ist und in welcher Menge. Es kann natürlich geskriptete werden ITEM=i_platemail_chest oder sonst was ohne die mysteriösen { } Auswähler, aber der Grund, warum TEMPLATES so interessant sind, ist die große Variabilität, die sie bringen.

{ random_food 1 0 3}

Das ist das Item, das erstellt wird. Aus der Einheit über gewichtete Zufallsauswahlen, 1 von 4 Mal, wird das random_food sein und 3 von 4 Mal, wird das 0 sein. Wenn ein Item 0 ist, dann wird nichts erstellt. Das bedeutet: "Hier gibt es eine 1 zu 4 Chance, dass random_food im Container auftaucht." Was random_food ist? Das ist ein weiteres TEMPLATE, das in spheretemplate.scp definiert wurde ... glaube ich.

{1 3} Ist die Menge des Items, die erstellt wird. Das ist eine zufällige Bereichsauswhl. Sphere nimmt eine Zahl zwischen 1 und 3 und setzt dann die Menge im Container. Natürlich: ist das Item zuvor 0 geworden, dann wird auch die Menge daran nichts ändern, denn 3 mal 0 ist weiterhin 0.

Das war grundlegend das Template Skript. Hier können noch so viele Items eingefügt werden, wie man Lust hat. Ausserdem ist noch folgendes Konstrukt dann interessant:

ITEM=i_sword_long,R11

Das ist eine Kurzform von:

ITEM={ i_sword_long 1 0 10 }

R11 bedeutet: "1 zu 11 Chance, dass das Item gefunden wird". Und zusätzlich kann noch eine Mengenauswahl hinten angehängt werden, was es ziemlich seltsam aussehen lässt:

ITEM=i_sword_long,R11,{4 5}

Aber warum würde man 4 oder 5 Langschwerter haben wollen? Das wäre noch seltsamer. :)

Das wars von Templates. Gratulation, das erste Kapitel ist hiermit durch. Jetzt sollten die Beispiele im nächsten Abschnitt nicht schwierig zu verstehen sein. Du könntest auch einige fragen haben, die hier allerdings ohnehin nicht beantwortet werden. Einfach weiterlesen, es wird noch vieles in den folgenden Kapiteln abgehandelt.

''(Ein Template Beispiel von Belgar)''

<tt>[TEMPLATE tm_necromancer] 
CONTAINER=i_bag 
ITEM=random_necro_scroll 
ITEM=random_necro_scroll 
ITEM=random_necro_reagent, {5 12} 
ITEM=random_reagent, {5 12} 
ITEM=random_necro_reagent, {5 12} </tt>

==Beispiele==
Oder ... naja, glaub es gibt kein anderes Wort für "Beispiele".

Das soll mein Versuch sein, einfachste simpelste Items zu erstellen. Du wirst hier einige DInge in diesen Beispielen sehen, die in den Tutorials nicht behandelt wurden. Hauptsächlich gibts hier ein ON=@create das im 2. Kapitel abgehandelt wird. Für die Beispiele ist nur wichtig, dass die Farbe der Dinge im Spiel geändert werden kann und dass das unter on=@create passieren muss.

'''Beispiel 1''': Ein rotes Schwert

<tt>[ITEMDEF i_sword_red] 
ID=i_sword_viking 
TYPE=t_weapon_sword 
NAME=Das rote Schwert 
CATEGORY=Weapons 
SUBSECTION=New Swords 
DESCRIPTION=Red Sword 

ON=@Create
:COLOR=colors_red // Das ist ein Kommentar. Kommentare werden von Sphere ignoriert. </tt>

Moment ... was heisst das // an dieser Stelle? Das ist ein Kommentar, er wird gänzlich von Sphere ignoriert, deshalb kann hier alles stehen, solange es hinter den // steht. Es gibt in Sphere keine mehrzeiligen Kommentare, solange man nicht jede Zeile mit // beginnen lässt. Deshalb sollte man das gar nicht versuchen, sonst wird Sphere viele Fehler ausgeben und man darf sie suchen.

'''Beispiel 2''': Ein blauer Ettin

<tt>[CHARDEF c_ettin_blue] 
ID=02 // Hier kann auch c_ettin benutzt werden natürlich. 
NAME=Mein blauer Ettin 
 
 
ON=@Create 
:COLOR=02 // Das ist dunkelblau. Wird oft für Counselorroben benutzt. Merken. </tt>

'''Beispiel 3''': Ein Template aus einer der Dateien, weil ich zu faul bin eins selbst zu schreiben

<tt>[TEMPLATE 101521] 
DEFNAME=goodie_meager_1 
CATEGORY=Item Templates 
SUBSECTION=Loot Templates 
DESCRIPTION=Meager Goodie 1 
ITEM={ meager_gold_pile 1 backpack_meager 1 pouch_meager 1 } 
ITEM={ random_boots 1 0 4 } 
ITEM={ random_gorget 1 0 4 } 
ITEM={ random_staff 1 0 4 } 
ITEM={ random_necklace 1 0 4 } 
ITEM={ i_cape 1 0 9 } 
COLOR=colors_all </tt>

Bemerkenswert ist hier etwas neues (das speziell in rot hervorgehoben ist) und ja, das kann man so schreiben. Alle Zeilen zwischen ITEM= Zeilen betreffen das zuvor erstelle Item. COLOR= bezieht sich also auf die Zeile

ITEM={ i_cape 1 0 9 }

Der beste Weg diese Art von Skripten zu lernen, liegt darin, dass man die Skripte in den Dateien wie beispielsweise sphereitem_colorarm.scp und sphereitem_beers.scp liest.

[[De:Chapter 2|Kapitel 2]]

[[Category:Tutorials]]

De:Chapter 1

2011-03-10T06:58:56Z

Sirius: /* Beispiele */

De:Chapter 2

2011-03-10T06:57:49Z

Sirius: /* spheretables.scp */ Uebersetzung verbessert

De:Chapter 1

2011-03-09T16:07:47Z

Sirius:

De:Chapter 1

2011-03-09T16:05:43Z

Sirius:

Es:Chapter 1

2011-03-09T07:18:57Z

Sirius: /* TEMPLATE */

{{Idiomas|Chapter_1}}

==Números==

La primera cosa de la que te das cuenta cuando echas un vistazo a los scripts de SPHERE, es la amplia variedad de formas que hay para escribir los números. Dado que los números son realmente importantes para un programador de SPHERE, esta será la primera lección de todas. Una vez acabes la lección, espero que tengas un entendimiento general del sistema hexadecimal, decimal y binario, y la forma que tiene SPHERE de identificar cada uno. También sabrás cómo generar números aleatorios ya sea de una serie o de una lista de elecciónes.

La primera cosa que necesitas comprender es que la forma en la que contamos no es la unica forma de contar. Nuestro sistema de numeración contiene diez dígitos (0, 1, 2, 3, 4, 5, 6, 7, 8, y 9). Pero, al decimo número, tenemos que añadir una columna al número y reestablecer la primera columna a cero (1, 2, 3, 4, 5, 6, 7, 8, 9, 10). Esa es la razón por la que nuestros sistema de numeración funciona en la forma en la que lo hace.

En el sistema decimal, sin darnos cuenta, escribimos los numeros para que se entiendan como potencias de diez. Por ejemplo, si tomamos el número 17282 (que me acabo de inventar), y lo dividimos, obtenemos esto:

{| border="1"
| Potencia de diez || 4 || 3 || 2 || 1 || 0
|-
| Diez a esa potencia || 10000 || 1000 || 100 || 10 || 1
|-
| Dígito || 1 || 7 || 2 || 8 || 2
|}

Para conseguir el número 17282 a partir de esto, sólo tenemos que tomar la potencia de diez de la fila superior, multiplicarlo por el número de la fila inferior, y sumar todos los resultados. Así pues obtendremos 10000 + 7000 + 200 + 80 + 2. Evidentemente, esto es mucho más simple, y ni siquiera nos damos cuenta de que lo estamos haciendo. Probablemente estés pensando "Vaaaaale, ¿qué se piensa Taran que está consiguiendo con esto?" Pues bien, no somos tan especiales como para que nuestro sistema de cuentas sea el único con el que se cuenta.

Por ejemplo, hay otro sistema numérico que es utilizado caso exclusivamente por los ordenadores. Éste solo contiene dos dígitos (1 y 0) y es por ello por lo que es llamado 'Sistema binario' (que significa 'dos'). Los números binarios tienen un aspecto parecido a este: 101011101101, y los verás con frecuencia en anuncios de ordenadores y electrónica (Muchas veces se los muestra saliendo de un grabador de CDs en anuncios de televisión). A los dígitos del sistema binario se les llama BITs (Abreviatura del inglés 'BInary digiT' - Dígito Binario). Los números en binario son prácitamente imposibles de traducir directamente al decimal, así que hay que echar algunas cuentas.

El binario funciona de la misma manera que el decimal: sumando potencias de un número. En el caso del binario, dado que sólo hay dos dígitos en todo el sistema, ese número naturalmente es 'dos'. Aquí hay algunas potencias de dos. Algunas personas pueden encontrar estos números algo familiares.

{| border="1"
| Potencia de 2 || Número Binario || Número Decimal
|-
| 0 || 1 || 1
|-
| 1 || 10 || 2
|-
| 2 || 100 || 4
|-
| 3 || 1000 || 8
|-
| 4 || 10000 || 16
|-
| 5 || 100000 || 32
|-
| 6 || 1000000 || 64
|-
| 7 || 10000000 || 128
|-
| 8 || 100000000 || 256
|-
| 9 || 1000000000 || 512
|-
| 10 || 10000000000 || 1024
|}

Absurdo, ¿verdad? :)

¡Necesitamos un sistema mejor! La razon por la que obtenemos unos resultados tan extraños es que 10 no forma parte de las potencias de dos. Necesitamos encontrar un sistema cuya base SEA una potencia de dos. El sistema que con más frecuencia se usa es base-16, or hexadecimal. Estoy seguro de que si has seguido los foros de SPHERE, habrás visto la palabra hex danzando por ahí. No, no es una palabrota ni un hechizo malvado, es la forma rápida de decir "hexadecimal".

{| border="1"
| Binario || Decimal || Hexadecimal
|-
| 1 || 1 || 1
|-
| 10 || 2 || 2
|-
| 11 || 3 || 3
|-
| 100 || 4 || 4
|-
| 101 || 5 || 5
|-
| 110 || 6 || 6
|-
| 111 || 7 || 7
|-
| 1000 || 8 || 8
|-
| 1001 || 9 || 9
|-
| 1010 || 10 || A
|-
| 1011 || 11 || B
|-
| 1100 || 12 || C
|-
| 1101 || 13 || D
|-
| 1110 || 14 || E
|-
| 1111 || 15 || F
|-
| 10000 || 16 || 10
|}

¿Has visto como funciona? Hay seis dígitos adicionales añadidos al final del sistema numérico, y representados por las letras del alfabeto (los dígitos se nos acabaron en el 9 y de alguna manera había que representar los que faltaban, ¿no?)

Ahora, durante la programacion de SPHERE, prácticamente NUNCA vas a manejar números binarios que NO sean potencias de dos, y si lo haces, simplemente puedes usar una calculadora científica para hacerte una idea del resultado. Pero es múchísimo más fácil en hexadecimal.

(Esta es la última tabla, ¡¡Lo prometo!!)
{| border="1"
| Binario || Hexadecimal
|-
| 000000001 (1) || 01
|-
| 000000010 (2) || 02
|-
| 000000100 (3) || 04
|-
| 000001000 (4) || 08
|-
| 000010000 (5) || 010
|-
| 000100000 (6) || 020
|-
| 001000000 (7) || 040
|-
| 010000000 (8) || 080
|-
| 100000000 (9) || 0100
|}

Como puedes ver, hay una especie de patrón en la columna hexadecimal. Puedes estar pensando que hay algún tipo de patrón con los números 1, 2, 4 y 8. Y estarias pensando acertadamente. otro detalle del que quizás te des cuenta es del de los ceros que hay delante de cada número hexadecimal (como 0100, en vez de simplemente 100). En SPHERE, ese 0 le dice al script "¡Oiga!, ¡este número está en HEX!" ya que 0100 y 100 son números muy distintos (0100 en hexadecimal equivale a 256 en decimal; 100 en decimal equivale, evidentemente, a 100 en decimal y por otro lado 100 en binario equivale a 4 en decimal; así que un poco si que cambia la cosa ¿verdad?).

Digamos que, para un script de SPHERE, necesitas establecer el decimotercer bit de un número (FLAGS, por ejemplo), podrías escribir algo parecido a:

'''SRC.FLAGS |= 8192'''

Pero, ¿realmente te acordarías de que 8192 es 2 elevado a la 13ª potencia? Lo dudo mucho. Lo que sería más fácil, es recorrer toda la lista de cabeza hasta llegar al 13er numero. (¡Recuerda!, ¡¡COMIENZA EN CERO cuando estés contando potencias!!)

{| border="1"
| 01 || 02 || 04 || 08 || 010 || 020 || 040 || 080 || 0100 || 0200 || 0400 || 0800 || 01000 || 02000
|-
| 2^0 || 2^1 || 2^2 || 2^3 || 2^4 || 2^5 || 2^6 || 2^7 || 2^8 || 2^9 || 2^10 || 2^11 || 2^12 || 2^13
|}

Y ahí tienes. Las primeras 14 potencias de dos traducidas a hexademical.

'''SRC.FLAGS |= 02000'''

El código de arriba es idéntico al ejemplo anterior. 8192 (decimal) es IGUAL que 02000 (hexadecimal)

'''8192 = 02000'''

Podrías decir, "¿Y cómo sé yo que no te estás inventando todo esto?" Pues bien, nuestros maravillosos amigos de Microsoft nos han provisto de una herramienta genial para convertir de decimal a binario, hexadecimal y octal (OTRO sistema de numeración que no se utiliza en SPHERE, así que pasaremos de él). Se llama 'Calculadora'. Puedes encontrarla en el botón 'Inicio', yendo a 'Programas', y luego 'Accesorios'. La calculadora debería estar sentada por alli viéndose preciosa. Una vez abierta la calculadora, Ve al menu 'Ver' y pulsa sobre 'Científica'. El display debería cambiar drásticamente. Para convertir los numeros entre los distintos sistemas numéricos, simplemente pincha en el sistema original (Dec), escribe un número (8192), y pulsa en el botón del otro sistema (Hex). Auto-mágicamente, Windows convertirá tu número decimal en hexadecimal. Pégale un cero delante, y SPHERE estará encantado de comerse ese suculento plato.

Probablmente esta sea la cosa más dificil para entender de la programación en SPHERE. Afortunadamente, debido a la siguiente sección, no tendrás que estar tratando con numeros tan feos todo el rato. Si después de todo este tochaco, aún sigues leyendo esto, ¡Sé que lo vas a hacer genial!

¡Vamos a por algo de programación en SPHERE!

==Defnames (Definiendo nombres)==

Aqui hay una lista de numeros bastante feos que puedes encontrarte mientras programas SPHERE.

{| border="1"
| El número feote || Lo que significa...
|-
| 0EED || ID de una moneda de oro
|-
| 0DDA || ID de un portal rojo
|-
| 1650,1440 || Coordenadas de Britain
|-
| 021 || Código numérico para el color rojo
|-
| 04000 || El color transparente
|-
| 04000EFAD || Identificador de un objeto
|-
| 4 || El PLEVEL de un GM
|-
| 2048 (or 0800) || Marca (FLAG) del hechizo Incógnito
|-
| 010 (or 16) || Tipo de memoria para los agresores
|}

Evidentemente, nadie va a querer acordarse de esos números. En los viejos tiempos, antes de SPHERE y TUS (pre-.50 SPHERE) e incluso en las nieblas de Grayworld (pre-.41 TUS), todos teníamos que acordarnos de esos números. Conozco todos los números que he dicho (excepto el identificador, que me lo acabo de inventar), y una docena más, lo digo de verdad. Afortunadamente para todos aquellos que no quereis sentaros a empollar números, SPHERE ha desarrollado un sistema por el cual las cosas pueden ser identificadas por nombres en lugar de números.

De hecho, las cosas aún se identifican por números. Son los números los que se identifican por nombres.

En el juego, escribe .add 0EED y pulsa intro. Aparecerá un cursor de objetivo y crearás una moneda de oro.

Ahora escribe .add i_gold y pulsa intro. Crearás la misma moneda de oro.

¿Cual de los dos es más facil de recordar, 0EED ó i_gold?. yo diría que i_gold gana de lejos. Pero, ¿cómo ocurre esta magia? Echémosle un vistazo al script que define una moneda de oro. No te molestes en entenderlo. ¡Explicaré los scripts de objetos en la siguente sección! Podemos encontrar este script en el archivo sphere_item_resources.scp.

<tt>[ITEMDEF 0eed] 
//gold coin 
DEFNAME=i_gold 
TYPE=T_GOLD 
VALUE=1 
CATEGORY=Provisiones - Miscelanea 
SUBSECTION=Monedas 
DESCRIPTION=Moneda de oro 
DUPELIST=0eee,0eef </tt>

He remarcado la linea que realmente importa para los propósitos de esta lección en rojo. Fíjate en ese 0EED en la primera línea del script, e ignora el resto. Ese 0EED es el auténtico número de ese objeto. Estudiaremos más números de objetos en la siguiente sección

Pero la verdadera línea que quiero que te fijes es en DEFNAME=i_gold. Ahí es donde el script le dice al servidor, "Quiero que el objeto 0EED sea identidifcado con el texto i_gold a partir de ahora." Si has intentado acceder a i_gold antes de que el servidor lea este script (Un poco más acerca de reordenar scripts en el [[Capítulo 2]]), escupirá uno de sus errores, pero ahora ya sabe a que te refieres, y por lo tanto lo puedes usar en juego o en otros scripts.

Deberias darle SIEMPRE a los objetos que crees un DEFNAME que se ajuste a ese objeto. Normalmente el nombre por defecto se definirá en el mismo identficador [ITEMDEF] (de nuevo, más de esto luego), pero si insistes en usar números, asegurate de darle un nombre fácil de recordar (Y no gulash_dorada para definir a una espada vikinga). Esto lo hará mas facil de recordar que los números.

Otra manera de definir un DEFNAME es usando la cabecera [DEFNAME] en un script. He aquí un ejemplo:

<tt>[DEFNAME colores] 
color_azul 02 
color_rojo 021 
color_verde 041 </tt>

Encontraras un script parecido en spheredefs.scp, otro de los archivos que debería ser cargado antes que ningún otro.

Aquí está el análisis, línea por línea:

'''Línea 1''': Aquí es donde defines el tipo de script y el nombre por defecto (Sí, colores es el nombre por defecto de este script). Esto le dice al servido qué tipo de script se debe esperar entre este y el siguiente identificador (Los identificadores son las lineas encerradas en corchetes). Todos los identificadores tienen este formato. El primer parámetro es el tipo de script. Éstos son variados, y los explicaré conforme vayamos llegando. El segundo puede ser tanto un ID como un nombre por defecto. En la mayoría de las veces, en los scripts que escribas, será un nombre. La única excepción que se me ocurre es que utilices un programa para parchear el cliente y añadir nuevos tipos de objeto.

'''Lines 2-4''': Éstas definen cada DEFNAME. Viene a decir que color_azul equivale a 02, color_rojo equivale a 021, y color_verde equivale a 041. Puedes utilizar todos los espacios que quieras entre el nombre y el valor. Las definiciones contenidas en spheredefs.scp están entre las más útiles que puedas llegar a encontrarte, dado que evitan que tengas que escribir números tan feos como los vistos en la sección anterior. Estas incluyen cosas como nombres para marcas (flags), atributos de objetos, música en MIDI o MP3, tipos de memoria, y otras muchas cosas. Échale un ojo al archivo para ver qué es lo que este te ofrece.

Esto es lo que hay que saber sobre DEFNAMEs. Ya veremos un poco más conforme vayamos cubriendo otros tipos de scripts.

Aprendamos algo acerca de objetos.

==ITEMDEF (Definiendo Objetos)==
O, cómo hacer una montaña de un grano de arena, al estilo SPHERE.

La mayoría de la gente crea scritps de objetos de una forma mucho más dificil de lo que realmente es. Para propósitos de este tutorial, y dado que hay uno más avanzado para luego, sólamente veremos lo más básico de un script de objetos, línea a línea. Usaremos el script de la moneda de oro de la lección anterior.

Helo aquí, ¡Coloreado convenientente para disfrute de tus ojos!

<spherescript>[ITEMDEF 0EED]
//moneda de oro
DEFNAME=i_gold
TYPE=T_GOLD
VALUE=1
CATEGORY=Provisiones - Miscelanea
SUBSECTION=Monedas
DESCRIPTION=Moneda de oro
DUPELIST=0EEE,0EEF</spherescript>

Esto es lo más simple en scripts de objetos, ya que no tiene ningún comportamiento más allá de la pura existencia. Repasaré linea por linea, describiéndote que hace cada una, y cómo afecta al resultado final.

'''Línea 1''': [ITEMDEF 0EED]

La primera línea de un script de objetos es probablemente la más importante. Básicamente esta linea le dice al servidor "Oiga, ¡esto es un objeto y quiero que se llame 0EED!" El servidor, entonces mira uno de los archivos del cliente (Especificamente art.idx), Identifica si es o no es un objeto Build-in. Creo que todos los objetos por debajo de 04500 están definidos como objetos built-in, así que no definas nunca un objeto en ese rango. Escribiendo esta línea, le dices al servidor que lo siguiente es un script de objet. También defines 0EED como objeto válido, ¡Lo cual ayuda bastante cuando intentes darle oro a tus jugadores!

'''N.T.: Dejo el resto del artículo pendiente para otra ocasión u otra persona. Disculpad las molestias, seguiré mañana.'''

'''Línea 2''': // moneda de oro

This is the SPHERE version of comment. C programmers will recognize the format immediately. If you type // on any line of code, everything beyond that is ignored by the script reader. This can be on a line by itself, or at the end of a line to explain what the specific line does. In all cases, it won't affect your program, just make it easier to read.

'''Línea 3''': DEFNAME=i_gold

You should know by now what this does! If you don't, go back and read the previous lesson! It tells the server that i_gold and 0eed mean the same thing. In item scripts, all parameters are defined in that format:

variable=value

You will see later on, when we get into scripting, how that format will help you more than you would believe. Items have a good number of variables that you can define, including:

* DEFNAME
* ID
* TYPE
* VALUE
* RESOURCES
Other variables depend on the value of the TYPE. Which leads us right into...

'''Line 4''': TYPE=t_gold

The first thing you might say is "What the heck is t_gold?" Well it's a DEFNAME. Actually it's a number. And that number is 72. If you want to check me on this, look in spheredefs.scp, it's there! Writing TYPE=72 would have the exact same effect.

There are, currently, 183 built-in item types. These are hardcoded item types that contain predefined actions for an item. If an item has no type, when you click it, you get the "You cannot think of a way to use that item" message. There is a complete list of types, and how to set them up, here . All you need to know for now is that setting the type of this item to t_gold has no effect other than to make the item act like a gold coin (i.e. you can buy stuff with it!) Setting another item to type t_gold would probably make the server think that you can buy stuff with that item too. I've never tried this. It might be an interesting way to have unique currencies...

'''Line 5''': VALUE=1

This defines how much the item costs when purchased, in gold. Of course, this is one gold piece, which is worth, well, one gold piece. So the value of the item is one.

'''Lines 6-8''': CATEGORY, SUBSECTION, DESCRIPTION

These are lines used only by SPHERE's GM tool, Axis, which actually saves you a lot of work by typing ".add i_gold" for you. More importantly, it types ".add 01737" and things like that for you, for items that were not important enough to get their own separate DEFNAME.

'''Line 9''': DUPEITEM

It would be a ton of work for the SPHERE team to define all 8000 items that came with the game, especially when many of them are the same. (For an example of this, use the .xflip command on a door or sign. It cycles through all of the DUPEITEMs for that the item being flipped.) The numbers listed here are item numbers, which probably have not been defined yet. Here is the script for item 0eee:

<spherescript>[ITEMDEF 0EEE]
//gold coins
DUPEITEM=0EED
CATEGORY=Provisions - Miscellaneous
SUBSECTION=Coins
DESCRIPTION=Gold Coins</spherescript>

As you can see, there is only one parameter for this whole item. It reiterates the DUPEITEM and sends the server looking to our 0eed (or i_gold) item for more information, such as TYPE and VALUE. DUPEITEM only exists to save typing. You probably won't use it.

==CHARDEF==
Or, what it takes to make a naked man who can stand around and say "Huh?"

NPCs... They make the world go around. They are what makes UO a unique multiplayer game. The monsters and NPCs you create make your server unique from any other. This section of chapter one will cover how to create a simple naked man who walks around and says little more than "Huh?" (or "Stop thief!" if you tell him to!).

First of all, we'll look at the script for a simple naked man. I'm pulling this out of spherechar_human.scp.

<spherescript>[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</spherescript>

As you can see, it doesn't look a lot different than the item scripts we examined in the previous section. There are a lot of variables set that are the same, including DEFNAME, DESCRIPTION, and the other Axis variables.

But, there are a lot of new things here that we will again go over, one line at a time! And it's longer this time! Let the good times roll! (Sorry if you're not American.. All my American clichés are probably growing irritating!)

'''Line 1''': [CHARDEF 0190]

Surprise surprise! It's an identifier, telling the server that we are going to be defined a character between this and the next [identifier]. And we also tell it that our character, or NPC, will have the ID 0190. The server knows that this ID is one of the built-in IDs. In fact, it's the ID of a naked man. You also know that 0190 is hexadecimal is 400 in decimal right? :) Well why didn't you know that! Oh I'm just kidding, you don't need to know things like that.

'''Line 2''': DEFNAME=c_man

Nothing new here. c_man is now the same as 0190. Most character DEFNAMEs will begin with C and then an underscore (c_) like you see above.

'''Line 3''': Name=Man

Oh oh! Something new! Items come with default names, built in to the server. Characters don't. So we have to assign him a name. We can give him any name we want, but since this isn't a specific man, we just give him a name telling us what he is. In this case "Man".

'''Line 4''': ICON=i_pet_man

It took me a while to figure this one out. ICON defines what little picture you see when you're using the Tracking skill and all those little miniature creatures appear in the window. Those are actually items, all the i_pet items. To find out what the i_pet item for your creature should be, create him in the game using .addnpc, then use the .shrink command on him. The ID of the item that he becomes is your i_pet item.

'''Line 5''': CAN=mt_*

(In case you don't know, * means "anything" for those who use Linux.)

This is one of the most important lines of your character script, next to the ID we give him in the first line. First, because it allows us to tell the game what our NPC can do and what he can't do. There are only a few mt_* items, all of which are defined in spheredefs.scp. For the purpose of the lesson, I am going to copy them here. (The purple comments are mine.)

<spherescript>MT_NONMOVER 0 // We can't move at all
MT_GHOST 01 // We can walk through doors and such, like a ghost
MT_SWIM 02 // I can swim! (Water elementals, dolphins, etc)
MT_WALK 04 // I can move. Set this if you want your creature to move.
MT_FLY 010 // Moves through (supposed to be over) trees
MT_FIRE_IMMUNE 020 // Immune to damage by fire. Setting this on a player is bad. :)
MT_EQUIP 00100 // Can equip things
MT_USEHANDS 00200 // Can use his hands to carry things (or open doors)
MT_MALE 0 // Is a male
MT_FEMALE 00800 // Is a female
MT_NONHUM 01000 // Non-human. I'm not sure what this does.
MT_RUN 02000 // Can move really fast!</spherescript>

According to this chart, we can see that if we don't give a creature a CAN flag, it will be an MT_MALE and an MT_NONMOVER (the two zeros). You can see from the example that by putting a | (found by pressing shift+backslash) between two CAN flags, we can give him more than one. In this case, we allow our man to equip things, walk, run, and use his hands. (An interesting fact is, even creatures that don't have hands can be set to use their hands, thus allowing them to carry light sources. Fire elementals do this. That's how they glow.)

'''Line 6''': RESOURCES

Resources is a very morbid name for this setting. Especially for a person. These are the items that you get whenever you chop up this creature's corpse. Scary eh? :)

'''Line 7-10''': FOODTYPE, DESIRES, AVERSIONS

'''FOODTYPE''': Defines what kind of food the npc will eat and if NPC_AI_FOOD is on it'll make the npc look for this food + grass when he's hunger.

'''DESIRES''': Defines what kind of items will the npc be interested in, if NPC_AI_EXTRA is on it'll show what items the npc will loot of players corpses or walk towards when it's on the ground.

'''AVERSIONS''': No idea, but I think it tells the npc what sort of NPCs he'll try to fight, for example: I have a horse with e_horse as an event, and an imp without any events, if the npc has AVERSIONS=e_horse it'll prefer to fight the horse.

'''Line 11''': BLOODCOLOR

Ever wanted to make your players have green blood? This is where you do it! A color number or a color defname will work fine. (Try to learn the numbers for common colors, it makes it so much easier.)

The rest of it: TSPEECH and TEVENTS

We're going to cover these in sections of their own. They are probably the most complex topics in scripting! (How many times do you suppose I'm going to say that before it's actually true?)

''Some other things:''

On 56B we have some other fields like MOVERATE,RESLEVEL,RESDISPDNID and RESDISPDNHUE. They sound some difficult and strange thing but they aren't. Here's the explanation for them:

'''MOVERATE''': This setting (that can only be writed at the npc chardef) controls how fast the npc moves. The smaller the value, the faster the npc is. For example, if I have a horse chardef with default moverate (100) and another with moverate=60, the one with 60 will walk and run a lot faster than the other horse. This is great for making really difficult monsters to kill.

'''RESLEVEL''': This tells sphere what version of uo this monster is from, for example, a Wanderer of the Void will have RESLEVEL=3 (3=AOS) (see sphere_defs.scp for a complete list), so only accounts with RESDISP 3 or bigger can see this monster as he really is.

''NOTE'': If you set a lower value for RESLEVEL, if the player doesn't have this npc anim he'll crash.

'''RESDISPDNID''': As you probably have seen, I used a lot of "as he really" is, exactly because of this setting, this tells the client what monster will the player see instead of the correct one. For example, this Wanderer of the Void will show as Wanderer of the Void for those who has ACCOUNT.RESDISP=3 or bigger, but for those who has smaller values it'll show as a c_spectre (if you so define).

'''RESDISPDNHUE''': This defines what color will the player see the monster if the RESDISPDNID id is shown to him (have an account.resdisp lower than the reslevel of this char)

Here's an example for those new settings:

<spherescript>[CHARDEF 310]
DEFNAME=c_Wailing_Banshee
NAME=Wailing Banshee
SOUND=snd_monster_zombie1
ICON=i_pet_wailingbanshee
DAM=11,16
RESDISPDNID=c_spectre
RESLEVEL=3
RESDISPDNHUE=01
ARMOR=20
CAN=MT_WALK|MT_FLY
DESIRES=i_gold,e_notoriety,e_horses,c_man,c_woman,t_corpse
CATEGORY=New Monsters
SUBSECTION=AOS
DESCRIPTION=Wailing Banshee

ON=@Create
NPC = brain_monster
FAME = {100 3000}
KARMA = {-5000 -6999}
STR = {126 166}
INT = {86 115}
DEX = {41 75}
MAGICRESISTANCE = {75.0 95.0}
TACTICS = {45.0 75.0}
WRESTLING = {50.0 70.0}

ON=@NpcRestock
ITEM = i_gold, {50 100}
ITEM = i_reag_daemon_bone, {2 6}</spherescript>

And there you have it. A simple character script and some new things. Read the chapter that is all about making NPCs later in the tutorial.

==TEMPLATE==
Or, how to put great laggy quantities of items into one unlaggy container.

You've all seen it. Those shards out there that don't use TEMPLATEs. When you kill, say, a dragon, on those shards, and go to loot him, you find that rather than neatly organized containers, there are 100 potions scattered about the loot window. Not only that, but all your magical weapons are buried neatly beneath them!

How do we solve this problem? Well, SPHERE has given us the handy tool of TEMPLATEs. These allow you to define a container item, AND the items inside of it, AT THE SAME TIME. Isn't that neat? I thought so too, when I first figured out what they were. Let's do our traditional take-apart-the-script section. I'll place a nice TEMPLATE from the file spheretemp_loot.scp.

<tt>[TEMPLATE 101505] 
DEFNAME=backpack_poor 
CATEGORY=Item Templates 
SUBSECTION=Loot Templates 
DESCRIPTION=Poor Backpack 
CONTAINER=i_backpack 
ITEM={ random_food 1 0 3 },{ 1 3 } 
ITEM={ random_bottle 1 0 8 } 
ITEM={ random_light 1 0 8 } 
ITEM={ random_male_tops 1 0 4 } 
COLOR=colors_all 
ITEM={ random_male_pants 1 0 4 } 
COLOR=colors_all 
ITEM=POOR_GOLD_PILE </tt>

Wow, that looks confusing. But don't worry, by the time we're done, you'll know exactly what it means!

[TEMPLATE 101505]: First of all, we look at the header for our template. An interesting thing about templates is that the item name cannot be a DEFNAME like all other scripts. It must be a ridiculously high number like 101505.

DEFNAME=backpack_poor: Of course, SPHERE developers are not entirely evil, and have provided us with the ability to give these scary numbers a DEFNAME for easier access. You tell me, which would you rather type? ".add 101505" or ".add backpack_poor"? I thought so.

CATEGORY, SUBSECTION, DESCRIPTION: Axis crap. Optional. See the previous sections for a description of what these do.

CONTAINER=i_backpack: Ahh, now we're getting down to the meat of this thing. This specifies the holding container that all other items in this template will be in. When you add the item in game, you will see this container. In this case, it's a backpack. Simple enough. This can be any valid item with a TYPE of t_container or t_container_locked.

ITEM={ random_food 1 0 3},{1 3} Well, that's certainly cryptic. I think we need to break this line down even further.

But first, we're going to cover RANDOM SELECTORS! Sounds like fun doesn't it? Nah, it doesn't sound fun to me either, but it's absolutely necessary to a good shard.

Basically, they are an easy way to get different numbers with one command. What fun would a shard be where you killed a dragon and got a Platemail of Magic Stuff and a Super Duper Sword of Power every single time? Everyone would be running around with them. What we need is some variety!

There are two types of random selectors: weighted random and ranged random. Weighted random makes a statement like this: "Ok, 1 out of 10 times pick Number A, 3 out of 10 times pick Number B, and 6 out of 10 times pick number C". Ranged random makes a statement like this: "Pick any number between the two numbers I give you".

Our example actually has an example of both ranged random and weighted random. We'll cover them in the order they appear:

{ random_food 1 0 3}

This is a weighted random selector. The way to interpret these is to take the numbers that appear between the parentheses and divide them into sets of two:

random_food 1 
0 3

Add up the second numbers in both sets, and we get 4. This tells SPHERE, "Ok, 1 out of four times, I want you to pick random_food, and 3 out of four times, I want you to pick zero." You can even have random sets within random sets, but then it just gets confusing.

{ { random_food 1 0 3} 1 random_clothing 1}

Can you figure it out?

random_clothing 1
{ random_food 1 0 3} 1

2 is our magic number in this case. One out of two times, SPHERE will pick random_clothing, and one out of two times, SPHERE will pick our previous random selector, which will then select one of its own options. If you're confused at this point, don't worry. This is extremely rare, and we'll see in a moment how templates help us to solve this problem.

I did mention, though, that there is another type of random selector, and you can probably see what it is:

{1 3}

NOTE: Spacing here is important. There must be ZERO spaces between the { and the first number, or the } and the last number. It will behave strangely otherwise.

This tells SPHERE "Pick a number between 1 and 3, inclusive". Inclusive means that SPHERE can pick 1, 3, or any number in between. In this case, the range is rather limited. SPHERE will give you a 1, 2 or 3 here. Ranged random selectors are actually more often used inside of weighted random selectors.

{ {1 3} 3 {4 9} 1}

"One out of four times, pick a number between 4 and 9. Three out of four times, pick a number between 1 and 3."

And with that out of the way, we're going to analyze the actual line of the script from above. The Piece What the Line does ITEM=
This tells the script "Ok, we're going to add an item to this container. Anything after the = tells the script exactly what it is we're adding and in what amounts. You could easily say ITEM=i_platemail_chest, or something like that, without the mysterious { } sections, but the reason templates are interesting is because they can vary greatly.

{ random_food 1 0 3}

This is the item you will be creating. As we can see from our weighted random selector lesson, 1 out of 4 times, it will be random_food, and 3 out of 4 times, it will be zero. If an ITEM is zero, nothing will be created this time. Basically this is saying "There will be a one in four chance of getting random_food in this container." What is random_food you ask? Well, it happens to be another TEMPLATE, defined in spheretemplate.scp, I believe.

{1 3} This is the amount of the item that will be created. You should recognize this as a ranged random selector. This tells SPHERE to put between 1 and 3 of this item into the container. Of course, if the item is zero as selected above, this has no effect since one nothing and three nothings are still nothing.

So basically, that is a template script. You then fill it with as many items as you want. You may also notice the following construction:

ITEM=i_sword_long,R11

This is a shorthand way of writing this:

ITEM={ i_sword_long 1 0 10 }

R11 means "one out of 11 chance of finding this item". And you can add an amount selector to the end of that as well, which makes it look long and scary:

ITEM=i_sword_long,R11,{4 5}

But why would you want 4 or 5 long swords in one item? That would be bizzare. :)

And that's about it for templates. Congratulations, you're finished with chapter 1. Now you should be able to understand the examples to follow on the next section. You may also have some questions which are addressed in the common questions area. If you have a question which is not addressed there, perhaps it is too advanced of a topic for chapter 1. I assure you almost every aspect of SPHERE scripting will be covered in later chapters.

''(A template example by Belgar)''

<tt>[TEMPLATE tm_necromancer] 
CONTAINER=i_bag 
ITEM=random_necro_scroll 
ITEM=random_necro_scroll 
ITEM=random_necro_reagent, {5 12} 
ITEM=random_reagent, {5 12} 
ITEM=random_necro_reagent, {5 12} </tt>

==Examples==
Or, um. Well I guess there really isn't another way to say "Examples".

This shall be my attempt to create the most basic new items available. You will see things in these examples that are NOT mentioned in the tutorials. The major factor will be ON=@Create, which is the primary topic of Chapter 2. Just know for now that things you can change in game (color, etc) must go under ON=@Create.

'''Example 1''': A Red Sword

<tt>[ITEMDEF i_sword_red] 
ID=i_sword_viking 
TYPE=t_weapon_sword 
NAME=The Red Sword 
CATEGORY=Weapons 
SUBSECTION=New Swords 
DESCRIPTION=Red Sword 

ON=@Create
:COLOR=colors_red // This is a comment. Comments are ignored by SPHERE. </tt>

Wait, what is this weird // thing we've got going here? That's called a comment. It's completely ignored by SPHERE, so you can write whatever you want to the end of the line after //. You cannot have multi-line comments in SPHERE unless you use a new //, so don't even try it. SPHERE will give funky errors and then you'll have fun finding them.

'''Example 2''': A blue ettin

<tt>[CHARDEF c_ettin_blue] 
ID=02 // You could just as easily use c_ettin here. 
NAME=My Blue Ettin 
 
 
ON=@Create 
:COLOR=02 // This is a dark blue color. It's often used for Counselor robes. Remember it. </tt>

'''Example 3''': A template from the file, since I'm too lazy to write one myself

<tt>[TEMPLATE 101521] 
DEFNAME=goodie_meager_1 
CATEGORY=Item Templates 
SUBSECTION=Loot Templates 
DESCRIPTION=Meager Goodie 1 
ITEM={ meager_gold_pile 1 backpack_meager 1 pouch_meager 1 } 
ITEM={ random_boots 1 0 4 } 
ITEM={ random_gorget 1 0 4 } 
ITEM={ random_staff 1 0 4 } 
ITEM={ random_necklace 1 0 4 } 
ITEM={ i_cape 1 0 9 } 
COLOR=colors_all </tt>

You may notice something new here (especially since I highlighted it in red), and yes, it is legal. Any lines between ITEM= lines will affect the previously created item. The COLOR= line here affects the ITEM created by the line

ITEM={ i_cape 1 0 9 }

Remember, the best way to learn this type of scripts is to read the scripts provided for you in files like sphereitem_colorarm.scp and sphereitem_beers.scp.

[[Category:Tutorials]]
<math>Formel hier einfügen</math>

Chapter 1

2011-03-09T07:18:03Z

Sirius: /* TEMPLATE */

{{Languages|Chapter_1}}

==Numbers==

The first thing you'll notice while looking through SPHERE scripts is the wide variety of ways to write numbers. Since numbers are insanely important to a SPHERE scripter, this is the first lesson in the series. By the end of the lesson, I hope that you have a general understanding of hexadecimal, decimal and binary numbering systems, and SPHERE's ways of identifying each. You will also know how to generate random numbers either from a series or from a list of choices.

The first thing you need to understand is that the way we count is not the only way to count. Our numbering system contains ten digits (0, 1, 2, 3, 4, 5, 6, 7, 8, and 9). Therefore, at the tenth number, we have to add an extra column to the number, and reset the first column to zero (1, 2, 3, 4, 5, 6, 7, 8, 9, 10). That's why our numbering system works the way it does.

In the decimal system, without realizing it, we write our numbers to mean powers of ten. For example, if you take the number 17282 (which I just made up), and divide it down we get this:

{| border="1"
| Power of ten || 4 || 3 || 2 || 1 || 0
|-
| Ten to that power || 10000 || 1000 || 100 || 10 || 1
|-
| Digit || 1 || 7 || 2 || 8 || 2
|}

To reach the number 17282 from here, we simply take ten to the power of the number in the top row, multiply it by the number in the bottom row, and then add all those numbers together. We get 10000 + 7000 + 200 + 80 + 2. Obviously, this is simplistic, and we do it without even realizing we're doing it. You're probably thinking "Riiight, what does Taran think he's getting at?" Well, we aren't so special that our counting system is the only way to count.

Now, there is another numbering system that is used almost solely by computers. It only contains two numbers (1 and 0) and is therefore called the binary (meaning two) system. Binary numbers look like this: 101011101101, and you often see them in ads for computers and other electronic equipment (oftentimes they are shown streaming out of a CD player on television commercials). Digits in the binary system are called bits (short for BInary digiT)Binary numbers are almost impossible to translate to decimal directly, and so some math must be done.

Binary works in the same way, by adding powers of a number. In the case of binary, since there are two numbers in the whole system, that number is naturally two. Here are some examples of powers of two. These numbers might look familiar to some people.

{| border="1"
| Power of 2 || Binary number || Decimal number
|-
| 0 || 1 || 1
|-
| 1 || 10 || 2
|-
| 2 || 100 || 4
|-
| 3 || 1000 || 8
|-
| 4 || 10000 || 16
|-
| 5 || 100000 || 32
|-
| 6 || 1000000 || 64
|-
| 7 || 10000000 || 128
|-
| 8 || 100000000 || 256
|-
| 9 || 1000000000 || 512
|-
| 10 || 10000000000 || 1024
|}

Ridiculous eh? :)

We need a better system! The reason we get such strange results is because 10 is not a power of two. We need to find a system where the number base IS a power of two. The most commonly used system used is base-16, or hexadecimal. I'm sure if you've perused the SPHERE boards, you've seen the word hex floating around. No, this isn't a curse or evil spell, it's a short way of saying "hexadecimal".

{| border="1"
| Binary || Decimal || Hexadecimal
|-
| 1 || 1 || 1
|-
| 10 || 2 || 2
|-
| 11 || 3 || 3
|-
| 100 || 4 || 4
|-
| 101 || 5 || 5
|-
| 110 || 6 || 6
|-
| 111 || 7 || 7
|-
| 1000 || 8 || 8
|-
| 1001 || 9 || 9
|-
| 1010 || 10 || A
|-
| 1011 || 11 || B
|-
| 1100 || 12 || C
|-
| 1101 || 13 || D
|-
| 1110 || 14 || E
|-
| 1111 || 15 || F
|-
| 10000 || 16 || 10
|}

See how it works? There are an extra six numbers added onto the end of the system, represented by the first six letters of the alphabet.

Now, in SPHERE scripting, you are almost NEVER going to be dealing with binary numbers that are NOT powers of two, and if you do, you can simply use any scientific calculator to figure it out. But it's a lot easier in hexadecimal.

(This is the last table, I promise!!)
{| border="1"
| Binary || Hexadecimal
|-
| 000000001 (1) || 01
|-
| 000000010 (2) || 02
|-
| 000000100 (3) || 04
|-
| 000001000 (4) || 08
|-
| 000010000 (5) || 010
|-
| 000100000 (6) || 020
|-
| 001000000 (7) || 040
|-
| 010000000 (8) || 080
|-
| 100000000 (9) || 0100
|}

As you can see, there's a bit of a pattern in the hexadecimal column. You might be thinking, there seems to be some sort of pattern of the numbers 1, 2, 4 and 8. And you would be right. Another detail you may notice is the zeros in front of the hexadecimal numbers (like 0100, rather than just 100). In SPHERE, that 0 tells the script "Hey, this number is HEX!" 0100 and 100 are very different numbers.

Let's say, for a SPHERE script, you need to set the 13th bit of a number (FLAGS, for example), you could write something like this:

'''SRC.FLAGS |= 8192'''

But would you really remember that 8192 is 2 to the 13th power? I didn't think so. What would be easier is to go down through your list in your head, until you reach the 13th number. (Remember, START AT ZERO when you're counting!)

{| border="1"
| 01 || 02 || 04 || 08 || 010 || 020 || 040 || 080 || 0100 || 0200 || 0400 || 0800 || 01000 || 02000
|-
| 2^0 || 2^1 || 2^2 || 2^3 || 2^4 || 2^5 || 2^6 || 2^7 || 2^8 || 2^9 || 2^10 || 2^11 || 2^12 || 2^13
|}

And there you have it. The first 14 powers of two in hexademical.

'''SRC.FLAGS |= 02000'''

The above code is identical to the previous example. 8192 (decimal) is EQUAL to 02000 (hexadecimal)

'''8192 = 02000'''

You may be saying, "How do I know he's just not making all of this up?" Well, our wonderful friends at Microsoft have provided us with a nice tool that converters from decimal to hexadecimal to binary to octal (ANOTHER numbering system that is useless in SPHERE, so we will not deal with it). It's called the Calculator. You may find it by clicking your start button, going to Programs, then Accessories. Calculator should be sitting there looking pretty. Once in the calculator program, go to the View menu, and click Scientific. You'll see the display drastically change. To convert a number between numbering systems, simply click on the original system (Dec), type a number (8192), then click on the button for the other system (Hex). Automagically, Windows will convert your decimal number to hexadecimal. Stick a zero on the front, and SPHERE will be perfectly happy with it.

This is probably the hardest thing in all of SPHERE scripting to understand. Luckily, because of the next section, you won't have to deal with scary numbers most of the time. If I still have you at the end of this lesson, I know you're going to do great!

Onward to some SPHERE scripting!

==Defnames==

Here's a list of scary numbers you might encounter while programming in SPHERE.

{| border="1"
| The Scary Number || What it means
|-
| 0eed || ID of a gold coin
|-
| 0dda || ID of a red moongate
|-
| 1650,1440 || Coordinates of Britain
|-
| 021 || The code number for red
|-
| 04000 || The invisible color
|-
| 04000efad || An item's serial number
|-
| 4 || The PLEVEL of a GM
|-
| 2048 (or 0800) || Flag for incognito spell
|-
| 010 (or 16) || Memory type for aggressors
|}

Obviously, no one is going to want to remember those numbers. Back in the old days, before SPHERE and TUS (pre-.50 SPHERE) and even into the mists of Grayworld (pre-.41 TUS), we all had to remember those numbers. I know all of those numbers I just said (except the serial number which I just made up), plus a couple dozen more, by heart. Luckily for those of you who don't like to sit around remembering numbers all day, SPHERE has developed a system whereby things can be identified by names instead of numbers.

Actually, the things are still identified by numbers. It's the numbers which are identified by the name.

In the game, type .add 0eed and press enter. A target will come up and you'll create a single gold piece.

Now type .add i_gold and press enter. You will create the same single gold piece.

Now which is easier to remember, 0eed or i_gold. I would say that i_gold wins by a long shot. But how does this magic happen? Let's take a look at the script definition for a piece of gold. Don't worry about understanding it. I'll explain item scripts in full in the next section! You can find this script in the file sphere_item_resources.scp.

<tt>[ITEMDEF 0eed] 
//gold coin 
DEFNAME=i_gold 
TYPE=T_GOLD 
VALUE=1 
CATEGORY=Provisions - Miscellaneous 
SUBSECTION=Coins 
DESCRIPTION=Gold Coin 
DUPELIST=0eee,0eef </tt>

I have highlighted in red the line that really matters for the purposes of this lesson. Take note of the 0eed in the top line of the script, and then ignore the rest of it. That 0eed is the real item number of this item. We'll cover item numbers more in the next section.

But the real line we want to see the DEFNAME=i_gold line. This is where the script tells the server, "I want item 0eed to be identified by the text i_gold from here on." If you tried to refer to i_gold before the server read this script (more on reordering scripts in [[Chapter 2]], the server would spit out an error, but now it knows what that refers to, so you can use it in the game or in another script.

You should ALWAYS give items you create a DEFNAME that fits the item. Usually the defname will be defined in the [ITEMDEF] identifier itself (again, more on this later), but if you insist upon using numbers, be sure you give it an easy-to-remember name (not golden_gulash for a viking sword). It makes it easier to remember names than numbers.

A second way to define a DEFNAME is by using the [DEFNAME] tag in a script. Here is an example of that:

<tt>[DEFNAME colors] 
color_blue 02 
color_red 021 
color_green 041 </tt>

You'll find a script similar to this in spheredefs.scp, another file that should be loaded before any other file.

Here's the rundown on this script, line by line:

'''Line 1''': This is where the type of script and the defname (yes colors is the defname of this script) is defined. This tells the server what type of script to expect between this and the next identifier (identifiers are the lines contained in square brackets). All identifiers have this format. The first parameter is the script type. These are numerous, and I will go over them as we get to them. The second parameter is either an ID number or a defname. In most cases, in the scripts you write, it will be a defname. The only exceptions to this I can think of would be if you used a program to insert a new item into the client files.

'''Lines 2-4''': These set up your individual DEFNAME pieces. It says that color_blue is equal to 02, color_red is equal to 021, and color_green is equal to 041. You may have any number of spaces between the name and the value. The definitions contained in spheredefs.scp are among the most useful you will encounter, as they prevent you from writing the long scary numbers we went over in the previous section. These include things like names for flags, names for item attributes, names for the built-in MIDI or MP3 music, names for memory types, and many other things. Look through the file to see what it offers you.

That's about it for DEFNAMEs. You'll see more of these later as we cover other types of scripts.

Now go on to learn about items.

==ITEMDEF==
Or, how to make a mountain from a molehill, SPHERE style

Most people make item scripting much harder than it needs to be. For the purposes of this tutorial, since there is a more advanced one later, we will simply go over the basics of an ITEM script, line by line. We'll be using the gold script from the previous lesson, provided I can find it again....

Ah, here it is, conveniently color coded for your viewing pleasure!

<spherescript>[ITEMDEF 0eed]
//gold coin
DEFNAME=i_gold
TYPE=T_GOLD
VALUE=1
CATEGORY=Provisions - Miscellaneous
SUBSECTION=Coins
DESCRIPTION=Gold Coin
DUPELIST=0eee,0eef</spherescript>

This is the simplest of item scripts, since it has no additional behaviors beyond existing. I will go through this line by line, describing to you what each line does, and how it affects the end result.

'''Line 1''': [ITEMDEF 0eed]

The first lines of an item script are frequently the most important. Basically, this line tells the server "Hey this is an item and I want it to be called 0eed!" The server then looks through one of the client files (specifically art.idx), and identifies whether or not this item is one of the built-in items. I think all items below 04500 are defined as built-in items, so never define a new item in that range. By typing this line, you tell the server that an item script is following. You also define 0eed as a valid item, which will definitely help later on when you try to give gold to players!

'''Line 2''': // gold coin

This is the SPHERE version of comment. C programmers will recognize the format immediately. If you type // on any line of code, everything beyond that is ignored by the script reader. This can be on a line by itself, or at the end of a line to explain what the specific line does. In all cases, it won't affect your program, just make it easier to read.

'''Line 3''': DEFNAME=i_gold

You should know by now what this does! If you don't, go back and read the previous lesson! It tells the server that i_gold and 0eed mean the same thing. In item scripts, all parameters are defined in that format:

variable=value

You will see later on, when we get into scripting, how that format will help you more than you would believe. Items have a good number of variables that you can define, including:

* DEFNAME
* ID
* TYPE
* VALUE
* RESOURCES
Other variables depend on the value of the TYPE. Which leads us right into...

'''Line 4''': TYPE=t_gold

The first thing you might say is "What the heck is t_gold?" Well it's a DEFNAME. Actually it's a number. And that number is 72. If you want to check me on this, look in spheredefs.scp, it's there! Writing TYPE=72 would have the exact same effect.

There are, currently, 183 built-in item types. These are hardcoded item types that contain predefined actions for an item. If an item has no type, when you click it, you get the "You cannot think of a way to use that item" message. There is a complete list of types, and how to set them up, here . All you need to know for now is that setting the type of this item to t_gold has no effect other than to make the item act like a gold coin (i.e. you can buy stuff with it!) Setting another item to type t_gold would probably make the server think that you can buy stuff with that item too. I've never tried this. It might be an interesting way to have unique currencies...

'''Line 5''': VALUE=1

This defines how much the item costs when purchased, in gold. Of course, this is one gold piece, which is worth, well, one gold piece. So the value of the item is one.

'''Lines 6-8''': CATEGORY, SUBSECTION, DESCRIPTION

These are lines used only by SPHERE's GM tool, Axis, which actually saves you a lot of work by typing ".add i_gold" for you. More importantly, it types ".add 01737" and things like that for you, for items that were not important enough to get their own separate DEFNAME.

'''Line 9''': DUPEITEM

It would be a ton of work for the SPHERE team to define all 8000 items that came with the game, especially when many of them are the same. (For an example of this, use the .xflip command on a door or sign. It cycles through all of the DUPEITEMs for that the item being flipped.) The numbers listed here are item numbers, which probably have not been defined yet. Here is the script for item 0eee:

<spherescript>[ITEMDEF 0eee]
//gold coins
DUPEITEM=0eed
CATEGORY=Provisions - Miscellaneous
SUBSECTION=Coins
DESCRIPTION=Gold Coins</spherescript>

As you can see, there is only one parameter for this whole item. It reiterates the DUPEITEM and sends the server looking to our 0eed (or i_gold) item for more information, such as TYPE and VALUE. DUPEITEM only exists to save typing. You probably won't use it.

==CHARDEF==
Or, what it takes to make a naked man who can stand around and say "Huh?"

NPCs... They make the world go around. They are what makes UO a unique multiplayer game. The monsters and NPCs you create make your server unique from any other. This section of chapter one will cover how to create a simple naked man who walks around and says little more than "Huh?" (or "Stop thief!" if you tell him to!).

First of all, we'll look at the script for a simple naked man. I'm pulling this out of spherechar_human.scp.

<spherescript>[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</spherescript>

As you can see, it doesn't look a lot different than the item scripts we examined in the previous section. There are a lot of variables set that are the same, including DEFNAME, DESCRIPTION, and the other Axis variables.

But, there are a lot of new things here that we will again go over, one line at a time! And it's longer this time! Let the good times roll! (Sorry if you're not American.. All my American clichés are probably growing irritating!)

'''Line 1''': [CHARDEF 0190]

Surprise surprise! It's an identifier, telling the server that we are going to be defined a character between this and the next [identifier]. And we also tell it that our character, or NPC, will have the ID 0190. The server knows that this ID is one of the built-in IDs. In fact, it's the ID of a naked man. You also know that 0190 is hexadecimal is 400 in decimal right? :) Well why didn't you know that! Oh I'm just kidding, you don't need to know things like that.

'''Line 2''': DEFNAME=c_man

Nothing new here. c_man is now the same as 0190. Most character DEFNAMEs will begin with C and then an underscore (c_) like you see above.

'''Line 3''': Name=Man

Oh oh! Something new! Items come with default names, built in to the server. Characters don't. So we have to assign him a name. We can give him any name we want, but since this isn't a specific man, we just give him a name telling us what he is. In this case "Man".

'''Line 4''': ICON=i_pet_man

It took me a while to figure this one out. ICON defines what little picture you see when you're using the Tracking skill and all those little miniature creatures appear in the window. Those are actually items, all the i_pet items. To find out what the i_pet item for your creature should be, create him in the game using .addnpc, then use the .shrink command on him. The ID of the item that he becomes is your i_pet item.

'''Line 5''': CAN=mt_*

(In case you don't know, * means "anything" for those who use Linux.)

This is one of the most important lines of your character script, next to the ID we give him in the first line. First, because it allows us to tell the game what our NPC can do and what he can't do. There are only a few mt_* items, all of which are defined in spheredefs.scp. For the purpose of the lesson, I am going to copy them here. (The purple comments are mine.)

<spherescript>MT_NONMOVER 0 // We can't move at all
MT_GHOST 01 // We can walk through doors and such, like a ghost
MT_SWIM 02 // I can swim! (Water elementals, dolphins, etc)
MT_WALK 04 // I can move. Set this if you want your creature to move.
MT_FLY 010 // Moves through (supposed to be over) trees
MT_FIRE_IMMUNE 020 // Immune to damage by fire. Setting this on a player is bad. :)
MT_EQUIP 00100 // Can equip things
MT_USEHANDS 00200 // Can use his hands to carry things (or open doors)
MT_MALE 0 // Is a male
MT_FEMALE 00800 // Is a female
MT_NONHUM 01000 // Non-human. I'm not sure what this does.
MT_RUN 02000 // Can move really fast!</spherescript>

According to this chart, we can see that if we don't give a creature a CAN flag, it will be an MT_MALE and an MT_NONMOVER (the two zeros). You can see from the example that by putting a | (found by pressing shift+backslash) between two CAN flags, we can give him more than one. In this case, we allow our man to equip things, walk, run, and use his hands. (An interesting fact is, even creatures that don't have hands can be set to use their hands, thus allowing them to carry light sources. Fire elementals do this. That's how they glow.)

'''Line 6''': RESOURCES

Resources is a very morbid name for this setting. Especially for a person. These are the items that you get whenever you chop up this creature's corpse. Scary eh? :)

'''Line 7-10''': FOODTYPE, DESIRES, AVERSIONS

'''FOODTYPE''': Defines what kind of food the npc will eat and if NPC_AI_FOOD is on it'll make the npc look for this food + grass when he's hunger.

'''DESIRES''': Defines what kind of items will the npc be interested in, if NPC_AI_EXTRA is on it'll show what items the npc will loot of players corpses or walk towards when it's on the ground.

'''AVERSIONS''': No idea, but I think it tells the npc what sort of NPCs he'll try to fight, for example: I have a horse with e_horse as an event, and an imp without any events, if the npc has AVERSIONS=e_horse it'll prefer to fight the horse.

'''Line 11''': BLOODCOLOR

Ever wanted to make your players have green blood? This is where you do it! A color number or a color defname will work fine. (Try to learn the numbers for common colors, it makes it so much easier.)

The rest of it: TSPEECH and TEVENTS

We're going to cover these in sections of their own. They are probably the most complex topics in scripting! (How many times do you suppose I'm going to say that before it's actually true?)

''Some other things:''

On 56B we have some other fields like MOVERATE,RESLEVEL,RESDISPDNID and RESDISPDNHUE. They sound some difficult and strange thing but they aren't. Here's the explanation for them:

'''MOVERATE''': This setting (that can only be writed at the npc chardef) controls how fast the npc moves. The smaller the value, the faster the npc is. For example, if I have a horse chardef with default moverate (100) and another with moverate=60, the one with 60 will walk and run a lot faster than the other horse. This is great for making really difficult monsters to kill.

'''RESLEVEL''': This tells sphere what version of uo this monster is from, for example, a Wanderer of the Void will have RESLEVEL=3 (3=AOS) (see sphere_defs.scp for a complete list), so only accounts with RESDISP 3 or bigger can see this monster as he really is.

''NOTE'': If you set a lower value for RESLEVEL, if the player doesn't have this npc anim he'll crash.

'''RESDISPDNID''': As you probably have seen, I used a lot of "as he really" is, exactly because of this setting, this tells the client what monster will the player see instead of the correct one. For example, this Wanderer of the Void will show as Wanderer of the Void for those who has ACCOUNT.RESDISP=3 or bigger, but for those who has smaller values it'll show as a c_spectre (if you so define).

'''RESDISPDNHUE''': This defines what color will the player see the monster if the RESDISPDNID id is shown to him (have an account.resdisp lower than the reslevel of this char)

Here's an example for those new settings:

<spherescript>[CHARDEF 310]
DEFNAME=c_Wailing_Banshee
NAME=Wailing Banshee
SOUND=snd_monster_zombie1
ICON=i_pet_wailingbanshee
DAM=11,16
RESDISPDNID=c_spectre
RESLEVEL=3
RESDISPDNHUE=01
ARMOR=20
CAN=MT_WALK|MT_FLY
DESIRES=i_gold,e_notoriety,e_horses,c_man,c_woman,t_corpse
CATEGORY=New Monsters
SUBSECTION=AOS
DESCRIPTION=Wailing Banshee

ON=@Create
NPC = brain_monster
FAME = {100 3000}
KARMA = {-5000 -6999}
STR = {126 166}
INT = {86 115}
DEX = {41 75}
MAGICRESISTANCE = {75.0 95.0}
TACTICS = {45.0 75.0}
WRESTLING = {50.0 70.0}

ON=@NpcRestock
ITEM = i_gold, {50 100}
ITEM = i_reag_daemon_bone, {2 6}</spherescript>

And there you have it. A simple character script and some new things. Read the chapter that is all about making NPCs later in the tutorial.

==TEMPLATE==
Or, how to put great laggy quantities of items into one unlaggy container.

You've all seen it. Those shards out there that don't use TEMPLATEs. When you kill, say, a dragon, on those shards, and go to loot him, you find that rather than neatly organized containers, there are 100 potions scattered about the loot window. Not only that, but all your magical weapons are buried neatly beneath them!

How do we solve this problem? Well, SPHERE has given us the handy tool of TEMPLATEs. These allow you to define a container item, AND the items inside of it, AT THE SAME TIME. Isn't that neat? I thought so too, when I first figured out what they were. Let's do our traditional take-apart-the-script section. I'll place a nice TEMPLATE from the file spheretemp_loot.scp.

<tt>[TEMPLATE 101505] 
DEFNAME=backpack_poor 
CATEGORY=Item Templates 
SUBSECTION=Loot Templates 
DESCRIPTION=Poor Backpack 
CONTAINER=i_backpack 
ITEM={ random_food 1 0 3 },{ 1 3 } 
ITEM={ random_bottle 1 0 8 } 
ITEM={ random_light 1 0 8 } 
ITEM={ random_male_tops 1 0 4 } 
COLOR=colors_all 
ITEM={ random_male_pants 1 0 4 } 
COLOR=colors_all 
ITEM=POOR_GOLD_PILE </tt>

Wow, that looks confusing. But don't worry, by the time we're done, you'll know exactly what it means!

[TEMPLATE 101505]: First of all, we look at the header for our template. An interesting thing about templates is that the item name cannot be a DEFNAME like all other scripts. It must be a ridiculously high number like 101505.

DEFNAME=backpack_poor: Of course, SPHERE developers are not entirely evil, and have provided us with the ability to give these scary numbers a DEFNAME for easier access. You tell me, which would you rather type? ".add 101505" or ".add backpack_poor"? I thought so.

CATEGORY, SUBSECTION, DESCRIPTION: Axis crap. Optional. See the previous sections for a description of what these do.

CONTAINER=i_backpack: Ahh, now we're getting down to the meat of this thing. This specifies the holding container that all other items in this template will be in. When you add the item in game, you will see this container. In this case, it's a backpack. Simple enough. This can be any valid item with a TYPE of t_container or t_container_locked.

ITEM={ random_food 1 0 3},{1 3} Well, that's certainly cryptic. I think we need to break this line down even further.

But first, we're going to cover RANDOM SELECTORS! Sounds like fun doesn't it? Nah, it doesn't sound fun to me either, but it's absolutely necessary to a good shard.

Basically, they are an easy way to get different numbers with one command. What fun would a shard be where you killed a dragon and got a Platemail of Magic Stuff and a Super Duper Sword of Power every single time? Everyone would be running around with them. What we need is some variety!

There are two types of random selectors: weighted random and ranged random. Weighted random makes a statement like this: "Ok, 1 out of 10 times pick Number A, 3 out of 10 times pick Number B, and 6 out of 10 times pick number C". Ranged random makes a statement like this: "Pick any number between the two numbers I give you".

Our example actually has an example of both ranged random and weighted random. We'll cover them in the order they appear:

{ random_food 1 0 3}

This is a weighted random selector. The way to interpret these is to take the numbers that appear between the parentheses and divide them into sets of two:

random_food 1 
0 3

Add up the second numbers in both sets, and we get 4. This tells SPHERE, "Ok, 1 out of four times, I want you to pick random_food, and 3 out of four times, I want you to pick zero." You can even have random sets within random sets, but then it just gets confusing.

{ { random_food 1 0 3} 1 random_clothing 1}

Can you figure it out?

random_clothing 1
{ random_food 1 0 3} 1

2 is our magic number in this case. One out of two times, SPHERE will pick random_clothing, and one out of two times, SPHERE will pick our previous random selector, which will then select one of its own options. If you're confused at this point, don't worry. This is extremely rare, and we'll see in a moment how templates help us to solve this problem.

I did mention, though, that there is another type of random selector, and you can probably see what it is:

{1 3}

NOTE: Spacing here is important. There must be ZERO spaces between the { and the first number, or the } and the last number. It will behave strangely otherwise.

This tells SPHERE "Pick a number between 1 and 3, inclusive". Inclusive means that SPHERE can pick 1, 3, or any number in between. In this case, the range is rather limited. SPHERE will give you a 1, 2 or 3 here. Ranged random selectors are actually more often used inside of weighted random selectors.

{ {1 3} 3 {4 9} 1}

"One out of four times, pick a number between 4 and 9. Three out of four times, pick a number between 1 and 3."

And with that out of the way, we're going to analyze the actual line of the script from above. The Piece What the Line does ITEM=
This tells the script "Ok, we're going to add an item to this container. Anything after the = tells the script exactly what it is we're adding and in what amounts. You could easily say ITEM=i_platemail_chest, or something like that, without the mysterious { } sections, but the reason templates are interesting is because they can vary greatly.

{ random_food 1 0 3}

This is the item you will be creating. As we can see from our weighted random selector lesson, 1 out of 4 times, it will be random_food, and 3 out of 4 times, it will be zero. If an ITEM is zero, nothing will be created this time. Basically this is saying "There will be a one in four chance of getting random_food in this container." What is random_food you ask? Well, it happens to be another TEMPLATE, defined in spheretemplate.scp, I believe.

{1 3} This is the amount of the item that will be created. You should recognize this as a ranged random selector. This tells SPHERE to put between 1 and 3 of this item into the container. Of course, if the item is zero as selected above, this has no effect since one nothing and three nothings are still nothing.

So basically, that is a template script. You then fill it with as many items as you want. You may also notice the following construction:

ITEM=i_sword_long,R11

This is a shorthand way of writing this:

ITEM={ i_sword_long 1 0 10 }

R11 means "one out of 11 chance of finding this item". And you can add an amount selector to the end of that as well, which makes it look long and scary:

ITEM=i_sword_long,R11,{4 5}

But why would you want 4 or 5 long swords in one item? That would be bizzare. :)

And that's about it for templates. Congratulations, you're finished with chapter 1. Now you should be able to understand the examples to follow on the next section. You may also have some questions which are addressed in the common questions area. If you have a question which is not addressed there, perhaps it is too advanced of a topic for chapter 1. I assure you almost every aspect of SPHERE scripting will be covered in later chapters.

''(A template example by Belgar)''

<tt>[TEMPLATE tm_necromancer] 
CONTAINER=i_bag 
ITEM=random_necro_scroll 
ITEM=random_necro_scroll 
ITEM=random_necro_reagent, {5 12} 
ITEM=random_reagent, {5 12} 
ITEM=random_necro_reagent, {5 12} </tt>

==Examples==
Or, um. Well I guess there really isn't another way to say "Examples".

This shall be my attempt to create the most basic new items available. You will see things in these examples that are NOT mentioned in the tutorials. The major factor will be ON=@Create, which is the primary topic of Chapter 2. Just know for now that things you can change in game (color, etc) must go under ON=@Create.

'''Example 1''': A Red Sword

<tt>[ITEMDEF i_sword_red] 
ID=i_sword_viking 
TYPE=t_weapon_sword 
NAME=The Red Sword 
CATEGORY=Weapons 
SUBSECTION=New Swords 
DESCRIPTION=Red Sword 

ON=@Create
:COLOR=colors_red // This is a comment. Comments are ignored by SPHERE. </tt>

Wait, what is this weird // thing we've got going here? That's called a comment. It's completely ignored by SPHERE, so you can write whatever you want to the end of the line after //. You cannot have multi-line comments in SPHERE unless you use a new //, so don't even try it. SPHERE will give funky errors and then you'll have fun finding them.

'''Example 2''': A blue ettin

<tt>[CHARDEF c_ettin_blue] 
ID=02 // You could just as easily use c_ettin here. 
NAME=My Blue Ettin 
 
 
ON=@Create 
:COLOR=02 // This is a dark blue color. It's often used for Counselor robes. Remember it. </tt>

'''Example 3''': A template from the file, since I'm too lazy to write one myself

<tt>[TEMPLATE 101521] 
DEFNAME=goodie_meager_1 
CATEGORY=Item Templates 
SUBSECTION=Loot Templates 
DESCRIPTION=Meager Goodie 1 
ITEM={ meager_gold_pile 1 backpack_meager 1 pouch_meager 1 } 
ITEM={ random_boots 1 0 4 } 
ITEM={ random_gorget 1 0 4 } 
ITEM={ random_staff 1 0 4 } 
ITEM={ random_necklace 1 0 4 } 
ITEM={ i_cape 1 0 9 } 
COLOR=colors_all </tt>

You may notice something new here (especially since I highlighted it in red), and yes, it is legal. Any lines between ITEM= lines will affect the previously created item. The COLOR= line here affects the ITEM created by the line

ITEM={ i_cape 1 0 9 }

Remember, the best way to learn this type of scripts is to read the scripts provided for you in files like sphereitem_colorarm.scp and sphereitem_beers.scp.

[[Category:Tutorials]]

De:Chapter 1

2011-03-09T07:17:08Z

Sirius: /* TEMPLATE */

De:Chapter 1

2011-03-08T19:52:26Z

Sirius: /* CHARDEF */ Uebersetzung und kleine Tippfehlerkorrektur

{{Languages|Chapter_1}}

==Zahlen==

Als erstes wird die verschiedenartige Art und Weise zur Verwendung von Zahlen innerhalb der Sphere Skripte behandelt. Da Zahlen naturgemäß sehr wichtig für einen Sphereskripter sind, ist dies der erste Abschnitt überhaupt. Am Ende dieser Einheit wird hoffentlich jeder über ein allgemeines Verständnis über hexadezimale, dezimale und binäre Zahlensysteme und die Verwendung in Sphere Skripten besitzen. Zudem wird noch vermittelt, wie einerseits Zufallszahlen innerhalb eines Zahlenbereichs oder aus einer Liste von Zahlen generiert werden können.

Es muss zunächst verstanden werden: wie wir zählen ist nicht die einzige Art zu zählen. Unser Zahlensystem enthält zehn Ziffern (0, 1, 2, 3, 4, 5, 6, 7, 8, und 9). Ab der zehnten Zahl wird eine weitere Ziffer angehängt und die letzte Stelle auf 0 gesetzt (1, 2, 3, 4, 5, 6, 7, 8, 9, 10). Deshalb funktioniert unser Zahlensystem wie es funktioniert.

Im Dezimalsystem, ohne dass wir davon Notiz nehmen, schreiben wir diese Zahlen immer als Zehnerpotenzen. Beispielsweise die beliebige Zahl 17282 aufgeteilt in Zehnerpotenzen:

{| border="1"
| Zehnerpotenz || 4 || 3 || 2 || 1 || 0
|-
| 10 hoch Zehnerpotenz || 10000 || 1000 || 100 || 10 || 1
|-
| Ziffer || 1 || 7 || 2 || 8 || 2
|}

Um zur Zahl 17282 zu gelangen, wird immer 10 hoch Zehnerpotenz mal der Ziffer in der untersten Zeile berechnet und am Ende alle Ergebnisse addiert. Das Ergebnis: 10000 + 7000 + 200 + 80 + 2. Offensichtlich ist das sehr einfach und jeder tut das ständig ohne davon Notiz zu nehmen. Du fragst dich sicherlich jetzt "Richtig, warum schrieb Taran das alles?" Die Sache ist die, dass unser Zahlensystem nicht das einzige ist.

Computer zählen beispielsweise komplett anders. Sie kennen nur zwei Ziffern (1 und 0) und das wird dann Binärsystem genannt. Binäre Zahlen sehen beispielsweise so aus: 101011101101. Oftmals tauchen sie in der Werbung für Computer auf. Ziffern im Binärsystem werden Bit genannt (kurz für BInary digiT). Binärzahlen im Kopf zu Dezimalzahlen zu berechnen ist meist nicht ohne weiteres möglich, hierfür braucht es ein wenig Mathematik.

Binärsysteme funktionieren wie Dezimalsysteme, es wird eine Potenz einer Zahl addiert. Da Binarzählen nur aus zwei Ziffern bestehen, handelt es sich hierbei um Zweierpotenzen. Manchen wird die folgende Tabelle sicher bekannt vorkommen:

{| border="1"
| Zweierpotenz || Binärzahl || Dezimalzahl
|-
| 0 || 1 || 1
|-
| 1 || 10 || 2
|-
| 2 || 100 || 4
|-
| 3 || 1000 || 8
|-
| 4 || 10000 || 16
|-
| 5 || 100000 || 32
|-
| 6 || 1000000 || 64
|-
| 7 || 10000000 || 128
|-
| 8 || 100000000 || 256
|-
| 9 || 1000000000 || 512
|-
| 10 || 10000000000 || 1024
|}

Spannend oder? :)

Wir brauchen ein besseres System! Der Grund, dass seltsame Ergebnisse auftreten, liegt daran, dasss 10 keine Potenz von 2 ist. Wir brauchen deshalb ein System, das eine Zweierpotenz als Basis hat. Das am meisten genutzte System ist ein 16er System, auch hexadezimal genannt. Im Sphere-Forum sieht man das Wort hex sicherlich an der ein oder andren Stelle, das ist kein Fluch und auch kein böser Zauber. Es ist eine Kurzform für "hexadecimal".

{| border="1"
| Binär || Dezimal || Hexadezimal
|-
| 1 || 1 || 1
|-
| 10 || 2 || 2
|-
| 11 || 3 || 3
|-
| 100 || 4 || 4
|-
| 101 || 5 || 5
|-
| 110 || 6 || 6
|-
| 111 || 7 || 7
|-
| 1000 || 8 || 8
|-
| 1001 || 9 || 9
|-
| 1010 || 10 || A
|-
| 1011 || 11 || B
|-
| 1100 || 12 || C
|-
| 1101 || 13 || D
|-
| 1110 || 14 || E
|-
| 1111 || 15 || F
|-
| 10000 || 16 || 10
|}

Ersichtlich, wie das funktioniert? Es gibt sechs Ziffern, die zusätzlich am Ende des Systems herangezogen werden müssen, es werden üblicherweise hierfür die ersten 6 Buchstaben des Alphabets verwendet.

Innerhalb von Sphere Skripten wird beinahe NIE mit Binärzahlen gearbeitet, die KEINE Potenz von zwei sind und wenn, dann kann jeder herkömmliche Taschenrechner benutzt werden, um sie umzurechnen. Mit Hexadezimalzahlen ist das um einiges einfacher.

(This is the last table, I promise!!)
{| border="1"
| Binär || Hexadezimal
|-
| 000000001 (1) || 01
|-
| 000000010 (2) || 02
|-
| 000000100 (3) || 04
|-
| 000001000 (4) || 08
|-
| 000010000 (5) || 010
|-
| 000100000 (6) || 020
|-
| 001000000 (7) || 040
|-
| 010000000 (8) || 080
|-
| 100000000 (9) || 0100
|}

Wie in der Tabelle ersichtlich gibt es ein Muster in der Hexadezimalspalte. Man könnte meinen, dass da ein Muster in den Zahlen 1, 2, 4 und 8 auftritt. Das stimmt auch. Ein weiteres Detail sind die führenden 0en für Hexadezimalzahlen (0100 statt nur 100). In Sphere bedeutet eine solche führende 0: "Diese Zahl ist eine Hexadezimalzahl!" und dementsprechend sind 100 und 0100 völlig verschiedene Zahlen.

Angenommen in einem Sphere Skript wird das 13. bit in einer Zahl benötigt (FLAGS beispielsweise), dann würde so etwas verwendet werden:

'''SRC.FLAGS |= 8192'''

Allerdings: merkt man sich wirklich, dass 8192 das Ergebnis von 2 hoch 13 ist? Das tut man nicht, es ist viel einfacher diese Liste durch zu gehen, bis man zur 13. Zahl kommt (wichtig: Zählen beginnt immer bei 0!).

{| border="1"
| 01 || 02 || 04 || 08 || 010 || 020 || 040 || 080 || 0100 || 0200 || 0400 || 0800 || 01000 || 02000
|-
| 2^0 || 2^1 || 2^2 || 2^3 || 2^4 || 2^5 || 2^6 || 2^7 || 2^8 || 2^9 || 2^10 || 2^11 || 2^12 || 2^13
|}

Und hier sind sie: die ersten 14 Zweierpotenzen in Hexadezimal.

'''SRC.FLAGS |= 02000'''

Diese Zeile ist identisch zur obigen, nur dass 8192 (dezimal) GLEICH 02000 (hexadezimal) ist.

'''8192 = 02000'''

Nun könnte man sagen "Wie weiß ich, dass das nicht frei erfunden ist?". Nunja, schon der windowseigene Microsofttaschenrechner beherrscht die Umrechnung zwischen Binär-, Hexadezimal-, Dezimal und Oktalzahlen (ein weiteres, aber in Sphere nutzloses Zahlensystem). Der Taschenrechner von Windows befindet sich im Startmenü unter Programme im Zubehör. Im Taschenrechner wird im Menü Ansicht auf Wissenschaftlich umgestellt. Die Oberfläche des Taschenrechners verändert sich dann ziemlich. Um damit eine Zahl zwischen den Systemen umzurechnen, muss nur die originale Zahl eingegeben werden und dann kann zwischen den verschiedenen Zahlensystemen (Hex, Dez, Okt, Bin) umgeschaltet werden. Eine 0 vorne an eine Hexadezimalzahl gehängt und Sphere interpretiert sie als auch als eine hexadezimale Zahl.

Das war vermutlich das schwierigste in allen Sphere Skripten. Glücklicherweise, wegen des nächsten Abschnitts, muss sich ab jetzt niemand mehr mit angsteinflössenden Zahlen beschäftigen. Wenn du nach dieser Einheit noch dabei bist, wird sicher alles gut!

Weiter gehts mit: Skripten für Sphere!

==Defnames==

Hier eine Liste angsteinflössender Zahlen, die man innerhalb von Sphere Skripten antrifft:

{| border="1"
| angsteinflössende Zahl || Was sie bedeutet
|-
| 0eed || ID einer Goldmünze
|-
| 0dda || ID eines roten Moongates
|-
| 1650,1440 || Koordinaten von Britain
|-
| 021 || Farbcode für die Farbe "rot"
|-
| 04000 || Farbcode für unsichtbar
|-
| 04000efad || Eindeutige serielle Nummer eines Gegestands
|-
| 4 || Das PLEVEL eines GMs
|-
| 2048 (oder 0800) || Flag für den Unsichtbarkeitszauber
|-
| 010 (oder 16) || Memory type für Aggressoren
|}

Offensichtlich will solche Zahlen niemand auswendig kennen. Aber in frühesten Versionen, weit vor Sphere und TUS (vor .50 Sphere) und tief im Nebel von Grayworld (vor .41 TUS), musste jeder Skripter diese Zahlen kennen. Ich kenne diese Zahlen (ausser die serielle Nummer, die frei erfunden ist) und noch ein paar weitere, allesamt in- und auswändig. Glücklicherweise hat sich für jeden, der nicht gern Zahlen auswendig lernen will, Sphere dazu entwickelt, dass Namen statt Zahlen verwendet werden können.

Zwar wird alles mögliche immer noch mit Zahlen verknüpft, aber diese Zahlen sind mittlerweile mit Namen verknpft worden.

Gib im Spiel .add 0eed ein und drücke die Returntaste. Ein Zielcursor taucht auf und es kann eine Goldmünze erschaffen werden.

Nun gib .add i_gold ein und drücke Return. Es passiert genau das selbe.

Natürlich kann man sich i_gold leichter als 0eed merken. Aber wie funktioniert das? Dazu muss die Skriptdefinition von einer Goldmünze angesehen werden. Dieses Skript muss an dieser Stelle noch nicht verstanden werden, Itemskripte werden später genauer behandelt. Dieser Skriptausschnitt findet sich in der Datei sphere_item_resources.scp.

<tt>[ITEMDEF 0eed] 
//gold coin 
DEFNAME=i_gold 
TYPE=T_GOLD 
VALUE=1 
CATEGORY=Provisions - Miscellaneous 
SUBSECTION=Coins 
DESCRIPTION=Gold Coin 
DUPELIST=0eee,0eef </tt>

Die rot markierte Zeile ist für diese Lektion von Belang. Ansonsten ist noch die erste Zeile, die 0eed enthält, interessant, aber der Rest kann getrost ignoriert werden vorerst. Die 0eed ist die Nummer des Items, diese Nummern werden im nächsten Abschnitt behandelt.

Wirklich interessant ist allerdings DEFNAME=i_gold. Diese Zeile legt im Server fest: "Ab jetzt wird 0eed mit i_gold identifiziert". Wird vor dieser Zeile irgendwo innerhalb eines Skripts i_gold verwendet, wird der Server einen Fehler melden (siehe [[Chapter 2|Kapitel 2]] über die Reihenfolge von Skripten), aber jetzt ist ihm bekannt, worauf i_gold verweist und es kann in Skripten oder im Spiel frei verwendet werden.

Es sollte IMMER ein solcher Name mit DEFNAME erstellt werden, wenn ein Item geskriptet wird. Normalerweise wird dieser defname in [ITEMDEF] selbst festgelegt (mehr darüber später), aber wenn unbedingt Zahlen verwendet werden sollen, sollte zudem noch ein einfach zu zu merkender Name verwendet werden (bspw nicht goldenes_gulasch für ein Schwert). Es macht das Leben einfacher, als Zahlen zu benutzen.

Eine zweite Möglichkeit, DEFNAME zu nutzen, ist die Nutzung eines [DEFNAME]-Abschnitts. Hier ein Beispiel dafür:

<tt>[DEFNAME colors] 
color_blue 02 
color_red 021 
color_green 041 </tt>

Ein ähnliches Skript steht in spheredefs.scp, eine weitere Datei, die ganz am Anfang geladen werden sollte.

Hier eine Aufschlüsselung dieses Skripts, Zeile für Zeile:

'''Zeile 1''': Hier wird der Typ des Skripts festgelegt und der Name dafür (Colors in diesem Fall). Hier wird dem Server vermittelt, dass von dieser Zeile bis zum nächsten Identifier (das sind die Zeilen die von eckigen Klammern eingerahmt sind) eine bestimmte Art von Skript enthalten ist. Alle Identifier haben dieses Format. Der erste Parameter legt dabei den Skripttyp fest und davon gibt es mehrere, die in den weiteren Kapiteln abgehandelt werden. Der zweite Parameter ist entweder eine Zahl als ID oder ein Defname. In den meisten Fällen wird in selbst geschriebenen Skripten wird hier ein Defname stehen. Die einzige Ausnahme besteht dann, wenn neue Items in die Clientdateien eingefügt werden.

'''Zeilen 2-4''': Diese Zeilen enthalten individuelle Teile. Es wird festgelegt, dass color_blue gleich 02, color_red gleich 021 und color_green gleich 041 ist. Zwischen dem Namen und dem Wert können beliebig viele Leerzeichen enthalten sein. Die Definitionen in spheredefs.scp sind so ziemlich die nützlichsten auf die man treffen kann, da sie es unnötig machen, viele angsteinflössende Zahlen zu verwenden. In spheredefs.scp werden deshalb Namen für Flags, für Attribute von Items, für verschiedene Töne und Klänge, für Memory Types und viele andere Dinge festgelegt. Einen Blick in diese Datei zu werfen ist sicherlich zuweilen ganz ratsam.

Das wars mit DEFNAMES. Weiteres taucht später in allen möglichen Skripten auf.

Jetzt werden Items abgehandelt.

==ITEMDEF==
Oder: wie macht man aus einem Maulwurfshügel einen Berg auf Sphere-Art.

Die meisten machen sich Itemskripte schwieriger, als es nötig ist. Für die Zwecke dieses Tutorials, da es noch ein weit fortgeschritteneres später gibt, werden hier nur einfach die Grundlagen eines ITEM Skripts behandelt, Zeile für Zeile. Wir werden das Goldskript vom vorherigen Absatz verwenden, vorausgesetzt ich finde es ...

Ok, hier ist es, mit Farbe unterlegt, damit es schöner anzusehen ist!

<spherescript>[ITEMDEF 0eed]
//gold coin
DEFNAME=i_gold
TYPE=T_GOLD
VALUE=1
CATEGORY=Provisions - Miscellaneous
SUBSECTION=Coins
DESCRIPTION=Gold Coin
DUPELIST=0eee,0eef</spherescript>

Das ist das einfachste aller Itemskripts, da es kein weiteres Verhalten hat und nichts anderes macht ausser einfach nur zu existieren. Es wird nun jede Zeile erklärt und was es damit auf sich hat:

'''Zeile 1''': [ITEMDEF 0eed]

Die erste Zeile eines Itemskripts ist die wichtigste. Grundsätzlich bedeutet diese Zeile für den Server "Hey, das ist ein Item und es soll 0eed heißen!". Der Server sieht sich dann die Clientdateien an (vor allem art.idx), und gleicht ab, ob das Item eins der eingebauten ist. Ich glaube, alle Items mit Nummern unter 04500 gelten als eingebaut, deshalb sollte nie ein neues Item mit einer Zahl definiert werden, die darunter liegt. Bei Eingabe dieser Zeile, wird der Server wissen, dass ein Itemskript folgt. Außerdem wird 0eed als gültiges Item festgelegt, was später nützlich ist, wenn die Spieler Gold brauchen!

'''Zeile 2''': // gold coin

Das ist die Sphereversion eines Kommentars. C-Programmierer kennen das Format (Anmerkung des Übersetzers: eigentlich kennt man das erst ab C++). Jede Zeile, die mit // beginnt ist eine Kommentarzeile und alles, was in einer Kommentarzeile enthalten ist, wird nicht vom Server interpretiert oder gelesen. Diese Kommentare können aber auch an beliebiger Stelle innerhalb einer Zeile beginnen um am Ende einer Zeile eine Erklärung einzufügen. Auf jeden Fall sind Kommentare nicht für die Funktion des Skriptes relevant, sondern können sie unter Umständen verständlicher machen.

'''Zeile 3''': DEFNAME=i_gold

Du solltest jetzt wissen, was diese Zeile bedeutet. Wenn nicht, dann sollte die vorherige Einheit nochmal wiederholt werden. Es legt im Server fest, dass i_gold und 0eed das selbe sind. In Itemskripten sind alle alle Parameter nach diesem Format spezifiziert:

variable=wert

Später, wenn es um Skripte geht, wird ersichtlicher, dass dieses Format sehr hilfreich ist. Items haben einige Variablen, die belegt werden können, unter anderem:

* DEFNAME
* ID
* TYPE
* VALUE
* RESOURCES
Andere Variablen sind wiederum vom Wert von TYPE abhängig.

'''Zeile 4''': TYPE=t_gold

"Was ist t_gold?" Auch das ist nur ein DEFNAME. Also eine Zahl, in diesem Fall 72. In spheredefs.scp steht diese Zahl, also hätte TYPE=72 den selben Effekt.

Momentan gibt es 183 eingebaute Itemtypen. Sie sind hardcoded (=fest in Sphere implementiert) und enthalten vordefinierte Verwendungszwecke für einen Gegenstand. Hat ein Gegenstand keinen Typ, dann erhält man eine "You cannot think of a way to use that item"-Nachricht, wenn man im Spiel das Item anklickt. Es gibt eine vollständige Liste von Itemtypen und wie sie genutzt werden. Der Typ t_gold hat nur einen Effekt: der Gegenstand wird behandelt wie eine Goldmünze (d.h: es können damit Dinge gekauft werden!). Andere Gegenstände den Typ t_gold zu geben würde den Server dazu veranlassen auch diese Dinge als Währung heran zu ziehen. Ich habe das nie versucht, aber es könnte eine interessanter Weg sein einzigartige Währungen zu haben ...

'''Zeile 5''': VALUE=1

Diese Zeile legt fest, wie viel ein Item wert ist, wenn es gekauft wird - in Gold. Natürlich ist eine Goldmünze eine Goldmünze wert, deshalb wird der Wert hier auf 1 gesetzt.

'''Zeilen 6-8''': CATEGORY, SUBSECTION, DESCRIPTION

Diese Zeilen werden nur von Spheres GM-Tool, Axis, benutzt, das es unnötig macht, im Spiel ".add i_gold" einzugeben. Wichtiger noch, es übernimmt solche Aufgaben auch für Items, die keinen DEFNAME haben, sondern nur eine Nummer.

'''Zeile 9''': DUPEITEM

Es wäre viel Arbeit für das Sphereteam alle 8000 Items im Spiel zu definieren, vor allem, wenn viele eigentlich ein und das selbe sind. (Beispielsweise kann eine Tür mit dem Befehl .xflip gedreht werden. Dieser Befehl läuft durch alle DUPEITEMS, die für ein Item angegeben sind.) Die Liste von Nummern sind Itemnummern, die vielleicht noch nicht definiert wurden. Hier wäre das Skript für 0eee:

<spherescript>[ITEMDEF 0eee]
//gold coins
DUPEITEM=0eed
CATEGORY=Provisions - Miscellaneous
SUBSECTION=Coins
DESCRIPTION=Gold Coins</spherescript>

In diesem Skript gibt es nur einen Parameter für das Item. Es verweist den Server auf das DUPEITEM, das unter 0eed (oder i_gold) angelegt wurde, um die Informationen von dort, wie TYPE und VALUE zu verwenden. DUPEITEM spart Tipparbeit, wahrscheinlich wird es selten benutzt.

==CHARDEF==
Oder was es braucht, einen nackten Mann zu machen, der rumstehen und "Huh?" sagen kann.

NPCs machen die Welt lebendig. Sie sind das, was UO zu einem einzigartigen Multiplayer Spiel macht. Die Monster und NPCs die du skriptest machen den Server einzigartig im Vergleich zu jedem anderen. Dieser Abschnitt des ersten Kapitels wird beinhalten, wie ein einfacher nackter Mann geskriptet wird, der herumwandern und ein wenig mehr als "Huh?" (oder "Halt Dieb!", wenn man so will) sagen kann.

Als erstens sehen wir uns das SKript eines einfachen nackten Mannes an. Es befindet sich in spherechar_human.scp.

<spherescript>[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</spherescript>

Wie ersichtlich sieht es sehr viel anders aus als die Skripte der vorherigen Abschnitte. Es werden eine ganze Menge an Variablen gesetzt, die gleich sind wie der DEFNAME, DESCRIPTION und die anderen Axis Variablen.

Aber es gibt auch eine Menge neuer Dinge hier, die der Reihe nach und Zeile für Zeile betrachtet werden! Und es ist länger diesmal! Let the good times roll! (Entschuldigung an alle Nichtamerikaner, alle amerikanischen Cliches sind vermutlich irritierend!)

'''Zeile 1''': [CHARDEF 0190]

Überraschung! Ein Identifier, der dem Server mitteilt, dass hier ein Charakter bis zum zum nächsten Identifier definiert wird. Und zudem wird für diesen Charakter bzw. NPC die ID 0190 gesetzt. Der Server kennt diese ID, da es eine eingebaute ist. In der Tat gehört diese ID zum nackten Mann. Des weiteren steht 0190 als hexadezimale Zahl natürlich für 400, nicht wahr? :) Warum weißt du das nicht? OK, nur ein Witz, das muss man natürlich nicht wissen.

'''Zeile 2''': DEFNAME=c_man

Nichts neues. c_man entspricht hiermit 0190. Die meisten DEFNAMES für Charaktere beginnen mit c und dann folgt ein _ wie oben.

'''Zeile 3''': Name=Man

Hier ist etwas neues. Items haben einen vorgegebenen Namen, der im Server bekannt ist. Charaktere nicht. Deshalb muss ein Name zugewiesen werden. Es kann im Grunde jeder Name zugewiesen werden, den man hier haben möchte, aber da das kein spezifischer Mann ist, heißt er einfach nur Man.

'''Zeile 4''': ICON=i_pet_man

Ich brauchte eine Weile, um das herauszufinden. ICON legt ein kleines Bildchen fest, das man bei benutzung des Tracking Skills sieht und diese kleinen ICONs tauchen im Menü dort auf. Eigentlich sind diese Bildchen Items. Um herauszufinden, wie dieses Bildchen aussieht, kann der Mann einfach im Spiel mit .addnpc c_man erstellt werden und dann der .shrink Befehl auf ihn angewendet werden. Die ID dieses Items wird dann zum i_pet Item.

'''Zeile 5''': CAN=mt_*

(Falls * nicht bekannt ist: * heisst "alles mögliche" für diejenigen, die Linux nutzen.)

Das ist eine der wichtigsten Zeilen im Character Skript, neben der ID die in der ersten Zeile vergeben wird. Sie lässt uns festlegen, was ein NPC tun kann und was nicht. Es gibt nur ein paar wenige Möglichkeiten für mt_*, die alle in der spheredefs.scp definiert sind. Für unsere Zwecke sind sie hier hin kopiert worden.

<spherescript>MT_NONMOVER 0 // Kann ueberhaupt nicht laufen
MT_GHOST 01 // Kann wie ein Geist durch Tueren und aehnliches laufen
MT_SWIM 02 // Ich kann schwimmen! (Wasser Elementare, Delphine, etc)
MT_WALK 04 // Ich kann laufen! Setze dies wenn deine Kreatur laufen koennen soll.
MT_FLY 010 // Laeuft durch Baeume (soll das darueber Fliegen darstellen)
MT_FIRE_IMMUNE 020 // Ist gegen Feuer Immun. Das sollte man nicht auf einen Spieler setzen. :)
MT_EQUIP 00100 // Kann Sachen anlegen (equip).
MT_USEHANDS 00200 // Kann seine Haende benutzen um Sachen zu tragen (oder Tueren zu oeffnen)
MT_MALE 0 // Ist maennlich
MT_FEMALE 00800 // Ist weiblich
MT_NONHUM 01000 // Kein Mensch. Ich bin mir nicht sicher was es genau bewirkt.
MT_RUN 02000 // Kann wirklich schnell laufen!</spherescript>

Nach dieser Tabelle wird klar, dass ein NPC ohne CAN Flags ein MT_Male und MT_NONMOVER (zweimal 0) ist. Die Flags können durch ein | (Alt Gr + <) getrennt in einer Liste angegeben werden, so dass ein NPC mehrere solcher Flags erhalten kann. In diesem Fall erlauben wir unserem Mann, dass er etwas ausrüsten (oder anziehen), gehen, rennen und seine Hände benutzen kann. (Interessant ist, dass sogar Kreaturen ohne Hände ihre Hände nutzen können und damit bspw. Lichtquellen tragen können. Feuerelementare tun das beispielsweise, deshalb leuchten sie.)

'''Zeile 6''': RESOURCES

Die Resources sind etwas morbide als Bezeichnung. Vor allem für Personen, denn sie enthalten die Items, die herauskommen, wenn man im Spiel eine Leiche aufschneidet. Gruslig, hm?

'''Zeile 7-10''': FOODTYPE, DESIRES, AVERSIONS

'''FOODTYPE''': Legt fest, welche Art von Essen der NPC essen würde und wenn NPC_AI_FOOD aktiviert ist, sucht der NPC nach so einem Essen wenn er hungrig wird.

'''DESIRES''': Legt fest, welche Art von Items ihn interessieren und wenn NPC_AI_EXTRA aktiviert ist, dann wird ein NPC aus Spielerleichen diese Gegenstände holen oder, falls diese Gegenstände am Boden liegen, zu ihnen hingehen.

'''AVERSIONS''': Das ist nicht ganz klar. Ich nehme an, dass diese Option angibt, was der NPC am liebsten angreift. Beispielsweise: Ich habe ein Pferd mit dem Event e_horse und einen Imp mit AVERSIONS=e_horse, dann würde im Falle eines Kampfs der IMP wohl vorziehen gegen das Pferd zu kämpfen.

'''Zeile 11''': BLOODCOLOR

Jemals vorgehabt den Spielern grünes Blut zu verpassen? Das geht hiermit. Eine Nummer für eine Farbe oder ein DEFNAME funktioniert hier. (Für Farben sollte man versuchen die Zahlen zu lernen, das macht es einfacher.)

Der Rest: TSPEECH and TEVENTS

Diese beiden Zeilen erhalten eigene Kapitel. Sie sind sehr komplex und mitunter die komplexesten Dinge beim Skripten! (Wie oft ich das wohl sagen werde, bis das wirklich wahr ist?)

''Einige andere Dinge:''

Auf 56B gibt es weitere Variablen wie MOVERATE, RESLEVEL, RESDISPDNID and RESDISPDNHUE. Sie klingen schwierig und seltsam, aber das sind sie nicht. Hier ist eine Erklärung:

'''MOVERATE''': Diese Einstellung (die nur innerhalb eines CHARDEF Blocks sein kann) legt fest, wie schnell sich ein NPC bewegt. Je kleiner der Wert, desto schneller ist ein NPC. Beispielsweise für ein Pferd mit vorgegebener MOVERATE von 100, wäre ein anderer NPC mit MOVERATE von 60 schneller als das Pferd. Das ist ganz gut, um schwierige Monster zu skripten, die nur schwer zu erlegen sind.

'''RESLEVEL''': Das sagt Sphere aus welcher Version von UO das Monster abstammt, Beispielsweise hat ein "Wanderer of the Void" RESLEVEL=3 (3 ist AOS) (siehe spheredefs.scp für eine Liste), so dass nur Accounts mit RESDISP 3 oder größer das Monster so sehen, wie es wirklich aussieht.

''NOTE'': Setzt man einen zu niedrigen Wert für RESLEVEL und der Spieler hat die passende Animation nicht, führt das zum Absturz seines Clients.

'''RESDISPDNID''': Wie wahrscheinlich bemerkt, sagte ich oft nun "wie er wirklich" ist, genau wegen dieser Einstellung. Das legt fest, wie ein Monster für einen Spieler aussieht, hat er die Animation nicht. Beispielsweise wird der Wanderer of the Void für jeden mit ACCOUNT.RESDISP=3 oder großer auch wie ein Wanderer of the Void aussehen, aber für alle anderen sieht er wie ein c_spectre aus (wenn es so eingestellt wurde).

'''RESDISPDNHUE''': Das legt fest, welche Farbe für den Spieler das Monster hat, wenn die RESDISPDNID angezeigt wird (und sein account.resdisp kleiner als reslevel dieses Charakters ist).

Hier ist ein Beispiel für diese neuen Einstellungen:

<spherescript>[CHARDEF 310]
DEFNAME=c_Wailing_Banshee
NAME=Wailing Banshee
SOUND=snd_monster_zombie1
ICON=i_pet_wailingbanshee
DAM=11,16
RESDISPDNID=c_spectre
RESLEVEL=3
RESDISPDNHUE=01
ARMOR=20
CAN=MT_WALK|MT_FLY
DESIRES=i_gold,e_notoriety,e_horses,c_man,c_woman,t_corpse
CATEGORY=New Monsters
SUBSECTION=AOS
DESCRIPTION=Wailing Banshee

ON=@Create
NPC = brain_monster
FAME = {100 3000}
KARMA = {-5000 -6999}
STR = {126 166}
INT = {86 115}
DEX = {41 75}
MAGICRESISTANCE = {75.0 95.0}
TACTICS = {45.0 75.0}
WRESTLING = {50.0 70.0}

ON=@NpcRestock
ITEM = i_gold, {50 100}
ITEM = i_reag_daemon_bone, {2 6}</spherescript>

Und das wars. Einfache Charakterskripte und ein paar neue Dinge. Es gibt dazu noch ein spezielles Kapitel nur über das Skripten von NPCs später.

==TEMPLATE==
Oder wie man eine große Menge serverbelastender Items in einen nichtserverbelastenden Container packt.

Jeder hat sie schon gesehen. Die Shards, die keine TEMPLATEs benutzen. Wird beispielsweise ein Drache auf diesen Shards erlegt und lootet man ihn dann, dann findet man statt schön abgepackte Behälter ein paar 100 Tränke im Lootfenster verteilt. Nicht nur das, alle magischen Gegenstände sind auch noch darunter vergraben!

Wie wird das Problem gelöst? Sphere hat ein sehr handhabbares Werkzeug: die TEMPLATES. Sie erlauben, dass Container Items definiert werden und die Items in diesen Containern ebenfalls und zwar gleichzeitig. Das ist doch toll? I dachte es mir, als ich heraus fand, was sie sind. Deshalb wieder eine Zeile für Zeile Aufschlüsselung, diesmal mit einem TEMPLATE aus spheretemp_loot.scp.

<tt>[TEMPLATE 101505] 
DEFNAME=backpack_poor 
CATEGORY=Item Templates 
SUBSECTION=Loot Templates 
DESCRIPTION=Poor Backpack 
CONTAINER=i_backpack 
ITEM={ random_food 1 0 3 },{ 1 3 } 
ITEM={ random_bottle 1 0 8 } 
ITEM={ random_light 1 0 8 } 
ITEM={ random_male_tops 1 0 4 } 
COLOR=colors_all 
ITEM={ random_male_pants 1 0 4 } 
COLOR=colors_all 
ITEM=POOR_GOLD_PILE </tt>

Sieht verwirrend aus. Aber kein Problem, das wird schon alles klar werden, was das bedeutet!

[TEMPLATE 101505]: Als erstes wird die Kopfzeile des templates betrachtet. Interessant an Templates ist, dass der Itemname kein DEFNAME sein kann, sondern eine sehr hohe Zahl sein muss.

DEFNAME=backpack_poor: Natürlich sind die Sphere Entwickler nicht bösartig und haben deshalb hier noch die Möglichkeit eines DEFNAMEs eingeführt.

CATEGORY, SUBSECTION, DESCRIPTION: Der übliche Axiskram. Optional natürlich. In den vorherigen Abschnitten wird das genauer erklärt.

CONTAINER=i_backpack: Ok, nun gehts runter bis aufs Eingemachte. Das ist der Container, der benutzt wird und alle anderen Items landen in diesem. Wenn der Container im Spiel erstellt wird, dann sieht man ihn. In diesem Fall ist das ein Rucksack. Ganz einfach. Hier kann nur ein gültiger Container vom Typ t_container oder t_container_locked angegeben werden.

ITEM={ random_food 1 0 3},{1 3} Das sieht ziemlich kryptisch aus. Deshalb wird diese Zeile ein wenig eingehender beleuchtet.

Als erstes muss ZUFALLSAUSWAHL behandelt werden! Klingt nach Spaß, nicht? Nun ja, klingt auch für mich nicht danach, aber es ist unbedingt notwendig, um einen guten Shard zu bauen.

Sie sind einfache grundlegende Mechanismen, um mit einem Befehl eine zufällige Zahl zu erhalten. Was wäre das schon für ein Shard, auf dem jeder getötete Drache auch eine Platemail of Magic Stuff und ein Super Duper Sword of Power liefern würde? Jeder würde damit herumlaufen, deshalb braucht es etwas Variabilität.

Es gibt zwei Arten von Zufallsauswahlen: gewichtete und bereichsweise Auswahl. Gewichtete Auswahlen funktionieren so: "OK, 1 mal von 10 nimm Nummer A, 3 mal von 10 nimm Nummer B und 6 mal von 10 nimm Nummer C". Bereichsweise Auswahlen funktionieren so: "Wähle eine zufällige Zahl zwischen zwei Zahlen, die ich festlege".

Unser Beispiel nutzt beides - sowohl bereichsweisen als auch gewichteten Zufall. Der Reihe nach:

{ random_food 1 0 3}

Das ist eine gewichtete Auswahl. Um das richtig zu verstehen, wird der Ausdruck zwischen den Klammern in zwei Teile zerlegt:

random_food 1
0 3

Addiert man die letzte Zahl in den beiden Zeilen, erhält man 4. Das sagt Sphere "OK, 1 von 4 Mal, will ich random_food und 3 von 4 Mal wähle ich 0." Man kann auch Zufallsauswahlen verschachteln, aber das wird dann verwirrend.

{ { random_food 1 0 3} 1 random_clothing 1}

Klar, was das heisst?

random_clothing 1
{ random_food 1 0 3} 1

2 ist hier die magische Zahl. Einmal von 2 nimmt Sphere random_clothing und einmal von 2 nimmt Sphere den vorherigen Auswähler, der dann aus seinen eigenen Optionen eins auswählt. Wenn du jetzt schon verwirrt bist, keine Sorge. Das ist sehr selten, aber es wird sich zeigen, wie TEMPLATES diese Probleme lösen können.

Ich habe erwähnt, dass es noch einen weiteren Zufallswähler gibt. Und dieser ist hier:

{1 3}

Anmerkung: Leerzeichen sind hier wichtig. Hier dürfen keine Leerzeichen zwischen { und der ersten Zahl oder } und der letzten Zahl sein. Ansonsten kommt seltsames Verhalten dabei heraus.

Das weist Sphere an "Nimm eine beliebige Zahl zwischen 1 und 3, inklusive". Inklusive heißt, dass Sphere auch 1 und 3 wählen kann oder eben jede Zahl dazwischen. In diesem Fall ist der Bereich sehr beschränkt. Sphere wird eine 1, 2 oder eine 3 liefern. Bereichsweise Auswähler werden oftmals in gewichteten Auswählern benutzt.

{ {1 3} 3 {4 9} 1}

"Einmal aus 4, nimm eine Zahl zwischen 4 und 9. Dreimal von 4, nimm eine Zahl zwischen 1 und 3."

Nachdem wir das nun hinter uns haben, sehen wir uns die Zeile des Skripts von oben an. Der Teil mit ITEM= 
Das legt im Skript fest "Ok, wir werden jetzt ein Item zum Container hinzufügen". Alles nach dem = legt fest, was genau das ist und in welcher Menge. Es kann natürlich geskriptete werden ITEM=i_platemail_chest oder sonst was ohne die mysteriösen { } Auswähler, aber der Grund, warum TEMPLATES so interessant sind, ist die große Variabilität, die sie bringen.

{ random_food 1 0 3}

Das ist das Item, das erstellt wird. Aus der Einheit über gewichtete Zufallsauswahlen, 1 von 4 Mal, wird das random_food sein und 3 von 4 Mal, wird das 0 sein. Wenn ein Item 0 ist, dann wird nichts erstellt. Das bedeutet: "Hier gibt es eine 1 zu 4 Chance, dass random_food im Container auftaucht." Was random_food ist? Das ist ein weiteres TEMPLATE, das in spheretemplate.scp definiert wurde ... glaube ich.

{1 3} Ist die Menge des Items, die erstellt wird. Das ist eine zufällige Bereichsauswhl. Sphere nimmt eine Zahl zwischen 1 und 3 und setzt dann die Menge im Container. Natürlich: ist das Item zuvor 0 geworden, dann wird auch die Menge daran nichts ändern, denn 3 mal 0 ist weiterhin 0.

Das war grundlegend das Template Skript. Hier können noch so viele Items eingefügt werden, wie man Lust hat. Ausserdem ist noch folgendes Konstrukt dann interessant:

ITEM=i_sword_long,R11

Das ist eine Kurzform von:

ITEM={ i_sword_long 1 0 10 }

R11 bedeutet: "1 zu 11 Chance, dass das Item gefunden wird". Und zusätzlich kann noch eine Mengenauswahl hinten angehängt werden, was es ziemlich seltsam aussehen lässt:

ITEM=i_sword_long,R11,{4 5}

Aber warum würde man 4 oder 5 Langschwerter haben wollen? Das wäre noch seltsamer. :)

Das wars von Templates. Gratulation, das erste Kapitel ist hiermit durch. Jetzt sollten die Beispiele im nächsten Abschnitt nicht schwierig zu verstehen sein. Du könntest auch einige fragen haben, die hier allerdings ohnehin nicht beantwortet werden. Einfach weiterlesen, es wird noch vieles in den folgenden Kapiteln abgehandelt.

''(Ein Template Beispiel von Belgar)''

<tt>[TEMPLATE tm_necromancer] 
CONTAINER=i_bag 
ITEM=random_necro_scroll 
ITEM=random_necro_scroll 
ITEM=random_necro_reagent, {5 12} 
ITEM=random_reagent, {5 12} 
ITEM=random_necro_reagent, {5 12} </tt>

==Beispiele==
Oder ... naja, glaub es gibt kein anderes Wort für "Beispiele".

Das soll mein Versuch sein, einfachste simpelste Items zu erstellen. Du wirst hier einige DInge in diesen Beispielen sehen, die in den Tutorials nicht behandelt wurden. Hauptsächlich gibts hier ein ON=@create das im 2. Kapitel abgehandelt wird. Für die Beispiele ist nur wichtig, dass die Farbe der Dinge im Spiel geändert werden kann und dass das unter on=@create passieren muss.

'''Beispiel 1''': Ein rotes Schwert

<tt>[ITEMDEF i_sword_red] 
ID=i_sword_viking 
TYPE=t_weapon_sword 
NAME=Das rote Schwert 
CATEGORY=Weapons 
SUBSECTION=New Swords 
DESCRIPTION=Red Sword 

ON=@Create
:COLOR=colors_red // Das ist ein Kommentar. Kommentare werden von Sphere ignoriert. </tt>

Moment ... was heisst das // an dieser Stelle? Das ist ein Kommentar, er wird gänzlich von Sphere ignoriert, deshalb kann hier alles stehen, solange es hinter den // steht. Es gibt in Sphere keine mehrzeiligen Kommentare, solange man nicht jede Zeile mit // beginnen lässt. Deshalb sollte man das gar nicht versuchen, sonst wird Sphere viele Fehler ausgeben und man darf sie suchen.

'''Beispiel 2''': Ein blauer Ettin

<tt>[CHARDEF c_ettin_blue] 
ID=02 // Hier kann auch c_ettin benutzt werden natürlich. 
NAME=Mein blauer Ettin 
 
 
ON=@Create 
:COLOR=02 // Das ist dunkelblau. Wird oft für Counselorroben benutzt. Merken. </tt>

'''Beispiel 3''': Ein Template aus einer der Dateien, weil ich zu faul bin eins selbst zu schreiben

<tt>[TEMPLATE 101521] 
DEFNAME=goodie_meager_1 
CATEGORY=Item Templates 
SUBSECTION=Loot Templates 
DESCRIPTION=Meager Goodie 1 
ITEM={ meager_gold_pile 1 backpack_meager 1 pouch_meager 1 } 
ITEM={ random_boots 1 0 4 } 
ITEM={ random_gorget 1 0 4 } 
ITEM={ random_staff 1 0 4 } 
ITEM={ random_necklace 1 0 4 } 
ITEM={ i_cape 1 0 9 } 
COLOR=colors_all </tt>

Bemerkenswert ist hier etwas neues (das speziell in rot hervorgehoben ist) und ja, das kann man so schreiben. Alle Zeilen zwischen ITEM= Zeilen betreffen das zuvor erstelle Item. COLOR= bezieht sich also auf die Zeile

ITEM={ i_cape 1 0 9 }

Der beste Weg diese Art von Skripten zu lernen, liegt darin, dass man die Skripte in den Dateien wie beispielsweise sphereitem_colorarm.scp und sphereitem_beers.scp liest.

[[Category:Tutorials]]