Altes Verzeichnis man entfernt.
Die Files werden inzwischen woanders hin erzeugt.
Change-Id: I3470330847e6377c10f08f92370b44f9077caab4
diff --git a/doc/sphinx/man/index b/doc/sphinx/man/index
deleted file mode 100644
index b2693f9..0000000
--- a/doc/sphinx/man/index
+++ /dev/null
@@ -1,21 +0,0 @@
-
-Willkommen bei der Morgengrauen-Mudlib - Dokumentation!
-*******************************************************
-
-Inhalt:
-
-* sefuns (simulated efuns)
-
-* Properties
-
-* lfuns
-
-
-Indices and tables
-******************
-
-* *Index*
-
-* *Module Index*
-
-* *Search Page*
diff --git a/doc/sphinx/man/lfun-liste b/doc/sphinx/man/lfun-liste
deleted file mode 100644
index 63c3862..0000000
--- a/doc/sphinx/man/lfun-liste
+++ /dev/null
@@ -1,871 +0,0 @@
-
-Verzeichnis der dokumentierten lfuns
-************************************
-
-* AddAction()
-
-* AddAdjective()
-
-* AddAmount()
-
-* AddClass()
-
-* AddCmd()
-
-* AddCmd_bsp()
-
-* AddDefender()
-
-* AddDetail()
-
-* AddDrink()
-
-* AddExit()
-
-* AddExp()
-
-* AddExtraLook()
-
-* AddFixedObject()
-
-* AddFood()
-
-* AddFuel()
-
-* AddFun()
-
-* AddId()
-
-* AddInfo()
-
-* AddItem()
-
-* AddKnownPotion()
-
-* AddMaterial()
-
-* AddMiniQuest()
-
-* AddMoney()
-
-* AddMsg()
-
-* AddPlant()
-
-* AddPluralId()
-
-* AddPursuer()
-
-* AddReadDetail()
-
-* AddResistanceModifier()
-
-* AddRoomCmd()
-
-* AddRoomMessage()
-
-* AddRoute()
-
-* AddSingularId()
-
-* AddSmells()
-
-* AddSounds()
-
-* AddSpecialDetail()
-
-* AddSpecialExit()
-
-* AddSpecialInfo()
-
-* AddSpell()
-
-* AddToMenu()
-
-* AddTouchDetail()
-
-* AllGroups()
-
-* AllMaterials()
-
-* AssocMember()
-
-* Attack()
-
-* BecomesNetAlive()
-
-* BecomesNetDead()
-
-* CannotSee()
-
-* ChangeMiniQuest()
-
-* ChangeReputation()
-
-* CheckFindRestrictions()
-
-* CheckLightType()
-
-* CheckResistance()
-
-* CheckSensitiveAttack()
-
-* CheckSpellFatigue()
-
-* ClearRingBuffer()
-
-* Configure()
-
-* ConvMaterialList()
-
-* CreateRingBuffer()
-
-* CustomizeObject()
-
-* Damage()
-
-* DeAssocMember()
-
-* DeclAdj()
-
-* Defend()
-
-* DefendFunc()
-
-* DefendInfo()
-
-* DefendOther()
-
-* Defend_bsp()
-
-* DeleteSpellFatigue()
-
-* DeleteTimedAttrModifier()
-
-* DiscoverDoor()
-
-* DistributeExp()
-
-* DoDecay()
-
-* DoDecayMessage()
-
-* DoUnwear()
-
-* DoUnwield()
-
-* DoWear()
-
-* DoWield()
-
-* DoorIsKnown()
-
-* Dump()
-
-* EnemyPresent()
-
-* Enter()
-
-* EvalArmour()
-
-* EvalWeapon()
-
-* ExtraAttack()
-
-* FilterArmours()
-
-* FilterClothing()
-
-* FindBestArmours()
-
-* FindBestWeapon()
-
-* FindDistantEnemyVictim()
-
-* FindDistantGroup()
-
-* FindDistantGroups()
-
-* FindEnemyVictim()
-
-* FindFarEnemyVictim()
-
-* FindGroup()
-
-* FindGroupN()
-
-* FindGroupP()
-
-* FindNearEnemyVictim()
-
-* FindPotion()
-
-* FindRangedTarget()
-
-* Flee()
-
-* FreeHands()
-
-* GetAquarium()
-
-* GetDetail()
-
-* GetDoorsMapping()
-
-* GetEnemies()
-
-* GetExits()
-
-* GetFValue()
-
-* GetFValueO()
-
-* GetFactor()
-
-* GetGroupMembers()
-
-* GetInfoArr()
-
-* GetMatMembership()
-
-* GetOffset()
-
-* GetOwner()
-
-* GetPhiolenInfos()
-
-* GetReputation()
-
-* GetReputations()
-
-* GetValue()
-
-* GetValueO()
-
-* Gildenproperties()
-
-* GiveMiniQuest()
-
-* GiveQuest()
-
-* GroupName()
-
-* GuardExit()
-
-* Halt()
-
-* HasMiniQuest()
-
-* HitFunc()
-
-* Identify()
-
-* InFight()
-
-* InList()
-
-* InformAlcoholEffect()
-
-* InformDefend()
-
-* InformRowChange()
-
-* InformUnwear()
-
-* InformUnwield()
-
-* InformWear()
-
-* InformWield()
-
-* InsertEnemy()
-
-* InsertEnemyTeam()
-
-* InsertSensitiveObject()
-
-* InternalModifyAttack()
-
-* InternalModifyDefend()
-
-* IsArmour()
-
-* IsBottle()
-
-* IsClothing()
-
-* IsEnemy()
-
-* IsEqual()
-
-* IsPlayerCorpse()
-
-* IsRoom()
-
-* IsTeamLeader()
-
-* IsTeamMove()
-
-* IsUnit()
-
-* Kill()
-
-* LearnSkill()
-
-* Leave()
-
-* LimitAbility()
-
-* MaterialGroup()
-
-* MaterialList()
-
-* MaterialName()
-
-* MayAddObject()
-
-* MayAddWeight()
-
-* Message()
-
-* ModifyQuestTime()
-
-* ModifySkill()
-
-* ModifySkillAttribute()
-
-* More()
-
-* NPC_Killed_by()
-
-* NewDoor()
-
-* NoParaObjects()
-
-* NotifyDestruct()
-
-* NotifyInsert()
-
-* NotifyLeave()
-
-* NotifyMove()
-
-* NotifyPlayerDeath()
-
-* NotifyRemove()
-
-* NotifyTimedAttrModExpired()
-
-* NotifyXMAttrModLimitViolation()
-
-* Pacify()
-
-* PayIn()
-
-* PlayerQuit()
-
-* PresentEnemies()
-
-* PresentEnemyRows()
-
-* PresentPosition()
-
-* PresentRows()
-
-* PresentTeamPositions()
-
-* PresentTeamRows()
-
-* PreventFollow()
-
-* PreventInsert()
-
-* PreventInsertLiving()
-
-* PreventLeave()
-
-* PreventLeaveLiving()
-
-* PreventMove()
-
-* Query()
-
-* QueryAllDoors()
-
-* QueryArmourByType()
-
-* QueryArrived()
-
-* QueryArticle()
-
-* QueryAttribute()
-
-* QueryAttributeOffset()
-
-* QueryBuyFact()
-
-* QueryBuyValue()
-
-* QueryCoinsPerUnits()
-
-* QueryDamage()
-
-* QueryDefend()
-
-* QueryDisguise()
-
-* QueryDoorKey()
-
-* QueryDoorStatus()
-
-* QueryDu()
-
-* QueryEnemies()
-
-* QueryFlaw()
-
-* QueryGenderString()
-
-* QueryGramsPerUnits()
-
-* QueryGroupedKeys()
-
-* QueryGuest()
-
-* QueryHealInfo()
-
-* QueryMaterial()
-
-* QueryMaterialGroup()
-
-* QueryMaxQP()
-
-* QueryMoney()
-
-* QueryName()
-
-* QueryOpenMiniQuestsForPlayer()
-
-* QueryOwn()
-
-* QueryPassengers()
-
-* QueryPosition()
-
-* QueryPossPronoun()
-
-* QueryPrayRoom()
-
-* QueryPreferedEnemy()
-
-* QueryPronoun()
-
-* QueryProp()
-
-* QueryProperties()
-
-* QueryQuest()
-
-* QueryQuestTime()
-
-* QueryRealAttribute()
-
-* QuerySellValue()
-
-* QuerySkill()
-
-* QuerySkillAbility()
-
-* QuerySkillAttribute()
-
-* QuerySkillAttributeModifier()
-
-* QuerySkillBonus()
-
-* QueryStorageRoom()
-
-* QueryTimedAttrModifier()
-
-* QueryTotalQP()
-
-* QueryUser()
-
-* QueryValidObject()
-
-* ReceiveMsg()
-
-* RegisterEvent()
-
-* RegisterHelperNPC()
-
-* RegisterHelperObject()
-
-* RemoveAdjective()
-
-* RemoveClass()
-
-* RemoveCmd()
-
-* RemoveDefender()
-
-* RemoveDetail()
-
-* RemoveExit()
-
-* RemoveExtraLook()
-
-* RemoveFixedObject()
-
-* RemoveFromMenu()
-
-* RemoveFunc()
-
-* RemoveId()
-
-* RemoveInfo()
-
-* RemoveItem()
-
-* RemoveKnownPotion()
-
-* RemovePluralId()
-
-* RemovePursuer()
-
-* RemoveReadDetail()
-
-* RemoveResistanceModifier()
-
-* RemoveRoute()
-
-* RemoveSensitiveObject()
-
-* RemoveSingularId()
-
-* RemoveSkillAttributeModifier()
-
-* RemoveSmells()
-
-* RemoveSounds()
-
-* RemoveSpecialDetail()
-
-* RemoveSpecialExit()
-
-* RemoveTouchDetail()
-
-* ResizeRingBuffer()
-
-* RingBufferGet()
-
-* RingBufferPut()
-
-* SearchPath()
-
-* SelectEnemy()
-
-* SelectFarEnemy()
-
-* SelectNearEnemy()
-
-* Set()
-
-* SetAttackChats()
-
-* SetAttr()
-
-* SetAttribute()
-
-* SetBuyFact()
-
-* SetChats()
-
-* SetCoinsPerUnits()
-
-* SetDoorStatus()
-
-* SetEnemies()
-
-* SetGramsPerUnits()
-
-* SetProp()
-
-* SetProperties()
-
-* SetRealAttribute()
-
-* SetSpellFatigue()
-
-* SetStorageRoom()
-
-* SetTimedAttrModifier()
-
-* ShowDoors()
-
-* ShowPropList()
-
-* SkillResTransfer()
-
-* SpellAttack()
-
-* SpellDefend()
-
-* SpellInform()
-
-* Start()
-
-* StopHuntFor()
-
-* StopHuntText()
-
-* SuggestArticle()
-
-* SwapRows()
-
-* TakeFlaw()
-
-* TeamFlee()
-
-* TeamMembers()
-
-* TeamPrefix()
-
-* Teleport()
-
-* TestIgnore()
-
-* TestIgnoreSimple()
-
-* TestLimitViolation()
-
-* TriggerEvent()
-
-* UnregisterEvent()
-
-* UnregisterHelperNPC()
-
-* UnregisterHelperObject()
-
-* Unwear()
-
-* UnwearArmour()
-
-* UnwearClothing()
-
-* UnwieldFunc()
-
-* UpdateAttributes()
-
-* UpdateResistanceStrengths()
-
-* UseHands()
-
-* UseSkill()
-
-* UseSpell()
-
-* Validate()
-
-* Wear()
-
-* WearArmour()
-
-* WearClothing()
-
-* WearFunc()
-
-* WieldFunc()
-
-* WithDraw()
-
-* __INIT()
-
-* _query_current_money()
-
-* _unparsed_args()
-
-* access_rights()
-
-* buffer_hp()
-
-* buffer_sp()
-
-* buy_obj()
-
-* catch_msg()
-
-* catch_tell()
-
-* check_and_update_timed_key()
-
-* check_restrictions()
-
-* check_timed_key()
-
-* clean_up()
-
-* cmd_shoot()
-
-* command_me()
-
-* consume()
-
-* create()
-
-* create_default_npc()
-
-* create_super()
-
-* defuel_drink()
-
-* defuel_food()
-
-* deregister_modifier()
-
-* die()
-
-* doUnwearMessage()
-
-* doUnwieldMessage()
-
-* doWearMessage()
-
-* doWieldMessage()
-
-* do_damage()
-
-* do_frage()
-
-* do_unwear()
-
-* do_wear()
-
-* drink_alcohol()
-
-* drink_soft()
-
-* drop()
-
-* drop_obj()
-
-* drop_objects()
-
-* eat_food()
-
-* execute_anything()
-
-* exit()
-
-* find_obs()
-
-* get_killing_player()
-
-* give()
-
-* give_notify()
-
-* give_obj()
-
-* heal_self()
-
-* heart_beat()
-
-* id()
-
-* init()
-
-* insert_sensitive_inv()
-
-* insert_sensitive_inv_trigger()
-
-* int_long()
-
-* int_short()
-
-* is_class_member()
-
-* lfun()
-
-* locate_objects()
-
-* logon()
-
-* long()
-
-* make_immortal()
-
-* make_invlist()
-
-* match_ids()
-
-* move()
-
-* moved_objects()
-
-* moved_where()
-
-* muster()
-
-* name()
-
-* notify_player_change()
-
-* pick()
-
-* pick_obj()
-
-* pick_objects()
-
-* present_objects()
-
-* put()
-
-* put_obj()
-
-* query_prevent_shadow()
-
-* query_real_name()
-
-* query_weight_contents()
-
-* reduce_hit_points()
-
-* reduce_spell_points()
-
-* register_modifier()
-
-* remove()
-
-* remove_multiple()
-
-* reset()
-
-* restore_hit_points()
-
-* restore_spell_points()
-
-* save_me()
-
-* second_life()
-
-* sell_obj()
-
-* set_object_next_reset()
-
-* shoot_dam()
-
-* short()
-
-* show_notify()
-
-* trigger_sensitive_attack()
-
-* trigger_sensitive_inv()
-
-* wield_me()
-
-* Verzeichnis der lfuns speziell in/für Gilden
-
-* Verzeichnis der lfuns in master()
-
-* Verzeichnis der veralteten lfuns
diff --git a/doc/sphinx/man/lfun.index b/doc/sphinx/man/lfun.index
deleted file mode 100644
index 2018524..0000000
--- a/doc/sphinx/man/lfun.index
+++ /dev/null
@@ -1,20 +0,0 @@
-
-lfuns
-*****
-
-lfuns sind in LPC geschriebene Funktionen innerhalb von Objekten. Oft
-kann man diese von aussen rufen, einige lfuns sind jedoch auch privat.
-In den meisten Faellen beeinflusst man Objekte im Spiel durch das
-Rufen von jeweils passenden lfuns.
-
-
-Verzeichnis der dokumentierten lfuns
-====================================
-
-* Verzeichnis der dokumentierten lfuns
-
-* Verzeichnis der lfuns speziell in/für Gilden
-
-* Verzeichnis der lfuns in master()
-
-* Verzeichnis der veralteten lfuns
diff --git a/doc/sphinx/man/lfun/AddAction b/doc/sphinx/man/lfun/AddAction
deleted file mode 100644
index 29c83c1..0000000
--- a/doc/sphinx/man/lfun/AddAction
+++ /dev/null
@@ -1,104 +0,0 @@
-
-AddAction()
-***********
-
-
-AddAction(L)
-============
-
-
-FUNKTION
-========
-
- varargs void AddAction(mixed fun, mixed cmd, int flag, int lvl);
-
-
-DEFINIERT IN
-============
-
- /std/player/command.c
-
-
-ARGUMENTE
-=========
-
- fun zu rufende Methode im Spieler oder eine Closure
- cmd ausloesendes Kommandoverb
- flag unscharf ausfuehren
- lvl ab welchem (Magierlevel) funktioniert das Kommando
-
-
-BESCHREIBUNG
-============
-
- Dem Spieler wird ein neues Kommando definiert. Dieses kann eine Methode
- in ihm sein, so wie bei allen Spielerkommandos ueblich, kann aber auch
- eine Closure (Lfun-Closure oder Lambda) enthalten.
-
- Mittels "flag" kann man die Kommandoerkennung unscharf halten, d.h. wie
- bei AddCmd(L) und add_action(E) wird ein 'cmd' bei 'flag = 1' auch
- schon von Praefix-Strings (hier ohne Leerzeichen) getriggert:
- AddAction([...], "muh", 1, 0) wird zB auch von 'muhtens' oder 'muh4'
- ausgeloest.
-
- Mit "lvl" begrenzt man die Ausfuehrbarkeit. Spieler haben ein
- Magierlevel von 0, Seher von 1.
-
- Das Kommando wird in P_LOCALCMDS eingetragen. Diese Property wird
- nicht gespeichert! Effektiv kann man mit AddAction() ein kommando-
- gebendes Objekt im Spieler einsparen.
-
-
-BEMERKUNGEN
-===========
-
- - es gibt _noch_ kein RemoveAction! Per Hand in P_LOCALCMDS editieren
- kann zu ernsten Fehlern fuehren.
- - echte Spielerkommandos kann man damit _nicht_ ueberschreiben,
- ein AddAction(...,"sag",1,0); funktioniert nicht
- - ein generelles AddAction(...,"",1,0); geht nicht
-
-
-BEISPIELE
-=========
-
- ...
- this_player()->AddAction(symbol_function("zeige_mysterium",
- find_object(".../mystzeiger")),
- "knorfula",0,0);
- write(break_string("Wann immer du jetzt das Kommando \"knorfula\" "
- "eingibst, werden dir Mysterien enthuellt!",78));
- ...
-
- // im Objekt "knorfula" ...
- int zeige_mysterium(string str) {
- string myst;
- myst=environment(TP)->QueryMysterium(str);
- if(myst) {
- write("Du hast ein Mysterium entdeckt!\n");
- write(break_string(myst,78));
- say(break_string(
- TP->Name(WER)+" scheint nach kurzer Konzentration etwas "
- "entdeckt zu haben!",78));
- } else {
- write(break_string(
- "Leider entdeckst du trotz deiner magischen Faehigkeit "
- "kein Mysterium in deiner Umgebung.",78));
- say(break_string(
- TP->Name(WER)+" konzentriert sich sichtbar, sieht dann "
- "jedoch etwas enttaeuscht aus.",78));
- }
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- P_LOCALCMDS
- Fehlermeldungen: notify_fail(E), _notify_fail(E)
- Argumentstring: query_verb(E), _unparsed_args(L)
- Sonstiges: replace_personal(E), enable_commands(E)
- Alternativen: AddCmd(L), add_action(E)
-
-24. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/AddAdjective b/doc/sphinx/man/lfun/AddAdjective
deleted file mode 100644
index a96a5e5..0000000
--- a/doc/sphinx/man/lfun/AddAdjective
+++ /dev/null
@@ -1,62 +0,0 @@
-
-AddAdjective()
-**************
-
-
-FUNKTION
-========
-
- void AddAdjective(string|string* adj);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- adj
- String oder Array von String mit den Adjektiven.
-
-
-BESCHREIBUNG
-============
-
- Zusaetzlich zu den mit AddId() vergebenen Bezeichnern laesst sich mit
- der Vergabe von Adjektiven die Ansprechbarkeit eines Objektes erhoehen.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Die Adjektive werden nicht dekliniert, man muss also fuer jeden
- sinnvollen Fall ein Adjektiv uebergeben.
-
-
-BEISPIELE
-=========
-
- AddId( ({ "zettel", "blatt" }) );
- AddAdjective( ({ "kleinen", "kleines" }) );
-
- Das Objekt reagiert jetzt auf "zettel", "kleinen zettel", "blatt",
- "kleines blatt" sowie auf die (sprachlich nicht ganz so korrekten)
- Konstruktionen "kleines zettel", "kleinen blatt", "kleines kleinen
- zettel", ...
-
-
-SIEHE AUCH
-==========
-
- AddId(), RemoveAdjective() id(), present(), /std/thing/description.c
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddAmount b/doc/sphinx/man/lfun/AddAmount
deleted file mode 100644
index 59bb9b1..0000000
--- a/doc/sphinx/man/lfun/AddAmount
+++ /dev/null
@@ -1,44 +0,0 @@
-
-AddAmount()
-***********
-
-
-FUNKTION
-========
-
- void AddAmount(int menge);
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- menge
- Die Menge, die der Unit hinzugefuegt werden soll (kann auch
- negativ sein).
-
-
-BESCHREIBUNG
-============
-
- menge wird zur aktuellen Menge hinzugezaehlt. Sollte das Ergebnis 0
- werden, wird die Unit in absehbarer Zeit zerstoert.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- /std/unit.c
-
-Last modified: Wed May 8 10:15:50 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/AddClass b/doc/sphinx/man/lfun/AddClass
deleted file mode 100644
index fee72e3..0000000
--- a/doc/sphinx/man/lfun/AddClass
+++ /dev/null
@@ -1,48 +0,0 @@
-
-AddClass()
-**********
-
-
-FUNKTION
-========
-
- void AddClass(string|string* class);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- string/string* class - String oder Stringarray der Klasse(n)
-
-
-BESCHREIBUNG
-============
-
- Dem Objekt werden weitere Klassifizierungen hinzugefuegt.
-
- Die allgemein verfuegbaren Klassen sind unter /sys/class.h definiert.
-
-
-BEMERKUNGEN
-===========
-
- Vor dem 7. Nov 2012 pruefte is_class_member() auch die P_IDS. Damit war
- zB ein AddId("daemon") gleichbedeutend einem AddClass(CL_DEMON).
-
- Bitte prueft eure Objekte (NPCs, Krankheiten, Gifte, ...) auf korrekte
- Klassifizierung.
-
-
-SIEHE AUCH
-==========
-
- RemoveClass(), is_class_member()
- P_CLASS
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddCmd b/doc/sphinx/man/lfun/AddCmd
deleted file mode 100644
index 088da28..0000000
--- a/doc/sphinx/man/lfun/AddCmd
+++ /dev/null
@@ -1,244 +0,0 @@
-
-AddCmd()
-********
-
-
-AddCmd(L)
-=========
-
-
-FUNKTION
-========
-
- varargs void AddCmd(mixed cmd, mixed func, [mixed flag, [mixed id]]);
-
-
-DEFINIERT IN
-============
-
- /std/thing/commands.c
-
-
-ARGUMENTE
-=========
-
- cmd
- Verben, auf die reagiert werden soll
-
- ODER
-
- Regel mit Triggerverb und noetigen Keywords/Synonymen
- func
- Funktionsname im selben Objekt oder Closure (Funktionspointer)
- flag (optional)
- Unscharfe Ausfuehrung == 1
-
- ODER
-
- Fehlermeldungen bei Nutzung von Regeln
- id (optional)
- eine ID, ueber die das Kommando eindeutig wieder geloescht
- werden kann
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Spieler im Einflussbereich des Objektes das Verb benutzt,
- wird die entsprechende Funktion im Objekt aufgerufen:
- - die Verben sollten Imperative sein
- - die Funktion muss 1 fuer ERFOLG (und FPs!) und 0 sonst zurueckgeben
- (sonst werden evtl. weitere Funktionen mit diesem Kommandoverb gerufen)
- - innerhalb der Funktionen koennen Fehlermeldungen fuer den totalen
- Misserfolg des Kommandos mit notify_fail gesetzt werden
- (anstatt "Wie bitte?")
-
- AddCmd ist ein dynamischer Ersatz fuer add_action - im Gegensatz
- zu add_action koennen auch ohne erneuten Aufruf der init() neue
- Kommandos hinzugefuegt werden.
-
- AddCmd kann das Leben einfacher machen mit:
- ### REGELN: ###
- Bei komplexen Syntaxen kann ein String angegeben werden, der die
- _notwendigen_ (nicht die erlaubten!) Schluesselworte und deren
- zulaessige Synonyme beschreibt. Damit kann man sich einen grossen
- Teil eigener Auswertung ersparen.
-
- Nur wenn in richtiger Reihenfolge aus JEDER der durch & getrennten
- Synonymgruppen ein Wort im Spielerkommando enthalten ist, wird
- die zugehoerige Funktion ausgefuehrt.
-
- Trenner sind: | fuer Alternativen
- & fuer Konjunktionen
-
- Beispiel:
- "ritz|ritze|schnitz|schnitze&mit&messer|schnitzmesser&"
- "herz|herzchen&rinde|baumrinde"
- wuerde z.B. durch
- "ritz mit dem Messer ein Herz in die Rinde des Baumes"
- "schnitz mit Messer Herzchen Baumrinde"
- "schnitz mit meinem Messer Herzchen in die harte Baumrinde"
- erfuellt werden.
-
- Spezialregelteile sind:
- - @PRESENT: entspricht einem Objekt in Inv oder Env des Spielers
- - @ID: entspricht der ID des kommandobesitzenden Objektes
- (wo die Kommandomethode definiert ist, ist noch unwichtig)
- - @PUT_GET_DROP, @PUT_GET_TAKE, @PUT_GET_NONE:
- entsprechend den Filteroptionen fuer find_obs()
- ACHTUNG: Zusaetzliche Ziffern in Verbindung mit den @-Spezialregeln
- sind schlecht. @-Regeln versuchen gierig, Objekte exakt im
- Inventory zu matchen ("objekt 3" anstatt "objekt") und miss-
- interpretieren daher zB die 4 in "stopf objekt 3 in loch 4" als
- Teil des Objekt-ID-Strings.
- Interna: 3 Substrings fuer @PRESENT/@ID ("gruener kristall 2")
- 5 fuer @PUT... ("kristall 2 in beutel 3")
-
- ### FEHLERMELDUNGEN (bei Anwendung von Regeln): ###
- Als dritter Parameter koennen auch Fehlermeldungen fuer jeweils
- fehlende Synonymgruppen (ausser der ersten - den Kommandoverben)
- angegeben werden. Sie werden in derselben Reihenfolge (!) wie die
- Synonymgruppen angegeben.
-
- Mit nicht von Spielern erfuellbaren Regeln und ^-Fehlermeldungen
- kann man auch ohne Ausfuehrung einer Funktion Texte an Spieler
- und Umgebung ausgeben. Siehe dazu AddCmd_bsp.
-
- Trenner sind: | zum Trennen der einzelnen Fehlermeldungen
- ^ um
- - die Auswertung (ab dieser Fehlermeldung!) mit
- "return 1;" zu beenden und
- - eine write^say-Meldung zu trennen und
- - (fuer funktionslose AddCmd auch FPs zu vergeben!)
-
- Beispielfehlermeldungen fuer obige Regel:
- "Womit willst Du schnitzen?|Was willst Du schnitzen?|"
- "Wohinein willst Du das schnitzen?"
-
- Es koennen in den Fehlermeldungen folgende Platzhalter benutzt
- werden:
- - @verb (ersetzt durch query_verb() ohne beendendes 'e')
- - @VERB (ersetzt durch capitalize(query_verb()) ohne beendendes 'e')
- - @WERx, @WESSENx, @WEMx, @WENx: siehe alles aus replace_personal()
- - @WE..1 ist immer der aktive Spieler
- - alle folgenden sind die matchenden Parameter der Spielereingabe
- - (x-1)<=Fehlermeldung (da x=1 Spieler und
- (x-1)>Fehlermeldungsobjekt nicht existent)
-
- Ausfuehrungsbeispiel:
- AddCmd("ritz|ritze|schnitz|schnitze&mit&messer|schnitzmesser&"
- "herz|herzchen&rinde|baumrinde",#'fun,
- "Willst Du mit etwas @verben?|Womit willst du @verben?|"
- "Was willst du mit dem @WEM3 @verben?|"
- "Wohinein willst Du das @WEN4 schnitzen?");
- 1. "ritze" == "Willst Du mit etwas ritzen?"
- 2. "schnitz mit" == "Womit willst du schnitzen?"
- 3. "ritz mit messer" == "Was willst du mit dem messer ritzen?"
- 4. "ritze mit dem messer ein herz" ==
- "Wohinein willst Du das herz schnitzen?"
- 5. "ritze mit dem messer ein herzchen in die baumrinde"
- == Erfolg!
-
- ### UNSCHARFER AUSFUEHRUNG: ###
- Bei unscharfer Ausfuehrung wird die zugehoerige Methode auch dann
- ausgefuehrt, wenn das verwendete Verb ein Superstring ist und
- bisher noch nicht behandelt wurde.
- Dieses Verhalten sollte nur beim generellen Abfangen von
- Befehlsgruppen benutzt werden und ist ansonsten veraltet. Es
- entsprich add_action("fun","kommando",1).
-
-
- Beispiel:
- 1. AddCmd("klett","fun",1);
- 2. AddCmd("kletter|klettere&hoch",#'fun2,"Wohin klettern?");
-
- a) "klett"
- b) "kletter"
- c) "klettere hoch"
-
- Ausgefuehrte Funktion bei: 1a, 1b, 1c; 2c
- (1 wuerde also immer ausgefuehrt)
- Fehlermeldung bei: 2b ("Wohin klettern?")
-
-
-BEMERKUNGEN
-===========
-
- - Methoden der put_and_get (nimm/nehme) sollten so nicht versucht
- werden zu ueberschreiben - dazu sind invis Container da
- - benutzt man fuer <function> eine Closure, kann man die Fkt. auch
- protected oder private deklarieren _und_ sie kann in einem
- anderen Objekt sein
- - bei Regeln wird an die ggf. gerufene Methode als zweiter Parameter
- ein Array der erfuellenden Eingabeteile uebergeben:
- "steck&@PRESENT&in&loch" bei Erfuellung -> ({<Objekt>,"in","loch})
- - bei Nutzung von @PUT_GET_XXX koennen die Parameter wiederum
- Arrays sein ("jede Hose" -> mehrere gueltige Objekte)
- - juengere AddCmd ueberschreiben aeltere, bzw. werden vor diesen
- ausgewertet
- - @PUT_GET_XXX kosten sehr viel Auswertungszeit
-
-BEISPIELE (SIEHE AUCH ADDCMD_BSP):
- // SIMPEL: ganz simpel, beinahe wie add_action
- AddCmd("befiehl","action_befehlen"); ... int action_befehlen(string
- str) {
-
- if(!str || !strlen(str))
- // Fehlermeldung, falls gar keine Funktion 1 dafuer
- zurueckgibt notify_fail("Was willst du befehlen?!n");
-
- else {
- write("Du befiehlst ""+str+"", und alle folgen!n");
- say(TP->Name(WER)+" befiehlt ""+str+"", und du folgst!n");
- return 1; // ERFOLG - Abbruch der Kommandoauswertung
-
- } return 0; // MISSERFOLG - Fehlermeldung oben gesetzt
-
- }
-
- // SIMPEL .. weitere Beispiele
- AddCmd(({"kletter","klettere"}),"action_klettern" );
- AddCmd(({"renn","renne"}),#'action_rennen);
-
- // REGELN: eine komplexere Regel AddCmd("loesch|loesche|ersticke&f
- euer|brand|flammen&decke|wolldecke",
-
- "action_loeschen", "Was willst du loeschen?|Womit willst du
- loeschen?");
-
- // REGELN: mit Platzhaltern im Fehlerstring
- AddCmd("spring|springe|huepf|huepfe&von|vom&baum|ast|eiche",
-
- #'action_huepfe, "Willst du von etwas @verben?|Von wo willst du
- @verben?");
-
- // SCHLECHT: eine unscharfe Regel - sie sollten eine Ausnahme sein
- (!) AddCmd("kletter","fun_klettern",1);
-
- // FALSCH: sehr schlecht, kein Imperativ verwendet // ausserdem
- sollte man fuer solche Syntaxen AddReadDetail benutzen
- AddCmd("lese","eval_lesen");
-
- // SIMPLE REGEL OHNE METHODE // mit Regeln kann man auch
- Aktivitaeten im Raum erlauben, ohne eine // Funktion aufrufen zu
- muessen: die letzte Regel ist fuer Spieler // unmoeglich zu
- erfuellen, die dazugehoerige Fehlermeldung wird mit // dem ^
- (write-Flag) versehen und entsprechend an den Spieler // (und den
- Raum (hinter dem ^)) ausgegeben
- AddCmd("spring|springe&herunter|runter&nbimpossible",0,
-
- "Wohin oder wovon willst Du springen?|" "Du springst vom Baum
- und kommst hart auf.^" "@WER1 springt vom Baum und kommt hart
- auf.");
-
-
-SIEHE AUCH
-==========
-
- AddCmd_bsp, RemoveCmd(L), init(E)
- Fehlermeldungen: notify_fail(E), _notify_fail(E)
- Argumentstring: query_verb(E), _unparsed_args(L)
- Sonstiges: replace_personal(E), enable_commands(E)
- Alternativen: AddAction(L), add_action(E)
-
-30. Aug 2013 Gloinson
diff --git a/doc/sphinx/man/lfun/AddCmd_bsp b/doc/sphinx/man/lfun/AddCmd_bsp
deleted file mode 100644
index ec8ff17..0000000
--- a/doc/sphinx/man/lfun/AddCmd_bsp
+++ /dev/null
@@ -1,382 +0,0 @@
-
-AddCmd_bsp()
-************
-
-
-ADDCMD() - BEISPIELE
-====================
-
-
-FUNKTION
-========
-
- varargs void AddCmd(mixed cmd, mixed func, mixed flag);
-
-
-BEMERKUNGEN
-===========
-
- Die hier aufgefuehrten Komplexbeispiele sind zum Verstaendnis gedacht,
- daher fuehren sie oft Alternativen auf. Die letzte Variante ist dann
- jeweils diejenige, welche am leichtesten das Problem loesen koennte.
- Falls die einem zu komplex ist, hilft vielleicht die vorletzte.
-
-
-BEISPIELE
-=========
-
- // SIMPEL: ganz simpel, beinahe wie add_action
- AddCmd("befiehl","action_befehlen");
- ...
- int action_befehlen(string str) {
- if(!str || !strlen(str))
- // Fehlermeldung, falls gar keine Funktion 1 dafuer zurueckgibt
- notify_fail("Was willst du befehlen?!\n");
- else {
- write("Du befiehlst \""+str+"\", und alle folgen!\n");
- say(TP->Name(WER)+" befiehlt \""+str+"\", und du folgst!\n");
- return 1; // ERFOLG - Abbruch der Kommandoauswertung
- }
- return 0; // MISSERFOLG - Fehlermeldung oben gesetzt
- }
-
- // SIMPEL .. weitere Beispiele
- AddCmd(({"kletter","klettere"}),"action_klettern" );
- AddCmd(({"renn","renne"}),#'action_rennen);
-
- // REGELN: eine komplexere Regel
- AddCmd("loesch|loesche|ersticke&feuer|brand|flammen&decke|wolldecke",
- "action_loeschen",
- "Was willst du loeschen?|Womit willst du loeschen?");
-
- // REGELN: mit Platzhaltern im Fehlerstring
- AddCmd("spring|springe|huepf|huepfe&von|vom&baum|ast|eiche",
- #'action_huepfe,
- "Willst du von etwas @verben?|Von wo willst du @verben?");
-
- // SCHLECHT: eine unscharfe Regel - sie sollten eine Ausnahme sein (!)
- AddCmd("kletter","fun_klettern",1);
-
- // FALSCH: sehr schlecht, kein Imperativ verwendet
- // ausserdem sollte man fuer solche Syntaxen AddReadDetail benutzen
- AddCmd("lese","eval_lesen");
-
- // SIMPLE REGEL
- static int action_jump(string str); // Prototype (wegen closure)
- ...
- AddCmd("spring|springe|huepf|huepfe&von&baum|ast",#'action_jump,
- "Willst Du von etwas @verben?|Wovon willst Du @verben?");
- ...
- static int action_jump(string str) {
- write(break_string("Du springst vom Baum und kommst hart auf!",78));
- this_player()->move((XXXROOM+"boden"), M_GO, 0,
- "springt unelegant vom Baum","faellt vom Baum");
- this_player()->Defend(random(100),({DT_BLUDGEON}),([SP_RECURSIVE:1]),
- this_object());
- return 1;
- }
-
- // SIMPLE REGEL OHNE METHODE
- // mit Regeln kann man auch Aktivitaeten im Raum erlauben, ohne eine
- // Funktion aufrufen zu muessen: die letzte Regel ist fuer Spieler
- // unmoeglich zu erfuellen, die dazugehoerige Fehlermeldung wird mit
- // dem ^ (write-Flag) versehen und entsprechend an den Spieler
- // (und den Raum (hinter dem ^)) ausgegeben
- AddCmd("spring|springe&herunter|runter&\n\bimpossible",0,
- "Wohin oder wovon willst Du springen?|"
- "Du springst vom Baum und kommst hart auf.^"
- "@WER1 springt vom Baum und kommt hart auf.");
-
-## Komplexbeispiel: Regeln mit Fehlermeldungen ##
- ## Variante 1, OHNE REGELN ##
- // bei Nichtverwendung von Regeln muss man Parameter selbst
- auswerten AddCmd(({"bohr","bohre"}),#'action_bohren); ...
- private int action_bohren(string str) {
-
- string >>*<<tmp; notify_fail("Wo willst (etwas) Du
- bohren?n"); if(!str) return 0; // Tja, keine Argumente
- ... tmp=explode(str," "); // nach " " in Argument-Array
- aufspalten if((i=member(tmp,"loch"))>=0) { // aha, ab jetzt
- uebernehmen wir :)
-
- if((j=member(tmp[(i+1)..],"in"))<0 &&
- (j=member(tmp[(i+1)..],"durch"))<0)
-
- write("Willst Du das Loch in etwas bohren?n");
-
- else if((i=member(tmp[(j+1)..],"boden"))<0 &&
- (i=member(tmp[(j+1)..],"erde"))<0)
-
- write("In/Durch was willst du das Loch bohren?n");
-
- else {
- write("Du bohrst ein Loch in den Boden.n");
- say(this_player()->Name(WER)+" bohrt ein Loch in den
- Boden.n");
-
- } return 1; // "bohre loch" war so eindeutig, dass
- nur diese
-
- // Methode gemeint sein konnte, also brechen wir die
- // weitere Auswertung auf jeden Fall ab (und geben
- // eine write-Fehlermeldung)
-
- } // end if(..."loch") return 0; // "bohre" allein
- muss nicht diese Methode meinen,
-
- // also nur obige notify_fail()-Meldung, falls // sich
- nach dieser Methode gar keine sonst // angesprochen fuehlt
-
- } // end fun
-
- ## Variante 1a, OHNE REGELN ##
- // prinzipiell koennte die Methode action_bohren auch so //
- aussehen, ist aber nicht ganz so flexibel: private int
- action_bohren(string str) {
-
- string tmp; if(!str || (sprintf(str,"loch in erde%s",tmp)!=1
- &&
-
- sprintf(str,"loch durch erde%s",tmp)!=1 &&
- sprintf(str,"loch in boden%s",tmp)!=1 &&
- sprintf(str,"loch durch boden%s",tmp)!=1))
-
- notify_fail("Willst Du in irgendwas ein Loch bohren?n");
-
- else {
- ... return 1;
-
- } return 0;
-
- }
-
- ## Variante 2, MIT REGEL ##
- // das gleiche in etwa mal als einfache Regel
- AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
-
- "Was willst du (wohin) bohren?|" "Willst du das Loch in etwas
- bohren?|" "Wohin willst du das Loch bohren?");
-
- ... private int action_bohren(string str, mixed >>*<<param) {
-
- write("Du bohrst ein Loch in den Boden.n");
- say(this_player()->Name(WER)+" bohrt ein Loch in den
- Boden.n"); ... return 1;
-
- }
-
- ## Variante 3, MIT REGEL UND FEHLERMELDUNG ##
- // und nun mit Fehlermeldungen mit Ersetzungen, so dass wir mehr
- // auf die Eingaben des Spielers eingehen
- AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
-
- "Was willst du (wohin) @verben?|" "Willst du das Loch in
- etwas @verben?|" "@WER3 was willst du das Loch @verben?");
-
- ... private int action_bohren(string str, mixed >>*<<param) ...
-
- ## Variante 4, MIT REGEL, FEHLERMELDUNG UND RETURN 1 ##
- // in Variante 1 kam sinnvollerweise sehr frueh der Abbruch mit
- // "return 1;" und die Ausgabe von write-Fehlermeldungen, // das
- koennen wir auch
- AddCmd("bohr|bohre&loch&in|durch&erde|boden",#'action_bohren,
-
- "Was willst du (wohin) @verben?|" "Willst du das Loch in
- etwas @verben?^|" "@WER3 was willst du das Loch @verben?^");
-
- ... private int action_bohren(string str, mixed >>*<<param) ...
-
- ## Variante 5, MIT REGEL, FEHLERMELDUNG, RETURN 1, OHNE FUN ##
- // und falls in action_bohren() nichts ausser Ausgaben
- passiert, koennen // wir uns die auch ganz sparen indem wir
- eine nichterfuellbare Regel // samt Fehlermeldung bauen
- AddCmd("bohr|bohre&loch&in|durch&erde|boden&nimpossible",0,
-
- "Was willst du (wohin) @verben?|" "Willst du das Loch in
- etwas @verben?^|" "@WER3 was willst du das Loch
- @verben?^|" "Du @verbst ein Loch @WER3 den Boden.^@WER1
- @verbt " "ein Loch @WER3 den Boden.");
-
- --- Ende Komplexbeispiel Regeln mit Fehlermeldungen ---
-
-## Komplexbeispiel: Spezialregeln @PRESENT und @ID ##
- ## Variante 1, OHNE REGELN ##
- // oft agieren Kommandos auf Objekten im Raum, diese muessen
- dabei per // present() identifiziert werden: // Beispiel ist ein
- Geldautomat (den man besser mit einem Container // mit
- PreventInsert() basteln sollte)
- AddCmd(({"stopf","stopfe"}),#'action_stopf); ... private int
- action_stopf(string str) {
-
- string tmp,tmp2; object o;
-
- if(str && (sprintf("%s in automat%s",tmp,tmp2)==2 ||
- sprintf("%s in geldautomat%s",tmp,tmp2)==2 ||
- sprintf("%s in bankomat%s",tmp,tmp2)==2) {
-
- o=present(tmp,this_player()); if(o) {
-
- if(o->QueryProp(...)) {
- write(break_string(
- "Du stopfst "+o->name(WEN,1)+" in den
- Automaten.",78));
-
- say(...);
-
- } else {
- write(break_string(
- "Du versuchst "+o->name(WEN,1)+" in den Automaten
- zu stopfen, " "aber "+o->QueryPronoun(WER)+"
- passt nicht hinein.",78));
-
- say(...);
-
- }
-
- } else {
- write("Was willst du in den Automaten stopfen?n");
- say(....);
-
- } return 1;
-
- } notify_fail("Was willst du wohin stecken?n"); return 0;
-
- }
-
- ## Variante 2, MIT REGEL ##
- // einerseits koennen wir das Finden von Objekten in Inv und
- Env // integrieren und uns andererseits das Aufzaehlen aller
- IDs des // Automaten ersparen
- AddCmd("steck|stecke&@PRESENT&in&@ID",#'action_stopf,
-
- "Was willst du wohin stopfen?|" "Willst du @WEN2 in etwas
- stopfen?|" "Wohinein willst du @WEN2 stopfen?");
-
- ... // dabei werden wie immer die gefunden Matches als
- Parameterarray // uebergeben ... und die @PRESENT und @ID als
- Objekte! private int action_stopf(string str, mixed
- >>*<<param) {
-
- if(param[0]->QueryProp(...)) {
- write(break_string(
- "Du stopfst "+param[0]->name(WEN,1)+" in den
- Automaten.",78));
-
- say(...);
-
- } else {
- write(break_string(
- "Du versuchst "+param[0]->name(WEN,1)+" in den
- Automaten zu " "stopfen, aber
- "+param[0]->QueryPronoun(WER)+" passt nicht "
- "hinein.",78));
-
- say(...);
-
- } return 1;
-
- }
-
- --- Ende Komplexbeispiel Spezialregeln @PRESENT und @ID ---
-
-## Komplexbeispiel: gleiches Verb, mehrere Regeln ##
- // Das Problem mehrerer Regeln fuer ein Kommandoverb besteht darin,
- dass // letztlich nur eine der Fehlermeldungen zum Tragen kommt -
- welche // genau ist etwas vage. // Dabei kann man sich auf eines
- verlassen: juengere AddCmd werden // zuerst ausgewertet. Wenn sich
- das aendert, tretet euren EM.
-
- ## Problem 1: Mehrere Regeln weil mehrere Zwecke ##
- ## Variante 1 - GLEICHLAUTENDE FEHLERMELDUNG // fuer alles wird
- eine identische Fehlermeldung gesetzt, das ist // natuerlich
- nicht sehr flexibel oder schoen AddCmd("kriech|krieche&hoch|hin
- auf|hinaus|heraus|raus",#'result_kriech,
-
- "Wohin willst Du kriechen?");
-
- AddCmd("kriech|krieche&nach&oben",#'result_kriech,
- "Wohin willst Du kriechen??|Wohin willst Du kriechen?");
-
- AddCmd("kriech|krieche&aus&loch|grube|falle",#'result_kriech);
- "Wohin willst Du kriechen?|Wohin willst Du kriechen?");
-
- // oder man versucht eine bessere Regel zu schaffen, was hier
- durch // die Moeglichkeit von zwei oder drei Parameter
- unmoeglich ist
-
- ## Variante 2 - EIGENE AUSWERTUNG // es bietet sich also eigene
- Weiterauswertung an, was durch die // Uebergabe der getriggerten
- Verben erleichtert wird:
- AddCmd("kriech|krieche&hoch|hinauf|hinaus|heraus|raus|aus|nach",
-
- #'result_kriech, "Wohin willst Du kriechen?");
-
- ... static int result_kriech(string str, mixed >>*<<extra) {
-
- if(member(extra,"aus")>=0 &&
- !sizeof(({str}),"*.\<(hoehle|grube|falle)\>.*"))
-
- notify_fail("Woraus willst Du kriechen?n");
-
- else if(member(extra,"nach")>=0 && strstr(str,"oben")<0)
- notify_fail("In welche Richtung willst Du kriechen?n");
-
- else if(this_player()->QueryAttribute(A_DEX)>10 ||
- member(holding_root,this_player())) {
-
- write("Du kriechst mit Muehe heraus.n");
- this_player()->move((XXXROOM+"draussen"), M_GO, 0,
-
- "kriecht mit Muehe aus der Grube", "kriecht aus einer
- Grube");
-
- return 1;
-
- } else
- write("Du bist zu ungeschickt, halt Dich irgendwo
- fest.n"); return 1;
-
- } return 0;
-
- } // (ob sich der Aufwand fuer diese Beispielsyntax lohnt ist
- fraglich)
-
- ## Problem 2: mehrere Regeln, weil optionale Parameter ##
- // Manchmal will man optionale Parameter erlauben, die aber eine
- // Wirkung zeigen sollen:
- AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart,
-
- "Was oder wen willst du @verben?|" "Wie willst du @WEN2
- schlagen?");
-
- AddCmd("schlag|schlage&@ID",#'action_schlag,
- "Was oder wen willst du @verben?");
-
- // Da juengere AddCmd aelteren vorgehen, wird die komplexere
- Regel samt // ihrer Fehlermeldung nie ausgewertet, da ein
- "schlag ball hart" auch // die zweite Regel triggert.
-
- // anders herum: AddCmd("schlag|schlage&@ID",#'action_schlag,
-
- "Was oder wen willst du @verben?");
-
- AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart,
- "Was oder wen willst du @verben?|" "Wie willst du @WEN2
- schlagen?");
-
- // Jetzt wird die komplexere Regel zuerst ueberprueft und
- triggert // auch die richtige Funktion. // Leider kommt die
- Fehlermeldung nie zum Tragen, denn was durch Regel 2 //
- durchfaellt, triggert entweder Regel 1 oder faellt auch durch
- Regel 1 // durch und ueberschreibt dabei die Meldung.
-
- AddCmd("schlag|schlage&@ID",#'action_schlag,
- "Was oder wen willst du wie @verben?");
-
- AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart);
-
- // Fast perfekt. Besser wird es nicht.
-
- --- Ende Komplexbeispiel mehrere Regeln ---
-
-Letzte Aenderung: 22.12.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/AddDefender b/doc/sphinx/man/lfun/AddDefender
deleted file mode 100644
index 5b33e14..0000000
--- a/doc/sphinx/man/lfun/AddDefender
+++ /dev/null
@@ -1,50 +0,0 @@
-
-AddDefender()
-*************
-
-
-FUNKTION
-========
-
- void AddDefender(object friend);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- friend
- Objekt (normal Lebewesen), welches zukuenftig ueber Angriffe
- informiert werden soll oder diese sogar abwehrt.
-
-
-BESCHREIBUNG
-============
-
- Ein Lebewesen, welches angegriffen wird, kann andere Objekte ueber
- einen solchen Angriff per InformDefend() informieren oder ihnen
- sogar die Moeglichkeit geben, per DefendOther() direkt in den
- laufenden Angriff einzugreifen (Schaeden abwehren oder umwandeln).
- Im Normalfall handelt es sich hierbei um andere Lebewesen, welche
- als Verteidiger des angegriffenen Lebewesens auftreten: Daher der
- Name der Funktion.
- Die Objekte sind in Form eines Arrays in der Property P_DEFENDERS
- abgespeichert und koennen dort abgerufen werden. Natuerlich kann
- man weitere Objekte direkt dort eintragen, jedoch sollte man die
- hierfuer bereitgestellte Funktionen AddDefender() verwenden.
- Zum Loeschen von Eintraegen im Array steht ebenfalls eine Funktion
- bereit: RemoveDefender().
-
-
-SIEHE AUCH
-==========
-
- RemoveDefender(), InformDefend(), DefendOther(),
- P_DEFENDERS, /std/living/combat.c
-
-Last modified: Thu Jul 29 18:48:45 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/AddDetail b/doc/sphinx/man/lfun/AddDetail
deleted file mode 100644
index 951b48a..0000000
--- a/doc/sphinx/man/lfun/AddDetail
+++ /dev/null
@@ -1,110 +0,0 @@
-
-AddDetail()
-***********
-
-
-FUNKTION
-========
-
- void AddDetail(string|string* keys,
- string|string*|mapping|closure desc);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
-
-
-BESCHREIBUNG
-============
-
- Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
- bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
- Beschreibung <desc> ab:
- <desc> ist ein String.
- Beim Untersuchen wird dieser String zurueckgegeben.
- <desc> ist ein String-Array.
- Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
- <desc> ist ein Mapping.
- Das Mapping muss folgenden Aufbau haben:
- ([0: "Defaulttext",
- "rasse1": "r1text", ...]).
-
- Falls fuer die Rasse des das Detail untersuchenden Spielers ein
- Eintrag im Mapping existiert, wird der entsprechende Text
- zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
- rassenabhaengige Details moeglich. Siehe auch die Beispiele.
- <desc> ist eine Closure.
- In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
- zurueckgegeben. Die Closure bekommt dabei den Namen des Details
- als Parameter uebergeben.
-
- Fuer Details koennen Forscherpunkte eingetragen werden.
-
-
-BEISPIELE
-=========
-
- Ein schlichtes Detail:
-
- AddDetail(({"sofa","couch"}), "Eine kleine Couch.\n");
-
- Laengere Details sollten hierbei nicht per Hand umgebrochen werden,
- sondern man kann hierzu die Funktion break_string() nutzen:
-
- AddDetail("detail", break_string(
- "Du wolltest es ja nicht anders, jetzt musst Du Dir dieses "
- "fuerchterlich lange Detail durchlesen!!!", 78));
-
- Noetige Zeilenumbrueche bei Zeilenlaengen groesser 77 werden so
- automatisch generiert.
- Ein rassenabhaengiges Detail:
-
- AddDetail(({"bett","bettchen"}),
- ([0 :"Eine kleines Bett.\n", // Der Defaulttext
- "zwerg": // Die Rasse klein schreiben
- "Das Bett laedt geradezu zu einem Nickerchen ein.\n"]));
-
- Und nun ein Detail mit Closure (diese Version ersetzt das Verhalten
- von AddSpecialDetail).
-
- int hebel_betaetigt;
- ...
- string hebel(string str); // Funktion bekannt machen (Prototyping)
- ...
- AddDetail(({"hebel","schalter"}), #'hebel);
- ...
- string hebel(string key) {
- if(hebel_betaetigt)
- return "Der "+capitalize(key)+" steht auf EIN.\n";
- else
- return "Der "+capitalize(key)+" steht auf AUS.\n";
- }
-
- Man erhaelt verschiedene Ergebnisse beim Untersuchen, je nachdem
- ob das Flag hebel_betaetigt gesetzt ist oder nicht.
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
- P_TOUCH_DETAILS, P_SPECIAL_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddDrink b/doc/sphinx/man/lfun/AddDrink
deleted file mode 100644
index 4d722ec..0000000
--- a/doc/sphinx/man/lfun/AddDrink
+++ /dev/null
@@ -1,18 +0,0 @@
-
-AddDrink()
-**********
-
-
-BEMERKUNGEN
-===========
-
- Die Funktion AddDrink() sollte NICHT MEHR BENUTZT werden.
- Bitte AddToMenu() verwenden.
-
-
-SIEHE AUCH
-==========
-
- AddToMenu(), RemoveFromMenu()
-
-Last modified: Fri Mar 03 13:23:00 2000 by Paracelsus
diff --git a/doc/sphinx/man/lfun/AddExit b/doc/sphinx/man/lfun/AddExit
deleted file mode 100644
index 384975f..0000000
--- a/doc/sphinx/man/lfun/AddExit
+++ /dev/null
@@ -1,114 +0,0 @@
-
-AddExit()
-*********
-
-
-FUNKTION
-========
-
- void AddExit(string|string* cmd, closure|string dest);
-
-
-DEFINIERT IN
-============
-
- /std/room/exits
-
-
-ARGUMENTE
-=========
-
- string/string* cmd
- die Richtung(en), in die der Ausgang fuehrt
- string/closure dest
- das Ziel des Ausgangs mit Text/Closure
-
-
-BESCHREIBUNG
-============
-
- Es wird ein Ausgang in die Richtung(en) cmd eingefuegt. Die Art des
- Ausgangs haengt ab von dest:
-
- - ein String:
- - mit einem Dateinamen:
- Der Ausgang fuehrt in den Raum, den der Dateiname bezeichnet.
- - der Form "<msg>#dateiname"
- Der Ausgang fuehrt in den Raum, den der Dateiname bezeichnet,
- bei der Benutzung wird jedoch statt "<name> geht nach <richtung>"
- "<name> geht nach <msg>" ausgegeben.
- - eine Closure:
- Die Closure wird bei Nutzung des Ausgangs aufgerufen. Das entspricht
- eine SpecialExit - in der gerufenen Funktion muss man den Spieler
- selbst in den Zielraum bewegen.
- Gegebenenfalls kann das durch AddCmd() ersetzt werden.
-
-
-BEMERKUNGEN
-===========
-
- Man kann fuer den Dateinamen des Zielraumes auch einen relativen Pfad
- angeben. Die Auswertung erfolgt nach folgendem Schema:
- - "./<dateiname>"
- Es wird ein Zielraum relativ zum gleichen Verzeichnis wie dieser
- Raum angesprochen.
- - "../<dateiname>"
- Es wird ein Zielraum relativ zur Verzeichnisebene ueber der
- dieses Raumes angesprochen (analog mit mehrerern "../..")
-
- Mittels P_HIDE_EXITS kann man Ausgaenge verstecken.
-
- Bei der Benutzung eines Ausgangs wird der Hook H_HOOK_EXIT_USE
- ausgeloest.
-
-
-BEISPIELE
-=========
-
- ### normale Ausgaenge ###
- // Beim Kommando "sueden" kommt: "<name> geht nach Sueden."
- AddExit("sueden", "/gilden/abenteurer");
-
- // Beim Kommando "sueden" kommt: "<name> geht in die Gilde."
- AddExit("sueden", "in die Gilde#/gilden/abenteurer");
-
- ### Ausgaenge mit relativen Pfaden ###
- // Der Name des Raumes sei "/d/inseln/wargon/hafen1"
- // Dieser Ausgang geht nach "/d/inseln/wargon/kneipe":
- AddExit("norden", "./kneipe" );
-
- // Und dieser nach "/d/inseln/anthea/anlege":
- AddExit("sueden", "../anthea/anlege" );
-
- ### dynamische Ausgaenge ###
- // ein Ausgang soll nur von Froeschen benutzbar sein:
-
- static int lochfkt(string dir); // Prototyp
- ...
- AddExit("loch", #'lochfkt);
- // auch identisch zu:
- // AddSpecialExit("loch", #'lochfkt); [eine Closure] oder
- // AddSpecialExit("loch", "lochfkt"); [ein Funktionsname]
-
- static int lochfkt(string dir) {
- if (!(this_player()->QueryProp(P_FROG))) {
- // Kein Frosch => passt nicht!
- notify_fail("Du bist zu gross!\n");
- return 0;
- }
- // Meldungen werden im move() gleich mitgegeben
- return this_player()->move("/room/loch", M_GO, 0,
- "huepft ins Loch", "huepft herein");
- }
-
-
-SIEHE AUCH
-==========
-
- AddSpecialExit(), GetExits(),
- RemoveExit(), RemoveSpecialExit(),
- GuardExit(),
- H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
-
-Letzte Aenderung: 22.12.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/AddExp b/doc/sphinx/man/lfun/AddExp
deleted file mode 100644
index a8bf488..0000000
--- a/doc/sphinx/man/lfun/AddExp
+++ /dev/null
@@ -1,56 +0,0 @@
-
-AddExp()
-********
-
-
-FUNKTION
-========
-
- int AddExp(int e)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- int e - Anzahl der hinzuzufuegenden (abzuziehenden) XP
-
-
-BESCHREIBUNG
-============
-
- Dem Living werden e XP auf seine bisherigen P_XP addiert.
-
- Falls es sich um einen Spieler mit P_KILLS>0 handelt und
- e positiv ist, bekommt der Spieler keine XP gutgeschrieben.
-
- P_LAST_XP wird aktualisiert.
-
-
-BEMERKUNG
-=========
-
- - positive und negative Werte sind moeglich
- - P_XP wird nicht <0 gesetzt.
-
-
-RUECKGABEWERT
-=============
-
- int - neuer XP-Wert
-
-
-SIEHE AUCH
-==========
-
- Funktionen: do_damage(), DistributeExp()
- Properties: P_XP, P_LAST_XP
- Sonstiges: P_NO_XP, P_NO_SCORE
- create_default_npc()
-
-14.Feb 2007 Gloinson
diff --git a/doc/sphinx/man/lfun/AddExtraLook b/doc/sphinx/man/lfun/AddExtraLook
deleted file mode 100644
index 7436f7e..0000000
--- a/doc/sphinx/man/lfun/AddExtraLook
+++ /dev/null
@@ -1,130 +0,0 @@
-
-AddExtraLook()
-**************
-
-AddExtraLook() varargs int AddExtraLook(string look, [int duration,
-string key,
-
- string lookende, object ob]);
-
-
-DEFINIERT IN
-============
-
- /std/living/description.c
-
-
-BESCHREIBUNG
-============
-
- Der Extralook erscheint in der Langbeschreibung des Lebewesens.
- Eintraege koennen mit dieser Funktion hinzugefuegt werden. Dies ist der
- bevorzugte Weg, wenn ansonsten extra ein Objekt im Spielerinventar abgelegt
- werden muesste.
-
-
-
- Alle Parameter bis auf <look> sind optional.
-
-
-ARGUMENTE
-=========
-
- - string look:
- String, der in der Langbeschreibung des Lebewesens zusaetzlich ausgegeben
- wird.
- Kann auch ein Funktionsname sein, wenn <ob> angegeben wird (s.u.).
- - int duration:
- > 0: Wie lang bleibt der Extralook gueltig (in Sekunden)? Anschliessend
- wird er automatisch geloescht.
- 0: Dieser Eintrag bleibt unbegrenzt gueltig.
- < 0: Dieser Eintrag bleibt bis zum Ende/Reboot bestehen.
- - string key:
- Schluesselwort, unter dem der Eintrag registriert wird und mit dem man ihn
- auch mittels RemoveExtraLook() entfernen kann. Sollte natuerlich
- moeglichst eindeutig sein. ;-) Wenn <key> nicht angeben wird, wird der
- Objektname (object_name()) benutzt.
- - string lookende:
- String, der an das Lebewesen (nur bei Spielern) ausgegeben wird, wenn der
- eingetragene Extralook abgelaufen ist.
- Kann auch ein Funktionsname sein, wenn <ob> angegeben wird.
- - object ob:
- Wenn hier ein Objekt angegeben wird, werden <look> und <lookende> als
- Funktonsnamen aufgefasst. Diese Funktionen werden in <ob> aufgerufen, wenn
- der Extralook des Lebewesen angezeigt wird bzw. der eingetragene Extralook
- abgelaufen ist. Diese Funktionen bekommen das jeweilige Lebenwesen als
- Objekt uebergeben. Sie muessen einen String zurueckliefern, der ausgegeben
- wird. Dieser String wird direkt so ausgeben, also selber fuer Zeilenumbruch
- etc. sorgen!
- WICHTIG: Das Objekt sollte nach Moeglichkeit eine Blueprint sein, da das
- ganze nix mehr ausgibt, sobald der Clone zerstoert wird, falls hier
- einer angeben wird. Wenn ihr keine BP uebergebt: Wisst, was ihr tut. ;-)
-
-
-RUECKGABEWERTE
-==============
-
- > 0, falls der Eintrag erfolgreich registriert wurde.
- < 0 sonst.
- -1: <key> war nicht gueltig und es konnte keiner ermittelt werden.
- -2: <look> war kein gueltiger String.
- -3: <duration> war kein Integer.
- -4: unter <key> gibt es schon einen Eintrag.
-
-
-BEMERKUNGEN
-===========
-
- Die Strings <look> und <lookende> werden vor Ausgabe durch
- replace_personal() geschickt, daher ist die Verwendung von @WER1, @WESSEN1
- usw. moeglich (s. replace_personal). Dies gilt aber _nicht_ fuer den Fall,
- dass die entsprechenden Funktionen in <ob> gerufen werden, dann muessen die
- Funktionen selber umbrechen, etc.
- Nach replace_personal() werden die Strings noch von break_string() auf 78
- Zeilen umgebrochen, allerdings bleiben dabei vorhandene Umbrueche erhalten.
- Die Meldung von <lookende> bzw. der Funktionsaufruf erfolgt, wenn der
- Extralook der Lebewesen das erste Mal nach Ablauf der Gueltigkeit aufgerufen
- wird.
-
-
-BEISPIELE
-=========
-
- # einfacher Eintrag, "fuer die Ewigkeit"
- living->AddExtraLook("@WER1 hat den Drachengott der SSP besiegt.");
-
- # Eintrag der nach 1h automatisch weg ist.
- living->AddExtraLook("@WER1 ist ganz mit Marmelade bedeckt.", 3600);
-
-
-
- # Eintrag mit bestimmten Schluessel, damit man ihn wieder entfernen kann.
- living->AddExtraLook("@WER1 ist ganz mit Marmelade bedeckt.", 3600,
- "humni_marmeladen_look");
-
-
-
- # Mit "Ende"-Meldung, aber kein eigener Schluessel.
- living->AddExtraLook("@WER1 ist patschnass.", 1200, 0,
- "Du bist endlich wieder trocken. Puuh.");
-
-
-
- # Mit Objekt, was den Extralook dynamisch erzeugt
- living->AddExtraLook("get_my_special_extralook", 3600, 0, 0, this_object());
- In diesem Fall muss this_object() natuerlich die Funktion
- "get_my_special_extralook()" definieren, die einen String zurueckgibt.
-
- # Mit Objekt, was den Extralook und die Endemeldung dynamisch erzeugt
- living->AddExtraLook("get_my_special_extralook", 3600, 0,
- "extralookende", this_object());
-
-
-SIEHE AUCH
-==========
-
- RemoveExtraLook(),
- replace_personal(), break_string()
- P_INTERNAL_EXTRA_LOOK
-
-14.05.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/AddFixedObject b/doc/sphinx/man/lfun/AddFixedObject
deleted file mode 100644
index 5875ee2..0000000
--- a/doc/sphinx/man/lfun/AddFixedObject
+++ /dev/null
@@ -1,74 +0,0 @@
-
-AddFixedObject()
-****************
-
-
-FUNKTION
-========
-
- varargs void AddFixedObject(string str, int val, mixed ids);
-
-
-DEFINIERT IN
-============
-
- /std/room/shop.c
-
-
-ARGUMENTE
-=========
-
- str
- Der absolute Filename eines Objekts, das in quasi beliebiger Menge
- vom betreffenden Laden verkauft werden soll.
- val
- Sofern angegeben der angenommene Wert des Objekts. Falls val nicht
- angegeben oder 0 ist, wird der Wert aus dem angegebenen Objekt
- selbst ermittelt.
- Der Verkaufspreis ist 3 * Wert des Objekts.
- ids
- String oder Stringarray mit der ID oder den IDs, ueber die man das
- Objekt im Laden ansprechen kann. Falls nicht angegeben, wird die
- ID-Liste aus der blueprint des Objekts ausgelesen.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann man einem Laden mitteilen, dass ein Objekt
- in ihm in unbegrenzter Anzahl verkauft werden soll.
- WICHTIG: Das zu verkaufende Objekt sollte dies insofern unterstuetzen,
- dass die Blueprint die notwendigen Informationen
- (P_SHORT, P_IDS, P_VALUE, P_LONG, P_NAME) beinhaltet. Dies bedeutet im
- einfachsten Fall, dass im create() auf
- if (!clonep()) return;
- verzichtet wird.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- AddFixedObject("/obj/fackel", 5000, "fackel");
- Der Laden verkauft Fackeln zum Preis von 3*5000 Goldmuenzen und man
- kann die Fackel (ausser ueber die Inventarnummer) nur mittels der
- id "fackel" kaufen.
-
-
-
- AddFixedObject("/obj/fackel");
- Der Laden verkauft Fackeln zum dreifachen Wert dessen, was im Objekt
- /obj/fackel.c angegeben ist (derzeit sind das 5 Muenzen) und laesst
- alle IDs zu, die in /obj/fackel.c angegeben sind. Derzeit ist das
- auch nur "fackel".
-
-
-SIEHE AUCH
-==========
-
- RemoveFixedObject(), SetStorageRoom(), /std/store.c
diff --git a/doc/sphinx/man/lfun/AddFood b/doc/sphinx/man/lfun/AddFood
deleted file mode 100644
index b870a5e..0000000
--- a/doc/sphinx/man/lfun/AddFood
+++ /dev/null
@@ -1,18 +0,0 @@
-
-AddFood()
-*********
-
-
-BEMERKUNGEN
-===========
-
- Die Funktion AddFood() sollte NICHT MEHR BENUTZT werden.
- Bitte AddToMenu() verwenden.
-
-
-SIEHE AUCH
-==========
-
- AddToMenu(), RemoveFromMenu()
-
-Last modified: Fri Mar 03 13:23:00 2000 by Paracelsus
diff --git a/doc/sphinx/man/lfun/AddFuel b/doc/sphinx/man/lfun/AddFuel
deleted file mode 100644
index cd0b25e..0000000
--- a/doc/sphinx/man/lfun/AddFuel
+++ /dev/null
@@ -1,51 +0,0 @@
-
-AddFuel()
-*********
-
-
-FUNKTION
-========
-
- void AddFuel(int fuel);
-
-
-DEFINIERT IN
-============
-
- /std/lightsource.c
-
-
-ARGUMENTE
-=========
-
- fuel
- Die zusaetzliche Brenndauer in Sekunden.
-
-
-BESCHREIBUNG
-============
-
- Die Brenndauer der Lichtquelle wird um fuel Sekunden verlaengert.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Es werden keine Checks durchgefuehrt! Wenn man seine Lichtquelle
- nachfuellbar gestalten will, sollte die Nachfuellfunktion vor dem
- AddFuel()-Aufruf nachsehen, wie voll die Lichtquelle noch ist, und fuel
- entsprechend begrenzen.
-
-
-SIEHE AUCH
-==========
-
- /std/lightsource.c
-
-Last modified: Wed May 8 10:16:39 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/AddFun b/doc/sphinx/man/lfun/AddFun
deleted file mode 100644
index 5ba6cf1..0000000
--- a/doc/sphinx/man/lfun/AddFun
+++ /dev/null
@@ -1,85 +0,0 @@
-
-AddFun()
-********
-
-
-FUNKTION
-========
-
- void AddFun(string fun, int next);
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- fun
- Name der Funktion.
- next
- Zeit bis zur naechsten Fahrplanstation.
-
-
-BESCHREIBUNG
-============
-
- Dem Fahrplan wird der Aufruf der Funktion fun, die im Transporter
- definiert sein muss, hinzugefuegt. Nach Aufruf der Funktion vergehen
- next Sekunden, bis die naechste Station angefahren wird.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- Wenn ein zufaellig ausgewaehlter Passagier eines Schiffes unterwegs
- seekrank werden soll, koennte man das wie folgt realisieren:
-
- create()
- {
- ...
-
- AddFun("seekrank", 5);
- ...
- }
-
- seekrank()
- {
- object *passagiere, opfer;
-
- // soll nicht immer passieren
- if (random(5))
- return;
-
- // Opfer auswaehlen
- passagiere = QueryPassengers();
- if (sizeof(passagiere))
- opfer = passagiere[random(sizeof(passagiere))];
-
- // Und viel Spass...
- tell_object(opfer,
- "Du wirst seekrank! Schnell stuerzt Du zur Reling um Dich zu\n"
- +"uebergeben.\n");
- tell_room(this_object(),
- sprintf("%s ueberkommt die Seekrankheit!\n%s stuerzt an die Reling, "
- +"um sich zu uebergeben.\n",
- capitalize(opfer->name(WEN)),
- capitalize(opfer->QueryPronoun(WER))), ({ opfer }) );
- }
-
-
-SIEHE AUCH
-==========
-
- AddRoute(), AddMsg(), /std/transport.c
-
-Last modified: Wed May 8 10:16:46 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/AddId b/doc/sphinx/man/lfun/AddId
deleted file mode 100644
index 8c2aa4e..0000000
--- a/doc/sphinx/man/lfun/AddId
+++ /dev/null
@@ -1,75 +0,0 @@
-
-AddId()
-*******
-
-
-FUNKTION
-========
-
- void AddId(string|string* ids);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- ids
- String oder Array von Strings mit den Bezeichnungen, mit denen
- sich sich das Objekt ansprechen lassen soll.
-
-
-BESCHREIBUNG
-============
-
- Jedes Objekt sollte sich auf die eine oder andere Weise ansprechen
- lassen. Zu diesem Zweck kann man dem Objekt mit dieser Funktion
- Bezeichner uebergeben.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Jedes Objekt sollte man zumindest mit seiner Kurzbeschreibung
- ansprechen koennen! Fuer Abfragen von Questobjeken o.ae. sollte man
- zusaetzlich IDs verwenden, die Sonderzeichen wie "\n" oder "\t"
- enthalten, damit sichergestellt ist, dass der Spieler auch wirklich die
- richtigen Objekte dabeihat.
-
-
-BEISPIELE
-=========
-
- AddId( "buch" );
- AddId( "buechlein" );
-
- Das Objekt laesst sich jetzt als "buch" und als "buechlein" ansprechen.
-
- AddId( ({ "buch", "buechlein" }) );
-
- Diese Zeile bewirkt das gleiche wie die obigen zwei Zeilen.
-
- AddId( ({ "puzzle", "\nquest_puzzle" }) );
-
- Der Spieler kann das Objekt als "puzzle" ansprechen, questrelevante
- Objekte koennen mit der ID "\nquest_puzzle" nach ihm suchen.
-
-
-SIEHE AUCH
-==========
-
- AddAdjective(), RemoveId(), id(), present(), /std/thing/description.c
-
- -----------------------------------------------------------------------
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddInfo b/doc/sphinx/man/lfun/AddInfo
deleted file mode 100644
index 759a300..0000000
--- a/doc/sphinx/man/lfun/AddInfo
+++ /dev/null
@@ -1,243 +0,0 @@
-
-AddInfo()
-*********
-
-
-FUNKTION
-========
-
- varargs void AddInfo( frage, meldung
- [, indent [, [silent [, casebased] ] ] );
-
-
-DEFINIERT IN
-============
-
- /std/npc/info.c
-
-
-ARGUMENTE
-=========
-
- string/string* frage
- Schluesseltext(e) auf die Informationen gegeben werden sollen.
- string/closure meldung
- Information, die gegeben werden soll/Closure
- string indent
- Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
- int/string silent
- Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
- string/closure casebased
- Closure mit Returnwert string oder int.
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Spieler ein NPC mittels "frage <monstername> nach <frage>" nach
- einer Information mit dem Schluessel 'frage' fragt, so wird die
- entsprechende 'meldung' ausgegeben (oder die Closure in 'meldung'
- gerufen und der zurueckgegebene Text ausgegeben). Der Meldung wird
- der Name des Monsters vorangestellt.
-
- Frage:
- Schluessel muessen kleingeschrieben sein, koennen aber Leerzeichen
- enthalten.
-
- Meldung:
- Wenn kein 'indent' angegeben ist, muss man die Meldung selbst
- umbrechen.
-
- Indent:
- Wird ein 'indent' angegeben so wird jeder Zeile hinter dem
- Monsternamen noch das 'indent' vorangesetzt. Zusaetzlich wird
- 'meldung' auf jeden Fall sauber umgebrochen.
- Ein typisches indent ist "sagt: ".
-
- Silent:
- Bei 'silent'==1 erfolgt keine Textausgabe der Antwortmeldung im Raum,
- ist 'silent' ein String, so wird jener an alle anderen Spieler ausser
- dem Fragesteller im Raum ausgegeben.
-
- Casebased:
- Die als Closure angegebene Methode entscheidet, ob oder wie der NPC
- auf diese Frage antworten soll:
- - return 0: normale Antwort mit "meldung"
- - return 1: keine Antwort/Antwort mit DEFAULT_NOINFO
- - return string: Antwort mit string unter Beruecksichtigung eines
- indent
-
- Die Strings von 'silent' und 'meldung' werden geparsed.
- Dabei koennen die @...-Tags von replace_personal() verwendet werden,
- Objekt 1 ist this_player(). Ersetzte String am Satzanfang werden
- automatisch gross geschrieben.
- AddInfo() konvertiert die alten Schluesselworte @WER, @WESSEN, @WEM,
- @WEN zu denen von replace_personal().
-
- Mittels der in <npc.h> definierten Frage DEFAULT_INFO kann eine
- Meldung gesetzt werden, die gegeben werden soll, wenn der Spieler
- etwas fragt, auf das keine Antwort vorgegeben ist (das loest
- SetProp(P_DEFAULT_INFO, <text>) ab).
-
-
-BEISPIELE
-=========
-
- ### eine Standardantwort setzen ###
- AddInfo(DEFAULT_INFO, "starrt Dir boese in die Augen.\n");
- // identisch zu
- SetProp(P_DEFAULT_INFO, "starrt Dir boese in die Augen.\n");
-
- ### einfache Beispiele, auch mit casebased ###
- AddInfo(({"knete","kohle"}),
- "sagt: ich habe so etwas nicht.\n");
- AddInfo("geld",
- "Ich habe zwar kein Geld, aber ... blablabla ...",
- "sagt: " );
- AddInfo("muenzen",
- "fluestert: Du willst Geld?\n",
- 0,
- "fluestert @WEM etwas zu.\n");
-
- // "frage monster nach geld": alle im Raum hoeren
- // Das Monster sagt: Ich habe zwar kein Geld, aber ...
- // Das Monster sagt: ... blablabla ...
-
- // "frage monster nach muenzen":
- // - der Fragensteller hoert:
- // "Das Monster fluestert: Du willst Geld?"
- // - alle andere hoeren:
- // "Das Monster fluestert <Fragenstellernamen> etwas zu."
-
- ### dynamisch ###
- // ein Prototyp, damit wir die Methode bekannt machen
- static string query_kekse();
- ...
- AddInfo(({"keks","kekse"}),
- #'query_kekse, // ein Verweis auf die Funktion
- "sagt: ");
- ...
- static string query_kekse() {
- if(present("keks"))
- return("Ich hab noch welche. Aetsch!");
- return("Menno. Keine mehr da!");
- }
-
- // "frage monster nach keks":
- // - wenn es noch Kekse hat, hoeren alle:
- // "Das Monster sagt: Ich hab noch welche. Aetsch!
- // - sonst:
- // "Das Monster sagt: "Menno. Keine mehr da!
-
- ### dynamischer ###
- // ein Prototyp, damit wir die Methode bekannt machen
- static string query_kekse();
- static mixed case_fighting();
- ...
- AddInfo(({"keks","kekse"}),
- #'query_kekse," // ein Verweis auf die Funktion
- sagt: ",
- 0, // nicht silent :)
- #'case_fighting); // noch ein Funktionsverweis
- ...
- static string query_kekse() {
- if(present("keks"))
- return("Ich hab noch welche. Aetsch!");
- return("Menno. Keine mehr da!");
- }
-
- static mixed case_fighting() {
- if(InFight())
- return("Keine Zeit fuer Kekse. Muss kaempfen.");
- return 0;
- }
-
- // "frage monster nach keks":
- // - wenn es kaempft, hoeren alle:
- // "Das Monster sagt: Keine Zeit fuer Kekse. Muss kaempfen.
- // - sonst, wenn es noch Kekse hat, hoeren alle:
- // "Das Monster sagt: Ich hab noch welche. Aetsch!
- // - sonst:
- // "Das Monster sagt: "Menno. Keine mehr da!
-
-
- ### dynamisch und komplex ###
- // ein Prototyp, damit wir die Methode bekannt machen
- static string question_gold();
- ...
-
- // "gold" wird eine Closure auf die Methode question_gold()
- // zugewiesen, ausserdem soll es still bleiben (wir informieren
- // den Restraum selbst)
- AddInfo("gold",#'question_gold,"murmelt: ",1);
- ...
-
- // los gehts, wir generieren unsere Antwort selbst
- static string question_gold() {
- int money;
- string *y, objstr;
- object o;
- // wieviel Kohle hat der Spieler
- money=this_player()->QueryMoney();
- y=allocate(0);
- // und jetzt suchen wir die Dinge aus Gold
- o=first_inventory(this_player());
- while(o) {
- if(o->QueryMaterial(MAT_GOLD)>0 &&
- strstr(object_name(o),"/obj/money"))
- y+=({o->name(WER,1)});
- o=next_inventory(o);
- }
-
- // das geht an alle anderen im Raum, silent bietet sich hier
- // nicht an, weil es mehrere Moeglichkeiten gibt
- say(break_string(
- Name(WER,1)+" murmelt "+
- this_player()->name(WEM,1)+
- " etwas zu"+
- ((money || sizeof(y))?
- " und glotzt "+
- this_player()->QueryPronoun(WEN)+" gierig an.":
- "."),78),({this_player()}));
-
- // und hier die Antwort an den Spieler selbst, mit vielen
- // Verzweigungen fuer dessen Besitztum
- return("Ich hab kein Gold bei mir."+
- ((money || sizeof(y))?
- " Aber du "+
- (money?"hast ja jede Menge Kohle bei dir, so etwa "+money+
- " Muenzen."+
- (sizeof(y)?
- " Ausserdem "+
- ((sizeof(y)==1)?"ist":"sind")+
- " auch noch "+CountUp(y)+" aus Gold.":
- ""):
- (sizeof(y)?" Aber was du so bei dir hast: "+
- CountUp(y)+
- (sizeof(y)==1?" ist":" sind")+
- " aus Gold.":"")):
- ""));
- }
-
- // "frage monster nach gold"
- // - der Fragesteller hoert zB:
- // Das Monster murmelt: Ich hab kein Gold bei mir. Aber du hast ja
- // Das Monster murmelt: jede Menge Kohle bei dir, so etwas <number>
- // Das Monster murmelt: Muenzen. Ausserdem ist/sind noch <object1>
- // Das Monster murmelt: und <object2> aus Gold."
- // - die Umstehenden hoeren:
- // "Das Monster murmelt @WEM etwas zu."
- // oder
- // "Das Monster murmelt @WEM etwas zu und glotzt ihn/sie gierig an."
-
-
-SIEHE AUCH
-==========
-
- Verwandt: AddSpecialInfo(L), RemoveInfo(L)
- Props: P_PRE_INFO, P_DEFAULT_INFO
- Files: /std/npc/info.c
- Loggen: P_LOG_INFO
- Interna: GetInfoArr, do_frage
-
-7.Apr 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/AddItem b/doc/sphinx/man/lfun/AddItem
deleted file mode 100644
index 222b24d..0000000
--- a/doc/sphinx/man/lfun/AddItem
+++ /dev/null
@@ -1,184 +0,0 @@
-
-AddItem()
-*********
-
-
-FUNKTION
-========
-
- varargs object AddItem(mixed filename,int refresh,mixed props);
-
-
-DEFINIERT IN
-============
-
- /std/room/items.c
- /std/npc/items.c
-
-
-ARGUMENTE
-=========
-
- filename
- String mit dem Namen des zu erzeugenden Objektes oder Array von
- Strings mit den Namen der zu erzeugenden Objekte. Bei einem Array
- wird ein Name zufaellig ausgewaehlt.
- refresh
- Wann und wie soll das Objekt erneuert werden:
- - REFRESH_NONE - Kein Refresh bis zum Neuladen des Raums
- - oder NPCs.
- - REFRESH_DESTRUCT - Refresh bei Reset, wenn Item zerstoert
- wurde.
- - REFRESH_REMOVE - Refresh bei Reset, wenn Item entfernt wurde.
- - REFRESH_ALWAYS - Neuer Clone bei jedem Reset.
- - REFRESH_MOVE_HOME - Objekt wird bei Reset automatisch
- zurueckgeholt, wenn es wegbewegt wurde.
- (nur in Raeumen!)
- Bei NPC's gilt zusaetzlich:
- - CLONE_WEAR - Item Anziehen, wenn es eine Ruestung ist.
- - CLONE_WIELD - Item zuecken, wenn es eine Waffe ist.
- - CLONE_NO_CHECK - Zuecken oder Anziehen ohne Ueberpruefungen.
- props (optional)
- Mapping mit denen in einem geclonten Objekt zu setzenden
- Properties oder 1 fuer die Erzeugung einer Blueprint.
-
-
-RUeCKGABEWERT
-=============
-
- Innerhalb von Raeumen wird das erzeugte Objekt zurueckgeliefert. Bei
- NPC's klappt dies leider nicht, da dort die Objekte nicht sofort
- erzeugt werden, sondern erst, nachdem der NPC an seinen
- Bestimmungsort transferiert wurde. Daher wird bei NPC immer 0
- zurueckgegeben.
-
-
-BESCHREIBUNG
-============
-
- Abhaengig von <filename> und <props> wird ein Objekt erzeugt und in
- den Raum bzw. NPC bewegt. Dabei gibt es folgende Moeglichkeiten:
- - <filename> ist ein Dateiname.
- Es wird ein Clone dieser Datei erstellt oder (wenn <props>=1 ist)
- deren Blueprint verwendet.
- - <filename> ist ein Array von Dateinamen.
- Es wird eine Datei zufaellig aus dem Array ausgewaehlt und von
- dieser Datei ein Clone erstellt oder (wenn <props>=1 ist) deren
- Blueprint verwendet.
- Uebergibt man fuer <props> ein Mapping mit dem Aufbau
- ([prop_name:prop_wert,...]),
- so werden diese Properties im erzeugten Objekt gesetzt.
- Der Parameter <refresh> gibt an, was waehrend eines Resets im Raum
- bzw. in NPC's oder was beim Erzeugen von NPC's geschehen soll:
- In <rooms.h> sind dazu folgende Moeglichkeiten definiert:
- - REFRESH_NONE
- Das Objekt wird niemals erneuert; falls es zerstoert wurde, wird
- es erst dann wieder erzeugt, wenn der Raum erneut geladen bzw.
- der NPC neu erzeugt wird. Man beachte, dass nicht jeder NPC
- wirklich refreshende Objekte benoetigt, REFRESH_NONE spart
- hierbei sowohl Rechenzeit als auch Speicher!
- - REFRESH_DESTRUCT
- Das Objekt wird nur dann erneuert, wenn es in der Zwischenzeit
- zerstoert wurde (bei NPC's ist das zum Beispiel der Fall, wenn
- sie getoetet wurden).
- REFRESH_NONE & REFRESH_DESTRUCT + Blueprint-Objekt bedeutet bei
- NPC's ein Unique-Objekt, es wird also nicht beim Neuerzeugen des
- NPC's zurueckgesetzt.
- - REFRESH_REMOVE
- Das Objekt wird erneuert, wenn es sich nicht mehr im Raum bzw.
- im NPC befindet. Das kein sein, weil es zerstoert wurde, aber
- auch zum Beispiel in folgenden Faellen:
- * weil es jemand mitgenommen hat
- (in Raeumen bei Gegenstaenden)
- * weil es fortgegangen ist
- (in Raeumen bei NPC's, die herumlaufen)
- * weil es weggeworfen wurde
- (in NPC's bei Gegenstaenden)
- - REFRESH_ALWAYS
- Das Objekt wird immer erneuert. Von dieser Refreshmethode sollte
- man allerdings Abstand nehmen, da sich sonst mit der Zeit
- gewaltige Mengen von Objekten ansammeln koennen!
- - REFRESH_MOVE_HOME
- Das Objekt wird in einen Raum zurueckbewegt, sofern es noch
- existiert, jedoch nicht mehr in dem Raum ist. Sinnvoll ist dies
- eigentlich nur fuer Lebewesen, funktioniert aber auch bei
- beliebigen Objekten. Hauptsaechlich geht es hierbei darum,
- herumlaufende NPCs oder bei erzwungenen Bewegungen nicht von
- P_GUARD zurueckgehaltene NPCs wieder an einen definierten
- Ausgangsort zurueckzubringen.
- Hat man in Raeumen als <filename> ein Array von Dateinamen
- uebergeben, so wird beim Reset jedesmal aufs Neue ein zufaelliges
- Objekt aus der Liste ausgewaehlt (nicht in NPC's).
- In NPC's gilt der Grundsatz der Vermeidung von ueberfluessigen
- Objekten im MUD. Neu erzeugt werden Objekte beim Erzeugen eines
- NPC's oder bei einem Reset im selbigen. Anstatt die Objekte gleich
- neu zu erschaffen, wird erst geschaut, ob sich identische Objekte
- schon im Raum befinden. Ist dies der Fall, so nimmt der NPC sie auf,
- ruft jedoch vorher nochmals create() in ihnen auf!
- (noetig wegen moeglicher Veraenderungen an den Objekten)
- Was dann passiert, haengt von weiteren Angaben in <refresh> ab.
- Folgende weitere Moeglichkeiten sind in <npc.h> definiert:
- - CLONE_WEAR
- Ist das hinzugefuegte Item eine Ruestung, so wird sie nach
- Aufnahme oder Neuerzeugung angezogen.
- - CLONE_WIELD
- Ist das hinzugefuegte Item eine Waffe, so wird sie nach Aufnahme
- oder Neuerzeugung gezueckt.
- - CLONE_NO_CHECK
- Hiermit verhindert man eine Ueberpruefung, ob eine Ruestung
- angezogen oder eine Waffe gezueckt werden kann. Es ist jedoch
- Vorsicht geboten: So kann es ohne weiteres passieren, dass ein NPC
- mehrere Ruestungen gleichen Typs angezogen oder mehrere Waffen
- gezueckt hat.
- Benutzt man Blueprints (<props>=1) mit REFRESH_REMOVE oder
- REFRESH_ALWAYS, so kann es zu ungewollten Ueberraschungen kommen, da
- die Blueprint dann unabhaengig von ihrem momentanen Aufenthaltsort
- wieder in den Raum bzw. NPC bewegt wird, von dem sie erzeugt wurde!
-
-
-BEMERKUNGEN
-===========
-
- Wenn man Blueprints benutzt, sollte man daran denken, dass sich von
- dieser dann keine Clones mehr erstellen lassen!
- RemoveItem() zum Entfernen von Items ist nur fuer Raeume definiert!
-
- Die Option CLONE_NEW ist veraltet. Die Objekte werden nun immer
- neu erzeugt. Die Option darf noch angegeben werden, hat aber keine
- Bedeutung mehr.
-
-
-BEISPIELE
-=========
-
- // Ein Wuerfel, der sich nach Entfernen erneuert:
- AddItem("/obj/misc/wuerfel",REFRESH_REMOVE);
- // Ein etwas veraenderter Wuerfel:
- AddItem("/obj/misc/wuerfel",
- REFRESH_REMOVE,
- ([P_SHORT :"Ein schwerer Wuerfel",
- P_WEIGHT:100]));
- // Eine Blueprint, die nur einmal im MUD existiert. Wenn sie
- // zerstoert wurde, wird sie bei Reset neu erzeugt:
- AddItem("/mon/angsthase",REFRESH_DESTRUCT,1);
- // Eine Blueprint, die nur einmal im MUD existiert. Wenn sie aus dem
- // Raum entfernt wurde, wird sie bei Reset zurueckgeholt:
- AddItem("/mon/angsthase",REFRESH_MOVE_HOME,1);
- // Ein zufaelliges Objekt:
- AddItem(({"/obj/misc/lolli",
- "/obj/misc/bonbon",
- "/obj/misc/bier"}),REFRESH_REMOVE);
- // Eine Ruestung, die auch angezogen wird (nur in NPC's):
- AddItem("/ruestung/sommerkleid",REFRESH_REMOVE|CLONE_WEAR);
- // Eine Unique-Waffe, die auch gezueckt wird (nur in NPC's):
- AddItem("/waffe/zapper",REFRESH_DESTRUCT|CLONE_WIELD,1);
-
-
-SIEHE AUCH
-==========
-
- RemoveItem(), replace_program(), create(), P_GUARD,
- /std/room/items.c, /std/npc/items.c,
- /sys/rooms.h, /sys/npc.h
-
-Last modified: Thu Nov 23 13:43:30 CET 2006 by Rumata
diff --git a/doc/sphinx/man/lfun/AddKnownPotion b/doc/sphinx/man/lfun/AddKnownPotion
deleted file mode 100644
index 874e55c..0000000
--- a/doc/sphinx/man/lfun/AddKnownPotion
+++ /dev/null
@@ -1,45 +0,0 @@
-
-AddKnownPotion()
-****************
-
-
-FUNKTION
-========
-
- int AddKnownPotion(int nr)
-
-
-DEFINIERT IN
-============
-
- /std/player/potion.c
-
-
-ARGUMENTE
-=========
-
- int nr Nummer eines ZTs
-
-
-BESCHREIBUNG
-============
-
- Addiert einen ZT als bekannt in einem Spieler. Nur vom Orakel rufbar.
-
-
-RUeCKGABEWERT
-=============
-
- 1 Erfolg
- -1 fehlende Berechtigung
- -2 Nummer bereits eingetragen
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: FindPotion(), RemoveKnownPotion(), InList()
- Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
-
-6.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/lfun/AddMaterial b/doc/sphinx/man/lfun/AddMaterial
deleted file mode 100644
index 7f90d82..0000000
--- a/doc/sphinx/man/lfun/AddMaterial
+++ /dev/null
@@ -1,100 +0,0 @@
-
-AddMaterial()
-*************
-
-
-FUNKTION
-========
-
- private static varargs void AddMaterial(string mat, int gender,
- mixed names, mixed groups,
- mixed dif) {
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-ARGUMENTE
-=========
-
- string mat
- Materialstring, definiert in <thing/material.h>
-
- int gender
- Geschlecht des einzutragenden Materials
-
- mixed names
- Name des Materials:
- - "<Nominativ>" oder (meist nur Nom. und Gen. noetig)
- - ({"<Nominativ>","<Genitiv>","<Dativ>","<Akkusativ>"})
-
- mixed groups
- Eingruppierung des Materials:
- - MATGROUP_XXX oder ({MATGROUP_XXX,...})
- - ([MAT_GROUP_XXX:xx,MATGROUP_YYY:yy,...])
-
- mixed dif
- Schwierigkeiten bei der Erkennbarkeit:
- - int x oder ({MINMAT,x1,MATPOS1,x2,MATPOS2 ...})
- - xn: Erkennbarkeitsschwierigkeit (100=100%) -100..100
- - MINMAT: Erkennung zumindest als _dieses_ Material
- moeglich
- - MATPOSn: moegliches Material, erkennbar, wenn
- Erkennbarkeitfaehigkeit>=xn
- -> das letzte MATPOS muss natuerlich
- string mat entsprechen
-
-
-BESCHREIBUNG
-============
-
- Es wird in die Materialiendatenbank eine neues Material aufgenommen,
- die Stringkonstante dafuer wird vorher in <thing/material.h> fest-
- gelegt. Falls der Genitiv nicht Nominativ+"s" entspricht (z.B. "Seide"),
- sollte dieser explizit angegeben werden.
- Nach Neuladen der Datenbank ist dieses Material auch per MaterialName(),
- 'erkennbar' (siehe mixed dif, siehe Beispiel) bzw. seinen einzelnen
- Gruppen zuordnbar.
-
-
-BEISPIELE
-=========
-
- AddMaterial(MAT_NITROGLYCERINE,NEUTER,"Nitroglycerin",
- ({MATGROUP_EXPLOSIVE,MATGROUP_FLUID}),
- ({MAT_OIL,25,MAT_MISC_EXPLOSIVE,50,MAT_NITROGLYCERINE}));
-
- Damit wird das Material Nytroglycerin aufgenommen, ein explosiver
- (damit entflammbarer) sowie fluessiger Stoff. Liegt die Erkennungs-
- faehigkeit (MaterialName()) unter 25, wird es nur als Oel erkannt,
- liegt sie unter 50, wird es zumindest als explosives Material erkannt,
- liegt sie ueber 49, so wird es korrekt erkannt (wie schade :) ).
-
-
-BEMERKUNGEN
-===========
-
- Wird in der create() der Datenbank aufgerufen. Zu beachten:
- - vor Eintrag eines _neuen_ Materials die Datenbank durchsuchen!
- - bei den Materialiengruppen die automatischen Abhaengigkeiten in
- AddMaterial() durchsehen!
- - bitte Datenbank neu laden
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
- Listen: AllMaterials(), AllGroups(), Dump()
- materialliste, materialgruppen
- Master: ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
- Sonstiges: P_MATERIAL_KNOWLEDGE
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/AddMiniQuest b/doc/sphinx/man/lfun/AddMiniQuest
deleted file mode 100644
index 787e718..0000000
--- a/doc/sphinx/man/lfun/AddMiniQuest
+++ /dev/null
@@ -1,71 +0,0 @@
-
-AddMiniQuest()
-**************
-
-
-FUNKTION
-========
-
- int AddMiniQuest(int stupse, string questgeber, string desc, int active,
- string titel, string erledigt, mapping voraussetzungen,
- string region, string *erlaubte)
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion traegt eine neue Miniquest im Questmaster ein.
-
-
-ARGUMENTE
-=========
-
- stupse (>0) - Anzahl Stufenpunkte, die fuer die MQ gutgeschrieben werden
- questgeber - Ladename des Objekts, das GiveMiniQuest() aufruft
- desc - Aufgabenbeschreibung der Miniquest
- active (0/1) - ist die Miniquest aktiv, d.h. spielbar, oder nicht?
- titel - Titel der Miniquest, darf weder "in", noch "im" enthalten,
- weil dann der Eintrag in der Fraternitas-Bibliothek nicht
- gelesen werden kann.
- erledigt - Beschreibung der Miniquest, nachdem man sie erledigt hat
- Der Text kann in der Bibliothek der kleinen und grossen
- Heldentaten in der Fraternitas eingesehen werden.
- voraussetzungen - Mapping im Format von P_RESTRICTIONS (s. dort), um
- die Voraussetzungen festzulegen, die ein Spieler
- erfuellen muss, um die MQ ueberhaupt spielen zu koennen
- Wird fuer die regionsbezogenen Informationspunkte/-NPCs
- ausgewertet. 0 oder ([]) eintragen, wenn keine
- Voraussetzungen bestehen.
- region - Zuordnung der Miniquest zu einer Region; wird fuer der
- Bibliothek der Fraternitas verwendet, um die MQs der
- einzelnen Regionen herauszufiltern.
- erlaubte - Array mit Ladenamen von Objekten, die berechtigt sind,
- die Daten der MQ abzufragen, um Spielern einen Hinweis
- darauf zu geben, die sie noch nicht bestanden haben.
-
-
-RUECKGABEWERTE
-==============
-
- 1: Hat geklappt
- -1: Parameterformat stimmt nicht (questgeber kein String oder Leerstring,
- voraussetzungen kein Mapping, region oder titel keine Strings,
- erlaubte kein Array)
- -2: weniger als 1 Stufenpunkt einzutragen versucht
- -3: Das Array in "erlaubte" ist leer, oder zum angegebenen Questgeber
- wurde keine Datei gefunden.
- -4: Der angegebene Questgeber vergibt schon eine andere Miniquest
-
-
-SIEHE AUCH
-==========
-
- GiveMiniQuest(L), HasMiniQuest(L)
- P_RESTRICTIONS
- /secure/questmaster.c
diff --git a/doc/sphinx/man/lfun/AddMoney b/doc/sphinx/man/lfun/AddMoney
deleted file mode 100644
index b9e16b2..0000000
--- a/doc/sphinx/man/lfun/AddMoney
+++ /dev/null
@@ -1,92 +0,0 @@
-
-AddMoney()
-**********
-
-
-AddMoney(L)
-===========
-
-
-FUNKTION
-========
-
- public int AddMoney(int amount);
-
-
-DEFINIERT IN
-============
-
- /std/container/moneyhandler.c
- /std/living/moneyhandler.c
- /std/player/moneyhandler.c
-
-
-ARGUMENTE
-=========
-
- int amount
- Die zufuehrende oder abziehende Geldmenge
-
-
-BESCHREIBUNG
-============
-
- Dem Spieler wird die in <amount> festgelegte Geldmenge abgezogen oder
- zugefuehrt.
-
-
-RUeCKGABEWERT
-=============
-
- Technisch gesehen wird Geld mit entsprechendem <amount> erzeugt
- ("/items/money.c") und mittels "move" in den Spieler bewegt. Das Ergebnis
- dieses "move"-Aufrufes wird hier uebergeben, z.B. 1 fuer OK.
- Die moeglichen Fehler-Konstanten sind in /sys/moving.h definiert, siehe
- auch Dokumentation zu "move".
-
-
-BEMERKUNGEN
-===========
-
- <amount> kann sowohl positiv als auch negativ sein. Welche Auswirkungen
- beide Faelle haben, sollte klar sein. Doch sollte bei einem negativen
- <amount> vorher mittels QueryMoney() abgefragt werden, ob der Spieler
- auch ueber ausreichend Geld verfuegt.
- Wird dem Spieler Geld abgezogen, ist darauf zu achten, dieses in der
- Zentralbank einzuzahlen (s.a.:PayIn() ).
- Verschafft man dem Spieler Geld aus dem Nichts, muss es vorher bei der
- Zentralbank abgebucht (WithDraw()) werden.
-
- Achtung: Kann der Spieler die in <amount> angebene Geldmenge nicht
- tragen, werden ihm keine Muenzen in sein Inventar bewegt. Die
- Fehlermeldung erkennt man an dem Rueckgabewert ME_TOO_HEAVY.
-
- Im Gegensatz zu Spielern haben alle anderen Objekte (Raeume, NPC, etc.)
- standardmaessig keinen Moneyhandler. In diesem Fall muss in Lebewesen
- "/std/living/moneyhandler"
- und in nicht-Lebewesen
- "/std/container/moneyhandler"
- geerbt werden.
-
-
-BEISPIELE
-=========
-
- // gib ihm Geld
- this_player()->AddMoney(50);
-
- // nimm ihm Geld
- if(this_player()->AddMoney(-50)==1)
- write("Der Ork beklaut dich!\n");
-
-
-SIEHE AUCH
-==========
-
- Geldhandling: QueryMoney(L)
- Zentralbank: PayIn(L), WithDraw(L)
- Sonstiges: move(L),
- /items/money.c, /sys/moving.h, /sys/money.h, /sys/bank.h
- /std/container/moneyhandler.c
-
-18.02.2013, Zesstra
diff --git a/doc/sphinx/man/lfun/AddMsg b/doc/sphinx/man/lfun/AddMsg
deleted file mode 100644
index 9faad47..0000000
--- a/doc/sphinx/man/lfun/AddMsg
+++ /dev/null
@@ -1,62 +0,0 @@
-
-AddMsg()
-********
-
-
-FUNKTION
-========
-
- void AddMsg(string msg, int next);
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- msg
- Die auszugebende Meldung.
- next
- Zeit bis zur naechsten Fahrplanstation.
-
-
-BESCHREIBUNG
-============
-
- Dem Fahrplan wird die Ausgabe einer Meldung an den Transporter
- hinzugefuegt. Diese Meldung koennte zum Beispiel das Nahen der
- naechsten Haltestelle ankuendigen o.ae. Nach Ausgabe der Meldung
- vergehen next Sekunden, bis die naechste Station angefahren wird.
-
- Um das Umbrechen der Meldung (normalerweise auf 78 Zeichen pro Zeile)
- muss sich der Aufrufer selber kuemmern.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- AddMsg("In der Ferne taucht eine kleine Inseln auf.\n", 10);
- AddMsg("Das Schiff steuert einen kleinen Steg an.\n");
- AddRoute(...);
-
- Nach der Ankuendigung der Insel vergehen 10 Sekunden, bis die naechste
- Meldung ausgegeben wird. Da bei der zweiten Meldung keine Zeit
- angegeben war, legt das Schiff direkt nach der Ausgabe der Meldung an.
-
-
-SIEHE AUCH
-==========
-
- AddRoute(), AddFun(), /std/transport.c
-
-25.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddPlant b/doc/sphinx/man/lfun/AddPlant
deleted file mode 100644
index ae2df8b..0000000
--- a/doc/sphinx/man/lfun/AddPlant
+++ /dev/null
@@ -1,84 +0,0 @@
-
-AddPlant()
-**********
-
-
-FUNKTION
-========
-
- varargs int AddPlant(string filename, [string|string* npcId])
-
-
-DEFINIERT IN
-============
-
- /std/room/kraeuter.c
-
-
-ARGUMENTE
-=========
-
- filename
- Der Filename des Krauts das hier gefunden werden soll.
- npcId
- Die ID eines NPCs oder die IDs einer Liste von NPCs, der/die das
- Kraut bewachen soll/en. Befindet sich ein NPC mit einer dieser IDs
- im Raum, kann das Kraut nicht gepflueckt werden. Dieses Argument
- ist optional!
-
-
-RUeCKGABEWERT
-=============
-
- -1 wenn das Objekt nicht geclont werden konnte
- >=0 sonst
-
-
-BESCHREIBUNG
-============
-
- Mit Hilfe dieser Funktion koennen Kraeuter fuer den mudweiten
- Kraeuterskill recht einfach eingebaut werden. Alles was man
- noch machen muss, ist den Namen der Pflanze in einem Detail oder
- der Langbeschreibung zu erwaehnen.
- Mit dem Befehl "showplant" in /obj/tools/planttool kann man sich
- bequem anzeigen lassen, was es alles an Kraeutern gibt, die man
- nehmen kann.
-
-
-BEMERKUNGEN
-===========
-
- Damit die Kraeuter von den Spielern zum Brauen von Traenken benutzt
- werden koennen, muss der Raum erst in einem Master eingetragen werden.
- Derzeit schickt ihr dazu am besten eine kurze Mail an einen Erzmagier,
- gerne nimmt Humni die derzeit entgegen.
- Die Kraeuter wurden von der Balance bereits alle im vorhinein
- abgenommen. Lediglich die Einhaltung der Kategorien ist zu beachten.
- Sind Kraeuter nicht im Master konfiguriert (wie z.B. im Homemud), sind
- alle erzeugten Kraeuter nur "Testkraeuter" mit nur der ID "kraut".
-
-
-BEISPIELE
-=========
-
- #include <items/kraeuter/kraeuterliste.h>
- inherit "/std/room/kraeuter";
- inherit "/std/room";
-
-
-
- void create()
- {
- ::create();
- SetProp(P_INT_LONG, "Du siehst eine Wiese voller Feldklee.\n");
- AddPlant(FELDKLEE);
- }
-
-
-SIEHE AUCH
-==========
-
- AddItem();
-
-18.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddPluralId b/doc/sphinx/man/lfun/AddPluralId
deleted file mode 100644
index 8d6d249..0000000
--- a/doc/sphinx/man/lfun/AddPluralId
+++ /dev/null
@@ -1,49 +0,0 @@
-
-AddPluralId()
-*************
-
-
-FUNKTION
-========
-
- void AddPluralId(mixed id);
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- id
- Identfikationsstring oder Array von Strings
-
-
-BESCHREIBUNG
-============
-
- Es werden ein oder mehrere Bezeichner hinzugefuegt, mit denen sich
- mehrere Einheiten der Menge ansprechen lassen.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- siehe /items/money.c
-
-
-SIEHE AUCH
-==========
-
- AddSingularId(), RemovePluralId(), AddId(), id(), /std/unit.c
-
-Last modified: Mon Jul 14 11:30:00 1997 by Silvana
diff --git a/doc/sphinx/man/lfun/AddPursuer b/doc/sphinx/man/lfun/AddPursuer
deleted file mode 100644
index f4839e6..0000000
--- a/doc/sphinx/man/lfun/AddPursuer
+++ /dev/null
@@ -1,52 +0,0 @@
-
-AddPursuer()
-************
-
-
-FUNKTION
-========
-
- void AddPursuer(object pursuer)
-
-
-ARGUMENTE
-=========
-
- pursuer: Objekt, das demjenigen folgen soll, in dem AddPursuer
- aufgerufen wurde.
-
-
-FUNKTION
-========
-
- Durch den Aufruf von AddPursuer in einem Objekt, welches living() ist,
- wird das Object, welches als Argument uebergeben wurde in die Liste
- der Verfolger eingetragen. Alle Objekte, die in der Verfolgerliste stehen
- werden bei Bewegungen des Verfolgten in dasselbe Environment bewegt.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNG
-=========
-
- Im Verfolger wird PreventFollow mit dem Zielobjekt, in das der Verfolgte
- bewegt wird, aufgerufen. Dadurch kann der raeumliche Bereich, in dem
- verfolgt wird, eingeschraenkt werden.
-
-
-BEISPIELE
-=========
-
- find_player("jof")->AddPursuer(find_player("kirk"))
- Danach wird Jof von Kirk verfolgt.
-
-
-SIEHE AUCH
-==========
-
- "RemovePursuer", "PreventFollow"
diff --git a/doc/sphinx/man/lfun/AddReadDetail b/doc/sphinx/man/lfun/AddReadDetail
deleted file mode 100644
index 7f36aa4..0000000
--- a/doc/sphinx/man/lfun/AddReadDetail
+++ /dev/null
@@ -1,102 +0,0 @@
-
-AddReadDetail()
-***************
-
-
-FUNKTION
-========
-
- void AddReadDetail(string|string*keys,
- string|string*|mapping|closure desc);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
-
-
-BESCHREIBUNG
-============
-
- Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
- beim Lesen ausgegeben werden, haengt im wesentlichen vom Typ der
- Beschreibung <desc> ab:
- <desc> ist ein String.
- Beim Lesen wird dieser String zurueckgegeben.
- <desc> ist ein String-Array.
- Beim Lesen wird zufaellig einer der Strings zurueckgegeben.
- <desc> ist ein Mapping.
- Das Mapping muss folgenden Aufbau haben:
- ([0: "Defaulttext",
- "rasse1": "r1text", ...]).
-
- Falls fuer die Rasse des das Detail untersuchenden Spielers ein
- Eintrag im Mapping existiert, wird der entsprechende Text
- zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
- rassenabhaengige Texte moeglich.
- <desc> ist eine Closure.
- In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
- zurueckgegeben. Die Closure bekommt dabei den Namen des Details
- als Parameter uebergeben.
-
- Fuer lesbare Details koennen Forscherpunkte eingetragen werden.
-
- Will man ein lesbares Detail an einem Objekt haben, welches der Spieler
- mit "lies <id>" (<id> ist eine ID des Objekts) bekommt, muss man ein
- Detail SENSE_DEFAULT hinzufuegen.
- (Ein Detail "<id>" hinzuzufuegen, hat einen ganz anderes Effekt! Dieses
- wuerde vom Spieler mit "lies <id> an <id>" gelesen werden und ist
- meistens nicht das, was gewuenscht wird.)
-
-
-BEMERKUNGEN
-===========
-
- (1) Auf die 'desc' wird kein process_string() mehr angewendet.
- Bitte stattdessen lfun closures bzw. 'inline closures'
- verwenden.
-
- (2) Im Gegensatz zum Verhalten von AddTouchDetail(), AddSmells() und
- AddSounds() wirkt ein SENSE_DEFAULT-Detail in einem Raum nicht.
- Ein einfaches "lies" bleibt dann ohne Rueckgabewert.
-
-
-BEISPIELE
-=========
-
- AddReadDetail( ({ "schild" }),
- "BETRETEN STRENGSTENS VERBOTEN!\n" );
-
- AddReadDetail("inschrift",
- ([0: "Dort steht: Ein Ring sie zu binden. ....\n",
- "elf": "Alles in dir straeubt sich, DAS DA zu lesen.\n"]));
-
- AddReadDetail("regeln",
- function string() {
- this_player()->More("/etc/WIZRULES", 1);
- return "";
- });
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddResistanceModifier b/doc/sphinx/man/lfun/AddResistanceModifier
deleted file mode 100644
index b8a5ad8..0000000
--- a/doc/sphinx/man/lfun/AddResistanceModifier
+++ /dev/null
@@ -1,75 +0,0 @@
-
-AddResistanceModifier()
-***********************
-
-
-FUNKTION
-========
-
- varargs int AddResistanceModifier(mapping mod, string add)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- mapping mod:
- Mapping mit Schadensarten und ihrem Resistenzmodifikator (der im Bereich
- von -1.0 bis +x liegen kann), z.B. ([DT_FIRE:-1.0]) (Totalresistenz).
- string add:
- Ein Identifikator fuer _diesen_ Eintrag des setzenden Objektes.
-
-
-BESCHREIBUNG
-============
-
- Es werden Resistenzen in dem Objekt gesetzt, die solange bestehen, wie
- das setzende Objekt existiert, oder nicht RemoveResistanceModifier
- (mit eventuellem Schluessel add) aufgerufen wird. Zusaetzliche Resistenzen
- werden eingerechnet.
-
-
-BEMERKUNGEN
-===========
-
- Fuer Ruestungen kann und sollte man P_RESISTANCE_STRENGTHS verwenden.
-
-
-BEISPIELE
-=========
-
- // Oel mit vervierfachtem Feuerschaden
- int add_action() {
- ...
- write(break_string("Du schuettest das Oel ueber "+
- npc->name(WEN)+".",78));
- ...
- npc->AddResistanceModifier(([DT_FIRE:3.0]), "oel");
- SetProp(P_INVIS,1);
- SetProp(P_EXTRA_LOOK, "Ueberall tropft Oel herunter.\n");
- move(npc,M_NOCHECK);
- ...
- }
-
-
-RUeCKGABEWERT
-=============
-
- 1 fuer Erfolg
-
-
-SIEHE AUCH
-==========
-
- Modifikatoren: RemoveResistanceModifier(), P_RESISTANCE_MODIFIER
- simple Resistenz: P_RESISTANCE, P_VULNERABILITY
- Hauptmapping: P_RESISTANCE_STRENGTHS
- Berechnung: CheckResistance(), UpdateResistanceStrengths()
- anderes: balance, /std/armour/combat.c, /std/living/combat.c
-
-29.Apr 2002, Gloinson@MG
diff --git a/doc/sphinx/man/lfun/AddRoomCmd b/doc/sphinx/man/lfun/AddRoomCmd
deleted file mode 100644
index f4aeb68..0000000
--- a/doc/sphinx/man/lfun/AddRoomCmd
+++ /dev/null
@@ -1,23 +0,0 @@
-
-AddRoomCmd()
-************
-
-
-SYNTAX
-======
-
- AddRoomCmd( string kommando, string funktion );
- AddRoomCmd( string *kommandos, string funktion );
-
-
-FUNKTION
-========
-
- Diese Funktion ist veraltet. Sie wird vollstaendig durch
- die Funktion AddCmd ersetzt.
-
-
-SIEHE AUCH
-==========
-
- "AddCmd"
diff --git a/doc/sphinx/man/lfun/AddRoomMessage b/doc/sphinx/man/lfun/AddRoomMessage
deleted file mode 100644
index aa700c1..0000000
--- a/doc/sphinx/man/lfun/AddRoomMessage
+++ /dev/null
@@ -1,103 +0,0 @@
-
-AddRoomMessage()
-****************
-
-
-FUNKTION
-========
-
- void AddRoomMessage(string *msg, int time, mixed *func);
-
-
-DEFINIERT IN
-============
-
- /std/room/description.c
-
-
-ARGUMENTE
-=========
-
- msg
- Array von Strings mit den Meldungen.
- time
- Der Abstand zwischen zwei Meldungen in Sekunden.
- func (optional)
- String oder Array von Strings mit Funktionsnamen
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion legt man fest, dass in bestimmten Zeitabstaenden
- Meldungen an den Raum geschickt werden sollen.
-
- Es wird alle time Sekunden zufaellig eine der in msg angegebenen
- Meldungen ausgegeben. Hat man auch noch func angegeben, so wird
- zusaetzlich diese Funktion (bei einem Array: eine zufaellig ausgesuchte
- Funktion) im Raum aufgerufen. Als Parameter bekommt die Funktion die
- Nummer der ausgegebenen Meldung.
-
- Bevor man allerdings jeden Raum mit AddRoomMessage() pflastert, sollte
- man folgendes bedenken:
- o Viele Meldungen in vielen Raeumen tendieren dazu, den Spielern auf
- die Nerven zu gehen!
- o Da das Timing ueber einen call_out() gesteuert wird, ist das Ganze
- aus Sicht des GameDrivers auch noch relativ teuer!
- Fazit: weniger ist mehr!
-
-
-BEMERKUNGEN
-===========
-
- * Falls time < 15 Sekunden ist, wird auf 15 Sekunden aufgerundet.
- * der Praefix Add... taeuscht hier. Ein Aufruf von AddRoomMessage()
- ueberschreibt alle vorherigen Werte
- * THIS_PLAYER() NICHT VERWENDEN!
- In Funktionen, die durch AddRoomMessage() ausgeloest werden, darf
- this_player() nicht verwendet werden. AddRoomMessage ist call_out-
- gesteuert und speichert somit das this_player(). Damit ist this_player()
- immer der Spieler, der den Raum geladen, also den Raum als erster
- betreten hat.
- Spieler also bitte selbst ueber filter(all_inventory(this_object()),
- #'interactive) suchen.
-
-
-BEISPIELE
-=========
-
- Es soll alle halbe Minute eine Meldung ausgegeben werden. Falls es
- unter den Fuessen knackt, soll man zudem mit 30%-iger
- Wahrscheinlichkeit zusammenzucken:
-
- inherit "/std/room";
-
- void create() {
- ::create();
- AddRoomMessage( ({ "In der Ferne schreit ein Kaeuzchen.\n",
- "Es raschelt im Gebuesch.\n",
- "Etwas knackt unter Deinen Fuessen.\n" }),
- 30, ({"sound", "sound_more_rnd"}) );
- ...
- }
-
- void sound(int msg) {
- if (msg == 2) // Es hat geknackt...
- if (random(10) < 3) // Schreck lass nach! ;-)
- tell_room(this_object(), "Erschrocken faehrst Du zusammen!\n" );
- }
-
- // Extra-Beispiel: wir setzen die Wartedauer (Parameter tim) neu
- void sound_more_rnd() {
- sound(0); // die Message-Nummer ist hier unwichtig
- SetProp(P_MSG_PROB, 25+random(20)); // neue Wartedauer
- }
-
-
-SIEHE AUCH
-==========
-
- Verwandt: tell_room(), ReceiveMsg()
- Props: P_ROOM_MSG, P_FUNC_MSG, P_MSG_PROB
-
-2.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/lfun/AddRoute b/doc/sphinx/man/lfun/AddRoute
deleted file mode 100644
index 265fa8a..0000000
--- a/doc/sphinx/man/lfun/AddRoute
+++ /dev/null
@@ -1,114 +0,0 @@
-
-AddRoute()
-**********
-
-
-FUNKTION
-========
-
- public varargs void AddRoute(string room, int stay, int next,
- string harbour_desc, mixed dest_ids, string deststr)
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- string room
- Filename der Haltestelle (des Ziels)
- int stay
- Aufenthaltszeit an der Haltestelle.
- int next
- Fahrtzeit von dort bis zum naechsten Fahrplanpunkt
- string harbour_desc
- Name der Haltestelle (fuer QueryArrived)
- mixed dest_ids
- kleingeschriebene IDs der Haltestelle
- string destrstr
- Unbenutzt / Undefiniert.
-
-
-BESCHREIBUNG
-============
-
- Dem Fahrplan des Transporters wird eine neue Haltestelle hinzugefuegt.
-
- Bei Erreichen der Haltestelle wird der Transporter in den Raum 'room'
- bewegt und sichtbar gemacht. Nun kann man ihn fuer 'stay' Sekunden
- betreten oder verlassen, bevor er ablegt (unsichtbar gemacht wird).
- Nach 'next' Sekunden wird dann der naechste Punkt des Fahrplans
- ausgefuehrt.
-
-
-
- 'harbour_desc' ist ein String, den QueryArrived() zurueckgibt, wenn sich
- der Transporter an einer Haltestelle befindet. In der Regel ist das ein
- String, der die Haltestelle naeher beschreibt.
-
-
-
- 'dest_ids' ist ein Array von Strings, die als ID-Code fuer diese
- Haltstelle dienen. Das wird zB bei der Ermittlung einer Haltestelle bei
- "reise nach" benutzt. Wenn 'dest_ids' nicht gesetzt ist, und auch
- P_HARBOUR des Zielhafens nicht korrekt gesetzt ist, werden
- grossgeschriebene Begriffe aus 'harbour_desc' verwendet.
-
-
-BEISPIELE
-=========
-
- #1 Hier ein Auszug aus /d/inseln/schiffe/jolle.c:
-
- AddRoute("/d/ebene/room/PortVain/po_haf2", 40,
- 10, "Hafen von Port Vain");
-
- Die Jolle wird also beim Anlegen in den Port Vainer Hafen bewegt und
- laesst sich dort 40 Sekunden lang betreten oder verlassen.
- QueryArrived() liefert waehrend dieser Zeit den String "Hafen von Port
- Vain" zurueck. Nach den 40 Sekunden legt die Jolle ab, und nach
- weiteren 10 Sekunden wird die naechste Station in ihrem Fahrplan
- angefahren.
-
- #2 Die Galeere nach Orkhausen:
- AddRoute(INSEL("steg"), 30, 20, "Verlorene Land ( Orkhausen )" );
- - haelt 30 Sekunden
- - reist 20 Sekunden
- - reist nach INSEL("steg"), bekannt als "Verlorene Land ( Orkhausen )"
- - da keine 'dest_ids' angegeben sind, waere eine so definierte
- Haltstelle nur mit den IDs ansprechbar, die in P_HARBOURS im Zielraum
- angegeben sind.
-
- Wenn man nun erreichen wollte, dass das Ziel auch mit dem Kuerzel "vland"
- ansprechbar ist, kann man zum einen explizite 'dest_ids' eintragen:
- AddRoute(INSEL("steg"), 30, 20, "Verlorene Land ( Orkhausen )",
- ({"verlorenes", "land", "orkhausen", "vland"}));
- Dies laesst sich im Zielhafen aber auch durch Eintragen des Kuerzels
- "vland" in P_HARBOUR erreichen. Dies hat den Vorteil, dass dieser Hafen
- dann von allen Transportern, die dort anlegen, unter demselben Namen
- erreicht werden kann.
-
-
-HINWEISE
-========
-
- Dadurch, dass die Eintraege aus P_HARBOUR und 'dest_ids' gleichberechtigt
- fuer "reise nach <ziel>" verwendet werden koennen, ist es moeglich,
- dass die Reiseziele auf einem Schiff unter zusaetzlichen Bezeichnungen
- bekannt sind, als an Land (zum Beispiel koennte eine fernwestliche
- Besatzung die Ziele anders nennen).
-
-
-SIEHE AUCH
-==========
-
-Funktionen AddMsg(L), AddFun(L), /std/transport.c Properties
-P_HARBOUR, P_NO_TRAVELING, P_TRAVEL_INFO
-
-
-2015-Jan-18, Arathorn.
-======================
diff --git a/doc/sphinx/man/lfun/AddSingularId b/doc/sphinx/man/lfun/AddSingularId
deleted file mode 100644
index c45199e..0000000
--- a/doc/sphinx/man/lfun/AddSingularId
+++ /dev/null
@@ -1,49 +0,0 @@
-
-AddSingularId()
-***************
-
-
-FUNKTION
-========
-
- void AddSingularId(mixed id);
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- id
- Identifikationsstring oder Array von Strings
-
-
-BESCHREIBUNG
-============
-
- Es werden ein oder mehrere Bezeichner hinzugefuegt, mit denen sich eine
- einzelne Einheit ansprechen laesst.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- siehe /items/money.c
-
-
-SIEHE AUCH
-==========
-
- AddPluralId(), RemoveSingularId(), AddId(), id(), /std/unit.c
-
-Last modified: Mon Jul 14 11:31:00 1997 by Silvana
diff --git a/doc/sphinx/man/lfun/AddSmells b/doc/sphinx/man/lfun/AddSmells
deleted file mode 100644
index 2623f98..0000000
--- a/doc/sphinx/man/lfun/AddSmells
+++ /dev/null
@@ -1,92 +0,0 @@
-
-AddSmells()
-***********
-
-
-FUNKTION
-========
-
- void AddSmells(string|string* keys, string|string*|mapping|closure desc);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
- koennen hiermit Gerueche realisiert werden:
- Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
- bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
- Beschreibung <desc> ab:
- <desc> ist ein String.
- Beim Untersuchen wird dieser String zurueckgegeben.
- <desc> ist ein String-Array.
- Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
- <desc> ist ein Mapping.
- Das Mapping muss folgenden Aufbau haben:
- ([0: "Defaulttext",
- "rasse1": "r1text", ...]).
-
- Falls fuer die Rasse des das Detail untersuchenden Spielers ein
- Eintrag im Mapping existiert, wird der entsprechende Text
- zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
- rassenabhaengige Details moeglich. Siehe auch die Beispiele.
- <desc> ist eine Closure.
- In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
- zurueckgegeben. Die Closure bekommt dabei den Namen des Details
- als Parameter uebergeben.
-
- Fuer Geruchsdetails koennen Forscherpunkte eingetragen werden.
-
- Gerueche koennen allgemein einen Raum oder Objekt zugeordnet werden:
- dafuer muss man als <key> SENSE_DEFAULT uebergeben.
-
-
-
- Spielerkommandos: "riech", "rieche", "schnupper", "schnuppere"
-
-
-BEISPIELE
-=========
-
- Ein kleines Beispiel fuer rassenabhaengige Gerueche mit Closures:
- string strafe(string key);
- ...
- AddSmells(SENSE_DEFAULT,
- "Der Geruch von Knoblauch ist ueberwaeltigend!\n");
- AddSmells(({"knoblauch","geruch"}),
- ([0: "Puhh, das stinkt!\n",
- "vampir": #'strafe]));
- ...
- string strafe(string key) {
- this_player()->reduce_hit_points(100);
- return "Der Knoblauch schmerzt dich furchtbar!\n";
- }
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddSounds b/doc/sphinx/man/lfun/AddSounds
deleted file mode 100644
index b14b976..0000000
--- a/doc/sphinx/man/lfun/AddSounds
+++ /dev/null
@@ -1,82 +0,0 @@
-
-AddSounds()
-***********
-
-
-FUNKTION
-========
-
- void AddSounds(string|string* keys, string|string*|mapping|closure desc);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
- koennen hiermit Geraeusche realisiert werden:
- Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
- bei der Untersuchung aussehen, haengt im wesentlichen vom Typ der
- Beschreibung <desc> ab:
- <desc> ist ein String.
- Beim Untersuchen wird dieser String zurueckgegeben.
- <desc> ist ein String-Array.
- Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
- <desc> ist ein Mapping.
- Das Mapping muss folgenden Aufbau haben:
- ([0: "Defaulttext",
- "rasse1": "r1text", ...]).
-
- Falls fuer die Rasse des das Detail untersuchenden Spielers ein
- Eintrag im Mapping existiert, wird der entsprechende Text
- zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
- rassenabhaengige Details moeglich. Siehe auch die Beispiele.
- <desc> ist eine Closure.
- In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
- zurueckgegeben. Die Closure bekommt dabei den Namen des Details
- als Parameter uebergeben.
-
- Fuer Geraeuschdetails koennen Forscherpunkte eingetragen werden.
-
- Gerauesche koennen allgemein einen Raum oder Objekt zugeordnet werden:
- dafuer muss man als <key> SENSE_DEFAULT uebergeben.
-
- Spielerkommandos: "lausche", "lausch", "hoer", "hoere"
-
-
-BEISPIELE
-=========
-
- Ein kleines Beispiel fuer rassenabhaengige Gerauesche
- AddSounds(SENSE_DEFAULT, "Die Zwergenmusik uebertoent alles!\n");
- AddSounds(({"zwergenmusik","musik"}),
- ([0 : "Seltsamer Krach!\n",
- "zwerg": "Das klingt einfach fantastisch!\n"]));
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSmells(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddSpecialDetail b/doc/sphinx/man/lfun/AddSpecialDetail
deleted file mode 100644
index 3405eec..0000000
--- a/doc/sphinx/man/lfun/AddSpecialDetail
+++ /dev/null
@@ -1,87 +0,0 @@
-
-AddSpecialDetail()
-******************
-
-
-VERALTET AddSpecialDetail()
-===========================
-
-
-FUNKTION
-========
-
- void AddSpecialDetail(string|string* keys, string func);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den Namen der Details.
- func
- String mit dem Namen der Funktion, die zur Auswertung aufgerufen
- wird.
-
-
-BESCHREIBUNG
-============
-
- Es wird ein Detail hinzugefuegt, dessen Inhalt nicht von vornherein
- feststeht, sondern von aeusseren Bedingungen abhaengt. Zu diesem
- Zweck wird immer, wenn dieses Detail untersucht wird, die Funktion
- func aufgerufen, um den aktuellen Zustand des Details zu bestimmen.
- Der Funktion wird als Parameter das Schluesselwort uebergeben, mit
- dem das Detail untersucht wurde.
-
- VERALTET: Bitte AddDetail mit Closure benutzen.
-
-
-BEISPIELE
-=========
-
- Ein zustandsabhaengiges Detail:
-
- int hebel_betaetigt;
- string hebel(string key);
- ...
- // ALT: AddSpecialDetail( ({ "hebel", "schalter" }), "hebel" );
- AddDetail(({ "hebel", "schalter" }), #'hebel );
- ...
- string hebel(string key)
- { if(hebel_betaetigt)
- return "Der "+capitalize(key)+" steht auf EIN.\n";
- else
- return "Der "+capitalize(key)+" steht auf AUS.\n";
- }
-
- Man erhaelt verschiedene Ergebnisse beim Untersuchen, je nachdem
- ob das Flag hebel_betaetigt gesetzt ist oder nicht.
-
-
-BEMERKUNG
-=========
-
- Intern werden Details und SpecialDetails im selben Mapping
- verwaltet.
- Man kann statt dieser Funktion deshalb auch AddDetail mit Closures
- nutzen.
-
-
-SIEHE AUCH
-==========
-
- Setzen : AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AddSpecialExit b/doc/sphinx/man/lfun/AddSpecialExit
deleted file mode 100644
index 2f16c17..0000000
--- a/doc/sphinx/man/lfun/AddSpecialExit
+++ /dev/null
@@ -1,82 +0,0 @@
-
-AddSpecialExit()
-****************
-
-
-FUNKTION
-========
-
- void AddSpecialExit(string|string* cmd, string|closure func);
-
-
-DEFINIERT IN
-============
-
- /std/room/exits
-
-
-ARGUMENTE
-=========
-
- string/string* cmd
- die Richtung(en), in die der Ausgang fuehrt
- string/closure func
- der Name der aufzurufenden Funktion/Closure
-
-
-BESCHREIBUNG
-============
-
- Es wird ein Ausgang in die Richtung(en) cmd eingefuegt. Wird der
- Ausgang benutzt, so wird die Closure bzw. Funktion func ausgefuehrt.
-
- AddSpecialExit(cmd, "func") entspricht:
- - AddExit(keys, #'func)
-
-
-BEMERKUNGEN
-===========
-
- In func muss man den Spieler selbst in den Zielraum bewegen. Im
- Erfolgsfall sollte man einen Wert >0 zurueckgeben, im Fehlerfall einen
- Wert <=0.
-
- func bekommt als Parameter einen String mit der gewaehlten
- Bewegungsrichtung uebergeben.
-
-
-BEISPIELE
-=========
-
- // ein Ausgang soll nur von Froeschen benutzbar sein:
-
- AddSpecialExit("loch", "lochfkt");
- // der gleiche Aufruf, nur anders:
- // static int lochfkt(string dir); // Prototyp
- // ...
- // AddSpecialExit("loch", #'lochfkt);
- // auch identisch zu:
- // AddExit("loch", #'lochfkt);
-
- static int lochfkt(string dir) {
- if (!(this_player()->QueryProp(P_FROG))) {
- // Kein Frosch => passt nicht!
- notify_fail("Du bist zu gross!\n");
- return 0;
- }
- // Meldungen werden im move() gleich mitgegeben
- return this_player()->move("/room/loch", M_GO, 0,
- "huepft ins Loch", "huepft herein");
- }
-
-
-SIEHE AUCH
-==========
-
- AddExit(), GetExits(),
- RemoveExit(), RemoveSpecialExit(),
- GuardExit(),
- H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
-
-Letzte Aenderung: 22.12.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/AddSpecialInfo b/doc/sphinx/man/lfun/AddSpecialInfo
deleted file mode 100644
index efc3067..0000000
--- a/doc/sphinx/man/lfun/AddSpecialInfo
+++ /dev/null
@@ -1,88 +0,0 @@
-
-AddSpecialInfo()
-****************
-
-
-FUNKTION
-========
-
- varargs void AddSpecialInfo( frage, meldung
- [, indent [, [silent [, casebased] ] ] );
-
-
-ARGUMENTE
-=========
-
- string/string* frage
- Schluesseltext(e) auf die Informationen gegeben werden sollen.
- string/closure function
- Methodenname im NPC/Closure
- string indent
- Text, der sich bei mehrzeiligen Meldungen wiederholen soll.
- int/string silent
- Ist silent gesetzt, so erfolgt Antwort nur an Fragenden.
- string/closure casebased
- Funktionsname oder Closure mit Returnwert string oder int.
-
-
-DEFINIERT IN
-============
-
- /std/npc/info.c
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Spieler ein NPC mittels "frage <monstername> nach <frage>" nach
- einer Information mit dem Schluessel frage fragt, so wird die Methode
- "function" gerufen. Die Rueckgabe wird als Meldung ausgegeben.
-
- Fuer die Beschreibung der weiteren Parameter siehe man AddInfo(L).
-
- AddSpecialInfo(keys, "function", ...) entspricht:
- - AddInfo(keys, #'function, ...)
-
-
-BEMERKUNGEN
-===========
-
- Da AddSpecialInfo() und AddInfo() auf die gleichen Daten zugreifen,
- kann man Informationen, die mit AddSpecialInfo() gesetzt wurden, auch
- mit RemoveInfo() entfernen. Es gibt kein RemoveSpecialInfo().
-
-
-BEISPIELE
-=========
-
- // Das folgende Beispiel ist auch unter man AddInfo(L) zu finden.
- ### dynamisch ###
- AddSpecialInfo(({"keks","kekse"}),
- "query_kekse", // der Methodenname
- "sagt: ");
- // ist uebrigens das gleiche wie:
- // static string query_kekse();
- // ...
- // AddInfo(({"keks","kekse"}),
- // #'query_kekse, // ein Verweis auf die Methode
- // "sagt: ");
- ...
- static string query_kekse() {
- if(present("keks"))
- return("Ich hab noch welche. Aetsch!");
- return("Menno. Keine mehr da!");
- }
-
- // "frage monster nach keks":
- // - wenn es noch Kekse hat, hoeren alle:
- // "Das Monster sagt: Ich hab noch welche. Aetsch!
- // - sonst:
- // "Das Monster sagt: "Menno. Keine mehr da!
-
-
-SIEHE AUCH
-==========
-
- AddInfo(L), RemoveInfo(L)
-
-7.Apr 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/AddSpell b/doc/sphinx/man/lfun/AddSpell
deleted file mode 100644
index 1661f8c..0000000
--- a/doc/sphinx/man/lfun/AddSpell
+++ /dev/null
@@ -1,173 +0,0 @@
-
-AddSpell()
-**********
-
-
-FUNKTION
-========
-
- varargs int AddSpell(int rate, int damage, string TextForEnemy,
- string TextForOthers, string|string* dam_type,
- string|closure func, int|mapping spellarg)
-
-
-DEFINIERT IN
-============
-
- /std/npc/combat.c
-
-
-ARGUMENTE
-=========
-
- rate - Relative Haeufigkeit der Anwendung (*),
- muss >= 0 sein
- damage - Der Schadenswert fuer Defend(),
- muss > 0 sein
- TextForEnemy - Text, den der Feind erhalten soll
- TextForOthers - Text, den andere im Raum erhalten sollen
- dam_type - Schadenstyp(en) fuer Defend(),
- (Default: ({DT_MAGIC}) )
- func - Funktionsname oder Closure, die nach Anwendung
- aufgerufen werden soll
- (Optional, bekommt als Argumente object enemy,
- int real_damage, string* dam_type)
- spellarg - Spell-Argument fuer Defend(), Default ist "1"
-
-
-BESCHREIBUNG
-============
-
- Ermoeglicht einfache Angriffs-Zaubersprueche fuer NPCs. Das Ausfuehren von
- Spells verursacht bei dem NPC keine KP-Kosten.
-
- Mit P_SPELLRATE wird die generelle Wahrscheinlichkeit der Ausfuehrung
- solcher Spells im Heartbeat angegeben, mit 'rate' kann man die relative
- Wahrscheinlichkeit der Spells untereinander steuern.
-
- (*) Relative Haeufigkeit heisst, dass sich alle 'rate' der Spells
- aufaddieren und ein einzelnes 'rate' dann in Relation zur Gesamtsumme
- steht. D.h. drei Spells mit 80, 10, 10 (Summe 100) haben die selben
- Aufruf-Wahrscheinlichkeiten wie drei Spells mit 120, 15, 15 oder drei
- Spells mit 160, 20, 20.
-
- Ein Spell wird immer in folgender Reihenfolge abgearbeitet:
- 1. Die Texte werden an die Beteiligten ausgegeben.
- 2. Es wird ggf. SpellDefend gerufen (wenn kein SP_PHYSICAL_ATTACK).
- Abbruch bei Schutz.
- 3. Im Opfer wird Defend() mit den angegebenen Werten aufgerufen.
- Abbruch bei Tod/Zerstoerung des Opfers.
- 4. Eine Funktion, so definiert, wird ausgefuehrt.
-
-
-BEMERKUNGEN
-===========
-
- TextForOthers wird vor der Ausgabe der Meldung durch replace_personal()
- geschickt, d.h. es koennen Platzhalter wie @WER1, @WEMQP1 und aehnliche
- verwendet werden (siehe auch die Manpage von replace_personal()).
- Da Ersetzungen nur fuer das Gegnerobjekt beruecksichtigt werden, koennen
- nur Platzhalter mit Endziffer 1 verwendet werden. Die Ersetzungen werden
- so gesteuert, dass die eingefuegten Namen nach Satzanfaengen automatisch
- gross geschrieben werden.
- Frueher wurden statt replace_personal() die Platzhalter @WER, @WESSEN,
- @WEM, @WEN verwendet. Diese funktionieren weiterhin, sollten aber nicht
- mehr in neuem Code benutzt werden.
-
- In der von AddSpell gerufenen Methode "func" koennen speziellere
- Sachen mit dem aktuellen Feind angestellt werden koennen. Die Methode
- muss im selben Objekt definiert sein, sofern der Funktionsname und
- keine Closure uebergeben wird.
-
- Will man einen physischen Angriff ausloesen, MUSS <spellarg> ein Mapping
- mit ([SP_PHYSICAL_ATTACK: 1]) sein. Bei Uebergeben einer 0 oder Weglassen
- des Werts wird an Defend das Default '1' (da es Spells sind) uebergeben.
-
- Wenn damage<=0 oder rate<0 oder keine Meldungen uebergeben werden, wird
- der Spell NICHT eingetragen, sondern die Funktion bricht mit Rueckgabe
- von 0 ab.
-
-
-BEISPIELE
-=========
-
- // #1 Einfacher NPC mit drei Spells, Gesamtrate = 100, also sind die
- // Raten direkt als Prozent Aufrufwahrscheinlichkeit lesbar.
- AddSpell(80, 400,
- "Der Hexer greift Dich mit einem kleinen Feuerball an.\n",
- "Der Hexer greift @WEN mit einem kleinen Feuerball an.\n",
- ({DT_FIRE, DT_MAGIC}));
- AddSpell(10, 800,
- "Der Hexer greift Dich mit einem riesigen Feuerball an.\n",
- "Der Hexer greift @WEN mit einem riesigen Feuerball an.\n",
- ({DT_FIRE, DT_MAGIC}));
- AddSpell(8, 100,
- "Der Hexer piekst Dir in die Augen!",
- "Der Hexer piekst @WEM in die Augen!", ({DT_PIERCE}),
- "augen_stechen");
- AddSpell(2, 5, (string)0, (string)0, (string*)0, "salto_mortalis");
-
- (Kleiner Feuerball mit 80% Wahrscheinlichkeit, riesiger mit 10%,
- "augen_stechen" mit 8%, "salto_mortalis" mit 2%)
-
- // Die Funktion "augen_stechen" kann dann so aussehen:
- void augen_stechen(object enemy, int damage, mixed dam_types ) {
- if (damage>10 && !enemy->QueryProp(P_BLIND)) {
- enemy->SetProp(P_BLIND, 1);
- if(enemy->QueryProp(P_BLIND))
- tell_object(enemy, "Du bist nun blind!\n");
- }
- }
-
- // Zur Funktion "salto_mortalis" gibt es keine Meldungen, dennoch
- // wird Defend mit: enemy->Defend(5, ({DT_MAGIC}), 1, this_object())
- // gerufen!
- void salto_mortalis(object enemy, int damage, mixed dam_types ) {
- // dem geneigten Leser ueberlassen, den Gegner zu toeten
- }
-
- // #2 Physische Angriffe: die Ruestungen sollen beruecksichtigt werden!
- // SP_PHYSICAL_ATTACK muss in einem Mapping auf 1 gesetzt werden,
- // damit Ruestungen physisch wirken (ansonsten werden nur ihre
- // DefendFuncs() ausgewertet). Es muss auch eine physische Schadensart
- // enthalten sein!
- // SpellDefend() wird bei diesem Flag nicht mehr am Gegner gerufen.
- AddSpell(100, 200+random(200),
- "Die kleine Ratte beisst Dich!\n",
- "@WER wird von einer kleinen Ratte gebissen!\n",
- ({DT_PIERCE, DT_POISON}), (string)0,
- ([SP_PHYSICAL_ATTACK:1]));
-
- // #3 Selektive physische Angriffe (siehe auch man Defend_bsp):
- // Will man erreichen, dass einige Ruestungen wirken, andere aber
- // nicht oder nur teilweise, kann man das ueber die Spellparameter
- // ausfuehrlich steuern:
-
- // erstmal fuer alle Ruestungsarten einen Schutz von 0% einstellen:
- mapping armours = map_indices(VALID_ARMOUR_CLASS, #'!);
- armours[AT_TROUSERS] = 120; // 120% Schutz durch Hosen
- armours[AT_BOOT] = 30; // 30% Schutz durch Stiefel
-
- AddSpell(20,200+random(200),
- "Die kleine Ratte beisst Dir blitzschnell in die Wade!\n",
- "@WER wird von einer kleinen Ratte in die Wade gebissen!\n",
- ({DT_PIERCE, DT_POISON}), (string)0,
- ([SP_PHYSICAL_ATTACK:1, SP_NO_ACTIVE_DEFENSE:1,
- SP_REDUCE_ARMOUR: armours]));
-
- // SP_NO_ACTIVE_DEFENSE = 1 schaltet aktive Abwehr (Karate/Klerus) ab
- // SP_REDUCE_ARMOUR enthaelt eine Liste von Ruestungstypen mit ihren
- // neuen Wirkungsgraden in Prozent. Nicht enthaltene Ruestungen haben
- // weiterhin 100% Schutzwirkung.
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: SpellAttack, SpellDefend, Defend, QueryDefend, SelectEnemy
- replace_personal
- Properties: P_DISABLE_ATTACK, P_SPELLRATE, P_AGGRESSIVE
- Abwehr: Defend, Defend_bsp, SpellDefend
- Methoden: modifiers
-
-Zuletzt geaendert: 20.11.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/AddToMenu b/doc/sphinx/man/lfun/AddToMenu
deleted file mode 100644
index 01d46b6..0000000
--- a/doc/sphinx/man/lfun/AddToMenu
+++ /dev/null
@@ -1,271 +0,0 @@
-
-AddToMenu()
-***********
-
-
-FUNKTION
-========
-
- varargs string AddToMenu(string menuetext,
- mixed ids,
- mapping minfo,
- mixed rate,
- mixed msg,
- mixed refresh,
- mixed delay,
- mixed d_msg);
-
-
-DEFINIERT IN
-============
-
- /std/pub.c
-
-
-ARGUMENTE
-=========
-
- Die Erlaeuterung der Parameter beschraenkt sich im Folgenden
- zunaechst auf die Grundfunktionalitaet bei Verwendung fester
- Werte. Die Moeglichkeiten zur Realisierung dynamischen Verhaltens
- sind in den Fussnoten zu den einzelnen Parametern beschrieben.
-
- menuetext
- Der Text steht als kurze Beschreibung im Menue.
- ids
- String oder Array von Strings, mit denen sich die Speise bzw. das
- Getraenk beim Bestellen ansprechen laesst.
- minfo
- Mapping mit Eintraegen fuer:
- P_HP LP-Heilung in Punkten [*]
- P_SP KP-Heilung in Punkten [*]
- P_FOOD Saettigungswirkung der Speise [*]
- P_DRINK Saettigungswirkung des Getraenks [*]
- P_ALCOHOL Alkoholgehalt des Getraenks [*]
- P_VALUE Preis der Speise bzw. des Getraenks [*]
- rate [*]
- Heilrate in Punkten pro HeartBeat.
- msg [**]
- Meldung beim Essen:
- Array mit 2 Strings: (1) fuer Empfaenger, (2) fuer Andere.
- Verfuegbare Platzhalter sind weiter unten im Abschnitt "Beispiel"
- dokumentiert.
- refresh
- Mapping mit Eintraegen fuer:
- PR_USER (Kontingent fuer einzelnen Spieler) [*]
- PR_ALL (Zusatzkontingent fuer alle) [*]
- Alternativ: 0 fuer unbegrenzte Verfuegbarkeit
- Einem Key muessen dabei zwei Werte zugeordnet werden:
- Der Erste gibt die Hoehe des Kontingents an, der Zweite legt
- fest, alle wieviel reset()s das Kontingent wieder aufgefuellt
- wird.
- Verwendung des Mappings erfordert Inkludieren von pub.h.
- delay [*]
- Zahl der Sekunden, um die verzoegert die Heilung eintritt,
- z.B. weil das Essen erst zubereitet werden muss.
- d_msg [**]
- Meldung beim Bestellen, falls die Heilung verzoegert wird
- Array mit 2 Strings: (1) fuer Empfaenger, (2) fuer Andere.
-
-
-
- [*] Dieser Parameter kann statt eines festen Zahlenwerts mit
- folgenden Werten gefuellt werden:
-
- 1) Mapping <racemodifier> der Form:
- ([ 0 : <standardwert> ,
- <rasse_1> : <wert_1>,
- ... ,
- <rasse_n> : <wert_n> ]).
- Die Eintraege in diesem Mapping werden gegen die Rasse des
- bestellenden Spielers geprueft und entsprechend die
- zugehoerigen Werte verwendet.
- 2) string <func>: Aufruf erfolgt mittels
- call_other(this_object(), func, empfaenger);
- gerufen (aber: siehe Hinweise).
- 3) closure <func>: Aufruf erfolgt mittels
- funcall(func, empfaenger);
- 4) Array der Form ({string <obj>, string <func>}) oder
- ({object <obj>, string <func>})
- Aufruf erfolgt mittels
- call_other(obj, func, empfaenger);
- (aber: siehe Hinweise). <obj> ist folglich als Objektpointer
- oder dessen object_name() anzugeben. <func> wird mittels
- function_exists() auf Existenz ueberprueft.
-
- HINWEISE: im Falle von Lieferverzoegerung ("delay") und
- Preis (P_VALUE) wird bei allen Funktionsaufrufen NICHT der
- Empfaenger, sondern der Zahler uebergeben.
- Im Falle der Kontingent-Liste ("refresh") kann nur die
- verfuegbare Menge modifiziert werden, nicht die Zeit
- bis zum Wieder-Auffuellen.
-
- [**] Zur Erzeugung variabler Meldungen koennen folgende Werte
- eingetragen werden:
-
- 1) closure <func>: Aufruf erfolgt mittels
- funcall(func, zahler, empfaenger, ident, minfo);
- 2) string <func>: Aufruf erfolgt mittels
- call_other(this_object(), func, zahler, empfaenger,
- ident, minfo);
- <func> bekommt Zahler und Empfaenger als Objektpointer,
- ident als String und minfo als Mapping mit den
- jeweiligen Heilwerten uebergeben. minfo entspricht hierbei
- den Daten, die als dritter Parameter an AddToMenu()
- uebergeben wurden.
- HINWEIS: wenn in das minfo-Mapping keine int-Festwerte
- eingetragen wurden, werden diese gemaess den Regeln unter [*]
- geprueft; Funktionen/Closures werden ggf. ausgewertet und
- deren Rueckgabewerte an die Funktion <func> uebergeben.
- WICHTIG: Die Rueckgabewerte der Funktion werden nicht
- ausgewertet. Jeder, der anstatt einer Meldung einen
- Funktionsaufruf programmiert, muss fuer die Ausgabe der
- Meldungen selbst sorgen.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion werden Speisen oder Getraenke in die Karte
- von Kneipen und Restaurants eingefuegt.
-
-
-RUECKGABEWERT
-=============
-
- Rueckgabewert ist ein String "menuentry%d", wobei %d eine Nummer
- ist, die darueber Auskunft gibt, den wievielten Eintrag in die
- interne Karte der Kneipe diese Speise bzw. dieses Getraenk
- darstellt. Im Prinzip handelt es sich bei dem String um einen Key
- fuer ein Mapping, in dem die Speisen bzw. Getraenke gespeichert
- sind.
-
-
-BEMERKUNGEN
-===========
-
- Die aelteren Funktionen 'AddDrink' bzw. 'AddFood' werden zwar mithilfe
- dieser maechtigeren Funktion aus Gruenden der Abwaertskompatibilitaet
- simuliert, sollen aber nicht mehr eingesetzt werden.
-
-
-
- Die alten Platzhalter && etc. (s.u.) werden weiterhin unterstuetzt,
- sollten aber fuer bessere Wartbarkeit nicht mehr verwendet werden.
-
-
-
- Fuer das Testen der Kneipe gibt es in jeder Kneipe den Befehl
- 'pubinit'. Hiermit lassen sich die Speisen und Getraenke durch-
- checken. Steht in der Ausgabe bei einem Getraenk/Essen ein FAIL,
- so wird die entsprechende Speise (oder Getraenk) NICHT an Spieler
- verkauft. Ausnahmen fuer Speisen/Getraenke mit hoeheren maximalen
- Werten sind durch Balance-EM zu genehmigen.
-
-
-BEISPIEL
-========
-
- include <pub.h>
-
- create()
- {
- AddToMenu("'Opa's Drachenkeule'",({"drachenkeule","keule"}),
- ([P_HP:63,P_SP:63,P_FOOD:9,P_VALUE:528]), 5,
- ({"Du isst die Keule mit einem schlechten Gewissen.",
- "@WER1 isst die Keule mit einem schlechten Gewissen."}),
- ([ PR_USER : 4; 1 , PR_ALL : 20; 3 ]), 9,
- ({"Der unsichtbare Kneipier schneidet einem Rentner ein grosses "
- "Stueck aus dessen Keule und bereitet sie Dir zu. Komisch, muss "
- "wohl ein Tippfehler auf der Karte gewesen sein.",
- "Der unsichtbare Kneipier schneidet einem hilflosen Opa ein "
- "Stueck aus dessen Keule und braet diese fuer @WEN1."}) );
- }
-
- 1) Name der Speise (des Getraenks) auf der Karte (bei menue).
-
- AddToMenu("'Opa's Drachenkeule'",
-
- 2) ids mit denen sich bestellen laesst (z.B. "kaufe keule").
-
- ({"drachen","drachenkeule","keule"}),
-
- 3) Heilung fuer LP und KP, Saettigung (P_FOOD oder P_DRINK,
- P_ALCOHOL nach Belieben setzen), Preis (P_VALUE).
- HP und SP muessen nicht gleich sein. Speisen und Getraenke,
- die nur eines von beiden heilen, sind auch moeglich.
-
- ([P_HP:63,P_SP:63,P_FOOD:9,P_VALUE:528]),
-
- 4) Heilung pro Heartbeat (in diesem Beispiel je 5 KP/LP).
-
-
-
- 5,
-
- 5) Meldungen fuer Spieler und Umstehende die bei Genuss ausgege-
- ben werden (also NICHT der Bestell-Text).
-
- ({"Du isst die Keule mit einem schlechten Gewissen.",
- "@WER1 isst die Keule mit einem schlechten Gewissen."}),
-
- Die Ausgabe-Strings werden vor der Ausgabe mit dem Empfaenger
- als Objekt an replace_personal() uebergeben. Fuer die
- moeglichen Platzhalter siehe dort.
-
-
-
- 6) Die Speise ist in ihrer Anzahl begrenzt. Fuer jeden Spieler
- sind 4 Keulen pro reset() da. Ausserdem gibt es noch einen
- "Notvorrat" von 20 Keulen, der alle 3 reset()s aufgefuellt
- wird. Aus diesem (so noch vorhanden) werden die Spieler
- versorgt, wenn ihr "persoenlicher Vorrat" aufgebraucht ist.
-
- ([ PR_USER : 4; 1 , PR_ALL : 20; 3 ]),
-
-
-
- HINWEIS: bei Benutzung des Mappings muss <pub.h> inkludiert
- werden!
-
-
-
- Wenn man keine reset-abhaengigen Speisen haben moechte, traegt
- man hier eine 0 ein.
-
- 7) Die Zahl ist die Wartezeit in Sekunden, die der Wirt z.B. fuer
- die Zubereitung und Auslieferung an den Spieler braucht.
-
- 9,
-
-
-
- 8) Letztendlich die Meldungen an Spieler und Umstehende, die bei Be-
- stellung (hier 'kaufe keule') ausgegeben werden.
-
- ({"Der unsichtbare Kneipier schneidet einem Rentner ein grosses "
- "Stueck aus dessen Keule und bereitet sie Dir zu. Komisch, muss "
- "wohl ein Tippfehler auf der Karte gewesen sein.",
- "Der unsichtbare Kneipier schneidet einem hilflosen Opa ein "
- "Stueck aus dessen Keule und braet diese fuer @WEN1."}));
-
-LISTE DER ALTEN PLATZHALTER (DEPRECATED):
- && - pl->name(WER,2) &1& - pl->name(WER,2) &2& -
- pl->name(WESSEN,2) &3& - pl->name(WEM,2) &4& - pl->name(WEN,2) &1#
- - capitalize(pl->name(WER,2)) &2# - capitalize(pl->name(WESSEN,2))
- &3# - capitalize(pl->name(WEM,2)) &4# - capitalize(pl->name(WEN,2))
- &! - pl->QueryPronoun(WER) &5& - pl->QueryPronoun(WE); &6& -
- pl->QueryPronoun(WESSEN) &7& - pl->QueryPronoun(WEM) &8& -
- pl->QueryPronoun(WEN) &5# - capitalize(pl->QueryPronoun(WER)) &6# -
- capitalize(pl->QueryPronoun(WESSEN)) &7# -
- capitalize(pl->QueryPronoun(WEM)) &8# -
- capitalize(pl->QueryPronoun(WEN))
-
-
-SIEHE AUCH
-==========
-
- AddFood(), AddDrink(), /sys/pub.h
- RemoveFromMenu(), replace_personal()
-
-Last modified: Sam, 01. Okt 2011, 23:40 by Arathorn
diff --git a/doc/sphinx/man/lfun/AddTouchDetail b/doc/sphinx/man/lfun/AddTouchDetail
deleted file mode 100644
index 6ca61e8..0000000
--- a/doc/sphinx/man/lfun/AddTouchDetail
+++ /dev/null
@@ -1,90 +0,0 @@
-
-AddTouchDetail()
-****************
-
-
-FUNKTION
-========
-
- void AddTouchDetail(string|string* keys,
- string|string*|mapping|closure desc);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion entspricht dem AddDetail() fuer Standarddetails, nur
- koennen hiermit (ab)tastbare bzw. fuehlbare Details realisiert werden:
- Die Beschreibung der Details <keys> wird gesetzt. Wie die Details
- beim (Ab)Tasten aussehen, haengt im wesentlichen vom Typ der
- Beschreibung <desc> ab:
- <desc> ist ein String.
- Beim Untersuchen wird dieser String zurueckgegeben.
- <desc> ist ein String-Array.
- Beim Untersuchen wird zufaellig einer der Strings zurueckgegeben.
- <desc> ist ein Mapping.
- Das Mapping muss folgenden Aufbau haben:
- ([0: "Defaulttext",
- "rasse1": "r1text", ...]).
-
- Falls fuer die Rasse des das Detail untersuchenden Spielers ein
- Eintrag im Mapping existiert, wird der entsprechende Text
- zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
- rassenabhaengige Details moeglich. Siehe auch die Beispiele.
- <desc> ist eine Closure.
- In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
- zurueckgegeben. Die Closure bekommt dabei den Namen des Details
- als Parameter uebergeben.
-
- Fuer fuehlbare Details koennen Forscherpunkte eingetragen werden.
-
- Fuehlbare Details koennen allgemein einen Raum oder Objekt zugeordnet
- werden: dafuer muss man als <key> SENSE_DEFAULT uebergeben.
-
- Spielerkommandos: "taste"
-
-
-BEISPIELE
-=========
-
- Ein kleines Beispiel fuer rassenabhaengige, fuehlbare Details mit Closures:
- string strafe(string key);
- ...
- AddTouchDetail(SENSE_DEFAULT, "Du fuehlst einige Knollen\n");
- AddTouchDetail(({"knollen"}),
- ([0: "Sie fuehlen sich an wie Knoblauchknollen. "
- "Riech doch mal daran.\n",
- "vampir": #'strafe]));
-
- string strafe(string key) {
- this_player()->reduce_hit_points(100);
- return "Au! Das waren ja Knoblauchknollen!\n";
- }
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/AllGroups b/doc/sphinx/man/lfun/AllGroups
deleted file mode 100644
index 6511189..0000000
--- a/doc/sphinx/man/lfun/AllGroups
+++ /dev/null
@@ -1,36 +0,0 @@
-
-AllGroups()
-***********
-
-
-FUNKTION
-========
-
- string *AllGroups()
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-BESCHREIBUNG
-============
-
- Gibt ein Array aller existenten Materialgruppen zurueck (ihre
- Definitionsform wie in <thing/material.h> aufgelistet).
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Listen: AllMaterials(), Dump()
- materialliste, materialgruppen
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/AllMaterials b/doc/sphinx/man/lfun/AllMaterials
deleted file mode 100644
index 57d1f6d..0000000
--- a/doc/sphinx/man/lfun/AllMaterials
+++ /dev/null
@@ -1,36 +0,0 @@
-
-AllMaterials()
-**************
-
-
-FUNKTION
-========
-
- string *AllMaterials()
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-BESCHREIBUNG
-============
-
- Gibt ein Array aller existenten Materialien zurueck (ihre Definitions-
- form wie in <thing/material.h> aufgelistet).
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Listen: AllGroups(), Dump()
- materialliste, materialgruppen
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/AssocMember b/doc/sphinx/man/lfun/AssocMember
deleted file mode 100644
index 139a670..0000000
--- a/doc/sphinx/man/lfun/AssocMember
+++ /dev/null
@@ -1,74 +0,0 @@
-
-AssocMember()
-*************
-
-
-FUNKTION
-========
-
- int AssocMember(object npc)
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- Der zuzuordnende NPC.
-
-
-BESCHREIBUNG
-============
-
- Ordnet einen NPC einem Spieler zu. Dieser ist dann
- immer im Team des Spielers, moeglichst in der gleichen Reihe.
-
-
-RUECKGABEWERT
-=============
-
- 1, falls Zuordnung erfolgreich, sonst 0.
-
-
-BEISPIEL
-========
-
- void fun(object pl)
- {
- if ( pl && pl->AssocMember(this_object()) )
- tell_object(pl,break_string(
- "Ich kaempfe nun auf Deiner Seite!\n",78,"Ein Feuerteufel "
- "teilt Dir mit:");
- ...
- }
-
-
-BEMERKUNGEN
-===========
-
- 1. Kann nur von Gilden, Spellbooks, vom Objekt selber und vom
- zuzuordnenden NPC aufgerufen werden.
- 2. Einem NPC, der selber einem Spieler zugeordnet ist, kann kein
- NPC zugeordnet werden.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_TEAM_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 04.10.2011, Zesstra
diff --git a/doc/sphinx/man/lfun/Attack b/doc/sphinx/man/lfun/Attack
deleted file mode 100644
index 08a0c20..0000000
--- a/doc/sphinx/man/lfun/Attack
+++ /dev/null
@@ -1,42 +0,0 @@
-
-Attack()
-********
-
-
-FUNKTION
-========
-
- void Attack(object enemy)
-
-
-ARGUMENTE
-=========
-
- enemy: Der Feind.
-
-
-BESCHREIBUNG
-============
-
- Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
- stark angegriffen.
-
-
-RUECKGABEWERT
-=============
-
- Keiner.
-
-
-BEMERKUNG
-=========
-
- Diese Funktion gibt die Angriffsmeldung aus.
- Falls mit blossen Haenden angegriffen wird, ist die Staerke
- (2*Staerke_der_Haende + 10*A_STR)/3
-
-
-SIEHE AUCH
-==========
-
- "Defend", "QueryDamage"
diff --git a/doc/sphinx/man/lfun/BecomesNetAlive b/doc/sphinx/man/lfun/BecomesNetAlive
deleted file mode 100644
index a64f328..0000000
--- a/doc/sphinx/man/lfun/BecomesNetAlive
+++ /dev/null
@@ -1,68 +0,0 @@
-
-BecomesNetAlive()
-*****************
-
-
-FUNKTION
-========
-
- void BecomesNetAlive(object pl);
-
-
-GERUFEN VON
-===========
-
- /std/player/base.c
-
-
-ARGUMENTE
-=========
-
- pl
- Spieler, der Verbindung zum MUD wiedererlangt.
-
-
-BESCHREIBUNG
-============
-
- Spieler, welche die Verbindung zum MUD freiwillig
- (z.B. per 'schlafe ein') oder unfreiwillig verlieren, gehen in den
- Netztotenstatus ueber. Sie verbleiben noch eine definierte Zeit in
- der zuletzt betretenen Umgebung und werden schliesslich automatisch
- in den Netztotenraum ueberfuehrt.
- Wird die Verbindung wieder aufgebaut, so wird der Spielercharakter
- wieder zum Leben erweckt und gegebenenfalls zuvor aus dem
- Netztotenraum zurueck zu seiner letzten Umgebung teleportiert.
- Um nun einen Ueberblick darueber zu erhalten, wann ein Spieler die
- Verbindung zum MUD wiederherstellt, gibt es die Funktion
- BecomesNetAlive(). Sie wird automatisch in der Umgebung des
- Spielers, in allen Objekten in der Umgebung des Spielers
- (nicht rekursiv) und in allen Objekten im Spieler (rekursiv)
- aufgerufen. Uebergeben wird hierbei das Spielerobjekt.
-
- Es gibt auch noch die Funktion BecomesNetDead(), mit der man
- auf aehnliche Weise einschlafende Spieler registrieren kann.
-
-
-BEISPIELE
-=========
-
- In einem NPC waere folgendes denkbar:
-
-
-
- void BecomesNetAlive(object pl) {
- tell_room(environment(),break_string(
- "Guten Morgen "+pl->name(WER)+", auch schon ausgeschlafen?!", 77,
- Name(WER)+" sagt grinsend: "));
- }
- Steht der NPC in einem Raum, wo ein Spieler aufwacht, so wird der
- Spieler gebuehrend begruesst.
-
-
-SIEHE AUCH
-==========
-
- BecomesNetDead(), PlayerQuit(), /std/player/base.c, /room/netztot.c
-
-24. Aug 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/BecomesNetDead b/doc/sphinx/man/lfun/BecomesNetDead
deleted file mode 100644
index 8938d13..0000000
--- a/doc/sphinx/man/lfun/BecomesNetDead
+++ /dev/null
@@ -1,67 +0,0 @@
-
-BecomesNetDead()
-****************
-
-
-FUNKTION
-========
-
- void BecomesNetDead(object pl);
-
-
-GERUFEN VON
-===========
-
- /std/player/base.c
-
-
-ARGUMENTE
-=========
-
- object pl
- Spieler, der Verbindung zum MUD verliert.
-
-
-BESCHREIBUNG
-============
-
- Spieler, welche die Verbindung zum MUD freiwillig
- (z.B. per 'schlafe ein') oder unfreiwillig verlieren, gehen in den
- Netztotenstatus ueber. Sie verbleiben noch eine definierte Zeit in
- der zuletzt betretenen Umgebung und werden schliesslich automatisch
- in den Netztotenraum ueberfuehrt.
- Um nun einen Ueberblick darueber zu erhalten, wann ein Spieler die
- Verbindung zum MUD verliert, gibt es die Funktion BecomesNetDead().
- Sie wird automatisch in der Umgebung des Spielers, in allen Objekten
- in der Umgebung des Spielers (nicht rekursiv) und in allen Objekten
- im Spieler (rekursiv) aufgerufen. Uebergeben wird hierbei das
- Spielerobjekt.
-
- Es gibt auch noch die Funktion BecomesNetAlive(), mit der man
- auf aehnliche Weise erwachende Spieler registrieren kann.
-
-
-BEISPIELE
-=========
-
- Es gibt Gebiete, in denen netztote Spieler unerwuenscht sind.
- Folgendermassen kann man sich ihrer wirkungsvoll entledigen:
-
-
-
- void BecomesNetDead(object pl) {
- pl->move("eingangsraum zu gebiet", M_TPORT|M_NOCHECK);
- }
- Man schickt diese Spieler wieder zum Eingang des Gebietes.
- Da der letzte Aufenthaltsort eines Spielers, der in den
- Netztotenstatus uebergeht, erst nach Aufruf der Funktion
- BecomesNetDead() abgespeichert wird, wacht der Spieler dann an dem
- Ort auf, wo man Ihn innerhalb dieser Funktion hinteleportiert hat.
-
-
-SIEHE AUCH
-==========
-
- BecomesNetAlive(), PlayerQuit(), /std/player/base.c, /room/netztot.c
-
-24. Aug 2011, Gloinson
diff --git a/doc/sphinx/man/lfun/CannotSee b/doc/sphinx/man/lfun/CannotSee
deleted file mode 100644
index b86d33a..0000000
--- a/doc/sphinx/man/lfun/CannotSee
+++ /dev/null
@@ -1,49 +0,0 @@
-
-CannotSee()
-***********
-
-
-FUNKTION
-========
-
- varargs int CannotSee(int silent);
-
-
-DEFINIERT IN
-============
-
- /std/living/light.c
-
-
-ARGUMENTE
-=========
-
- silent - Soll an das Lebewesen direkt automatisch eine Meldung
- ausgegeben werden wenn es nichts sehen kann?
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion prueft ob das Lebewesen etwas sehen kann, oder nicht.
- Hierbei wird sowohl das Lichtlevel mit saemtlichen Modifikatoren,
- als auch Nachtsicht und die Property P_BLIND beruecksichtigt. Da
- diese Funktion bei zukuenftigen Mudlibaenderungen immer aktualisiert
- werden duerfte, sollte man sie nach Moeglichkeit benutzen und die
- Abfragen nicht selbst implementieren.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn der Spieler etwas sehen kann
- 1, wenn der Spieler nichts sehen kann: Blindheit
- 2, wenn der Spieler nichts sehen kann: zu wenig Licht/keine Nachtsicht
-
-
-SIEHE AUCH
-==========
-
- P_BLIND, P_LIGHT_MODIFIER, P_PLAYER_LIGHT
-
-Last modified: Mon Jan 17 18:22:27 2000 by Padreic
diff --git a/doc/sphinx/man/lfun/ChangeMiniQuest b/doc/sphinx/man/lfun/ChangeMiniQuest
deleted file mode 100644
index 507bd68..0000000
--- a/doc/sphinx/man/lfun/ChangeMiniQuest
+++ /dev/null
@@ -1,72 +0,0 @@
-
-ChangeMiniQuest()
-*****************
-
-
-FUNKTION
-========
-
- int ChangeMiniQuest(mixed questgeber, int parameter, mixed newvalue)
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion aendert einen Parameter einer Miniquest im Questmaster,
- schreibt fuer diese Aktion einen Log-Eintrag und erstellt das Miniquest-
- Dumpfile neu.
-
-
-ARGUMENTE
-=========
-
- questgeber - Ladename des Objekts (string), das die Miniquest vergibt,
- oderdie Indexnummer (int) der Miniquest in der MQ-Liste
- parameter - Angabe des zu aendernen Parameters (Position des Values
- im Miniquests-Mapping):
- 0 : Miniquest-Stufenpunkte, mind. 1
- 2 : Aufgabenbeschreibung der Miniquest (string)
- 3 : Sichtbarkeit der Miniquest (0/1), default ist 1
- 4 : aktiv/inaktiv (1/0)
- 5 : Titel der Miniquest
- 6 : "geschafft"-Beschreibung nach Abschluss der MQ
- 7 : Voraussetzungen, Mapping im Format von P_RESTRICTIONS
- 8 : zugeordnete Region, String wie z.B."polar", "gebirge"
- 9 : erlaubte Abfrageobjekte, Array von Ladenamen, z.B.
- ({"/d/region/magier/npc/infonpc"}), es koennen mehrere
- Objekte eingetragen sein
- newvalue - neuer Wert fuer den angegebenen Parameter
-
-
-RUECKGABEWERTE
-==============
-
- 1: hat geklappt
- 0: Zugriff verweigert
- -2: ungueltiger Datentyp eines der Argumente, bei Parameter 9 wird
- ein uebergebenes Array zusaetzlich auf Leerstrings und Elemente
- geprueft, die keine Strings sind. Wenn das Array ausschliesslich
- aus solchen Elementen besteht, wird ebenfalls -2 zurueckgegeben.
-
-
-BEMERKUNGEN
-===========
-
- Das Flag "active" laesst sich bequemer ueber die Questmaster-Funktion
- SwitchMiniQuestActive() umschalten.
- Der Miniquest-Titel darf kein "in" oder "im" enthalten, weil dann die
- Eintraege in der Fraternitas-Bibliothek nicht gelesen werden
- koennen.
-
-
-SIEHE AUCH
-==========
-
- AddMiniQuest(L)
- P_RESTRICTIONS
diff --git a/doc/sphinx/man/lfun/ChangeReputation b/doc/sphinx/man/lfun/ChangeReputation
deleted file mode 100644
index c3d010e..0000000
--- a/doc/sphinx/man/lfun/ChangeReputation
+++ /dev/null
@@ -1,72 +0,0 @@
-
-ChangeReputation()
-******************
-
-
-FUNKTION
-========
-
- public varargs int ChangeReputation(string repid, int value, int silent)
-
-
-DEFINIERT IN
-============
-
- /std/player/reputation.c
-
-
-ARGUMENTE
-=========
-
- repid
- Jede neue Reputationsgruppe muss anfangs mit einer eindeutigen ID von
- einem EM in den Reputationsmaster eingetragen werden. Danach kann man
- ueber die eindeutige ID <repid> auf sie zugreifen.
- value
- Der Wert, um den die Reputation geaendert werden soll. Positive Werte
- erhoehen die Reputation, negative verschlechtern sie.
- silent
- Ein optionales Flag. Falls gesetzt, wird keine Standardmeldung ueber
- die Reputationsaenderung an den Spieler ausgegeben. Man koennte dann
- eigene Meldungen ausgeben.
-
-
-BESCHREIBUNG
-============
-
- Vor der Aenderung wird ein Check auf die UID des ausfuehrenden Objektes
- ausgefuehrt, "fremde" Reputationen darf man somit nicht veraendern.
- Man kann aber selbstverstaendlich in begruendeten Faellen mit dem
- zustaendigen Magier/Regionsmagier sprechen, ob man ebenfalls Zugriff
- erhaelt. Eingetragen wird dies schlussendlich durch einen EM.
-
-
-RUeCKGABEWERT
-=============
-
- REP_RET_SUCCESS Reputation wurde veraender.
- REP_RET_SUCCESSCUT Reputation wurde auf Min / Max veraendert
- REP_RET_WRONGARGS Falsche Argumente fuer ChangeRep()
- REP_RET_INVALIDUID Unzulaessige UID / keine Zugriffsrechte
- REP_RET_ALREADYMAX Reputation bereits Max / Min
- REP_RET_INACTIVE Reputation momentan inaktiv
- REP_RET_INVALIDREP Reputation nicht vorhanden
-
-
-BEISPIELE
-=========
-
- s. reputation
-
-
-SIEHE AUCH
-==========
-
- reputation
- GetReputation(), GetReputations()
-
-
-ZULETZT GEAeNDERT
-=================
-
-06.04.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/CheckFindRestrictions b/doc/sphinx/man/lfun/CheckFindRestrictions
deleted file mode 100644
index a021a58..0000000
--- a/doc/sphinx/man/lfun/CheckFindRestrictions
+++ /dev/null
@@ -1,43 +0,0 @@
-
-CheckFindRestrictions()
-***********************
-
-
-FUNKTION
-========
-
- varargs int CheckFindRestrictions(object ob, mixed restr, closure qp)
-
-
-DEFINIERT IN
-============
-
- /std/room/shop.c
-
-
-ARGUMENTE
-=========
-
- ob - Objekt
- restr - zusaetzliches Argument
- qp - symbol_function("QueryProp",ob)
-
-
-BESCHREIBUNG
-============
-
- Funktion, die FindBestWeapon / FindBestArmours einschraenkt.
- Wird in Wert ungleich 0 zurueckgeliefert, so wird das Objekt
- nicht genommen.
-
-
-RUECKGABEWERT
-=============
-
- Normalerweise 0
-
-
-SIEHE AUCH
-==========
-
- FindBestWeapon(), FindBestArmours()
diff --git a/doc/sphinx/man/lfun/CheckLightType b/doc/sphinx/man/lfun/CheckLightType
deleted file mode 100644
index 2296ab8..0000000
--- a/doc/sphinx/man/lfun/CheckLightType
+++ /dev/null
@@ -1,110 +0,0 @@
-
-CheckLightType()
-****************
-
-
-FUNKTION
-========
-
- varargs int CheckLightType(int lighttype, int mode);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- lighttype
- Auf diesen Lichttyp wird getestet.
- mode
- Die Methode, nach der der Lichttyp ueberprueft wird.
-
-
-BESCHREIBUNG
-============
-
- Die Funktion prueft, ob der uebergebene lighttype mit dem in
- P_LIGHT_TYPE definierten Lichttyp uebereinstimmt.
-
- Dabei kann in verschiedenen Modi getestet werden:
-
- LT_CHECK_ANY
- Es wird geprueft, ob mindestens einer der in lighttype ueber
- gebenen Lichttypen im Objekt vorhanden ist. Dies ist das
- Standardverhalten (default) der Funktion.
-
- LT_CHECK_ALL
- Es wird geprueft, ob alle in lighttype definierten Lichttypen
- vorhanden sind. Es koennen aber auch mehr Lichttypen definiert
- sein.
-
- LT_CHECK_MATCH
- Es wird geprueft, ob genau die in lighttype definierten Licht-
- tyen definiert sind, sind mehr oder weniger vorhanden, gibt die
- Funktion 0 zurueck.
-
- LT_CHECK_NONE
- Es wird geprueft, ob keiner der uebergebenen Lichttypen vorhanden
- sind. Ob sonst noch andere Lichttypen vorhanden sind, ist dabei
- egal.
-
-
-RUeCKGABEWERT
-=============
-
- 0 wenn die geprueften Bedingungen nicht korrekt sind, sonst
- ein Wert ungleich 0.
-
-
-BEISPIELE
-=========
-
- In einem Raum scheint die Sonne, ausserdem gibt es dort ein Lager-
- feuer und ein Objekt mit magischem Gluehen (meine Phantasie streikt
- grad):
-
- raum->SetProp( P_LIGHT_TYPE, LT_SUN|LT_OPEN_FIRE|LT_GLOWING );
-
- Es soll getestet werden, ob an in dem Raum Tageslicht herrscht:
-
- raum->CheckLightType(LT_DAYLIGHT, LT_CHECK_ANY);
- raum->CheckLightType(LT_DAYLIGHT); // gleichwertig
-
- Die Funktion ergibt wahr, da LT_DAYLIGHT unter anderem LT_SUN ent-
- haelt (vgl man P_LIGHT_TYPES).
-
- Es soll getestet werden, dass weder Mond noch Sterne im Raum sind:
-
- raum->CheckLightType(LT_MOON|LT_STARS, LT_CHECK_NONE);
-
- Die Funktion ergibt wahr, da die beiden nicht gesetzt sind.
-
- Es soll geprueft werden, ob Mond und Sterne im Raum leuchten:
-
- raum->CheckLightType(LT_MOON|LT_STARS, LT_CHECK_ALL);
-
- Die Funktion ergibt falsch, da keins der beiden Lichter vorhanden
- ist. Sie ergaebe aber auch falsch, wenn einer der beiden Typen
- vorhanden waer. Nur wenn beide vorhanden sind, gibt LT_CHECK_ALL
- wahr.
-
-
-BEMERKUNG
-=========
-
- Lighttypes haben nichts mit dem Lichtsystem zu tun. Sie dienen
- nur der Beschreibung der Lichtverhaeltnisse an/in einem Objekt.
- Objekte mit verschiedenen Lichtverhaeltnissen beeinflussen sich
- gegenseitig nicht.
-
-
-SIEHE AUCH
-==========
-
- /std/thing/description.c, /std/thing/lighttypes.h, P_LIGHT_TYPE
-
-Last modified: Fri Jun 11 20:47:33 2004 by Vanion
diff --git a/doc/sphinx/man/lfun/CheckResistance b/doc/sphinx/man/lfun/CheckResistance
deleted file mode 100644
index bcf64ca..0000000
--- a/doc/sphinx/man/lfun/CheckResistance
+++ /dev/null
@@ -1,37 +0,0 @@
-
-CheckResistance()
-*****************
-
-
-FUNKTION
-========
-
- CheckRessistance(string* dam_type_list)
-
-
-ARGUMENTE
-=========
-
- dam_type_list: Liste der Schadensarten, die geprueft werden
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ueberprueft, gegen welche der angegebenen
- Schadensarten das Lebewesen resistent oder verletzlich ist und
- gibt einen Faktor zurueck, der mit dem Schaden multipliziert wird.
- Dieser Faktor betraegt normalerweise 1, bei bei jeder Resistenz
- wird er halbiert und bei jeder Verletzlichkeit verdoppelt.
-
-
-RUECKGABEWERT
-=============
-
- Ein Faktor, der mit dem Schaden multipliziert wird, vom Typ "float".
-
-
-SIEHE AUCH
-==========
-
- "Defend"
diff --git a/doc/sphinx/man/lfun/CheckSensitiveAttack b/doc/sphinx/man/lfun/CheckSensitiveAttack
deleted file mode 100644
index 74f6220..0000000
--- a/doc/sphinx/man/lfun/CheckSensitiveAttack
+++ /dev/null
@@ -1,54 +0,0 @@
-
-CheckSensitiveAttack()
-**********************
-
-
-FUNKTION
-========
-
- void CheckSensitiveAttack(int dam, string *dam_type, mixed spell,
- object enemy)
-
-
-DEFINIERT IN
-============
-
- /std/living/inventory.c
-
-
-ARGUMENTE
-=========
-
- dam - an Defend uebergebener Schaden
- dam_type - Schadenstyp(en)
- spell - spell, int oder mapping
- enemy - Feindesobjekt
-
-
-BESCHREIBUNG
-============
-
- Wird von Defend() aufgerufen und prueft die Listen in
- P_SENSITIVE_ATTACK durch.
- Wenn die Schluessel und Threshold-Werte stimmen, wird
- trigger_sensitive_attack(enemy,key,dam,spell,options)
- im Objekt gerufen.
-
-
-BEMERKUNGEN
-===========
-
- Objekte mit P_SENSITIVE mit Schluessel SENSITIVE_ATTACK bitte vorsichtig
- verwenden, da rechenintensiv.
-
-
-SIEHE AUCH
-==========
-
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
- P_SENSITIVE_INVENTORY_TRIGGER
-
-28.Jan.2001, Gloinson@MG
diff --git a/doc/sphinx/man/lfun/CheckSpellFatigue b/doc/sphinx/man/lfun/CheckSpellFatigue
deleted file mode 100644
index ac9d3fe..0000000
--- a/doc/sphinx/man/lfun/CheckSpellFatigue
+++ /dev/null
@@ -1,85 +0,0 @@
-
-CheckSpellFatigue()
-*******************
-
-
-FUNKTION
-========
-
- public varargs int CheckSpellFatigue(string key)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
- /std/player/skills.c
- /sys/living/skills.h
-
-
-ARGUMENTE
-=========
-
- string key : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
- oder 0 fuer die globale Spruchermuedung.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion dient zum Pruefen von individuellen Spruchermuedungen
- (Spellfatigue, Spruchsperren).
- Hiermit lassen sich unabhaengige Ermuedungen/Sperren fuer einzelne
- Sprueche oder Gruppen von Spruechen gestalten.
-
- Wird <key> nicht angegeben oder ist 0, wird die globale Spruchsperre
- geprueft (identisch zu der Property P_NEXT_SPELL_TIME), anderenfalls
- die unter <key> gespeicherte Spruchermuedung.
- Prueft man einen Eintrag ohne Angabe von <key> ist das Ergebnis dieser
- Funktion identisch zur Abfrage von P_NEXT_SPELL_TIME.
-
-
-RUeCKGABEWERT
-=============
-
- 0 Spruchermuedung existiert nicht oder ist abgelaufen.
-
- >0 Spruchermuedung ist noch nicht abgelaufen, Rueckgabewert ist die
- Zeit, bei der dieser Eintrag ablaeuft. Der Spruch darf _nicht_
- ausgefuehrt werden.
-
-
-BEISPIELE
-=========
-
- Ein Spell gehoert zu einer Gruppe von Spells mit dem Namen 'extrasuess'.
- Er darf nur ausgefuehrt werden, wenn seit 5s kein anderer Spruch aus der
- Gruppe ausgefuehrt wurde.
- if (ob->CheckSpellFatigue("extrasuess") {
- // alte Sperre noch nicht abgelaufen.
- tell_object(ob, "Deine unendliche Schokotorte ist noch nicht wieder "
- "nachgewachsen.\n");
- return ... ;
- }
-
-
-BEMERKUNGEN
-===========
-
- Die genauen Zeitdauern koennen von Spielern beeinflusst werden, sie
- unterliegen der jeweiligen Einstellung von 'spruchermuedung', d.h. koennen
- auf volle 2s aufgerundet werden.
- Auch wenn diese Funktion zum Verwalten von beliebigen Zeitsperren genutzt
- werden koennen, beschraenkt euch bitte auf Spruchermuedungen und benutzt
- ansonsten check_and_update_timed_key(). Falls ihr diesbzgl. weitere/andere
- Wuensche habt, sprecht den/die Mudlib-EM an.
-
-
-SIEHE AUCH
-==========
-
- SetSpellFatigue(L), DeleteSpellFatigue(L)
- P_NEXT_SPELL_TIME
- spruchermuedung
-
-27.03.2010, Zesstra
diff --git a/doc/sphinx/man/lfun/ClearRingBuffer b/doc/sphinx/man/lfun/ClearRingBuffer
deleted file mode 100644
index 869d298..0000000
--- a/doc/sphinx/man/lfun/ClearRingBuffer
+++ /dev/null
@@ -1,56 +0,0 @@
-
-ClearRingBuffer()
-*****************
-
-
-FUNKTION
-========
-
- protected struct std_ringbuffer ClearRingBuffer(struct std_ringbuffer b);
-
-
-DEFINIERT IN
-============
-
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
-
-
-ARGUMENTE
-=========
-
- b - der zu loeschende Ringpuffer
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion loescht alle Daten aus dem Puffer <b> und re-initialisiert
- ihn.
-
-
-RUeCKGABEWERT
-=============
-
- Der geloeschte Puffer <b> wird wieder zurueckgegeben.
-
-
-BEISPIELE
-=========
-
- // Ringpuffer anlegen:
- struct std_ringbuffer buffer=CreateRingBuffer(10, MODE_FIFO);
- // mit irgendwelchen Daten fuellen...
- // ...
- // Puffer loeschen
- buffer = ClearRingBuffer(buffer);
- // oder:
- ClearRingBuffer(buffer);
-
-
-SIEHE AUCH
-==========
-
- CreateRingBuffer(), RingBufferGet(), ResizeRingBuffer()
-
-23.05.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/Configure b/doc/sphinx/man/lfun/Configure
deleted file mode 100644
index 5a919ce..0000000
--- a/doc/sphinx/man/lfun/Configure
+++ /dev/null
@@ -1,102 +0,0 @@
-
-Configure()
-***********
-
-Configure()
-
- public mixed Configure(mixed data)
-
-
-DEFINIERT IN
-============
-
- Beliebigen Objekten
-
-
-ARGUMENTE
-=========
-
- <data>
- 0 fuer Datenabfrage
- beliebige Daten, die ein Configure(0) vorher lieferte
-
-
-BESCHREIBUNG
-============
-
- Viele Objekte werden fuer bestimmte Spieler konfiguriert und so
- personalisiert. Sie enthalten zusaetzlich zu den Daten, welche waehrend des
- create() gesetzt wurden, noch weitere spieler-individuelle Daten.
- Damit diese Objekte im Bedarfsfall neu erstellt werden koennen, sollte ein
- geeignetes Configure() definfiert werden, um diese Daten abzurufen und in
- einem neuen Clone (oder neugeladener Blueprint) wieder zu setzen.
-
-
-
- Existiert Configure() im Objekt, MUSS dieses bei einem Aufruf mit
- <data>==0 (d.h. Configure(0)) alle individuellen Daten zurueckliefern,
- die noetig sind, um den aktuellen Zustand des Objektes spaeter
- wiederherzustellen.
- Das Objekt darf nach dem Zurueckgeben dieser Daten diese NICHT mehr
- veraendern, d.h. es muss ggf. eine Kopie erstellt werden (copy, deep_copy)
-
- Genau diese Daten werden in einem neu geclonten Objekt durch den Aufruf
- von Configure(data) wieder gesetzt. Das Configure MUSS genau die Daten, die
- es im alten Objekt zurueckliefert, wieder akzeptieren.
-
-
-RUeCKGABEWERT
-=============
-
- Wenn <data>==0:
- Alle individuellen Daten in einer beliebigen Form. Ein Mapping bietet
- sich jedoch an.
- Nicht erlaubt sind: Objekte und Closures.
-
- Wenn <data>!=0:
- 1, wenn die Daten zur Konfiguration akzeptiert wurden.
- 0, sonst.
-
-
-BEMERKUNGEN
-===========
-
- Configure() ist nicht verpflichtet, erneut Daten zu akzeptieren, wenn es
- bereits einmal mit gueltigen Daten aufgerufen wurde.
- Das Zurueckschreiben der Daten kann auch nach Ablauf laengerer Zeit
- und/oder in einer anderen Uptime erfolgen.
-
-
-BEISPIELE
-=========
-
- Ein Objekt, welches ein anderes Objekt sicher ersetzt, d.h. die
- individuelle Konfiguration bleibt erhalten:
- mixed data;
- if (call_resolved(data,ob,"Configure",0) == 1) {
- string obname = load_name(ob);
- ob->remove();
- ob = clone_object(obname);
- if (data) {
- if (ob->Configure(data) == 1) {
- printf("Instanz von %s erfolgreich ersetzt, neues Objekt: %O\n",
- obname,ob);
- }
- else {
- raise_error(sprintf("Configure() in %O akzeptierte Daten nicht!\n",
- ob));
- }
- }
- }
- else {
- printf(break_string(
- "Das Objekt %O definiert keine Funktion Configure(). Es kann "
- "nicht sicher ersetzt werden, da unbekannt ist, ob es individuelle "
- "Daten enthaelt.",78));
- }
-
-
-LETZTE AeNDERUNG
-================
-
-26.09.2011, Zesstra
diff --git a/doc/sphinx/man/lfun/ConvMaterialList b/doc/sphinx/man/lfun/ConvMaterialList
deleted file mode 100644
index 874753b..0000000
--- a/doc/sphinx/man/lfun/ConvMaterialList
+++ /dev/null
@@ -1,65 +0,0 @@
-
-ConvMaterialList()
-******************
-
-
-FUNKTION
-========
-
- varargs string ConvMaterialList(mixed mats, int casus, mixed idinf)
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-ARGUMENTE
-=========
-
- mixed mats: - das zu erkennende Material:
- - ein Mapping, ein String oder ein Stringarray
- ([MAT_A:y,MAT_B:x,..]) oder MAT_A oder ({MAT_A,MAT_B,..})
- int casus: - der Fall: 0..3 -> <language.h>: WAS, WESSEN, WEM, WEN
- mixed idinf - Dinge, welche die Faehigkeiten des Erkennens beeinflussen
- (siehe "man MaterialList")
-
-
-BESCHREIBUNG
-============
-
- Man uebergibt ConvMaterialList() eine Liste von Materialien, die die
- Funktion unter Verwendung von MaterialName() in ihre Bestandteile
- aufsplittet und mit "und" und "," verknuepft zurueckgibt.
-
-
-RUECKGABEWERT
-=============
-
- string - Materialien, durch Komma und "und" getrennt oder
- "unbekanntes Material"
-
-
-BEMERKUNGEN
-===========
-
- Wird von /std/thing/description::MaterialList() gerufen.
- Bitte an Objekten auch MaterialList() verwenden.
- Ruft direkt MaterialName() auf.
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
- Listen: AllMaterials(), AllGroups(), Dump()
- materialliste, materialgruppen
- Master: AddMaterial(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
- Sonstiges: P_MATERIAL_KNOWLEDGE
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/CreateRingBuffer b/doc/sphinx/man/lfun/CreateRingBuffer
deleted file mode 100644
index e10b671..0000000
--- a/doc/sphinx/man/lfun/CreateRingBuffer
+++ /dev/null
@@ -1,70 +0,0 @@
-
-CreateRingBuffer()
-******************
-
-
-FUNKTION
-========
-
- protected struct std_ringbuffer CreateRingBuffer(int size, int newmode);
-
-
-DEFINIERT IN
-============
-
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
-
-
-ARGUMENTE
-=========
-
- size - Groesse des neuen Ringpuffers (int)
- newmode - Ausgabemodus beim Abrufen des Puffers (int):
- MODE_FIFO: First-in-First-Out
- MODE_LIFO: Last-in-First-Out
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion erstellt einen neuen, leeren Ringpuffer der Groesse <size>
- und liefert ihn zurueck. Die Daten des Puffers werden spaeter gemaess
- <newmode> so gespeichert, dass bei der Ausgabe des Puffers mittels
- RingBufferGet() die entweder die neuesten Daten zuerst (MODE_LIFO) oder
- die aeltesten Daten zuerst (MODE_FIFO) geliefert werden.
-
-
-RUeCKGABEWERT
-=============
-
- Der neue Ringpuffer. Dieser wird in einer Struct std_ringbuffer
- gespeichert. Er ist in einer Variable 'mixed' oder in einer mittels
- 'struct std_ringbuffer' angelegten Variable speicherbar.
-
-
-BEMERKUNGEN
-===========
-
- Der gelieferte Ringpuffer sollte nicht per Hand verarbeitet oder
- genaendert werden, sondern nur ueber die Verwaltungsfunktionen aus
- /std/util/ringbuffer.c.
-
-
-BEISPIELE
-=========
-
- // Variable anlegen:
- struct std_ringbuffer buffer;
- // _oder_: mixed buffer;
- // neuen Puffer mit max. 50 Elementen anlegen, der bei der Abfrage die
- // aeltesten Daten zuerst zurueckliefert:
- buffer = CreateRingBuffer(50, MODE_FIFO);
-
-
-SIEHE AUCH
-==========
-
- RingBufferPut(), RingBufferGet(), ResizeRingBuffer()
-
-23.05.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/CustomizeObject b/doc/sphinx/man/lfun/CustomizeObject
deleted file mode 100644
index 2c7736a..0000000
--- a/doc/sphinx/man/lfun/CustomizeObject
+++ /dev/null
@@ -1,84 +0,0 @@
-
-CustomizeObject()
-*****************
-
-
-FUNKTION
-========
-
- string CustomizeObject();
-
-
-DEFINIERT IN
-============
-
- /std/virtual/v_compiler.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUeCKGABEWERT
-=============
-
- Den Objektnamen, den das zuletzt erzeugte Objekt (welches gerade die
- Funktion aufruft) spaeter vom Driver bekommen wird.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ist aus dem Grunde da, da zum Zeitpunkt des Clonens des
- VC-Objektes (P_STD_OBJECT) dieses Objekt ja noch nicht weiss Wer
- oder Was es spaeter mal sein wird.
- Deshalb kann dieses VC-Objekt im create() (und nur da!) die Funktion
- CustomizeObject() in dem virtual_compiler aufrufen, welches das Objekt
- geclont hat und bekommt von diesem den Objektnamen zureck, welches es
- spaeter mal bekommen wird.
- Da das VC-Objekt vom VC geclont wurde, ist previous_object() im create()
- des VC-Objektes der VC, in dem man CustomizeObject() ruft.
-
-
-BEMERKUNGEN
-===========
-
- Das CustomizeObject() im Standard-VC gibt nur den zukuenftigen Objektnamen
- zurueck und macht sonst nix.
-
-
-BEISPIELE
-=========
-
- create() eines VC-Objektes:
-
-
-
- protected void create() {
- ...
-
-
-
- // wer bin ich denn eigentlich?
- string myname = previous_object()->CustomizeObject();
- switch(myname) {
- // Kram konfigurier, ja nach myname...
- }
-
-
-
- ...
- }
-
-
-SIEHE AUCH
-==========
-
- virtual_compiler
- CustomizeObject(), Validate(), NoParaObjects(),
- P_COMPILER_PATH, P_PARA
- /std/virtual/v_compiler.c
-
-21.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/Damage b/doc/sphinx/man/lfun/Damage
deleted file mode 100644
index b36061b..0000000
--- a/doc/sphinx/man/lfun/Damage
+++ /dev/null
@@ -1,56 +0,0 @@
-
-Damage()
-********
-
-
-FUNKTION
-========
-
- int Damage(int dam);
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c und
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- dam Der Wert, mit dem die Waffe/Ruestung beschaedig werden soll.
-
-
-BESCHREIBUNG
-============
-
- P_WC bzw. P_AC wird um dam reduziert und P_DAMAGED wird um
- dam erhoeht.
- Bei dam>0 wird das Objekt beschaedigt, bei dam<0 repariert.
- Dabei werden sowohl die Obergrenzen (s. /sys/combat.h) wie auch
- die Untergrenzen (Waffen:30, Ruestungen: 0) fuer P_WC und P_AC
- beachtet. Es kann auch nicht mehr repariert werden, als vorher
- beschaedigt wurde.
-
-
-RUeCKGABEWERT
-=============
-
- Der Wert der Beschaedigung, die tatsaechlich vorgenommen wurde.
-
-
-BEMERKUNGEN
-===========
-
- Ist das Objekt in Benutzung, setzt die Funktion Damage automatisch
- die Properties P_TOTAL_WC bzw. P_TOTAL_AC in dem benutzenden Spieler
- auf die richtigen Werte.
-
-
-SIEHE AUCH
-==========
-
- /std/armour/combat.c, /std/weapon/combat.c
-
-Last modified: Thu May 22 10:13:23 1997 by Paracelsus
diff --git a/doc/sphinx/man/lfun/DeAssocMember b/doc/sphinx/man/lfun/DeAssocMember
deleted file mode 100644
index f47d548..0000000
--- a/doc/sphinx/man/lfun/DeAssocMember
+++ /dev/null
@@ -1,71 +0,0 @@
-
-DeAssocMember()
-***************
-
-
-FUNKTION
-========
-
- int DeAssocMember(object npc)
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- Der NPC, der nicht mehr zugeordnet sein soll.
-
-
-BESCHREIBUNG
-============
-
- Hebt die Zuordnung eines NPCs zu einem Spieler auf.
-
-
-RUECKGABEWERT
-=============
-
- 1, falls Aufhebung erfolgreich, sonst 0.
-
-
-BEISPIEL
-========
-
- void fun(object pl)
- {
- if ( pl && pl->DeAssocMember(this_object()) )
- tell_object(pl,break_string(
- "Ich kaempfe nun nicht mehr auf Deiner Seite!\n",78,
- "Ein Feuerteufel teilt Dir mit:");
- ...
- }
-
-
-BEMERKUNGEN
-===========
-
- Kann nur von Gilden, Spellbooks, vom Objekt selber und vom
- zugeordneten NPC aufgerufen werden.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/DeclAdj b/doc/sphinx/man/lfun/DeclAdj
deleted file mode 100644
index d7a7f91..0000000
--- a/doc/sphinx/man/lfun/DeclAdj
+++ /dev/null
@@ -1,68 +0,0 @@
-
-DeclAdj()
-*********
-
-
-FUNKTION
-========
-
- varargs string DeclAdj( string adj, int casus, int demon);
-
-
-DEFINIERT IN
-============
-
- /std/thing/language.c
-
-
-ARGUMENTE
-=========
-
- adj
- Das zu deklinierende Adjektiv.
-
- casus
- Der Fall, in den es dekliniert werden soll.
-
- demon
- Bezieht sich das Adjektiv auf einen bestimmten oder einen
- unbestimmten Gegenstand?
-
-
-BESCHREIBUNG
-============
-
- Dekliniert das uebergebene Adjektiv in den angegebenen Fall. Ist demon
- ungleich Null, so wird das Adjektiv so behandelt, als wuerde es sich
- auf einen bestimmten Gegenstand beziehen, ansonsten bezieht es sich auf
- einen unbestimmten Gegenstand.
-
-
-RUeCKGABEWERT
-=============
-
- Das deklinierte Adjektiv. Es wird zusaetzlich noch ein Leerzeichen
- hinten angefuegt!
-
-
-BEISPIELE
-=========
-
- Zunaechst ein bestimmtes Adjektiv:
-
- printf("Der %sBall.\n", ball->DeclAdj("gruen", WER, 1);
-
- Nun ein unbestimmtes Adjektiv:
-
- printf("Ein %sBall.\n", ball->DeclAdj("gruen", WER, 0);
-
- Da DeclAdj() "gruene " bzw. "gruener " zurueckgibt, darf zwischen dem
- "%s" und dem "Ball" kein Leerzeichen stehen!
-
-
-SIEHE AUCH
-==========
-
- /std/thing/language.c
-
-Last modified: Wed May 8 10:18:05 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/Defend b/doc/sphinx/man/lfun/Defend
deleted file mode 100644
index aa53945..0000000
--- a/doc/sphinx/man/lfun/Defend
+++ /dev/null
@@ -1,175 +0,0 @@
-
-Defend()
-********
-
-
-FUNKTION
-========
-
- public int Defend(int dam, string|string* dam_type, int|mapping spell,
- object enemy)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat
-
-
-ARGUMENTE
-=========
-
- int dam initiale Staerke des Angriffs (10 dam ~ 1 HP)
- string* dam_type Art(en) des Schadens, der angerichtet werden
- soll
- Muss ein Array von Schadenstypen sein,
- alte Objekte uebergeben hier manchmal strings.
- int/mapping spell - 0 fuer normale Angriffe (keine Zauber)
- - 1 fuer Zauber (Standardruestungen ignorieren)
- - mapping fuer mehr Informationen
- Heute bitte nach Moeglichkeit ein Mapping
- uebergeben.
- object enemy der Feind/Schadenverursacher
-
-
-BESCHREIBUNG
-============
-
- 1. Generell
- Wenn das Lebewesen angegriffen wird, wird geprueft, wie stark die
- Ruestungen und koerpereigenen Abwehrkraefte sind und die Staerke des
- Schadens dementsprechend vermindert.
- Ggf. wird der Schaden zugefuegt und der Feind in die Liste der Feinde
- aufgenommen. Der Schaden betraegt:
- (dam-Summe(Ruestungsstaerken)-random(P_BODY+A_DEX))*CheckResistance/10
- aber nicht unter 0.
-
- 2. Der Parameter 'spell'
- Ist 'spell' 0, dann gilt der Angriff als normale physische Attacke
- Uebergibt man als 'spell'-Parameter ein Mapping, so gibt es dafuer
- diverse Flags, die das Ergebnis manipulieren (in new_skills.h
- enthalten). Nichtangabe eines Flags gilt als 0.
-
- - SP_PHYSICAL_ATTACK ---------- 0/1
- 1, wenn Ruestungen wirken sollen, 0 sonst
- -> entspricht !spell, wenn dieses Int ist
- - SP_NO_ENEMY ----------------- 0/1
- 1, falls der Angriff nicht toedlich ist, es also keinen echten
- Gegner gibt
- -> es wird dann reduce_hit_points() gerufen statt do_damage()
- - SP_NO_ACTIVE_DEFENSE -------- 0/1
- 1, falls aktive Abwehren (wie zurueckschlagende Amulette,
- Karateabwehren oder Ausweichmanoever) unterbleiben sollen
- -> zB bei Kratzen durch Dornen oder Fall aus grosser Hoehe
- ist aktive Abwehr oder Ausweichen unlogisch
- - SP_RECURSIVE ---------------- 0/1
- 1, falls der Spell aus einem Defend gerufen wurde (oder einer
- DefendFunc)
- -> verhindert Rekursionsprobleme
- - SP_NAME --------------------- string
- Name des Spells
- - SP_REDUCE_ARMOUR ------------ Mapping: keys AT_X/P_BODY, values int>=0
- Die Schutzwirkung durch P_AC/Magie einer Ruestung wird
- typabhaengig reduziert. Aufbau eines Mappings im Beispiel:
- ([AT_BOOTS: 0, // Stiefel schuetzen gar nicht
- P_BODY: 50, // Koerper zu 50%
- AT_BELT: 600 // Guertel zu 600%
- ])
- -> alle 'fehlenden' Eintraege wirken normal
- - SP_SHOW_DAMAGE -------------- 0/1 oder Array von Arrays
- 0, fuer keine Treffermeldung, 1 sonst
- In einem Array koennen Ersatz-Treffermeldungen definiert
- werden. Format ist:
- ({
- ({ int lphit1, string mess_me,
- string mess_en,
- string mess_room }),
- ({ lphit2, mess_me, mess_en, mess_room }),
- ...
- ({ lphitn, mess_me, mess_en, mess_room }),
- })
- wobei lphit1<lphit2<...<lphitn sein muss, d.h. das Array-
- Array aufsteigend sortiert.
-
- Ist ein Treffer x LP hart, werden die Meldungen des lphit-
- Arrays ausgegeben, dessen Wert am naehesten unter dem Schaden
- liegt.
-
- In den Meldungen mess_me (an den Getroffenen), mess_en (an
- den Feind), mess_room (an die restlichen Umstehenden) koennen
- Ersatzstrings wie folgt verwendet werden:
- @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
- @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
- - EINFO_DEFEND ------------ Mapping
- Dieses Mapping liefert erweiterte Informationen zu dem
- bisherigen Ablauf des aktiven Attacks.
- Die verfuegbaren Informationen sind in der Manpage zu
- DefendInfo festgehalten.
-
- 3. Reihenfolgen in Defend
- - das Living wird angegriffen, wenn
- - P_NO_ATTACK != 0
- - 'enemy' existiert und kein netztoter Spieler ist
- - P_DEFENDERS werden durchgegangen (und eventuell benachrichtigt)
- - P_TMP_ATTACK_HOOK wird abgefragt
- - die Ruestungen werden vom Schaden gegebenenfalls abgezogen
- - magischer Ausweichskill beruecksichtigt
- - sensitive Objekte werden ggf. benachrichtigt
- - InternalModifyDefend wird gerufen
- - Koerperabwehr abgezogen
- - der Schaden an do_damage()/reduce_hit_points() uebergeben
- - Flucht ueberpruefen mit CheckWimpyAndFlee()
-
-
-BEMERKUNGEN
-===========
-
- Ruestungen wirken konventionell nur, wenn mindestens ein Schadensanteil
- mechanisch ist und es kein Spell oder ein Spell mit SP_PHYSICAL_ATTACK
- auf 1 ist.
-
- Defend() beruecksichtigt magische Verteidigungen, die der Spieler bei
- sich hat, sollte also aus Fairness gegenueber den Objekten anderer
- Magier immer dem direkten reduce_hit_points() oder do_damage()
- vorgezogen werden. Mittels der Flags in 'spell' kann man sehr viel
- aendern.
-
-
-RUECKGABEWERT
-=============
-
- Hoehe des tatsaechlichen Schadens. Dies kann mehr sein als die
- Lebenspunkte des Lebewesens.
-
-BEISPIELE (SIEHE AUCH Defend_bsp):
- // ein simpler Angriff: enem->Defend(100, ({DT_BLUDGEON}), 0,
- this_object());
-
- // ein magischer Angriff (ohne Treffermeldung): enem->Defend(100,
- ({DT_BLUDGEON, DT_FIRE}), 1, this_object());
-
- // ein magischer Angriff mit Treffermeldung: enem->Defend(100,
- ({DT_BLUDGEON, DT_FIRE}), ([SP_SHOW_DAMAGE:1]),
-
- this_object());
-
-
-SIEHE AUCH
-==========
-
- Angriff: Attack(L), P_NO_ATTACK, InsertEnemy(L)
- Schaden: P_ENABLE_IN_ATTACK_OUT, P_LAST_MOVE,
- do_damage(L), reduce_hit_points(L)
- Schutz: P_DEFENDERS, InformDefend(L), DefendOther(L)
- P_ARMOURS, P_AC, P_DEFEND_FUNC, QueryDefend(L)
- P_BODY, A_DEX
- Daten: P_LAST_COMBAT_TIME
- P_LAST_DAMTYPES, P_LAST_DAMTIME, P_LAST_DAMAGE
- P_DAMAGE_MSG
- Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance(L)
- Sonstiges: CheckSensitiveAttack(L)
- InternalModifyDefend(L)
- UseSkill(L),
- DefendInfo
-
-15.09.2010, Zesstra
diff --git a/doc/sphinx/man/lfun/DefendFunc b/doc/sphinx/man/lfun/DefendFunc
deleted file mode 100644
index 1683b3f..0000000
--- a/doc/sphinx/man/lfun/DefendFunc
+++ /dev/null
@@ -1,107 +0,0 @@
-
-DefendFunc()
-************
-
-
-DefendFunc(L)
-=============
-
-
-FUNKTION
-========
-
- int DefendFunc(string|string *dtyp, int|mappingspell, object enemy);
-
-
-DEFINIERT IN
-============
-
- eigenen Objekten; fuer /std/armour/combat.c
-
-
-ARGUMENTE
-=========
-
- dtyp
- Schadenstypen der Angriffsart.
- Sollte heute ein string* sein.
- spell
- 0 bei veralteten konventionellen Angriffen im Regelfall jedoch
- ein Mapping mit weiteren Infos.
- Bei einem konventionellen Angriff ist spell[SP_PHYSICAL_ATTACK] gleich
- 1.
- enemy
- Der angreifende Gegner
-
-
-BESCHREIBUNG
-============
-
- Anhand der uebergebenen Parameter kann hier ein Ruestungsbonus (oder
- auch ein Ruestungsmalus) errechnet werden, der zu dem normalen
- Ruestungswert (abhaengig von der Angriffsart) hinzuaddiert wird.
-
-
-RUeCKGABEWERT
-=============
-
- Der Ruestungsbonus, der zur Ruestungsklasse addiert werden soll.
-
-
-BEMERKUNGEN
-===========
-
- Auch wenn man eine DefendFunc() benutzt, darf der Rueckgabewert
- zusammen mit der P_AC insgesamt nur in sehr seltenen, wohldurch-
- dachten Ausnahmefaellen die maximal zulaessige P_AC fuer diesen
- Ruestungstyp ueberschreiten. In solchen Ausnahmefaellen duerfen
- die DefendFuncs nicht konstant wirken.
-
- Bei aktivem Zurueckschlagen IMMER auf Flags wie SP_RECURSIVE und
- SP_NO_ACTIVE_DEFENSE pruefen und ggf. abbrechen.
-
-
-BEISPIELE
-=========
-
- Eine Ruestung, die bei Angriffen mit Feuer ihre volle Staerke entfaltet
- und bei Angriffen durch Geister geschwaecht wird:
-
- void create()
- {
- ::create();
-
- SetProp(P_ARMOUR_TYPE, AT_ARMOUR);
- SetProp(P_AC, 20);
- ...
- // Die DefendFunc() ist in der Ruestung selbst definiert
- SetProp(P_DEFEND_FUNC, this_object());
- }
-
- int DefendFunc(string *dtyp, mixed spell, object enemy)
- {
- int prot;
-
- // Zuerst fragen wir den Angriff durch Feuer ab:
- if (member(dtyp, DT_FIRE) >= 0) // Feuer gehoert zu den Schadenstypen
- prot = 5 + random(10); // Das ergibt maximal 14. Zusammen mit P_AC
- // kommt man also maximal auf 14+20 = 34,
- // liegt also unter der fuer AT_ARMOUR
- // geltenden Obergrenze
-
- // Und jetzt der Geistertest
- if (enemy->QueryProp(P_RACE) == "Geist" ||
- enemy->is_class_member(CL_GHOST))
- prot -= random(10);
-
- // Der Rueckgabewert wird auf den aus P_AC errechneten Wert draufgeschlagen
- return prot;
- }
-
-
-SIEHE AUCH
-==========
-
- P_DEFEND_FUNC, QueryDefend(), /std/armour/combat.c
-
-Last modified: 18.Jul 2006 Muadib
diff --git a/doc/sphinx/man/lfun/DefendInfo b/doc/sphinx/man/lfun/DefendInfo
deleted file mode 100644
index 21d41ac..0000000
--- a/doc/sphinx/man/lfun/DefendInfo
+++ /dev/null
@@ -1,216 +0,0 @@
-
-DefendInfo()
-************
-
-
-FUNKTION
-========
-
-
-DEFINIERT IN
-============
-
- /sys/combat.h
-
-
-ARGUMENTE
-=========
-
-
-BESCHREIBUNG
-============
-
- Die DefendInformationen werden im Runde eines Attack/Defend Vorgangs
- in Attack initial angelegt und dem Defend ueber den Parameter spell
- uebergeben. Ist dieser Parameter ein Mapping, so sind die
- DefendInformationen ueber den Key EINFO_DEFEND zu erhalten.
- Die Informationen liegen in Form eines Mappings vor.
- Vor Zugriff sollte immer auf die Existenz dieses Keys in dem Mapping
- geprueft werden, da nicht alle Informationen immer existieren.
- Die Keys sind in combat.h definiert und sind folgende:
-
-
-
- ORIGINAL_AINFO - Mapping
- Hier ist eine Kopie des originalen ainfo-mappings des Attacks
- vorhanden mit folgenden Eintraegen:
- Immer vorhandene Eintraege:
- SI_ENEMY der angegriffene Gegner
-
-
-
- Angriff mit gezueckter Waffe:
- P_WEAPON das Waffenobjekt selbst
- P_WEAPON_TYPE P_WEAPON_TYPE der Waffe
- P_WC P_WC der Waffe
- P_NR_HANDS P_NR_HANDS der Waffe
- SI_SKILLDAMAGE_TYPE P_DAM_TYPE der Waffe
- SI_SKILLDAMAGE waffe->QueryDamage(enemy)
- bei vorhandenem Zweihandskill SK_TWOHANDED wird nur der durch
- den Skill modifizierte Schadenswert uebernommen
- SI_SKILLDAMAGE_MSG "mit "+waffe->name(WEM,0)
- SI_SKILLDAMAGE_MSG2 "mit "+waffe->name(WEM,1)
- SI_SPELL 0
-
- Angriff mit blossen Haenden:
- P_WEAPON_TYPE WT_HANDS
- P_WC P_HANDS[1]
- SI_SKILLDAMAGE Schadenswert, aus P_HANDS[1] und A_STR
- berechnet
- SI_SKILLDAMAGE_TYPE P_HANDS[2]
- SI_SKILLDAMAGE_MSG
- SI_SKILLDAMAGE_MSG2 beides P_HANDS[0]
- SI_SPELL 0
-
-
-
- Angriff mit einem Spell (SK_MAGIC_ATTACK):
- SI_SKILLDAMAGE Schadenswert des Spells
- SI_SKILLDAMAGE_TYPE Schadenstypen des Spells
- SI_SKILLDAMAGE_MSG Schadensmeldung des Spells, wenn vorhanden,
- sonst "mit magischen Faehigkeiten"
- SI_SKILLDAMAGE_MSG2 entsprechende Meldung des Spells, wenn
- gesetzt, ansonsten identisch mit
- SI_SKILLDAMAGE_MSG
- P_WEAPON_TYPE P_WEAPON_TYPE des Spells, wenn vorhanden,
- sonst WT_MAGIC
- SI_SPELL SI_SPELL des Spells
-
-
-
- Hinweise:
- - Alle Eintraege in diesem Mapping koennen bereits durch
- InternalModifyAttack() veraendert worden sein.
- - Die Daten werden mittels deep_copy(ainfo) eingetragen.
- - Daten in den Eintraegen SI_SKILLDAMAGE* und SI_SPELL koennen bei
- physikalischen Angriffen durch die Skills FIGHT(P_WEAPON_TYPE) oder
- SK_FIGHT oder durch einen P_TMP_ATTACK_MOD bzw. Hook vom Typ
- H_HOOK_ATTACK_MOD modifiziert worden sein.
-
-
-
- ORIGINAL_DAM - int
- Der Originalschaden aus dem Attack
-
- ORIGINAL_DAM_TYPE - string/string*
- Der Originaldamagetyp aus dem Attack
-
- CURRENT_DAM - int
- Der momentane Schaden, nach schon erfolgten Modifikationen
-
-
-
- CURRENT_DAM_TYPE - string/string*
- Der momentane Damagetyp, nach schon erfolgten Modifikationen
-
-
-
- ENEMY_INSERTED - int
- 0 oder 1 je nachdem ob der Angreifer schon in der enemy-list
- vorhanden war oder nicht
-
-
-
- RFR_REDUCE - int
- 0 oder reduzierter Schaden durch RFR Modifikation
-
-
-
- PRESENT_DEFENDERS - Array
- Liste der durch InformDefend informierten Defender als Objekt.
- Ein Defender wird immer NACH InformDefend
- dazugefuegt
-
-
-
- DEFENDING_DEFENDER - Array ({})
- Hat ein durch InformDefend ein Defender verteidigt, so wird
- fuer diesen Defender ein Eintrag in diesem Array vorgenommen,
- welcher folgende Struktur besitzt.
- ({
- DEF_DEFENDER - Object
- Der Verteidiger, welcher VOR
- DefendOther eingefuegt wird
- DEF_DAM - int
- Der veraenderte Schaden, welcher NACH
- DefendOther eingefuegt wird
- DEF_DAMTYPE string/string*
- Die veraenderte Schadensart, welche
- NACH DefendOther eingefuegt wird
- DEF_SPELL - Mapping
- Das Mapping des veraenderten Spells, welches
- als Kopie NACH DefendOther eingefuegt wird
- })
-
-
-
- DEFEND_HOOK - Int/Array
- DI_NOHOOK, wenn kein Hook da war, DI_HOOKINTERRUPT, wenn der
- Hook das Defend unterbricht, DI_HOOK, wenn ein Hook vorhanden
- ist, dieser das Defend aber unveraendert laesst.
- Veraendert ein Hook das Defend, so ist hier ein Array zu finden
- mit den veraenderten Parametern in der Struktur:
- ({
- HOOK_DAM - int
- Der veraenderte Schaden
- HOOK_DAMTYPE - string/string*
- Die veraenderte Schadensart
- HOOK_SPELL - Mapping
- Das Mapping des veraenderten Spells als Kopie
- })
-
-
-
- DEFEND_ARMOURS - Mapping (2 Werte pro Key)
- Liste der beruecksichtigten Ruestungen. Fuer jede Ruestung
- wird ein Eintrag vorgenommen, mit dem Objekt der jeweiligen
- Ruestung als Key. Hierbei werden die Ruestungen erst eingetragen,
- wenn ihr jeweiliges QueryDefend() aufgerufen wird, d.h. es sind nicht
- von Anfang an alle getragenen Ruestung drin. Jeder Eintrag im Mapping
- besitzt die folgenden 2 Werte:
- DEF_ARMOUR_DAM - int
- Der Schaden NACH QueryDefend (vorher 0)
- DEF_ARMOUR_PROT - int
- Verteidigungswert der Ruestung VOR DefendFunc
- Bsp: Ich will wissen, wie gut 'ruestung' schuetzte:
- spell[EINFO_DEFEND][DEFEND_ARMOURS][ruestung,DEF_ARMOUR_PROT]
-
- DEFEND_GUILD - Array
- Eine Liste mit der Modifikation der Gilde mit der Struktur
- ({
- GUILD_DAM - int
- Der veraenderte Schaden
- GUILD_DAMTYPE - string/string*
- Die veraenderte Schadensart
- })
-
-
-
- DEFEND_RESI - int
- Schaden nach CheckResistance
-
-
-
- DEFEND_BODY - int
- Schaden nach Beruecksichtigung des Bodies (nur
- physikalisch)
-
-
-
- DEFEND_LOSTLP - int
- Tatsaechlich abgezogene LP
-
-
-
- DEFEND_CUR_ARMOUR_PROT - int
- Schutz der Ruestung vor Call der
- DefendFunc. Ist nur in der DefendFunc definiert. Kann auch aus
- DEFEND_ARMOURS entnommen werden
-
-
-SIEHE AUCH
-==========
-
- Attack, Defend
-
-18.Jul 2006 Muadib
diff --git a/doc/sphinx/man/lfun/DefendOther b/doc/sphinx/man/lfun/DefendOther
deleted file mode 100644
index f0386f2..0000000
--- a/doc/sphinx/man/lfun/DefendOther
+++ /dev/null
@@ -1,107 +0,0 @@
-
-DefendOther()
-*************
-
-
-FUNKTION
-========
-
- mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- dam
- Der Schaden, der voraussichtlich beim zu verteidigenden Lebewesen
- verursacht werden soll.
- dam_type
- Der Schadenstyp (oder die Schadenstypen), der beim zu
- verteidigenden Lebewesen verursacht werden sollen.
- spell
- Wenn das zu verteidigende Lebewesen mit Spells angegriffen wurde,
- so koennte man hier mehr Infos entnehmen.
- enemy
- Der Feind, der ein zu verteidigendes Lebewesen angegriffen hat.
-
-
-RUeCKGABEWERT
-=============
-
- Array mit den Eintraegen der gegebenenfalls veraenderten
- uebergebenen Parameter:
- (1) dam [Typ int],
- (2) dam_type [Typ string*],
- (3) spell [Typ mapping].
-
-
-BESCHREIBUNG
-============
-
- Es ist moeglich, dass Objekte Angriffe auf Lebewesen abwehren oder
- umwandeln, sofern diese Objekte bei dem angegriffenen Lebewesen
- mittels AddDefender() angemeldet wurden und sich der selben Umgebung
- befinden.
- Zumeist wird es sich bei den Objekten natuerlich ebenfalls um
- andere Lebewesen handeln, die das Lebewesen, bei dem sie angemeldet
- sind, verteidigen sollen.
- Bei einem Angriff auf das Lebewesen koennen alle Objekte per Aufruf
- von DefendOther() in einen Angriff eingreifen, wobei die
- Schadensstaerke, der Schadenstyp (die Schadenstypen),
- Zusatzinformationen fuer Angriffsspells und der Angreifer als
- Parameter uebergeben werden.
- Desweiteren ist zu beachten, dass bei als physikalisch markierten
- Angriffen in einem Team nur Verteidiger aus der ersten Reihe
- beruecksichtigt werden und dass bei einem Angriff zufaellig aus
- allen moeglichen Verteidigern ausgewaehlt wird.
- Standardmaessig ist diese Funktion in Lebewesen bereits definiert,
- wobei der Skill SK_DEFEND_OTHER, sofern vorhanden, aufgerufen wird.
-
-
-BEISPIEL
-========
-
- Sehr beliebt sind in Gilden NPCs, die den Beschwoerer begleiten und
- verteidigen, z.B. beschworene Daemonen:
- inherit "std/npc";
- include <properties.h>
- object owner;
- void create()
- { ::create();
- SetProp(P_NAME,"Daemon");
- ...
- }
- // nach Clonen des Daemons folgende Funktion mit Beschwoerer als
- // Parameter aufrufen
- Identify(object caster)
- { if(!objectp(caster))
- call_out(#'remove,0);
- owner=caster;
- owner->AddDefender(this_object());
- }
- // der Daemon wehrt jeden Angriff mit Feuer voll ab, man muss zuerst
- // den Verteidiger umbringen, um den Beschwoerer toeten zu koennen
- mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy)
- { if(sizeof(dam_type)&&member_array(DT_FIRE,dam_type)!=-1)
- dam=0;
- return({dam,dam_type,spell});
- }
- Soll der Daemon sich auch in ein Team einordnen, in welchem sich der
- Beschwoerer eventuell befindet, so ist zusaetzlich AssocMember() in
- diesem Beschwoerer aufzurufen, wobei der Daemon als Parameter
- uebergeben wird.
-
-
-SIEHE AUCH
-==========
-
- AddDefender(), RemoveDefender(), InformDefend(), Kill(), IsEnemy(),
- P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
-
-Last modified: Fri Feb 25 14:45:00 2000 by Paracelsus
diff --git a/doc/sphinx/man/lfun/Defend_bsp b/doc/sphinx/man/lfun/Defend_bsp
deleted file mode 100644
index 9feb25f..0000000
--- a/doc/sphinx/man/lfun/Defend_bsp
+++ /dev/null
@@ -1,155 +0,0 @@
-
-Defend_bsp()
-************
-
-
-Defend() - BEISPIELE
-====================
-
-
-FUNKTION
-========
-
- varargs int Defend(int dam, mixed dam_type, mixed spell, object enemy)
-
-
-BEMERKUNGEN
-===========
-
- Die hier aufgefuehrten Komplexbeispiele sind zum Verstaendnis gedacht.
-
-
-BEISPIELE
-=========
-
- 1) Ein ordinaerer Biss ins Bein.
- this_player()->Defend(random(500),
- ({DT_PIERCE, DT_RIP}),
- 0,
- this_object());
-
- 2) Ein Biss ins Bein, mit der Hose als 200%ige Ruestung und Rest mit 100%.
- this_player()->Defend(random(500),
- ({DT_PIERCE, DT_RIP}),
- ([SP_PHYSICAL_ATTACK: 1,
- SP_REDUCE_ARMOUR: ([AT_TROUSERS: 200])
- ]),
- this_object());
-
- 3) Der Biss, wenn ein Tier in die Hose gekrochen ist und dieser ohne
- Treffermeldung und physischen Ruestungsschutz durchgeht.
- this_player()->Defend(random(500),
- ({DT_PIERCE, DT_RIP}),
- ([SP_PHYSICAL_ATTACK: 0]),
- this_object());
-
- 4) Spell-Parameter
- // Beispiel fuer einen Spell, der nur vom Helm normal und von einem
- // Amulett mit 115% aufgehalten wird, alle anderen (angebenenen)
- // Ruestungen haben 0% Schutzwirkung.
- // Mit Ausgabe eigener Meldungen: beginnend mit -1, da der verursachte
- // Schadenswert minimal 0 wird (fuers Ersetzen: Feind: @WEx2,
- // Spieler: WEx1); maximal wird er (Empfindlichkeiten jetzt mal aussen
- // vor) 49 (499/10 = 49), nicht 499!!!
- this_player()->Defend(
- random(500),
- ({DT_PIERCE, DT_AIR}),
- ([SP_PHYSICAL_ATTACK: 1, // wegen DT_PIERCE
- SP_REDUCE_ARMOUR: ([AT_ARMOUR: 0,
- AT_HELMET: 100,
- AT_RING: 0,
- AT_GLOVE: 0,
- AT_CLOAK: 0,
- AT_BOOT: 0,
- AT_TROUSERS: 0,
- AT_SHIELD: 0,
- AT_AMULET: 115,
- AT_MISC: 0,
- AT_BELT: 0,
- AT_QUIVER: 0])
- SP_SHOW_DAMAGE:
- ({({-1,"@WER2 schrammt Dich mit einem durchbohrenden Blick.",
- "Du schrammst @WEN1 mit einem durchbohrenden Blick.",
- "@WER2 schrammt @WEN1 mit einem durchbohrenden Blick."
- }),
- ({5,"Der durchbohrende Blick von @WEM2 trifft Dich.",
- "Dein durchbohrender Blick trifft @WEN1.",
- "Der durchbohrende Blick von @WEM2 trifft @WEN1."
- }),
- ({20,"@WESSEN2 stechender Blick durchbohrt Dich.",
- "Dein stechender Blick durchbohrt @WEN1.",
- "@WESSEN2 stechender Blick durchbohrt @WEN1."
- })})
- ]),
- this_object());
-
- // Etwas geschickter geht das Ganze, wenn wir einfach aus der Mudlib
- // alle existierenden Ruestungen in ein Mapping packen und diese
- // nullen (damit sind wir auch gegen neue Ruestungstypen sicher):
- mapping amap = map_indices(VALID_ARMOUR_CLASS,#'!);
- amap[AT_HELMET]=100;
- amap[AT_AMULET]=115;
-
- this_player()->Defend(random(500),
- ({DT_PIERCE, DT_AIR}),
- ([SP_PHYSICAL_ATTACK: 1,
- SP_REDUCE_ARMOUR: amap,
- SP_SHOW_DAMAGE: ({ ... (siehe oben)
-
- 5) Der Biss von weiter oben mit Meldung.
- // Eine Meldung, die nur ausgegeben wird, wenn der Biss auch mindestens
- // einen LP abzieht.
- this_player()->Defend(random(500),
- ({DT_PIERCE, DT_RIP}),
- ([SP_PHYSICAL_ATTACK: 1,
- SP_REDUCE_ARMOUR: ([AT_TROUSERS: 200]),
- SP_SHOW_DAMAGE: ({
- ({1,"@WER2 beisst Dich ins Bein!",
- "Du beisst @WEN1 ins Bein!",
- "@WER2 beisst @WEN1 ins Bein!"
- }) })
- ]),
- this_object());
-
- 6) DefendFunc() und Defend() in einem Objekt
- 6a)
- // eine Luftangriffe reflektierende Ruestung:
- int DefendFunc(string *dtyp, mixed spell, object enemy) {
- if(member(dtyp, DT_AIR)>=0 && !spell[SP_RECURSIVE])
- enemy->Defend(random(200),
- ({DT_AIR}),
- ([SP_RECURSIVE: 1,
- SP_SHOW_DAMAGE:
- ({"Ein Luftwirbel erfasst auch Dich.",
- "Deine Ruestung wirbelt @WEN1 herum.",
- "@WESSEN2 Ruestung wirbelt @WEN1 herum."
- })
- ]),
- QueryProp(P_WORN));
-
- return 0; // -> In diesem Fall gibts keinen Ruestungsbonus!
- }
-
- 6b)
- // Eine NUR REINE Luftangriffe reflektierende Ruestung:
- int DefendFunc(string *dtyp, mixed spell, object enemy) {
- if(!sizeof(dtyp-({DT_AIR})) && !spell[SP_RECURSIVE])
- ...
-
-
-SIEHE AUCH
-==========
-
- Angriff: Attack(L), P_NO_ATTACK, InsertEnemy(L)
- Schaden: P_ENABLE_IN_ATTACK_OUT, P_LAST_MOVE, do_damage(L),
- reduce_hit_points(L), reduce_spell_points(L)
- Schutz: P_DEFENDERS, InformDefend(L), DefendOther(L),
- P_ARMOURS, P_AC, P_DEFEND_FUNC, QueryDefend(L),
- P_BODY, A_DEX, Defend(L)
- Daten: P_LAST_COMBAT_TIME, P_LAST_XP, P_LAST_DAMAGE,
- P_LAST_DAMTYPES, P_LAST_DAMTIME
- Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance(L)
- Sonstiges: CheckSensitiveAttack(L), UseSkill(L),
- InternalModifyDefend(L)
-
-25. Mai 2011 Gabylon
diff --git a/doc/sphinx/man/lfun/DeleteSpellFatigue b/doc/sphinx/man/lfun/DeleteSpellFatigue
deleted file mode 100644
index f01755b..0000000
--- a/doc/sphinx/man/lfun/DeleteSpellFatigue
+++ /dev/null
@@ -1,55 +0,0 @@
-
-DeleteSpellFatigue()
-********************
-
-
-FUNKTION
-========
-
- public void DeleteSpellFatigue(string key)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
- /std/player/skills.c
- /sys/living/skills.h
-
-
-ARGUMENTE
-=========
-
- string key : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
- oder 0 fuer die globale Spruchermuedung.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion dient zum Loeschen von individuellen Spruchermuedungen
- (Spellfatigue, Spruchsperren).
-
- Ist <key> 0, wird die globale Spruchsperre geloescht (identisch zu der
- Property P_NEXT_SPELL_TIME), anderenfalls die unter <key> gespeicherte
- Spruchermuedung.
- Loescht man einen Eintrag 0 ist das Ergebnis dieser Funktion identisch zum
- Loeschen/Nullen von P_NEXT_SPELL_TIME.
-
-
-BEMERKUNGEN
-===========
-
- Spruchsperren (insb. fremde) duerfen nicht ohne weiteres geloescht oder
- geaendert werden. Dieses bedarf grundsaetzlich der Genehmigung durch die
- Gildenbalance!
-
-
-SIEHE AUCH
-==========
-
- SetSpellFatigue(L), CheckSpellFatigue(L)
- P_NEXT_SPELL_TIME
- spruchermuedung
-
-27.03.2010, Zesstra
diff --git a/doc/sphinx/man/lfun/DeleteTimedAttrModifier b/doc/sphinx/man/lfun/DeleteTimedAttrModifier
deleted file mode 100644
index 2d1bd1e..0000000
--- a/doc/sphinx/man/lfun/DeleteTimedAttrModifier
+++ /dev/null
@@ -1,53 +0,0 @@
-
-DeleteTimedAttrModifier()
-*************************
-
-
-FUNKTION
-========
-
- int DeleteTimedAttrModifier(string key)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- key - aus P_TIMED_ATTR_MOD zu loeschender Eintrag
-
-
-BESCHREIBUNG
-============
-
- Der zu key gehoerende Eintrag in P_TIMED_ATTR_MOD wird geloescht und
- update_max_sp_and_hp ausgefuehrt.
-
-
-RUeCKGABEWERT
-=============
-
- TATTR_INVALID_ARGS - Im Falle eines fehlenden key-Arguments
- TATTR_NO_SUCH_MODIFIER - Falls der Modifier mit diesem Key nicht
- existiert
- TATTR_OK - Im Erfolgsfall
-
-
-
- Die Rueckgabewerte sind in /sys/living/attributes.h definiert.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/lfun/DiscoverDoor b/doc/sphinx/man/lfun/DiscoverDoor
deleted file mode 100644
index 9046a0e..0000000
--- a/doc/sphinx/man/lfun/DiscoverDoor
+++ /dev/null
@@ -1,54 +0,0 @@
-
-DiscoverDoor()
-**************
-
-
-FUNKTION
-========
-
- varargs int DiscoverDoor(string dname)
-
-
-ARGUMENTE
-=========
-
- dname: Name des Raumes, in dem der Seher das Sehertor kennenlernen soll.
- Default: Die Umgebung des Sehers.
-
-
-BESCHREIBUNG
-============
-
- Nachdem diese Funktion aufgerufen wurde, kann der Seher (this_player())
- das Tor in dem angegebenen Raum immer verwenden.
-
-
-RUECKGABEWERT
-=============
-
- 1, falls der Seher ein NEUES Tor kennengelernt hat
- 0, falls er das Tor schon kannte oder kein Seher war
-
-
-BEMERKUNGEN
-===========
-
- Von einem Sehertor wird diese Funktion automatisch beim Betreten des
- umgebenden Raumes aufgerufen, falls P_SEERDOOR_DISCOVER gesetzt ist. Wenn
- ein Tor auf diese Art nicht entdeckt werden soll, so darf
- P_SEERDOOR_DISCOVER nicht gesetzt sein und muss DiscoverDoor() separat,
- z.B. von einem Questobjekt, aufgerufen werden.
- Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
-
-
-BEISPIELE
-=========
-
- write("Der Zauberer sagt: Im Nichts wirst Du ein weiteres Tor finden!\n");
- "/d/seher/portale/sehertormaster"->DiscoverDoor("/room/void");
-
-
-SIEHE AUCH
-==========
-
- DoorIsKnown, ShowDoors, Teleport, GetDoorsMapping
diff --git a/doc/sphinx/man/lfun/DistributeExp b/doc/sphinx/man/lfun/DistributeExp
deleted file mode 100644
index e29427d..0000000
--- a/doc/sphinx/man/lfun/DistributeExp
+++ /dev/null
@@ -1,42 +0,0 @@
-
-DistributeExp()
-***************
-
-
-FUNKTION
-========
-
- private void DistributeExp(object enemy, int exp_to_give)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- object enemy - toetender Feind
- int exp_to_give - zu verteilende XP (== P_XP/100)
-
-
-BESCHREIBUNG
-============
-
- Das sterbende Wesen verteilt seine XP an seine Feinde.
-
- Dabei bekommt jeder Gegner seinen Anteil (abhaengig von 50% von seinem
- gemachten Schaden) und einen Teamanteil (die anderen 50% ueber das
- gesamte Team addiert und durch die Teamanzahl geteilt).
-
-
-SIEHE AUCH
-==========
-
- Funktionen: AddExp()
- Properties: P_XP
- Sonstiges: teamkampf
-
-Letzte Aenderung: 22.12.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/DoDecay b/doc/sphinx/man/lfun/DoDecay
deleted file mode 100644
index 695856a..0000000
--- a/doc/sphinx/man/lfun/DoDecay
+++ /dev/null
@@ -1,69 +0,0 @@
-
-DoDecay()
-*********
-
-
-FUNKTION
-========
-
- public int DoDecay(int silent)
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- silent (int)
- Falls != 0, erfolgt beim Zerfall keine Meldung, d.h. doDecayMessaage()
- wird nicht gerufen.
-
-
-RUeCKGABEWERT
-=============
-
- Die Funktion gibt die nach dem Zerfall noch uebrig gebliebene Menge
- zurueck (int).
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird in Clones von Unitobjekten aus der Blueprint gerufen,
- wenn ein Zerfallsintervall abgelaufen ist (natuerlich nur, wenn in der BP
- der Zerfall konfiguriert ist).
- Die Funktion prueft normalerweise via P_UNIT_DECAY_FLAGS, ob der Zerfall
- stattfinden soll, bestimmt aus P_UNIT_DECAY_QUOTA die zu zerfallende
- Menge, ruft DoDecayMessage() und reduziert P_AMOUNT.
-
-
-
- Sie kann auch von Hand gerufen werden, um einen Zerfall auszuloesen, auch
- wenn mir gerade nicht einfaellt, in welchen Situationen das sinnvoll
- waere (vielleicht als Spruchmisserfolg. *g*)
-
-
-BEMERKUNGEN
-===========
-
- Wenn man einen anderen Zerfallsmechanismus haben, will muss man diese
- Funktion wohl ueberschreiben. In fast allen Faellen sollte dies jedoch
- unnoetig sein. Hat jemand das Verlangen, diese Funktion zu
- ueberschreiben, ist vielleicht vorher eine Diskussion mit dem Mudlib-EM
- angebracht.
-
-
-SIEHE AUCH
-==========
-
- unit
- P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA,
- P_UNIT_DECAY_MIN
- DoDecayMessage()
- /std/unit.c
-
-14.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/DoDecayMessage b/doc/sphinx/man/lfun/DoDecayMessage
deleted file mode 100644
index 671f9c7..0000000
--- a/doc/sphinx/man/lfun/DoDecayMessage
+++ /dev/null
@@ -1,54 +0,0 @@
-
-DoDecayMessage()
-****************
-
-
-FUNKTION
-========
-
- protected void DoDecayMessage(int oldamount, int zerfall);
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- oldamount (int)
- Menge vor dem Zerfall
- zerfall (int)
- jetzt zerfallende Menge
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird von DoDecay() gerufen und gibt die Standardmeldungen
- beim Zerfall von Unitobjekten aus.
- Hierbei ist an der Unit noch alles unveraendert, wenn diese Funktion
- gerufen wird, die Reduktion von P_AMOUNT erfolgt direkt im Anschluss.
- Die Funktion wird nicht gerufen, wenn DoDecay() mit silent!=0 gerufen
- wird.
-
-
-BEMERKUNGEN
-===========
-
- Will man nicht die Standardzerfallsmeldungen (wovon ich meist ausgehe),
- kann man diese Funktion ueberschreiben und eigene Meldungen erzeugen.
-
-
-SIEHE AUCH
-==========
-
- unit
- P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA,
- P_UNIT_DECAY_MIN
- DoDecay()
- /std/unit.c
-
-14.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/DoUnwear b/doc/sphinx/man/lfun/DoUnwear
deleted file mode 100644
index 56e53d3..0000000
--- a/doc/sphinx/man/lfun/DoUnwear
+++ /dev/null
@@ -1,55 +0,0 @@
-
-DoUnwear()
-**********
-
-
-FUNKTION
-========
-
- varargs int DoUnwear(int silent, int all);
-
-
-DEFINIERT IN
-============
-
- /std/clothing/wear.c
-
-
-ARGUMENTE
-=========
-
- silent
- Falls ungleich 0, so werden keine Meldungen ausgegeben.
- Falls (silent&M_NOCHECK) werden auch verfluchte Ruestungen
- ausgezogen
- all
- Ungleich 0, wenn DoUnwear() aus einem "ziehe alles aus" heraus
- aufgerufen wurde.
-
-
-BESCHREIBUNG
-============
-
- Es wird versucht, die Ruestung auszuziehen. Dabei werden eine eventuell
- vorhandene RemoveFunc() und Flueche mit beruecksichtigt.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn die Ruestung gar nicht getragen war, ansonsten 1.
-
-
-BEMERKUNGEN
-===========
-
- Auch wenn eine 1 zurueckgegeben wird, muss das nicht heissen, dass die
- Ruestung erfolgreich ausgezogen wurde!
-
-
-SIEHE AUCH
-==========
-
- DoWear(), RemoveFunc(), InformUnwear(), /std/armour/combat.c
-
-Last modified: Sun Jun 27 22:22:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/lfun/DoUnwield b/doc/sphinx/man/lfun/DoUnwield
deleted file mode 100644
index d003bfc..0000000
--- a/doc/sphinx/man/lfun/DoUnwield
+++ /dev/null
@@ -1,54 +0,0 @@
-
-DoUnwield()
-***********
-
-
-FUNKTION
-========
-
- varargs int DoUnwield(int silent);
-
-
-DEFINIERT IN
-============
-
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- silent
- Ungleich 0, wenn die Waffe ohne Meldungen weggesteckt werden soll.
- Wenn silent&M_NOCHECK wird die Waffe auch weggesteckt wenn sie
- verflucht ist und UnwieldFunc() wird nicht ausgewertet.
-
-
-BESCHREIBUNG
-============
-
- Es wird versucht, die Waffe wegzustecken.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn die Waffe gar nicht gezueckt war, ansonsten 1.
-
-
-BEMERKUNGEN
-===========
-
- Anhand des Rueckgabewertes laesst sich nicht ersehen, ob die Waffe sich
- wegstecken liess oder nicht!
-
- Wenn die Waffe verflucht ist oder (falls definiert) UnwieldFunc() 0
- zurueckgibt, laesst sie sich nicht wegstecken.
-
-
-SIEHE AUCH
-==========
-
- UnwieldFunc(), InformUnwield(), /std/weapon.c
-
-Letzte Aenderung: 18.11.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/DoWear b/doc/sphinx/man/lfun/DoWear
deleted file mode 100644
index e253290..0000000
--- a/doc/sphinx/man/lfun/DoWear
+++ /dev/null
@@ -1,64 +0,0 @@
-
-DoWear()
-********
-
-
-FUNKTION
-========
-
- varargs int DoWear(int silent, int all);
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c
-
-
-ARGUMENTE
-=========
-
- silent
- Falls ungleich 0, so werden keine Meldungen ausgegeben.
- all
- Ungleich 0, wenn DoWear() aus einem "ziehe alles an" heraus
- aufgerufen wurde.
-
-
-BESCHREIBUNG
-============
-
- Es wird versucht, die Ruestung anzuziehen. Dabei wird eine eventuell
- vorhandene WearFunc() mit beruecksichtigt.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn man die Ruestung gar nicht bei sich hat oder sie schon an hat,
- ansonsten 1.
-
-
-BEMERKUNGEN
-===========
-
- Auch wenn eine 1 zurueckgegeben wird, muss das nicht heissen, dass die
- Ruestung erfolgreich angezogen wurde!
-
- Gruende fuer ein Fehlschlagen des Anziehens koennen sein:
- o Man hat die Ruestung nicht bei sich.
- o Man hat die Ruestung schon an.
- o Man hat schon eine Ruestung des gleichen Typs an.
- o Der Typ der Ruestung oder die Ruestungsklasse ist illegal.
- o Falls definiert: WearFunc() gab 0 zurueck.
- o Falls es sich um einen Schild handelt: Man hat keine Hand mehr
- frei.
-
-
-SIEHE AUCH
-==========
-
- DoUnwear(), WearFunc(), InformWear(), P_EQUIP_TIME,
- /std/armour/combat.c, P_UNWEAR_MSG, P_WEAR_MSG
-
-Last modified: Sun Jun 27 22:22:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/lfun/DoWield b/doc/sphinx/man/lfun/DoWield
deleted file mode 100644
index 6e6c06c..0000000
--- a/doc/sphinx/man/lfun/DoWield
+++ /dev/null
@@ -1,63 +0,0 @@
-
-DoWield()
-*********
-
-
-FUNKTION
-========
-
- varargs int DoWield(int silent);
-
-
-DEFINIERT IN
-============
-
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- silent
- Ungleich 0, wenn die Waffe ohne Meldungen gezueckt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Es wird versucht, die Waffe zu zuecken. Hat man schon eine Waffe
- gezueckt, so wird versucht, diese wegzustecken. Klappt das nicht, kann
- die Waffe nicht gezueckt werden.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn man die Waffe gar nicht bei sich traegt, ansonsten 1.
-
-
-BEMERKUNGEN
-===========
-
- Anhand des Rueckgabewertes laesst sich nicht entscheiden, ob die Waffe
- sich erfolgreich zuecken liess!
-
- Gruende, warum sich eine Waffe nicht zuecken lassen kann, sind
- folgende:
- o Man traegt sie nicht bei sich (oder sie steckt in einem Beutel
- o.ae.).
- o Man hat sie schon gezueckt.
- o Falls definiert: WieldFunc() gibt 0 zurueck.
- o Man ist nicht geschickt genug (das haengt von der Waffenklasse
- ab).
- o Eine schon gezueckte Waffe laesst sich nicht wegstecken.
- o Die Waffenklasse ist hoeher als erlaubt.
- o Man hat nicht genug Haende frei.
-
-
-SIEHE AUCH
-==========
-
- WieldFunc(), InformWield(), P_EQUIP_TIME, /std/weapon.c
-
-Last modified: Wed Apr 08 10:25:00 2004 by Muadib
diff --git a/doc/sphinx/man/lfun/DoorIsKnown b/doc/sphinx/man/lfun/DoorIsKnown
deleted file mode 100644
index b799698..0000000
--- a/doc/sphinx/man/lfun/DoorIsKnown
+++ /dev/null
@@ -1,46 +0,0 @@
-
-DoorIsKnown()
-*************
-
-
-FUNKTION
-========
-
- int DoorIsKnown()
-
-
-ARGUMENTE
-=========
-
- Keine.
-
-
-BESCHREIBUNG
-============
-
- Testet, ob der Seher (this_player()) das Tor in seiner momentanen
- Umgebung schon kennt.
-
-
-RUECKGABEWERT
-=============
-
- Die Nummer des Tores.
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
-
-
-BEISPIELE
-=========
-
- /d/seher/portale/sehertormaster->DoorIsKnown()
-
-
-SIEHE AUCH
-==========
-
- DiscoverDoor, ShowDoors, Teleport, GetDoorsMapping
diff --git a/doc/sphinx/man/lfun/Dump b/doc/sphinx/man/lfun/Dump
deleted file mode 100644
index 9d8d7e0..0000000
--- a/doc/sphinx/man/lfun/Dump
+++ /dev/null
@@ -1,38 +0,0 @@
-
-Dump()
-******
-
-
-FUNKTION
-========
-
- void Dump()
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-BESCHREIBUNG
-============
-
- Schreibt alle Materialien samt ihren Gruppen und alle Gruppen mit
- dazugehoerenden Materialien in DUMPFILE (/p/daemon/save/MATERIALS)
- Wird in create() der Materialiendatenbank automatisch aufgerufen.
- Das Dumpfile ist zum Recherchieren der Materialien gedacht.
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Listen: AllMaterials(), AllGroups()
- materialliste, materialgruppen
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/EnemyPresent b/doc/sphinx/man/lfun/EnemyPresent
deleted file mode 100644
index bf3853c..0000000
--- a/doc/sphinx/man/lfun/EnemyPresent
+++ /dev/null
@@ -1,34 +0,0 @@
-
-EnemyPresent()
-**************
-
-
-FUNKTION
-========
-
- public mixed EnemyPresent()
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-BESCHREIBUNG
-============
-
- Gibt aus der Feindesliste den ersten anwesenden, lebenden und
- angreifbaren aktuellen Gegner im Raum zurueck.
- Damit ist die Funktion identisch zu InFight().
-
- Will man alle Gegner, auf die diese Kriterien zutreffen, sollte man
- PresentEnemies() verwenden.
-
-
-SIEHE AUCH
-==========
-
- PresentEnemies(), Infight()
-
-22.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/Enter b/doc/sphinx/man/lfun/Enter
deleted file mode 100644
index 0ebc7f0..0000000
--- a/doc/sphinx/man/lfun/Enter
+++ /dev/null
@@ -1,64 +0,0 @@
-
-Enter()
-*******
-
-
-FUNKTION
-========
-
- int Enter();
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Wenn sich der Spieler noch nicht auf dem Transporter befindet, und der
- Transporter momentan an einer Haltestelle liegt, betritt der Spieler
- den Transporter.
-
-
-RUeCKGABEWERT
-=============
-
- Null, wenn der Spieler den Transporter nicht betreten konnte, sonst
- ungleich Null.
-
-
-BEMERKUNGEN
-===========
-
- Es werden keine Tests durchgefuehrt, ob der Transporter ueberhaupt
- angesprochen wurde! Das muss man selber machen.
-
-
-BEISPIELE
-=========
-
- int myEnter(string str)
- {
- if (str && id(str))
- return Enter();
-
- notify_fail("Was willst Du betreten?\n");
- return 0;
- }
-
-
-SIEHE AUCH
-==========
-
- Leave(), /std/transport.c
-
-Last modified: Wed May 8 10:18:42 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/EvalArmour b/doc/sphinx/man/lfun/EvalArmour
deleted file mode 100644
index 7daf07c..0000000
--- a/doc/sphinx/man/lfun/EvalArmour
+++ /dev/null
@@ -1,40 +0,0 @@
-
-EvalArmour()
-************
-
-
-FUNKTION
-========
-
- int EvalArmour(object ob, closure qp)
-
-
-DEFINIERT IN
-============
-
- /std/room/shop.c
-
-
-ARGUMENTE
-=========
-
- ob - Eine Ruestung.
- qp - symbol_function("QueryProp",ob)
-
-
-BESCHREIBUNG
-============
-
- Bewertet die Ruestung.
-
-
-RUECKGABEWERT
-=============
-
- Max(P_AC,P_EFFECTIVE_AC);
-
-
-SIEHE AUCH
-==========
-
- FindBestArmour()
diff --git a/doc/sphinx/man/lfun/EvalWeapon b/doc/sphinx/man/lfun/EvalWeapon
deleted file mode 100644
index 395a0a1..0000000
--- a/doc/sphinx/man/lfun/EvalWeapon
+++ /dev/null
@@ -1,40 +0,0 @@
-
-EvalWeapon()
-************
-
-
-FUNKTION
-========
-
- int EvalWeapon(object ob, closure qp)
-
-
-DEFINIERT IN
-============
-
- /std/room/shop.c
-
-
-ARGUMENTE
-=========
-
- ob - Eine Waffe.
- qp - symbol_function("QueryProp",ob)
-
-
-BESCHREIBUNG
-============
-
- Bewertet die Waffe.
-
-
-RUECKGABEWERT
-=============
-
- Max(P_WC,P_EFFECTIVE_WC);
-
-
-SIEHE AUCH
-==========
-
- FindBestWeapon()
diff --git a/doc/sphinx/man/lfun/ExtraAttack b/doc/sphinx/man/lfun/ExtraAttack
deleted file mode 100644
index cc0b109..0000000
--- a/doc/sphinx/man/lfun/ExtraAttack
+++ /dev/null
@@ -1,49 +0,0 @@
-
-ExtraAttack()
-*************
-
-
-FUNKTION
-========
-
- varargs public void ExtraAttack(object enemy, int ignore_previous);
-
-
-ARGUMENTE
-=========
-
- enemy: Der Feind.
- ignore_previous: Ein Flag
-
-
-BESCHREIBUNG
-============
-
- Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
- stark angegriffen. Hierbei wird Attack() aufgerufen.
- Ist ignore_previous ungleich 0, dann wird die Erstschlagsperre von
- Attack ignoriert. Dieser Angriff ist also auch dann moeglich, wenn
- das Lebewesen eigentlich keinen Schlag mehr in dieser Runde ausfuehren
- duerfte.
-
-
-RUECKGABEWERT
-=============
-
- Keiner.
-
-
-BEMERKUNG
-=========
-
- Der Einsatz dieser Funktion ist genehmigungspflichtig.
- Weitere Hinweise siehe "man Attack".
-
-
-SIEHE AUCH
-==========
-
- "Attack"
- /std/living/combat.c
-
-Last modified: Sun Nov 21 12:32:20 2004 by Bambi
diff --git a/doc/sphinx/man/lfun/FilterArmours b/doc/sphinx/man/lfun/FilterArmours
deleted file mode 100644
index 32a7f2b..0000000
--- a/doc/sphinx/man/lfun/FilterArmours
+++ /dev/null
@@ -1,99 +0,0 @@
-
-FilterArmours()
-***************
-
-
-FUNKTION
-========
-
- public object *FilterArmours(closure filterfun, varargs mixed* extra)
-
-
-DEFINIERT IN
-============
-
- /std/living/clothing.c
-
-
-ARGUMENTE
-=========
-
- closure filterfun
- Die Closure, die entscheiden soll, ob eine Ruestung im Ergebnisarray
- enthalten sein soll.
-
-
-
- mixed extra
- Beliebig viele Extra-Argumente, die <filterfun> uebergeben werden.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ruft <filterfunc> fuer jede getragene Ruestung des
- Lebewesen mit der jeweiligen Ruestung als Argument auf und liefert ein
- Array mit allen Ruestungen zurueck, fuer die <filterfun> einen Wert != 0
- zurueckliefert.
- Die <extra> Argumente werden als zusaetzliche Parameter an <filterfun>
- uebergeben und duerfen keine Referenzen sein.
-
-
-
- Diese Variante ist zu bevorzugen, wenn man Ruestungen nach bestimmten
- Kriterien durchsuchen will und QueryArmourByType() nicht ausreichend sein
- sollte.
-
-
-RUeCKGABEWERT
-=============
-
- Ein Array von Objekten mit allen passenden Ruestungen.
-
-
-BEISPIELE
-=========
-
- 1) Ich moechte gerne alle Ruestungen haben, die beschaedigt sind:
- private int _is_damaged(object ruestung) {
- return ruestung->QueryProp(P_DAMAGE);
- }
- ...
- object *damaged_armours = PL->FilterArmours(#'_is_damaged);
-
- 2) Ich moechte alle Ruestungen, die groesser als 50cm sind.
- private int _armour_is_bigger(object ruestung, int size) {
- return ruestung->QueryProp(P_SIZE) > size;
- }
- ...
- object *big_armours = PL->FilterArmours(#'_amour_is_bigger, 50);
-
- 3) alle Ruestungen mit einer speziellen ID.
- private int _has_id(object ruestung, string idstr) {
- return ruestung->id(idstr);
- }
- object *has_id = PL->FilterArmours(#'_has_id, "\ntolleruestung");
-
- 4) alle Ruestungen mit einer speziellen ID, die groesser als 50cm sind.
- private int _has_id(object ruestung, string idstr, int size) {
- return ruestung->id(idstr) && ruestung->QueryProp(P_SIZE) > size;
- }
- object *has_id = PL->FilterArmours(#'_has_id, "\ntolleruestung", 50);
-
- 5) ueberhaupt alle getragene Ruestung
- object *rue = PL->FilterArmours(#'objectp)
-
-
-SIEHE AUCH
-==========
-
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
- UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), QueryArmourByType()
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/FilterClothing b/doc/sphinx/man/lfun/FilterClothing
deleted file mode 100644
index a7e1d01..0000000
--- a/doc/sphinx/man/lfun/FilterClothing
+++ /dev/null
@@ -1,80 +0,0 @@
-
-FilterClothing()
-****************
-
-
-FUNKTION
-========
-
- public object *FilterClothing(closure filterfun, varargs mixed* extra)
-
-
-DEFINIERT IN
-============
-
- /std/living/clothing.c
-
-
-ARGUMENTE
-=========
-
- closure filterfun
- Die Closure, die entscheiden soll, ob eine Kleidung im Ergebnisarray
- enthalten sein soll.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ruft <filterfunc> fuer jede getragene Kleidung des
- Lebewesen mit der jeweiligen Kleidung als Argument auf und liefert ein
- Array mit aller Kleidung zurueck, fuer die <filterfun> einen Wert != 0
- zurueckliefert.
- Die <extra> Argumente werden als zusaetzliche Parameter an <filterfun>
- uebergeben und duerfen keine Referenzen sein.
-
-
-
- Diese Variante ist zu bevorzugen, wenn man die getrage Kleidung nach
- bestimmten Kriterien durchsuchen will.
-
-
-RUeCKGABEWERT
-=============
-
- Ein Array von Objekten mit allen passenden Kleidung.
-
-
-BEISPIELE
-=========
-
- 1) Ich moechte alle Kleidung, die groesser als 50cm ist.
- private int _armour_is_bigger(object clothing, int size) {
- return clothing->QueryProp(P_SIZE) > size;
- }
- ...
- object *big_armours = PL->FilterClothing(#'_amour_is_bigger, 50);
-
- 2) alle Kleidung mit einer speziellen ID.
- private int _has_id(object clothing, string idstr) {
- return clothing->id(idstr);
- }
- object *has_id = PL->FilterClothing(#'_has_id, "\ntollekleidung");
-
- 3) ueberhaupt alle getragene Kleidung
- object *clothing = PL->FilterClothing(#'objectp)
-
-
-SIEHE AUCH
-==========
-
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
- UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterArmours(), QueryArmourByType()
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/FindBestArmours b/doc/sphinx/man/lfun/FindBestArmours
deleted file mode 100644
index 10a5d80..0000000
--- a/doc/sphinx/man/lfun/FindBestArmours
+++ /dev/null
@@ -1,64 +0,0 @@
-
-FindBestArmours()
-*****************
-
-
-FUNKTION
-========
-
- varargs object *FindBestArmours(mixed type, int maxmon, int maxw,
- mapping minac, mixed restr)
-
-
-DEFINIERT IN
-============
-
- /std/room/shop.c
-
-
-ARGUMENTE
-=========
-
- type - gewuenschter Ruestungstyp / Ruestungstypen
- maxmon - Geld das ausgegeben werden darf
- maxw - Maximales Gewicht
- minac - minimale gewuenschte Ruestungsklasse pro Typ
- restr - zusaetzliches Argument fuer CheckFindRestrictions()
-
-
-BESCHREIBUNG
-============
-
- Sucht die besten Ruestungen, die der Laden verkaufen kann.
-
-
-RUECKGABEWERT
-=============
-
- Die besten Ruestungen
-
-
-BEMERKUNG
-=========
-
- Die Qualitaet der Ruestung wird mit EvalArmour() bestimmt.
- Haben zwei Ruestungen die gleiche Qualitaet,
- wird die preiswertere genommen.
-
-
-BEISPIEL
-========
-
- FindBestArmours(AT_ARMOUR,5000)
- Bestes Ruestung unter 5000 Muenzen.
-
- FindBestArmours(({AT_ARMOUR,AT_CLOAK,AT_BOOT}),10000,([AT_ARMOUR:20]))
- Finded beste Ruestung, Umhang und Schuhe, die der Laden fuer
- insgesamt 10000 Muenzen verkaufen kann, wobei die Ruestung mindestens
- AC 20 haben muss.
-
-
-SIEHE AUCH
-==========
-
- FindBestWeapon(), CheckFindRestrictions(), EvalArmour()
diff --git a/doc/sphinx/man/lfun/FindBestWeapon b/doc/sphinx/man/lfun/FindBestWeapon
deleted file mode 100644
index 1aaeb0d..0000000
--- a/doc/sphinx/man/lfun/FindBestWeapon
+++ /dev/null
@@ -1,59 +0,0 @@
-
-FindBestWeapon()
-****************
-
-
-FUNKTION
-========
-
- varargs object FindBestWeapon(mixed type, int maxmon, int maxw, int hands,
- int minwc, mixed restr)
-
-
-DEFINIERT IN
-============
-
- /std/room/shop.c
-
-
-ARGUMENTE
-=========
-
- type - gewuenschter Waffentyp / Waffentypen
- maxmon - Geld das ausgegeben werden darf
- maxw - Maximales Gewicht
- hands - Anzahl Haende, die die Waffe belegen darf
- minwc - minimale gewuenschte Waffenklasse
- restr - zusaetzliches Argument fuer CheckFindRestrictions()
-
-
-BESCHREIBUNG
-============
-
- Sucht die beste Waffe, die der Laden verkaufen kann.
-
-
-RUECKGABEWERT
-=============
-
- Die beste Waffe :-)
-
-
-BEMERKUNG
-=========
-
- Die Qualitaet der Waffe wird mit EvalWeapon() bestimmt.
- Haben zwei Waffen die gleiche Qualitaet, wird die preiswertere genommen.
-
-
-BEISPIEL
-========
-
- FindBestWeapon(WT_SWORD,5000,1)
- Bestes einhaendiges Schwert unter 5000 Muenzen.
-
-
-SIEHE AUCH
-==========
-
- FindBestArmours(), CheckFindRestrictions(), EvalWeapon()
diff --git a/doc/sphinx/man/lfun/FindDistantEnemyVictim b/doc/sphinx/man/lfun/FindDistantEnemyVictim
deleted file mode 100644
index 5ea712d..0000000
--- a/doc/sphinx/man/lfun/FindDistantEnemyVictim
+++ /dev/null
@@ -1,55 +0,0 @@
-
-FindDistantEnemyVictim()
-************************
-
-
-FUNKTION
-========
-
- object FindDistantEnemyVictim(string wen, object pl, string msg,
- int dist, int dy)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- wen - id des gewuenschten Gegners, falls nicht angegeben:
- SelectEnemy(FindDistantGroup(pl,-1,dist,dy,10000)
- pl - Caster.
- msg - Nachricht falls Gegner nicht anwesend ist.
- dist - Entfernung
- dy - 2*erlaubte Abweichung von der Entfernung, default 100
-
-
-BESCHREIBUNG
-============
-
- Findet einen Gegner in Entfernung dist-dy/2 bis dist+dy/2
- z.B. fuer einen Angriffsspruch.
-
-
-RUECKGABEWERT
-=============
-
- Der Auserwaehlte :-)
-
-
-BEMERKUNGEN
-===========
-
- 1. Der Gegner wird auf jeden Fall angegriffen.
- 2. dist wird mit SA_RANGE modifiziert,
- dy wird mit SA_EXTENSION modifiziert.
- 3. Die Entfernung ist relativ zum Spieler.
-
-
-SIEHE AUCH
-==========
-
- teams, FindEnemyVictim, FindNearEnemyVictim, FindFarEnemyVictim
diff --git a/doc/sphinx/man/lfun/FindDistantGroup b/doc/sphinx/man/lfun/FindDistantGroup
deleted file mode 100644
index b94e048..0000000
--- a/doc/sphinx/man/lfun/FindDistantGroup
+++ /dev/null
@@ -1,53 +0,0 @@
-
-FindDistantGroup()
-******************
-
-
-FUNKTION
-========
-
- varargs object *FindDistantGroup(object pl, int who,
- int dist, int dy, int dx)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- pl - Caster
- who - 1=Freunde, -1=Gegner, 0=beide
- dist - Entfernung
- dy - Tiefe (default 100)
- dx - Breite (default 100*MAX_TEAM_ROWLEN)
-
-
-BESCHREIBUNG
-============
-
- Ermittelt Lebewesen, die sich in Entfernung <dist> in einem Bereich
- der Breite <dx> und Tiefe <dy> befinden.
-
-
-RUECKGABEWERT
-=============
-
- Array mit den gefundenen Lebewesen.
-
-
-BEMERKUNGEN
-===========
-
- Genauere Hinweise unter "FindDistantGroups".
- Wer sowohl Freunde wie auch Feinde in getrennten Arrays braucht,
- sollte FindDistantGroups statt FindDistantGroup verwenden.
-
-
-SIEHE AUCH
-==========
-
- teams, FindDistantGroups
diff --git a/doc/sphinx/man/lfun/FindDistantGroups b/doc/sphinx/man/lfun/FindDistantGroups
deleted file mode 100644
index efb3354..0000000
--- a/doc/sphinx/man/lfun/FindDistantGroups
+++ /dev/null
@@ -1,85 +0,0 @@
-
-FindDistantGroups()
-*******************
-
-
-FUNKTION
-========
-
- varargs mixed FindDistantGroups(object pl, int dist, int dy, int dx)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- pl - Caster
- dist - Entfernung
- dy - Tiefe (default 100)
- dx - Breite (default 100*MAX_TEAM_ROWLEN)
-
-
-BESCHREIBUNG
-============
-
- Ermitteld feindliche (bei Spielern NPCs, bei NPCs Spieler) und
- freundliche (bei Spielern Spieler, bei NPCs NPCs) Lebewesen,
- die sich in Entfernung <dist> in einem Bereich der Breite <dx>
- und Tiefe <dy> befinden.
-
-
-RUECKGABEWERT
-=============
-
- Array mit zwei Arrays als Inhalt:
- ({ feindliche Lebewesen, freundliche Lebewesen })
-
-
-BEMERKUNGEN
-===========
-
- Die Entfernungsangaben sind als cm. zu verstehen.
- Jedes Lebewesen belegt 50cm x 50cm mit Abstand 50cm
- zum naechsten Lebewesen in jeder Richtung.
- Die Breitenangabe wirkt sich nur in der Anzahl der
- Lebewesen aus, die zufaellig pro Reihe ausgewaehlt werden.
- Die Skillattribute SA_RANGE und SA_EXTENSION werden beruecksichtigt.
-
-
-BEISPIEL
-========
-
- dist=200, dy=200, dx=200, ein Punkt = 50cm x 50cm
- . . . . . . . . . . . . .
- 3. . . . . . . G . . . . . .
- . . . . . . . . . . . . .
- 2. . . . . . G . G . . . . .dist+dy/2-+
- . . . . . . . . . . . . . |
- 1. . . . . G . G . G . . . . dist +-+ (Gegner G)
- ---.-.-.-.-.-.-.-.-.-.-.-.-. | |
- 1. . . . . F . F . F . . . .dist-dy/2-+ | (Freunde F)
- . . . . . . . . . . . . . |
- 2. . . . . . F . S . . . . .------------+ (Reihe des Spielers S)
- . . . . . . . . . . . . .
- 3. . . . . . . F . . . . . .
- . . . . . . . . . . . . .
- Abgedeckter Bereich: 100cm bis 300cm
- Reihe 3: 375cm..425cm 375>300 -> nicht erwischt
- Reihe 2: 275cm..325cm 275<300 -> erwischt
- Gegner Reihe 1: 175cm..225cm 100<175,225<300 -> erwischt
- Freunde Reihe 1: 75cm..125cm 100<125 -> erwischt
- Reihe 2: -25cm...25cm 100> 25 -> nicht erwischt
- Reihe 3: -125cm..-75cm 100>-75 -> nicht erwischt
- Ergebnis: ({({G,G,G,G}),({F,F})})
- (Maximal 2 Lebewesen pro Reihe bei Breite 200).
-
-
-SIEHE AUCH
-==========
-
- teams, FindDistantGroup
diff --git a/doc/sphinx/man/lfun/FindEnemyVictim b/doc/sphinx/man/lfun/FindEnemyVictim
deleted file mode 100644
index c5a81a6..0000000
--- a/doc/sphinx/man/lfun/FindEnemyVictim
+++ /dev/null
@@ -1,47 +0,0 @@
-
-FindEnemyVictim()
-*****************
-
-
-FUNKTION
-========
-
- object FindEnemyVictim(string wen, object pl, string msg)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- wen - id des gewuenschten Gegners, falls nicht angegeben SelectEnemy.
- pl - Caster.
- msg - Nachricht falls Gegner nicht anwesend ist.
-
-
-BESCHREIBUNG
-============
-
- Findet einen Gegner, z.B. fuer einen Angriffsspruch.
-
-
-RUECKGABEWERT
-=============
-
- Der Auserwaehlte :-)
-
-
-BEMERKUNGEN
-===========
-
- Der Gegner wird auf jeden Fall angegriffen.
-
-
-SIEHE AUCH
-==========
-
- FindLivingVictim
diff --git a/doc/sphinx/man/lfun/FindFarEnemyVictim b/doc/sphinx/man/lfun/FindFarEnemyVictim
deleted file mode 100644
index 455cf89..0000000
--- a/doc/sphinx/man/lfun/FindFarEnemyVictim
+++ /dev/null
@@ -1,53 +0,0 @@
-
-FindFarEnemyVictim()
-********************
-
-
-FUNKTION
-========
-
- object FindFarEnemyVictim(string wen, object pl, string msg,
- int min, int max)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- wen - id des gewuenschten Gegners, SelectFarEnemy falls n/a.
- pl - Caster.
- msg - Nachricht falls Gegner nicht anwesend ist.
- min - minimale Kampfreihe
- max - maximale Kampfreihe
-
-
-BESCHREIBUNG
-============
-
- Findet einen Gegner aus Kampfreihe <min> bis <max>
- z.B. fuer einen Angriffsspruch.
-
-
-RUECKGABEWERT
-=============
-
- Der Auserwaehlte :-)
-
-
-BEMERKUNGEN
-===========
-
- 1. Der Gegner wird auf jeden Fall angegriffen.
- 2. Die Reihenangaben werden NICHT mit Skillattributen modifiziert.
- 3. Die Angabe der Reihe ist absolut.
-
-
-SIEHE AUCH
-==========
-
- teams, FindEnemyVictim, FindNearEnemyVictim, FindDistantEnemyVictim
diff --git a/doc/sphinx/man/lfun/FindGroup b/doc/sphinx/man/lfun/FindGroup
deleted file mode 100644
index 112c76f..0000000
--- a/doc/sphinx/man/lfun/FindGroup
+++ /dev/null
@@ -1,98 +0,0 @@
-
-FindGroup()
-***********
-
-
-FUNKTION
-========
-
- object*FindGroup(object pl,int who);
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- pl
- Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
- gefunden werden sollen.
- who
- Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
- sollen (Konstanten definiert in '/sys/new_skills.h'):
- FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
- FG_FRIENDS - (Wert 1) Freunde sollen gefunden werden
- FG_ALL - (Wert 0) alle Lebewesen sollen gefunden werden
-
-
-RUeCKGABEWERT
-=============
-
- Array mit gefundenen Lebewesen
-
-
-BESCHREIBUNG
-============
-
- Bei Spells, die sich auf mehrere Gegner auswirken oder bei denen man
- per Hand ein Opfer auswaehlen moechte, laesst sich mittels der
- Funktion FindGroup() eine Liste von Lebewesen ermitteln, welche in
- der Umgebung von <pl> zu finden sind.
- Je nachdem, was man denn genau vorhat, kann man sich von der
- Funktion freundlich oder feindlich gesinnte Lebewesen heraussuchen
- lassen.
- Will man die freundlich gesinnten Lebewesen ermitteln, so uebergibt
- man in <who> die Konstante FG_FRIENDS, bei feindlich gesinnten die
- Konstante FG_ENEMIES, und wenn man alle Lebewesen bekommen moechte
- schliesslich FG_ALL.
- Bei der Auswahl gelten folgende Regeln:
- (1) Lebewesen, mit denen <pl> im Kampf ist, sind grundsaetzlich
- feindlich gesinnt.
- (2) Teammitglieder von <pl> sind grundsaetzlich freundlich
- gesinnt.
- (3) Spieler sind gegenueber Spielern freundlich gesinnt, NPCs
- gegenueber NPCs. NPCs kann man hierbei mit Hilfe der Property
- P_FRIEND den Spielern zuordnen.
- (4) Daraus folgt natuerlich, dass Spieler und NPCs grundsaetzlich
- eine feindliche Einstellung gegenueber haben, sofern die NPCs
- nicht die Property P_FRIEND gesetzt haben
- (was standardmaessig natuerlich nicht der Fall ist).
- (5) Netztote werden nicht erkannt.
- (6) Magier werden nicht erkannt, wenn sie unsichtbar sind.
- (7) Ein Magier wird als feindlich gesinnt nur dann erkannt, wenn
- <pl> mit ihm im Kampf ist.
- (6) Sucht man feindlich gesinnte Lebewesen, so werden die, welche
- eine von den Properties P_NO_ATTACK oder P_NO_GLOBAL_ATTACK
- gesetzt haben, nicht erkannt.
- Die Property P_FRIEND sollte man in NPCs setzen, die dem Spieler
- hilfreich beiseite stehen, z.B. vom Spieler beschworene HilfsNPCs.
-
-
-BEISPIELE
-=========
-
- Wenn man einen Feuerball nach jemandem wirft, so trifft dieser unter
- Umstaenden auch andere, wenn er gross genug ist. Man nimmt hierbei
- an, dass sich die freundlich gesinnten Lebewesen des Gegners auch
- naeher bei ihm befinden als die feindlich gesinnten:
- victim->Defend(500,DT_FIRE,([SP_SHOW_DAMAGE:1]),caster);
- victimList=FindGroup(victim,FG_FRIENDS);
- map_objects(victimList,
- "Defend",
- 100,
- DT_FIRE,
- ([SP_SHOW_DAMAGE:1]),
- caster);
- Hiermit trifft man also auch die Freunde von <victim>.
-
-
-SIEHE AUCH
-==========
-
- FindGroupN(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
-
-Last modified: Mon Jan 28 21:45:00 2002 by Tiamak
diff --git a/doc/sphinx/man/lfun/FindGroupN b/doc/sphinx/man/lfun/FindGroupN
deleted file mode 100644
index b0104ee..0000000
--- a/doc/sphinx/man/lfun/FindGroupN
+++ /dev/null
@@ -1,67 +0,0 @@
-
-FindGroupN()
-************
-
-
-FUNKTION
-========
-
- object*FindGroupN(object pl,int who,int n);
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- pl
- Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
- gefunden werden sollen.
- who
- Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
- sollen (Konstanten definiert in '/sys/new_skills.h'):
- FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
- FG_FRIENDS - (Wert 1) Freunde sollen gefunden werden
- FG_ALL - (Wert 0) alle Lebewesen sollen gefunden werden
- n
- Anzahl der Lebewesen, die zurueckgegeben werden sollen.
- Hierbei geht vorher noch das Skillattribute SA_EXTENSION ein!
- Es wird mindestens 1 Lebewesen zurueckgeliefert (sofern gefunden).
-
-
-RUeCKGABEWERT
-=============
-
- Array mit gefundenen Lebewesen
-
-
-BESCHREIBUNG
-============
-
- Ausgesucht werden die Lebewesen genauso wie bei FindGroup(), nur
- dass zum Schluss die Anzahl noch begrenzt wird.
-
-
-BEISPIELE
-=========
-
- Man moechte maximal 5 Feinde finden, die man gleichzeitig mit einem
- Spell belegen kann:
- enemyList=FindGroupN(caster,FG_ENEMIES,5);
- Dies gilt jedoch nur bei SA_EXTENSION==100, sonst wird
- dementsprechend mehr oder weniger zurueckgegeben.
- (also bei SA_EXTENSION==200 doppelt so viele -> 10 Lebewesen)
- Das Skillattribute SA_EXTENSION kann auch durch SA_QUALITY
- veraendert worden sein; das sollte beachtet werden.
-
-
-SIEHE AUCH
-==========
-
- FindGroup(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
-
-Last modified: Mon Jan 25 15:04:31 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/FindGroupP b/doc/sphinx/man/lfun/FindGroupP
deleted file mode 100644
index e4c297b..0000000
--- a/doc/sphinx/man/lfun/FindGroupP
+++ /dev/null
@@ -1,68 +0,0 @@
-
-FindGroupP()
-************
-
-
-FUNKTION
-========
-
- object*FindGroupP(object pl,int who,int pr);
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- pl
- Lebewesen, von welchem die Freunde oder Feinde in der Umgebung
- gefunden werden sollen.
- who
- Flag, welches anzeigt, ob Freunde oder Feinde gefunden werden
- sollen (Konstanten definiert in '/sys/new_skills.h'):
- FG_ENEMIES - (Wert -1) Feinde sollen gefunden werden
- FG_FRIENDS - (Wert 1) Freunde sollen gefunden werden
- FG_ALL - (Wert 0) alle Lebewesen sollen gefunden werden
- pr
- Wahrscheinlichkeit, mit der ein Lebewesen ausgesucht werden soll.
- Hierbei geht vorher noch das Skillattribute SA_EXTENSION ein!
-
-
-RUeCKGABEWERT
-=============
-
- Array mit gefundenen Lebewesen
-
-
-BESCHREIBUNG
-============
-
- Ausgesucht werden die Lebewesen genauso wie bei FindGroup(), nur
- dass zum Schluss die einzelnen Lebewesen per Zufall ausgewaehlt
- werden. Es ist also nicht gesichert, dass ueberhaupt ein Lebewesen
- zurueckgeliefert wird, trotzdem welche gefunden wurden.
-
-
-BEISPIELE
-=========
-
- Man moechte im Schnitt 50% der Feinde finden, die man gleichzeitig
- mit einem Spell belegt:
- enemyList=FindGroupP(caster,FG_ENEMIES,50);
- Dies gilt jedoch nur bei SA_EXTENSION==100, sonst wird mit
- dementsprechend mehr oder weniger Wahrscheinlichkeit zurueckgegeben.
- (also bei SA_EXTENSION==200 doppelt so viele -> 100%, also alle)
- Das Skillattribute SA_EXTENSION kann auch durch SA_QUALITY
- veraendert worden sein; das sollte beachtet werden.
-
-
-SIEHE AUCH
-==========
-
- FindGroup(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
-
-Last modified: Mon Jan 25 15:04:31 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/FindNearEnemyVictim b/doc/sphinx/man/lfun/FindNearEnemyVictim
deleted file mode 100644
index 4bd0458..0000000
--- a/doc/sphinx/man/lfun/FindNearEnemyVictim
+++ /dev/null
@@ -1,48 +0,0 @@
-
-FindNearEnemyVictim()
-*********************
-
-
-FUNKTION
-========
-
- object FindNearEnemyVictim(string wen, object pl, string msg)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- wen - id des gewuenschten Gegners, SelectNearEnemy falls n/a.
- pl - Caster.
- msg - Nachricht falls Gegner nicht anwesend ist.
-
-
-BESCHREIBUNG
-============
-
- Findet einen im Nahkampf erreichbaren Gegner,
- z.B. fuer einen Angriffsspruch.
-
-
-RUECKGABEWERT
-=============
-
- Der Auserwaehlte :-)
-
-
-BEMERKUNGEN
-===========
-
- Der Gegner wird auf jeden Fall angegriffen.
-
-
-SIEHE AUCH
-==========
-
- teams, FindEnemyVictim, FindFarEnemyVictim, FindDistantEnemyVictim
diff --git a/doc/sphinx/man/lfun/FindPotion b/doc/sphinx/man/lfun/FindPotion
deleted file mode 100644
index 5d8cae1..0000000
--- a/doc/sphinx/man/lfun/FindPotion
+++ /dev/null
@@ -1,74 +0,0 @@
-
-FindPotion()
-************
-
-
-FUNKTION
-========
-
- varargs int FindPotion(string s);
-
-
-DEFINIERT IN
-============
-
- /std/player/potion.c
-
-
-ARGUMENTE
-=========
-
- string s
- Ausgabetext. Wenn 0/Leerstring, wird Default verwendet.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt einem aufrufenden Spieler eventuell diesen ZT.
-
-
-
- Das aufrufende Spielerobjekt muss dafuer:
- * diesen ZT im Potionmaster in seiner Liste eingetragen haben
- * diesen ZT in der Liste der bekannten Traenke haben (durch
- Orakel also fuer ihn auch freigeschaltet)
- * darf keine Playerkills haben (P_KILLS)
- * darf nicht im Editiermodus sein
- * darf kein Geist sein (Ausnahme: Geisterschloss)
-
- Wenn alle Kriterien erfolgreich erfuellt sind, wird 's' oder
- "Du findest einen Zaubertrank, den Du sofort trinkst." ausgegeben
- und dem Spieler ggf die Wahl der Attribute gegeben.
-
-
-RUeCKGABEWERT
-=============
-
- 0 bei Nichtvergabe, 1 bei erfolgreicher Vergabe.
-
-
-BEISPIELE
-=========
-
- string detail_papiere() {
- if (this_player()->FindPotion(
- break_string("Beim Rumwuehlen in den Papieren entdeckst Du einen "
- "kleinen Zaubertrank, den Du sofort trinkst.", 78)))
- return "";
- // Es muss ein String zurueckgegeben werden, da man sonst
- // die Fehlermeldung "Sowas siehst du hier nicht." bekommt
- else
- return "Die Papiere sind alle unbeschriftet.\n";
- }
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: AddKnownPotion(), RemoveKnownPotion(), InList()
- Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
- Befehl: traenke (fuer Magier zum Einschalten des Findens von ZTs)
-
-6.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/lfun/FindRangedTarget b/doc/sphinx/man/lfun/FindRangedTarget
deleted file mode 100644
index 5fa6776..0000000
--- a/doc/sphinx/man/lfun/FindRangedTarget
+++ /dev/null
@@ -1,63 +0,0 @@
-
-FindRangedTarget()
-******************
-
-
-FUNKTION
-========
-
- static string FindRangedTarget(string str, mapping shoot)
-
-
-DEFINIERT IN
-============
-
- /std/ranged_weapon.c
-
-
-ARGUMENTE
-=========
-
- string str - Schusssyntax
- mapping shoot - Schussdaten
-
-
-BESCHREIBUNG
-============
-
- Erhaelt von /std/ranged_weapon::cmd_shoot() die Schussdaten und eine
- eventuell bereits modifizierte Syntax und versucht einen passenden Gegner
- im Raum oder im Gebiet (P_SHOOTING_AREA) zu finden.
- Dieser wird in SI_ENEMY im Mapping 'shoot' eingetragen und ein Wert != 0
- zurueckgegeben.
-
-
-RUECKGABEWERT
-=============
-
- 0 bei Fehlschlag
- != 0 bei gueltigem SI_ENEMY in 'shoot'
-
-
-BEMERKUNGEN
-===========
-
- 'shoot' enthaelt normalerweise folgende Eintraege:
- * Key P_WEAPON: die Schusswaffe
- * Key P_WEAPON_TYPE: P_AMMUNITION, also die Munitions-ID
- * Key P_STRETCH_TIME: P_STRETCH_TIME der Waffe
- * Key P_WC: P_SHOOTING_WC der Waffe
-
-
-SIEHE AUCH
-==========
-
- Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
- Methoden: shoot_dam(L), cmd_shoot(L)
- Gebiet: P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
- Team: PresentPosition(L)
- Suche: present, SelectFarEnemy(L)
- Syntax: _unparsed_args(L)
- Sonstiges: fernwaffen
-
-28.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/lfun/Flee b/doc/sphinx/man/lfun/Flee
deleted file mode 100644
index 995cf26..0000000
--- a/doc/sphinx/man/lfun/Flee
+++ /dev/null
@@ -1,83 +0,0 @@
-
-Flee()
-******
-
-
-FUNKTION
-========
-
- public varargs void Flee( object oldenv, int force )
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- oldenv
- Ein Raum oder 0.
- Wird ein Raum angegeben, dann muss sich der Fluechtende in diesem
- Raum befinden, damit er versucht, zu fluechten, es sei denn, das
- optionale Flag "force" ist gesetzt.
- force
- 1, wenn der spieler unabhaengig von seiner Vorsicht fluechten soll.
- 0 sonst.
-
-
-BESCHREIBUNG
-============
-
- Flee() wird im heart_beat() oder von CheckWimpyAndFlee() aufgerufen,
- um den Spieler fluechten zu lassen. Man kann die Funktion im Spieler
- auch "von Hand" aufrufen, beispielsweise in einem Spell. Man sollte
- dann force auf 1 setzen, damit der Spieler unabhaengig von seiner
- Vorsicht fluechtet.
- Hierbei kann die Flucht dazu fuehren, dass man die Teamreihe wechselt,
- aber auch, dass man den Raum verlaesst.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
-
-BEISPIELE
-=========
-
- this_player()->Flee(0, 1);
- // Der Spieler soll fluechten, egal, ob seine Lebenspunkte geringer
- // als seine Vorsicht sind und unabhaengig von seiner Position.
-
-
-
- this_player()->Flee( find_object("/gilden/abenteurer") );
- // Der Spieler soll fluechten, wenn er sich in der Abenteurergilde
- // befindet (oder wenn diese nicht existiert)
-
-
-
- this_player()->Flee( "/gilden/abenteurer" );
- // Der Spieler wird nicht fluechten, da der Vergleich von Dateiname
- // und dem Raum 0 ergibt.
-
- this_player()->Flee( find_object("/gilden/abenteurer"), 1);
- // Der Spieler soll auf jeden Fall fluechten, egal ob er sich in der
- // Abenteurergilde befindet oder nicht. Grund: Gesetztes force-Flag.
-
-
-SIEHE AUCH
-==========
-
- CheckWimpyAndFlee(), Defend(), heart_beat(),
-
-Last modified: Wed Nov 12 14:44:42 2003 by Bambi
diff --git a/doc/sphinx/man/lfun/FreeHands b/doc/sphinx/man/lfun/FreeHands
deleted file mode 100644
index c876b21..0000000
--- a/doc/sphinx/man/lfun/FreeHands
+++ /dev/null
@@ -1,60 +0,0 @@
-
-FreeHands()
-***********
-
-
-FUNKTION
-========
-
- public varargs int FreeHands(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- ob - das Objekt, dessen Handnutzung vorbei ist
- - kann 0 sein, dann wird PO benutzt
-
-
-RUECKGABEWERT
-=============
-
- 0, wenn kein Objekt uebergeben wurde oder kein PO existiert
- 1, sonst
-
-
-BESCHREIBUNG
-============
-
- Befreit die Haende eines Livings von ein bestimmten Objekt.
- Es werden _alle_ Haende wieder freigegeben.
-
-
-BEISPIELE
-=========
-
- > halte seil fest
- ...
- this_player()->UseHands(this_object(),2);
- ...
-
- > lasse seil los
- ...
- this_player()->FreeHands(this_object());
- ...
-
-
-SIEHE AUCH
-==========
-
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
- UseHands
-
-1.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/lfun/GetAquarium b/doc/sphinx/man/lfun/GetAquarium
deleted file mode 100644
index 3896ac5..0000000
--- a/doc/sphinx/man/lfun/GetAquarium
+++ /dev/null
@@ -1,59 +0,0 @@
-
-GetAquarium()
-*************
-
-
-FUNKTION
-========
-
- varargs public string* GetAquarium(object angel)
-
-
-ARGUMENTE
-=========
-
- Das optionale Argument <angel> ist die Angel selbst.
-
-
-BESCHREIBUNG
-============
-
- Die Funktion wird beim Angeln in Raeumen gerufen, wenn diese als
- Gewaessertyp W_USER gesetzt haben (siehe Manpage zu P_WATER).
- Aus der zurueckgegebenen Liste der Pfade wird einer zufaellig aus-
- gewaehlt und das Objekt geclont.
-
-
-RUECKGABEWERT
-=============
-
- String-Array mit Pfadnamen zu den in diesem Raum fangbaren Fischen.
-
-
-BEMERKUNG
-=========
-
- Man kann die Fangchancen durch Mehrfachnennung einzelner Eintraege
- modifizieren. Es muss sich bei den Eintraegen um lad- und clonebare
- Objekte handeln.
- Fuer selbstprogrammierte Fische ist das Basisobjekt
- /std/items/fishing/fish zu verwenden. Einige vorgefertigte Fische
- finden sich darueber hinaus in /items/fishing/aquarium/
-
-
-BEISPIEL
-========
-
- varargs string* GetAquarium(object angel) {
- return ({"/d/dschungel/rikus/q4e/obj/stichling",
- "/d/dschungel/rikus/q4e/obj/karpfen",
- "/p/seher/partymonster/obj/fisch"});
- }
-
-
-SIEHE AUCH
-==========
-
- Properties: P_WATER, P_FISH
-
-zuletzt geaendert: 2014-Sep-02, Arathorn
diff --git a/doc/sphinx/man/lfun/GetDetail b/doc/sphinx/man/lfun/GetDetail
deleted file mode 100644
index 7e5a092..0000000
--- a/doc/sphinx/man/lfun/GetDetail
+++ /dev/null
@@ -1,90 +0,0 @@
-
-GetDetail()
-***********
-
-
-FUNKTION
-========
-
- varargs string GetDetail(string key, string race, int sense)
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- key
- Das zu ermittelnde Detail.
- race
- Rasse des ermittelnden Objektes (falls es ein Lebewesen ist).
- sense
- Die Art des zu untersuchenden Details:
- Untersuchen, Riechen, Hoeren, Tasten.
-
-
-BESCHREIBUNG
-============
-
- Die Beschreibung des gewuenschten Details wird ermittelt. Dabei
- werden rassenspezifische Details beruecksichtigt. Es gibt hierbei
- verschiedene Detailarten, deren Typ man in <sense> angibt:
- SENSE_VIEW - Fuer Defaultdetails zum Untersuchen.
- SENSE_SMELL - Fuer Details, die man riechen kann.
- SENSE_SOUND - Fuer Details, die man hoeren kann.
- SENSE_TOUCH - Fuer Details, die man abtasten kann.
- SENSE_READ - Fuer Details, die man lesen kann.
-
- Dabei ist 0 == SENSE_VIEW.
-
-
-RUeCKGABEWERT
-=============
-
- Die Beschreibung des Details oder 0, wenn es dieses Detail nicht
- gibt.
-
-
-BEISPIEL
-========
-
- Im folgenden wird ein kleines Testdetail generiert:
- AddDetail("test","Das ist ein Test!\n");
- Im folgenden wird das Detail entfernt, wenn es existiert. Dies ist
- eigentlich nicht noetig, da RemoveDetail() damit zurechtkommt, aber
- eventuell sind ja noch weitere Aktionen noetig.
- if(GetDetail("test"))
- { RemoveDetail("test");
- ...
- }
- Ein Geruch kann man folgendermassen erzeugen:
- AddSmells("gold",
- ([0 :"Gold kann man nicht riechen!\n",
- "zwerg":"Deine trainierte Nase riecht es muehelos!\n"]));
- Die Abfrage des Details gestaltet sich recht einfach:
- GetDetail("gold","zwerg",SENSE_SMELL);
- Die Funktion liefert das Detail fuer den Zwerg.
- GetDetail("gold",0,SENSE_SMELL);
- Die Funktion liefert das Detail fuer die restlichen Rassen.
- GetDetail("gold",0,SENSE_SOUND);
- Ein Sounddetail mit dem Namen "gold" existiert nicht, die Funktion
- liefert 0 zurueck.
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveReadDetail(), RemoveSmells(), RemoveDetail(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
- P_TOUCH_DETAILS, P_SPECIAL_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: break_string()
-
-27. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/lfun/GetDoorsMapping b/doc/sphinx/man/lfun/GetDoorsMapping
deleted file mode 100644
index 68beb0d..0000000
--- a/doc/sphinx/man/lfun/GetDoorsMapping
+++ /dev/null
@@ -1,46 +0,0 @@
-
-GetDoorsMapping()
-*****************
-
-
-FUNKTION
-========
-
- mapping GetDoorsMapping()
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion erhaelt man das Mapping der vorhandenen
- Seherportale.
-
-
-
- Die Struktur ist von der Form:
- ([ Pfad: Portalnummer; Portalbeschreibung, ])
- Es wird eine Kopie dieses Mappings geliefert.
-
-
-RUECKGABEWERT
-=============
-
- Das Sehertormapping
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
-
-
-BEISPIELE
-=========
-
- "/d/seher/portale/sehertormaster"->GetDoorsMapping();
-
-
-SIEHE AUCH
-==========
-
- DoorIsKnown, ShowDoors, Teleport, DiscoverDoor
diff --git a/doc/sphinx/man/lfun/GetEnemies b/doc/sphinx/man/lfun/GetEnemies
deleted file mode 100644
index e288250..0000000
--- a/doc/sphinx/man/lfun/GetEnemies
+++ /dev/null
@@ -1,53 +0,0 @@
-
-GetEnemies()
-************
-
-
-FUNKTION
-========
-
- mapping GetEnemies();
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUeCKGABEWERT
-=============
-
- Mapping mit bekannten Gegnern als Schluessel und Zeiten als
- Eintraegen.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert das interne Mapping zurueck, in dem alle
- Gegner abgespeichert sind. Diese Gegner stellen die Schluessel in
- dem Mapping dar. Als Eintraege sind die Zeiten vermerkt, nach
- welcher Zeit ein Gegner automatisch wieder vergessen werden soll.
- Mehr Informationen dazu sind in der Dokumentation zur aehnlich
- gearteten Funktion QueryEnemies() zu finden, die jedoch zwei Arrays
- getrennte zurueckliefert.
- Achtung: Es wird keine Kopie des Mappings erstellt. Saemtliche
- Veraenderungen in dem Mapping wirken sich unmittelbar auf die
- interne Gegnerliste aus. Die Funktion sollte deshalb nicht genutzt
- werden. Gegner ein- und austragen sollte man nur mittels
- InsertEnemy() und StopHuntFor().
-
-
-SIEHE AUCH
-==========
-
- QueryEnemies(), SetEnemies(), InsertEnemy(), StopHuntFor()
-
-Last modified: Wed May 26 16:47:51 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/GetExits b/doc/sphinx/man/lfun/GetExits
deleted file mode 100644
index a235b1f..0000000
--- a/doc/sphinx/man/lfun/GetExits
+++ /dev/null
@@ -1,46 +0,0 @@
-
-GetExits()
-**********
-
-
-FUNKTION
-========
-
- varargs string GetExits(object viewer);
-
-
-DEFINIERT IN
-============
-
- /std/room/exits
-
-
-ARGUMENTE
-=========
-
- viewer
- Derjenige, der sich die Ausgaenge anschaut.
-
-
-BESCHREIBUNG
-============
-
- Es wird eine Liste der fuer viewer sichtbaren Ausgaenge erstellt.
-
-
-RUeCKGABEWERT
-=============
-
- String mit der Liste der sichtbaren Ausgaenge.
-
-
-SIEHE AUCH
-==========
-
- AddExit(), AddSpecialExit(), GetExits(),
- RemoveExit(), RemoveSpecialExit(),
- GuardExit(),
- H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
-
-Letzte Aenderung: 22.12.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/GetFValue b/doc/sphinx/man/lfun/GetFValue
deleted file mode 100644
index 30db195..0000000
--- a/doc/sphinx/man/lfun/GetFValue
+++ /dev/null
@@ -1,47 +0,0 @@
-
-GetFValue()
-***********
-
-
-FUNKTION
-========
-
- varargs int GetFValue(string vname, mapping map, object pl)
-
-
-ARGUMENTE
-=========
-
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
-
-
-BESCHREIBUNG
-============
-
- Berechnet den Wert und den Factor des Parameters in spellmapping.
-
-
-RUECKGABEWERT
-=============
-
- Berechneter Wert*Factor aus dem Spellmapping.
-
-
-BEMERKUNGEN
-===========
-
- Ruft GetValue(vname,map,pl)*GetFactor(vname,map,pl)/100 auf.
-
-
-BEISPIEL
-========
-
- xxx=GetFValue(SI_SKILLDAMAGE,sinfo,caster);
-
-Siehe auch:
-
- "GetValue", "GetFactor", "GetOffset", "GetValueO", "GetFValueO"
-
- Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/sphinx/man/lfun/GetFValueO b/doc/sphinx/man/lfun/GetFValueO
deleted file mode 100644
index 25650fb..0000000
--- a/doc/sphinx/man/lfun/GetFValueO
+++ /dev/null
@@ -1,85 +0,0 @@
-
-GetFValueO()
-************
-
-
-FUNKTION
-========
-
- varargs int GetFValueO(string vname, mapping map, object pl)
-
-
-ARGUMENTE
-=========
-
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
-
-
-BESCHREIBUNG
-============
-
- 'Berechnet' den Wert, den Factor und den Offset des Parameters
- in spellmapping.
-
-
-RUECKGABEWERT
-=============
-
- Berechneter (Wert*Factor)/100+Offset aus dem Spellmapping.
-
-
-BEMERKUNGEN
-===========
-
- Ruft (GetValue(vname,map,pl)*GetFactor(vname,map,pl))/100+
- GetOffset(vname,map,pl) auf.
-
-
-BEISPIEL
-========
-
- AddSpell("egal",10,
- ([
- OFFSET(SI_COST):([SM_RACE:(["Zwerg":4]) ]),
- FACTOR(SI_COST):([SM_RACE:(["Mensch":90]) ]),
- SI_SKILLDAMAGE:100,
- OFFSET(SI_SKILLDAMAGE):25,
- SI_SKILLDAMAGE_TYPE:DT_EXAMPLE,
- FACTOR(SI_SKILLDAMAGE):([SM_RACE:(["Zwerg":80,"Elf":120]) ])
- ]));
-
- So, was sollen uns diese Zeilen sagen?
-
- Es wird ein Spruch Names 'egal' ins Spellbook eingetragen. Er kostet
- regulaer 10 MP. Fuer Zwerge allerdings wird ein Offset von 4 MP
- aufgeschlagen. Ausserdem machen Zwerge nur 80% Schaden, Elfen
- hingegen 120%. Der Grundschaden betraegt 100 Schadenspunkte, der
- Offset des Schadens nochmal 25. Menschen bezahlen fuer diesen
- Spruch nur 90% der Kosten.
-
- Nun die Rechenbeispiele:
-
- Fuer die Kosten:
- Value ValueO FValue FValueO
- Mensch 10 10 9 9
- Elf 10 10 10 10
- Hobbit 10 10 10 10
- Zwerg 10 14 10 14
-
- Fuer den Schaden:
- Value ValueO FValue FValueO
- Mensch 100 125 100 125
- Elf 100 125 120 150
- Hobbit 100 125 100 125
- Zwerg 100 125 80 100
-
- An diesem Beispiel sieht man deutlich, wie man mit ein paar
- Offsets und Faktoren die Wirkung eines Spruches deutlich
- veraendern kann. Es sollte bei eigenen Berechnungen immer
- GetFValueO benutzt werden.
-
-Siehe auch:
-
- "GetValue", "GetFactor", "GetOffset", "GetFValue", "GetValueO"
diff --git a/doc/sphinx/man/lfun/GetFactor b/doc/sphinx/man/lfun/GetFactor
deleted file mode 100644
index adc6a19..0000000
--- a/doc/sphinx/man/lfun/GetFactor
+++ /dev/null
@@ -1,48 +0,0 @@
-
-GetFactor()
-***********
-
-
-FUNKTION
-========
-
- varargs int GetFactor(string vname, mapping map, object pl)
-
-
-ARGUMENTE
-=========
-
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
-
-
-BESCHREIBUNG
-============
-
- 'Berechnet' den Factor des Parameters in spellmapping.
-
-
-RUECKGABEWERT
-=============
-
- Berechneter Factor aus dem Spellmapping.
-
-
-BEMERKUNGEN
-===========
-
- Beschraekung auf 10-1000. Werte groesser oder kleiner als diese
- werden 'abgeschnitten'.
-
-
-BEISPIEL
-========
-
- xxx=GetFactor(SI_SKILLDAMAGE,sinfo,caster);
-
-Siehe auch:
-
- "GetValue", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
-
- Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/sphinx/man/lfun/GetGroupMembers b/doc/sphinx/man/lfun/GetGroupMembers
deleted file mode 100644
index 8c765d7..0000000
--- a/doc/sphinx/man/lfun/GetGroupMembers
+++ /dev/null
@@ -1,60 +0,0 @@
-
-GetGroupMembers()
-*****************
-
-
-FUNKTION
-========
-
- string *GetGroupMembers(string grp)
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-ARGUMENTE
-=========
-
- string grp - Gruppenname
-
-
-BESCHREIBUNG
-============
-
- Gibt alle dieser Gruppe zugehoerigen Materialien zurueck. Dazu gut, sich
- einen Ueberblick ueber die aktuelle Liste zu verschaffen.
-
-
-RUECKGABEWERT
-=============
-
- Array von Strings mit Materialien oder ({})
-
-
-BEISPIELE
-=========
-
- // wir wollen irgend ein Metall haben, nennen dies aber beim Namen
- int ind;
- string* likeit;
- likeit=MATERIALDB->GetGroupMembers(MATGROUP_METAL);
- ind=random(sizeof(likeit));
- ...
- write("Der Schmied sagt: Mir fehlt noch "+
- MATERIALDB->MaterialName(likeit[ind], WER, 100)+".\n");
- ...
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetMatMembership()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/GetInfoArr b/doc/sphinx/man/lfun/GetInfoArr
deleted file mode 100644
index ba6c4c4..0000000
--- a/doc/sphinx/man/lfun/GetInfoArr
+++ /dev/null
@@ -1,55 +0,0 @@
-
-GetInfoArr()
-************
-
-
-FUNKTION
-========
-
- static mixed *GetInfoArr(string str)
-
-
-DEFINIERT IN
-============
-
- /std/npc/info.c
-
-
-ARGUMENTE
-=========
-
- string str - Schluesselwort der Frage
-
-
-BESCHREIBUNG
-============
-
- Sucht nach einem Schluesselwort in den abgelegten Antworten
- und gibt die Informationen oder einen 0er-Array zurueck.
-
-
-BEMERKUNGEN
-===========
-
- Ueberschreibbar :)
-
-
-RUECKGABEWERT
-=============
-
- Siehe Parameter von AddInfo:
-
- Array mit:
- ({ <Infostring> (0 fuer keine Antwort),
- <Indent-String> (Default: 0),
- <Silent> (Default: 0),
- <Casebased> (Default: 0)
- })
-
-
-SIEHE AUCH
-==========
-
- Verwandt: AddInfo, do_frage
-
-31.Mar 2007 Gloinson
diff --git a/doc/sphinx/man/lfun/GetMatMembership b/doc/sphinx/man/lfun/GetMatMembership
deleted file mode 100644
index e25e991..0000000
--- a/doc/sphinx/man/lfun/GetMatMembership
+++ /dev/null
@@ -1,79 +0,0 @@
-
-GetMatMembership()
-******************
-
-
-FUNKTION
-========
-
- string *GetMatMembership(string mat)
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-ARGUMENTE
-=========
-
- string mat - ein Material
-
-
-BESCHREIBUNG
-============
-
- Gibt alle Gruppen, denen das Material angehoert zurueck. Geeignet, um
- die Eigenschaften eines Materials zu ueberpruefen.
-
-
-RUECKGABEWERT
-=============
-
- Array von Strings mit Materialiengruppen oder ({})
-
-
-BEISPIELE
-=========
-
- // ein weiser Schmied:
- int i;
- string *mat, mname, mgroup;
- mat=m_indices(ob->QueryProp(P_MATERIAL));
- i=sizeof(mat);
-
- write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
- while(i--) {
- // den Namen erkennen/aussprechen:
- // Materialien werden allgemein etwas besser erkannt (zu 5%), aber
- // alles aus Metall wird zu +100% besser erkannt ...
- mname=MATERIALDB->MaterialName(mat[i], WER,
- ({5, ([MATRGROUP_METAL, 100])}));
-
- // und nur Metalle analysieren ...
- if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
- int j;
- string *mgr;
- mgr=MATERIALDB->GetMatMembership(mat[i]);
- j=sizeof(mgr);
- mgroup=" gehoert zu ";
- while(j--) {
- mgroup+=MATERIALDB->GroupName(mgr[j]);
- if(j>0) mgroup+=", ";
- }
- } else mgroup=" kenne ich nicht";
- printf("%-12.12s: %s\n",mname, mgroup);
- }
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/GetOffset b/doc/sphinx/man/lfun/GetOffset
deleted file mode 100644
index ee982b7..0000000
--- a/doc/sphinx/man/lfun/GetOffset
+++ /dev/null
@@ -1,49 +0,0 @@
-
-GetOffset()
-***********
-
-
-FUNKTION
-========
-
- varargs int GetOffset(string vname, mapping map, object pl)
-
-
-ARGUMENTE
-=========
-
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
-
-
-BESCHREIBUNG
-============
-
- 'Berechnet' den Offset des Parameters in spellmapping.
-
-
-RUECKGABEWERT
-=============
-
- Berechneter Offset aus dem Spellmapping.
-
-
-BEMERKUNGEN
-===========
-
- Beschraekung auf -10000 bis +10000. Werte groesser oder kleiner
- als diese werden 'abgeschnitten'. Mehr als 100% Bonus oder Malus
- gibts nicht ;-).
-
-
-BEISPIEL
-========
-
- xxx=GetOffset(SI_SKILLDAMAGE,sinfo,caster);
-
-Siehe auch:
-
- "GetValue", "GetFactor", "GetFValue", "GetValueO", "GetFValueO"
-
- Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/sphinx/man/lfun/GetOwner b/doc/sphinx/man/lfun/GetOwner
deleted file mode 100644
index 92543f0..0000000
--- a/doc/sphinx/man/lfun/GetOwner
+++ /dev/null
@@ -1,38 +0,0 @@
-
-GetOwner()
-**********
-
-
-GetOwner(L)
-===========
-
-
-FUNKTION
-========
-
- string GetOwner();
-
-
-BESCHREIBUNG
-============
-
- Wird vom Hoerrohr gerufen:
- /d/inseln/shakedbeer/shakyisland/obj/hoerrohr.c
- und kann einen Besitzer der Dateien zurueckgeben, der vom Besitzer
- der Pfade in denen die Datei liegt abweicht.
-
-
-BEISPIELE
-=========
-
- string GetOwner() {
- return "Tiamak";
- }
-
-
-SIEHE AUCH
-==========
-
- P_INFO
-
-11. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/GetPhiolenInfos b/doc/sphinx/man/lfun/GetPhiolenInfos
deleted file mode 100644
index ccd0f68..0000000
--- a/doc/sphinx/man/lfun/GetPhiolenInfos
+++ /dev/null
@@ -1,122 +0,0 @@
-
-GetPhiolenInfos()
-*****************
-
-
-GetPhiolenInfos(L)
-==================
-
-
-FUNKTION
-========
-
- mixed *GetPhiolenInfos();
-
-
-BESCHREIBUNG
-============
-
- Wird von der Phiole aufgerufen:
- /d/inseln/miril/sternquest/obj/phiole.c
- Der Raum muss /p/service/miril/phiole.h includen.
- Mit der Phiole kann ein Spieler durch Tueren schauen. Bei Tueren, die
- vom Doormaster (/obj/doormaster.c) verwaltet werden, klappt dies auto-
- matisch. Moechte man das verbieten, so muss die Funktion
- GetPhiolenInfos() im entsprechenden Raum definiert sein.
- Befinden sich Tueren im Raum, die nicht vom Doormaster verwaltet werden,
- aber bei denen die Phiole funktionieren soll, so kann dies ebenfalls
- mittels GetPhiolenInfos() geschehen.
-
-
-
- Funktion der Phiole:
- Sie projiziert ein Bild dessen, was hinter der Tuer liegt auf die Tuer.
- Steht die Tuer offen, so sieht der Spieler nur eine Wand, denn es wird
- gezeigt, was hinter dieser Tuer ist.
-
-
-
- Ist die Tuer jedoch ge- oder verschlossen, so sieht er auf der Tuer
- die Langbeschreibung des Raumes, der hinter der Tuer liegt, sowie das
- Inventar dieses Raumes.
-
- Aufbau der Funktion:
- mixed *GetPhiolenInfos() {
- return ({
- ([
- PHIOLE_DEST: string,
- PHIOLE_IDS: *string,
- PHIOLE_GENDER: int,
- PHIOLE_STATUS: int, (optional)
- PHIOLE_LONG: string, (optional)
- PHIOLE_VERBOTEN: int (optional)
- ]),
- ([
- ... Naechste Tuer
- ])
- });
- }
-
-
-
- PHIOLE_DEST Dateiname des Zielraums
- PHIOLE_IDS Array der Strings, mit denen sich die Tuer
- ansprechen laesst
- PHIOLE_GENDER Geschlecht der Tuer
- PHIOLE_STATUS aktueller Status der Tuer:
- 0 geschlossen/verschlossen, 1 offen
- Bei Tueren, die mit NewDoor erzeugt wurden
- nicht setzen
- PHIOLE_LONG Beschreibung des Zielraums (z.B. bei einer
- Faketuer)
- PHIOLE_VERBOTEN 0 erlaubt, 1 verboten
-
-
-BEISPIEL
-========
-
- Ein Raum enthaelt eine Holztuer und ein Portal. Erstere ist mittels
- NewDoor(...) gebaut, soll aber nicht zu durchschauen sein, letztere ist
- selbstgestrickt. Die erste fuehrt in den Workroom von Jof, die zweite
- ist nur ein Fake und immer geschlossen. Bei vom Doormaster erzeugten
- Tueren sollte PHIOLE_STATUS nicht gesetzt werden, da dies automatisch
- abgefragt wird.
-
-
-
- #include "/p/service/miril/phiole.h"
- ...
- mixed *GetPhiolenInfos(){
- return ({
- ([
- PHIOLE_DEST:"/players/jof/workroom",
- PHIOLE_IDS:({"holztuer"}),
- PHIOLE_GENDER:FEMALE,
- PHIOLE_VERBOTEN:1
- ]),
- ([
- PHIOLE_DEST:0,
- PHIOLE_IDS:({"portal"}),
- PHIOLE_GENDER:NEUTER,
- PHIOLE_STATUS:0,
- PHIOLE_LONG:"Du stehst in einer riesigen Schatzkammer und "
- "kannst Dein Glueck kaum fassen. Nun brauchst "
- "Du nur noch zuzugreifen und bist der reichste "
- "Bewohner des MorgenGrauen.",
- PHIOLE_VERBOTEN:0
- ])
- });
- }
- Mittels PHIOLE_LONG laesst sich auch bei erlaubten und verbotenen Tueren
- einstellen, was der Spieler statt der normalen Raumbeschreibung und den
- im Raum befindlichen Objekten sehen soll. Das koennte z.B. sinnvoll
- sein, falls der Spieler zwar die Raumbeschreibung, aber nicht den fiesen
- Drachen sehen soll, der sich ebenfalls im Raum befindet.
-
-
-SIEHE AUCH
-==========
-
- NewDoor(), QueryDoorStatus(), SetDoorStatus(), QueryAllDoors()
-
-Letzte Aenderung: Sam, 14. Jan 2006, 12:21, Miril
diff --git a/doc/sphinx/man/lfun/GetReputation b/doc/sphinx/man/lfun/GetReputation
deleted file mode 100644
index b27d053..0000000
--- a/doc/sphinx/man/lfun/GetReputation
+++ /dev/null
@@ -1,53 +0,0 @@
-
-GetReputation()
-***************
-
-
-FUNKTION
-========
-
- public int GetReputation(string repid)
-
-
-DEFINIERT IN
-============
-
- /std/player/reputation.c
-
-
-ARGUMENTE
-=========
-
- repid
- Eindeutige ID der angefragten Reputation.
-
-
-BESCHREIBUNG
-============
-
- Liefert den aktuellen Wert der angegebenen Reputation <repid> zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Zahlenwert, Integer.
-
-
-BEISPIELE
-=========
-
- s. reputation
-
-
-SIEHE AUCH
-==========
-
- reputation
- ChangeReputation(), GetReputations()
-
-
-ZULETZT GEAeNDERT
-=================
-
-06.04.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/GetReputations b/doc/sphinx/man/lfun/GetReputations
deleted file mode 100644
index 134bd2c..0000000
--- a/doc/sphinx/man/lfun/GetReputations
+++ /dev/null
@@ -1,47 +0,0 @@
-
-GetReputations()
-****************
-
-
-FUNKTION
-========
-
- public mapping GetReputations()
-
-
-DEFINIERT IN
-============
-
- /std/player/reputation.c
-
-
-BESCHREIBUNG
-============
-
- Liefert ein Mapping aller im Spieler gespeicherten Reputationen und ihrer
- Werte zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Mapping ([(string)repid: (int)wert])
-
-
-BEISPIELE
-=========
-
- s. repuation
-
-
-SIEHE AUCH
-==========
-
- reputation
- GetReputation(), GetReputations()
-
-
-ZULETZT GEAeNDERT
-=================
-
-06.04.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/GetValue b/doc/sphinx/man/lfun/GetValue
deleted file mode 100644
index 29eea03..0000000
--- a/doc/sphinx/man/lfun/GetValue
+++ /dev/null
@@ -1,46 +0,0 @@
-
-GetValue()
-**********
-
-
-FUNKTION
-========
-
- varargs int GetValue(string vname, mapping map, object pl)
-
-
-ARGUMENTE
-=========
-
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
-
-
-BESCHREIBUNG
-============
-
- 'Berechnet' den Wert des uebergebenen Parameters aus dem
- Spellmapping.
-
-
-RUECKGABEWERT
-=============
-
- Berechneter Wert aus dem Spellmapping.
-
-
-BEMERKUNGEN
-===========
-
-
-BEISPIEL
-========
-
- xxx=GetValue(SI_SKILLDAMAGE,sinfo,caster);
-
-Siehe auch:
-
- "GetFactor", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
-
- Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/sphinx/man/lfun/GetValueO b/doc/sphinx/man/lfun/GetValueO
deleted file mode 100644
index e9a7522..0000000
--- a/doc/sphinx/man/lfun/GetValueO
+++ /dev/null
@@ -1,47 +0,0 @@
-
-GetValueO()
-***********
-
-
-FUNKTION
-========
-
- varargs int GetValueO(string vname, mapping map, object pl)
-
-
-ARGUMENTE
-=========
-
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
-
-
-BESCHREIBUNG
-============
-
- Berechnet den Wert und den Offset des Parameters in spellmapping.
-
-
-RUECKGABEWERT
-=============
-
- Berechneter Wert+Offset aus dem Spellmapping.
-
-
-BEMERKUNGEN
-===========
-
- Ruft GetValue(vname,map,pl)+GetOffset(vname,map,pl) auf.
-
-
-BEISPIEL
-========
-
- xxx=GetValueO(SI_SKILLDAMAGE,sinfo,caster);
-
-Siehe auch:
-
- "GetValue", "GetFactor", "GetOffset", "GetFValue", "GetFValueO"
-
- Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/sphinx/man/lfun/Gildenproperties b/doc/sphinx/man/lfun/Gildenproperties
deleted file mode 100644
index dd5676f..0000000
--- a/doc/sphinx/man/lfun/Gildenproperties
+++ /dev/null
@@ -1,186 +0,0 @@
-
-Gildenproperties()
-******************
-
-Name Beschreibung
-
-P_GUILD_SKILLS Property fuer Skills in der Gilde
-P_GUILD_RESTRICTIONS Restriktionen fuer den Eintritt in die Gilde
-P_GUILD_DEFAULT_SPELLBOOK P_GUILD_MALE_TITLES Maennliche
-Gildentitel P_GUILD_FEMALE_TITLES Weibliche Gildentitel
-P_GUILD_LEVELS Gildenstufen P_SB_SPELLS Property
-fuer Spells in Spellbook P_GLOBAL_SKILLPROPS Properties der Gilde
-UND des Spellbooks
-
-Properties des Spielers P_GUILD String mit dem Namen
-der Gilde P_GUILD_LEVEL Gildenstufe P_GUILD_TITLE
-Gildentitel P_GUILD_RATING Rating in der Gilde P_NEWSKILLS
-mapping mit Skills und Spells P_NEXT_SPELL_TIME Zeit bis der
-naechste Spell gesprochen werden kann P_TMP_ATTACK_HOOK
-Angriffs-Ersatzfunktion P_TMP_ATTACK_MOD Angriffs-Modifizierung
-P_TMP_DEFEND_HOOK Abwehr-Ersatzfunktion P_TMP_DIE_HOOK
-"Die"-Ersatzfunktion P_TMP_MOVE_HOOK Bewegungs-Ersatzfunktion
-P_DEFENDERS Verteidiger P_PREPARED_SPELL
-Vorbereiteter Spell P_DEFAULT_GUILD Standardgilde
-P_MAGIC_RESISTANCE_OFFSET Offset fuer Magie-Resistenzen
-
-Standard-Skills SK_FIGHT Kampfskill(global)
-SK_SWORDFIGHTING Schwertkampf SK_WEAPONLESS
-Waffenloser Kampf SK_TWOHANDED Zweihandkampf SK_CASTING
-Zauber-Skill SK_MAGIC_ATTACK Magischer Angriff
-SK_MAGIC_DEFENSE Magische Abwehr SK_NIGHTVISION
-Nachtsicht SK_BOOZE Sauf-Skill SK_INFORM_DEFEND
-SK_DEFEND_OTHER SK_CARRY Trage-Skill SK_SPELL_DEFEND
-Spruch-Abwehr
-
-Skill-Attribute P_SKILL_ATTRIBUTES Property fuer Skill-Attribute
-P_SKILL_ATTRIBUTE_OFFSETS Property fuer Offsets der Skill-Attribute
-SA_QUALITY Allgemeine Qualitaet SA_DAMAGE
-Schaden SA_SPEED Geschwindigkeit SA_DURATION
-Dauer SA_EXTENSION Ausdehnung SA_RANGE
-Reichweit SA_ENEMY_SAVE identisch zu SA_SPELL_PENETRATION (OBSOLET!)
-SA_SPELL_PENETRATION Chance des _Casters_, einen Spell durch ein
-
- P_NOMAGIC durchzukriegen.
-
-Skill-Info FACTOR(x) Faktor OFFSET(x)
-Offset SI_SKILLFUNC Funktion, die aufgerufen wird
-SI_CLOSURE Intern (Geschwindigkeitsoptimierung)
-SI_SPELLBOOK Spellbook, in dem der Spell steht SI_SPELLCOST
-Kosten des Spells SI_TIME_MSG Die Meldung wird anstelle
-von "Du bist noch zu
-
- erschoepft von Deinem letzten Spruch." ausgegeben.
-
-SI_SP_LOW_MSG Die Meldung wird anstelle von "Du hast zu
-wenig
- Zauberpunkte fuer diesen Spruch." ausgegeben.
-
-SI_NOMAGIC Prozentwert, mit dem P_NOMAGIC mgangen werden
-kann SI_SPELLFATIGUE Erschoepfung - Zeit, in der keine
-weiteren Spells
-
- aufgerufen werden koennen
-
-SI_SKILLLEARN Lerngeschwindigkeit in 0.01% pro A_INT/2
-SI_SKILLABILITY Faehigkeit, diesen Spruch zu benutzen
-SI_SKILLARG Argumente, die uebergeben wurden
-SI_SKILLRESTR_USE Beschraenkungen beim Gebrauch
-SI_SKILLRESTR_LEARN Beschraenkungen beim Lernen SI_SKILLINFO
-Kurzer Informationstext SI_SKILLINFO_LONG Langer
-Informationstext SI_SKILLDAMAGE Schaden SI_SKILLDAMAGE_TYPE
-Art des Schadens SI_SKILLDAMAGE_MSG Meldung die anstelle einer
-Waffe kommen soll SI_SKILLDAMAGE_MSG2 dito fuer den Text fuer
-andere im Raum SI_SPELL Spell, mit dem angegriffen
-wurde SI_INHERIT Skill, von dem etwas uebernommen werden
-soll SI_DIFFICULTY Wert, der die Obergrenze der Faehigkeit
-abgrenzt SI_LASTLIGHT Fuer Nachtsicht Wann hat der Spieler
-zum letzten
-
- mal Licht gesehen.
-
-SI_SKILLHEAL Heilung SI_USR selbst
-definierte Infos SI_GUILD Gilde, falls Auswahl aus
-mehreren moeglich SI_ENEMY Feind bei Kampfspruechen
-SI_FRIEND Der zu verteidigende Freund bei DefendOther
-
- und InformDefend
-
-SI_MAGIC_TYPE Von was fuer einer Art ist die Magie (s.u.)
-SI_PREPARE_TIME Zeit die zur Vorbereitung benoetigt wird.
-SI_ATTACK_BUSY_MSG Meldung, wenn der Spieler zu beschaeftigt ist
-SI_NO_ATTACK_BUSY Wenn der Spell nicht als Taetigkeit
-zaehlen/gezaehlt
-
- werden soll, kann man hier NO_ATTACK_BUSY[_SET|_QUERY] setzen
-
-SP_NAME Name des Spells, falls Mapping SP_SHOW_DAMAGE
-Treffermeldung soll gezeigt werden. SP_REDUCE_ARMOUR AC soll
-Typabhaengig reduziert werden. SP_PHYSICAL_ATTACK Koerperlicher
-Angriff SP_RECURSIVE Rekursionen
-
-Skill-Restrictions SR_FUN Funktion, die weitere
-Einschraenkungen prueft SR_EXCLUDE_RACE Ausgeschlossene Rassen
-SR_INCLUDE_RACE Eingeschlossene Rassen SR_GOOD
-Align < SR_BAD Align > SR_FREE_HANDS
-Benoetigte freie Haende SR_SEER Muss Seher sein
-SR_MIN_SIZE Mindestgroesse SR_MAX_SIZE
-Maximalgroesse SM_RACE Rassenspezifische
-Besonderheiten
-
-Magie-Arten MT_ANGRIFF Angriff MT_SCHUTZ
-Schutz MT_ILLUSION Illusion MT_BEHERRSCHUNG
-Beherrschung MT_HELLSICHT Hellsicht MT_VERWANDLUNG
-Verwandlung MT_BESCHWOERUNG Beschwoerung MT_BEWEGUNG
-Bewegung MT_SAKRAL 'Goettliches' MT_HEILUNG
-Heilung MT_CREATION Erschaffung MT_PSYCHO
-Psycho-Kram MT_MISC Sonstiges -----------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
--------
diff --git a/doc/sphinx/man/lfun/GiveMiniQuest b/doc/sphinx/man/lfun/GiveMiniQuest
deleted file mode 100644
index d208dbd..0000000
--- a/doc/sphinx/man/lfun/GiveMiniQuest
+++ /dev/null
@@ -1,68 +0,0 @@
-
-GiveMiniQuest()
-***************
-
-
-FUNKTION
-========
-
- int GiveMiniQuest(object winner)
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster
-
-
-ARGUMENTE
-=========
-
- winner
- Spielerobjekt, das die Quest bestanden hat.
-
-
-RUeCKGABEWERT
-=============
-
- (Die Defines fuer den Rueckgabewert finden sich in
- /secure/questmaster.h)
- 1 : Hat geklappt (OK)
- -1 : Spieler hat die Quest bereits geloest (MQ_ALREADY_SET)
- -2 : Ungueltiger Questname (MQ_KEY_INVALID)
- -3 : Unbefugter Zugriff (MQ_ILLEGAL_OBJ)
- -4 : Quest zur Zeit inaktiv (MQ_IS_INACTIVE)
- -5 : Gaeste loesen keine Quests (MQ_GUEST)
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion wird nach dem erfolgreichen Loesen einer
- MiniQuest die Quest im Spieler eingetragen. Dabei muss der
- Aufruf in dem Objekt erfolgen, welches im Questmaster
- eingetragen ist. Als Argument muss das Spielerobjekt
- angegeben werden, welches die Quest bestanden hat.
-
-
-BEISPIEL
-========
-
- QM->GiveMiniQuest(this_player());
-
-
-SIEHE AUCH
-==========
-
- HasMiniQuest
- /secure/questmaster.h, /secure/questmaster.c
-
-
-HINWEIS
-=======
-
- Die Informationen fuer den EM fuer Quests sollten diesem
- beim Eintragen der Miniquest in den Questmaster per Mail
- zugeschickt werden. Siehe dazu die Hilfe zu AddMiniQuest.
-
-Zuletzt geaendert: Don, 30. Jan 2014, 22:14:12 von Ark.
diff --git a/doc/sphinx/man/lfun/GiveQuest b/doc/sphinx/man/lfun/GiveQuest
deleted file mode 100644
index daedc6c..0000000
--- a/doc/sphinx/man/lfun/GiveQuest
+++ /dev/null
@@ -1,86 +0,0 @@
-
-GiveQuest()
-***********
-
-
-FUNKTION
-========
-
- varargs int GiveQuest(string questname, string message)
-
-
-DEFINIERT IN
-============
-
- /std/player/quests.c
-
-
-ARGUMENTE
-=========
-
- questname
- Questname, wie er im Questmaster eingetragen wurde.
- message
- Optionale Meldung, die auf dem Abenteuer-Kanal statt der
- Standardmeldung gesendet wird.
- Dabei wird @@name@@ durch den Spielernamen ersetzt.
-
-
-RUeCKGABEWERT
-=============
-
- (Die Defines fuer den Rueckgabewert finden sich in
- /secure/questmaster.h)
- 1 : Hat geklappt (OK)
- -1 : Spieler hat die Quest bereits geloest (GQ_ALREADY_SET)
- -2 : Ungueltiger Questname (GQ_KEY_INVALID)
- -3 : Unbefugter Zugriff (GQ_ILLEGAL_OBJ)
- -4 : Quest zur Zeit inaktiv (GQ_IS_INACTIVE)
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion wird nach dem erfolgreichen Loesen einer
- Quest die Quest im Spieler eingetragen. Dabei muss der Aufruf
- in dem Objekt erfolgen, welches im Questmaster eingetragen ist.
- Zusaetzlich wird der Zeitpunkt eingetragen, an dem die Quest
- bestanden wurde.
-
-
-
- Wer sich da nicht sicher ist, kann mit dem Questtool
- (/obj/tools/questtool) nachsehen.
-
- Nachdem eine Quest als geloest markiert wurde, ist dies in einem
- Logfile fuer die Quest im Verzeichnis /log/quest einzutragen. Dazu
- wird write_file verwendet.
-
-
-BEISPIEL
-========
-
- int quest;
-
- quest = this_player()->GiveQuest("Zacharias Eispalast");
-
- if (quest == 1)
- {
- write("Du fuehlst, wie Deine Erfahrung ansteigt.\n");
- write_file("/log/quest/eispalast",
- dtime(time())+" Aufgabe geloest von "
- +this_player()->name()+"\n");
- }
- else if (quest != -1)
- write( "Die Weltenmaschine will Dir Deine Arbeit "
- +"nicht anerkennen.\n"
- +"Frage einen Erzmagier um Hilfe.\n" );
-
-
-SIEHE AUCH
-==========
-
- /secure/questmaster.h, /obj/tools/questtool
- QueryQuest(), write_file(), ModifyQuestTime()
-
-Zuletzt geaendert: Son, 27. Apr 2014, Arathorn
diff --git a/doc/sphinx/man/lfun/GroupName b/doc/sphinx/man/lfun/GroupName
deleted file mode 100644
index 7b819be..0000000
--- a/doc/sphinx/man/lfun/GroupName
+++ /dev/null
@@ -1,87 +0,0 @@
-
-GroupName()
-***********
-
-
-FUNKTION
-========
-
- string GroupName(string grp)
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-ARGUMENTE
-=========
-
- string grp - ein Gruppenname
-
-
-BESCHREIBUNG
-============
-
- Gibt die Langbeschreibung des Gruppennamens zurueck.
-
-
-RUECKGABEWERT
-=============
-
- Die Gruppenbeschreibung oder "Unbekanntes"
-
-
-BEISPIELE
-=========
-
- // simpel
- tmp=m_indices(ob->QueryProp(P_MATERIAL));
- write("Dieses Objekt gehoert u.a. zur Gruppe "+
- MATERIALDB->GroupName(MATERIALDB->GetMatMembership(tmp[0])[0])+
- ".\n");
- // gibt die erste Gruppenzugehoerigkeit des erste Materials in
- // P_MATERIAL zurueck (bei MATGROUP_METAL z.B. "... zur Gruppe Metalle.")
-
- // ein weiser Schmied:
- int i;
- string *mat, mname, mgroup;
- mat=m_indices(ob->QueryProp(P_MATERIAL));
- i=sizeof(mat);
-
- write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
- while(i--) {
- // den Namen erkennen/aussprechen:
- // Materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
- // alles aus Metall wird zu +100% gut erkannt ...
- mname=MATERIALDB->MaterialName(mat[i], WER,
- ({5, ([MATERIAL_SYMMETRIC_RECOGNIZABILITY:
- ({MATGROUP_METAL, 100})])}));
-
- // und nur Metalle analysieren ...
- if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
- int j;
- string *mgr;
- mgr=MATERIALDB->GetMatMembership(mat[i]);
- j=sizeof(mgr);
- mgroup=" gehoert zu ";
- while(j--) {
- mgroup+=MATERIALDB->GroupName(mgr[j]);
- if(j>0) mgroup+=", ";
- }
- } else mgroup=" kenne ich nicht";
- printf("%-12.12s: %s\n",mname, mgroup);
- }
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- MaterialName(),
- GetGroupMembers(), GetMatMembership()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/GuardExit b/doc/sphinx/man/lfun/GuardExit
deleted file mode 100644
index 88da3c9..0000000
--- a/doc/sphinx/man/lfun/GuardExit
+++ /dev/null
@@ -1,111 +0,0 @@
-
-GuardExit()
-***********
-
-
-FUNKTION
-========
-
- protected <int|<string|closure>* >* GuardExit(object room, int hookid,
- <string|closure>* hdata);
-
-
-DEFINIERT IN
-============
-
- /std/npc/moving.c
-
-
-ARGUMENTE
-=========
-
- room
- Der den Hook ausloesende Raum (environment())
- hookid
- Die ID des Hooks (H_HOOK_EXIT_USE)
- hdata
- Ein Array mit 3 Elementen:
- ({
- verb - Das Kommandoverb/Ausgangsname (string)
- dest - Zielraum (string) oder closure (special exits)
- msg - Bewegungsrichtung (string) oder 0
- })
-
-
-BESCHREIBUNG
-============
-
- Ist diese Funktion in einem NPC definiert, traegt sich der NPC bei jeder
- Bewegung automatisch als Konsument von H_HOOK_EXIT_USE ein und diese
- Funktion wird immer gerufen, wenn ein Lebewesen im gleichen Environment
- wie der NPC versucht, einen Ausgang zu benutzen.
- Der NPC kann dann die Bewegung abbrechen (und so den Ausgang
- blockieren), Ziel oder Bewegungsmeldung aendern oder keine Veraenderung
- vornehmen.
- Die Konstanten fuer Hookid und Hookstatus (s. Rueckgabewert) sind in
- <hook.h> definiert.
-
-
-RUeCKGABEWERT
-=============
-
- Array mit zwei Elementen:
- ({
- H_NO_MOD / H_ALTERED / H_CANCELLED,
- hdata
- })
- hdata ist ggf. das geaenderte Array, welches die Funktion uebergeben
- wird. Weitere Details s. auch /doc/std/hooks
-
-
-BEMERKUNGEN
-===========
-
- Die Anzahl an Konsumenten eines Hooks ist begrenzt. Es ist daher
- moeglich, dass die Registrierung nicht klappt, wenn zuviele (>5) Waechter
- im Raum sind. Will man darauf reagieren, muesste man die Registrierung
- pruefen.
- Ein NPC, welcher GuardExit() definiert, aber im aktuellen Environment
- keine Wache halten will, koennte sich selber de-registrieren.
-
-
-BEISPIELE
-=========
-
- <int|<string|closure>* >* GuardExit(object room, int hookid,
- <string|closure>* hdata)
- {
- // Nur in Gefaengnisraeumen Wache halten
- if (strstr(object_name(environment()), "/room/jail")==0)
- {
- // Hier gehts nicht raus. ;-)
- if (hdata[0] == "raus") {
- tell_object(this_player(), ...);
- return ({H_CANCELLED, hdata});
- }
- // Special exits ersetzen wir durch einen eigenen
- else if (closurep(hdata[1])) {
- hdata[1] = #'my_special_exit;
- return ({H_ALTERED, hdata});
- }
- // alle anderen Ausgaenge in die persoenliche Zelle
- else {
- tell_object(this_player(), ...);
- hdata[1] = "/room/jail_"+getuid(this_player());
- hdata[2] = "Sueden";
- return ({H_ALTERED, hdata});
- }
- }
- // in allen anderen Raeumen nicht eingreifen
- return ({H_NO_MOD, hdata});
- }
-
-
-SIEHE AUCH
-==========
-
- AddExit, AddSpecialExit, RemoveExit
- HRegisterToHook, HRegisterModifier, HUnregisterFromHook
- /doc/std/hooks
-
-20.02.2016, Zesstra 22.05.2016, Mupfel (Beispiel korrigiert)
diff --git a/doc/sphinx/man/lfun/Halt b/doc/sphinx/man/lfun/Halt
deleted file mode 100644
index 2fb45e8..0000000
--- a/doc/sphinx/man/lfun/Halt
+++ /dev/null
@@ -1,52 +0,0 @@
-
-Halt()
-******
-
-
-FUNKTION
-========
-
- void Halt();
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Die Fahrt des Transporters wird abgebrochen. Sie muss explizit mit
- Start() wieder aufgenommen werden!
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Es gibt keine einfache Moeglichkeit, die Fahrt eines Transporters an
- der Stelle wieder aufzunehmen, an der sie unterbrochen wurde. Man
- muesste die aktuelle Position mit QueryPosition() ermitteln, mit Hilfe
- der AddXXX()-Aufrufe in eine Positionsnummer umwandlen und diese an
- Start() uebergeben.
-
-
-SIEHE AUCH
-==========
-
- Start(), /std/transport.c
-
-Last modified: Wed May 8 10:19:23 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/HasMiniQuest b/doc/sphinx/man/lfun/HasMiniQuest
deleted file mode 100644
index c832f00..0000000
--- a/doc/sphinx/man/lfun/HasMiniQuest
+++ /dev/null
@@ -1,59 +0,0 @@
-
-HasMiniQuest()
-**************
-
-
-FUNKTION
-========
-
- int HasMiniQuest(mixed pl, mixed name)
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster
-
-
-ARGUMENTE
-=========
-
- pl
- Name des Spielers oder das Spielerobjekt
- name
- Filename des Objekts oder das Objekt selbst, welches die Miniquest
- im Spieler eintragen darf, oder die Nummer (int) der Miniquest
-
-
-RUeCKGABEWERT
-=============
-
- 1 : Der Spieler hat die MiniQuest
- 0 : Der Spieler hat die MiniQuest noch nicht
- -2 : angegebene Miniquest existiert nicht
- -3 : falsche Datentypen fuer pl oder name uebergeben
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann getestet werden, ob ein Spieler eine
- MiniQuest bereits geloest hat. Dabei ist entweder der Filename des
- Objektes anzugeben, das die Quest im Spieler eintragen darf oder
- das Objekt selbst.
-
-
-BEISPIEL
-========
-
- if( QM->HasMiniQuest(getuid(this_player()), this_object())!=1 )
- write("Du bist noch nicht reif genug.\n");
-
-
-SIEHE AUCH
-==========
-
- GiveMiniQuest(L)
- /secure/questmaster.h, /secure/questmaster.c
-
-Zuletzt geaendert: 2014-Feb-03, Arathorn.
diff --git a/doc/sphinx/man/lfun/HitFunc b/doc/sphinx/man/lfun/HitFunc
deleted file mode 100644
index 2fb9b79..0000000
--- a/doc/sphinx/man/lfun/HitFunc
+++ /dev/null
@@ -1,94 +0,0 @@
-
-HitFunc()
-*********
-
-
-FUNKTION
-========
-
- int HitFunc(object enemy);
-
-
-DEFINIERT IN
-============
-
- eigenen Objekten, fuer /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- enemy
- Der Gegner, gegen den die Waffe eingesetzt wird.
-
-
-BESCHREIBUNG
-============
-
- Die Waffe kann anhand des Gegners enemy entscheiden, ob ein
- Schadensbonus oder auch ein Schadensmalus wirksam wird. Dieser Bonus
- wird zu dem normalen Schaden der Waffe hinzuaddiert.
-
-
-RUeCKGABEWERT
-=============
-
- Der Schadensbonus bzw. der Abschlag.
-
-
-BEMERKUNGEN
-===========
-
- Wenn durch den Bonus die Genehmigungsgrenzen der Balance
- ueberschritten werden koennen, muss man seinen Regionsmagier und
- die Objekt-Balance konsultieren!
-
- Werte der HitFunc sollten immer ueber ein random() zurueckgegeben
- werden!
-
- Diese Funktion sollte die Waffe nicht zerstoeren! Falls ihr im Kampf eine
- Waffe (ggf. in Abhaengigkeit vom Gegner) zerstoeren wollt, nutzt dazu
- bitte TakeFlaw().
-
-
-BEISPIELE
-=========
-
- Eine Waffe, die gegen Orks besonders gut wirkt:
-
- inherit "std/weapon";
-
- #include <properties.h>
- #include <combat.h>
- #include <class.h>
-
- create(){
- if(!clonep(this_object())) {
- set_next_reset(-1);
- return;
- }
- ::create();
- /*
- zig SetProp's, um die Waffe zu konfigurieren
- HitFunc() ist in der Waffe selbst definiert
- */
- SetProp(P_HIT_FUNC, this_object());
- }
-
- int HitFunc(object enemy)
- {
- /* laesst sich der Gegner als Ork ansprechen? */
- if (enemy->is_class_member(CL_ORC))
- return random(10+random(50)); /* Ja => Schaden erhoehen */
-
- return 0; /* ansonsten keinen zusaetzlichen Schaden anrichten */
- }
-
-
-SIEHE AUCH
-==========
-
- QueryDefend(), /std/weapon.c
- TakeFlaw()
-
-11.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/Identify b/doc/sphinx/man/lfun/Identify
deleted file mode 100644
index 9f55541..0000000
--- a/doc/sphinx/man/lfun/Identify
+++ /dev/null
@@ -1,43 +0,0 @@
-
-Identify()
-**********
-
-
-FUNKTION
-========
-
- void Identify(object ob);
-
-
-DEFINIERT IN
-============
-
- /std/corpse.c
-
-
-ARGUMENTE
-=========
-
- ob
- Das kuerzlich nach langem, hartem Kampf verstorbene Objekt.
-
-
-BESCHREIBUNG
-============
-
- In dieser Funktion werden Lang- und Kurzbeschreibung der Leiche gesetzt
- sowie die Verwesung in Gang gesetzt.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- /std/corpse.c
-
-Last modified: Wed May 8 10:19:57 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/InFight b/doc/sphinx/man/lfun/InFight
deleted file mode 100644
index 73fef03..0000000
--- a/doc/sphinx/man/lfun/InFight
+++ /dev/null
@@ -1,52 +0,0 @@
-
-InFight()
-*********
-
-
-FUNKTION
-========
-
- mixed InFight()
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wurde dazu geschrieben, um herauszufinden,
- ob sich ein PC/NPC direkt im Kampf befindet. Dazu wird
- das Array mit den Namen der Feinden des PC/NPCs durch die
- Funktion environment gefiltert und so festgestellt, ob
- die Umgebung der beiden Feinde gleich ist.
-
-RUECKGABEWERT:
- Als Rueckgabewert enthaelt man entweder 0, wenn das Objekt im
- Moment keine Feinde hat bzw. die nicht im selben Raum sind, oder
- aber das Feindobjekt, das als erstes im Array steht und anwesend
- ist.
-
-
-BEISPIEL
-========
-
- Selbsterklaerend ;)
-
-
-BEMERKUNG
-=========
-
- InFight() gibt lediglich das Ergebnis von EnemyPresent() zurueck.
-
-
-SIEHE AUCH
-==========
-
- EnemyPresent(), PresentEnemies()
- /std/living/combat.c
-
-22.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/InList b/doc/sphinx/man/lfun/InList
deleted file mode 100644
index 82de3c9..0000000
--- a/doc/sphinx/man/lfun/InList
+++ /dev/null
@@ -1,48 +0,0 @@
-
-InList()
-********
-
-
-FUNKTION
-========
-
- int InList(object room, int *potionlist, int *knownlist)
-
-
-DEFINIERT IN
-============
-
- /secure/potionmaster.c
-
-
-ARGUMENTE
-=========
-
- Implizit: previous_object() - Spielerobjekt, das ZT bekommen soll
- object room - Objekt, welches ZT vergeben will
- int* potionlist - Liste der ZTs des Spielers
- int* knownlist - Liste der bekannten ZTs des Spielers
-
-
-BESCHREIBUNG
-============
-
- Prueft, ob 'room' einen ZT vergeben darf und gibt zurueck, ob die
- Nummer dieses ZTs in der 'knownlist' enthalten ist.
-
-
-RUeCKGABEWERT
-=============
-
- 0 Kein aktiver ZT oder nicht in Liste enthalten.
- 1 Aktiver ZT und in Liste.
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: zaubertraenke, /room/orakel.c
- Verwandt: FindPotion(), RemoveKnownPotion(), AddKnownPotion()
- Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
-
-6.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/lfun/InformAlcoholEffect b/doc/sphinx/man/lfun/InformAlcoholEffect
deleted file mode 100644
index 4967510..0000000
--- a/doc/sphinx/man/lfun/InformAlcoholEffect
+++ /dev/null
@@ -1,65 +0,0 @@
-
-InformAlcoholEffect()
-*********************
-
-
-FUNKTION
-========
-
- void InformAlcoholEffect(object pl, int msgid, int area)
-
-
-DEFINIERT IN
-============
-
- eigenen Objekten; fuer /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- pl
- Das Lebewesen, das alkoholisiert ist.
- msgid
- Flag fuer die Meldung, die ausgegeben wird.
- area
- Aufruf erfolgt in Gilde (0) oder im Environment (1).
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Lebewesen alkoholisiert ist, werden in unregelmaessigen
- Abstaenden Meldungen an die Umgebung und ans Lebewesen ausgegeben.
- Gleichzeitig wird die Funktion InformAlcoholEffect in der Gilde
- und im Environment des Lebewesens aufgerufen.
-
-
-
- Es gibt vier verschiedene Meldungen (definiert in /sys/health.h):
- ALC_EFFECT_HICK (0) : "<Hick>! Oh, Tschuldigung.\n"
- ALC_EFFECT_RUELPS (1) : "Du ruelpst.\n"
- ALC_EFFECT_LOOKDRUNK (2) : "Du fuehlst Dich benommen.\n"
- ALC_EFFECT_STUMBLE (3) : "Du stolperst.\n"
-
-
-
- Wird die Funktion in einem Gildenraum implementiert, so kann man
- anhand des 3. Parameters unterscheiden, ob die Gilde als Gilde
- oder als Raum gemeint ist (die Funktion wird je einmal aufgerufen):
- ALC_EFFECT_AREA_GUILD (0) : der Aufruf betrifft die Gilde,
- ALC_EFFECT_AREA_ENV (1) : der Aufruf betrifft die Umgebung.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- P_ALCOHOL, /sys/health.h
-
-Last modified: Thu May 23 23:08:00 2002 by Mupfel
diff --git a/doc/sphinx/man/lfun/InformDefend b/doc/sphinx/man/lfun/InformDefend
deleted file mode 100644
index d6a401e..0000000
--- a/doc/sphinx/man/lfun/InformDefend
+++ /dev/null
@@ -1,81 +0,0 @@
-
-InformDefend()
-**************
-
-
-FUNKTION
-========
-
- void InformDefend(object enemy);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- enemy
- Der Feind, der ein zu verteidigendes Lebewesen angegriffen hat.
-
-
-BESCHREIBUNG
-============
-
- Es ist moeglich, dass Objekte ueber Angriffe auf Lebewesen
- informiert werden, sofern diese Objekte bei dem angegriffenen
- Lebewesen mittels AddDefender() angemeldet wurden und sich der
- selben Umgebung befinden.
- Zumeist wird es sich bei den Objekten natuerlich ebenfalls um
- andere Lebewesen handeln, die das Lebewesen, bei dem sie angemeldet
- sind, verteidigen sollen.
- Bei einem Angriff auf das Lebewesen werden alle Objekte per Aufruf
- von InformDefend() darueber informiert, wobei der Angreifer als
- Parameter uebergeben wird.
- Standardmaessig ist diese Funktion in Lebewesen bereits definiert,
- wobei der Skill SK_INFORM_DEFEND, sofern vorhanden, aufgerufen wird.
-
-
-BEISPIEL
-========
-
- Sehr beliebt sind in Gilden NPCs, die den Beschwoerer begleiten und
- verteidigen, z.B. beschworene Daemonen:
- inherit "std/npc";
- include <properties.h>
- object owner;
- void create()
- { ::create();
- SetProp(P_NAME,"Daemon");
- ...
- }
- // nach Clonen des Daemons folgende Funktion mit Beschwoerer als
- // Parameter aufrufen
- Identify(object caster)
- { if(!objectp(caster))
- call_out(#'remove,0);
- owner=caster;
- owner->AddDefender(this_object());
- }
- // folgende Funktion wird automatisch aufgerufen, wenn der
- // Beschwoerer angegriffen wird
- void InformDefend(object enemy)
- { if(!IsEnemy(enemy)&&enemy!=owner)
- Kill(enemy);
- }
- Soll der Daemon sich auch in ein Team einordnen, in welchem sich der
- Beschwoerer eventuell befindet, so ist zusaetzlich AssocMember() in
- diesem Beschwoerer aufzurufen, wobei der Daemon als Parameter
- uebergeben wird.
-
-
-SIEHE AUCH
-==========
-
- AddDefender(), RemoveDefender(), DefendOther(), Kill(), IsEnemy(),
- P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
-
-Last modified: Thu Jul 29 18:48:45 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/InformRowChange b/doc/sphinx/man/lfun/InformRowChange
deleted file mode 100644
index 7e7b804..0000000
--- a/doc/sphinx/man/lfun/InformRowChange
+++ /dev/null
@@ -1,43 +0,0 @@
-
-InformRowChange()
-*****************
-
-
-FUNKTION
-========
-
- varargs void InformRowChange(int from, int to, object caster);
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- from - Reihe, in die der Spieler vorher war.
- to - Reihe in der der Spieler jetzt ist.
- caster - Der Spieler, falls die Funktion in der Gilde aufgerufen wird.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird im Spieler und in seiner Gilde aufgerufen,
- falls sich die aktuelle Kampfreihe in der Teamaufstellung
- aendert.
-
-
-RUECKGABEWERT
-=============
-
- Keiner.
-
-
-SIEHE AUCH
-==========
-
- teams
diff --git a/doc/sphinx/man/lfun/InformUnwear b/doc/sphinx/man/lfun/InformUnwear
deleted file mode 100644
index 01e9886..0000000
--- a/doc/sphinx/man/lfun/InformUnwear
+++ /dev/null
@@ -1,48 +0,0 @@
-
-InformUnwear()
-**************
-
-
-FUNKTION
-========
-
- protected void InformUnwear(object pl, int silent, int all)
-
-
-DEFINIERT IN
-============
-
- /std/clothing/wear.c
-
-
-ARGUMENTE
-=========
-
- pl
- Das Lebewesen, das die Ruestung ausgezogen hat.
- silent
- Flag, ob Meldungen unterdruckt werden sollen.
- all
- Flag, ob die Ruestung mit "ziehe alles aus"/
- "ziehe alle ruestungen aus" ausgezogen wurde.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird aufgerufen, wenn die Ruestung erfolgreich
- ausgezogen wurde.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- InformUnwield(), InformWield(), InformWear()
-
-06.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/InformUnwield b/doc/sphinx/man/lfun/InformUnwield
deleted file mode 100644
index 1f10e72..0000000
--- a/doc/sphinx/man/lfun/InformUnwield
+++ /dev/null
@@ -1,45 +0,0 @@
-
-InformUnwield()
-***************
-
-
-FUNKTION
-========
-
- protected void InformUnwield(object pl, int silent)
-
-
-DEFINIERT IN
-============
-
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- pl
- Das Lebewesen, das die Waffe gezueckt hatte.
- silent
- Flag, ob Meldungen unterdruckt werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird aufgerufen, wenn die Waffe erfolgreich
- weggesteckt wurde.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- InformWield(), InformWear(), InformUnwear()
-
-06.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/InformWear b/doc/sphinx/man/lfun/InformWear
deleted file mode 100644
index 6860633..0000000
--- a/doc/sphinx/man/lfun/InformWear
+++ /dev/null
@@ -1,48 +0,0 @@
-
-InformWear()
-************
-
-
-FUNKTION
-========
-
- protected void InformWear(object pl, int silent, int all)
-
-
-DEFINIERT IN
-============
-
- /std/clothing/wear.c
-
-
-ARGUMENTE
-=========
-
- pl
- Das Lebewesen, das die Ruestung angezogen hat.
- silent
- Flag, ob Meldungen unterdruckt werden sollen.
- all
- Flag, ob die Ruestung mit "trage alles"/"trage alle ruestungen"
- angezogen wurde.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird aufgerufen, wenn die Ruestung erfolgreich
- angezogen wurde.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- InformUnwield(), InformWield(), InformUnwear()
-
-06.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/InformWield b/doc/sphinx/man/lfun/InformWield
deleted file mode 100644
index 0c14c2a..0000000
--- a/doc/sphinx/man/lfun/InformWield
+++ /dev/null
@@ -1,45 +0,0 @@
-
-InformWield()
-*************
-
-
-FUNKTION
-========
-
- protected void InformWield(object pl, int silent)
-
-
-DEFINIERT IN
-============
-
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- pl
- Das Lebewesen, das die Waffe gezueckt hat.
- silent
- Flag, ob Meldungen unterdruckt werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird aufgerufen, wenn die Waffe erfolgreich
- gezueckt wurde.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- InformUnwield(), InformWear(), InformUnwear()
-
-06.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/InsertEnemy b/doc/sphinx/man/lfun/InsertEnemy
deleted file mode 100644
index 84885db..0000000
--- a/doc/sphinx/man/lfun/InsertEnemy
+++ /dev/null
@@ -1,53 +0,0 @@
-
-InsertEnemy()
-*************
-
-gefunden : lfun/InsertEnemy
-
-
-FUNKTION
-========
-
- int InsertEnemy(object enemy)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- enemy: Das Lebewesen, das angegriffen werden soll.
-
-
-BESCHREIBUNG
-============
-
- Nach Aufruf der Funktion wird das Wesen in die Liste der Feinde
- aufgenommen.
- In jedem heart_beat() wird dann ein anwesender Feind
- angegriffen.
-
-
-RUECKGABEWERT
-=============
-
- 0, falls der Feind nicht existiert, kein Lebewesen ist, ein Geist ist,
- oder im Gegner P_NO_ATTACK gesetzt ist, oder schon angegegriffen
- wurde
- 1 sonst
-
-
-SIEHE AUCH
-==========
-
- Kill, IsEnemy, StopHuntFor, P_NO_ATTACK
-
-
-LETZTE AENDERUNG
-================
-
-26.08.2010, Zesstra
diff --git a/doc/sphinx/man/lfun/InsertEnemyTeam b/doc/sphinx/man/lfun/InsertEnemyTeam
deleted file mode 100644
index b25843d..0000000
--- a/doc/sphinx/man/lfun/InsertEnemyTeam
+++ /dev/null
@@ -1,66 +0,0 @@
-
-InsertEnemyTeam()
-*****************
-
-
-FUNKTION
-========
-
- varargs void InsertEnemyTeam(mixed ens, int rek)
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- ens object Feind oder object *Feinde
- rek Wurde von InsertEnemyTeam aufgerufen
-
-
-BESCHREIBUNG
-============
-
- Alle Teammitglieder des Feindes bzw. die angegebenen Feinde (aber
- nicht deren Teammitglieder) werden zu Feinden
- a) des Spielers und aller Teammitglieder, falls rek==0
- b) des Spielers, falls rek!=0
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- 1. Nur wenn Gegner und Teammitglied im gleichen Raum stehen (aber
- nicht notwendigerweise im gleichen Raum wie der Spieler) werden
- sie zu Feinden.
- 2. Falls Teammitglied und Gegner beides Spieler sind, werden sie
- nicht zu Feinden gemacht.
- 3. Ist der Gegner im eigenen Team, so wird nichts gemacht.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/InsertSensitiveObject b/doc/sphinx/man/lfun/InsertSensitiveObject
deleted file mode 100644
index 534db19..0000000
--- a/doc/sphinx/man/lfun/InsertSensitiveObject
+++ /dev/null
@@ -1,68 +0,0 @@
-
-InsertSensitiveObject()
-***********************
-
-
-FUNKTION
-========
-
- void InsertSensitiveObject(object ob, mixed *arg)
-
-
-DEFINIERT IN
-============
-
- /std/container/inventory.c
- generalizes /std/living/inventory.c
-
-
-BESCHREIBUNG
-============
-
- Fuegt "ob" in die Benachrichtigungslisten des Containers ein.
- Wird von thing/moving.c im Ziel-Environment gerufen, wenn
- P_SENSITIVE gesetzt ist.
-
-
-BEMERKUNGEN
-===========
-
- Setzt man P_SENSITIVE nicht als Default sondern situationsabhaengig,
- dann muss man auch InsertSensitiveObject() im Environment
- auch selbst rufen!
-
-
-BEISPIEL
-========
-
- // Fackel (inheriting lightsource)
- // wenn angezuendet, aendert es die Eigenschaften und wird zum
- // aktiven Objekt - das muss man dem environment() mitteilen
- static int light(string str) {
- int i;
- i=::light(str);
- if(i && QueryProp(P_LIGHT)>0) {
- SetProp(P_SENSITIVE,
- ({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,120})}));
- if(environment())
- environment()->InsertSensitiveObject(this_object(),
- QueryProp(P_SENSITIVE));
- }
- return i;
- }
-
- - falls ein empfindliches Objekt im environment() ist, dann wird
- in diesem nun eventuell (Treshold) trigger_sensitive_inv()
- gerufen
-
-
-SIEHE AUCH
-==========
-
- P_SENSITIVE
- RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY, P_SENSITIVE_INVENTORY_TRIGGER
- CheckSensitiveAttack
-
-25.Apr.2001, Gloinson@MG
diff --git a/doc/sphinx/man/lfun/InternalModifyAttack b/doc/sphinx/man/lfun/InternalModifyAttack
deleted file mode 100644
index 2d9f3eb..0000000
--- a/doc/sphinx/man/lfun/InternalModifyAttack
+++ /dev/null
@@ -1,58 +0,0 @@
-
-InternalModifyAttack()
-**********************
-
-
-InternalModifyAttack(L)
-=======================
-
-
-FUNKTION
-========
-
- protected void InternalModifyAttack(mapping ainfo)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat
-
-
-ARGUMENTE
-=========
-
- mapping ainfo Werte aus der Attack
-
-
-BESCHREIBUNG
-============
-
- Dient dazu noch Aenderungen am Verhalten der Attack() vornehmen zu
- koennen. Die Parameter werden alle per Referenz uebergeben, Aenderungen
- wirken also direkt in der Attack()!
- Einfach ueberschreiben (aber ::InternalModifyAttack(&ainfo) nicht
- vergessen!
-
- Aufbau von 'ainfo':
- ([ SI_ENEMY : object Angreifer, (-> Defend)
- SI_SPELL : 0/1/array Spellparameter, (-> Defend)
- P_WEAPON : - oder Waffe,
- SI_SKILLDAMAGE_MSG: string Angriffsmeldungsende an Raum,
- SI_SKILLDAMAGE_MSG2: string Angriffsmeldungsende an Kaempfende,
- SI_SKILLDAMAGE: int Schaden in Zehntel HP (Skills schon drin)
- (-> Defend),
- SI_SKILLDAMAGE_TYPE: string/string* Schadenstypen, (-> Defend)
- P_WEAPON_TYPE: string Waffentyp (combat.h),
- P_WC: - oder int WC der Waffe/Hand,
- P_NR_HANDS: - oder int Hands der Waffe/Hand,
- ]);
-
-
-SIEHE AUCH
-==========
-
- InternalModifyDefend(L)
- Attack(L)
-
-28.03.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/InternalModifyDefend b/doc/sphinx/man/lfun/InternalModifyDefend
deleted file mode 100644
index 3015534..0000000
--- a/doc/sphinx/man/lfun/InternalModifyDefend
+++ /dev/null
@@ -1,50 +0,0 @@
-
-InternalModifyDefend()
-**********************
-
-
-InternalModifyDefend(L)
-=======================
-
-
-FUNKTION
-========
-
- protected void InternalModifyDefend(int dam, mixed dt, mixed spell,
- object enemy)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat
-
-
-ARGUMENTE
-=========
-
- int dam Staerke des abzuwehrenden Angriffs (in HP/10)
- string/string* dt Art(en) des Schadens, der angerichtet werden soll
- int/mapping spell 0 fuer normale Angriffe (keine Zauber)
- 1 fuer Zauber (Standardruestungen ignorieren)
- mapping fuer mehr Informationen
- object enemy der Feind/Schadenverursacher
-
-
-BESCHREIBUNG
-============
-
- Dient dazu noch Aenderungen am Verhalten der Defend() vornehmen zu
- koennen. Die Parameter werden alle per Referenz uebergeben, Aenderungen
- wirken also direkt in der Defend()!
- Einfach ueberschreiben, aber ::InternalModifyDefend(&..., &....) nicht
- vergessen!
-
-
-SIEHE AUCH
-==========
-
- InternalModifyAttack(L)
- Defend(L)
-
-28.03.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/IsArmour b/doc/sphinx/man/lfun/IsArmour
deleted file mode 100644
index a7e5daf..0000000
--- a/doc/sphinx/man/lfun/IsArmour
+++ /dev/null
@@ -1,55 +0,0 @@
-
-IsArmour()
-**********
-
-
-FUNKTION
-========
-
- status IsArmour()
-
-
-DEFINIERT IN
-============
-
- /std/armour/wear.c
-
-
-RUeCKGABEWERT
-=============
-
- 1 wenn ein Ruestung
- 0 sonst
-
-
-BESCHREIBUNG
-============
-
- Gibt 1 zurueck, wenn entsprechende Klasse irgendwo geerbt wurden, es
- also eine Ruestung ist.
-
-
-BEMERKUNGEN
-===========
-
- Entsprechende Basisklasse ueberschreibt und gibt fuer IsClothing()
- explizit 0 zurueck.
-
-
-BEISPIEL
-========
-
- // enthaelt im Gegensatz zu P_ARMOURS auch nichtgetragenen Kram
- // im Inventory L1
- object *allarmours =
- filter_objects(all_inventory(this_player()), "IsArmour")
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: living, interactive
- Aehnlich: IsBottle, IsClothing, IsPlayerCorpse, IsRoom, IsUnit
- Props: P_ARMOURS
-
-3. Sep 2016, Gloinson
diff --git a/doc/sphinx/man/lfun/IsBottle b/doc/sphinx/man/lfun/IsBottle
deleted file mode 100644
index 08f0125..0000000
--- a/doc/sphinx/man/lfun/IsBottle
+++ /dev/null
@@ -1,42 +0,0 @@
-
-IsBottle()
-**********
-
-
-IsPlayerCorpse
-==============
-
-
-FUNKTION
-========
-
- int IsBottle()
-
-
-DEFINIERT IN
-============
-
- /std/items/flasche.c
-
-
-RUeCKGABEWERT
-=============
-
- 1 wenn Flasche
- 0 sonst
-
-
-BESCHREIBUNG
-============
-
- Gibt 1 zurueck, wenn das eine Flasche mit ordentlichem Flaschenverhalten
- ist.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: living, interactive
- Aehnlich: IsArmour, IsClothing, IsPlayerCorpse, IsRoom, IsUnit
-
-3. Sep 2016, Gloinson
diff --git a/doc/sphinx/man/lfun/IsClothing b/doc/sphinx/man/lfun/IsClothing
deleted file mode 100644
index c51f3f6..0000000
--- a/doc/sphinx/man/lfun/IsClothing
+++ /dev/null
@@ -1,49 +0,0 @@
-
-IsClothing()
-************
-
-
-FUNKTION
-========
-
- status IsClothing()
-
-
-DEFINIERT IN
-============
-
- /std/clothing.c
- /std/clothing_container.c
-
-
-RUeCKGABEWERT
-=============
-
- 1 wenn ein Kleidungsstueck
- 0 sonst
-
-
-BESCHREIBUNG
-============
-
- Gibt 1 zurueck, wenn entsprechende Klassen irgendwo geerbt wurden, es
- also ein Kleidungsstueck (oder ein Kleidungsstueck mit Taschen) ist.
-
-
-BEISPIEL
-========
-
- // enthaelt im Gegensatz zu P_CLOTHING auch nichtgetragenen Kram
- // im Inventory L1
- object *allcloth =
- filter_objects(all_inventory(this_player()), "IsClothing")
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: living, interactive
- Aehnlich: IsArmour, IsBottle, IsPlayerCorpse, IsRoom, IsUnit
- Props: P_CLOTHING
-
-3. Sep 2016, Gloinson
diff --git a/doc/sphinx/man/lfun/IsEnemy b/doc/sphinx/man/lfun/IsEnemy
deleted file mode 100644
index 45fb1fc..0000000
--- a/doc/sphinx/man/lfun/IsEnemy
+++ /dev/null
@@ -1,50 +0,0 @@
-
-IsEnemy()
-*********
-
-
-FUNKTION
-========
-
- int IsEnemy(object wer);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- wer
- Das Objekt, welches darauf ueberprueft werden soll, ob es
- derzeit als Gegner bekannt ist.
-
-
-RUeCKGABEWERT
-=============
-
- Flag: 1 bei Feindschaft, 0 sonst
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann man ueberpruefen, ob das Objekt <wer>, also
- im Normalfall ein Lebewesen, derzeit als Gegner erkannt wird. Nach
- einer gewissen Zeit laeuft die Feindschaft automatisch aus, sodass
- man sich nicht darauf verlassen, dass ein Gegner auch zukuenftig als
- solchiger erkannt wird. (Diese Zeit betraegt normal 300 Sekunden.)
- Solch eine Feindschaft kann im uebrigen auch einseitig sein! Mehr
- dazu findet man in der Dokumentation zu StopHuntFor(), einer
- Funktion, die Frieden zwischen Gegnern stiften soll.
-
-
-SIEHE AUCH
-==========
-
- SelectEnemy(), QueryEnemies(), StopHuntFor()
-
-Last modified: Wed May 26 16:47:51 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/IsEqual b/doc/sphinx/man/lfun/IsEqual
deleted file mode 100644
index 34d142f..0000000
--- a/doc/sphinx/man/lfun/IsEqual
+++ /dev/null
@@ -1,58 +0,0 @@
-
-IsEqual()
-*********
-
-
-FUNKTION
-========
-
- int IsEqual(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- ob Das Objekt das geprueft werden soll.
-
-BESCHREIBUNG:
- Diese Funktion prueft ob zwei Objekte vom gleichen Typ sind, also
- ob z.B. ob und this_object() beides Muenzen sind oder beides
- Edelsteine. Bei einem Ergebnis != 0 fasst unit.c diese zwei Objekte
- automatisch zusammen, wenn ob->IsEqual(this_object()) auch einen
- Wert != 0 ergibt. Hierbei wird das IsEqual() von beiden beteiligten
- Objekten gerufen und sie muessen uebereinstimmen, dass sie
- eigentlich das gleiche Objekt sind. Selbstverstaendlich ist diese
- Funktion nur im Falle von Unitobjekten sinnvoll.
-
-
-RUeCKGABEWERT
-=============
-
- 0 - this_object() ist nicht vom selben Typ wie ob
- 1 - this_object() ist vom gleichen Typ wie ob
-
-
-BEISPIELE
-=========
-
- o Ein Unitobjekt das verschiedene Beschreibungen haben kann...
-
- int IsEqual(object ob)
- {
- if (!(int)::IsEqual(ob)) return 0;
- return (QueryProp(P_SHORT)==ob->QueryProp(P_SHORT));
- }
-
-
-SIEHE AUCH
-==========
-
- /std/unit.c
-
-25.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/IsPlayerCorpse b/doc/sphinx/man/lfun/IsPlayerCorpse
deleted file mode 100644
index 3cccc05..0000000
--- a/doc/sphinx/man/lfun/IsPlayerCorpse
+++ /dev/null
@@ -1,38 +0,0 @@
-
-IsPlayerCorpse()
-****************
-
-
-FUNKTION
-========
-
- public int IsPlayerCorpse()
-
-
-DEFINIERT IN
-============
-
- /std/corpse.c
-
-
-RUeCKGABEWERT
-=============
-
- 1 wenn Spielerleiche
- 0 sonst
-
-
-BESCHREIBUNG
-============
-
- Gibt 1 zurueck, wenn diese Leiche eine Spielerleiche ist. Es kann auch
- eine "normale" NPC-Leiche sein.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: living, interactive
- Aehnlich: IsArmour, IsBottle, IsClothing, IsRoom, IsUnit
-
-3. Sep 2016, Gloinson
diff --git a/doc/sphinx/man/lfun/IsRoom b/doc/sphinx/man/lfun/IsRoom
deleted file mode 100644
index 61ce904..0000000
--- a/doc/sphinx/man/lfun/IsRoom
+++ /dev/null
@@ -1,38 +0,0 @@
-
-IsRoom()
-********
-
-
-FUNKTION
-========
-
- status IsRoom()
-
-
-DEFINIERT IN
-============
-
- /std/room.c
-
-
-RUeCKGABEWERT
-=============
-
- 1 wenn ein Raum
- 0 sonst
-
-
-BESCHREIBUNG
-============
-
- Gibt 1 zurueck, wenn /std/room.c irgendwo geerbt wurde, es also ein
- Raum ist.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: living, interactive
- Aehnlich: IsArmour, IsBottle, IsClothing, IsPlayerCorpse, IsUnit
-
-3. Sep 2016, Gloinson
diff --git a/doc/sphinx/man/lfun/IsTeamLeader b/doc/sphinx/man/lfun/IsTeamLeader
deleted file mode 100644
index 1880cc9..0000000
--- a/doc/sphinx/man/lfun/IsTeamLeader
+++ /dev/null
@@ -1,68 +0,0 @@
-
-IsTeamLeader()
-**************
-
-
-FUNKTION
-========
-
- object IsTeamLeader()
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Testet, ob der Spieler ein Teamleiter ist.
-
-
-RUECKGABEWERT
-=============
-
- Falls der Spieler Teamleiter ist, wird das Teamobjekt zurueckgegeben,
- sonst 0.
-
-
-BEISPIEL
-========
-
- string leader_test(object pl)
- {
- ...
-
- if ( objectp(pl->IsTeamLeader()) )
- return "Als Leiter eines Teams hast Du grosse Verantwortung zu "
- "tragen!";
- else
- return "Wenn Du mal Leiter eines Teams sein moechtes, solltest "
- "Du Dir vorher der Verantwortung bewusst werden!";
- }
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/IsTeamMove b/doc/sphinx/man/lfun/IsTeamMove
deleted file mode 100644
index 584dc13..0000000
--- a/doc/sphinx/man/lfun/IsTeamMove
+++ /dev/null
@@ -1,60 +0,0 @@
-
-IsTeamMove()
-************
-
-
-FUNKTION
-========
-
- object IsTeamMove()
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Testet, ob momentan die Angriffsbewegung ausgefuehrt wird.
-
-
-RUECKGABEWERT
-=============
-
- Falls die Angriffsbewegung gerade ausgefuehrt wird, wird das
- Teamobjekt zurueckgegeben, sonst 0.
-
-
-BEMERKUNGEN
-===========
-
- Wird intern benoetigt, damit der Begruessungsschlag verzoegert
- werden kann, bis alle Teammitglieder ihre Angriffsbewegung
- ausgefuehrt haben.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/IsUnit b/doc/sphinx/man/lfun/IsUnit
deleted file mode 100644
index 230f09e..0000000
--- a/doc/sphinx/man/lfun/IsUnit
+++ /dev/null
@@ -1,42 +0,0 @@
-
-IsUnit()
-********
-
-
-FUNKTION
-========
-
- int IsUnit();
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert immer 1 zurueck und zeigt damit an, dass es sich
- bei diesem Objekt um ein Mengenobjekt handelt.
-
-
-RUeCKGABEWERT
-=============
-
- 1 bei allen Objekten, die /std/unit.c erben, ansonsten 0.
-
-
-SIEHE AUCH
-==========
-
- /std/unit.c
-
-Last modified: Wed May 8 10:20:19 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/Kill b/doc/sphinx/man/lfun/Kill
deleted file mode 100644
index 1125345..0000000
--- a/doc/sphinx/man/lfun/Kill
+++ /dev/null
@@ -1,43 +0,0 @@
-
-Kill()
-******
-
-
-FUNKTION
-========
-
- int Kill(object enemy)
-
-
-ARGUMENTE
-=========
-
- enemy: Der boese, boese Feind.
-
-
-BESCHREIBUNG
-============
-
- Nach Aufruf der Funktion wird der Feind in jedem
- heart_beat() attackiert.
-
-
-RUECKGABEWERT
-=============
-
- 0, Falls der Feind nicht existiert
- -1, falls der Feind ein Geist ist
- -2, falls der Feind P_NO_ATTACK gesetzt hat
- -3, falls der Angreifer selber P_NO_ATTACK gesetzt hat
- -4, falls der Feind bereits angegriffen wurde
- 1 falls der Feind erfolgreich als Find registriert wurde.
-
-
-BEMERKUNGEN
-===========
-
-
-SIEHE AUCH
-==========
-
- InsertEnemy
diff --git a/doc/sphinx/man/lfun/LearnSkill b/doc/sphinx/man/lfun/LearnSkill
deleted file mode 100644
index caab276..0000000
--- a/doc/sphinx/man/lfun/LearnSkill
+++ /dev/null
@@ -1,53 +0,0 @@
-
-LearnSkill()
-************
-
-
-FUNKTION
-========
-
- public varargs void LearnSkill(string sname, int add, int diff)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
-
-
-ARGUMENTE
-=========
-
- string sname der zu lernende Skill
- string add Anzahl zu lernender Skillpunkte
- int diff Schwierigkeit
-
-
-BESCHREIBUNG
-============
-
- Die Methode laesst einen interaktiven (eingeloggten) Spieler den
- Skill 'sname' um 'add' Punkte lernen.
-
- Dabei wird sichergestellt, dass 'add' den Wert MAX_SKILLEARN nicht
- ueberschreitet, der Skill nicht verschwindet und fuer uebergeordnete
- Skills (SI_INHERIT) dieser uebergeordnete Skill auch einen Lerneffekt
- erfaehrt.
-
- Wird zB von Learn (spellbook) und SpellSuccess (spellbook) gerufen.
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung
- * Properties: P_NEWSKILLS
- Spellbook: Learn, SpellSuccess
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/Leave b/doc/sphinx/man/lfun/Leave
deleted file mode 100644
index fef5e6f..0000000
--- a/doc/sphinx/man/lfun/Leave
+++ /dev/null
@@ -1,64 +0,0 @@
-
-Leave()
-*******
-
-
-FUNKTION
-========
-
- int Leave();
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Wenn sich der Spieler auf einem Transporter befindet, und dieser sich
- momentan an einer Haltestelle liegt, verlaesst der Spieler den
- Transporter.
-
-
-RUeCKGABEWERT
-=============
-
- Null, wenn der Spieler den Transporter nicht verlassen konnte, sonst
- ungleich Null.
-
-
-BEMERKUNGEN
-===========
-
- Es werden keine Tests durchgefuehrt, ob der Transporter ueberhaupt
- angesprochen wurde! Das muss man selber machen.
-
-
-BEISPIELE
-=========
-
- int myLeave(string str)
- {
- if (str && id(str))
- return Leave();
-
- notify_fail("Was willst Du verlassen?\n");
- return 0;
- }
-
-
-SIEHE AUCH
-==========
-
- Enter(), /std/transport.c
-
-Last modified: Wed May 8 10:20:30 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/LimitAbility b/doc/sphinx/man/lfun/LimitAbility
deleted file mode 100644
index 6c31eed..0000000
--- a/doc/sphinx/man/lfun/LimitAbility
+++ /dev/null
@@ -1,67 +0,0 @@
-
-LimitAbility()
-**************
-
-
-FUNKTION
-========
-
- protected varargs mixed LimitAbility(mixed sinfo, int diff)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
-
-
-ARGUMENTE
-=========
-
- mixed sinfo Skill-Informationen
- int diff Schwierigkeit
-
-
-BESCHREIBUNG
-============
-
- Setzt ein Maximum an Skillfertigkeit basierend auf der Schwierigkeit
- und dem P_LEVEL des Spielers.
-
-
-
- Folgend eine Kopie (!) der Tabelle aus /std/living/skills:
- diff|lvl 1:| 3:| 7:| 10:| 13:| 16:| 19:| 22:| 25:| 28:| 31:| 34:|
- ----+------+-----+-----+----+----+----+----+----+----+----+----+----+
- -50| 83%| 84%| 86%| 87%| 89%| 90%| 92%| 93%| 95%| 96%| 98%| 99%|
- -10| 69%| 72%| 74%| 77%| 80%| 82%| 85%| 88%| 91%| 93%| 96%| 99%|
- 0| 66%| 69%| 72%| 75%| 78%| 81%| 84%| 87%| 90%| 93%| 96%| 99%|
- 10| 62%| 65%| 69%| 72%| 75%| 79%| 82%| 85%| 89%| 92%| 95%| 98%|
- 20| 59%| 62%| 66%| 70%| 73%| 77%| 80%| 84%| 88%| 91%| 95%| 98%|
- 30| 55%| 59%| 63%| 67%| 71%| 75%| 79%| 83%| 87%| 90%| 94%| 98%|
- 40| 52%| 56%| 60%| 65%| 69%| 73%| 77%| 81%| 86%| 90%| 94%| 98%|
- 50| 49%| 53%| 58%| 62%| 67%| 71%| 76%| 80%| 85%| 89%| 94%| 98%|
- 100| 32%| 38%| 44%| 50%| 56%| 62%| 68%| 74%| 80%| 86%| 92%| 98%|
- 150| 15%| 22%| 30%| 37%| 45%| 52%| 60%| 67%| 75%| 82%| 90%| 97%|
- 200| -2%| 7%| 16%| 25%| 34%| 43%| 52%| 61%| 70%| 79%| 88%| 97%|
- 250| -19%| -8%| 2%| 12%| 23%| 33%| 44%| 54%| 65%| 75%| 86%| 96%|
- 300| -36%| -24%| -12%| 0%| 12%| 24%| 36%| 48%| 60%| 72%| 84%| 96%|
- 400| -70%| -55%| -40%|-25%|-10%| 5%| 20%| 35%| 50%| 65%| 80%| 95%|
- 500| -104%| -86%| -68%|-50%|-32%|-14%| 4%| 22%| 40%| 58%| 76%| 94%|
- 600| -138%|-117%| -96%|-75%|-54%|-33%|-12%| 9%| 30%| 51%| 72%| 93%|
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung
- * Properties: P_NEWSKILLS
- Spellbook: Learn, SpellSuccess
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/MaterialGroup b/doc/sphinx/man/lfun/MaterialGroup
deleted file mode 100644
index 1b4e61e..0000000
--- a/doc/sphinx/man/lfun/MaterialGroup
+++ /dev/null
@@ -1,64 +0,0 @@
-
-MaterialGroup()
-***************
-
-
-FUNKTION
-========
-
- int MaterialGroup(mapping mats, string grp)
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-ARGUMENTE
-=========
-
- mapping mats - Materialienmapping
- string grp - Materialiengruppe
-
-
-BESCHREIBUNG
-============
-
- Die Materialien im Mapping werden auf Zugehoerigkeit zu der Gruppe
- untersucht und der Gesamtanteil dieser Materialiengruppe am Mapping
- in Prozent zurueckgegeben (wenn das Mapping sich auf 100% aufaddiert).
-
-
-RUECKGABEWERT
-=============
-
- int - prozentualer Anteil der Materialiengruppe -100 ... 100 %
-
-
-BEISPIELE
-=========
-
- if(MATERIALDB->MaterialGroup(
- ([MAT_MISC_STONE:40,MAT_AMETHYST:50,MAT_MISC_METAL:10]),
- MATGROUP_JEWEL)>50)
- write("Oh ja, darin sind sehr viele Edelsteine!\n");
-
-
-BEMERKUNGEN
-===========
-
- Wird von /std/thing/description::QueryMaterialGroup() gerufen.
- Bitte an Objekten auch QueryMaterialGroup() verwenden.
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Master: AddMaterial(), ConvMaterialList()
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/MaterialList b/doc/sphinx/man/lfun/MaterialList
deleted file mode 100644
index 228f7a8..0000000
--- a/doc/sphinx/man/lfun/MaterialList
+++ /dev/null
@@ -1,96 +0,0 @@
-
-MaterialList()
-**************
-
-
-MaterialList(L)
-===============
-
-
-FUNKTION
-========
-
- varargs string MaterialList(int casus, mixed idinf)
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- int casus - der Fall, in dem die Materialien dekliniert werden sollen
- mixed idinf - Dinge, welche die Faehigkeiten des Erkennens beeinflussen:
- Einzelne Werte:
- * x: allgemeine Erkennung -100 ... 100
- * who: der Spieler - P_MATERIAL_KNOWLEDGE wird abgefragt
- * fun: wird evaluiert
- * what, kann folgendes enthalten:
- - Eintrag fuer Materialien ([MAT_XXX:-100...100])
- - Eintrag fuer Materialiengruppen (dito)
- - ([MATERIAL_SYMMETRIC_RECOGNIZABILITY: mixed mg])
- * mg ein Array:
- ({MATGROUP_X1,int z1, MATGROUP_X2, int z2, ...})
- wobei bei Zugehoerigkeit von string mat zu Gruppe
- z<n> auf die Faehigkeit addiert, andernfalls davon
- subtrahiert wird
- Array mit obigen Werten:
- - alle Parameter des Arrays sind optional und additiv
- - ({int x, object who, mapping what, closure fun})
-
-
-BESCHREIBUNG
-============
-
- Listet die Materialien auf, aus denen ein Objekt besteht.
- Dabei haengt die Genauigkeit der Materialerkennung von idinf ab. D.h.
- je nach den Faehigkeiten/der angegebenen Faehigkeit wird zB Wolfram
- als "Wolfram" oder nur als "Metall" erkannt.
-
- Wenn ein Spieler etwas identifiziert, sollte auch TP uebergeben werden,
- bei NPCs koennte das anders aussehen.
-
-
-RUECKGABEWERT
-=============
-
- String mit Liste der Materialien.
-
-
-BEMERKUNGEN
-===========
-
- - es werden nur die Materialien angegeben, nicht die Menge.
- - ruft ConvMaterialList() an der MATERIALDB
-
-
-BEISPIELE
-=========
-
- // simpel
- write("Der Gegenstand besteht aus"+ob->MaterialList(WEM,TP)+".\n")
- // -> "Der Gegenstand besteht aus Gold, Silber und Rubin.\n"
-
- // komplexer
- ob->SetProp(P_MATERIAL, ([P_NITROGLYCERINE:90,P_GUNPOWDER:10]));
- write("Das enthaelt "+ob->MaterialList(WER,TP)+".\n");
- // -> "Das enthaelt Schwarzpulver und Nitroglycerin."
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Methoden: QueryMaterial(), QueryMaterialGroup()
- Listen: AllMaterials(), AllGroups(), Dump()
- materialliste, materialgruppen
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
- Sonstiges: P_MATERIAL_KNOWLEDGE
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/MaterialName b/doc/sphinx/man/lfun/MaterialName
deleted file mode 100644
index 782a9f7..0000000
--- a/doc/sphinx/man/lfun/MaterialName
+++ /dev/null
@@ -1,96 +0,0 @@
-
-MaterialName()
-**************
-
-
-FUNKTION
-========
-
- varargs string MaterialName(string mat, int casus, mixed idinf)
-
-
-DEFINIERT IN
-============
-
- /p/daemon/materialdb.c (MATERIALDB)
-
-
-ARGUMENTE
-=========
-
- string mat - das zu erkennende Material
- int casus - der Fall
- mixed idinf - Dinge, welche die Faehigkeiten des Erkennens beeinflussen
- (siehe "man MaterialList")
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion sucht unter Beruecksichtigung der Erkennungsbe-
- schraenkungen des Materials und Faehigkeiten des Spielers den
- Klarnamen des Materials heraus und gibt den zurueck.
-
-
-RUECKGABEWERT
-=============
-
- string: Materialname oder genereller Name.
-
-
-BEISPIELE
-=========
-
- // der hier mag alle existierenden Juwelen, auch wenn welche ergaenzt
- // werden sollten
- // Parameter: 1. ein Juwel, 2. Casus, 3. 100% Erkennung - ob er sie
- // beim Empfang dann auch zu 100% erkennt, steht hier nicht!
- string* likeit;
- likeit=MATERIALDB->GetGroupMembers(MATGROUP_JEWEL);
- ...
- write("Der Alte sagt: Ich mag "+
- MATERIALDB->MaterialName(likeit[random(sizeof(likeit))], WEN, 100)+
- ".\n");
- ...
-
- // ein weiser schmied:
- int i;
- string *mat, mname, mgroup;
- mat=m_indices(ob->queryprop(p_material));
- i=sizeof(mat);
-
- write("der schmied sagt: "+ob->name(wer)+" besteht aus ...\n");
- while(i--) {
- // den namen erkennen/aussprechen:
- // materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
- // alles aus metall wird zu +100% gut erkannt ...
- mname=materialdb->materialname(mat[i], wer,
- ({5, ([material_symmetric_recognizability:
- ({matgroup_metal, 100})])}));
-
- // und nur metalle analysieren ...
- if(materialdb->materialgroup(([mat[i]:100]),matgroup_metal)>=100) {
- int j;
- string *mgr;
- mgr=materialdb->getmatmembership(mat[i]);
- j=sizeof(mgr);
- mgroup=" gehoert zu ";
- while(j--) {
- mgroup+=materialdb->groupname(mgr[j]);
- if(j>0) mgroup+=", ";
- }
- } else mgroup=" kenne ich nicht";
- printf("%-12.12s: %s\n",mname, mgroup);
- }
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName()
- GetGroupMembers(), GetMatMembership()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/MayAddObject b/doc/sphinx/man/lfun/MayAddObject
deleted file mode 100644
index 1df06ea..0000000
--- a/doc/sphinx/man/lfun/MayAddObject
+++ /dev/null
@@ -1,55 +0,0 @@
-
-MayAddObject()
-**************
-
-
-FUNKTION
-========
-
- int MayAddObject(object ob);
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- ob - Das Object bei dem geprueft werden soll, ob es noch in den
- Container passt.
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Objekt in einen Container bewegt wird, prueft move() ueber
- diese Funktion, ob das Objekt ueberhaupt noch in den Behaelter hinein
- passt. Dazu uebergibt move() das Objekt das in den Container bewegt
- werden soll. (In Raeumen ist diese Funktionen ueberschrieben und
- liefert immer True zurueck.)
-
-
-RUeCKGABEWERT
-=============
-
- 1 - wenn das Objekt noch vom Container aufgenommen werden kann.
- 0 sonst.
-
-
-BEMERKUNGEN
-===========
-
- invis-Objekte passen immer in den Container hinein!
- move() ruft diese Funktion nicht auf, wenn in den Flags M_NOCHECK
- gesetzt war!
-
-
-SIEHE AUCH
-==========
-
- MayAddWeight(), PreventInsert(), move(), /std/container/restrictions.c
-
-Last modified: 23.09.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/MayAddWeight b/doc/sphinx/man/lfun/MayAddWeight
deleted file mode 100644
index bc8e06d..0000000
--- a/doc/sphinx/man/lfun/MayAddWeight
+++ /dev/null
@@ -1,72 +0,0 @@
-
-MayAddWeight()
-**************
-
-
-FUNKTION
-========
-
- int MayAddWeight(int gewicht);
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- gewicht
- Das zu pruefende Gewicht.
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Objekt ein einen Behaelter bewegt wird, prueft move() ueber
- diese Funktion, ob das Objekt ueberhaupt noch in den Behaelter hinein
- passt. Dazu uebergibt move() dieser Funktion das Gewicht des zu
- bewegenden Objektes.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn der Behaelter noch ein gewicht Gramm wiegendes Objekt aufnehmen
- kann, -1 im anderen Fall.
-
-
-BEMERKUNGEN
-===========
-
- move() ruft diese Funktion nicht auf, wenn in den Flags M_NOCHECK
- gesetzt war!
-
-
-BEISPIELE
-=========
-
- Die entsprechende Abfrage in /std/thing/moving.c sieht etwa
- folgendermassen aus:
-
- int weight;
-
- ...
- weight = QueryProp(P_TOTAL_WEIGHT); // Behaelter? Ja => Gesamtgewicht
- if (!weight)
- weight = QueryProp(P_WEIGHT); // Nein: einfaches Gewicht
-
- if (ziel->MayAddWeight(weight) == -1) // Passt es noch rein?
- return ME_TOO_HEAVY; // Nein, entspr. Fehler zurueckgeben
-
- ...
-
-
-SIEHE AUCH
-==========
-
- MayAddObject(), PreventInsert(), move(), /std/container/restrictions.c
-
-Last modified: 23.09.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/Message b/doc/sphinx/man/lfun/Message
deleted file mode 100644
index bee1d46..0000000
--- a/doc/sphinx/man/lfun/Message
+++ /dev/null
@@ -1,40 +0,0 @@
-
-Message()
-*********
-
-
-FUNKTION
-========
-
- varargs int Message(string str, int flag)
-
-
-ARGUMENTE
-=========
-
- str: Den zu uebermittelnden Text.
- flag: Beschreibt die Art der Meldung naeher, siehe
- /sys/player/comm.h
-
-
-BESCHREIBUNG
-============
-
- Einem Spieler wird der Text str uebermittelt.
-
-
-RUECKGABEWERT
-=============
-
- 1 bei erfolgreicher Uebermittlung
- 0 wenn der Kobold aktiv war
- <0 wenn Spieler oder verwendetes Verb ignoriert
- werden
-
-
-SIEHE AUCH
-==========
-
- P_IGNORE, TestIgnore()
-
-12. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/ModifyQuestTime b/doc/sphinx/man/lfun/ModifyQuestTime
deleted file mode 100644
index 432a362..0000000
--- a/doc/sphinx/man/lfun/ModifyQuestTime
+++ /dev/null
@@ -1,66 +0,0 @@
-
-ModifyQuestTime()
-*****************
-
-
-FUNKTION
-========
-
- int ModifyQuestTime(string questname, int zeit)
-
-
-DEFINIERT IN
-============
-
- /std/player/quests.c
-
-
-ARGUMENTE
-=========
-
- questname
- Questname, wie er im Questmaster eingetragen wurde.
- zeit
- Zeitpunkt, zu dem die Quest geloest wurde
-
-
-RUeCKGABEWERT
-=============
-
- 1 : Questzeitpunkt erfolgreich nachgetragen
- -1 : keine Zugriffsrechte (nur EM+ und der Tagebuchmaster erlaubt)
- -2 : Questliste im Spielerobjekt ist unerwartet kein Mapping
- -3 : Spieler hat diese Quest noch nicht bestanden
- -4 : kein gueltiger Zeitpunkt uebergeben (kein Integer, Wert < -1
- oder Wert > time()).
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann der Zeitpunkt nachgetragen werden, zu
- dem ein Spieler eine bestimmte Quest bereits geloest hat.
- Als Questname wird dazu der Name angegeben, der im Questmaster
- eingetragen ist. Der Zeitpunkt ist als Integer-Wert im ueblichen
- time()-Format anzugeben. Uebergibt man -1 als <zeit>, dann wird
- der Tagebuchmaster erneut versuchen, das Logfile einzulesen,
- wenn der Spieler das naechste mal sein Abenteuertagebuch liest.
-
-
-HINWEIS
-=======
-
- Die Funktion mktime() ist nuetzlich, wenn der Zeitpunkt des
- Bestehens einer Quest manuell rekonstruiert werden muss, der
- Zeitpunkt aber nur als Datums-/Zeitangabe in Textform vorliegt
- (etwa aus einem Logfile oder aus der Quest-Feedbackmail).
-
-
-SIEHE AUCH
-==========
-
- /secure/questmaster.h, /obj/tools/questtool
- GiveQuest(L)
- mktime(E), dtime(SE)
-
-Zuletzt geaendert: Mon, 27. Jan. 2015, Arathorn
diff --git a/doc/sphinx/man/lfun/ModifySkill b/doc/sphinx/man/lfun/ModifySkill
deleted file mode 100644
index 70c33ba..0000000
--- a/doc/sphinx/man/lfun/ModifySkill
+++ /dev/null
@@ -1,98 +0,0 @@
-
-ModifySkill()
-*************
-
-
-FUNKTION
-========
-
- public varargs void ModifySkill(string sname, mixed val,
- int diff, string gilde)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
-
-
-ARGUMENTE
-=========
-
- string sname der zu aendernde Skill
- mixed val Aenderungswert: int fuer SI_SKILLABILITY, sonst mapping
- int diff Schwierigkeit (optional: default ist existierendes diff)
- string gilde Gilde (optional: default ist eigene Gilde)
-
-
-BESCHREIBUNG
-============
-
- Mit der Methode kann man die Werte eines Skills/Spells veraendern. Dabei
- wird ein Skill immer in ein Mapping umgewandelt (Skills/Spells koennen
- auch einfach nur ihren Skillwert enthalten, diese ist aequivalent zu
- einem Mapping mit ([SI_SKILLABILITY:<Skillwert>]).
-
- Ist 'val' ein int, wird dieses als SI_SKILLABILITY gesetzt. Falls der
- Skill nur ein int war, wird ein 'diff'!=0 als SI_DIFFICULTY gesetzt.
-
- Ist 'val' ein Mapping, wird dieses zum Skillmapping addiert.
-
-
-
- Etwaige SI_SKILLABILITY-Aenderungen laufen danach noch durch LimitAbility.
-
-
-BEISPIELE
-=========
-
- // #1a: Lerne einen Spell/Skill (einer Gilde)
- caster->ModifySkill("feuerball", MAX_ABILITY, 100, "abenteurer")
- // #1b: ... oder ...
- caster->ModifySkill("feuerball", ([SI_SKILLABILITY: MAX_ABILITY]), 100,
- "abenteurer")
- // #1c: ... oder fuer einen Abenteurer ...
- caster->ModifySkill("feuerball", ([SI_SKILLABILITY: MAX_ABILITY]), 100);
-
-
-
- // #2: Setze eine Skill-Funktion fuer einen Kampfskill des Klerus
- this_player()->ModifySkill(FIGHT(WT_CLUB),
- ([SI_SKILLFUNC: "Keulenkampf",
- SI_DIFFICULTY: 100]),
- 100, "klerus");
-
- // #3: Speichere im Skill (also Spieler) eine Option fuer diesen Skill
- // Vorteil: dieser Eintrag wird dem Spell immer uebergeben
- caster->ModifySkill("blitz", (["klerus_spell_option": 2]));
-
- (Code in /doc/beispiele/testobjekte/modifyskillspell_test)
- // #4: Lerne einen unabhaengigen Spell: ACHTUNG
- // dieser Spell funktioniert nur solange, wie die Closure existiert,
- // SI_SKILLABILITY und Spell bleiben jedoch im Spieler gespeichert (!)
- this_player()->ModifySkill("fnrx",
- ([SI_CLOSURE:
- function int (object caster, string skill, mapping sinf) {
- caster->LearnSkill("fnrx", 1);
- tell_object(caster, "Peng! Dein Skillwert steigt auf "+
- caster->QuerySkillAbility("fnrx")+".\n");
- return ERFOLG;
- },
- SI_SKILLABILITY: 8432]),
- 100,
- "ANY");
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung
- * Properties: P_NEWSKILLS
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/ModifySkillAttribute b/doc/sphinx/man/lfun/ModifySkillAttribute
deleted file mode 100644
index 1b4fe40..0000000
--- a/doc/sphinx/man/lfun/ModifySkillAttribute
+++ /dev/null
@@ -1,133 +0,0 @@
-
-ModifySkillAttribute()
-**********************
-
-
-FUNKTION
-========
-
- public int ModifySkillAttribute(string atrname, mixed value,
- int duration)
-
-
-DEFINIERT IN
-============
-
- /std/living/skill_attributes.c
-
-
-ARGUMENTE
-=========
-
- <atrname> string
- Name des zu veraendernden Attributes
- (Definiert in /sys/living/skill_attributes.h)
-
- <value> int oder closure
- Wert des Modifikators
- oder
- eine Closure, welche bei Abfrage des betreffenden SAs
- abgefragt um den Modifikator zu bestimmen.
-
- <duration> int
- Dauer in Sekunden
-
-
-BESCHREIBUNG
-============
-
- Aendert temporaer, d.h. fuer eine bestimmte Zeit, ein Skill-Attribut
- eines Lebewesen, indem ein Modifikator hinzugefuegt wird.
-
-
-
- Der Standardwert eines SA wird von P_SKILL_ATTRIBUTE_OFFSETS festgelegt
- oder ist 100, wenn besagte Property leer ist.
- Alle Modifikatoren (negativ wie positiv) werden addiert und bilden
- zusammen mit dem Standardwert eine Gesamtsumme.
- Bei allen SAs ausser SA_QUALITY wird diese Gesamtsumme noch mit
- SA_QUALITY (welches sich damit auf alle anderen Skill-Attribute
- auswirkt) multipliziert und das Ergebnis stellt den Endwert des SA dar.
- (Beispiel s.u.)
-
- Der Wert eines Modifikators muss zwischen -1000 und 1000 liegen. Der
- Gesamtwert eines SA kann 10 nicht unter- und 1000 nicht ueberschreiten.
-
- Falle <value> eine Closure ist, wird diese Closure jedesmal
- ausgefuehrt, wenn das entsprechende SA abgefragt wird. Der
- Rueckgabewert dieser Closure stellt dann den Wert des Modifikators
- dar. Auch dieser muss zwischen -1000 und 1000 liegen. Gibt die
- Closure keinen int zurueck, wird der Modifikator geloescht.
-
- Gueltige Skill-Attribute sind momentan:
- * SA_QUALITY: Allgemeine Qualitaet: wirkt sich auf alle anderen
- Attribute auch aus (multplikativ auf Basis 100)
- * SA_DAMAGE: Schaden, den das Lebewesen macht
- * SA_SPEED: Geschwindigkeit des Lebewesens (zB Angriffe/Runde)
- * SA_DURATION: Spell-/Skilldauer
- * SA_ENEMY_SAVE: identisch zu SA_SPELL_PENETRATION (OBSOLET!)
- * SA_SPELL_PENETRATION: Chance des _Casters_, einen Spell durch ein
- P_NOMAGIC durchzukriegen.
- * SA_RANGE: Reichweite des Lebewesens (eher unbenutzt)
- * SA_EXTENSION: "Ausdehnung" bei Gruppen-/Flaechenspells: FindGroupN/P
-
-
-RUECKGABEWERT
-=============
-
- SA_MOD_OK wenn der Modifikator gesetzt wurde
- SA_TOO_MANY_MODS wenn die max. Anzahl an Mods schon erreicht ist.
- SA_MOD_TOO_SMALL wenn der Modifikator zu klein ist
- SA_MOD_TOO_BIG wenn der Modifikator zu gross ist
- SA_MOD_INVALID_ATTR wenn das gewuenschte SA gar nicht existiert
- SA_MOD_INVALID_OBJECT wenn das setzende Objekt ungueltig ist
- SA_MOD_INVALID_VALUE wenn der Modifikator ungueltig ist
- Wenn man nur wissen will, ob die Operation erfolgreich war, empfiehlt
- es sich, auf == SA_MOD_OK zu pruefen.
-
-
-BEMERKUNGEN
-===========
-
- Nachdem ein Objekt, welches Modifikatoren setzte, zerstoert wurde,
- werden die Modifikatoren spaetestens ungueltig, sobald in dem
- manipulierten Lebewesen erneut ModifySkillAttribute() gerufen wird!
- Bei Closures ist der Mod sofort weg.
-
-
-BEISPIELE
-=========
-
- // sei PL ein Spieler, den mein NPC schwaechen will:
- PL->ModifySkillAttribute(SA_QUALITY, -75, 13);
- // Fuer 13s wird SA_QUALITY um 75 reduziert. Dies wirkt sich auf alle
- // anderen SAs aus! (s. drittes Beispiel)
-
- // sei PL ein Lebewesen, welchem ich fuer 11s 2 Schlaege pro Kampfrunde
- // zusaetzlich geben moechte:
- PL->ModifySkillAttribute(SA_SPEED, 200, 11);
- // wenn keine weiteres Modifikatoren wirken, hat PL jetzt 3 Schlaege
- // pro Kampfrunde (Basiswert 100 + 200 == 300 => 3).
-
- Angenommen, ein Lebewesen hat einen Basiswert von 130 auf SA_SPEED und
- 100 auf SA_QUALITY (P_SKILL_ATTRIBUTE_OFFSETS) und nun 3 Modifikatoren
- gesetzt: SA_SPEED +100, SA_SPEED -30 und SA_QUALITY von -10:
- Zunaechst wird SA_QUALITY bestimmt: 100 - 10 = 90 => 0.9
- Anschliessend wird SA_SPEED bestimmt: 130 + 100 - 30 = 200 => 2
- Nun wird SA_SPEED noch mit SA_QUALITY multipliziert: 2 * 0.9 = 1.8
- Das Lebewesen hat nun also im Endeffekt 1.8 Schlaege pro Kampfrunde.
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill
- * Modifikation: QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/More b/doc/sphinx/man/lfun/More
deleted file mode 100644
index c504209..0000000
--- a/doc/sphinx/man/lfun/More
+++ /dev/null
@@ -1,80 +0,0 @@
-
-More()
-******
-
-
-FUNKTION
-========
-
- varargs public void More(string txt, int file,
- mixed ctrl, mixed *ctrlargs, int flags);
-
-
-DEFINIERT IN
-============
-
- /std/util/pager.c
-
-
-ARGUMENTE
-=========
-
- txt - entweder ein Text der ausgegeben werden soll, oder ein filename.
- file - das flag file gibt an, ob es sich bei <txt> um einen text oder
- einen Filenamen handelt. Bei einem Filenamen wird der Inhalt
- dieses Files eingelesen und ausgegeben.
- ctrl - Eine closure, die aufgerufen wird, falls kein <txt> angegeben
- wurde.
- ctrlargs - ctrlargs wird als Parameter an ctrl uebergeben.
- flags - flags wird mit den im Spieler definierten P_MORE_FLAGS
- kombiniert.
-
-
-BESCHREIBUNG
-============
-
- More() dient der Ausgabe von Texten an Spieler. Mit Hilfe eines
- PL->More(txt) oder PL->More(txt, 1) ist es sehr einfach laengere Texte
- an Spieler auszugeben. Bei der Ausgabe werden die persoenlichen
- Einstellungen des Spielern (wie z.b. Zeilen pro Bildschirmseite)
- automatisch beruecksichtigt und der Text dadurch ggf. zerstueckelt
- und in mehreren Schritten nacheinander angezeigt.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Beim einlesen des Files sind die Leserechte des Spieler in dem More()
- aufgerufen wird von Bedeutung und nicht die Rechte des Objektes das
- More() aufruft. Spielerobjekte haben im MorgenGrauen jedoch nur sehr
- eingeschraenkte Leserechte! Ausgegeben werden koennen nur files
- aus /p/*, /gilden/* und /d/* die _keinen_ code enthalten. Als Code
- wird hierbei jedes File betrachtet das als vorletztes Zeichen einen .
- hat (also .c, .h, .o usw.).
- Will man aus irgendwelchen Gruenden ein File (z.b. aus /players/)
- ausgeben, so sollte man stattdessen folgendes verwenden:
- this_player()->More(read_file(filename))
-
-
-BEISPIELE
-=========
-
- // Ausgabe eines normalen textes...
- this_player()->More("Einfach nur mal so ein Test...\n");
-
- // Ausgabe eines kompletten files
- this_player()->More("/etc/WIZRULES", 1);
-
-
-SIEHE AUCH
-==========
-
- ----------------------------------------------------------------------------
-
-Last modified: Mon Feb 22 15:09:18 1999 by Padreic
diff --git a/doc/sphinx/man/lfun/NPC_Killed_by b/doc/sphinx/man/lfun/NPC_Killed_by
deleted file mode 100644
index 3b8801d..0000000
--- a/doc/sphinx/man/lfun/NPC_Killed_by
+++ /dev/null
@@ -1,28 +0,0 @@
-
-NPC_Killed_by()
-***************
-
-
-FUNKTION
-========
-
- void NPC_Killed_By(object pl)
-
-
-ARGUMENTE
-=========
-
- Spieler, der einen NPC gekillt hat.
-
-
-BESCHREIBUNG
-============
-
- Wird in der Gilde des Spielers aufgerufen,
- wenn dieser einen NPC gekillt hat.
-
-
-RUECKGABEWERT
-=============
-
- Keiner
diff --git a/doc/sphinx/man/lfun/NewDoor b/doc/sphinx/man/lfun/NewDoor
deleted file mode 100644
index c534be5..0000000
--- a/doc/sphinx/man/lfun/NewDoor
+++ /dev/null
@@ -1,252 +0,0 @@
-
-NewDoor()
-*********
-
-
-FUNKTION
-========
-
- varargs int NewDoor(string|string* cmds, string dest, string|string* ids,
- mapping|<int|string|string*>* props);
-
-
-DEFINIERT IN
-============
-
- /std/room/doors.c
-
-
-ARGUMENTE
-=========
-
- cmds (string|string*)
- String oder Array von Strings mit den Befehlen, mit denen man
- durch die Tuer geht (in der Regel Richtungen wie "norden").
- dest (string)
- Pfad des Zielraumes, OHNE ".c", sonst wird eine zweiseitige Tuer
- (wie sie ueblich ist) nicht als solche erkannt.
- ids (string|string*)
- String oder Array von Strings mit den Bezeichnern der Tuer. Kann
- auch 0 sein; in diesem Fall laesst sich die Tuer nur als "tuer"
- ansprechen.
- props (mapping|<int|string|string*>*)
- Die Eigenschaften der Tuer (s.u.).
-
-
-BESCHREIBUNG
-============
-
- Es wird eine neue Tuer geschaffen. Die Tuer laesst sich, wenn sie
- geoeffnet ist, mit den in <cmds> angegebenen Befehlen durchschreiten.
- Man gelangt dann in den Raum <dest>.
-
- Die Kommandos werden bei geoeffneter Tuer in die Liste der sichtbaren
- Ausgaenge eingefuegt.
-
- In <props> lassen sich Aussehen und Eigenschaften der Tuer festlegen.
- Historisch ist es ein Array mit Paaren von Schluesseln und Werten, d.h.
- es kommt immer erst ein Element, welches die Eigenschaft bezeichnet und
- dann ein Element mit dem Wert dieser Eigenschaft.
- Moderner ist es, ein Mapping mit den entsprechenden Schluesseln und
- Werten zu uebergeben. Dies ist auch dringend empfohlen.
-
- In <doorroom.h> sind dazu folgende Eigenschaften definiert:
- D_FLAGS
- DOOR_OPEN
- Die Tuer ist beim Erzeugen geoeffnet.
- DOOR_CLOSED
- Die Tuer ist beim Erzeugen geschlossen.
- DOOR_NEEDKEY
- Man benoetigt einen Schluessel zum Oeffnen der Tuer.
- DOOR_CLOSEKEY
- Man benoetigt einen Schluessel zum Schliessen der Tuer.
- DOOR_RESET_CL
- Die Tuer schliesst sich beim Reset.
- DOOR_RESET_OP
- Die Tuer oeffnet sich beim Reset.
-
- D_LONG
- Die Langbeschreibung der Tuer.
- Hier kann ein Mapping eingetragen werden, das als Keys den Tuer-
- Status hat und die zugehoerige Langbeschreibung dazu. Beispiel:
- ([ D_STATUS_CLOSED : "Die Tuer ist geschlossen.\n",
- D_STATUS_OPEN : "Die Tuer ist offen.\n" ])
-
-
-
- Default: "Eine Tuer.\n"
-
- D_SHORT
- Die Kurzbeschreibung der Tuer. Ein "%s" wird durch "geoeffnet"
- bzw. "geschlossen" ersetzt.
-
- Es werden die Kurzbeschreibungen aller im Raum vorhandenen Tueren
- aneinandergehaengt (es wird jeweils ein Leerzeichen eingeschoben),
- das Ganze mit break_string() umgebrochen und an P_INT_LONG
- angehaengt.
-
- Default: "Eine %se Tuer."
-
- D_NAME
- Der Name der Tuer. Dieser Name wird beim Oeffnen und Schliessen
- der Tuer sowie bei Fehlermeldungen ausgegeben. Man kann wie bei
- P_NAME einen String oder ein Array von Strings angeben.
-
- Default: "Tuer"
-
- D_GENDER
- Das Geschlecht der Tuer.
-
- Default: FEMALE
-
- D_MSGS
- String oder Array von drei Strings. Diese Strings werden beim
- Durchschreiten der Tuer an move() als dir bzw. dir, textout und
- textin uebergeben.
-
- D_FUNC
- String mit dem Namen einer Funktion, die im Startraum vor dem
- Durchschreiten der Tuer aufgerufen werden soll. Diese Funktion
- kann das Durchschreiten jedoch nicht verhindern!
-
- D_FUNC2
- String mit dem Namen einer Funktion, die im Zielraum nach dem
- Durchschreiten der Tuer aufgerufen werden soll.
-
- D_TESTFUNC
- Falls auf den Namen einer Funktion gesetzt, wird diese Funktion
- vor dem Durchschreiten im Startraum aufgerufen. Wenn sie einen
- Wert != 0 zurueckliefert, wird die Tuer NICHT durchschritten.
-
- D_RESET_MSG
- Meldung, die beim Reset der Tuer ausgegeben wird.
-
- D_OPEN_WITH_MOVE
- Tuer oeffnet automatisch bei Eingabe des Befehls zum
- Hindurchgehen.
-
-
-RUECKGABEWERT
-=============
-
- 1, wenn die Tuer ordungsgemaess eingebaut werden konnte, sonst 0.
-
-
-BEMERKUNGEN
-===========
-
- Zwei Tuerseiten gelten als verschiedene Seiten einer Tuer, wenn als
- Ziel in Raum A Raum B und in Raum B Raum A angegeben ist. Der Zustand
- wird abgefragt, wenn der Raum betreten wird (init), wenn die Tuer
- geoeffnet/geschlossen wird, P_INT_LONG oder P_EXITS abgefragt wird
- und beim Reset.
-
- Es sind auch Tueren moeglich, die nur auf einer Seite existieren, oder
- auch solche, die auf beiden Seiten verschieden aussehen oder gar auf
- einer Seite nur mit einem Schluessel zu oeffnen sind, auf der anderen
- jedoch kein Schluessel noetig ist.
-
- Wer aus irgendeinem Grund den Zustand einer Tuer selber abfragen oder
- veraendern will, kann dafuer in /obj/doormaster die Funktionen
- QueryDoorStatus(ziel) bzw. SetDoorStatus(ziel,status) aufrufen.
-
- *** ACHTUNG ***
- Es gibt eine Questbelohnung (Phiole aus der Sternenlicht-Quest von
- Miril), mit der man durch Tueren hindurchschauen kann. Derzeit ist das
- per default fuer alle Tueren erlaubt. Wenn man das nicht moechte,
- oder andere Texte ausgeben, als die Phiole normalerweise erzeugt,
- dann kann man dies durch Nutzung bestimmter Funktionen bzw. Flags
- erreichen. Zur Dokumentation siehe Manpage zu GetPhiolenInfos().
-
-
-BEISPIELE
-=========
-
- ** Dies ist eine gewoehnliche Tuer ohne Besonderheiten und ohne
- Extra-Beschreibung:
-
- NewDoor("sueden","/players/rochus/room/test1");
-
- ** Ein Portal:
-
- NewDoor("norden","/players/rochus/room/test2",
- "portal",
- ([ D_NAME: "Portal",
- D_GENDER: NEUTER,
- D_SHORT: "Im Norden siehst Du ein %ses Portal.",
- D_LONG: "Das Portal ist einfach nur gigantisch.\n",
- ]) );
-
- Alternativ mit props in alter Arraynotation:
- NewDoor("norden","/players/rochus/room/test2",
- "portal",
- ({ D_NAME, "Portal",
- D_GENDER, NEUTER,
- D_SHORT, "Im Norden siehst Du ein %ses Portal.",
- D_LONG, "Das Portal ist einfach nur gigantisch.\n"
- }) );
-
-
-
- ** Tueren mit Bewegungsmeldung:
-
- NewDoor("norden","/room/see2",
- ({ D_MSGS, ({"nach Norden","schwimmt",
- "kommt hereingeschwommen"}) }) );
-
- ** Eine Tuer mit Testfunktion:
-
- NewDoor("osten","/mein/zielraum",
- ({ D_TESTFUNC, "blocker_da" }) );
-
- Die Funktion blocker_da:
-
- int blocker_da() // KEINE protected-Funktion! Sie wird sonst NICHT
- { // aufgerufen und ausgewertet!
- if ( present("mein_fieses_mo\nster",this_object()) )
- {
- write("Ein fieses Monster stellt sich Dir in den Weg.\n");
- return 1;
- }
- return 0; // optional
- }
-
- ** Nun noch eine Tuer mit einigen Extras:
-
- NewDoor("nordwesten","/rooms/kammer",
- ({"tuer","holztuer"}),
- ({
- D_FLAGS, (DOOR_CLOSED|DOOR_RESET_CL),
- D_MSGS, ({"nach Nordwesten","geht",
- "kommt durch eine Tuer herein"}),
- D_SHORT, "Im Nordwesten siehst Du eine %se Holztuer.",
- D_LONG, "Sie trennt den Laden vom dahinterliegenden Raum.\n",
- D_NAME, "Holztuer",
- D_FUNC, "view",
- D_FUNC2, "look_up"
- }) );
-
- Im Startraum:
-
- void view()
- {
- write("Der Angestellte wirft Dir einen missbilligenden Blick zu, "
- "laesst Dich aber passieren.\n");
- }
-
- Im Zielraum:
-
- void look_up()
- {
- write("Ein alter Mann schaut kurz zu Dir auf und vertieft sich dann "
- "wieder in seine Akten.\n");
- }
-
-
-SIEHE AUCH
-==========
-
- QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
-
-08.02.2015, Arathorn
diff --git a/doc/sphinx/man/lfun/NoParaObjects b/doc/sphinx/man/lfun/NoParaObjects
deleted file mode 100644
index 4b6013a..0000000
--- a/doc/sphinx/man/lfun/NoParaObjects
+++ /dev/null
@@ -1,46 +0,0 @@
-
-NoParaObjects()
-***************
-
-********************** VERALTETE LFUN ****************************
-NoParaObjects()
-
-
-FUNKTION
-========
-
- int NoParaObjects()
-
-
-DEFINIERT IN
-============
-
- /std/virtual/v_compiler.c
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn der VC keine Parawelt-Objekte erzeugt,
- 0, wenn er es doch tut.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ist veraltet. QueryValidObject() ist genereller und
- einfacher zu handhaben. Bitte in Zukunft P_PARA im VC setzen, siehe hierzu
- die Manpage von QueryValidObject().
-
- Die Funktion gibt an, ob ein Virtual Compiler auch Parawelt-Objekte
- erzeugen kann.
- Wichtig: Entweder dieser Funktion im VC definieren, wenn der VC keine
- Para-Objekte erzeugen wird oder P_PARA passend setzen!
-
-
-SIEHE AUCH
-==========
-
- virtual_compiler, P_PARA, QueryValidObject
-
-04.03.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/NotifyDestruct b/doc/sphinx/man/lfun/NotifyDestruct
deleted file mode 100644
index 31e02e9..0000000
--- a/doc/sphinx/man/lfun/NotifyDestruct
+++ /dev/null
@@ -1,66 +0,0 @@
-
-NotifyDestruct()
-****************
-
-
-FUNKTION
-========
-
- public int|string NotifyRemove(object zerstoerer);
-
-
-ARGUMENTE
-=========
-
- zerstoerer
- Das Objekt, welches destruct() auf dieses Objekt anwendet.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird vom Master der Mudlib in jedem Objekt gerufen,
- welches zerstoert wird, um Objekten eine letzte Chance zu geben, sich
- aufzuraeumen.
- Wenn ihr diese Funktion selber definiert, achtet bittet darauf, dass sie
- in keinem Fall Fehler ausloesen sollte, d.h. testet entsprechend
- gruendlich.
- Wenn ihr aus /std/ erbt und diese Funktion ueberschreibt,, _muesst_ ihr
- die geerbte NotifyDestruct() aufrufen, da sonst das Lichtsystem nicht
- aktualisiert wird.
-
- Privilegierte Objekte (z.B. Root-Objekte, spezielle Ausnahmen wie der
- Netztotenraum, Armageddon) koennen die Zerstoerung in letzter Sekunde
- verhindern, indem sie hier einen Wert != 0 zurueckliefern. Wird ein
- string zurueckgeliefert, wird dieser die Fehlermeldung des
- prepare_destruct() im Master sein.
- Bei nicht-privilegierten Objekten (also fast alle) ist an dieser Stelle
- _kein_ Abbruch der Zerstoerung moeglich!
-
-
-RUeCKGABEWERT
-=============
-
- Der Rueckgabewert muss ein string oder ein int sein. Allerdings wird der
- Master den Rueckgabewert nur fuer privilegierte Objekte auswerten.
-
-
-BEMERKUNGEN
-===========
-
- Wie gesagt, bitte keine Fehler ausloesen (auch wenn der Master
- grundsaetzlich damit klar kommt). Speziell ist ein raise_error() zur
- Verhinderung eines destructs nutzlos.
- Bitte macht in dieser Funkion nur das, was _unbedingt_ notwendig ist.
- Wenn jemand ein destruct() anwendet statt ein remove() zu rufen, hat das
- in der Regel einen Grund (z.B. um buggende remove() zu umgehen). Insb.
- ist ein save_object() in remove() und NotifyDestruct() vollstaendig
- ueberfluessig.
-
-
-SIEHE AUCH
-==========
-
- NotifyLeave(), NotifyInsert(), NotifyRemove()
-
-Last modified: 25.02.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/NotifyInsert b/doc/sphinx/man/lfun/NotifyInsert
deleted file mode 100644
index fa2f2ac..0000000
--- a/doc/sphinx/man/lfun/NotifyInsert
+++ /dev/null
@@ -1,47 +0,0 @@
-
-NotifyInsert()
-**************
-
-
-FUNKTION
-========
-
- void NotifyInsert(object ob, object oldenv);
-
-
-ARGUMENTE
-=========
-
- ob
- Das Objekt, das in den Behaelter eingefuegt wurde.
- oldenv
- Das Objekt, aus dem <ob> kam.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird im Behaelter aufgerufen, nachdem ein Objekt in
- besagten Behaelter hinein bewegt wurde.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion wird nur im Falle unbelebter Objekte gerufen. Fuer
- Lebewesen s. bitte. init().
-
-
-SIEHE AUCH
-==========
-
- NotifyLeave(), PreventInsert(), PreventLeave(), move(), NotifyRemove()
- exit(), init(), NotifyMove(), PreventMove()
-
-Last modified: 21.05.2012, Zesstra
diff --git a/doc/sphinx/man/lfun/NotifyLeave b/doc/sphinx/man/lfun/NotifyLeave
deleted file mode 100644
index fbfc1c3..0000000
--- a/doc/sphinx/man/lfun/NotifyLeave
+++ /dev/null
@@ -1,47 +0,0 @@
-
-NotifyLeave()
-*************
-
-
-FUNKTION
-========
-
- void NotifyLeave(object ob, object dest);
-
-
-ARGUMENTE
-=========
-
- ob
- Das Objekt, das aus dem Behaelter entfernt wurde.
- dest
- Das Objekt, in das <ob> bewegt wurde.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird im Behaelter aufgerufen, nachdem ein Objekt aus
- besagten Behaelter entfernt wurde.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion wird nur im Falle unbelebter Objekte gerufen. Fuer
- Lebewesen s. bitte. exit().
-
-
-SIEHE AUCH
-==========
-
- NotifyRemove(), NotifyInsert(), PreventInsert(), PreventLeave(), move(),
- exit(), init(), NotifyMove(), PreventMove()
-
-Last modified: 21.05.2012, Zesstra
diff --git a/doc/sphinx/man/lfun/NotifyMove b/doc/sphinx/man/lfun/NotifyMove
deleted file mode 100644
index 18261f8..0000000
--- a/doc/sphinx/man/lfun/NotifyMove
+++ /dev/null
@@ -1,83 +0,0 @@
-
-NotifyMove()
-************
-
-
-FUNKTION
-========
-
- protected void NotifyMove(object dest, object oldenv, int method);
-
-
-DEFINIERT IN
-============
-
- /std/thing/moving.c
- /std/living/moving.c
- /std/player/moving.c
-
-
-ARGUMENTE
-=========
-
- dest
- Das Ziel des Moves bzw. das jetzt aktuelle Environment
- oldenv
- Das alte Environment des Objekts
- method
- Die Move-Methode(n), mit der/denen bewegt wurde.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird vom move() im Objekt gerufen, sobald die Bewegung im
- wesentlichen abgeschlossen ist. Sie soll einerseits das Objekt ueber eine
- stattgefundene Bewegung informieren, aber auch einige Dinge erledigen,
- die bei der Bewegung stattfinden muessen (bei Livings z.B. das Team
- nachholen).
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion kann ueberschrieben werden, damit das Objekt Bewegungen
- mitgekommt, ohne das move() selber zu ueberschreiben oder einen Move-Hook
- zu setzen. Dabei aber bitte unbedingt beachten:
- Das geerbte NotifyMove() _MUSS IN JEDEM FALL_ mit aufgerufen werden!
- Solltet ihr das vergessen, werden eure Objekte buggen. ;-)
- Die Funktion darf nur objektintern verwendet werden. Beim Ueberschreiben
- das 'protected' nicht vergessen!
-
-
-BEISPIELE
-=========
-
- Eine Bombe, die in Seherhaustruhen explodiert:
-
- protected void NotifyMove(object dest, object oldenv, int method) {
- ::NotifyMove(dest, oldenv, method); // WICHTIG!
- if (objectp(dest) &&
- load_name(dest) == "/d/seher/haeuser/truhe") {
- if (find_call_out("explodiere")==-1)
- call_out("explodiere",900);
- }
- else
- remove_call_out("explodiere");
- }
-
-
-SIEHE AUCH
-==========
-
- PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
- PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
- PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
-
-Last modified: 04.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/NotifyPlayerDeath b/doc/sphinx/man/lfun/NotifyPlayerDeath
deleted file mode 100644
index 96678ea..0000000
--- a/doc/sphinx/man/lfun/NotifyPlayerDeath
+++ /dev/null
@@ -1,99 +0,0 @@
-
-NotifyPlayerDeath()
-*******************
-
-
-FUNKTION
-========
-
- void NotifyPlayerDeath(object victim,object killer,int lost_exp);
-
-
-DEFINIERT IN
-============
-
- /std/player/life.c
-
-
-ARGUMENTE
-=========
-
- victim
- Getoeteter Spieler.
- killer
- Objekt, welches den Spieler getoetet hat.
- lost_exp
- Erfahrungspunkte, die der Spieler durch den Tod verloren hat.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird aus dem Spielerobjekt heraus immer dann
- aufgerufen, wenn der Spieler stirbt und zwar:
- 1) im Gegner, der den Spieler getoetet hat,
- 2) im Environment des getoeteten Spielers,
- 3) in der Gilde des Spielers,
- 4) in allen Objekten in diesem Environment und
- 5) in allen Objekten (auch innerhalb Containern) im Spieler.
- Der Gegner wird hierbei nur einmal informiert, also bei letzteren
- Faellen herausgefiltert, falls noetig!
- Hauptaufgabe dieser Funktion ist es somit, auf Tode von Spielern zu
- reagieren oder selbige einfach nur mitzuloggen.
-
- Zu dem Zeitpunkt des Aufrufs dieser Funktion ist der Spieler noch _nicht_
- Geist und noch _nicht_ im Todesraum - dies wird im Anschluss an den Aufruf
- der NotifyPlayerDeath() durchgefuehrt.
-
-
-
- Aufgerufen wird die Funktion aus '/std/player/life.c' mittels catch() und
- werden mit limited() auf max. 150k (Gegner, Environment, Gilde) bzw. 80k
- (alle anderen Objekte) Ticks beschraenkt.
- Fehler in dieser Funktion haben somit keine negativen Auswirkungen
- auf das Sterben des Spielers.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- Folgendes Beispiel demonstriert beispielsweise, wie man Tode von
- Spielern mitloggen kann (das Beispiel ist hierbei auf den am
- haeufigsten auftretenden Fall bezogen, dass nur das toetende Objekt
- den Tod protokollieren soll):
-
- void NotifyPlayerDeath(object dead, object killer, int lost_exp)
- {
- if ( intp(lost_exp) && objectp(dead) && objectp(killer) &&
- killer==this_object() )
- write_file( "/log/patryn/dead", sprintf(
- "%s - %s von %s getoetet. XP: -%d", ctime(), getuid(dead),
- killer->name(WEM), lost_exp) );
- }
-
- Bitte beachten: write_file() schreibt ohne Groessenbegrenzung in das
- Logfile. Da dies auf Dauer bzw. in Gebieten mit hoher Log-Aktivitaet
- zu Logfiles von enormer Groesse fuehren kann, ist die Verwendung
- von write_file() nicht empfehlenswert. Ausnahmen koennen natuerlich
- mit dem zustaendigen Regionsmagier abgesprochen werden, z.B. fuer
- begrenzte Anwendung etwa bei sehr starken, selten besiegten Gegnern.
-
- Weiterhin ist es empfehlenswert, das toetende Objekt (killer) nicht
- im NotifyPlayerDeath() zu zestoeren, sondern etwas zeitversetzt,
- damit nicht etwa im nachfolgenden NotifyPlayerDeath() eines anderen
- Objektes (s.o. Reihenfolge) killer==0 ist.
-
-
-SIEHE AUCH
-==========
-
- Defend(), do_damage(), NotifyHpChange(), catch(), write_file(), log_file()
- P_LAST_DEATH_PROPS
-
-24.03.2012, Zesstra
diff --git a/doc/sphinx/man/lfun/NotifyRemove b/doc/sphinx/man/lfun/NotifyRemove
deleted file mode 100644
index 2604b77..0000000
--- a/doc/sphinx/man/lfun/NotifyRemove
+++ /dev/null
@@ -1,45 +0,0 @@
-
-NotifyRemove()
-**************
-
-
-FUNKTION
-========
-
- void NotifyRemove(object ob);
-
-
-ARGUMENTE
-=========
-
- ob
- Das Objekt, das aus dem Behaelter entfernt wurde.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird im Behaelter aufgerufen, wenn ein Objekt im
- besagten Behaelter zerstoert wird.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Wird nicht gerufen, wenn ein Spielerobjekt zerstoert wird.
-
-
-SIEHE AUCH
-==========
-
- NotifyLeave(), NotifyInsert(), PreventInsert(), PreventLeave(), move(),
- NotifyMove(), PreventMove(),
- BecomesNetDead()
-
-Last modified: 04.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/NotifyTimedAttrModExpired b/doc/sphinx/man/lfun/NotifyTimedAttrModExpired
deleted file mode 100644
index 09dc168..0000000
--- a/doc/sphinx/man/lfun/NotifyTimedAttrModExpired
+++ /dev/null
@@ -1,38 +0,0 @@
-
-NotifyTimedAttrModExpired()
-***************************
-
-
-FUNKTION
-========
-
- void NotifyTimedAttrModExpired(string key)
-
-
-DEFINIERT IN
-============
-
- Push-Methode in notify-Objekten.
-
-
-ARGUMENTE
-=========
-
- string key - der geloeschte Modifier
-
-
-BESCHREIBUNG
-============
-
- Wird aus dem Lebewesen aus aufgerufen, in dem der entsprechenden
- Modifier soeben ungueltig geworden ist.
-
-
-SIEHE AUCH
-==========
-
- Properties: P_ATTRIBUTES, P_TIMED_ATTR_MOD
- Methoden: SetTimedAttrModifier(L), DeleteTimedAttrModifier(L),
- QueryTimedAttrModifier(L)
-
-27. Juli 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/NotifyXMAttrModLimitViolation b/doc/sphinx/man/lfun/NotifyXMAttrModLimitViolation
deleted file mode 100644
index f3c54a4..0000000
--- a/doc/sphinx/man/lfun/NotifyXMAttrModLimitViolation
+++ /dev/null
@@ -1,35 +0,0 @@
-
-NotifyXMAttrModLimitViolation()
-*******************************
-
-
-FUNKTION
-========
-
- void NotifyXMAttrModLimitViolation()
-
-
-DEFINIERT IN
-============
-
- /std/thing/restrictions.c
-
-
-BESCHREIBUNG
-============
-
- Wird gerufen wenn die Summe der in P_X_ATTR_MOD oder P_X_ATTR_MOD
- angegebenen Modifikatoren die Summe aller Modifikatoren im Spieler
- ueber den zugelassenen Grenzwert hebt und somit nicht mehr in die
- Berechnung eingeht.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-13.Jun.2004, Muadib
diff --git a/doc/sphinx/man/lfun/Pacify b/doc/sphinx/man/lfun/Pacify
deleted file mode 100644
index feca7bf..0000000
--- a/doc/sphinx/man/lfun/Pacify
+++ /dev/null
@@ -1,146 +0,0 @@
-
-Pacify()
-********
-
-
-FUNKTION
-========
-
- public int Pacify(object caster)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion versucht, ein Lebewesen zu befrieden.
- Will eine Gilde ein Lebewesen befrieden, muss sie hierfuer diese Funktion
- in dem Lebewesen aufrufen.
-
- Ein immer befriedbarer NPC kann durch das Setzen von P_ACCEPT_PEACE in einem
- Lebewesen realisiert werden.
-
- Standardmaessig funktioniert die Funktion wie folgt:
- * Kommt der Versuch vom Spellcaster selbst, ist er immer erfolgreich.
- * Kommt der Versuch von einem Teamkollegen, ist er immer erfolgreich.
- * Hat das Lebewesen keine Gegner, ist der Versuch immer erfolglos.
- In diesen Faellen erfolgt auch keine Erhoehung des Befriedezaehlers.
-
-
-
- In anderen Faellen wird die in P_PEACE_HISTORY fuer die Gilde des Casters
- abgelegte Zahl erfolgreicher Befriedungen (ANZ), die Intelligenz des
- Casters (INT_CASTER) und die Intelligenz des Lebenwesens selber (INT_ME)
- ermittelt.
- Anschliessend wird eine Wahrscheinlichkeit w ausgerechnet:
-
-
-
- w = (INT_CASTER + 10 - ANZ*4) / (INT_ME + 10)
-
-
-
- Hierbei gibt w die Chance auf eine erfolgreiche Befriedung an. Mittels einer
- Zufallszahl wird bestimmt, ob der aktuelle Versuch erfolgreich ist. Falls
- ja, wird der Zaehler fuer die Gilde des Casters in P_PEACE_HISTORY erhoeht.
-
- Je oefter ein Lebewesen als von einer Gilde schon befriedet wurde, desto
- unwahrscheinlicher, dass es erneut darauf 'hereinfaellt'.
-
-
-BEMERKUNGEN
-===========
-
- * Die Funktion kann auch ueberschrieben werden, um ein vom Magier
- gewuenschtes Verhalten zu realisieren. Ein komplettes Abhaengen von
- Befriedungen sollte dabei aber die Ausnahme sein!
- * Diese Funktion verwaltet auch das P_PEACE_HISTORY, speziell die Reduktion
- der Erfolgszaehler. Ueberschreibt man sie ohne das geerbte Pacify()
- zu nutzen, wird P_PEACE_HISTORY nicht mehr verwaltet.
-
-
-RUECKGABEWERTE
-==============
-
- 1 - das Lebewesen wurde erfolgreich befriedet..
- 0 - der Befriedeversuch ist gescheitert.
-
-
-BEISPIELE
-=========
-
- Angenommen, der Caster hat eine Intelligenz von 22. Die folgende Tabelle
- gibt dann die Wahrscheinlichkeiten fuer eine erfolgreiche Befriedung an:
- (in Abhaengigkeit von eigener Intelligenz und vergangener erfolgreicher
- Versuche)
- INT_ME Erfolgswahrscheinlichkeiten je nach Anzahl erfolgreicher Versuche
- 1 2 3 4 5 6 7 8
- 0 280 240 200 160 120 80 40 0
- 2 233,33 200 166,67 133,33 100 66,67 33,33 0
- 4 200 171,43 142,86 114,29 85,71 57,14 28,57 0
- 6 175 150 125 100 75 50 25 0
- 8 155,56 133,33 111,11 88,89 66,67 44,44 22,22 0
- 10 140 120 100 80 60 40 20 0
- 12 127,27 109,09 90,91 72,73 54,55 36,36 18,18 0
- 14 116,67 100 83,33 66,67 50 33,33 16,67 0
- 16 107,69 92,31 76,92 61,54 46,15 30,77 15,38 0
- 18 100 85,71 71,43 57,14 42,86 28,57 14,29 0
- 20 93,33 80 66,67 53,33 40 26,67 13,33 0
- 22 87,5 75 62,5 50 37,5 25 12,5 0
- 24 82,35 70,59 58,82 47,06 35,29 23,53 11,76 0
- 26 77,78 66,67 55,56 44,44 33,33 22,22 11,11 0
- 28 73,68 63,16 52,63 42,11 31,58 21,05 10,53 0
- 30 70 60 50 40 30 20 10 0
- 32 66,67 57,14 47,62 38,1 28,57 19,05 9,52 0
- 34 63,64 54,55 45,45 36,36 27,27 18,18 9,09 0
- 35 62,22 53,33 44,44 35,56 26,67 17,78 8,89 0
- 36 60,87 52,17 43,48 34,78 26,09 17,39 8,7 0
- 38 58,33 50 41,67 33,33 25 16,67 8,33 0
- 40 56 48 40 32 24 16 8 0
- 42 53,85 46,15 38,46 30,77 23,08 15,38 7,69 0
- 44 51,85 44,44 37,04 29,63 22,22 14,81 7,41 0
- 46 50 42,86 35,71 28,57 21,43 14,29 7,14 0
- 48 48,28 41,38 34,48 27,59 20,69 13,79 6,9 0
- 50 46,67 40 33,33 26,67 20 13,33 6,67 0
- 52 45,16 38,71 32,26 25,81 19,35 12,9 6,45 0
- 54 43,75 37,5 31,25 25 18,75 12,5 6,25 0
- 56 42,42 36,36 30,3 24,24 18,18 12,12 6,06 0
- 58 41,18 35,29 29,41 23,53 17,65 11,76 5,88 0
- 60 40 34,29 28,57 22,86 17,14 11,43 5,71 0
- 62 38,89 33,33 27,78 22,22 16,67 11,11 5,56 0
- 64 37,84 32,43 27,03 21,62 16,22 10,81 5,41 0
- 66 36,84 31,58 26,32 21,05 15,79 10,53 5,26 0
- 68 35,9 30,77 25,64 20,51 15,38 10,26 5,13 0
- 70 35 30 25 20 15 10 5 0
- 72 34,15 29,27 24,39 19,51 14,63 9,76 4,88 0
- 74 33,33 28,57 23,81 19,05 14,29 9,52 4,76 0
- 76 32,56 27,91 23,26 18,6 13,95 9,3 4,65 0
- 78 31,82 27,27 22,73 18,18 13,64 9,09 4,55 0
- 80 31,11 26,67 22,22 17,78 13,33 8,89 4,44 0
- 82 30,43 26,09 21,74 17,39 13,04 8,7 4,35 0
- 84 29,79 25,53 21,28 17,02 12,77 8,51 4,26 0
- 86 29,17 25 20,83 16,67 12,5 8,33 4,17 0
- 88 28,57 24,49 20,41 16,33 12,24 8,16 4,08 0
- 90 28 24 20 16 12 8 4 0
- 92 27,45 23,53 19,61 15,69 11,76 7,84 3,92 0
- 94 26,92 23,08 19,23 15,38 11,54 7,69 3,85 0
- 96 26,42 22,64 18,87 15,09 11,32 7,55 3,77 0
- 98 25,93 22,22 18,52 14,81 11,11 7,41 3,7 0
- 100 25,45 21,82 18,18 14,55 10,91 7,27 3,64 0
-
-
-SIEHE AUCH
-==========
-
- P_ACCEPT_PEACE, P_PEACE_HISTORY
-
-
-LETZTE AENDERUNG
-================
-
-07.06.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/PayIn b/doc/sphinx/man/lfun/PayIn
deleted file mode 100644
index 35616de..0000000
--- a/doc/sphinx/man/lfun/PayIn
+++ /dev/null
@@ -1,73 +0,0 @@
-
-PayIn()
-*******
-
-
-FUNKTION
-========
-
- varargs void PayIn(int amount, int percent);
-
-
-DEFINIERT IN
-============
-
- /p/daemon/zentralbank.c
-
-
-ARGUMENTE
-=========
-
- int amount - einzuzahlender Betrag
- int percent - Bewertungsprozentsatz
-
-
-BESCHREIBUNG
-============
-
- Es wird Brutto amount Geld in die Bank eingezahlt. Der Prozentsatz legt
- fest, wieviel tatsaechlich gutgeschrieben wird:
- Gutschrift = amount*percent/100
-
- Wird percent nicht angegeben, dann wird der derzeitige Bankbewertungs-
- massstab fuer Geld angenommen.
-
-
-BEISPIELE
-=========
-
- #include <bank.h>
- ...
- AddCmd("spende",#'action_spende,
- "Was willst du spenden?");
- ...
- int action_spende(string str, extra *o) {
- int i;
- if(sscanf("%d muenze",i)==1 && i>0)
- if(this_player()->QueryMoney(i) && this_player()->AddMoney(-i)) {
- write("Du spendest "+i+" Muenzen.\n");
- say(this_player()->Name(WER)+" spendet "+i+" Muenzen.\n");
- ZENTRALBANK->PayIn(i);
-
-
-
- } else
- write("Soviel hast du nicht dabei!\n");
- ...
-
-
-BEMERKUNGEN
-===========
-
- Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
- an anderen Stellen Geld erzeugt wird.
-
-
-SIEHE AUCH
-==========
-
- Geldhandling: AddMoney(L), QueryMoney(L)
- Zentralbank: WithDraw(L), _query_current_money(L)
- Sonstiges: /items/money.c, /sys/bank.h
-
-27. Apr 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/PlayerQuit b/doc/sphinx/man/lfun/PlayerQuit
deleted file mode 100644
index 0eb8fbf..0000000
--- a/doc/sphinx/man/lfun/PlayerQuit
+++ /dev/null
@@ -1,37 +0,0 @@
-
-PlayerQuit()
-************
-
-
-FUNKTION
-========
-
- void PlayerQuit(object pl);
-
-
-GERUFEN VON
-===========
-
- /std/player/base.c
-
-
-ARGUMENTE
-=========
-
- object pl
- Spieler, der Verbindung beendet
-
-
-BESCHREIBUNG
-============
-
- Wird im environment() gerufen, wenn der Spieler das MUD mit "ende"
- verlaesst.
-
-
-SIEHE AUCH
-==========
-
- BecomesNetAlive(), BecomesNetDead()
-
-24. Aug 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/PresentEnemies b/doc/sphinx/man/lfun/PresentEnemies
deleted file mode 100644
index 12ac650..0000000
--- a/doc/sphinx/man/lfun/PresentEnemies
+++ /dev/null
@@ -1,95 +0,0 @@
-
-PresentEnemies()
-****************
-
-
-FUNKTION
-========
-
- object *PresentEnemies();
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUeCKGABEWERT
-=============
-
- anwesende Feinde
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert genau die Feinde zurueck, die sich derzeit im
- selben Raum befinden. Die Feinde unterliegen hierbei noch gewissen
- Einschraenkungen:
- (1) Sie duerfen als NPC nicht gestorben sein, das heisst, sie
- muessen als Objekt noch existieren.
- (2) Sie duerfen als Spieler nicht gestorben sein, das heisst, sie
- duerfen keine Geister sein (Property P_GHOST nicht gesetzt).
- (3) Sie muessen angreifbar sein, das heisst, die Property
- P_NO_ATTACK darf nicht gesetzt sein.
- Wird eine dieser Bedingungen verletzt, so wird der Gegner aus der
- internen Gegnerliste entfernt. Zusaetzlich gilt:
- Netztote werden nur als Gegner erkannt, wenn keine anderen Gegner
- zur Verfuegung stehen.
-
-
-BEISPIEL
-========
-
- Im Folgenden erblinden alle Gegner im Raum:
- string blindThemAll()
- { ob*livList;
- if(!livList=PresentEnemies())
- return break_string(
- "Mist...keiner da, der blind werden moechte.",77,
- Name(WER)+" grummelt: ");
- for(i=sizeof(livList);i--;)
- { if(livList[i]->QueryProp(P_BLIND))
- { tell_object(this_object(),break_string(
- livList[i]->Name(WER)+" ist schon blind.",77));
- continue;
- }
- tell_object(this_object(),break_string(
- "Du kratzt "+livList[i]->name(WEM)+" die Augen aus.",77));
- tell_object(livList[i],break_string(
- Name(WER)+" kratzt Dir die Augen aus!",77));
- tell_room(environment(this_object()),break_string(
- Name(WER)+" kratzt "+livList[i]->name(WEM)
- +" die Augen aus.",77),({this_object(),livList[i]}));
- livList[i]->SetProp(P_BLIND,1);
- }
- return"";
- }
- Aufgerufen wird das ganze am Besten in einem Chat:
- void create()
- { ::create();
- ...
- SetProp(P_CHAT_CHANCE,10);
- SetChats(20,({break_string(
- "Nicht angreifen, sonst wirst Du noch blind!",77,
- Name(WER)+" bruellt: "),
- "@@blindThemAll@@"}));
- }
- Natuerlich sind auch noch mehr Funktionen und Meldungen als Chats
- moeglich: Die zwei im Beispiel sind im Normalfall etwas wenig.
-
-
-SIEHE AUCH
-==========
-
- SelectEnemy(), QueryEnemies(), IsEnemy(), P_GHOST, P_NO_ATTACK,
- SetChats, P_CHAT_CHANCE
-
-Last modified: Thu May 27 15:01:48 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/PresentEnemyRows b/doc/sphinx/man/lfun/PresentEnemyRows
deleted file mode 100644
index 003d6c3..0000000
--- a/doc/sphinx/man/lfun/PresentEnemyRows
+++ /dev/null
@@ -1,60 +0,0 @@
-
-PresentEnemyRows()
-******************
-
-
-FUNKTION
-========
-
- varargs mixed *PresentEnemyRows(object *here)
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- Rueckgabewert von PresentEnemies kann uebergeben werden.
-
-
-BESCHREIBUNG
-============
-
- Ergibt die feindlichen Reihen.
-
-
-RUECKGABEWERT
-=============
-
- Ein Array, bestehend aus MAX_TEAMROWS Arrays mit den Objekten
- der anwesenden Feinde.
-
-
-BEMERKUNGEN
-===========
-
- Jede Reihe ist Summe der entsprechenden Reihen der
- anwesenden Teams.
- Feinde, die in keinem Team sind, stehen im ersten Array.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentTeamPosition,
- SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/PresentPosition b/doc/sphinx/man/lfun/PresentPosition
deleted file mode 100644
index c94d129..0000000
--- a/doc/sphinx/man/lfun/PresentPosition
+++ /dev/null
@@ -1,58 +0,0 @@
-
-PresentPosition()
-*****************
-
-
-FUNKTION
-========
-
- varargs int PresentPosition(mixed pmap)
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- Rueckgabewert von PresentTeamRows() oder PresentTeamPositions()
- kann uebergeben werden.
-
-
-BESCHREIBUNG
-============
-
- Ergibt die Nummer der Reihe, in der der Spieler gerade steht.
-
-
-RUECKGABEWERT
-=============
-
- Reihennummer im Bereich von 1 bis TEAM_MAXROWS.
-
-
-BEMERKUNGEN
-===========
-
- Ist ein Spieler in keinem Team, so steht er automatisch in Reihe 1.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentRows, PresentEnemyRows, PresentTeamPosition,
- SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/PresentRows b/doc/sphinx/man/lfun/PresentRows
deleted file mode 100644
index 37e3ab8..0000000
--- a/doc/sphinx/man/lfun/PresentRows
+++ /dev/null
@@ -1,120 +0,0 @@
-
-PresentRows()
-*************
-
-
-FUNKTION
-========
-
- mixed *PresentRows(object env);
-
-
-DEFINIERT IN
-============
-
- TEAM_OBJECT (s. <living/team.h>)
-
-
-ARGUMENTE
-=========
-
- object env
- Das Environment des gewuenschten Objektes.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion bekommt man die aktuellen Teamreihen, die im Argument
- env anwesend sind, des Teams zurueckgegeben. Ist env kein Objekt, so
- wird environment(this_player()) als solches angenommen.
-
-
-RUECKGABEWERT
-=============
-
- Es wird ein mixed-Array zurueckgegeben, dabei sind die einzelnen Reihen
- selbst wiederum Arrays mit den Spielerobjekten.
-
-
-BEISPIEL
-========
-
- Ein NPC im Kampf laesst eine Feuerwalze auf ein Team los, welche aber nur
- Spieler in der ersten und zweiten Teamreihe Schaden zufuegen soll.
-
- void Attack( object enemy )
- {
- ...
-
- object team = enemy->QueryProp(P_TEAM);
-
- if ( objectp(team) )
- {
- mixed teamrows = team->PresentRows(enemy);
-
-// Inhalt von "teamrows" zu diesem Zeitpunkt:
-
-// ({ ({[/dwarf:hauweg]}),({}),({[/elf:spitzohr]}),({}),({}),({}) })
-
-// In der Umgebung von Zwerg Hauweg steht also noch Elf Spitzohr, und
-zwar // in der dritten Teamreihe (der hat Glueck gehabt). // Wenn
-dem Team noch mehr Spieler angehoeren, befinden sie sich gerade //
-nicht in der Umgebung (sprich im selben Raum) wie Hauweg.
-
- foreach ( i : 2 )
- {
- foreach ( object pl : teamrows[i] )
- {
- tell_object(pl,"Der Feuerteufel laesst eine
- Feuerwalze auf Dich "
- "und Dein Team los.n");
-
- pl->Defend(200+random(200),({DT_FIRE}),([SP_S
- HOW_DAMAGE:1]),TO);
-
- }
-
- }
-
- }
-
- else
- {
- tell_object(enemy,"Der Feuerteufel laesst eine Feuerwalze
- auf Dich "
- "los.n");
-
- enemy->Defend(200+random(200),({DT_FIRE}),([SP_SHOW_DAMAG
- E:1]),TO);
-
- }
-
- ...
-
- }
-
-
-BEMERKUNG
-=========
-
- Man beachte, dass das erste Argument (also Argument 0) die erste
- Teamreihe ist.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentEnemyRows, PresentTeamPosition,
- SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/PresentTeamPositions b/doc/sphinx/man/lfun/PresentTeamPositions
deleted file mode 100644
index 3af354b..0000000
--- a/doc/sphinx/man/lfun/PresentTeamPositions
+++ /dev/null
@@ -1,60 +0,0 @@
-
-PresentTeamPositions()
-**********************
-
-
-FUNKTION
-========
-
- varargs mapping PresentTeamPositions(mixed pmap)
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- Rueckgabewert von PresentTeamRows() kann uebergeben werden.
-
-
-BESCHREIBUNG
-============
-
- Ermittelt die Reihennummern aller anwesender Teammitglieder.
-
-
-RUECKGABEWERT
-=============
-
- Ein Mapping mit den Reihennummern (von 1 bis MAX_TEAMROWS)
- der anwesenden Teammitglieder.
-
-
-BEMERKUNGEN
-===========
-
- Kann auch zur Konvertierung anderer Kampfreihen-Arrays in
- ein Positions-Mapping verwendet werden.
- Ist der Spieler in keinem Team, so steht er in Reihe 1.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/PresentTeamRows b/doc/sphinx/man/lfun/PresentTeamRows
deleted file mode 100644
index 7875918..0000000
--- a/doc/sphinx/man/lfun/PresentTeamRows
+++ /dev/null
@@ -1,47 +0,0 @@
-
-PresentTeamRows()
-*****************
-
-
-FUNKTION
-========
-
- mixed *PresentTeamRows()
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Ergibt die Reihen mit den anwesenden Teammitgliedern.
-
-
-RUECKGABEWERT
-=============
-
- Ein Array bestehend aus MAX_TEAMROWS Arrays mit den Objekten
- der anwesenden Teammitglieder.
-
-
-BEMERKUNGEN
-===========
-
- Wenn der Spieler in keinem Team ist, enthaelt das erste Array
- nur den Spieler und die anderen Arrays sind leer.
-
-
-SIEHE AUCH
-==========
-
- teams
diff --git a/doc/sphinx/man/lfun/PreventFollow b/doc/sphinx/man/lfun/PreventFollow
deleted file mode 100644
index c3de6b1..0000000
--- a/doc/sphinx/man/lfun/PreventFollow
+++ /dev/null
@@ -1,72 +0,0 @@
-
-PreventFollow()
-***************
-
-
-FUNKTION
-========
-
- int PreventFollow(object dest)
-
-
-ARGUMENTE
-=========
-
- dest: Zielobjekt, in das der Verfolgte bewegt werden soll.
-
-
-FUNKTION
-========
-
- In jedem Verfolger, der mit AddPursuer in die Liste der Verfolger
- eingetragen wurde, wird vor dem Bewegen in das Zielobjekt die Funktion
- PreventFollow mit dem Zielobjekt als Argument aufgerufen.
-
-
-RUECKGABEWERT
-=============
-
- 0: Verfolger darf in das Zielobjekt folgen
- 1: Verfolger darf in dieses Zielobjekt nicht folgen
- (Verfolgung bleibt weiterhin aktiv)
- 2: Verfolger darf in dieses Zielobjekt nicht folgen
- (Verfolgung wird abgebrochen und Verfolger aus der Verfolgerliste
- ausgetragen)
-
-
-BEMERKUNG
-=========
-
- Durch PreventFollow kann der raeumliche Bereich, in dem verfolgt werden
- darf, eingeschraenkt werden.
-
-
-BEISPIELE
-=========
-
- Man moechte, dass ein NPC auf einer Insel nicht mit dem Spieler in das
- Boot steigt, um mit dem Spieler zusammen von der Insel herunterzukommen.
-
- #define PATH(x) ("/d/.../.../mein/pfad/+(x)")
-
- ...
-
- int PreventFollow(object boot)
- {
- if ( object_name(boot)[0..strlen(PATH("boot"))-1] == PATH("boot") )
- return 1;
- }
-
- Diese Funktions-Definition ist sehr flexibel, denn sie erlaubt sowohl
- spaetere Pfadanpassung als auch mehrere Boote.
- Da ueber die Funktion strlen() nur bis zum letzten Buchstaben des
- angegebenen Strings getestet wird, wird also gleichzeitig auch auf
- boot[1], boot[2] usw. getestet.
-
-
-SIEHE AUCH
-==========
-
- "AddPursuer", "RemovePursuer"
-
-Last modified: Tue Jun 10 13:59:30 2003 by Gabylon
diff --git a/doc/sphinx/man/lfun/PreventInsert b/doc/sphinx/man/lfun/PreventInsert
deleted file mode 100644
index 3635142..0000000
--- a/doc/sphinx/man/lfun/PreventInsert
+++ /dev/null
@@ -1,71 +0,0 @@
-
-PreventInsert()
-***************
-
-
-FUNKTION
-========
-
- int PreventInsert(object ob);
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- ob
- Das Objekt, das in den Behaelter eingefuegt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann ein Behaelter pruefen, ob er das Objekt ob
- aufnehmen moechte oder nicht.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn das Objekt aufgenommen werden kann; ein Wert groesser als 0
- zeigt an, dass das Objekt nicht aufgenommen werden soll.
-
-
-BEMERKUNGEN
-===========
-
- Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsert() zwar
- aufgerufen, das Objekt wird jedoch auf jeden Fall in den Behaelter
- bewegt, unabhaengig vom Rueckgabewert!
-
-
-BEISPIELE
-=========
-
- Um zu verhindern, dass man Geld in einen Behaelter stecken kann, sollte
- man wie folgt vorgehen:
-
- varargs int PreventInsert(object ob)
- {
- // Wenn es Geld ist, erheben wir sofort Einspruch
- if (ob->id("geld"))
- return 1;
- // Ansonsten koennte ein ererbtes Objekt noch Einspruch erheben!
- else
- return ::PreventInsert(ob);
- }
-
-
-SIEHE AUCH
-==========
-
- PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
- PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
- PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
-
-Last modified: Sat Dec 18 02:00:00 1999 by Tiamak
diff --git a/doc/sphinx/man/lfun/PreventInsertLiving b/doc/sphinx/man/lfun/PreventInsertLiving
deleted file mode 100644
index fbde29f..0000000
--- a/doc/sphinx/man/lfun/PreventInsertLiving
+++ /dev/null
@@ -1,56 +0,0 @@
-
-PreventInsertLiving()
-*********************
-
-
-FUNKTION
-========
-
- int PreventInsertLiving(object ob);
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- ob
- Das Living, das in den Behaelter eingefuegt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann ein Behaelter pruefen, ob er das Living ob
- aufnehmen moechte oder nicht.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn das Living aufgenommen werden kann; ein Wert groesser als 0
- zeigt an, dass das Living nicht aufgenommen werden soll.
-
-
-BEMERKUNGEN
-===========
-
- Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventInsertLiving()
- zwar aufgerufen, das Living wird jedoch auf jeden Fall in den Behaelter
- bewegt, unabhaengig vom Rueckgabewert!
-
-
-SIEHE AUCH
-==========
-
- PreventLeaveLiving(), /std/container/restrictions.c,
- PreventMove(), PreventInsert(), PreventLeave(),
- NotifyMove(), NotifyInsert(), NotifyLeave(), NotifyRemove(),
- move(), init(), exit(),
- InitAttack(), ExitAttack()
-
-Last modified: 04.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/PreventLeave b/doc/sphinx/man/lfun/PreventLeave
deleted file mode 100644
index 24c33d2..0000000
--- a/doc/sphinx/man/lfun/PreventLeave
+++ /dev/null
@@ -1,57 +0,0 @@
-
-PreventLeave()
-**************
-
-
-FUNKTION
-========
-
- int PreventLeave(object ob, mixed dest);
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- ob
- Das Objekt, das aus dem Behaelter genommen werden soll.
- dest
- Das Ziel in das das Objekt ob bewegt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann ein Behaelter pruefen, ob er das Objekt ob
- sich bewegen lassen moechte oder nicht.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn das Objekt bewegt werden kann; ein Wert groesser als 0
- zeigt an, dass das Objekt nicht bewegt werden soll.
-
-
-BEMERKUNGEN
-===========
-
- Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventLeave() zwar
- aufgerufen, das Objekt wird jedoch auf jeden Fall aus dem Behaelter
- bewegt, unabhaengig vom Rueckgabewert!
-
-
-SIEHE AUCH
-==========
-
- PreventInsert(), NotifyInsert(), NotifyLeave(),
- MayAddWeight(), move(), /std/container/restrictions.c
- PreventLeaveLiving(), PreventInsertLiving(), PreventMove(),
- NotifyMove(), MayAddObject(), NotifyRemove()
-
-Last modified: 04.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/PreventLeaveLiving b/doc/sphinx/man/lfun/PreventLeaveLiving
deleted file mode 100644
index 20a5844..0000000
--- a/doc/sphinx/man/lfun/PreventLeaveLiving
+++ /dev/null
@@ -1,58 +0,0 @@
-
-PreventLeaveLiving()
-********************
-
-
-FUNKTION
-========
-
- int PreventLeaveLiving(object ob, mixed dest);
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- ob
- Das Living, das aus dem Behaelter genommen werden soll.
- dest
- Das Ziel in das das Living ob bewegt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann ein Behaelter pruefen, ob er das Living ob
- sich bewegen lassen moechte oder nicht.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn das Living bewegt werden kann; ein Wert groesser als 0
- zeigt an, dass das Living nicht bewegt werden soll.
-
-
-BEMERKUNGEN
-===========
-
- Wenn ob mit dem Flag M_NOCHECK bewegt wird, wird PreventLeave() zwar
- aufgerufen, das Living wird jedoch auf jeden Fall aus dem Behaelter
- bewegt, unabhaengig vom Rueckgabewert!
-
-
-SIEHE AUCH
-==========
-
- PreventInsertLiving(), /std/container/restrictions.c
- PreventMove(), PreventLeave(), PreventInsert(),
- NotifyMove(), NotifyLeave(), NotifyInsert(), NotifyRemove(),
- move(), exit(), init(),
- InitAttack, ExitAttack()
-
-Last modified: 04.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/PreventMove b/doc/sphinx/man/lfun/PreventMove
deleted file mode 100644
index 920372d..0000000
--- a/doc/sphinx/man/lfun/PreventMove
+++ /dev/null
@@ -1,109 +0,0 @@
-
-PreventMove()
-*************
-
-
-PreventInsert()
-===============
-
-
-FUNKTION
-========
-
- protected int PreventMove(object dest, object oldenv, int method);
-
-
-DEFINIERT IN
-============
-
- /std/thing/moving.c
- /std/living/moving.c
- /std/player/moving.c
-
-
-ARGUMENTE
-=========
-
- dest
- Das Ziel des Moves
- oldenv
- Das (Noch-)Environment des Objekts
- method
- Die Move-Methode(n), mit der/denen bewegt werden soll
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion prueft ein Objekt, ob es von 'oldenv' nach 'dest'
- bewegt werden mag. Dabei wird 'method' beruecksichtigt (z.B. schaltet
- M_NOCHECK die meisten Pruefungen ab).
- Bei Gegenstaenden wird z.B. P_NODROP, P_NOGET, das Gewicht, ob das Ziel
- das Objekt aufnehmen will (MayAddWeight(), PreventInsert) oder auch
- PreventLeave() geprueft.
- Bei Lebewesen wird z.B. P_NO_TPORT in 'dest' und 'oldenv' und
- PreventLeaveLiving/PreventInsertLiving() ausgewertet.
- Bei Spielern wird auch noch getestet, ob method M_GO oder M_TPORT
- enthaelt und ob das Ziel nur von Testspielern betreten werden kann.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn das Objekt bewegt werden darf.
- Wenn es nicht bewegt werden darf, sind als Rueckgabewerte die in
- /sys/moving.h definierten Move-Fehlerwerte zulaessig (s. move()). Sollte
- hier ein ungueltiger Fehlerwert zurueckgegeben werden, wird das move()
- ebenfalls abgebrochen und ME_DONT_WANT_TO_BE_MOVED zurueckgeben.
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion kann ueberschrieben, um feinere Kontrolle ueber die
- Bewegungen des Objekt zu haben. Dabei aber bitte einige Dinge beachten:
- 1. Denkt daran, ggf. M_NOCHECK zu beruecksichtigen und und eure
- Pruefungen nur zu machen, wenn es nicht in method vorkommt.
- 2. GANZ WICHTIG: Wenn ihr mit euren Pruefungen fertig sein und das Objekt
- bewegt werden duerfte, die geerbten Pruefungen noch testen, also _IMMER_
- das geerbte PreventMove() noch aufrufen und dessen Wert
- zurueckgeben/beruecksichtigen, da sonst Pruefungen des Gewichts etc.
- nicht funktionieren oder bei Lebewesen die Prevent*() im Environment
- nicht gerufen werden!
- 3. Die Funktion ist nur objektintern zu verwenden, Call-Other von aussen
- sind nicht moeglich, beim Ueberschreiben 'protected' nicht vergessen.
- 4. Nochmal: Geerbtes PreventMove() _NICHT VERGESSEN_!
-
-
-BEISPIELE
-=========
-
- Ein Objekt, was nur im Sternenlicht aufgenommen werden kann (warum
- auch immer):
-
- protected int PreventMove(object dest, object oldenv, int method) {
- if ( (method & M_NOCHECK) ) {
- // wenn mit M_NOCHECK bewegt, ist das Sternenlicht egal, nur
- // geerbtes PreventMove() beruecksichten:
- return ::PreventMove(dest, oldenv, method);
- }
- else if ( method & M_GET) {
- // wenn es aufgenommen werden soll: nach Sternenlicht im Raum
- // gucken:
- if (objectp(dest) &&
- (dest->QueryProp(P_LIGHT_TYPE) != LT_STARS))
- return ME_CANT_BE_TAKEN;
- }
- // Fall-through:
- return ::PreventMove(dest, oldenv, method);
- }
-
-
-SIEHE AUCH
-==========
-
- PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
- PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
- PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
-
-Last modified: 04.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/Query b/doc/sphinx/man/lfun/Query
deleted file mode 100644
index 27c2d9e..0000000
--- a/doc/sphinx/man/lfun/Query
+++ /dev/null
@@ -1,108 +0,0 @@
-
-Query()
-*******
-
-
-FUNKTION
-========
-
- public varargs mixed Query(string name, int Type);
-
-
-DEFINIERT IN
-============
-
- /std/thing/properties.c
-
-
-ARGUMENTE
-=========
-
- string name - Property, deren Wert(e) ausgelesen werden
- int type - Art der gewuenschten Information.
-
-
-BESCHREIBUNG
-============
-
- Der Wert einer der inneren Eigenschaften der Property 'name' wird
- zurueckgegeben. 'Type' ist dabei einer der in /sys/thing/properties.h
- und folgend aufgelisteten F_XXX-Werte:
-
- F_VALUE (==0, Default)
- Unter Umgehung einer eventuell vorhandenen Abfragemethode oder
- _query_'name'() wird der Datenwert der Property 'name'
- zurueckgegeben.
- F_MODE
- Die internen Flags der Property werden zurueckgegeben.Dies koennen
- (logisch mit & verknuepft) sein:
- SAVE - Property soll bei save_object() gespeichert werden
- PROTECTED - Objekt selbst/EM/Root kann Property manipulieren
- SECURED - wie PROTECTED, das Flag kann aber nicht
- zurueckgesetzt werden (immer SECURED)
- NOSETMETHOD - niemand kann Property manipulieren
- (auch kein F_SET_METHOD oder _set_'name'())
- F_SET_METHOD
- Ein eventuell fuer die Property eingetragene F_SET_METHOD wird
- zurueckgegeben.
- (_set_'name'()-Methoden werden so nicht aufgefuehrt!)
- F_QUERY_METHOD
- Ein eventuell fuer die Property eingetragene F_QUERY_METHOD wird
- zurueckgegeben.
- (_query_'name'()-Methoden werden so nicht aufgefuehrt!)
-
-
-RUeCKGABEWERT
-=============
-
- Die gewuenschte Eigenschaft, abhaengig von 'Type'.
-
-
-BEMERKUNGEN
-===========
-
- - Query() sollte nicht zum regulaeren Auslesen des Inhalt einer
- Property verwendet werden, da sowohl F_QUERY_METHOD als auch
- libinterne _query_'name'()-Methoden umgangen werden und das Ergebnis
- fuer so veraenderte Propertys undefiniert ist
- - _set_'name'() und _query_'name'() sind alte Propertymethoden und
- sollten nicht in normalen Objekten benutzt werden ->
- F_SET_METHOD/F_QUERY_METHOD (ggf. mit PROTECTED) nutzen
- - F_SET/F_QUERY_METHODs koennen 'protected' (empfohlen) oder 'static'
- sein. _set_/_query_ duerfen momentan _nicht_ 'protected' sein, fuer
- diese geht nur 'static' (in diesem Fall empfohlen).
-
-
-BEISPIELE
-=========
-
- // Auslesen des Wertes unter Umgehung einer Abfragemethode
- Query(P_XYZ, F_VALUE);
-
- // Auslesen der Flags erfaehrt man mit:
- Query(P_XYZ, F_MODE);
-
- // sauberes Programmieren, wir wollen eine F_QUERY_METHOD setzen,
- // pruefen vorher auf Existenz:
- if(this_player()->Query(P_FROG, F_QUERY_METHOD) {
- write(break_string(
- "Ich kann dich nicht weiter vor Froschsein schuetzen!",
- "Der Magier winkt ab: ", 78));
- say(break_string(
- "Ich kann dich nicht weiter vor Froschsein schuetzen!",
- "Der Magier sagt zu "+this_player()->name(WEM)+": ", 78));
- } else {
- this_player()->Set(P_FROG, #'query_protect_frog, F_QUERY_METHOD);
- ...
- }
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: SetProp(L), QueryProp(L), Set(L)
- Generell: SetProperties(L), QueryProperties(L)
- Konzept: properties, /std/thing/properties.c
- Sonstiges: P_AUTOLOADOBJ
-
-28.03.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/QueryAllDoors b/doc/sphinx/man/lfun/QueryAllDoors
deleted file mode 100644
index cdf7140..0000000
--- a/doc/sphinx/man/lfun/QueryAllDoors
+++ /dev/null
@@ -1,52 +0,0 @@
-
-QueryAllDoors()
-***************
-
-
-FUNKTION
-========
-
- mapping QueryAllDoors();
-
-
-DEFINIERT IN
-============
-
- /obj/doormaster.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Es werden die Zustaende ALLER Tueren im MorgenGrauen ermittelt.
-
-
-RUECKGABEWERT
-=============
-
- Ein Mapping mit den Zustaenden aller Tueren im MorgenGrauen. Als
- Schluessel dienen die Dateinamen der Start- und Zielraeume in
- lexikographischer (alphabetischer) Reihenfolge, getrennt durch ":",
- der Wert des Keys ist der aktuelle Zustand dieser Tuer, z.B.:
-
- ([ "/d/inseln/schiffe/jolle:/d/inseln/schiffe/jolle/masch" : -1,
- ...
- ]);
-
- Es gibt also eine Tuer zwischen Jolle und Maschinenraum, die
- momenten geschlossen ist (-1 = D_STATUS_CLOSED).
-
-
-SIEHE AUCH
-==========
-
- NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), P_DOOR_INFOS
-
-Letzte Aenderung: Don, 08.05.2014, Gabylon
diff --git a/doc/sphinx/man/lfun/QueryArmourByType b/doc/sphinx/man/lfun/QueryArmourByType
deleted file mode 100644
index 20fcab5..0000000
--- a/doc/sphinx/man/lfun/QueryArmourByType
+++ /dev/null
@@ -1,91 +0,0 @@
-
-QueryArmourByType()
-*******************
-
-
-QyeryArmourByType()
-===================
-
-
-FUNKTION
-========
-
- mixed QueryArmourByType(string type)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- string type
- Typ der Ruestung aus /sys/combat.h, auf die getestet werden soll.
-
-
-BESCHREIBUNG
-============
-
- Abfrage, ob das Lebewesen eine Ruestung des angegebenen Typs traegt.
-
- Zurueckgegeben wird je nach Tragestatus und <type>:
- * 0, falls das Lebewesen die gesuchte Ruestungsart nicht traegt
- * im Erfolgsfall das Ruestungsobjekt
- * falls <type> AT_MISC ist:
- * ({}), wenn es keine AT_MISC-Ruestung traegt
- * ein Array von AT_MISC-Ruestungen
- * falls <type> 0 ist: ein Mapping, das diese Informationen mit dem
- Ruestungstypen als Schluessel enthaelt:
- ([AT_MISC: ({[object], ...}),
- AT_...: <object>,
- ... ])
-
-
-BEMERKUNG
-=========
-
- Ist <type> AT_MISC, so wird auf jeden Fall ein Array zurueckgegeben!
-
-
-BEISPIELE
-=========
-
- Wir wollen wissen, ob this_player() Handschuhe traegt:
-
- if (objectp(this_player()->QueryArmourByType(AT_GLOVE)))
- ...
-
-
- Wir bauen einen Tuersteher, der auf AT_MISC-Kleidung achtet:
-
- if (sizeof(this_player()->QueryArmourByType(AT_MISC)) > 3) {
- if(this_player()->ReceiveMsg(
- "Du darfst nicht passieren, Du hast zuviele "
- "unpassende Dinge an!",
- MT_LISTEN|MSG_DONT_STORE, MA_TELL,
- "Der Waechter teilt Dir mit: ")<MSG_DELIVERED && // taub?
- this_player()->ReceiveMsg(
- "Der Waechter haelt dich auf.", MT_LOOK)<MSG_DELIVERED) // blind?
- this_player()->ReceiveMsg(
- "Jemand haelt dich auf.", MT_FEEL); // nu aber!
- // Aufhalten!
- } else this_player()->ReceiveMsg(
- "Du darfst passieren, viel Spass im Casino!",
- MT_LISTEN|MSG_DONT_STORE, MA_TELL,
- "Der Waechter teilt Dir mit: ");
- // im Erfolgsfall ist es uns egal, wenn es der Spieler nicht
- // liest: er wird dann eben "wortlos" durchgelassen
-
-
-SIEHE AUCH
-==========
-
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
- UnwearClothing(), FilterClothing(),
- P_ARMOUR_TYPE, P_CLOTHING, P_ARMOURS,
- /std/living/combat.c
-
-02.02.2016, Gloinson
diff --git a/doc/sphinx/man/lfun/QueryArrived b/doc/sphinx/man/lfun/QueryArrived
deleted file mode 100644
index 9c4de60..0000000
--- a/doc/sphinx/man/lfun/QueryArrived
+++ /dev/null
@@ -1,45 +0,0 @@
-
-QueryArrived()
-**************
-
-
-FUNKTION
-========
-
- mixed QueryArrived();
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ermittelt, ob sich der Transporter momentan an einer
- Haltestelle befindet (und bestiegen oder verlassen werden kann) oder ob
- er unterwegs ist.
-
-
-RUeCKGABEWERT
-=============
-
- Null, wenn der Transporter unterwegs ist. Liegt der Transporter an
- einer Haltestelle, so wird der mit AddRoute als name uebergebene String
- zurueckgegeben.
-
-
-SIEHE AUCH
-==========
-
- AddRoute(), /std/transport.c
-
-Last modified: Wed May 8 10:21:47 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryArticle b/doc/sphinx/man/lfun/QueryArticle
deleted file mode 100644
index 3be5ecc..0000000
--- a/doc/sphinx/man/lfun/QueryArticle
+++ /dev/null
@@ -1,118 +0,0 @@
-
-QueryArticle()
-**************
-
-
-FUNKTION
-========
-
- varargs string QueryArticle(int casus, int dem, int force);
-
-
-DEFINIERT IN
-============
-
- /std/thing/language.c
-
-
-ARGUMENTE
-=========
-
- casus
- Der Fall, in dem der Artikel gewuenscht wird.
- (Konstanten aus /sys/thing/language.h: WER, WEM, WESSEN, WEN.)
-
- dem
- Wird ein bestimmter oder ein unbestimmter Artikel verlangt?
- + dem = 0: Unbestimmter Artikel!
- + dem = 1: Bestimmter Artikel!
- + dem = 2: Finde selbst heraus, welcher Artikel passt!
-
- force
- Falls ungleich Null, so wird auf jeden Fall ein Artikel
- zurueckgegeben, trotz P_ARTICLE == 0.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt einen zum Geschlecht des Objektes passenden Artikel
- zurueck, der in den passenden Fall dekliniert wird.
-
- Das Herausfinden des passenden Artikels bei 'dem' = 2 bezieht sich auf
- Situationen, in denen mehrere gleichnamige Objekte im selben Environment
- sind. Man 'nimmt' dann zB nicht "den Stamm" sondern "einen Stamm".
-
- Ist P_ARTICLE = 0, so wird ein Leerstring zurueckgegeben, es sei denn,
- man uebergibt in dem Argument 'force' einen Wert ungleich Null.
-
-
-BEMERKUNGEN
-===========
-
- Achtung: bei gueltigem Artikel wird ein Leerzeichen angehaengt!
-
- Name()/name() nutzen bereits QueryArticle(), wenn P_ARTICLE gesetzt
- ist. Deshalb muss man sich "Eines Orks" nicht selbst aus dem
- QueryArticle() und dem Namen zusammenbasteln, wenn mehrere Orks
- im Raum herumstehen und man eine Nachricht wie:
- "Du haust den Ork." und folgend
- "[Des|Eines] Orks Nase schwillt an."
- haben moechte:
- "Du haust "+ork->name(WEN, 1)+". "
- ork->Name(WESSEN, 2)+" Nase schwillt an."
-
-
-RUeCKGABEWERT
-=============
-
- * gewuenschter Artikel als String plus Leerzeichen (!) ODER
- * Leerstring
-
-
-BEISPIELE
-=========
-
- // "X haut Y auf die Nase. [Der|Die|Das] ist nicht beeindruckt."
- // Man will:
- // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
- // * nur den bestimmten Artikel
- send_room(this_object(),
- pl1->Name(WER)+" haut "+pl2->name(WEM)+" auf die Nase. "+
- capitalize(pl2->QueryArticle(WER, 1, 1))+"ist nicht beeindruckt.",
- MT_LOOK|MT_LISTEN, 0, 0, ({pl1, pl2}));
-
- // "X gibt dir Y. [Er|Sie|Es] prueft [den|die|das] ..."
- // Man will:
- // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
- // * nur den bestimmten Artikel
- send_room(this_object(),
- pl1->Name(WER)+" gibt "+pl2->name(WEM)+" "+obj->name(WER)+". "+
- capitalize(pl2->QueryPronoun(WER))+" prueft "+
- ob->QueryArticle(WEN, 1, 1)+"...",
- MT_LOOK|MT_LISTEN, 0, 0, ({pl1, pl2}));
-
- // "Dir faellt X auf den Kopf. Du siehst [die|den|das|eine|einen|eines "
- // "auf dem Boden liegen. [Sie|Er|Es] sieht blutig aus. Aua. Ist das "
- // "von dir?"
- // Man will:
- // * auf jeden Fall einen Artikel, auch wenn kein P_ARTICLE gesetzt ist
- // * bestimmte/unbestimmte Artikel, wenn bereits gleiche Gegenstaende
- // (zB Kokosnuesse) auf dem Boden liegen ...
- ob->move(environment(), M_NOCHECK); // vorher machen!
- pl->ReceiveMsg(
- "Dir faellt "+ob->name(WER, 0)+" auf den Kopf. Du siehst "+
- ob->QueryArticle(WEN, 2, 1)+" auf dem Boden liegen. "+
- capitalize(ob->QueryPronoun(WER))+" sieht blutig ...
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: SuggestArticle(), query_c_article(), query_g_suffix()
- Sonstiges: QueryOwn(), QueryDu(),
- QueryPronoun(), QueryPossPronoun()
- DeclAdj()
- name()
-
-9. Jun 2016, Gloinson
diff --git a/doc/sphinx/man/lfun/QueryAttribute b/doc/sphinx/man/lfun/QueryAttribute
deleted file mode 100644
index 978c6c0..0000000
--- a/doc/sphinx/man/lfun/QueryAttribute
+++ /dev/null
@@ -1,59 +0,0 @@
-
-QueryAttribute()
-****************
-
-
-FUNKTION
-========
-
- int QueryAttribute(string attr)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- attr - interessierendes Gesamtattribut
-
-
-BESCHREIBUNG
-============
-
- Das Attribut samt seiner Offsets (Modifier) wird zurueckgegeben.
-
-
-RUeCKGABEWERT
-=============
-
- Wert des Attributes, bei Spielern nicht groesser als 30.
-
-
-BEISPIELE
-=========
-
- if (this_player()->QueryAttribute(A_CON) > 20)
- write("Du schaffst es den Berg hoch. Aber nur muehsam.\n");
-
-
-BENERKUNGEN
-===========
-
- Wenn es um Attributabfragen geht, bitte diese Methode verwenden!
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/lfun/QueryAttributeOffset b/doc/sphinx/man/lfun/QueryAttributeOffset
deleted file mode 100644
index b16d10c..0000000
--- a/doc/sphinx/man/lfun/QueryAttributeOffset
+++ /dev/null
@@ -1,47 +0,0 @@
-
-QueryAttributeOffset()
-**********************
-
-
-FUNKTION
-========
-
- int QueryAttributeOffset(string attr)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- attr - gesuchter AttributOffset
-
-
-BESCHREIBUNG
-============
-
- Die Offsets des Attributs (inklusive Modifier) werden zurueckgegeben.
-
-
-BEISPIELE
-=========
-
- if(this_player()->QueryAttributeOffset(A_STR)<0)
- write("Du bist geschwaecht.\n");
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/lfun/QueryBuyFact b/doc/sphinx/man/lfun/QueryBuyFact
deleted file mode 100644
index 3f728c3..0000000
--- a/doc/sphinx/man/lfun/QueryBuyFact
+++ /dev/null
@@ -1,41 +0,0 @@
-
-QueryBuyFact()
-**************
-
-
-FUNKTION
-========
-
- int QueryBuyFact();
-
-
-DEFINIERT IN
-============
-
- /std/laden.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Gibt den mit SetBuyFact() gesetzten Faktor zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Der Einkaufspreismultiplikator.
-
-
-SIEHE AUCH
-==========
-
- SetBuyFact(), /std/laden.c
-
-Last modified: Wed May 8 10:21:57 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryBuyValue b/doc/sphinx/man/lfun/QueryBuyValue
deleted file mode 100644
index cecc57c..0000000
--- a/doc/sphinx/man/lfun/QueryBuyValue
+++ /dev/null
@@ -1,56 +0,0 @@
-
-QueryBuyValue()
-***************
-
-QueryBuyValue()
-
-Funktion
- static varargs int QueryBuyValue(mixed ob, object client)
-
-Definiert in
- /std/room/shop
-
-Argumente
- ob
- Das zu kaufende Objekt (String oder object). Im Normalfall
- handelt es sich um ein Objekt. Ausnahme sind Gegenstaende, die
- mit AddFixedObject() hinzugefuegt wurden.
-
- client
- Der Kaeufer.
-
-Beschreibung
- Ermittelt den Preis, den <client> fuer <ob> zu bezahlen hat.
-
-Rueckgabewert
- Der Preis als Integer.
-
-Beispiel
- Ein Haendler, der Spielern die ihm geholfen haben einen Rabatt von
- 10% gewaehrt
-
- object >>*<<helpers; protected void create() {
-
- ::create(); helpers=({}); ...
-
- }
-
- static varargs int QueryBuyValue(mixed ob, object client) {
-
- if(member(helpers,client)!=-1) {
-
- return ::QueryBuyValue(ob,client)*9/10;
-
- } return ::QueryBuyValue(ob,client);
-
- }
-
-Siehe auch:
- Funktionen:
- AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
- QueryStorageRoom(), QueryBuyFact(), sell_obj(), buy_obj()
-
- Properties:
- P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
-
-Letzte Aenderung: 21.05.2014, Bugfix
diff --git a/doc/sphinx/man/lfun/QueryCoinsPerUnits b/doc/sphinx/man/lfun/QueryCoinsPerUnits
deleted file mode 100644
index 7261758..0000000
--- a/doc/sphinx/man/lfun/QueryCoinsPerUnits
+++ /dev/null
@@ -1,57 +0,0 @@
-
-QueryCoinsPerUnits()
-********************
-
-
-QueryCoinsPerUnit()
-===================
-
-
-FUNKTION
-========
-
- int *QueryCoinsPerUnits();
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Liefert das Wertverhaeltnis fuer die Einheiten zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Ein Array von zwei Zahlen. Die erste Zahl ist der Wert der in der
- zweiten Zahl angegebenen Einheiten.
-
-
-BEISPIELE
-=========
-
- Steht im Unit-Objekt folgende Wertzuweisung:
-
- SetCoinsPerUnits(7,2);
-
- so liefert QueryCoinsPerUnits() als Ergebnis ({7, 2}).
-
-
-SIEHE AUCH
-==========
-
- SetCoinsPerUnits(), SetGramsPerUnits(), QueryGramsPerUnit(),
- /std/unit.c
-
-Last modified: Wed May 8 10:22:02 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryDamage b/doc/sphinx/man/lfun/QueryDamage
deleted file mode 100644
index 812636a..0000000
--- a/doc/sphinx/man/lfun/QueryDamage
+++ /dev/null
@@ -1,61 +0,0 @@
-
-QueryDamage()
-*************
-
-
-FUNKTION
-========
-
- int QueryDamage(object enemy);
-
-
-DEFINIERT IN
-============
-
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- enemy
- Der Gegner, gegen den die Waffe eingesetzt wird.
-
-
-BESCHREIBUNG
-============
-
- Dies ist die zentrale Funktion der Waffe. Sie wird in jeder Kampfrunde
- von Attack() aus aufgerufen und gibt den Schaden zurueck, den der
- Gegner abwehren muss.
-
- In den Schaden gehen sowohl die Staerke der Waffe als auch die Staerke
- des Traegers der Waffe ein.
-
- Wurde eine HitFunc() angegeben, so wird diese mit den gleichen
- Parametern wie QueryDamage() aufgerufen.
-
-
-RUeCKGABEWERT
-=============
-
- Die Staerke des Schlages fuer diese Kampfrunde. Sie ermittelt sich als
- Zufallszahl zwischen 0 und einem Wert, der sich aus der Staerke der
- Waffe und der Staerke ihres Traegers ergibt. Das Ergebnis des
- HitFunc()-Aufrufs wird zu dieser Zahl hinzugezaehlt.
-
-
-BEMERKUNGEN
-===========
-
- Auch wenn man eine HitFunc() verwendet, darf der Rueckgabewert
- insgesamt nicht groesser als 200 werden. Im Zweifelsfall sollte
- man sich mit der zustaendigen Balance besprechen!
-
-
-SIEHE AUCH
-==========
-
- HitFunc(), Attack(), /std/weapon.c, grenzwerte
-
-Last modified: Fre Feb 16.02.01 12:58:00 von Tilly
diff --git a/doc/sphinx/man/lfun/QueryDefend b/doc/sphinx/man/lfun/QueryDefend
deleted file mode 100644
index fa3fb11..0000000
--- a/doc/sphinx/man/lfun/QueryDefend
+++ /dev/null
@@ -1,68 +0,0 @@
-
-QueryDefend()
-*************
-
-
-FUNKTION
-========
-
- int QueryDefend(string|string* dtyp, int|mapping spell, object enemy);
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c
-
-
-ARGUMENTE
-=========
-
- dtyp - Schadenstypen der Angriffsart
- spell - 0 bei konventionellem Angriff,
- != 0 bei Angriff mit einem nichtphysischen Spell,
- mapping bei genaueren Angaben zur Wirkung
- enemy - Der angreifende Gegner
-
-
-BESCHREIBUNG
-============
-
- Dies ist die zentrale Funktion einer Ruestung. Sie wird in jeder
- Kampfrunde aus /std/living/combat::Defend() fuer jede Ruestung aufgerufen,
- die der Spieler angezogen hat.
-
- Der Schutzwert von P_AC entfaltet seine Wirkung nur bei konventionellen
- Angriffen:
- * wenn 'spell' 0 ist (bei Aufruf aus der Defend heraus ausgeschlossen)
- * wenn 'spell' ein Mapping mit dem Flag SP_PHYSICAL_ATTACK != 0 UND
- in 'dtyp' mindestens ein physischer Schaden enthalten ist
-
-
-RUeCKGABEWERT
-=============
-
- Die Ruestungsstaerke in dieser Kampfrunde. Sie ermittelt sich als
- Zufallszahl zwischen 0 und P_AC, zuzueglich des Ergebnisses des
- DefendFunc()-Aufrufs.
-
-
-BEMERKUNGEN
-===========
-
- Auch wenn man eine DefendFunc() benutzt, darf der Rueckgabewert
- insgesamt nicht groesser werden als der fuer den Ruestungstyp
- maximal zulaessige!
-
-
-SIEHE AUCH
-==========
-
- Ruestungen: P_ARMOUR_TYPE, P_NR_HANDS, P_ARMOURS, P_WORN
- Schutz: P_AC, Defend(), DefendFunc
- Sonstiges: P_EQUIP_TIME, P_LAST_USE, P_DAM_TYPE
- Verwandt: QueryArmourByType(L), P_WEAPON, FilterClothing(),
- FilterArmours()
- Resistenz: P_RESISTANCE_STRENGTHS, CheckResistance(L)
-
-28.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/lfun/QueryDisguise b/doc/sphinx/man/lfun/QueryDisguise
deleted file mode 100644
index 3cf4b8d..0000000
--- a/doc/sphinx/man/lfun/QueryDisguise
+++ /dev/null
@@ -1,51 +0,0 @@
-
-QueryDisguise()
-***************
-
-
-FUNKTION
-========
-
- mixed QueryDisguise();
-
-
-DEFINIERT IN
-============
-
- ???
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Prueft, ob der Spieler durch einen Shadow (meistens der Tarnhelm)
- 'manipuliert' ist.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn dies nicht der Fall ist, ansonsten die Beschreibung des Shadow
- vom Typ string.
-
-
-BEMERKUNGEN
-===========
-
- In Waffen / Ruestungen u.ae. die P_RESTRICTIONS gesetzt haben,
- eruebrigt sich eine Abfrage auf QueryDisguise(), da dies bereits im
- restriction_checker erledigt wird.
-
-
-SIEHE AUCH
-==========
-
- P_RESTRICTIONS, /std/restriction_checker.c
-
-Last modified: Mon Mar 26 14:48:20 2001 von Tilly
diff --git a/doc/sphinx/man/lfun/QueryDoorKey b/doc/sphinx/man/lfun/QueryDoorKey
deleted file mode 100644
index f606c52..0000000
--- a/doc/sphinx/man/lfun/QueryDoorKey
+++ /dev/null
@@ -1,71 +0,0 @@
-
-QueryDoorKey()
-**************
-
-
-FUNKTION
-========
-
- mixed QueryDoorKey();
-
-
-DEFINIERT IN
-============
-
- versch. Schluesseln
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird in einem Schluessel aufgerufen, wenn man mit diesem
- eine Tuer auf- oder abschliessen will. Anhand des Rueckgabewertes wird
- entschieden, ob der Schluessel passt oder nicht.
-
-
-RUECKGABEWERT
-=============
-
- String oder Array von Strings der Raumpfade, deren gemeinsame Tueren
- sich mit diesem Schluessel auf- bzw. abschliessen lassen. Die Keys sind
- dabei die Raumpfade, getrennt durch ein ":". Dabei muessen die Pfade
- in lexikographischer (alphabetischer) Reihenfolge sortiert sein:
-
- "<name_raum_1>:<name_raum_2>"
-
-
-BEISPIELE
-=========
-
- Ein Schluessel, mit dem sich eine einzige Tuer oeffnen laesst (falls es
- jemals eine Tuer zwischen Karate- und Abenteurergilde geben sollte...):
-
- string QueryDoorKey()
- {
- return "/gilden/abenteurer:/gilden/karate";
- }
-
- Ein Schluessel, der in mehreren Tueren passt:
-
- string* QueryDoorKey()
- {
- return ({ "/gilden/abenteurer:/players/wargon/workroom",
- "/gilden/abenteurer:/gilden/karate",
- "/players/jof/workroom:/players/wargon/workroom"
- });
- }
-
-
-SIEHE AUCH
-==========
-
- NewDoor(), QueryDoorStatus(), SetDoorStatus(), P_DOOR_INFOS,
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
-
-Letzte Aenderung: Don, 08.05.2014, Gabylon
diff --git a/doc/sphinx/man/lfun/QueryDoorStatus b/doc/sphinx/man/lfun/QueryDoorStatus
deleted file mode 100644
index 74f7034..0000000
--- a/doc/sphinx/man/lfun/QueryDoorStatus
+++ /dev/null
@@ -1,48 +0,0 @@
-
-QueryDoorStatus()
-*****************
-
-
-FUNKTION
-========
-
- int QueryDoorStatus(string dest);
-
-
-DEFINIERT IN
-============
-
- /obj/doormaster.c
-
-
-ARGUMENTE
-=========
-
- <dest> = Zielraum der Tuer.
-
-
-BESCHREIBUNG
-============
-
- Es wird der Zustand der Tuer, die von diesem Raum nach <dest> fuehrt,
- ermittelt.
-
-
-RUeCKGABEWERT
-=============
-
- 0 bei nicht vorhandene Tuer, ansonsten einer der folgenden Zustaende (aus
- <doorroom.h>):
-
- D_STATUS_LOCKED - Tuer abgeschlossen
- D_STATUS_CLOSED - Tuer geschlossen
- D_STATUS_OPEN - Tuer geoeffnet
-
-
-SIEHE AUCH
-==========
-
- NewDoor(), QueryDoorKey(), SetDoorStatus(), P_DOOR_INFOS,
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
-
-Letzte Aenderung: Don, 08.05.2014, Gabylon
diff --git a/doc/sphinx/man/lfun/QueryDu b/doc/sphinx/man/lfun/QueryDu
deleted file mode 100644
index aa184cc..0000000
--- a/doc/sphinx/man/lfun/QueryDu
+++ /dev/null
@@ -1,61 +0,0 @@
-
-QueryDu()
-*********
-
-
-FUNKTION
-========
-
- varargs string QueryDu(int casus, int gender, int anzahl);
-
-
-DEFINIERT IN
-============
-
- /std/thing/language.c
-
-
-ARGUMENTE
-=========
-
- casus
- Der Fall fuer die Anrede.
-
- gender
- Das Geschlecht des anzuredenden Objektes.
-
- anzahl
- Ist nur ein Objekt anzusprechen oder mehrere?
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert die dem Anlass entsprechende Anrede fuer ein
- Objekt.
-
-
-RUeCKGABEWERT
-=============
-
- Ein String mit der Anrede.
-
-
-BEISPIELE
-=========
-
- printf("%s setzt %s auf den Boden.\n",
- capitalize(QueryDu(WER, TP->QueryProp(P_GENDER), SINGULAR),
- QueryDu(WEN, TP->QueryProp(P_GENDER), SINGULAR));
-
- (In den meisten Faellen kann man hier auch direkt "Du" und "dich"
- einsetzen.)
-
-
-SIEHE AUCH
-==========
-
- /std/thing/language.c
- QueryPossPronoun(), QueryOwn(), QueryPronoun()
-
-Last modified: Wed May 8 10:22:27 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryEnemies b/doc/sphinx/man/lfun/QueryEnemies
deleted file mode 100644
index fc00c0e..0000000
--- a/doc/sphinx/man/lfun/QueryEnemies
+++ /dev/null
@@ -1,54 +0,0 @@
-
-QueryEnemies()
-**************
-
-
-FUNKTION
-========
-
- mixed QueryEnemies();
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUeCKGABEWERT
-=============
-
- Array mit Array aus bekannten Gegnern und Array aus Zeiten
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion enthaelt ein Array, das zwei Elemente enthaelt, die
- wiederum Arrays sind:
- 1. Array: Die bekannten Gegner als Objektpointer.
- 2. Array: Die zugeordneten Zeiten, wie lange ein Gegner noch als
- solcher bekannt sein soll.
- Im Normalfall wird ein Gegner dann bekannt, wenn man gezielt
- jemanden atackiert, oder wenn man einen Angriff abwehren muss.
- Dann wird der Gegner intern abgespeichert, und es wird eine Zeit
- gesetzt, die dann runtergezaehlt wird. Ist die Zeit auf 0, so wird
- der Gegner wieder automatisch ausgetragen.
- (Standardmaessig betraegt diese Zeit 600 Sekunden (300 Heartbeats).)
- Man kann sich die Gegner auch in Form eines Mappings zurueckgeben
- lassen. Dies erreicht man mittels der Funktion GetEnemies().
-
-
-SIEHE AUCH
-==========
-
- Kill(), Attack(), Defend(), do_my_heart_beat(), PresentEnemies(),
- GetEnemies(), SelectEnemy(), QueryPreferedEnemy(), P_PREFERED_ENEMY
-
-29.12.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/QueryFlaw b/doc/sphinx/man/lfun/QueryFlaw
deleted file mode 100644
index e12a119..0000000
--- a/doc/sphinx/man/lfun/QueryFlaw
+++ /dev/null
@@ -1,63 +0,0 @@
-
-QueryFlaw()
-***********
-
-
-FUNKTION
-========
-
- mixed *QueryFlaw();
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c,
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- QueryFlaw() liefert Informationen ueber den Grad der Abnutzung der
- Waffe bzw. Ruestung. Der Zustand wird als Array mit der Zahl der
- TakeFlaw()-Aufrufe und dem Datum des ersten TakeFlaw()-Aufrufs
- zurueckgegeben.
-
-
-RUeCKGABEWERT
-=============
-
- Ein Array mit drei Elementen:
- 1. der aktuelle Zaehlerstand
- 2. Zeit der ersten Benutzung
- 3. die Zeit der ersten Benutzung als String
-
-
-BEISPIELE
-=========
-
- Den aktuellen Abnutzungsgrad einer Ruestung kann man sich wie folgt
- anzeigen lassen:
-
- mixed *flaw;
-
- flaw = ruestung->QueryFlaw();
-
- printf("Zaehlerstand: %d, erster Schlag: %s\n", flaw[0], flaw[2]);
- // oder analog:
- printf("Zaehlerstand: %d, erster Schlag: %s\n", flaw[0], dtime(flaw[1]));
-
-
-SIEHE AUCH
-==========
-
- TakeFlaw(), /std/armour/combat.c, /std/weapon/combat.c
-
-Last modified: Wed May 8 10:22:32 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryGenderString b/doc/sphinx/man/lfun/QueryGenderString
deleted file mode 100644
index 845758f..0000000
--- a/doc/sphinx/man/lfun/QueryGenderString
+++ /dev/null
@@ -1,42 +0,0 @@
-
-QueryGenderString()
-*******************
-
-
-FUNKTION
-========
-
- string QueryGenderString();
-
-
-DEFINIERT IN
-============
-
- /std/thing/language.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Es wird ein String mit dem Geschlecht des Objektes zurueckgegeben
- ("maennlich", "weiblich", "saechlich").
-
-
-RUeCKGABEWERT
-=============
-
- Der String mit dem Geschlecht.
-
-
-SIEHE AUCH
-==========
-
- /std/thing/language.c
-
-Last modified: Wed May 8 10:23:00 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryGramsPerUnits b/doc/sphinx/man/lfun/QueryGramsPerUnits
deleted file mode 100644
index 62d5580..0000000
--- a/doc/sphinx/man/lfun/QueryGramsPerUnits
+++ /dev/null
@@ -1,53 +0,0 @@
-
-QueryGramsPerUnits()
-********************
-
-
-FUNKTION
-========
-
- int *QueryGramsPerUnits();
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Liefert das Gewichtsverhaeltnis fuer die Einheiten zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Ein Array von zwei Zahlen. Die erste Zahl ist das Gewicht der in der
- zweiten Zahl angegebenen Einheiten.
-
-
-BEISPIELE
-=========
-
- Steht im Unit-Objekt folgende Gewichtszuweisung:
-
- SetGramsPerUnits(4,1);
-
- so liefert QueryGramsPerUnits() als Ergebnis ({4, 1}).
-
-
-SIEHE AUCH
-==========
-
- SetCoinsPerUnits(), QueryCoinsPerUnits() SetGramsPerUnits(),
- /std/unit.c
-
-Last modified: Wed May 8 10:22:39 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryGroupedKeys b/doc/sphinx/man/lfun/QueryGroupedKeys
deleted file mode 100644
index 5101e8d..0000000
--- a/doc/sphinx/man/lfun/QueryGroupedKeys
+++ /dev/null
@@ -1,44 +0,0 @@
-
-QueryGroupedKeys()
-******************
-
-
-FUNKTION
-========
-
- mixed *QueryGroupedKeys()
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUECKGABEWERT
-=============
-
- Array mit Arrays mit den Schluesselwoertern der Quests
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert ein Array mit mehreren Arrays zurueck, die
- die Schluesselwoerter der Quests enthalten. Dabei enthaelt das
- erste Array die Schluesselwoerter der Quests der ersten Gruppe etc.
- Das letzte Array enthaelt die Gruppe der optionalen Quests.
-
-
-SIEHE AUCH
-==========
-
- GiveQuest, QueryQuest, /secure/questmaster.h
-
-Zuletzt geaendert: Son, 19. Nov 2000, 13:22:15 von Zook.
diff --git a/doc/sphinx/man/lfun/QueryGuest b/doc/sphinx/man/lfun/QueryGuest
deleted file mode 100644
index 61cfb04..0000000
--- a/doc/sphinx/man/lfun/QueryGuest
+++ /dev/null
@@ -1,54 +0,0 @@
-
-QueryGuest()
-************
-
-
-FUNKTION
-========
-
- int QueryGuest();
-
-
-DEFINIERT IN
-============
-
- /std/player/base
-
-
-BESCHREIBUNG
-============
-
- Auf der uid basierende Hilfsfunktion, um Gaeste zu identifizieren.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn Spielerobjekt ein Gast ist; 0 sonst
-
-
-BEISPIELE
-=========
-
- if(this_interactive()->QueryGuest())
- {
- (this_interactive()->ReceiveMsg(
- "Wir bedienen hier nur ordentliche Charaktere.",
- MT_LISTEN, MA_SAY,
- "Der Wirt sagt: ") != MSG_SENSE_BLOCK) ||
- (this_interactive()->ReceiveMsg(
- "Der Wirt gestikuliert dich hinaus.",
- MT_LOOK, MA_LOOK) != MSG_SENSE_BLOCK) ||
- (this_interactive()->ReceiveMsg(
- "Irgendwer stupst dich an. Du sollst wohl gehen.",
- MT_FEEL, MA_FEEL));
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- getuid()
-
-14. Mai 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/QueryHealInfo b/doc/sphinx/man/lfun/QueryHealInfo
deleted file mode 100644
index cc42fbc..0000000
--- a/doc/sphinx/man/lfun/QueryHealInfo
+++ /dev/null
@@ -1,45 +0,0 @@
-
-QueryHealInfo()
-***************
-
-
-FUNKTION
-========
-
- string QueryHealInfo();
-
-
-DEFINIERT IN
-============
-
- /std/corpse.c,
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- QueryHealInfo() liefert einen Standardtext zurueck, der grob Auskunft
- darueber gibt, welche Auswirkungen das Essen einer Leiche haette.
- Diese Info kann z.B. von Gilden verwendet werden, die P_HEAL (s.dort)
- einer Leiche nicht selbst auswerten wollen.
-
-
-RUeCKGABEWERT
-=============
-
- Ein nicht umbrochener String. Fuer Zeilenumbrueche kann derjenige,
- der den Text ausliest, selbst sorgen.
-
-
-SIEHE AUCH
-==========
-
- /std/corpse.c, P_HEAL
-
-Last modified: 31.03.2008, Arathorn
diff --git a/doc/sphinx/man/lfun/QueryMaterial b/doc/sphinx/man/lfun/QueryMaterial
deleted file mode 100644
index 94a5367..0000000
--- a/doc/sphinx/man/lfun/QueryMaterial
+++ /dev/null
@@ -1,62 +0,0 @@
-
-QueryMaterial()
-***************
-
-
-QueryMaterial(L)
-================
-
-
-FUNKTION
-========
-
- int QueryMaterial(string mat)
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- string mat - Material, auf das getestet werden soll
-
-
-BESCHREIBUNG
-============
-
- Testet, ob ein Gegenstand aus dem angegebenen Material besteht
- und gibt dessen Anteil zurueck.
- Die Rueckgabe ist im Wertebereich -100 (Antigruppen) bis +100 (%).
-
-
-RUECKGABEWERT
-=============
-
- Anteil in Prozent.
-
-
-BEISPIELE
-=========
-
- if(ob->QueryMaterial(MAT_IVORY)<=0)
- write("Daraus kannst Du keine Billiardkugeln schnitzen!\n");
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Methoden: QueryMaterialGroup(), MaterialList(),
- Listen: AllMaterials(), AllGroups(), Dump()
- materialliste, materialgruppen
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
- Sonstiges: P_MATERIAL_KNOWLEDGE
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/QueryMaterialGroup b/doc/sphinx/man/lfun/QueryMaterialGroup
deleted file mode 100644
index 3365f73..0000000
--- a/doc/sphinx/man/lfun/QueryMaterialGroup
+++ /dev/null
@@ -1,81 +0,0 @@
-
-QueryMaterialGroup()
-********************
-
-
-QueryMaterialGroup(L)
-=====================
-
-
-FUNKTION
-========
-
- int QueryMaterialGroup(string grp)
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- string grp - Materialgruppe, auf die getestet werden soll
-
-
-BESCHREIBUNG
-============
-
- Liefert eine Angabe, zu welchem Anteil das Objekt aus Materialien
- dieser Gruppe besteht.
- Die Rueckgabe ist im Wertebereich -100 (Antigruppen) bis +100 (%).
-
-
-RUECKGABEWERT
-=============
-
- Anteil in Prozent.
-
-
-BEMERKUNGEN
-===========
-
- Ruft MaterialGroup() an der MATERIALDB.
-
-
-BEISPIELE
-=========
-
- // kann man damit was anfangen?
- if(ob->QueryMaterialGroup(MATGROUP_METAL)<50)
- write("Der Schmied sagt: Daraus kann ich kein Schwert fertigen.\n");
-
- // verbrennt das Ding?
- if(ob->QueryMaterialGroup(MATGROUP_INFLAMMABLE)>50) {
- write(ob->Name(WER)+" geht in Flammen auf.\n");
- ob->remove();
- }
-
- // wie magnetisch ist es denn?
- if(ob->QueryMaterialGroup(MATGROUP_MAGNETIC)>50)
- write(break_string(
- ob->Name(WER)+" flutscht Dir aus der Hand und bleibt am Magneten "
- "kleben!",78));
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Methoden: QueryMaterial(), MaterialList(),
- Listen: AllMaterials(), AllGroups(), Dump()
- materialliste, materialgruppen
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
- Sonstiges: P_MATERIAL_KNOWLEDGE
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/QueryMaxQP b/doc/sphinx/man/lfun/QueryMaxQP
deleted file mode 100644
index 7b5aba2..0000000
--- a/doc/sphinx/man/lfun/QueryMaxQP
+++ /dev/null
@@ -1,45 +0,0 @@
-
-QueryMaxQP()
-************
-
-
-FUNKTION
-========
-
- int QueryMaxQP()
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUECKGABEWERT
-=============
-
- Abenteuerpunkte der Pflichtquests
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert die Abenteuerpunkte der als Pflichtquest
- eingetragenen Abenteuer zurueck. Pflichtquest bedeutet entweder,
- dass die Quest zwingend geloest werden muss oder dass sie zu
- der 80%-Regel gehoert.
-
-
-SIEHE AUCH
-==========
-
- GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
- QueryOptQP, QueryTotalQP
-
-Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
diff --git a/doc/sphinx/man/lfun/QueryMoney b/doc/sphinx/man/lfun/QueryMoney
deleted file mode 100644
index 775a65c..0000000
--- a/doc/sphinx/man/lfun/QueryMoney
+++ /dev/null
@@ -1,49 +0,0 @@
-
-QueryMoney()
-************
-
-
-FUNKTION
-========
-
- int QueryMoney()
-
-
-DEFINIERT IN
-============
-
- /std/player/moneyhandler.c
-
-
-BESCHREIBUNG
-============
-
- Testet, ob ein Spieler, Objekt, Raum oder Npc ueber eine definierte
- Geldmenge verfuegt, oder nicht.
-
-
-RUECKGABEWERT
-=============
-
- Geldmenge im Besitz des abgefragten Spielers
-
-
-BEISPIELE
-=========
-
- int i;
- i=50+random(10);
- if(!this_player()->QueryMoney())
- write("Du besitzt keine Muenzen!\n");
- if(this_player()->QueryMoney() < i)
- write("Du besitzt nicht die erforderlichen "+i+" Muenzen.\n");
-
-
-SIEHE AUCH
-==========
-
- Geldhandling: AddMoney(L)
- Zentralbank: PayIn(L), WithDraw(L), _query_current_money(L)
- Sonstiges: /items/money.c
-
-Last modified: Die, 1. Aug 2000, 16:39:06 by Tilly
diff --git a/doc/sphinx/man/lfun/QueryName b/doc/sphinx/man/lfun/QueryName
deleted file mode 100644
index 71e65e3..0000000
--- a/doc/sphinx/man/lfun/QueryName
+++ /dev/null
@@ -1,43 +0,0 @@
-
-QueryName()
-***********
-
-
-FUNKTION
-========
-
- mixed QueryName();
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- DIESE FUNKTION SOLLTE NICHT MEHR BENUTZT WERDEN!
- Es wird der Inhalt der Property P_NAME zuueckgegeben; dies laesst sich
- jedoch genau so gut mit QueryProp(P_NAME) bewerkstelligen!
-
-
-RUeCKGABEWERT
-=============
-
- String oder Array von Strings mit dem Namen des Objektes.
-
-
-SIEHE AUCH
-==========
-
- QueryProp(), Name(), name(), /std/thing/description.c
-
-Last modified: Sat Aug 3 11:21:05 2002 by Vanion
diff --git a/doc/sphinx/man/lfun/QueryOpenMiniQuestsForPlayer b/doc/sphinx/man/lfun/QueryOpenMiniQuestsForPlayer
deleted file mode 100644
index f43d7cc..0000000
--- a/doc/sphinx/man/lfun/QueryOpenMiniQuestsForPlayer
+++ /dev/null
@@ -1,80 +0,0 @@
-
-QueryOpenMiniQuestsForPlayer()
-******************************
-
-
-FUNKTION
-========
-
- mapping QueryOpenMiniQuestsForPlayer(object player)
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt die Liste der offenen Miniquests des Spielers als
- Mapping zurueck.
-
-
-ARGUMENTE
-=========
-
- player - das interessierende Spielerobjekt
-
-
-RUECKGABEWERTE
-==============
-
- Mapping mit der Liste der Miniquests, fuer die das abfragende Objekt
- zustaendig ist, oder leeres Mapping, wenn der Spieler keine MQs mehr
- offen hat.
-
- Die Liste enthaelt die Miniquestnummer als Key. Diesem sind zwei Werte
- zugeordnet: zum einen ein Miniquest-Aufgabentext, und zum anderen -
- falls der Spieler eine der Vorbedingungen fuer die Miniquest nicht
- erfuellt - ein Hinweistext, der Auskunft gibt, welche Bedingung noch
- zu erfuellen ist ("Seherstatus fehlt"). Diese Hinweistexte entsprechen
- denen aus check_restrictions() in /std/restriction_checker.c. Der
- jeweils andere Text wird auf 0 gesetzt.
-
- Die Struktur des Mappings ist daher folgende:
- ([ MQ-Nummer : <Aufgabenstellung> ; <Hinderungsgrund> ])
-
-
-
- Beispiel: ein Spieler hat die Miniquests 18 und 49 noch nicht geloest,
- erfuellt aber nur fuer Miniquest 49 die Anforderungen. Miniquest 18
- erfordert den Seherstatus. Dann saehe das Mapping so aus:
- ([ 18 : 0 ; "Dazu musst Du erst Seher werden.\n",
- 49 : "Aufgabentext_zu_49" ; 0 ])
-
- Jedes abfragende Objekt muss daher dieses Mapping zunaecht geeignet
- auf seinen Inhalt pruefen, um zu ermitteln, welche Meldung jeweils
- auszugeben ist.
-
-
-BEMERKUNGEN
-===========
-
- Das abfragende Objekt muss von einem Erzmagier oder Gott (z.B. dem
- zustaendigen Quest-EM) im Questmaster als zugriffsberechtigt bei den-
- jenigen Miniquests eingetragen sein, fuer die es die entsprechenden
- Miniquest-Hinweise ausgeben darf. Diese Berechtigung ist mit dem
- Quest-EM abzustimmen. Anderen Objekten wird ein leeres Mapping zurueck-
- gegeben.
-
-
-SIEHE AUCH
-==========
-
- AddMiniQuest(L), ChangeMiniQuest(L)
- P_RESTRICTIONS
- erzmagier
-
-Last modified: 6. Juni 2014, Arathorn.
diff --git a/doc/sphinx/man/lfun/QueryOwn b/doc/sphinx/man/lfun/QueryOwn
deleted file mode 100644
index 22e9e5f..0000000
--- a/doc/sphinx/man/lfun/QueryOwn
+++ /dev/null
@@ -1,53 +0,0 @@
-
-QueryOwn()
-**********
-
-
-FUNKTION
-========
-
- varargs string QueryOwn(int casus)
-
-
-DEFINIERT IN
-============
-
- /std/thing/language.c
-
-
-ARGUMENTE
-=========
-
- casus
- Der Fall fuer die Anrede.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert das dem Anlass entsprechende Possessiv-
- pronomen fuer den Spieler selber (Dein/Deine).
-
-
-RUeCKGABEWERT
-=============
-
- Ein String mit dem Pronomen.
-
-
-BEISPIELE
-=========
-
- printf("%s %s loest sich auf.\n",
- capitalize(obj->QueryOwn(WER)),obj->name(WER));
-
- (In den meisten Faellen kann man hier auch direkt "Dein" oder "Deine"
- einsetzen.)
-
-
-SIEHE AUCH
-==========
-
- /std/thing/language.c
-
-Last modified: Sun Aug 10 23:55:27 2003 by Mandragon
diff --git a/doc/sphinx/man/lfun/QueryPassengers b/doc/sphinx/man/lfun/QueryPassengers
deleted file mode 100644
index d6f9331..0000000
--- a/doc/sphinx/man/lfun/QueryPassengers
+++ /dev/null
@@ -1,51 +0,0 @@
-
-QueryPassengers()
-*****************
-
-
-FUNKTION
-========
-
- object *QueryPassengers();
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ermittelt die momentan auf dem Transporter befindlichen
- Passagiere.
-
-
-RUeCKGABEWERT
-=============
-
- Array von Objekten mit den Passagieren.
-
-
-BEMERKUNGEN
-===========
-
- Es werden nur die Passagiere zurueckgegeben, die sich in dem
- eigentlichen Transporterobjekt befinden! Wenn der Transporter noch um
- zusaetzliche Raeume vergroessert wird, werden unter Umstaenden nicht
- alle Passagiere erfasst!
-
-
-SIEHE AUCH
-==========
-
- /std/transport.c
-
-Last modified: Wed May 8 10:22:48 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryPosition b/doc/sphinx/man/lfun/QueryPosition
deleted file mode 100644
index 08af6fe..0000000
--- a/doc/sphinx/man/lfun/QueryPosition
+++ /dev/null
@@ -1,48 +0,0 @@
-
-QueryPosition()
-***************
-
-
-FUNKTION
-========
-
- string *QueryPosition();
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Es wird ein Array von zwei Strings mit Kennzeichnern der letzten (oder
- aktuellen) und der naechsten Station im Fahrplan zurueckgegeben.
-
- Die Kennzeichner sind dabei die ersten Argumente der entsprechenden
- AddXXX()-Aufrufen, also der Name der Haltestelle bei AddRoute, der Text
- der Meldung bei AddMsg() und der Name der Funktion bei AddFun().
-
-
-RUeCKGABEWERT
-=============
-
- Array mit zwei Strings. Der erste String gibt den Kennzeichner der
- momentanen Fahrplanstation an, der zweite String den Kennzeichner der
- naechsten Fahrplanstation.
-
-
-SIEHE AUCH
-==========
-
- AddRoute(), AddMsg(), AddFun(), /std/transport.c
-
-Last modified: Wed May 8 10:22:52 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryPossPronoun b/doc/sphinx/man/lfun/QueryPossPronoun
deleted file mode 100644
index 90af78a..0000000
--- a/doc/sphinx/man/lfun/QueryPossPronoun
+++ /dev/null
@@ -1,74 +0,0 @@
-
-QueryPossPronoun()
-******************
-
-
-FUNKTION
-========
-
- varargs string QueryPossPronoun(mixed what, int casus, int anzahl);
-
-
-DEFINIERT IN
-============
-
- /std/thing/language.c
-
-
-ARGUMENTE
-=========
-
- what
- Geschlecht des Objektes, das besessen wird, oder das Objekt
- selbst.
-
- casus
- Der Fall, in dem das Objekt besessen wird.
-
- anzahl
- Handelt es sich um nur ein Objekt oder um mehrere?
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt ein Possessivpronomen zurueck, das das
- Besitzverhaeltnis eines Objektes zu diesem Objekt anzeigt.
-
-
-RUeCKGABEWERT
-=============
-
- Das Possessivpronomen im entsprechenden Fall.
-
-
-BEMERKUNGEN
-===========
-
- what und casus beziehen sich auf das Objekt, welches besessen wird, und
- nicht auf den Besitzer!!!
-
-
-BEISPIELE
-=========
-
- Um eine korrekte Ausgabe beim Haendeklatschen zu erreichen, koennte man
- zB. folgende Zeile verwenden:
-
- printf("%s klatscht in %s Haende.\n",this_player()->name(WER),
- this_player()->QueryPossPronoun(FEMALE, WEN, PLURAL));
-
- FEMALE, da "die Hand" weiblich ist, WEN, da man im Akkusativ klatscht,
- und PLURAL, da man dazu beide Haende braucht.
-
- Ein beliebter Fehler ist es, als Fall WESSEN zu verwenden (in WESSEN
- Haende klatscht man? => in seine).
- Die richtige Frage waere aber: WEN klatscht man? (in die Haende)
-
-
-SIEHE AUCH
-==========
-
- QueryOwn(), QueryPronoun(), /std/thing/language.c
-
-Last modified: Wed Jan 11 13:13:35 CET 2006 by Rumata
diff --git a/doc/sphinx/man/lfun/QueryPrayRoom b/doc/sphinx/man/lfun/QueryPrayRoom
deleted file mode 100644
index b783174..0000000
--- a/doc/sphinx/man/lfun/QueryPrayRoom
+++ /dev/null
@@ -1,50 +0,0 @@
-
-QueryPrayRoom()
-***************
-
-
-FUNKTION
-========
-
- public string QueryPrayRoom()
-
-
-DEFINIERT IN
-============
-
- /std/player/base.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Dies ist der Raum, in den der Spieler nach dem Ende der Todessequenz
- bewegt wird, d.h. ein Raum, wo er beten kann, um einen neuen Koerper zu
- erhalten.
- Der Raum wird als String angegeben (kein Objekt).
-
- Jede Rasse hat einen Default fuer diese Funktion, welcher mit
- SetDefaultPrayRoom() gesetzt wird. Dieser Default kann mit der Property
- P_PRAY_ROOM ueberlagert werden. Wird die Property auf 0 dgesetzt, wird
- dieser Default aktiv.
-
-
-RUeCKGABEWERT
-=============
-
- Der Objektname des Betraums (string)
-
-
-SIEHE AUCH
-==========
-
- P_PRAY_ROOM
- SetDefaultPrayRoom
-
-21.05.2013, Zesstra
diff --git a/doc/sphinx/man/lfun/QueryPreferedEnemy b/doc/sphinx/man/lfun/QueryPreferedEnemy
deleted file mode 100644
index 10a8ae0..0000000
--- a/doc/sphinx/man/lfun/QueryPreferedEnemy
+++ /dev/null
@@ -1,56 +0,0 @@
-
-QueryPreferedEnemy()
-********************
-
-
-FUNKTION
-========
-
- object QueryPreferedEnemy();
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUeCKGABEWERT
-=============
-
- bevorzugter Gegner
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert unter folgenden Bedingungen zufaellig eines
- der Lebewesen als bevorzugten Gegner zurueck, welche in der
- Property P_PREFERED_ENEMY in einem Array eingetragen sind:
- (1) Der erste Eintrag des erwaehnten Propertyarrays enthaelt
- einen Wert zwischen 0 und 100, der die Wahrscheinlichkeit
- dafuer angibt, dass ein Lebewesen als Gegner bevorzugt werden
- soll. Es wird also nicht immer bevorzugt, wenn dort ein Wert
- kleiner 100 steht! In diesem Fall wird eine 0 zurueckgegeben.
- (2) Das per Zufall aus den Arrayelementen ab Element 2 gewaehlte
- Lebewesen muss auch wirklich existieren. Ist dies nicht der
- Fall, wird das nunmehr leere Element aus dem Array entfernt
- und eine 0 zurueckgeliefert.
- (3) Das Lebewesen muss derzeit auch wirklich Feind sein! Ist dies
- nicht der Fall, wird eine 0 zurueckgegeben.
- Will man eine andere Bevorzugung von Gegnern erreichen,
- ueberschreibt man am besten diese Funktion.
-
-
-SIEHE AUCH
-==========
-
- SelectEnemy(), IsEnemy(), P_PREFERED_ENEMY
-
-Last modified: Wed May 26 16:47:51 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/QueryPronoun b/doc/sphinx/man/lfun/QueryPronoun
deleted file mode 100644
index 39088f9..0000000
--- a/doc/sphinx/man/lfun/QueryPronoun
+++ /dev/null
@@ -1,54 +0,0 @@
-
-QueryPronoun()
-**************
-
-
-FUNKTION
-========
-
- string QueryPronoun(int casus);
-
-
-DEFINIERT IN
-============
-
- /std/thing/language.c
-
-
-ARGUMENTE
-=========
-
- casus
- Der Fall, in dem das Personalpronomen verlangt wird.
-
-
-BESCHREIBUNG
-============
-
- Es wird ein Personalpronomen ("er", "sie", "es") im entsprechenden Fall
- fuer dieses Objekt berechnet.
-
-
-RUeCKGABEWERT
-=============
-
- Das Pronomen im entsprechenden Fall.
-
-
-BEISPIELE
-=========
-
- printf("Du versucht, %s zu nehmen, aber %s ist zu schwer.\n",
- ob->name(WEN), ob->QueryPronoun(WER));
-
- Hier wird immer das richtige Pronomen verwendet, egal, welches
- Geschlecht das Objekt ob hat.
-
-
-SIEHE AUCH
-==========
-
- SuggestArticle(), QueryPossPronoun(), /std/thing/language.c
- QueryOwn()
-
-Last modified: Wed May 8 10:23:14 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/QueryProp b/doc/sphinx/man/lfun/QueryProp
deleted file mode 100644
index 71c4fdf..0000000
--- a/doc/sphinx/man/lfun/QueryProp
+++ /dev/null
@@ -1,63 +0,0 @@
-
-QueryProp()
-***********
-
-
-FUNKTION
-========
-
- mixed QueryProp(string name);
-
-
-DEFINIERT IN
-============
-
- /std/thing/properties.c
-
-
-ARGUMENTE
-=========
-
- string name - abzufragende Property
-
-
-BESCHREIBUNG
-============
-
- Der Datenwert der Property 'name' wird zurueckgegeben.
-
- Existiert eine F_QUERY_METHOD oder eine _query_'name'()-Methode fuer
- diese Property, so wird diese aufgerufen und ihr 'Value' uebergeben.
- Eine F_QUERY_METHOD hat dabei Vorrang vor _query_'name'(), d.h.
- _query_'name'() wird nach erfolgreicher F_QUERY_METHOD nicht mehr
- gerufen.
-
- (Diese Methoden nutzen dann Set(), um auf den Datenwert der Property
- 'name' zurueckzugreifen. Teilweise werden aber auch interne Variablen
- so oeffentlich gemacht und sind nicht in der ueber Set/Query
- verfuegbaren Property 'name' abgelegt.)
-
-
-RUeCKGABEWERT
-=============
-
- Der Datenwert der Property.
- 0, falls diese nicht existiert.
-
-
-BEISPIELE
-=========
-
- // wie hoch sind die aktuelle LP des Spielers?
- hp = this_player()->QueryProp(P_HP);
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: SetProp(L), Set(L), Query(L)
- Generell: SetProperties(L), QueryProperties(L)
- Konzept: properties, /std/thing/properties.c
- Sonstiges: P_AUTOLOADOBJ
-
-15.Dez 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/QueryProperties b/doc/sphinx/man/lfun/QueryProperties
deleted file mode 100644
index 6949e0f..0000000
--- a/doc/sphinx/man/lfun/QueryProperties
+++ /dev/null
@@ -1,54 +0,0 @@
-
-QueryProperties()
-*****************
-
-
-FUNKTION
-========
-
- mapping QueryProperties()
-
-
-DEFINIERT IN
-============
-
- /std/thing/properties.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert ein Mapping mit allen fuer das Objekt
- definierten Properties zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Ein Mapping mit den Properties. Das Mapping hat folgenden Aufbau:
- ([ name: wert; flags; set_method; query_method,
- name2: ... ]);
-
-
-BEMERKUNGEN
-===========
-
- - diese Funktion wird von restore_object() und save_object()
- - F_QUERY_METHODs und _query_'prop'()-Methoden haben keine Auswirkung
- auf die Wertefelder!
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: SetProp(L), QueryProp(L), Set(L), Query(L)
- Generell: SetProperties(L)
- Konzept: properties, /std/thing/properties.c
-
-1.Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/QueryQuest b/doc/sphinx/man/lfun/QueryQuest
deleted file mode 100644
index 338ed77..0000000
--- a/doc/sphinx/man/lfun/QueryQuest
+++ /dev/null
@@ -1,53 +0,0 @@
-
-QueryQuest()
-************
-
-
-FUNKTION
-========
-
- int QueryQuest(string questname)
-
-
-DEFINIERT IN
-============
-
- /std/player/quests.c
-
-
-ARGUMENTE
-=========
-
- questname
- Questname, wie er im Questmaster eingetragen wurde.
-
-
-RUeCKGABEWERT
-=============
-
- (Die Defines fuer den Rueckgabewert finden sich in
- /secure/questmaster.h)
- 1 : Spieler hat die Quest bereits geloest (OK)
- 0 : Ungueltiger Questname oder der Spieler
- hat die Quest noch nicht. (QQ_KEY_INVALID)
- 2 : Gaeste koennen keine Quest loesen (QQ_QUEST)
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann getestet werden, ob ein Spieler eine
- bestimmte Quest bereits geloest hat. Als Questname wird dazu
- der Name angegeben, der im Questmaster eingetragen wurde.
-
- Wer sich da nicht sicher ist, kann mit dem Questtool
- (/obj/tools/questtool) nachsehen.
-
-
-SIEHE AUCH
-==========
-
- /secure/questmaster.h, /obj/tools/questtool
- GiveQuest
-
-Zuletzt geaendert: Mon, 17. Jul 2000, 12:16:41 von Zook.
diff --git a/doc/sphinx/man/lfun/QueryQuestTime b/doc/sphinx/man/lfun/QueryQuestTime
deleted file mode 100644
index 9b93c8d..0000000
--- a/doc/sphinx/man/lfun/QueryQuestTime
+++ /dev/null
@@ -1,48 +0,0 @@
-
-QueryQuestTime()
-****************
-
-
-FUNKTION
-========
-
- int QueryQuestTime(string questname)
-
-
-DEFINIERT IN
-============
-
- /std/player/quests.c
-
-
-ARGUMENTE
-=========
-
- questname
- Questname, wie er im Questmaster eingetragen wurde.
-
-
-RUeCKGABEWERT
-=============
-
- Questzeitpunkt in Sekunden seit Epoch als positiver Integer-Wert
- 0 : Tagebuchmaster hat keine Daten in den Logfiles gefunden und
- macht das auf diese Weise kenntlich
- -1 : Questzeitpunkt unbekannt
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann der Zeitpunkt abgefragt werden, zu
- dem ein Spieler eine bestimmte Quest geloest hat.
- Als Questname wird dazu der Name angegeben, der im Questmaster
- eingetragen ist.
-
-
-SIEHE AUCH
-==========
-
- GiveQuest(L), QueryQuest(L), ModifyQuestTime(L)
-
-Zuletzt geaendert: 19. Dez. 2015, Arathorn
diff --git a/doc/sphinx/man/lfun/QueryRealAttribute b/doc/sphinx/man/lfun/QueryRealAttribute
deleted file mode 100644
index 246008f..0000000
--- a/doc/sphinx/man/lfun/QueryRealAttribute
+++ /dev/null
@@ -1,47 +0,0 @@
-
-QueryRealAttribute()
-********************
-
-
-FUNKTION
-========
-
- int QueryRealAttribute(string attr)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- attr - das interessierende Attribut
-
-
-BESCHREIBUNG
-============
-
- Das reale Attribut (ohne Offsets) wird zurueckgegeben.
-
-
-BEISPIELE
-=========
-
- if(this_player()->QueryRealAttribute(A_INT)>15)
- write("Du bist auch so ganz schoen clever.\n");
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/lfun/QuerySellValue b/doc/sphinx/man/lfun/QuerySellValue
deleted file mode 100644
index 4d5a518..0000000
--- a/doc/sphinx/man/lfun/QuerySellValue
+++ /dev/null
@@ -1,54 +0,0 @@
-
-QuerySellValue()
-****************
-
-
-FUNKTION
-========
-
- varargs int QuerySellValue(object ob, object client);
-
-
-DEFINIERT IN
-============
-
- /std/trading_price.c
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion kann dazu genutzt werden, den Verkaufspreis in einem
- Laden global zu veraendern. Sofern dies zugunsten der Spieler geschieht,
- muss dafuer die Zustimmung des zustaendigen Regionsmagiers und der
- Balance eingeholt werden. Zudem sollte es nicht in jedem x-beliebigen
- Laden genutzt werden, sondern nur in recht abgelegenen Gebieten, in
- die man nicht einfach skripten kann.
-
- Ein Beispiel ist der Laden auf dem Kutter in Port Vain, der nur in
- laengeren Intervallen mal zugaenglich ist.
-
-
-BEISPIEL
-========
-
- Ein Laden zahlt 10% ueber dem normalen Verkaufspreis:
-
- private int sell_factor = 110;
-
- varargs int QuerySellValue(object ob, object client) {
- // Es wird nicht naeher geprueft, ob <ob> ein gueltiger Objektpointer
- // ist, da der Laden selbst sicherstellt, dass das so ist. Wenn
- // das doch einmal nicht der Fall sein sollte, liegt der Fehler
- // woanders. Einen Bug auszuloesen ist dann sinnvoll.
-
- // Basispreis ermitteln
- int preis = ::QuerySellValue(ob, client);
- // und den Bonus aufschlagen.
- preis = (sell_factor * preis)/100;
-
- // Nicht mehr auszahlen, als das Objekt an sich wert ist.
- return min(preis, ob->QueryProp(P_VALUE));
- }
-
-LETZTE AENDERUNG: 18-Jun-2015, Arathorn
diff --git a/doc/sphinx/man/lfun/QuerySkill b/doc/sphinx/man/lfun/QuerySkill
deleted file mode 100644
index 0978df1..0000000
--- a/doc/sphinx/man/lfun/QuerySkill
+++ /dev/null
@@ -1,56 +0,0 @@
-
-QuerySkill()
-************
-
-
-FUNKTION
-========
-
- public varargs mapping QuerySkill(string sname, string gilde)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
-
-
-ARGUMENTE
-=========
-
- string sname Name des abzufragenden Skill
- string gilde Name der Gilde, unter der der Skill gesucht werden soll
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert das Skillmappings des Skills 'snme' im Lebewesen
- zurueck. Diese enthaelt Eintraege, die in der Man-Page skill_info_liste
- beschrieben sind.
-
- Falls 'gilde' nicht angegeben wird, wird der Skill zuerst fuer die Gilde
- P_GUILD des Lebewesens gesucht, ansonsten in den allgemeinen Skills
- "ANY" (es wird NICHT in Gildenobjekt oder Spellbook etwas abgefragt).
-
-
-RUECKGABEWERT
-=============
-
- Ein Mapping mit Skillinfos oder 0, falls der Skill nicht vorhanden ist.
- Das Mapping ist eine Kopie.
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/QuerySkillAbility b/doc/sphinx/man/lfun/QuerySkillAbility
deleted file mode 100644
index fd8666f..0000000
--- a/doc/sphinx/man/lfun/QuerySkillAbility
+++ /dev/null
@@ -1,47 +0,0 @@
-
-QuerySkillAbility()
-*******************
-
-
-FUNKTION
-========
-
- public varargs int QuerySkillAbility(string sname, string gilde)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
-
-
-ARGUMENTE
-=========
-
- string sname Name des abzufragenden Skill
- string gilde Gilde, unter der der Skill gesucht werden soll
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert einen Wert zurueck, der aussagt, wie gut das
- Lebewesen den Skill 'sname' beherrscht (Key SI_SKILLABILITY im
- Skillmapping).
- Dieser Wert kann zwischen -MAX_ABILITY und MAX_ABILITY liegen,
- normal ist 0 bis MAX_ABILITY (10000 - Skill perfektioniert).
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/QuerySkillAttribute b/doc/sphinx/man/lfun/QuerySkillAttribute
deleted file mode 100644
index 1b3a71e..0000000
--- a/doc/sphinx/man/lfun/QuerySkillAttribute
+++ /dev/null
@@ -1,87 +0,0 @@
-
-QuerySkillAttribute()
-*********************
-
-
-FUNKTION
-========
-
- public int QuerySkillAttribute(string atrname)
-
-
-DEFINIERT IN
-============
-
- /std/living/skill_attributes.c
-
-
-ARGUMENTE
-=========
-
- string atrname Name des abzufragenden Attributs
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann man den Wert bestimmter Attribute
- abfragen, dabei werden das abgefragte Attribut, Todesfolgen,
- SA_QUALITY und Werte in P_SKILL_ATTRIBUTE_OFFSETS
- beruecksichtigt.
-
-
-
- Momentane Skills siehe ModifySkillAttribute.
-
-
-RUECKGABEWERT
-=============
-
- Der Wert des Attributs. Ist nichts bestimmtes gesetzt, wird
- der Standardwert 100 zurueckgegeben.
- Der Rueckgabewert liegt zwischen 10 bis 1000 (Prozent).
-
-
-BEMERKUNG
-=========
-
- Die Funktion ist zwar als 'varargs' definiert, gibt man allerdings
- keinen Attributnamen an, wird immer 100 zurueckgegeben.
-
-
-BEISPIEL
-========
-
- // ein Spieler kann ein Stueck Kaese stibitzen, wenn er schnell
- // genug ist ... (15% ueber normal)
- if(this_player()->QuerySkillAttribute(SA_SPEED)>=115) {
- tell_object(this_player(),
- "Du schnappst das Stueck Kaese aus der Falle.\n");
- obj kaese = clone_object(...);
- [...]
- } else {
- mapping amap=map_indices(VALID_ARMOUR_CLASS,#'!);
- amap[AT_GLOVE]=100;
- tell_object(this_player(),
- "Du bist zu langsam und die Falle schnappt hungrig zu.\n");
- this_player()->Defend(random(100),
- ({DT_PIERCE, DT_SQUEEZE}),
- ([SP_PHYSICAL_ATTACK: 1,
- SP_REDUCE_ARMOUR: amap,
- SP_SHOW_DAMAGE: 0]));
- }
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/QuerySkillAttributeModifier b/doc/sphinx/man/lfun/QuerySkillAttributeModifier
deleted file mode 100644
index 055815e..0000000
--- a/doc/sphinx/man/lfun/QuerySkillAttributeModifier
+++ /dev/null
@@ -1,118 +0,0 @@
-
-QuerySkillAttributeModifier()
-*****************************
-
-
-FUNKTION
-========
-
- public varargs mapping QuerySkillAttributeModifier(object caster,
- string *atrnames)
-
-
-DEFINIERT IN
-============
-
- /std/living/skill_attributes.c
-
-
-ARGUMENTE
-=========
-
- <caster> object
- Objekt, welches die gesuchten Mods gesetzt hat
-
- <atrnames> string*
- Array von Skill-Attributen, welche durchsucht werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert alle Mods von <caster> auf den Skill-
- Attributen <atrnames> in einem Mapping zurueck.
- Wird <atrnames> nicht angegeben oder ist ein leeres Array, werden alle
- Skill-Attribute nach Mods abgesucht.
- Wird <caster> nicht angeben oder ist 0, so werden alle Mods der
- gewuenschten Skill-Attribute geliefert.
- Dementsprechend bekommt man alle Mods aller Skill-Attribute, wenn keins
- von beidem angegeben wird.
-
-
-RUECKGABEWERT
-=============
-
- ([]), falls keine Modifikatoren gefunden wurden.
- In anderen Faellen ist die Datenstruktur des Mappings wie folgt:
- ([ atrname1: ([ <caster>: <value>; <duration> ]),
- atrname2: ([ <caster>: <value>; <duration> ]) ])
- Die Schluessel im Mapping sind die jeweiligen Skill-Attribute, die Werte
- des Mappings sind erneut Mappings, welche als Schluessel die Objekte
- haben, welche die Mods gesetzt haben. In diesem Mapping gehoeren zu jedem
- Schluessel zwei Werte, den Wert des Modifikators und die Ablaufzeit.
- <value> kann hierbei ein int oder eine closure sein, <duration> ist ein
- int, <caster> ist ein Objekt.
- Ggf. kann das innere Mapping natuerlich auch mehrere Modifikatoren
- enthalten (also caster1, caster2, usw.).
-
-
-BEMERKUNGEN
-===========
-
-
-BEISPIELE
-=========
-
- Ein Objekt moechte seinen bestehenden Modifikator um 20 und die
- Gueltigkeit um 13 erhoehen.
- mapping res = ob->QuerySkillAttributeModifier(this_object(),
- ({SA_DAMAGE}) );
- if (member(res, SA_DAMAGE) && member(res[SA_DAMAGE], this_object())) {
- // alten Mod ueberschreiben und Werte dabei anheben.
- ob->ModifySkillAttributeModifier(SA_DAMAGE,
- res[SA_DAMAGE][this_object(),0] + 20,
- res[SA_DAMAGE][this_object(),1] + 13 );
- }
- else
- // neuen Mod setzen.
- ob->ModifySkilAttributeModifier(SA_DAMAGE, 20, 13);
-
-
-
- Ein Objekt hat den Fluch der unpraezisen Schnelligkeit, welcher SA_DAMAGE
- reduziert, sofern das Lebewesen einen positiven Modifikator auf SA_SPEED
- hat:
- mapping res = ob->QuerySkillAttributeModifier(0, ({SA_SPEED}) );
- if (member(res, SA_SPEED) {
- int val, int dur;
- foreach(object caster, int v, int d: res[SA_SPEED]) {
- // groessten Mod rausfinden, dabei keine closures
- // beruecksichtigen.
- if (intp(v) && v>val) {
- val=v;
- dur=d;
- }
- }
- if (val > 0) {
- // pos. Mod auf SA_SPEED gefunden, entsprechenden neg. Mod auf
- // SA_DAMAGE setzen, der zum gleichen Zeitpunkt ungueltig wird
- // wie der Mod auf SA_SPEED.
- if (ob->ModifySkillAttribute(SA_DAMAGE, -val, dur) == SA_MOD_OK)
- tell_object(ob, "tolle Fluchmeldung.");
- }
- }
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
-
-14.08.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/QuerySkillBonus b/doc/sphinx/man/lfun/QuerySkillBonus
deleted file mode 100644
index 1cb82e8..0000000
--- a/doc/sphinx/man/lfun/QuerySkillBonus
+++ /dev/null
@@ -1,91 +0,0 @@
-
-QuerySkillBonus()
-*****************
-
-
-FUNKTION
-========
-
- int QuerySkillBonus(object caster, object target, mapping sinfo)
-
-
-DEFINIERT IN
-============
-
- beliebigen Objekten
-
-
-ARGUMENTE
-=========
-
- object caster
- der Benutzer eines Skills/Spells (Lebewesen)
- object target
- das Ziel eines Skills/Spells (beliebiges Objekt oder 0)
- mapping sinfo
- das Skillinfomapping
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird von der Gilde des Casters im Environment und ggf.
- auch im Ziel eines Skills/Spells gerufen.
- Die Gilde uebergibt neben Caster und Ziel ein Mapping mit Skillinfos (s.
- SI Konstanten aus new_skills.h fuer Details), welches alle wesentlichen
- Informationen ueber den benutzten Skill/Spell enthaelt.
-
- QuerySkillBonus() liefert einen Bonus (oder Malus) zurueck, den der
- Aufrufer als Faktor in der Berechnung des Effekts des Skills
- beruecksichtigen kann (aber nicht muss).
- Der Bonus/Malus wird hierbei als ganzzahliger 0.01-Prozentwert aufgefasst
- (10000 == 100% == keine Veraenderung, 1 == 0.01%).
-
- Diese Funktion kann in beliebigen Objekten (re-)definiert werden. Im
- Falle mobiler Objekte oder anhaltender Effekte ist jedoch eine
- Balancegenehmigung erforderlich, sofern kampfrelevante Skills beeinflusst
- werden.
- Eine flaechendeckende Reduzierung von Skills/Gildenfaehigkeiten ist
- explizit _nicht_ erwuenscht und soll auf einzelne Raeume und Objekte
- beschraenkt sein.
-
-
-BEMERKUNGEN
-===========
-
- Das Mapping <sinfo> kann in dieser Funktion geaendert werden. Dieses kann
- allerdings sehr weitreichende Folgen haben, speziell bei mangelnden
- Kenntnissen ueber Interna des Skillsystems. Daher bitte von Aenderungen
- absehen bzw. vorher mit dem jeweiligen Gildenmagier und/oder der
- Gildenbalance abklaeren.
- Die Bedeutung der Werte in <sinfo> kann je nach Gilde variieren. Im
- Zweifelsfall bitte bei den jeweiligen Gildenmagiern nachfragen.
- Die Gilde kann diese Funktion rufen, muss aber nicht. Ebenso kann sie das
- Ergebnis beruecksichtigen, muss aber nicht.
-
-
-BEISPIELE
-=========
-
- In einem Raum sollen Heilzauber besonders effizient sein:
- int QuerySkillBonus(object caster, object target, mapping sinfo) {
- if (pointerp(sinfo[SI_MAGIC_TYPE])
- && member(sinfo[SI_MAGIC_TYPE], MT_HEILUNG) > -1)
- {
- return 12000 + random(3000); // bonus von 120-150%
- }
- return 10000;
- }
-
-
-SIEHE AUCH
-==========
-
- gilden-doku
- <new_skills.h>
-
-
-LETZTE AeNDERUNG
-================
-
-19.08.2013, Zesstra
diff --git a/doc/sphinx/man/lfun/QueryStorageRoom b/doc/sphinx/man/lfun/QueryStorageRoom
deleted file mode 100644
index 4442237..0000000
--- a/doc/sphinx/man/lfun/QueryStorageRoom
+++ /dev/null
@@ -1,27 +0,0 @@
-
-QueryStorageRoom()
-******************
-
-QueryStorageRoom()
-
-Funktion
- string QueryStorageRoom()
-
-Definiert in
- /std/room/shop
-
-Rueckgabewert
- Dateiname des Lagers, in dem die aufgekauften Gegenstaende
- aufbewahrt werden.
-
-Siehe auch
- Funktionen
- AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
- QueryBuyValue(), QueryBuyFact(), sell_obj(), buy_obj()
-
- Properties
- P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
-
-
-Letzte Aenderung 21.05.2014, Bugfix
-===================================
diff --git a/doc/sphinx/man/lfun/QueryTimedAttrModifier b/doc/sphinx/man/lfun/QueryTimedAttrModifier
deleted file mode 100644
index 4d858a8..0000000
--- a/doc/sphinx/man/lfun/QueryTimedAttrModifier
+++ /dev/null
@@ -1,67 +0,0 @@
-
-QueryTimedAttrModifier()
-************************
-
-
-FUNKTION
-========
-
- mapping QueryTimedAttrModifier(string key)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- key - aus P_TIMED_ATTR_MOD abzufragender Eintrag
-
-
-BESCHREIBUNG
-============
-
- Der zu key gehoerende Eintrag in P_TIMED_ATTR_MOD wird abgefragt.
-
-
-RUeCKGABEWERT
-=============
-
- Ein leeres Mapping im Falle eines fehlerhaften key-Argumentes oder
- eines nicht existenten Keys.
-
-
-
- Ansonsten wird ein Mapping der Form
-
-
-
- ([
- Key : ([ Mapping mit den Modifikatoren ]) ;
- Ablaufzeit ; Ablaufobjekt ; Nachrichtenempfaenger
- ])
-
- zurueckgegeben.Die Ablaufzeit ist hierbei die Zeit in Sekunden seit
- dem 1. Jan 1970, 0.0:0 GMT, das Ablaufobjekt ist das Objekt an dessen
- Existenz die Attributveraenderungen gebunden ist und der
- Nachrichtenempfaenger ist dasjenigen Objekte welches im Falle
- durch den Aufruf von "NotifyTimedAttrModExpired" benachrichtigt
- wird sobald das Attribut abgelaufen ist.
- Der Funktion NotifyTimedAttrModExpired wird als Argument der key
- der abgelaufenen Attributveraenderung uebergeben.
- Das Mapping ist eine Kopie der Originaldatenstruktur zu diesem Key.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/lfun/QueryTotalQP b/doc/sphinx/man/lfun/QueryTotalQP
deleted file mode 100644
index 1471010..0000000
--- a/doc/sphinx/man/lfun/QueryTotalQP
+++ /dev/null
@@ -1,43 +0,0 @@
-
-QueryTotalQP()
-**************
-
-
-FUNKTION
-========
-
- int QueryTotalQP()
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUECKGABEWERT
-=============
-
- Abenteuerpunkte saemtlicher Quests
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert die Abenteuerpunkte der saemtlicher aktivierter
- Quests zurueck.
-
-
-SIEHE AUCH
-==========
-
- GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
- QueryMaxQP, QueryOptQP
-
-Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
diff --git a/doc/sphinx/man/lfun/QueryUser b/doc/sphinx/man/lfun/QueryUser
deleted file mode 100644
index ad1e4fa..0000000
--- a/doc/sphinx/man/lfun/QueryUser
+++ /dev/null
@@ -1,77 +0,0 @@
-
-QueryUser()
-***********
-
-
-FUNKTION
-========
-
- public object QueryUser()
-
-
-DEFINIERT IN
-============
-
- /std/npc/combat.c
- /std/clothing/wear.c
- /std/weapon/combat.c
- alle Objekte, in denen es darueber hinaus noetig ist
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Liefert den aktuellen Nutzer (Lebewesen) eines Items oder NPCs.
-
-
-
- Diese Funktion wird z.B. von get_killing_player() benutzt, um
- herauszufinden, zu welchem Spieler denn das Objekt gehoert, was den
- toedlichen Schaden verursacht hat.
-
- Im Falle eines NPCs ist dies standardmaessig der Spieler, bei dem der
- NPC als Helfer-NPC eingetragen ist (s. RegisterHelperNPC).
- Im Falle einer Ruestung ist es das Lebewesen, welches sie gerade traegt.
- Im Falle einer Waffe ist es das Lebewesen, welches sie gerade gezueckt
- hat.
- Alle anderen Objekte enthalten keinen Default fuer diese Funktion.
-
-
-RUeCKGABEWERT
-=============
-
- Das nutzende Lebewesen, falls es ermittelt werden konnte, sonst 0.
-
-
-BEMERKUNGEN
-===========
-
- Sollte in allen Objekten definiert werden, welche Lebewesen Schaden
- zufuegen, ohne dass das verursachende Lebewesen dabei als Feind im
- Defend() angeben wird.
- Der gelieferte Nutzer muss explizit kein Spieler sein. Es waere z.B.
- moeglich, dass von einem Spieler kontrollierter NPC einen Bumerang nutzt.
-
-
-BEISPIELE
-=========
-
- Ein von einem Spieler beschworenes Wesen wirft einen Bumerang nach einem
- Feind.
- Dann liefert QueryUser() im Bumerang den NPC als Nutzer und
- QueryUser() im NPC wiederum den Spieler.
-
-
-SIEHE AUCH
-==========
-
- RegisterHelperNPC(), get_killer_player()
- P_WORN, P_WIELDED
-
-12.11.2013, Zesstra
diff --git a/doc/sphinx/man/lfun/QueryValidObject b/doc/sphinx/man/lfun/QueryValidObject
deleted file mode 100644
index 649a0b2..0000000
--- a/doc/sphinx/man/lfun/QueryValidObject
+++ /dev/null
@@ -1,69 +0,0 @@
-
-QueryValidObject()
-******************
-
-
-FUNKTION
-========
-
- public int QueryValidObject(string oname);
-
-
-DEFINIERT IN
-============
-
- /std/virtual/v_compiler.c
-
-
-ARGUMENTE
-=========
-
- oname
- Objektname, der geprueft werden soll (kompletter Pfad mit / am Anfang)
-
-
-RUeCKGABEWERT
-=============
-
- <=0 - falls VC nicht zustaendig ist.
- >0 - falls der VC sich fuer das Objekt zustaendig erklaert.
-
-
-BESCHREIBUNG
-============
-
- Ueber die Funktion laesst sich herausfinden, ob ein VC sich fuer das
- gewuenschte Objekt zustaendig fuehlt. Dabei wird Validate(),
- P_COMPILER_PATH, NoParaObjects() und P_PARA im VC ausgewertet:
- 1. Zuerst wird mit Validate() geprueft, ob der Filename (ohne Pfad) ok ist.
- 2. wird geguckt, ob das angefragte Objekt im richtigen Pfad liegt
- (P_COMPILER_PATH).
- 3. wenn das angefragte Objekt ein Para-Objekt ist:
- a) wird NoParaObjects() geprueft, wenn das !=0 ist, sind gar keine Para-
- Objekte erlaubt.
- b) wird P_PARA _im VC_ abgefragt, dort kann man ein Array aller
- erlaubten Para-Dimensionen reinschreiben. Fuer alle anderen erklaert
- sich der VC fuer nicht zustaendig. Wenn P_PARA nicht gesetzt ist,
- sind alle erlaubt. Ein leeres Array ({}) wuerde einem
- NoParaObjects() {return 1;} entsprechen.
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion wird vom move abgefragt. Bitte auf jeden Fall P_PARA oder
- NoParaObjects() passend definieren, sonst buggts.
-
- Wenn jemand mit dem oben beschrieben Standardverhalten nicht gluecklich
- ist, kann man die Funktion passend ueberschreiben.
-
-
-SIEHE AUCH
-==========
-
- virtual_compiler
- CustomizeObject(), Validate(), NoParaObjects(),
- P_COMPILER_PATH, P_PARA
- /std/virtual/v_compiler.c
-
-21.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/ReceiveMsg b/doc/sphinx/man/lfun/ReceiveMsg
deleted file mode 100644
index cd1a34d..0000000
--- a/doc/sphinx/man/lfun/ReceiveMsg
+++ /dev/null
@@ -1,278 +0,0 @@
-
-ReceiveMsg()
-************
-
-ReceiveMsg()
-
-public varargs int ReceiveMsg(string msg, int msg_typ, string
-msg_action,
- string msg_prefix, mixed origin)
-
-
-DEFINIERT IN
-============
-
- /std/living/comm.c
- /std/npc/comm.c
- /std/player/comm.c
- /std/room/items.c
-
-
-ARGUMENTE
-=========
-
- string msg
- String mit der uebermittelten Nachricht. Muss nicht umgebrochen sein,
- da ReceiveMsg() das ebenfalls erledigt.
- int msg_typ
- Nachrichtentyp(en) fuer Filterung und Flags fuer Behandlung/Umbruch.
- Siehe unten fuer mit | kombinierbare Konstanten.
- string msg_action (optional)
- Ausloesende Aktion, wird auch fuer Ignorieren verwendet.
- Default ist query_verb(). Siehe unten fuer alternative Konstanten.
- string msg_prefix (optional)
- String, welcher ggf. im break_string() als indent verwendet wird.
- Default ist 0 (kein Indent)
- mixed origin (<object>) (optional)
- Das die Meldung ausloesende Objekt, wird fuer Ignorieren verwendet.
- Default: previous_object()
-
-
-BESCHREIBUNG
-============
-
- ReceiveMsg() wird benutzt, um einem Lebewesen eine Nachricht zu senden.
- Dabei ruft es das sonst uebliche tell_object() fuer Spieler bzw.
- catch_tell() im NPC auf.
-
- Gerade fuer Nachrichten an Spieler bietet die Methode weitere Features,
- die bisher sonst haendisch zu implementieren waren:
- 1) Pruefung auf Empfangbarkeit, je nach 'msg_typ', zB
- MT_LOOK nur an Nichtblinde
- MT_LISTEN nur an Nichttaube
- MT_DEBUG nur an Magier/Testspieler
- 2) Pruefen auf Ignorieren von
- - Aktion ('msg_action')
- - mit 'msg_action' || query_verb()
- - Urheber ('origin')
- - fuer sendende Spieler mit origin->query_realname()
- - fuer sendende NPCs mit origin->Name(RAW))
- 3) Speicherung in der tmhist (Typ MT_COMM)
- 4) Speicherung im Kobold (Typ MT_COMM + aktiver Kobold)
- 5) Umbrechen unter Beruecksichtigung von indent, 'msg_typ'-Flags
- fuer Umbruch und P_PREPEND_BS
-
- Raeume definieren standardmaessig ebenfalls ein ReceiveMsg(), welches in
- jedem Objekt im Raum ReceiveMsg() mit den uebergebenen Argumenten aufruft.
- In diesem Fall ist der Rueckgabe der kleinste von allen gerufenen
- ReceiveMsg() zurueckgelieferte Wert.
-
-
-RUeCKGABEWERT
-=============
-
- > 0 fuer Erfolg, < 0 fuer Misserfolg, s.u.
- MSG_DELIVERED bei erfolgreicher Zustellung
- MSG_BUFFERED bei Zwischenspeicherung durch den Kobold
-
- MSG_FAILED nicht naeher spezifizierter Fehler bei Zustellung
- MSG_IGNORED Nachricht wurde ignoriert (Absender, origin)
- MSG_VERB_IGN Nachricht wurde ignoriert (Kommandoverb, msg_action)
- MSG_MUD_IGN Absendendes Mud wurde ignoriert.
- MSG_SENSE_BLOCK Passende Sinne des Empfaenger sind blockiert (z.B.
- blind, taub)
- MSG_BUFFER_FULL Kobold kann sich nichts mehr merken
-
-
-BEMERKUNGEN
-===========
-
- Fuer saemtliche Alternativmeldungen im Falle einer nicht erfolgreich
- zugestellten Nachricht ist der Aufrufer von ReceiveMsg() verantwortlich.
-
- NPCs:
- * ReceiveMsg() ruft zwecks Abwaertskompatibilitaet catch_tell() auf
- * empfohlen ist, in NPCs nun ReceiveMsg() zu ueberschreiben.
- * catch_tell() muss weiterhin fuer andere tell_object()
- ueberschrieben werden
-
-
-BEISPIELE
-=========
-
- #1.1 Nachricht an einen Spieler, zB in der Wueste
- this_player()->ReceiveMsg("Die Sonne brennt dir auf den Kopf.",
- MT_FEEL|MT_LOOK);
-
- #1.2 Nachricht an einen Spieler von einem NPC mit Indent
- // bei aktivem Editor+Kobold landet dieser Text auch im Kobold
- this_player()->ReceiveMsg("Du haust ja ganz schoen rein!",
- MT_COMM|MT_FAR|MSG_DONT_STORE,
- MA_TELL,
- "Arkshat teilt dir mit: ");
-
- #1.3 Nachricht an einen Spieler mit Fallback-Kaskade
- // Achtung, bei MT_COMM oder Ignorieren gibt es natuerlich auch
- // Misserfolgs-Rueckgaben. Bei einem normalen Kommando wie diesem
- // hier ist das unproblematisch und daher sinnvoll:
- if(this_player()->ReceiveMsg(
- "Du drueckst den Knopf und es oeffnet sich knirschend "
- "ein kleines Fach in der Wand.", MT_LOOK) < MSG_DELIVERED &&
- this_player()->ReceiveMsg(
- "Du drueckst den Knopf und irgend etwas scheint sich "
- "knirschend zu oeffnen. Das Geraeusch kam von der Wand.",
- MT_LISTEN) < MSG_DELIVERED) // leider blind UND taub ... also:
- this_player()->ReceiveMsg(
- "Du drueckst den Knopf und irgend etwas scheint zu passieren, "
- "aber leider siehst und hoerst du nichts.", MT_FEEL);
-
-
- #2.1 Im NPC als Empfaenger auf ein TM reagieren
- public varargs int ReceiveMsg(string msg, int msg_typ, string msg_action,
- string msg_prefix, mixed origin) {
- int ret = MSG_DELIVERED; // Default
-
- // eine OOC-Kommunikation?
- if(msg_typ&MT_COMM) {
- if(strstr(msg, "hilfe")>=0)
- if(environment(origin)==environment()) {
- origin->ReceiveMsg("Ich werd dir gleich helfen!",
- MT_COMM|MSG_DONT_STORE, MA_TELL,
- "Arkshat teilt dir mit: ");
- } else {
- origin->ReceiveMsg("Hilf dir selbst, dann hilft dir Gott!",
- MT_COMM|MT_FAR|MSG_DONT_STORE,
- MA_TELL,
- "Arkshat teilt dir mit: ");
- }
- else if(...)
- [...]
- } else if(msg_typ&MT_LISTEN && msg_action==MA_SAY) {
- [...]
- }
-
- return ret;
- }
-
-
- #3.1 als Sender an viele, Variante mit eigenem filter
- // Achtung: siehe 3.3. send_room() loest vieles.
- // Living nickt nur seinen Nichtgegnern zu
- object *all = filter(all_inventory(environment(this_player())),
- #'living) - ({this_player()});
- all -= this_player()->PresentEnemies();
- all->ReceiveMsg(this_player()->Name()+
- " nickt dir verstohlen zu und scheint bereit.",
- MT_LOOK, MA_EMOTE);
-
- #3.2 als Sender an viele, Variante mit einzelnem Iterieren
- // Achtung: siehe 3.3. send_room() loest vieles.
- // Living trinkt etwas, jeder im Raum soll es sehen oder hoeren
- object ob = first_inventory(environment(this_player()));
- do {
- if(living(ob) && ob!=this_player())
- ob->ReceiveMsg(this_player()->Name()+" trinkt einen Schnaps aus.",
- MT_LOOK|MT_LISTEN,
- MA_DRINK);
- ob = next_inventory(ob);
- } while(ob);
-
- #3.3 als Sender an viele, Variante mit send_room
- // Living gruesst seine Freunde
- // send_room() ruft ReceiveMsg mit allen entsprechenden Parametern
- object *exclude = this_player()->PresentEnemies();
- send_room(this_object(),
- this_player()->Name()+" gruesst dich.",
- MT_LOOK|MT_LISTEN,
- MA_EMOTE,
- 0,
- exclude);
-
- #3.4 als Sender an viele mit send_room und ReceiveMsg()
- // Living gruesst seine Freunde, seine Feinde sehen das
- // send_room() ruft ReceiveMsg mit allen entsprechenden Parametern
- object *exclude = this_player()->PresentEnemies();
- send_room(this_object(),
- this_player()->Name()+" gruesst dich.",
- MT_LOOK|MT_LISTEN, MA_EMOTE, 0, exclude);
- exclude->ReceiveMessage(
- this_player()->Name()+" gruesst, aber nicht dich.",
- MT_LOOK|MT_LISTEN, MA_EMOTE);
-
-
-KONSTANTEN FUER PARAMETER
-=========================
-
- Saemtlich in "/sys/living/comm.h". Hier nicht notwendigerweise
- immer aktuell oder vollstaendig.
-
- <msg_typ>
- MT_UNKNOWN unspez. Nachrichtentyp (nicht verwenden). Es wird
- versucht, aufgrund <msg_action> den Typ zu erraten.
- MT_LOOK alles, was man sieht
- MT_LISTEN alles, was man hoert
- MT_FEEL alles, was man fuehlt
- MT_TASTE alles, was man schmeckt
- MT_SMELL alles, was man riecht
- MT_MAGIC alle sonstigen (uebersinnlichen) Wahrnehmungen
- MT_NOTIFICATION Statusmeldungen, Kommandobestaetigungen
- MT_COMM alle OOC-Kommunikation, d.h. nicht durch o.g. Sinne
- abgedeckt.
- MT_FAR alles, was aus der Ferne / einem anderen Raum kommt.
- muss mit min. einem anderen Typ kombiniert werden
- MT_DEBUG Debugmeldungen, sehen nur Magier im Magiermodus
- MT_NEWS Mails & MPA
-
- MSG_DONT_BUFFER Nachricht darf nicht im Kobold gespeichert werden
- MSG_DONT_STORE Nachricht darf nicht in die Comm-History
- MSG_DONT_WRAP Nachricht nicht per break_string umbrechen
- MSG_DONT_IGNORE Nachricht kann nicht ignoriert werden
-
- MSG_BS_LEAVE_LFS wie BS_LEAVE_MY_LFS fuer break_string()
- MSG_BS_SINGLE_SPACE wie BS_SINGLE_SPACE fuer break_string()
- MSG_BS_BLOCK wie BS_BLOCK fuer break_string()
- MSG_BS_NO_PARINDENT wie BS_NO_PARINDENT fuer break_string()
- MSG_BS_INDENT_ONCE wie BS_INDENT_ONCE fuer break_string()
- MSG_BS_PREP_INDENT wie BS_PREPEND_INDENT fuer break_string()
-
- <msg_action> (optional)
- MA_UNKNOWN Unspez. Aktion. Es wird der Default query_verb()
- benutzt bzw. versucht, die Aktion zu erraten.
- MA_PUT Jemand legt etwas hin und gibt jemanden etwas
- MA_TAKE Jemand nimmt etwas
- MA_MOVE_IN Jemand betritt den Raum
- MA_MOVE_OUT Jemand verlaesst den Raum
- MA_MOVE Jemand bewegt sich
- MA_FIGHT Jemand kaempft
- MA_WIELD Jemand zueckt eine Waffe
- MA_UNWIELD Jemand steckt eine Waffe weg
- MA_WEAR Jemand zieht etwas an
- MA_UNWEAR Jemand zieht etwas aus
- MA_EAT Jemand isst etwas
- MA_DRINK Jemand trinkt etwas
- MA_SPELL Jemand wirkt einen Spell
- MA_LOOK Jemand sieht etwas an, untersucht etwas
- MA_LISTEN Jemand horcht oder lauscht an etwas
- MA_FEEL Jemand betastet etwas
- MA_SMELL Jemand schnueffelt herum
- MA_SENSE Jemand macht eine uebersinnliche Wahrnehmung
- MA_READ Jemand liest etwas
- MA_USE Jemand benutzt etwas
- MA_SAY Jemand sagt etwas
- MA_REMOVE Etwas verschwindet
- // MA_CHAT Chatkrams (z.B. teile-mit, Teamkampfchat)
- MA_CHANNEL Ebenen
- MA_EMOTE (r)Emotes, Soulverben (remotes mit Typ MT_COMM|MT_FAR)
- MA_SHOUT Rufen (nicht: shout()!)
- MA_SHOUT_SEFUN Rufen ueber shout(SE)
-
-
-SIEHE AUCH
-==========
-
- Verwandt: send_room(SE)
- Lfuns: TestIgnore(L)
- Efuns: tell_object(E), catch_tell(L), catch_msg(L)
- query_verb(E), query_once_interactive(E), break_string(SE)
-
-13.03.2016, Zesstra
diff --git a/doc/sphinx/man/lfun/RegisterEvent b/doc/sphinx/man/lfun/RegisterEvent
deleted file mode 100644
index a664b3b..0000000
--- a/doc/sphinx/man/lfun/RegisterEvent
+++ /dev/null
@@ -1,113 +0,0 @@
-
-RegisterEvent()
-***************
-
-
-FUNKTION
-========
-
- int RegisterEvent(string eid, string fun, object listener);
-
-
-DEFINIERT IN
-============
-
- /p/daemon/eventd.c
-
-
-DEKLARIERT IN
-=============
-
- /sys/events.h
-
-
-ARGUMENTE
-=========
-
- string eid,
- Die ID des Events, fuer den man sich registrieren will. Da dieser
- String fuer alle Events jeweils eindeutig sein muss, empfiehlt es sich,
- fuer eigene Events z.B. als Praefix den eigenen Magiernamen zu nehmen,
- z.B. "zesstra_vulkanausbruch".
- ACHTUNG: IDs, die mit '_evt_lib_' beginnen, sind AUSSCHLIESSLICH der
- Mudlib vorbehalten!
- string fun,
- Name der Funktion, die im Objekt listener bei Auftreten des Events
- gerufen werden soll.
- object listener,
- Das Objekt, das als Lauscher fuer diesen Event registriert werden soll.
-
-
-BESCHREIBUNG
-============
-
- Das Objekt 'listener' wird als Lauscher dieses Events registriert. Ab
- diesem Moment wird immer dann, wenn ein Event mit der ID 'eid' ausgeloest
- wird, in 'listener' die Funktion 'fun' aufgerufen (zeitverzoegert, meist
- 0-2s).
-
-
-
- Die Funktion wird dabei immer mit 3 Argumenten aufgerufen:
- listener->fun(eid, triggerob, data);
- Hierbei ist 'eid' die jeweilige Event-ID und 'triggerob' ist das Objekt,
- welches den Event ausloeste.
- 'data' kann jeder LPC-Datentyp sein und enthaelt die Daten, die das
- triggernde Objekt an alle Listener uebermitteln will (damit sind Datentyp
- und Inhalt komplett abhaengig vom Event!)
-
- Existiert bisher noch kein Event mit der ID 'eid', wird implizit ein
- neuer Event erstellt, der erstmal nur das sich gerade registrierende
- Objekt als Lauscher hat.
-
-
-RUeCKGABEWERT
-=============
-
- 1 fuer Erfolg, <=0 fuer Misserfolg.
- 1 - Erfolg, 'listener' wurde eingetragen.
- -1 - falsche Argumente wurden uebergeben
- -2 - nicht-oeffentlicher Event und 'listener' wurde nicht fuer diesen
- Event freigegeben (momentan gibt es noch keine nicht-oeffentlichen
- Events)
- -3 - 'fun' in 'listener' ist nicht vorhanden oder nicht von aussen
- aufrufbar (protected, static, private).
-
-
-BEMERKUNGEN
-===========
-
- Wenn 'listener' bereits fuer den Event registriert wird, wird die alte
- Registrierung ueberschrieben (als ggf. gilt dann der jetzt uebergebene
- Funktionsname).
- Die Funktion 'fun' sollte sparsam mit den Eval-Ticks umgehen. Momentan
- ist die max. Menge an Ticks auf 30000 beschraenkt. Dies kann bei
- Problemen auch jederzeit reduziert werden!
- Der EVENTD merkt sich Event-Lauscher nicht ueber Reboots hinaus.
- Sollte sich eine Blueprint anmelden, sich zerstoeren und neugeladen
- werden, ist die neue Blueprint noch angemeldet, weil das neue Objekt
- unter dem alten Namen wiedergefunden wird. Dies gilt _nicht_ fuer
- Clones!
-
-
-BEISPIELE
-=========
-
- 1. Ein Objekt moechte ueber Spielertode informiert werden:
- EVENTD->RegisterEvent(EVT_LIB_PLAYER_DEATH, "spieler_ist_tot",
- this_object());
- Ab jetzt wird im Objekt jedes Mal, wenn ein Spieler stirbt, die
- Funktion "spieler_ist_tot" aufgerufen.
-
- 2. Ein Objekt will informiert werden, wenn der Event
- "boing_zwergenkoenig_angriff" ausgeloest wird:
- EVENTD->RegisterEvent("boing_zwergenkoenig_angriff","alarm",
- this_object());
-
-
-SIEHE AUCH
-==========
-
- events, eventd, UnregisterEvent(), TriggerEvent()
-
-Last modified: 15.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/RegisterHelperNPC b/doc/sphinx/man/lfun/RegisterHelperNPC
deleted file mode 100644
index f8b6a2e..0000000
--- a/doc/sphinx/man/lfun/RegisterHelperNPC
+++ /dev/null
@@ -1,114 +0,0 @@
-
-RegisterHelperNPC()
-*******************
-
-
-FUNKTION
-========
-
- public int RegisterHelperNPC(object npc, int flags);
-
-
-DEFINIERT IN
-============
-
- /std/player/combat.c
- /sys/living/combat.h
-
-
-ARGUMENTE
-=========
-
- object npc
- Objekt des helfenden NPC, der angemeldet werden soll.
-
- int flags
- ver-oder-te Konstanten, die die Art des Helfer-NPC beschreiben (s.u.)
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion wird ein einem Spieler helfender NPC im Spieler
- angemeldet. Hierdurch kann spaeter herausgefunden werden, welche NPC
- einem Spieler helfen und ggf. den von diesen verursachten Schaden im
- Kampf dem Spieler zuzurechnen.
-
- Die Flags sind eine der folgenden Konstanten oder eine beliebige durch
- ver-oder-ung gebildete Kombination.
-
- Momentan gibt es 2 Klassen von Helfer-NPC:
- + GUILD_HELPER: der Helfer-NPC ist ein Gilden-NPC
- + MISC_HELPER: der Helfer-NPC ist irgendein NPC, der nicht zu einer Gilde
- gehoert.
-
- Zusaetzlich zu den Klassen gibt es noch weitere Flags, die etwas ueber
- den Helfer-NPC sagen:
-
- + EXCLUSIVE_HELPER: dieser Helfer-NPC duldet keinen weiteren NPC der
- gleichen Klasse.
- + ACTIVE_HELPER: ist dieses Flag gesetzt, ist der NPC mehr als nur reiner
- Schlagfaenger.
-
- Wird EXCLUSIVE_HELPER gesetzt und es ist in der gleichen Klasse schon ein
- NPC angemeldet, schlaegt die Registrierung fehl.
- Ist in der gleichen Klasse bereits ein NPC mit EXCLUSIVE_HELPER
- angemeldet, schlaegt die Registierung ebenfalls fehl, auch wenn der neue
- NPC kein EXCLUSIVE_HELPER setzt.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn die Registrierung erfolgreich war.
- 0 sonst. In diesem Fall darf der NPC dem Spieler NICHT helfen, weder
- passiv (Schlagfaenger), noch aktiv.
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion setzt bei der Erfolg die Property P_HELPER_NPC in <npc>
- auf passende Werte.
- Bitte auf gar keinen Fall die numerischen Werte der Konstanten fuer
- <flags> nutzen, diese koennen sich jederzeit aendern.
-
-
-BEISPIELE
-=========
-
- 1. Ein nicht-exklusiver Gilden-NPC, der dem Spieler folgt.
- if (spieler->RegisterHelperNPC(this_object(), GUILD_HELPER) == 1) {
- move(environment(spieler), M_GO);
- spieler->AddPursuer(this_object());
- // meldung ausgebene...
- }
-
- 2a. Ein exklusiver Nicht-Gilden-NPC
- if (spieler->RegisterHelperNPC(this_object(),
- MISC_HELPER|EXCLUSIVE_HELPER) == 1) {
- move(environment(spieler), M_GO);
- }
-
- 2b. Ein nicht-exklusiver Nicht-Gilde-NPC, der nach 2a. kommt.
- if (spieler->RegisterHelperNPC(this_object(), MISC_HELPER) == 1) {
- // ... wenn der NPC aus 2a noch existiert, trifft dies hier nie zu.
- }
-
- 3. Ein exklusiver NPC, der weitere Gilden- und sonstige NPC ausschliesst
- (Solche Kombination bitte mit der Gilden-Balance abstimmen.)
- if (spieler->RegisterHelperNPC(this_object(),
- MISC_HELPER|GUILD_HELPER|EXCLUSIVE_HELPER) == 1) {
- move(environment(spieler), M_GO);
- }
-
- 4. Die Registrierung ohne Klasse schlaegt fehl, z.B.:
- spieler->RegisterHelperNPC(this_object(), 0);
- spieler->RegisterHelperNPC(this_object(), EXCLUSIVE_HELPER);
-
-
-SIEHE AUCH
-==========
-
- UnregisterHelperNPC()
- P_HELPER_NPC
diff --git a/doc/sphinx/man/lfun/RegisterHelperObject b/doc/sphinx/man/lfun/RegisterHelperObject
deleted file mode 100644
index af33a5c..0000000
--- a/doc/sphinx/man/lfun/RegisterHelperObject
+++ /dev/null
@@ -1,145 +0,0 @@
-
-RegisterHelperObject()
-**********************
-
-
-FUNKTION
-========
-
- int RegisterHelperObject(object helper, int type,
- string|closure callback);
-
-
-DEFINIERT IN
-============
-
- /std/living/helpers.c
-
-
-ARGUMENTE
-=========
-
- object helper
- Das Objekt, das bei einem Lebewesen als Hilfsobjekt registriert
- werden soll. Das Objekt muss sich dazu nicht im Inventar des
- Lebewesens befinden.
- int type
- Helfertyp, einer der in /sys/living/helpers.h definierten Typen:
- - HELPER_TYPE_AERIAL fuer die Flug-/Segelunterstuetzung
- - HELPER_TYPE_AQUATIC fuer Tauchunterstuetzung
- string|closure callback
- Closure oder Funktionsname als String; dies ist die Funktion, die im
- Objekt helper gerufen wird, um abzufragen, ob es sich aktuell fuer
- zustaendig erklaert oder nicht.
-
-
-BESCHREIBUNG
-============
-
- Das Objekt "helper" wird als Hilfsobjekt fuer bestimmte Aktivitaeten wie
- zum Beispiel Fliegen oder Tauchen registriert.
-
-
-
- Die als Callback uebergebene Funktion wird bei der Abfrage der
- P_*_HELPERS-Properties (siehe unten) aufgerufen und deren
- Rueckgabewert in der Property vermerkt.
-
-
-
- Der Rueckgabewert der Callback-Methode muss im Wertebereich
- 0..10000 liegen, wobei ein Wert von 0 bedeutet, dass das Hilfsobjekt
- sich gerade nicht zustaendig fuehlt. Bei den Werten >0 ist es dem
- abfragenden Objekt ueberlassen, wie es diese Daten bewertet.
-
- Die Funktion muss existieren und public sein, d.h. von aussen gerufen
- werden koennen.
-
-
-
- Die Funktion bekommt das Spielerobjekt und das abfragende Objekt als
- Parameter uebergeben.
-
-
-HINWEIS
-=======
-
- Es ist ein Unterschied, ob sich ein Objekt via UnregisterHelperObject()
- als Helfer austraegt, oder ob der Aufruf der Callback-Funktion eine
- 0 zurueckgibt. Im letzteren Fall ist das Objekt nach wie vor
- registriert und kann trotzdem vom abfragenden Objekt als
- funktionsfaehig angesehen werden.
-
-
-RUECKGABEWERTE
-==============
-
- 1 Objekt wurde erfolgreich registriert (HELPER_SUCCESS)
- -1 angegebenes Hilfsobjekt existiert nicht (HELPER_NO_CALLBACK_OBJECT)
- -2 angegebenes Hilfsobjekt ist bereits fuer diese Art der
- Unterstuetzung registriert (HELPER_ALREADY_LISTED)
-
-
-BEISPIELE
-=========
-
- a) Eine luftgefuellte Blase will sich als Tauch-Helfer am Spieler
- anmelden und ist zustaendig, solange sich noch Luft in ihr befindet:
-
- int luft = 5; // globale Variable z.B. fuer Luftinhalt von 5 Atemzuegen
-
- // Registrierung im Spielerobjekt
- if ( TP->RegisterHelperObject(ME, HELPER_TYPE_AQUATIC,
- "DivingCallback") == HELPER_SUCCESS ) {
- tell_object(TP, "Du kannst jetzt mit Hilfe der Luftblase unter Wasser "
- "atmen.\n");
- }
-
- // hier koennen natuerlich auch noch komplexere Dinge ablaufen, z.B.
- // wenn ein Wert zurueckgegeben werden soll, der nicht nur 0 oder 1 ist.
- public int DivingCallback(object player, object caller) {
- return (environment(ME)==player && luft>0);
- }
-
- b) Ein Spieler befindet sich in einem Raum mit einem steilen Abhang, den
- man hinunterspringen kann. Dies geht aber nur dann gefahrlos, wenn es
- Hilfsobjekte gibt, die den (Segel)flug erlauben:
-
- // cmd_springen() sei die Funktion, die bei der Eingabe des Befehls durch
- // den Spieler aufgerufen wird.
- static int cmd_springen(string str) {
- [...]
- // Property abfragen
- mapping helpers = TP->QueryProp(P_AERIAL_HELPERS);
- // Liste der Werte fuer die einzelnen Unterstuetzungsobjekte ermitteln
- int *values = m_values(helpers,0);
- // Spieler schonmal runterbewegen, die Folgen seines Handelns spuert
- // er dann, wenn er unten angekommen ist.
- TP->move(zielraum, M_GO|M_SILENT);
- // "helpers" ist immer ein Mapping, das pruefen wir nicht extra.
- // Wenn die Liste der Objekte noch mindestens ein Element enthaelt,
- // nachdem alle unzustaendigen Hilfsobjekte (Rueckgabewert der
- // Callback-Funktion == 0) rausgerechnet wurden, existiert mindestens
- // ein geeignetes Hilfsobjekt.
- if ( sizeof(values-({0})) ) {
- tell_object(TP, "Sanft segelst Du den Hang hinab.\n");
- }
- else {
- tell_object(TP, BS("Todesmutig springst Du den Hang hinab und "
- "schlaegst hart unten auf. Du haettest vielleicht daran denken "
- "sollen, Dir geeignete Hilfsmittel fuer so eine Aktion zu "
- "besorgen.");
- TP->Defend(800, ({DT_BLUDGEON}), ([SP_NO_ACTIVE_DEFENSE:1]), ME);
- }
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Funktionen: UnregisterHelperObject()
- Properties: P_HELPER_OBJECTS, P_AERIAL_HELPERS, P_AQUATIC_HELPERS
- Sonstiges: /sys/living/helpers.h
-
-05.02.2015 Arathorn
diff --git a/doc/sphinx/man/lfun/RemoveAdjective b/doc/sphinx/man/lfun/RemoveAdjective
deleted file mode 100644
index bd1796f..0000000
--- a/doc/sphinx/man/lfun/RemoveAdjective
+++ /dev/null
@@ -1,43 +0,0 @@
-
-RemoveAdjective()
-*****************
-
-
-FUNKTION
-========
-
- void RemoveAdjective(string|string* adj);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- adj
- String oder Array von String mit den Adjektiven.
-
-
-BESCHREIBUNG
-============
-
- Falls einige der vorhandenen Adjektive nicht mehr verwendet werden
- sollen, koennen sie mit dieser Funktion entfernt werden.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- AddAdjective(), RemoveId(), /std/thing/description.c
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveClass b/doc/sphinx/man/lfun/RemoveClass
deleted file mode 100644
index 26b0b79..0000000
--- a/doc/sphinx/man/lfun/RemoveClass
+++ /dev/null
@@ -1,38 +0,0 @@
-
-RemoveClass()
-*************
-
-
-FUNKTION
-========
-
- void RemoveClass(string|string* class);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- string/string* class - String oder Stringarray der Klasse(n)
-
-
-BESCHREIBUNG
-============
-
- Dem Objekt werden einige der mit AddClass() gesetzten Klassen wieder
- entzogen.
- Die allgemein verfuegbaren Klassen sind unter /sys/class.h definiert.
-
-
-SIEHE AUCH
-==========
-
- AddClass(), is_class_member()
- P_CLASS
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveCmd b/doc/sphinx/man/lfun/RemoveCmd
deleted file mode 100644
index 6adffbf..0000000
--- a/doc/sphinx/man/lfun/RemoveCmd
+++ /dev/null
@@ -1,91 +0,0 @@
-
-RemoveCmd()
-***********
-
-
-RemoveCmd(L)
-============
-
-
-FUNKTION
-========
-
- varargs int RemoveCmd(mixed cmd, int norule, mixed id)
-
-
-DEFINIERT IN
-============
-
- /std/thing/commands.c
-
-
-ARGUMENTE
-=========
-
- com
- String oder Array von Strings mit den zu entfernenden Kommandos.
- norule
- Kommandos mit Regeln werden nicht entfernt (ausser bei cmd==0)
- id
- eine ID, mit der man ein vorher mit dieser ID gespeichertes
- Kommando eindeutig lvschen kann
-
-
-BESCHREIBUNG
-============
-
- Mit AddCmd() hinzugefuegte Kommandos koennen mit diesem Befehl wieder
- abgemeldet werden. Die entfernten Kommandos sind direkt nach dem
- RemoveCmd()-Aufruf nicht mehr ansprechbar.
-
- Wird ein Regelstring angegeben, so wird die identische AddCmd-
- Regel entfernt.
-
-
-BEMERKUNGEN
-===========
-
- Uebergibt man fuer com eine 0, so werden alle definierten Kommandos
- entfernt!
-
-
-RUECKGABEWERT
-=============
-
- Anzahl der entfernten Kommandos.
-
-
-BEISPIELE
-=========
-
- (1) AddCmd("test");
- (2) AddCmd("test|teste&mit¶meter");
- (3) AddCmd(({"test"}),1);
- (4) AddCmd("test",0,0,"XYZ");
- (5) AddCmd("test&mit¶meter",0,0,"XYZ");
-
- RemoveCmd(0);
- - entfernt alle Kommandos
- RemoveCmd("test",1);
- - entfernt (1) und (3)
- RemoveCmd("test");
- - entfernt (1), (3) und einen Teil von (2),
- es verbleibt "teste&mit¶meter"
- RemoveCmd("test|teste&mit¶meter"
- - entfernt (2)
- RemoveCmd("test",0,"XYZ");
- - entfernt (4) und (5)
- RemoveCmd("test",1,"XYZ");
- - entfernt (4), nicht (5)
- RemoveCmd(0,0,"XYZ");
- - entfernt (4) und (5)
-
-
-SIEHE AUCH
-==========
-
- AddCmd(L), AddCmd_bsp
- Sonstiges: replace_personal(E), enable_commands(E), init(E)
- Alternativen: AddAction(L), add_action(E)
-
-24.Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/RemoveDefender b/doc/sphinx/man/lfun/RemoveDefender
deleted file mode 100644
index 1dec97a..0000000
--- a/doc/sphinx/man/lfun/RemoveDefender
+++ /dev/null
@@ -1,52 +0,0 @@
-
-RemoveDefender()
-****************
-
-
-FUNKTION
-========
-
- void RemoveDefender(object friend);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- friend
- Objekt (normal Lebewesen), welches zukuenftig nicht mehr ueber
- Angriffe informiert werden soll und diese auch nicht mehr abwehrt.
-
-
-BESCHREIBUNG
-============
-
- Ein Lebewesen, welches angegriffen wird, kann andere Objekte ueber
- einen solchen Angriff per InformDefend() informieren oder ihnen
- sogar die Moeglichkeit geben, per DefendOther() direkt in den
- laufenden Angriff einzugreifen (Schaeden abwehren oder umwandeln).
- Im Normalfall handelt es sich hierbei um andere Lebewesen, welche
- als Verteidiger des angegriffenen Lebewesens auftreten: Daher der
- Name der Funktion. Ausserdem besteht die Einschraenkung, dass diese
- Objekte in der gleichen Umgebung sein muessen, wie das zu
- verteidigende Lebewesen.
- Die Objekte sind in Form eines Arrays in der Property P_DEFENDERS
- abgespeichert und koennen dort abgerufen werden. Natuerlich kann
- man alte Objekte direkt dort loeschen, jedoch sollte man die
- hierfuer bereitgestellte Funktionen RemoveDefender() verwenden.
- Zum Hinzufuegen von Eintraegen im Array steht ebenfalls eine
- Funktion bereit: AddDefender().
-
-
-SIEHE AUCH
-==========
-
- AddDefender(), InformDefend(), DefendOther(),
- P_DEFENDERS, /std/living/combat.c
-
-Last modified: Thu Jul 29 18:48:45 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/RemoveDetail b/doc/sphinx/man/lfun/RemoveDetail
deleted file mode 100644
index 48a0330..0000000
--- a/doc/sphinx/man/lfun/RemoveDetail
+++ /dev/null
@@ -1,80 +0,0 @@
-
-RemoveDetail()
-**************
-
-
-FUNKTION
-========
-
- void RemoveDetail(mixed *keys);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den zu entfernenden Details.
-
-
-BESCHREIBUNG
-============
-
- Entfernt die in <keys> angegebenen Details aus der Liste der
- vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
- saemtliche Details entfernt!
-
-
-BEISPIEL
-========
-
- Ein kleines Beispiel, bei dem eine Oeffnung erscheint und wieder
- verschwindet, je nachdem, ob man eine Luke oeffnet oder schliesst.
- int oeffneLuke(string str);
- int schliesseLuke(string str);
- ...
- AddCmd("oeffne", #'oeffneLuke);
- AddCmd("schliesse", #'schliesseLuke);
- ...
- int oeffneLuke(string str) {
- if(str!="luke" || GetDetail("oeffnung"))
- return 0;
- AddDetail("oeffnung","Du siehst eine kleine Oeffnung.\n");
- return 1;
- }
-
- int schliesseLuke(string str) {
- if(str!="luke" || !GetDetail("oeffnung"))
- return 0;
- RemoveDetail("oeffnung"); // Detail wieder entfernen
- return 1;
- }
-
-
-BEMERKUNGEN
-===========
-
- Da intern Details und SpecialDetails im gleichen Mapping verwaltet
- werden, lassen sich mit dieser Funktion auch SpecialDetails
- entfernen.
- Die Funktion RemoveSpecialDetail() sollte also nicht genutzt werden!
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS,
- P_TOUCH_DETAILS, P_SPECIAL_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-8. Juli 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/RemoveExit b/doc/sphinx/man/lfun/RemoveExit
deleted file mode 100644
index 6854229..0000000
--- a/doc/sphinx/man/lfun/RemoveExit
+++ /dev/null
@@ -1,49 +0,0 @@
-
-RemoveExit()
-************
-
-
-FUNKTION
-========
-
- void RemoveExit(string|string* cmd);
-
-
-DEFINIERT IN
-============
-
- /std/room/exits
-
-
-ARGUMENTE
-=========
-
- string/string* cmd
- Richtung(en), die entfernt werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Die in cmd angegebenen Ausgaenge werden wieder entfernt.
-
- Ist cmd = 0, so werden alle Ausgaenge entfernt.
-
-
-BEMERKUNGEN
-===========
-
- Ausgaenge werden an der gleichen Stelle gespeichert:
- - RemoveExit() greift auf die gleichen Daten wie RemoveSpecialExit()
- zu, entfernt also auch spezielle Ausgaenge!
-
-
-SIEHE AUCH
-==========
-
- AddExit(), AddSpecialExit(), GetExits()
- RemoveSpecialExit(),
- H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
-
-31.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveExtraLook b/doc/sphinx/man/lfun/RemoveExtraLook
deleted file mode 100644
index 0369992..0000000
--- a/doc/sphinx/man/lfun/RemoveExtraLook
+++ /dev/null
@@ -1,65 +0,0 @@
-
-RemoveExtraLook()
-*****************
-
-RemoveExtraLook()
-
-
-int RemoveExtraLook(string look);
-=================================
-
-
-DEFINIERT IN
-============
-
- /std/living/description.c
-
-
-BESCHREIBUNG
-============
-
- Der Extralook erscheint in der Langbeschreibung des Lebewesens.
- Eintraege koennen mit dieser Funktion (vorzeitig) wieder entfernt werden.
-
-
-ARGUMENTE
-=========
-
- - string look:
- Schluesselwort, unter dem der Eintrag, den man entfernen moechte, von
- AddExtraLook() registriert wurde.
-
-
-RUECKGABEWERTE
-==============
-
- > 0, falls der Eintrag erfolgreich entfernt wurde.
- < 0 sonst.
- -1: keinen (gueltigen) <key> uebergeben.
- -2: kein Eintrag fuer <key> gefunden.
-
-
-BEMERKUNGEN
-===========
-
- Beim Entfernen mit dieser Funktion wird die "Endemeldung" des entfernten
- Eintrages nicht ausgegeben.
-
-
-BEISPIELE
-=========
-
- # Extralook registrieren.
- living->AddExtraLook("@WER1 wird von einer Horde Daemonen verfolgt.",
- "ennox_daemonenhordenverfolgerlook");
- # Nun kann der Eintrag auch wieder entfernt werden:
- living->RemoveExtraLook("ennox_daemonenhordenverfolgerlook");
-
-
-SIEHE AUCH
-==========
-
- AddExtraLook(),
- P_INTERNAL_EXTRA_LOOK
-
-14.05.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveFixedObject b/doc/sphinx/man/lfun/RemoveFixedObject
deleted file mode 100644
index 22179de..0000000
--- a/doc/sphinx/man/lfun/RemoveFixedObject
+++ /dev/null
@@ -1,62 +0,0 @@
-
-RemoveFixedObject()
-*******************
-
-
-FUNKTION
-========
-
- void RemoveFixedObject(string filename);
-
-
-DEFINIERT IN
-============
-
- /std/laden.c
-
-
-ARGUMENTE
-=========
-
- str
- Dateiname des Objektes, welches nicht mehr dauerhaft im Laden sein
- soll.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BESCHREIBUNG
-============
-
- Objekte, die mittels der Funktion AddFixedObject() im Laden
- eingebunden werden, sind dort staendig verfuegbar. Um diesen Zustand
- wieder aufzuheben, kann man sie mittels dieser Funktion wieder
- entfernen. Eventuell im Lager befindliche Objekte dieser Art werden
- hierbei nicht zerstoert und koennen durchaus noch gekauft werden,
- bis sie alle sind. Danach gibt es sie dort nicht mehr!
-
-
-BEISPIELE
-=========
-
- Im allen Laeden gibt es schon ein Objekt, welches dort
- standardmaessig erhaeltlich ist. Folgende Zeile sorgt dafuer:
- AddFixedObject("/obj/boerse",80,({"boerse","geldboerse"}));
- Wenn man das in seinem Laden nicht wuenscht, kann man die Geldboerse
- mittels folgender Zeile wieder aus dem Laden loeschen:
- RemoveFixedObject("/obj/boerse");
- Es ist nicht moeglich, keine oder mehrere Objekte anzugeben, um auf
- diese Weise alle bzw. mehrere Objekte als nicht mehr staendig
- verfuegbar zu markieren.
-
-
-SIEHE AUCH
-==========
-
- AddFixedObject(), SetStorageRoom(), /std/store.c
-
-Last modified: Thu Jun 18 14:19:19 1998 by Patryn
diff --git a/doc/sphinx/man/lfun/RemoveFromMenu b/doc/sphinx/man/lfun/RemoveFromMenu
deleted file mode 100644
index fdcb916..0000000
--- a/doc/sphinx/man/lfun/RemoveFromMenu
+++ /dev/null
@@ -1,55 +0,0 @@
-
-RemoveFromMenu()
-****************
-
-
-FUNKTION
-========
-
- int RemoveFromMenu(mixed ids)
-
-
-DEFINIERT IN
-============
-
- /std/pub.c
-
-
-ARGUMENTE
-=========
-
- ids - string oder string*
- String oder Array von Strings, mit denen sich die Speise bzw.
- das Getraenk beim Bestellen ansprechen laesst.
-
-
-RUECKGABEWERT
-=============
-
- int - Anzahl entfernter Einzelmenueeintraege
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Methode kann man id-basiert Speisen und Getraenke
- wieder von der Karte entfernen (wenn zB nur saisonbasiert
- bestimmte Dinge angeboten werden sollen).
-
-
-BEMERKUNGEN
-===========
-
- - sich zwischen zwei Speisen ueberschneidende IDs fuehren zu
- undefiniertem Verhalten!
- - bei Benutzung von RemoveFromMenu sollte man in Delay-Speisen oder
- -Getraenken auf die Nutzung vom ident-Parameter in den
- Serviernachrichten verzichten (es sei, man weiss was man tut)
-
-
-SIEHE AUCH
-==========
-
- AddToMenu(), AddFood(), AddDrink(), /sys/pub.h
-
-15. Februar 2009 Gloinson
diff --git a/doc/sphinx/man/lfun/RemoveFunc b/doc/sphinx/man/lfun/RemoveFunc
deleted file mode 100644
index bf01ae9..0000000
--- a/doc/sphinx/man/lfun/RemoveFunc
+++ /dev/null
@@ -1,113 +0,0 @@
-
-RemoveFunc()
-************
-
-
-FUNKTION
-========
-
- int RemoveFunc(object ruest, int info, object user);
-
-
-DEFINIERT IN
-============
-
- eigenen Objekten (fuer /std/clothing/wear)
-
-
-ARGUMENTE
-=========
-
- ruest (object)
- Die Ruestung/Kleidung, die ausgezogen werden soll.
- info (int)
- Bei (info&M_SILENT) wird keine Meldung ueber das Ausziehen
- ausgegeben.
- Bei (info&M_NOCHECK) wird die Kleidung ausgezogen, egal was diese
- Funktion zurueckgibt. Dies tritt insbesondere dann auf, wenn der
- Spieler, der die Ruestung traegt, stirbt und die Ruestung in
- die Leiche bewegt wird.
- user (object)
- Das Lebewesen, welches die Ruestung/Kleidung gerade traegt und sie
- ausziehen will.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann man pruefen, ob sich das Kleidungsstueck bzw.
- Ruestung <ruest> von this_player() ausziehen laesst oder nicht.
- Kann die Ruestung ausgezogen werden, so muss ein Wert ungleich 0
- zurueckgegeben werden.
-
-
-
- Diese Funktion meldet nur einen _Wunsch_ an. Dieser kann ignoriert
- werden (z.B. bei bestimmten Bewegungen, Tod des Spielers etc.).
- Unabhaengig vom Wert dieser Funktion kann das Ausziehen noch Scheitern
- oder Erzwungen werden.
- Wenn ihr sicher sein wollt, dass der Spieler ein Objekt angezogen hat,
- benutzt bitte InformUnwear().
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn sich die Ruestung nicht ausziehen laesst, ansonsten ungleich 0.
-
-
-BEMERKUNGEN
-===========
-
- Verfluchte Ruestungen, die sich erst nach Entfernung des Fluches wieder
- ausziehen lassen, sollte man besser mit P_CURSED realisieren (man spart
- die RemoveFunc() ein).
- Bitte nicht drauf verlassen, dass this_player() das ausziehende Lebewesen
- ist.
- Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
- erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
- Objekte zu aendern.
-
-
-BEISPIELE
-=========
-
- Ein Umhang, den man nur mit guter Einstellung wieder ausziehen kann:
-
- inherit "std/armour.c";
-
- #include <properties.h>
- #include <moving.h>
-
- create()
- {
- ::create();
-
- SetProp(P_ARMOUR_TYPE, AT_CLOAK);
- /* zig weitere SetProp's, um den Umhang zu konfigurieren */
-
- /* RemoveFunc() ist im Umhang selbst zu finden */
- SetProp(P_REMOVE_FUNC, this_object());
- }
-
- int RemoveFunc(object me, int info, object user)
- {
- if (user->QueryProp(P_ALIGN) >= 0 || (info&M_NOCHECK))
- return 1; /* gute Charaktere koennen den Umhang ausziehen */
-
- /* Ansonsten geben wir evtl. einen entsprechenden Hinweis aus: */
- if (!(info&M_SILENT))
- write( "Der Umhang wird von Deiner Bosheit so sehr "
- +"angezogen, dass Du ihn\nnicht mehr ausziehen kannst!\n");
- return 0;
- }
-
-
-SIEHE AUCH
-==========
-
- P_WEAR_MSG, P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
- DoUnwear(), DoWear(), InformWear(), InformUnwear()
- /std/clothing/wear.c
-
-02.07.2013, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveId b/doc/sphinx/man/lfun/RemoveId
deleted file mode 100644
index efd709d..0000000
--- a/doc/sphinx/man/lfun/RemoveId
+++ /dev/null
@@ -1,44 +0,0 @@
-
-RemoveId()
-**********
-
-
-FUNKTION
-========
-
- void RemoveId(string|string* ids);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- ids
- String oder Array von Strings mit den Bezeichnungen, die aus der
- Liste der IDs des Objektes entfernt werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Objekt sich nicht mehr mit gewissen Bezeichnern ansprechen
- lassen soll, kann man diese mit dieser Funktion entfernen.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- AddId(), RemoveAdjective(), /std/thing/description.c
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveInfo b/doc/sphinx/man/lfun/RemoveInfo
deleted file mode 100644
index 75485c6..0000000
--- a/doc/sphinx/man/lfun/RemoveInfo
+++ /dev/null
@@ -1,45 +0,0 @@
-
-RemoveInfo()
-************
-
-
-FUNKTION
-========
-
- void RemoveInfo(string key)
-
-
-DEFINIERT IN
-============
-
- /std/npc/info.c
-
-
-ARGUMENTE
-=========
-
- key zu loeschender Schluessel
-
-
-BESCHREIBUNG
-============
-
- Loescht die Antwort zum entsprechenden Frageschluessel.
-
-
-BEISPIEL
-========
-
- // erstellen und loeschen
- AddInfo("gold","sagt: Ich habe keines.\n");
- RemoveInfo("gold");
-
-
-SIEHE AUCH
-==========
-
- AddInfo(L), AddSpecialInfo(L)
- P_PRE_INFO, P_DEFAULT_INFO
- /std/npc/info.c
-
-17.Aug.2003 Gloinson
diff --git a/doc/sphinx/man/lfun/RemoveItem b/doc/sphinx/man/lfun/RemoveItem
deleted file mode 100644
index a21cdc2..0000000
--- a/doc/sphinx/man/lfun/RemoveItem
+++ /dev/null
@@ -1,64 +0,0 @@
-
-RemoveItem()
-************
-
-
-FUNKTION
-========
-
- void RemoveItem(mixed file);
-
-
-DEFINIERT IN
-============
-
- /std/room/items.c
-
-
-ARGUMENTE
-=========
-
- file
- String oder Array von Strings mit dem Namen des zu entfernenden
- Objekts.
-
-
-BESCHREIBUNG
-============
-
- Das mit AddItem(file) dem Raum hinzugefuegte Objekt wird wieder aus
- der Liste der Objekte entfernt.
- Wurde bei AddItem() ein Array von Dateinamen uebergeben, so muss das
- selbe Array auch bei RemoveItem() uebergeben werden!
- Falls das Objekt, das durch den AddItem()-Aufruf erzeugt wurde, sich
- noch im Raum befindet, wird es durch den RemoveItem()-Aufruf zerstoert.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- Ein muellschluckerfreier Laden laesst sich wie folgt erzeugen:
-
- inherit "/std/laden";
- #include <properties.h>
-
- create()
- {
- ::create(); // Hier wird u.a. der Muellschlucker erzeugt
-
- RemoveItem("/obj/entsorg"); // und weg damit!
-
- SetProp(...); // und die normale Beschreibung...
- }
-
-
-SIEHE AUCH
-==========
-
- AddItem(), /std/room/items.c
diff --git a/doc/sphinx/man/lfun/RemoveKnownPotion b/doc/sphinx/man/lfun/RemoveKnownPotion
deleted file mode 100644
index f7af610..0000000
--- a/doc/sphinx/man/lfun/RemoveKnownPotion
+++ /dev/null
@@ -1,45 +0,0 @@
-
-RemoveKnownPotion()
-*******************
-
-
-FUNKTION
-========
-
- int RemoveKnownPotion(int nr)
-
-
-DEFINIERT IN
-============
-
- /std/player/potion.c
-
-
-ARGUMENTE
-=========
-
- int nr Nummer eines ZTs
-
-
-BESCHREIBUNG
-============
-
- Entfernt einen bekannten ZT aus einen Spieler. Nur vom Orakel rufbar.
-
-
-RUeCKGABEWERT
-=============
-
- 1 Erfolg
- -1 fehlende Berechtigung
- -2 Nummer nicht eingetragen
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: FindPotion(), AddKnownPotion(), InList()
- Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
-
-6.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/lfun/RemovePluralId b/doc/sphinx/man/lfun/RemovePluralId
deleted file mode 100644
index 23f394a..0000000
--- a/doc/sphinx/man/lfun/RemovePluralId
+++ /dev/null
@@ -1,49 +0,0 @@
-
-RemovePluralId()
-****************
-
-
-FUNKTION
-========
-
- void RemovePluralId(mixed id);
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- id
- Identfikationsstring oder Array von Strings
-
-
-BESCHREIBUNG
-============
-
- Es werden ein oder mehrere Bezeichner entfernt, mit denen sich
- mehrere Einheiten der Menge ansprechen lassen.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- siehe /items/money.c
-
-
-SIEHE AUCH
-==========
-
- RemoveSingularId(), AddPluralId(), AddId(), id(), /std/unit.c
-
-Last modified: Mon Jul 14 11:30:00 1997 by Silvana
diff --git a/doc/sphinx/man/lfun/RemovePursuer b/doc/sphinx/man/lfun/RemovePursuer
deleted file mode 100644
index cf8f0dc..0000000
--- a/doc/sphinx/man/lfun/RemovePursuer
+++ /dev/null
@@ -1,53 +0,0 @@
-
-RemovePursuer()
-***************
-
-
-RemoveRursuer()
-===============
-
-
-FUNKTION
-========
-
- void RemovePursuer(object pursuer)
-
-
-ARGUMENTE
-=========
-
- pursuer: Objekt, das aus der Verfolgerliste des Objektes, in dem
- RemovePursuer aufgerufen wurde, ausgetragen werden soll.
-
-
-FUNKTION
-========
-
- Durch den Aufruf von RemovePursuer in einem Objekt, welches living() ist,
- wird das Object, welches als Argument uebergeben wurde aus der Liste
- der Verfolger ausgetragen.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNG
-=========
-
- keine
-
-
-BEISPIELE
-=========
-
- find_player("jof")->RemovePursuer(find_player("kirk"))
- Danach wird Jof nicht mehr von Kirk verfolgt.
-
-
-SIEHE AUCH
-==========
-
- "AddPursuer", "PreventFollow"
diff --git a/doc/sphinx/man/lfun/RemoveReadDetail b/doc/sphinx/man/lfun/RemoveReadDetail
deleted file mode 100644
index 495dfe3..0000000
--- a/doc/sphinx/man/lfun/RemoveReadDetail
+++ /dev/null
@@ -1,50 +0,0 @@
-
-RemoveReadDetail()
-******************
-
-
-FUNKTION
-========
-
- void RemoveReadDetail(string|string* keys);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den zu entfernenden Details.
-
-
-BESCHREIBUNG
-============
-
- Entfernt die in keys angegebenen Details aus der Liste der vorhandenen
- lesbaren Details.
-
-
-BEMERKUNGEN
-===========
-
- Uebergibt man fuer keys eine 0, so werden saemtliche lesbaren Details
- entfernt!
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveResistanceModifier b/doc/sphinx/man/lfun/RemoveResistanceModifier
deleted file mode 100644
index ca14c74..0000000
--- a/doc/sphinx/man/lfun/RemoveResistanceModifier
+++ /dev/null
@@ -1,57 +0,0 @@
-
-RemoveResistanceModifier()
-**************************
-
-
-FUNKTION
-========
-
- varargs void RemoveResistanceModifier(string add);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- string add:
- Ein eventueller Identifikator fuer einen gesetzten Modifikator.
-
-
-BESCHREIBUNG
-============
-
- Die von einem Objekt im Zielobjekt gesetzte Resistenz wird geloescht,
- der Schluessel add wird dazu benutzt, eine bestimmte Resistenz zu
- loeschen (so kann ein setzendes Objekt mehrere verschiedene Re-
- sistenzen setzen und selektiv loeschen).
-
-
-BEISPIELE
-=========
-
- // unser Oel aus AddResistanceModifier() verbrennt endgueltig
- varargs void trigger_sensitive_attack() {
- ...
- if(environment() && living(environment())) {
- environment()->RemoveResistanceModifier("oel");
- tell_object(environment(),"Das Oel verbrennt endgueltig.\n");
- }
- remove();
- }
-
-
-SIEHE AUCH
-==========
-
- Modifikatoren: AddResistanceModifier, P_RESISTANCE_MODIFIER
- simple Resistenz: P_RESISTANCE, P_VULNERABILITY
- Hauptmapping: P_RESISTANCE_STRENGTHS
- Berechnung: CheckResistance(), UpdateResistanceStrengths()
- anderes: balance, /std/armour/combat.c, /std/living/combat.c
-
-29.Apr 2002, Gloinson@MG
diff --git a/doc/sphinx/man/lfun/RemoveRoute b/doc/sphinx/man/lfun/RemoveRoute
deleted file mode 100644
index 61fb082..0000000
--- a/doc/sphinx/man/lfun/RemoveRoute
+++ /dev/null
@@ -1,42 +0,0 @@
-
-RemoveRoute()
-*************
-
-
-FUNKTION
-========
-
- void RemoveRoute();
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Der Transporter wird angehalten und der gesamte Fahrplan wird
- geloescht. Damit lassen sich zum Beispiel variable Routen konstruieren.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- AddRoute(), AddMsg(), AddFun(), /std/transport.c
-
-Last modified: Wed May 8 10:24:26 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/RemoveSensitiveObject b/doc/sphinx/man/lfun/RemoveSensitiveObject
deleted file mode 100644
index 0678e70..0000000
--- a/doc/sphinx/man/lfun/RemoveSensitiveObject
+++ /dev/null
@@ -1,79 +0,0 @@
-
-RemoveSensitiveObject()
-***********************
-
-
-FUNKTION
-========
-
- void RemoveSensitiveObject(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/container/inventory.c
- generalizes /std/living/inventory.c
-
-
-ARGUMENTE
-=========
-
- ob - zu entfernendes Objekt
-
-
-BESCHREIBUNG
-============
-
- Entfernt ob aus den Benachrichtigungslisten des Containers.
- Wird von thing/moving.c im alten Environment gerufen, wenn
- P_SENSITIVE gesetzt ist.
- Ruft dazu RemoveSensitiveObjectFromList().
-
-
-BEMERKUNGEN
-===========
-
- Setzt man P_SENSITIVE nicht als Default sondern situationsabhaengig,
- dann muss man auch RemoveSensitiveObject im Environment
- auch selbst rufen!
-
-
-BEISPIEL
-========
-
- // Fackel (inheriting lightsource)
- void create() {
- ...
- SetProp(P_SENSITIVE,
- ({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,120})}));
- ...
- }
-
- // wenn die Fackel geloescht wird, verliert sie ihre aktive
- // Eigenschaft und muss das dem environment() mitteilen
- static int extinguish(string str) {
- int i;
- i=::extinguish(str);
- if(i && QueryProp(P_LIGHT)<=0) {
- SetProp(P_SENSITIVE,0);
- if(environment())
- environment()->RemoveSensitiveObject(this_object());
- }
- return i;
- }
-
- - empfindliche Objekte wie Eiszapfen koennen jetzt wieder gefahrlos
- in das selbe environment() bewegt werden
-
-
-SIEHE AUCH
-==========
-
- P_SENSITIVE
- InsertSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY, P_SENSITIVE_INVENTORY_TRIGGER
- CheckSensitiveAttack
-
-25.Apr.2001, Gloinson@MG
diff --git a/doc/sphinx/man/lfun/RemoveSingularId b/doc/sphinx/man/lfun/RemoveSingularId
deleted file mode 100644
index fcf0c3d..0000000
--- a/doc/sphinx/man/lfun/RemoveSingularId
+++ /dev/null
@@ -1,49 +0,0 @@
-
-RemoveSingularId()
-******************
-
-
-FUNKTION
-========
-
- void RemoveSingularId(mixed id);
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- id
- Identifikationsstring oder Array von Strings
-
-
-BESCHREIBUNG
-============
-
- Es werden ein oder mehrere Bezeichner entfernt, mit denen sich eine
- einzelne Einheit ansprechen laesst.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- siehe /items/money.c
-
-
-SIEHE AUCH
-==========
-
- AddSingularId(), RemovePluralId(), AddId(), id(), /std/unit.c
-
-Last modified: Mon Jul 14 11:31:00 1997 by Silvana
diff --git a/doc/sphinx/man/lfun/RemoveSkillAttributeModifier b/doc/sphinx/man/lfun/RemoveSkillAttributeModifier
deleted file mode 100644
index 5fa69b2..0000000
--- a/doc/sphinx/man/lfun/RemoveSkillAttributeModifier
+++ /dev/null
@@ -1,83 +0,0 @@
-
-RemoveSkillAttributeModifier()
-******************************
-
-
-FUNKTION
-========
-
- public int RemoveSkillAttributeModifier(object caster, string atrname)
-
-
-DEFINIERT IN
-============
-
- /std/living/skill_attributes.c
-
-
-ARGUMENTE
-=========
-
- <atrname> string
- Name des Skill-Attributes, von dem der Modifikator geloescht
- werden soll.
- (Definiert in /sys/living/skill_attributes.h)
-
- <caster> object
- Objekt, dessen Modifikator wieder entfernt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Entfernt den Modifikator, den Object <caster> gesetzt hat, wieder. Dies
- ist nur notwendig, wenn der Effekt vor Ablauf der Gueltigkeit des
- Modifikators aufgehoben werden soll.
-
-
-RUECKGABEWERT
-=============
-
- SA_MOD_REMOVED wenn der Modifikator geloescht wurde
- SA_MOD_NOT_FOUND wenn der Modifikator nicht gefunden wurde
- Wenn man nur wissen will, ob die Operation erfolgreich war, empfiehlt es
- sich, auf == SA_MOD_REMOVED zu pruefen.
-
-
-BEISPIELE
-=========
-
- // eine Waffe setzt im InformWield() einen Bonus auf SA_DAMAGE fuer 10min
- protected void InformWield(object pl, int silent) {
- if (objectp(pl)) {
- if (pl->ModifySkillAttribute(SA_DAMAGE, 20, 600) == SA_MOD_OK)
- // Erfolgsmeldung an Spieler
- else
- // Misserfolgsmeldung an Spieler.
- }
- }
-
- // wenn der Spieler die Waffe vor Ablauf der 600s wegstecken will, muss
- // der Bonus natuerlich auch wieder raus
- protected void InformUnwield(object pl, int silent) {
- if (objectp(pl))
- pl->RemoveSkillAttributeModifier(this_object(), SA_DAMAGE);
- // falls kein solcher Mod mehr gesetzt war, liefert RSAM()
- // SA_MOD_NOT_FOUND zurueck. Auswertung des Rueckgabewertes ist
- // vernachlaessigt.
- }
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
-
-13.08.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveSmells b/doc/sphinx/man/lfun/RemoveSmells
deleted file mode 100644
index b56fe27..0000000
--- a/doc/sphinx/man/lfun/RemoveSmells
+++ /dev/null
@@ -1,57 +0,0 @@
-
-RemoveSmells()
-**************
-
-
-FUNKTION
-========
-
- void RemoveSmells(string|string* keys);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den zu entfernenden Details.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,
- nur koennen hiermit Gerueche entfernt werden:
- Entfernt die in <keys> angegebenen Details aus der Liste der
- vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
- saemtliche Details entfernt!
-
-
-BEISPIEL
-========
-
- Zuerst erzeugen wir ein kleines Detail, mit dem wir am Rauch riechen
- koennen. Das Feuer brennt langsam ab und das Detail wird wieder
- entfernt:
-
- AddSmells("rauch",* H U S T *\n");
- call_out(#'RemoveSmells, 100, "rauch");
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveSounds b/doc/sphinx/man/lfun/RemoveSounds
deleted file mode 100644
index 4ef4263..0000000
--- a/doc/sphinx/man/lfun/RemoveSounds
+++ /dev/null
@@ -1,66 +0,0 @@
-
-RemoveSounds()
-**************
-
-
-FUNKTION
-========
-
- void RemoveSounds(string|string* keys);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den zu entfernenden Details.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,
- nur koennen hiermit Gerauesche entfernt werden:
- Entfernt die in <keys> angegebenen Details aus der Liste der
- vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
- saemtliche Details entfernt!
-
-
-BEISPIEL
-========
-
- Wir lassen etwas Musik spielen und wenn wir den Plattenspieler
- ausmachen, dann endet sie und man hoert auch nichts mehr:
-
- int ausmachen(string str);
- ...
- AddSounds(({"musik","hip-hop"}) ,"Klingt nach Hip-Hop...\n");
- AddCmd("mach|mache&plattenspieler&aus", #'ausmachen,
- "Was willst du (aus)machen?|Willst du den ausmachen?^");
- ...
- int ausmachen(string str) {
- if(!GetDetail("musik", 0, SENSE_SOUND)) // existiert Musikdetail ?
- return("Der Plattenspieler laeuft doch gar nicht!\n", 1);
- RemoveSounds(0);
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-8. Juli 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/RemoveSpecialDetail b/doc/sphinx/man/lfun/RemoveSpecialDetail
deleted file mode 100644
index 96a7a39..0000000
--- a/doc/sphinx/man/lfun/RemoveSpecialDetail
+++ /dev/null
@@ -1,60 +0,0 @@
-
-RemoveSpecialDetail()
-*********************
-
-
-VERALTET RemoveSpecialDetail()
-==============================
-
-
-FUNKTION
-========
-
- void RemoveSpecialDetail(string|string* keys);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den zu entfernenden Details.
-
-
-BESCHREIBUNG
-============
-
- Entfernt die in keys angegebenen Details aus der Liste der
- vorhandenen SpecialDetails.
-
- VERALTET: Bitte RemoveDetail() benutzen.
-
-
-BEMERKUNGEN
-===========
-
- Uebergibt man fuer keys eine 0, so werden saemtliche SpecialDetails
- entfernt!
- Da intern Details und SpecialDetails im gleichen Mapping verwaltet
- werden, lassen sich mit dieser Funktion auch Details entfernen.
- Man sollte diese Funktion deshalb nicht mehr verwenden, siehe
- AddDetail mit Closures.
-
-
-SIEHE AUCH
-==========
-
- Setzen : AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds(), RemoveTouchDetail()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveSpecialExit b/doc/sphinx/man/lfun/RemoveSpecialExit
deleted file mode 100644
index ee2e8e8..0000000
--- a/doc/sphinx/man/lfun/RemoveSpecialExit
+++ /dev/null
@@ -1,49 +0,0 @@
-
-RemoveSpecialExit()
-*******************
-
-
-FUNKTION
-========
-
- void RemoveSpecialExit(string|string* cmd);
-
-
-DEFINIERT IN
-============
-
- /std/room/exits
-
-
-ARGUMENTE
-=========
-
- string/string* cmd
- Richtung(en), die entfernt werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Die in cmd angegebenen Ausgaenge werden wieder entfernt.
-
- Ist cmd = 0, so werden alle Ausgaenge entfernt.
-
-
-BEMERKUNGEN
-===========
-
- Ausgaenge werden an der gleichen Stelle gespeichert:
- - RemoveSpecialExit() greift auf die gleichen Daten wie RemoveExit()
- zu, entfernt also auch normale Ausgaenge!
-
-
-SIEHE AUCH
-==========
-
- AddExit(), AddSpecialExit(), AddGuardedExit(), GetExits()
- RemoveExit(),
- P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
-
-31.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/RemoveTouchDetail b/doc/sphinx/man/lfun/RemoveTouchDetail
deleted file mode 100644
index 4f6ace3..0000000
--- a/doc/sphinx/man/lfun/RemoveTouchDetail
+++ /dev/null
@@ -1,75 +0,0 @@
-
-RemoveTouchDetail()
-*******************
-
-
-FUNKTION
-========
-
- void RemoveTouchDetail(string|string* keys);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keys
- String oder Array von Strings mit den zu entfernenden Details.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion entspricht dem RemoveDetail() fuer Standarddetails,
- nur koennen hiermit (ab)tastbare Details entfernt werden:
- Entfernt die in <keys> angegebenen Details aus der Liste der
- vorhandenen Details. Uebergibt man fuer <keys> eine 0, so werden
- saemtliche tastbaren/fuehlbaren Details entfernt!
-
-
-BEISPIEL
-========
-
- Zuerst wird ein Detail "boden" erzeugt, das abgetastet werden kann.
- Dieses kann durch Betaetigen eines Knopfes, aeh, entfernt werden.
-
- int knopf();
- void knopf2();
-
- AddTouchDetail("boden", "Er ist aus Stein.\n");
- AddCmd("drueck|druecke&knopf", #'knopf, "Was willst du druecken?");
-
- void knopf() {
- tell_room(this_object(), break_string(
- this_player()->Name(WER)+" drueckt einen Knopf, der dabei satt "+
- "klackt.", 78));
-
- if(find_call_out(#'knopf2)<=0)
- call_out(#'knopf2, 1);
- }
-
-
-
- void knopf2() {
- tell_room(this_object(), "Uhoh. Der Boden klappt weg. Du faellst.");
- RemoveTouchDetails("boden");
- }
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail(), AddReadDetail(), AddSmells(), AddSounds(),
- AddTouchDetail()
- Loeschen: RemoveDetail(), RemoveReadDetail(), RemoveSmells(),
- RemoveSounds()
- Daten: P_DETAILS, P_READ_DETAILS, P_SMELLS, P_SOUNDS, P_TOUCH_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/ResizeRingBuffer b/doc/sphinx/man/lfun/ResizeRingBuffer
deleted file mode 100644
index 17c3332..0000000
--- a/doc/sphinx/man/lfun/ResizeRingBuffer
+++ /dev/null
@@ -1,66 +0,0 @@
-
-ResizeRingBuffer()
-******************
-
-
-FUNKTION
-========
-
- protected struct std_ringbuffer buf RingBufferPut(
- struct std_ringbuffer buf,
- int size);
-
-
-DEFINIERT IN
-============
-
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
-
-
-ARGUMENTE
-=========
-
- buf - Ringpuffer, dessen Groesse geaendert werden soll
- size - neue Groesse (int)
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion erstellt einen neuen Ringpuffer der Groesse <size>, welcher
- den gleichen Modus hat wie <buf> und die gleichen Daten enthaelt.
- Ist der neue Puffer kleiner als <buf>, so kommt es hierbei zu
- Datenverlust.
- <buf> wird nicht veraendert. Ist die Groesse von <buf> gleich der
- neuen gewuenschten Groesse, wird letztendlich der Ringpuffer kopiert.
- Je nach Groesse von <buf> und Wert von <size> kann dies eine teure
- Angelegenheit sein.
-
-
-RUeCKGABEWERT
-=============
-
- Der neue Ringpuffer mit Groesse <size>.
-
-
-BEISPIELE
-=========
-
- // Ringpuffer anlegen:
- struct std_ringbuffer buffer = CreateRingBuffer(5, MODE_FIFO);
- // 5 Werte reinschreiben:
- foreach(int i: 5) RingBufferPut(buffer, i);
- // Groesse aendern
- buffer = ResizeRingBuffer(buffer, 10);
- // Daten als Array ermitteln:
- mixed array = RingBufferGet(buffer);
- // array enthaelt: ({0,0,0,0,0,0,1,2,3,4})
-
-
-SIEHE AUCH
-==========
-
- RingBufferGet(), RingBufferPut(), CreateRingBuffer()
-
-23.05.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/RingBufferGet b/doc/sphinx/man/lfun/RingBufferGet
deleted file mode 100644
index 128807f..0000000
--- a/doc/sphinx/man/lfun/RingBufferGet
+++ /dev/null
@@ -1,63 +0,0 @@
-
-RingBufferGet()
-***************
-
-
-FUNKTION
-========
-
- protected mixed RingBufferGet(struct std_ringbuffer buf);
-
-
-DEFINIERT IN
-============
-
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
-
-
-ARGUMENTE
-=========
-
- buf - Ringpuffer, welcher ausgeben werden soll
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert die Daten des Ringpuffers in Form eines Arrays
- zurueck, welches dann weiterverarbeitet werden kann.
- Die Reihenfolge der Daten ist entsprechend des beim Anlegen des
- Ringpuffers angebenen Modes:
- MODE_FIFO: aelteste Daten zuerst
- MODE_LIFO: neueste Daten zuerst
-
-
-BEMERKUNGEN
-===========
-
- Aenderungen am Array beeinflussen die Daten des Ringpuffers nicht. Aber:
- Hierbei werden die Daten nicht tief kopiert. D.h. enthaelt der Ringpuffer
- Referenzen auf weitere Daten, zeigen der Ringpuffer und das hier
- gelieferte Array auf die gleichen Daten.
-
-
-BEISPIELE
-=========
-
- // Ringpuffer anlegen:
- struct std_ringbuffer buffer = CreateRingBuffer(10, MODE_FIFO);
- // 15 Werte reinschreiben:
- foreach(int i: 15) RingBufferPut(buffer, i);
- // Werte abrufen:
- mixed array=RingBufferGet(buffer);
- // array enthaelt nun:
- // ({5,6,7,8,9,10,11,12,13,14})
-
-
-SIEHE AUCH
-==========
-
- CreateRingBuffer(), RingBufferPut(), ResizeRingBuffer()
-
-23.05.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/RingBufferPut b/doc/sphinx/man/lfun/RingBufferPut
deleted file mode 100644
index 00c046c..0000000
--- a/doc/sphinx/man/lfun/RingBufferPut
+++ /dev/null
@@ -1,49 +0,0 @@
-
-RingBufferPut()
-***************
-
-
-FUNKTION
-========
-
- protected void RingBufferPut(struct std_ringbuffer buf, mixed val);
-
-
-DEFINIERT IN
-============
-
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
-
-
-ARGUMENTE
-=========
-
- buf - Ringpuffer, in den <val> geschrieben werden soll
- val - neues Datum
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion schreibt <val> in den Ringpuffer <buf>. Hierbei wird ggf.
- das aelteste im Puffer existierende Datum ueberschrieben. <buf> muss eine
- von CreateRingBuffer() oder ResizeRingBuffer() zurueckgelieferter
- Ringpuffer sein.
-
-
-BEISPIELE
-=========
-
- // Ringpuffer anlegen:
- struct std_ringbuffer buffer = CreateRingBuffer(10, MODE_FIFO);
- // 15 Werte reinschreiben:
- foreach(int i: 15) RingBufferPut(buffer, i);
-
-
-SIEHE AUCH
-==========
-
- RingBufferGet(), CreateRingBuffer(), ResizeRingBuffer()
-
-23.05.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/SearchPath b/doc/sphinx/man/lfun/SearchPath
deleted file mode 100644
index 040965e..0000000
--- a/doc/sphinx/man/lfun/SearchPath
+++ /dev/null
@@ -1,108 +0,0 @@
-
-SearchPath()
-************
-
-
-FUNKTION
-========
-
- public int SearchPath(string from, string to, int para,
- closure callback)
-
-
-DEFINIERT IN
-============
-
- /p/daemon/pathd.c
- <sys/path.d>
-
-
-ARGUMENTE
-=========
-
- from - Der Startpunkt
- to - Der Endpunkt
- para - Die Parawelt in der gesucht wird (Normalwelt: 0)
- callback - Closure, die am Ende der Pfadsuche gerufen wird
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion berechnet - sofern moeglich - den kuerzesten Pfad zwischen
- <from> und <to> in der (Para-)Welt <para>.
-
-
-
- Die Pfadsuche wird anhand von Daten ueber von Spielern gelaufene Wege
- durchgefuehrt. D.h. Gebiete, die von Spielern nicht (in letzter Zeit mal)
- betreten werden, sind auch dem Pfaddaemon nicht bekannt. Auch kann es
- Gebiete geben, wo zwar gebietsintern Pfade bekannt sind, aber keine Wege
- in den Rest vom MG.
-
- Da diese Suche im Allgemeinen SEHR aufwendig sein kann, wird sie meistens
- nicht sofort fertig, sondern dauert eine Weile. Wenn sie fertig ist, wird
- die Closure <callback> aufgerufen und ihr die Argumente <from>, <to>,
- <parawelt>, <kosten>, <path> und <cmds> uebergeben. Die Bedeutung
- dieser Argumente ist unten erklaert.
-
- Eine Suche nach einem Pfad in einer Parawelt fuehrt durch Raeume der
- gewuenschen Parawelt und durch Raeume der Normalwelt.
-
-
-RUeCKGABEWERT
-=============
-
- 1 - Suche wurde gestartet
- 2 - Pfad gefunden (und callback gerufen)
- -1 - es laeuft schon ein Suchauftrage fuer die UID des anfragenden
- Objektes
- -2 - es laufen bereits zuviele Suchanfragen
- -3 - <from> und/oder <to> sind nicht bekannt
-
-
-
- An <callback> uebergebene Argumente am Ende der Pfadsuche:
- <from> - Startpunkt des Weges (string)
- <to> - Zielpunkt des Weges (string)
- <para> - Parawelt des Weges (int)
- <costs>- Kosten des Wege. (int) Je hoeher, desto
- laenger/unguenstiger. 0, wenn kein Pfad gefunden
- <path> - Array mit Raumnamen, die durchlaufen werden (string*)
- 0, wenn kein Pfad gefunden
- <cmds> - Array mit Kommandos zum Ablaufen des Weges (string*)
- 0, wenn kein Pfad gefunden
-
-
-BEMERKUNGEN
-===========
-
- Es ist natuerlich nicht dazu gedacht, Spielern fertige Routen zwischen
- Orten zu geben - bzw. nur in Ausnahmefaellen.
- Pfadabfrgen werden geloggt.
-
- Die Angabe <costs> sagt grob etwas ueber die Laenge und vor allem ueber die
- "Qualitaet" des Pfades aus. Die steigt bei Paraweltwechseln, wenig
- abgelaufenen Verbindungen zwischen Raeumen oder wenn eine Verbindung kein
- normaler Ausgang ist.
-
- Die Closure <callback> sollte nicht zuviele Ticks verbrauchen.
-
-
-BEISPIEL
-========
-
- #include <pathd.h>
- void suchergebnis(string from, string to, int para, int costs, string*
- path, string* cmds) {
- tell_object(find_player("zesstra"), sprintf(
- "Ergebnis Pfadsuche von %s nach %s in Para %d fuer %d:\n %O\n %O\n",
- from, to, para, costs, path, cmds));
- };
-
- ...
- mixed res=PATHD->SearchPath("/gilden/abenteurer",
- "/d/ebene/dancer/lucky/room/pova_la3",
- 0, #'suchergebnis);
-
-22.12.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/SelectEnemy b/doc/sphinx/man/lfun/SelectEnemy
deleted file mode 100644
index 5a05eab..0000000
--- a/doc/sphinx/man/lfun/SelectEnemy
+++ /dev/null
@@ -1,51 +0,0 @@
-
-SelectEnemy()
-*************
-
-
-FUNKTION
-========
-
- varargs object SelectEnemy(object*here);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- here
- Gegner, aus welchen ausgewaehlt werden soll (optional!)
-
-
-RUeCKGABEWERT
-=============
-
- Ausgewaehlter Gegner, der angegriffen werden soll.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion waehlt einen Gegner aus, der angegriffen werden soll.
- Werden keine Gegner im Parameter <here> angegeben, so wird der
- Rueckgabewert der Funktion PresentEnemies() verwandt, welche die
- aktuell anwesenden Gegner im Raum liefert.
- Sind keine Gegner anwesend, so wird 0 zurueckgeliefert.
- Danach wird geschaut, ob Gegner bevorzugt ausgewaehlt werden sollen.
- Dies geschieht mittels der Funktion QueryPreferedEnemy().
- Auch dieser bevorzugte Gegner muss im selben Raum sein! Wenn nicht,
- wird doch irgendein anderer Gegner ausgewaehlt und zurueckgegeben.
-
-
-SIEHE AUCH
-==========
-
- PresentEnemies(), QueryPreferedEnemy(), P_PREFERED_ENEMY,
- InsertEnemy(), StopHuntFor()
-
-Last modified: Thu May 27 15:01:48 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/SelectFarEnemy b/doc/sphinx/man/lfun/SelectFarEnemy
deleted file mode 100644
index c390d42..0000000
--- a/doc/sphinx/man/lfun/SelectFarEnemy
+++ /dev/null
@@ -1,65 +0,0 @@
-
-SelectFarEnemy()
-****************
-
-
-FUNKTION
-========
-
- varargs object SelectFarEnemy(object *here, int min, int max,
- int forcefrom)
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- here - Rueckgabewert von PresentEnemies()
- min - minimale Kampfreihe
- max - maximale Kampfreihe
- forcefrom - Gegner MUSS aus uebergebenem Array ausgewaehlt werden
-
-
-BESCHREIBUNG
-============
-
- Waehlt einen Feind aus Reihe <min> bis <max> aus.
-
-
-RUECKGABEWERT
-=============
-
- Der Auserwaehlte :-)
-
-
-BEMERKUNGEN
-===========
-
- 1. Wenn in den angegeben Reihen kein Feind ist oder <max> kleiner
- als <min> ist, wird auch keiner zurueckgegeben.
- 2. Aus Effizienzgruenden sollte forcefrom nur benutzt werden, wenn
- es wirklich noetig ist (s. hierzu auch SelectNearEnemy()).
- 3. 0 <= <min> <= <max> < MAX_TEAMROWS
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/SelectNearEnemy b/doc/sphinx/man/lfun/SelectNearEnemy
deleted file mode 100644
index 43ba033..0000000
--- a/doc/sphinx/man/lfun/SelectNearEnemy
+++ /dev/null
@@ -1,69 +0,0 @@
-
-SelectNearEnemy()
-*****************
-
-
-FUNKTION
-========
-
- varargs object SelectNearEnemy(object *here, int forcefrom)
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- here - Rueckgabewert von PresentEnemies()
- forcefrom - Gegner MUSS aus uebergebenem Array ausgewaehlt werden
-
-
-BESCHREIBUNG
-============
-
- Waehlt einen im Nahkampf erreichbaren Feind aus
-
-
-RUECKGABEWERT
-=============
-
- Der Auserwaehlte :-)
-
-
-BEMERKUNGEN
-===========
-
- 1. Falls der Spieler in einem Team ist und in einer hinteren Reihe
- steht, wird kein Feind ausgewaehlt, es sei denn, der Spieler hat
- einen Kampf mit einem Teammitglied angefangen.
- 2. Wenn ein bevorzugter Feind in einer der hinteren Reihen eines
- Teams steht, wird solange das Team bevorzugt.
- 3. Auch Feinde in den hinteren Reihen koennen im Nahkampf erreichbar
- sein, wenn die vorderen Reihen nicht genuegend Deckung bieten.
- 4. ACHTUNG: Der Auserwaehlte kommt nicht notwendigerweise aus dem
- uebergebenen Array, wenn forcefrom=0 ist. Normalerweise ist dieses
- Verhalten beabsichtigt, damit jemand, der sich in der Reihe vor
- einen Gegner stellt, angegriffen wird, auch wenn er noch nicht
- Feind ist.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/Set b/doc/sphinx/man/lfun/Set
deleted file mode 100644
index d654027..0000000
--- a/doc/sphinx/man/lfun/Set
+++ /dev/null
@@ -1,174 +0,0 @@
-
-Set()
-*****
-
-
-FUNKTION
-========
-
- public varargs mixed Set(string name, mixed Value, int Type, int extern);
-
-
-DEFINIERT IN
-============
-
- /std/thing/properties.c
- /sys/thing/properties.h (Prototyp)
-
-
-ARGUMENTE
-=========
-
- name - Property, die manipuliert werden soll
- Value - der zu setzende/aendernde Wert
- Type - die Eigenschaft der Property, die manipuliert werden soll
- extern - Interne Verwendung:
- Wurde Set ueber SetProp von aussen gerufen.
-
-
-BESCHREIBUNG
-============
-
- Eine der inneren Eigenschaften der Property 'name' wird veraendert.
- 'Type' ist dabei einer der in /sys/thing/properties.h definierten
- F_XXX - Werte:
-
- F_VALUE (==0, default)
- Setzt den Inhalt der Property auf 'Value'. Aehnlich "SetProp",
- umgeht jedoch eine etwaige F_SET_METHOD oder _set_'name'()-Methode.
- F_MODE
- F_MODE_AS
- F_MODE_AD
- Aendert eines der internen Flags der Property. F_MODE negiert den
- vorherigen Wert vom Flag 'Value', F_MODE_AS setzt und F_MODE_AD
- loescht ihn.
- Verfuegbare interne Flags:
-
- SAVE
-
- Property wird bei save_object() gespeichert
-
- PROTECTED
-
- Flag setzbar durch: beliebiges Objekt
- Flag loeschbar durch: this_object(), ROOT, EM+
- Inhalt der Property veraendern sowie Set- und Query-Methoden
- setzen oder loeschen duerfen nur noch this_object(), ROOT, EM+
- WARNUNG: Dieses Flag nicht leichtfertig bei Spielern setzen!
-
- SECURED
-
- Flag setzbar durch: this_object(), ROOT, EM+
- Flag loeschbar durch: Niemanden!
- Inhalt der Property veraendern sowie Set- und Query-Methoden
- setzen oder loeschen duerfen nur noch this_object(), ROOT, EM+
-
- NOSETMETHOD
-
- Property nicht mehr ueber SetProp() aenderbar
- (damit entfallen auch SET_METHOD, _set_'name')
- F_SET_METHOD
- Aendert den Eintrag fuer eine SetMethod - eine Closure, die anstatt
- des Setzens der Property beim Aufruf von SetProp mit 'Value'
- aufgerufen wird.
- F_QUERY_METHOD
- Aendert den Eintrag fuer eine QueryMethod - eine Closure, die anstatt
- des Lesens der Property beim Aufruf von QueryProp aufgerufen wird.
-
-
-RUeCKGABEWERT
-=============
-
- Das Ergebnis der Manipulation bzw. einer der definierten
- Fehlercodes.
-
-
-BEMERKUNGEN
-===========
-
- - Set() sollte nicht zum regulaeren Manipulieren des Inhalts einer
- Property verwendet werden, da sowohl F_SET_METHOD als auch libinterne
- _set_'name'()-Methoden umgangen werden und das Ergebnis fuer so
- veraenderte Properties undefiniert ist.
- - eine gesetzte F_SET/F_QUERY_METHOD hat bei SetProp/QueryProp Vorrang
- vor einer _set/_query_method
- -> _set/_query wird nach erfolgreichem Ruf von F_XXX_METHOD ignoriert
- - F_SET/F_QUERY_METHOD sollte normalerweise Vorzug vor einer
- _set_/_query_* gegeben werden.
-
- SetMethods/QueryMethods:
- - falls ihr Query/SetMethods an oeffentlichen Properties setzen
- wollt, prueft bitte vorher, ob dort nicht schon eine (fremde) gesetzt
- ist und brecht ggf. euer Set() ab, um nicht die Arbeit anderer
- Mitmagier zu sabotieren (z.B. P_HANDS)
- - Properties sollten mit Query- oder SetMethoden nur so lange wie
- noetig belegt werden
- -> manche Properties sollte man als Wert setzen, _auch wenn_ die
- Spieler sie zuruecksetzen koennten (zB P_MSGIN/P_MSGOUT)
- - auf keinen Fall den Wert speichern, ueberschreiben, rueckschreiben,
- das fuehrt fast immer zu Problemen.
- - Set/QueryMethoden sollten nicht als Trigger/Listener fuer ein
- Ereignis (z.B. P_DIE_MSG fuer das Ereignis "Tod des Spielers")
- missbraucht werden
- -> es gibt sichere und saubere Moeglichkeiten (NotifyPlayerDeath),
- und wenn nicht, wendet euch an den EM eures Vertrauens
- - F_SET/F_QUERY_METHODs koennen 'protected' (empfohlen) oder 'static'
- sein. _set_/_query_ duerfen momentan _nicht_ 'protected' sein, fuer
- geht nur 'static' (in diesem Fall empfohlen).
-
-
-BEISPIELE
-=========
-
- ### Aendern von Eigenschaften einer Property ###
- // Setzen des SAVE-Flags (bei save_object() mitzuspeichern)
- Set(P_XYZ, SAVE, F_MODE_AS);
-
- // Loeschen des SAVE-Flags
- Set(P_XYZ, SAVE, F_MODE_AD);
-
-
-
- // Negieren des bisherigen SAVE-Flags
- Set(P_XYZ, SAVE, F_MODE);
- // Hinweis: das Setzen des Flags funktioniert mittels F_MODE nur dann,
- // wenn sichergestellt ist, dass es vorher nicht gesetzt war. Die
- // sichere Variante ist daher, F_MODE_AS zu verwenden.
-
- // Sperren des SetProp/SET_METHOD-Zugriffs:
- Set(P_XYZ, NOSETMETHOD, F_MODE_AS);
-
- // Vorlaeufiger Zugriffsschutz fuer eine Property:
- Set(P_XYZ, PROTECTED, F_MODE_AS);
-
- // Permanenter Zugriffsschutz fuer eine Property:
- Set(P_XYZ, SECURED, F_MODE_AS);
-
- ### Setzen einer SetMethod/QueryMethod ###
- // Setzen einer internen SetMethod
- mixed foo(mixed val);
- ...
- Set(P_XYZ, #'foo, F_SET_METHOD);
- ...
-
- // Setzen einer QueryMethod bei einem anderen Objekt
- mixed bar();
- ...
- other->Set(P_XYZ, #'bar, F_QUERY_METHOD);
- ...
-
- // Der Vollstaendigkeit halber sei das Aendern einer Property unter
- // Umgehung von Set-Methoden angegeben. Es ist aber aus o.g. Gruenden
- // zu empfehlen, diese Variante nicht zu verwenden.
- Set(P_XYZ, "bla", F_VALUE);
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: SetProp(L), QueryProp(L), Query(L)
- Generell: SetProperties(L), QueryProperties(L)
- Konzept: properties, /std/thing/properties.c
- Sonstiges: P_AUTOLOADOBJ
-
-6. Jan 2008 Arathorn
diff --git a/doc/sphinx/man/lfun/SetAttackChats b/doc/sphinx/man/lfun/SetAttackChats
deleted file mode 100644
index 90e8a66..0000000
--- a/doc/sphinx/man/lfun/SetAttackChats
+++ /dev/null
@@ -1,104 +0,0 @@
-
-SetAttackChats()
-****************
-
-
-FUNKTION
-========
-
- void SetAttackChats(int chance, mixed strs);
-
-
-DEFINIERT IN
-============
-
- /std/npc/chat.c
-
-
-ARGUMENTE
-=========
-
- chance
- Prozentuale Wahrscheinlichkeit einer Ausgabe
- strs
- Stringarray mit den Monsterchats
-
-
-BESCHREIBUNG
-============
-
- Der NPC gibt mit der Wahrscheinlichkeit 'chance' einen zufaellig
- gewaehlten Text aus 'strs' von sich. Die Arrayelemente koennen
- auch Funktionen ("@@func@@") oder Closures enthalten, die dann
- aufgerufen werden und deren Rueckgabewerte das Monster dann ausgibt.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- AttackChats werden nur im Kampf ausgegeben. Ansonsten ist SetChats()
- zu verwenden.
-
-
-
- 'chance' wird in der Property P_ACHAT_CHANCE abgelegt. Um einen NPC
- voruebergehend 'stillzulegen', kann man P_ACHAT_CHANCE auf 0 setzen.
-
-
-
- Man kann AttackChats nutzen, um Monsterspells zu realisieren. Besser
- ist es aber, dafuer 'AddSpell' zu verwenden.
-
-
-BEISPIELE
-=========
-
- SetAttackChats( 20,
- ({ "Der Ork tritt Dir in den Hintern.\n",
- "Der Ork bruellt: Lebend kommst Du hier nicht raus!\n",
- "Der Ork blutet schon aus mehreren Wunden.\n",
- "@@knirsch@@" }) );
-
-
-
- string knirsch()
- {
- object *ruestung, *tmp, helm;
-
-
-
- ruestung = this_player()->QueryProp(P_ARMOURS); // getragene Ruestung
- tmp = filter_objects(ruestung, "id", AT_HELMET);
- // Wenn der Spieler einen Helm traegt, enthaelt 'tmp' jetzt
- // ein Array mit dem Helmobjekt als einzigem Element
- if (sizeof(tmp)) helm = tmp[0];
- if (objectp(helm))
- {
- // AC nur dann senken, wenn sie nicht schon 0 ist.
- if (helm->QueryProp(P_AC)>0) {
- helm->Damage(1);
- return "Der Ork beschaedigt Deinen Helm!\n";
- }
- return "";
- }
- else
- return ""; // keine Meldung
- }
-
-
-SIEHE AUCH
-==========
-
- P_ACHAT_CHANCE, SetChats(), /std/npc/chat.c, AddSpell()
-
-
-LETZTE AENDERUNG
-================
-
- Don, 27.12.2007, 16:35:00 von Arathorn
diff --git a/doc/sphinx/man/lfun/SetAttr b/doc/sphinx/man/lfun/SetAttr
deleted file mode 100644
index fe5d97b..0000000
--- a/doc/sphinx/man/lfun/SetAttr
+++ /dev/null
@@ -1,55 +0,0 @@
-
-SetAttr()
-*********
-
-
-FUNKTION
-========
-
- public int SetAttr(string attr, int val)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- attr - zu setzendes Attribut
- val - Wert
-
-
-BESCHREIBUNG
-============
-
- Filtert den Wert durch _filterattr(). Dadurch werden STR, INT, CON, DEX
- auf 20 begrenzt. Setzt dann das Attribut.
- Offsets werden hier nicht beruecksichtigt, QueryAttribute() gibt also
- val + etwaige Offsets/Modifier zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Tatsaechlich gesetzter Wert.
-
-
-BEMERKUNGEN
-===========
-
- Wird von SetAttribute() und SetRealAttribute() aufgerufen.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- TestAttributeLock(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Letzte Aenderung: 22.12.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/SetAttribute b/doc/sphinx/man/lfun/SetAttribute
deleted file mode 100644
index 139fc99..0000000
--- a/doc/sphinx/man/lfun/SetAttribute
+++ /dev/null
@@ -1,49 +0,0 @@
-
-SetAttribute()
-**************
-
-
-FUNKTION
-========
-
- int SetAttribute(string attr, int val)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- attr - zu setzendes Attribut
- val - Wert
-
-
-BESCHREIBUNG
-============
-
- Nimm val als Gesamtwert des Attributes, d.h. zieht etwaige Offsets vor
- Setzen ab. (QueryAttribute gibt dann also val zurueck)
-
-
-RUeCKGABEWERT
-=============
-
- Den durch SetAttr gefilterten gesetzten Wert.
- Bitte nicht auf Spieler anwenden!
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/lfun/SetBuyFact b/doc/sphinx/man/lfun/SetBuyFact
deleted file mode 100644
index 8994bd3..0000000
--- a/doc/sphinx/man/lfun/SetBuyFact
+++ /dev/null
@@ -1,58 +0,0 @@
-
-SetBuyFact()
-************
-
-
-FUNKTION
-========
-
- void SetBuyFact(int fact);
-
-
-DEFINIERT IN
-============
-
- /std/laden.c
-
-
-ARGUMENTE
-=========
-
- fact
- Der Einkaufspreismultiplikator.
-
-
-BESCHREIBUNG
-============
-
- Der Preis, der beim Kauf eines Objekts im Laden zu entrichten ist,
- errechnet sich aus seinem Wert ( P_VALUE), multipliziert mit dem Faktor
- fact. Dieser Preis ist konstant und nicht von der aktuellen Marktlage
- abhaengig.
-
- Der Defaultwert ist 3. Ein hoeherer Wert entspricht einem teuren Laden,
- waehrend ein kleinerer Wert zu kleinen Preisen fuehrt.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Normalerweise kommt man ohne diese Funktion aus: in teuren Laeden wird
- nicht viel eingekauft (es sei denn, es liegen standardmaessig gute
- Objekte im Speicher), einem Billigladen wird bald das Geld ausgehen mit
- der Folge, dass der Ladenbesitzer nichts mehr ankaufen kann und sein
- Lager gaehnend leer ist.
-
-
-SIEHE AUCH
-==========
-
- QueryBuyFact(), /std/laden.c
-
-Last modified: Wed May 8 10:24:52 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/SetChats b/doc/sphinx/man/lfun/SetChats
deleted file mode 100644
index 70d312e..0000000
--- a/doc/sphinx/man/lfun/SetChats
+++ /dev/null
@@ -1,94 +0,0 @@
-
-SetChats()
-**********
-
-
-FUNKTION
-========
-
- void SetChats(int chance,mixed strs);
-
-
-DEFINIERT IN
-============
-
- /std/npc/chat.c
-
-
-ARGUMENTE
-=========
-
- chance
- Prozentuale Wahrscheinlichkeit einer Ausgabe
- strs
- Stringarray mit den Monsterchats
-
-
-BESCHREIBUNG
-============
-
- Der NPC gibt mit der Wahrscheinlichkeit <chance> pro Heartbeat einen
- zufaellig gewaehlten Text aus dem Array <strs> von sich.
- Die Arrayelemente koennen auch Closures oder
- process_string()-Funktionen ("@@func@@") enthalten, die dann
- aufgerufen werden und deren Rueckgabewerte das Monster dann ausgibt.
- (Fuer keine Ausgabe dann Leerstring "" zurueckgeben!)
- In diesen Funktionen ist this_player() das Monster selbst!
- Fuer Zeilenumbrueche ist immer selbst zu sorgen.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- Ein einfaches Beispiel:
- // Prototype fuer Closure.
- static string info1();
- void create()
- { ...
- SetChats(20,
- ({"Der Ork sagt: Hau ab, bevor ich Dich fresse.\n",
- "Der Ork grinst Dich unverschaemt an.\n",
- "Der Ork wedelt mit seinem Saebel vor Deinem Gesicht herum.\n",
- "Der Ork droht Dir mit der Faust.\n",
- #'info1,
- "@@info2@@"}));
- }
- // Funktion als Closure. Prototype notwendig!
- static string info1()
- { if(QueryProp(P_HP)<QueryProp(P_ALIGN))
- return"Gleich werde ich von hier fliehen!\n";
- return"";
- }
- // Funktion als process_string().
- string info2()
- { return QueryProp(P_HP)==QueryProp(P_MAX_HP)?
- "Der Ork grinst: Mir geht es fantastisch!\n":
- "Der Ork seufzt: Mir ging es wirklich schon mal besser.\n";
- }
-
-
-BEMERKUNGEN
-===========
-
- Im Kampf werden keine Chats ausgegeben. Es ist dann SetAttackChats()
- zu verwenden.
- Funktionen als process_string() sollte man nicht mehr verwenden.
- <chance> wird in der Property P_CHAT_CHANCE abgelegt. Um einen NPC
- voruebergehend 'stillzulegen', kann man P_CHAT_CHANCE auf 0 setzen.
- Wenn kein Spieler anwesend ist, haben NPC in der Regel keinen Heartbeat,
- weswegen dann auch die Chats ausgeschaltet sind.
- Spieler koennen NPC 'stillen', d.h. Chats und AttackChats abschalten.
-
-
-SIEHE AUCH
-==========
-
- P_CHAT_CHANCE, SetAttackChats(), process_string()
-
-Last modified: Sat Jan 18 18:48:06 2003 by Patryn
diff --git a/doc/sphinx/man/lfun/SetCoinsPerUnits b/doc/sphinx/man/lfun/SetCoinsPerUnits
deleted file mode 100644
index 0533275..0000000
--- a/doc/sphinx/man/lfun/SetCoinsPerUnits
+++ /dev/null
@@ -1,63 +0,0 @@
-
-SetCoinsPerUnits()
-******************
-
-
-FUNKTION
-========
-
- void SetCoinsPerUnits(int coins, int units);
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- coins
- Zahl der Muenzen
- units
- Zahl der Einheiten
-
-
-BESCHREIBUNG
-============
-
- Es wird festgelegt, wieviel eine bestimmte Menge der Einheiten kostet.
- Eine einzelne Einheit kostet coins/units Muenzen.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Bei der Preisberechnung wird abgerundet. Hat man also ein Verhaeltnis
- von einer Muenze pro zwei Einheiten, so ist der Preis einer einzelnen
- Einheit 0!
-
-
-BEISPIELE
-=========
-
- Eine Einheit soll 3.5 Muenzen wert sein:
-
- /* 7 Muenzen / 2 Einheiten = 3.5 Muenzen / Einheit */
- SetCoinsPerUnits(7,2);
-
-
-SIEHE AUCH
-==========
-
- QueryCoinsPerUnits(), SetGramsPerUnits(), QueryGramsPerUnits(),
- /std/unit.c
-
-Last modified: Wed May 8 10:24:57 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/SetDoorStatus b/doc/sphinx/man/lfun/SetDoorStatus
deleted file mode 100644
index c433c40..0000000
--- a/doc/sphinx/man/lfun/SetDoorStatus
+++ /dev/null
@@ -1,49 +0,0 @@
-
-SetDoorStatus()
-***************
-
-
-FUNKTION
-========
-
- void SetDoorStatus(string dest, int status);
-
-
-DEFINIERT IN
-============
-
- /obj/doormaster.c
-
-
-ARGUMENTE
-=========
-
- <dest> = Zielraum der Tuer.
- <status> = Der neue Zustand der Tuer.
-
-
-BESCHREIBUNG
-============
-
- Der Zustand der Tuer, die von diesem Raum nach <dest> fuehrt, wird auf
- <status> geaendert. Hierbei muss <status> einer der drei folgenden Werte
- aus <doorroom.h> sein:
-
- D_STATUS_LOCKED - Tuer abgeschlossen
- D_STATUS_CLOSED - Tuer geschlossen
- D_STATUS_OPEN - Tuer geoeffnet
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- NewDoor(), QueryDoorKey(), QueryDoorStatus(), P_DOOR_INFOS,
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
-
-Letzte Aenderung: Don, 08.05.2014, Gabylon
diff --git a/doc/sphinx/man/lfun/SetEnemies b/doc/sphinx/man/lfun/SetEnemies
deleted file mode 100644
index 2c92035..0000000
--- a/doc/sphinx/man/lfun/SetEnemies
+++ /dev/null
@@ -1,53 +0,0 @@
-
-SetEnemies()
-************
-
-
-FUNKTION
-========
-
- mapping SetEnemies(object *myenemies);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- myenemies
- Array: ({Gegnerarray, Zeitenarray})
-
-
-RUeCKGABEWERT
-=============
-
- Internes Mapping mit bekannten Gegnern und Zeiten.
-
-
-BESCHREIBUNG
-============
-
- Normalerweise fuegt man einzelne Gegner mittels InsertEnemy() ein und
- loescht alte Feinde mittels StopHuntFor().
-
- Um jedoch mit einem Schlag viele Veraenderungen vorzunehmen, kann man
- die Funktion SetEnemies() nutzen.
-
- Ihr uebergibt man ein Array mit einem Array mit den gewuenschten Gegnern
- als und einem zweiten, gleichgrossen Array mit den Zeiten, wie lange
- diese Gegner aktuell sein sollen, als Eintraege.
-
- Die Funktion traegt diese Werte als Gegner mit entsprechender
- Feindeszeit ein.
-
-
-SIEHE AUCH
-==========
-
- InsertEnemy(), StopHuntFor(), SelectEnemy(), PresentEnemies()
-
-10.Feb 2005 Gloinson
diff --git a/doc/sphinx/man/lfun/SetGramsPerUnits b/doc/sphinx/man/lfun/SetGramsPerUnits
deleted file mode 100644
index 66c1934..0000000
--- a/doc/sphinx/man/lfun/SetGramsPerUnits
+++ /dev/null
@@ -1,54 +0,0 @@
-
-SetGramsPerUnits()
-******************
-
-
-FUNKTION
-========
-
- void SetGramsPerUnits(int grams, int units);
-
-
-DEFINIERT IN
-============
-
- /std/unit.c
-
-
-ARGUMENTE
-=========
-
- grams
- Gewicht in Gramm
- units
- Zahl der Einheiten
-
-
-BESCHREIBUNG
-============
-
- Es wird festgelegt, wieviel eine bestimmte Menge der Einheiten wiegt.
- Eine einzelne Einheit wiegt grams/units Gramm.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- Vier Einheiten sollen 3 Gramm wiegen:
-
- SetGramsPerUnits(3,4);
-
-
-SIEHE AUCH
-==========
-
- SetCoinsPerUnits(), QueryCoinsPerUnits(), QueryGramsPerUnits(),
- /std/unit.c
-
-Last modified: Wed May 8 10:25:09 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/SetProp b/doc/sphinx/man/lfun/SetProp
deleted file mode 100644
index 9664be8..0000000
--- a/doc/sphinx/man/lfun/SetProp
+++ /dev/null
@@ -1,70 +0,0 @@
-
-SetProp()
-*********
-
-
-FUNKTION
-========
-
- public mixed SetProp(string name, mixed Value);
-
-
-DEFINIERT IN
-============
-
- /std/thing/properties.c
- /sys/thing/properties.h (Prototyp)
-
-
-ARGUMENTE
-=========
-
- name - Property, deren Wert veraendert werden soll.
- Value - Wert, auf den der Inhalt der Property gesetzt werden soll
-
-
-BESCHREIBUNG
-============
-
- Der Datenwert der Property 'name' wird auf den Wert 'Value' gesetzt.
-
- Existiert eine F_SET_METHOD oder eine _set_'name'()-Methode fuer
- diese Property, so wird diese aufgerufen und ihr 'Value' uebergeben.
- Eine F_SET_METHOD hat dabei Vorrang vor _set_'name'(), d.h.
- _set_'name'() wird nach erfolgreicher F_QUERY_METHOD nicht mehr
- gerufen.
-
- (Diese Methoden nutzen dann Set(), um den Datenwert der Property
- 'name' zu aendern. Teilweise werden aber auch interne Variablen so
- oeffentlich gemacht und sind nicht in der ueber Set/Query verfuegbaren
- Property 'name' abgelegt.)
-
-
-RUeCKGABEWERT
-=============
-
- Der Wert, der nun in der Property gespeichert ist.
- In der Regel ist das 'Value'. Wenn die Property ueber eine SET_METHOD
- oder eine _set_'name'()-Funktion verfuegt und diese 'Value' aendert
- (zum Beispiel, indem sie 'Value' an einen bestimmten erlaubten
- Wertebereich anpasst), kann der Rueckgabewert jedoch auch veraendert
- sein.
-
- Wenn die Property nicht veraendert werden darf, wird -1 zurueckgegeben.
-
-
-BEISPIELE
-=========
-
- // geben wir dem Zwerg eine Kurzbeschreibung
- SetProp(P_SHORT, "Ein kleiner Zwerg");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: QueryProp(L), Set(L), Query(L)
- Generell: SetProperties(L), QueryProperties(L)
- Konzept: properties, /std/thing/properties.c
-
-15.Dez 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/SetProperties b/doc/sphinx/man/lfun/SetProperties
deleted file mode 100644
index a4ac72a..0000000
--- a/doc/sphinx/man/lfun/SetProperties
+++ /dev/null
@@ -1,48 +0,0 @@
-
-SetProperties()
-***************
-
-
-FUNKTION
-========
-
- void SetProperties(mapping props);
-
-
-DEFINIERT IN
-============
-
- /std/thing/properties.c
-
-
-ARGUMENTE
-=========
-
- props - Mapping mit den Daten fuer alle Properties
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion setzt angegebene Properties auf einen Schlag.
- Mapping muss wie folgt aufgebaut sein:
- ([ name: wert; flags; set_method; query_method,
- name2: ... ]);
-
-
-BEMERKUNGEN
-===========
-
- - diese Funktion wird von restore_object() verwendet, um nicht alle
- restaurierten Properties einzeln setzen zu muessen.
- - SECURED/PROTECTED/NOSETMETHOD Properties werden beruecksichtigt
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: SetProp(L), QueryProp(L), Set(L), Query(L)
- Generell: QueryProperties(L)
- Konzept: properties, /std/thing/properties.c
-
-1.Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/SetRealAttribute b/doc/sphinx/man/lfun/SetRealAttribute
deleted file mode 100644
index fc72d9b..0000000
--- a/doc/sphinx/man/lfun/SetRealAttribute
+++ /dev/null
@@ -1,55 +0,0 @@
-
-SetRealAttribute()
-******************
-
-
-FUNKTION
-========
-
- int SetRealAttribute(string attr, int val)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- attr - zu setzendes Attribut
- val - Wert
-
-
-BESCHREIBUNG
-============
-
- Setzt den realen Wert des Attributes, d.h. das reine Attribut,
- wenn moeglich. Lediglich eine Alias-Methode fuer SetAttr().
- (QueryAttribute() gibt also val + etwaige Offsets/Modifier zurueck)
-
-
-RUeCKGABEWERT
-=============
-
- Den gesetzten Wert.
-
-
-BEMERKUNGEN
-===========
-
- Bitte nicht auf Spieler anwenden!
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/lfun/SetSpellFatigue b/doc/sphinx/man/lfun/SetSpellFatigue
deleted file mode 100644
index f2c5861..0000000
--- a/doc/sphinx/man/lfun/SetSpellFatigue
+++ /dev/null
@@ -1,99 +0,0 @@
-
-SetSpellFatigue()
-*****************
-
-
-FUNKTION
-========
-
- public varargs int SetSpellFatigue(int duration, string key)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
- /std/player/skills.c
- /sys/living/skills.h
-
-
-ARGUMENTE
-=========
-
- int duration: Wie lang soll die Spruchermuedung andauern?
- string key : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
- oder 0 fuer die globale Spruchermuedung.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion dient zum Verwalten von individuellen Spruchermuedungen
- (Spellfatigue, Spruchsperren).
- Hiermit lassen sich unabhaengige Ermuedungen/Sperren fuer einzelne
- Sprueche oder Gruppen von Spruechen gestalten.
-
- <duration> ist die Zeit (in Sekunden), welche die Spruchermuedung
- anhalten soll (nicht die Endzeit).
-
- Wird <key> nicht angegeben oder ist 0, wird die globale Spruchsperre
- gesetzt (identisch zu der Property P_NEXT_SPELL_TIME), anderenfalls die
- unter <key> gespeicherte Spruchermuedung.
- Setzt man einen Eintrag ohne Angabe von <key> bedeutet dies damit auch,
- dass der Wert von P_NEXT_SPELL_TIME geaendert wird.
-
-
-RUeCKGABEWERT
-=============
-
- -1 Der Eintrag <key> ist noch nicht abgelaufen, es wurde _keine_
- neue Spruchermuedung/-Sperre gespeichert.
-
- >0 Eintrag wurde gespeichert, Rueckgabewert ist die Zeit, zu der die
- Sperre ablaeuft.
-
-
-BEISPIELE
-=========
-
- Ein Spell gehoert zu einer Gruppe von Spells mit dem Namen 'extrasuess'.
- Er darf nur ausgefuehrt werden, wenn seit 5s kein anderer Spruch aus der
- Gruppe ausgefuehrt wurde.
- if (CalculateSpellSuccess(...) > x) {
- // Spellfatigue setzen (und Erfolg pruefen!)
- if (ob->SetSpellFatigue(5, "extrasuess") > -1) {
- tell_object(ob, "Du fuetterst " + enemy->Name(WEN) + " mit einem "
- "Stueck suesser Schokotorte.\n");
- ...
- }
- else {
- // Sauerei! Zu ermuedet fuer diesen Spruch. Fehlermdeldung ...
- }
- }
- Dieses setzt natuerlich voraus, dass alle anderen Sprueche der Gruppe
- "extrasuess" den gleichen <key> pruefen und setzen.
- (Will man vor CalculateSpellSuccess() wissen, ob der Spruch ueberhaupt
- gewirkt werden duerfte, sollte man hierzu dann CheckSpellFatigue()
- verwenden.)
-
-
-BEMERKUNGEN
-===========
-
- Die genauen Zeitdauern koennen von Spielern beeinflusst werden, sie
- unterliegen der jeweiligen Einstellung von 'spruchermuedung', d.h. koennen
- auf volle 2s aufgerundet werden. (Dies ist nicht der Fall bei NPC.)
- Auch wenn diese Funktion zum Verwalten von beliebigen Zeitsperren genutzt
- werden koennen, beschraenkt euch bitte auf Spruchermuedungen und benutzt
- ansonsten check_and_update_timed_key(). Falls ihr diesbzgl. weitere/andere
- Wuensche habt, sprecht den/die Mudlib-EM an.
-
-
-SIEHE AUCH
-==========
-
- CheckSpellFatigue(L), DeleteSpellFatigue(L)
- P_NEXT_SPELL_TIME
- spruchermuedung
-
-27.03.2010, Zesstra
diff --git a/doc/sphinx/man/lfun/SetStorageRoom b/doc/sphinx/man/lfun/SetStorageRoom
deleted file mode 100644
index f1d66a5..0000000
--- a/doc/sphinx/man/lfun/SetStorageRoom
+++ /dev/null
@@ -1,108 +0,0 @@
-
-SetStorageRoom()
-****************
-
-
-FUNKTION
-========
-
- void SetStorageRoom(string store);
-
-
-DEFINIERT IN
-============
-
- /std/room/shop.c
-
-
-ARGUMENTE
-=========
-
- store
- Dateiname des Lagers, in dem die aufgekauften Objekte aufbewahrt
- werden.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion wird dem Laden bekannt gegeben, welches Objekt
- als Lager fuer angekaufte Objekte dienen soll. Jeder Laden muss
- explizit einen eigenen Lagerraum setzen, ansonsten wird ein
- Laufzeitfehler ausgeloest und der Laden ist nicht ladbar.
-
-
-
- Das Speicherobjekt sollte /std/store.c erben, da dort einige
- Aufraeumfunktionen definiert sind. Entscheidend fuer selbige sind
- die Properties P_MIN_STOCK und P_STORE_CONSUME.
-
-
-BEISPIELE
-=========
-
- Der Raum 'myladen.c' koennte etwa so aussehen:
-
-
-
- // myladen.c
- inherit "/std/shop";
- #include <properties.h>
-
-
-
- protected void create() {
- ::create();
- SetProp(...); // Beschreibung wie bei normalen Raeumen
- SetStorageRoom("/d/beispiel/mystore");
- AddFixedObject("/items/fackel");
- }
-
- In diesem Laden wird nun die Standardfackel als mengenmaessig
- unbegrenzter Artikel verkauft.
-
- Der zugehoerige Lagerraum 'mystore.c' kann dann im einfachsten Fall
- so aussehen:
-
-
-
- // mystore.c
- inherit "/std/store";
- #include <rooms.h> // Fuer AddItem-Konstanten
-
-
-
- protected void create() {
- ::create();
- // KEINE weiteren Beschreibungen!
- // 1. erbt der Speicher keine Beschreibungsmodule,
- // 2. sollen da eh nur Sachen und keine Spieler rein!
- AddItem("/items/schaufel", REFRESH_REMOVE);
- }
-
-
-
- Der Laden verkauft nun auch Schaufeln, jedoch nur eine pro Reset.
-
-HINWEISE:
- Fuer standardmaessig verkaufte Waren beachte man den Unterschied
- zwischen den Funktionen AddItem() und AddFixedObject(). Die
- erstgenannte Funktion ist im Lager zu verwenden, letztere jedoch im
- Laden.
-
-
-SIEHE AUCH
-==========
-
- Allgemeines: laden
- Funktionen: AddItem(L), AddFixedObject(L), RemoveFixedObject(L)
- Basisobjekte: /std/store.c
- Properties: P_MIN_STOCK, P_STORE_CONSUME
-
-Last modified: 19-Jun-2015, Arathorn
diff --git a/doc/sphinx/man/lfun/SetTimedAttrModifier b/doc/sphinx/man/lfun/SetTimedAttrModifier
deleted file mode 100644
index 5ab39dd..0000000
--- a/doc/sphinx/man/lfun/SetTimedAttrModifier
+++ /dev/null
@@ -1,113 +0,0 @@
-
-SetTimedAttrModifier()
-**********************
-
-
-FUNKTION
-========
-
- int SetTimedAttrModifier(string key, mapping modifier,
- int outdated, object dependent, mixed notify)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-ARGUMENTE
-=========
-
- key - in P_TIMED_ATTR_MOD vorzunehmender oder zu
- aendernder Eintrag
- modifier - Mapping mit den Attributveraenderungen
- outdated - Zeitpunkt zu dem die Attributveraenderungen
- ablaufen sollen in Sekunden seit dem
- 1. Jan 1970, 0.0:0 GMT oder 0
- dependent - Objekt dessen Existenz eine Bedingung fuer die
- Attributveraenderung sein soll oder 0
- notify - Objekt oder File das mittels
- NotifyTimedAttrModExpired ueber
- den Attributablauf informiert werden soll
-
-
-BESCHREIBUNG
-============
-
- Der zu key gehoerende Eintrag wird in P_TIMED_ATTR_MOD angelegt oder
- modifiziert und update_max_sp_and_hp aufgerufen.
- Es empfiehlt sich auf die Eindeutigkeit des string-Parameters key
- besonderes Augenmerk zu legen.
-
- Unter dem Key key wird in P_TIMED_ATTR_MOD ein Eintrag vorgenommen,
- welcher die Attribute des Livings um die in modifier stehenden Offsets
- veraendert.
-
- Diese Veraenderung ist solange aktiv bis entweder die in outdated
- stehende Zeit ueberschritten ist oder das in dependent uebergebene
- Objekt nicht mehr existiert.
- Sind beide Argumente 0 so laeuft die Attributveraenderung nicht ab
- und kann durch DeleteTimedAttrModifier geloescht werden.
- Laeuft die Attributveraenderung ab, so wird der in notify angegebene
- Empfaenger mittels Aufruf NotifyTimedAttrModExpired davon
- benachrichtigt.
- Der Funktion NotifyTimedAttrModExpired wird als Argument der key
- der abgelaufenen Attributveraenderung uebergeben.
-
-
-BEISPIELE
-=========
-
- Ein NPC kann einen Spieler auf die folgende Weise solange die
- Attribute um eins herabsetzen bis entweder eine Stunde verstrichen
- ist oder der NPC nicht mehr existiert zum Beispiel weil er getoetet
- wurde.
-
- player->SetTimedAttrModifier( player->query_real_name(),
- ([A_STR:-1,A_INT:-1,A_DEX:-1,A_CON:-1]),
- time()+3600,
- this_object(),
- this_object()
- );
-
- Will der NPC nun noch darauf reagieren, dass die Attributmodifikation
- durch Timeout abgelaufen ist, so koennte dies folgendermassen geschehen.
-
- void NotifyTimedAttrModExpired(string str)
- {
- // Die Funktion wird aus dem Lebewesen gerufen, in welchem der Mod
- // gerade abgelaufen ist. Also Meldungsausgabe an
- // previous_object().
- tell_object(previous_object()
- ,"Da hast Du aber nochmal Glueck gehabt.\n");
- }
-
-
-RUeCKGABEWERT
-=============
-
- TATTR_INVALID_ARGS - Im Falle eines fehlenden key-Arguments,
- eines fehlenden modifier-Arguments oder
- eines bereits abgelaufenen
- outdatet-Arguments
- TATTR_OK - Im Erfolgsfall
-
- Die Rueckgabewerte sind in /sys/living/attributes.h definiert.
-
-
-SIEHE AUCH
-==========
-
- Attribute: QueryAttribute(), SetAttribute()
- SetRealAttribute(), QueryRealAttribute(),
- QueryAttributeOffset(),
- UpdateAttributes()
- Methoden: QueryTimedAttrModifier(), DeleteTimedAttrModifier()
- Callback: NotifyTimedAttrModExpired()
- Properties: P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS
- P_X_ATTR_MOD, P_M_ATTR_MOD
- P_TIMED_ATTR_MOD
- Sonstiges: /std/living/attributes.c
-
-LETZTE Aenderung: 15.02.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/ShowDoors b/doc/sphinx/man/lfun/ShowDoors
deleted file mode 100644
index c315632..0000000
--- a/doc/sphinx/man/lfun/ShowDoors
+++ /dev/null
@@ -1,46 +0,0 @@
-
-ShowDoors()
-***********
-
-
-FUNKTION
-========
-
- void ShowDoors()
-
-
-ARGUMENTE
-=========
-
- Keine.
-
-
-BESCHREIBUNG
-============
-
- Zeigt alle Sehertor an, die der Seher (this_player()) schon kennt.
- Falls in seiner Umgebung ein Tor steht, so wird dieses eingeklammert.
-
-
-RUECKGABEWERT
-=============
-
- Keiner.
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
-
-
-BEISPIELE
-=========
-
- /d/seher/portale/sehertormaster->ShowDoors()
-
-
-SIEHE AUCH
-==========
-
- DiscoverDoor, DoorIsKnown, Teleport, GetDoorsMapping
diff --git a/doc/sphinx/man/lfun/ShowPropList b/doc/sphinx/man/lfun/ShowPropList
deleted file mode 100644
index 41599d7..0000000
--- a/doc/sphinx/man/lfun/ShowPropList
+++ /dev/null
@@ -1,74 +0,0 @@
-
-ShowPropList()
-**************
-
-
-FUNKTION
-========
-
- void ShowPropList(string *props);
-
-
-DEFINIERT IN
-============
-
- /std/thing/util.c
-
-
-ARGUMENTE
-=========
-
- props
- Array von Strings mit den Namen der Properties, die ausgegeben
- werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Gibt die Inhalte der in props angegebenen Properties aus.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- Sei test.c folgendes Programm:
-
- inherit "std/thing";
- inherit "std/thing/util";
-
- create() {
- ::create();
-
- SetProp(P_SHORT, "Kurz");
- SetProp(P_NAME, ({ "Name", "Namens", "Namen", "Namen" }));
- SetProp("me", this_object() );
- }
-
- Mit xcall test->ShowPropList( ({ P_SHORT, P_NAME, "me" }) ); erhielte
- man dann folgende Ausgabe:
-
- *short: "Kurz"
- *name: ({ "Name", "Namens", "Namen", "Namen" })
- *me: OBJ(/players/wargon/test#12345)
-
-
-BEMERKUNGEN
-===========
-
- Mit dem Befehl xprops des MGtools lassen sich uebrigens saemtliche
- Properties eines Objekte auf einen Schlag ausgeben.
-
-
-SIEHE AUCH
-==========
-
- /std/ting/util.c
-
-Last modified: Wed May 8 10:25:26 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/SkillResTransfer b/doc/sphinx/man/lfun/SkillResTransfer
deleted file mode 100644
index 128cea7..0000000
--- a/doc/sphinx/man/lfun/SkillResTransfer
+++ /dev/null
@@ -1,48 +0,0 @@
-
-SkillResTransfer()
-******************
-
-
-FUNKTION
-========
-
- protected void SkillResTransfer(mapping from_M, mapping to_M)
-
-
-DEFINIERT IN
-============
-
- /std/living/skill_utils
-
-
-ARGUMENTE
-=========
-
- mapping from_M: Mapping mit zu kopierenden Werten
- mapping to_M: Zielmapping
-
-
-BESCHREIBUNG
-============
-
- Interne Methode, die zB (!) waehrend der Ausfuehrung von Attack() durch
- Skills oder P_TMP_ATTACK_MOD geaenderte Werte selektiert in das
- Hauptangriffsmapping uebertraegt.
-
- Derzeit werden folgende Werte kopiert:
- SI_SKILLDAMAGE, SI_SKILLDAMAGE_MSG, SI_SKILLDAMAGE_MSG2,
- SI_SKILLDAMAGE_TYPE, SI_SPELL
-
-
-BEMERKUNGEN
-===========
-
- * wird an mehreren Stellen, nicht nur der living/combat verwendet
-
-
-SIEHE AUCH
-==========
-
- P_TMP_ATTACK_MOD, UseSkill (Waffenfaehigkeiten)
-
-18.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/lfun/SpellAttack b/doc/sphinx/man/lfun/SpellAttack
deleted file mode 100644
index ba00347..0000000
--- a/doc/sphinx/man/lfun/SpellAttack
+++ /dev/null
@@ -1,97 +0,0 @@
-
-SpellAttack()
-*************
-
-
-FUNKTION
-========
-
- void SpellAttack(object enemy)
-
-
-ARGUMENTE
-=========
-
- enemy: Der Feind.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird in jedem Heartbeat eines NPCs ausgefuehrt,
- falls nicht P_DISABLE_ATTACK gesetzt ist (Paralyse).
- Standardmaessig tut diese Funktion nichts, aber man kann sie
- ueberschreiben, damit in jedem Heartbeat Angriffe mit Spells
- ausgefuehrt werden.
-
- Man sollte hierbei ein random() einbauen, damit der NPC nicht
- in jedem Heartbeat auch wirklich einen Angriff ausfuehrt.
- Ausserdem sollte man auch fuer eventuelle Ausgaben sorgen.
-
-
-RUECKGABEWERT
-=============
-
- Keiner.
-
-
-BEMERKUNG
-=========
-
- Die AttackChats, die mittels SetAttackChats gesetzt werden
- koennen, macht im Grunde nichts anderes, aber Chats sind halt
- keine Angriffe. :-)
-
-
-BEISPIELE
-=========
-
- Im Grunde ist dieses simple Beispiel eine Nachbildung von
- Attack-Chats und soll dementsprechend nur der Anschauung dienen.
-
- void SpellAttack(object enemy)
- {
- // mit 80% Wahrscheinlichkeit wird nichts gemacht.
- switch(random(5))
- {
- case 0:
- write("Der Ork tritt Dir in den Hintern.\n");
- return;
- case 1:
- write("Der Ork bruellt: Lebend kommst Du hier nicht raus!\n");
- return;
- case 2:
- write("Der Ork blutet schon aus mehreren Wunden.\n");
- return;
- case 3:
- write(knirsch(enemy));
- return;
- default:
- return;
- }
- }
-
- string knirsch(object enemy)
- {
- if (objectp(enemy))
- helm = enemy->QueryArmourByType(AT_HELMET);
- if (objectp(helm))
- {
- helm->Damage(1);
- return "Der Ork beschaedigt Deinen Helm!\n";
- }
- else
- return ""; // keine Meldung
- }
-
-
-SIEHE AUCH
-==========
-
- "Attack", "SetAttackChats", /std/npc/combat.c
-
-
-LETZTE AENDERUNG
-================
-
- Don, 27.02.2003, 12:50:00 von Hirudo
diff --git a/doc/sphinx/man/lfun/SpellDefend b/doc/sphinx/man/lfun/SpellDefend
deleted file mode 100644
index 22b038c..0000000
--- a/doc/sphinx/man/lfun/SpellDefend
+++ /dev/null
@@ -1,71 +0,0 @@
-
-SpellDefend()
-*************
-
-
-FUNKTION
-========
-
- public int SpellDefend(object caster,mapping sinfo);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- object caster - Gegner
- mapping sinfo - Zusatzinformationen zum Spell
-
-
-BESCHREIBUNG
-============
-
- Ueber den Skill SK_SPELL_DEFEND mit den Aufrufparametern
- SI_ENEMY : <caster>
- und
- SI_SKILLARG : <sinfo>
- wird eine Abwehrchance in 0.01%-Schritten fuer einen
- Spell ermittelt, also 0% - 100% bzw. als Rueckgabewert
- 0 - 10000.
-
-
-
- Weiterhin wird automatisch P_MAGIC_RESISTANCE_OFFSET und der Skill
- SK_SPELL_DEFEND beruecksichtigt.
-
-
-RUeCKGABEWERT
-=============
-
- Die Abwehrchance in 0.01%-Schritten.
-
-
-
- Fuer Spieler wird dieser Rueckgabewert auf 3333 maximal, also 33,33%
- Abwehrmoeglichkeit beschraenkt.
-
-
-BEMERKUNGEN
-===========
-
- Die Spellbooks muessen selbst auf die Auswertung dieser Funktion
- achten! Dies geschieht nur im Falle von TryGlobalAttackSpell()
- und bei Spells fuer NPCs mittels P_SPELLS automatisch!
-
- Bitte bei NPCs nicht pauschal 100% / 10000 zurueckgeben. Danke.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: P_MAGIC_RESISTANCE_OFFSET
- Aehnlich: P_NOMAGIC
- Generell: TryGlobalAttackSpell, /std/spellbook.c
- Sonstiges: UseSkill, SK_SPELL_DEFEND
-
-29.Dez 2007 Gloinson
diff --git a/doc/sphinx/man/lfun/SpellInform b/doc/sphinx/man/lfun/SpellInform
deleted file mode 100644
index ce8fdbd..0000000
--- a/doc/sphinx/man/lfun/SpellInform
+++ /dev/null
@@ -1,51 +0,0 @@
-
-SpellInform()
-*************
-
-
-FUNKTION
-========
-
- void SpellInform(caster,spell,sinfo);
-
-
-DEFINIERT IN
-============
-
- selber zu definieren
-
-
-ARGUMENTE
-=========
-
- pl
- Das Lebewesen, das erfolgreich gezaubert hat.
- spell
- Der Name des gezauberten Spells
- sinfo
- Das komplette Spellmapping des gezauberten Spells
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird vom Spellbuch einer Gilde in der Umgebung
- (Environment) eines Lebewesens aufgerufen, wenn immer das Lebewesen
- einen Spell _erfolgreich_ gezaubert hat.
- Bemerkung: Bitte vermeiden, aufwaendige Sachen in der Funktion zu
- machen, da sonst u.U. deswegen Gilden anfangen zu buggen. Falls es
- sein muss, macht dann lieber einen call_out mit 2s Wartezeit.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- ----------------------------------------------------------------------------
-
-16.04.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/Start b/doc/sphinx/man/lfun/Start
deleted file mode 100644
index e0b1070..0000000
--- a/doc/sphinx/man/lfun/Start
+++ /dev/null
@@ -1,44 +0,0 @@
-
-Start()
-*******
-
-
-FUNKTION
-========
-
- varargs void Start(int pos);
-
-
-DEFINIERT IN
-============
-
- /std/transport.c
-
-
-ARGUMENTE
-=========
-
- pos
- Fahrplanstation, an der begonnen werden soll.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion schickt den Transporter auf die Strecke. Dabei beginnt
- der Weg an der mit pos bezeichneten Stelle im Fahrplan. Default ist 0,
- d.h. der Transporter beginnt seinen Weg an der ersten Fahrplanposition.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- Halt(), /std/transport.c
-
-Last modified: Wed May 8 10:25:30 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/StopHuntFor b/doc/sphinx/man/lfun/StopHuntFor
deleted file mode 100644
index e09d9fa..0000000
--- a/doc/sphinx/man/lfun/StopHuntFor
+++ /dev/null
@@ -1,77 +0,0 @@
-
-StopHuntFor()
-*************
-
-
-FUNKTION
-========
-
- varargs int StopHuntFor(object arg,int silent);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- arg
- Der Gegner, welcher nicht mehr bekaempft werden soll.
- silent
- Flag, welches gesetzt anzeigt, dass die beiden Ex-Streithaehne
- ueber das einseitige Friedensangebot nicht informiert werden
- sollen.
-
-
-RUeCKGABEWERT
-=============
-
- Flag: Bei 0 war der Gegner nicht auffindbar, bei 1 Erfolg.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann man ein Lebewesen <arg> als Gegner
- austragen. Im Normalfall erhalten sowohl das aktuelle Objekt, als
- auch der Gegner eine Information darueber. Dies kann jedoch mit dem
- gesetzten Flag <silent> unterbunden werden.
- Es ist auch moeglich, auf diese Meldung Einfluss zu nehmen, indem
- man die Funktion StopHuntText() ueberschreibt, welche dafuer
- verantwortlich ist.
- Achtung: Um zwischen beiden Streithaehnen Frieden zu schliessen,
- muss der eine Gegner jeweils bei dem anderen ausgetragen werden. Ein
- einzelnes StopHuntFor() ist sozusagen nur ein einseitiges
- Friedensangebot.
-
-
-BEMERKUNGEN
-===========
-
- Soll ein Viech unter bestimmten Umstaenden nicht angreifbar sein, ist in
- keinem Fall StopHuntFor() im Defend() zu verwenden, sondern P_NO_ATTACK.
- Grund: Stoppt man unliebsame Kaempfe jeweils am Anfang vom Defend, kann ein
- Gegner gefahrlos Angriffsspells ausfuehren (und ueben), ohne dass die Gefahr
- besteht, dass der NPC zurueckschlaegt.
-
-
-BEISPIELE
-=========
-
- Man will aus irgendeinem Grund den Kampf zwischen sich und Gegner enemy
- einstellen:
- ...
- StopHuntFor(enemy); // enemy nicht mehr bekaempfen
- enemy->StopHuntFor(this_object()); // enemy soll mich nicht bekaempfen.
- ...
-
-
-SIEHE AUCH
-==========
-
- StopHuntText(), SelectEnemy(), QueryEnemies(), IsEnemy()
-
-16.03.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/StopHuntText b/doc/sphinx/man/lfun/StopHuntText
deleted file mode 100644
index fca271b..0000000
--- a/doc/sphinx/man/lfun/StopHuntText
+++ /dev/null
@@ -1,77 +0,0 @@
-
-StopHuntText()
-**************
-
-
-FUNKTION
-========
-
- void StopHuntText(object arg);
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- arg
- Der Gegner, welcher nicht mehr bekaempft wird.
-
-
-BESCHREIBUNG
-============
-
- Mit der Funktion StopHuntFor() kann man ein Lebewesen als Gegner
- austragen. Dabei erhalten sowohl der Gegner, als auch das Lebewesen,
- welches (einseitig!) Frieden schliesst, jeweils eine Meldung, sofern
- man dies nicht mittels eines Flags unterbindet.
- Es ist nun moeglich, auf diese Meldung Einfluss zu nehmen, indem
- man die Funktion StopHuntText() ueberschreibt, welche dafuer
- verantwortlich ist.
-
-
-BEISPIEL
-========
-
- Ein Lebewesen moechte einen Kampf sofort abbrechen, wenn es von
- einem Frosch angegriffen wird:
- int Defend(int dam,mixed dam_type,mixed spell,object enemy)
- { if(enemy&&enemy->QueryProp(P_FROG))
- { if(StopHuntFor(enemy))
- { // wenn Frosch angreifen will, der noch kein Gegner war
- tell_object(arg,
- this_object()->Name(WER)+" kaempft nicht mit Dir.\n"
- +"Wahrscheinlich werden Froesche verschont.\n");
- tell_object(this_object(),
- "Der bloede Frosch wollte Dich doch tatsaechlich angreifen.\n");
- }
- enemy->StopHuntFor(this_object(),1);
- return 0;
- }
- return::Defend(dam,dam_type,spell,enemy);
- }
- // wird nur aufgerufen, wenn der Gegner irgendwann Frosch wurde
- void StopHuntText(object arg)
- { tell_object(arg,
- this_object()->Name(WER)+" jagd Dich nicht mehr.\n"
- +"Wahrscheinlich werden Froesche verschont.\n");
- tell_object(this_object(),
- "Dein Gegner ist doch tatsaechlich ploetzlich Frosch geworden!\n");
- }
- Warum braucht man nun das erste StopHuntFor(), wenn doch Gegner erst
- in ::Defend() eingetragen werden, welches doch gar nicht ausgefuehrt
- wird, wenn der Gegner ein Frosch ist? Man beachte hierbei, dass der
- Gegner ja auch waehrend des Kampfes oder waehrend der Feindschaft
- irgendwann Frosch werden koennte und dann schon Gegner war.
-
-
-SIEHE AUCH
-==========
-
- StopHuntFor(), SelectEnemy(), QueryEnemies(), IsEnemy()
-
-Last modified: Wed May 26 16:47:51 1999 by Patryn
diff --git a/doc/sphinx/man/lfun/SuggestArticle b/doc/sphinx/man/lfun/SuggestArticle
deleted file mode 100644
index 31c2047..0000000
--- a/doc/sphinx/man/lfun/SuggestArticle
+++ /dev/null
@@ -1,57 +0,0 @@
-
-SuggestArticle()
-****************
-
-
-FUNKTION
-========
-
- varargs int SuggestArticle(string name);
-
-
-DEFINIERT IN
-============
-
- /std/thing/language.c
-
-
-ARGUMENTE
-=========
-
- name
- Der Name zur Entscheidungshilfe.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion versucht herauszufinden, ob der Artikel zu diesem Objekt
- ein unbestimmter oder besser ein bestimmter Artikel sein sollte. Die
- Vorgehensweise ist folgende: Gibt es in der Umgebung dieses Objektes
- ein weiteres Objekt, das den Namen name besitzt, so wird ein
- unbestimmter Artikel vorgeschlagen, ansonsten ein bestimmter.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn ein unbestimmter Artikel geeignet ist, ansonsten 1.
-
-
-BEMERKUNGEN
-===========
-
- Der Vergleich erfolgt mittels der Property P_NAME. Um Erfolg zu haben,
- sollte man diese Funktion daher in der Form
-
- SuggestArticle(QueryProp(P_NAME))
-
- aufrufen.
-
-
-SIEHE AUCH
-==========
-
- QueryArticle(), name(), /std/thing/language.c
-
-Last modified: Wed May 8 10:25:34 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/SwapRows b/doc/sphinx/man/lfun/SwapRows
deleted file mode 100644
index aa18364..0000000
--- a/doc/sphinx/man/lfun/SwapRows
+++ /dev/null
@@ -1,60 +0,0 @@
-
-SwapRows()
-**********
-
-
-FUNKTION
-========
-
- int SwapRows( object ob1, object ob2 )
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- ob1, ob2 - Spieler, die die Reihen tauschen sollen.
-
-
-BESCHREIBUNG
-============
-
- Die angegebenen Spieler tauschen die Reihen.
-
-
-RUECKGABEWERT
-=============
-
- 1 bei erfolgreichem Tausch, 0 sonst.
-
-
-BEMERKUNG
-=========
-
- Der Tausch wird nur durchgefuehrt, wenn die angegebenen Spieler auch
- tatsaechlich im Team sind und damit kein NPC vor einen Spieler gestellt
- wuerde.
- Moechte man wissen, ob ein Spieler eine Reihe gewechselt hat, muss man
- sich der Hilfe eines Hooks bedienen: H_HOOK_TEAMROWCHANGE
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_TEAM_LEADER, P_TEAM_ASSOC_MEMBERS,
- P_TEAM_NEWMEMBER
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/TakeFlaw b/doc/sphinx/man/lfun/TakeFlaw
deleted file mode 100644
index 40d99a2..0000000
--- a/doc/sphinx/man/lfun/TakeFlaw
+++ /dev/null
@@ -1,100 +0,0 @@
-
-TakeFlaw()
-**********
-
-
-FUNKTION
-========
-
- varargs void TakeFlaw(object enemy); (Waffen)
- varargs void TakeFlaw(mixed dam_types,mapping einfos) (Ruestungen)
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c,
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird in Waffen und Ruestungen waehrend des Kampfes
- aufgerufen. In einer Waffe erfolgt der Aufruf bei jedem Schlag mit
- dieser Waffe, bei Ruestungen wird TakeFlaw() in einer zufaellig
- ausgewaehlten getragenen Ruestung aufgerufen.
- Waffen bekommen das Gegnerobjekt uebergeben, Ruestungen die erweiterten
- DefendInfos (s. dort fuer Details). Aufgrund dieser Informationen kann
- man den Schaden, den ein Gegenstand nimmt, flexibler gestalten (z.B. bei
- einer Waffe in Abhaengigkeit von P_BODY des Gegners.)
-
- Soweit man die Funktion nicht ueberlaedt, bewirkt sie nichts weiter als
- das Erhoehen eines Zaehlers, der mit QueryFlaw() abgefragt werden kann.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Die Waffen-/ Ruestungsklasse wird nicht automatisch reduziert! Wenn
- eine Waffe oder Ruestung sich abnutzen soll, muss man TakeFlaw()
- ueberladen und dort entsprechend handeln, oder (fuer einfache
- Faelle) die Property P_QUALITY setzen.
-
-
-BEISPIELE
-=========
-
- Eine Waffe, deren Waffenklasse alle 20 Schlaege um 1 abnimmt:
-
- inherit "std/weapon";
-
- #include <properties.h>
- #include <combat.h>
-
- create()
- {
- /* Das Uebliche... */
- }
-
- TakeFlaw()
- {
- int flaw;
-
- /* erst mal den Zaehler erhoehen... */
- ::TakeFlaw();
-
- /* jetzt den aktuellen Zaehlerstand abfragen */
- flaw = QueryFlaw()[0];
-
- /* Abzug nur jeden 20. Schlag */
- if (!(flaw % 20)) {
- /* So, jetzt fuer den Schaden sorgen. Hierfuer benutzt */
- /* man am sichersten die eingebaute Funktion Damage() */
- Damage(1);
- }
- }
-
- Dieses einfache Beispiel haette natuerlich auch ueber ein
- SetProp(P_QUALITY,20); im create() realisiert werden koennen.
-
-
-SIEHE AUCH
-==========
-
- QueryFlaw(), Damage(), DefendInfo, P_QUIALITY, /std/armour/combat.c,
- /std/weapon/combat.c
-
-Last modified: Thu May 22 10:30:10 1997 by Paracelsus
diff --git a/doc/sphinx/man/lfun/TeamFlee b/doc/sphinx/man/lfun/TeamFlee
deleted file mode 100644
index 216fbbf..0000000
--- a/doc/sphinx/man/lfun/TeamFlee
+++ /dev/null
@@ -1,60 +0,0 @@
-
-TeamFlee()
-**********
-
-
-FUNKTION
-========
-
- int TeamFlee()
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Spieler wird zur Flucht in hintere Reihe veranlasst, falls er dies
- eingestellt hat.
-
-
-RUECKGABEWERT
-=============
-
- 1, falls der Spieler in eine hintere Reihe fliehen wollte und nach
- dem Versuch nicht mehr in der ersten Reihe steht, sonst 0.
-
-
-BEMERKUNGEN
-===========
-
- Beim Teamleiter fuehrt der Fluchtversuch dazu, dass sein Team nicht
- mehr folgt.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/TeamMembers b/doc/sphinx/man/lfun/TeamMembers
deleted file mode 100644
index 5971bfb..0000000
--- a/doc/sphinx/man/lfun/TeamMembers
+++ /dev/null
@@ -1,58 +0,0 @@
-
-TeamMembers()
-*************
-
-
-FUNKTION
-========
-
- object *TeamMembers()
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Liefert Teammitglieder des Teams des Spielers.
-
-
-RUECKGABEWERT
-=============
-
- Array mit ALLEN Teammitgliedern.
-
-
-BEMERKUNGEN
-===========
-
- Falls der Spieler in keinem Team ist, enthaelt das Array nur den
- Spieler.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/TeamPrefix b/doc/sphinx/man/lfun/TeamPrefix
deleted file mode 100644
index 2cf1582..0000000
--- a/doc/sphinx/man/lfun/TeamPrefix
+++ /dev/null
@@ -1,56 +0,0 @@
-
-TeamPrefix()
-************
-
-
-FUNKTION
-========
-
- string TeamPrefix()
-
-
-DEFINIERT IN
-============
-
- /std/living/team.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Ergibt Team-Prefix eines Spielers.
-
-
-RUECKGABEWERT
-=============
-
- "[Team Teamname] ", falls der Spieler in einem Team ist,
- "" sonst.
-
-
-BEMERKUNGEN
-===========
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_NEWMEMBER, P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: AssocMember, DeAssocMember, InsertEnemyTeam,
- SelectNearEnemy, SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/lfun/Teleport b/doc/sphinx/man/lfun/Teleport
deleted file mode 100644
index ddddb89..0000000
--- a/doc/sphinx/man/lfun/Teleport
+++ /dev/null
@@ -1,51 +0,0 @@
-
-Teleport()
-**********
-
-
-FUNKTION
-========
-
- int Teleport(string ziel)
-
-
-ARGUMENTE
-=========
-
- ziel: Nummer des Sehertors, zu dem teleportiert werden soll.
-
-
-BESCHREIBUNG
-============
-
- Teleportiert den Seher (this_player()) zu dem Tor mit der angegebenen
- Nummer. Falls keine Nummer angegeben wird, wird mit ShowDoors() die
- Liste der bekannten Tore angezeigt und auf die Eingabe einer Nummer
- gewartet.
-
-
-RUECKGABEWERT
-=============
-
- 0, falls der Seher nicht neben einem Tor steht, dass er kennt.
- 1 sonst.
-
-
-BEMERKUNGEN
-===========
-
- Der Seher muss in einem Raum stehen, in dem sich ein Sehertor befindet,
- dass er kennt. Der Seher muss auch das angegebene Ziel kennen.
- Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
-
-
-BEISPIELE
-=========
-
- /d/seher/portale/sehertormaster->Teleport(1)
-
-
-SIEHE AUCH
-==========
-
- DiscoverDoor, DoorIsKnown, ShowDoors, GetDoorsMapping
diff --git a/doc/sphinx/man/lfun/TestIgnore b/doc/sphinx/man/lfun/TestIgnore
deleted file mode 100644
index d1d2b95..0000000
--- a/doc/sphinx/man/lfun/TestIgnore
+++ /dev/null
@@ -1,88 +0,0 @@
-
-TestIgnore()
-************
-
-
-FUNKTION
-========
-
- public int TestIgnore(string|string* arg)
-
-
-DEFINIERT IN
-============
-
- /std/player/comm.c
-
-
-ARGUMENTE
-=========
-
- arg
- String oder Array von Strings, die getestet werden sollen,
- Format jeweils: [spieler].aktion[.qualifizierer]
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn arg nicht ignoriert wird
- MSG_IGNORED, wenn (min. ein Element von) arg ignoriert wird
-
-
-BESCHREIBUNG
-============
-
- Es wird geprueft, ob der Spieler irgendeinen Eintrag auf seiner Liste
- hat, der dazu fuehrt, dass <arg> ignoriert wird. Hierbei kommen je nach
- den Angaben in <arg> folgende Regeln zum Tragen:
- 1) spieler
- Wird der Spieler ignoriert?
- 2) .aktion
- Ignoriert der Spieler .aktion, d.h. die Aktion komplett (OHNE
- Qualifizierer)?
- 3) spieler.aktion
- Ignoriert der Spieler spieler, .aktion oder spieler.aktion?
- 4) spieler.aktion.qualifizierer
- Ignoriert der Spieler spieler, .aktion, spieler.aktion oder
- spieler.aktion.qualifizierer?
- 5) .aktion.qualifizierer
- Ignoriert der Spieler .aktion oder .aktion.qualifizierer?
-
- Da TestIgnore() damit durchaus etwas aufwendiger sein kann, sollte
- man dies nicht unnoetig oft aufrufen. (Braucht man das Ergebnis z.B.
- kurz spaeter nochmal, koennte man das Ergebnis speichern.) Wird der
- Qualifizierer nicht gebraucht, sollte man ihn weglassen.
-
-
-BEISPIEL
-========
-
- if (!this_player()->TestIgnore("andy"))
- tell_object(this_player(), "Andy teilt Dir mit: Hallo!\n");
-
- // Beispiel fuer eine Ignore-Check fuer Aktion (kratzen) fuer einen
- // Spieler (this_player()) an einem anderen Spieler (target)
- if (!target->TestIgnore( ({getuid(this_player()) + ".kratze",
- getuid(this_player()) + ".kratz"}) ))
- {
- tell_object(target, this_player()->Name()+" kratzt dich.\n");
- tell_object(this_player(), "Du kratzt "+target->Name()+".\n");
- }
- else
- tell_object(this_player(), target->Name()+" ignoriert dich.\n");
-
- // allumfassender Ignorier-Check in einer Gilde (Klerus) auf
- // eine Aktion (kurieren) fuer einen bestimmten Spieler (den caster)
- // an einem zu kurierenden Spieler (target)
- if (target->TestIgnore(getuid(caster)+".kuriere.klerus"))
- tell_object(caster, break_string(
- target->Name()+" ignoriert deinen Versuch.", 78));
-
-
-SIEHE AUCH
-==========
-
- P_IGNORE, AddIgnore, RemoveIgnore, TestIgnoreSimple, /std/player/comm.c
-
-26.04.2014 Zesstra
diff --git a/doc/sphinx/man/lfun/TestIgnoreSimple b/doc/sphinx/man/lfun/TestIgnoreSimple
deleted file mode 100644
index c0ec76e..0000000
--- a/doc/sphinx/man/lfun/TestIgnoreSimple
+++ /dev/null
@@ -1,77 +0,0 @@
-
-TestIgnoreSimple()
-******************
-
-
-FUNKTION
-========
-
- public int TestIgnoreSimple(string *arg)
-
-
-DEFINIERT IN
-============
-
- /std/player/comm.c
-
-
-ARGUMENTE
-=========
-
- arg
- Liste von Strings, die getestet werden sollen
-
-
-BESCHREIBUNG
-============
-
- TestIgnoreSimple() prueft, ob der Spieler min. einen der uebergebenen
- Eintraege auf seiner Ignoriereliste hat.
- Falls man mehrere Eintraege pruefen muss/moechte, ist es schneller, alle
- Eintraege in einem zu uebergeben anstatt fuer jeden einzeln
- TestIgnoreSimple() aufzurufen.
-
-
-RUeCKGABEWERT
-=============
-
- 1, falls es mindestens eine Uebereinstimmungen von arg und der
- Ignoriere-Liste des Spielers gibt.
- 0, sonst.
-
-
-BEISPIEL
-========
-
- if (!this_player()->TestIgnoreSimple(({"andy"})))
- tell_object(this_player(), "Andy teilt Dir mit: Hallo!\n");
-
- // Beispiel fuer eine Ignore-Check fuer Aktion (kratzen) fuer einen
- // Spieler (this_player()) an einem anderen Spieler (target)
- if (!target->TestIgnoreSimple(getuid(this_player()),
- getuid(this_player())+".kratz",
- getuid(this_player())+".kratze",
- ".kratz", ".kratze"}))) {
- tell_object(target, this_player()->Name()+" kratzt dich.\n");
- tell_object(this_player(), "Du kratzt "+target->Name()+".\n");
- } else
- tell_object(this_player(), target->Name()+" ignoriert dich.\n");
-
- // allumfassender Ignorier-Check in einer Gilde (Klerus) auf
- // eine Aktion (kurieren) fuer einen bestimmten Spieler (den caster)
- // an einem zu kurierenden Spieler (target)
- if (target->TestIgnoreSimple(({getuid(caster),
- getuid(caster)+".kuriere",
- getuid(caster)+".kuriere.klerus",
- ".kuriere",
- ".kuriere.klerus"})))
- tell_object(caster, break_string(
- target->Name()+" ignoriert deinen Versuch.", 78));
-
-
-SIEHE AUCH
-==========
-
- P_IGNORE, AddIgnore, RemoveIgnore, TestIgnore, /std/player/comm.c
-
-26.04.2014 Zesstra
diff --git a/doc/sphinx/man/lfun/TestLimitViolation b/doc/sphinx/man/lfun/TestLimitViolation
deleted file mode 100644
index df9f7b2..0000000
--- a/doc/sphinx/man/lfun/TestLimitViolation
+++ /dev/null
@@ -1,39 +0,0 @@
-
-TestLimitViolation()
-********************
-
-
-FUNKTION
-========
-
- status TestLimitViolation(mapping check)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-PARAMETER
-=========
-
- check - Mapping mit Attributen: ([<attr>:<wert>])
-
-
-BESCHREIBUNG
-============
-
- Prueft, ob die Summe der in check enthaltenen Modifikatoren die Summe
- aller Modifikatoren im Spieler ueber den zugelassenen Grenzwert hebt.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-13.Jun.2004, Muadib
diff --git a/doc/sphinx/man/lfun/TriggerEvent b/doc/sphinx/man/lfun/TriggerEvent
deleted file mode 100644
index 44dd2e4..0000000
--- a/doc/sphinx/man/lfun/TriggerEvent
+++ /dev/null
@@ -1,87 +0,0 @@
-
-TriggerEvent()
-**************
-
-
-FUNKTION
-========
-
- varargs int TriggerEvent(string eid, mixed data);
-
-
-DEFINIERT IN
-============
-
- /p/daemon/eventd.c
-
-
-DEKLARIERT IN
-=============
-
- /sys/events.h
-
-
-ARGUMENTE
-=========
-
- string eid,
- Die ID des Events, der ausgeloest werden soll.
- Da dieser String fuer alle Events jeweils eindeutig sein muss,
- empfiehlt es sich, fuer eigene Events z.B. als Praefix den eigenen
- Magiernamen zu nehmen, z.B. "zesstra_vulkanausbruch".
- ACHTUNG: IDs, die mit 'evt_lib_' beginnen, sind AUSSCHLIESSLICH der
- Mudlib vorbehalten!
-
- mixed data,
- Daten, die jeder Lauscher uebergeben bekommt. Kann ein beliebiger
- Datentyp sein. Ggf. ein Mapping oder Array benutzen.
-
-
-BESCHREIBUNG
-============
-
- Der Event mit der ID 'eid' wird ausgeloest. Mit kurzer Verzoegerung
- (meist 0-2s) werden alle fuer 'eid' registrierten Lauscher durch Aufruf
- einer Funktion in ihnen informiert:
- listener->fun(eid, triggerob, data);
- 'triggerob' ist hierbei das Objekt, welche TriggerEvent() gerufen hat,
- 'data' das, was das triggernde Objekte als Daten weiterverteilen moechte.
- Die einzelnen fun() in den lauschenden Objekten muessen wissen, was sie
- mit 'data' anfangen sollen. ;-)
-
-
-RUeCKGABEWERT
-=============
-
- 1 fuer Erfolg, <=0 fuer Misserfolg.
- 1 - Erfolg, Event 'eid' wurde ausgeloest.
- -1 - falsche Argumente wurden uebergeben
- -2 - nicht-oeffentlicher Event und das triggernde Objekt wurde nicht
- fuer diesen Event freigegeben (momentan gibt es noch keine
- nicht-oeffentlichen Events)
- -3 - Event 'eid' existiert nicht, d.h. es gibt keine Lauscher.
- -4 - Es gibt zuviele nicht verarbeitete Events.
-
-
-BEMERKUNGEN
-===========
-
-
-BEISPIELE
-=========
-
- 1. Ein Waechter wird angegriffen:
- EVENTD->TriggerEvent("xand_holzfaellerlager_angriff",
- (["angreifer": enemy,
- "ort": environment(this_object()) ]) );
- Alle anderen angemeldeten Waechter der Lagers werden nun informiert
- und koennen ihrerseits reagieren (dem ersten Waechter zuhilfe kommen
- oder auch die Lagertore schliessen).
-
-
-SIEHE AUCH
-==========
-
- events, eventd, UnregisterEvent(), RegisterEvent()
-
-Last modified: 15.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/UnregisterEvent b/doc/sphinx/man/lfun/UnregisterEvent
deleted file mode 100644
index 6d9bfb7..0000000
--- a/doc/sphinx/man/lfun/UnregisterEvent
+++ /dev/null
@@ -1,79 +0,0 @@
-
-UnregisterEvent()
-*****************
-
-
-FUNKTION
-========
-
- int UnregisterEvent(string eid, object listener);
-
-
-DEFINIERT IN
-============
-
- /p/daemon/eventd.c
-
-
-DEKLARIERT IN
-=============
-
- /sys/events.h
-
-
-ARGUMENTE
-=========
-
- string eid,
- Die ID des Events, vom dem man sich abmelden will.
- object listener,
- Das Objekt, das als Lauscher ausgetragen werden soll.
-
-
-BESCHREIBUNG
-============
-
- Das Objekt 'listener' wird als Lauscher dieses Events ausgetragen. Ab
- diesem Moment wird es bei Events vom Typ 'eid' nicht mehr informiert.
-
- Hat der Event 'eid' im Anschluss keine Lauscher mehr, wird er implizit
- geloescht.
-
-
-RUeCKGABEWERT
-=============
-
- 1 fuer Erfolg, <=0 fuer Misserfolg.
- 1 - Erfolg, 'listener' wurde eingetragen.
- -1 - falsche Argumente uebergeben
- -2 - 'listener' ist nicht fuer 'eid' registriert.
-
-
-BEMERKUNGEN
-===========
-
- Wenn sich ein Objekt vor Zerstoerung nicht abmeldet, wird es ggf. beim
- naechsten Auftreten von 'eid' automatisch ausgetragen.
- Falls Blueprints nach Neuladen nicht automatisch angemeldet sein sollen,
- sollten sie sich im remove() explizit abmelden.
-
-
-BEISPIELE
-=========
-
- 1. Ein Objekt moechte nicht mehr ueber Spielertode informiert werden:
- EVENTD->UnregisterEvent(EVT_LIB_PLAYER_DEATH, this_object());
-
- 2. Ein Objekt moechte sich bei Zerstoerung abmelden:
- varargs int remove(int silent) {
- ...
- EVENTD->UnregisterEvent("zesstra_vulkanausbruch",this_object());
- }
-
-
-SIEHE AUCH
-==========
-
- events, eventd, UnregisterEvent(), RegisterEvent()
-
-Last modified: 15.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/UnregisterHelperNPC b/doc/sphinx/man/lfun/UnregisterHelperNPC
deleted file mode 100644
index 79c18f6..0000000
--- a/doc/sphinx/man/lfun/UnregisterHelperNPC
+++ /dev/null
@@ -1,72 +0,0 @@
-
-UnregisterHelperNPC()
-*********************
-
-
-FUNKTION
-========
-
- public int UnregisterHelperNPC(object npc);
-
-
-DEFINIERT IN
-============
-
- /std/player/combat.c
-
-
-ARGUMENTE
-=========
-
- object npc
- Objekt des helfenden NPC, der abgemeldet werden soll.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion wird ein einem Spieler helfender NPC im Spieler
- wieder abgemeldet, wenn dieser dem Spieler ab jetzt nicht mehr hilft.
-
- Wenn ein Helfer-NPC zerstoert wird, ist der Aufruf nicht noetig.
- Bleibt das Objekt des NPC aber existent, bitte auf jeden Fall wieder
- ordentlich abmelden, da ansonsten ggf. der Spieler unnoetig blockiert
- wird.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn die Abmeldung erfolgreich war.
- 0 sonst, z.B. wenn der NPC gar nicht als Helfer registriert war.
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion setzt bei der Erfolg die Property P_HELPER_NPC in <npc>
- auf 0.
-
-
-BEISPIELE
-=========
-
- 1. Ein NPC, der dem Spieler nicht mehr helfen will und normalerweisen im
- Raum verbleiben soll:
- tell_object(spieler, "Ich mag Dich nicht mehr, Du bist doof!\n");
- if (spieler->UnregisterHelperNPC(this_object()) != 1) {
- // das ist ja bloed...
- remove(0);
- }
- else {
- tell_room(environment(),
- Name()+" dreht " +spieler->Name(WEM) + " schmollend den Ruecken "
- "zu.\n");
- }
-
-
-SIEHE AUCH
-==========
-
- UnregisterHelperNPC()
- P_HELPER_NPC
diff --git a/doc/sphinx/man/lfun/UnregisterHelperObject b/doc/sphinx/man/lfun/UnregisterHelperObject
deleted file mode 100644
index d6242c9..0000000
--- a/doc/sphinx/man/lfun/UnregisterHelperObject
+++ /dev/null
@@ -1,71 +0,0 @@
-
-UnregisterHelperObject()
-************************
-
-
-FUNKTION
-========
-
- int UnregisterHelperObject(object helper, int type);
-
-
-DEFINIERT IN
-============
-
- /std/living/helpers.c
-
-
-ARGUMENTE
-=========
-
- object helper
- Das Objekt, das als Hilfsobjekt deregistriert werden soll.
- int type
- Helfertyp, einer der in /sys/living/helpers.h definierten Typen:
- - HELPER_TYPE_AERIAL fuer die Flug-/Segelunterstuetzung
- - HELPER_TYPE_AQUATIC fuer Tauchunterstuetzung
-
-
-BESCHREIBUNG
-============
-
- Das als Hilfsobjekt fuer bestimmte Aktivitaeten wie zum Beispiel Tauchen
- oder Fliegen bei einem Lebewesen registrierte Objekt "helper" meldet
- sich bei diesem ab.
- Hinweis: fuer eine temporaer gueltige "Nicht-Zustaendigkeit" kaeme auch
- in Frage, in dieser Zeit einfach "0" zurueckzugeben, statt sich
- komplett abzumelden.
-
-
-RUECKGABEWERTE
-==============
-
- 1 Objekt wurde erfolgreich ausgetragen (HELPER_SUCCESS)
- -1 angegebenes Hilfsobjekt existiert nicht (HELPER_NO_CALLBACK_OBJECT)
- -3 angegebenes Hilfsobjekt war gar nicht angemeldet
- (HELPER_NOTHING_TO_UNREGISTER)
-
-
-BEISPIEL
-========
-
- Eine luftgefuellte Blase hatte sich als Tauch-Helfer am Spieler
- angemeldet, ist jetzt aber verbraucht und meldet sich daher ab:
-
- // Austragen im Spielerobjekt
- void BlaseAustragen() {
- [...]
- if ( TP->UnregisterHelperObject(ME, HELPER_TYPE_AQUATIC)
- == HELPER_SUCCESS )
- remove();
- }
-
-
-SIEHE AUCH
-==========
-
- Funktionen: RegisterHelperObject()
- Properties: P_HELPER_OBJECTS, P_AERIAL_HELPERS, P_AQUATIC_HELPERS
- Sonstiges: /sys/living/helpers.h
-
-19.02.2013 Arathorn
diff --git a/doc/sphinx/man/lfun/Unwear b/doc/sphinx/man/lfun/Unwear
deleted file mode 100644
index 0ef0a2a..0000000
--- a/doc/sphinx/man/lfun/Unwear
+++ /dev/null
@@ -1,65 +0,0 @@
-
-Unwear()
-********
-
-
-FUNKTION
-========
-
- public int Unwear(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/living/clothing.c
-
-
-ARGUMENTE
-=========
-
- object ob
- Die Ruestung oder Kleidung, die ausgezogen wird.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
- oder das Kleidungsstueck <ob> aus.
- ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
- Ruestung/Kleidung aus P_ARMOURS bzw. P_CLOTHING ausgetragen wird. Es
- finden zur Zeit keine Pruefungen statt, ob das Lebewesen den Gegenstand
- ueberhaupt ausziehen kann. Genausowenig werden Funktionen wie
- InformUnwear()/RemoveFunc() gerufen oder etwaige Stat-Boni deaktiviert.
-
- Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
- von diesem im Lebewesen gerufen zu werden.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Ausziehen erfolgreich war.
- 0 sonst.
-
-
-BEMERKUNGEN
-===========
-
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
-
-
-SIEHE AUCH
-==========
-
- Wear(), WearArmour(), WearClothing(), UnwearArmour(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/UnwearArmour b/doc/sphinx/man/lfun/UnwearArmour
deleted file mode 100644
index b3c7d77..0000000
--- a/doc/sphinx/man/lfun/UnwearArmour
+++ /dev/null
@@ -1,65 +0,0 @@
-
-UnwearArmour()
-**************
-
-
-FUNKTION
-========
-
- public int UnwearArmour(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/living/clothing.c
-
-
-ARGUMENTE
-=========
-
- object ob
- Die Ruestung, die ausgezogen wird.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
- <ob> aus.
- ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
- Ruestung/Kleidung aus P_ARMOURS ausgetragen wird. Es finden zur Zeit
- keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
- ausziehen kann. Genausowenig werden Funktionen wie
- InformUnwear()/RemoveFunc() gerufen oder etwaige Stat-Boni deaktiviert.
-
- Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
- von diesem im Lebewesen gerufen zu werden.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Ausziehen erfolgreich war.
- 0 sonst.
-
-
-BEMERKUNGEN
-===========
-
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
-
-
-SIEHE AUCH
-==========
-
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/UnwearClothing b/doc/sphinx/man/lfun/UnwearClothing
deleted file mode 100644
index fe0372b..0000000
--- a/doc/sphinx/man/lfun/UnwearClothing
+++ /dev/null
@@ -1,65 +0,0 @@
-
-UnwearClothing()
-****************
-
-
-FUNKTION
-========
-
- public int UnwearClothing(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/living/clothing.c
-
-
-ARGUMENTE
-=========
-
- object ob
- Das Kleidungsstuck, das ausgezogen wird.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion gerufen wird, zieht das
- Kleidungsstueck <ob> aus.
- ABER: 'Ausziehen' bedeutet in diesem Kontext lediglich, dass die
- Ruestung/Kleidung aus P_CLOTHING ausgetragen wird. Es finden zur Zeit
- keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
- ausziehen kann. Genausowenig werden Funktionen wie
- InformUnwear()/RemoveFunc() gerufen.
-
- Die Funktion ist nur dazu gedacht, im Zuge des Ausziehens eines Objekts
- von diesem im Lebewesen gerufen zu werden.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Ausziehen erfolgreich war.
- 0 sonst.
-
-
-BEMERKUNGEN
-===========
-
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
-
-
-SIEHE AUCH
-==========
-
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/UnwieldFunc b/doc/sphinx/man/lfun/UnwieldFunc
deleted file mode 100644
index 0301182..0000000
--- a/doc/sphinx/man/lfun/UnwieldFunc
+++ /dev/null
@@ -1,74 +0,0 @@
-
-UnwieldFunc()
-*************
-
-
-FUNKTION
-========
-
- int UnwieldFunc(object weapon, int info, object user);
-
-
-DEFINIERT IN
-============
-
- eigenen Objekten, fuer /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- weapon (object)
- Die Waffe, die weggesteckt werden soll.
- info (int)
- Bei (info&M_SILENT) wird keine Meldung ueber das Wegstecken
- ausgegeben.
- Bei (info&M_NOCHECK) wird die Waffe auch weggesteckt, wenn
- sie verflucht ist. Die tritt insbesondere dann auf, wenn der
- Spieler, der die Waffe benutzt, stirbt und die Waffe in
- die Leiche bewegt wird.
- user (object)
- Das Lebewesen, welches die Waffe gerade gezueckt hat und sie nun
- ausziehen will.
-
-
-BESCHREIBUNG
-============
-
- Hier koennen zusaetzliche Abfragen vorgenommen werden, ob sich die
- Waffe <weapon> wegstecken laesst oder nicht.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn sich die Waffe nicht wegstecken laesst, ansonsten ungleich 0.
-
-
-BEMERKUNGEN
-===========
-
- Verfluchte Waffen, die sich erst nach Entfernung des Fluches wegstecken
- lassen, sollte man besser mit P_CURSED realisieren.
- Selbst wenn man einen Wert ungleich Null zurueckgibt, ist das noch
- keine Garantie, dass sich die Waffe auch wirklich zuecken laesst! Der
- Spieler koennte zum Beispiel noch eine Waffe gezueckt haben, die sich
- nicht wegstecken laesst, etc.
- Wenn ihr sicher sein wollt, dass der Spieler ein Objekt gezueckt hat,
- benutzt bitte InformWear().
- Bitte nicht drauf verlassen, dass this_player() das Lebewesen ist,
- welches die Waffe gezueckt und wegstecken will.
- Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
- erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
- Objekte zu aendern.
-
-
-SIEHE AUCH
-==========
-
- P_WIELD_MSG, P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
- DoWield(), DoUnwield(), InformWield(), InformUnwield(),
- UnwieldFunc, WieldFunc()
- /std/weapon/combat.c
-
-02.02.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/UpdateAttributes b/doc/sphinx/man/lfun/UpdateAttributes
deleted file mode 100644
index cdebaa7..0000000
--- a/doc/sphinx/man/lfun/UpdateAttributes
+++ /dev/null
@@ -1,52 +0,0 @@
-
-UpdateAttributes()
-******************
-
-
-FUNKTION
-========
-
- void UpdateAttributes()
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-BESCHREIBUNG
-============
-
- Rechnet damit alle Attributmodifier der im Inventory befindlichen
- (P_X_ATTR_MOD, P_X_HEALTH_MOD) und getragenen/gezueckten
- (P_M_HEALTH_MOD, P_M_ATTR_MOD) Objekte und aller Attributoffsets
- zusammen und speichert sie in einer intern fuer Attribute
- verwendete Variablen.
- Berechnet darauf basierend HP und SP neu.
-
-
-
- Die Bedingungen fuer die ueber P_TIMED_ATTR_MOD gesetzten
- Attributveraenderungen werden im Heartbeat in der Funktion
- attribute_hb ueberprueft.
-
-
-BEMERKUNGEN
-===========
-
- Sollte nach Einbringen neuer Modifikatorobjekte am Living gerufen
- werden.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-09.05.2007 by Zesstra
diff --git a/doc/sphinx/man/lfun/UpdateResistanceStrengths b/doc/sphinx/man/lfun/UpdateResistanceStrengths
deleted file mode 100644
index 8ae9198..0000000
--- a/doc/sphinx/man/lfun/UpdateResistanceStrengths
+++ /dev/null
@@ -1,43 +0,0 @@
-
-UpdateResistanceStrengths()
-***************************
-
-
-FUNKTION
-========
-
- public void UpdateResistanceStrengths()
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-BESCHREIBUNG
-============
-
- Die Funktion wird intern mehrmals (durch Defend, AddResistanceModifier
- und RemoveResistanceModifier) aufgerufen. In ihr wird das Resistenz-
- mapping zusammengerechnet und Eintraege geloescht, deren Eintraege
- invalid sind oder deren setzende Objekte geloescht wurden.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- Berechnung: CheckResistance(), Defend()
- Modifikatoren: AddResistanceModifier, RemoveResistanceModifier(),
- P_RESISTANCE_MODIFIER
- simple Resistenz: P_RESISTANCE, P_VULNERABILITY
- Hauptmapping: P_RESISTANCE_STRENGTHS
- anderes: balance, /std/armour/combat.c, /std/living/combat.c
-
-29.Apr 2002, Gloinson@MG
diff --git a/doc/sphinx/man/lfun/UseHands b/doc/sphinx/man/lfun/UseHands
deleted file mode 100644
index d11723c..0000000
--- a/doc/sphinx/man/lfun/UseHands
+++ /dev/null
@@ -1,61 +0,0 @@
-
-UseHands()
-**********
-
-
-FUNKTION
-========
-
- public varargs int UseHands(object ob, int num)
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- ob - das Objekt, das die Haende belegen soll
- num - die Anzahl der zu belegenden Haende
-
-
-RUECKGABEWERT
-=============
-
- 1, fuer Erfolg
- 0, sonst
-
-
-BESCHREIBUNG
-============
-
- Belegt, wenn moeglich Haende eines Livings durch ein bestimmtes
- Objekt. Wenn die Anzahl der freien Haende (P_MAX_HANDS-P_USED_HANDS)
- kleiner ist als "num", dann schlaegt diese Belegung fehl.
-
-
-BEISPIELE
-=========
-
- > halte seil fest
- ...
- this_player()->UseHands(this_object(),2);
- ...
-
- > lasse seil los
- ...
- this_player()->FreeHands(this_object());
- ...
-
-
-SIEHE AUCH
-==========
-
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
- FreeHands
-
-1.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/lfun/UseSkill b/doc/sphinx/man/lfun/UseSkill
deleted file mode 100644
index 4f3398d..0000000
--- a/doc/sphinx/man/lfun/UseSkill
+++ /dev/null
@@ -1,74 +0,0 @@
-
-UseSkill()
-**********
-
-
-FUNKTION
-========
-
- public varargs mixed UseSkill(string skill, mapping args)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
-
-
-ARGUMENTE
-=========
-
- string skill Skill-Name
- mapping args Argumente (veraenderte Skillmapping-Informationen)
-
-
-BESCHREIBUNG
-============
-
- Benutzt einen Skill. Dieser Skill sollte (als grossgeschriebener Skill)
- im Living vorliegen und das Living darf kein Geist sein.
-
-
-
- Die Argumente 'args' werden temporaer auf das Skillmapping des Living
- addiert (also nur fuer diesen Aufruf und SI_INHERIT gueltig).
-
-
-
- Eine ausfuehrbare Skill-Funktion zum Skill wird in folgender
- Reihenfolge bestimmt:
- - eine gesetzte SI_CLOSURE nutzen
- - ein gesetztes SI_SKILLFUNC in der gesetzten Gilde nutzen
- - im Living die Funktion "StdSkill_"+skill (zB Waffenskills) nutzen
- - QuerySkillAbility() nutzen
- Die so bestimmte Skill-Funktion wird dann als SI_CLOSURE im Spieler
- gesetzt und ist bis zur Zerstoerung der entsprechenden Objekte gueltig.
- Die Methode wird dann gerufen (der Skill also angewandt).
-
-
-
- Standardmaessig gibt ein UseSkill() also einfach den SI_SKILLABILITY-Wert
- eines Skills zurueck, es sei denn, eine Funktion wurde fuer den Skill
- an einer der oben genannten Stellen implementiert.
-
-
-
- Ein eventuell uebergeordneter Skill (SI_INHERIT) wird mit dem durch den
- Aufruf der Skill-Funktion veraenderten Mapping mit UseSkill(skill, args)
- ebenfalls noch ausgefuehrt, bevor das Resultat zurueckgegeben wird.
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
- Spellbook: Learn, SpellSuccess, Erfolg, Misserfolg
-
-4. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/UseSpell b/doc/sphinx/man/lfun/UseSpell
deleted file mode 100644
index b5cfbf7..0000000
--- a/doc/sphinx/man/lfun/UseSpell
+++ /dev/null
@@ -1,105 +0,0 @@
-
-UseSpell()
-**********
-
-
-FUNKTION
-========
-
- public varargs int UseSpell(string str, string spell)
-
-
-DEFINIERT IN
-============
-
- /std/living/skills.c
-
-
-ARGUMENTE
-=========
-
- string str Spell-Optionen
- string spell optionaler Spellname
-
-
-BESCHREIBUNG
-============
-
- Benutzt einen Spell, dessen Spellname 'spell' ggf ueber query_verb()
- ermittelt wird. Dieser Spell sollte (als kleingeschriebener
- Skill/Spell) im Living vorliegen.
-
-
-
- Die Argumente 'str' werden als SI_SKILLARG temporaer in das
- Skillmapping eingetragen (also nur fuer diesen Aufruf gueltig).
-
-
-
- Eine ausfuehrbare Spell-Funktion zum Spell wird in folgender
- Reihenfolge bestimmt:
- - eine gesetzte SI_CLOSURE nutzen
- - "UseSpell" an einem gesetzten SI_SPELLBOOK nutzen
- - "UseSpell" an der gesetzten P_GUILD nutzen
- - [UseSpell der Gilde sucht iA ebenfalls nur den Spell am Spellbook]
- - eine Closure mit Rueckgabewert 0 erstellen
- Die so bestimmte Spell-Funktion wird dann als SI_CLOSURE im Spieler
- gesetzt und ist bis zur Zerstoerung der entsprechenden Objekte gueltig.
- Die Methode wird dann gerufen (der Spell also angewandt).
-
- Standardmaessig gibt ein UseSpell() also 0 zurueck, es sei denn, eine
- Funktion wurde fuer den Spell an einer der oben genannten Stellen
- implementiert.
-
- SI_INHERIT ist fuer Spells beim Aufruf wirkungslos (gilt aber bei
- LearnSkill normal).
-
- Ein Durchlauf von UseSpell durch den Spieler sieht in etwa so aus:
- 1) Die Methode wird als Empfaenger fuer Kommandos bekannt gemacht.
- Das passiert mit der Anweisung
- 'add_action("UseSpell", "", 1);' in den Dateien player/base.c und
- in living/npc.c.
-
- 2) /std/living/skills::UseSpell wird durch Kommando oder Heartbeat
- gerufen.
-
-
-
- 3) UseSpell() ermittelt eine SI_CLOSURE oder delegiert diesen Aufruf
- an die gueltige Gilde/das Spellbook weiter.
-
-
-
- 4) Eine gueltige Closure wird ausgefuehrt. UseSpell() uebergibt dabei
- die Spell/Skill-Informationen und SI_SKILLARG.
-
-
-
- 4.1.) Im Normalfall einer Gilde/Spellbook landet der Aufruf ueber
- /std/gilden_ob::UseSpell() in /std/spellbook::UseSpell() und
- dieses ruft eine Spellfunktion im Spellbook auf.
- Die Spellfunktion arbeitet mit den Spell-Informationen und
- gibt ein ERFOLG, MISSERFOLG oder 0 dafuer zurueck, ob das
- Spellbook Lernen/Fehlermeldung oder nichts machen soll.
- Dementsprechend werden P_SP, P_ATTACK_BUSY und
- P_NEXT_SPELL_TIME im Spellbook geaendert.
-
- 5.) Der Aufruf der Closure kehrt zurueck und wird zurueckgegeben.
- Damit ist der 0-Rueckgabewert der Spellfunktion im Spellbook
- aequivalent einem nicht ausgefuehrten Kommando.
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
- Spellbook: UseSpell (spellbook), Learn, SpellSuccess
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/Validate b/doc/sphinx/man/lfun/Validate
deleted file mode 100644
index ddfceef..0000000
--- a/doc/sphinx/man/lfun/Validate
+++ /dev/null
@@ -1,74 +0,0 @@
-
-Validate()
-**********
-
-
-FUNKTION
-========
-
- string Validate(string oname);
-
-
-DEFINIERT IN
-============
-
- /std/virtual/v_compiler.c
-
-
-ARGUMENTE
-=========
-
- oname
- Objektname, der geprueft werden soll
-
-
-RUeCKGABEWERT
-=============
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion hat die Aufgabe zu ueberpruefen ob ein Objekt welches
- geladen werden soll, in dem VC ueberhaupt erlaubt ist. Dieser
- Funktion wird nur der reine Filename uebergeben, ohne Pfad!
- Diese Funktion macht im Standard-VC in /std/ nichts weiter, als
- das '.c' am File Namen abzuschneiden.
- Sollte der Dateiname gueltig sein liefert die Funktion als Rueckgabewert
- den Filenamen ohne .c und sonst 0.
-
-
-BEMERKUNGEN
-===========
-
- Am besten ruft man in seinem Validate() das ::Validate(), was einem die
- Arbeit abnimmt, ein .c am Ende zu entfernen.
-
-
-BEISPIEL
-========
-
- string Validate(string oname) {
- string raum, spieler;
- //.c abschneiden
- oname=::Validate(oname);
-
-
-
- // folgt der Raum dem Muster "arena|name"? Wenn nein -> ungueltig,
- // 0 zureckgeben, sonst den Filenamen.
- if(sscanf(oname,"%s|%s",raum,spieler)<2 || raum!="arena")
- return 0;
- return oname;
- }
-
-
-SIEHE AUCH
-==========
-
- virtual_compiler
- CustomizeObject(), Validate(), NoParaObjects(),
- P_COMPILER_PATH, P_PARA
- /std/virtual/v_compiler.c
-
-27.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/Wear b/doc/sphinx/man/lfun/Wear
deleted file mode 100644
index 6a46903..0000000
--- a/doc/sphinx/man/lfun/Wear
+++ /dev/null
@@ -1,64 +0,0 @@
-
-Wear()
-******
-
-
-FUNKTION
-========
-
- public int Wear(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/living/clothing.c
-
-
-ARGUMENTE
-=========
-
- object ob
- Die Ruestung oder Kleidung, die angezogen wird.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
- oder das Kleidungsstueck <ob> an.
- ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
- Ruestung/Kleidung in P_ARMOURS bzw. P_CLOTHING eingetragen wird. Es
- finden zur Zeit keine Pruefungen statt, ob das Lebewesen den Gegenstand
- ueberhaupt anziehen kann. Genausowenig werden Funktionen wie InformWear()
- gerufen oder etwaige Stat-Boni aktiviert.
- Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
- von diesem im Lebewesen gerufen zu werden.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Anziehen erfolgreich war.
- 0 sonst.
-
-
-BEMERKUNGEN
-===========
-
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
-
-
-SIEHE AUCH
-==========
-
- WearArmour(), WearClothing(), Unwear(), UnwearArmour(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/WearArmour b/doc/sphinx/man/lfun/WearArmour
deleted file mode 100644
index a6961b2..0000000
--- a/doc/sphinx/man/lfun/WearArmour
+++ /dev/null
@@ -1,64 +0,0 @@
-
-WearArmour()
-************
-
-
-FUNKTION
-========
-
- public int WearArmour(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/living/clothing.c
-
-
-ARGUMENTE
-=========
-
- object ob
- Die Ruestung, die angezogen wird.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion gerufen wird, zieht die Ruestung
- <ob> an.
- ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
- Ruestung/Kleidung in P_ARMOURS eingetragen wird. Es finden zur Zeit keine
- Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt anziehen
- kann. Genausowenig werden Funktionen wie InformWear() gerufen oder
- etwaige Stat-Boni aktiviert.
- Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
- von diesem im Lebewesen gerufen zu werden.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Anziehen erfolgreich war.
- 0 sonst.
-
-
-BEMERKUNGEN
-===========
-
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
-
-
-SIEHE AUCH
-==========
-
- Wear(), WearClothing(), Unwear(), UnwearArmour(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/WearClothing b/doc/sphinx/man/lfun/WearClothing
deleted file mode 100644
index 51cc015..0000000
--- a/doc/sphinx/man/lfun/WearClothing
+++ /dev/null
@@ -1,64 +0,0 @@
-
-WearClothing()
-**************
-
-
-FUNKTION
-========
-
- public int WearClothing(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/living/clothing.c
-
-
-ARGUMENTE
-=========
-
- object ob
- Das Kleidungsstuck, das angezogen wird.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion gerufen wird, zieht das
- Kleidungsstueck <ob> an.
- ABER: 'Anziehen' bedeutet in diesem Kontext lediglich, dass die
- Ruestung/Kleidung in P_CLOTHING eingetragen wird. Es finden zur Zeit
- keine Pruefungen statt, ob das Lebewesen den Gegenstand ueberhaupt
- anziehen kann. Genausowenig werden Funktionen wie InformWear() gerufen.
-
- Die Funktion ist nur dazu gedacht, im Zuge des Anziehens eines Objekts
- von diesem im Lebewesen gerufen zu werden.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Anziehen erfolgreich war.
- 0 sonst.
-
-
-BEMERKUNGEN
-===========
-
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
-
-
-SIEHE AUCH
-==========
-
- Wear(), WearArmour(), Unwear(), UnwearArmour(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/WearFunc b/doc/sphinx/man/lfun/WearFunc
deleted file mode 100644
index d1d0121..0000000
--- a/doc/sphinx/man/lfun/WearFunc
+++ /dev/null
@@ -1,105 +0,0 @@
-
-WearFunc()
-**********
-
-
-FUNKTION
-========
-
- int WearFunc(object ruest, int silent, object user);
-
-
-DEFINIERT IN
-============
-
- eigenen Objekten (fuer /std/clothing/wear)
-
-
-ARGUMENTE
-=========
-
- ruest (object)
- Die Ruestung/Kleidung, die angezogen werden soll.
- silent (int)
- Ob dabei eine Meldung ausgegeben wird.
- user (object)
- Das Lebewesen, welches die Ruestung/Kleidung anziehen will.
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion kann man pruefen, ob sich das Kleidungsstueck bzw.
- Ruestung <ruest> von this_player() anziehen laesst oder nicht.
- Kann die Ruestung angezogen werden, so muss ein Wert ungleich 0
- zurueckgegeben werden.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn sich die Ruestung nicht anziehen laesst, ansonsten ungleich 0.
-
-
-BEMERKUNGEN
-===========
-
- Bitte nicht darauf verlassen, dass der Spieler das Objekt auch wirklich
- anzieht, wenn man hier 1 zurueckgibt.
- Speziell bei Schilden kann das Anziehen trotz eines Rueckgabewertes
- != 0 immer noch schief gehen, wenn der Spieler keine Hand mehr frei hat.
- Wenn ihr sicher sein wollt, dass der Spieler ein Objekt angezogen hat,
- benutzt bitte InformWear().
- Bitte nicht drauf verlassen, dass this_player() das ausziehende Lebewesen
- ist.
- Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
- erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
- Objekte zu aendern.
-
-
-BEISPIELE
-=========
-
- Ein Helm, der nur von Elfen getragen werden kann:
-
- inherit "std/armour.c";
-
- #include <properties.h>
-
- create()
- {
- ::create();
-
- SetProp(P_ARMOUR_TYPE, AT_HELMET);
- /* zig weitere SetProp's, um den Helm zu konfigurieren */
-
- /* WearFunc() ist im Helm selbst zu finden */
- SetProp(P_WEAR_FUNC, this_object());
- }
-
- int WearFunc(object me, int silent, object user)
- {
- if (user->QueryProp(P_RACE) == "Elf")
- return 1; /* Elfen duerfen den Helm tragen */
-
- /* Die anderen Rassen sollten zumindest erfahren koennen, wieso
- sie den Helm nicht tragen koennen... */
- if (!silent)
- write( "Der Helm rutscht Dir immer ueber Deine runden "
- +"Ohren.\n" );
- return 0;
- }
-
- Gibt jetzt ein Nicht-Elf "trage helm" ein, so bekommt er die Meldung
- "Der Helm rutscht Dir immer ueber Deine runden Ohren.", Elfen dagegen
- passt das Teil wie angegossen.
-
-
-SIEHE AUCH
-==========
-
- P_WEAR_MSG, P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
- DoWear(), DoUnwear(), InformUnwear(), InformWear()
- /std/clothing/wear.c
-
-02.02.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/WieldFunc b/doc/sphinx/man/lfun/WieldFunc
deleted file mode 100644
index 7c607e4..0000000
--- a/doc/sphinx/man/lfun/WieldFunc
+++ /dev/null
@@ -1,102 +0,0 @@
-
-WieldFunc()
-***********
-
-
-FUNKTION
-========
-
- int WieldFunc(object weapon, int silent, object user);
-
-
-DEFINIERT IN
-============
-
- eigenen Objekten (fuer /std/weapon/combat)
-
-
-ARGUMENTE
-=========
-
- weapon (object)
- Die Waffe, die gezueckt werden soll.
- silent (int)
- Ob dabei eine Meldung ausgegeben werden soll.
- user (object)
- Das Lebewesen, welches die Waffe zuecken will.
-
-
-BESCHREIBUNG
-============
-
- In dieser Funktion kann man zusaetzliche Abfragen vornehmen, ob sich
- die Waffe <weapon> von <user> zuecken laesst oder nicht.
-
-
-RUeCKGABEWERT
-=============
-
- 0, wenn die Waffe nicht gezueckt werden kann, sonst ungleich 0.
-
-
-BEMERKUNGEN
-===========
-
- Selbst wenn man einen Wert ungleich Null zurueckgibt, ist das noch
- keine Garantie, dass sich die Waffe auch wirklich zuecken laesst! Der
- Spieler koennte zum Beispiel noch eine Waffe gezueckt haben, die sich
- nicht wegstecken laesst, etc.
- Wenn ihr sicher sein wollt, dass der Spieler ein Objekt gezueckt hat,
- benutzt bitte InformWield().
- Bitte nicht drauf verlassen, dass this_player() das Lebewesen ist,
- welches die Waffe zuecke will.
- Die Reihenfolge der Argumente ist etwas unschoen, aber leider wurde <user>
- erheblich spaeter hinzugefuegt und es war unmoeglich, einige hundert
- Objekte zu aendern.
-
-
-BEISPIELE
-=========
-
- Eine Waffe, die sich nicht von Zwergen zuecken laesst:
-
- inherit "std/weapon";
-
- #include <properties.h>
- #include <combat.h>
-
- create()
- {
- ::create();
-
- ... /* zig SetProp's, um die Waffe zu konfigurieren */
-
- /* WieldFunc() ist in der Waffe selbst zu finden */
- SetProp(P_WIELD_FUNC, this_object());
- }
-
- int WieldFunc(object weapon, int silent, object user)
- {
- /* Nicht-Zwerge duerfen die Waffe zuecken */
- if (user->QueryProp(P_RACE) != "Zwerg")
- return 1;
-
- /* Ansonsten sagen wir evtl., warum das Zuecken nicht klappt... */
- if (!silent)
- write( "Deine kleinen Haendchen koennen den Griff nicht "+
- "umklammern.\n");
-
- /* ...und brechen das Zuecken ab. */
- return 0;
- }
-
-
-SIEHE AUCH
-==========
-
- P_WIELD_MSG, P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
- DoWield(), DoUnwield(), InformUnwield(), InformWield()
- UnwieldFunc, WieldFunc
- /std/weapon/combat.c
-
-02.02.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/WithDraw b/doc/sphinx/man/lfun/WithDraw
deleted file mode 100644
index 1bff547..0000000
--- a/doc/sphinx/man/lfun/WithDraw
+++ /dev/null
@@ -1,69 +0,0 @@
-
-WithDraw()
-**********
-
-
-FUNKTION
-========
-
- int WithDraw(int amount);
-
-
-DEFINIERT IN
-============
-
- /p/daemon/zentralbank.c
-
-
-ARGUMENTE
-=========
-
- int amount - angeforderte Geldmenge
-
-
-BESCHREIBUNG
-============
-
- Damit wird bei der Zentralbank eine bestimmte Menge Geld angefordert.
- Der Rueckgabewert haengt vom Kassenstand der Zentralbank ab und ist
- entweder amount oder amount/3.
-
-
-RUeCKGABEWERT
-=============
-
- Menge des bei der Zentralbank "abgehobenen" Geldes.
-
-
-BEISPIELE
-=========
-
- #include <bank.h>
- ...
- if(ZENTRALBANK->WithDraw(50000)<50000)
- write(break_string(
- "Leider koennen wir ihnen keinen vollen Zuschuss zu ihrem Hotelbau "
- "geben!",
- "Der Beamte sagt: ",78));
- say(break_string(
- "Leider koennen wir ihnen keinen vollen Zuschuss zu ihrem Hotelbau "
- "geben!",
- "Der Beamte sagt zu "+this_player()->name(WEM)+": ",78));
- ...
-
-
-BEMERKUNGEN
-===========
-
- Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
- an anderen Stellen Geld erzeugt wird.
-
-
-SIEHE AUCH
-==========
-
- Geldhandling: AddMoney(L), QueryMoney(L)
- Zentralbank: PayIn(L), _query_current_money(L)
- Sonstiges: /items/money.c, /sys/bank.h
-
-27. Apr 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/__INIT b/doc/sphinx/man/lfun/__INIT
deleted file mode 100644
index 3ba4793..0000000
--- a/doc/sphinx/man/lfun/__INIT
+++ /dev/null
@@ -1,25 +0,0 @@
-
-__INIT()
-********
-
-
-SYNOPSIS
-========
-
- __INIT
-
-
-DESCRIPTION
-===========
-
- This function is constructed automagically by the parser at
- compiler, if the parser was compiled with #define
- INITIALISATION__INIT. This function is not intended to be
- defined by the lpc objects, and never to be called from lpc
- objects. This man page is here just for completeness.
-
-
-SEE ALSO
-========
-
- initialisation(LPC)
diff --git a/doc/sphinx/man/lfun/_query_current_money b/doc/sphinx/man/lfun/_query_current_money
deleted file mode 100644
index db3663f..0000000
--- a/doc/sphinx/man/lfun/_query_current_money
+++ /dev/null
@@ -1,53 +0,0 @@
-
-_query_current_money()
-**********************
-
-
-FUNKTION
-========
-
- int _query_current_money()
-
-
-DEFINIERT IN
-============
-
- /p/daemon/zentralbank.c
-
-
-BESCHREIBUNG
-============
-
- Es wird zurueckgegeben, wieviel Geld die Zentralbank besitzt.
-
-
-BEISPIELE
-=========
-
- #include <bank.h>
- ...
- if(ZENTRALBANK->_query_current_money()<30000) {
- write(break_string(
- "Leider koennen wir ihren Bausparvertrag derzeit nicht einloesen.",
- "Der Beamte sagt: ",78));
- say(break_string(
- "Leider koennen wir ihren Bausparvertrag derzeit nicht einloesen.",
- "Der Beamte sagt zu "+this_player()->name(WEM)+": ",78));
- }
-
-
-BEMERKUNGEN
-===========
-
- Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
- an anderen Stellen Geld erzeugt wird.
-
-
-SIEHE AUCH
-==========
-
- Geldhandling: AddMoney(L), QueryMoney(L)
- Zentralbank: WithDraw(L), PayIn(L)
- Sonstiges: /items/money.c, /sys/bank.h
-
-27. Apr 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/_unparsed_args b/doc/sphinx/man/lfun/_unparsed_args
deleted file mode 100644
index caf3653..0000000
--- a/doc/sphinx/man/lfun/_unparsed_args
+++ /dev/null
@@ -1,49 +0,0 @@
-
-_unparsed_args()
-****************
-
-
-FUNKTION
-========
-
- varargs string _unparsed_args(int level)
-
-
-DEFINIERT IN
-============
-
- /std/player/command.c:
-
-
-ARGUMENTE
-=========
-
- level
- Gibt an, wieviel des Textes "weggeparsed" werden soll.
-
-
-BESCHREIBUNG
-============
-
- Gibt den Text des letzten Befehls des Spielers (ohne das Befehlswort
- selbst) zurueck. "level" gibt dabei an, wieviel geparsed wird:
- level = 0 : Gar kein Parsing.
- level = 1 : Der Text wird in Kleinbuchstaben umgewandelt, doppelte
- Leerzeichen werden entfernt.
- level = 2 : Semikoli, Kommata und Doppelpunkte werden in Leerzeichen
- umgewandelt, doppelte Leerzeichen und Artikel (der, die,
- das, ein,...) werden entfernt.
-
-
-RUeCKGABEWERT
-=============
-
- Der geparste Text.
-
-
-SIEHE AUCH
-==========
-
- query_command(), query_verb(), modify_command()
-
-25.08.2016, Arathorn
diff --git a/doc/sphinx/man/lfun/access_rights b/doc/sphinx/man/lfun/access_rights
deleted file mode 100644
index 7a99a99..0000000
--- a/doc/sphinx/man/lfun/access_rights
+++ /dev/null
@@ -1,98 +0,0 @@
-
-access_rights()
-***************
-
-
-FUNKTION
-========
-
- int access_rights(string euid, string file);
-
-
-DEFINIERT IN
-============
-
- access_rights.c (muss man selber schreiben)
-
-
-PARAMETER
-=========
-
- euid
- Die euid desjenigen, der auf das Verzeichnis schreiben will
- file
- Name der Datei, auf die zugegriffen werden soll
-
-
-BESCHREIBUNG
-============
-
- access_rights() wird immer dann aufgerufen, wenn jemand, der nicht
- sowieso schon schreibberechtigt ist, in die Datei/das Verzeichnis file
- schreiben oder loeschen will.
-
- Anhand von euid kann man dann entscheiden, ob der Schreibzugriff erlaubt
- wird oder nicht.
-
-
-RUECKGABEWERT
-=============
-
- 0, wenn der Zugriff verweigert wird,
- 1, wenn der Zugriff erlaubt wird.
-
-
-BEISPIELE
-=========
-
- /* /d/inseln/wargon/access_rights.c */
-
- int access_rights(string euid, string file)
- {
- string dir, rest;
-
- // Catweazle darf auf alles zugreifen (*argl* ;^)
- if (euid == "catweazle")
- return 1;
-
- // Rechte auf einzelne Verzeichnisse ermitteln:
- if (sscanf(file, "%s/%s", dir, rest) != 2)
- rest = file;
-
- // Jof und Boing duerfen an Tarko Reub rumpfuschen:
- if (dir == "tarko" && (euid == "jof" || euid == "boing"))
- return 1;
-
- // Anthea darf die Karten von Aurora und der Piratenhoehle bearbeiten:
- if (dir == "MAPS" &&
- member( ({"Aurora", "Piratenhoehle" }), rest) >= 0 &&
- euid == "anthea")
- return 1;
-
- // alle anderen duerfen nicht!
- return 0;
- }
-
-
-BEMERKUNGEN
-===========
-
- file ist immer relativ zu dem Verzeichnis, in dem das access_rights.c
- liegt! Will also jemand auf /d/inseln/wargon/tarko/macros.h schreiben,
- wird file "tarko/macros.h" uebergeben.
-
- In Verzeichnissen von Magiern mit einem Level >= ELDER_LVL wird das
- access_rights.c NICHT ausgewertet (da damit andere Magier zB. an
- Erzmagierrechte gelangen koennten).
-
- Es wird immer nur EIN access_rights.c ausgewertet, naemlich das in der
- tiefsten Verzeichnisebene.
-
- Man kann sowohl in seinen Regionsverzeichnissen als auch in seinen
- Homeverzeichnissen access_rights.c-Dateien anlegen.
-
- GANZ WICHTIG!!!
- Fuer die Dateien, die evtl. von anderen angelegt werden, ist man immer
- noch selbst verantwortlich! Wenn jemand also ein Gebiet bei Dir an-
- schliesst, muss es erst von den verantwortlichen Regionsmagiern abgesegnet
- sein!
diff --git a/doc/sphinx/man/lfun/buffer_hp b/doc/sphinx/man/lfun/buffer_hp
deleted file mode 100644
index 181751c..0000000
--- a/doc/sphinx/man/lfun/buffer_hp
+++ /dev/null
@@ -1,104 +0,0 @@
-
-buffer_hp()
-***********
-
-
-FUNKTION
-========
-
- int buffer_hp( int val, int rate );
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- val: Gesamte Heilung.
- rate: LP-Rate.
-
-
-BESCHREIBUNG
-============
-
- Erhoeht die LP eines Spielers automatisch insgesamt um den Wert "val".
- Pro heart_beat() wird ihm dabei der Wert "rate" zugefuehrt.
- Sollen neben P_HP noch weitere Props manipuliert werden - bspw. zur
- P_FOOD - bietet sich die Funktion consume() an.
-
-
-RUECKGABEWERTE
-==============
-
- Der getankte Wert pro heart_beat().
-
-
-BEMERKUNG
-=========
-
- Sollte von jeder tragbaren Heilung genutzt werden, welche den Spieler
- darauf schliessen lassen kann, auf natuerlichem und nichtmagischem Weg
- (Essen, Trinken) geheilt worden zu sein.
-
-
-BEISPIEL
-========
-
- #define TP this_player()
- ...
-
- int heilung=1;
- ...
-
- create()
- {
- ::create();
- SetProp(P_NAME,"Heilpflanze");
- ...
-
- AddCmd("iss","eat");
- }
-
- int eat(string str)
- {
- notify_fail("WAS willst Du essen?\n");
- if ( !str || !id(str) )
- return 0;
- ...
-
- if ( !TP->eat_food(25) )
- return 1;
-
- TP->buffer_hp(20,5);
- TP->buffer_sp(80,10);
- heilung--;
- write(BS("Du fuehlst langsam, wie Deine Kraefte zurueckkehren."));
-
- return 1;
- }
-
- reset()
- {
- heilung=1;
- ::reset();
- }
-
- Es wird durch eat_food getestet, ob der Spieler noch genuegend essen kann.
- Wenn ja, kriegt unser Held die 25 automatisch oben drauf und ausserdem
- 20 LP in 5-LP-Schritten und 80 KP in 10-LP-Schritten gutgeschrieben.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: heal_self, restore_spell_points, restore_hit_points,
- buffer_sp
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Props: P_SP, P_HP,
- Konzepte: heilung
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/buffer_sp b/doc/sphinx/man/lfun/buffer_sp
deleted file mode 100644
index 09cad72..0000000
--- a/doc/sphinx/man/lfun/buffer_sp
+++ /dev/null
@@ -1,63 +0,0 @@
-
-buffer_sp()
-***********
-
-
-FUNKTION
-========
-
- int buffer_sp( int val, int rate );
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- val: Gesamte Heilung.
- rate: KP-Rate.
-
-
-BESCHREIBUNG
-============
-
- Erhoeht die KP eines Spielers automatisch insgesamt um den Wert "val".
- Pro heart_beat() wird ihm dabei der Wert "rate" zugefuehrt.
- Sollen neben P_SP noch weitere Props manipuliert werden - bspw. zur
- P_FOOD - bietet sich die Funktion consume() an.
-
-
-RUECKGABEWERTE
-==============
-
- Der getankte Wert pro heart_beat().
-
-
-BEMERKUNG
-=========
-
- Sollte von jeder tragbaren Heilung genutzt werden, welche den Spieler
- darauf schliessen lassen kann, auf natuerlichem und nichtmagischem Weg
- (Essen, Trinken) geheilt worden zu sein.
-
-
-BEISPIEL
-========
-
- s. Bsp. zu "buffer_hp"
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: heal_self, restore_spell_points, restore_hit_points,
- buffer_hp
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Props: P_SP, P_HP,
- Konzepte: heilung
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/buy_obj b/doc/sphinx/man/lfun/buy_obj
deleted file mode 100644
index 0f0b965..0000000
--- a/doc/sphinx/man/lfun/buy_obj
+++ /dev/null
@@ -1,65 +0,0 @@
-
-buy_obj()
-*********
-
-
-FUNKTION
-========
-
- static string buy_obj(mixed ob, int short);
-
-
-DEFINIERT IN
-============
-
- /std/shop.c
-
-
-ARGUMENTE
-=========
-
- ob - der Gegenstand bei dem geprueft werden soll, ob der Laden ihn
- an this_player() verkauft. Sollte es sich hierbei um ein
- FixedObject handeln, wird ein String uebergeben, ansonsten ein
- object.
- short - Bisher noch nicht in Benutzung. Aber fuer die Zukunft
- vorgesehn, falls man mehrere Objekte auf einmal kauft.
- Ein auswerten ist keine Pflicht, waere aber praktisch, damit
- der Scroll dabei nicht zu gross wird.
-
-
-RUeCKGABEWERT
-=============
-
- Ein String was der Haendler sagen soll wieso der Gegenstand nicht
- verkauft wird. Der String wird dabei wie folgt umgebrochen:
- break_string(str, 78, Name(WER, 1)+" sagt: ")
-
-
-BESCHREIBUNG
-============
-
- Durch ueberschreiben dieser Funktion ist es moeglich bestimmte
- Objekte (wie z.b. Questobjekte) nur an ausgewaehlte Spieler zu
- verkaufen). Aber auch abfragen ob der Laden ueberhaupt mit
- this_player() handelt, sind moeglich.
-
-
-BEISPIELE
-=========
-
- static string buy_obj(mixed ob, int short)
- {
- if (PL->QueryProp(P_RACE)=="Zwerg")
- return "Ich verkaufe nichts an Zwerge!";
- return ::buy_obj(ob, short);
- }
-
-
-SIEHE AUCH
-==========
-
- sell_obj(), AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
- /std/shop.c
-
-Last modified: Thu Mar 4 15:26:13 1999 by Padreic
diff --git a/doc/sphinx/man/lfun/catch_msg b/doc/sphinx/man/lfun/catch_msg
deleted file mode 100644
index 42d1950..0000000
--- a/doc/sphinx/man/lfun/catch_msg
+++ /dev/null
@@ -1,26 +0,0 @@
-
-catch_msg()
-***********
-
-
-SYNOPSIS
-========
-
- void catch_msg(mixed *arr, object obj)
-
-
-DESCRIPTION
-===========
-
- When say(), tell_object() or tell_room() are used with an array
- as message, the array will be passed to catch_message() in all living
- objects that can hear it, instead of writing to the user resp.
- sending to catch_tell(). This can be used to implement
- communication protocols between livings. The second denotes
- the object that has sent the message.
-
-
-SEE ALSO
-========
-
- say(E), tell_room(E), tell_object(E), catch_tell(L)
diff --git a/doc/sphinx/man/lfun/catch_tell b/doc/sphinx/man/lfun/catch_tell
deleted file mode 100644
index ff4e030..0000000
--- a/doc/sphinx/man/lfun/catch_tell
+++ /dev/null
@@ -1,36 +0,0 @@
-
-catch_tell()
-************
-
-
-SYNOPSIS
-========
-
- void catch_tell(string)
-
-
-DESCRIPTION
-===========
-
- When a message is sent to a noninteractive player, via say(),
- tell_object, tell_room(), printf() or write(), it will get to the
- function catch_tell(string). This will enable communications between
- NPCs and from a player to an NPC.
-
- Also, if an interactive object is being shadowed and the
- shadow has catch_tell() defined, it will receive all output
- that would otherwise be written to the user.
-
- If a message is sent by an interactive object, catch_tell() is
- not called in that object, to prevent recursive calls. Thus
- catch_tell() in interactive objects can be used to filter the
- output that goes to the users.
-
- The efun shout() sends to interactive objects only.
-
-
-SEE ALSO
-========
-
- enable_commands(E), say(E), tell_object(E), tell_room(E),
- write(E), catch_msg(L)
diff --git a/doc/sphinx/man/lfun/check_and_update_timed_key b/doc/sphinx/man/lfun/check_and_update_timed_key
deleted file mode 100644
index aa96667..0000000
--- a/doc/sphinx/man/lfun/check_and_update_timed_key
+++ /dev/null
@@ -1,114 +0,0 @@
-
-check_and_update_timed_key()
-****************************
-
-
-FUNKTION
-========
-
- public int check_and_update_timed_key(int duration, string key)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- int duration: In wieviel Sekunden wird <key> wieder freigebeben,
- (z.B. wann kann der Spieler an dieser Stelle eine neue
- Heilung bekommen).
- string key : Eindeutiger Name, wird zusammen mit <duration>
- gespeichert.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion hat die Aufgabe, Zeitsperren verschiedenster Art
- einfach zu ermoeglichen (z.B. die Realisierung charakter-abhaengiger
- Heilstellen u.ae.).
-
- <key> muss eindeutig sein, am besten verwendet man den eigenen
- Magiernamen (und ggf. nen Gebietsnamen) als Teil des Strings.
-
- Die Funktion ist definiert in /std/living/life.c. Somit funktioniert
- sie auch bei NPCs. Die Daten werden in P_TIMING_MAP gespeichert, sind
- also gegen "ende" resistent. (werden allerdings nach Ablauf ggf.
- 'aufgeraeumt')
-
- Das Mapping P_TIMING_MAP ist NICHT zur Abfrage und / oder Manipulation
- 'per Hand' vorgesehen.
-
-
-RUeCKGABEWERT
-=============
-
- 0 Irgendein Fehler im Aufruf, evtl. existiert die Funktion (noch)
- nicht im jew. Objekt.
-
- -1 Alles okay. Neuer Zeitpunkt wird automatisch gespeichert. In
- diesem Fall darf der Spieler geheilt werden.
-
- >0 Key noch gesperrt, in dem Fall darf also nicht geheilt werden.
- Der Rueckgabewert ist der Zeitpunkt, ab dem <key> wieder frei ist,
- laesst sich daher dazu nutzen, um dem Spieler einen Anhaltspunkt
- zu geben, wann er die Stelle wieder nutzen kann, etwa:
-
- "Die Schale ist erst halb voll, Du musst noch etwas warten."
-
-
-BEISPIELE
-=========
-
- Eine Heilstelle soll jedem Spieler alle 5min zur Verfuegung stehen:
-
- AddCmd(({"trink","trinke"}),"trink_cmd");
-
- int trink_cmd(string str){
- ...
- ...
- /*
- Der key sollte natuerlich eine etwas eindeutigere Kennzeichnung
- wie etwa "tilly_trinken" bekommen, auch wenn er durch einen
- anderen (gleichnamigen) nicht ueberschrieben werden kann.
-
- Trifft diese Abfrage hier zu, kann dem Spieler Heilung o.ae. zu-
- gefuehrt werden. Die neue Zeit (duration) wird automatisch gesetzt.
- */
- if(this_player()->check_and_update_timed_key(300,"jof_trinken")==-1){
- if(this_player()->drink_soft(2)){
- this_player()->heal_self(50);
- write("Du fuehlst Dich sichtlich erfrischt.\n");
- return 1;
- }
- else{
- write("Du hast schon zuviel getrunken.\n");
- return 1;
- }
- }
- else {
- write("Du trinkst und denkst . o O (Hmm, nicht schlecht).\n");
- return 1;
- }
- return 0;
- }
-
-BEMERKUNGEN:
- Auch bei dieser Funktion ist darauf zu achten, dass Properties wie
- P_FOOD, P_DRINK und P_ALCOHOL beruecksichtigt werden. Heilstellen
- sind dem zustaendigen Magier fuer Heilungs-Balance zu melden. Wer
- dies momentan ist, kann dem Mailalias heilungs_balance entnommen
- werden.
-
-
-SIEHE AUCH
-==========
-
- check_timed_key, eat_food, drink_alcohol, drink_soft, heal_self,
- restore_spell_points, reduce_hit_point
-
-08.01.2012, Zesstra
diff --git a/doc/sphinx/man/lfun/check_restrictions b/doc/sphinx/man/lfun/check_restrictions
deleted file mode 100644
index e173e8f..0000000
--- a/doc/sphinx/man/lfun/check_restrictions
+++ /dev/null
@@ -1,202 +0,0 @@
-
-check_restrictions()
-********************
-
-
-FUNKTION
-========
-
- string check_restrictions(object pl, mapping restr)
-
-
-DEFINIERT IN
-============
-
- /std/restriction_checker.c
-
-
-ARGUMENTE
-=========
-
- object pl geprueftes Lebewesen
- mapping restr Mapping mit Restriktionen, s.u.
-
-
-BESCHREIBUNG
-============
-
- Die Methode wird verwendet, um Restriktionen (zum Beispiel fuer das
- Casten eines Spells) zu pruefen. Sie wird von Spellbook und
- Gildenobjekt direkt genutzt.
-
- Ihr wird dabei ein Spielerobjekt sowie ein Mapping mit den jeweiligen
- Restriktionen uebergeben. Die aktuell moeglichen Keys des Mappings sind
- weiter unten gelistet.
-
-
-BEMERKUNGEN
-===========
-
- Es wird bei der Rasse P_REAL_RACE geprueft. Der Tarnhelm funktioniert
- also nicht.
-
- Bei Erweiterungsvorschlaegen wendet euch bitte an einen EM oder
- inheritet im Zweifelsfall nach Absprache.
- NIEMALS solchen Code einfach KOPIEREN. Spaeter muss nur irgendwer
- eurem alten Code hinterherraeumen.
-
-Aktuelle Liste der pruefbaren Parameter:
- P_LEVEL
- Mindeststufe, die das Lebewesen besitzen muss, um die Aktion
- auszufuehren.
-
- P_GUILD_LEVEL
- Gildenlevel, das das Lebewesen mindestens erreicht haben muss,
- um die Aktion auszufuehren.
-
- SR_SEER
- Ist gesetzt, wenn das Lebewesen Seher sein muss. Auswertung nur
- fuer Interactives, NSC ignorieren das Flag.
-
- P_XP
- Mindestmenge an Erfahrungspunkten, die ein Lebewesen besitzen
- muss, um die Aktion auszufuehren.
-
- P_QP
- Mindestmenge an Abenteuerpunkten, die das Lebewesen haben muss.
-
- P_ALCOHOL
- Menge an Alkohol, unter der der Alkoholspiegel des Lebewesen
- liegen muss, um die Aktion noch ausfuehren zu koennen.
-
- P_DRINK
- Menge an Fluessigkeit, unter der der Fluessigkeitsspiegel des
- Lebewesen liegen muss, um die Aktion noch ausfuehren zu koennen.
-
- P_FOOD
- Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel
- des Spielers liegen muss, um die Aktion noch ausfuehren zu
- koennen.
-
- P_DEAF
- Ist gesetzt, falls der Spieler nicht taub sein darf.
-
- P_FROG
- Ist gesetzt, falls der Spieler kein Frosch sein darf.
-
- P_BLIND
- Ist gesetzt, falls der Spieler nicht blind sein darf. Achtung:
- das ist nicht gleichbedeutend mit dem Umstand, dass er evtl.
- nichts mehr sehen kann. Auch andere Gruende (zum Beispiel
- Dunkelheit) koennen bewirken, dass ein Spieler nichts mehr
- sieht.
-
- A_INT, A_DEX, A_CON, A_STR
- Jeweilige Mindesthoehe eines Attribut, um eine Aktion ausfuehren
- zu koennen.
-
- SR_BAD, SR_GOOD
- Gibt an, wie [minimal] boese bzw. wie [maximal] gut ein
- Charakter sein darf, um eine Aktion ausfuehren zu koennen.
-
- SR_MIN_SIZE, SR_MAX_SIZE
- Gibt die minimale, bzw. die maximale Groesse an, die ein
- Charakter maximal haben darf, um eine Aktion ausfuehren zu
- koennen.
-
- SR_FREE_HANDS
- Gibt an, wieviele freie Haende ein Charakter fuer diese Aktion
- besitzen muss.
-
- SR_EXCLUDE_RACE
- Mitglieder aller in dieser Liste aufgefuehrten Rassen koennen
- diese Aktion nicht ausfuehren.
-
- SR_INCLUDE_RACE
- Mitglieder aller NICHT in dieser Liste aufgefuehrten Rassen
- koennen diese Aktion nicht ausfuehren.
-
- SM_RACE
- Hier kann pro Rasse ein Mapping mit besonderen (nur) fuer diese
- Rasse geltenden Einschraenkungen vorgenommen werden. Als Keys
- sind die in dieser Manpage beschriebenen Keys erlaubt, wobei
- SM_RACE nicht rekursiv ausgewertet wird. Der Rassenname ist
- gross geschrieben und "*" steht fuer alle Rassen.
-
- SR_EXCLUDE_GUILD SR_INCLUDE_GUILD
-
- Diese beiden Keys verhalten sich wie SR_*_RACE, nur dass hier
- Gilden genannt werden.
-
- SR_FUN
- Hier kann eine Funktion in verschiedenen Formen zum Pruefen der
- Restriktionen angegeben werden, siehe execute_anything(). Das
- kann nuetzlich sein, um andere Restriktionen zu pruefen, wie das
- Bestehen von Miniquests oder andere Faehigkeiten/Flags. Ist der
- Test nicht bestanden, gibt die Funktion einen String zurueck.
-
- SR_PROP
- Hier kann ein Mapping mit Properties und zugehoerigen Werten
- angegeben werden, die jeweils auf Identitaet geprueft werden.
- Zusaetzlich sollte eine Meldung angegeben werden, die als
- Fehlermeldung ausgegeben wird, wenn der Spieler die Bedingung
- nicht erfuellt. Es sollte immer eine passende Meldung fuer den
- Spieler eingebaut werden. Beispiel: ([ SR_PROP:
- ([P_AUSGANG_ENTDECKT: 1; "Dein Schwert fluestert "
-
- "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn
- Du " "Dich als wuerdig erwiesen hast!"]) ])
-
- Aufgrund der Meldung wird empfohlen, SR_PROP nicht in
- Restriktionen einzusetzen, die massenweise in Savefiles landen
- (z.B. Spielersavefiles).
-
- SR_QUEST
- Hier kann ein String-Array mit den Namen (Keys) der Quest(s)
- angegeben werden, die der Spieler bestanden haben muss, um die
- Aktion ausfuehren zu koennen.
-
- SQ_MINIQUEST
- Hier kann entweder ein String-Array mit den Ladenamen der
- vergebenden Objekte oder ein Int-Array mit den Index-Nummern
- (IDs) der Miniquest(s) (empfohlen!) angegeben werden, die der
- Spieler bestanden haben muss, um die Aktion ausfuehren zu
- koennen.
-
-
-BEISPIELE
-=========
-
- // #1 Levelbeschraenkung in der Abenteurergilde
- AddSpell("feuerball",20,
- ([SI_SKILLRESTR_LEARN:([P_LEVEL:15]), ...
-
- // #2 Glaubenstest im Klerus
- AddSpell("bete",
- ([SI_SKILLRESTR_LEARN: ([P_GUILD_LEVEL : LVL_NOVIZE,
- SR_FUN : #'glaubensTest ]), ...
- // mit
- static string glaubensTest(object pl) {
- if (pl->QueryProp(K_STRENGTH) < 8000)
- return ("Deine Glaubensstaerke laesst zu wuenschen uebrig!\n");
- return 0;
- }
-
- // #3 SM_RACE-Modifikation der Restriktionen:
- // haertere Restriktionen fuer Zwerge
- // - hoeheres Level
- // - zusaetzlich A_STR pruefen
- ([P_LEVEL:15,
- A_INT:10,
- SM_RACE: (["Zwerg": ([P_LEVEL:17, A_STR:20])])])
- // ist identisch zu
- ([SM_RACE: (["*": ([P_LEVEL:15, A_INT:10]),
- "Zwerg": ([P_LEVEL:17, A_INT:10, A_STR:20])])])
-
-
-SIEHE AUCH
-==========
-
- execute_anything(L), AddSpell (Gilde), P_RESTRICTIONS
-
-3. Januar 2014, Arathorn
diff --git a/doc/sphinx/man/lfun/check_timed_key b/doc/sphinx/man/lfun/check_timed_key
deleted file mode 100644
index 58c70ab..0000000
--- a/doc/sphinx/man/lfun/check_timed_key
+++ /dev/null
@@ -1,52 +0,0 @@
-
-check_timed_key()
-*****************
-
-
-FUNKTION
-========
-
- public int check_timed_key(string key)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- string key : Eindeutiger Name
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion hat die Aufgabe, mittels check_and_update_timed_key()
- gespeicherte Zeitsperren zu pruefen, aber dabei nicht zu veraendern.
-
- Es MUSS bei der eigentlichen Aktion (z.B. Heilung des Spielers) der
- Rueckgabewert von check_and_update_timed_key() beruecksichtigt werden,
- sollte dieses nicht -1 geliefert haben, MUSS <key> als gesperrt
- betrachtet werden, d.h. check_timed_key() hat nur informativen
- Charakter.
-
-
-RUeCKGABEWERT
-=============
-
- 0 Die Zeitsperre <key> ist abgelaufen.
-
- >0 <key> ist noch gesperrt.
- Der Rueckgabewert ist der Zeitpunkt, ab dem <key> wieder frei ist,
-
-
-SIEHE AUCH
-==========
-
- check_and_update_timed_key, eat_food, drink_alcohol, drink_soft,
- heal_self, restore_spell_points, reduce_hit_point
-
-08.01.2012, Zesstra
diff --git a/doc/sphinx/man/lfun/clean_up b/doc/sphinx/man/lfun/clean_up
deleted file mode 100644
index 7c124fb..0000000
--- a/doc/sphinx/man/lfun/clean_up
+++ /dev/null
@@ -1,67 +0,0 @@
-
-clean_up()
-**********
-
-
-FUNKTION
-========
-
- int clean_up(int ref);
-
-
-DEFINIERT IN
-============
-
- /std/room.c
- man kann die Funktion jedoch auch in beliebigen Objekten selbst
- definieren.
-
-
-ARGUMENTE
-=========
-
- ref
- + 0 bei gecloneten Objekten
- + 1 bei einfachen geladenen Objekten
- + >1 bei Objekten, die geerbt wurden oder als Blueprint dienen
- + <0, wenn clean_up() von aussen aufgerufen wurde (das muss man
- selbst beachten!)
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Objekt seit langer Zeit nicht mehr benutzt wurde, kann es sich
- hier selbst zerstoeren. Das sollte das Objekt allerdings nur tun, wenn
- ref kleiner oder gleich 1 ist.
-
-
-RUeCKGABEWERT
-=============
-
- Der Rueckgabewert hat nur dann eine Bedeutung, wenn sich das Objekt
- nicht selbst zerstoert hat. Wird 0 zurueckgegeben, so wird clean_up()
- erst dann wieder aufgerufen, nachdem das Objekt aus- und wieder
- eingeswappt wurde.
-
- Ein Rueckgabewert ungleich 0 zeigt an, dass das Objekt sich
- wahrscheinlich in der naechsten clean_up()-Runde zerstoeren kann, wenn
- in der Zwischenzeit zB. noch einmal reset() aufgerufen wurde.
-
-
-BEMERKUNGEN
-===========
-
- Standardmaessig definieren nur Raeume clean_up().
-
- Die Zeiten zwischen zwei Aufrufen von clean_up() betragen momentan
- einen Tag (86400 Sekunden).
-
-
-SIEHE AUCH
-==========
-
- reset(), P_NEVER_CLEAN
- memory
-
-21. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/cmd_shoot b/doc/sphinx/man/lfun/cmd_shoot
deleted file mode 100644
index 9cbc9b9..0000000
--- a/doc/sphinx/man/lfun/cmd_shoot
+++ /dev/null
@@ -1,54 +0,0 @@
-
-cmd_shoot()
-***********
-
-
-FUNKTION
-========
-
- static int cmd_shoot(string str)
-
-
-DEFINIERT IN
-============
-
- /std/ranged_weapon.c
-
-
-ARGUMENTE
-=========
-
- string str - Schusssyntax
-
-
-BESCHREIBUNG
-============
-
- Kommandofunktion der Fernwaffe. Enthaelt die Vorbereitung und den Schuss.
-
-
-BEMERKUNGEN
-===========
-
- Ist in der Fernwaffe mit AddCmd( ({"schiess", "schiesse"}), "cmd_shoot");
- angebunden. Will man eine andere Syntax haben, kann man mit
- AddCmd/RemoveCmd diese umsetzen.
-
-
-BEISPIELE
-=========
-
- RemoveCmd(({"schiess", "schiesse"})); // entferne Default-Kommando
- AddCmd(({"schleuder", "schleudere"}), #'cmd_shoot);
-
-
-SIEHE AUCH
-==========
-
- Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
- Methoden: shoot_dam(L), cmd_shoot(L)
- Kommandos: AddCmd(L), RemoveCmd(L)
- Syntax: _unparsed_args(L)
- Sonstiges: fernwaffen
-
-28.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/lfun/command_me b/doc/sphinx/man/lfun/command_me
deleted file mode 100644
index 77a3cc5..0000000
--- a/doc/sphinx/man/lfun/command_me
+++ /dev/null
@@ -1,110 +0,0 @@
-
-command_me()
-************
-
-
-FUNKTION
-========
-
- int command_me(string str)
-
-
-ARGUMENTE
-=========
-
- string str - auszufuehrendes Kommando
-
-
-DEFINIERT IN
-============
-
- /std/npc.c, /std/player/command.c
-
-
-BESCHREIBUNG
-============
-
- Fuehrt 'str' wie ein Kommando aus, welches direkt vom Living
- abgegeben wurde.
-
- Der Rueckgabewert ist >=1 fuer Erfolg und 0 fuer Misserfolg.
- Rueckgabewert ist im Erfolgsfall die Hoehe der EvalCost in Ticks.
-
- command_me() leitet den Befehl an command()(E) weiter und erlaubt
- dadurch auch den Aufruf von sonst durch "static", "protected" oder
- "private" vor externem Aufruf geschuetzten Kommando-Funktionen.
-
- Kommandos mit oeffentlichen Kommandofunktionen (also damit alle mit
- AddCmd definierten Kommandos) koennen auch durch command()(E)
- von aussen ausgeloest werden.
-
-BEMERKUNGEN:
- * beruecksichtigt Aliase, d.h. wenn man Aliase eines Spielers
- ignorieren will, muss man ein \ (fuer ein im Eingabestring) vor
- den Befehl stellen
-
- * fuer objektinterne Kommandos funktioniert also auch
- command()(E)
-
-
-BEISPIEL
-========
-
- (Code des Testraum ist in /doc/beispiele/testobjekte/command_me_testraum)
- // #1: Testraum, zwinge Spieler bei "schleiche heran" zum Furzen
- // command_me() ist hier noetig, da das Furzen eine geschuetzte
- // Kommandofunktion hat
- inherit "/std/room";
-
- void create() {
- ::create();
- AddCmd("schleiche&heran|herum", "action_schleichen");
- }
-
-
-
- void init() {
- ::init();
- add_action("action_kriechen", "kriech", 1);
- }
-
- static int action_schleichen(string str) {
- string tmp = this_player()->QueryProp(P_RACE);
- // ...
- if(tmp[<1]=='e') tmp=tmp[0..<2];
- write(break_string("Du versuchst leise zu schleichen, dabei passiert "
- "dir aber ein allzu "+
- (tmp=="Mensch"?"menschliches":lower_case(tmp)+"isches")+
- " Missgeschick. Verflucht!", 78));
- this_player()->command_me("\\furze");
- return 1;
- }
-
-
-
- static int action_kriechen(string str) {
- write(break_string("Deine Knie tun zu sehr weh dafuer.", 78));
- tell_room(this_object(), break_string(this_player()->Name(WER)+
- " knackt mit den Knien.", 78));
- return 1;
- }
-
-
-
- // #2 (in obigem Raum): zwinge Spieler in Raum zu obigem Kommando
- // Beide Kommandos gelingen, da Kommando mit AddCmd definiert.
- find_player("naddl")->command_me("schleiche herum")
- command("schleiche herum", find_player("naddl"));
-
- // #3 (in obigem Raum): zwinge Spieler in Raum zu obigem Kommando
- find_player("naddl")->command_me("krieche")
- // Folgendes Kommando schlaegt fehl, da Kommandofunktion static ist.
- command("krieche", find_player("naddl"));
-
-
-SIEHE AUCH
-==========
-
- enable_commands(E), command(E)
-
-06 Sep 2012 Gloinson
diff --git a/doc/sphinx/man/lfun/consume b/doc/sphinx/man/lfun/consume
deleted file mode 100644
index f07ece3..0000000
--- a/doc/sphinx/man/lfun/consume
+++ /dev/null
@@ -1,115 +0,0 @@
-
-consume()
-*********
-
-public varargs int consume(mapping cinfo, int testonly)
-
-
-FUNKTION
-========
-
- public varargs int consume(mapping cinfo, int testonly);
-
- Aenderung der Gesundheit eines Lebewesens durch etwas Konsumierbares.
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- cinfo
- Mapping mit Informationen ueber die Gesundheitsaenderung
- Heilung.
- testonly
- Gibt an, ob nur die Bedingungen abgetestet werden sollen,
- oder auch die Wirkung eintreten soll.
-
-
-RUECKGABEWERT
-=============
-
- 1 erfolgreich konsumiert
- 0 keine oder falsche Aenderungsdaten in cinfo (nicht benutzbar)
- <0 Bedingung fuer konsumieren nicht erfuellt, Bitset aus:
- HC_MAX_FOOD_REACHED - Kann nichts mehr essen
- HC_MAX_DRINK_REACHED - Kann nichts mehr trinken
- HC_MAX_ALCOHOL_REACHED - Kann nichts mehr saufen
- HC_HOOK_CANCELLETION - durch H_HOOK_CONSUME abgebrochen
-
-
-BESCHREIBUNG
-============
-
- Die Funktion stellt eine Moeglichkeit zur Verfuegung, die Aenderung
- der Gesundheit eines Lebewesens beim Konsumieren von irgendetwas (z.B in
- einer Kneipe, durch eine Heilstellte oder tragbare Tanke, ...) zentral zu
- erledigen. Sie vereint in sich die Pruefung auf Durchfuerbarkeit der
- Aenderung und Anwendung der Aenderung.
-
- Der erste Parameter gibt die Eigenschaften der Aenderung an, der zweite ob
- ausschliesslich die Pruefung auf Anwendbarkeit erfolgen soll.
-
- Das Mapping cinfo hat folgende Struktur:
- a) Einfache Angabe der betroffenen Properties. In neuem Code bitte nicht
- machen, dort ein Mapping wie unter b) beschrieben nutzen!
-
- b) Strukturiert in Effekte und Bedingungen mit folgenden Schluesseln:
- H_EFFECTS - Mapping der zu aendernden Properties mit dem Umfang der
- Aenderung, erlaubte Properties siehe H_ALLOWED_EFFECTS
-
- H_CONDITIONS - Mapping der zu pruefenden Properties mit dem Umfang der
- Aenderung, erlaubte Properties siehe H_ALLOWED_CONDITIONS
-
- H_DISTRIBUTION - Verteilung der Aenderung fuer P_SP, P_HP
- HD_INSTANT bzw. 0: instante Heilung
- 1 - 50: angebene Zahl pro Heartbeat
- HD_STANDARD: 5 pro Heartbeat
-
- Aenderungen koennen sowohl positiv als auch negativ sein.
-
-
-BEMERKUNGEN
-===========
-
- Hierbei aber bitte beachten, dass Tanken/Entanken sowie Heilungen ggf. von
- der (Heilungs-)Balance genehmigt werden muessen!
-
-
-BEISPIELE
-=========
-
- Heilung um 100 KP, 50 LP, aber nur wenn 30 P_FOOD gegessen werden kann:
-
- consume( ([H_EFFECTS: ([P_HP:50, P_SP:100]),
- H_CONDITIONS: ([P_FOOD:30]) ]) );
-
- Heilung um 100 KP und Vergiftung um 2, wenn 15 Alkohol getrunken werden
- koennen. Die SP werden zeitverzoegert mit 10 pro Heartbeat zugefuehrt.
-
- consume(([H_EFFECTS: ([P_SP: 100, P_POISON: 2]),
- H_CONDITIONS: ([P_ALCOHOL: 15]),
- H_DISTRIBUTION: 10]) )
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: drink_alcohol, eat_food, drink_soft
- Heilung: heal_self, restore_spell_points, restore_hit_points,
- buffer_hp, buffer_sp
- Timing: check_and_update_timed_key
- Enttanken: defuel_drink, defuel_food
- Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-
-LETZTE AeNDERUNG
-================
-
- 29.05.2015, Boing
diff --git a/doc/sphinx/man/lfun/create b/doc/sphinx/man/lfun/create
deleted file mode 100644
index 03fc91a..0000000
--- a/doc/sphinx/man/lfun/create
+++ /dev/null
@@ -1,104 +0,0 @@
-
-create()
-********
-
-
-FUNKTION
-========
-
- protected void create();
- void create();
-
-
-DEFINIERT IN
-============
-
- allen Standardobjekten
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird aufgerufen, wenn ein Objekt geladen oder geclont
- wird.
- In dieser Funktion wird das Objekt initialisiert und konfiguriert.
- Waehrend des create() kann es einen this_player()/this_interactive()
- geben, muss aber nicht!
- Im create() hat das Objekt noch kein environment().
- create() wird nur gerufen, wenn das Objekte geclont oder explizit geladen
- wird. Wenn es aufgrund eines inherit in einem anderen Objekt vom Driver
- geladen wird, wird das create() nicht ausgefuehrt (s. create_super()).
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Erbt man von anderen Objekten, so besteht die erste Aktion innerhalb
- von create() normalerweise darin, in diesen Objekten create()
- aufzurufen.
- Die Funktion kann protected oder static sein (aber nicht private). Es
- duerfte fuer die meisten Objekte sinnvoll sein, create() protected zu
- deklarieren.
-
- Um Speicher zu sparen, kann man bei Blueprints von der Konfigurierung
- absehen (siehe Beispiel). Dies sollte man allerdings nicht bei Objekten
- machen, von denen keine Clones erzeugt werden sollen (zB. bei Raeumen).
-
- Man sollte bei Abbruch des create() in BP unbedingt set_next_reset(-1);
- rufen, da sonst die (nicht konfigurierte) BP resetten kann und dann
- buggt.
-
-
-BEISPIELE
-=========
-
- Ein Gegenstand wuerde wie folgt konfiguriert:
-
- inherit "std/thing";
-
- #include <properties.h>
-
- create()
- {
- // Wenn wir die Blueprint sind: NICHT konfigurieren!
- // Bei normalen Raeumen oder Transportern sind diese beiden
- // Zeilen wegzulassen!!!
- if (!clonep(this_object())) {
- set_next_reset(-1); // wichtig, damit die BP nicht resettet.
- return;
- }
-
- // Ansonsten die allgemeinen Eigenschaften von /std/thing
- // konfigurieren...
- ::create();
-
- // ...und nun unsere speziellen Eigenschaften:
- SetProp(P_NAME, "Muell");
- SetProp(P_SHORT, "Muell");
- SetProp(P_LONG, "Voellig unnuetzer Muell!\n");
- SetProp(P_ARTICLE, 0);
- SetProp(P_VALUE, 0);
- SetProp(P_GENDER, MALE);
- }
-
-
-SIEHE AUCH
-==========
-
- create(L), reset(L)
- hook(C), create(H), create_ob(H), create_super(H, reset(H)
- create(A), reset(A)
-
-22.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/create_default_npc b/doc/sphinx/man/lfun/create_default_npc
deleted file mode 100644
index 09c3a14..0000000
--- a/doc/sphinx/man/lfun/create_default_npc
+++ /dev/null
@@ -1,76 +0,0 @@
-
-create_default_npc()
-********************
-
-
-FUNKTION
-========
-
- varargs void create_default_npc( int level, int maxhp );
-
-
-BENUTZUNG
-=========
-
- inherit "std/npc";
-
-
-FUNKTION
-========
-
- Setze die Daten eines Monsters auf einen gewissen Level.
-
- Der Level sollte zwischen 1 und 20 liegen. Die Stats werden auf diesen
- Level gesetzt und mehrere andere Werte, so dass das Monster von der
- Staerke her einem Spieler gleichen Levels entspricht.
-
- Wird der (optionale) Parameter maxhp weggelassen, wird dieser berechnet
- nach:
- maxhp = 42 + 8 * level
-
- Die genauen Werte sind:
- P_LEVEL : level
- P_MAX_HP: maxhp
- P_MAX_SP: maxhp
- P_HANDS : 10 * level
- P_BODY : (20/3) * level
- P_XP : 50 * level * maxhp (== 5 * P_HANDS * max_hp)
-
- A_STR, A_INT, A_DEX, A_CON : level
-
-
-BEMERKUNG
-=========
-
- Diese Funktion sollte nur im create() eines Monsters benutzt werden.
- Oben beschriebene Werte, die vor dem Aufruf der Funktion gesetzt
- wurden, werden durch die neuen Werte ersetzt.
-
- Ab einem Aufruf mit Level 20 werden P_XP = 202000 gesetzt, also ein
- Kill-Stup vergeben (siehe P_XP).
-
-
-BEISPIEL
-========
-
- create_default_npc(17) ergibt:
-
- P_LEVEL : 17
- P_MAX_HP: 178
- P_MAX_SP: 178
- P_HANDS : 170
- P_BODY : 113
- P_XP : 151300
-
- A_STR, A_INT, A_DEX, A_CON : 17
-
-
-SIEHE AUCH
-==========
-
- Funktionen: AddExp(), GiveKillScore()
- Properties: P_XP
- P_LEVEL, P_MAX_HP, P_MAX_SP, P_HANDS, P_BODY
- Sonstiges: npcs
-
-14.Feb 2007 Gloinson
diff --git a/doc/sphinx/man/lfun/create_super b/doc/sphinx/man/lfun/create_super
deleted file mode 100644
index 101531f..0000000
--- a/doc/sphinx/man/lfun/create_super
+++ /dev/null
@@ -1,75 +0,0 @@
-
-create_super()
-**************
-
-
-FUNKTION
-========
-
- protected void create_super();
-
-
-DEFINIERT IN
-============
-
- allen Standardobjekten
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird immer dann aufgerufen, wenn ein Objekt implizit durch
- ein 'inherit' in einem erbenden Objekte geladen wird.
- Normalweise muss man dieses so geladene Objekte nicht konfigurieren, weil
- nur das Programm dieses Objektes fuer die erbenden Objekte interessant
- ist, nicht seine Daten.
- Was hier aber z.B. sinnvoll ist, ist das Abschalten des Resets, denn ein
- Objekt, was nur dazu dient, dass es von anderen geerbt wird, braucht
- keinen Reset, auch wenn es ein reset() definiert (was in erbenden Objekte
- benutzt wird).
- Die create_super() in den Standardobjekten tun momentan genau dieses.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Wenn ihr von /std/ erbt, braucht ihr euch in aller Regel um diese
- Funktion keine Gedanken machen.
- Ihr koennt diese Funktion aber in Objekten selber definieren, die nur zum
- Erben gedacht sind. Dies kann sinnvoll ein, wenn ihr nicht von /std/ erbt
- und ein reset() im Objekt habt oder was machen wollt, was ueber das
- Abschalten des Resets hinausgeht.
-
-
-BEISPIELE
-=========
-
- Gegeben sei folgende Vererbungskette:
- /std/room -> /d/inseln/zesstra/stdraum -> /d/inseln/zesstra/raum
-
- Wird nun 'raum' geladen und 'stdraum' ist noch nicht geladen, wird der
- Driver implizit von selbst 'stdraum' laden (weil 'raum' das Programm von
- 'stdraum' braucht). Bei diesem Laden wird das create() in 'stdraum' nicht
- ausgefuehrt, sondern stattdessen create_super().
-
-
-SIEHE AUCH
-==========
-
- create(L), reset(L)
- hook(C), create(H), create_ob(H), create_super(H, reset(H)
- create(A), reset(A)
-
-22.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/defuel_drink b/doc/sphinx/man/lfun/defuel_drink
deleted file mode 100644
index 266907e..0000000
--- a/doc/sphinx/man/lfun/defuel_drink
+++ /dev/null
@@ -1,87 +0,0 @@
-
-defuel_drink()
-**************
-
-
-FUNKTION
-========
-
- int defuel_drink();
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- Keine.
-
-
-BESCHREIBUNG
-============
-
- Enttankt den Spieler automatisch um einen gewissen Fluessigkeits-Wert,
- sofern der Spieler ueber einer bestimmten Enttank-Grenze liegt und seit
- seinem letzten Enttanken eine gewisse Zeit vergangen ist.
- Alle diese Werte sind rassenabhaengig.
- Ausserdem wird dem Spieler eine gewisse Menge Alkohol entzogen. Er wird
- also mit jedem fluessigen Enttanken etwas nuechterner.
-
- Es ist also NICHT moeglich, Einfluss auf die Menge des Enttankens
- zu nehmen. Das ist hier so gewollt.
-
- Hat der Spieler mindestens
- * P_DEFUEL_LIMIT_DRINK in P_DRINK
- kann er alle
- * P_DEFUEL_TIME_DRINK
- um
- * (x=P_DRINK*P_DEFUEL_AMOUNT_DRINK/2) + random(x)
- (also um (50 bis 100 * P_DRINK) Prozent)
- enttanken.
-
-
-RUECKGABEWERTE
-==============
-
- DEFUEL_TOO_SOON: -2, wenn Enttankintervallzeiten zu kurz.
- DEFUEL_TOO_LOW: -1, wenn Enttankgrenze noch nicht erreicht.
- NO_DEFUEL: 0, wenn Enttanken nicht noetig war (Spieler war leer)
- >0, wenn Erfolg (enttankte Wert wird zurueckgegeben).
-
- (Konstanten kommen aus /sys/defuel.h)
-
-
-BEMERKUNG
-=========
-
- Bitte defuel_drink() benutzen und nicht P_DRINK oder P_MAX_DRINK des
- manipulieren!
-
- Es gibt keine eigene Methode fuer die Verringerung von P_ALCOHOL.
-
- Achtung: Nur Toiletten sollten diese Funktion im Spieler aufrufen!
-
-
-BEISPIEL
-========
-
- s. Bsp. zu defuel_food()
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: defuel_food
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Heilung: heal_self, restore_spell_points, restore_hit_points,
- buffer_hp, buffer_sp
- Timing: check_and_update_timed_key
- Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/defuel_food b/doc/sphinx/man/lfun/defuel_food
deleted file mode 100644
index 380c2bc..0000000
--- a/doc/sphinx/man/lfun/defuel_food
+++ /dev/null
@@ -1,113 +0,0 @@
-
-defuel_food()
-*************
-
-
-FUNKTION
-========
-
- int defuel_food();
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- Keine.
-
-
-BESCHREIBUNG
-============
-
- Enttankt den Spieler automatisch um einen gewissen Essens-Wert,
- sofern der Spieler ueber einer bestimmten Enttank-Grenze liegt und seit
- seinem letzten Enttanken eine gewisse Zeit vergangen ist.
- Alle diese Werte sind rassenabhaengig.
-
- Es ist also NICHT moeglich, Einfluss auf die Menge des Enttankens
- zu nehmen. Das ist hier so gewollt.
-
- Hat der Spieler mindestens
- * P_DEFUEL_LIMIT_FOOD in P_FOOD
- kann er alle
- * P_DEFUEL_TIME_FOOD
- um
- * (x=P_DRINK*P_DEFUEL_AMOUNT_FOOD/2) + random(x)
- (also um (50 bis 100 * P_FOOD) Prozent)
- enttanken.
-
-
-RUECKGABEWERTE
-==============
-
- DEFUEL_TOO_SOON: -2, wenn Enttankintervallzeiten zu kurz.
- DEFUEL_TOO_LOW: -1, wenn Enttankgrenze noch nicht erreicht.
- NO_DEFUEL: 0, wenn Enttanken nicht noetig war (Spieler war leer)
- >0, wenn Erfolg (enttankte Wert wird zurueckgegeben).
-
- (Konstanten kommen aus /sys/defuel.h)
-
-
-BEMERKUNG
-=========
-
- Bitte defuel_food() benutzen und nicht P_FOOD oder P_MAX_FOOD des
- Spielers manipulieren!
-
- Achtung: Nur Toiletten sollten diese Funktion im Spieler aufrufen!
-
-
-BEISPIEL
-========
-
- int action_enttanken() {
- string msg;
- int val = this_player()->defuel_food();
-
- switch (val) {
- case DEFUEL_TOO_SOON:
- msg = "Du warst doch erst vor kurzem auf Toilette...";
- break;
- case DEFUEL_TOO_LOW:
- msg = "Du versuchst Dich zu entleeren, aber irgendwie will "
- "das nicht so recht klappen.";
- break;
- case NO_DEFUEL:
- msg = "Du hast seit langem nichts gegessen, wie willst Du dann "
- "was loswerden koennen?";
- break;
- default:
- string qualifier;
- int fuzzypercent = (90+random(20)) *
- val/this_player()->QueryProp(P_MAX_FOOD);
- switch(fuzzypercent) {
- case 0..50: qualifier = "etwas"; break;
- case 51..75: qualifier = "enorm"; break;
- default: qualifier = "unglaublich"; break;
- }
- msg = "Du entleerst Dich "+qualifier"+. Puh, das tat gut!";
- break;
- }
- tell_object(this_player(), break_string(msg, 78));
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: defuel_drink
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Heilung: heal_self, restore_spell_points, restore_hit_points,
- buffer_hp, buffer_sp
- Timing: check_and_update_timed_key
- Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/deregister_modifier b/doc/sphinx/man/lfun/deregister_modifier
deleted file mode 100644
index eb0c160..0000000
--- a/doc/sphinx/man/lfun/deregister_modifier
+++ /dev/null
@@ -1,42 +0,0 @@
-
-deregister_modifier()
-*********************
-
-
-FUNKTION
-========
-
- void deregister_modifier(object modifier)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-PARAMETER
-=========
-
- modifier - Objekt mit P_X_ATTR_MOD oder P_M_ATTR_MOD
-
-
-BESCHREIBUNG
-============
-
- Meldet einen Modifier im Spieler ab. Wird durch RemoveSensitiveObject
- beziehungsweise beim Ausziehen oder Wegstecken gerufen.
- Muss nicht direkt gerufen werden. Bei Veraenderungen von Modifikatoren
- sollte stattdessen UpdateAttributes gerufen werden.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- register_modifier(),P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
- P_ATTRIBUTES_MODIFIER, P_X_ATTR_MOD, P_M_ATTR_MOD,
- /std/living/attributes.c
-
-13.Jun.2004, Muadib
diff --git a/doc/sphinx/man/lfun/die b/doc/sphinx/man/lfun/die
deleted file mode 100644
index a76a1aa..0000000
--- a/doc/sphinx/man/lfun/die
+++ /dev/null
@@ -1,67 +0,0 @@
-
-die()
-*****
-
-
-FUNKTION
-========
-
- public varargs void die(int poisondeath,int extern);
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- int poisondeath
- Dieses Flag sollte bei einem Gifttod (P_POISON) gesetzt sein.
- int extern
- Intern.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen stirbt, meist automatisch von do_damage() ausgeloest, wenn
- 0 HP unterschritten werden. In diesem Fall wird der Kampf beendet, Gift,
- Alkohol, Trink- und Esswerte, Blindheit, Taubheit u.s.w. auf Null
- gesetzt oder geloescht.
-
- Es wird automatisch eine Leiche (siehe auch P_CORPSE, P_NOCORPSE) nebst
- Todesmeldungen (siehe auch P_DIE_MSG) erzeugt, und fuer Spieler werden
- Killstupse vergeben, sofern notwendig.
-
- Ueber den Hook P_TMP_DIE_HOOK kann man jedoch auf den Automatismus
- Einfluss nehmen, z.B. koennte ein temporaerer Todesbann-Zauber das
- Sterben fuer kurze Zeit verhindern.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion sollte nur selten direkt verwendet werden. Meist ist der
- uebliche Weg ueber Defend() -> do_damage() -> die() die logisch bessere
- und balancetechnisch guenstigere Loesung.
-
-
-SIEHE AUCH
-==========
-
- Todesursachen: Defend(L), do_damage(L), P_POISON
- Verwandt: P_TMP_DIE_HOOK, P_DEADS
- Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_MURDER_MSG, P_DIE_MSG
- P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /std/corpse.c
-
-Last modified: Mon May 14 16:20:34 2001 by Patryn
diff --git a/doc/sphinx/man/lfun/doUnwearMessage b/doc/sphinx/man/lfun/doUnwearMessage
deleted file mode 100644
index b6128ce..0000000
--- a/doc/sphinx/man/lfun/doUnwearMessage
+++ /dev/null
@@ -1,46 +0,0 @@
-
-doUnwearMessage()
-*****************
-
-
-FUNKTION
-========
-
- void doUnwearMessage(object worn_by, int all);
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c
-
-
-ARGUMENTE
-=========
-
- worn_by
- Das Lebewesen, dass die Ruestung bisher getragen hat
- all
- Wurde "ziehe alles aus"/"ziehe alle ruestungen aus" eingegeben,
- so ist all gesetzt, ansonsten nicht.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt beim Ausziehen einer Ruestung die entspr.
- Meldung an den Traeger und die Umgebung aus.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- doWearMessage(), doWieldMessage(), doUnwieldMessage()
-
-Last modified: Sat Jun 26 15:41:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/lfun/doUnwieldMessage b/doc/sphinx/man/lfun/doUnwieldMessage
deleted file mode 100644
index f2245b6..0000000
--- a/doc/sphinx/man/lfun/doUnwieldMessage
+++ /dev/null
@@ -1,43 +0,0 @@
-
-doUnwieldMessage()
-******************
-
-
-FUNKTION
-========
-
- void doUnwieldMessage(object wielded_by);
-
-
-DEFINIERT IN
-============
-
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- wielded_by
- Das Lebewesen, dass die (Parier)Waffe bisher gezueckt hatte.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt beim Wegstecken einer Waffe die entspr.
- Meldung an den Benutzer und die Umgebung aus.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- doWearMessage(), doUnwearMessage(), doWieldMessage()
-
-Last modified: Sat Jun 26 15:32:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/lfun/doWearMessage b/doc/sphinx/man/lfun/doWearMessage
deleted file mode 100644
index 6770180..0000000
--- a/doc/sphinx/man/lfun/doWearMessage
+++ /dev/null
@@ -1,44 +0,0 @@
-
-doWearMessage()
-***************
-
-
-FUNKTION
-========
-
- varargs void doWearMessage(int all);
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c
-
-
-ARGUMENTE
-=========
-
- all
- Wurde "trage alles"/"trage alle ruestungen" eingegeben, so
- ist all gesetzt, ansonsten nicht.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt beim Anziehen einer Ruestung die entspr.
- Meldung an den Traeger und die Umgebung aus.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- doUnwearMessage(), doWieldMessage(), doUnwieldMessage()
-
-Last modified: Sat Jun 26 15:30:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/lfun/doWieldMessage b/doc/sphinx/man/lfun/doWieldMessage
deleted file mode 100644
index a3b737f..0000000
--- a/doc/sphinx/man/lfun/doWieldMessage
+++ /dev/null
@@ -1,42 +0,0 @@
-
-doWieldMessage()
-****************
-
-
-FUNKTION
-========
-
- void doWieldMessage();
-
-
-DEFINIERT IN
-============
-
- /std/weapon/combat.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt beim Zuecken einer Waffe die entspr.
- Meldung an den Benutzer und die Umgebung aus.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- doWearMessage(), doUnwearMessage(), doUnwieldMessage()
-
-Last modified: Sat Jun 26 15:33:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/lfun/do_damage b/doc/sphinx/man/lfun/do_damage
deleted file mode 100644
index 91c6bc8..0000000
--- a/doc/sphinx/man/lfun/do_damage
+++ /dev/null
@@ -1,70 +0,0 @@
-
-do_damage()
-***********
-
-do_damage(L)
-
-
-FUNKTION
-========
-
- int do_damage(int dam,mixed enemy);
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- int dam
- Die abzuziehenden Lebenspunkte (HP).
- object enemy
- Das Objekt, welches den Schaden zufuegt.
-
-
-BESCHREIBUNG
-============
-
- Dem Lebewesen werden <dam> HP abgezogen. Falls weniger als 0 HP uebrig
- bleiben, so stirbt es automatisch mittels die().
- Ein Lebewesen, welches sich bewegt hat, trifft die ersten Kampfrunden
- sehr viel schlechter, um Rein-Raus-Attacken zu verhindern. Dieses
- Vorgehen kann man mittels P_ENABLE_IN_ATTACK_OUT deaktivieren.
- Lebewesen, welche P_NO_ATTACK gesetzt haben, kann man mit dieser
- Funktion nicht schaden.
-
-
-RUeCKGABEWERT
-=============
-
- Der tatsaechlich verursachte Schaden.
-
-
-BEMERKUNGEN
-===========
-
- Beim Gegner <enemy>, falls vorhanden, werden XP und ALIGN entsprechend
- angepasst, im Opfer wird der Gegner in P_KILLER vermerkt, der Kampf wird
- beendet.
- Diese Funktion sollte nur selten direkt verwendet werden. Meist ist der
- uebliche Weg ueber Defend() -> do_damage() -> die() die logisch bessere
- und balancetechnisch guenstigere Loesung, da Defend() magische
- Verteidigungen, die der Spieler bei sich hat beruecksichtigt.
- Es sollte also allein schon aus Fairness gegenueber den Objekten
- anderer Magier Defend() immer dem direkten reduce_hit_points() oder
- do_damage() vorgezogen werden. Mittels der Flags in 'spell' kann man
- sehr viele Parameter beeinflussen.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: Defend(L), reduce_hit_points(L), die(L)
- Props: P_NO_ATTACK, P_ENABLE_IN_ATTACK_OUT, P_KILLER
- P_XP, P_ALIGN
-
-23.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/lfun/do_frage b/doc/sphinx/man/lfun/do_frage
deleted file mode 100644
index 6c848b8..0000000
--- a/doc/sphinx/man/lfun/do_frage
+++ /dev/null
@@ -1,42 +0,0 @@
-
-do_frage()
-**********
-
-
-FUNKTION
-========
-
- int do_frage(string text)
-
-
-DEFINIERT IN
-============
-
- /std/npc/info.c
-
-
-ARGUMENTE
-=========
-
- string str - Schluesselwort der Frage
-
-
-BESCHREIBUNG
-============
-
- Bearbeitet ein Schluesselwort, das mit "frage <wen> nach " uebergeben
- wurde. Gibt entsprechende Antworten formatiert aus.
-
-
-BEMERKUNGEN
-===========
-
- Recht komplex, besser nicht ueberschreiben wenn man es nicht versteht.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: GetInfoArr, AddInfo
-
-31.Mar 2007 Gloinson
diff --git a/doc/sphinx/man/lfun/do_unwear b/doc/sphinx/man/lfun/do_unwear
deleted file mode 100644
index dd91478..0000000
--- a/doc/sphinx/man/lfun/do_unwear
+++ /dev/null
@@ -1,56 +0,0 @@
-
-do_unwear()
-***********
-
-
-FUNKTION
-========
-
- varargs int do_unwear(string str, int silent);
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c
-
-
-ARGUMENTE
-=========
-
- str
- String der normalerweise dem Parameter des "ziehe"-Kommandos
- entspricht.
-
- silent
- 1, wenn das Ausziehen ohne Meldungen durchgefuehrt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion stellt fest, ob die Ruestung sich durch str
- identifizieren laesst und angezogen ist und ruft im Erfolgsfall
- UnWear(silent) auf.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn alles gut ging, ansonsten 0.
-
-
-BEMERKUNGEN
-===========
-
- Wenn man Ruestungen "von aussen" ausziehen will, sollte man direkt
- UnWear() verwenden!
-
-
-SIEHE AUCH
-==========
-
- do_wear(), UnWear(), RemoveFunc(), InformUnwear(),
- /std/armour/combat.c
-
-Last modified: Sun Jun 27 22:29:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/lfun/do_wear b/doc/sphinx/man/lfun/do_wear
deleted file mode 100644
index abf7051..0000000
--- a/doc/sphinx/man/lfun/do_wear
+++ /dev/null
@@ -1,46 +0,0 @@
-
-do_wear()
-*********
-
-
-FUNKTION
-========
-
- varargs int do_wear(string str, int silent);
-
-
-DEFINIERT IN
-============
-
- /std/armour/combat.c
-
-
-ARGUMENTE
-=========
-
- str
- String, der normalerweise dem Parameter des
- "ziehe/trage"-Kommandos entspricht.
- silent
- 1, wenn das Anziehen ohne Meldungen durchgefuehrt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Wenn sich die Ruestung mit "str" identifizieren laesst, wird versucht,
- sie mittels DoWear() anzuziehen.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn sich die Ruestung anziehen liess, sonst 0.
-
-
-SIEHE AUCH
-==========
-
- do_unwear(), DoWear(), WearFunc(), InformWear(), /std/armour/combat.c
-
-Last modified: Sun Jun 27 22:31:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/lfun/drink_alcohol b/doc/sphinx/man/lfun/drink_alcohol
deleted file mode 100644
index 01d0a77..0000000
--- a/doc/sphinx/man/lfun/drink_alcohol
+++ /dev/null
@@ -1,112 +0,0 @@
-
-drink_alcohol()
-***************
-
-
-FUNKTION
-========
-
- public varargs int drink_alcohol(int strength, int testonly, string mytext)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- strength: wird zur aktuellen Saettigung P_ALCOHOL dazu addiert
- testonly: Ist das Flag gesetzt, wird dem Spieler kein ALCOHOL zugefuehrt.
- Darf nur zum Testen der Heilstelle verwendet werden und muss
- im normalen Betrieb auf '0' stehen!
- mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
- darf sich hier was nettes ausdenken.
- Achtung: Das unterdrueckt nicht die "Nuechtern"-Meldung, die bei
- negativem strength auftreten kann, wenn P_ALCOHOL wieder 0 ist.
-
-
-BESCHREIBUNG
-============
-
- Es wird geprueft, ob dem Spieler der angegebene Wert fuer 'strength'
- auf seine aktuelle P_ALCOHOL addiert werden kann oder nicht. Falls
- das moeglich ist und testonly = 0, wird P_ALCOHOL entsprechend
- aktualisiert.
-
- Sollen neben P_ALCOHOL noch weitere Props manipuliert werden - bspw. zur
- Heilung eines Lebewesens - bietet sich die Funktion consume() an.
-
-
-RUECKGABEWERT
-=============
-
- 0 bei [potentiellem] Misserfolg (strength + P_ALCOHOL > P_MAX_ALCOHOL)
- 1 bei [potentiellem] Erfolg
- * potentiell bezieht sich hier auf Nutzung mit 'testonly' != 0
-
-
-BEMERKUNG
-=========
-
- drink_alocohol() bitte anstatt eigener Manipulationen von P_ALCOHOL und
- P_MAX_ALCOHOL verwenden.
-
- Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
-
- Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
- dafuer eingerichteten Funktion check_and_update_timed_key realisiert
- werden.
-
-
-BEISPIEL
-========
-
- int heilstelle() {
- if(this_player()->drink_alcohol(10, 0,
- "Du prustest in den Schnaps. "
- "Der passt nicht mehr rein.\n")) {
- // Platz fuer 10 "Alkohol" war noch, diese sind jetzt bereits addiert
- // Nachricht an den Spieler:
- tell_object(this_player(),
- break_string("Du trinkst den Schnaps aus.", 78));
-
- // Nachricht an andere Livings im Raum
- object ob = first_inventory(environment(this_player()));
- do {
- if(living(ob) && ob!=this_player())
- ob->ReceiveMsg(this_player()->Name()+" trinkt einen Schnaps aus.",
- MT_LOOK|MT_LISTEN,
- MA_DRINK);
- ob = next_inventory(ob);
- } while(ob);
-
- // Rassenabhaengige Heilung: Sofort oder in Schritten
- // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
- if(this_player()->QueryProp(P_REAL_RACE)=="Schnapsdrossel")
- this_player()->heal_self(30);
- else {
- this_player()->buffer_hp(30,5);
- this_player()->buffer_sp(30,5);
- }
- }
-
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: consume, eat_food, drink_soft
- Heilung: heal_self, restore_spell_points, restore_hit_points,
- buffer_hp, buffer_sp
- Timing: check_and_update_timed_key
- Enttanken: defuel_drink, defuel_food
- Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/drink_soft b/doc/sphinx/man/lfun/drink_soft
deleted file mode 100644
index 0f030f6..0000000
--- a/doc/sphinx/man/lfun/drink_soft
+++ /dev/null
@@ -1,111 +0,0 @@
-
-drink_soft()
-************
-
-
-FUNKTION
-========
-
- public varargs int drink_soft(int strength, int testonly, string mytext)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- strength: Wird zu dem augenblicklichen Saettigungsgrad (P_DRINK) addiert.
- testonly: Ist das Flag gesetzt, wird dem Spieler kein DRINK zugefuehrt.
- Darf nur zum Testen der Heilstelle verwendet werden und muss
- im normalen Betrieb auf '0' stehen!
- mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
- darf sich hier was nettes ausdenken.
- Achtung: Das unterdrueckt nicht die "Durst"-Meldung, die bei
- negativem strength auftritt, wenn P_DRINK wieder 0 ist.
-
-
-BESCHREIBUNG
-============
-
- Es wird geprueft, ob dem Spieler der angebene Wert "strength" auf
- aktuelle P_DRINK addiert werden kann oder nicht. Ist dies moeglich,
- wird es gemacht, es sei denn das testonly != 0.
-
- Sollen neben P_DRINK noch weitere Props manipuliert werden - bspw. zur
- Heilung eines Lebewesens - bietet sich die Funktion consume() an.
-
-
-RUECKGABEWERT
-=============
-
- 0, wenn strength + P_DRINK > P_MAX_DRINK
- >0, wenn Erfolg
-
-
-BEMERKUNG
-=========
-
- drink_soft() bitte anstatt eigener Manipulationen von P_DRINK und
- P_MAX_DRINK verwenden.
-
- Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
-
- Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
- dafuer eingerichteten Funktion check_and_update_timed_key realisiert
- werden.
-
-
-BEISPIEL
-========
-
- int heilstelle() {
- if(this_player()->drink_soft(10, 0, "Du blubberst nicht ueberzeugt "
- "in der Limonade. Das ist zu viel.\n")) {
- // Platz fuer 10 "Trinken" war noch, diese sind jetzt bereits addiert
- // Nachricht an den Spieler:
- tell_object(this_player(), break_string("Du nimmst einen grossen "
- "Schluck zuckersuesse Limonade.", 78));
-
- // alle anderen im Raum bekommen es ggf auch mit:
- // 1) filter(..., #'living) ergibt die Lebewesen im Raum
- // 2) filter_objects(..., "ReceiveMsg") ruft ReceiveMsg an jedem
- // 3) ReceiveMsg(...) bekommt die Folgeparameter
- filter_objects(filter(all_inventory(environment(this_player())),
- #'living) - ({this_player()}),
- "ReceiveMsg",
- this_player()->Name()+
- " trinkt einen Schluck Limonade.",
- MT_LOOK|MT_LISTEN,
- MA_DRINK);
-
- // Rassenabhaengige Heilung: Sofort oder in Schritten
- // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
- if(this_player()->QueryProp(P_REAL_RACE)=="Saufziege")
- this_player()->heal_self(30);
- else {
- this_player()->buffer_hp(30,5);
- this_player()->buffer_sp(30,5);
- }
- }
-
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: consume, drink_alcohol, eat_food
- Heilung: heal_self, restore_spell_points, restore_hit_points,
- buffer_hp, buffer_sp
- Timing: check_and_update_timed_key
- Enttanken: defuel_drink, defuel_food
- Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/drop b/doc/sphinx/man/lfun/drop
deleted file mode 100644
index cdd372b..0000000
--- a/doc/sphinx/man/lfun/drop
+++ /dev/null
@@ -1,70 +0,0 @@
-
-drop()
-******
-
-
-FUNKTION
-========
-
- public varargs int drop(object o, mixed msg);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- object o
- Das Objekt, das fallengelassen werden soll.
- mixed msg
- Eine optionale Meldung, die anstelle von P_DROP_MSG oder der
- Standardmeldung verwendet wird, oder -1, um die Meldung zu
- unterdruecken.
-
-
-BESCHREIBUNG
-============
-
- Der Spieler oder NPC laesst das Objekt fallen. Gibt o->move() keinen
- positiven Wert zurueck, beispielsweise weil das Objekt verflucht ist,
- bekommt er eine entsprechende Fehlermeldung.
-
-
-RUECKGABEWERT
-=============
-
- Wenn das Fallenlassen geklappt hat, 1, ansonsten 0.
-
-
-BEMERKUNG
-=========
-
- Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
- fallenlassen lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
- moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
- manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
-
- Die Funktion prueft nicht, ob der Spieler/NPC das Objekt ueberhaupt hat,
- das muss man ggf. selbst ermitteln.
-
-
-BEISPIEL
-========
-
- if (this_player()->drop(obj, ({
- "Du wirfst @WEN2 in den Saeureteich.\n",
- "@WER1 wirft @WENU2 in den Saeureteich.\n" })))
- obj->remove();
-
-
-SIEHE AUCH
-==========
-
- move(L), P_DROP_MSG, drop_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
- P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NODROP
-
-Last modified: Thu Aug 28 22:20:37 2008 by Amynthor
diff --git a/doc/sphinx/man/lfun/drop_obj b/doc/sphinx/man/lfun/drop_obj
deleted file mode 100644
index 3e1057f..0000000
--- a/doc/sphinx/man/lfun/drop_obj
+++ /dev/null
@@ -1,44 +0,0 @@
-
-drop_obj()
-**********
-
-
-FUNKTION
-========
-
- int drop_obj(object ob);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- ob Das Objekt, das von dem Lebewesen, in dem diese Funktion aufgerufen
- wird, fallengelassen werden soll.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion aufgerufen werden soll, laesst
- den angegebenen Gegenstand fallen, wenn dies moeglich ist.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Objekt fallen gelassen wurde oder dies nicht moeglich war.
- (in diesem Fall wird auch direkt eine Textausgabe ausgegeben)
- 0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
- plaziert.
-
-
-SIEHE AUCH
-==========
-
- find_obs(), give_obj(), pick_obj(), put_obj(), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/lfun/drop_objects b/doc/sphinx/man/lfun/drop_objects
deleted file mode 100644
index 93cbee5..0000000
--- a/doc/sphinx/man/lfun/drop_objects
+++ /dev/null
@@ -1,73 +0,0 @@
-
-drop_objects()
-**************
-
-
-FUNKTION
-========
-
- public varargs int drop_objects(string str, mixed msg);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- string str
- Was fallengelassen werden soll.
- mixed msg
- Eine optionale Meldung, die anstelle von P_DROP_MSG oder der
- Standardmeldung verwendet wird, oder -1, um die Meldung zu
- unterdruecken.
-
-
-BESCHREIBUNG
-============
-
- Der Spieler oder NPC laesst die in <str> benannten Sachen fallen.
- Kann er ein Objekt nicht fallenlassen, bekommt er eine entsprechende
- Fehlermeldung. Wenn keine Objekte auf <str> passen, wird per
- _notify_fail() eine Meldung gesetzt, aber noch nicht ausgegeben.
-
-
-RUECKGABEWERT
-=============
-
- Wenn <str> irgendwelche vorhandenen Sachen sind, 1, sonst 0.
-
-
-BEMERKUNG
-=========
-
- Wenn die Funktion 1 zurueckgibt, heisst das noch nicht, dass der Spieler
- etwas fallengelassen hat! Er hat es nur versucht, d.h. auf jeden Fall eine
- Meldung bekommen. Gibt die Funktion 0 zurueck, hat er noch keine bekommen.
-
-
-BEISPIEL
-========
-
- private int cmd_opfern(string str)
- {
- notify_fail("WAS moechtest Du opfern?\n");
-
- if (!this_player()->drop_objects(str, ({ "Du opferst @WEN2.",
- "@WER1 opfert @WENU2.\n" })))
- return 0;
-
- filter_objects(this_player()->moved_objects(), "remove");
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- move(L), drop(L), P_DROP_MSG, find_objects(L), moved_objects(L)
-
-Last modified: Fri Jul 25 10:59:37 2008 by Amynthor
diff --git a/doc/sphinx/man/lfun/eat_food b/doc/sphinx/man/lfun/eat_food
deleted file mode 100644
index 32327e2..0000000
--- a/doc/sphinx/man/lfun/eat_food
+++ /dev/null
@@ -1,114 +0,0 @@
-
-eat_food()
-**********
-
-
-FUNKTION
-========
-
- public varargs int eat_food(int food, int testonly, string mytext)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- food: Wird zu dem augenblicklichen Saettigungsgrad (P_FOOD) addiert.
- testonly: Ist das Flag gesetzt, wird dem Spieler kein FOOD zugefuehrt.
- Darf nur zum Testen der Heilstelle verwendet werden und muss
- im normalen Betrieb auf '0' stehen!
- mytext: Wer selber einen Text bei Misserfolg ausgeben lassen moechte,
- darf sich hier was nettes ausdenken.
- Achtung: Das unterdrueckt nicht die "Hunger"-Meldung, die bei
- negativem food auftreten kann, wenn P_FOOD wieder 0 ist.
-
-
-BESCHREIBUNG
-============
-
- Es wird geprueft, ob dem Spieler der angebene Wert "strength" auf seine
- aktuelle P_FOOD addiert werden kann oder nicht. Ist dies moeglich, wird
- wird es gemacht, es sei denn das testonly != 0.
-
- Sollen neben P_FOOD noch weitere Props manipuliert werden - bspw. zur
- Heilung eines Lebewesens - bietet sich die Funktion consume() an.
-
-
-RUECKGABEWERT
-=============
-
- 0, wenn strength + P_FOOD > P_MAX_FOOD.
- >0, wenn Erfolg.
-
-
-BEMERKUNG
-=========
-
- eat_food() bitte anstatt eigener Manipulationen von P_FOOD und
- P_MAX_FOOD verwenden.
-
- Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
-
- Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
- dafuer eingerichteten Funktion check_and_update_timed_key realisiert
- werden.
-
-
-BEISPIEL
-========
-
- int heilstelle() {
- // Wenn auf das P_FOOD des Spielers die angegebenen 10 nicht mehr addiert
- // addiert werden koennen (weil sonst P_MAX_FOOD ueberschritten wird),
- // wird die Fehlermeldung ausgegeben, dass der Spieler nichts mehr
- // essen/trinken kann.
- // Bei gesetztem 'mytext' wird 'mytext' an den Spieler ausgegeben.
- // Ansonsten wird die Standardmeldung ausgegeben.
- if (!this_player()->eat_food(10, 0, "Der Keks ist einfach "
- "zuviel fuer Dich.\n") )
- return 1;
-
- // Spieler hatte noch ausreichend Spielraum bei P_FOOD. Die 10 sind
- // schon addiert worden. Jetzt Nachricht ausgeben:
- tell_object(this_player(), break_string("Du knabberst ein bisschen an "
- "dem Keks herum und fuehlst Dich gleich viel besser.", 78));
-
- // alle Lebewesen im Raum bekommen das auch mit
- foreach(object ob:
- (filter(all_inventory(environment(this_player())), #'living) -
- ({this_player()})))
- ob->ReceiveMsg(this_player()->Name()+" knuspert einen Keks weg.",
- MT_LOOK|MT_LISTEN,
- MA_EAT);
-
- // Rassenabhaengige Heilung: Sofort oder in Schritten
- // Tragbare Heilungen sollten auch eher buffer_hp/_sp benutzen.
- if(this_player()->QueryProp(P_REAL_RACE)=="Kruemelmonster")
- this_player()->heal_self(30);
- else {
- this_player()->buffer_hp(30,5);
- this_player()->buffer_sp(30,5);
- }
-
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: consume, drink_alcohol, drink_soft
- Heilung: heal_self, restore_spell_points, restore_hit_points,
- buffer_hp, buffer_sp
- Timing: check_and_update_timed_key
- Enttanken: defuel_drink, defuel_food
- Props: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/execute_anything b/doc/sphinx/man/lfun/execute_anything
deleted file mode 100644
index 39ec45a..0000000
--- a/doc/sphinx/man/lfun/execute_anything
+++ /dev/null
@@ -1,64 +0,0 @@
-
-execute_anything()
-******************
-
-
-FUNKTION
-========
-
- protected mixed execute_anything(mixed fun, mixed args, ...)
-
-
-DEFINIERT IN
-============
-
- /std/util/executer.c
-
-
-ARGUMENTE
-=========
-
- mixed fun auszufuehrende Funktion/Array/Closure ... anything
- mixed args weitere Argumente, werden weiter uebergeben
-
-
-BESCHREIBUNG
-============
-
- Fuehrt "alles" aus:
-
-
-
- 'fun' kann sein:
- - eine Closure
- [funcall(fun, args, ...)]
- - einen String als Funktion im Objekt
- [call_other(this_object(), fun, args, ...)]
- - ein Array mit Objekt/Objektnamen + Funktion als Aufruf der Funktion am
- Objekt/Objektnamen:
- [call_other(array[0], array[1], args...)]
-
- Wird execute_anything() aus dem restriction_checker gerufen, wird als
- erster Parameter immer das gepruefte Living uebergeben.
-
-
-BEMERKUNGEN
-===========
-
- Es kann sich anbieten, die gerufene Funktion mit varargs-Argumenten zu
- gestalten, damit ihr mehr Argumente uebergeben werden koennen als in der
- Funktionsdefinition angegeben sind.
-
- Der Restriktionspruefer (/std/restriction_checker) versteht im Falle eines
- Arrays mit Objekt/Objektnamen + Funktion auch ein Array mit mehr als 2
- Elementen. Die weiteren Elemente werden dann zu weiteren Argumenten der
- gerufenen Funktion. Hierbei wird <pl> ggf. aber als erstes Argument vor
- alle anderen eingefuegt.
-
-
-SIEHE AUCH
-==========
-
- check_restrictions, varargs
-
-31.12.2013, Zesstra
diff --git a/doc/sphinx/man/lfun/exit b/doc/sphinx/man/lfun/exit
deleted file mode 100644
index f2d0b00..0000000
--- a/doc/sphinx/man/lfun/exit
+++ /dev/null
@@ -1,56 +0,0 @@
-
-exit()
-******
-
-
-FUNKTION
-========
-
- varargs void exit(object liv, object dest);
-
-
-DEFINIERT IN
-============
-
- /std/room/description.c
-
-
-ARGUMENTE
-=========
-
- liv - (object) Das bewegte Lebewesen.
- dest - (object) Das Environment, in welches bewegt wird.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird immer dann aufgerufen, wenn ein Lebewesen den
- Raum verlaesst. Standardmaessig werden hier ggf. die Raummeldungen
- abgestellt, man kann aber auch eigene Checks einhaengen. In dem Fall MUSS
- man aber das geerbte exit() auf jeden Fall aufrufen.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNG
-=========
-
- Man beachte, dass this_player() 0 sein kann, wenn z.B. ein netztoter Spieler
- Spieler den Raum verlaesst.
- Man beachte ausserdem, dass this_player() nicht unbedingt das bewegte Living
- sein muss. Wenn z.B. jemand ein Lebewesen bewegt, ist TP der, der die
- Bewegung durchfuehrt, nicht das Lebewesen.
-
-
-SIEHE AUCH
-==========
-
- init(), this_player(), previous_object(), caller_stack(),
- NotfiyLeave(), NotifyRemove(), NotifyDestruct()
-
-Last modified: 25.02.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/find_obs b/doc/sphinx/man/lfun/find_obs
deleted file mode 100644
index 994ac6f..0000000
--- a/doc/sphinx/man/lfun/find_obs
+++ /dev/null
@@ -1,53 +0,0 @@
-
-find_obs()
-**********
-
-
-FUNKTION
-========
-
- object* find_obs(string str, int meth)
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- str Der String der geparsed werden soll.
- meth Mit Hilfe dieses Parameters koennen bestimmte Bereichs-
- eingrenzungen vorgenommen werden (definiert in moving.h):
-
- PUT_GET_NONE - keinerlei Bereichseingrenzung.
- PUT_GET_TAKE - es handelt sich um ein Nehmen von Gegenstaenden
- also wird das inventory ausgenommen.
- PUT_GET_DROP - es handelt sich um das Entfernen von Gegenstaenden
- also wird das environment ausgenommen.
-
-
-BESCHREIBUNG
-============
-
- Der String (str) muss folgendes Format haben damit Objekte gefunden
- werden.
-
- <gegenstand> [aus container] [in mir|im raum]
-
- <gegenstand> kann hierbei sowohl eine Objekt-ID als auch ein
- Gruppenbezeichner wie z.b. "alles" sein.
-
-
-RUeCKGABEWERT
-=============
-
- Ein Array mit allen Objekten die sich angesprochen fuehlen, oder aber 0.
-
-
-SIEHE AUCH
-==========
-
- drop_obj(), give_obj(), pick_obj(), put_obj(), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/lfun/get_killing_player b/doc/sphinx/man/lfun/get_killing_player
deleted file mode 100644
index 3500be1..0000000
--- a/doc/sphinx/man/lfun/get_killing_player
+++ /dev/null
@@ -1,61 +0,0 @@
-
-get_killing_player()
-********************
-
-
-FUNKTION
-========
-
- protected object get_killing_player()
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Liefert im Tod (nach dem toetenden do_damage()) das Spielerobjekt, was
- den Tod wohl zu verantworten hat, falls es ermittelt werden kann. Es
- werden registrierte Helfer-NPC und einige schadenverursachende Objekte
- beruecksichtigt. Hierbei wird QueryUser() in den Objekten abgefragt.
-
- Es benoetigt ein gueltiges P_KILLER, d.h. falls das Lebewesen vergiftet
- wurde oder das toetende Objekt aus sonstigen Gruenden nicht in P_KILLER
- steht, funktioniert es nicht.
- Auch gibt es bestimmt Objekte, die fuer Spieler toeten koennen, die die
- diese Funktion nicht kennt.
- (Dies gilt beides ebenso fuer /p/service/mupfel/getkill.c, ist also kein
- Grund, jenes statt dieser Funktion zu nutzen.)
-
-
-RUeCKGABEWERT
-=============
-
- Das Objekt des Spielers, falls es ermittelt werden konnte, sonst 0.
-
-
-BEMERKUNGEN
-===========
-
- Der Name des Spieler ist mittel Name() ermittelbar. Will man die Info,
- womit ein Spieler den Kill ggf. gemacht hat, kann man P_KILLER
- auswerten/nutzen.
-
-
-SIEHE AUCH
-==========
-
- QueryUser
- P_KILLER
-
-11.11.2013, Zesstra
diff --git a/doc/sphinx/man/lfun/gilde/AddSkill b/doc/sphinx/man/lfun/gilde/AddSkill
deleted file mode 100644
index 6be310b..0000000
--- a/doc/sphinx/man/lfun/gilde/AddSkill
+++ /dev/null
@@ -1,57 +0,0 @@
-
-AddSkill()
-**********
-
-
-FUNKTION
-========
-
- varargs int AddSkill(string sname, mapping ski)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- string sname Name des Skills
- mapping ski Skill-Mapping
-
-
-BESCHREIBUNG
-============
-
- Fuegt den Skill zur Liste der in dieser Gilde lernbaren Skills
- hinzu. Das Mapping enthaelt Informationen, die der Gildenraum
- bzw. das Gildenobjekt zum Skill herausgeben und die das Lernen
- des Skills beeinflussen.
-
-
-RUECKGABWERT
-============
-
- 1 fuer Erfolg
-
-
-BEISPIEL
-========
-
- AddSkill( FIGHT(WT_CLUB), ([ OFFSET(SI_SKILLLEARN) : 1 ]) );
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), QuerySpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/AddSpell b/doc/sphinx/man/lfun/gilde/AddSpell
deleted file mode 100644
index 027b4d6..0000000
--- a/doc/sphinx/man/lfun/gilde/AddSpell
+++ /dev/null
@@ -1,74 +0,0 @@
-
-AddSpell()
-**********
-
-
-FUNKTION
-========
-
- varargs int AddSpell(string verb, mapping ski)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- string verb Name des Spells
- mapping ski Skill-Mapping
-
-
-BESCHREIBUNG
-============
-
- Fuegt den Spell zur Liste der in dieser Gilde lernbaren Spells
- hinzu. Das Mapping enthaelt Informationen, die der Gildenraum
- bzw. das Gildenobjekt zum Spell herausgeben und die das Lernen
- des Spells beeinflussen.
-
-
-RUECKGABWERT
-============
-
- 1 fuer Erfolg
-
-
-BEMERKUNGEN
-===========
-
- Siehe das Verhalten von QuerySpell (gilde) zum Zusammenfuegen
- der AddSpell-Informationen aus Gilde und Spellbook. Relevant
- zB fuer Lernrestriktionen.
-
-
-BEISPIEL
-========
-
- AddSpell("entfluche",
- ([SI_SKILLRESTR_LEARN :
- ([P_GUILD_LEVEL: LVL_WANDER,
- SR_FUN: #'glaubensTest]),
- SI_DIFFICULTY: 100,
- SI_SKILLINFO: "Wanderprediger ab Stufe 7",
- SI_SKILLINFO_LONG: break_string(
- "Um jemanden von einem laestigen Sprachfluch zu befreien, "
- "sollte man diese Anrufung benutzen [...]", 78),
- SI_GOD: LEMBOLD]));
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSkill, QuerySpell, QuerySkill, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/GuildRating b/doc/sphinx/man/lfun/gilde/GuildRating
deleted file mode 100644
index ca4ec1b..0000000
--- a/doc/sphinx/man/lfun/gilde/GuildRating
+++ /dev/null
@@ -1,47 +0,0 @@
-
-GuildRating()
-*************
-
-
-FUNKTION
-========
-
- int GuildRating(object pl)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- object pl Spieler, der geratet werden soll
-
-
-BESCHREIBUNG
-============
-
- Gibt das Guild-Rating des Spielers im Bereich 0-MAX_ABILITY zurueck
- und schreibt sie in P_GUILD_RATING. Wichtig fuer Levelbestimmung!
-
-
-
- Normalerweise ist das der Mittelwert der Skill-Abilities aller Skills
- und Spells, das Verhalten kann aber ueberschrieben werden.
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS, P_GUILD_RATING
- Gildenfkt.:
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-10. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/InitialSkillAbility b/doc/sphinx/man/lfun/gilde/InitialSkillAbility
deleted file mode 100644
index afea3e9..0000000
--- a/doc/sphinx/man/lfun/gilde/InitialSkillAbility
+++ /dev/null
@@ -1,52 +0,0 @@
-
-InitialSkillAbility()
-*********************
-
-
-FUNKTION
-========
-
- static int InitialSkillAbility(mapping ski, object pl)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- mapping ski Der zu lernende Skill
- object pl Spieler
-
-
-BESCHREIBUNG
-============
-
- Gibt den initialen Ability-Wert fuer einen neu zu lernenden Skill (Spell)
- zurueck. Die Standardformel benutzt nur Intelligenz und SI_SKILLLEARN und
- kann in der Gilde ueberschrieben werden.
-
-
-BEMERKUNGEN
-===========
-
- Der zurueckgegebene Wert wird noch in das Spieler-Skillsystem eingegeben
- und daher kann der real gelernte Wert abweichen
-
-
-SIEHE AUCH
-==========
-
- Skills: LimitAbility, ModifySkill
- GObj Lernen: LearnSkill, LearnSpell
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/LearnSkill b/doc/sphinx/man/lfun/gilde/LearnSkill
deleted file mode 100644
index 07a4dc9..0000000
--- a/doc/sphinx/man/lfun/gilde/LearnSkill
+++ /dev/null
@@ -1,59 +0,0 @@
-
-LearnSkill()
-************
-
-
-FUNKTION
-========
-
- int LearnSkill(string skill)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- string skill Der zu lernende Skill
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ueberprueft den Spieler auf Gildenzugehoerigkeit
- und ruft, falls kein 'skill' angegeben ist die SkillListe()
- fuer Skills auf.
-
- Falls ein Argument angegeben wird, wird bei dem Spieler dieser Skill
- initialisiert, sofern er die notwendigen Anforderungen erfuellt hat.
-
-
-RUECKGABEWERT
-=============
-
- 0 bei Fehler, 1 bei Erfolg.
-
-
-BEMERKUNGEN
-===========
-
- Fuer die Lebewesen-Skills gibt es eine gleichnamige Funktion.
- Siehe dafuer LearnSkill.
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/LearnSpell b/doc/sphinx/man/lfun/gilde/LearnSpell
deleted file mode 100644
index 385da3e..0000000
--- a/doc/sphinx/man/lfun/gilde/LearnSpell
+++ /dev/null
@@ -1,53 +0,0 @@
-
-LearnSpell()
-************
-
-
-FUNKTION
-========
-
- varargs int LearnSpell(string spell, object pl)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- string spell Der zu lernende Spell
- object pl lernender Spieler, wenn 0, wird this_player() genommen
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ueberprueft den Spieler auf Gildenzugehoerigkeit
- und ruft, falls kein 'spell' angegeben ist die SkillListe()
- fuer Spells auf.
-
- Falls ein Argument angegeben wird, wird bei dem Spieler dieser Spell
- initialisiert, sofern er die notwendigen Anforderungen erfuellt hat.
-
-
-RUECKGABEWERT
-=============
-
- 0 bei Fehler, 1 bei Erfolg.
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/QuerySkill b/doc/sphinx/man/lfun/gilde/QuerySkill
deleted file mode 100644
index ee3e68a..0000000
--- a/doc/sphinx/man/lfun/gilde/QuerySkill
+++ /dev/null
@@ -1,54 +0,0 @@
-
-QuerySkill()
-************
-
-
-FUNKTION
-========
-
- mapping QuerySkill(string skill)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- string skill Name des Skills
-
-
-BESCHREIBUNG
-============
-
- Liefert fuer diesen Skill die Gildeninformationen in einem
- Mapping zurueck.
-
-
-BEISPIEL
-========
-
- // /gilden/klerus->QuerySkill(FIGHT(WT_CLUB)) gibt zB zurueck:
- ([SI_FUN: "Fight_club",
- OFFSET(SI_SKILLLEARN): 1
- SI_SKILLRESTR_USE: ([SR_FUN:#'gilden/klerus->spellTest()]),
- OFFSET(SI_SKILLLEARN): #'gilden/klerus->learnOffset,
- OFFSET(SI_SPELLCOST): #'gilden/klerus->costOffset,
- FACTOR(SI_SPELLCOST): #'gilden/klerus->costFactor])
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSkill, AddSpell, QuerySpell
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/QuerySpell b/doc/sphinx/man/lfun/gilde/QuerySpell
deleted file mode 100644
index 32eff3a..0000000
--- a/doc/sphinx/man/lfun/gilde/QuerySpell
+++ /dev/null
@@ -1,75 +0,0 @@
-
-QuerySpell()
-************
-
-
-FUNKTION
-========
-
- mapping QuerySpell(string spell)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- string spell Name des Spells
-
-
-BESCHREIBUNG
-============
-
- Liefert fuer diesen Spell die Gilden- und Spellbookinformationen
- zusammengefasst in ein Mapping zurueck.
- Die Gildeninformationen haben dabei Vorrang (d.h. eine Lernrestriktion
- im Spellbook wird benutzt, bei unterschiedlichen Werten fuer das gleiche
- Attribut geht der Wert in der Gilde vor).
-
-
-BEISPIEL
-========
-
- // /gilden/klerus->QuerySpell("entfluche") gibt zB zurueck:
- ([SI_SPELLFATIGUE: 2,
- SI_SP_LOW_MSG: "Deine Konzentration reicht nicht aus, das Interesse "
- "der Goetter zu "wecken.\n",
- SI_TIME_MSG: "So schnell koennen sich die Goetter nicht wieder um "
- "Dich kuemmern!\n",
- SI_SKILLLEARN: 5,
- OFFSET(SI_SKILLLEARN):15
- SI_SKILLRESTR_LEARN:
- ([P_LEVEL: 7,
- P_GUILD_LEVEL: LVL_WANDER,
- SR_FUN: #'gilden/klerus->glaubensTest]),
- SI_DIFFICULTY: 100,
- SI_SKILLINFO: "Wanderprediger ab Stufe 7",
- SI_SKILLINFO_LONG:
- "Um jemanden von einem laestigen Sprachfluch zu befreien, "
- "sollte man diese Anrufung benutzen [...]",
- SP_NAME: "entfluche",
- SI_SKILLRESTR_USE: ([ SR_FREE_HANDS : 0 ]),
- SI_MAGIC_TYPE: ({MT_SAKRAL})
- SI_GOD: LEMBOLD,
- SI_SKILLRESTR_USE: ([SR_FUN:#'gilden/klerus->spellTest()]),
- OFFSET(SI_SKILLLEARN): #'gilden/klerus->learnOffset,
- OFFSET(SI_SPELLCOST): #'gilden/klerus->costOffset,
- FACTOR(SI_SPELLCOST): #'gilden/klerus->costFactor])
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSkill, AddSpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/SkillListe b/doc/sphinx/man/lfun/gilde/SkillListe
deleted file mode 100644
index 200650b..0000000
--- a/doc/sphinx/man/lfun/gilde/SkillListe
+++ /dev/null
@@ -1,49 +0,0 @@
-
-SkillListe()
-************
-
-
-FUNKTION
-========
-
- int SkillListe(int what)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- int what Rueckgabeoption:
-
-
-BESCHREIBUNG
-============
-
- Gibt eine Text mit Liste mit lernbaren Skills/Spells zurueck:
-
-
-
- Fuer 'what': 0 - alle; 1 - Spells; 2 - Skills.
-
-
-
- Zeigt Eintraege aus SI_SKILLINFO.
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
- Skills: skill_info_liste
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/UseSpell b/doc/sphinx/man/lfun/gilde/UseSpell
deleted file mode 100644
index 4f3724c..0000000
--- a/doc/sphinx/man/lfun/gilde/UseSpell
+++ /dev/null
@@ -1,53 +0,0 @@
-
-UseSpell()
-**********
-
-
-FUNKTION
-========
-
- varargs int UseSpell(object caster, string spell, mapping sinfo)
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- object caster Spieler, der Spell nutzt
- string spell Spell-Name
- mapping sinfo Spell-Informationen
-
-
-BESCHREIBUNG
-============
-
- Prueft, ob der Spell in der Gilde definiert ist und ruft ihn dann
- ggf in aus dem Spell-Mapping gelesenen Gilden-SI_SPELLBOOK auf.
-
- Wird von living/skills::UseSpell gerufen, wenn dieses die SI_CLOSURE,
- also die Funktion eines Spells sucht, fuer den kein SI_SPELLBOOK
- explizit angegeben wurde.
-
-
-RUECKGABWERT
-============
-
- Rueckgabewert des Spells aus dem Spellbook oder 0.
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.: GuildRating
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/austreten b/doc/sphinx/man/lfun/gilde/austreten
deleted file mode 100644
index cde77e2..0000000
--- a/doc/sphinx/man/lfun/gilde/austreten
+++ /dev/null
@@ -1,52 +0,0 @@
-
-austreten()
-***********
-
-
-FUNKTION
-========
-
- varargs int austreten(int loss)
-
-
-ARGUMENTE
-=========
-
- int loss Prozentsatz, um den sich die Gildenskills verschlechtern
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-BESCHREIBUNG
-============
-
- Austrittsfunktion der Gilde. Prueft die Restriktionen der Gilde und
- laesst this_player() ggf austreten. Das Austreten aus der Standard-
- gilde ist dabei nicht moeglich.
-
- Der Gildenmaster loest ggf ein EVT_GUILD_CHANGE aus. Dabei werden
- E_OBJECT, E_GUILDNAME, E_LAST_GUILDNAME entsprechend gesetzt.
-
- Der Gildenmaster senkt auch die Skill/Spell-Faehigkeiten um 'loss' bzw.
- normalerweise mindestens 20%.
-
- Durch Ueberschreiben koennen hier zB Abschiedsmeldungen gesendet werden.
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.:
- * Ein/Austritt: beitreten, bei_oder_aus_treten
- * Props dafuer: P_GUILD_RESTRICTIONS
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/bei_oder_aus_treten b/doc/sphinx/man/lfun/gilde/bei_oder_aus_treten
deleted file mode 100644
index abed024..0000000
--- a/doc/sphinx/man/lfun/gilde/bei_oder_aus_treten
+++ /dev/null
@@ -1,43 +0,0 @@
-
-bei_oder_aus_treten()
-*********************
-
-
-FUNKTION
-========
-
- int bei_oder_aus_treten(string str)
-
-
-ARGUMENTE
-=========
-
- string str Spielerparameter
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-BESCHREIBUNG
-============
-
- Aus- oder Eintrittsfunktion, ruft beitreten() bzw. austreten() auf.
- Wird im Std-Gildenraum per AddCmd zur Verfuegung gestellt.
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell, QuerySkill
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.:
- * Ein/Austritt: beitreten, austreten
- * Props dafuer: P_GUILD_RESTRICTIONS
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/gilde/beitreten b/doc/sphinx/man/lfun/gilde/beitreten
deleted file mode 100644
index 6e5a957..0000000
--- a/doc/sphinx/man/lfun/gilde/beitreten
+++ /dev/null
@@ -1,43 +0,0 @@
-
-beitreten()
-***********
-
-
-FUNKTION
-========
-
- int beitreten()
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-BESCHREIBUNG
-============
-
- Beitrittsfunktion der Gilde. Prueft die Gilde selbst im Gildenmaster,
- dann die Restriktionen der Gilde und laesst this_player() ggf eintreten.
-
- Der Gildenmaster loest ggf ein EVT_GUILD_CHANGE aus. Dabei werden
- E_OBJECT, E_GUILDNAME, E_LAST_GUILDNAME entsprechend gesetzt.
-
- Durch Ueberschreiben koennen hier zB Standard-Skills und Spells den
- Spieler bei Eintritt gelehrt werden.
-
-
-SIEHE AUCH
-==========
-
- GObj Lernen: LearnSkill, LearnSpell, InitialSkillAbility
- * Anzeigen: SkillListe
- * Verwalten: AddSpell (gilde), AddSkill, QuerySpell
- * Nutzen: UseSpell (gilde)
- * Properties: P_GUILD_SKILLS, P_GLOBAL_SKILLPROPS
- Gildenfkt.:
- * Ein/Austritt: bei_oder_aus_treten, austreten
- * Props dafuer: P_GUILD_RESTRICTIONS
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/give b/doc/sphinx/man/lfun/give
deleted file mode 100644
index 866c1e3..0000000
--- a/doc/sphinx/man/lfun/give
+++ /dev/null
@@ -1,65 +0,0 @@
-
-give()
-******
-
-
-FUNKTION
-========
-
- public varargs int give(object o, object dest, mixed msg);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- object o
- Das Objekt, das uebergeben werden soll.
- object dest
- Der Spieler oder NPC, der das Objekt bekommen soll.
- mixed msg
- Eine optionale Meldung, die anstelle von P_GIVE_MSG oder der
- Standardmeldung verwendet wird, oder -1, um die Meldung zu
- unterdruecken.
-
-
-BESCHREIBUNG
-============
-
- Der Spieler oder NPC uebergibt dem Empfaenger das Objekt. Gibt o->move()
- keinen positiven Wert zurueck, beispielsweise weil das Objekt verflucht
- ist oder der Empfaenger es nicht mehr tragen kann, bekommt er eine
- entsprechende Fehlermeldung.
-
-
-RUECKGABEWERT
-=============
-
- Wenn die Uebergabe geklappt hat, 1, ansonsten 0.
-
-
-BEMERKUNG
-=========
-
- Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
- weitergeben lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
- moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
- manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
-
- Die Funktion prueft nicht, ob der Spieler/NPC der Objekt ueberhaupt hat,
- das muss man ggf. selbst ermitteln.
-
-
-SIEHE AUCH
-==========
-
- move(L), P_GIVE_MSG, give_objects(L), give_notify(L),
- P_NOINSERT_MSG, P_NOLEAVE_MSG, P_TOO_MANY_MSG,
- P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NODROP
-
-Last modified: Thu Aug 28 22:21:19 2008 by Amynthor
diff --git a/doc/sphinx/man/lfun/give_notify b/doc/sphinx/man/lfun/give_notify
deleted file mode 100644
index ef316cb..0000000
--- a/doc/sphinx/man/lfun/give_notify
+++ /dev/null
@@ -1,87 +0,0 @@
-
-give_notify()
-*************
-
-
-FUNKTION
-========
-
- void give_notify(object obj);
-
-
-DEFINIERT IN
-============
-
- /std/npc/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- obj
- an den NPC uebergebenes Objekt
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird automatisch immer dann aufgerufen, wenn ein
- Lebewesen (welches kein Spielercharakter ist) ein Objekt uebergeben
- bekommt. Dies muss jedoch ueber die Funktionalitaet von
- put_and_get.c geschehen sein, innerhalb von move() wird die Funktion
- nicht aufgerufen!
-
-
-BEISPIEL
-========
-
- Oftmals will man in Quests erreichen, dass einem NPC ein bestimmtes
- Item als Beweis der Erfuellung einer bestimmten Aufgabe ueberbracht
- wird. Folgendermasse kann dies realisiert werden:
- void create() {
- ::create();
- ...
- SetProp(P_REJECT,({REJECT_GIVE,
- Name(WER)+" sagt: Das brauche ich nicht!\n"}));
- ...
- }
-
- void quest_ok(object obj) { ...
- // Vernichtung des Questobjektes und Questtexte
- // Questbelohnung und Questanerkennung
- }
-
- void give_notify(object obj) {
- if(obj->id("\nquestitem")) // Questitem bekommen?
- quest_ok(obj);
- else
- ::give_notify(obj); // P_REJECT soll sonst greifen
- }
- Der Aufruf von ::give_notify() stellt sicher, dass ein Objekt
- zurueckgegeben wird, sofern es nicht das gesuchte ist. Erreicht wird
- dies ueber P_REJECT (siehe Bemerkungen).
-
-
-BEMERKUNGEN
-===========
-
- Speziell in NPCs ist diese Funktion normalerweise dafuer
- verantwortlich, dass mittels der Property P_REJECT die Annahme von
- Objekten verweigert werden kann. Ueberschreibt man sie, so sollte
- man gegebenenfalls darauf achten, dass diese Standardfunktion
- ebenfalls aufgerufen wird.
-
-
-SIEHE AUCH
-==========
-
- P_REJECT, show_notify(),
- /std/npc/put_and_get.c, /std/living/put_and_get.c
-
-22. Oktober 2013, Arathorn.
diff --git a/doc/sphinx/man/lfun/give_obj b/doc/sphinx/man/lfun/give_obj
deleted file mode 100644
index 753fd09..0000000
--- a/doc/sphinx/man/lfun/give_obj
+++ /dev/null
@@ -1,43 +0,0 @@
-
-give_obj()
-**********
-
-
-FUNKTION
-========
-
- int give_obj(object ob, object where)
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- ob Das Objekt, das abgegeben werden soll.
- where Das Lebewesen, dass das Objekt erhaelt.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion aufgerufen werden soll, gibt
- den angegebenen Gegenstand (ob) an das angegebene Lebewesen (where).
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Objekt uebergeben wurde oder die Uebergabe nicht moeglich war.
- (in diesem Fall wird auch direkt eine Textausgabe ausgegeben)
- 0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe plaziert.
-
-
-SIEHE AUCH
-==========
-
- pick_obj(), drop_obj(), put_obj(), find_obs(), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/lfun/heal_self b/doc/sphinx/man/lfun/heal_self
deleted file mode 100644
index 53697a2..0000000
--- a/doc/sphinx/man/lfun/heal_self
+++ /dev/null
@@ -1,68 +0,0 @@
-
-heal_self()
-***********
-
-
-FUNKTION
-========
-
- void heal_self(int points);
-
-
-ARGUMENTE
-=========
-
- points: Die dem Lebewesen zukommende Heilung.
-
-
-BESCHREIBUNG
-============
-
- Dem Lebewesen werden points Lebens- und Konzentrationspunkte
- gutgeschrieben und auf die aktuellen addiert. Es werden aber nicht
- die maximalen Werte ueberschritten.
-
-
-RUECKGABEWERT
-=============
-
- Keiner
-
-
-BEISPIELE
-=========
-
- AddCmd("pflueck&beere","pfluecke_cmd","Was moechtest Du pfluecken?");
-
- int pfluecke_cmd(string str){
- write("Du pflueckst eine Beere, isst sie und fuehlst Dich gleich "
- +"viel besser.\n");
- this_player()->heal_self(30);
- return 1;
- }
-
- Der Spieler bekommt hier pro Beere die er pflueckt und isst je 30 LP/KP
- zu seinen momentanen.
-
-BEMERKUNGEN:
- heal_self wird gerne fuer Heilstellen in Gebieten genommen, in
- denen ein Spieler diese Heilung auch wirklich braucht. Dennoch ist
- der Einsatz un- bedingt mit der Heilungsbalance abzusprechen und
- darauf zu achten, dass pro reset() nur eine bestimmte Anzahl an
- Heilungen ausgegeben werden.
-
- Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der
- eigens dafuer eingerichteten Funktion check_and_update_timed_key
- realisiert werden.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: restore_spell_points, restore_hit_points, buffer_hp
- buffer_sp, check_and_update_timed_key
- Gegenparts: do_damage, reduce_hit_points, reduce_spell_points
- Props: P_HP, P_SP
- Konzept: heilung
-
-Last modified: 27.05.2007 by Ennox
diff --git a/doc/sphinx/man/lfun/heart_beat b/doc/sphinx/man/lfun/heart_beat
deleted file mode 100644
index 475a781..0000000
--- a/doc/sphinx/man/lfun/heart_beat
+++ /dev/null
@@ -1,57 +0,0 @@
-
-heart_beat()
-************
-
-
-FUNKTION
-========
-
- protected void heart_beat();
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
- /std/living/combat.c
- und anderen...
- kann auch in beliebigen Objekten selbst definiert werden.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird alle zwei Sekunden vom GameDriver aufgerufen. Sie
- regelt in der MG-MudLib das Heilen von Spielern und Monstern, den
- Ablauf von Kampfrunden, die Verdauung etc.
-
- Da heart_beat() ziemlich viele Ressourcen des GameDrivers verbraet,
- sollte man Objekte mit heart_beat() nur so selten wie moeglich
- benutzen! Und selbst dann sollte der heart_beat() nicht die ganze Zeit
- ueber laufen, sondern sich so bald wie moeglich abschalten.
-
- Das Ein- und Ausschalten des heart_beat()s erfolgt mit
- set_heart_beat().
-
-
-BEMERKUNGEN
-===========
-
- 1. Teuer, teuer, teuer!
- 2. Soll euer Viech pro "echtem" Heartbeat mehrere Kampfrunden haben,
- benutzt dafuer SA_SPEED und ruft auf gar keinen Fall mehrfach
- ::heart_beat() auf. Also _NICHT_
- void heart_beat() {
- ::heart_beat();
- ::heart_beat(); }
- sondern:
- SetProp(P_SKILL_ATTRIBUTE_OFFSETS, ([SA_SPEED: 200]) );
-
-
-SIEHE AUCH
-==========
-
- Efuns: set_heart_beat(), absolute_hb_count(), set_next_reset()
- Fehler: make_immortal(L)
-
-22.3.2008, Zesstra
diff --git a/doc/sphinx/man/lfun/id b/doc/sphinx/man/lfun/id
deleted file mode 100644
index 4921395..0000000
--- a/doc/sphinx/man/lfun/id
+++ /dev/null
@@ -1,99 +0,0 @@
-
-id()
-****
-
-
-FUNKTION
-========
-
- varargs int id(string str, int lvl);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
- /std/player/base.c
-
-
-ARGUMENTE
-=========
-
- string str
- String, auf den getestet werden soll.
- int lvl
- In /std/player/base.c benutzt. Wenn der Spieler unsichtbar ist
- und lvl kleiner ist als sein Level, wird 0 zurueckgegeben.
-
-
-BESCHREIBUNG
-============
-
- Es wird geprueft, ob sich das Objekt mit str ansprechen laesst. Dazu
- wird str mit dem Inhalt der Property P_IDS verglichen. Falls
- P_ADJECTIVES gesetzt ist, werden auch alle Adjektivkombinationen mit
- den Bezeichnern geprueft.
-
- Besondere Bedeutung hat diese Funktion bei Mengenobjekten: Anhand von
- str wird vermerkt, welche Menge des Objektes angesprochen wird. Es
- werden dabei mehrere Faelle unterschieden:
- o str ist einer der mit AddId() angegebener Bezeichner. In diesem
- Fall ist die angesprochene Menge die Gesamtmenge.
- o str ist einer der mit AddSingularId() angegebenen Bezeichner. Die
- angesprochene Menge ist in diesem Fall 1.
- o str ist einer der mit AddPluralId() angegebenen Bezeichner. Die
- angesprochene Menge ist in diesem Fall . die Gesamtmenge.
- o Hat str die Form "<n> <id>", wobei <n>=1 und <id> eine SingularId
- oder 1 < <n> <= der Gesamtmenge und <id> eine PluralId, so ist die
- angesprochene Menge = <n>.
- Wie gesagt, gilt dies einzig und allein bei Mengenobjekten!
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn sich das Objekt von str angesprochen fuehlt, ansonsten 0.
-
-
-BEISPIELE
-=========
-
- Angenommen, ein Objekt habe folgende Bezeichner:
-
- AddId( "murmel" );
- AddAdjective( "runde" );
-
- Dann liefern die angegebenen id()-Aufrufe folgende Ergebnisse:
-
- id( "murmel" ); => 1
- id( "runde murmel" ); => 1
- id( "kleine murmel" ); => 0
- id( "runder ball" ); => 0
- id( "runde murmel 2" ); => 1, wenn dies die zweite Murmel in der
- gleichen Umgebung ist, ansonsten 0
-
- Bei einem Haufen von 100 Muenzen haette man zB.:
-
- AddId( "geld" );
- AddSingularId( "muenze" );
- AddPluralId( "muenzen" );
-
- Nach fuehlen sich nach den folgenden id()-Aufrufen folgende Anzahlen
- angesprochen:
-
- id( "geld" ); => 100 Muenzen
- id( "muenze" ); => 1 Muenze
- id( "muenzen" ); => 100 Muenzen
- id( "1 muenze" ); => 1 Muenze
- id( "42 muenzen" ); => 42 Muenzen
-
- id() liefert in all diesen Faellen 1 zurueck.
-
-
-SIEHE AUCH
-==========
-
- AddId(), AddAdjective(), AddSingularId(), AddPluralId(), present(),
- match_ids(), /std/thing/description.c, /std/unit.c
-
-6. Sep 2012 Gloinson
diff --git a/doc/sphinx/man/lfun/init b/doc/sphinx/man/lfun/init
deleted file mode 100644
index 481eec2..0000000
--- a/doc/sphinx/man/lfun/init
+++ /dev/null
@@ -1,91 +0,0 @@
-
-init()
-******
-
-
-FUNKTION
-========
-
- void init();
-
-
-DEFINIERT IN
-============
-
- /std/room/description.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- init() wird immer dann aufgerufen, wenn ein lebendes Objekt in die
- Naehe anderer Objekte bewegt wird oder ein nicht lebendiges Objekt
- in die Naehe von Lebewesen gelangt. init() wird dabei in allen
- Objekten aufgerufen, bei denen es notwendig ist.
-
- Der Hauptzweck dieser Funktion besteht darin, den Objekten
- untereinander ihre jeweiligen Befehle zugaenglich zu machen.
- Waehrend dies in anderen MudLibs durch eine Reihe von
- add_action()-Aufrufen im Rumpf von init() geschah, geschieht dies in
- der MG-MudLib bei Objekten, die /std/thing/commands.c erben
- (das sind zB. alle Standardobjekte) quasi automatisch
- (dort werden die Befehle dann per AddCmd() im create() angemeldet,
- man spart sich die Implementierung von init() und dem Mud somit
- Speicher). Der andere Weg ist aber natuerlich immer noch moeglich.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Der Ablauf der init()-Kette ist wie folgt:
- o Ist das Objekt X, welches ins Zielobjekt D bewegt wurde, ein
- Lebewesen, so wird in D init() aufgerufen, wobei this_player() auf
- X gesetzt ist.
- o Dann wird fuer jedes Objekt C in D folgendes ausgefuehrt:
- + Ist C ein Lebewesen, dann wird init() in X aufgerufen, wobei
- this_player() auf C gesetzt ist.
- + Ist X ein Lebewesen, dann wird init() in C aufgerufen, wobei
- this_player() auf X gesetzt ist.
- o Schliesslich wird in dem Fall, dass D lebendig ist, in X init()
- aufgerufen, wobei this_player() auf D gesetzt ist.
-
-
-BEISPIELE
-=========
-
- D sei ein Raum, in dem sich das Lebewesen L1 sowie die Gegenstaende
- N1 und N2 befinden.
- Betritt ein Spieler X diesen Raum, so werden folgende init()s
- aufgerufen:
-
- D->init(); // this_player() == X
- X->init(); // this_player() == L1
- L1->init(); // this_player() == X
- N1->init(); // this_player() == X
- N2->init(); // this_player() == X
-
- Gelangt dagegen ein nichtlebendiges Objekt nach D, so sieht das Ganze
- wie folgt aus:
-
- X->init(); // this_player() == L1
-
-
-SIEHE AUCH
-==========
-
- exit(), AddCmd(), add_action(),
- NotifyInsert()
-
-Last modified: 04.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/insert_sensitive_inv b/doc/sphinx/man/lfun/insert_sensitive_inv
deleted file mode 100644
index 513632a..0000000
--- a/doc/sphinx/man/lfun/insert_sensitive_inv
+++ /dev/null
@@ -1,36 +0,0 @@
-
-insert_sensitive_inv()
-**********************
-
-
-FUNKTION
-========
-
- void insert_sensitive_inv(object ob, string key,
- int threshold, mixed *opt)
-
-
-DEFINIERT IN
-============
-
- /std/container/inventory.c
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion sucht, ob beim Hinzufuegen eines sensitiven Objekts
- schon ein Objekt da ist, dass dieses ausloest.
-
-
-SIEHE AUCH
-==========
-
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv_trigger
- P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
- P_SENSITIVE_INVENTORY_TRIGGER
- CheckSensitiveAttack
-
-28.Jan.2001, Gloinson@MG
diff --git a/doc/sphinx/man/lfun/insert_sensitive_inv_trigger b/doc/sphinx/man/lfun/insert_sensitive_inv_trigger
deleted file mode 100644
index edb78f8..0000000
--- a/doc/sphinx/man/lfun/insert_sensitive_inv_trigger
+++ /dev/null
@@ -1,36 +0,0 @@
-
-insert_sensitive_inv_trigger()
-******************************
-
-
-FUNKTION
-========
-
- void insert_sensitive_inv_trigger(object ob, string key,
- int threshold, mixed *opt)
-
-
-DEFINIERT IN
-============
-
- /std/container/inventory.c
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion sucht, ob ein sensitives Objekt im Inventory ist,
- das durch dieses (soeben eingefuegte) Objekt ausgeloest wird.
-
-
-SIEHE AUCH
-==========
-
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv
- P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
- P_SENSITIVE_INVENTORY_TRIGGER
- CheckSensitiveAttack
-
-28.Jan.2001, Gloinson@MG
diff --git a/doc/sphinx/man/lfun/int_long b/doc/sphinx/man/lfun/int_long
deleted file mode 100644
index 931e132..0000000
--- a/doc/sphinx/man/lfun/int_long
+++ /dev/null
@@ -1,91 +0,0 @@
-
-int_long()
-**********
-
-
-FUNKTION
-========
-
- varargs string int_long(mixed viewer, mixed viewpoint, int flags)
-
-
-DEFINIERT IN
-============
-
- /std/room/description.c
-
-
-ARGUMENTE
-=========
-
- mixed viewer - der Betrachter des Raumes
- mixed viewpoint - 0/Objekt/Array der/die Ausgangspunkt(e) des
- Betrachtens (und damit nicht sichtbar!)
- int flags - Modifikatoren fuer die Anzeige
- (siehe "man make_invlist", wird mit 3 verUNDet!)
-
-
-BESCHREIBUNG
-============
-
- Es wird die Beschreibung des Rauminneren erstellt. Dabei wird die
- Langbeschreibung des Raumes, die enthaltenen Objekte (exklusive
- aller viewpoints (normalerweise nur der Betrachter)) und Ausgaenge,
- wenn vom Viewer eingeschaltet dargestellt.
- Falls der Raum innerhalb eines anderen Raumes liegt und selbst
- transparent ist, wie zusaetzlich die Kurzbeschreibung des Aussen-
- raumes angezeigt.
-
- Ist Viewer ein Magier mit eingeschaltetem Magiermodus, so wird der
- Beschreibung der Dateiname des Raumes vorangestellt.
-
-
-RUeCKGABEWERT
-=============
-
- Die Langbeschreibung des Raumes von innen.
-
-
-BEMERKUNGEN
-===========
-
- Die Trennung von viewer und viewpoint hat durchaus ihren Sinn. So ist
- es zum Beispiel moeglich, einen Raum "mit den Augen eines Anderen" zu
- betrachten. Dabei saehe man sich selbst, wenn man im Raum waere.
-
-
-BEISPIELE
-=========
-
- // in diesem Raum sieht man keine Mitspieler im "schau" oder beim
- // Betreten (vielleicht ist es zu neblig)
- // dazu werden einfach alle Interactives zu den viewpoints addiert
- string int_long(object viewer, mixed viewpoints, int flags) {
- if(!pointerp(viewpoints)) viewpoints=({viewpoints});
- return ::int_long(&viewer,
- viewpoints+
- filter(all_inventory(this_object()),
- #'interactive),
- &flags);
- }
-
- string int_short(object viewer, mixed viewpoints) {
- if(!pointerp(viewpoints)) viewpoints=({viewpoints});
- return ::int_short(&viewer,
- viewpoints+
- filter(all_inventory(this_object()),
- #'interactive));
- }
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: int_short()
- Properties: P_INT_LONG, P_SHORT
- P_HIDE_EXITS, P_SHOW_EXITS
- P_TRANSPARENT
- Kommandokette: make_invlist(), short()
- Sonstiges: P_REFERENCE_OBJECT, P_WANTS_TO_LEARN
-
-11. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/int_short b/doc/sphinx/man/lfun/int_short
deleted file mode 100644
index aabd547..0000000
--- a/doc/sphinx/man/lfun/int_short
+++ /dev/null
@@ -1,85 +0,0 @@
-
-int_short()
-***********
-
-
-FUNKTION
-========
-
- string int_short(mixed viewer, mixed viewpoint);
-
-
-DEFINIERT IN
-============
-
- /std/room/description.c
-
-
-ARGUMENTE
-=========
-
- mixed viewer - der Betrachter des Raumes
- mixed viewpoint - 0/Objekt/Array der/die Ausgangspunkt(e) des
- Betrachtens (und damit nicht sichtbar!)
-
-
-BESCHREIBUNG
-============
-
- Es wird eine kurze Beschreibung des Rauminneren erstellt. Dabei wird
- die Kurzbeschreibung des Raumes, die enthaltenen Objekte (exklusive
- aller viewpoints (normalerweise nur der Betrachter)) und Ausgaenge,
- wenn vom Viewer eingeschaltet dargestellt.
-
- Ist Viewer ein Magier mit eingeschaltetem Magiermodus, so wird der
- Beschreibung der Dateiname des Raumes vorangestellt.
-
-
-RUeCKGABEWERT
-=============
-
- Die Kurzbeschreibung des Raumes von innen.
-
-
-BEMERKUNGEN
-===========
-
- Die Trennung von viewer und viewpoint hat durchaus ihren Sinn. So ist
- es zum Beispiel moeglich, einen Raum "mit den Augen eines Anderen" zu
- betrachten. Dabei saehe man sich selbst, wenn man im Raum waere.
-
-
-BEISPIELE
-=========
-
- // in diesem Raum sieht man keine Mitspieler im "schau" oder beim
- // Betreten (vielleicht ist es zu neblig)
- // dazu werden einfach alle Interactives zu den viewpoints addiert
- string int_long(object viewer, mixed viewpoints, int flags) {
- if(!pointerp(viewpoints)) viewpoints=({viewpoints});
- return ::int_long(&viewer,
- viewpoints+
- filter(all_inventory(this_object()),
- #'interactive),
- &flags);
- }
-
- string int_short(object viewer, mixed viewpoints) {
- if(!pointerp(viewpoints)) viewpoints=({viewpoints});
- return ::int_short(&viewer,
- viewpoints+
- filter(all_inventory(this_object()),
- #'interactive));
- }
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: int_long()
- Properties: P_INT_SHORT, P_SHORT
- P_HIDE_EXITS, P_SHOW_EXITS
- Kommandokette: make_invlist(), short()
- Sonstiges: P_REFERENCE_OBJECT, P_WANTS_TO_LEARN
-
-11. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/is_class_member b/doc/sphinx/man/lfun/is_class_member
deleted file mode 100644
index 1018e71..0000000
--- a/doc/sphinx/man/lfun/is_class_member
+++ /dev/null
@@ -1,174 +0,0 @@
-
-is_class_member()
-*****************
-
-
-FUNKTION
-========
-
- int is_class_member(string|string* class);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- string/string* class - String oder Stringarray der Klasse(n)
-
-
-BESCHREIBUNG
-============
-
- Es wird getestet, ob das Objekt in eine der in class angegebenen
- Klassen faellt. In diesen Test werden die folgenden Eigenschaften des
- Objektes einbezogen:
-
- 1. Die Rasse des Objektes (bei Lebewesen),
- 2. die IDs des Objektes und
- 3. die explizit angegebenen Klassen des Objektes.
- 4. einigen impliziten Klassen, die sich aus den Klassen in 3 ergeben.
-
- Die moeglichen Klassen sind in /sys/class.h definiert. Momentan stehen
- folgende Klassen zur Verfuegung:
-
- CL_AMMUNITION
- Das Objekt eignet sich als Munition.
- CL_ANIMAL
- Das Objekt ist ein Tier.
- CL_ARACHNID
- Das Objekt in ein Spinnenwesen.
- CL_BIGBANG
- Dieses Objekt kann mehreren Lebewesen auf einmal Schaden zufuegen.
- CL_BIRD
- Ein Vogel.
- CL_CRAWLING
- Dieses Wesen bewegt sich kriechend.
- CL_CURSE
- Das Objekt ist ein Fluch (zB. ein Sprachfluch).
- CL_DEMON
- Bei dem Objekt handelt es sich um einen Daemon.
- CL_DISEASE
- Eine Krankheit.
- CL_DRAGON
- Ein Drache.
- CL_DWARF
- Fuer unsere kleinen Gaeste...
- CL_ELF
- Elfen aller Art.
- CL_ELEMENTAL
- Ein Elementar irgendeiner Art. Material setzen waere angebracht.
- CL_EXPLOSIVE
- Bei dem Objekt handelt es sich um einen Sprengstoff.
- CL_FELINE
- Felinen und andere katzenartigen Lebewesen.
- CL_FISH
- Fische - keine Meeressaeuger!
- CL_FLYING
- Dieses Wesen bewegt sich fliegend.
- CL_FROG
- Froesche - auch gefroschte Spieler.
- CL_GHOST
- Geister und geisterhafte Wesen.
- CL_GHOUL
- Ein Ghoul. Er faellt automatisch in die Klasse CL_UNDEAD.
- CL_GIANT
- Ein riesiges Lebewesen.
- CL_GNOME
- Ein Gnom.
- CL_GOBLIN
- Ein Goblin.
- CL_HOBBIT
- Ein Hobbit.
- CL_HOBGOBLIN
- Ein Hobgoblin. Er faellt automatisch auch in die Klasse CL_GOBLIN.
- CL_HUMAN
- Ein Mensch.
- CL_INORGANIC
- Anorganische Lebewesen wie Metallmonster
- CL_INSECT
- Insekten (Nicht mit Spinnen verwechseln)
- CL_LIVING
- Lebewesen im allgemeinen.
- CL_MAMMAL
- Saeugetiere.
- CL_MAMMAL_LAND
- Landsaeugetiere
- CL_MAMMAL_WATER
- Meeressaeuger.
- CL_ORC
- Ein Ork.
- CL_PLANT
- Pflanzen und pflanzenartige Monster.
- CL_POISON
- Das Objekt ist selbst ein Gift
- CL_POISONOUS
- Das Objekt kann einen Spieler/NPC vergiften.
- CL_REPTILE
- Reptilien.
- CL_SHADOW
- Schattenwesen.
- CL_SKELETON
- Ein Skelett. Es faellt automatisch in die Klasse CL_UNDEAD.
- CL_SLIME
- Fuer Einzeller und aehnliches Schleimgetier
- CL_SNAKE
- Schlangen.
- CL_SWIMMING
- Dieses Wesen bewegt sich schwimmend.
- CL_TROLL
- Ein Troll.
- CL_UNDEAD
- Ein untotes Lebewesen.
- CL_WALKING
- Dieses Wesen bewegt sich gehend.
- CL_VAMPIRE
- Ein Vampir. Er faellt automatisch in die Klasse CL_UNDEAD.
- CL_ZOMBIE
- Ein Zombie. Er faellt automatisch in die Klasse CL_UNDEAD.
-
- Implizite Klassen:
- Bei einigen Klassen wird im AddClass() automatisch eine oder mehrere
- weiterer Klassen hinzugefuegt und im RemoveClass() die entsprechenden
- impliziten Klassen auch automatisch entfernt.
- Wuenscht man diese impliziten Klassen nicht, muss man nach dem AddClass()
- diese mittels eines entsprechenden RemoveClass() entfernen.
- Die impliziten Klassen einer Klasse lassen sich mit Hilfe der Funktion
- QueryImplicitClasses() in CLASSDB herausfinden:
- CLASSDB->QueryImplicitClasses(...)
- Momentan sind dies:
- CL_ZOMBIE: CL_UNDEAD
- CL_SKELETON: CL_UNDEAD
- CL_GHOUL: CL_UNDEAD
- CL_VAMPIRE: CL_UNDEAD
- CL_HOBGOBLIN: CL_GOBLIN
- CL_MAMMAL_LAND: CL_MAMMAL, CL_ANIMAL
- CL_MAMMAL_WATER: CL_MAMMAL, CL_ANIMAL
- CL_SNAKE: CL_REPTILE
- CL_ARACHNID: CL_ANIMAL
- CL_BIRD: CL_ANIMAL
- CL_FISH: CL_ANIMAL
- CL_FROG: CL_ANIMAL
- CL_INSECT: CL_ANIMAL
- CL_MAMMAL: CL_ANIMAL
- CL_REPTILE: CL_ANIMAL
- CL_SNAKE: CL_ANIMAL
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Objekt in eine der angegebenen Klassen faellt, ansonsten 0.
-
-
-SIEHE AUCH
-==========
-
- AddClass(), RemoveClass(), /std/thing/description.c
- P_CLASS
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/lfun b/doc/sphinx/man/lfun/lfun
deleted file mode 100644
index 6e35081..0000000
--- a/doc/sphinx/man/lfun/lfun
+++ /dev/null
@@ -1,25 +0,0 @@
-
-lfun()
-******
-
-
-NAME
-====
-
- lfun()
-
-
-DESCRIPTION
-===========
-
- This directory contains descriptions for the lfuns used by
- Amylaar's version of the LPC parser.
-
- These are functions that are applied by the parser to the LPC
- objects on various occasions.
-
-
-SEE ALSO
-========
-
- efun(E), master(M), concepts(C), lpc(LPC), driver(D)
diff --git a/doc/sphinx/man/lfun/locate_objects b/doc/sphinx/man/lfun/locate_objects
deleted file mode 100644
index 5854980..0000000
--- a/doc/sphinx/man/lfun/locate_objects
+++ /dev/null
@@ -1,79 +0,0 @@
-
-locate_objects()
-****************
-
-
-FUNKTION
-========
-
- object *locate_objects(string desc, int info);
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- desc
- Die Umschreibung des gesuchten Objektes.
-
- info
- Ist ungleich 0, wenn diese Funktion von /std/living/put_and_get.c
- aus aufgerufen wurde.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion erweitert die Funktionalitaet von present_objects()
- insofern, als dass es moeglich ist, auch noch Behaelter innerhalb des
- Behaelters zu durchsuchen. Das genaue Verhalten haengt von desc ab:
-
- Ist desc von der Form "<id>", so wird das Ergebnis von
- present_objects(desc) zurueckgegeben.
-
- Ist desc von der Form "<gesucht> in <id>", so wird in allen Objekten,
- die von present_objects("<id>") erfasst wurden,
- locate_objects("<desc>") aufgerufen. Zurueckgegeben werden alle auf
- diese Weise gefundenen Objekte.
-
-
-RUeCKGABEWERT
-=============
-
- Array von Objekten, die auf die oben geschilderte Art und Weise
- ermittelt wurden. Konnte kein Objekt ermittelt werden, wird ein leeres
- Array zurueckgegeben.
-
-
-BEMERKUNGEN
-===========
-
- Theoretisch sollte es moeglich sein, ueber desc rekursiv mehrere
- Behaelterebenen erfassen zu koennen (etwa mit "schwert in beutel in
- beutel in wargon"). In der aktuellen Implementierung klappt das jedoch
- nicht; nach dem ersten "in" ist Schluss!
-
-
-BEISPIELE
-=========
-
- Was steckt alles dem Beutel, den der Spieler bei sich traegt?
-
- object *obs;
- obs = this_player()->locate_objects("alles in beutel");
-
- Traegt der Spieler keinen Beutel bei sich oder ist dieser leer, so wird
- ein leeres Array zurueckgegeben.
-
-
-SIEHE AUCH
-==========
-
- present_objects(), /std/container/restrictions.c
-
-Last modified: Wed May 8 10:20:36 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/logon b/doc/sphinx/man/lfun/logon
deleted file mode 100644
index 4fb7117..0000000
--- a/doc/sphinx/man/lfun/logon
+++ /dev/null
@@ -1,26 +0,0 @@
-
-logon()
-*******
-
-
-SYNOPSIS
-========
-
- int logon(void)
-
-
-DESCRIPTION
-===========
-
- When the parser accepts a new connection, it first calls
- connect() in the master object and then applies logon() to
- the object that is returned by the master. That will usually be
- a special login object, that is expected to clone and get going
- a user shell or player object.
- Should return 0 on failure, everything else means success.
-
-
-SEE ALSO
-========
-
- connect(M)
diff --git a/doc/sphinx/man/lfun/long b/doc/sphinx/man/lfun/long
deleted file mode 100644
index a186cf9..0000000
--- a/doc/sphinx/man/lfun/long
+++ /dev/null
@@ -1,55 +0,0 @@
-
-long()
-******
-
-
-FUNKTION
-========
-
- varargs string long(int mode);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- int mode - Modifikatoren fuer die Anzeige, falls this_object()
- ein Container ist
- (siehe "man make_invlist")
-
-
-BESCHREIBUNG
-============
-
- Der Inhalt der Property P_LONG wird ausgewertet und zurueckgegeben.
- Falls das Objekt ein Container und transparent (offen) ist, wird
- zudem make_invlist() auf den Inhalt zurueckgegeben.
-
-
-RUeCKGABEWERT
-=============
-
- Die Langbeschreibung des Objektes.
-
-
-BEMERKUNGEN
-===========
-
- Durch Ueberladen von long() lassen sich noch weitere Eigenschaften des
- Objektes anzeigen. Behaelter koennen zum Beispiel noch ihren Inhalt
- anzeigen, Lebewesen ihren Gesundheitszustand, o.ae.
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: short()
- Properties: P_LONG, P_INVIS, P_TRANSPARENT
- Sonstiges: make_invlist()
-
-11. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/make_immortal b/doc/sphinx/man/lfun/make_immortal
deleted file mode 100644
index 9d0f402..0000000
--- a/doc/sphinx/man/lfun/make_immortal
+++ /dev/null
@@ -1,44 +0,0 @@
-
-make_immortal()
-***************
-
-
-FUNKTION
-========
-
- void make_immortal();
-
-
-DEFINIERT IN
-============
-
- /std/npc/combat.c
-
-
-BESCHREIBUNG
-============
-
- Macht den NPC fuer 5 Minuten unangreifbar und heilt ihn.
-
- Wird bei Fehlern im Herzschlag des NPCs gerufen um Bugnutzung
- zu unterbinden.
-
- Ausschrift:
- "... versteckt sich hinter einem Fehler im Raum-Zeit-Gefuege und
- entgeht so voruebergehend allen Angriffen."
-
-
-BEMERKUNGEN
-===========
-
- Nicht missbrauchen.
-
-
-SIEHE AUCH
-==========
-
- Methoden: heart_beat(), static _check_immortality()
- Master: heart_beat_error()
- Properties: "time_to_mortality"
-
-1.Juni 2007 Gloinson
diff --git a/doc/sphinx/man/lfun/make_invlist b/doc/sphinx/man/lfun/make_invlist
deleted file mode 100644
index 379b47c..0000000
--- a/doc/sphinx/man/lfun/make_invlist
+++ /dev/null
@@ -1,59 +0,0 @@
-
-make_invlist()
-**************
-
-
-FUNKTION
-========
-
- varargs mixed make_invlist(object viewer, mixed inv, int flags)
-
-
-DEFINIERT IN
-============
-
- /std/container/description.c
-
-
-ARGUMENTE
-=========
-
- object viewer - das Objekt, welches sich den Inhalt ansieht (in
- der Regel this_player())
- mixed inv - ein Array von Objekten, die in die Liste
- aufgenommen werden sollen
- int flags - Folgende Werte koennen verODERt werden:
- 1: das Inv nicht als String, sondern als ein
- Array zurueckgeben
- 2: gleiche Objekte nicht zusammengefassen
- 4: unterdrueckt die Ausgabe des Dateinamens hinter
- jedem trotz eingeschaltetem Magiermodus
-
-
-BESCHREIBUNG
-============
-
- Die Kurzbeschreibungen der Objekte in inv werden zu einer Liste
- zusammengefasst (eine Zeile pro Objekt). Unsichtbare Objekte tauchen in
- dieser Liste nicht auf.
-
- Ist viewer ein Magier mit eingeschaltetem Magiermodus, so wird hinter
- die Kurzbeschreibungen noch der Dateiname des jeweiligen Objektes in
- eckigen Klammern angegeben. Unsichtbare Objekte erscheinen in diesem
- Fall als Filenamen.
-
-
-RUeCKGABEWERT
-=============
-
- Ein String oder ein Array, die das inv beschreiben.
-
-
-SIEHE AUCH
-==========
-
- Kommandokette: short()
- Properties: P_SHORT, P_INVIS, P_WANTS_TO_LEARN
- Sonstiges: P_REFERENCE_OBJECT
-
-Last modified: Tue Oct 15 10:10:00 2002 by Rikus
diff --git a/doc/sphinx/man/lfun/master/AddWizardForUID b/doc/sphinx/man/lfun/master/AddWizardForUID
deleted file mode 100644
index 249e27c..0000000
--- a/doc/sphinx/man/lfun/master/AddWizardForUID
+++ /dev/null
@@ -1,74 +0,0 @@
-
-AddWizardForUID()
-*****************
-
-
-FUNKTION
-========
-
- string* AddWizardForUID(string uid, string wizard);
-
-
-DEFINIERT IN
-============
-
- /secure/master/userinfo.c
-
-
-ARGUMENTE
-=========
-
- uid
- Die UID, fuer die man einen (weiteren) verantwortlichen Magier
- explizit eintragen moechte.
- wizard
- Der Magier, den man eintragen moechte.
-
-
-BESCHREIBUNG
-============
-
- Die Funktion traegt einen Magier 'wizard' explizit als verantwortlichen
- Magier fuer die UID 'uid' ein. Hierbei kann 'uid' sogar der Name eines
- anderen Magiers sein, dessen UIDs 'wizard' sozusagen "adoptiert".
-
- Berechtigt zum Eintragen von Magiern fuer bestimmte UIDs sind alle Magier,
- die (implizit oder explizit) verantwortlich fuer die jeweilige UID sind.
- Z.B. kann Zesstra ohne weiteres jemand weiteren als verantwortlich fuer
- d.inseln.zesstra eintragen.
-
-
-RUeCKGABEWERT
-=============
-
- Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID,
- fuer die dier Magier jetzt explizit eingetragen ist.
-
-
-BEMERKUNGEN
-===========
-
- Es ist nicht noetig, z.B. Zesstra als verantwortlich fuer d.inseln.zesstra
- einzutragen, da sie ohnehin schon implizit dafuer zustaendig ist. Auch
- fuer RMs bzw. GMs muss ihre Region bzw. Gilde nicht explizit eingetragen
- werden.
-
-
-BEISPIELE
-=========
-
- master()->AddWizardForUID("p.waterluh","zook");
-
-
-
- string *uids = master()->AddWizardForUID("jof","zook");
- printf("Zook ist nun explizit zustaendig fuer: %s\n",CountUp(uids));
-
-
-SIEHE AUCH
-==========
-
- QueryWizardsForUID(), QueryUIDsForWizard,
- RemoveWizardFromUID()
-
-20.02.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/master/QueryUIDAlias b/doc/sphinx/man/lfun/master/QueryUIDAlias
deleted file mode 100644
index 8f58509..0000000
--- a/doc/sphinx/man/lfun/master/QueryUIDAlias
+++ /dev/null
@@ -1,65 +0,0 @@
-
-QueryUIDAlias()
-***************
-
-
-FUNKTION
-========
-
- varargs string* QueryUIDsForWizard(string uidalias, int recursive);
-
-
-DEFINIERT IN
-============
-
- /secure/master/userinfo.c
-
-
-ARGUMENTE
-=========
-
- uidalias
- UID, die expandiert werden soll.
- recursive (optional)
- Gibt an, ob QueryUIDAlias() (indirekt) rekursiv aufgerufen wurde.
- Sollte normalerweise nicht per Hand gesetzt werden.
-
-
-BESCHREIBUNG
-============
-
- Die Funktion ermittelt aus einer "Alias-UID" die UID, fuer die sie steht.
- Hierbei werden folgende UID-Aliase beruecksichtigt:
- "region": d.region.* + region + d.region
- "gilde": GUILD.gilde, GUILD.gildenspellbook, p.gilde
- "p": p.* (ohne p.service)
- "p.service": p.service.*
- "magierid": QueryUIDsForWizard()
-
- Das Ergebnis dieser Funktion wird laengere Zeit gecachet (bis zu 24h).
-
-
-RUeCKGABEWERT
-=============
-
- Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID.
- Sollte uidaliase keines der o.g. sein, wird ein ({uidalias}) geliefert.
-
-
-BEISPIELE
-=========
-
- string *uids = master()->QueryUIDAlias("schattenwelt");
- // uids enthaelt nun:
- // ({"d.anfaenger","anfaenger","d.anfaenger.ark","d.anfaenger.ennox",
- // "d.anfaenger.humni","d.anfaenger.kiria","d.anfaenger.konzepte",
- // "d.anfaenger.miril"})
-
-
-SIEHE AUCH
-==========
-
- QueryWizardsForUID(),
- AddWizardForUID(), RemoveWizardFromUID()
-
-16.12.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/master/QueryUIDsForWizard b/doc/sphinx/man/lfun/master/QueryUIDsForWizard
deleted file mode 100644
index e0d5816..0000000
--- a/doc/sphinx/man/lfun/master/QueryUIDsForWizard
+++ /dev/null
@@ -1,64 +0,0 @@
-
-QueryUIDsForWizard()
-********************
-
-
-FUNKTION
-========
-
- varargs string* QueryUIDsForWizard(string wizname, int recursive);
-
-
-DEFINIERT IN
-============
-
- /secure/master/userinfo.c
-
-
-ARGUMENTE
-=========
-
- wizname
- Der Magier, fuer den man die UIDs ermitteln will, fuer die er
- zustaendig ist.
- recursive (optional)
- Gibt an, ob QueryUIDsForWizard() (indirekt) rekursiv aufgerufen wurde.
- Sollte normalerweise nicht per Hand gesetzt werden.
-
-
-BESCHREIBUNG
-============
-
- Die Funktion ermittelt die UIDs, fuer die dieser Magier zustaendig ist.
- Dabei wird impliziert beruecksichtigt, wenn der Magier RM einer Region
- oder Gildenmagier einer Gilde ist, ebenso wie Verzeichnisse in den
- Regionen oder in /p/service.
- Ausserdem wird nachgeschaut, fuer welche UIDs dieser Magier explizit
- eingetragen worden ist.
- Wenn z.B. Magier A auch fuer alle UIDs von Magier B zustaendig sein
- sollte, liefert die Funktion auch die UIDs von B zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID.
- Sollte fuer einen Namen keine UID ermittelbar sein, ist das Arrays leer.
-
-
-BEISPIELE
-=========
-
- string *uids = master()->QueryUIDsForWizard("ennox");
- // uids enthaelt nun:
- // ({"ennox","d.anfaenger.ennox","d.schattenwelt.ennox",
- // "p.service.ennox","GUILD.chaos","p.chaos"})
-
-
-SIEHE AUCH
-==========
-
- QueryWizardsForUID(),
- AddWizardForUID(), RemoveWizardFromUID()
-
-16.12.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/master/QueryWizardsForUID b/doc/sphinx/man/lfun/master/QueryWizardsForUID
deleted file mode 100644
index 6ddbdc3..0000000
--- a/doc/sphinx/man/lfun/master/QueryWizardsForUID
+++ /dev/null
@@ -1,71 +0,0 @@
-
-QueryWizardsForUID()
-********************
-
-
-FUNKTION
-========
-
- varargs string* QueryWizardsForUID(string uid, int recursive);
-
-
-DEFINIERT IN
-============
-
- /secure/master/userinfo.c
-
-
-ARGUMENTE
-=========
-
- uid
- Die UID, fuer die man die Magier ermitteln will, die fuer sie
- zustaendig sind.
- recursive (optional)
- gibt an, ob das QueryWizardsForUID() (indirekt) aus einem
- QueryWizardsForUID() heraus gerufen wurde. Sollte nicht manuell gesetzt
- werden.
-
-
-BESCHREIBUNG
-============
-
- Die Funktion ermittelt die Magier, die fuer diese UID zustaendig sind.
-
-
-RUeCKGABEWERT
-=============
-
- Zurueckgeliefert wird ein Array von Strings, jedes Element ist ein Magier.
- Sollte fuer eine UID kein Magier ermittelbar sein, ist das Array leer.
- Wenn z.B. fuer die UID der Magier "Atamur" gefunden wird, aber fuer alle
- UIDs von "Atamur" auch der Magier "Rumata" zustaendig sein sollte, wird
- "Rumata" ueber eine rekursive Suche gefunden.
-
-
-BEMERKUNGEN
-===========
-
- Wenn die UID den Magier nicht implizit enthaelt (z.B. GUILD.gilde, im
- Gegensatz zu d.region.magier), findet diese Funktion nur Magier, fuer die
- seit Laden des Master bereits einmal get_userinfo() oder
- QueryUIDsForWizard() im Master gerufen wurde, was z.B. Einloggen passiert.
- Magier, die lang nicht einloggten, werden also manchmal nicht gefunden,
- was in der Regel nicht schlimm sein sollte, da sie ja ohnehin den
- entsprechenden Code gerade nicht warten...
-
-
-BEISPIELE
-=========
-
- string *wiz = master()->QueryWizards("GUILD.klerus");
- // wiz enthaelt nun: ({"morgoth","magdalena"})
-
-
-SIEHE AUCH
-==========
-
- QueryUIDsForWizard(),
- AddWizardForUID(), RemoveWizardFromUID()
-
-16.12.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/master/RemoveWizardFromUID b/doc/sphinx/man/lfun/master/RemoveWizardFromUID
deleted file mode 100644
index 1fdeba5..0000000
--- a/doc/sphinx/man/lfun/master/RemoveWizardFromUID
+++ /dev/null
@@ -1,62 +0,0 @@
-
-RemoveWizardFromUID()
-*********************
-
-
-FUNKTION
-========
-
- string* RemoveWizardFromUID(string uid, string wizard);
-
-
-DEFINIERT IN
-============
-
- /secure/master/userinfo.c
-
-
-ARGUMENTE
-=========
-
- uid
- Die UID, fuer die man einen zustaendigen Magier austragen will.
- wizard
- Der Magier, den man austragen moechte.
-
-
-BESCHREIBUNG
-============
-
- Die Funktion loescht die UID 'uid' aus der Liste der UIDs, fuer die
- 'wizard' explizit zustaendig ist.
-
- Berechtigt zum Austragen von Magiern fuer bestimmte UIDs sind alle Magier,
- die (implizit oder explizit) verantwortlich fuer die jeweilige UID sind.
- Man kann sich auch selber austragen. ;-)
-
-
-RUeCKGABEWERT
-=============
-
- Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID,
- fuer die dier Magier jetzt explizit eingetragen ist.
-
-
-BEISPIELE
-=========
-
- master()->RemoveWizardFromUID("p.waterluh","zook");
-
-
-
- string *uids = master()->RemoveWizardFromUID("jof","zook");
- printf("Zook ist nun explizit zustaendig fuer: %s\n",CountUp(uids));
-
-
-SIEHE AUCH
-==========
-
- QueryWizardsForUID(), QueryUIDsForWizard()
- AddWizardForUID()
-
-20.02.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/match_ids b/doc/sphinx/man/lfun/match_ids
deleted file mode 100644
index 48f368f..0000000
--- a/doc/sphinx/man/lfun/match_ids
+++ /dev/null
@@ -1,69 +0,0 @@
-
-match_ids()
-***********
-
-
-FUNKTION
-========
-
- int match_ids(string *list);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- *list String-Array mit zu testenden IDs
-
-
-BESCHREIBUNG
-============
-
- Die Liste der uebergebenen IDs wird mit den IDs des Objektes
- UND-Verknuepft. Die Groesse des resultierenden Arrays wird
- zurueckgegeben.
- Diese Funktion erlaubt also das gleichzeitige Pruefen auf
- mehrere IDs. Allerdings werden - im Gegensatz zu id() -
- Adjektive und Ausdruecke der Art "<ID> <nummer>" nicht
- beruecksichtigt.
- Ebenso werden Spezialitaeten wie Unitobjekte und Objekte mit
- ueberschriebenem id() nicht beruecksichtigt! Im Zweifelsfall ist daher
- doch die Nutzung von id() zu empfehlen.
-
-
-RUeCKGABEWERT
-=============
-
- Anzahl der zutreffenden IDs.
-
-
-BEISPIELE
-=========
-
- Angenommen, ein Objekt habe folgende Bezeichner:
-
- AddId( ({"murmel","kugel","glasmurmel","glaskugel"}) );
- AddAdjective( "rund" );
-
- Dann liefern die angegebenen match_ids()-Aufrufe folgende Ergebnisse:
-
- match_ids( ({"murmel","stein"}) ); => 1
- match_ids( ({"murmel","kugel"}) ); => 2
- match_ids( ({"runde murmel"}) ); => 0
- match_ids( ({"murmel 2"}) ); => 0, auch wenn dies die
- zweite Murmel in der
- gleichen Umgebung ist
-
-
-SIEHE AUCH
-==========
-
- AddId(), AddAdjective(), AddSingularId(), AddPluralId(), present(),
- id(), /std/thing/description.c, /std/unit.c
-
-Last modified: Sat Mar 15 21:40:00 2000 by Paracelsus
diff --git a/doc/sphinx/man/lfun/move b/doc/sphinx/man/lfun/move
deleted file mode 100644
index bd9d924..0000000
--- a/doc/sphinx/man/lfun/move
+++ /dev/null
@@ -1,242 +0,0 @@
-
-move()
-******
-
-move()
-
-FUNKTION:
- Fuer unbelebte Gegenstaende (/std/thing):
- varargs int move(object|string dest, int method);
-
- Fuer Lebewesen (/std/living, /std/npc, usw.):
- varargs int move(object|string dest, int method, string dir,
- string textout, string textin);
-
-
-DEFINIERT IN
-============
-
- /std/thing/moving.c
- /std/living/moving.c
-
-
-ARGUMENTE
-=========
-
- dest
- Das Zielobjekt (entweder der Dateiname oder das Objekt selbst).
-
- method
- Die Art der Bewegung (eine der unten aufgefuehrten Arten; es
- koennen auch mehrere zusammenge-ODER-t werden).
-
- dir
- Die Richtung, in die ein Lebewesen geht. Normalerweise ist das die
- eingeschlagene Laufrichtung (zB. "nach Norden").
-
- textout
- Verlaesst ein Lebewesen einen Raum, so wird diese Meldung in den
- Raum geschickt. Ist bei dir ein String angegeben, so wird dieser
- noch an textout angehaengt. Der Name des Lebewesens wird der
- Meldung in jedem Fall vorangestellt.
-
- textin
- Dieser Text wird im Zielraum ausgegeben, wenn ein Lebewesen ihn
- betritt. Bei normaler Fortbewegung ist das "kommt an". Dem Text
- wird noch der Name des Spielers vorangestellt.
-
-
-BESCHREIBUNG
-============
-
- Es wird versucht, das Objekt in das Zielobjekt dest zu bewegen.
- Abhaengig vom momentanen Aufenthaltsort und dem Zielobjekt ist die
- Bewegungsmethode method zu waehlen.
-
- In <moving.h> sind folgende Konstanten fuer die Art der Bewegung
- definiert:
- M_NOCHECK
- Es werden keine Abfragen durchgefuehrt, ob das Objekt ueberhaupt
- in das Zielobjekt hineinpasst (was zB. aus Gewichtsgruenden der
- Fall sein koennte).
-
- M_GO
- Ein Lebewesen bewegt sich gehend von einem Raum in den naechsten.
- Bei normalem Gehen wird diese Methode benutzt; man sollte sie auch
- benutzen, wenn man Spieler ueber einen SpecialExit in einen
- benachbarten Raum bewegt.
-
- M_TPORT
- Ein Lebewesen wird von einem Raum in einen anderen teleportiert.
- Im Gegensatz zu M_GO kann ein Raum verhindern, dass man ihn
- mittels M_TPORT verlaesst oder betritt.
-
- M_NO_SHOW
- Beim Bewegen von Lebewesen bekommen diese die Beschreibung des
- Zielraumes nicht ausgegeben.
-
- M_NO_ATTACK
- Beim Bewegen von Lebewesen bekommen diese keinen
- Begruessungsschlag, wenn ein Feind im Zielraum steht.
-
- M_SILENT
- Es werden beim Bewegen keine Meldungen ausgegeben. Dieser
- Parameter wirkt sich nur auf das Bewegen von Lebenwesen aus.
-
- M_GET
- Das Objekt wird von einem unbelebten Objekt (zB. einem Raum, einer
- Leiche, einem Beutel) in ein lebendes Objekt (Spieler oder NPC)
- bewegt.
-
- M_PUT
- Das Objekt wird von einem lebenden Objekt in ein unbelebtes Objekt
- bewegt.
-
- M_GIVE
- Das Objekt wird von einem Lebewesen an ein anderes Lebewesen
- weitergereicht.
-
- M_MOVE_ALL (Nur fuer Objekte, die /std/unit.c erben)
- Es wird die gesamte Menge bewegt, nicht nur ein Teil.
-
- Soll das Objekt auf jeden Fall und ohne jede Abfrage bewegt werden, so
- reicht es, als method M_NOCHECK zu uebergeben.
-
- Waffen und Ruestungen werden, soweit sie gezueckt bzw. angezogen sind,
- beim Bewegen auf jeden Fall weggesteckt bzw. ausgezogen. Ist in method
- M_SILENT enthalten, so geschieht dies ohne Meldungen.
-
- Die erste Art des Funktionsaufrufs ist sowohl beim Bewegen von
- Lebewesen als auch von unbelebten Objekten moeglich. Die zweite Art
- laesst sich nur bei Lebewesen anwenden.
-
-
-ANMERKUNG
-=========
-
- Diese Funktion sollte nicht (mehr) ueberschrieben werden. Stattdessen
- greift bitte auf PreventMove() und NotifyMove() zurueck. RMs sind
- aufgerufen, Objekt mit ueberschriebenen move() nur noch dann
- anzuschliessen, wenn der Zweck sonst nicht erreicht werden kann. Solltet
- ihr move() ueberschreiben: Seid euch sehr genau im klaren, was move()
- genau macht. ;-)
-
-
-
- Wenn Livings bewegt werden, sorgt move() automatisch in Abhaengigkeit
- von P_PARA dafuer, dass das Lebewesen in der korrekten (Parallel-)Welt
- landet.
-
- Bei Gegenstaenden wird ebenfalls versucht, die richtige Zielwelt
- auszuwaehlen (damit z.B. in der Parallelwelt geworfene Bumerangs auch nur
- innerhalb der Parallelwelt fliegen). Um Rechenzeit zu sparen, wird das
- allerdings nur versucht, wenn 'dest' ein Filename ist und kein Objekt.
-
- Grund: bei Zielobjekten handelt es sich meist um Bewegungen in das Inv
- oder Env eines Spielers - und die sind uninteressant. Raumwechsel dagegen
- erfolgen fast immer unter Angabe eines Filenamens anstatt eines Objektes.
-
-
-RUeCKGABEWERT
-=============
-
- Alle Rueckgabewerte sind als symbolische Konstanten in <moving.h>
- definiert. (MOVE_OK ist 1, alle anderen sind <0 und symbolisieren Fehler.
- Traditionell erfolgt die Pruefung auf erfolgreiches Move mit == 1, in
- Zukunft wird == MOVE_OK empfohlen.)
-
-
-
- MOVE_OK
- Die Bewegung wurde erfolgreich abgeschlossen.
-
- ME_PLAYER
- Lebewesen lassen sich nicht ohne weiteres bewegen. Es muss
- mindestens eine der Methoden M_NOCHECK, M_GO oder M_TPORT
- angegeben werden.
-
- ME_TOO_HEAVY
- Das Zielobjekt kann dieses Objekt aus Gewichtsgruenden nicht mehr
- aufnehmen.
-
- ME_CANT_TPORT_IN
- Das Zielobjekt verbietet das Teleportieren in sich hinein (nur bei
- M_TPORT ohne M_NOCHECK).
-
- ME_CANT_TPORT_OUT
- Der Raum, in dem sich das Lebewesen befindet, verbietet das
- Teleportieren aus sich hinaus (nur bei M_TPORT ohne M_NOCHECK).
-
- ME_CANT_BE_DROPPED
- Das Objekt kann nicht fallen gelassen werden (zB. weil P_NODROP
- gesetzt ist).
-
- ME_CANT_BE_TAKEN
- Das Objekt kann nicht genommen werden (zB. weil P_NOGET gesetzt
- ist).
-
- ME_CANT_BE_INSERTED
- Das Zielobjekt verhindert das Einfuegen aus bestimmten Gruenden.
-
- ME_CANT_LEAVE_ENV
- Der Container verhindert ein verlassen des Objektes
-
- ME_TOO_HEAVY_FOR_ENV
- Ein Objekt kann einen Behaelter nicht verlassen, da es dem
- Lebewesen sonst zu schwer wuerde.
-
- TOO_MANY_OBJECTS
- Das Zielobjekt kann soviele Objekte nicht mehr aufnehmen.
-
- ME_NOT_ALLOWED
- Raeume mit gesetzter Property P_NO_PLAYERS koennen nur von
- Testspielern und Magiern betreten werden. Bei Spielern oder
- Gildentesties gibt es diese Fehlermeldung.
- ME_WAS_DESTRUCTED
- Das Objekt hat sich entweder im Verlaufe der Bewegung selbst
- zerstoert oder wurde zerstoert, sodass move() nicht erfolgreich
- beendet werden konnte. (Bsp: sensitive Objekte)
-
- ME_DONT_WANT_TO_BE_MOVED
- Das Objekt moechte nicht bewegt werden.
-
-
-BEISPIELE
-=========
-
- o Ein Objekt "gibt sich" dem Spieler:
-
- move(this_player(), M_GET);
-
- o Ein Lebewesen wird in die Abenteurergilde teleportiert:
-
- lv->move("/gilden/abenteurer", M_TPORT);
-
- o Ein Spieler "wird in die Gilde gegangen":
-
- this_player()->move("/gilden/abenteurer", M_GO, "in die Gilde");
-
- Spieler, die mit ihm im gleichen Raum stehen, sehen folgende
- Meldung:
- "<name> geht in die Gilde."
-
- o Ein Spieler schwimmt durchs Meer:
-
- this_player()->move("meer_xy", M_GO, "nach Norden", "schwimmt",
- "schwimmt herein");
-
- Spieler in seinem Startraum sehen "<name> schwimmt nach Norden.",
- Spieler in seinem Zielraum sehen "<name> schwimmt herein."
-
-
-SIEHE AUCH
-==========
-
- move_object(), remove(), setmin, setmmin, setmout, setmmout, review,
- PreventInsert(), PreventLeave(), PreventInsertLiving(),
- PreventLeaveLiving(), PreventMove(), NotifyInsert(), NotifyLeave(),
- NotifyMove(), NotifyRemove(), init(), exit(),
- P_NO_PLAYERS, P_PARA, /std/thing/moving.c, /std/living/moving.c
- -----------------------------------------------------------------------
-
-2015-Jan-19, Arathorn
diff --git a/doc/sphinx/man/lfun/moved_objects b/doc/sphinx/man/lfun/moved_objects
deleted file mode 100644
index 8a5b536..0000000
--- a/doc/sphinx/man/lfun/moved_objects
+++ /dev/null
@@ -1,52 +0,0 @@
-
-moved_objects()
-***************
-
-
-FUNKTION
-========
-
- public object *moved_objects(void);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion lassen sich die Objekte ermitteln, die das Lebewesen
- beim letzten Aufruf von drop_objects(L) oder einer aehnlichen Funktion
- bewegt hat.
-
-
-RUECKGABEWERT
-=============
-
- Array mit den zuletzt bewegten Objekten, oder ein leeres Array, falls
- keine Objekte auf die Beschreibung des letzten drop_objects() /
- pick_objects() / put_objects() / give_objects() passten.
-
-
-BEISPIELE
-=========
-
- siehe drop_objects() und give_objects()
-
-
-SIEHE AUCH
-==========
-
- drop_objects(L), give_objects(L), pick_objects(L), put_objects(L),
- show_objects(L), NotifyMove(L)
-
-Last modified: Thu Aug 28 22:19:26 2008 by Amynthor
diff --git a/doc/sphinx/man/lfun/moved_where b/doc/sphinx/man/lfun/moved_where
deleted file mode 100644
index 640acae..0000000
--- a/doc/sphinx/man/lfun/moved_where
+++ /dev/null
@@ -1,50 +0,0 @@
-
-moved_where()
-*************
-
-
-FUNKTION
-========
-
- public object moved_where(void);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Funktion laesst sich ermitteln, wohin das Lebewesen zuletzt
- mittels put_objects(L) oder give_objects(L) etwas bewegt oder wem es mit
- show_objects(L) etwas gezeigt hat.
-
-
-RUECKGABEWERT
-=============
-
- Der Container oder das Lebewesen, wohin die Gegenstaende bewegt wurden.
-
-
-BEISPIEL
-========
-
- siehe give_objects()
-
-
-SIEHE AUCH
-==========
-
- put_objects(L), give_objects(L), show_objects(L), NotifyInsert(L),
- P_LAST_CONTENT_CHANGE
-
-Last modified: Thu Aug 28 22:16:15 2008 by Amynthor
diff --git a/doc/sphinx/man/lfun/muster b/doc/sphinx/man/lfun/muster
deleted file mode 100644
index aa7279c..0000000
--- a/doc/sphinx/man/lfun/muster
+++ /dev/null
@@ -1,33 +0,0 @@
-
-muster()
-********
-
-
-FUNKTION
-========
-
- type muster(...)
-
-
-ARGUMENTE
-=========
-
-
-BESCHREIBUNG
-============
-
-
-RUECKGABEWERT
-=============
-
-
-BEMERKUNG
-=========
-
-
-BEISPIEL
-========
-
-
-SIEHE AUCH
-==========
diff --git a/doc/sphinx/man/lfun/name b/doc/sphinx/man/lfun/name
deleted file mode 100644
index 3509366..0000000
--- a/doc/sphinx/man/lfun/name
+++ /dev/null
@@ -1,81 +0,0 @@
-
-name()
-******
-
-name()|Name()
-
-
-FUNKTION
-========
-
- varargs string name(int casus, int demon);
- varargs string Name(int casus, int demon);
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- casus
- Der Fall, in dem der Name dekliniert werden soll.
- demon
- Gibt an, ob der Name mit bestimmtem oder unbestimmtem Artikel
- versehen werden soll:
- + demon = 0: Unbestimmter Artikel.
- + demon = 1: Bestimmter Artikel.
- + demon = 2: Finde selbst heraus, ob ein bestimmter oder ein
- unbestimmter Artikel verwendet werden soll.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ermittelt den Namen des Objektes im gewuenschten Fall
- und mit dem angegebenen Artikel. Moegliche Werte fuer casus sind in
- <thing/language.h> definiert. Weiterhin werden auch (falls angegeben)
- die Namensadjektive dekliniert und in den Namen eingebaut.
-
- Name() ist ein Alias fuer capitalize(name()), der Artikel wird also
- gross geschrieben.
-
-
-RUeCKGABEWERT
-=============
-
- String mit dem Namen des Objektes.
-
-
-BEMERKUNGEN
-===========
-
- Falls P_ARTICLE gesetzt ist, werden weder Artikel noch Namensadjektive
- in den Namen eingebaut.
-
- Wenn man als casus RAW angibt, wird der Name im Nominativ ohne Artikel
- und Namensadjektive zurueckgegeben.
-
-
-BEISPIELE
-=========
-
- Wenn das Objekt ein Ball mit P_NAME="Ball" und P_NAME_ADJ="klein" ist,
- so liefern die folgenden Aufrufe die angegebenen Ergebnisse:
-
- name(WER,0); => "ein kleiner Ball"
- name(WESSEN,1); => "des kleinen Balls"
- name(RAW); => "Ball"
- name(WEM,2); => "einem kleinen Ball" oder "dem kleinen Ball",
- abhaengig davon, wieviele Baelle gerade da sind.
-
-
-SIEHE AUCH
-==========
-
- /std/thing/description.c, Name()
-
-Letzte Aenderung: 29.07.2016, Bugfix
diff --git a/doc/sphinx/man/lfun/notify_player_change b/doc/sphinx/man/lfun/notify_player_change
deleted file mode 100644
index 34c4024..0000000
--- a/doc/sphinx/man/lfun/notify_player_change
+++ /dev/null
@@ -1,82 +0,0 @@
-
-notify_player_change()
-**********************
-
-void notify_player_change(string/object who, int rein [, int invis])
-
-
-FUNKTION
-========
-
- void /notify_player_change(object who, int rein)
- void /std/player/base::notify_player_change(string who, int rein,
- int invis)
-
-
-GERUFEN VON
-===========
-
- /std/player/base.c (d.h. alle Spielershells/-Objekte)
-
-
-ARGUMENTE
-=========
-
- string who
- getuid() eines Spielers
- object who
- Spieler-Objekt
- int rein
- 0 fuer das MUD verlassende, 1 fuer hereinkommende Spieler
- int invis
- 1 fuer unsichtbare Spieler (Magier)
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird von Lebewesen fuer hereinkommende und das Spiel
- verlassende Spieler an verschiedenen Stellen aufgerufen:
-
-
-
- * in anderen Spielern mit notify_player_change() mit drei Parametern
- - dies dient fuer die "erwarte"-Funktionalitaet
- * in der Gilde des Spielern mit zwei Parameter
- - damit koennen Gilden notwendige Anpassungen vornehmen
-
- Diese Funktionen werden auch gerufen, wenn Magier "invis -e" bzw.
- "vis e" benutzen.
-
-
-BEISPIELE
-=========
-
- // in einer Gilde:
- void notify_player_change(object pl, int rein) {
- if (rein && objectp(pl)) {
- // Checks, ob Spielerskills in Ordnung sind
- mapping bete = pl->QuerySkill("bete");
-
-
-
- if (!mappingp(bete)) {
- if (IS_LEARNER(pl) || pl->QueryProp(P_TESTPLAYER)) {
- tell_object(pl, break_string(
- "Du bist ein kaputter Test-Kleriker ...", 78,
- "Arkshat teilt dir mit: "));
- // notduerftige Reparaturen
- } else
- raise_error("Klerus: Kaputter oder gesetzer Kleriker!\n");
- }
- }
- }
-
-
-SIEHE AUCH
-==========
-
- RegisterEvent mit (EVT_LIB_LOGIN, EVT_LIB_LOGOUT)
- erwarte
-
-1. Sep 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/obsolete/AddHpHook b/doc/sphinx/man/lfun/obsolete/AddHpHook
deleted file mode 100644
index 5a2adce..0000000
--- a/doc/sphinx/man/lfun/obsolete/AddHpHook
+++ /dev/null
@@ -1,52 +0,0 @@
-
-AddHpHook()
-***********
-
-********************* OBSOLETE LFUN
-*********************************** * Diese Efun bitte nicht mehr
-benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
-* *******************************************************************
-**** AddHpHook()
-
-
-FUNKTION
-========
-
- int AddHpHook(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/player/life.c
-
-
-ARGUMENTE
-=========
-
- ob - das Objekt, das sich eintragen moechte.
-
-
-BESCHREIBUNG
-============
-
- Traegt ein Objekt in P_HP_HOOKS ein, wenn es nicht schon darin steht.
-
- Aendern sich beim Spieler dann HP oder KP (nicht durch Set()), wird
- an allen eingetragenen Objekten NotifyHpChange() gerufen.
-
-
-RUECKGABEWERT
-=============
-
- 1, wenn Erfolg, 0 sonst
-
-
-SIEHE AUCH
-==========
-
- Gegenpart: RemoveHpHook()
- Props: P_HP_HOOKS, P_HP
- Verwandt: reduce_hit_points(), do_damage(), buffer_hp()
-
-23.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/lfun/obsolete/AddInsertHook b/doc/sphinx/man/lfun/obsolete/AddInsertHook
deleted file mode 100644
index 9a372ba..0000000
--- a/doc/sphinx/man/lfun/obsolete/AddInsertHook
+++ /dev/null
@@ -1,85 +0,0 @@
-
-AddInsertHook()
-***************
-
-********************* OBSOLETE LFUN
-*********************************** * Diese Efun bitte nicht mehr
-benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
-* *******************************************************************
-**** AddInsertHook()
-
-
-FUNKTION
-========
-
- void AddInsertHook(object ob);
-
-
-DEFINIERT IN
-============
-
- /std/player/restrictions.c
-
-
-ARGUMENTE
-=========
-
- ob - Das Objekt, das informiert werden soll, wenn ein Objekt dem
- Spielerinventar hinzugefuegt wurde.
-
-
-BESCHREIBUNG
-============
-
- (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
- H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
- vorhanden.)
-
- Diese Funktion wird im Spielerobjekt aufgerufen, um das Objekt ob als
- Hook-Listener anzumelden. Auf diese Weise eingetragene Listener
- werden informiert, wenn ein Objekt ins Spielerinventar bewegt wurde.
- Technisch wird die Bewegung ueber NotifyInsert() im Spielerobjekt
- detektiert, und im Listener-Objekt wird die Funktion InsertNotify()
- gerufen, die als Parameter das neu ins Spielerinventar bewegte Objekt
- uebergeben bekommt.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Das Listener-Objekt muss sich ebenfalls im Spielerinventar befinden,
- ansonsten wird der eingetragene Hook wieder geloescht.
-
-
-BEISPIEL
-========
-
- a) Objekt "ob" wird im Spieler als Listener angemeldet:
- this_player()->AddInsertHook(ob);
-
- b) Objekt "new" wird ins Spielerinventar bewegt, das Spielerobjekt
- informiert "ob" darueber:
- ob->InsertNotify(new);
-
- c) Das Listener-Objekt "ob" reagiert darauf, z.B. indem es die Fackel
- loescht, sofern sie vorher brannte:
- void InsertNotify(object new) {
- if ( objectp(new) && new->id("\nfackel") &&
- new->QueryProp(P_LIGHTED) )
- new->unlight();
- return;
- }
-
-
-SIEHE AUCH
-==========
-
- NotifyInsert(), RemoveInsertHook(), QueryInsertHooks()
-
-Last modified: 14.04.2010, Arathorn
diff --git a/doc/sphinx/man/lfun/obsolete/ModifySkillAttributeOld b/doc/sphinx/man/lfun/obsolete/ModifySkillAttributeOld
deleted file mode 100644
index b0b81ab..0000000
--- a/doc/sphinx/man/lfun/obsolete/ModifySkillAttributeOld
+++ /dev/null
@@ -1,118 +0,0 @@
-
-ModifySkillAttributeOld()
-*************************
-
-
-FUNKTION
-========
-
- varargs int ModifySkillAttributeOld(object caster, string atrname,
- int value, int duration, mixed fun)
-
-
-DEFINIERT IN
-============
-
- /std/living/skill_attributes.c
-
-
-ARGUMENTE
-=========
-
- <caster> IGNORIERT
- frueher Objekt, das die Modifikation vornimmt, heute ist
- dieses Argument ohne Bedeutung und wird ignoriert.
-
- <atrname> STRING
- Name des zu veraendernden Attributes
- (Definiert in /sys/living/skill_attributes.h)
-
- <value> INT
- Neuer Wert des Attributs (Standard: 100)
-
- <duration> INT
- Dauer in Sekunden
-
- <fun> NICHT MEHR UNTERSTUETZT - ModifySkillAttribute() nutzen!!
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion existiert nur aus Kompatibilitaetsgruenden. Bitte in neuen
- Objekten NICHT mehr verwenden und in alten nach Moeglichkeit ausbauen!
-
- Aendert ein Skill-Attribut eines Living.
-
-
-
- Fuer <value> ist folgendes zu beachten:
- Frueher handelte es sich um einen multiplikativen Faktor. 100 hatte die
- Bedeutung von 1 und veraenderte nichts. Heute sind die Modifikatoren
- additiv. Diese Funktion macht eine einfache Umrechnung, indem sie vom hier
- uebergeben Wert 100 abzieht. (In der Annahme, dass frueher meist eh nur
- ein Modifikator zur gleichen Zeit aktiv war.)
- Gibt man hier also hier eine 100 an, wird ein Modifikator von 0 einge-
- tragen, der nichts aendert, bei 200 wird ein Modifikator von 100 einge-
- tragen, bei 50 einer von -50, welcher das Skillattribute folglich
- reduziert.
-
- Es sind momentan max. 5 gleichzeitige Skillattribute-Modifikatoren pro SA
- zulaessig.
-
-
-RUECKGABEWERT
-=============
-
- 0 wenn der Wert ungueltig ist oder aus sonstigem Grunde nicht gesetzt
- werden konnte (fuer bessere Diagnostik -> ModifySkillAttribute()).
- >0 wenn alles okay war
-
-
-BEMERKUNGEN
-===========
-
- Frueher musste ein setzendes Objekt ein groesseres P_LEVEL haben als das
- Objekt, welches einen vorherigen Modifikator gesetzt hat, um diesen zu
- ueberschreiben. Dies ist inzwischen ohne Bedeutung.
-
-
-BEISPIELE
-=========
-
- Ein NPC:
-
- void
- create() {
- .
- .
- .
- AddSpell(1, 1,
- "Der fuerchterliche NPC haut Dir auf den Kopf.\n",
- "Der fuerchterliche NPC haut @WEN auf den Kopf.\n",
- DT_MAGIC, "schwaechen");
- .
- .
- }
-
- schwaechen(object enemy, int damage, mixed *dam_type) {
- int ergebnis;
- ergebnis = enemy->ModifySkillAttributeOld(this_object(), SA_QUALITY, 50, 5);
- if (ergebnis > 0)
- tell_object(enenmy, "Du fuehlst Dich ganz schwach.\n");
- }
-
-
-
- Der NPC schwaecht seinen Gegner erheblich! Alles wird fuer 5 Sekunden um
- 50, d.h. 0.5 Skillattribute reduziert (50 - 100 => -50 als Modifikator).
-
-
-SIEHE AUCH
-==========
-
- P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS,
- ModifySkillAttribute, QuerySkillAttribute(),
- RemoveSkillAttributeModifer(), QuerySkillAttributeModifier()
-
-07.08.2008 Zesstra
diff --git a/doc/sphinx/man/lfun/obsolete/NotifyGiveQuest b/doc/sphinx/man/lfun/obsolete/NotifyGiveQuest
deleted file mode 100644
index 220942b..0000000
--- a/doc/sphinx/man/lfun/obsolete/NotifyGiveQuest
+++ /dev/null
@@ -1,62 +0,0 @@
-
-NotifyGiveQuest()
-*****************
-
-********************* OBSOLETE LFUN
-*********************************** * Diese Efun bitte nicht mehr
-benutzen, sondern stattdessen die * * Events (siehe "man
-events"). * ******************
-*****************************************************
-
-NotifyGiveQuest()
-
-
-FUNKTION
-========
-
- void NotifyGiveQuest(object pl, string key);
-
-
-DEFINIERT IN
-============
-
- /std/gilden_ob.c
-
-
-ARGUMENTE
-=========
-
- pl Der Spieler, der eine Quest geloest hat.
- key Name der geloesten Quest.
-
-
-BESCHREIBUNG
-============
-
- Die Funktion wird in der Gilde des Spielers aufgerufen, wenn der
- Spieler eine gueltige Quest besteht - und zwar unabhaengig davon,
- ob er sie bereits geloest hat, oder nicht.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Die Funktion ist dafuer gedacht, von Gildenprogrammierern ueberschrieben
- zu werden, wenn beispielsweise bestimmte Quests als Aufstiegsbedingung
- verlangt werden, diese aber in der entsprechenden Gilde geloest sein
- muessen (z.B. Obergladiator als Level-5-Zauberer).
-
-
-SIEHE AUCH
-==========
-
- /std/gilden_ob.c
- /std/player/quests.c
-
-Last modified: Fri Oct 4 10:17:00 1996 by Silvana
diff --git a/doc/sphinx/man/lfun/obsolete/NotifyHpChange b/doc/sphinx/man/lfun/obsolete/NotifyHpChange
deleted file mode 100644
index 3c96222..0000000
--- a/doc/sphinx/man/lfun/obsolete/NotifyHpChange
+++ /dev/null
@@ -1,71 +0,0 @@
-
-NotifyHpChange()
-****************
-
-********************* OBSOLETE LFUN
-*********************************** * Diese Efun bitte nicht mehr
-benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
-* *******************************************************************
-**** NotifyHpChange()
-
-
-FUNKTION
-========
-
- void NotifyHpChange();
-
-
-DEFINIERT IN
-============
-
- /std/player/life.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Wenn sich die Lebenspunkte eines Spielers aendern, so werden davon
- auch andere Objekte unterrichtet, sofern diese mittels der Funktion
- AddHpHook() bei eben diesem Spieler angemeldet wurden.
- Fortan wird dann die Funktion NotifyHpChange() in diesen
- angemeldeten Objekten aufgerufen, wenn sich die Property P_HP des
- Spielers aendert. Es werden hierbei keine Argumente an
- NotifyHpChange() uebergeben, die aktuellen Lebenspunkte kann man ja
- auch ohne weiteres ueber die Property P_HP in Erfahrung bringen und
- aeltere Werte muss man sich gesondert merken. Zu beachten ist, dass
- die Property P_HP bei Aufruf der Funktion NotifyHpChange() bereits
- den neuen Wert enthaelt.
- Bei dem Spieler angemeldete Objekte, die von Lebenspunkteaenderungen
- informiert werden sollen, werden automatisch aus der Liste entfernt,
- wenn sie zerstoert wurden. Diese Liste ist in der Property
- P_HP_HOOKS zu finden. Per Hand kann man sie auch explizit mittels
- der Funktion RemoveHpHook() entfernen.
- Stirbt ein Spieler, so wird die Funktion NotifyPlayerDeath()
- aufgerufen und nicht NotifyHpChange()!
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- ist in Arbeit
-
-
-SIEHE AUCH
-==========
-
- P_HP, P_HP_HOOKS, AddHpHook(), RemoveHpHook(),
- Defend(), do_damage(), NotifyPlayerDeath()
-
-Last modified: Thu Nov 19 13:54:33 1998 by Patryn
diff --git a/doc/sphinx/man/lfun/obsolete/QueryEnemy b/doc/sphinx/man/lfun/obsolete/QueryEnemy
deleted file mode 100644
index 2613f53..0000000
--- a/doc/sphinx/man/lfun/obsolete/QueryEnemy
+++ /dev/null
@@ -1,51 +0,0 @@
-
-QueryEnemy()
-************
-
-********************* OBSOLETE LFUN
-***********************************
-
-
-FUNKTION
-========
-
- object QueryEnemy();
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUeCKGABEWERT
-=============
-
- gefundener Gegner
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert zufaellig einen der anwesenden Gegner
- zurueck, sofern keine Gegner bevorzugt ausgewaehlt werden.
-
-
-BEMERKUNGEN
-===========
-
- Diese Lfun existiert nicht mehr. Bitte SelectEnemy() benutzen.
-
-
-SIEHE AUCH
-==========
-
- SelectEnemy(), QueryPreferedEnemy(), P_PREFERED_ENEMY
-
-07.02.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/obsolete/QueryInsertHooks b/doc/sphinx/man/lfun/obsolete/QueryInsertHooks
deleted file mode 100644
index 317104c..0000000
--- a/doc/sphinx/man/lfun/obsolete/QueryInsertHooks
+++ /dev/null
@@ -1,52 +0,0 @@
-
-QueryInsertHooks()
-******************
-
-********************* OBSOLETE LFUN
-*********************************** * Diese Efun bitte nicht mehr
-benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
-* *******************************************************************
-**** QueryInsertHooks()
-
-
-FUNKTION
-========
-
- object *QueryInsertHooks();
-
-
-DEFINIERT IN
-============
-
- /std/player/restrictions.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
- H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
- vorhanden.)
-
- Diese Funktion gibt die aktuell beim Spielerobjekt angemeldeten
- Listener-Objekte zurueck.
-
-
-RUeCKGABEWERT
-=============
-
- Array aus Objektpointern oder leeres Array
-
-
-SIEHE AUCH
-==========
-
- NotifyInsert(), AddInsertHook(), RemoveInsertHook()
-
-Last modified: 14.04.2010, Arathorn
diff --git a/doc/sphinx/man/lfun/obsolete/QueryOptQP b/doc/sphinx/man/lfun/obsolete/QueryOptQP
deleted file mode 100644
index 77404ad..0000000
--- a/doc/sphinx/man/lfun/obsolete/QueryOptQP
+++ /dev/null
@@ -1,43 +0,0 @@
-
-QueryOptQP()
-************
-
-
-FUNKTION
-========
-
- int QueryOptQP()
-
-
-DEFINIERT IN
-============
-
- /secure/questmaster.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-RUECKGABEWERT
-=============
-
- Abenteuerpunkte der optionalen Quests
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert die Abenteuerpunkte der optionalen
- Abenteuer zurueck.
-
-
-SIEHE AUCH
-==========
-
- GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
- QueryMaxQP, QueryTotalQP
-
-Zuletzt geaendert: Sam, 25. Nov 2000, 14:04:28 von Zook.
diff --git a/doc/sphinx/man/lfun/obsolete/RemoveHpHook b/doc/sphinx/man/lfun/obsolete/RemoveHpHook
deleted file mode 100644
index 54c93ec..0000000
--- a/doc/sphinx/man/lfun/obsolete/RemoveHpHook
+++ /dev/null
@@ -1,48 +0,0 @@
-
-RemoveHpHook()
-**************
-
-********************* OBSOLETE LFUN
-*********************************** * Diese Efun bitte nicht mehr
-benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
-* *******************************************************************
-**** RemoveHpHook()
-
-
-FUNKTION
-========
-
- int RemoveHpHook(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/player/life.c
-
-
-ARGUMENTE
-=========
-
- ob - das Objekt, das sich austragen moechte.
-
-
-BESCHREIBUNG
-============
-
- Entfernt den Eintrag fuer dieses Objekt in P_HP_HOOKS.
-
-
-RUECKGABEWERT
-=============
-
- 1, wenn Erfolg, 0 sonst
-
-
-SIEHE AUCH
-==========
-
- Gegenpart: AddHpHook()
- Props: P_HP_HOOKS, P_HP
-
-23.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/lfun/obsolete/RemoveInsertHook b/doc/sphinx/man/lfun/obsolete/RemoveInsertHook
deleted file mode 100644
index 6c77edf..0000000
--- a/doc/sphinx/man/lfun/obsolete/RemoveInsertHook
+++ /dev/null
@@ -1,52 +0,0 @@
-
-RemoveInsertHook()
-******************
-
-********************* OBSOLETE LFUN
-*********************************** * Diese Efun bitte nicht mehr
-benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
-* *******************************************************************
-**** RemoveInsertHook()
-
-
-FUNKTION
-========
-
- void RemoveInsertHook(object ob);
-
-
-DEFINIERT IN
-============
-
- /std/player/restrictions.c
-
-
-ARGUMENTE
-=========
-
- ob - Das Objekt, das als Listener aus der Liste ausgetragen werden soll
-
-
-BESCHREIBUNG
-============
-
- (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
- H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
- vorhanden.)
-
- Diese Funktion wird im Spielerobjekt aufgerufen, um ein als Listener
- eingetragenes Hook-Objekt ob wieder auszutragen.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-SIEHE AUCH
-==========
-
- NotifyInsert(), AddInsertHook(), QueryInsertHooks()
-
-Last modified: 14.04.2010, Arathorn
diff --git a/doc/sphinx/man/lfun/obsolete/TestAttributeLock b/doc/sphinx/man/lfun/obsolete/TestAttributeLock
deleted file mode 100644
index 3d5d54d..0000000
--- a/doc/sphinx/man/lfun/obsolete/TestAttributeLock
+++ /dev/null
@@ -1,47 +0,0 @@
-
-TestAttributeLock()
-*******************
-
-********************* OBSOLETE LFUN
-*********************************** TestAttributeLock()
-
-
-FUNKTION
-========
-
- string TestAttributeLock(mapping check)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-PARAMETER
-=========
-
- check - Mapping mit Attributen: ([<attr>:<wert>])
-
-
-BESCHREIBUNG
-============
-
- Prueft, ob eines der im Mapping enthaltenen Attribute blockiert
- ist (bereits durch einen anderen Modifier belegt wurde).
-
-
-
- Da Modifier nicht mehr direkt blockieren ist diese Funktion obsolet
- und in Livings inzwischen nicht mehr existent.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-11.05.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/obsolete/extra_look b/doc/sphinx/man/lfun/obsolete/extra_look
deleted file mode 100644
index d8e9703..0000000
--- a/doc/sphinx/man/lfun/obsolete/extra_look
+++ /dev/null
@@ -1,32 +0,0 @@
-
-extra_look()
-************
-
-********************* VERALTETE LFUN ****************************** *
-Diese LFUN ist veraltet. Bitte benutzt sie NICHT mehr, sondern * *
-stattdessden AddExtraLook(). *
-*******************************************************************
-
-extra_look()
-
-
-FUNKTION
-========
-
- string extra_look();
-
-
-BESCHREIBUNG
-============
-
- Kann in Objekt definiert sein. Wenn ein Living (std/living/description)
- das Objekt enthaelt, wird zu dessen long() der zurueckgegebene String
- hinzugefuegt.
-
-
-SIEHE AUCH
-==========
-
- AddExtraLook()
-
-25.Jan 2015 Gloinson
diff --git a/doc/sphinx/man/lfun/obsolete/paramove b/doc/sphinx/man/lfun/obsolete/paramove
deleted file mode 100644
index 25ce252..0000000
--- a/doc/sphinx/man/lfun/obsolete/paramove
+++ /dev/null
@@ -1,66 +0,0 @@
-
-paramove()
-**********
-
-
-FUNKTION
-========
-
- int paramove();
-
-
-DEFINIERT IN
-============
-
- /std/room/para.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Bewegt den Spieler ggf. in eine Paralleldimension.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn der Spieler die Dimension gewechselt hat.
-
-
-BEISPIEL
-========
-
- init(){
- if(!paramove()) ::init();
- }
-
-
-BEMERKUNGEN
-===========
-
- DIESE FUNKTION NICHT MEHR BENUTZEN!
-
- Diese Funktion sollte nur aus einem init() aufgerufen werden!
-
- Fuer die Entscheidung, in welchem Raum ein Spieler in Abhaengigkeit
- von P_PARA landet, ist die Funktion move() zustaendig. Als Magier
- muss man sich darum nicht gesondert kuemmern. Das heisst aber auch,
- dass beim Anschluss eines Normalweltraumes automatisch alle in dem
- Verzeichnis mit gleichem Namen vorhandenen Parallelweltraeume mit
- angeschlossen werden.
-
- Deswegen ist paramove() veraltet und sollte nicht mehr genutzt werden.
-
-
-SIEHE AUCH
-==========
-
- /std/room/para.c, P_PARA, P_NO_PLAYERS, move
-
-Last modified: 05.08.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/pick b/doc/sphinx/man/lfun/pick
deleted file mode 100644
index 5063ee6..0000000
--- a/doc/sphinx/man/lfun/pick
+++ /dev/null
@@ -1,73 +0,0 @@
-
-pick()
-******
-
-
-FUNKTION
-========
-
- public varargs int pick(object o, mixed msg);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- object o
- Das Objekt, das aufgehoben werden soll.
- mixed msg
- Eine optionale Meldung, die anstelle von P_PICK_MSG oder der
- Standardmeldung verwendet wird, oder -1, um die Meldung zu
- unterdruecken.
-
-
-BESCHREIBUNG
-============
-
- Der Spieler oder NPC nimmt das Objekt auf. Gibt o->move() keinen positiven
- Wert zurueck, beispielsweise weil das Objekt zu schwer ist oder nicht
- genommen werden darf, bekommt er eine entsprechende Fehlermeldung.
-
-
-RUECKGABEWERT
-=============
-
- Wenn das Aufnehmen geklappt hat, 1, ansonsten 0.
-
-
-BEMERKUNG
-=========
-
- Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt
- aufnehmen lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
- moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
- manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
-
- Die Funktion prueft nicht, ob sich das Objekt ueberhaupt in der Reichweite
- des Spielers/NPC befindet, das muss man ggf. selbst ermitteln.
-
-
-BEISPIEL
-========
-
- ob = clone_object(WEINGUMMI);
-
- if (this_player()->pick(ob, ({ "Du nimmst @WENU2 aus dem Regal.",
- "@WER1 nimmt @WENU2 aus dem Regal." })))
- weingummi--;
- else
- ob->remove();
-
-
-SIEHE AUCH
-==========
-
- move(L), P_PICK_MSG, pick_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
- P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOGET
-
-Last modified: Thu Aug 28 22:21:41 2008 by Amynthor
diff --git a/doc/sphinx/man/lfun/pick_obj b/doc/sphinx/man/lfun/pick_obj
deleted file mode 100644
index 6557cee..0000000
--- a/doc/sphinx/man/lfun/pick_obj
+++ /dev/null
@@ -1,43 +0,0 @@
-
-pick_obj()
-**********
-
-
-FUNKTION
-========
-
- int pick_obj(object ob)
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- ob Das Objekt, das genommen werden soll.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion aufgerufen werden soll, hebt
- den angegebenen Gegenstand (ob) auf, falls es ihm moeglich ist.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Objekt genommen wurde oder dies nicht moeglich war. (in diesem
- Fall wird auch direkt eine Textausgabe ausgegeben)
- 0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
- plaziert
-
-
-SIEHE AUCH
-==========
-
- drop_obj(), find_obs(), give_obj(), put_obj(), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/lfun/pick_objects b/doc/sphinx/man/lfun/pick_objects
deleted file mode 100644
index ac70415..0000000
--- a/doc/sphinx/man/lfun/pick_objects
+++ /dev/null
@@ -1,61 +0,0 @@
-
-pick_objects()
-**************
-
-
-FUNKTION
-========
-
- public varargs int pick_objects(string str, int flag, mixed msg);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- string str
- Was aufgehoben werden soll.
- int flag
- Muss das Objekt irgendwo drinstecken (flag = 1), oder darf es einfach
- so herumliegen (flag = 0)? Dieses Argument ist hauptsaechlich fuer das
- Kommando "hole" gedacht, in der Regel braucht man es nicht anzugeben.
- mixed msg
- Eine optionale Meldung, die anstelle von P_PICK_MSG oder der
- Standardmeldung verwendet wird, oder -1, um die Meldung zu
- unterdruecken.
-
-
-BESCHREIBUNG
-============
-
- Der Spieler oder NPC nimmt die in <str> benannten Sachen. Kann er ein
- Objekt nicht nehmen, bekommt er eine entsprechende Fehlermeldung. Wenn
- keine Objekte auf <str> passen, wird per _notify_fail() eine Meldung
- gesetzt, aber noch nicht ausgegeben.
-
-
-RUECKGABEWERT
-=============
-
- Wenn <str> irgendwelche vorhandenen Sachen sind, 1, sonst 0.
-
-
-BEMERKUNG
-=========
-
- Wenn die Funktion 1 zurueckgibt, heisst das noch nicht, dass der Spieler
- etwas genommen hat! Er hat es nur versucht, d.h. auf jeden Fall eine
- Meldung bekommen. Gibt die Funktion 0 zurueck, hat er noch keine bekommen.
-
-
-SIEHE AUCH
-==========
-
- move(L), pick(L), P_PICK_MSG, find_objects(L), moved_objects(L)
-
-Last modified: Fri Jul 25 10:58:43 2008 by Amynthor
diff --git a/doc/sphinx/man/lfun/present_objects b/doc/sphinx/man/lfun/present_objects
deleted file mode 100644
index 77f31fa..0000000
--- a/doc/sphinx/man/lfun/present_objects
+++ /dev/null
@@ -1,50 +0,0 @@
-
-present_objects()
-*****************
-
-
-FUNKTION
-========
-
- object *present_objects(string desc);
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- desc
- Umschreibung des gesuchten Objektes oder "alles" oder "alle".
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion gibt die Objekte im Inneren des Behaelters zurueck, die
- sich mit desc ansprechen lassen. In dem Fall, dass "alle(s)"
- angefordert wird, sind das alle sichtbaren Objekte, ansonsten das erste
- Objekt, das sich mit desc ansprechen laesst.
- Objekte, die P_INVIS gesetzt haben, zaehlen als nicht ansprechbar, im
- Gegensatz zu solchen Objekten, die keine P_SHORT haben.
-
-
-RUeCKGABEWERT
-=============
-
- Ein Array von Objekten mit den geforderten Eigenschaften.
-
- Befindet sich kein Objekt im Behaelter, das sich durch desc ansprechen
- laesst, so wird ein leeres Array zurueckgegeben.
-
-
-SIEHE AUCH
-==========
-
- locate_objects(), /std/container/restrictions.c
-
-03.03.2013, Zesstra
diff --git a/doc/sphinx/man/lfun/put b/doc/sphinx/man/lfun/put
deleted file mode 100644
index 9b1d5eb..0000000
--- a/doc/sphinx/man/lfun/put
+++ /dev/null
@@ -1,65 +0,0 @@
-
-put()
-*****
-
-
-FUNKTION
-========
-
- public varargs int put(object o, object dest, mixed msg);
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- object o
- Das Objekt, das irgendwo hingesteckt werden soll.
- object dest
- Der Behaelter, in den das Objekt gesteckt werden soll.
- mixed msg
- Eine optionale Meldung, die anstelle von P_PUT_MSG oder der
- Standardmeldung verwendet wird, oder -1, um die Meldung zu
- unterdruecken.
-
-
-BESCHREIBUNG
-============
-
- Der Spieler oder NPC steckt das Objekt in einen Behaelter. Gibt o->move()
- keinen positiven Wert zurueck, beispielsweise weil er das Objekt nicht
- weggeben darf oder der Behaelter schon voll ist, bekommt er eine
- entsprechende Fehlermeldung.
-
-
-RUECKGABEWERT
-=============
-
- Wenn das Bewegen geklappt hat, 1, ansonsten 0.
-
-
-BEMERKUNG
-=========
-
- Diese Funktion ist dann sinnvoll, wenn man den Spieler ein Objekt irgendwo
- hinstecken lassen und sich nicht selbst um die Fehlerbehandlung kuemmern
- moechte - und da unzaehlige verschiedene Dinge schiefgehen koennen und
- manche Objekte eigene Fehlermeldungen definieren, eigentlich immer.
-
- Die Funktion prueft nicht, ob sich das Objekt und der Behaelter ueberhaupt
- in der Reichweite des Spielers/NPC befinden, das muss man ggf. selbst
- ermitteln.
-
-
-SIEHE AUCH
-==========
-
- move(L), P_PUT_MSG, put_objects(L), P_NOINSERT_MSG, P_NOLEAVE_MSG,
- P_TOO_MANY_MSG, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOGET, P_NODROP
-
-Last modified: Thu Aug 28 22:21:58 2008 by Amynthor
diff --git a/doc/sphinx/man/lfun/put_obj b/doc/sphinx/man/lfun/put_obj
deleted file mode 100644
index ff4dd91..0000000
--- a/doc/sphinx/man/lfun/put_obj
+++ /dev/null
@@ -1,46 +0,0 @@
-
-put_obj()
-*********
-
-
-FUNKTION
-========
-
- int put_obj(object ob, object where)
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- ob Das Objekt, das irgendwo hineingelegt werden soll.
- where Das (tote) Objekt, in das etwas hineingelegt werden soll.
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen, in dem diese Funktion aufgerufen werden soll, legt
- den angegebenen Gegenstand (ob) in das angegebene Zielobjekt (where).
- Dabei sollte es sich bei where um einen Container/Raum handeln.
- Ist where ein Lebewesen, verwendet man besser give_obj().
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Objekt weggelegt wurde oder dies nicht moeglich war. (in diesem
- Fall wird auch direkt eine Textausgabe ausgegeben)
- 0 sonst, in diesem Fall wird in notify_fail eine passende Ausgabe
- plaziert
-
-
-SIEHE AUCH
-==========
-
- drop_obj(), find_obs(), give_obj(), pick_obj(), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/lfun/query_prevent_shadow b/doc/sphinx/man/lfun/query_prevent_shadow
deleted file mode 100644
index 2c8d2f3..0000000
--- a/doc/sphinx/man/lfun/query_prevent_shadow
+++ /dev/null
@@ -1,54 +0,0 @@
-
-query_prevent_shadow()
-**********************
-
-query_prevent_shadow(L)
-
-
-FUNKTION
-========
-
- varargs int query_prevent_shadow(object shadower)
-
-
-PARAMETER
-=========
-
- object shadower - da Objekt, das eine Beschattung beantragt
-
-
-BESCHREIBUNG
-============
-
- Diese Methode kann in Objekten definiert werden, die nicht beschattet
- werden wollen oder anhand des Objektes shadower entscheiden wollen ob
- sie beschattet werden wollen.
-
- Gibt die Funktion 0 zurueck, wird ein Shadow auf das Objekt erlaubt,
- sonst schlaegt es fehl.
-
-
-BEISPIEL
-========
-
- // generell keine Beschattung
- int query_prevent_shadow(object who) {
- return 1;
- }
-
- // Beschattung durch offizielle Objekte erlaubt
- int query_prevent_shadow(object who) {
- if(who && !strstr(object_name(who),"/std/player"))
- return 0;
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Rechte: query_allow_shadow(M)
- Generell: shadow(E), unshadow(E)
- Informationen: query_shadowing(E)
-
-20. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/lfun/query_real_name b/doc/sphinx/man/lfun/query_real_name
deleted file mode 100644
index 1ebc69f..0000000
--- a/doc/sphinx/man/lfun/query_real_name
+++ /dev/null
@@ -1,26 +0,0 @@
-
-query_real_name()
-*****************
-
-
-SYNOPSIS
-========
-
- string query_real_name(void)
-
-
-DESCRIPTION
-===========
-
- The result of this_player()->query_real_name() is used as
- default argument for the efun wizlist().
-
- If LOG_SHOUT was #defined in the parser at compile time, the
- efun shout will use query_real_name() to log the shouter's
- name.
-
-
-SEE ALSO
-========
-
- shout(E), wizlist(E)
diff --git a/doc/sphinx/man/lfun/query_weight_contents b/doc/sphinx/man/lfun/query_weight_contents
deleted file mode 100644
index bd644f5..0000000
--- a/doc/sphinx/man/lfun/query_weight_contents
+++ /dev/null
@@ -1,36 +0,0 @@
-
-query_weight_contents()
-***********************
-
-
-FUNKTION
-========
-
- int query_weight_contents()
-
-
-DEFINIERT IN
-============
-
- /std/container/restrictions.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Gibt das Gewicht des Inhaltes des Behaelters zurueck (ohne
- Beruecksichtigung von P_WEIGHT_PERCENT!)
-
-
-RUeCKGABEWERT
-=============
-
- Das Gewicht des Behaelterinhaltes.
-
-Last modified: Wed May 8 10:23:32 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/reduce_hit_points b/doc/sphinx/man/lfun/reduce_hit_points
deleted file mode 100644
index 7a1dcf0..0000000
--- a/doc/sphinx/man/lfun/reduce_hit_points
+++ /dev/null
@@ -1,69 +0,0 @@
-
-reduce_hit_points()
-*******************
-
-
-FUNKTION
-========
-
- int reduce_hit_points(int damage)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- int damage - der zugefuegte Schaden
-
-
-BESCHREIBUNG
-============
-
- Dem Lebewesen werden damage Lebenspunkte abgezogen, aber der
- Wert wird hinterher nicht kleiner als 1 sein und das Lebewesen
- wird dadurch nicht sterben.
-
-
-RUECKGABEWERT
-=============
-
- Die verbleibenden Lebenspunkte.
-
-
-BEISPIELE
-=========
-
- write("Ploetzlich schiesst eine scheussliche Kreatur aus der Pfuetze "+
- "heraus und\nbeisst Dich ins Bein, sie verschwindet so schnell, "+
- "wie sie gekommen ist.\n");
- this_player()->reduce_hit_points(50);
- (Auszug aus /players/boing/friedhof/room/cat1x9)
-
-
-BEMERKUNGEN
-===========
-
- damage kann auch ein negativer Wert sein, dann werden dem Lebewesen
- diese Lebenspunkte gutgeschrieben und auf die aktuellen Lebenspunkte
- addiert. Da dies eine Form der Heilung ist, nur nach Ruecksprache mit
- dem Regionsmagier verwenden.
-
- Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
- dafuer eingerichteten Funktion check_and_update_timed_key realisiert
- werden.
-
-
-SIEHE AUCH
-==========
-
- Gegenpart: restore_hit_points()
- Verwandt: do_damage(), Defend(), reduce_spell_points()
- Props: P_HP
- Konzept: heilung
-
-Last modified: Sat Dec 13 01:00:47 1999 by Tilly
diff --git a/doc/sphinx/man/lfun/reduce_spell_points b/doc/sphinx/man/lfun/reduce_spell_points
deleted file mode 100644
index cddb7da..0000000
--- a/doc/sphinx/man/lfun/reduce_spell_points
+++ /dev/null
@@ -1,48 +0,0 @@
-
-reduce_spell_points()
-*********************
-
-
-FUNKTION
-========
-
- void reduce_spell_points(int points)
-
-
-DEFINIERT IN
-============
-
- /std/living/life.c
-
-
-ARGUMENTE
-=========
-
- points: Anzahl der Konzentrationspunkte die abgezogen werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Dem Lebewesen werden points Konzentrationspunkte abgezogen. Falls
- das Lebewesen weniger Konzentrationspunkte hat, als abgezogen werden
- sollen, werden sie auf 0 gesetzt.
-
-
-BEISPIELE
-=========
-
- write("Das boese boese Monster schaut Dich grimmig an und labt sich an "
- +"Deiner Konzentration.\n");
- this_player()->reduce_spell_points(50);
-
-
-SIEHE AUCH
-==========
-
- Gegenpart: restore_spell_points(L)
- Verwandt: reduce_hit_points(L), buffer_sp(L)
- Props: P_SP
- Konzept: heilung
-
-23.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/lfun/register_modifier b/doc/sphinx/man/lfun/register_modifier
deleted file mode 100644
index afe086c..0000000
--- a/doc/sphinx/man/lfun/register_modifier
+++ /dev/null
@@ -1,42 +0,0 @@
-
-register_modifier()
-*******************
-
-
-FUNKTION
-========
-
- void register_modifier(object modifier)
-
-
-DEFINIERT IN
-============
-
- /std/living/attributes.c
-
-
-PARAMETER
-=========
-
- modifier - Objekt mit P_X_ATTR_MOD oder P_M_ATTR_MOD
-
-
-BESCHREIBUNG
-============
-
- Registriert einen Modifier im Spieler. Wird durch InsertSensitiveObject
- beziehungsweise beim Anziehen oder Zuecken gerufen.
- Muss nicht direkt gerufen werden. Bei Veraenderungen von Modifikatoren
- sollte stattdessen UpdateAttributes gerufen werden.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttr(), SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- deregister_modifier(), P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
- P_ATTRIBUTES_MODIFIER,P_X_ATTR_MOD, P_M_ATTR_MOD,
- /std/living/attributes.c
-
-13.Jun.2004, Muadib
diff --git a/doc/sphinx/man/lfun/remove b/doc/sphinx/man/lfun/remove
deleted file mode 100644
index 914c1e1..0000000
--- a/doc/sphinx/man/lfun/remove
+++ /dev/null
@@ -1,56 +0,0 @@
-
-remove()
-********
-
-
-FUNKTION
-========
-
- varargs int remove(int silent);
-
-
-DEFINIERT IN
-============
-
- /std/thing/moving.c
- /std/living/moving.c
- /std/room/moving.c
-
-
-ARGUMENTE
-=========
-
- silent
- Falls ungleich 0, so werden beim Zerstoeren keine Meldungen
- ausgegeben.
-
-
-BESCHREIBUNG
-============
-
- Beim Aufruf dieser Funktion entfernt sich das Objekt selbst. Durch
- Ueberladen dieser Funktion kann man diesen Vorgang noch durch die
- Ausgabe von Meldungen kommentieren, oder irgendwelche Daten
- abspeichern, oder das Zerstoeren ganz verhindern (auf diesem Weg... Mit
- destruct() kann das Objekt immer noch direkt zerstoert werden!)
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn sich das Objekt erfolgreich selbst zerstoert hat, sonst 0.
-
-
-BEMERKUNGEN
-===========
-
- Nach einem erfolgreichen ::remove() gelten die selben Einschraenkungen
- wie nach einem destruct()!
-
-
-SIEHE AUCH
-==========
-
- destruct()
-
-Last modified: Wed May 8 10:23:40 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/remove_multiple b/doc/sphinx/man/lfun/remove_multiple
deleted file mode 100644
index 9e60d55..0000000
--- a/doc/sphinx/man/lfun/remove_multiple
+++ /dev/null
@@ -1,86 +0,0 @@
-
-remove_multiple()
-*****************
-
-
-FUNKTION
-========
-
- public varargs int remove_multiple(int limit, mixed fun);
-
-
-DEFINIERT IN
-============
-
- /std/container/items.c
-
-
-ARGUMENTE
-=========
-
- limit: Anzahl gleicher Objekte, die verbleiben sollen.
- fun: Funktionsname (string) oder Closure.
-
-
-BESCHREIBUNG
-============
-
- Wird diese Funktion aufgerufen, werden alle gleichen Objekte
- (standardmaessig definiert als gleicher Ladename, gleiche
- Kurzbeschreibung und gleiche Langbeschreibung), deren Anzahl <limit>
- ueberschreitet, entfernt.
-
-
-
- Ausnahmen: Lebewesen und per AddItem() hinzugefuegte Objekte.
-
- Mit dem Argument <fun> lassen sich die Kriterien fuer die "Gleichheit"
- aendern.
- Ist <fun> ein Funktionsname, wird diese Funktion an allen in Frage
- kommenenden Objekten im Container gerufen.
- Ist <fun> eine Closure, werden sie fuer jedes in Frage kommende Objekt
- einmal gerufen und ihr das Objekt uebergeben.
- Als 'gleich' werden alle Objekte betrachtet, fuer die <fun> den gleichen
- Wert zurueckliefert.
- Objekte, fuer die <fun> 0 zurueckliefert, werden ignoriert.
-
-
-BEMERKUNGEN
-===========
-
- 1) Raeume rufen remove_multiple(3) standardmaessig im reset(), jedoch
- nur, wenn kein Spieler anwesend ist und mehr als 10 Objekte im Raum
- sind.
- 2) remove_multipe(0) entfernt alle entfernbaren Objekte (s. Ausnahmen).
-
-
-BEISPIELE
-=========
-
- Ein Container enthaelt 5 Fackeln. Im reset() ruft man nun
- remove_multiple(3) auf. Anschliessend sind noch 3 Fackeln uebrig.
-
-
-
- Alle verbleibenden Objekte im Container sollen unterschiedliche Namen
- haben:
- remove_multiple(1, "name");
-
- Ein Container soll nur ein Objekt behalten, welches groesser als 70 cm
- ist:
- int groessen_filter(object ob) {
- if (ob->QueryProp(P_SIZE > 70)) return 1;
- return 0; // damit das Objekt ignoriert wird.
- // Alternativ koennte man statt 0 auch object_name(ob) zurueckliefern,
- // dann sind diese Objekte alle unterschiedlich.
- }
- ...
- remove_multiple(1, #'groessen_filter);
-
-
-SIEHE AUCH
-==========
-
- reset()
-
-31.01.2009, Zesstra
diff --git a/doc/sphinx/man/lfun/reset b/doc/sphinx/man/lfun/reset
deleted file mode 100644
index 5959b3f..0000000
--- a/doc/sphinx/man/lfun/reset
+++ /dev/null
@@ -1,106 +0,0 @@
-
-reset()
-*******
-
-
-FUNKTION
-========
-
- void reset();
- protected void reset();
-
-
-BESCHREIBUNG
-============
-
- reset() wird vom GameDriver in jedem Objekt aufgerufen, um dem Objekt
- die Gelegenheit zu geben, sich wieder in einen definierten Zustand zu
- versetzen: Raeume und Monster erzeugen per AddItem() eingefuegte und
- zwischenzeitlich entfernte Objekte neu, Tueren schliessen sich ...
-
- Solange das Objekt "benutzt" wird, wird reset() regelmaessig alle
- 45 Minuten (+/-15 Minuten) mit einer Aufloesung von 2s aufgerufen
- (d.h. der Driver prueft und ruft nur alle 2 Sekunden reset() auf
- allen Objekten).
-
- Wird eine Objekt nicht mehr "benutzt", d.h. wird an einem Objekt nicht
- von aussen (durch call_other etc.) _nach_ einem reset() eine Methode
- bzw. LFun gerufen, so bekommt dieses Objekt keinen weiteren reset().
-
- Ein Funktionsaufruf am Objekt schaltet den reset() wieder ein.
- Bei einem Objekt in einem Container waere das zB das Benutzen des
- Containers (Hineinlegen/Herausnehmen/Hineinsehen). Das kann
- sehr lange dauern.
-
- Die Abschaltung kann man verhindern, indem man im reset() per call_out()
- eine Funktion im Objekt ruft. Dies aber bitte _nur_ machen, wenn das
- Objekt _unbedingt_ auf einen staendigen Reset angewiesen ist, auch wenn
- es nicht "benutzt" wird.
-
- Aendern laesst sich die Zeit zwischen den Aufrufen von reset() mit
- set_next_reset(). Die Aufloesung von 2s kann man nicht aendern.
-
-
-BEMERKUNGEN
-===========
-
- - man kann reset() nutzen, um Ereignisse auszuloesen:
- - es ist billiger als lange call_out()
- - siehe Warnung bezueglich Abschalten des reset
- - man kann reset() als protected oder static definieren, wenn man nicht
- moechte, dass die Funktion von aussen gerufen werden kann. Dies
- verhindert Einflussnahme von aussen, kann aber auch Debugmassnahmen
- erschweren. Es ist aber dennoch fuer einige Objekte sinnvoll.
- - der Driver ruft reset() unabhaengig von zusaetzlichen, "manuellen"
- Rufen von reset()
- - keine Rufe von reset() mit call_out() aus reset() (Callout-Ketten-
- bildung droht), fuer solche Faelle ist set_next_reset(E) da!
- - bei Blueprints sollte der reset() in der Regel abgeschaltet werden,
- sofern er nicht auf wichtige Aufgaben in der BP zu tun hat:
- protected void create() {
- if(!clonep(ME)) {
- set_next_reset(-1);
- return;
- }
- ::create();
- ...
- }
-
-
-BEISPIELE
-=========
-
- // ein NPC, der bei jedem reset() schaut, ob um ihn herum bessere
- // Ausruestung liegt als die, die er selbst gerade traegt:
-
- ...
- void reset() {
- ::reset();
-
- if(clonep(this_object()) && environment()) {
- object o;
- o=first_inventory(environment());
- while(o) {
- look_for_good_weapons_and_use_them_if_better(o);
- o=next_inventory(o);
- }
- }
- }
-
- // ein reset fuer einen Gegenstand, der vielleicht in
- // in einem Container landet und dann weiter einen reset
- // bekommen muss/soll
-
- void reset() {
- // irgend ein Code hier
- call_other(this_object(), "???"); // einfach nur was aufrufen
- }
-
-
-SIEHE AUCH
-==========
-
- clean_up(), set_next_reset(E), query_next_reset(E)
- memory
-
-letzte Aenderung: 2009-01-14 Rumata
diff --git a/doc/sphinx/man/lfun/restore_hit_points b/doc/sphinx/man/lfun/restore_hit_points
deleted file mode 100644
index b4917cf..0000000
--- a/doc/sphinx/man/lfun/restore_hit_points
+++ /dev/null
@@ -1,57 +0,0 @@
-
-restore_hit_points()
-********************
-
-
-FUNKTION
-========
-
- int restore_hit_points(int heal)
-
-
-ARGUMENTE
-=========
-
- int heal - der zu heilende Betrag
-
-
-BESCHREIBUNG
-============
-
- Dem Lebewesen werden heal Lebenspunkte aufgeschlagen. Die HP
- steigen nicht ueber P_MAX_HP.
-
-
-RUECKGABEWERT
-=============
-
- Die verbleibenden Lebenspunkte.
-
-
-BEISPIELE
-=========
-
- write("Ploetzlich schiesst eine scheussliche Kreatur aus der Pfuetze "+
- "heraus und\nschleimt dich heilend voll, sie verschwindet so, "+
- "wie sie gekommen ist.\n");
- this_player()->restore_hit_points(50);
-
-
-BEMERKUNGEN
-===========
-
- Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
- dafuer eingerichteten Funktion check_and_update_timed_key realisiert
- werden.
- Ansonsten bitte buffer_hp() benutzen und die Konzeptseite lesen!
-
-
-SIEHE AUCH
-==========
-
- Gegenpart: reduce_hit_points()
- Verwandt: buffer_hp(), heal_self(), restore_spell_points()
- Props: P_HP
- Konzept: heilung
-
-23.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/lfun/restore_spell_points b/doc/sphinx/man/lfun/restore_spell_points
deleted file mode 100644
index 2c8e42c..0000000
--- a/doc/sphinx/man/lfun/restore_spell_points
+++ /dev/null
@@ -1,61 +0,0 @@
-
-restore_spell_points()
-**********************
-
-
-FUNKTION
-========
-
- void restore_spell_points(int points)
-
-
-ARGUMENTE
-=========
-
- points: Anzahl der Konzentrationspunkte die gutgeschrieben werden sollen.
-
-
-BESCHREIBUNG
-============
-
- Dem Lebewesen werden points Konzentrationspunkte gutgeschrieben. Falls
- Punkte abgezogen werden sollen und das Lebewesen nicht ueber <points>
- Konzentrationspunkte verfuegt, werden sie auf 0 gesetzt.
-
-
-RUECKGABEWERT
-=============
-
- Keiner
-
-
-BEISPIELE
-=========
-
- write("Das boese boese Monster schaut Dich suess an und gibt dir mehr "
- +"Konzentration.\n");
- this_player()->restore_spell_points(50);
-
-
-BEMERKUNGEN
-===========
-
- Da das Benutzen der Funktion eine Heilung bedeutet, sollte man bei
- Verwendung auf jeden Fall Ruecksprache mit seinem RM nehmen, bzw
- die Heilstelle bei der Heilungsbalance genehmigen lassen.
-
- Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
- dafuer eingerichteten Funktion check_and_update_timed_key realisiert
- werden.
- Ansonsten bitte buffer_sp() benutzen und die Konzeptseite lesen!
-
-
-SIEHE AUCH
-==========
-
- Gegenpart: reduce_spell_points(L)
- Verwandt: buffer_sp(L), restore_hit_points(L)
- Props: P_SP
- Konzept: heilung
-
-23.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/lfun/save_me b/doc/sphinx/man/lfun/save_me
deleted file mode 100644
index cbce90a..0000000
--- a/doc/sphinx/man/lfun/save_me
+++ /dev/null
@@ -1,41 +0,0 @@
-
-save_me()
-*********
-
-save_me(L)
-
-
-FUNKTION
-========
-
- void save_me(mixed value_items)
-
-
-DEFINIERT IN
-============
-
- /std/player/base.c
-
-
-ARGUMENTE
-=========
-
- value_items
- Ungleich 0, wenn Wert der Gegenstaende berechnet werden soll.
-
-
-BESCHREIBUNG
-============
-
- Speichert einen Spieler, seine Autoloader, bestimmt sein GuildRating
- und berechnet/speichert auf Anforderung den Wert der getragenen
- Gegenstaende.
-
-
-SIEHE AUCH
-==========
-
- Props: P_CARRIED_VALUE, P_AUTOLOADOBJ, P_LAST_LOGOUT
- Kommandos: save, ende
-
-1.September 2008 Gloinson
diff --git a/doc/sphinx/man/lfun/second_life b/doc/sphinx/man/lfun/second_life
deleted file mode 100644
index 1c3fc8b..0000000
--- a/doc/sphinx/man/lfun/second_life
+++ /dev/null
@@ -1,52 +0,0 @@
-
-second_life()
-*************
-
-
-FUNKTION
-========
-
- varargs int second_life(object obj);
-
-
-DEFINIERT IN
-============
-
- /std/player/life.c
-
-
-ARGUMENTE
-=========
-
- obj
- Leiche des Lebewesens.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird im die() des Lebewesens aufgerufen, wenn sicher
- ist, dass es stirbt. Ueblicherweise ist diese Funktion nur im Spieler
- definiert und regelt EP-Verlust und dergleichen. Ein Shadow wuerde
- diese Funktion ueberlagern, um zu verhindern, dass ein Spieler stirbt.
-
-
-RUeCKGABEWERT
-=============
-
- 1, wenn das Lebewesen nicht stirbt, sonst 0
-
-
-BEMERKUNG
-=========
-
- Bei NPCs sollte man direkt die() ueberschreiben, wenn man nicht
- moechte, dass sie sterben.
-
-
-SIEHE AUCH
-==========
-
- die()
-
-Last modified: 2015-Jan-19, Arathorn
diff --git a/doc/sphinx/man/lfun/sell_obj b/doc/sphinx/man/lfun/sell_obj
deleted file mode 100644
index 580fd87..0000000
--- a/doc/sphinx/man/lfun/sell_obj
+++ /dev/null
@@ -1,59 +0,0 @@
-
-sell_obj()
-**********
-
-sell_obj()
-
-Funktion:
- static string sell_obj(object ob, int short)
-
-Definiert in:
- /std/room/shop
-
-Argumente:
- ob:
- Das anzukaufende Objekt
-
- short:
- Gibt an, ob der Verkaeufer nur ein Objekt (0) oder mehrere (1)
- verkauft. (Verkaufe alles etc.)
-
-Beschreibung:
- Ermittelt ob der Laden bereit ist, <ob> anzukaufen.
-
-Rueckgabewert:
- Meldung die ausgegeben wird, wenn ein Objekt abgelehnt wird oder 0.
-
-Bemerkung:
- Man sollte im normalfall _niemals_ einfach 0 zurueckgeben, sondern
- das geerbte sell_obj() aus /std/room/shop, damit beispielsweise
- P_NOBUY beachtet wird.
-
-Beispiel:
- Ein Schmied, der nur Waffen ankauft:
-
- protected void create() {
-
- ...
-
- }
-
- static string sell_obj(object ob, int short) {
-
- if(!ob->QueryProp(P_WEAPON_TYPE)) {
-
- return "Ich bin nur an Waffen interessiert.";
-
- } return ::sell_obj(ob,short);
-
- }
-
-Siehe auch:
- Funktionen:
- AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
- QueryStorageRoom(), QueryBuyValue(), QueryBuyFact(), buy_obj()
-
- Properties:
- P_KEEPER, P_MIN_STOCK, P_STORE_CONSUME
-
-Letzte Aenderung: 21.05.2014, Bugfix
diff --git a/doc/sphinx/man/lfun/set_object_next_reset b/doc/sphinx/man/lfun/set_object_next_reset
deleted file mode 100644
index 9b77a9e..0000000
--- a/doc/sphinx/man/lfun/set_object_next_reset
+++ /dev/null
@@ -1,41 +0,0 @@
-
-set_object_next_reset()
-***********************
-
-
-FUNKTION
-========
-
- int set_object_next_reset(object ob, int zeit );
-
-DEFINIERT IN: /secure/debug.c
-
-
-ARGUMENTE
-=========
-
- ob: Das Objekt, dess Reset gesetzt werden soll.
- zeit: Zeit bis zum naechsten Reset von ob.
-
-
-FUNKTION
-========
-
- Die Funktion ruft letztendlich set_next_reset() in <ob> auf und setzt daher
- dessen Resetzeit auf einen neuen Wert. Dies ist zu Debugzwecken gedacht.
-
- Die Benutzung ist nur fuer EM+ moeglich.
-
-
-RUECKGABEWERT
-=============
-
- Gibt den Rueckgabewert des set_next_reset()-Aufrufs in <ob> zurueck.
-
-
-SIEHE AUCH
-==========
-
- set_next_reset(E)
-
-10.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/shoot_dam b/doc/sphinx/man/lfun/shoot_dam
deleted file mode 100644
index f66be19..0000000
--- a/doc/sphinx/man/lfun/shoot_dam
+++ /dev/null
@@ -1,63 +0,0 @@
-
-shoot_dam()
-***********
-
-
-FUNKTION
-========
-
- static int shoot_dam(mapping shoot)
-
-
-DEFINIERT IN
-============
-
- /std/ranged_weapon.c
-
-
-ARGUMENTE
-=========
-
- mapping shoot - Schussdaten
-
-
-BESCHREIBUNG
-============
-
- Erhaelt von /std/ranged_weapon::cmd_shoot() die Schussdaten und berechnet
- den Schaden der Waffe, basierend auf den P_SHOOTING_WC von Waffe und
- Munition sowie der Geschicklichkeit des Schuetzen. HitFuncs der Munition
- und Skills werden hier ebenfalls beruecksichtigt.
-
-
-RUECKGABEWERT
-=============
-
- Schaden. Ebenfalls in 'shoot' unter SI_SKILLDAMAGE aktualisiert.
-
-
-BEMERKUNGEN
-===========
-
- 'shoot' enthaelt normalerweise folgende Eintraege:
- * Key P_WEAPON: die Schusswaffe
- * Key P_WEAPON_TYPE: P_AMMUNITION, also die Munitions-ID
- * Key P_STRETCH_TIME: P_STRETCH_TIME der Waffe
- * Key P_WC: P_SHOOTING_WC der Waffe
- * Key P_SHOOTING_WC: P_SHOOTING_WC der Munition
- * Key P_AMMUNITION: Munitionsobjekt (eventuell Unit)
- * Key SI_ENEMY: gueltigen Gegner
- * Key SI_SKILLDAMAGE_TYPE: Schaden (aus P_DAM_TYPE der Munition)
- * Key SI_SKILLDAMAGE_MSG/2: Munitionsname
-
-
-SIEHE AUCH
-==========
-
- Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
- Methoden: FindRangedTarget(L), cmd_shoot(L)
- Skills: UseSkill(L), SkillResTransfer(L)
- Attribute: QueryAttribute
- Sonstiges: fernwaffen, HitFunc
-
-28.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/lfun/short b/doc/sphinx/man/lfun/short
deleted file mode 100644
index f7bb169..0000000
--- a/doc/sphinx/man/lfun/short
+++ /dev/null
@@ -1,53 +0,0 @@
-
-short()
-*******
-
-
-FUNKTION
-========
-
- public varargs string short();
-
-
-DEFINIERT IN
-============
-
- /std/thing/description.c
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Der Inhalt der Property P_SHORT wird ausgewertet, mit ".\n"
- abgeschlossen und zurueckgegeben.
-
-
-RUeCKGABEWERT
-=============
-
- Die Kurzbeschreibung als String oder 0, falls das Objekt unsichtbar
- ist.
-
-
-BEMERKUNGEN
-===========
-
- Durch Ueberladen von short() lassen sich noch weitere Eigenschaften des
- Objektes zeigen. Fackeln zeigen zum Beispiel an, ob sie brennen,
- Ruestungen, ob sie angezogen sind und Waffen, ob sie gezueckt sind.
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: long()
- Properties: P_SHORT, P_INVIS
- Sonstiges: make_invlist()
-
-20.01.2015, Zesstra
diff --git a/doc/sphinx/man/lfun/show_notify b/doc/sphinx/man/lfun/show_notify
deleted file mode 100644
index 0ce99ac..0000000
--- a/doc/sphinx/man/lfun/show_notify
+++ /dev/null
@@ -1,73 +0,0 @@
-
-show_notify()
-*************
-
-give_notify()
-
-
-FUNKTION
-========
-
- void show_notify(object obj)
-
-
-DEFINIERT IN
-============
-
- /std/living/put_and_get.c
-
-
-ARGUMENTE
-=========
-
- obj - dem Lebewesen gezeigtes Objekt
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird automatisch immer dann aufgerufen, wenn einem
- Lebewesen (welches kein Spielercharakter ist) ein Objekt gezeigt wird.
- Dies funktioniert nur dann, wenn der Standardbefehl der Spielershell
- verwendet wird ("zeige <name> <gegenstand>"). Selbstgebautes "zeige"
- funktioniert nicht.
-
-
-BEISPIEL
-========
-
- Oftmals will man in Quests erreichen, dass einem NPC ein bestimmtes
- Item als Beweis der Erfuellung einer bestimmten Aufgabe vorgezeigt
- wird. Folgendermassen kann dies realisiert werden:
-
- void quest_ok(object obj) { ...
- // z.B. Vernichtung des Questobjektes und Questtexte
- // Questbelohnung und Questanerkennung, etc.
- }
-
- void show_notify(object obj) {
- if(obj->id("\nquestitem")) // Ist das das geforderte Questobjekt?
- quest_ok(obj);
- }
-
-
-BEMERKUNGEN
-===========
-
- Da es nur um das Vorzeigen von Gegenstaenden geht, die nicht den
- Besitzer wechseln, sind Mechanismen wie P_REJECT in diesem Fall
- nicht erforderlich.
-
-
-SIEHE AUCH
-==========
-
- give_notify(), /std/npc/put_and_get.c, /std/living/put_and_get.c
-
-22. Oktober 2013 Arathorn
diff --git a/doc/sphinx/man/lfun/spellbook/AddSpell b/doc/sphinx/man/lfun/spellbook/AddSpell
deleted file mode 100644
index 65f0df8..0000000
--- a/doc/sphinx/man/lfun/spellbook/AddSpell
+++ /dev/null
@@ -1,78 +0,0 @@
-
-AddSpell()
-**********
-
-
-FUNKTION
-========
-
- varargs int AddSpell(string verb, int kosten, mixed ski)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- string verb Name des Spells
- int kosten normale Kosten (Grundkosten)
- mixed ski Skillmapping mit allen Eintraegen zum Spell
-
-
-BESCHREIBUNG
-============
-
- Addiert einen Eintrag fuer den Spell im Spellbook. Wenn dieser
- Spell direkt vom Spieler (SI_SPELLBOOK) oder (normalerweise)
- ueber ein Gildenobjekt aufgerufen wird, wird das Mapping auf
- die Skillinformationen aus Spieler und Gilde addiert und
- beeinflusst damit den Aufruf der letztlichen Spellfunktion.
-
-
-BEMERKUNGEN
-===========
-
- Siehe das Verhalten von QuerySpell (gilde) zum Zusammenfuegen
- der AddSpell-Informationen aus Gilde und Spellbook. Relevant
- zB fuer Lernrestriktionen.
-
-
-BEISPIEL
-========
-
- AddSpell("kampfschrei", 30,
- ([SI_SKILLRESTR_LEARN:([P_LEVEL:13]),
- SI_MAGIC_TYPE: ({MT_PSYCHO}),
- SI_SPELL: ([
- SP_NAME: "Kampfschrei",
- SP_SHOW_DAMAGE:
- ({({ -1, "Dir geschieht jedoch nichts.",
- "@WEM1 geschieht jedoch nichts.",
- "@WEM1 geschieht jedoch nichts." }),
- ({ 0, "Du kannst darueber aber nur lachen.",
- "@WER1 kann darueber aber nur lachen.",
- "@WER1 kann darueber aber nur lachen." }),
- ({ 10, "Dir droehnen die Ohren.",
- "@WEM1 droehnen die Ohren.",
- "@WEM1 droehnen die Ohren." })
- })])
- ]));
-
-
-SIEHE AUCH
-==========
-
- Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
- * Verwalten: QuerySpell
- * Angriff: TryAttackSpell, TryDefaultAttackSpell,
- TryGlobalAttackSpell
- * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * sonstig: spruchermuedung, skill_info_liste
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/spellbook/Erfolg b/doc/sphinx/man/lfun/spellbook/Erfolg
deleted file mode 100644
index 6338e6d..0000000
--- a/doc/sphinx/man/lfun/spellbook/Erfolg
+++ /dev/null
@@ -1,46 +0,0 @@
-
-Erfolg()
-********
-
-
-FUNKTION
-========
-
- void Erfolg(object caster, string spell, mapping sinfo)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- object caster Spell sprechender Spieler
- string spell Spellname
- mapping sinfo Spell-Info-Mapping mit allen Informationen
-
-
-BESCHREIBUNG
-============
-
- Wird bei Erfolg eines Spells gerufen. Ruft SpellInform() am
- Environment.
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: SpellInform
- Spellbook Lernen: Learn, SpellSuccess, Misserfolg
- * Verwalten: AddSpell, QuerySpell
- * Angriff: TryAttackSpell, TryDefaultAttackSpell,
- TryGlobalAttackSpell
- * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * sonstig: spruchermuedung, skill_info_liste
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/spellbook/Learn b/doc/sphinx/man/lfun/spellbook/Learn
deleted file mode 100644
index 8de112e..0000000
--- a/doc/sphinx/man/lfun/spellbook/Learn
+++ /dev/null
@@ -1,54 +0,0 @@
-
-Learn()
-*******
-
-
-FUNKTION
-========
-
- void Learn(object caster, string spell, mapping sinfo)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- object caster Derjenige, der den Spruch spricht.
- string spell Der gesprochene Spell
- mapping sinfo Mapping mit allen moeglichen Informationen zum Spell
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird von der Funktion "Misserfolg" aus dem
- Spellbook aufgerufen. Hier lernt der Spieler den Spruch, der
- nicht geglueckt ist.
-
-
-BEMERKUNGEN
-===========
-
- Kann auch ueberschrieben werden, wenn man komplexe Lern-Aenderungen
- vornehmen will. Andere Attribute sind ueber SI_LEARN_ATTRIBUTE
- setzbar.
-
-
-SIEHE AUCH
-==========
-
- Spellbook Lernen: SpellSuccess, Erfolg, Misserfolg
- * Verwalten: AddSpell, QuerySpell
- * Angriff: TryAttackSpell, TryDefaultAttackSpell,
- TryGlobalAttackSpell
- * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * sonstig: spruchermuedung, skill_info_liste
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/spellbook/Misserfolg b/doc/sphinx/man/lfun/spellbook/Misserfolg
deleted file mode 100644
index 5ffe8de..0000000
--- a/doc/sphinx/man/lfun/spellbook/Misserfolg
+++ /dev/null
@@ -1,78 +0,0 @@
-
-Misserfolg()
-************
-
-
-FUNKTION
-========
-
- void Misserfolg(object caster, string spell, mapping sinfo)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- object caster Spell sprechender Spieler
- string spell Spellname
- mapping sinfo Spell-Info-Mapping mit allen Informationen
-
-
-BESCHREIBUNG
-============
-
- Wird bei Misserfolg eines Spells im Spellbook aufgerufen und
- ruft die Lernfunktion Learn() nach einer Fehlermeldung.
-
-
-
- Kann ueberschrieben werden, um die Meldungen anzupassen.
-
-
-BEISPIEL
-========
-
- // Misserfolge im Klerus mit angepassten Meldungen
- void Misserfolg(object caster, string spell, mapping sinfo) {
- switch(spell) {
- case "begrabe":
- tell_object(caster, BS(
- "Du begraebst Deine Hoffnungen, dass Du diese Anrufung jemals "
- "perfekt beherrschen wirst."));
- tell_room(environment(caster),
- caster->Name(WER)+" tritt die Leiche lustlos.\n", ({caster}));
- break;
- case "blitz":
- [...]
- }
-
-
-
- int old_abil = sinfo[SI_SKILLABILITY];
- Learn(caster, spell, sinfo);
- int new_abil = caster->QuerySkillAbility(spell);
- if (old_abil < new_abil)
- tell_object(caster, "Die Goetter schenken Dir eine Erleuchtung.\n");
- else
- tell_object(caster, "Leider lernst Du nicht aus Deinem Fehler.\n");
- }
-
-
-SIEHE AUCH
-==========
-
- Spellbook Lernen: Learn, SpellSuccess, Erfolg
- * Verwalten: AddSpell, QuerySpell
- * Angriff: TryAttackSpell, TryDefaultAttackSpell,
- TryGlobalAttackSpell
- * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * sonstig: spruchermuedung, skill_info_liste
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/spellbook/QuerySpell b/doc/sphinx/man/lfun/spellbook/QuerySpell
deleted file mode 100644
index 963d30c..0000000
--- a/doc/sphinx/man/lfun/spellbook/QuerySpell
+++ /dev/null
@@ -1,46 +0,0 @@
-
-QuerySpell()
-************
-
-
-FUNKTION
-========
-
- mapping QuerySpell(string spell)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- string spell Name des Spells
-
-
-BESCHREIBUNG
-============
-
- Gibt das Spellmapping aus P_SB_SPELLS fuer diesen Spell zurueck.
-
-
-
- Hier enthaelt QuerySpell nur die Spellbook-Informationen.
-
-
-SIEHE AUCH
-==========
-
- Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
- * Verwalten: AddSpell
- * Angriff: TryAttackSpell, TryDefaultAttackSpell,
- TryGlobalAttackSpell
- * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * sonstig: spruchermuedung, skill_info_liste
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/spellbook/SpellSuccess b/doc/sphinx/man/lfun/spellbook/SpellSuccess
deleted file mode 100644
index 564c948..0000000
--- a/doc/sphinx/man/lfun/spellbook/SpellSuccess
+++ /dev/null
@@ -1,52 +0,0 @@
-
-SpellSuccess()
-**************
-
-
-FUNKTION
-========
-
- int SpellSuccess(object caster, mapping sinfo)
-
-
-DEFINIERT IN
-============
-
- /std/spellbook.c
-
-
-ARGUMENTE
-=========
-
- object caster Spell sprechender Spieler
- mapping sinfo Spell-Info-Mapping mit allen Informationen
-
-
-BESCHREIBUNG
-============
-
- Berechnet den Erfolg der Anwendung eines Spells aus seiner
- SI_SKILLABILITY und dem Skill SK_CASTING im Spieler. Laesst
- den Spieler bei besonders gutem Gelingen SK_CASTING lernen.
-
-
-BEMERKUNGEN
-===========
-
- SK_CASTING muss fuer die SK_CASTING-Boni beherrscht werden.
- Das ist zB im Klerus ab bestimmtem Level der Fall.
-
-
-SIEHE AUCH
-==========
-
- Spellbook Lernen: Learn, Erfolg, Misserfolg
- * Verwalten: AddSpell, QuerySpell
- * Angriff: TryAttackSpell, TryDefaultAttackSpell,
- TryGlobalAttackSpell
- * Properties: P_GLOBAL_SKILLPROPS, P_SB_SPELLS
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * sonstig: spruchermuedung, skill_info_liste
-
-5. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/lfun/spellbook/TryAttackSpell b/doc/sphinx/man/lfun/spellbook/TryAttackSpell
deleted file mode 100644
index d66684e..0000000
--- a/doc/sphinx/man/lfun/spellbook/TryAttackSpell
+++ /dev/null
@@ -1,57 +0,0 @@
-
-TryAttackSpell()
-****************
-
-** gilden-doku
- o TryAttackSpell(opfer,schaden,typen,is_spell,caster,info)
- Versucht den Angriffs-Spruch auf den Gegner anzuwenden. Die
- mittleren 4 Werte sind die, die auch bei Defend uebergeben
- werden. Dabei wird die Abwehrfaehigkeit des Gegners gegen Magie
- und das Skill-Attribut SA_DAMAGE automatisch beruecksichtigt.
-
-
-FUNKTION
-========
-
-int TryAttackSpell(object victim, int damage, mixed dtypes,
- mixed is_spell, object caster, mapping sinfo)
-
-
-ARGUMENTE
-=========
-
- victim : Das arme Opfer.
- damage : Der Schaden.
- dtypes : Die Schadensarten.
- is_spell : Ist es ein Spell? Werden noch Spezielle Parameter
- uebergeben (als mapping) ?
- caster : Derjenige, der den Spruch spricht.
- sinfo : Mapping mit allen moeglichen Informationen zum Spell
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird vom Spellbook aufgerufen, wenn der Spieler
- einen Angriffsspell gemacht hat und damit Schaden anrichten will.
-
-
-RUECKGABEWERT
-=============
-
- Der Wert, der vom Defend() des Gegners zurueckgeliefert wird.
-
-
-BEMERKUNGEN
-===========
-
- Zu erst wird ueberprueft, ob das Ziel ueberhaupt angreifbar ist. Dies
- verhindert das ueben von Spells an unangreifbaren NPCs.
- Als naechstes wird die Faehigkeit, Spells abzuwehren ueberprueft.
- Falls beide Abfragen ok sind, wird Defend aufgerufen.
-
-Siehe auch:
-
-TryDefaultAttackSpell (to be written)
-
-07.10.2007, Zesstra
diff --git a/doc/sphinx/man/lfun/trigger_sensitive_attack b/doc/sphinx/man/lfun/trigger_sensitive_attack
deleted file mode 100644
index f290fc8..0000000
--- a/doc/sphinx/man/lfun/trigger_sensitive_attack
+++ /dev/null
@@ -1,97 +0,0 @@
-
-trigger_sensitive_attack()
-**************************
-
-
-FUNKTION
-========
-
- varargs void trigger_sensitive_attack(object enemy, string key, int
- dam, mixed spell, mixed *options);
-
-
-DEFINIERT IN
-============
-
- eigenen sensitiven Objekten, wird aufgerufen von
- /std/living/inventory.c
-
-
-ARGUMENTE
-=========
-
- enemy
- Der Gegner, der die Aktion ausgeloest hat.
- key
- Der ausloesende Schadenstyp.
- dam
- Der angerichtete Schaden.
- spell
- Wie bei Defend().
- options
- Array mit den in P_SENSITIVE angegebenen Optionen fuer diese
- Aktion.
-
-
-BESCHREIBUNG
-============
-
- Wenn der bei einem Angriff zugefuegte Schaden den in P_SENSITIVE
- angegebenen Grenzwert uebersteigt sowie der als Schluessel angegebene
- Schadenstyp in den Schaedenstypen des Angriffes vorkommt, wird diese
- Funktion aufgerufen und kann entsprechend reagieren.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- Eine Fackel, die sich bei Feuerattacken selbst entzuendet und bei
- Wasserattacken verloescht, koennte man wie folgt implementieren:
-
- inherit "/std/lightsource.c"
-
- #include <properties.h>
- #include <sensitive.h>
- #include <combat.h>
-
- create()
- {
- ::create();
-
- SetProp(...); // die ueblichen Eigenschaften definieren
-
- SetProp(P_SENSITIVE,
- // Ereignis Key Grenze (keine Optionen)
- ({ ({ SENSITIVE_ATTACK, DT_FIRE, 100 }),
- ({ SENSITIVE_ATTACK, DT_WATER, 100 }) }) );
- }
-
- varargs void
- trigger_sensitive_attack(object enemy, string key,
- int dam, mixed spell)
- {
- // Es soll nicht verschwiegen werden, dass das Entzuenden und
- // Loeschen einer Lichtquelle so leider nicht funktioniert...
- if (key == DT_FIRE && !QueryProp(P_LIGHTED)) {
- SetProp(P_LIGHTED, 1);
- tell_object(environment(), "Die Fackel faengt Feuer.\n");
- }
- else if (key == DT_WATER && QueryProp(P_LIGHTED)) {
- SetProp(P_LIGHTED, 0);
- tell_object(environment(), "Die Fackel verlischt.\n");
- }
- }
-
-
-SIEHE AUCH
-==========
-
- trigger_sensitive_inv(), sensitive Objekte
-
-Last modified: Sun May 19 15:56:25 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/trigger_sensitive_inv b/doc/sphinx/man/lfun/trigger_sensitive_inv
deleted file mode 100644
index 27e26fb..0000000
--- a/doc/sphinx/man/lfun/trigger_sensitive_inv
+++ /dev/null
@@ -1,61 +0,0 @@
-
-trigger_sensitive_inv()
-***********************
-
-
-FUNKTION
-========
-
- varargs void trigger_sensitive_inv(object ob, string key, int wert,
- mixed *optionen1, mixed *optionen2);
-
-
-DEFINIERT IN
-============
-
- eigenen Objekten, wird aufgerufen von /std/container/inventory.c
-
-
-ARGUMENTE
-=========
-
- ob
- Das ausloesende Objekt
- key
- Der Schluessel, der die Aktion ausloeste.
- wert
- Der Grenzwert des ausloesenden Objektes.
- optionen1
- Die Optionen des ausloesenden Objektes.
- optionen2
- Die Optionen des reagierenden Objektes.
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion wird in Objekten des sensitiven Typs SENSITIVE_INVENTORY
- aufgerufen, wenn sie in Kontakt mit Objekten des Typs
- SENSITIVE_INVENTORY_TRIGGER treten, die den gleichen Schluessel
- aufweisen und einen hoeheren Grenzwert haben.
-
- Anhand der Parameter koennen dann die noetigen Aktionen ausgeloest
- werden.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
-
-SIEHE AUCH
-==========
-
- trigger_sensitive_attack(), sensitive Objekte
-
-Last modified: Wed May 8 10:26:10 1996 by Wargon
diff --git a/doc/sphinx/man/lfun/wield_me b/doc/sphinx/man/lfun/wield_me
deleted file mode 100644
index d1aa842..0000000
--- a/doc/sphinx/man/lfun/wield_me
+++ /dev/null
@@ -1,17 +0,0 @@
-
-wield_me()
-**********
-
-
-BEMERKUNGEN
-===========
-
- wield_me wurde durch DoWield ersetzt.
-
-
-SIEHE AUCH
-==========
-
- DoWieldFunc(), /std/weapon.c
-
-Last modified: Wed Apr 08 10:25:00 2004 by Muadib
diff --git a/doc/sphinx/man/lfuns-gilde b/doc/sphinx/man/lfuns-gilde
deleted file mode 100644
index b56c734..0000000
--- a/doc/sphinx/man/lfuns-gilde
+++ /dev/null
@@ -1,3 +0,0 @@
-
-Verzeichnis der lfuns speziell in/für Gilden
-********************************************
diff --git a/doc/sphinx/man/lfuns-master b/doc/sphinx/man/lfuns-master
deleted file mode 100644
index 7ca731d..0000000
--- a/doc/sphinx/man/lfuns-master
+++ /dev/null
@@ -1,13 +0,0 @@
-
-Verzeichnis der lfuns in master()
-*********************************
-
-* AddWizardForUID()
-
-* QueryUIDAlias()
-
-* QueryUIDsForWizard()
-
-* QueryWizardsForUID()
-
-* RemoveWizardFromUID()
diff --git a/doc/sphinx/man/lfuns-obsolet b/doc/sphinx/man/lfuns-obsolet
deleted file mode 100644
index ac47c41..0000000
--- a/doc/sphinx/man/lfuns-obsolet
+++ /dev/null
@@ -1,29 +0,0 @@
-
-Verzeichnis der veralteten lfuns
-********************************
-
-* AddHpHook()
-
-* AddInsertHook()
-
-* ModifySkillAttributeOld()
-
-* NotifyGiveQuest()
-
-* NotifyHpChange()
-
-* QueryEnemy()
-
-* QueryInsertHooks()
-
-* QueryOptQP()
-
-* RemoveHpHook()
-
-* RemoveInsertHook()
-
-* TestAttributeLock()
-
-* extra_look()
-
-* paramove()
diff --git a/doc/sphinx/man/props-gilden b/doc/sphinx/man/props-gilden
deleted file mode 100644
index df0782d..0000000
--- a/doc/sphinx/man/props-gilden
+++ /dev/null
@@ -1,17 +0,0 @@
-
-Verzeichnis der Gilden-Properties
-*********************************
-
-* P_GLOVE_FINGERLESS
-
-* P_Z_AUTOSHIELD
-
-* P_Z_INFO
-
-* P_Z_NO_MATERIAL
-
-* P_Z_NO_NOCONN
-
-* P_Z_NO_SPELL_SUPPORT
-
-* kaempferboni
diff --git a/doc/sphinx/man/props-liste b/doc/sphinx/man/props-liste
deleted file mode 100644
index f63a1cf..0000000
--- a/doc/sphinx/man/props-liste
+++ /dev/null
@@ -1,937 +0,0 @@
-
-Propertyliste
-*************
-
-
-Verzeichnis der dokumentierten Properties:
-==========================================
-
-* P_ABILITIES
-
-* P_AC
-
-* P_ACCEPT_PEACE
-
-* P_ACHATS
-
-* P_ACHAT_CHANCE
-
-* P_ACTUAL_NOTIFY_FAIL
-
-* P_ADJECTIVES
-
-* P_AERIAL_HELPERS
-
-* P_AGE
-
-* P_AGGRESSIVE
-
-* P_ALCOHOL
-
-* P_ALCOHOL_DELAY
-
-* P_ALC_FULL_MSG
-
-* P_ALIGN
-
-* P_ALLOWED_SHADOW
-
-* P_AMMUNITION
-
-* P_AMOUNT
-
-* P_AQUATIC_HELPERS
-
-* P_ARMOURS
-
-* P_ARMOUR_TYPE
-
-* P_ARRIVEMSG
-
-* P_ARTICLE
-
-* P_ATTACK_BUSY
-
-* P_ATTRIBUTES
-
-* P_ATTRIBUTES_MODIFIER
-
-* P_ATTRIBUTES_OFFSETS
-
-* P_AUTH_INFO
-
-* P_AUTOLOAD
-
-* P_AUTOLOADOBJ
-
-* P_AVATAR_URI
-
-* P_AVERAGE_SIZE
-
-* P_AVERAGE_WEIGHT
-
-* P_AWAY
-
-* P_BAD_MSG
-
-* P_BLIND
-
-* P_BODY
-
-* P_BRIEF
-
-* P_BUFFER
-
-* P_BUY_ONLY_PLANTS
-
-* P_CALLED_FROM_IP
-
-* P_CAN_FLAGS
-
-* P_CAP_NAME
-
-* P_CARRIED_VALUE
-
-* P_CHATS
-
-* P_CHAT_CHANCE
-
-* P_CLASS
-
-* P_CLOCKMSG
-
-* P_CLONER
-
-* P_CLONE_MSG
-
-* P_CLONE_TIME
-
-* P_CLOTHING
-
-* P_CMSG
-
-* P_CNT_STATUS
-
-* P_COMBATCMDS
-
-* P_COMMANDS
-
-* P_COMPILER_PATH
-
-* P_CONSUME_MSG
-
-* P_CONTAINER
-
-* P_CONTENTS
-
-* P_CORPSE
-
-* P_CURRENTDIR
-
-* P_CURSED
-
-* P_DAMAGED
-
-* P_DAMAGE_MSG
-
-* P_DAM_DESC
-
-* P_DAM_TYPE
-
-* P_DEADS
-
-* P_DEAF
-
-* P_DEATH_MSG
-
-* P_DEATH_SPONSORED_BY
-
-* P_DEFAULT_GUILD
-
-* P_DEFAULT_NOTIFY_FAIL
-
-* P_DEFENDERS
-
-* P_DEFEND_FUNC
-
-* P_DEFUEL_AMOUNT_DRINK
-
-* P_DEFUEL_AMOUNT_FOOD
-
-* P_DEFUEL_LIMIT_DRINK
-
-* P_DEFUEL_LIMIT_FOOD
-
-* P_DEFUEL_TIME_DRINK
-
-* P_DEFUEL_TIME_FOOD
-
-* P_DEPARTMSG
-
-* P_DESCRIPTION
-
-* P_DESTROY_BAD
-
-* P_DESTRUCT_MSG
-
-* P_DETAILS
-
-* P_DIE_MSG
-
-* P_DISABLE_ATTACK
-
-* P_DISABLE_COMMANDS
-
-* P_DISTRIBUTION
-
-* P_DMSG
-
-* P_DOMAIN
-
-* P_DOOR_INFOS
-
-* P_DO_DESTRUCT
-
-* P_DRINK
-
-* P_DRINK_DELAY
-
-* P_DRINK_FULL_MSG
-
-* P_DROP_MSG
-
-* P_EARMUFFS
-
-* P_EATER_MSG
-
-* P_EFFECTIVE_AC
-
-* P_EFFECTIVE_WC
-
-* P_EMPTY_MSG
-
-* P_EMPTY_PROPS
-
-* P_ENABLE_IN_ATTACK_OUT
-
-* P_ENEMY_DAMAGE
-
-* P_ENEMY_DEATH_SEQUENCE
-
-* P_ENTERCMDS
-
-* P_ENTERFAIL
-
-* P_ENTERMSG
-
-* P_ENV_MSG
-
-* P_ENV_TOO_HEAVY_MSG
-
-* P_EQUIP_TIME
-
-* P_EVAL_FACTORS
-
-* P_EVAL_OFFSETS
-
-* P_EXITS
-
-* P_EXTRA_LOOK
-
-* P_FAO
-
-* P_FAO_PORTALS
-
-* P_FISH
-
-* P_FLAGS
-
-* P_FOLLOW_SILENT
-
-* P_FOOD
-
-* P_FOOD_DELAY
-
-* P_FOOD_FULL_MSG
-
-* P_FORCE_MURDER_MSG
-
-* P_FREE_HANDS
-
-* P_FRIEND
-
-* P_FROG
-
-* P_FUEL
-
-* P_FUNC_MSG
-
-* P_FW_ALWAYS_READABLE
-
-* P_FW_UNDERSTAND
-
-* P_GENDER
-
-* P_GHOST
-
-* P_GIVE_MSG
-
-* P_GLOBAL_SKILLPROPS
-
-* P_GUARD
-
-* P_GUILD
-
-* P_GUILD_DEACTIVATE_SKILLS
-
-* P_GUILD_DEFAULT_SPELLBOOK
-
-* P_GUILD_FEMALE_TITLES
-
-* P_GUILD_LEVEL
-
-* P_GUILD_LEVELS
-
-* P_GUILD_MALE_TITLES
-
-* P_GUILD_PREPAREBLOCK
-
-* P_GUILD_RATING
-
-* P_GUILD_RESTRICTIONS
-
-* P_GUILD_SKILLS
-
-* P_GUILD_TITLE
-
-* P_HANDS
-
-* P_HANDS_USED_BY
-
-* P_HARBOUR
-
-* P_HAUS_ERLAUBT
-
-* P_HB
-
-* P_HEAL
-
-* P_HELPER_NPC
-
-* P_HELPER_OBJECTS
-
-* P_HIDE_EXITS
-
-* P_HISTMIN
-
-* P_HIT_FUNC
-
-* P_HOMEPAGE
-
-* P_HP
-
-* P_HP_DELAY
-
-* P_HP_HOOKS
-
-* P_HUNTTIME
-
-* P_IDS
-
-* P_IGNORE
-
-* P_INDOORS
-
-* P_INFO
-
-* P_INFORMME
-
-* P_INPC_HOME
-
-* P_INPC_LAST_ENVIRONMENT
-
-* P_INPC_LAST_PLAYER_CONTACT
-
-* P_INPC_WALK_AREA
-
-* P_INPC_WALK_DELAYS
-
-* P_INPC_WALK_FLAGS
-
-* P_INPC_WALK_MODE
-
-* P_INPC_WALK_ROUTE
-
-* P_INTERMUD
-
-* P_INTERNAL_EXTRA_LOOK
-
-* P_INT_LIGHT
-
-* P_INT_LONG
-
-* P_INT_SHORT
-
-* P_INVIS
-
-* P_IP_NAME
-
-* P_IS_ARTILLERY
-
-* P_ITEMS
-
-* P_I_HATE_ALCOHOL
-
-* P_KEEPER
-
-* P_KEEP_ON_SELL
-
-* P_KILLER
-
-* P_KILLS
-
-* P_KILL_MSG
-
-* P_KILL_NAME
-
-* P_KNOWN_POTIONROOMS
-
-* P_LASTDIR
-
-* P_LAST_COMBAT_TIME
-
-* P_LAST_COMMAND_ENV
-
-* P_LAST_CONTENT_CHANGE
-
-* P_LAST_DAMAGE
-
-* P_LAST_DAMTIME
-
-* P_LAST_DAMTYPES
-
-* P_LAST_DEATH_PROPS
-
-* P_LAST_DEATH_TIME
-
-* P_LAST_LOGIN
-
-* P_LAST_LOGOUT
-
-* P_LAST_MOVE
-
-* P_LAST_USE
-
-* P_LAST_WEAR_ACTION
-
-* P_LAST_XP
-
-* P_LEAVECMDS
-
-* P_LEAVEFAIL
-
-* P_LEAVEMSG
-
-* P_LEP
-
-* P_LEVEL
-
-* P_LIFETIME
-
-* P_LIGHT
-
-* P_LIGHTDESC
-
-* P_LIGHTED
-
-* P_LIGHT_ABSORPTION
-
-* P_LIGHT_MODIFIER
-
-* P_LIGHT_TRANSPARENCY
-
-* P_LIGHT_TYPE
-
-* P_LIQUID
-
-* P_LOCALCMDS
-
-* P_LOCATION
-
-* P_LOG_INFO
-
-* P_LONG
-
-* P_LONG_EMPTY
-
-* P_LONG_FULL
-
-* P_MAGIC
-
-* P_MAGIC_RESISTANCE_OFFSET
-
-* P_MAILADDR
-
-* P_MAP_RESTRICTIONS
-
-* P_MARRIED
-
-* P_MATERIAL
-
-* P_MATERIAL_KNOWLEDGE
-
-* P_MAX_ALCOHOL
-
-* P_MAX_DRINK
-
-* P_MAX_FOOD
-
-* P_MAX_HANDS
-
-* P_MAX_HP
-
-* P_MAX_OBJECTS
-
-* P_MAX_PASSENGERS
-
-* P_MAX_POISON
-
-* P_MAX_SP
-
-* P_MAX_WEIGHT
-
-* P_MESSAGE_BEEP
-
-* P_MESSAGE_PREPEND
-
-* P_MIN_STOCK
-
-* P_MMSGIN
-
-* P_MMSGOUT
-
-* P_MSGIN
-
-* P_MSGOUT
-
-* P_MSG_PROB
-
-* P_MUD_NEWBIE
-
-* P_MURDER_MSG
-
-* P_M_ATTR_MOD
-
-* P_M_HEALTH_MOD
-
-* P_NAME
-
-* P_NAME_ADJ
-
-* P_NEEDED_QP
-
-* P_NETDEAD_ENV
-
-* P_NETDEAD_INFO
-
-* P_NEVERDROP
-
-* P_NEVER_CLEAN
-
-* P_NEWSKILLS
-
-* P_NEXT_DEATH_SEQUENCE
-
-* P_NEXT_DISABLE_ATTACK
-
-* P_NOBUY
-
-* P_NOCORPSE
-
-* P_NODRINK_MSG
-
-* P_NODROP
-
-* P_NOFOOD_MSG
-
-* P_NOGET
-
-* P_NOINSERT_MSG
-
-* P_NOLEAVE_MSG
-
-* P_NOMAGIC
-
-* P_NOSELL
-
-* P_NO_ASCII_ART
-
-* P_NO_ATTACK
-
-* P_NO_BAD
-
-* P_NO_GLOBAL_ATTACK
-
-* P_NO_PARA_TRANS
-
-* P_NO_PLAYERS
-
-* P_NO_REGENERATION
-
-* P_NO_SCORE
-
-* P_NO_STD_DRINK
-
-* P_NO_TPORT
-
-* P_NO_TRAVELING
-
-* P_NO_XP
-
-* P_NPC
-
-* P_NPC_FASTHEAL
-
-* P_NR_HANDS
-
-* P_ORAKEL
-
-* P_ORIG_FILE_NAME
-
-* P_ORIG_NAME
-
-* P_PARA
-
-* P_PARRY
-
-* P_PARRY_WEAPON
-
-* P_PEACE_HISTORY
-
-* P_PERM_STRING
-
-* P_PICK_MSG
-
-* P_PILE_NAME
-
-* P_PLAYER_LIGHT
-
-* P_PLURAL
-
-* P_POISON
-
-* P_POISON_DELAY
-
-* P_PORTIONS
-
-* P_POST
-
-* P_POTIONROOMS
-
-* P_PRAY_ROOM
-
-* P_PREFERED_ENEMY
-
-* P_PRESAY
-
-* P_PREVENT_PILE
-
-* P_PRE_INFO
-
-* P_PROMPT
-
-* P_PUB_NOT_ON_MENU
-
-* P_PUB_NO_KEEPER
-
-* P_PUB_NO_MONEY
-
-* P_PUB_UNAVAILABLE
-
-* P_PURSUERS
-
-* P_PUT_MSG
-
-* P_QP
-
-* P_QUALITY
-
-* P_QUESTS
-
-* P_QUEST_ITEM
-
-* P_RACE
-
-* P_RACESTRING
-
-* P_RACE_DESCRIPTION
-
-* P_RANGE
-
-* P_READ_DETAILS
-
-* P_READ_NEWS
-
-* P_REAL_RACE
-
-* P_REFERENCE_OBJECT
-
-* P_REJECT
-
-* P_REMOVE_FUNC
-
-* P_REMOVE_MSG
-
-* P_RESET_LIFETIME
-
-* P_RESISTANCE
-
-* P_RESISTANCE_MODIFIER
-
-* P_RESISTANCE_STRENGTHS
-
-* P_RESTRICTIONS
-
-* P_ROOM_MSG
-
-* P_ROOM_TYPE
-
-* P_SB_SPELLS
-
-* P_SCREENSIZE
-
-* P_SECOND
-
-* P_SECOND_MARK
-
-* P_SEERDOORS
-
-* P_SEERDOOR_ALLOWED
-
-* P_SENSITIVE
-
-* P_SENSITIVE_ATTACK
-
-* P_SENSITIVE_INVENTORY
-
-* P_SENSITIVE_INVENTORY_TRIGGER
-
-* P_SHOOTING_AREA
-
-* P_SHOOTING_WC
-
-* P_SHORT
-
-* P_SHORT_CWD
-
-* P_SHOWEMAIL
-
-* P_SHOW_ALIAS_PROCESSING
-
-* P_SHOW_EXITS
-
-* P_SHOW_INV
-
-* P_SHOW_MSG
-
-* P_SIBLINGS
-
-* P_SIZE
-
-* P_SKILLS
-
-* P_SKILL_ATTRIBUTES
-
-* P_SKILL_ATTRIBUTE_OFFSETS
-
-* P_SMELLS
-
-* P_SNOOPFLAGS
-
-* P_SOUNDS
-
-* P_SP
-
-* P_SPECIAL_DETAILS
-
-* P_SPECIAL_EXITS
-
-* P_SPELLRATE
-
-* P_SPELLS
-
-* P_SP_DELAY
-
-* P_START_HOME
-
-* P_STD_OBJECT
-
-* P_STORE_CONSUME
-
-* P_STRETCH_TIME
-
-* P_SUBGUILD_TITLE
-
-* P_SYNTAX_HELP
-
-* P_TARGET_AREA
-
-* P_TEAM
-
-* P_TEAM_ASSOC_MEMBERS
-
-* P_TEAM_ATTACK_CMD
-
-* P_TEAM_AUTOFOLLOW
-
-* P_TEAM_COLORS
-
-* P_TEAM_LEADER
-
-* P_TEAM_NEWMEMBER
-
-* P_TEAM_WANTED_ROW
-
-* P_TEAM_WIMPY_ROW
-
-* P_TELNET_RTTIME
-
-* P_TESTPLAYER
-
-* P_TIMED_ATTR_MOD
-
-* P_TIMEZONE
-
-* P_TITLE
-
-* P_TOO_HEAVY_MSG
-
-* P_TOO_MANY_MSG
-
-* P_TOTAL_AC
-
-* P_TOTAL_LIGHT
-
-* P_TOTAL_OBJECTS
-
-* P_TOTAL_WC
-
-* P_TOTAL_WEIGHT
-
-* P_TOUCH_DETAILS
-
-* P_TPORT_COST_IN
-
-* P_TPORT_COST_OUT
-
-* P_TRANK_FINDEN
-
-* P_TRANSPARENT
-
-* P_TRAVEL_CMDS
-
-* P_TRAVEL_INFO
-
-* P_TRAY
-
-* P_TTY
-
-* P_TTY_COLS
-
-* P_TTY_ROWS
-
-* P_TTY_SHOW
-
-* P_TTY_TYPE
-
-* P_UNIT_DECAY_FLAGS
-
-* P_UNIT_DECAY_INTERVAL
-
-* P_UNIT_DECAY_MIN
-
-* P_UNIT_DECAY_QUOTA
-
-* P_UNWEAR_MSG
-
-* P_UNWIELD_FUNC
-
-* P_UNWIELD_MSG
-
-* P_UNWIELD_TIME
-
-* P_USED_HANDS
-
-* P_VALID_GUILDS
-
-* P_VALUE
-
-* P_VALUE_PER_UNIT
-
-* P_VARIABLES
-
-* P_VISIBLE_GUILD
-
-* P_VISIBLE_SUBGUILD_TITLE
-
-* P_VISUALBELL
-
-* P_VULNERABILITY
-
-* P_WAITFOR
-
-* P_WAITFOR_FLAGS
-
-* P_WAITFOR_REASON
-
-* P_WANTS_TO_LEARN
-
-* P_WATER
-
-* P_WC
-
-* P_WEAPON
-
-* P_WEAPON_TEACHER
-
-* P_WEAPON_TYPE
-
-* P_WEAR_FUNC
-
-* P_WEAR_MSG
-
-* P_WEIGHT
-
-* P_WEIGHT_PERCENT
-
-* P_WEIGHT_PER_UNIT
-
-* P_WIELDED
-
-* P_WIELD_FUNC
-
-* P_WIELD_MSG
-
-* P_WIMPY
-
-* P_WIMPY_DIRECTION
-
-* P_WIZ_DEBUG
-
-* P_WORN
-
-* P_XP
-
-* P_X_ATTR_MOD
-
-* P_X_HEALTH_MOD
-
-* P_ZAP_MSG
-
-* U_REQ
-
-* skill_info_liste
-
-* Verzeichnis der Gilden-Properties
-
-* Verzeichnis der obsoleten Properties
diff --git a/doc/sphinx/man/props-obsolet b/doc/sphinx/man/props-obsolet
deleted file mode 100644
index a7e8edd..0000000
--- a/doc/sphinx/man/props-obsolet
+++ /dev/null
@@ -1,29 +0,0 @@
-
-Verzeichnis der obsoleten Properties
-************************************
-
-* P_BALANCED_WEAPON
-
-* P_DEFAULT_INFO
-
-* P_LAST_KILLER
-
-* P_LAST_PEACE_TIME
-
-* P_LOG_FILE
-
-* P_NEXT_SPELL_TIME
-
-* P_READ_MSG
-
-* P_TECHNIQUE
-
-* P_TMP_ATTACK_HOOK
-
-* P_TMP_ATTACK_MOD
-
-* P_TMP_DEFEND_HOOK
-
-* P_TMP_DIE_HOOK
-
-* P_TMP_MOVE_HOOK
diff --git a/doc/sphinx/man/props.index b/doc/sphinx/man/props.index
deleted file mode 100644
index b63a77e..0000000
--- a/doc/sphinx/man/props.index
+++ /dev/null
@@ -1,159 +0,0 @@
-
-Properties
-**********
-
-Properties sind im MG Eigenschaften eines Objektes, welche von (in der
-Regel) von aussen gesetzt werden koennen (im Gegensatz zu Variablen
-innerhalb von Objekten).
-
-
-BESCHREIBUNG:
-=============
-
-Im Gegensatz zu Variablen innerhalb eines Objektes, kann man
-Properties von aussen veraendern, ohne eine besondere Funktion
-geschrieben zu haben.
-
-
-Das zugrundeliegende Prinzip
-----------------------------
-
- Das grundlegende Konzept der MUDlib ist, dass wichtige,
- objektbezogene Informationen in den sogenannnten Properties
- gespeichert werden (engl. property -- Eigenschaft, Eigentum).
- Diese Informationen koennen einfache Werte, wie z.B. Zahlen,
- Zeichen oder Objekte, aber auch kompliziertere Strukturen sein.
- Jedes Objekt kann beliebig viele solcher Properties besitzen und
- deren Namensgebung ist nicht nur auf die von der MUDlib
- bereitgestellten Standardproperties begrenzt. Das heisst, das
- fuer eigene Anwendungen die Menge der Properties fuer ein Objekt
- beliebig erweitert werden kann. Damit sind auch schon die beiden
- Hauptmerkmale einer Property ange- sprochen:
-
- 1. ein Name oder Kennung und
-
- 2. ein Wert, der durch den Namen repraesentiert wird.
-
- Das reine Verwalten einer Property mit Namen und Wert ist aber
- nicht sehr sinnvoll und so gehoeren zu jeder Property noch zwei
- weitere wichtige Dinge. Zu jeder Property wurden jeweils zwei
- Operationen eingefuehrt, welche den uebergebenen Wert vor der
- Speicherung oder Abfrage bearbeiten.
-
- Zusammenfassend laesst sich das Konzept der Property in folgendem
- Schema darstellen:
-
- +-------------------------------------------+
- | Property |
- +-------------------------------------------+
- | privater Datenbereich (Property Werte) |
- +-------------------------------------------+
- | Direktzugriff auf den Datenbereich |
- +-------------------------------------+ |
- | ^ Methoden v | ^ v |
- | Setzen | Abfragen | |
- +-------------------------------------+-----+
- ^ |
- | V
- SetProp() QueryProp()
-
- Aus dem Schema laesst sich Folgendes erkennen
-
- * beim Setzen und Abfragen wird der Wert einer Methode
- uebergeben, die den Wert zurueckgibt oder ggf. die Aenderungen
- vornimmt
-
- * ein direkter Zugriff auf den Wert der ist ebenfalls moeglich,
- sollte aber nicht der Normalfall sein, da die Methoden
- Nebeneffekte erzeugen
-
- * in bestimmten Faellen kann man den aeusserlich aendernden
- Zugriff vollkommen unterbinden (NOSETMETHOD, PROTECT) (VORSICHT
- bei mappings/arrays, diese werden bei QueryProp() als Referenz
- zurueckgegeben, sind also so aenderbar)
-
-
-Implementation
---------------
-
- Die Klasse /std/thing/properties.c stellt folgende Funktionen fuer
- die Behandlung von Properties bereit:
-
- * Normaler Zugriff
-
- * "mixed SetProp(<name>, <wert>)" setzt den Wert von <name> auf
- <wert>
-
- * "mixed QueryProp(<name>)" gibt den Wert von <name> zurueck
-
- * Direkter Zugriff
-
- * "mixed Set(<name>, <wert>, <interpretation>)" wird genutzt,
- um eines der folgenden zu setzen:
-
- * den normalen Wert (aber fast immer besser: *SetProp()*
- verwenden!)
-
- * eine Query- oder Setmethode
-
- * ein Flag/Modus: Speicherstatus/Zugriffsschutz
-
- * "mixed Query(<name>, <interpretation>)" fragt fuer <name>
- einen <wert> ab
-
- * den normalen Wert (aber fast immer besser: *QueryProp()*
- verwenden!)
-
- * die Closure der Query- oder Setmethode
-
- * den Modus der Property
-
-
-Besonderheiten/Eingebaute Properties
-------------------------------------
-
- Existiert zu einer Property eine Funktion mit dem selben Namen und
- einem "_set_" bzw "_query_" davor, so wird nicht auf die das
- Property-Mapping zugegriffen, sondern es werden die Argumente an
- diese Funktion uebergeben und der Rueckgabewert dieser Funktion
- zurueckgegeben.
-
- * Vorteile
-
- * so kann man Daten, die schnell verfuegbar sein muessen,
- (bei denen also Effizienz gegen SetProp/QueryProp spricht)
- trotzdem nach aussen einheitlich zugreifbar machen
-
- * Nachteile
-
- * nicht wirklich sauber
-
- * Speichern muss man selbst vornehmen
-
- * Set/Query gehen wie auch bei Methoden an _set_*/_query_*
- vorbei
-
- * dieses Verhalten sollte der Mudlib vorbehalten bleiben,
- fuer eigene Prueffunktionen (wird etwas gesetzt/abgefragt)
- bzw. Aenderungen sollte man Methoden
- (F_SET_METHOD/F_QUERY_METHOD) benutzen
-
-
-SIEHE AUCH:
-===========
-
-* *SetProp()*, *QueryProp()*, *Set()*, *Query()*,
-
-* *SetProperties()*, *QueryProperties()*
-
-* objekte, effizienz, closures
-
-
-Gesamtverzeichnis der dokumentierten Properties:
-================================================
-
-* Propertyliste
-
-* Verzeichnis der Gilden-Properties
-
-* Verzeichnis der obsoleten Properties
diff --git a/doc/sphinx/man/props/P_ABILITIES b/doc/sphinx/man/props/P_ABILITIES
deleted file mode 100644
index b852bdf..0000000
--- a/doc/sphinx/man/props/P_ABILITIES
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_ABILITIES
-***********
-
-
-NAME
-====
-
- P_ABILITIES "abilities"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- *** OBSOLET! ***
- Siehe P_NEWSKILLS.
diff --git a/doc/sphinx/man/props/P_AC b/doc/sphinx/man/props/P_AC
deleted file mode 100644
index e9eda47..0000000
--- a/doc/sphinx/man/props/P_AC
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_AC
-****
-
-
-NAME
-====
-
- P_AC "ac"
-
-
-DEFINIERT IN
-============
-
- <armour.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property beschreibt die Ruestungsklasse (engl: armour class),
- also den Schutz, den die Ruestung dem Traeger verleiht. Je hoeher der
- Wert (als Zahl), um so besser ist die Ruestung. Negative Werte bewirken
- negativen Schutz, d.h. der Schaden wird vergroessert statt verringert.
-
-
-BEMERKUNGEN
-===========
-
- Query- und Setmethoden auf P_AC sollten unbedingt vermieden werden. Sie
- fuehren in der Regel zu massiven Inkonsistenzen im Mechanismus der
- Ruestungsbeschaedigung und -reparatur.
- Fuer jeden Ruestungstyp ist in <combat.h> eine Obergrenze definiert,
- die man nicht ueberschreiten darf.
- Ruestungen vom Typ AT_MISC haben immer AC 0 und werden mit keinen
- hoeheren Werten genemigt.
-
-
-SIEHE AUCH
-==========
-
- /std/armour.c, P_DAMAGED, Damage() P_TOTAL_AC
-
-02.10.2007, Zesstra
diff --git a/doc/sphinx/man/props/P_ACCEPT_PEACE b/doc/sphinx/man/props/P_ACCEPT_PEACE
deleted file mode 100644
index 214dc06..0000000
--- a/doc/sphinx/man/props/P_ACCEPT_PEACE
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_ACCEPT_PEACE
-**************
-
-
-PROPERTY
-========
-
- P_ACCEPT_PEACE "accept_peace"
-
-
-DEFINIERT IN
-============
-
- /sys/combat.h
-
-
-BESCHREIBUNG
-============
-
- Mittels setzen Dieser Prop lassen sich leicht NPCs bauen,
- die von jedem zu befrieden sind. Wenn die Property == 1 ist,
- ist der NPC immer wieder befriedbar, sonst fuehrt der NPC das
- uebliche Verhalten aus.
-
-
-SIEHE AUCH
-==========
-
- QueryPacify(),
- P_PEACE_HISTORY
-
-
-LETZTE AENDERUNG
-================
-
-01.05.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_ACHATS b/doc/sphinx/man/props/P_ACHATS
deleted file mode 100644
index c62e357..0000000
--- a/doc/sphinx/man/props/P_ACHATS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_ACHATS
-********
-
-
-NAME
-====
-
- P_ACHATS "achats"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Chats, die das Monster im Kampf ausgibt.
diff --git a/doc/sphinx/man/props/P_ACHAT_CHANCE b/doc/sphinx/man/props/P_ACHAT_CHANCE
deleted file mode 100644
index fc28ac9..0000000
--- a/doc/sphinx/man/props/P_ACHAT_CHANCE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_ACHAT_CHANCE
-**************
-
-
-NAME
-====
-
- P_ACHAT_CHANCE "achat_chance"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wahrscheinlichkeit fuer die Attack-Chat-Ausgabe.
diff --git a/doc/sphinx/man/props/P_ACTUAL_NOTIFY_FAIL b/doc/sphinx/man/props/P_ACTUAL_NOTIFY_FAIL
deleted file mode 100644
index 0c9acd1..0000000
--- a/doc/sphinx/man/props/P_ACTUAL_NOTIFY_FAIL
+++ /dev/null
@@ -1,51 +0,0 @@
-
-P_ACTUAL_NOTIFY_FAIL
-********************
-
-********************** VERALTETE PROPERTY
-*********************************
-
-
-NAME
-====
-
- P_ACTUAL_NOTIFY_FAIL "actual_notify_fail"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-ACHTUNG
-=======
-
- Diese Prop wird nicht mehr gesetzt (und auch nicht mehr abgefragt), da LD
- eine efun hat, um das Objekt zu ermitteln, was als letztes ein
- notify_fail() gesetzt hat, ein Speichern im Spieler also voellig
- ueberfluessig ist.
-
-
-BESCHREIBUNG
-============
-
- Ist im Spielerobjekt gesetzt und enthaelt das Objekt, welches zuletzt
- eine Fehlermeldung mit notify_fail()/_notify_fail() erfolgreich
- waehrend des aktuellen Kommandos abgespeichert hat.
-
-
-BEMERKUNGEN
-===========
-
- Dient dazu, bei _notify_fail() zu ueberpruefen, ob schon vorher eine
- Fehlermeldung gesetzt wurde.
-
-
-SIEHE AUCH
-==========
-
- AddCmd(), add_action()
- notify_fail(), _notify_fail()
-
-10.03.2007, Zesstra
diff --git a/doc/sphinx/man/props/P_ADJECTIVES b/doc/sphinx/man/props/P_ADJECTIVES
deleted file mode 100644
index 1c8ccb6..0000000
--- a/doc/sphinx/man/props/P_ADJECTIVES
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_ADJECTIVES
-************
-
-
-NAME
-====
-
- P_ADJECTIVES "adjectives"
-
-
-DEFINIERT IN
-============
-
- <thing/description.h>
-
-
-BESCHREIBUNG
-============
-
- Hier steht ein Array von Strings, welche die Identifizierung des
- Objektes ergaenzen. Die Verwaltung erfolgt ueber die Funktionen
- AddAdjective() und RemoveAdjective().
-
-
-BEMERKUNGEN
-===========
-
- Man sollte an dieser Property nicht "von Hand" herumfummeln, sondern
- immer die zugehoerigen Funktionen benutzen!
-
-
-SIEHE AUCH
-==========
-
- /std/thing/description.c, AddAdjective(), RemoveAdjective()
-
-Last modified: Sun May 19 20:22:24 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_AERIAL_HELPERS b/doc/sphinx/man/props/P_AERIAL_HELPERS
deleted file mode 100644
index 781510c..0000000
--- a/doc/sphinx/man/props/P_AERIAL_HELPERS
+++ /dev/null
@@ -1,63 +0,0 @@
-
-P_AERIAL_HELPERS
-****************
-
-
-NAME
-====
-
- P_AERIAL_HELPERS "lib_p_aerial_helpers"
-
-
-DEFINIERT IN
-============
-
- <living/helpers.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property kann in allen Lebewesen abgefragt werden, um die Objekte
- zu ermitteln, die fuer die Unterstuetzung beim Fliegen/Segeln bei diesem
- Lebewesen registriert haben. Die Daten werden als Mapping der folgenden
- Form zurueckgeliefert:
- ([ Objekt : Rueckgabewert von dessen Callback-Methode ])
- Eine Erlaeuterung dazu findet sich in der Dokumentation zu
- RegisterHelperObject().
-
-
-BEMERKUNGEN
-===========
-
- Diese Property kann nur abgefragt werden.
- Es ist erwuenscht, dass entsprechende, neu geschaffene Stellen jegliche
- Helfer akzeptieren, deren Callback-Methode >0 zurueckgibt.
-
-
-BEISPIEL
-========
-
- Um zu ermitteln, ob der Spieler mindestens ein Objekt bei sich hat, das
- beim Fliegen hilft, sucht man alle Objekte aus dem Mapping heraus, die
- einen Wert >0 eingetragen haben und prueft deren Anzahl:
-
- mapping aerial = this_player()->QueryProp(P_AERIAL_HELPERS);
- object* helpers = filter( aerial, function int (object h) {
- return (aerial[h]>0); });
- if ( sizeof(helpers) ) {
- tell_object(this_player(), "Du erhebst Dich mit Hilfe "+
- helpers[0]->name(WESSEN,1)+" elegant in die Luefte.\n");
- }
- else {
- tell_object(this_player(), "Du hast nichts zum Fliegen bei Dir.\n");
- }
-
-
-SIEHE AUCH
-==========
-
- Methoden: RegisterHelperObject(L), UnregisterHelperObject(L)
- Properties: P_HELPER_OBJECTS, P_AQUATIC_HELPERS
-
-12.03.2016, Arathorn
diff --git a/doc/sphinx/man/props/P_AGE b/doc/sphinx/man/props/P_AGE
deleted file mode 100644
index e35473c..0000000
--- a/doc/sphinx/man/props/P_AGE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_AGE
-*****
-
-
-NAME
-====
-
- P_AGE "age"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Alter des Spielers in Heart-Beats (1 HB == 2 Sekunden)
diff --git a/doc/sphinx/man/props/P_AGGRESSIVE b/doc/sphinx/man/props/P_AGGRESSIVE
deleted file mode 100644
index 5184687..0000000
--- a/doc/sphinx/man/props/P_AGGRESSIVE
+++ /dev/null
@@ -1,55 +0,0 @@
-
-P_AGGRESSIVE
-************
-
-
-NAME
-====
-
- P_AGGRESSIVE "aggressive"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Gesetzt, wenn das Wesen von sich aus Angriffe startet.
-
- Ueblicherweise nimmt man als Wert 1, man kann jedoch auch
- einen kleineren Wert nehmen wenn es nur mit einer bestimmten
- Wahrscheinlichkeit automatisch angreifen soll.
-
- Der Wert von Spieler und Monster wird addiert, um zu entscheiden,
- ob ein Spieler angegriffen werden soll, man kann P_AGGRESSIVE
- also auch bei Spielern setzen, so dass sie von allen Monstern
- angegriffen werden.
-
- Bei Monstern (und NUR bei diesen) kann man hier auch ein Mapping
- angeben, das als Keys Namen von Properties des Spielers enthaelt
- und als Values Mappings, in denen steht welcher Wert bei welchen
- Wert fuer die Property genommen werden soll (Beispiele folgen).
- Mit Key 0 kann man einen Default-Wert (sowohl in inneren Mappings
- wie auch im aeusseren Mapping) festlegen. Default-Werte werden
- genommen, falls keine anderen gesetzt sind, also Vorsicht mit
- 0-Eintraegen (Tip: 0.0 ist in LPC ungleich 0).
- Bei mehreren Properties werden alle gesetzten Werte gemittelt.
-
-
-BEISPIELE
-=========
-
- SetProp(P_AGGRESSIVE,([P_RACE:(["Zwerg":1, "Elf":0.0, 0:0.5])]))
- Zwerge werden immer automatisch angegriffen, Elfen nie und
- alle anderen mit 50% Wahrscheinlichkeit.
- Man beachte, dass hier 0.0 genommen werden musste anstelle von 0,
- weil sonst Elfen auch 50% Wahrscheinlichkeit bekommen haetten.
-
- SetProp(P_AGGRESSIVE,([P_RACE:(["Zwerg":0.3]),
- P_GUILD:(["Chaos":0.7])]))
- Zwerge werden mit 30% Wahrscheinlichkeit angegriffen,
- Chaoten mit 70% und Zwerg-Chaoten mit 50%.
diff --git a/doc/sphinx/man/props/P_ALCOHOL b/doc/sphinx/man/props/P_ALCOHOL
deleted file mode 100644
index d827a94..0000000
--- a/doc/sphinx/man/props/P_ALCOHOL
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_ALCOHOL
-*********
-
-
-NAME
-====
-
- P_ALCOHOL "alcohol"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- - Lebewesen
- Numerischer Wert fuer den Grad der Betrunkenheit eines Lebewesens.
- Der maximale Wert steht in P_MAX_ALCOHOL.
-
- - Speisen/Kneipen
- Numerischer Wert fuer den Grad, den eine Portion der Speise den
- Konsumenten betrunken macht
-
-
-SIEHE AUCH
-==========
-
- P_MAX_ALCOHOL, P_ALCOHOL_DELAY, consume,
- P_FOOD, P_DRINK, wiz/food,
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_ALCOHOL_DELAY b/doc/sphinx/man/props/P_ALCOHOL_DELAY
deleted file mode 100644
index 6ea0513..0000000
--- a/doc/sphinx/man/props/P_ALCOHOL_DELAY
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_ALCOHOL_DELAY
-***************
-
-
-NAME
-====
-
- P_ALCOHOL_DELAY "alcohol_delay"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der heart_beats, bis P_ALCOHOL um einen Punkt sinkt.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
diff --git a/doc/sphinx/man/props/P_ALC_FULL_MSG b/doc/sphinx/man/props/P_ALC_FULL_MSG
deleted file mode 100644
index 5df4b65..0000000
--- a/doc/sphinx/man/props/P_ALC_FULL_MSG
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_ALC_FULL_MSG
-**************
-
-
-NAME
-====
-
- P_ALC_FULL_MSG "std_food_alc_full_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Konsumenten, wenn Alkohol konsumiert werden soll,
- obwohl dieser nicht mehr Alkohol vertraegt.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "Soviel Alkohol vertraegst Du nicht mehr."
-
-
-SIEHE AUCH
-==========
-
- P_ALCOHOL, P_MAX_ALCOHOL, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_ALIGN b/doc/sphinx/man/props/P_ALIGN
deleted file mode 100644
index d4ca76c..0000000
--- a/doc/sphinx/man/props/P_ALIGN
+++ /dev/null
@@ -1,29 +0,0 @@
-
-P_ALIGN
-*******
-
-
-NAME
-====
-
- P_ALIGN "align"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert fuer Gut- oder Boesheit des Wesens.
-
- Kann Werte von -1000 (Boese wie der Teufel hoechstpersoenlich)
- bis +1000 (Jesus, bist Du's ?) annehmen.
-
- Werte ausserhalb dieser Skala werden zwar teilweise verwendet,
- das Setzen derselben sollte jedoch UNBEDINGT unterbleiben.
-
-Last modified: Sat Jul 12 17:00:00 by Mandragon
diff --git a/doc/sphinx/man/props/P_ALLOWED_SHADOW b/doc/sphinx/man/props/P_ALLOWED_SHADOW
deleted file mode 100644
index 5d849b7..0000000
--- a/doc/sphinx/man/props/P_ALLOWED_SHADOW
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_ALLOWED_SHADOW
-****************
-
-
-NAME
-====
-
- P_ALLOWED_SHADOW "allowed_shadow"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Normalerweise koennen nur Shadows an Spieler gebunden werden, die in
- /std/player/shadows/ liegen.
-
-
-
- Zu Testzwecken kann in dieser Property der Pfad eines Shadows eingetragen
- werden. Damit wird die oben beschriebene Regel fuer diesen Spieler und
- diesen Shadow ausser Kraft gesetzt.
-
-BEMERKUNG:
-
- Der Spieler muss ein Testspieler sein. Ansonsten wird diese
- Property ignoriert.
-
- Die Property ist secured gesetzt. Das heisst, nur EM+ koennen diese
- Property setzen und loeschen.
-
-Last modified: Sun Mar 21 00:27:46 2004 by Vanion
diff --git a/doc/sphinx/man/props/P_AMMUNITION b/doc/sphinx/man/props/P_AMMUNITION
deleted file mode 100644
index cbe7f56..0000000
--- a/doc/sphinx/man/props/P_AMMUNITION
+++ /dev/null
@@ -1,62 +0,0 @@
-
-P_AMMUNITION
-************
-
-
-NAME
-====
-
- P_AMMUNITION "munition"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die fuer eine Waffe gueltige Munition als String. Die
- Munition muss diesen String als ID besitzen.
-
- Fuer die Munitionsobjekte gilt:
- * es kann ein Skill am Spieler definiert werden, dieser wirkt dann
- zusaetzlich zum generellen SK_SHOOT-Skill.
- * sie koennen eine HitFunc besitzten, die beim Schuss abgefragt wird
-
-
-BEMERKUNGEN
-===========
-
- Bitte das #define MUN_MISC(x) benutzen. Munition sollte auch immer
- in Deutsch und Plural angegeben werden, da P_AMMUNITION direkt
- fuer Ausgaben an den Spieler ausgewertet wird.
-
- Momentan sind vier Munitionsarten in der combat.h vordefiniert:
- MUN_ARROW, MUN_STONE, MUN_BOLT, MUN_MISC
-
-
-BEISPIELE
-=========
-
- // fuer ein kleines Blasrohr im Blasrohr
- SetProp(P_AMMUNITION, MUN_MISC("Erbsen"));
-
- // Entsprechend in der Munition:
- AddId(MUN_MISC("Erbsen"));
-
-
-SIEHE AUCH
-==========
-
- Generell: P_SHOOTING_WC, P_STRETCH_TIME
- Methoden: FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
- Gebiet: P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
- Waffen: P_WEAPON_TYPE, P_WC, P_EQUIP_TIME, P_NR_HANDS
- Kampf: Attack(L), Defend(L), P_DISABLE_ATTACK, P_ATTACK_BUSY
- Team: PresentPosition(L)
- Sonstiges: fernwaffen
-
-29.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/props/P_AMOUNT b/doc/sphinx/man/props/P_AMOUNT
deleted file mode 100644
index 5c0e51a..0000000
--- a/doc/sphinx/man/props/P_AMOUNT
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_AMOUNT
-********
-
-
-NAME
-====
-
- P_AMOUNT "amount"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der Objekte, fuer die das Objekt steht.
diff --git a/doc/sphinx/man/props/P_AQUATIC_HELPERS b/doc/sphinx/man/props/P_AQUATIC_HELPERS
deleted file mode 100644
index 8429a41..0000000
--- a/doc/sphinx/man/props/P_AQUATIC_HELPERS
+++ /dev/null
@@ -1,64 +0,0 @@
-
-P_AQUATIC_HELPERS
-*****************
-
-
-NAME
-====
-
- P_AQUATIC_HELPERS "lib_p_aquatic_helpers"
-
-
-DEFINIERT IN
-============
-
- <living/helpers.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property kann in allen Lebewesen abgefragt werden, um die Objekte
- zu ermitteln, die fuer die Unterstuetzung beim Tauchen bei diesem
- Lebewesen registriert haben. Die Daten werden als Mapping der folgenden
- Form zurueckgeliefert:
- ([ Objekt : Rueckgabewert von dessen Callback-Methode ])
- Eine Erlaeuterung dazu findet sich in der Dokumentation zu
- RegisterHelperObject().
-
-
-BEMERKUNGEN
-===========
-
- Diese Property kann nur abgefragt werden.
- Es ist erwuenscht, dass entsprechende, neu geschaffene Stellen jegliche
- Helfer akzeptieren, deren Callback-Methode >0 zurueckgibt.
-
-
-BEISPIEL
-========
-
- Um zu ermitteln, ob der Spieler mindestens ein Objekt bei sich hat, das
- beim Tauchen hilft, sucht man alle Objekte aus dem Mapping heraus, die
- einen Wert >0 eingetragen haben und prueft deren Anzahl:
-
- mapping aquatic = this_player()->QueryProp(P_AQUATIC_HELPERS);
- object* helpers = filter( aquatic, function int (object h) {
- return (aquatic[h]>0); });
- if ( sizeof(helpers) ) {
- tell_object(this_player(), "Du stuerzt Dich in die Fluten und "
- "stellst ueberrascht fest, dass Du mit Hilfe "+
- helpers[0]->name(WESSEN,1)+" sogar unter Wasser atmen kannst!\n");
- }
- else {
- tell_object(this_player(), "Du hast nichts zum Tauchen bei Dir.\n");
- }
-
-
-SIEHE AUCH
-==========
-
- Methoden: RegisterHelperObject(L), UnregisterHelperObject(L)
- Properties: P_HELPER_OBJECTS, P_AERIAL_HELPERS
-
-06.04.2016, Arathorn
diff --git a/doc/sphinx/man/props/P_ARMOURS b/doc/sphinx/man/props/P_ARMOURS
deleted file mode 100644
index e0d6a0c..0000000
--- a/doc/sphinx/man/props/P_ARMOURS
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_ARMOURS
-*********
-
-
-NAME
-====
-
- P_ARMOURS "armours"
-
-
-DEFINIERT IN
-============
-
- <living/combat.h>
-
-
-BESCHREIBUNG
-============
-
- Array mit den getragenen Schutzbekleidungen des Lebewesen.
-
- Bitte nach Moeglichkeit davon absehen, diese Property zu beschreiben, da
- es hierbei zu Inkonsistenzen kommen kann.
-
-
-
- Falls ihr die Ruestungen des Lebewesens, ggf. mit bestimten Kriterien,
- ermitteln wollt, benutzt hierfuer bitte die Funktion FilterArmours()
- statt selber ueber dieses Array zu laufen.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: QueryArmourByType(L), P_WEAPON, FilterClothing(),
- FilterArmours()
- Ruestungen: P_AC, P_ARMOUR_TYPE, P_NR_HANDS
- Sonstiges: P_EQUIP_TIME, P_LAST_USE
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_ARMOUR_TYPE b/doc/sphinx/man/props/P_ARMOUR_TYPE
deleted file mode 100644
index 19e6812..0000000
--- a/doc/sphinx/man/props/P_ARMOUR_TYPE
+++ /dev/null
@@ -1,63 +0,0 @@
-
-P_ARMOUR_TYPE
-*************
-
-
-NAME
-====
-
- P_ARMOUR_TYPE "armour_type"
-
-
-DEFINIERT IN
-============
-
- <armour.h>
-
-
-BESCHREIBUNG
-============
-
- In dieser Property wird der Typ einer Ruestung festgehalten. Man sollte
- hier nur die in <combat.h> definierten Konstanten verwenden:
-
- AT_AMULET Amulett
- AT_ARMOUR Ruestung
- AT_BELT Guertel
- AT_BOOT Schuhe
- AT_CLOAK Umhang
- AT_GLOVE Handschuhe
- AT_HELMET Helm
- AT_QUIVER Koecher
- AT_RING Ring
- AT_SHIELD Schild
- AT_TROUSERS Hosen
- AT_MISC Sonstiges
-
- Der Ruestungstyp AT_MISC ist schnoedem Tand und anderem nutzlosen
- Kram vorbehalten. Auf keinen Fall darf eine AT_MISC-Ruestung ueber
- eine AC > 0 verfuegen noch irgendwie kampfrelevante Bedeutung be-
- sitzen. Ruestungen des Typs AT_MISC, die KEINE DefendFunc benoetigen,
- muessen mittels /std/clothing als einfaches Kleidungsstueck realisiert
- werden.
-
-
-BEMERKUNGEN
-===========
-
- Die P_AC wird bei AT_MISC-Ruestungen gar nicht erst ausgewertet.
- DefendFuncs werden zwar ausgewertet, aber bitte ueberlegt euch gut, ob
- ihr sie braucht (Rechenzeit im Kampf ist kritisch!) und ob sie seitens
- der Balance in eurem Fall erlaubt sind.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: QueryArmourByType(L), P_WEAPON
- Ruestungen: P_AC, P_NR_HANDS (Schilde)
- Sonstiges: P_EQUIP_TIME, P_LAST_USE
- Code: /std/armour.c, /std/clothing.c
- Gildenergaenzung: P_GLOVE_FINGERLESS
-
-27. Mai 2015, Arathorn
diff --git a/doc/sphinx/man/props/P_ARRIVEMSG b/doc/sphinx/man/props/P_ARRIVEMSG
deleted file mode 100644
index cdafdaa..0000000
--- a/doc/sphinx/man/props/P_ARRIVEMSG
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_ARRIVEMSG
-***********
-
-
-NAME
-====
-
- P_ARRIVEMSG "arrivemsg"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Meldung, wenn der Transporter anlegt.
diff --git a/doc/sphinx/man/props/P_ARTICLE b/doc/sphinx/man/props/P_ARTICLE
deleted file mode 100644
index 2bf2c54..0000000
--- a/doc/sphinx/man/props/P_ARTICLE
+++ /dev/null
@@ -1,28 +0,0 @@
-
-P_ARTICLE
-*********
-
-
-NAME
-====
-
- P_ARTICLE "article"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/language.h
-
-
-BESCHREIBUNG
-============
-
- Gibt an, ob in der Beschreibung ein Artikel ausgegeben werden soll
- oder nicht.
-
- Wenn ein Artikel angegeben werden soll, so wird 1 gesetzt, sonst 0.
- Diese Property ist aus historischen Gruenden auf 1 voreingestellt
- und intern invertiert. (d.h., beim Auslesen per Query kommt als
- Ergebnis genau das falsche heraus). Bitte beachtet das bei Set- bzw.
- Query-Funktionen.
diff --git a/doc/sphinx/man/props/P_ATTACK_BUSY b/doc/sphinx/man/props/P_ATTACK_BUSY
deleted file mode 100644
index dfc8ba6..0000000
--- a/doc/sphinx/man/props/P_ATTACK_BUSY
+++ /dev/null
@@ -1,67 +0,0 @@
-
-P_ATTACK_BUSY
-*************
-
-
-NAME
-====
-
- P_ATTACK_BUSY "attack_busy"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Ueber diese Property kann festgestellt werden, ob ein Spieler noch
- Spezialwaffen (zB Flammenkugel) einsetzen kann.
-
-
-
- Ist der Wert bei Abfrage ungleich 0, dann darf der Spieler in dieser
- Runde keine Aktion mehr durchfuehren. Mit SetProp(P_ATTACK_BUSY, 1)
- wird eine Aktion verbraucht.
-
- Intern wird relativ fein gerechnet, ein SetProp(P_ATTACK_BUSY, x)
- wird in das Abziehen von x*100 Punkten umgerechnet. Der Wert freier
- Aktionen pro Runde berechnet sich wie folgt:
-
-
-
- Spieler: 100 + QuerySkillAttribute(SA_SPEED)
- Seher: Spieler + 200 + QueryProp(P_LEVEL)
-
- Das Maximum liegt bei 500.
- Damit betraegt die Anzahl der moeglichen Aktionen pro Runde: Wert/100,
- also maximal 5 Aktionen pro Runde.
-
- Zaubersprueche zaehlen im Normalfall auch als eine Aktion.
-
-
-BEMERKUNGEN
-===========
-
- Benutzt man P_ATTACK_BUSY fuer eine sich nicht sofort verbrauchende
- Sache, kann ein Seher dieses Objekt im Normalfall dreimal pro Runde
- benutzen. Wenn ungewollt, muss das ueber einen Zeitmarker selbst
- verhindert werden.
-
-
-BEISPIELE
-=========
-
- (Code eines Objektes ist in
- /doc/beispiele/testobjekte/attack_busy_sensitive_testobj.c)
- // einfacher Test auf ATTACK_BUSY und anschliessendes Setzen
- if (this_player()->QueryProp(P_ATTACK_BUSY)) {
- write("Du hast dafuer momentan einfach nicht mehr die Puste.\n");
- return 1;
- }
- this_player()->SetProp(P_ATTACK_BUSY, 1);
-
-7. Mar 2011 Gloinson
diff --git a/doc/sphinx/man/props/P_ATTRIBUTES b/doc/sphinx/man/props/P_ATTRIBUTES
deleted file mode 100644
index ed5dd1c..0000000
--- a/doc/sphinx/man/props/P_ATTRIBUTES
+++ /dev/null
@@ -1,79 +0,0 @@
-
-P_ATTRIBUTES
-************
-
-
-NAME
-====
-
- P_ATTRIBUTES "attributes"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt ein Mapping mit den Attributen des
- Lebewesens. Die Schluessel kennzeichnen hierbei das jeweilige
- Attribut. Die verschiedenen Standardattribute findet man in
- /sys/living/attributes.h, welche derzeit folgende Moeglichkeiten
- bieten: - A_STR (Kraft)
- - A_INT (Intelligenz)
- - A_DEX (Geschick)
- - A_CON (Konstitution)
- Sie werden automatisch an verschiedenen Stellen in der MUDLib
- ausgewertet, zum Beispiel bestimmt A_INT die maximal moeglichen
- Konzentrationspunkte und A_CON die maximal moeglichen Lebenspunkte.
-
-
-BEMERKUNGEN
-===========
-
- Keine echte Property, _query_attributes() und _set_attributes() sind
- in /std/living/attributes.c implementiert.
-
- Es bietet sich an, zum Erfragen der Attributwerte die Funktion
- QueryAttribute() zu nutzen, da es auch moegliche Offsets gibt,
- so beispielsweise ueber die Properties P_ATTRIBUTES_OFFSETS bzw.
- P_ATTRIBUTES_MODIFIER im Lebewesen selbst, oder auch ueber
- P_X_ATTR_MOD bzw. P_M_ATTR_MOD in Objekten im Lebewesen.
- Kurzfristige zeit- oder objektgebundene Attributveraenderungen
- koennen ueber die Property P_TIMED_ATTR_MOD realisiert werden.
-
- Es gibt auch zahlreiche andere Dienstfunktionen fuer diesen sehr
- balancekritischen Bereich, siehe unten.
-
-
-BEISPIEL
-========
-
- Ein moegliches Ergebnis fuer einen frischen Level 1 Spieler waere:
- QueryProp(P_ATTRIBUTES);
- Ergebnis: (["int":1,"con":1,"str":1,"dex":1])
- Hinzu kommen eventuell moegliche Rassenboni, die mittels
- P_ATTRIBUTE_OFFSETS realisiert werden, Zwerge sind beispielsweise
- recht stark:
- QueryProp(P_ATTRIBUTES_OFFSETS);
- Ergebnis: (["int":1,"con":1,"str":1,"dex":3])
- Jetzt bekaeme man (sofern keine weiteren Offsets realisiert sind)
- mittels QueryAttribute() insgesamt:
- QueryAttribute(A_DEX);
- Ergebnis: 4
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/props/P_ATTRIBUTES_MODIFIER b/doc/sphinx/man/props/P_ATTRIBUTES_MODIFIER
deleted file mode 100644
index ab9f24d..0000000
--- a/doc/sphinx/man/props/P_ATTRIBUTES_MODIFIER
+++ /dev/null
@@ -1,78 +0,0 @@
-
-P_ATTRIBUTES_MODIFIER
-*********************
-
-
-NAME
-====
-
- P_ATTRIBUTES_MODIFIER "attributes_modifier"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property werden Attribut-Modifikatoren gespeichert, die
- laengere Zeit wirksam sein sollen, tlw. auch ueber einen Reboot
- hinweg.
- Intern werden die Modifikatoren in einem Mapping der Form
-
- ([ Setzer-Key : ([ A_xy : Wert, ... ]) , ... ])
-
- gespeichert. Das Setzen folg hingegen in der Form
-
- spieler->SetProp(P_ATTRIBUTES_MODIFIER, ([ A_xy : Wert, ... ]));
- oder
- spieler->SetProp(P_ATTRIBUTES_MODIFIER, ({ Setzer-Key, ([ ... ]) }));
-
- Bei der ersten Variante wird hierbei der Filename des setzenden Objektes
- als Setzer-Key genommen.
- Es koennen also durchaus von mehreren Objekten Modifier gesetzt werden.
- Bekannte Modifier sind:
-
- #death Attribut-Abzug durch Todesfolgen (Mudlib)
- #drain Statabzug durch NPCs (Paracelsus)
- #frosch Staerken-Abzug bei Froeschen (Mudlib)
-
-
-BEMERKUNGEN
-===========
-
- Keine echte Property, _query_attributes_modifier() und
- _set_attributes_modifier() sind in /std/living/attributes.c
- implementiert
- - SetProp/QueryProp nutzen!
- - Wenn ein Modifier nicht mehr gebracht wird, nicht die Attributswerte auf
- 0 setzen, sondern den ganzen Eintrag! also:
- SetProp(P_ATTRIBUTES_MODIFIER, ([]) );
- oder: SetProp(P_ATTRIBUTES_MODIFIER, 0 );
- aber nicht: SetProp(P_ATTRIBUTES_MODIFIER, ([A_STR:0]));
-
-
-BEISPIELE
-=========
-
- // ein Bonus ... 'ende'-fest (muss also per uid gesichert werden)
- player->SetProp(P_ATTRIBUTES_MODIFIER,
- ({"g_klerus_segen", ([A_CON:5, A_INT:5])}));
- ...
- player->SetProp(P_ATTRIBUTES_MODIFIER, ({"g_klerus_segen", 0}));
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/props/P_ATTRIBUTES_OFFSETS b/doc/sphinx/man/props/P_ATTRIBUTES_OFFSETS
deleted file mode 100644
index dfcbb8c..0000000
--- a/doc/sphinx/man/props/P_ATTRIBUTES_OFFSETS
+++ /dev/null
@@ -1,46 +0,0 @@
-
-P_ATTRIBUTES_OFFSETS
-********************
-
-
-NAME
-====
-
- P_ATTRIBUTES_OFFSETS "attributes_offsets"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt ein Mapping mit Offsets, die zu den
- Attributen eine Lebewesens addiert werden. Diese koennen auch
- negativ sein! Realisiert werden damit beispielsweise Rassenboni.
- Es gibt noch weitere Moeglichkeiten, Attributoffsets anzugeben.
- Fuer weiteres siehe P_ATTRIBUTES.
-
-
-BEMKERUNGEN
-===========
-
- Keine echte Property, _query_attributes_offsets() und
- _set_attributes_offsets() sind in /std/living/attributes.c
- implementiert.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_TIMED_ATTR_MOD,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/props/P_AUTH_INFO b/doc/sphinx/man/props/P_AUTH_INFO
deleted file mode 100644
index 953b519..0000000
--- a/doc/sphinx/man/props/P_AUTH_INFO
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_AUTH_INFO
-***********
-
-
-NAME
-====
-
- P_AUTH_INFO "auth_info"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Username des Spielers, wenn bei ihm ein AUTHD laeuft
diff --git a/doc/sphinx/man/props/P_AUTOLOAD b/doc/sphinx/man/props/P_AUTOLOAD
deleted file mode 100644
index 5e623bb..0000000
--- a/doc/sphinx/man/props/P_AUTOLOAD
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_AUTOLOAD
-**********
-
-
-NAME
-====
-
- P_AUTOLOAD "autoload"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Mapping mit der Menge der Autoloadobjekte und den zugeh.
- Properties.
-
-
-BEMERKUNGEN
-===========
-
- Funktioniert momentan nicht. Die Methode wurde entfernt. Doku bleibt
- hier bis der Fall geklaert ist. (Stand 27.Aug 2006)
-
-27.Aug 2006 Gloinson
diff --git a/doc/sphinx/man/props/P_AUTOLOADOBJ b/doc/sphinx/man/props/P_AUTOLOADOBJ
deleted file mode 100644
index 3184fff..0000000
--- a/doc/sphinx/man/props/P_AUTOLOADOBJ
+++ /dev/null
@@ -1,141 +0,0 @@
-
-P_AUTOLOADOBJ
-*************
-
-
-NAME
-====
-
- P_AUTOLOADOBJ "autoloadobj"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Hiermit kann prinzipiell angegeben werden ob ein Objekt ueber das
- Ausloggen eines Spielers (Reboot/ende) behalten werden soll.
-
- Als Inhalt der Property koennen permanente Eigenschaften des Objektes
- angegeben werden.
- Beim Einloggen wird das Objekt neu erzeugt und P_AUTOLOADOBJ auf die
- gespeicherten Werte gesetzt. Die Werte muessen allerdings selbst
- verwaltet werden.
-
- Bitte geht nicht davon aus, dass es waehrend des Setzens/Abfragens dieser
- Prop einen this_player() oder ein this_interactive() geben muss.
- Speziell ist this_interactive() nicht == /secure/login!
- Ebenfalls muss das Objekt beim Setzen/Abfragen nicht in einem Spieler
- sein.
-
-
-BEMERKUNGEN
-===========
-
- Autoloadobjekte werden beim Ausloggen nicht fallengelassen!
-
-
-BEISPIELE
-=========
-
- ## Variante 1: simples Objekt, bleibt einfach nur erhalten,
- ## Variablen werden nicht gesichert ##
- void create() {
- ...
- SetProp(P_AUTOLOADOBJ,1);
- ...
- }
-
-
- ## Variante 2: Speicherung mehrerer Variablen ueber
- ## P_AUTOLOADOBJ (elegante Verwaltung)
-
- // ein paar #defines fuer die Plaetze in der Speichervariablen
- #define MY_AL_SHORT 0
- #define MY_AL_ATTRM 1
- #define MY_AL_OWNER 2
- #define MY_AL_DESTRUCT 3
-
- // die Variablen, die erhalten bleiben sollen
- static object owner;
- static int destruct_time;
-
- // diese hier wird gerufen, wenn der Spieler gespeichert wird,
- // wir packen also alle aktuellen Variablen in eine und geben die
- // zum Speichern heraus ... wir nehmen hier ein Array (statt
- // zB eines Mappings), weil das am wenigsten Platz braucht
- static mixed* _query_autoloadobj() {
- mixed *ret;
- ret=allocate(4);
- ret[MY_AL_SHORT] = QueryProp(P_SHORT); // SHORT merken
- ret[MY_AL_ATTRM] = QueryProp(P_M_ATTR_MOD); // einen Modifikator merken
- ret[MY_AL_OWNER] = getuid(owner); // ah, ein Besitzer!
- ret[MY_AL_DESTRUCT]=destruct_time-time(); // und eine Lebensdauer!
-
- return ret;
-
- /*
- // normalerweise wuerde man das einfach so schreiben:
- return (({QueryProp(P_SHORT),
- QueryProp(P_M_ATTR_MOD),
- getuid(owner),
- destruct_time-time()}));
- */
- }
-
- // diese hier wird gerufen, wenn das Objekt neu im Spieler
- // erzeugt wurde (Login), also packen wir das Speicherarray wieder
- // aus und in alle entsprechenden Variablen
- static mixed* _set_autoloadobj(mixed *new) {
- // wenn das Format nicht mit dem oben uebereinstimmt ist was
- // schiefgelaufen
- if(pointerp(new) && !owner && sizeof(new)>4 &&
- (owner=find_player(new[MY_AL_OWNER]))) {
- // los, zuweisen!
-
- SetProp(P_SHORT, new[MY_AL_SHORT]);
- SetProp(P_M_ATTR_MOD, new[MY_AL_ATTRM]);
- destruct_time= time()+new[MY_AL_DESTRUCT];
-
- call_out(#'remove,new[3]);
- } else call_out(#'remove,0);
-
- return new;
- }
-
-
- ## Variante 3: und das gleiche mit Set/Querymethoden ##
- // Prototypen fuer Set und Query-Methoden -> man Set
- static mixed *my_query_autoloadobj();
- static mixed *my_set_autoloadobj(mixed *new);
-
- void create() {
- // Binden der Methoden
- Set(P_AUTOLOADOBJ, #'my_query_autoloadobj, F_QUERY_METHOD);
- Set(P_AUTOLOADOBJ, #'my_set_autoloadobj, F_SET_METHOD);
-
- // die werden nur von mir veraendert!
- Set(P_AUTOLOADOBJ, PROTECTED, F_MODE_AS);
- ...
- }
-
- static mixed *my_query_autoloadobj () {
- // s.o.
- }
-
- static mixed *my_set_autoloadobj (mixed *new) {
- // s.o.
- }
-
-
-SIEHE AUCH
-==========
-
- P_AUTOLOAD, SetProp
-
-24.Aug.2006 Gloinson@MG
diff --git a/doc/sphinx/man/props/P_AVATAR_URI b/doc/sphinx/man/props/P_AVATAR_URI
deleted file mode 100644
index 0a2437c..0000000
--- a/doc/sphinx/man/props/P_AVATAR_URI
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_AVATAR_URI
-************
-
-
-NAME
-====
-
- P_AVATAR_URI "p_lib_avataruri"
-
-
-DEFINIERT IN
-============
-
- /sys/living/description.h
-
-
-BESCHREIBUNG
-============
-
- Lebewesen speichern in der Prop P_AVATAR_URI eine URI (string), welche auf
- ein Bild im Netz verweist, welches ein Client fuer dieses Lebewesen
- anzeigen kann.
- Spieler koennen diese Avatar-URI mit dem Befehl 'avatar' anzeigen,
- aendern und loeschen.
- Avatar-URIs anderer Spieler lassen sich mit 'finger -a' ausgeben.
-
-
-BEMERKUNGEN
-===========
-
- Diese Property kann nur vom Spieler oder einem EM modifiziert werden.
-
-
-SIEHE AUCH
-==========
-
- avatar
-
-
-LETZTER AENDERUNG
-=================
-
- 03.9.2011, Zesstra
diff --git a/doc/sphinx/man/props/P_AVERAGE_SIZE b/doc/sphinx/man/props/P_AVERAGE_SIZE
deleted file mode 100644
index 155528f..0000000
--- a/doc/sphinx/man/props/P_AVERAGE_SIZE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_AVERAGE_SIZE
-**************
-
-
-NAME
-====
-
- P_AVERAGE_SIZE "average_size"
-
-
-DEFINIERT IN
-============
-
- /sys/player/description.h
-
-
-BESCHREIBUNG
-============
-
- Durchschnittliche Groesse eines Wesens dieser Rasse (derzeit nur Player)
diff --git a/doc/sphinx/man/props/P_AVERAGE_WEIGHT b/doc/sphinx/man/props/P_AVERAGE_WEIGHT
deleted file mode 100644
index d71c53b..0000000
--- a/doc/sphinx/man/props/P_AVERAGE_WEIGHT
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_AVERAGE_WEIGHT
-****************
-
-
-NAME
-====
-
- P_AVERAGE_WEIGHT "average_weight"
-
-
-DEFINIERT IN
-============
-
- /sys/player/description.h
-
-
-BESCHREIBUNG
-============
-
- Durchschnittliche Gewicht eines Wesens dieser Rasse (derzeit nur Player)
diff --git a/doc/sphinx/man/props/P_AWAY b/doc/sphinx/man/props/P_AWAY
deleted file mode 100644
index 5678440..0000000
--- a/doc/sphinx/man/props/P_AWAY
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_AWAY
-******
-
-
-NAME
-====
-
- P_AWAY "away"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- String der ausgegeben wird, wenn man weg ist und eine Mitteilung bekommt.
diff --git a/doc/sphinx/man/props/P_BAD_MSG b/doc/sphinx/man/props/P_BAD_MSG
deleted file mode 100644
index 7015a9c..0000000
--- a/doc/sphinx/man/props/P_BAD_MSG
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_BAD_MSG
-*********
-
-
-NAME
-====
-
- P_BAD_MSG "std_food_bad_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung, wenn eine Speise gerade verdirbt.
- Befindet sich die Speise in einem Spieler, geht die Meldung an genau
- diesen, liegt die Speise im Raum, geht die Meldung an alle anwesenden
- Spieler.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "@WER1 verdirbt."
-
-
-SIEHE AUCH
-==========
-
- P_LIFETIME, P_RESET_LIFETIME, P_NO_BAD,
- wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_BLIND b/doc/sphinx/man/props/P_BLIND
deleted file mode 100644
index da86624..0000000
--- a/doc/sphinx/man/props/P_BLIND
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_BLIND
-*******
-
-
-NAME
-====
-
- P_BLIND "blind"
-
-
-DEFINIERT IN
-============
-
- /sys/player/viewcmd.h
-
-
-BESCHREIBUNG
-============
-
- 1, wenn der Spieler blind ist und nichts mehr sehen kann.
-
- Wird von CannotSee() bei 'schau' und Betreten von Raeumen
- u.ae. ausgewertet.
-
- P_BLIND kann auch auf einen String gesetzt werden, der
- dann statt des 'Du bist blind' ausgegeben wird.
-
-
-BEISPIELE
-=========
-
- this_player()->SetProp(P_BLIND,1);
-
- this_player()->SetProp(P_BLIND,"Du hast Dir vorhin so schoen die "
- +"Augen ausgekratzt ... deswegen "
- +"siehst Du nun nichts mehr.\n");
-
-
-BEMERKUNGEN
-===========
-
- Um herauszufinden, ob ein Spieler etwas sehen kann oder nicht,
- sollte man lieber if(this_player()->CannotSee() != 0) pruefen
- statt if(this_player()->QueryProp(P_BLIND)).
-
- Denn CannotSee() beruecksichtigt auch Nachtsicht (bzw. hier
- eine nicht aktivierte) und die Lichtmodifikatoren.
-
-
-SIEHE AUCH
-==========
-
- P_LIGHT_MODIFIER, P_PLAYER_LIGHT, CannotSee
-
-Letzte Aenderung: Sa 02.11.02, 00:30:00 Uhr, von Tilly
diff --git a/doc/sphinx/man/props/P_BODY b/doc/sphinx/man/props/P_BODY
deleted file mode 100644
index 5871adb..0000000
--- a/doc/sphinx/man/props/P_BODY
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_BODY
-******
-
-
-NAME
-====
-
- P_BODY "body"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert fuer die Abwehrstaerke des blanken Koerpers
- des Wesens.
diff --git a/doc/sphinx/man/props/P_BRIEF b/doc/sphinx/man/props/P_BRIEF
deleted file mode 100644
index f6d3769..0000000
--- a/doc/sphinx/man/props/P_BRIEF
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_BRIEF
-*******
-
-
-NAME
-====
-
- P_BRIEF "brief"
-
-
-DEFINIERT IN
-============
-
- /sys/player/viewcmd.h
-
-
-BESCHREIBUNG
-============
-
- Ist gesetzt, wenn der Spieler nur die Kurzbeschreibung sehen will.
diff --git a/doc/sphinx/man/props/P_BUFFER b/doc/sphinx/man/props/P_BUFFER
deleted file mode 100644
index 699f91c..0000000
--- a/doc/sphinx/man/props/P_BUFFER
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_BUFFER
-********
-
-
-NAME
-====
-
- P_BUFFER "buffer"
-
-
-DEFINIERT IN
-============
-
- /sys/player/comm.h
-
-
-BESCHREIBUNG
-============
-
- Zeigt an, ob der Kobold des Spielers aktiv oder nicht aktiv ist.
diff --git a/doc/sphinx/man/props/P_BUY_ONLY_PLANTS b/doc/sphinx/man/props/P_BUY_ONLY_PLANTS
deleted file mode 100644
index 0d15a94..0000000
--- a/doc/sphinx/man/props/P_BUY_ONLY_PLANTS
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_BUY_ONLY_PLANTS
-*****************
-
-
-NAME
-====
-
- P_BUY_ONLY_PLANTS "lib_p_buy_only_plants"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property kann auf 1 gesetzt werden, wenn ein Laden nur Kraeuter
- ankaufen darf. Hierzu muss /std/room/kraeuterladen.c geerbt werden,
- da nur dieses Objekt die Property beruecksichtigt.
-
-
-SIEHE AUCH
-==========
-
- /std/room/kraeuterladen.c
-
-Last modified: 02.04.2015 Arathorn
diff --git a/doc/sphinx/man/props/P_CALLED_FROM_IP b/doc/sphinx/man/props/P_CALLED_FROM_IP
deleted file mode 100644
index 306241c..0000000
--- a/doc/sphinx/man/props/P_CALLED_FROM_IP
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CALLED_FROM_IP
-****************
-
-
-NAME
-====
-
- P_CALLED_FROM_IP "called_from_ip"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Letzte IP-Adr, von der aus sich der Spieler eingeloggt hat.
diff --git a/doc/sphinx/man/props/P_CAN_FLAGS b/doc/sphinx/man/props/P_CAN_FLAGS
deleted file mode 100644
index 06afe76..0000000
--- a/doc/sphinx/man/props/P_CAN_FLAGS
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_CAN_FLAGS
-***********
-
-
-NAME
-====
-
- P_CAN_FLAGS "can_flags"
-
-
-DEFINIERT IN
-============
-
- /sys/player/can.h
-
-
-BESCHREIBUNG
-============
-
- Flags die bestimmte Befehle freischalten:
- CAN_EMOTE, CAN_ECHO, CAN_REMOTE, CAN_PRESAY
diff --git a/doc/sphinx/man/props/P_CAP_NAME b/doc/sphinx/man/props/P_CAP_NAME
deleted file mode 100644
index 0069948..0000000
--- a/doc/sphinx/man/props/P_CAP_NAME
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_CAP_NAME
-**********
-
-
-NAME
-====
-
- P_CAP_NAME "cap_name"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Name des Spielers, der dekliniert und ausgegen wird.
- NOT YET IMPLEMENTED.
diff --git a/doc/sphinx/man/props/P_CARRIED_VALUE b/doc/sphinx/man/props/P_CARRIED_VALUE
deleted file mode 100644
index 8792664..0000000
--- a/doc/sphinx/man/props/P_CARRIED_VALUE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CARRIED_VALUE
-***************
-
-
-NAME
-====
-
- P_CARRIED_VALUE "carried"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Entschaedigung, die der Spieler beim Einloggen erhaelt.
diff --git a/doc/sphinx/man/props/P_CHATS b/doc/sphinx/man/props/P_CHATS
deleted file mode 100644
index 51e1a5e..0000000
--- a/doc/sphinx/man/props/P_CHATS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CHATS
-*******
-
-
-NAME
-====
-
- P_CHATS "chats"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Alist mit Strings, die das Monster zufaellig ausgibt.
diff --git a/doc/sphinx/man/props/P_CHAT_CHANCE b/doc/sphinx/man/props/P_CHAT_CHANCE
deleted file mode 100644
index bd032bf..0000000
--- a/doc/sphinx/man/props/P_CHAT_CHANCE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CHAT_CHANCE
-*************
-
-
-NAME
-====
-
- P_CHAT_CHANCE "chat_chance"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wahrscheinlichkeit, mit der die Chats ausgegeben werden.
diff --git a/doc/sphinx/man/props/P_CLASS b/doc/sphinx/man/props/P_CLASS
deleted file mode 100644
index 80017cc..0000000
--- a/doc/sphinx/man/props/P_CLASS
+++ /dev/null
@@ -1,33 +0,0 @@
-
-P_CLASS
-*******
-
-
-NAME
-====
-
- P_CLASS "class"
-
-
-DEFINIERT IN
-============
-
- <thing/description.h>
-
-
-BESCHREIBUNG
-============
-
- Die Klassifizierung eines Objektes, soweit sie nicht schon ueber die
- Rasse oder die IDs des Objektes erfolgt ist. Zum Setzen dieser Property
- sollte man AddClass() benutzen, zur Klassenabfrage steht
- is_class_member() zur Verfuegung.
- Die moeglichen Klassen findet man in /sys/class.h
-
-
-SIEHE AUCH
-==========
-
- AddClass(), RemoveClass(), is_class_member()
-
-Last modified: Sun May 19 20:30:09 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_CLOCKMSG b/doc/sphinx/man/props/P_CLOCKMSG
deleted file mode 100644
index 6f85b56..0000000
--- a/doc/sphinx/man/props/P_CLOCKMSG
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CLOCKMSG
-**********
-
-
-NAME
-====
-
- P_CLOCKMSG "clockmsg"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Die Meldung wird zur vollen Stunde ausgegeben
diff --git a/doc/sphinx/man/props/P_CLONER b/doc/sphinx/man/props/P_CLONER
deleted file mode 100644
index 75e9d02..0000000
--- a/doc/sphinx/man/props/P_CLONER
+++ /dev/null
@@ -1,28 +0,0 @@
-
-P_CLONER
-********
-
-
-NAME
-====
-
- P_CLONER "cloner"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt einen String mit dem Namen desjenigen, der das Objekt gecloned
- hat.
-
-
-SIEHE AUCH
-==========
-
- P_CLONE_TIME
diff --git a/doc/sphinx/man/props/P_CLONE_MSG b/doc/sphinx/man/props/P_CLONE_MSG
deleted file mode 100644
index d16f42e..0000000
--- a/doc/sphinx/man/props/P_CLONE_MSG
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CLONE_MSG
-***********
-
-
-NAME
-====
-
- P_CLONE_MSG "clone_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Meldung, die beim Clonen eines Obj ausgegegen wird (nur Magier)
diff --git a/doc/sphinx/man/props/P_CLONE_TIME b/doc/sphinx/man/props/P_CLONE_TIME
deleted file mode 100644
index fb7c3e5..0000000
--- a/doc/sphinx/man/props/P_CLONE_TIME
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_CLONE_TIME
-************
-
-
-NAME
-====
-
- P_CLONE_TIME "clone_time"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die Clone-Time eines Objektes.
- Heutzutage obsolet, bitte stattdessen lieber die Efun object_time()
- benutzen.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: object_time(E)
- Aehnlich: program_time(E)
diff --git a/doc/sphinx/man/props/P_CLOTHING b/doc/sphinx/man/props/P_CLOTHING
deleted file mode 100644
index 3458058..0000000
--- a/doc/sphinx/man/props/P_CLOTHING
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_CLOTHING
-**********
-
-
-P_CLOTHINGS
-===========
-
-
-NAME
-====
-
- P_CLOTHING "std:clothing"
-
-
-DEFINIERT IN
-============
-
- <living/clothing.h>
-
-
-BESCHREIBUNG
-============
-
- Array mit der getragenen nicht-schuetzenden Kleidung des Lebewesen.
-
-
-
- Falls ihr die Kleidung des Lebewesens, ggf. mit bestimten Kriterien,
- ermitteln wollt, benutzt hierfuer bitte die Funktion FilterClothing()
- statt selber ueber dieses Array zu laufen.
-
- Diese Property kann nur vom Lebewesen selber beschrieben werden.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: QueryArmourByType(L), FilterClothing(), FilterArmours()
- Wear(), Unwear(), P_ARMOURS
-
-14.03.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_CMSG b/doc/sphinx/man/props/P_CMSG
deleted file mode 100644
index e38f085..0000000
--- a/doc/sphinx/man/props/P_CMSG
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CMSG
-******
-
-
-NAME
-====
-
- P_CMSG "clonemsg"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- *** OBSOLET! *** Siehe P_CLONE_MSG
diff --git a/doc/sphinx/man/props/P_CNT_STATUS b/doc/sphinx/man/props/P_CNT_STATUS
deleted file mode 100644
index 5bcc584..0000000
--- a/doc/sphinx/man/props/P_CNT_STATUS
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_CNT_STATUS
-************
-
-
-NAME
-====
-
- P_CNT_STATUS "cnt_status"
-
-
-DEFINIERT IN
-============
-
- /sys/container.h
-
-
-BESCHREIBUNG
-============
-
- Status des Containers (offen, geschlossen, abgeschlossen)
- siehe auch /sys/container.h
diff --git a/doc/sphinx/man/props/P_COMBATCMDS b/doc/sphinx/man/props/P_COMBATCMDS
deleted file mode 100644
index e82336a..0000000
--- a/doc/sphinx/man/props/P_COMBATCMDS
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_COMBATCMDS
-************
-
-
-NAME
-====
-
- P_COMBATCMDS "combatcmds"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Fuer den Kampf gebrauchbare Befehle spezieller Objekte (damit auch
- Monster sie automatisch richtig anwenden koennen)
- Der Inhalt von P_COMBATCMDS ist ein Mapping, der Key ist das Kommando,
- um den Gegenstand zu benutzen (also z.B. "wirf flammenkugel"), und der
- Value ein weiteres Mapping mit Zusatzinfos (definiert in /sys/combat.h).
- Folgende Keys sind definiert:
- - C_MIN, C_AVG, C_MAX:
- minimaler, mittlerer und maximaler Schaden, den das
- Objekt macht. Alle Angaben in LEBENSPUNKTEN, d.h. Defend-Einheiten/10.
- Bei einem Aufruf wie 'enemy->Defend(200+random(200), ...)' ist dann
- C_MIN=20, C_AVG=30, C_MAX=40.
- - C_DTYPES:
- Array mit dem Schadenstyp oder den Schadenstypen. Beim Eisstab
- wuerde der Eintrag dann 'C_DTYPES:({DT_COLD})' lauten.
- - C_HEAL:
- Sollte das Kampfobjekt ueber die Moeglichkeit verfuegen, den Anwender
- irgendwie zu heilen, so wird hier die Heilung in LP/MP eingetragen.
- Das funktioniert auch bei Objekten, die nur heilen, also sonst
- nichts mit Kampf zu tun haben.
- Im Lupinental z.B. gibt es Pfirsiche, die beim Essen 5LP heilen. Da
- kann man dann 'SetProp(P_COMBATCMDS, (["iss pfirsich":([C_HEAL:5])]))'
- eintragen.
- Es sind auch mehrere Kommandos moeglich, z.B. bei Objekten, die sowohl
- heilen als auch Kampfwirkung haben.
diff --git a/doc/sphinx/man/props/P_COMMANDS b/doc/sphinx/man/props/P_COMMANDS
deleted file mode 100644
index 5812b35..0000000
--- a/doc/sphinx/man/props/P_COMMANDS
+++ /dev/null
@@ -1,76 +0,0 @@
-
-P_COMMANDS
-**********
-
-
-NAME
-====
-
- P_COMMANDS "commands"
-
-
-DEFINIERT IN
-============
-
- <thing/commands.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt ein Mapping mit den Befehlen, die dem Objekt
- zugeordnet sind.
-
- Sie sollte nicht von Hand manipuliert werden, sondern nur ueber die
- Funktionen AddCmd() und RemoveCmd().
-
- Das Mapping hat folgenden Aufbau:
-
- ([ befehl : ({funktion1,...});
- ({flag1,...});
- ({regel1,...});
- ({id1, ...}),
- ({closure auf fun1, ...}),
- ... ])
-
- Die Eintraege entsprechen den Parametern des AddCmd()-Aufrufs, sind
- aber in anderer Form. Als Beispiel:
-
- AddCmd(verb,fun1,1);
- AddCmd(verb+syn1a|syn1b&syn2a|syn2b|syn2c, fun2,
- error1_notify|error2_notify^error2_write);
- -->
- ([verb:
- ({fun1,fun2}); // funs
- ({1,({error1_notify, error2_write^error2_say, 1})}); // flags
- ({0,({({syn1a,syn1b}),({syn2a,syn2b,syn2c})})}); // rules
- 0; // IDs
- ({closure auf fun1, closure auf fun2}) ]) // Cache
-
- Funs: ({<fun1> ,...
- 'fun' kann sein: Closure
- String: Methodenname - wird etwas geprueft
- Objekt: wenn keine Methode, this_object() fuer
- intern, previous_object() fuer extern
- 0 (erloschenes externes Objekt)
- Rules: ({<Regelsatz fuer fun1>, ({<1. Synonymgruppe>,
- <2. Synonymgruppe, ...}), ...})
- Flags: ({<Flag fuer fun1>, ({<Fehlermeldung 1. Synonymgruppe>, ... ,
- [, Index fuer write anstatt notify_fail]}),
- ... })
- IDs: 0 oder ({<ID fuer fun1>}) oder ({0, <ID fuer fun2>}) ...
- Cache: ({<closure fuer fun1>, ...
-
-
-BEMERKUNGEN
-===========
-
- Cache-Closures sind bei Export immer genullt
-
-
-SIEHE AUCH
-==========
-
- /std/thing/commands.c, AddCmd(), RemoveCmd()
-
-16. Dez 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_COMPILER_PATH b/doc/sphinx/man/props/P_COMPILER_PATH
deleted file mode 100644
index e67d01f..0000000
--- a/doc/sphinx/man/props/P_COMPILER_PATH
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_COMPILER_PATH
-***************
-
-
-NAME
-====
-
- P_COMPILER_PATH "compiler_path"
-
-
-DEFINIERT IN
-============
-
- /sys/v_compiler.h
-
-
-BESCHREIBUNG
-============
-
- Directory in dem ein Virtual Compiler Objekte erzeugt.
- Muss im virtual_compiler.c gesetzt werden.
-
- Der VirtualCompiler muss nicht zwingend in diesem Verzeichnis
- liegen, um zu funktionieren, sollte es aber, um die Zuordnung des VCs zu
- "seinen" Objekten zu erleichern.
-
-
-BEISPIEL
-========
-
- SetProp(P_COMPILER_PATH,"/d/region/magier/vc/");
-
-
-SIEHE AUCH
-==========
-
- P_STD_OBJECT, virtual_compiler
-
-Letzte Aenderung: 23.10.2007, von Zesstra
diff --git a/doc/sphinx/man/props/P_CONSUME_MSG b/doc/sphinx/man/props/P_CONSUME_MSG
deleted file mode 100644
index 0300037..0000000
--- a/doc/sphinx/man/props/P_CONSUME_MSG
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_CONSUME_MSG
-*************
-
-
-NAME
-====
-
- P_CONSUME_MSG "std_food_consume_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Raum exklusive Konsument, wenn eine Speise konsumiert
- wird.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "@WER2 konsumiert @WEN1."
-
-
-SIEHE AUCH
-==========
-
- /std/food.c, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_CONTAINER b/doc/sphinx/man/props/P_CONTAINER
deleted file mode 100644
index e779f75..0000000
--- a/doc/sphinx/man/props/P_CONTAINER
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CONTAINER
-***********
-
-
-NAME
-====
-
- P_CONTAINER "container"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_CONTENTS b/doc/sphinx/man/props/P_CONTENTS
deleted file mode 100644
index fc9f20e..0000000
--- a/doc/sphinx/man/props/P_CONTENTS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_CONTENTS
-**********
-
-
-NAME
-====
-
- P_CONTENTS "contents"
-
-
-DEFINIERT IN
-============
-
- /sys/container.h
-
-
-BESCHREIBUNG
-============
-
- *** OBSOLET! ***
diff --git a/doc/sphinx/man/props/P_CORPSE b/doc/sphinx/man/props/P_CORPSE
deleted file mode 100644
index 762f03c..0000000
--- a/doc/sphinx/man/props/P_CORPSE
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_CORPSE
-********
-
-
-NAME
-====
-
- P_CORPSE "corpse"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Hier kann man angeben, welche Art von Leiche beim Tod des NPCs
- hinterlassen wird. Damit die Leiche auf dem Moerder-Kanal senden
- kann, muss das Leichen-Objekt /std/corpse sein oder erben.
-
-
-BEISPIELE
-=========
-
- Die uebliche Standardleiche befindet sich unter "/std/corpse.c",
- welches auch die Defaulteinstellung fuer diese Property darstellt:
- SetProp(P_CORPSE,"/std/corpse");
- Man koennte aber auch einen Zombie entstehen lassen:
- SetProp(P_CORPSE,PATH("zombie"));
- PATH kennzeichnet hierbei den Pfad, unter welchem "zombie.c" zu
- finden ist.
-
-
-SIEHE AUCH
-==========
-
- P_NOCORPSE, P_ZAP_MSG, P_DIE_MSG, P_MURDER_MSG, P_KILL_MSG
-
-Last modified: Mon Apr 07 11:02:06 2003 by Mandragon
diff --git a/doc/sphinx/man/props/P_CURRENTDIR b/doc/sphinx/man/props/P_CURRENTDIR
deleted file mode 100644
index b1dc2a4..0000000
--- a/doc/sphinx/man/props/P_CURRENTDIR
+++ /dev/null
@@ -1,28 +0,0 @@
-
-P_CURRENTDIR
-************
-
-
-NAME
-====
-
- P_CURRENTDIR "currentdir"
-
-
-DEFINIERT IN
-============
-
- /sys/shells.h
-
-
-BESCHREIBUNG
-============
-
- Momentanes Verzeichnis in dem der Magier ist.
- (nur fuer Magier von Belang)
-
-Siehe auch:
- P_CURRENTDIR
-
-Letzte Aenderung:
- 03.06.2015, Bugfix
diff --git a/doc/sphinx/man/props/P_CURSED b/doc/sphinx/man/props/P_CURSED
deleted file mode 100644
index c3a9061..0000000
--- a/doc/sphinx/man/props/P_CURSED
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_CURSED
-********
-
-
-NAME
-====
-
- P_CURSED "cursed"
-
-
-DEFINIERT IN
-============
-
- <properties.h>
-
-
-BESCHREIBUNG
-============
-
- Ruestungen und Waffen, die sich, einmal angezogen bzw. gezueckt, nicht
- wieder entfernen lassen sollen, kann man ueber diese Property
- realisieren. Die Waffe oder Ruestung hat dann in der Regel negative
- Auswirkungen auf den Traeger...
-
- Setzt man diese Property auf eine Zahl ungleich 0, so bekommt man bei
- dem Versuch, den verfluchten Gegenstand auszuziehen bzw. wegzustecken
- eine Defaultmeldung.
-
- Traegt man dagegen einen String ein, so wird dieser beim Versuch, den
- Gegenstand loszuwerden, ausgegeben.
-
-
-BEMERKUNGEN
-===========
-
- Der 'Fluch' wird erst wirksam, wenn das Opfer die Waffe zueckt bzw. die
- Ruestung anzieht. Ist dies erst einmal geschehen, helfen nur noch
- Zaubersprueche oder fluchbrechende Institutionen.
-
- Moechte man, dass der Gegenstand entfluchbar ist, dann sollte er auch
- ansprechbar sein (gueltige ID, nicht unsichtbar), da das durch derzeitige
- Entfluchmoeglichkeiten vorausgesetzt wird.
-
- Flueche koennen ein P_LEVEL 1-100 haben, welches die Schwierigkeit des
- Enfluchens festlegt. Der Klerus behandelt das nicht linear.
-
-
-SIEHE AUCH
-==========
-
- Eigenschaften: P_LEVEL
- Aehnlich: AddClass (CL_CURSE)
- Code: /std/armour, /std/weapon, /gilden/files.klerus/prayermaster
-
-25. Aug 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_DAMAGED b/doc/sphinx/man/props/P_DAMAGED
deleted file mode 100644
index 91d5324..0000000
--- a/doc/sphinx/man/props/P_DAMAGED
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_DAMAGED
-*********
-
-
-NAME
-====
-
- P_DAMAGED "item_damaged"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Ruestungen und Waffen koennen im Eifer des Gefechts beschaedigt werden.
- Der Grad der Beschaedigung sollte in dieser Property festgehalten
- werden.
-
- Bei Waffen ergibt sich die urspruengliche Waffenklasse aus der Summe
- von aktueller Waffenklasse und dem Wert von P_DAMAGED:
- altes P_WC = aktuelles P_WC + P_DAMAGED.
-
- Analoges gilt fuer die Ruestungsklasse einer beschaedigten Ruestung:
- altes P_AC = aktuelles P_AC + P_DAMAGED.
-
- P_DAMAGED bitte niemals direkt setzen, sondern immer ueber
- die Funktion Damage() manipulieren!
-
-
-SIEHE AUCH
-==========
-
- /std/armour.c, /std/weapon.c, TakeFlaw(), QueryFlaw(), Damage()
-
-02.10.2007, Zesstra
diff --git a/doc/sphinx/man/props/P_DAMAGE_MSG b/doc/sphinx/man/props/P_DAMAGE_MSG
deleted file mode 100644
index e9c71a8..0000000
--- a/doc/sphinx/man/props/P_DAMAGE_MSG
+++ /dev/null
@@ -1,58 +0,0 @@
-
-P_DAMAGE_MSG
-************
-
-
-NAME
-====
-
- P_DAMAGE_MSG "std_p_dam_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property lassen sich individuelle Treffer-/Schadensmeldungen
- fuer dieses Lebewesen festlegen. Sie werden verwendet, falls bei
- eingehendem Schaden der Aufrufer von Defend() Schadensmeldungen wuenscht
- (d.h. SP_SHOW_DAMAGE != 0), jedoch keine eigenen Meldungen vorgibt.
-
- Enthaelt diese Property kein Array, werden ggf. die Standardmeldungen
- ausgegeben.
-
- Datenstruktur der Property:
- ({
- ({ int lphit1, string mess_me,
- string mess_en,
- string mess_room }),
- ({ lphit2, mess_me, mess_en, mess_room }),
- ...
- ({ lphitn, mess_me, mess_en, mess_room }),
- })
- wobei lphit1<lphit2<...<lphitn sein muss, d.h. das Array-
- Array ist aufsteigend sortiert.
-
- Ist ein Treffer x LP hart, werden die Meldungen des lphit-
- Arrays ausgegeben, dessen Wert am naechsten unter dem Schaden
- liegt.
-
- In den Meldungen mess_me (an den Getroffenen), mess_en (an
- den Feind), mess_room (an die restlichen Umstehenden) koennen
- Ersatzstrings wie folgt verwendet werden:
- @WER1/@WESSEN1/@WEM1/@WEN1 - name(casus) des Getroffenen (TO)
- @WER2/@WESSEN2/@WEM2/@WEN2 - name(casus) des Feindes (enemy)
-
-
-SIEHE AUCH
-==========
-
- Defend()
- /std/living/combat.c
-
-15.09.2010, Zesstra
diff --git a/doc/sphinx/man/props/P_DAM_DESC b/doc/sphinx/man/props/P_DAM_DESC
deleted file mode 100644
index 151f555..0000000
--- a/doc/sphinx/man/props/P_DAM_DESC
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_DAM_DESC
-**********
-
-
-NAME
-====
-
- P_DAM_DESC "dam_desc"
-
-
-DEFINIERT IN
-============
-
- <weapon/description.h>
-
-
-BESCHREIBUNG
-============
-
- In dieser Property befindet sich ein String oder String-Array, durch
- den die Langbeschreibung einer Ruestung oder Waffe ergaenzt wird,
- wenn diese Beschaedigt ist.
-
-
-BEMERKUNGEN
-===========
-
- Wird ein String gesetzt, so wird dieser angezeigt, wenn die Waffe
- mehr als die Haelfte beschaedigt ist. Bei einem Array wird der
- Text entsprechend dem Grad der Beschaedigung ausgewaehlt; das Array
- muss in der Reihenfolge zunehmender Beschaedigung sortiert sein.
-
-
-
- Bei Waffen ist P_DAM_DESC defaultmaessig auf DFLT_DAM_DESC gesetzt,
- bei Ruestungen auf 0.
-
-
-BEISPIELE
-=========
-
- SetProp(P_DAM_DESC,"ist beschaedigt");
- SetProp(P_DAM_DESC,({
- "ist etwas beschaedigt",
- "ist beschaedigt",
- "ist beschaedigt",
- "ist sehr beschaedigt"}) );
-
-
-SIEHE AUCH
-==========
-
- /std/weapon/description.c
-
-Last modified: Mon Oct 14 15:29:00 1996 by Paracelsus
diff --git a/doc/sphinx/man/props/P_DAM_TYPE b/doc/sphinx/man/props/P_DAM_TYPE
deleted file mode 100644
index e5088d2..0000000
--- a/doc/sphinx/man/props/P_DAM_TYPE
+++ /dev/null
@@ -1,35 +0,0 @@
-
-P_DAM_TYPE
-**********
-
-
-NAME
-====
-
- P_DAM_TYPE "dam_type"
-
-
-DEFINIERT IN
-============
-
- <weapon.h>
-
-
-BESCHREIBUNG
-============
-
- Was fuer eine Art von Schaden richtet die Waffe an? Hier kann man einen
- String oder ein Array von Strings angeben, je nachdem, welche Effekte
- die Waffe ausloesen kann. Man sollte hier nur die in <combat.h>
- definierten Schadenstypen verwenden.
-
- Fragt man diese Property ab, bekommt man uebrigens immer ein Array von
- Strings zurueck.
-
-
-SIEHE AUCH
-==========
-
- /std/weapon.c
-
-Last modified: Sun May 19 15:23:43 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_DEADS b/doc/sphinx/man/props/P_DEADS
deleted file mode 100644
index 03f0c07..0000000
--- a/doc/sphinx/man/props/P_DEADS
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_DEADS
-*******
-
-
-NAME
-====
-
- P_DEADS "deads"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der Tode des Spielers seit Einfuehrung dieser Property (irgendwann
- im Dezember 94)
diff --git a/doc/sphinx/man/props/P_DEAF b/doc/sphinx/man/props/P_DEAF
deleted file mode 100644
index 570ac06..0000000
--- a/doc/sphinx/man/props/P_DEAF
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_DEAF
-******
-
-
-NAME
-====
-
- P_DEAF "deaf"
-
-
-DEFINIERT IN
-============
-
- /sys/player/comm.h
-
-
-BESCHREIBUNG
-============
-
- Der Spieler ist taub. Falls hier ein String steht, wird dieser bei
- "teile ... mit" an den Mitteilenden ausgegeben, ansonsten kommt nur
- "Soundso ist leider gerade taub.\n"
diff --git a/doc/sphinx/man/props/P_DEATH_MSG b/doc/sphinx/man/props/P_DEATH_MSG
deleted file mode 100644
index d5de007..0000000
--- a/doc/sphinx/man/props/P_DEATH_MSG
+++ /dev/null
@@ -1,79 +0,0 @@
-
-P_DEATH_MSG
-***********
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property kann man ein Array ablegen, das beim Tod eines
- Spielers ausgewertet und der darin enthaltene String
- anschliessend auf dem Todeskanal gesendet wird.
- Der Array muss folgenden Aufbau haben:
-
- SetProp( P_DEATH_MSG, ({ Text, Flag }) )
-
-
-
- Text: Der Text kann beliebig eingegeben werde. Allerdings darf
- er nicht mit einem '\n' abgeschlossen werden.
-
-
-
- Flag: Hier kann man drei Arten von Sendemethoden waehlen.
- 1. MSG_SAY Normales Senden
- 2. MSG_GEMOTE Genitiv-Emote
- 3. MSG_EMOTE Emote
-
-
-BEISPIEL
-========
-
- Der Spieler soll direkt nach seinem Tod eine Meldung auf dem
- Todeskanal senden.
-
-
-
- Nachricht auf dem Todes-Kanal:
-
-
-
- [Tod:Spieler] Ich will keine Beleidsbekundungen!
-
-
-
- void spieler_stirbt()
- {
- this_player()->SetProp( P_DEATH_MSG, ({ "Ich will keine "
- "Beleidsbekundungen!", MSG_SAY}) );
- this_player()->die();
- }
-
-
-
- Nachricht auf dem Todes-Kanal:
-
-
-
- [Tod:Spieler liebt es zu sterben.]
-
-
-
- void spieler_stirbt()
- {
- this_player()->SetProp( P_DEATH_MSG, ({ "liebt es zu sterben.",
- MSG_EMOTE }) );
- this_player()->die();
- }
-
-
-SIEHE AUCH
-==========
-
- P_MURDER_MSG, P_FORCE_MURDER_MSG
diff --git a/doc/sphinx/man/props/P_DEATH_SPONSORED_BY b/doc/sphinx/man/props/P_DEATH_SPONSORED_BY
deleted file mode 100644
index cae8532..0000000
--- a/doc/sphinx/man/props/P_DEATH_SPONSORED_BY
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_DEATH_SPONSORED_BY
-********************
-
-
-NAME
-====
-
- P_DEATH_SPONSORED_BY "responsible_wizard_for_death"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property hat fuer den Spielverlauf keinerlei Bedeutung.
- Doch gibt es Magier, die ihren Namen gern in /log/KILLS lesen.
- Wird ein Spieler durch einen Npc getoetet, ist normalerweise der
- Magier fuer den Tod verantwortlich, in dessen Verzeichnis sich
- das Monster befindet.
- Doch gibt es nun auch den Fall, dass sich das Monster in einem
- Verzeichnis /alle/mon/ befindet, oder der Spieler durch eine
- Aktion im Raum oder an einem Objekt stirbt.
-
- Ist in einem solchen Monster, Raum oder Objekt diese Property
- gesetzt, wird der dort angebene String an das Log-File ueber-
- geben.
-
-
-BEISPIEL
-========
-
- SetProp(P_DEATH_SPONSORED_BY,"tilly");
-
-
-Last modified Don Feb 15 140100 2001 von Tilly
-==============================================
diff --git a/doc/sphinx/man/props/P_DEFAULT_GUILD b/doc/sphinx/man/props/P_DEFAULT_GUILD
deleted file mode 100644
index 55abd50..0000000
--- a/doc/sphinx/man/props/P_DEFAULT_GUILD
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_DEFAULT_GUILD
-***************
-
-
-NAME
-====
-
- P_DEFAULT_GUILD "default_guild"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt den Namen der Gilde, welcher der Spieler
- standardmaessig angehoert. Der Name wird hierbei in Form eines
- kleingeschriebenen Strings angegeben. Ist P_GUILD gleich Null, so
- wird bei der Abfrage selbiger Property hierfuer der Eintrag von
- P_DEFAULT_GUILD eingesetzt.
-
-
-BEMERKUNGEN
-===========
-
- Nach dem ersten Einloggen des Spielers wird ebenfalls dieser Eintrag
- genutzt, um die Gildenzugehoerigkeit festzulegen. Dies kann dazu
- genutzt werden, um eine rassenabhaengige Bestimmung der
- Standardgilde zu gewaehrleisten
- (Felinen -> Katzenkrieger, andere Rassen -> Abenteurer).
-
-
-SIEHE AUCH
-==========
-
- P_GUILD, P_VISIBLE_GUILD
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_DEFAULT_NOTIFY_FAIL b/doc/sphinx/man/props/P_DEFAULT_NOTIFY_FAIL
deleted file mode 100644
index 351c96c..0000000
--- a/doc/sphinx/man/props/P_DEFAULT_NOTIFY_FAIL
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_DEFAULT_NOTIFY_FAIL
-*********************
-
-
-NAME
-====
-
- P_DEFAULT_NOTIFY_FAIL "default_notify_fail"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Welche Fehlermeldung kommt, wenn kein Objekt ein notify_fail macht?
diff --git a/doc/sphinx/man/props/P_DEFENDERS b/doc/sphinx/man/props/P_DEFENDERS
deleted file mode 100644
index a54134a..0000000
--- a/doc/sphinx/man/props/P_DEFENDERS
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_DEFENDERS
-***********
-
-
-NAME
-====
-
- P_DEFENDERS "defenders"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property wird in Lebewesen gesetzt, welche zum Beispiel durch
- andere Lebewesen verteidigt werden. Die Verteidiger muessen
- natuerlich bekannt sein, damit sie per InformDefend() ueber Angriffe
- informiert werden und per DefendOther() in den laufenden Angriff
- eingreifen koennen (zum Beispiel Schaeden abwehren oder umwandeln).
- Es muessen jedoch nicht unbedingt Lebewesen oder echte Verteidiger
- sein, auch beliebige Objekte koennen ueber Angriffe informiert
- werden und in diese eingreifen. Allerdings besteht die
- Einschraenkung, dass diese Objekte in der gleichen Umgebung sein
- muessen, wie das zu verteidigende Lebewesen oder im zu verteidigenden
- Lebewesen selbst.
- Die Objekte, welche dies betrifft, sind in Form eines Arrays in
- der Property P_DEFENDERS abgelegt.
- Gesetzt und geloescht werden sollten die Eintraege dieses Arrays
- jedoch nur mittels der dafuer bereitgestellten Funktionen
- AddDefender() und RemoveDefender().
-
-
-SIEHE AUCH
-==========
-
- AddDefender(), RemoveDefender(), InformDefend(), DefendOther(),
- /std/living/combat.c
-
-Last modified: 21.09.2007, Zesstra
diff --git a/doc/sphinx/man/props/P_DEFEND_FUNC b/doc/sphinx/man/props/P_DEFEND_FUNC
deleted file mode 100644
index a9939e1..0000000
--- a/doc/sphinx/man/props/P_DEFEND_FUNC
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_DEFEND_FUNC
-*************
-
-
-NAME
-====
-
- P_DEFEND_FUNC "defend_func"
-
-
-DEFINIERT IN
-============
-
- <armour.h>
-
-
-BESCHREIBUNG
-============
-
- Falls ein Objekt eine DefendFunc() fuer die Ruestung definiert, so muss
- dieses Objekt in dieser Property eingetragen sein.
-
- Die Auswertung dieser Property erfolgt in QueryDefend().
-
-
-BEMERKUNGEN
-===========
-
- 1. Es funktioniert _nicht_ hier eine Closure reinzuschreiben.
- 2. Diese Prop laesst sich _nicht_ sinnvoll mit Set() setzen, also z.B.
- keine Query-Methoden hier reinzuschreiben.
- 3. Definieren von _set_defend_func() oder Set-Methoden via Set()
- funktioniert auch nicht, zumindest nicht mit dem gewuenschten
- Ergebnis. ;-)
- 4. Bei Verwendung bitte Balance-Richtlinien beachten!
-
-
-BEISPIELE
-=========
-
- Siehe das Beispiel zu DefendFunc()
-
-
-SIEHE AUCH
-==========
-
- /std/armour.c, DefendFunc(), balance, grenzwerte
-
-Last modified: Sat May 18 15:26:17 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_DEFUEL_AMOUNT_DRINK b/doc/sphinx/man/props/P_DEFUEL_AMOUNT_DRINK
deleted file mode 100644
index 79dcfa5..0000000
--- a/doc/sphinx/man/props/P_DEFUEL_AMOUNT_DRINK
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_DEFUEL_AMOUNT_DRINK
-*********************
-
-
-NAME
-====
-
- P_DEFUEL_AMOUNT_DRINK "defuel_amount_drink"
-
-
-DEFINIERT IN
-============
-
- /sys/defuel.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die rassenabhaengige Enttankvorgabe fuer Trinken.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
- P_DEFUEL_AMOUNT_FOOD
- Methoden: defuel_drink, defuel_food
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Weitere: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_DEFUEL_AMOUNT_FOOD b/doc/sphinx/man/props/P_DEFUEL_AMOUNT_FOOD
deleted file mode 100644
index f61a23e..0000000
--- a/doc/sphinx/man/props/P_DEFUEL_AMOUNT_FOOD
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_DEFUEL_AMOUNT_FOOD
-********************
-
-
-NAME
-====
-
- P_DEFUEL_AMOUNT_FOOD "defuel_amount_food"
-
-
-DEFINIERT IN
-============
-
- /sys/defuel.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die rassenabhaengige Enttankvorgabe fuer Essen.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
- P_DEFUEL_AMOUNT_DRINK
- Methoden: defuel_drink, defuel_food
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Weitere: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_DEFUEL_LIMIT_DRINK b/doc/sphinx/man/props/P_DEFUEL_LIMIT_DRINK
deleted file mode 100644
index d3a2c3c..0000000
--- a/doc/sphinx/man/props/P_DEFUEL_LIMIT_DRINK
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_DEFUEL_LIMIT_DRINK
-********************
-
-
-NAME
-====
-
- P_DEFUEL_LIMIT_DRINK "defuel_limit_drink"
-
-
-DEFINIERT IN
-============
-
- /sys/defuel.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die rassenabhaengige minimale Menge an Trinken, ab dem ein
- Enttankvorgang fuer den Spieler moeglich ist.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- P_DEFUEL_LIMIT_FOOD,
- P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
- Methoden: defuel_drink, defuel_food
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Weitere: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_DEFUEL_LIMIT_FOOD b/doc/sphinx/man/props/P_DEFUEL_LIMIT_FOOD
deleted file mode 100644
index bb012a3..0000000
--- a/doc/sphinx/man/props/P_DEFUEL_LIMIT_FOOD
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_DEFUEL_LIMIT_FOOD
-*******************
-
-
-NAME
-====
-
- P_DEFUEL_LIMIT_FOOD "defuel_limit_food"
-
-
-DEFINIERT IN
-============
-
- /sys/defuel.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die rassenabhaengige minimale Menge an Essen, ab dem ein
- Enttankvorgang fuer den Spieler moeglich ist.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- P_DEFUEL_LIMIT_DRINK,
- P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
- Methoden: defuel_drink, defuel_food
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Weitere: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_DEFUEL_TIME_DRINK b/doc/sphinx/man/props/P_DEFUEL_TIME_DRINK
deleted file mode 100644
index 3ff3b74..0000000
--- a/doc/sphinx/man/props/P_DEFUEL_TIME_DRINK
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_DEFUEL_TIME_DRINK
-*******************
-
-
-NAME
-====
-
- P_DEFUEL_TIME_DRINK "defuel_time_drink"
-
-
-DEFINIERT IN
-============
-
- /sys/defuel.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die rassenabhaengige minimale Zeit zwischen einzelnen
- Enttankvorgaengen fuer Trinken eines Spielers.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: P_DEFUEL_TIME_FOOD,
- P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
- P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
- Methoden: defuel_drink, defuel_food
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Weitere: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_DEFUEL_TIME_FOOD b/doc/sphinx/man/props/P_DEFUEL_TIME_FOOD
deleted file mode 100644
index fcd80d0..0000000
--- a/doc/sphinx/man/props/P_DEFUEL_TIME_FOOD
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_DEFUEL_TIME_FOOD
-******************
-
-
-NAME
-====
-
- P_DEFUEL_TIME_FOOD "defuel_time_food"
-
-
-DEFINIERT IN
-============
-
- /sys/defuel.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die rassenabhaengige minimale Zeit zwischen einzelnen
- Enttankvorgaengen fuer Essen eines Spielers.
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: P_DEFUEL_TIME_DRINK,
- P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK,
- P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
- Methoden: defuel_drink, defuel_food
- Tanken: consume, drink_alcohol, drink_soft, eat_food
- Weitere: P_DRINK, P_FOOD, P_ALCOHOL, P_SP, P_HP,
- P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
- Konzepte: heilung, enttanken, food
-
-9. August 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_DEPARTMSG b/doc/sphinx/man/props/P_DEPARTMSG
deleted file mode 100644
index 917e01c..0000000
--- a/doc/sphinx/man/props/P_DEPARTMSG
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_DEPARTMSG
-***********
-
-
-NAME
-====
-
- P_DEPARTMSG "departmsg"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Meldung, mit der ein Transporter ablegt.
diff --git a/doc/sphinx/man/props/P_DESCRIPTION b/doc/sphinx/man/props/P_DESCRIPTION
deleted file mode 100644
index 4d32999..0000000
--- a/doc/sphinx/man/props/P_DESCRIPTION
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_DESCRIPTION
-*************
-
-
-NAME
-====
-
- P_DESCRIPTION "description"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Beschreibung des Spielers
diff --git a/doc/sphinx/man/props/P_DESTROY_BAD b/doc/sphinx/man/props/P_DESTROY_BAD
deleted file mode 100644
index 94f00e5..0000000
--- a/doc/sphinx/man/props/P_DESTROY_BAD
+++ /dev/null
@@ -1,52 +0,0 @@
-
-P_DESTROY_BAD
-*************
-
-
-NAME
-====
-
- P_DESTROY_BAD "std_food_destroy_bad"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Speichert den Wert fuer das Verhalten, wenn eine Speise verdirbt.
- Dieses Verhalten wird in make_bad() umgesetzt.
-
-
-
- DESTROY_BAD : Die Speise wird beim Verderben zerstoert
- bzw. der Behaelter wird geleert
- DESTROY_NEVER : Die Speise wird beim Verderben nicht zerstoert
- pos. Integer : Anzahl der Sekunden, die zwischen Verderben
- und Zerstoeren der Speise liegen sollen
-
-
-BEMERKUNGEN
-===========
-
- Ist ein positiver Integer-Wert in dieser Property gespeichert, wird nach
- Ausfuehren der Methode make_bad() nach Ablauf der angegebenen Sekunden
- ein weiterer Reset ausgeloest, der make_destroy() aufruft.
-
-
-DEFAULT
-=======
-
- Initial ist diese Property auf DESTROY_BAD gesetzt.
-
-
-SIEHE AUCH
-==========
-
- /std/food.c, wiz/food
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_DESTRUCT_MSG b/doc/sphinx/man/props/P_DESTRUCT_MSG
deleted file mode 100644
index 334c374..0000000
--- a/doc/sphinx/man/props/P_DESTRUCT_MSG
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_DESTRUCT_MSG
-**************
-
-
-NAME
-====
-
- P_DESTRUCT_MSG "destruct_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Meldung, die beim Destructen Obj ausgegegen wird (nur Magier)
diff --git a/doc/sphinx/man/props/P_DETAILS b/doc/sphinx/man/props/P_DETAILS
deleted file mode 100644
index e14c15c..0000000
--- a/doc/sphinx/man/props/P_DETAILS
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_DETAILS
-*********
-
-
-NAME
-====
-
- P_DETAILS "details"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt ein Mapping, in der Details im Objekt
- definiert werden und Beschreibungen, die ausgegeben werden, wenn man
- sich diese Details anschaut.
-
-
-BEMERKUNGEN
-===========
-
- Man kann diese Property nicht per SetProp() veraendern, sondern muss die
- entsprechenden Funktionen nutzen.
- AddSpecialDetail() und RemoveSpecialDetail() sollten nicht mehr
- verwendet werden.
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail()
- Loeschen: RemoveDetail()
- Aehnlich: P_SPECIAL_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail()
- Sonstiges: GetDetail(), break_string()
-
-27. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/props/P_DIE_MSG b/doc/sphinx/man/props/P_DIE_MSG
deleted file mode 100644
index 0bd5d17..0000000
--- a/doc/sphinx/man/props/P_DIE_MSG
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_DIE_MSG
-*********
-
-
-NAME
-====
-
- P_DIE_MSG "die_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property uebergibt man einen String, der ausgegeben wird, wenn
- das Lebewesen stirbt. Ist die Property nicht gesetzt, so wird als String
- benutzt:
- " faellt tot zu Boden.\n".
-
- Der Name des Lebewesens wird dem String vor der Ausgabe vorangestellt.
- Der Satzumbruch am Zeilenende und das Leerzeichen nach dem Namen des
- Lebewesens muss man selbst angegeben. Es sollte allerdings beachtet
- werden, dass ein Lebewesen, das durch Gift getoetet wird, eine spezielle
- nicht zu beeinflussende Meldung erhaelt. Es wird dann als String
- benutzt:
- " wird von Gift hinweggerafft und kippt um.\n".
-
-
-BEISPIELE
-=========
-
- Bei einem mitkaempfenden Schatten waere es eher unlogisch, wenn nach
- dessen 'Tod' eine Leiche zurueckbliebe. Eine logische Konsequenz waere
- folgende Meldung:
- SetProp(P_DIE_MSG," loest sich auf.\n");
- SetProp(P_NOCORPSE,1);
-
- Damit dann auch wirklich keine Leiche zurueckbleibt, wird zusaetzlich
- die Property P_NOCORPSE gesetzt.
-
-
-SIEHE AUCH
-==========
-
- Tod: die(L)
- Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_MURDER_MSG
- P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /std/corpse.c
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_DISABLE_ATTACK b/doc/sphinx/man/props/P_DISABLE_ATTACK
deleted file mode 100644
index 37544ae..0000000
--- a/doc/sphinx/man/props/P_DISABLE_ATTACK
+++ /dev/null
@@ -1,64 +0,0 @@
-
-P_DISABLE_ATTACK
-****************
-
-
-NAME
-====
-
- P_DISABLE_ATTACK "disable_attack"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Das Lebewesen kann nicht angreifen. Beim Setzen der Property ist es
- wichtig, SetProp() zu benutzen und die Anzahl der Kampfrunden anzugeben,
- die das Lebewesen paralysiert sein soll.
-
- Ein negativer Wert ist nicht gueltig. Bei mehr als 30 Kampfrunden wird
- die Paralyse auf 30 Kampfrunden gekappt.
-
- Fuer jede Paralyse bekommt ein Living eine ebenso lange Schutzzeit nach
- der Paralyse gewaehrt. Versucht man, vor Ablauf der Paralyse
- P_DISABLE_ATTACK hoeher zu setzen (oder setzt man innerhalb der folgenden
- Schutzzeit P_DISABLE_ATTACK auf > 0), wird DISABLE_TOO_EARLY von SetProp
- zurueck gegeben.
- Eine Reduktion von einem P_DISABLE_ATTACK ist moeglich, allerdings
- reduziert dies _nicht_ eine einmal gesetzte Schutzzeit.
-
- Einen Gegner,der nie paralysiert werden koennen soll, kann man einfach
- per
-
- Set(P_DISABLE_ATTACK, function int () {return 0;}, F_SET_METHOD);
-
- erstellen, da bei diesem der Wert von P_DISABLE_ATTACK nicht mehr mit
- einem normalen SetProp()-Aufruf geaendert werden kann.
-
-
-BEISPIELE
-=========
-
- // Gegner 17 Runden lang paralysieren, ohne Ruecksicht auf fruehere P.
- // (in diesem Moment ist das Living bis time() + 4 * 17 vor laengerer
- // oder erneuter Paralyse geschuetzt)
- en->SetProp(P_DISABLE_ATTACK, 17);
- // Der Gegner kann jetzt fuer 34 Kampfrunden nicht erneut paralysiert
- // werden.
- // Paralyse reduzieren auf 10 Kampfrunden
- en->SetProp(P_DISABLE_ATTACK, 10);
- // Die Schutzzeit ist immer noch bei 34 Kampfrunden, nicht bei 20.
-
-
-SIEHE AUCH
-==========
-
- P_NEXT_DISABLE_ATTACK
-
-19.08.2014, Zesstra
diff --git a/doc/sphinx/man/props/P_DISABLE_COMMANDS b/doc/sphinx/man/props/P_DISABLE_COMMANDS
deleted file mode 100644
index e66910a..0000000
--- a/doc/sphinx/man/props/P_DISABLE_COMMANDS
+++ /dev/null
@@ -1,100 +0,0 @@
-
-P_DISABLE_COMMANDS
-******************
-
-
-NAME
-====
-
- P_DISABLE_COMMANDS "p_lib_disablecommands"
-
-
-DEFINIERT IN
-============
-
- /sys/player/command.h
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Prop kann man verhindern, dass Kommandos eines Spielers
- verarbeitet werden. Dies ist z.B. in Sequenzen nuetzlich, wo der Spieler
- rein passiv konsumieren soll.
- In diese Property muss ein Array mit 2 oder 3 Elementen geschrieben
- werden:
- 1) Endzeitpunkt in Sekunden seit 1.1.1970 (int)
- 2) Meldung (String oder Closure)
- 3) (optional) Array von trotzdem erlaubten Verben (string*)
- (nur ausgewertet, wenn die Meldung ein String ist)
-
-
-
- Ist die Meldung ein String, wird dieser einfach bei jedem Kommando so wie
- er ist an den Spieler ausgegeben und das Kommando abgebrochen.
- Ist die Meldung eine Closure wird diese bei jedem Kommando aufgerufen und
- das Kommando abgebrochen, wenn sie einen Rueckgabewert != 0 zurueckgibt.
- In diesem Fall ist die gerufene Funktion dafuer verantwortlich, geeignete
- Meldungen an den Spieler auszugeben!
- Der Funktion wird der vom Spieler eingebene Befehl (string) als erstes
- Argument uebergeben. Zu diesem Zeitpunkt wurde alle Aliase schon
- ausgewertet. Die Funktion kann den Kommandogeber via this_player()
- ermitteln.
- Fuer weitere Informationen steht auch command_stack() zur Verfuegung,
- allerdings ist dort die Alias-Ersetzung nicht beruecksichtigt.
-
- Die Ausnahmeliste wird nur fuer simple Strings als Meldung ausgewertet,
- wird eine Closure verwendet, kann diese besser selber die Ausnahmen
- bestimmen.
-
-
-
- Fragt man diese Prop ab, erhaelt man ein Array mit 4 Elementen: setzendes
- Objekt (object), Ablaufzeit (int), Meldung (String oder Closure) und
- Liste von Ausnahmen (string*).
-
-
-BEMERKUNGEN
-===========
-
- 1. Die Prop wird fuer Magier mit eingeschaltetem P_WANTS_TO_LEARN
- ignoriert.
- 2. Wenn das Objekt zerstoert wird, was die Prop gesetzt hat, wird der
- Eintrag unwirksam.
- 3. Wenn diese Prop gesetzt und nicht abgelaufen ist, kann nur das gleiche
- Objekt sie mit neuen Daten ueberschreiben. Alle anderen Objekte koennen
- die Prop nur loeschen. Dies soll verhindern, dass Magier unabsichtlich
- einfach anderer Leute Eintraege ueberschreiben. Dementsprechend: Lasst
- die Finger davon, wenn die schon gesetzt ist. ;-)
- 4. Diese Prop darf _ausschliesslich_ mit SetProp() und QueryProp() benutzt
- werden, Set() und Query() funktionieren _nicht_.
- 5. Es gibt einige Verben, die NIE blockiert werden. Zur Zeit sind dies
- "mrufe", "mschau", "bug", "idee", "typo" und "detail".
- 6. Bitte nicht missbrauchen, speziell nicht dazu, die Kommandos von
- Spieler zu ueberwachen/mitzuschreiben. Das Setzen dieser Prop wird
- geloggt.
-
-
-BEISPIEL
-========
-
- In einem Raum startet eine Sequenz, in der der Spieler nichts machen soll:
-
- if (!pl->QueryProp(P_DISABLE_COMMANDS))
- pl->SetProp(P_DISABLE_COMMANDS,
- ({ time() + 120, "Du bist tief in Deinem Traum gefangen!\n" }) );
- else // ... Fehlerbehandlung, falls Prop schon gesetzt ...
-
-
-
- Soll die Prop aus irgendeinem Grund (vorzeitig) geloescht werden:
- pl->SetProp(P_DISABLE_COMMANDS, 0);
-
-
-SIEHE AUCH
-==========
-
- command(), query_command(), command_stack(), modify_command(),
- this_player()
-
-01.12.2012, Zesstra
diff --git a/doc/sphinx/man/props/P_DISTRIBUTION b/doc/sphinx/man/props/P_DISTRIBUTION
deleted file mode 100644
index 51140ae..0000000
--- a/doc/sphinx/man/props/P_DISTRIBUTION
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_DISTRIBUTION
-**************
-
-
-NAME
-====
-
- P_DISTRIBUTION "std_food_distribution"
-
-
-DEFINIERT IN
-============
-
- /sys/food.h
-
-
-BESCHREIBUNG
-============
-
- Verteilung der Heilung ueber mehrere Heartbeats.
- Dieser Wert wird im entry_info als H_DISTRIBUTION dem consume() im
- Living uebergeben.
-
-
-SIEHE AUCH
-==========
-
- consume
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_DMSG b/doc/sphinx/man/props/P_DMSG
deleted file mode 100644
index 40af065..0000000
--- a/doc/sphinx/man/props/P_DMSG
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_DMSG
-******
-
-
-NAME
-====
-
- P_DMSG "destmsg"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- *** OBSOLET! *** Siehe P_DESTRUCT_MSG
diff --git a/doc/sphinx/man/props/P_DOMAIN b/doc/sphinx/man/props/P_DOMAIN
deleted file mode 100644
index aad5288..0000000
--- a/doc/sphinx/man/props/P_DOMAIN
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_DOMAIN
-********
-
-
-NAME
-====
-
- P_DOMAIN "lib_p_domain"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die Region, in der ein Raum liegt, sofern er
- in /d/ liegt.
-
- Falls ein Raum nicht in /d/ liegt, aber es eigentlich ein Gebiet ist,
- welches eindeutig in einer Region zugeordnet ist, kann der Magier
- hier gezielt einen anderen Wert setzen.
-
-
-
- Bitte keine Regionen faelschen!
-
-
-BEISPIEL
-========
-
- In /d/inseln/zesstra/vulkanweg/room/r1 liefert
- QueryProp(P_DOMAIN)
- ein "Inseln" zurueck.
-
- In einem Raum der Chaosgilde:
- SetProp(P_DOMAIN, "Polar");
- damit der Raum als Raum der Region Polar angezeigt wird.
-
-
-SIEHE AUCH
-==========
-
- gmcp
-
-23.02.2013, Zesstra
diff --git a/doc/sphinx/man/props/P_DOOR_INFOS b/doc/sphinx/man/props/P_DOOR_INFOS
deleted file mode 100644
index dc393da..0000000
--- a/doc/sphinx/man/props/P_DOOR_INFOS
+++ /dev/null
@@ -1,58 +0,0 @@
-
-P_DOOR_INFOS
-************
-
-
-NAME
-====
-
- P_DOOR_INFOS "door_infos"
-
-
-DEFINIERT IN
-============
-
- /sys/doorroom.h
-
-
-BESCHREIBUNG
-============
-
- Mapping mit Informationen ueber eine im Raum per NewDoor() definierte
- Tuer. Diese Infos werden ueber /std/room/doors.c an den /obj/doormaster.c
- weitergegeben und dem Raum, der die Tuer besitzt, als Property gesetzt.
- Werden mehrere Tueren in einem Raum eingebunden, enthaelt das Mapping
- entsprechend viele Eintraege.
-
- Dieses Mapping dient zur internen Verwaltung der Tueren im
- /obj/doormaster.c und sollte nicht per Hand veraendert werden!
-
- Die Eintraege im Mapping haben folgende keys (definiert in
- /sys/doorroom.h):
-
- D_DEST : Zielraum (string)
- D_CMDS : Befehl(e), um durch die Tuer zu gehen (string oder *string)
- D_IDS : IDs der Tuer (string oder *string)
- D_FLAGS : Besondere Eigenschaften der Tuer (Tuer braucht Schluessel etc.)
- D_LONG : Langbeschreibung (string)
- D_SHORT : Kurzbeschreibung (string)
- D_NAME : Name (string oder *string)
- D_GENDER : Geschlecht
- D_FUNC : Funktion, die VOR dem Durchschreiten der Tuer aufgerufen wird
- D_MSGS : Bewegungsmeldungen
- D_FUNC2 : Funktion, die NACH dem Durchschreiten der Tuer aufgerufen wird
- D_TESTFUNC : Funktion die im Sartraum testet, ob die Tuer durchschritten
- werden darf
- D_RESET_MSG : Meldungen beim Tuer-Reset
- D_OPEN_WITH_MOVE : Falls gesetzt, wird die Tuer auch mit dem
- Bewegungsbefehl geoeffnet und durchschritten, falls
- Oeffnen erfolgreich
-
-
-SIEHE AUCH
-==========
-
- NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
-
-Letzte Aenderung: Don, 08.05.2014, Gabylon
diff --git a/doc/sphinx/man/props/P_DO_DESTRUCT b/doc/sphinx/man/props/P_DO_DESTRUCT
deleted file mode 100644
index 6aa9384..0000000
--- a/doc/sphinx/man/props/P_DO_DESTRUCT
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_DO_DESTRUCT
-*************
-
-
-NAME
-====
-
- P_DO_DESTRUCT "do_destruct"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Flag, ob sich die Lichtquelle am Ende der Leuchtzeit selbst
- zerstoert.
-
-
-SIEHE AUCH
-==========
-
- Basisklassen: /std/lightsource.c
- Properties: P_FUEL, P_LIGHTDESC, P_LIGHT
- Methoden: AddFuel(L)
-
-
-LETZTE AENDERUNG
-================
-
- 22. Dez. 2015, Arathorn
diff --git a/doc/sphinx/man/props/P_DRINK b/doc/sphinx/man/props/P_DRINK
deleted file mode 100644
index 028e987..0000000
--- a/doc/sphinx/man/props/P_DRINK
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_DRINK
-*******
-
-
-NAME
-====
-
- P_DRINK "drink"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- - Lebewesen
- Numerischer Wert fuer den Saettigungsgrad eines Lebewesens mit
- Getraenken. Der maximale Wert steht in P_MAX_DRINK.
-
- - Speisen/Kneipen
- Numerischer Wert fuer den Saettigungsgrad einer Portion eines
- Getraenkes. Ist diese Property nicht gesetzt oder zusaetzlich
- P_FOOD gesetzt, kann man diese Speise nicht trinken. Eine
- funktionierende Speise _muss_ entweder P_FOOD oder P_DRINK
- groesser 0 gesetzt haben.
-
-
-SIEHE AUCH
-==========
-
- P_MAX_DRINK, P_DRINK_DELAY, consume
- P_FOOD, P_ALCOHOL, wiz/food
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_DRINK_DELAY b/doc/sphinx/man/props/P_DRINK_DELAY
deleted file mode 100644
index 1617b47..0000000
--- a/doc/sphinx/man/props/P_DRINK_DELAY
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_DRINK_DELAY
-*************
-
-
-NAME
-====
-
- P_DRINK_DELAY "drink_delay"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der heart_beats, bis P_DRINK um einen Punkt sinkt.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
diff --git a/doc/sphinx/man/props/P_DRINK_FULL_MSG b/doc/sphinx/man/props/P_DRINK_FULL_MSG
deleted file mode 100644
index 1e5c2ce..0000000
--- a/doc/sphinx/man/props/P_DRINK_FULL_MSG
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_DRINK_FULL_MSG
-****************
-
-
-NAME
-====
-
- P_DRINK_FULL_MSG "std_food_drink_full_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Konsumenten, wenn ein Getraenk getrunken werden soll,
- obwohl dieser nichts mehr trinken kann.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "So viel kannst Du im Moment nicht trinken."
-
-
-SIEHE AUCH
-==========
-
- P_DRINK, P_MAX_DRINK, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_DROP_MSG b/doc/sphinx/man/props/P_DROP_MSG
deleted file mode 100644
index 9ccb875..0000000
--- a/doc/sphinx/man/props/P_DROP_MSG
+++ /dev/null
@@ -1,96 +0,0 @@
-
-P_DROP_MSG
-**********
-
-
-NAME
-====
-
- P_DROP_MSG "drop_message"
-
-
-DEFINIERT IN
-============
-
- /sys/living/put_and_get.h
-
-
-BESCHREIBUNG
-============
-
- Mit P_DROP_MSG kann man die Meldung, die man beim Ablegen eines
- Objektes bekommt, modifizieren.
-
- Folgende Werte sind moeglich:
-
-
-
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
-
-
-
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
-
-
-
- o Ein Array aus Strings
- Der erste String wird an den Spieler ausgegeben, der zweite
- (optionale) an den Raum.
-
-
-
- Die Strings werden durch die Funktion replace_personal() geparst.
- Objekt1 - Spieler
- Objekt2 - das Objekt, das fallengelassen wird
-
-
-
- Wird der zweite String nicht angegeben, erfolgt keine Meldung an
- den Raum.
-
-
-BEISPIEL
-========
-
- void create() {
- ...
- SetProp( P_SHORT, "Ugars Handaxt" );
- SetProp( P_LONG, break_string(
- "Dieses ist eine Kampfaxt, wie sie Orks normalerweise benutzen. "
- "Da Du Zeit hast, sie Dir anzuschauen, ist der Besitzer wohl "
- "bereits bei Lars.",78 ));
-
-
-
- SetProp( P_NAME, "Axt" );
- AddId( ({"handaxt","axt"}) );
- SetProp( P_GENDER, FEMALE );
-
-
-
- SetProp( P_DROP_MSG, ({
- "Du schmeisst @WEN2 hin.",
- "@WER1 schmeisst Dir @WENU2 vor die Fuesse.\n"}));
- ...
- }
-
- Will Ugar seine Axt ablegen und gibt "lasse axt fallen" ein, werden
- folgende Meldungen ausgegeben:
-
-
-
- Ugar: "Du schmeisst die Axt hin."
- Raum: "Ugar schmeisst Dir eine Axt vor die Fuesse."
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_PICK_MSG, P_PUT_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
- Fehler: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
- P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET
- Sonstiges: replace_personal(E), drop_obj(L), /std/living/put_and_get.c
-
-14. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_EARMUFFS b/doc/sphinx/man/props/P_EARMUFFS
deleted file mode 100644
index e5b4bbb..0000000
--- a/doc/sphinx/man/props/P_EARMUFFS
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_EARMUFFS
-**********
-
-
-NAME
-====
-
- P_EARMUFFS "earmuffs"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Shouts von Spielern und Magiern mit Magierlevel < earmuffs werden
- abgeblockt (Nur fuer Magier).
diff --git a/doc/sphinx/man/props/P_EATER_MSG b/doc/sphinx/man/props/P_EATER_MSG
deleted file mode 100644
index 132469d..0000000
--- a/doc/sphinx/man/props/P_EATER_MSG
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_EATER_MSG
-***********
-
-
-NAME
-====
-
- P_EATER_MSG "std_food_eater_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Konsumenten, wenn eine Speise konsumiert wird.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "Du konsumierst @WEN1."
-
-
-SIEHE AUCH
-==========
-
- /std/food.c, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_EFFECTIVE_AC b/doc/sphinx/man/props/P_EFFECTIVE_AC
deleted file mode 100644
index 5473d5d..0000000
--- a/doc/sphinx/man/props/P_EFFECTIVE_AC
+++ /dev/null
@@ -1,107 +0,0 @@
-
-P_EFFECTIVE_AC
-**************
-
-
-NAME
-====
-
- P_EFFECTIVE_AC "effective_ac"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property kommt sowohl in Ruestungen als auch in Waffen, die
- schuetzen sollen, zum Einsatz.
-
- In Ruestungen kann hier der Effektivwert der Ruestungsklasse vermerkt
- werden, wenn diese noch durch eine DefendFunc() modifiziert wird
- (soweit sich ein solcher Effektivwert angeben laesst).
-
- In einigen Gilden koennen Waffen auch als Ruestung eingesetzt werden
- (z.B. beim Parieren eines Angriffs). In dieser Property kann man die
- Ruestungsklasse eintragen, die die Waffe bei solchen Aktionen aufweisen
- soll. Dabei ist man an die ueblichen Beschraenkungen der
- Ruestungsklasse gebunden! (s. /sys/combat.h)
-
-
-BERMERKUNGEN
-============
-
- Das Kaempferspellbook verwendet fuer Paraden etc. P_EFFECTIVE_AC anstatt
- P_AC, wenn verfuegbar.
-
-
-BEISPIELE
-=========
-
- * DefendFuncs:
- Der doppelte Mittelwert der DefendFunc wird zur Basis-AC dazuaddiert,
- da sich der 'Schutzwert = random(Basis-AC) + absolut(DefendFunc-Wert)'
- berechnet.
-
- // #1 Eine Ruestung mit P_AC von 35 und randomisierter DefendFunc
- SetProp(P_AC, 35);
- SetProp(P_DEFEND_FUNC, this_object());
-
- int DefendFunc(...) {
- return random(20); // Mittelwert: 10
- }
- -> SetProp(P_EFFECTIVE_AC, 55); // 35 + 2*10 = 55
-
- // #2 Eine Ruestung mit P_AC von 35 und teilrandomisierter DefendFunc
- SetProp(P_AC, 35);
- SetProp(P_DEFEND_FUNC, this_object());
-
- int DefendFunc(...) {
- return 20 + random(10); // Mittelwert: 20 + 5
- }
- -> SetProp(P_EFFECTIVE_AC, 85); // 35 + 2*(20+5) = 85
-
- * Sonderfunktion im Kontext der Kaempfergilde:
- Auch wenn der eigentliche AC-Wert durch keine DefendFunc oAe
- modifiziert wird, sind abweichende Werte in P_EFFECTIVE_AC zB in der
- Kaempfergilde fuer Paraden oder aehnliches sinnvoll. Maximalwert ist
- dafuer der doppelte Wert des Basis-AC-Wertes.
-
- // #3 Ein schon sehr gutes Schild, welches bei der Schildparade aber
- // noch besser schuetzen soll.
- SetProp(P_ARMOUR_TYPE, AT_SHIELD);
- SetProp(P_AC, 38);
- SetProp(P_EFFECTIVE_AC, 55);
-
- // #4 Ein sehr labbriges Schild schuetzt zwar gegen normale Schlaege,
- // ist zum Parieren aber irgendwie ungeeignet weil unkontrollierbar.
- SetProp(P_ARMOUR_TYPE, AT_SHIELD);
- SetProp(P_AC, 38);
- SetProp(P_EFFECTIVE_AC, 20);
-
- * Waffen:
- P_EFFECTIVE_AC wird im Kaempferspellbook als Bonus dazugezaehlt! Daher
- sollten gute Parierwaffen auch einen niedrigeren P_WC-Wert haben.
- Reine Parierwaffen duerfen den maximalen AC-Wert von Schilden als
- Maximum gesetzt haben - die Balance klaert ggf, ob das auch auf den
- Gildenparierwert anwendbar ist.
-
- // #5 Eine maessige Hellebarde/Axtwaffe mit Parierhaken.
- SetProp(P_WEAPON_TYPE, WT_AXE);
- SetProp(P_WC, 100);
- SetProp(P_EFFECTIVE_AC, 25);
-
-
-SIEHE AUCH
-==========
-
- Waffen: P_WC, P_TOTAL_WC, P_EFFECTIVE_WC, HitFunc()
- Ruestungen: P_AC, P_TOTAL_AC, DefendFunc()
- Files: /std/weapon.c, /std/weapon/combat.c
- Balance: waffen, ruestungen, properties, kaempferboni
-
-6. Nov 2011 Gloinson
diff --git a/doc/sphinx/man/props/P_EFFECTIVE_WC b/doc/sphinx/man/props/P_EFFECTIVE_WC
deleted file mode 100644
index aa16980..0000000
--- a/doc/sphinx/man/props/P_EFFECTIVE_WC
+++ /dev/null
@@ -1,112 +0,0 @@
-
-P_EFFECTIVE_WC
-**************
-
-
-NAME
-====
-
- P_EFFECTIVE_WC "effective_wc"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property kommt sowohl in Waffen als auch Ruestungen, die Schaden
- machen sollen, zum Einsatz.
-
- Falls die Staerke einer Waffe noch durch eine HitFunc() modifiziert
- wird, sollte hier der Effektivwert der Waffenklasse vermerkt werden,
- soweit er sich angeben laesst.
- Diese Property dient vor allem dazu, eine Waffe mit HitFunc() korrekt
- einzuschaetzen.
-
- In einigen Gilden koennen Ruestungen auch als Waffen eingesetzt werden
- (z.B. ein Paar Schuhe zum Treten). In dieser Property kann man die
- Waffenklasse eintragen, die die Ruestung bei solchen Aktionen aufweisen
- soll. Dabei ist man an die ueblichen Beschraenkungen der Waffenklasse
- gebunden! (s. /sys/combat.h)
- Der Ruestung kann man dann auch einen Schadenstyp mit auf den Weg
- geben.
-
-
-BEMERKUNGEN
-===========
-
- Das Kaempferspellbook verwendet bei Ruestungen P_AC, wenn
- P_EFFECTIVE_WC nicht gesetzt ist.
-
-
-BEISPIELE
-=========
-
- * HitFuncs:
- Der doppelte Mittelwert der HitFunc wird zur Basis-WC dazuaddiert,
- da sich der 'Angriffswert = random(Basis-WC) + absolut(HitFunc-Wert)'
- berechnet.
-
- // #1 Waffe mit Basis-WC 120 und randomisierter HitFunc
- SetProp(P_WC, 120);
- SetProp(P_HIT_FUNC, this_object());
-
-
-
- int HitFunc(...) {
- return random(30); // Mittelwert: 15
- }
- -> SetProp(P_EFFECTIVE_WC, 150); // 120 + 2*15 = 150
-
-
-
- // #2 Waffe mit Basis-WC 120 und teilweise absoluter HitFunc
- SetProp(P_WC, 120);
- SetProp(P_HIT_FUNC, this_object());
-
-
-
- int HitFunc(...) {
- return 30 + random(10); // Mittelwert: 30 + 5
- }
- -> SetProp(P_EFFECTIVE_WC, 190); // 120 + 2*(30+5) = 190
-
- * Ruestungen (zB Gildennutzung):
- Der Maximalwert fuer die P_EFFECTIVE_WC bei Kaempfern ist der jeweils
- doppelte maximale P_AC-Wert. Angabe eines Schadenstyps ist sinnvoll.
-
- // #3 Ein paar Schuhe, mit maximalem Schlag-/Saeureschaden.
- SetProp(P_ARMOUR_TYPE, AT_BOOT);
- SetProp(P_AC, 2);
- SetProp(P_DAM_TYPE, ({DT_BLUDGEON,DT_ACID}));
- -> SetProp(P_EFFECTIVE_WC, 12); // hoechstmoeglicher Wert bei
- // Schuhen, da deren max. P_AC = 6
- // aequivalent und zukunftssicher:
- -> SetProp(P_EFFECTIVE_WC, 2 * VALID_ARMOUR_CLASS[AT_BOOT]);
-
- // #4 Ein Schild mit spitzem Dorn. (Stichschaden beim Schildstoss.)
- SetProp(P_ARMOUR_TYPE, AT_SHIELD);
- SetProp(P_AC, 5);
- SetProp(P_DAM_TYPE, ({DT_PIERCE}));
- SetProp(P_EFFECTIVE_WC, 55);
-
- // #5 Ein Gummischild ist schlecht fuer Angriffe. BOING!
- SetProp(P_ARMOUR_TYPE, AT_SHIELD);
- SetProp(P_AC, 30);
- SetProp(P_DAM_TYPE, ({DT_BLUDGEON}));
- SetProp(P_EFFECTIVE_WC, 10);
-
-
-SIEHE AUCH
-==========
-
- Waffen: P_WC, P_TOTAL_WC, HitFunc()
- Ruestungen: P_AC, P_TOTAL_AC, P_EFFECTIVE_AC, DefendFunc()
- Files: /std/weapon.c, /std/weapon/combat.c
- Balance: waffen, ruestungen, properties, kaempferboni
-
-6. Nov 2011 Gloinson
diff --git a/doc/sphinx/man/props/P_EMPTY_MSG b/doc/sphinx/man/props/P_EMPTY_MSG
deleted file mode 100644
index e91d622..0000000
--- a/doc/sphinx/man/props/P_EMPTY_MSG
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_EMPTY_MSG
-***********
-
-
-NAME
-====
-
- P_EMPTY_MSG "std_food_eater_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Konsumenten, wenn versucht wird, eine aufgebrauchte Speise
- (also einen leeren Behaelter) zu konsumieren.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise (also den leeren Behaelter)
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "@WER1 ist bereits leer."
-
-
-SIEHE AUCH
-==========
-
- /std/food.c, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_EMPTY_PROPS b/doc/sphinx/man/props/P_EMPTY_PROPS
deleted file mode 100644
index 6f5c126..0000000
--- a/doc/sphinx/man/props/P_EMPTY_PROPS
+++ /dev/null
@@ -1,54 +0,0 @@
-
-P_EMPTY_PROPS
-*************
-
-
-NAME
-====
-
- P_EMPTY_PROPS "std_food_empty_props"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Mapping mit Properties fuer den leeren Behaelter, der uebrig bleibt,wenn
- eine Speise aufgebraucht ist. Alle enthaltenen Properties werden gesetzt,
- wenn keine Portionen mehr vorhanden sind.
- Bereits in diesen Properties eingetragene Werte werden ueberschrieben!
- Wenn diese Property nicht gesetzt ist, wird die Speise zerstoert, wenn
- alle Portionen aufgebraucht ist - es bleibt also kein Behaelter zurueck.
- Achtung: Es werden keine closures in diesem Mapping unterstuetzt!
-
-
-BEMERKUNGEN
-===========
-
- Bei der Abfrage von P_VALUE und P_WEIGHT in der Speise, werden die dazu
- in P_EMPTY_PROPS gespeicherten Werte verwendet, um das Gewicht/Wert des
- leeren Behaelters zum Gesamtwert der Speise zu addieren.
- Man kann alle Properties in dieses Mapping eintragen, die sich in der
- Speise per SetProp setzen lassen. Zusaetzlich kann man Arrays in P_IDS
- und P_ADJECTIVES speichern, die per Add-Methode in der Speise
- hinzugefuegt werden, nachdem die im create() der Speise hinzugefuegten
- Ids/Adjectives dort entfernt wurden.
-
-
-BEISPIELE
-=========
-
- Beispiele zur Verwendung findet man unter /doc/beispiele/food
-
-
-SIEHE AUCH
-==========
-
- /std/food.c, wiz/food
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_ENABLE_IN_ATTACK_OUT b/doc/sphinx/man/props/P_ENABLE_IN_ATTACK_OUT
deleted file mode 100644
index 0a64c74..0000000
--- a/doc/sphinx/man/props/P_ENABLE_IN_ATTACK_OUT
+++ /dev/null
@@ -1,51 +0,0 @@
-
-P_ENABLE_IN_ATTACK_OUT
-**********************
-
-
-NAME
-====
-
- P_ENABLE_IN_ATTACK_OUT "enable_in_attack_out"
-
-
-DEFINIERT IN
-============
-
- /sys/combat.h
-
-
-BESCHREIBUNG
-============
-
- Normalerweise wird die bekannte Taktik Rein-Angriff-Raus
- standardmaessig unterbunden, damit NPCs auch eine Chance haben, sich
- zu verteidigen. Hierzu wird der Schaden innerhalb do_damage()
- durch einen Wert geteilt, der sich aus der Verweildauer des
- Angreifers im Raum ergibt (bis zu 3 Sekunden).
- Da manche NPCs so konzeptioniert wurden, dass man sie nur mit der
- erwaehnten Taktik toeten kann, kann man sie auch explizit erlauben
- (manche NPCs verwenden auch eigene Methoden, diese Taktik zu
- verbieten, und sie waere dann doppelt abgefangen).
- Hierzu setzt man einfach die Property P_ENABLE_IN_ATTACK_OUT im NPC.
-
-
-BEISPIEL
-========
-
- Das folgende Beispiel erlaubt einfach mal die angesprochene Taktik:
- void create()
- { ...
- SetProp(P_ENABLE_IN_ATTACK_OUT,1);
- ...
- }
- Jetzt kann man den NPC mit Rein-Angriff-Raus auch wirkungsvoll
- bekaempfen.
-
-
-SIEHE AUCH
-==========
-
- do_damage(), P_LAST_MOVE, /std/living/life.c
-
-Last modified: Sat Jan 30 12:53:00 1999 by Patryn
diff --git a/doc/sphinx/man/props/P_ENEMY_DAMAGE b/doc/sphinx/man/props/P_ENEMY_DAMAGE
deleted file mode 100644
index bad9c99..0000000
--- a/doc/sphinx/man/props/P_ENEMY_DAMAGE
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_ENEMY_DAMAGE
-**************
-
-
-NAME
-====
-
- P_ENEMY_DAMAGE "enemy_damage"
-
-
-DEFINIERT IN
-============
-
- <living/life.h>
-
-
-BESCHREIBUNG
-============
-
- In dieser Property ist vermerkt, welches Wesen diesem Wesen wieviel
- Schaden zugefuegt hat.
-
- Die Property enthaelt ein Mapping, das den Angreifern den
- errechten Schaden zuordnet:
- ([ <obname1>: <damage>; <owner>, ... ])
-
- <obname1>: Name des Objekts, das den Schaden verursacht hat (string),
- z.B. "/magier:zesstra"
- <damage> : Schadensmenge (int)
- <owner> : wenn das schadensverursachende Wesen ein NPC war/ist,
- welches P_HELPER_NPC gesetzt hatte und somit einem Spieler
- hilft, steht hier das Objekt des jeweiligen Spielers
- (object)
-
-
-BEMERKUNGEN
-===========
-
- Diese Property laesst sich nur abfragen!
-
-
-SIEHE AUCH
-==========
-
- P_HELPER_NPC
-
-26.10.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_ENEMY_DEATH_SEQUENCE b/doc/sphinx/man/props/P_ENEMY_DEATH_SEQUENCE
deleted file mode 100644
index 03b2bec..0000000
--- a/doc/sphinx/man/props/P_ENEMY_DEATH_SEQUENCE
+++ /dev/null
@@ -1,61 +0,0 @@
-
-P_ENEMY_DEATH_SEQUENCE
-**********************
-
-
-NAME
-====
-
- P_ENEMY_DEATH_SEQUENCE "enemy_death_sequence"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Ueber diese Property kann Einfluss auf die Todessequenz eines getoeten
- Spielers genommen werden. Sie muss im toetenden Objekt, d.h. dem
- Objekt welches die()/do_damage()/Defend() im Spieler gerufen hat,
- gesetzt sein.
-
- Es gibt folgende gueltige Werte:
- - string: Pfad zu einer eigenen Todessequenz im gueltigen Format
- - mixed* Eine Todessequenz im Format des Todesraumes:
- ({<int gesamtlaenge>,
- ([<int index1>: <string umgebrochene Meldung1>,
- <int index2>: <string umgebrochene Meldung2>,
- ...])
- })
- - mapping In die Standard-Lars-Todessequenz einzufuegende Zeilen:
- ([<int zeitindex>: <string umgebrochener Text>])
-
-
-BEISPIELE
-=========
-
- // Pfad zu einer eigenen DSQ
- SetProp(P_ENEMY_DEATH_SEQUENCE, ".../passende_dsq.txt");
-
- // eigene DSQ im Todesraumformat:
- SetProp(P_ENEMY_DEATH_SEQUENCE,
- ({ 2, ([1: "DU LERNST AUS DEINEM FEHLER.\n"])}));
-
- // Einfuegen einer Meldung (des NPCs) in die Standard-Todessequenz
- SetProp(P_ENEMY_DEATH_SEQUENCE,
- ([5: "Du hoerst "+name(WEN)+" hoehnisch kichern.\n"]));
-
-
-SIEHE AUCH
-==========
-
- Tod: die(L)
- Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
- P_ZAP_MSG, P_NEXT_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /room/death/death_room.c
-
-10. Nov 2011 Gloinson
diff --git a/doc/sphinx/man/props/P_ENTERCMDS b/doc/sphinx/man/props/P_ENTERCMDS
deleted file mode 100644
index fc6f72f..0000000
--- a/doc/sphinx/man/props/P_ENTERCMDS
+++ /dev/null
@@ -1,57 +0,0 @@
-
-P_ENTERCMDS
-***********
-
-
-NAME
-====
-
- P_ENTERCMDS "leavecmds"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Ein Array mit Befehlen, die zum Betreten des Transporters fuehren.
-
-
-BEISPIEL
-========
-
- SetProp(P_ENTERCMDS,({ "betrete","betritt" }) );
-
- Gibt der Spieler nun 'betrete xxx' ein, so sorgt /std/transport.c
- dafuer, das der Spieler auch auf oder in den Transporter bewegt
- wird. Vorausgesetzt natuerlich, er ist an einem Haltepunkt ange-
- langt und es ist genuegend Platz dort.
-
-
-BEMERKUNGEN
-===========
-
- Um /std/transport.c nicht aufzublaehen, werden weitere Argumente wie
- etwa 'betrete das|die|den xxx' _nicht_ unterstuetzt!
-
- Hier muss der verantwortliche Magier schon eine eigene Loesung finden
- und in seinen Transporter schreiben.
-
- Sollen Kommandos zum Betreten UND Verlassen eines Transporters ver-
- wendet werden koennen, muessen diese in P_TRAVEL_CMDS gesetzt werden.
-
-
-SIEHE AUCH
-==========
-
- P_LEAVEFAIL, P_ENTERFAIL, P_LEAVECMDS, P_TRAVEL_CMDS, transporter,
-
-
-LETZTE AENDERUNG
-================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_ENTERFAIL b/doc/sphinx/man/props/P_ENTERFAIL
deleted file mode 100644
index 5291065..0000000
--- a/doc/sphinx/man/props/P_ENTERFAIL
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_ENTERFAIL
-***********
-
-
-NAME
-====
-
- P_ENTERFAIL "enterfail"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Spieler, wenn er einen vollen Transporter betreten
- will. Ist die Propertie ein Array, so wird das erste Element als
- Meldung an den Spieler, das zweite als Meldung an die Mitspieler
- im Raum geschickt.
-
-
-BEISPIEL
-========
-
- SetProp(P_ENTERFAIL,"Dort ist wirklich kein Platz mehr fuer Dich");
-
-
-
- SetProp(P_ENTERFAIL, ({ "Dort ist wirklich kein Platz mehr fuer Dich",
- "versucht, auf die Kutsche zu klettern, wird "
- +"aber wieder heruntergeschickt" }) );
-
-
-SIEHE AUCH
-==========
-
- P_ENTERMSG, P_LEAVEFAIL, P_LEAVEMSG, transporter
-
-
-LETZTE AENDERUNG
-================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_ENTERMSG b/doc/sphinx/man/props/P_ENTERMSG
deleted file mode 100644
index 9ba314d..0000000
--- a/doc/sphinx/man/props/P_ENTERMSG
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_ENTERMSG
-**********
-
-
-NAME
-====
-
- P_ENTERMSG "entermsg"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Array mit zwei Meldungen, eine fuer den Raum, den der Spieler
- verlaesst, und eine fuer den Transporter, in den er geht.
-
-
-BEISPIEL
-========
-
- SetProp(P_ENTERMSG, ({ "klettert in die Kutsche","klettert herein" }) );
-
-
-SIEHE AUCH
-==========
-
- P_ENTERFAIL, P_LEAVEFAIL, P_LEAVEMSG, transporter
-
-
-LETZTER AENDERUNG
-=================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_ENV_MSG b/doc/sphinx/man/props/P_ENV_MSG
deleted file mode 100644
index e969399..0000000
--- a/doc/sphinx/man/props/P_ENV_MSG
+++ /dev/null
@@ -1,47 +0,0 @@
-
-P_ENV_MSG
-*********
-
-
-NAME
-====
-
- P_ENV_MSG "std_food_env_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Konsumenten, wenn eine Speise konsumiert werden soll,
- die nicht im eigenen Inventory liegt.
- Wenn diese Property leer ist, kann man die Speise dann sogar
- konsumieren!
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "Vielleicht solltest Du @WEN1 vorher nehmen."
-
-
-SIEHE AUCH
-==========
-
- wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_ENV_TOO_HEAVY_MSG b/doc/sphinx/man/props/P_ENV_TOO_HEAVY_MSG
deleted file mode 100644
index 23c1d6c..0000000
--- a/doc/sphinx/man/props/P_ENV_TOO_HEAVY_MSG
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_ENV_TOO_HEAVY_MSG
-*******************
-
-
-NAME
-====
-
- P_ENV_TOO_HEAVY_MSG "env_too_heavy_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
- versucht, ein Objekt in einen Behaelter zu legen, und dieser dann fuer
- sein Environment zu schwer wird.
- Die Property ist im Behaelter zu setzen.
- Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
- so wird die Standardmeldung ausgegeben.
- ("<Behaelter> wuerde dir dann zu schwer werden.")
- Der String in der Property wird noch durch replace_personal()
- verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
- zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
- umgebrochen.
- Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
- ganz.
-
-
-BEISPIELE
-=========
-
- SetProp(P_ENV_TOO_HEAVY_MSG, "Mit @WEM1 koenntest du den Rucksack nicht"
- " mehr tragen.");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_TOO_HEAVY_MSG, P_TOO_MANY_MSG, P_NOINSERT_MSG,
- P_NOLEAVE_MSG, P_NODROP, P_NOGET
- Erfolg: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
- P_WEAR_MSG, P_WIELD_MSG
- Sonstiges: replace_personal(E), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/props/P_EQUIP_TIME b/doc/sphinx/man/props/P_EQUIP_TIME
deleted file mode 100644
index ee0d07f..0000000
--- a/doc/sphinx/man/props/P_EQUIP_TIME
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_EQUIP_TIME
-************
-
-
-NAME
-====
-
- P_EQUIP_TIME "equip_time"
-
-
-DEFINIERT IN
-============
-
- /sys/combat.h
-
-
-BESCHREIBUNG
-============
-
- Innerhalb von Waffen und Ruestungen wird in dieser Property
- registriert, wann diese zuletzt gezueckt bzw. angezogen wurden.
- Innerhalb der Funktionen wield_me() in '/std/weapon/combat' bzw.
- DoWear() in '/std/armour/combat' wird hierbei jeweils folgende Aktion
- ausgefuehrt:
- SetProp(P_EQUIP_TIME,time());
-
-
-SIEHE AUCH
-==========
-
- Verwandt: P_LAST_USE
- Waffen: P_UNWIELD_TIME
- DoWield()
- Ruestungen: DoWear()
- Sonstiges: time()
- /std/weapon/combat.c, /std/armour/combat.c
-
-Last modified: Sun Jul 26 23:59:12 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_EVAL_FACTORS b/doc/sphinx/man/props/P_EVAL_FACTORS
deleted file mode 100644
index ed83d4e..0000000
--- a/doc/sphinx/man/props/P_EVAL_FACTORS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_EVAL_FACTORS
-**************
-
-
-NAME
-====
-
- P_EVAL_FACTORS "inpc_eval_factors"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/eval.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_EVAL_OFFSETS b/doc/sphinx/man/props/P_EVAL_OFFSETS
deleted file mode 100644
index e571f51..0000000
--- a/doc/sphinx/man/props/P_EVAL_OFFSETS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_EVAL_OFFSETS
-**************
-
-
-NAME
-====
-
- P_EVAL_OFFSETS "inpc_eval_offsets"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/eval.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_EXITS b/doc/sphinx/man/props/P_EXITS
deleted file mode 100644
index c31bac3..0000000
--- a/doc/sphinx/man/props/P_EXITS
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_EXITS
-*******
-
-
-NAME
-====
-
- P_EXITS "exits"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Mapping (der Breite 2) aller unmittelbar sichtbaren Ausgaenge mit
- zugehoerigen Nachbarraeumen und der jeweiligen Bewegungsmeldung.
-
-
-BEMERKUNG
-=========
-
- Enthaelt auch SpecialExits, bei der Abfrage mit QueryProp() werden
- diese jedoch ausgefiltert.
-
-
-
- Zugriff nur mit den dafuer vorgesehenen Funktionen, bitte nicht aendern.
-
-
-SIEHE AUCH
-==========
-
- AddExit(), AddSpecialExit(), GetExits(),
- RemoveExit(), RemoveSpecialExit(),
- GuardExit(),
- H_HOOK_EXIT_USE, P_SPECIAL_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
-
-Letzte Aenderung: 22.12.2016, Bugfix
diff --git a/doc/sphinx/man/props/P_EXTRA_LOOK b/doc/sphinx/man/props/P_EXTRA_LOOK
deleted file mode 100644
index e4f050e..0000000
--- a/doc/sphinx/man/props/P_EXTRA_LOOK
+++ /dev/null
@@ -1,52 +0,0 @@
-
-P_EXTRA_LOOK
-************
-
-
-NAME
-====
-
- P_EXTRA_LOOK "extralook"
-
-
-DEFINIERT IN
-============
-
- /sys/living/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt einen String. Sie wird entweder in Lebewesen
- direkt oder in Objekten gesetzt, die im Besitz von Lebewesen
- sein koennen.
- Diese Strings erscheinen dann zusaetzlich in der Langbeschreibung
- des Lebewesens bzw. des Besitzers (wenn das Objekt sich direkt im
- Lebewesen befindet, jedoch nicht in einem Behaelter im Lebewesen).
- Fuer den Zeilenumbruch muss man selbst sorgen.
-
-
-BEISPIEL
-========
-
- Ein Spieler hat eine Pfeife im Mund. In dieser Pfeife setzt man z.B.
- in der Funktion zum Pfeife Rauchen folgendes:
- SetProp(P_EXTRA_LOOK,break_string(
- this_player()->Name(WER)+" ist ganz umnebelt.",78);
-
-
-BEMERKUNG
-=========
-
- NUR dann benutzen, wenn ihr auch unabhaengig vom Extralook ein Objekt im
- Spieler benoetigt, ansonsten IMMER AddExtraLook() verwenden.
-
-
-SIEHE AUCH
-==========
-
- long(), /std/living/description.c, /std/player/base.c
- AddExtraLook(), RemoveExtraLook()
-
-16.02.2017, Bugfix
diff --git a/doc/sphinx/man/props/P_FAO b/doc/sphinx/man/props/P_FAO
deleted file mode 100644
index 33f673e..0000000
--- a/doc/sphinx/man/props/P_FAO
+++ /dev/null
@@ -1,33 +0,0 @@
-
-P_FAO
-*****
-
-
-NAME
-====
-
- P_FAO "fraternitasdonoarchmagorum"
-
-
-DEFINIERT IN
-============
-
- <player/fao.h>
-
-
-BESCHREIBUNG
-============
-
- Fraternitas-relevante Property.
-
- Genaue Informationen unbekannt.
- Schreibender Zugriff ist nur EMs oder dem FAOMASTER (s. Headerfile)
- moeglich.
-
-
-SIEHE AUCH
-==========
-
- P_FAO_PORTALS
-
-1.September 2008 Gloinson
diff --git a/doc/sphinx/man/props/P_FAO_PORTALS b/doc/sphinx/man/props/P_FAO_PORTALS
deleted file mode 100644
index 5d80c90..0000000
--- a/doc/sphinx/man/props/P_FAO_PORTALS
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_FAO_PORTALS
-*************
-
-
-NAME
-====
-
- P_FAO_PORTALS "fraternitasdonoarchmagorumPORTALS"
-
-
-DEFINIERT IN
-============
-
- <player/fao.h>
-
-
-BESCHREIBUNG
-============
-
- Fraternitas-relevante Property.
-
- Enthaelt eine Array mit einer Liste der ueber die Fraternitas
- gefundenen und benutzbaren Seher-Portale.
-
- Genaue Informationen unbekannt.
- Schreibender Zugriff ist nur EMs oder dem FAOMASTER (s. Headerfile)
- moeglich.
-
-
-SIEHE AUCH
-==========
-
- P_FAO_PORTALS, P_SEERDOORS
-
-1.September 2008 Gloinson
diff --git a/doc/sphinx/man/props/P_FISH b/doc/sphinx/man/props/P_FISH
deleted file mode 100644
index 0fa259f..0000000
--- a/doc/sphinx/man/props/P_FISH
+++ /dev/null
@@ -1,92 +0,0 @@
-
-P_FISH
-******
-
-
-NAME
-====
-
- P_FISH "fish"
-
-
-DEFINIERT IN
-============
-
- /sys/fishing.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt Einstellungen zu allem, was mit Fischen zu tun hat.
- Kann in Fischen, Raeumen und Koedern gesetzt werden. Die verfuegbaren
- Optionen und Funktionsweisen sind in den nachfolgenden Abschnitten
- aufgefuehrt.
-
- Fische:
- *******
- Die Property legt zusaetzliche Eigenschaften fest:
-
- F_NOROTTEN
- Fisch fault nicht; ggf. sollte hier auch gleich F_NOHEAL gesetzt
- werden, weil sonst eine unverderbliche tragbare Tanke erzeugt wuerde.
- F_NOTHUNGRY
- Fisch frisst Koeder nur, wenn er auch wirklich nachher an der Angel
- haengt. Ist er zu schwer fuer die Angel und reisst ab, bleibt der
- Koeder erhalten.
- F_REPLACE
- Fisch soll sich beim Entfernen von der Angel verwandeln. Hierzu ist
- die Funktion ReplaceFish() im Fisch zu definieren, die sich um die
- Verwandlung kuemmert (z.B. Monster clonen und Fisch zerstoeren; ein
- Beispiel findet sich in /d/ebene/fraggle/angel2/obj/saegefisch.c).
- F_NOHEAL
- Fisch heilt nicht bei Verzehr
-
- Raum (OPTIONAL):
- ****************
- Legt die Fischdichte des Gewaessers fest. Der eingestellte Wert wirkt
- sich auf die Wartezeit aus, die der Angler verbringen muss, bis ein
- Fisch anbeisst. Berechnung im Detail (alle Zahlenwerte in Sekunden):
- - Basis-Wartezeit: delay = 80
- - Die Werte von P_FISH von Raum und Koeder werden addiert:
- summe = raum->QueryProp(P_FISH) + koeder->QueryProp(P_FISH)
- -> positive Werte (Bonus) werden auf 60 begrenzt und mit Zufalls-
- komponente von <delay> abgezogen:
- delay -= random(summe)
- -> negative Werte (Malus) werden auf -300 begrenzt und mit Zufalls-
- komponente auf <delay> aufgeschlagen:
- delay += random(-summe)
-
- Zusaetzlich wird ein weiterer Malus auf die Wartezeit faellig, falls
- P_WATER in der Angel und/oder P_WATER im Koeder nicht zum aktuellen
- Gewaesser passen. Der Malus betraegt jeweils 60+random(60) Sekunden.
-
-
-
- Der Standardwert fuer P_FISH im Raum ist 0 und bedeutet 100 % Bestand.
- Positive Werte erhoehen die Dichte, negative senken sie. Positive Werte
- sollten nicht >100 sein.
-
- Sofern sich die Werte fuer P_FISH in den empfohlenen Grenzen bewegen,
- koennen Abzuege fuer falsches Gewaesser ueblicherweise kaum durch
- Boni auf Angel oder Koeder kompensiert werden. Ausserdem ist zu
- bedenken, dass es keine Boni fuer richtige Gewaesserwahl gibt.
-
-
-
- Koeder (OPTIONAL):
- ******************
- Ein Koeder kann mittels P_FISH die Fischdichte modifizieren, um hierueber
- ein besseres Beissen der Fische zu simulieren (reduziert die Wartezeit
- beim Angeln, siehe oben unter "Raum"). Wenn also der Raum einen Wert
- von -100 gesetzt hat und der Koeder +100, entspricht die Fischdichte im
- Gewaesser wieder dem Normalwert.
-
-
-SIEHE AUCH
-==========
-
- Properties: P_WATER
- Methoden: GetAquarium(L)
-
-Zuletzt geaendert: 2014-Aug-21, Arathorn
diff --git a/doc/sphinx/man/props/P_FLAGS b/doc/sphinx/man/props/P_FLAGS
deleted file mode 100644
index 3962aed..0000000
--- a/doc/sphinx/man/props/P_FLAGS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_FLAGS
-*******
-
-
-NAME
-====
-
- P_FLAGS "can_flags"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Flags des Spielers
diff --git a/doc/sphinx/man/props/P_FOLLOW_SILENT b/doc/sphinx/man/props/P_FOLLOW_SILENT
deleted file mode 100644
index 6dd07b3..0000000
--- a/doc/sphinx/man/props/P_FOLLOW_SILENT
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_FOLLOW_SILENT
-***************
-
-
-NAME
-====
-
- P_FOLLOW_SILENT "follow_silent"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Wenn diese Property 1 ist, wird der MOVE vom verfolge Silent ausge-
- fuehrt.
diff --git a/doc/sphinx/man/props/P_FOOD b/doc/sphinx/man/props/P_FOOD
deleted file mode 100644
index 3858431..0000000
--- a/doc/sphinx/man/props/P_FOOD
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_FOOD
-******
-
-
-NAME
-====
-
- P_FOOD "food"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- - Lebewesen
- Numerischer Wert fuer den Saettigungsgrad eines Lebewesens.
- Der maximale Wert steht in P_MAX_FOOD.
-
- - Speisen/Kneipen
- Numerischer Wert fuer den Saettigungsgrad einer Portion einer
- Speise. Ist diese Property nicht gesetzt, kann man diese
- Speise nicht essen. Eine funktionierende Speise _muss_ entweder
- P_FOOD oder P_DRINK groesser 0 gesetzt haben.
-
-
-SIEHE AUCH
-==========
-
- P_MAX_FOOD, P_FOOD_DELAY, consume,
- P_DRINK, P_ALCOHOL, wiz/food
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_FOOD_DELAY b/doc/sphinx/man/props/P_FOOD_DELAY
deleted file mode 100644
index f4eb2df..0000000
--- a/doc/sphinx/man/props/P_FOOD_DELAY
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_FOOD_DELAY
-************
-
-
-NAME
-====
-
- P_FOOD_DELAY "food_delay"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der heart_beats, bis P_FOOD um einen Punkt sinkt.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
diff --git a/doc/sphinx/man/props/P_FOOD_FULL_MSG b/doc/sphinx/man/props/P_FOOD_FULL_MSG
deleted file mode 100644
index f5c1bce..0000000
--- a/doc/sphinx/man/props/P_FOOD_FULL_MSG
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_FOOD_FULL_MSG
-***************
-
-
-NAME
-====
-
- P_FOOD_FULL_MSG "std_food_full_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Konsumenten, wenn eine Speise gegessen werden soll,
- obwohl dieser nichts mehr essen kann.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "Du bist zu satt, das schaffst Du nicht mehr."
-
-
-SIEHE AUCH
-==========
-
- P_FOOD, P_MAX_FOOD, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_FORCE_MURDER_MSG b/doc/sphinx/man/props/P_FORCE_MURDER_MSG
deleted file mode 100644
index 709ef4e..0000000
--- a/doc/sphinx/man/props/P_FORCE_MURDER_MSG
+++ /dev/null
@@ -1,57 +0,0 @@
-
-P_FORCE_MURDER_MSG
-******************
-
-
-NAME
-====
-
- P_FORCE_MURDER_MSG "force_murder_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Ob der Tod eines NPCs auf dem Moerder-Kanal erscheint, haengt davon
- ab, wie oft und welche Art von NPCs in der letzten Zeit getoetet
- wurden. Zum Beispiel ist es eher selten, dass ein schwacher NPC auf
- dem Kanal erscheint, wenn kuerzlich viele starke NPCs getoetet
- wurden. Mittels der Property P_FORCE_MURDER_MSG kann man auf diese
- Regelung Einfluss nehmen.
- Ein Wert groesser Null erzwingt die Meldung auf dem Moerder-Kanal,
- ein Wert kleiner Null unterdrueckt sie generell. Letzteres ist
- insbesondere fuer allzuoft getoetete Monster sinnvoll, um den
- Moerder-Kanal nicht uebermaessig zu belasten. Mit dem Erzwingen der
- Meldungen sollte man somit vorsichtig sein: Weniger ist oftmals
- besser als zu viel!
- Die Defaulteinstellung von P_FORCE_MURDER_MSG ist natuerlich Null
- und fuehrt zur bereits beschriebenen opferabhaengigen Meldung.
-
-
-BEISPIELE
-=========
-
- Ein grosser starker NPC, der getoetet wurde, sollte schon eine tolle
- Meldung auf dem Moerder-Kanal erzeugen. In der Property
- P_MURDER_MSG koennen hierzu alternative Texte zu den normal per
- Zufall ausgewaehlten angegeben werden:
- SetProp(P_MURDER_MSG,
- "Nicht schlecht, aber das schafft eh nur einer!");
- SetProp(P_FORCE_MURDER_MSG,1);
- Zwar ist es bei grossen NPCs hinreichend wahrscheinlich, dass es
- infolge derer Staerke zur automatischen Ausgabe einer Moerdermeldung
- kommt, aber mit der letzten Zeile wurde dies absolut sichergestellt.
-
-
-SIEHE AUCH
-==========
-
- P_MURDER_MSG, P_ZAP_MSG, P_KILL_MSG, P_DIE_MSG, P_CORPSE, P_NOCORPSE
-
-Last modified: Tue Nov 10 02:15:26 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_FREE_HANDS b/doc/sphinx/man/props/P_FREE_HANDS
deleted file mode 100644
index c8311cc..0000000
--- a/doc/sphinx/man/props/P_FREE_HANDS
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_FREE_HANDS
-************
-
-
-NAME
-====
-
- P_FREE_HANDS "free_hands"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der freien Haende.
- Effektiv nur ein die Differenz von P_MAX_HANDS und P_USED_HANDS.
-
-
-BEMERKUNGEN
-===========
-
- Keine echte Property. Die Methode /std/living/combat::_query_free_hands
- stellt die Daten zusammen. Nicht setzen!
-
-
-SIEHE AUCH
-==========
-
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_USED_HANDS
- UseHands, FreeHands
- /std/weapon.c, /std/spellbook.c
-
-1. Okt 2012, Gloinson
diff --git a/doc/sphinx/man/props/P_FRIEND b/doc/sphinx/man/props/P_FRIEND
deleted file mode 100644
index b22203b..0000000
--- a/doc/sphinx/man/props/P_FRIEND
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_FRIEND
-********
-
-
-NAME
-====
-
- P_FRIEND "friend"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Setzt man diese Property in einem NPC auf einen Wert ungleich Null,
- so wird der NPC bei Zauberspruechen, die auf bestimmte Gruppen
- wirken, der Gruppe der Spieler und nicht der Gruppe der NPCs
- zugeordnet. Ausserdem wird der NPC bei einem "toete alle" nicht mit
- angegriffen.
- Wurde der NPC einem Spieler per AssocMember() zugeordnet, so
- befindet sich der NPC automatisch im jeweiligen Team des Spielers
- (moeglichst auch in der selben Kampfreihe), und die Property hat
- dann automatisch das Spielerobjekt als Wert.
- Da dieser Wert in diesem Fall natuerlich ungleich Null ist, wird der
- NPC dann auch der Gruppe der Spieler zugeordnet.
-
-
-SIEHE AUCH
-==========
-
- FindGroup(), AssocMember(), P_TEAM_ASSOC_MEMBERS, /std/living/team.c
-
-Last modified: Tue Dec 29 17:02:55 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_FROG b/doc/sphinx/man/props/P_FROG
deleted file mode 100644
index 71badbe..0000000
--- a/doc/sphinx/man/props/P_FROG
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_FROG
-******
-
-
-NAME
-====
-
- P_FROG "frog"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Gesetzt, wenn der Spieler ein Frosch ist.
diff --git a/doc/sphinx/man/props/P_FUEL b/doc/sphinx/man/props/P_FUEL
deleted file mode 100644
index 79f8515..0000000
--- a/doc/sphinx/man/props/P_FUEL
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_FUEL
-******
-
-
-NAME
-====
-
- P_FUEL "fuel"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert fuer die Zeitdauer, die die Lichtquelle noch
- leuchten kann. Standardmaessig ist der Wert auf 20 gesetzt.
-
- Setzt man die Property auf einen Wert, der groesser ist als der vorige
- Maximalwert, wird dieser auf den neuen Wert erhoeht. Aendert man den
- Brennstoffvorrat der Lichtquelle hingegen mittels AddFuel(), so wird
- der Wert von P_FUEL ueber den Maximalwert hinaus erhoeht.
-
-
-HINWEIS
-=======
-
- Fuer Aenderungen an der Property kann auch die Funktion AddFuel()
- verwendet werden.
-
-
-SIEHE AUCH
-==========
-
- Basisklassen: /std/lightsource.c
- Properties: P_LIGHTDESC, P_DO_DESTRUCT, P_LIGHT
- Methoden: AddFuel(L)
-
-
-LETZTE AENDERUNG
-================
-
- 22. Dez. 2015, Arathorn
diff --git a/doc/sphinx/man/props/P_FUNC_MSG b/doc/sphinx/man/props/P_FUNC_MSG
deleted file mode 100644
index adcca1a..0000000
--- a/doc/sphinx/man/props/P_FUNC_MSG
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_FUNC_MSG
-**********
-
-
-NAME
-====
-
- P_FUNC_MSG "func_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- Liste mit Funktionen, die zufaellig im Raum aufgerufen werden.
-
- Hier ist nur eine zur rufende lokale Methode als String oder eine
- Sammlung davon als Stringarray gespeichert.
-
-
-ANMERKUNGEN
-===========
-
- Bitte AddRoomMessage() zum Hinzufuegen/Ueberschreiben benutzen!
-
-
-SIEHE AUCH
-==========
-
- LFuns: AddRoomMessage()
- Verwandt: tell_room(), ReceiveMsg()
- Props: P_ROOM_MSG, P_MSG_PROB
-
-2.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_FW_ALWAYS_READABLE b/doc/sphinx/man/props/P_FW_ALWAYS_READABLE
deleted file mode 100644
index f770431..0000000
--- a/doc/sphinx/man/props/P_FW_ALWAYS_READABLE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_FW_ALWAYS_READABLE
-********************
-
-
-NAME
-====
-
- P_FW_ALWAYS_READABLE "fw_always_readable"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_FW_UNDERSTAND b/doc/sphinx/man/props/P_FW_UNDERSTAND
deleted file mode 100644
index 2884555..0000000
--- a/doc/sphinx/man/props/P_FW_UNDERSTAND
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_FW_UNDERSTAND
-***************
-
-
-NAME
-====
-
- P_FW_UNDERSTAND "fw_understand"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_GENDER b/doc/sphinx/man/props/P_GENDER
deleted file mode 100644
index c2a3f77..0000000
--- a/doc/sphinx/man/props/P_GENDER
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_GENDER
-********
-
-
-NAME
-====
-
- P_GENDER "gender"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/language.h
-
-
-BESCHREIBUNG
-============
-
- Grammatikalisches Geschlecht des Objektes:
- (Definiert in language.h) MALE, FEMALE oder NEUTER
diff --git a/doc/sphinx/man/props/P_GHOST b/doc/sphinx/man/props/P_GHOST
deleted file mode 100644
index 31c9f2d..0000000
--- a/doc/sphinx/man/props/P_GHOST
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_GHOST
-*******
-
-
-NAME
-====
-
- P_GHOST "ghost"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Gesetzt, wenn der Spieler tot ist.
diff --git a/doc/sphinx/man/props/P_GIVE_MSG b/doc/sphinx/man/props/P_GIVE_MSG
deleted file mode 100644
index e21dbad..0000000
--- a/doc/sphinx/man/props/P_GIVE_MSG
+++ /dev/null
@@ -1,83 +0,0 @@
-
-P_GIVE_MSG
-**********
-
-
-NAME
-====
-
- P_GIVE_MSG "give_message"
-
-
-DEFINIERT IN
-============
-
- /sys/living/put_and_get.h
-
-
-BESCHREIBUNG
-============
-
- Mit P_GIVE_MSG kann man die Meldung, die man beim Uebergeben eines
- Objektes bekommt, modifizieren.
-
- Folgende Werte sind moeglich:
-
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
-
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
-
- o Ein Array aus Strings
- Der erste String wird an den Spieler ausgegeben, der zweite
- (optionale) an den Raum, der dritte (ebenfalls optionale) an den
- Empfaenger.
-
- Die Strings werden durch die Funktion replace_personal() geparst.
- Objekt1 - Spieler
- Objekt2 - das Objekt, das uebergeben wird
- Objekt3 - Empfaenger
-
- Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
- Raum. Beim Fehlen des dritten gibt es keine Meldung an den Empfaenger.
-
-
-BEISPIEL
-========
-
- void create() {
- ...
- SetProp( P_SHORT, "Etwas Sand" );
- SetProp( P_LONG, break_string(
- "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
-
- SetProp( P_NAME, "Sand" );
- AddId( ({"sand"}) );
- SetProp( P_GENDER, MALE );
-
- SetProp( P_GIVE_MSG, ({
- "Du laesst @WEN2 in @WESSEN3 Haende rieseln.",
- "@WER1 laesst @WENU2 in @WESSEN3 Haende rieseln.",
- "@WER1 laesst @WENU2 in deine Haende rieseln."}));
- ...
- }
-
- Das ganze fuehrt bei Ugars "gib sand an peter" zu folgenden
- Meldungen:
-
- Ugar: "Du laesst den Sand in Peters Haende rieseln."
- Raum: "Ugar laesst Sand in Peters Haende rieseln."
- Peter: "Ugar laesst Sand in deine Haende rieseln."
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_DROP_MSG, P_PUT_MSG, P_PICK_MSG, P_SHOW_MSG
- Fehler: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
- P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET
- Sonstiges: replace_personal(E), give(L), give_objects(L),
- give_notify(L), /std/living/put_and_get.c
-
-14. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_GLOBAL_SKILLPROPS b/doc/sphinx/man/props/P_GLOBAL_SKILLPROPS
deleted file mode 100644
index 1e3533b..0000000
--- a/doc/sphinx/man/props/P_GLOBAL_SKILLPROPS
+++ /dev/null
@@ -1,46 +0,0 @@
-
-P_GLOBAL_SKILLPROPS
-*******************
-
-
-NAME
-====
-
- P_GLOBAL_SKILLPROPS "sm_global"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Gilden- und Spellbookproperty enthaelt Eigenschaften, die
- alle Spells eines Spellbooks bzw. alle Skills und Spells einer Gilde
- haben sollen.
-
-
-BEISPIELE
-=========
-
- SetProp(P_GLOBAL_SKILLPROPS,
- ([SI_SKILLRESTR_USE: ([SR_FUN: #'spellTest]),
- OFFSET(SI_SKILLLEARN): #'learnOffset,
- OFFSET(SI_SPELLCOST): #'costOffset,
- FACTOR(SI_SPELLCOST): #'costFactor]));
-
-
-SIEHE AUCH
-==========
-
- GObj Verwalten: LearnSkill, LearnSpell, InitialSkillAbility
- * Properties: P_GUILD_SKILLS
- Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
- * Verwalten: AddSpell, QuerySpell
- * Properties: P_SB_SPELLS
- Skills: P_NEWSKILLS, spruchermuedung, skill_info_liste
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/props/P_GUARD b/doc/sphinx/man/props/P_GUARD
deleted file mode 100644
index 7128df6..0000000
--- a/doc/sphinx/man/props/P_GUARD
+++ /dev/null
@@ -1,70 +0,0 @@
-
-P_GUARD
-*******
-
-
-NAME
-====
-
- P_GUARD "guard"
-
-
-DEFINIERT IN
-============
-
- /sys/guard.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property gibt an, ob ein NPC aus einem Raum entfernt werden darf
- oder nicht. Abgefragt werden muss dies von den Items oder Spells, die
- den NPC zu einer Bewegung zwingen wollen. Es wird nicht automatisch
- darauf geachtet!
-
- Entscheidend hierbei ist ein in der Property enthaltene (ganzzahliger)
- Zahlenwert zwischen 0 und 100, der hierbei den Grad der
- 'Bewachungsstaerke' eines NPCs angibt. Bei 0 laesst sich das Lebewesen
- immer zu einer Bewegung ueberreden, bei 100 ueberhaupt nicht. Dazwischen
- gibt es die Wahrscheinlichkeit dafuer an.
-
-
-BEMERKUNGEN
-===========
-
- - alle von /std/npc abgeleiteten NPCs haben standardmaessig P_GUARD
- auf 100 gesetzt, sind also nicht fortfuehrbar
- - bei der Erzeugung von NPCs mit P_GUARD < 100 AddItem() mit dem
- Parameter REFRESH_MOVE_HOME verwenden, damit sie bei einem Raumreset
- gegebenenfalls an ihren Ausgangsort zurueckkehren.
- - gildenspezifische weitere Abfragen auf Level oAe bitte bei Gilden-
- magiern erfragen
-
-
-BEISPIELE
-=========
-
- // ein Test
- if(random(100)<=liv->QueryProp(P_GUARD))
- cannotMoveNPC(); // NPC darf nicht bewegt werden!
- else
- moveNPC(); // NPC darf bewegt werden
-
- // ein wegfuehrbarer NPC
- void create() {
- ::create();
- ...
- SetProp(P_GUARD,50);
- ...
- }
- // mit 50% Wahrscheinlichkeit (pro Versuch) laesst sich der NPC nun
- // fortfuehren
-
-
-SIEHE AUCH
-==========
-
- AddItem()
-
-13.April 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_GUILD b/doc/sphinx/man/props/P_GUILD
deleted file mode 100644
index c3c13cb..0000000
--- a/doc/sphinx/man/props/P_GUILD
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_GUILD
-*******
-
-
-NAME
-====
-
- P_GUILD "guild"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt den Namen der Gilde, welcher das Lebewesen
- angehoert. Der Name der Gilde ist hierbei kleingeschrieben als String
- definiert.
-
-
-BEMERKUNGEN
-===========
-
- Bei Spielern ist der Wert dieser Property niemals Null, denn sie
- gehoeren standardmaessig der in P_DEFAULT_GUILD stehenden Gilde an.
- Ueber die gesetzte P_GUILD werden auch aktive Skills ermittelt.
-
-
-SIEHE AUCH
-==========
-
- P_DEFAULT_GUILD, P_VISIBLE_GUILD
- P_GUILD_TITLE, P_SUBGUILD_TITLE
-
-26. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_GUILD_DEACTIVATE_SKILLS b/doc/sphinx/man/props/P_GUILD_DEACTIVATE_SKILLS
deleted file mode 100644
index a53d6ce..0000000
--- a/doc/sphinx/man/props/P_GUILD_DEACTIVATE_SKILLS
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_GUILD_DEACTIVATE_SKILLS
-*************************
-
-
-PROPERTY
-========
-
- P_GUILD_DEACTIVATE_SKILLS "guild_deactivate_skills"
-
-DEFINIERT IN:
-
- new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property erlaubt es, Gildenmitgliedern die benutzung von ANY-
- Skills zu untersagen. Dies sind einerseits die allgemeinen Waffenskills,
- andererseits koennte das auch der entgifte-Spruch der Duesterwald -
- Quest sein.
-
- Wert dieser Property ist ein Mapping, das als Keys die einzelnen
- Skills und als Wert 1 enthaelt, wenn ein Skill deaktiviert
- werden soll und 0, falls nicht.
-
- Diese Property wird nur bei einem Neuerzeugen des Spielers neu
- ausgelesen, da es sonst zuviel Rechenzeit kostet.
-
-
-BEISPIEL
-========
-
- Jede Gilde, die keine Waffenskills benutzen soll (oder selbst welche hat)
- enthaelt folgenden Befehl:
-
- SetProp(P_GUILD_DEACTIVATE_SKILLS,
- ([FIGHT(WT_SWORD):1,
- FIGHT(WT_AXE):1,
- FIGHT(WT_CLUB):1,
- FIGHT(WT_SPEAR):1,
- FIGHT(WT_KNIFE):1,
- FIGHT(WT_WHIP):1]));
-
-LETZTE AENDERUNG
-
-
-2003-01-30, 1415, Humni
-=======================
diff --git a/doc/sphinx/man/props/P_GUILD_DEFAULT_SPELLBOOK b/doc/sphinx/man/props/P_GUILD_DEFAULT_SPELLBOOK
deleted file mode 100644
index 4d6bbd0..0000000
--- a/doc/sphinx/man/props/P_GUILD_DEFAULT_SPELLBOOK
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_GUILD_DEFAULT_SPELLBOOK
-*************************
-
-
-NAME
-====
-
- P_GUILD_DEFAULT_SPELLBOOK "guild_sb"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Gildenproperty enthaelt den Namen des Spellbooks, welches
- standardmaessig von der Gilde verwendet wird.
-
-
-BEMERKUNGEN
-===========
-
- Bei Spells kann sie mit SI_SPELLBOOK ueberschrieben werden.
-
-
-BEISPIELE
-=========
-
- Bei Zauberern waere folgendes denkbar:
- SetProp(P_GUILD_DEFAULT_SPELLBOOK,"magie_sp");
- Das Spellbook ist hierbei unter "/spellbooks/magie_sp.c" zu finden.
-
-
-SIEHE AUCH
-==========
-
- P_GUILD
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_GUILD_FEMALE_TITLES b/doc/sphinx/man/props/P_GUILD_FEMALE_TITLES
deleted file mode 100644
index c06947d..0000000
--- a/doc/sphinx/man/props/P_GUILD_FEMALE_TITLES
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_GUILD_FEMALE_TITLES
-*********************
-
-
-NAME
-====
-
- P_GUILD_FEMALE_TITLES "guild_female_titles"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Gildenproperty enthaelt die Stufenbezeichnungen fuer
- weibliche Gildenmitglieder. Als Schluessel dienen hierbei die
- Gildenstufen und die entsprechenden Eintraege sind dann die zur
- Stufe gehoerigen Gildentitel.
-
-
-BEISPIELE
-=========
-
- Eine Programmierergilde koennte folgende Stufenbezeichnungen
- beinhalten:
- SetProp(P_GUILD_FEMALE_TITLES,([1:"die Anfaengerin",
- 2:"die Fortgeschrittene",
- 3:"die Professionelle ;)"]));
-
-
-SIEHE AUCH
-==========
-
- P_GENDER, P_GUILD_LEVEL, P_GUILD_TITLE, P_GUILD_MALE_TITLES
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_GUILD_LEVEL b/doc/sphinx/man/props/P_GUILD_LEVEL
deleted file mode 100644
index f38701c..0000000
--- a/doc/sphinx/man/props/P_GUILD_LEVEL
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_GUILD_LEVEL
-*************
-
-
-NAME
-====
-
- P_GUILD_LEVEL "guild_level"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die Gildenstufe des Lebewesens, welche nicht
- unbedingt seiner Spielerstufe entspricht.
-
-
-BEMERKUNGEN
-===========
-
- Bei manchen Gilden entspricht die Gildenstufe standardmaessig der
- Spielerstufe (Abenteurer, Katzenkrieger). In der Property selbst
- wird eigentlich ein Mapping eingetragen, welches die Gildennamen als
- Schluessel und die dazugehoerige Gildenstufe als Eintrag enthaelt.
- Bei der Abfrage der Property wird jedoch die Gilde beruecksichtigt
- und die aktuelle Gildenstufe zurueckgeliefert.
-
-
-SIEHE AUCH
-==========
-
- P_GUILD, P_GUILD_TITLE, P_GUILD_MALE_TITLES, P_GUILD_FEMALE_TITLES
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_GUILD_LEVELS b/doc/sphinx/man/props/P_GUILD_LEVELS
deleted file mode 100644
index 9b9b80d..0000000
--- a/doc/sphinx/man/props/P_GUILD_LEVELS
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_GUILD_LEVELS
-**************
-
-
-NAME
-====
-
- P_GUILD_LEVELS "guild_levels"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Gildenproperty enthaelt ein Mapping mit den
- Stufenbeschraenkungen fuer die jeweiligen Gildenstufen. Als
- Schluessel dient der jeweilige Gildenlevel und die entsprechenden
- Eintraege sind wiederum Mappings, in welchen die Beschraenkungen
- angegeben sind.
-
-
-BEMERKUNGEN
-===========
-
- Die Beschraenkungen fuer Level 1 sollten auch fuer die
- Eintrittsbeschraenkungen der Gilde gelten. Letztere kann man in der
- Property P_GUILD_RESTRICTIONS angeben.
-
-
-BEISPIELE
-=========
-
- Das folgende Beispiel zeigt ein paar moegliche Abfragen:
- string check(object pl);
- SetProp(P_GUILD_LEVELS,([1:([P_LEVEL:3,P_QP:100,SR_FUN:#'check]),
- 2:([A_INT:10,P_LEVEL:25]),
- 3:([A_INT:20,P_LEVEL:50])]));
- string check(object pl)
- { if(pl->QueryProp(P_MALE))
- return 0;
- return "Fuer Frauen ist das nichts!\n";
- }
-
-
-SIEHE AUCH
-==========
-
- P_GUILD_LEVEL, P_GUILD_RESTRICTIONS, /std/restriction_checker.c
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_GUILD_MALE_TITLES b/doc/sphinx/man/props/P_GUILD_MALE_TITLES
deleted file mode 100644
index 41cb773..0000000
--- a/doc/sphinx/man/props/P_GUILD_MALE_TITLES
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_GUILD_MALE_TITLES
-*******************
-
-
-NAME
-====
-
- P_GUILD_MALE_TITLES "guild_male_titles"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Gildenproperty enthaelt die Stufenbezeichnungen fuer
- maennliche Gildenmitglieder. Als Schluessel dienen hierbei die
- Gildenstufen und die entsprechenden Eintraege sind dann die zur
- Stufe gehoerigen Gildentitel.
-
-
-BEISPIELE
-=========
-
- Eine Programmierergilde koennte folgende Stufenbezeichnungen
- beinhalten:
- SetProp(P_GUILD_MALE_TITLES,([1:"der Anfaenger",
- 2:"der Fortgeschrittene",
- 3:"der Profi"]));
-
-
-SIEHE AUCH
-==========
-
- P_GENDER, P_GILD_LEVEL, P_GUILD_TITLE, P_GUILD_FEMALE_TITLES
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_GUILD_PREPAREBLOCK b/doc/sphinx/man/props/P_GUILD_PREPAREBLOCK
deleted file mode 100644
index ee1c361..0000000
--- a/doc/sphinx/man/props/P_GUILD_PREPAREBLOCK
+++ /dev/null
@@ -1,60 +0,0 @@
-
-P_GUILD_PREPAREBLOCK
-********************
-
-
-P_GUILD_PREPAREBLOCK (int)
-==========================
-
-
-NAME
-====
-
- P_GUILD_PREPAREBLOCK "guild_prepareblock"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die Information, ob das Lebewesen in
- der Konzentrationsphase eines Spells weiterkaempft oder ob
- die Angriffe derweil ausgesetzt werden.
-
-
-BEMERKUNGEN
-===========
-
- In der Property selbst wird eigentlich ein Mapping eingetragen,
- welches die Gildennamen als Schluessel und das dazugehoerige
- Block-Flag als Eintrag enthaelt. Bei der Abfrage der Property wird
- jedoch die Gilde beruecksichtigt und das aktuelle Flag
- zurueckgeliefert.
- Dementsprechend das diese Prop nicht mit Set() manipuliert werden,
- bitte ausschliessliche SetProp() verwenden.
-
-
-BEISPIELE
-=========
-
- Die Property sollte natuerlich nur von der Gilde gesetzt werden
- und auch nur bei Gildenmitgliedern
-
- if ( IsGuildMember(pl) )
- pl->SetProp(P_GUILD_PREPAREBLOCK,1);
-
- Resultat: Kein Ausfuehren von Attack(), wenn pl sich auf einen
- Zauberspruch konzentriert.
-
-
-SIEHE AUCH
-==========
-
- P_PREPARED_SPELL
-
-18.03.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_GUILD_RATING b/doc/sphinx/man/props/P_GUILD_RATING
deleted file mode 100644
index af9c24e..0000000
--- a/doc/sphinx/man/props/P_GUILD_RATING
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_GUILD_RATING
-**************
-
-
-NAME
-====
-
- P_GUILD_RATING "guild_rating"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property wird die Einstufung des Spielers innerhalb
- seiner Gilde festgelegt. Der dafuer zu ermittelnde Wert muss in
- einem Bereich von 0 bis 10000 liegen. Wie sich die Einstufung
- zusammensetzt, bleibt der jeweiligen Gilde ueberlassen.
-
-
-BEMERKUNGEN
-===========
-
- Der Wert muss von der Gilde ermittelt werden! Meist setzt er sich
- aus den Faehigkeiten des Mitglieds zusammen und mitunter fliessen
- auch Gildenquests oder aehnliches mit ein.
-
-
-SIEHE AUCH
-==========
-
- P_NEWSKILLS, GuildRating
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_GUILD_RESTRICTIONS b/doc/sphinx/man/props/P_GUILD_RESTRICTIONS
deleted file mode 100644
index c94ccf3..0000000
--- a/doc/sphinx/man/props/P_GUILD_RESTRICTIONS
+++ /dev/null
@@ -1,59 +0,0 @@
-
-P_GUILD_RESTRICTIONS
-********************
-
-
-NAME
-====
-
- P_GUILD_RESTRICTIONS "guild_rest"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Gildenproperty enthaelt ein Mapping mit den
- Eintrittsbeschraenkungen fuer die jeweilige Gilde.
-
-
-BEMERKUNGEN
-===========
-
- Im allgemeinen sollte das Mapping mit den Eintrittsbeschraenkungen
- mit den Beschraenkungen fuer Level 1 im Mapping von P_GUILD_LEVELS
- uebereinstimmen.
-
-
-BEISPIELE
-=========
-
- Ein paar moegliche Abfragen waeren folgende:
- string check(object pl);
-
- SetProp(P_GUILD_RESTRICTIONS,
- ([P_LEVEL:3,
- P_QP:100,
- SR_FUN:#'check]));
-
- string check(object pl) {
- if(pl->QueryProp(P_MALE))
- return 0;
- return "Fuer Frauen ist das nichts!\n";
- }
-
-
-SIEHE AUCH
-==========
-
- Gildenfkt.:
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
- * Sonstiges: P_GUILD_LEVELS
- Sonstiges: /std/restriction_checker.c
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/props/P_GUILD_SKILLS b/doc/sphinx/man/props/P_GUILD_SKILLS
deleted file mode 100644
index 232a5cf..0000000
--- a/doc/sphinx/man/props/P_GUILD_SKILLS
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_GUILD_SKILLS
-**************
-
-
-NAME
-====
-
- P_GUILD_SKILLS "guild_skills"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Gildenproperty enthaelt ein Mapping mit allen Skills und
- Spells der Gilde.
-
-
-BEMERKUNGEN
-===========
-
- Man sollte diese Property sollte nicht per Hand veraendern, sondern
- die Funktionen AddSkill() bzw. AddSpell() nutzen.
-
-
-SIEHE AUCH
-==========
-
- GObj Verwalten: LearnSkill, LearnSpell, InitialSkillAbility
- * Sonstiges: GuildRating
- Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
- * Verwalten: AddSpell, QuerySpell
- * Properties: P_SB_SPELLS, P_GLOBAL_SKILLPROPS, P_GUILD_RATING
- Skills: P_NEWSKILLS, spruchermuedung, skill_info_liste
-
-3. Okt 2011 Gloinson
diff --git a/doc/sphinx/man/props/P_GUILD_TITLE b/doc/sphinx/man/props/P_GUILD_TITLE
deleted file mode 100644
index d3a49b3..0000000
--- a/doc/sphinx/man/props/P_GUILD_TITLE
+++ /dev/null
@@ -1,58 +0,0 @@
-
-P_GUILD_TITLE
-*************
-
-
-NAME
-====
-
- P_GUILD_TITLE "guild_title"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt den Gildentitel des Lebewesens, welcher der
- Gildenstufe des Lebewesens entspricht und jedoch nur angezeigt wird,
- wenn P_TITLE des Lebewesens gleich Null ist.
-
-
-BEMERKUNGEN
-===========
-
- In der Property selbst wird eigentlich ein Mapping eingetragen, welches
- die Gildennamen als Schluessel und die dazugehoerigen Gildentitel als
- Eintrag enthaelt. Bei der Abfrage der Property wird jedoch die Gilde
- beruecksichtigt und der aktuelle Gildentitel zurueckgeliefert.
-
-
-BEISPIELE
-=========
-
- Fuer eine Programmierergilde waere folgendes denkbar:
- SetProp(P_GUILD_MALE_TITLES,([1:"der Anfaenger",
- 2:"der Fortgeschrittene",
- 3:"der Profi"]));
- SetProp(P_GUILD_FEMALE_TITLES,([1:"die Anfaengerin",
- 2:"die Fortgeschrittene",
- 3:"die Professionelle"]));
- Ein weibliches Gildenmitglied mit der dritten Gildenstufe und ohne
- P_TITLE wuerde dann den Titel "die Professionelle" tragen. Das hat
- zwar nichts mit Programmierern zu tun, aber wie heisst eigentlich
- ein weiblicher "Profi"?! :)
-
-
-SIEHE AUCH
-==========
-
- P_TITLE, P_GUILD, P_GUILD_LEVEL,
- P_GUILD_MALE_TITLES, P_GUILD_FEMALE_TITLES,
- P_SUBGUILD_TITLE
-
-26. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_HANDS b/doc/sphinx/man/props/P_HANDS
deleted file mode 100644
index 859b4eb..0000000
--- a/doc/sphinx/man/props/P_HANDS
+++ /dev/null
@@ -1,78 +0,0 @@
-
-P_HANDS
-*******
-
-
-NAME
-====
-
- P_HANDS "hands"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt ein dreielementiges Array mit
- den folgenden Eintraegen:
- 1. Element: String mit der Meldung, wenn ohne Waffen angegriffen
- wird.
- 2. Element: Waffenklasse, wenn ohne Waffen angegriffen wird.
- 3. Element: Array mit Schadensarten (frueher auch: Schadensart)
-
- eim Setzen dieser Property wird auch P_TOTAL_WC mit veraendert,
- wenn das Lebewesen keine Waffe gezueckt hat. Steckt das Lebewesen
- eine gezueckte Waffe weg, so wird ebenfalls P_TOTAL_WC mit der
- Waffenklasse aus P_HANDS aktualisiert. Zueckt das Lebewesen eine
- Waffe, so wird P_TOTAL_WC mit der Waffenklasse der Waffe (P_WC)
- ueberschrieben. Die Property P_TOTAL_WC enthaelt somit immer die
- aktuelle Angriffsstaerke des Lebewesen.
-
-
-BEMERKUNGEN
-===========
-
- In alten Objekten kann es vorkommen, dass das dritte Element (Angabe des
- Schadenstyps) fehlt. Dies ist eine Altlast, die Angabe des Schadenstypes
- ist NICHT optional.)
-
-
-BEISPIEL
-========
-
- Ein starker Tausendfuessler mit Schlagschaden:
-
- SetProp(P_HANDS,({" mit tausend kleinen Fuesschen",1000,
- ({DT_BLUDGEON}) }));
-
-
- Ein Saeurededaemon:
- SetProp(P_HANDS,
- ({
- " mit saeuretriefenden Klauen",
- 250,
- ({DT_RIP, DT_ACID})
- })
- );
-
- Hier wurden gleich zwei Schadensarten angegeben, also wird
- Mischschaden verursacht. Man sollte es jedoch nicht zu sehr
- uebertreiben! Mehr als zwei oder drei gleichzeitig verwendete
- Schadensarten lassen sich kaum mehr begruenden.
-
-
-SIEHE AUCH
-==========
-
- P_HANDS_USED_BY
- P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
- UseHands, FreeHands
- P_TOTAL_WC, P_WC
- /std/living/combat.c, /std/weapon/combat.c, /sys/combat.h
-
-22.02.2014 Zesstra
diff --git a/doc/sphinx/man/props/P_HANDS_USED_BY b/doc/sphinx/man/props/P_HANDS_USED_BY
deleted file mode 100644
index f0d5165..0000000
--- a/doc/sphinx/man/props/P_HANDS_USED_BY
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_HANDS_USED_BY
-***************
-
-
-NAME
-====
-
- P_HANDS_USED_BY "hands_used_by"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt eine Liste mit den Objekten, die derzeit die Haende
- des Livings belegen. Dabei koennen Objekte mehrmals auftauchen,
- je nachdem wie viele Haende sie belegen.
-
-
-BEMERKUNGEN
-===========
-
- Darf nur ueber UseHands() und FreeHands() manipuliert werden.
-
-
-SIEHE AUCH
-==========
-
- P_HANDS
- P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
- UseHands, FreeHands
-
-1.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/props/P_HARBOUR b/doc/sphinx/man/props/P_HARBOUR
deleted file mode 100644
index f049847..0000000
--- a/doc/sphinx/man/props/P_HARBOUR
+++ /dev/null
@@ -1,94 +0,0 @@
-
-P_HARBOUR
-*********
-
-
-NAME
-====
-
- P_HARBOUR "harbour_name"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Array mit eindeutiger Bezeichnung des 'Hafens'
-
-
-BEMERKUNGEN
-===========
-
- Diese Property wird in Raeumen gesetzt, die als Anleger fuer Transporter
- dienen sollen. Sie enthaelt ein Array aus zwei Elementen, einem String
- und einem String-Array, zum Beispiel:
-
- ({ "zur Sonneninsel", ({"sonneninsel"}) }) oder
- ({ "nach Titiwu", ({"titiwu"}) })
-
- Damit bekommt der Spieler bei einer Abfrage seiner Reiseroute mittels
- "reise route" eine Ausgabe wie
- 'Du reist mit dem Floss nach Titiwu' oder
- 'Du reist mit dem Wal zur Sonneninsel'.
-
- Das zweite Element der Property enthaelt eine Liste der IDs, mit denen
- sich der Hafen mit dem Befehl "reise nach <ID>" ansprechen laesst. Im
- Beispiel oben wuerde also "reise nach sonneninsel" und
- "reise nach titiwu" akzeptiert werden. Der erste Eintrag in dieser ID-
- Liste wird in der Ausgabe des Befehls "reise route" verwendet, sollte
- also den Anlegeort korrekt bezeichnen und nicht z.B. eine Abkuerzung
- enthalten.
- Es bietet sich an, bei bestimmten, deklinierbaren Bezeichnungen alle
- Varianten einzutragen, z.B. "verlorenes land" und zusaetzlich
- "verlorene land" und "verlorenen land", damit alle Varianten von
- "reise nach ..." funktionieren.
-
- Ist in einem Hafen diese Property nicht gesetzt, so bekommt der
- Spieler keinerlei Hinweis darauf, wohin ihn ein bestimmter Trans-
- porter befoerdert.
- Stattdessen erhaelt er die Bezeichnung 'unbekannt'.
-
-
-HINWEISE
-========
-
- Wird der zweite Parameter in dieser Property, d.h. die Liste der
- Anleger-IDs, nicht korrekt gesetzt, kann das dazu fuehren, dass Spieler
- den hier anlegenden Transporter nicht benutzen koennen, weil es
- keine sinnvolle Syntax gibt, um den gewuenschten Zielhafen zu finden.
-
- Zu achten ist auch darauf, das der erste Eintrag unveraendert in einer
- Meldung an den Spieler ausgegeben wird, d.h. Gross-und Kleinschreibung
- sollte korrekt sein.
-
-
-HISTORIE
-========
-
- Frueher war der zweite Eintrag in dieser Property ein einzelner String.
- Es existiert eine SetMethode auf dieser Property, die solche Daten in
- altem Code auf die neue Datenstruktur umbiegt. Dies fuehrt dazu, dass
- bei solchen Objekten die im geladenen Raum enthaltenen Daten nicht mit
- den Daten im File uebereinstimmen. Dies moege aber bitte niemand
- zum Anlass nehmen, in neuem Code veraltete Daten in die Property zu
- schreiben!
-
-
-SIEHE AUCH
-==========
-
- Properties: P_NO_TRAVELING, P_TRAVEL_INFO
- Funktionen: AddRoute(L)
- Spielerbefehle: reise
- weitere Doku: /d/inseln/schiffe/HowTo
-
-
-LETZTE AENDERUNG
-================
-
-2015-Jan-18, Arathorn
diff --git a/doc/sphinx/man/props/P_HAUS_ERLAUBT b/doc/sphinx/man/props/P_HAUS_ERLAUBT
deleted file mode 100644
index ffd5c8f..0000000
--- a/doc/sphinx/man/props/P_HAUS_ERLAUBT
+++ /dev/null
@@ -1,46 +0,0 @@
-
-P_HAUS_ERLAUBT
-**************
-
-
-NAME
-====
-
- P_HAUS_ERLAUBT "haus_erlaubt"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- Hier darf ein Seherhaus abgestellt werden
-
-
-BEMERKUNGEN
-===========
-
- Diese Property sollte nicht per default in Raeumen auf einen Wert > 0
- gesetzt werden um einem Wildwuchs an Seherhaus(-ruinen) vorzubeugen.
- Auch sei darauf geachtet, dass in Raeumen die P_INDOORS auf einen
- Wert > 0 haben, per default nicht gebaut werden kann.
- Hier lieber die Property per Hand auf 1 setzen und nach dem Aufstellen
- des Hauses wieder loeschen.
-
-
-
- xcall $h->SetProp(P_HAUS_ERLAUBT,1);
-
- Angemerkt sei noch, dass der Magier dem der Raum gehoert ueber Hausbau
- entscheidet und nicht der Regionsmagier. In jedem Fall Ruecksprache
- halten falls der entsprechende Magier zumindest ab und an anwesend sein
- sollte.
-
- Unter /doc/beispiele/misc liegt ein File, in dem dokumentiert ist,
- wie nach Aenderungen am Seherhaus zu verfahren ist.
-
-Last modified: Fri Nov 26 15:41:47 1999 by Tilly
diff --git a/doc/sphinx/man/props/P_HB b/doc/sphinx/man/props/P_HB
deleted file mode 100644
index bdaf9f1..0000000
--- a/doc/sphinx/man/props/P_HB
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_HB
-****
-
-
-NAME
-====
-
- P_HB "hb"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property wird gesetzt, wenn das Monster immer einen
- heart_beat haben soll. (VORSICHT, nur wenn es WIRKLICH sein muss!)
diff --git a/doc/sphinx/man/props/P_HEAL b/doc/sphinx/man/props/P_HEAL
deleted file mode 100644
index 83d4991..0000000
--- a/doc/sphinx/man/props/P_HEAL
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_HEAL
-******
-
-
-NAME
-====
-
- P_HEAL "heal"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert, der beim Verzehr einer Leiche zu den Lebenspunkten
- desjenigen hinzugezaehlt wird, der die Leiche isst. Der Wert kann auch
- negativ sein. Falls die Leiche den maximalen Verfallszustand erreicht
- hat, wird dieser Wert automatisch auf -4 gesetzt, sofern nicht schon
- ein geringerer Wert eingetragen ist.
-
- Werte unter -4 sind sehr sparsam und nur in begruendeten Einzelfaellen
- zu setzen. Die Regionsmagier werden auf sinnvolle Wertebereiche in
- ihrem Zustaendigkeitsbereich achten und ggf. Grenzwerte fuer ihre
- Region festlegen.
-
- Die Gilden koennen P_HEAL abfragen und eigene, grobe Informationstexte
- ausgeben, die den Spieler ueber den zu erwartenden Effekt beim Essen
- einer Leiche informieren.
-
- Positive Werte von P_HEAL sind bei der Heilungsbalance als Heilstelle
- zu beantragen.
-
- Fuer nicht allzu harte NPCs sollte P_HEAL auf 0 gesetzt sein. Dieser
- Wert ist gleichzeitig der Standardwert.
-
-
-SIEHE AUCH
-==========
-
- /std/corpse, QueryHealInfo()
-
-31.03.2008 Arathorn
diff --git a/doc/sphinx/man/props/P_HELPER_NPC b/doc/sphinx/man/props/P_HELPER_NPC
deleted file mode 100644
index af8bfef..0000000
--- a/doc/sphinx/man/props/P_HELPER_NPC
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_HELPER_NPC
-************
-
-
-NAME
-====
-
- P_HELPER_NPC "std:helper_npc
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Prop laesst sich herausfinden, ob ein NPC einem Spieler hilft
- bzw. welche NPC einem Spieler helfen.
- Wird diese Prop in einem NPC abgefragt, enthaelt sie ein Array
- ({ spielerobjekt, flags }) oder 0.
- Wird diese Prop in einem Spieler abgefragt, enthaelt sie ein Mapping
- ([npcobjekt1: flags1, npc-objekt2: flags2]).
-
- <flags> ist ein Integer, der eine Reihe von ver-oder-ten Konstanten (s.
- RegisterHelperNPC) enthalten kann.
-
-
-BEMERKUNGEN
-===========
-
- Diese Prop wird automatisch von RegisterHelperNPC() und
- UnregisterHelperNPC() verwaltet. Bitte aendert sie nicht per Hand.
-
-
-BEISPIEL
-========
-
- s. RegisterHelperNPC().
-
-
-SIEHE AUCH
-==========
-
- RegisterHelperNPC(), UnregisterHelperNPC()
-
-10.03.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_HELPER_OBJECTS b/doc/sphinx/man/props/P_HELPER_OBJECTS
deleted file mode 100644
index 94990c4..0000000
--- a/doc/sphinx/man/props/P_HELPER_OBJECTS
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_HELPER_OBJECTS
-****************
-
-
-NAME
-====
-
- P_HELPER_OBJECTS "lib_p_helper_objects"
-
-
-DEFINIERT IN
-============
-
- <living/helpers.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt eine Liste von Hilfsobjekten, die das Lebewesen,
- in dem sie gesetzt ist, bei bestimmten Aktivitaeten wie Tauchen oder
- Fliegen/Segeln unterstuetzt. Die Property enthaelt ein Mapping der Form
- ([ HELPER_TYPE : ({ Callback-Closures }) ]).
-
-
-BEMERKUNGEN
-===========
-
- Externe Manipulationen an dieser Property bitte unterlassen, zum Ein-
- und Austragen von Objekten gibt es die unten aufgefuehrten Methoden.
-
-
-SIEHE AUCH
-==========
-
- Methoden: RegisterHelperObject(L), UnregisterHelperObject(L)
- Properties: P_AERIAL_HELPERS, P_AQUATIC_HELPERS
-
-18.02.2013, Arathorn
diff --git a/doc/sphinx/man/props/P_HIDE_EXITS b/doc/sphinx/man/props/P_HIDE_EXITS
deleted file mode 100644
index c9aa2e5..0000000
--- a/doc/sphinx/man/props/P_HIDE_EXITS
+++ /dev/null
@@ -1,53 +0,0 @@
-
-P_HIDE_EXITS
-************
-
-
-NAME
-====
-
- P_HIDE_EXITS "hide_exits"
-
-
-DEFINIERT IN
-============
-
- /sys/room/exits.h
-
-
-BESCHREIBUNG
-============
-
- Ist diese Property in einem Raum auf einen Integerwert ungleich 0
- gesetzt, werden einem Spieler fuer diesen Raum keine Ausgaenge angezeigt.
- Auch der Text "Keine sichtbaren Ausgaenge." (oder so) kommt nicht.
- Alternativ kann man auch ein array von strings uebergeben. In diesem
- Fall werden all die Ausgaenge nicht angezeigt, deren Index in P_EXITS
- in dem array vorkommt.
- In diesem Fall wird ggf. der Text "Keine sichtbaren Ausgaenge."
- ausgegeben.
-
-
-BEISPIEL
-========
-
- AddExit("raus", "/ganz/wo/anders");
- AddExit("weiter", "/in/der/naehe");
-
- // KEINE Ausgaenge anzeigen. Noch nicht mal, dass man keine sieht.
- SetProp(P_HIDE_EXITS, 1);
-
- // Der Ausgang weiter wird nicht angezeigt.
- SetProp(P_HIDE_EXITS, ({"weiter"}) );
-
- // Keinen Ausgang zeigen, aber den Text, dass keiner sichtbar, ausgeben.
- SetProp(P_HIDE_EXITS, ({"weiter", "raus"}) );
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_SHOW_EXITS
- Sonstiges: AddExit(), GetExits(), int_long(), int_short()
-
-25. Apr 1996 Highlander
diff --git a/doc/sphinx/man/props/P_HISTMIN b/doc/sphinx/man/props/P_HISTMIN
deleted file mode 100644
index ca35504..0000000
--- a/doc/sphinx/man/props/P_HISTMIN
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_HISTMIN
-*********
-
-
-NAME
-====
-
- P_HISTMIN "histmin"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Minimale Laenge, die eine Zeile haben muss, um in die History zu kommen
diff --git a/doc/sphinx/man/props/P_HIT_FUNC b/doc/sphinx/man/props/P_HIT_FUNC
deleted file mode 100644
index 9bcc328..0000000
--- a/doc/sphinx/man/props/P_HIT_FUNC
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_HIT_FUNC
-**********
-
-
-NAME
-====
-
- P_HIT_FUNC "hit_func"
-
-
-DEFINIERT IN
-============
-
- <weapon.h>
-
-
-BESCHREIBUNG
-============
-
- Falls ein Objekt eine HitFunc() fuer die Waffe definiert, so muss
- dieses Objekt in dieser Property eingetragen werden.
-
- Die Auswertung dieser Property erfolgt in QueryDamage().
-
-
-BEISPIELE
-=========
-
- Siehe das Beispiel zu HitFunc()
-
-
-SIEHE AUCH
-==========
-
- /std/weapon.c, HitFunc()
-
-Last modified: Sun May 19 15:37:35 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_HOMEPAGE b/doc/sphinx/man/props/P_HOMEPAGE
deleted file mode 100644
index 5cf6bec..0000000
--- a/doc/sphinx/man/props/P_HOMEPAGE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_HOMEPAGE
-**********
-
-
-NAME
-====
-
- P_HOMEPAGE "homepage"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Die Homepage eines Spielers (mit dem Befehl 'url' zu setzen).
diff --git a/doc/sphinx/man/props/P_HP b/doc/sphinx/man/props/P_HP
deleted file mode 100644
index b7ded4a..0000000
--- a/doc/sphinx/man/props/P_HP
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_HP
-****
-
-
-NAME
-====
-
- P_HP "hp"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- - Lebewesen
- Anzahl der Lebenspunkte des Wesens.
-
- - Speisen/Kneipen
- Heilwirkung einer Portion der Speise auf die Lebenspunkte
- des Konsumenten
-
-
-SIEHE AUCH
-==========
-
- Props: P_MAX_HP
- Veraenderung: reduce_hit_points(), restore_hit_points()
- do_damage(L), Defend(L)
- buffer_hp()
- Ueberwachung: AddHpHook(L)
- Speisen/Kneipen: std/pub, wiz/food, consume
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_HP_DELAY b/doc/sphinx/man/props/P_HP_DELAY
deleted file mode 100644
index f15f748..0000000
--- a/doc/sphinx/man/props/P_HP_DELAY
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_HP_DELAY
-**********
-
-
-NAME
-====
-
- P_HP_DELAY "hp_delay"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der heart_beats, bis P_HP um einen Punkt regeneriert.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
diff --git a/doc/sphinx/man/props/P_HP_HOOKS b/doc/sphinx/man/props/P_HP_HOOKS
deleted file mode 100644
index 7bb48bf..0000000
--- a/doc/sphinx/man/props/P_HP_HOOKS
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_HP_HOOKS
-**********
-
-
-NAME
-====
-
- P_HP_HOOKS "hp_hooks"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Welche Objekte sollen bei HP-Aenderungen benachrichtigt werden?
- Diese Property bitte NICHT manipulieren! Zum Ein- und Austragen stehen
- hierfuer AddHpHook() und RemoveHpHook() bereit.
-
-
-BEMERKUNGEN
-===========
-
- Das neuere Hooksystem (s. Manpage std/hooks) stellt ebenfalls Hooks zur
- Ueberwachung von P_HP bereit.
-
-
-SIEHE AUCH
-==========
-
- AddHpHook(), RemoveHpHook(),
- NotifyHpChange()
- std/hooks
diff --git a/doc/sphinx/man/props/P_HUNTTIME b/doc/sphinx/man/props/P_HUNTTIME
deleted file mode 100644
index e712a49..0000000
--- a/doc/sphinx/man/props/P_HUNTTIME
+++ /dev/null
@@ -1,59 +0,0 @@
-
-P_HUNTTIME
-**********
-
-
-P_HUNTTIME (int)
-================
-
-
-NAME
-====
-
- P_HUNTTIME "p_lib_hunttime"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Property laesst sich festlegen, wie lange ein Monster einen
- Gegner verfolgt (also automatisch angreift), nachdem dieser geflohen ist.
- Die Angabe erfolgt in Sekunden.
- Die Standardzeit ist 600s (300 Heartbeats).
-
-
-BEMERKUNGEN
-===========
-
- 1. Wenn der Standardwert akzeptabel ist, bitte die Prop auch nicht setzen.
- 2. Enthaelt die Property keinen Integer oder ist sie <= 0, wird sie
- ignoriert und der Standardwert von 600s verwendet.
- 3. Kaempft man mit einem Lebenwesen mit einem groesseren Wert als man
- selber und man selber hat das Verfolgen eingestellt, der Gegner aber
- nicht, wird dieser beim Reinkommen den Kampf neu starten (und den
- ersten Schlag haben).
-
-
-BEISPIEL
-========
-
- Ein NPC soll sich erst eine Stunde nach Flucht des Gegners beruhigen.
- protected void create() {
- ...
- SetProp(P_HUNTTIME, 3600);
- }
-
-
-SIEHE AUCH
-==========
-
- InsertSingleEnemy, InsertEnemy
- /std/living/combat.c
-
-13.03.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_IDS b/doc/sphinx/man/props/P_IDS
deleted file mode 100644
index dee9a74..0000000
--- a/doc/sphinx/man/props/P_IDS
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_IDS
-*****
-
-
-NAME
-====
-
- P_IDS "ids"
-
-
-DEFINIERT IN
-============
-
- <thing/description.h>
-
-
-BESCHREIBUNG
-============
-
- In dieser Property steht ein Array von den Strings, mit denen sich das
- Objekt ansprechen laesst. Die Verwaltung dieser Property erfolgt ueber
- die Funktionen AddId() und RemoveId().
-
- Der Inhalt dieser Property wird von den Funktionen id() und (indirekt)
- present() ausgewertet.
-
-
-BEMERKUNGEN
-===========
-
- Man sollte an dieser Property nicht "von Hand" herumfummeln, sondern
- immer die zugehoerigen Funktionen benutzen!
-
-
-SIEHE AUCH
-==========
-
- /std/thing/description.c, AddId(), RemoveId()
-
-Last modified: Sun May 19 20:17:36 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_IGNORE b/doc/sphinx/man/props/P_IGNORE
deleted file mode 100644
index 3436a09..0000000
--- a/doc/sphinx/man/props/P_IGNORE
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_IGNORE
-********
-
-
-NAME
-====
-
- P_IGNORE "ignore"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Array mit Spielern, Kommandos, Aktionen u.ae. die ignoriert werden.
- In aller Regel sollte die Ignorierepruefung durch Aufruf von TestIgnore()
- im Spieler erfolgen und nicht selber P_IGNORE durchsucht werden.
-
-
-BEMERKUNGEN
-===========
-
- Die Daten in dieser Property werden intern als Mapping gespeichert, nicht
- als Array von Strings. Bitte nicht mit Set/Query() an dieser Property
- herumbasteln.
-
-
-SIEHE AUCH
-==========
-
- TestIgnore, /std/player/comm.c
-
-Last modified: 02.10.2011, Zesstra
diff --git a/doc/sphinx/man/props/P_INDOORS b/doc/sphinx/man/props/P_INDOORS
deleted file mode 100644
index 4483d10..0000000
--- a/doc/sphinx/man/props/P_INDOORS
+++ /dev/null
@@ -1,52 +0,0 @@
-
-P_INDOORS
-*********
-
-
-NAME
-====
-
- P_INDOORS "indoors"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- Gesetzt, wenn von dem Raum aus der Himmel nicht sichtbar ist.
-
- Objekte oder Gilden werten diese Property teilweise aus, fuer
- Innenraeume sollte sie also sinnvollerweise gesetzt werden.
-
- Licht wird _nicht_ durch P_INDOORS beeinflusst, muss also
- selbst angepasst werden.
-
-
-BEISPIEL
-========
-
- // Ein dunkler Innenraum:
- SetProp(P_INDOORS, 1); // ein Innenraum liegt innen :)
- SetProp(P_LIGHT, 0); // Licht auf 0
-
- // Ein richtig heller Aussenraum:
- SetProp(P_INDOORS, 0);
- SetProp(P_LIGHT, 2);
-
- // Ein heller Aussenraum mit Mondlicht (gut fuer Delfen)
- SetProp(P_INDOORS, 0);
- SetProp(P_LIGHT, 1);
- SetProp(P_LIGHT_TYPE, LT_STARS|LT_MOON);
-
-
-SIEHE AUCH
-==========
-
- P_LIGHT, P_LIGHT_ABSORPTION, P_LIGHT_TYPE
-
-25.Aug 2008 Gloinson
diff --git a/doc/sphinx/man/props/P_INFO b/doc/sphinx/man/props/P_INFO
deleted file mode 100644
index f29c242..0000000
--- a/doc/sphinx/man/props/P_INFO
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_INFO
-******
-
-
-NAME
-====
-
- P_INFO "info"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Geheime Information, die ggf. ueber einen Zauberspruch
- von Spielern ermittelt werden kann.
-
-
-BEISPIEL
-========
-
- SetProp(P_INFO,"Du ergruendest das Geheimnis.\n")
-
-
-SIEHE AUCH
-==========
-
- GetOwner(L)
-
-24. April 2006, Vanion
diff --git a/doc/sphinx/man/props/P_INFORMME b/doc/sphinx/man/props/P_INFORMME
deleted file mode 100644
index c6dd0ed..0000000
--- a/doc/sphinx/man/props/P_INFORMME
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_INFORMME
-**********
-
-
-NAME
-====
-
- P_INFORMME "informme"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt das Flag, ob der Spieler ueber ein-/ausloggende Spieler
- informiert werden will.
-
-
-SIEHE AUCH
-==========
-
- Spielerkommando: inform
-
-6.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_INPC_HOME b/doc/sphinx/man/props/P_INPC_HOME
deleted file mode 100644
index 1eafd4d..0000000
--- a/doc/sphinx/man/props/P_INPC_HOME
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_INPC_HOME
-***********
-
-
-NAME
-====
-
- P_INPC_HOME "inpc_home"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/walking.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_INPC_LAST_ENVIRONMENT b/doc/sphinx/man/props/P_INPC_LAST_ENVIRONMENT
deleted file mode 100644
index 8f7cb68..0000000
--- a/doc/sphinx/man/props/P_INPC_LAST_ENVIRONMENT
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_INPC_LAST_ENVIRONMENT
-***********************
-
-
-NAME
-====
-
- P_INPC_LAST_ENVIRONMENT "inpc_last_environment"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/walking.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_INPC_LAST_PLAYER_CONTACT b/doc/sphinx/man/props/P_INPC_LAST_PLAYER_CONTACT
deleted file mode 100644
index 14f8730..0000000
--- a/doc/sphinx/man/props/P_INPC_LAST_PLAYER_CONTACT
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_INPC_LAST_PLAYER_CONTACT
-**************************
-
-
-NAME
-====
-
- P_INPC_LAST_PLAYER_CONTACT "inpc_last_player_contact"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/walking.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_INPC_WALK_AREA b/doc/sphinx/man/props/P_INPC_WALK_AREA
deleted file mode 100644
index 9554d27..0000000
--- a/doc/sphinx/man/props/P_INPC_WALK_AREA
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_INPC_WALK_AREA
-****************
-
-
-NAME
-====
-
- P_INPC_WALK_AREA "inpc_walk_area"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/walking.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_INPC_WALK_DELAYS b/doc/sphinx/man/props/P_INPC_WALK_DELAYS
deleted file mode 100644
index e59deea..0000000
--- a/doc/sphinx/man/props/P_INPC_WALK_DELAYS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_INPC_WALK_DELAYS
-******************
-
-
-NAME
-====
-
- P_INPC_WALK_DELAYS "inpc_walk_delay"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/walking.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_INPC_WALK_FLAGS b/doc/sphinx/man/props/P_INPC_WALK_FLAGS
deleted file mode 100644
index 86c4835..0000000
--- a/doc/sphinx/man/props/P_INPC_WALK_FLAGS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_INPC_WALK_FLAGS
-*****************
-
-
-NAME
-====
-
- P_INPC_WALK_FLAGS "inpc_walk_flags"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/walking.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_INPC_WALK_MODE b/doc/sphinx/man/props/P_INPC_WALK_MODE
deleted file mode 100644
index 134bb50..0000000
--- a/doc/sphinx/man/props/P_INPC_WALK_MODE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_INPC_WALK_MODE
-****************
-
-
-NAME
-====
-
- P_INPC_WALK_MODE "inpc_walk_mode"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/walking.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_INPC_WALK_ROUTE b/doc/sphinx/man/props/P_INPC_WALK_ROUTE
deleted file mode 100644
index 762408d..0000000
--- a/doc/sphinx/man/props/P_INPC_WALK_ROUTE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_INPC_WALK_ROUTE
-*****************
-
-
-NAME
-====
-
- P_INPC_WALK_ROUTE "inpc_walk_route"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/walking.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_INTERMUD b/doc/sphinx/man/props/P_INTERMUD
deleted file mode 100644
index 8019998..0000000
--- a/doc/sphinx/man/props/P_INTERMUD
+++ /dev/null
@@ -1,25 +0,0 @@
-
-P_INTERMUD
-**********
-
-
-NAME
-====
-
- P_INTERMUD "intermud"
-
-
-DEFINIERT IN
-============
-
- /sys/player/comm.h
-
-
-BESCHREIBUNG
-============
-
- Die Bedeutung dieser Property ist in den praehistorischen Untiefen
- der Mudlib verlorengegangen.
- Wird nicht mehr benutzt.
- Nicht benutzen.
- Ignorieren.
diff --git a/doc/sphinx/man/props/P_INTERNAL_EXTRA_LOOK b/doc/sphinx/man/props/P_INTERNAL_EXTRA_LOOK
deleted file mode 100644
index ffa78ad..0000000
--- a/doc/sphinx/man/props/P_INTERNAL_EXTRA_LOOK
+++ /dev/null
@@ -1,57 +0,0 @@
-
-P_INTERNAL_EXTRA_LOOK
-*********************
-
-
-NAME
-====
-
- P_INTERNAL_EXTRA_LOOK "internal_extralook"
-
-
-DEFINIERT IN
-============
-
- /sys/living/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt ein Mapping, in dem alle einzelnen
- Extra-Look-Eintraege des Livings enthalten sind. Dabei weden die Daten von
- AddExtraLook() und RemoveExtraLook() verwaltet. Fragt man diese Prop mit
- QueryProp() ab, erhaelt man die Ausgabe der gueltigen Extralooks des
- Livings. Bei Abfrage per Query() erhaelt man ein Mapping mit allen
- Eintraegen und deren Daten. Jeder Wert im Mapping ist erneut ein Mapping,
- welches folgende Keys enthalten kann:
- - "xllook": String, der im Extralook des Living angezeigt wird.
- - "xlduration": Zeitstempel (int), der angibt, wie lang der Eintrag gueltig
- ist. 0 == "Unendlich", negative Zahlen besagen, dass der
- Eintrag nur bis Reboot/Ende gueltig sein und abs(xlduration)
- ist der Zeitpunkt des Eintrages dieses Extralooks.
- - "xlende": String, der nach Ablaufen an das Living ausgegeben wird.
- - "xlfun": Funktion, die gerufen wird und den String zurueckliefern muss,
- der ausgeben werden soll.
- - "xlendefun": Funktion, die gerufen wird, wenn der Eintrag abgelaufen ist
- und den String zurueckliefern muss, der dann ans Living
- ausgeben wird.
- - "xlobjectname": Objekt, in dem die o.a. Funktionen gerufen werden.
-
-
-BEMERKUNG
-=========
-
- DIESE PROPERTY BITTE NIEMALS PER HAND MIT Set()/SetProp() AENDERN!
- Die Daten in dieser Prop werden vom Living selber verwaltet. Extralooks
- koennen mittel AddExtraLook() eingetragen und mit RemoveExtraLook() entfernt
- werden.
-
-
-SIEHE AUCH
-==========
-
- long(), /std/living/description.c, /std/player/base.c
- AddExtraLook(), RemoveExtraLook()
-
-13.05.2007, Zesstra
diff --git a/doc/sphinx/man/props/P_INT_LIGHT b/doc/sphinx/man/props/P_INT_LIGHT
deleted file mode 100644
index dcf59b6..0000000
--- a/doc/sphinx/man/props/P_INT_LIGHT
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_INT_LIGHT
-***********
-
-
-NAME
-====
-
- P_INT_LIGHT "int_light"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Gibt den Lichtlevel an, der _in_ einem Objekt ist. Ein Abfragen dieser
- Property kann z.B. in Raeumen sinnvoll sein, wenn es z.B. um das
- aufwachen einer Eule oder einer Fledermaus geht. Zum Abfragen ob ein
- Spieler etwas sehen kann, bitte auf jeden Fall P_PLAYER_LIGHT benutzen!
-
- Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
- da das Lichtlevel ggf. neu berechnet werden muss!
-
- Ein direktes setzen dieser Property ist NICHT moeglich, hierzu bitte
- P_LIGHT benutzen!
-
-
-SIEHE AUCH
-==========
-
- P_LIGHT, P_TOTAL_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
diff --git a/doc/sphinx/man/props/P_INT_LONG b/doc/sphinx/man/props/P_INT_LONG
deleted file mode 100644
index 741e511..0000000
--- a/doc/sphinx/man/props/P_INT_LONG
+++ /dev/null
@@ -1,53 +0,0 @@
-
-P_INT_LONG
-**********
-
-
-NAME
-====
-
- P_INT_LONG "int_long"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt Beschreibung, die man bekommt, wenn man sich in dem
- Container (jeder Raum ist einer) umschaut als String.
-
- Der Text sollte bereits umgebrochen sein.
-
- Diese Property bestimmt die Ansicht des Containers von innen.
- Fuer die Aussen(lang)ansicht muss P_LONG benutzt werden.
-
-
-BEMERKUNGEN
-===========
-
- - Beschreibungen fuer etwaige Tueren im Raum werden in int_long()
- hinzugefuegt. (Frueher wurde dies in einer Querymethode auf diese Prop
- gemacht.)
-
-
-BEISPIELE
-=========
-
- SetProp(P_INT_LONG, break_string(
- "Du stehst in einem total spannenden Testraum. Seine absolute "
- "Nichtigkeit erfuellt dich mit ehrfuerchtigem Grauen.",78));
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_INT_SHORT
- Sonstiges: int_long(), P_LONG
- process_string(), break_string()
-
-04.06.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_INT_SHORT b/doc/sphinx/man/props/P_INT_SHORT
deleted file mode 100644
index 618bbab..0000000
--- a/doc/sphinx/man/props/P_INT_SHORT
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_INT_SHORT
-***********
-
-
-NAME
-====
-
- P_INT_SHORT "int_short"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die Innen-Kurzbeschreibung des Containers
- als String oder Closure (mit String-Rueckgabewert).
-
- Container sind hierbei z.B. Raeume.
- ACHTUNG: Die Kurzbeschreibung sollte dabei weder mit einem
- Satzzeichen noch mit einem "\n" abgeschlossen sein
- (dies wird von den zustaendigen Funktionen erledigt).
-
- Man sollte die Property nicht auf 0 setzen.
-
- Diese Property bestimmt die Ansicht des Containers von innen.
- Fuer die Aussen(kurz)ansicht muss P_SHORT benutzt werden.
-
-
-BEMERKUNGEN
-===========
-
- - int_short() (bei Bewegung) filtert P_INT_SHORT durch process_string()
- -> daher sind Closures moeglich
-
-
-BEISPIELE
-=========
-
- // ein Gang sieht natuerlich so aus
- SetProp(P_INT_SHORT, "Ein Gang");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_INT_LONG
- Sonstiges: int_short(), P_SHORT
- process_string(), break_string()
-
-Last modified: Thu May 31 15:34:05 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_INVIS b/doc/sphinx/man/props/P_INVIS
deleted file mode 100644
index 4063546..0000000
--- a/doc/sphinx/man/props/P_INVIS
+++ /dev/null
@@ -1,65 +0,0 @@
-
-P_INVIS
-*******
-
-
-NAME
-====
-
- P_INVIS "invis"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Die Property P_INVIS dient dazu, Objekte als unsichtbar zu kennzeichnen.
- Hierbei versucht P_INVIS die moeglichen Interaktionen mit Spielern zu
- minimieren (im Gegensatz zu einer fehlenden P_SHORT, welche das Objekt
- nur einfach nicht-sichtbar macht).
-
-
-
- Man sollte drei Arten von unsichtbaren Objekten unterscheiden:
-
- - Gegenstaende
- Setzt man P_INVIS auf eine Zahl ungleich 0, wird der Gegenstand
- unsichtbar und der Name zu "etwas". Zusaetzlich koennen Spieler ihn
- nicht mehr ansprechen, d.h. nehmen, wegwerfen, weitergeben etc.
- (Bei magier-eigenen Kommandos ist dies evtl. nicht umgesetzt...)
- Setzt man P_SHORT auf 0, wird der Gegenstand nur nicht mehr in
- der Inventarliste von Behaeltern/Raeumen angezeigt, er behaelt aber
- seinen Namen und ist durch Spieler ansprechbar, wenn sie eine ID
- kennen.
-
- - NPCs
- Bei gesetztem P_INVIS wird der NPC unsichtbar und sein Name wird zu
- "Jemand". Zusaetzlich koennen Spieler ihn nicht mehr ansprechen, z.B.
- toeten oder knuddeln.
- (Bei magier-eigenen Kommandos ist dies evtl. nicht umgesetzt...)
- Setzt man P_SHORT auf 0, wird der NPC nur nicht mehr in der
- Inventarliste von Behaeltern/Raeumen angezeigt, er behaelt aber seinen
- Namen und ist durch Spieler ansprechbar, wenn sie eine ID kennen. Auch
- angreifen und kaempfen ist moeglich.
-
-
-
- - Magier
- Magier macht man unsichtbar, indem man ihnen die Property P_INVIS auf
- einen Wert <> 0 setzt.
- * Spieler duerfen nicht unsichtbar gemacht werden! *
- * Wird ein Magier unsichtbar gemacht, muss man ihm die Property *
- * P_INVIS auf den Wert setzen, den die Property P_AGE zu diesem *
- * Zeitpunkt hat (keine F_QUERY_METHOD !). *
- Setzt man die Property auf den Wert 1, so erhaelt ein Spieler,
- wenn er den entsp. Magier fingert, die Ausgabe: Alter: 00:00:02,
- was genauso verraeterisch ist, wie ein Alter, dass bei einem
- scheinbar nicht eingeloggten Magier immer weiter hochgezaehlt
- wird.
-
-27.05.2015, Zesstra
diff --git a/doc/sphinx/man/props/P_IP_NAME b/doc/sphinx/man/props/P_IP_NAME
deleted file mode 100644
index 6003c80..0000000
--- a/doc/sphinx/man/props/P_IP_NAME
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_IP_NAME
-*********
-
-
-NAME
-====
-
- P_IP_NAME "ip_name"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Rechnername des Interactives
diff --git a/doc/sphinx/man/props/P_IS_ARTILLERY b/doc/sphinx/man/props/P_IS_ARTILLERY
deleted file mode 100644
index 2afcd60..0000000
--- a/doc/sphinx/man/props/P_IS_ARTILLERY
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_IS_ARTILLERY
-**************
-
-
-NAME
-====
-
- P_IS_ARTILLERY "artillery"
-
-
-DEFINIERT IN
-============
-
- /sys/combat.h
-
-
-BESCHREIBUNG
-============
-
- Is ein Objekt Artillerie, so muss diese Property
- gesetzt sein. (Derzeit einfach auf 1 setzen.)
-
-
-SIEHE AUCH
-==========
-
- artillerie
-
-Last modified: Sam, 5. Jul 2003, 22:07:12 by Zook.
diff --git a/doc/sphinx/man/props/P_ITEMS b/doc/sphinx/man/props/P_ITEMS
deleted file mode 100644
index 1fcafc5..0000000
--- a/doc/sphinx/man/props/P_ITEMS
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_ITEMS
-*******
-
-
-NAME
-====
-
- P_ITEMS "items"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Definition von Gegenstaenden, die in dem Raum liegen sollen.
- Erklaerung in einem Extrafile.
diff --git a/doc/sphinx/man/props/P_I_HATE_ALCOHOL b/doc/sphinx/man/props/P_I_HATE_ALCOHOL
deleted file mode 100644
index 0a0eefc..0000000
--- a/doc/sphinx/man/props/P_I_HATE_ALCOHOL
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_I_HATE_ALCOHOL
-****************
-
-
-NAME
-====
-
- P_I_HATE_ALCOHOL "i_hate_alcohol"
-
-
-DEFINIERT IN
-============
-
- /sys/inpc/boozing.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert, der die Obergrenze an P_ALCOHOL in einem Monster
- definiert, welcher beim eigenstaendigen Tanken beruecksichtigt wird.
-
-
-BEMERKUNG
-=========
-
- Geht der Npc (und nur fuer solche ist diese Prop gedacht) eigen-
- staendig tanken, werden vor dem Bestellen die Getraenke und Speisen
- auf ihren Alkoholgehalt geprueft und mit dem aktuellen Wert von
- P_ALCOHOL im Verhaeltnis zu P_I_HATE_ALCOHOL verglichen. Laege der
- Wert fuer P_ALCOHOL dann ueber dem von P_I_HATE_ALCOHOL, wird dieses
- Getraenk (diese Speise) nicht bestellt.
-
-
-SIEHE AUCH
-==========
-
- P_ALCOHOL, P_MAX_ALCOHOL
-
-Last modified: Sam Apr 14 12:35:00 2001 by Tilly
diff --git a/doc/sphinx/man/props/P_KEEPER b/doc/sphinx/man/props/P_KEEPER
deleted file mode 100644
index 63185c8..0000000
--- a/doc/sphinx/man/props/P_KEEPER
+++ /dev/null
@@ -1,26 +0,0 @@
-
-P_KEEPER
-********
-
-
-NAME
-====
-
- P_KEEPER "shop_keeper"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- In diese Property kann man in Kneipen und Laeden einen String schreiben.
- Dann wird vor den Transaktionen geprueft, ob ein NPC anwesend ist,
- der diesen String als ID hat.
- Ist der NPC nicht vorhanden, kann nichts ge- oder verkauft werden.
-
-Last modified: Mon Aug 23 14:29:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/props/P_KEEP_ON_SELL b/doc/sphinx/man/props/P_KEEP_ON_SELL
deleted file mode 100644
index ce5feba..0000000
--- a/doc/sphinx/man/props/P_KEEP_ON_SELL
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_KEEP_ON_SELL
-**************
-
-
-NAME
-====
-
- P_KEEP_ON_SELL "keep_on_sell"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Bei "verkaufe alles" wird das Objekt behalten.
diff --git a/doc/sphinx/man/props/P_KILLER b/doc/sphinx/man/props/P_KILLER
deleted file mode 100644
index 01bb0d1..0000000
--- a/doc/sphinx/man/props/P_KILLER
+++ /dev/null
@@ -1,46 +0,0 @@
-
-P_KILLER
-********
-
-
-NAME
-====
-
- P_KILLER "killer"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt das Objekt, welches das Lebewesen als letztes
- getoetet hat. Sie wird von do_damage(), heart_beat() (Vergiftungen) und
- die() (bei direkten Aufrufen) automatisch gesetzt. Ein manuelles
- Setzen vor Aufruf von do_damage() oder die() hat keinerlei Wirkung!
- Sinnvollerweise liest man diese Property im NotifyPlayerDeath() aus,
- spaeteres Auslesen ist unzuverlaessig, da der Killer inzwischen zerstoert
- sein koennte.
- Diese Property sollte _nicht_ per Hand gesetzt werden, schon gar nicht
- waehrend eines NotifyPlayerDeath(), weil es evtl. noch andere Objekte gibt,
- die sich dafuer interessieren!
-
-
-BEMERKUNGEN
-===========
-
- Normalerweise steht hier ein Objekt drin (s.o.). Es gibt allerdings eine
- Ausnahme: Stirbt ein Lebewesen an Gift, enthaelt P_KILLER den String
- "gift".
-
-
-SIEHE AUCH
-==========
-
- do_damage()
-
-29.08.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_KILLS b/doc/sphinx/man/props/P_KILLS
deleted file mode 100644
index 7ec3dac..0000000
--- a/doc/sphinx/man/props/P_KILLS
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_KILLS
-*******
-
-
-NAME
-====
-
- P_KILLS "playerkills"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der Spieler, die dieser Spieler schon getoetet hat.
- Unerlaubte Manipulation ist ein SCHWERES VERGEHEN gegen
- die Mudreglen.
diff --git a/doc/sphinx/man/props/P_KILL_MSG b/doc/sphinx/man/props/P_KILL_MSG
deleted file mode 100644
index 9437975..0000000
--- a/doc/sphinx/man/props/P_KILL_MSG
+++ /dev/null
@@ -1,96 +0,0 @@
-
-P_KILL_MSG
-**********
-
-
-NAME
-====
-
- P_KILL_MSG "kill_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Spieler getoetet wird, so erscheint dazu eine kurze Information
- auf dem Todeskanal. Um dem toetenden Objekt zusaetzlich die Moeglichkeit
- zu geben, noch etwas mehr auf diesem Kanal auszugeben, kann man in
- dieser Property einen String uebergeben.
- Noetige Zeilenumbrueche werden hierbei automatisch generiert.
-
- Es ist auch moeglich anzugeben, ob Emotes verwendet werden und ob das
- toetende Objekt ein Plural-Objekt ist. Hierzu uebergibt man ein Array
- der Gestalt:
-
- ({Killmessage,Emotes}) bzw. ({Killmessage,Emotes,PLURAL})
-
- Der Eintrag <Killmessage> stellt hierbei die Meldung selbst dar, PLURAL
- gibt an, dass es sich um ein Plural-Objekt handelt und <Emotes> kann
- folgende Werte annehmen:
-
- MSG_SAY - Meldung wird normal ausgegeben.
- MSG_EMOTE - Meldung erscheint als Emote.
- MSG_GEMOTE - Meldung erscheint als Genitiv-Emote.
- MSG_EMPTY - Meldung erscheint ohne zuvorige Angabe des
- toetenden Objektes.
-
- Moechte man die Meldung noch etwas "persoenlicher" ;-) gestalten, so
- kann man den Platzhalter %s verwenden. An dessen Stelle wird dann der
- Name des Verblichenen eingesetzt.
-
-
-BEISPIEL
-========
-
- Ein nettes Beispiel ist das folgende: Wenn ein Spieler sich als
- Drachentoeter bewehrt hat, so kann er traditionell in seinem Blut baden.
- Hin und wieder ist jedoch auch der Drache erfolgreich, dem man eine
- lustige Zusatzmeldung fuer den Todeskanal uebergeben kann:
-
- void create() {
- ::create();
- ...
- SetProp(P_KILL_MSG,"Jetzt bade ich mal in DEINEM Blut, %s!");
- ...
- }
-
-
- Falls der 'Killer' ein Plural-Objekt oder -NPC war, koennte eine Meldung
- auch folgendermassen aussehen:
-
- SetProp(P_KILL_MSG,({"haun sich jetzt die Hucke voll.",
- MSG_EMOTE,
- PLURAL}));
-
- wobei P_KILL_NAME hier natuerlich auf "Eine Menge Orks" oder
- dergleichen gesetzt sein sollte. Auf dem Kanal waere dann dies zu
- lesen:
-
- [Tod:Lars] Eine Menge Orks haben gerade Orktoeter umgebracht.
- [Tod:Eine Menge Orks haun sich jetzt die Hucke voll.]
-
-
- Weiteres Beispiel.
- Man habe einen NPC, dessen Killname als Plural aufzufassen ist, der aber
- keinen zusaetlichen Text auf -Tod bringen soll.
-
- SetProp(P_NAME, "Eine Horde Gummibaeren");
- SetProp(P_KILL_NAME, "Viele kleine Gummibaeren");
- SetProp(P_KILL_MSG, ({0, 0, 1}));
-
-
-SIEHE AUCH
-==========
-
- Tod: die(L)
- Todesmeldungen: P_KILL_NAME, P_DIE_MSG, P_MURDER_MSG
- P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /room/death/death_room.c
-
-Last modified: Wed Aug 21 14:36:04 2002 by Bambi
diff --git a/doc/sphinx/man/props/P_KILL_NAME b/doc/sphinx/man/props/P_KILL_NAME
deleted file mode 100644
index 0504066..0000000
--- a/doc/sphinx/man/props/P_KILL_NAME
+++ /dev/null
@@ -1,59 +0,0 @@
-
-P_KILL_NAME
-***********
-
-
-NAME
-====
-
- P_KILL_NAME "kill_name"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wenn ein Spieler getoetet wird, so erscheint eine kurze Information auf
- dem Todeskanal. Im Normalfall werden die Informationen aus P_NAME,
- P_ARTICLE und P_GENDER des toetenden Objektes verwendet, um einen Namen
- fuer eben dieses Objekt zu kreieren. Manchmal moechte man jedoch einen
- davon unabhaengigen Namen dort stehen haben. Dann kommt die Property
- P_KILL_NAME zum Einsatz.
- Man sollte beachten, dass der Name des Toetenden nicht zu lang sein
- sollte, denn obwohl bei einer Todesmeldung automatisch umgebrochen wird,
- kann es doch ziemlich stoeren. Wenn das toetende Objekt ein Plural-
- Objekt ist, so kann man dies zusaetzlich in der Property P_KILL_MSG
- angeben.
-
-
-BEISPIEL
-========
-
- Eine Wolke, die wahlweise zwischen verschiedenen Zustaenden mutiert,
- koennte mal eine Eiswolke, mal eine Giftwolke oder auch mal eine
- Feuerwolke sein. Fuer den Todeskanal soll jedoch immer erscheinen:
- '[Tod:] Eine mutierende Wolke hat gerade <Spieler> umgebracht.'
-
- void create()
- {
- ::create();
- ...
- SetProp(P_KILL_NAME,"Eine mutierende Wolke");
- ...
- }
-
-
-SIEHE AUCH
-==========
-
- Tod: die(L)
- Todesmeldungen: P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
- P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /room/death/death_room.c
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_KNOWN_POTIONROOMS b/doc/sphinx/man/props/P_KNOWN_POTIONROOMS
deleted file mode 100644
index 29e17d3..0000000
--- a/doc/sphinx/man/props/P_KNOWN_POTIONROOMS
+++ /dev/null
@@ -1,35 +0,0 @@
-
-P_KNOWN_POTIONROOMS
-*******************
-
-
-NAME
-====
-
- P_KNOWN_POTIONROOMS "known_potionrooms"
-
-
-DEFINIERT IN
-============
-
- /sys/player/potion.h
-
-
-BESCHREIBUNG
-============
-
- Array mit den Nummern der Raeume, in denen der Spieler Zauber-
- traenke finden kann. Die Zuordnung der Raeume und Nummern
- geschieht im Potionmaster.
-
- Nur lesbare _query - Property.
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: FindPotion(), AddKnownPotion(), RemoveKnownPotion(), InList()
- Props: P_POTIONROOMS
-
-6.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_LASTDIR b/doc/sphinx/man/props/P_LASTDIR
deleted file mode 100644
index 2695f06..0000000
--- a/doc/sphinx/man/props/P_LASTDIR
+++ /dev/null
@@ -1,28 +0,0 @@
-
-P_LASTDIR
-*********
-
-
-NAME
-====
-
- P_LASTDIR "p_lib_lastdir"
-
-
-DEFINIERT IN
-============
-
- /sys/shells.h
-
-
-BESCHREIBUNG
-============
-
- Das jeweils letzte Verzeichnis, in dem der Magier war.
- (Nur fuer Magier von Belang)
-
-Siehe auch:
- P_CURRENTDIR
-
-Letzte Aenderung:
- 03.05.2016, Zesstra
diff --git a/doc/sphinx/man/props/P_LAST_COMBAT_TIME b/doc/sphinx/man/props/P_LAST_COMBAT_TIME
deleted file mode 100644
index 941ec1e..0000000
--- a/doc/sphinx/man/props/P_LAST_COMBAT_TIME
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_LAST_COMBAT_TIME
-******************
-
-
-NAME
-====
-
- P_LAST_COMBAT_TIME "last_combat_time"
-
-
-DEFINIERT IN
-============
-
- /sys/combat.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property wird genau die Zeit festgehalten, zu der ein
- Lebewesen zuletzt einen Angriff abgewehrt oder einen Angriff
- durchgefuehrt hat. Die Property enthaelt diese Information hierbei
- immer in Form eines Integerwertes.
- Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte, wann
- ein Lebewesen zuletzt gekaempft hat. Es ist beispielsweise nicht
- moeglich, waehrend oder auch unmittelbar nach einem Kampf den Befehl
- 'Ende' zu nutzen, da dies zur Flucht missbraucht werden kann. Dafuer
- wird der Wert der Property zuvor ausgewertet.
-
-
-SIEHE AUCH
-==========
-
- P_LAST_DAMTIME, P_LAST_DAMAGE, P_LAST_DAMTYPES, Attack(), Defend(),
- /std/living/combat.c, /std/living/life.c
-
-Last modified: Wed May 26 16:43:00 1999 by Patryn
diff --git a/doc/sphinx/man/props/P_LAST_COMMAND_ENV b/doc/sphinx/man/props/P_LAST_COMMAND_ENV
deleted file mode 100644
index 40bd6a0..0000000
--- a/doc/sphinx/man/props/P_LAST_COMMAND_ENV
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_LAST_COMMAND_ENV
-******************
-
-
-NAME
-====
-
- P_LAST_COMMAND_ENV "last_command_env"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Der Raum, in dem das letzte Kommando eingegeben wurde.
-
-
-BEMERKUNGEN
-===========
-
- Keine echte Property, _query_last_command_env() ist
- in /std/players/command.c implementiert.
-
-14.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/props/P_LAST_CONTENT_CHANGE b/doc/sphinx/man/props/P_LAST_CONTENT_CHANGE
deleted file mode 100644
index f128774..0000000
--- a/doc/sphinx/man/props/P_LAST_CONTENT_CHANGE
+++ /dev/null
@@ -1,32 +0,0 @@
-
-P_LAST_CONTENT_CHANGE
-*********************
-
-
-NAME
-====
-
- P_LAST_CONTENT_CHANGE "last_content_change"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wann wurde zum letzten Mal was ins Obj gestopft oder rausgenommen?
- Wichtig fuer den Weight-Cache
-
-
-ANMERKUNG
-=========
-
- Die Property kann nur ueber QueryProp() und SetProp() ausgelesen bzw.
- gesetzt werden. Query() und Set() funktionieren *nicht*.
-
- Ausserdem fuehrt ein Setzen per SetProp() zu einer Erhoehung des
- Wertes um eins - unabhaengig vom gesetzten Wert.
diff --git a/doc/sphinx/man/props/P_LAST_DAMAGE b/doc/sphinx/man/props/P_LAST_DAMAGE
deleted file mode 100644
index 66388b7..0000000
--- a/doc/sphinx/man/props/P_LAST_DAMAGE
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_LAST_DAMAGE
-*************
-
-
-NAME
-====
-
- P_LAST_DAMAGE "last_damage"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property wird genau die Schadensstaerke festgehalten,
- welche ein Lebewesen zuletzt abbekommen hat. Die Property enthaelt
- diese Information hierbei immer in Form eines Integerwertes.
- Auch die Staerke des Giftschadens durch die Wirkung einer Vergiftung
- wird hier festgehalten.
- Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte,
- welche Schadensstaerke nach Einwirkung von Defendern, Ruestung,
- Hooks und Skills uebriggeblieben ist.
-
-
-SIEHE AUCH
-==========
-
- P_LAST_DAMTIME, P_LAST_DAMTYPES, Defend(),
- /std/living/combat.c, /std/living/life.c
-
-Last modified: Tue Jan 26 12:34:29 1999 by Patryn
diff --git a/doc/sphinx/man/props/P_LAST_DAMTIME b/doc/sphinx/man/props/P_LAST_DAMTIME
deleted file mode 100644
index 7e6d0ea..0000000
--- a/doc/sphinx/man/props/P_LAST_DAMTIME
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_LAST_DAMTIME
-**************
-
-
-NAME
-====
-
- P_LAST_DAMTIME "last_damtime"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property wird genau die Zeit festgehalten, zu der ein
- Lebewesen zuletzt einen Schaden abbekommen hat. Die Property
- enthaelt diese Information hierbei immer in Form eines
- Integerwertes.
- Auch der Zeitpunkt der Einwirkung von Giftschaden durch die Wirkung
- einer Vergiftung wird hier festgehalten.
- Dieser Wert koennte z.B. wichtig sein, wenn man wissen moechte, wann
- ein Lebewesen zuletzt verletzt wurde.
-
-
-SIEHE AUCH
-==========
-
- P_LAST_COMBAT_TIME, P_LAST_DAMAGE, P_LAST_DAMTYPES, Defend(),
- /std/living/combat.c, /std/living/life.c
-
-Last modified: Wed May 26 16:44:38 1999 by Patryn
diff --git a/doc/sphinx/man/props/P_LAST_DAMTYPES b/doc/sphinx/man/props/P_LAST_DAMTYPES
deleted file mode 100644
index ecdf571..0000000
--- a/doc/sphinx/man/props/P_LAST_DAMTYPES
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_LAST_DAMTYPES
-***************
-
-
-NAME
-====
-
- P_LAST_DAMTYPES "last_damtypes"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property werden genau die Schadensarten festgehalten,
- welche ein Lebewesen zuletzt abbekommen hat. Die Property enthaelt
- diese Information hierbei immer in Form eines Arrays.
- Auch der Giftschaden durch die Wirkung einer Vergiftung wird hier
- festgehalten.
- Dieser Wert koennte z.B. wichtig sein, wenn man nach dem Tod eines
- Lebewesens feststellen moechte, durch was es umgekommen ist.
-
-
-SIEHE AUCH
-==========
-
- P_LAST_DAMAGE, P_LAST_DAMTIME, Defend(),
- /std/living/combat.c, /std/living/life.c
-
-Last modified: Tue Jan 26 12:34:29 1999 by Patryn
diff --git a/doc/sphinx/man/props/P_LAST_DEATH_PROPS b/doc/sphinx/man/props/P_LAST_DEATH_PROPS
deleted file mode 100644
index 7249dad..0000000
--- a/doc/sphinx/man/props/P_LAST_DEATH_PROPS
+++ /dev/null
@@ -1,32 +0,0 @@
-
-P_LAST_DEATH_PROPS
-******************
-
-
-NAME
-====
-
- P_LAST_DEATH_PROPS "last_death_props"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt nach dem Tod eines Spielers ein Mapping mit
- den Werte aller Properties, die im die() zurueckgesetzt werden.
-
- Auf diese Weise kann ein Objekt auch im NotifyPlayerDeath() noch
- auf die Werte zurueckgreifen, obwohl sie bereits geloescht sind.
-
- Folgende Properties werden so gesichert:
-
-
-
- P_POISON, P_FROG, P_ALCOHOL, P_DRINK, P_FOOD , P_BLIND, P_DEAF,
- P_MAX_HANDS, P_PARA, P_NO_REGENERATION , P_HP, P_SP, P_LAST_DEATH_TIME
diff --git a/doc/sphinx/man/props/P_LAST_DEATH_TIME b/doc/sphinx/man/props/P_LAST_DEATH_TIME
deleted file mode 100644
index 669e7a1..0000000
--- a/doc/sphinx/man/props/P_LAST_DEATH_TIME
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_LAST_DEATH_TIME
-*****************
-
-
-NAME
-====
-
- P_LAST_DEATH_TIME "last_death_time"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Der Zeitpunkt des letzten Todes des Spielers.
diff --git a/doc/sphinx/man/props/P_LAST_LOGIN b/doc/sphinx/man/props/P_LAST_LOGIN
deleted file mode 100644
index 4ad7360..0000000
--- a/doc/sphinx/man/props/P_LAST_LOGIN
+++ /dev/null
@@ -1,35 +0,0 @@
-
-P_LAST_LOGIN
-************
-
-
-NAME
-====
-
- P_LAST_LOGIN "last_login"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Zeitpunkt des letzten Logins
-
-
-BEMERKUNGEN
-===========
-
- Gegen aeussere Aenderung und Set/QueryMethoden geschuetzt.
-
-
-SIEHE AUCH
-==========
-
- P_LAST_LOGOUT, save_me
-
-28. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/props/P_LAST_LOGOUT b/doc/sphinx/man/props/P_LAST_LOGOUT
deleted file mode 100644
index e94e89e..0000000
--- a/doc/sphinx/man/props/P_LAST_LOGOUT
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_LAST_LOGOUT
-*************
-
-
-NAME
-====
-
- P_LAST_LOGOUT "last_logout"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Zeitpunkt des letzten Logouts. Anhand dieser Zeit werden die Feindes-
- listen und in Abwesenheit eingefuegte Gegenstaende aktualisiert.
-
- Dieses Datum wird bei Magiern nicht aktualisiert, wenn sie unsichtbar
- sind/sich unsichtbar ausloggen.
-
-
-BEMERKUNGEN
-===========
-
- Gegen aeussere Aenderung und Set/QueryMethoden geschuetzt.
-
-
-SIEHE AUCH
-==========
-
- P_LAST_LOGIN, P_INVIS, save_me, init, StopHuntFor
-
-28. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/props/P_LAST_MOVE b/doc/sphinx/man/props/P_LAST_MOVE
deleted file mode 100644
index f6c974a..0000000
--- a/doc/sphinx/man/props/P_LAST_MOVE
+++ /dev/null
@@ -1,36 +0,0 @@
-
-P_LAST_MOVE
-***********
-
-
-NAME
-====
-
- P_LAST_MOVE "last_move"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property wird die Zeit der letzten Bewegung eines
- Lebewesens festgehalten. Selbsterklaerend ist auch der dazugehoerige
- Quellcode innerhalb move() in '/std/living/moving.c':
- SetProp(P_LAST_MOVE,time());
- Wichtig ist diese Property insbesondere fuer die Unterbindung von
- Rein-Angriff-Raus-Taktiken. Dieser Modus ist standardmaessig in jedem
- NPC aktiviert und kann ueber die Property P_ENABLE_IN_ATTACK_OUT
- ausgeschalten werden.
-
-
-SIEHE AUCH
-==========
-
- move(), time(), P_ENABLE_IN_ATTACK_OUT, /std/living/moving.c
-
-Last modified: Sat Jan 30 12:53:00 1999 by Patryn
diff --git a/doc/sphinx/man/props/P_LAST_USE b/doc/sphinx/man/props/P_LAST_USE
deleted file mode 100644
index 57519c9..0000000
--- a/doc/sphinx/man/props/P_LAST_USE
+++ /dev/null
@@ -1,33 +0,0 @@
-
-P_LAST_USE
-**********
-
-
-NAME
-====
-
- P_LAST_USE "last_use"
-
-
-DEFINIERT IN
-============
-
- <properties.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property wird in Ruestungen und Waffen dazu benutzt um
- festzuhalten, wann die Ruestung/Waffe zuletzt im Kampf benutzt
- wurde.
-
-
-SIEHE AUCH
-==========
-
- Ruestungen: QueryDefend(L)
- Waffen: QueryDamage(L)
- Sonstiges: P_EQUIP_TIME, P_UNWIELD_TIME
-
-Last modified: Fri Feb 06 10:15:00 1998 by Paracelsus
diff --git a/doc/sphinx/man/props/P_LAST_WEAR_ACTION b/doc/sphinx/man/props/P_LAST_WEAR_ACTION
deleted file mode 100644
index 5531955..0000000
--- a/doc/sphinx/man/props/P_LAST_WEAR_ACTION
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_LAST_WEAR_ACTION
-******************
-
-
-PROPERTY
-========
-
- P_LAST_WEAR_ACTION "last_wear_action"
-
-DEFINIERT IN:
-
- /sys/armour.h (und damit auch in properties.h)
-
-
-BESCHREIBUNG
-============
-
- Diese Prop gibt an, welche An/Auszieh-Aktion ein Spieler zuletzt
- durchgefuehrt hat. Sie ist ein zweielementiges Array, wobei der
- erste Eintrag angibt, ob der Spieler sich an- oder ausgezogen
- hat (WA_WEAR, WA_UNWEAR, auch in armour.h definiert) und der
- zweite den Zeitpunkt.
-
- Die Property wird (unter anderem?) dafuer verwendet festzustellen ob
- der Spieler in der letzten Runde schon einen Ruestungswechsel
- vorgenommen hat und einen entgegengesetzten zu unterbinden.
-
-LETZTE AENDERUNG:
-
-2003-01-29, 17:30 von Humni
diff --git a/doc/sphinx/man/props/P_LAST_XP b/doc/sphinx/man/props/P_LAST_XP
deleted file mode 100644
index c31a8b4..0000000
--- a/doc/sphinx/man/props/P_LAST_XP
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_LAST_XP
-*********
-
-
-NAME
-====
-
- P_LAST_XP "last_xp"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Ein Array vom Typ ({ pfad, xp }).
-
- Der Eintrag "pfad" gibt das Gebiet an, in dem ein Spieler zuletzt XP
- bekommen hat. Dabei wird aus "/d/ebene/magier/room/raum1.c" dann
- "/d/ebene/magier/room".
-
- Der Wert "xp" zeigt an, wieviele XP der Spieler _in diesem Gebiet_
- gesammelt hat. Sobald er auch nur einen XP in einem anderen Gebiet
- bekommt, zeigt P_LAST_XP nur noch diesen neu erhaltenen XP an.
-
- Der Anwendungszweck waere z.B. eine Heilstelle, die nur dann Wirkung
- zeigt, wenn der Spieler wirklich in dem betreffenden Gebiet gemetzelt hat
- und nicht nur zum Tanken hergerannt ist oder eine Unterscheidung, ob
- jemand metzelt oder nur uebt (ueber die XP).
-
-
-SIEHE AUCH
-==========
-
- Funktionen: AddExp()
- Verwandt: P_NO_XP, P_XP
-
-14.Feb 2007 Gloinson
diff --git a/doc/sphinx/man/props/P_LEAVECMDS b/doc/sphinx/man/props/P_LEAVECMDS
deleted file mode 100644
index 5b0e03c..0000000
--- a/doc/sphinx/man/props/P_LEAVECMDS
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_LEAVECMDS
-***********
-
-
-NAME
-====
-
- P_LEAVECMDS "leavecmds"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Ein Array mit Befehlen, die zum Verlassen des Transporters fuehren.
-
-
-BEISPIEL
-========
-
- SetProp(P_LEAVECMDS,({ "verlass","verlasse" }) );
-
- Gibt der Spieler nun 'verlasse xxx' ein, so sorgt /std/transport.c
- dafuer, das der Spieler auch von oder aus dem Transporter bewegt
- wird. Vorausgesetzt natuerlich, er ist an einem Haltepunkt angelangt.
-
-
-BEMERKUNGEN
-===========
-
- Um /std/transport.c nicht aufzublaehen, werden weitere Argumente wie
- etwa 'verlasse das|die|den xxx' _nicht_ unterstuetzt!
-
- Hier muss der verantwortliche Magier schon eine eigene Loesung finden
- und in seinen Transporter schreiben.
-
- Sollen Kommandos zum Betreten UND Verlassen eines Transporters ver-
- wendet werden koennen, muessen diese in P_TRAVEL_CMDS gesetzt werden.
-
-
-SIEHE AUCH
-==========
-
- P_LEAVEFAIL, P_ENTERFAIL, P_ENTERCMDS, P_TRAVEL_CMDS, transporter,
-
-
-LETZTE AENDERUNG
-================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_LEAVEFAIL b/doc/sphinx/man/props/P_LEAVEFAIL
deleted file mode 100644
index 88e92ea..0000000
--- a/doc/sphinx/man/props/P_LEAVEFAIL
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_LEAVEFAIL
-***********
-
-
-NAME
-====
-
- P_LEAVEFAIL "leavefail"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Spieler, wenn er ausserhalb der Anlegezeiten einen
- Transporter verlassen will. Ist die Propertie ein Array, so wird
- das erste Element als Meldung an den Spieler, das zweite als
- Meldung an die Mitspieler im Transporter geschickt. Ist der Eintrag
- dagegen ein simpler String, so wird die Meldung nur an den Spieler
- ausgegeben.
-
-
-BEISPIEL
-========
-
- SetProp(P_LEAVEFAIL, "Die Wildgaense fliegen viel zu hoch" );
-
- SetProp(P_LEAVEFAIL, ({ "Die Wildgaense fliegen viel zu hoch",
- "versucht, vom Ruecken der Wildgans zu "
- +"klettern und besinnt sich dann doch" }) );
-
-
-SIEHE AUCH
-==========
-
- P_LEAVEMSG, P_ENTERMSG, P_ENTERFAIL, transporter
-
-
-LETZTE AENDERUNG
-================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_LEAVEMSG b/doc/sphinx/man/props/P_LEAVEMSG
deleted file mode 100644
index a3a1baf..0000000
--- a/doc/sphinx/man/props/P_LEAVEMSG
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_LEAVEMSG
-**********
-
-
-NAME
-====
-
- P_LEAVEMSG "leavemsg"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Array mit zwei Meldungen. Der erste Eintrag wird an den Transporter
- ausgegeben, der zweite an den Raum in den der Spieler kommt.
-
-
-BEISPIEL
-========
-
- SetProp(P_LEAVEMSG, ({ "klettert vom Ruecken der Wildgans",
- "kommt vom Ruecken einer Wildgans herunter" }) );
-
-SIEHE AUCH:
- P_ENTERMSG, P_LEAVEFAIL, P_ENTERFAIL, transporter
-
-
-LETZTE AENDERUNG
-================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_LEP b/doc/sphinx/man/props/P_LEP
deleted file mode 100644
index dbcea68..0000000
--- a/doc/sphinx/man/props/P_LEP
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_LEP
-*****
-
-
-NAME
-====
-
- P_LEP "lep"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Levelpunkte eines Spielers
- NICHT VON HAND SETZEN!!!
diff --git a/doc/sphinx/man/props/P_LEVEL b/doc/sphinx/man/props/P_LEVEL
deleted file mode 100644
index a4b804c..0000000
--- a/doc/sphinx/man/props/P_LEVEL
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_LEVEL
-*******
-
-
-NAME
-====
-
- P_LEVEL "level"
-
-
-DEFINIERT IN
-============
-
- /sys/living/description.h
-
-
-BESCHREIBUNG
-============
-
- Spieler-Level (!= Magierlevel)
-
- In Krankheits- (CL_DISEASE) und Giftobjekten (CL_POISON) drueckt
- P_LEVEL aus, wie schwer die Krankheit/das Gift ist. Je nachdem, wie
- hoch oder niedrig der Level gesetzt wird, muss z.B. ein Kleriker mehr
- oder weniger oft kurieren, um eine (ggf. stufenweise) Heilung zu
- bewirken.
-
- In Fluchobjekten (CL_CURSE) gibt P_LEVEL ebenfalls die Schwere des
- Fluches an, jedoch ist hier zu beachten, dass z.B. Kleriker aktuell
- keine stufenweise Schwaechung bewirken koennen, sondern entweder den
- Fluch entfernen koennen oder komplett scheitern.
- Der Fluchlevel ist hier grob als Chance des Scheiterns in einem
- Wertebereich von 1-100 zu sehen, was bedeutet, dass ein Fluchlevel
- von 100 als permanenter, nicht entfernbarer Fluch anzusehen ist.
-
- Genaueres ist in der Klerusgilde nachzulesen oder beim GM Klerus zu
- erfragen.
-
-
-SIEHE AUCH
-==========
-
- Properties: P_GUILD_LEVEL
- Allgemeines: /doc/wiz/gift, /doc/help/gift
- Funktionen: AddClass(L), is_class_member(L)
-
-Letzte Aenderung: 2015-Feb-02, Arathorn.
diff --git a/doc/sphinx/man/props/P_LIFETIME b/doc/sphinx/man/props/P_LIFETIME
deleted file mode 100644
index 4c76f14..0000000
--- a/doc/sphinx/man/props/P_LIFETIME
+++ /dev/null
@@ -1,51 +0,0 @@
-
-P_LIFETIME
-**********
-
-
-NAME
-====
-
- P_LIFETIME "std_food_lifetime"
-
-
-DEFINIERT IN
-============
-
- /sys/food.h
-
-
-BESCHREIBUNG
-============
-
- Zeit in Sekunden, die die Speise haltbar ist.
- Mit Setzen dieser Property wird der Wert fuer P_RESET_LIFETIME und
- dort gespeichert.
- Nach dieser Zeit wird diese Speise schlecht und je nach Konfiguration
- der Speise eventuell zerstoert. Sichergestellt wird dies durch den
- Aufruf von reset() nach dieser Anzahl Sekunden.
- Moechte man eine Speise haben, die niemals verdirbt
- (genehmigungspflichtig!), nutzt man die Property P_NO_BAD
-
-
-BEMERKUNGEN
-===========
-
- Sobald der Countdown zum Schlechtwerden der Speise laeuft, also ein
- Spieler damit in Beruehrung kam, zeigt SetProp auf diese Property keine
- Wirkung mehr.
-
-
-DEFAULT
-=======
-
- Ohne Setzen von P_LIFETIME ,P_RESET_LIFETIME und P_NO_BAD verdirbt die
- Speise nach einem Reset, also zwischen 30 und 60 Minuten
-
-
-SIEHE AUCH
-==========
-
- wiz/food, P_RESET_LIFETIME, P_NO_BAD
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_LIGHT b/doc/sphinx/man/props/P_LIGHT
deleted file mode 100644
index d0b55d8..0000000
--- a/doc/sphinx/man/props/P_LIGHT
+++ /dev/null
@@ -1,81 +0,0 @@
-
-P_LIGHT
-*******
-
-
-NAME
-====
-
- P_LIGHT "light"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Gibt den Lichtlevel eines Objektes an, d.h. wie hell das Objekt von sich
- aus leuchtet. Moechte man den gesamten Lichtlevel haben der von einem
- Objekt ausgeht, so sollte man P_TOTAL_LIGHT nehmen, das den Inhalt eines
- Containers direkt mit verrechnet.
-
- Bitte _nur_ ueber SetProp bzw. QueryProp zugreifen, da es fuer die
- Berechnung wichtig ist, das in allen Containern P_LAST_CONTENT_CHANGE
- gesetzt wird um ein neuberechnen des Lichtlevels auszuloesen!
-
-
-ANMERKUNG
-=========
-
- Um ein ungefaehres Gefuehl davon zu bekommen was ein Lichtlevel in
- etwa bedeutet hier einige allgemeine Beispiele von Gegenstaenden.
- Grundsaetzlich sollten Lichtlevel <0 und >2 nur in Ruecksprache mit dem
- Balanceteam benutzt werden.
-
- Lichtlevel -1, z.B. ein schwarzer Ring, von dem eine kleine dunkle Aura
- ausgeht, die den Spieler umgibt.
- Lichtlevel 0, der Gegenstand beeinflusst das Licht ueberhaupt nicht
- Lichtlevel 1, der Spieler haelt eine kleine Lichtquelle in Haenden,
- dieses kann ein Leuchtpfirsich, eine Fackel oder ein
- Feuerschwert oder aehnliches sein.
- Lichtlevel 2, eine etwas groessere Lichtquelle, die aber immer noch
- nicht den Raum beleuchtet sondern lediglich dem Spieler
- einen Lichtschein gewaehrt mit dem er sehen kann.
- Lichtlevel >2, extrem helle Lichtquellen, die den gesamten Raum
- ausleuchten, in der Regel wohl eher magischer Natur.
- Solche Lichtquellen sollten sich mit der Zeit
- verbrauchen, dem Spieler Schaden zufuegen oder
- aehnliches, damit die Spieler nicht defaultmaessig mit
- einer solchen Lichtquelle durchs MG ziehn.
-
- Daraus ergeben sich dann folgende Konsequenzen fuer Raeume:
- Lichtlevel >1: Der Raum ist sehr hell erleuchtet und kann von Spielern
- nicht oder nur sehr schwer abgedunkelt werden. Ein Wert
- von 2-3 kann interessant sein, wenn die NPCs im Raum
- ueber keine Nachtsicht verfuegen. Ueber ein Abdunkeln des
- Raumes kann der Spieler dann doch den Nachtkampf nutzen.
- Lichtlevel 1: Der Raum ist erleuchtet und die Spieler koennen ohne
- weitere Lichtquellen sehen...
- Lichtlevel 0: Ein dunkler Raum in dem man mit jeder Fackel sehen kann.
- Lichtlevel -1: man benoetigt zwei einfache Lichtquellen oder Nachtsicht
- um in diesem Raum etwas sehen zu koennen.
- Lichtlevel -2: Man benoetigt schon eine besondere Lichtquelle um in
- diesem Raum noch etwas sehen zu koennen. Solche
- Lichtquellen sind nichts fuer Anfaenger oder mittlere
- Spieler da sie schwer zu beschaffen und in der Regel
- auch einige Handicaps haben.
- Lichtlevel <-2: Der Raum ist wirklich absolut stockduster und
- Lichtquellen die solch einen Raum ausleuchten koennen,
- sind ausserordentlich selten und haben immer ihre
- Tuecken. Diese Lichtlevel sollten nur mit Vorsicht
- genossen werden.
-
-
-SIEHE AUCH
-==========
-
- P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
diff --git a/doc/sphinx/man/props/P_LIGHTDESC b/doc/sphinx/man/props/P_LIGHTDESC
deleted file mode 100644
index e8c52d1..0000000
--- a/doc/sphinx/man/props/P_LIGHTDESC
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_LIGHTDESC
-***********
-
-
-NAME
-====
-
- P_LIGHTDESC "lightdesc"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- String oder Array von Strings mit Adjektiven, die das Leuchten der
- Lichtquelle beschreiben (z.B. leuchtend, brennend, gluehend).
- Standardmaessig ist die Property auf "brennend" gesetzt.
-
- Wenn ein Array angegeben wird, werden die Beschreibungen passend auf
- die Benndauer aufgeteilt und das zur aktuell noch vorhandenen Rest-
- Brenndauer passende Adjektiv ausgegeben. Das Array wird dabei rueck-
- aerts durchlaufen, d.h. fuer eine frisch entzuendete Lichtquelle wird
- der letzte Eintrag des Arrays verwendet (s. Beispiele).
-
-
-BEISPIELE
-=========
-
- Eine einfache Oellampe:
-
- SetProp(P_LIGHTDESC, "angezuendet");
-
- Eine Fackel mit mehreren Brennstadien (aus /items/fackel.c):
-
- SetProp(P_LIGHTDESC, ({"glimmend","flackernd","leicht flackernd",
- "brennend","hell lodernd","frisch angezuendet"}));
-
-
-SIEHE AUCH
-==========
-
- Basisklassen: /std/lightsource.c
- Properties: P_FUEL, P_DO_DESTRUCT, P_LIGHT
- Methoden: AddFuel(L)
-
-
-LETZTE AENDERUNG
-================
-
- 22. Dez. 2015, Arathorn
diff --git a/doc/sphinx/man/props/P_LIGHTED b/doc/sphinx/man/props/P_LIGHTED
deleted file mode 100644
index 31d7709..0000000
--- a/doc/sphinx/man/props/P_LIGHTED
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_LIGHTED
-*********
-
-
-NAME
-====
-
- P_LIGHTED "lighted"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Flag, ob die Lichtquelle in Betrieb ist.
diff --git a/doc/sphinx/man/props/P_LIGHT_ABSORPTION b/doc/sphinx/man/props/P_LIGHT_ABSORPTION
deleted file mode 100644
index 4443a98..0000000
--- a/doc/sphinx/man/props/P_LIGHT_ABSORPTION
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_LIGHT_ABSORPTION
-******************
-
-
-NAME
-====
-
- P_LIGHT_ABSORPTION "light_absorption"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- In Raeumen verteilt sich aufgrund ihrer Groesse das Licht und gerade in
- groesseren Raeumen kann eine kleine Fackel unter Umstaenden nicht mehr
- ausreichen den gesamten Raum auszuleuchten. In diesem Fall kann man
- ueber diese Property das Verhalten des Lichts steuern.
- Ein "normaler" durchschnittlicher Raum hat hier den Defaultwert 1.
-
-
-SIEHE AUCH
-==========
-
- P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
diff --git a/doc/sphinx/man/props/P_LIGHT_MODIFIER b/doc/sphinx/man/props/P_LIGHT_MODIFIER
deleted file mode 100644
index c7741ee..0000000
--- a/doc/sphinx/man/props/P_LIGHT_MODIFIER
+++ /dev/null
@@ -1,75 +0,0 @@
-
-P_LIGHT_MODIFIER
-****************
-
-
-NAME
-====
-
- P_LIGHT_MODIFIER "light_modifier"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Veraendert das Lichtlevel das von einem Lebewesen wahrgenommen wird.
- Der Wert dieser Property wird additiv in P_PLAYER_LIGHT beruecksichtigt.
- Es ist hiermit z.B. moeglich eine Sonnenbrille zu programmieren, diese
- veraendert ja nicht das tatsaechliche Lichtlevel, sondern verdunkelt nur
- die Sicht.
-
-
-ANMERKUNG
-=========
-
- Damit NPCs in der Lage sind solche Gegenstaende richtig einzuschaetzen,
- sollte diese Property in jedem Gegenstand der einen Light-Modifier setzt,
- auch gesetzt sein. Das veraendern dieser Property in Spielern durch NPCs
- oder Gegenstaende ist selbstverstaendlich genehmigungspflichtig.
-
-
-BEISPIELE
-=========
-
- // Ein NPC der auch in relativ dunklen Raeumen mit Lichtlevel -2
- // noch sehen kann...
- create_default_npc(10);
- SetProp(P_LIGHT_MODIFIER, 3);
-
- // Eine Sonnenbrille, die das Lichtlevel um eins senkt.
-
- create()
- {
-
- :
-
- SetProp(P_ARMOUR_TYPE, AT_GLASSES);
- SetProp(P_LIGHT_MODIFIER, -1);
-
- :
-
- }
-
- // Achtung: Falls pl Query- oder Set-Methoden auf P_LIGHT_MODIFIER hat,
- // wird diese Methode hier furchtbar schief gehen und im besten Fall
- // nichts veraendern. In realen Objekten empfiehlt sich zumindest eine
- // Pruefung im Vorfeld, ob eine Query-/Set-Methode gesetzt ist.
- protected void InformWear(object pl, int silent, int all) {
- pl->SetProp(P_LIGHT_MODIFIER, pl->QueryProp(P_LIGHT_MODIFIER) -1);
- }
-
- protected void InformUnwear(object pl, int silent, int all) {
- pl->SetProp(P_LIGHT_MODIFIER, pl->QueryProp(P_LIGHT_MODIFIER) +1);
- }
-
-
-SIEHE AUCH
-==========
-
- P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
diff --git a/doc/sphinx/man/props/P_LIGHT_TRANSPARENCY b/doc/sphinx/man/props/P_LIGHT_TRANSPARENCY
deleted file mode 100644
index 42d0d13..0000000
--- a/doc/sphinx/man/props/P_LIGHT_TRANSPARENCY
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_LIGHT_TRANSPARENCY
-********************
-
-
-NAME
-====
-
- P_LIGHT_TRANSPARENCY "light_transparency"
-
-
-DEFINIERT IN
-============
-
- /sys/container.h
-
-
-BESCHREIBUNG
-============
-
- Wieviel Licht schluckt ein Container, d.h. wieviel Licht dringt aus
- einem Behaelter noch nach draussen. Bei Containern die _nicht_
- transparent sind, liefert eine _query_method hier immer 999 zurueck.
- Defaultmaessig steht diese Property auf 2.
-
-
-SIEHE AUCH
-==========
-
- P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
diff --git a/doc/sphinx/man/props/P_LIGHT_TYPE b/doc/sphinx/man/props/P_LIGHT_TYPE
deleted file mode 100644
index 47abbf4..0000000
--- a/doc/sphinx/man/props/P_LIGHT_TYPE
+++ /dev/null
@@ -1,106 +0,0 @@
-
-P_LIGHT_TYPE
-************
-
-
-NAME
-====
-
- P_LIGHT_TYPE "light_type"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Gibt an, was fuer ein Licht in einem Objekt vorherrscht.
-
-
-
- Es sind verschiedene 'atomare' Lichttypen, vordefiniert:
- LT_MISC Unbestimmt, keine Angaben.
-
- LT_SUN Sonnenlicht.
- LT_MOON Mondlicht
- LT_STARS Sternenlicht.
-
-
-
- LT_DIFFUSE Indirektes Tageslicht. (z.B. im Wald)
-
- LT_CANDLE Kerzenlicht.
- LT_TORCH Fackelschein.
- LT_OPEN_FIRE Sonstiges offenes Feuer. (Lagerfeuer etc.)
-
-
-
- LT_MAGIC Irgendeine magische Lichtquelle.
-
- LT_GLOWING Eine selbstleuchtende Lichtquelle.
-
- LT_DARKNESS Kein wirkliches Licht, aber auch Dunkelheit soll
- explizit gesetzt werden koennen.
-
- In einem Objekt koennen mehrere Lichttypen gesetzt werden. Dies
- geschieht durch logische Oder-Verknuepfungen, siehe man operators.
-
- Wenn in einem Raum mehr als ein Lichttyp gesetzt ist, bedeutet das,
- normalerweise, dass mehrere Lichtquellen verschiedenen Typs im Raum
- sind.
-
- Es gibt zudem noch Lichttypen, die zusammengesetzt sind:
-
- LT_DAYLIGHT Tageslicht (Sonne/Diffuse)
- LT_NATURAL Natuerliches Licht (Daylight/Sterne/Mond)
- LT_ARTIFICIAL Kuenstliches Licht (Magie/Feuer/Gluehen)
- LT_FIRE Feuer (Kerzen/Fackeln/offenes Feuer)
-
-
-BEISPIELE
-=========
-
- Ein Objekt soll ein geheimnisvolles Gluehen von sich geben:
-
-
-
- objekt->SetProp( P_LIGHT_TYPE, LT_GLOWING )
-
- Soll ein Raum beschrieben werden, der durch Sternenlicht erhellt ist,
- in dem aber zusaetzlich noch ein Lagerfeuer brennt, sieht die Syntax
- folgendermassen aus:
-
-
-
- raum->SetProp( P_LIGHT_TYPE, LT_STARS|LT_OPEN_FIRE );
-
- Einer brennenden Hose kann der Lichttyp fuer offenes Feuer mitgegeben
- werden. Es muss jedoch nicht zwingend der Lichttyp fuer magische
- Lichtquellen benutzt werden. Es ist klar, dass es irgendwas mit Magie
- zu tun hat, wenn brennende Spieler durch die Gegend laufen, ohne zu
- schreien. P_LIGHT_TYPE sollte jedoch das fassbare Licht beschreiben.
- LT_MAGIC ist also eher eine Notloesung fuer Licht, dessen Ursache man
- nicht erklaeren kann.
-
-
-ANMERKUNG
-=========
-
- P_LIGHT_TYPE dient ausschliesslich der Beschreibung des Lichtes, das
- vorherrscht. Es ist nicht verbunden mit dem Lichtsystem, und soll es
- auch nicht werden.
-
- Die Empfindlichkeit der Dunkelelfen gegen Sonnenlicht wird ueber diese
- Property gesteuert. Soll ein Raum mit (P_INDOORS==0) so dunkel sein, dass
- sie nicht in Gefahr sind, sollten nicht LT_MISC oder LT_SUN gesetzt
- sein.
-
-
-SIEHE AUCH
-==========
-
- CheckLightType, /std/thing/description.h, operators
diff --git a/doc/sphinx/man/props/P_LIQUID b/doc/sphinx/man/props/P_LIQUID
deleted file mode 100644
index 55672bb..0000000
--- a/doc/sphinx/man/props/P_LIQUID
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_LIQUID
-********
-
-
-NAME
-====
-
- P_LIQUID "w_max_wasserfuellmenge"
-
-
-DEFINIERT IN
-============
-
- /sys/fishing.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_LOCALCMDS b/doc/sphinx/man/props/P_LOCALCMDS
deleted file mode 100644
index 02a3c2a..0000000
--- a/doc/sphinx/man/props/P_LOCALCMDS
+++ /dev/null
@@ -1,25 +0,0 @@
-
-P_LOCALCMDS
-***********
-
-
-NAME
-====
-
- P_LOCALCMDS "localcmds"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Ein Array von Arrays aller Befehle die im Spieler selbst definiert sind.
- ({ ({ "befehl", "funktion", flag, wizlevel }) })
- Wenn flag gesetzt ist werden nur die ersten Zeichen die auch in Befehl
- angegeben sind mit dem Verb ueberprueft. Siehe auch
- add_action("funktion", "befehl", 1) und AddCmd("befehl", "funktion", 1).
diff --git a/doc/sphinx/man/props/P_LOCATION b/doc/sphinx/man/props/P_LOCATION
deleted file mode 100644
index cf2ed6c..0000000
--- a/doc/sphinx/man/props/P_LOCATION
+++ /dev/null
@@ -1,32 +0,0 @@
-
-P_LOCATION
-**********
-
-
-NAME
-====
-
- P_LOCATION "location"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Hier kann der Spieler mit dem Befehl "ort" den Ort setzen,
- von dem er kommt bzw. zu kommen glaubt ;)
- Um wieder den automatisch ermittelten Ort anzuzeigen, ist
- P_LOCATION auf 0 zu setzen.
-
-
-SIEHE AUCH
-==========
-
- ort
-
-Last modified: Sat Jul 01 23:16:00 2000 by Mupfel
diff --git a/doc/sphinx/man/props/P_LOG_INFO b/doc/sphinx/man/props/P_LOG_INFO
deleted file mode 100644
index 0ed186d..0000000
--- a/doc/sphinx/man/props/P_LOG_INFO
+++ /dev/null
@@ -1,55 +0,0 @@
-
-P_LOG_INFO
-**********
-
-
-NAME
-====
-
- P_LOG_INFO "log_info"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wenn diese Property gesetzt ist wird jede Frage, die ein
- Monster nicht beantworten kann, im Report-File des
- zustaendigen Magiers geloggt.
-
- Es ist jedoch auch moeglich, direkt einen Filenamen anzugeben.
- Bei diesen wird dann jedoch automatisch ein /log/ vorne angehaengt.
-
-
-BEISPIELE
-=========
-
- SetProp(P_LOG_INFO,1); // Alle fehlenden Infos dieses
- Monsters werden in das Report-
- File unter /log/report/ gelogt.
-
- SetProp(P_LOG_INFO,"tilly/opa"); // Alle fehlenden Infos dieses
- Monsters werden in das File
- monster unter /log/tilly/ ge-
- logt.
-
-
-BEMERKUNGEN
-===========
-
- Bei nachtraeglich angeschlossenen Monstern empfiehlt sich Variante
- 2 der Beispiele. Ein muehsames Suchen (und Loeschen) der fehlenden
- Infos des Monsters im Report-File eruebrigt sich dann naemlich.
-
-
-SIEHE AUCH
-==========
-
- P_LOG_FILE, write_file(), log_file(), AddInfo
-
-Letzte Aenderung: 13.09.04 Tilly@MorgenGrauen
diff --git a/doc/sphinx/man/props/P_LONG b/doc/sphinx/man/props/P_LONG
deleted file mode 100644
index bad7968..0000000
--- a/doc/sphinx/man/props/P_LONG
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_LONG
-******
-
-
-NAME
-====
-
- P_LONG "long"
-
-
-DEFINIERT IN
-============
-
- <thing/description.h>
-
-
-BESCHREIBUNG
-============
-
- Die Langbeschreibung des Objektes als String oder Closure (diese muss
- einen String zurueckgeben). Die Langbeschreibung wird beim Untersuchen
- des Objektes ausgegeben. Sie sollte umgebrochen sein.
-
- Diese Property bestimmt die Ansicht des Objektes von aussen. Fuer die
- Innen(lang)ansicht von Raeumen muss man P_INT_LONG benutzen.
-
-
-BEMERKUNGEN
-===========
-
- - long() ("untersuche") filtert P_LONG durch process_string()
- -> daher sind Closures moeglich
-
-
-BEISPIELE
-=========
-
- SetProp(P_LONG, "Diese Axt ist eine furchtbare Waffe!\n");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_SHORT, long()
- Sonstiges: P_INT_LONG, process_string(), break_string()
-
-Last modified: Sun May 19 20:10:18 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_LONG_EMPTY b/doc/sphinx/man/props/P_LONG_EMPTY
deleted file mode 100644
index cac74e0..0000000
--- a/doc/sphinx/man/props/P_LONG_EMPTY
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_LONG_EMPTY
-************
-
-
-NAME
-====
-
- P_LONG_EMPTY "w_longdesc_empty"
-
-
-DEFINIERT IN
-============
-
- /sys/fishing.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_LONG_FULL b/doc/sphinx/man/props/P_LONG_FULL
deleted file mode 100644
index 7de6081..0000000
--- a/doc/sphinx/man/props/P_LONG_FULL
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_LONG_FULL
-***********
-
-
-NAME
-====
-
- P_LONG_FULL "w_longdesc_full"
-
-
-DEFINIERT IN
-============
-
- /sys/fishing.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_MAGIC b/doc/sphinx/man/props/P_MAGIC
deleted file mode 100644
index 8994533..0000000
--- a/doc/sphinx/man/props/P_MAGIC
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_MAGIC
-*******
-
-
-NAME
-====
-
- P_MAGIC "magic"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Dieses Objekt ist magisch.
diff --git a/doc/sphinx/man/props/P_MAGIC_RESISTANCE_OFFSET b/doc/sphinx/man/props/P_MAGIC_RESISTANCE_OFFSET
deleted file mode 100644
index 8d270e3..0000000
--- a/doc/sphinx/man/props/P_MAGIC_RESISTANCE_OFFSET
+++ /dev/null
@@ -1,52 +0,0 @@
-
-P_MAGIC_RESISTANCE_OFFSET
-*************************
-
-
-NAME
-====
-
- P_MAGIC_RESISTANCE_OFFSET "mag_res_offset"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Mapping mit ganzzahligen Prozentwerten in 0.01%-Schritten
- (0-10000) zur Resistenz/Empfindlichkeit gegen bestimmte
- Magieklassen.
-
- Die Property wird in der Methode SpellDefend() ausgewertet und
- fuer einen auf den NPC/Spieler gesprochenen Spell werden die
- Werte fuer all dessen Magieklassen aufaddiert. Daher sind auch
- negative Werte fuer einzelne Magieklassen sinnvoll.
-
- P_MAGIC_RESISTANCE_OFFSET und SpellDefend werden von den Spellbooks
- ausgewertet. Der Einfluss ist daher abhaengig vom Spellbook.
-
-
-BEISPIELE
-=========
-
- // Goblins
- SetProp(P_MAGIC_RESISTANCE_OFFSET,
- ([MT_ANGRIFF:600, // 6% Resistenz gegen Angriff
- MT_ILLUSION:500, // 6% Resistenz gegen Illusionen
- MT_VERWANDLUNG:-300, // 3% Empfindlichkeit
- MT_HELLSICHT:-750, // 7.5% Empfindlichkeit
- MT_BEHERRSCHUNG:250])); // 2.5% Resistenz
-
-
-SIEHE AUCH
-==========
-
- Verwandt: SpellDefend
- Aehnlich: P_NOMAGIC
-
-29.Dez 2007 Gloinson
diff --git a/doc/sphinx/man/props/P_MAILADDR b/doc/sphinx/man/props/P_MAILADDR
deleted file mode 100644
index 32556a7..0000000
--- a/doc/sphinx/man/props/P_MAILADDR
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_MAILADDR
-**********
-
-
-NAME
-====
-
- P_MAILADDR "mailaddr"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- EMailadresse des Spielers.
diff --git a/doc/sphinx/man/props/P_MAP_RESTRICTIONS b/doc/sphinx/man/props/P_MAP_RESTRICTIONS
deleted file mode 100644
index ee9e620..0000000
--- a/doc/sphinx/man/props/P_MAP_RESTRICTIONS
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_MAP_RESTRICTIONS
-******************
-
-
-NAME
-====
-
- P_MAP_RESTRICTIONS "lib_p_map_restrictions"
-
-
-DEFINIERT IN
-============
-
- /sys/rooms.h
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Property laesst sich beeinflussen, welche Informationen ueber
- den Raum das Morgengrauen dem Client zukommen laesst (zur Zeit nur via
- GMCP, aber es mag irgendwann auch andere Wege geben).
- Beispielsweise sollen vielleicht in einem Labyrinth keine eindeutigen
- Raum-IDs uebermittelt werden.
-
- Als Werte duerfen alle MR_-Konstanten aus <rooms.h> verwendet werden.
- Diese duerfen auch ver-ODER-t werden, wenn mehr als eine davon gelten
- soll.
-
- Moegliche Werte:
- MR_NOUID - verhindert, dass die eindeutige Raum-ID uebertragen wird.
- MR_NOINFO - verhindert, dass ueberhaupt irgendetwas an den Client
- uebermittelt wird. Damit kriegt er ggf. auch nicht mit,
- dass er Raum gewechselt wurde. Ist fuer Sequenzraeume
- gedacht. Bitte SEHR sparsam einsetzen.
-
- Die Verwendung dieser Property sollte der Ausnahmefall sein!
-
-
-BEISPIEL
-========
-
- (in einem Raum)
- SetProp(P_MAP_RESTRICTIONS, MR_NOUID);
-
- Nun bekommt der Client zwar die Kurzbeschreibung des Raums, die Region
- und die sichtbaren Ausgaenge, aber keine UID mehr uebermittelt.
-
-
-SIEHE AUCH
-==========
-
- gmcp
-
-23.02.2013, Zesstra
diff --git a/doc/sphinx/man/props/P_MARRIED b/doc/sphinx/man/props/P_MARRIED
deleted file mode 100644
index 7cafa6f..0000000
--- a/doc/sphinx/man/props/P_MARRIED
+++ /dev/null
@@ -1,28 +0,0 @@
-
-P_MARRIED
-*********
-
-
-NAME
-====
-
- P_MARRIED "married"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt einen String mit der uid des Partners
- (sofern vorhanden)
-
-
-SIEHE AUCH
-==========
-
- scheidung
diff --git a/doc/sphinx/man/props/P_MATERIAL b/doc/sphinx/man/props/P_MATERIAL
deleted file mode 100644
index 4ea4032..0000000
--- a/doc/sphinx/man/props/P_MATERIAL
+++ /dev/null
@@ -1,99 +0,0 @@
-
-P_MATERIAL
-**********
-
-
-NAME
-====
-
- P_MATERIAL "material"
-
-
-DEFINIERT IN
-============
-
- <thing/material.h>
-
-
-BESCHREIBUNG
-============
-
- Mapping mit prozentualen Anteilen von Materialien, aus denen ein Objekt
- besteht.
-
-
-BEMERKUNGEN
-===========
-
- Bei SetProp kann man zu Vereinfachung auch ein einzelnes Material oder
- ein Array aus Materialien angeben. Die Anteile werden dann
- gleichmaessig verteilt.
-
-
-BEISPIELE
-=========
-
- // 100% Eis
- SetProp(P_MATERIAL, MAT_ICE);
- // QueryProp(P_MATERIAL) -> ([MAT_ICE:100])
-
- // 50% Eis, 50% Misc-Holz
- SetProp(P_MATERIAL, ({ MAT_ICE, MAT_MISC_WOOD }));
- // QueryProp(P_MATERIAL) -> ([MAT_ICE:50, MAT_MISC_WOOD: 50])
-
- // 60% Eis, 40% Misc-Holz
- SetProp(P_MATERIAL, ([ MAT_ICE: 60, MAT_MISC_WOOD: 40 ]));
-
- // 100% Papier
- SetProp(P_MATERIAL, MAT_PAPER);
- // QueryProp(P_MATERIAL) -> ([MAT_PAPER:100])
-
- // 50% Silber, 50% Gold
- SetProp(P_MATERIAL, ({MAT_SILVER, MAT_GOLD}))
- // QueryProp(P_MATERIAL) -> ([MAT_SILVER:50,MAT_GOLD:50])
-
- // ein weiser Schmied, der was daraus macht:
- int i;
- string *mat, mname, mgroup;
- mat=m_indices(ob->QueryProp(P_MATERIAL));
- i=sizeof(mat);
-
- write("Der Schmied sagt: "+ob->Name(WER)+" besteht aus ...\n");
- while(i--) {
- // den Namen erkennen/aussprechen:
- // Materialien werden allgemein ganz schlecht erkannt (zu 5%), aber
- // alles aus Metall wird zu +100% gut erkannt ...
- mname=MATERIALDB->MaterialName(mat[i], WER,
- ({5, ([MATERIAL_SYMMETRIC_RECOGNIZABILITY:
- ({MATGROUP_METAL, 100})])}));
-
- // und nur Metalle analysieren ...
- if(MATERIALDB->MaterialGroup(([mat[i]:100]),MATGROUP_METAL)>=100) {
- int j;
- string *mgr;
- mgr=MATERIALDB->GetMatMembership(mat[i]);
- j=sizeof(mgr);
- mgroup=" gehoert zu ";
- while(j--) {
- mgroup+=MATERIALDB->GroupName(mgr[j]);
- if(j>0) mgroup+=", ";
- }
- } else mgroup=" kenne ich nicht";
- printf("%-12.12s: %s\n",mname, mgroup);
- }
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: /sys/thing/material.h
- Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
- Listen: AllMaterials(), AllGroups(), Dump()
- materialliste, materialgruppen
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
- Sonstiges: P_MATERIAL_KNOWLEDGE
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_MATERIAL_KNOWLEDGE b/doc/sphinx/man/props/P_MATERIAL_KNOWLEDGE
deleted file mode 100644
index 0694fef..0000000
--- a/doc/sphinx/man/props/P_MATERIAL_KNOWLEDGE
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_MATERIAL_KNOWLEDGE
-********************
-
-
-NAME
-====
-
- P_MATERIAL_KNOWLEDGE "material_knowledge"
-
-
-DEFINIERT IN
-============
-
- <thing/material.h>
-
-
-BESCHREIBUNG
-============
-
- Mapping, Closure oder Integer mit Regeln zur Materialienerkennung. Die
- Regeln sind in "man materialerkennung" zu lesen.
-
- Diese werden bei Angabe eines Spielerobjektes in MaterialList() oder
- MaterialName() an diesem abgefragt und hat Einfluss darauf, ob ein
- Material genau, generell oder gar nicht erkannt wird.
-
- In den einzelnen Rassenshells sind Defaultwerte dafuer angegeben.
-
-
-BEISPIELE
-=========
-
- // Erkennungsbonus auf diverse Materialgruppen und
- // Erkennungsbonus/-malus auf biologische/nichtbiologische Materialien
- SetProp(P_MATERIAL_KNOWLEDGE,
- ([MATGROUP_WOOD:20,
- MATGROUP_METAL:20,
- MATGROUP_ELEMENTAL:20,
- MATGROUP_CLOTH:20,
- MATERIAL_SYMMETRIC_RECOGNIZABILITY: ({MATGROUP_BIO,5})]));
-
-
-SIEHE AUCH
-==========
-
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Methoden: QueryMaterial(), QueryMaterialGroup(), MaterialList(),
- Listen: AllMaterials(), AllGroups(), Dump()
- materialliste, materialgruppen
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
-
-7. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_MAX_ALCOHOL b/doc/sphinx/man/props/P_MAX_ALCOHOL
deleted file mode 100644
index 541972f..0000000
--- a/doc/sphinx/man/props/P_MAX_ALCOHOL
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_MAX_ALCOHOL
-*************
-
-
-NAME
-====
-
- P_MAX_ALCOHOL "max_alcohol"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert fuer den maximalen Grad der Betrunkenheit eines
- Lebewesens.
-
-
-ANMERKUNGEN
-===========
-
- Der Wert von P_MAX_ALCOHOL ist bei den einzelnen Rassen verschieden,
- ebenso wie der fuer P_ALCOHOL_DELAY. Die genauen Werte stehen in den
- Rassen-Shells (/std/shells).
-
-
-SIEHE AUCH
-==========
-
- P_ALCOHOL, P_ALCOHOL_DELAY, drink_alcohol,
- P_MAX_FOOD, P_MAX_DRINK
-
-Last modified: Tue Dec 18 12:16:10 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_MAX_DRINK b/doc/sphinx/man/props/P_MAX_DRINK
deleted file mode 100644
index 33fdeb8..0000000
--- a/doc/sphinx/man/props/P_MAX_DRINK
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_MAX_DRINK
-***********
-
-
-NAME
-====
-
- P_MAX_DRINK "max_drink"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert fuer die maximale Saettigung eines Lebewesens mit
- Getraenken.
-
-
-ANMERKUNGEN
-===========
-
- Der Wert von P_MAX_DRINK ist bei den einzelnen Rassen verschieden,
- ebenso wie der fuer P_DRINK_DELAY. Die genauen Werte stehen in den
- Rassen-Shells (/std/shells).
-
-
-SIEHE AUCH
-==========
-
- P_DRINK, P_DRINK_DELAY, drink_soft,
- P_MAX_FOOD, P_MAX_ALCOHOL
-
-Last modified: Tue Dec 18 12:16:10 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_MAX_FOOD b/doc/sphinx/man/props/P_MAX_FOOD
deleted file mode 100644
index fa7f661..0000000
--- a/doc/sphinx/man/props/P_MAX_FOOD
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_MAX_FOOD
-**********
-
-
-NAME
-====
-
- P_MAX_FOOD "max_food"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert fuer die maximale Saettigung eines Lebewesens.
-
-
-ANMERKUNGEN
-===========
-
- Der Wert von P_MAX_FOOD ist bei den einzelnen Rassen verschieden,
- ebenso wie der fuer P_FOOD_DELAY. Die genauen Werte stehen in den
- Rassen-Shells (/std/shells).
-
-
-SIEHE AUCH
-==========
-
- P_FOOD, P_FOOD_DELAY, eat_food,
- P_MAX_DRINK, P_MAX_ALCOHOL
-
-Last modified: Tue Dec 18 12:16:10 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_MAX_HANDS b/doc/sphinx/man/props/P_MAX_HANDS
deleted file mode 100644
index 4c65afa..0000000
--- a/doc/sphinx/man/props/P_MAX_HANDS
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_MAX_HANDS
-***********
-
-
-NAME
-====
-
- P_MAX_HANDS "max_hands"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der Haende, die ein Wesen hat.
-
-
-BEMERKUNGEN
-===========
-
- An dieser Propertie sollte bei Spielern nur im Rahmen der
- Gilden 'gespielt' werden.
-
- Fuer Magier, die in ihren Npc gerne alle Properties setzen,
- gilt folgendes:
-
- Setzt diese Propertie NIE auf 0 !
-
- Ohne Haende wird kein Npc irgendeinen Spieler angreifen koennen.
-
-
-SIEHE AUCH
-==========
-
- P_HANDS, P_HANDS_USED_BY
- P_USED_HANDS, P_FREE_HANDS
- UseHands, FreeHands
-
-1.Feb.2004 Gloinson
diff --git a/doc/sphinx/man/props/P_MAX_HP b/doc/sphinx/man/props/P_MAX_HP
deleted file mode 100644
index fcb3cb0..0000000
--- a/doc/sphinx/man/props/P_MAX_HP
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_MAX_HP
-********
-
-
-NAME
-====
-
- P_MAX_HP "max_hp"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Maximale Anzahl der Lebenspunkte.
-
-
-SIEHE AUCH
-==========
-
- Props: P_HP
- Verwandt: UpdateAttributes()
-
-21.April 2006 Gloinson
diff --git a/doc/sphinx/man/props/P_MAX_OBJECTS b/doc/sphinx/man/props/P_MAX_OBJECTS
deleted file mode 100644
index 68c008f..0000000
--- a/doc/sphinx/man/props/P_MAX_OBJECTS
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_MAX_OBJECTS
-*************
-
-
-NAME
-====
-
- P_MAX_OBJECTS "max_objects"
-
-
-DEFINIERT IN
-============
-
- /sys/container.h
-
-
-BESCHREIBUNG
-============
-
- Maximale Anzahl an Objekten, die in einen Container passen.
- P_MAX_OBJECTS sollte im Normfall zwischen 0 - 100 liegen.
-
-
-BEMERKUNGEN
-===========
-
- Soll es sich um einen herausragenden Container handeln, der zum
- Beispiel das Gewicht um mehr als 50% reduziert, sollte P_MAX_OBJECTS
- einen kleineren Wert haben. Das Verhaeltnis von P_MAX_WEIGHT,
- P_WEIGHT_PERCENT und dieser Property sollte stimmen.
-
-
-BEISPIELE
-=========
-
- Als Beispiel sollte man sich das Postpaket ansehen und sich an dessen
- Werten orientieren (/p/service/loco/obj/parcel).
-
-
-SIEHE AUCH
-==========
-
- P_MAX_WEIGHT, P_WEIGHT_PERCENT, P_LIGHT_TRANSPARENCY, container
diff --git a/doc/sphinx/man/props/P_MAX_PASSENGERS b/doc/sphinx/man/props/P_MAX_PASSENGERS
deleted file mode 100644
index 32e5f27..0000000
--- a/doc/sphinx/man/props/P_MAX_PASSENGERS
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_MAX_PASSENGERS
-****************
-
-
-NAME
-====
-
- P_MAX_PASSENGERS "maxpass"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert fuer die maximale Anzahl von Wesen in dem Transporter.
- 0 bedeutet unbeschaenkte Spielerzahl.
diff --git a/doc/sphinx/man/props/P_MAX_POISON b/doc/sphinx/man/props/P_MAX_POISON
deleted file mode 100644
index 0d39dc4..0000000
--- a/doc/sphinx/man/props/P_MAX_POISON
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_MAX_POISON
-************
-
-
-NAME
-====
-
- P_MAX_POISON "max_poison"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Maximale Vergiftung
diff --git a/doc/sphinx/man/props/P_MAX_SP b/doc/sphinx/man/props/P_MAX_SP
deleted file mode 100644
index 7f7aa43..0000000
--- a/doc/sphinx/man/props/P_MAX_SP
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_MAX_SP
-********
-
-
-NAME
-====
-
- P_MAX_SP "max_sp"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Maximale Anzahl der Magiepunkte.
-
-
-SIEHE AUCH
-==========
-
- Props: P_SP
- Verwandt: UpdateAttributes()
-
-21.April 2006 Gloinson
diff --git a/doc/sphinx/man/props/P_MAX_WEIGHT b/doc/sphinx/man/props/P_MAX_WEIGHT
deleted file mode 100644
index abd0942..0000000
--- a/doc/sphinx/man/props/P_MAX_WEIGHT
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_MAX_WEIGHT
-************
-
-
-NAME
-====
-
- P_MAX_WEIGHT "max_weight"
-
-
-DEFINIERT IN
-============
-
- /sys/container.h
-
-
-BESCHREIBUNG
-============
-
- Maximales Gewicht in Gramm, das in dem Container verstaut werden
- kann.
-
-
-BEMERKUNGEN
-===========
-
- Das Verhaeltnis von P_WEIGHT_PERCENT, P_MAX_OBJECTS und dieser Property
- sollte stimmen. Eine feste Grenze gibt es nicht. Als Beispiel kann
- das Postpaket von Loco unter /p/servive/loco/obj herangezogen werden.
- Bessere Werte als in diesem sollte es nicht, und wenn doch nur gut be-
- gruendet, geben.
-
-
-SIEHE AUCH
-==========
-
- P_WEIGHT_PERCENT, P_MAX_OBJECTS, P_LIGHT_TRANSPARENCY, container
diff --git a/doc/sphinx/man/props/P_MESSAGE_BEEP b/doc/sphinx/man/props/P_MESSAGE_BEEP
deleted file mode 100644
index 6ecf718..0000000
--- a/doc/sphinx/man/props/P_MESSAGE_BEEP
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_MESSAGE_BEEP
-**************
-
-
-NAME
-====
-
- P_MESSAGE_BEEP "message_beep"
-
-
-DEFINIERT IN
-============
-
- /sys/player/comm.h
-
-
-BESCHREIBUNG
-============
-
- Wertebereich: int=0..3600 (Sekunden)
- Wenn gesetzt wird in der Kommunikation des Spielers in den angegebenen
- Zeitraeumen ein Signalton ausgegeben. Wird in player/comm.c in comm_beep()
- verarbeitet.
- Ausgabe erfolgt nur, wenn P_VISUALBELL nicht gesetzt ist.
- Wird im Spielerobjekt gespeichert!
-
-
-SIEHE AUCH
-==========
-
- klingelton, ton, P_VISUALBELL, P_MESSAGE_LAST_BEEP
-
-
-LETZTE AENDERUNG
-================
-
- 16. Mai 2007 Ennox
diff --git a/doc/sphinx/man/props/P_MESSAGE_PREPEND b/doc/sphinx/man/props/P_MESSAGE_PREPEND
deleted file mode 100644
index be54d65..0000000
--- a/doc/sphinx/man/props/P_MESSAGE_PREPEND
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_MESSAGE_PREPEND
-*****************
-
-
-NAME
-====
-
- P_MESSAGE_PREPEND "message_prepend"
-
-
-DEFINIERT IN
-============
-
- /sys/player/comm.h
-
-
-BESCHREIBUNG
-============
-
- Wertebereich: int = 0,1
- Wenn vom Ziel eingeschaltet, wird von teile mit (_tell) und sag (_communicate) das
- BS_PREPEND_INDENT Flag fuer break_string genutzt, um den Indent (Sender) ggf.
- vor dem Textblock anzuzeigen.
- Wird im Spielerobjekt gespeichert!
-
-
-SIEHE AUCH
-==========
-
- grafik aus, break_string, senderwiederholung
-
-
-LETZTE AENDERUNG
-================
-
- 16. Mai 2007 Ennox
diff --git a/doc/sphinx/man/props/P_MIN_STOCK b/doc/sphinx/man/props/P_MIN_STOCK
deleted file mode 100644
index 3be8d4e..0000000
--- a/doc/sphinx/man/props/P_MIN_STOCK
+++ /dev/null
@@ -1,55 +0,0 @@
-
-P_MIN_STOCK
-***********
-
-
-NAME
-====
-
- P_MIN_STOCK "min_stock"
-
-
-DEFINIERT IN
-============
-
- /sys/bank.h
-
-
-BESCHREIBUNG
-============
-
- P_MIN_STOCK enthaelt die Anzahl an Objekten, die ein Lager eines
- Ladens minimal behaelt. Standardmaessig entspricht dies 20 Objekten
- und sollte auch nicht wesentlich erhoeht werden. Nur fuer
- Anfaengergebiete waeren Werte zwischen 20 und 60 akzeptabel. In die
- Berechnung der Anzahl von Objekten gehen keine Objekte ein, die im
- Laden mittels AddFixedObject() staendig verfuegbar gemacht worden
- sind und auch keine Objekte, die per AddItem() im Lager hinzugefuegt
- wurden und nach jedem Reset aufgefrischt werden.
- Bei jedem Reset wird nun aus Speicher- und Laggruenden das Lager um
- eine bestimmte Prozentzahl an Objekten dezimiert. Entscheidend
- dafuer ist der Wert in der Property P_STORE_CONSUME.
- Beide hier erwaehnten Properties sollten ueberigens nur mittels
- QueryProp/SetProp ausgelesen bzw. veraendert werden.
-
-
-BEISPIEL
-========
-
- In '/std/store.c' befindet sich bereits ein gutes Beispiel, da dort
- der Standardwert von 20 Objekten bereitgestellt wird:
- create()
- { ...
- SetProp(P_MIN_STOCK,20);
- }
- Diesen Wert kann man in einem davon abgeleiteten eigenen Lager
- natuerlich auch veraendern.
-
-
-SIEHE AUCH
-==========
-
- P_STORE_CONSUME, SetStorageRoom(), /std/store.c, /std/shop.c
- AddItem(), RemoveItem(), AddFixedObject(), RemoveFixedObject()
-
-Last modified: 19-Jun-2015, Arathorn
diff --git a/doc/sphinx/man/props/P_MMSGIN b/doc/sphinx/man/props/P_MMSGIN
deleted file mode 100644
index 98d37f3..0000000
--- a/doc/sphinx/man/props/P_MMSGIN
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_MMSGIN
-********
-
-
-NAME
-====
-
- P_MMSGIN "mmsgin"
-
-
-DEFINIERT IN
-============
-
- /sys/player/moving.h
-
-
-BESCHREIBUNG
-============
-
- String mit der Meldung, die beim Verlassen eines Raumes mit M_TPORT
- an die uebrigen Anwesenden ausgegeben wird.
diff --git a/doc/sphinx/man/props/P_MMSGOUT b/doc/sphinx/man/props/P_MMSGOUT
deleted file mode 100644
index 6035ba8..0000000
--- a/doc/sphinx/man/props/P_MMSGOUT
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_MMSGOUT
-*********
-
-
-NAME
-====
-
- P_MMSGOUT "mmsgout"
-
-
-DEFINIERT IN
-============
-
- /sys/player/moving.h
-
-
-BESCHREIBUNG
-============
-
- String mit der Meldung, die beim Betreten eines Raumes mit M_TPORT
- an die uebrigen Anwesenden ausgegeben wird.
diff --git a/doc/sphinx/man/props/P_MSGIN b/doc/sphinx/man/props/P_MSGIN
deleted file mode 100644
index f5d90f8..0000000
--- a/doc/sphinx/man/props/P_MSGIN
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_MSGIN
-*******
-
-
-NAME
-====
-
- P_MSGIN "msgin"
-
-
-DEFINIERT IN
-============
-
- /sys/player/moving.h
-
-
-BESCHREIBUNG
-============
-
- String mit der Meldung, die beim Betreten eines Raumes mit M_GO
- an die uebrigen Anwesenden ausgegeben wird.
diff --git a/doc/sphinx/man/props/P_MSGOUT b/doc/sphinx/man/props/P_MSGOUT
deleted file mode 100644
index 95a8545..0000000
--- a/doc/sphinx/man/props/P_MSGOUT
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_MSGOUT
-********
-
-
-NAME
-====
-
- P_MSGOUT "msgout"
-
-
-DEFINIERT IN
-============
-
- /sys/player/moving.h
-
-
-BESCHREIBUNG
-============
-
- String mit der Meldung, die beim Verlassen eines Raumes mit M_GO
- an die uebrigen Anwesenden ausgegeben wird.
diff --git a/doc/sphinx/man/props/P_MSG_PROB b/doc/sphinx/man/props/P_MSG_PROB
deleted file mode 100644
index b4465df..0000000
--- a/doc/sphinx/man/props/P_MSG_PROB
+++ /dev/null
@@ -1,35 +0,0 @@
-
-P_MSG_PROB
-**********
-
-
-NAME
-====
-
- P_MSG_PROB "msg_prob"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- Parameter fuer die Wartezeit in Sekunden bis zur naechsten Ausgabe
- einer Raumnachricht.
- Wird in AddRoomMessage() explizit mitgesetzt. Koennte natuerlich von
- einer Nachrichtenmethode auch regelmaessig geaendert werden, um
- mehr Zufall in die Intervalle zu bringen.
-
-
-SIEHE AUCH
-==========
-
- LFuns: AddRoomMessage()
- Props: P_ROOM_MSG, P_MSG_PROB
- Verwandt: call_out()
-
-2.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_MUD_NEWBIE b/doc/sphinx/man/props/P_MUD_NEWBIE
deleted file mode 100644
index 71801eb..0000000
--- a/doc/sphinx/man/props/P_MUD_NEWBIE
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_MUD_NEWBIE
-************
-
-
-NAME
-====
-
- P_MUD_NEWBIE "_lib_mud_newbie"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Der Spieler hat bei Erstellung des Charakters angegeben, noch nie in einem
- Mud gespielt zu haben. In diesem Fall enthaelt die Property den
- Zeitstempel der Charaktererstellung.
-
- ACHTUNG: Diese Prop wird nicht gespeichert, d.h. nachdem ein solcher
- Spieler "ende" gemacht hat oder ein Reboot erfolgte, ist diese Information
- verloren.
-
-
-SIEHE AUCH
-==========
diff --git a/doc/sphinx/man/props/P_MURDER_MSG b/doc/sphinx/man/props/P_MURDER_MSG
deleted file mode 100644
index c565cfa..0000000
--- a/doc/sphinx/man/props/P_MURDER_MSG
+++ /dev/null
@@ -1,83 +0,0 @@
-
-P_MURDER_MSG
-************
-
-
-NAME
-====
-
- P_MURDER_MSG "murder_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property kann man einen String oder eine Closure ablegen
- dessen Wert bzw. deren Resultat beim Tod des NPCs auf dem
- Moerder-Kanal erscheint.
- Normalerweise ist die Property nicht gesetzt, woraufhin zufaellig
- eine Meldung generiert wird.
-
- Ob der Tod eines NPCs auf dem Moerder-Kanal erscheint, haengt davon ab,
- wie oft und welche Art von NPCs in der letzten Zeit getoetet wurden. Zum
- Beispiel ist es eher selten, dass ein schwacher NPC auf dem Kanal
- erscheint, wenn kuerzlich viele starke NPCs getoetet wurden. Allerdings
- kann man auf diese Regelung mittels der Property P_FORCE_MURDER_MSG
- Einfluss nehmen.
-
- Wird in einen String der Platzhalter %s eingefuegt, so erscheint an der
- Stelle spaeter der Name des Moerders.
-
-
-BEISPIELE
-=========
-
- // Zum Beispiel koennte man ja bei einer Ratte, die getoetet wird,
- // folgendes auf dem Moerder-Kanal ausgeben lassen:
- SetProp(P_MURDER_MSG,
- "Ratten aller MUDs, vereinigt euch gegen %s!");
-
-
- // Um auch mal eine Closure zu zeigen: die Ratte koennte auch ihre
- // Meldung erst bei ihrem Tod erstellen lassen:
- private string moerder_meldung() {
- return ({"Achweh!", "Au!", "Weia!"})[random(3)];
- }
-
- SetProp(P_MURDER_MSG, #'moerder_meldung);
-
-
-BEMERKUNGEN
-===========
-
- - P_NOCORPSE:
- Ist in dem NPC die Property P_NOCORPSE gesetzt, so wird die
- Moerdermeldung nicht auf dem Kanal gesendet, da diese Ausgabe ueber
- /std/corpse laeuft.
- Will man dennoch eine Meldung, so sollte man /std/corpse im die()
- selbst clonen, daran Identify(this_object()) rufen und das geclonte
- Objekt wieder entsorgen.
-
- - Closures:
- Closures bieten sich an, wenn ein zentrales Objekt fuer mehrere NPCs
- bestimmte Moerdermeldungen generieren soll. Dann muss nur noch bei
- den NPCs die Closure, die auf die erstellende Methode zeigt gesetzt
- werden.
-
-
-SIEHE AUCH
-==========
-
- Tod: die(L)
- Verwandt: P_FORCE_MURDER_MSG
- Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_DIE_MSG
- P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /std/corpse.c
-
-30. Mai 2006, Gloinson
diff --git a/doc/sphinx/man/props/P_M_ATTR_MOD b/doc/sphinx/man/props/P_M_ATTR_MOD
deleted file mode 100644
index d279484..0000000
--- a/doc/sphinx/man/props/P_M_ATTR_MOD
+++ /dev/null
@@ -1,64 +0,0 @@
-
-P_M_ATTR_MOD
-************
-
-
-NAME
-====
-
- P_M_ATTR_MOD "magic_attributes_modifier"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- Mapping, das die Attribute des Spielers veraendert, der diese Ruestung
- bzw. Waffe traegt bzw. benutzt.
-
- Zu beachten:
- P_M_ATTR_MOD kann problemlos durch ein SetProp() gesetzt werden. Es wird
- nur dann beruecksichtigt, wenn die Ruestung/Waffe getragen/benutzt wird.
- Beim Tragen/Ausziehen/Zuecken/Wegstecken wird im Spieler automatisch
- UpdateAttributes() aufgerufen.
-
- Fuer Krankheiten etc. oder Objekte, deren *Besitz* allein schon die
- Attribute veraendern sollen, verwendet man besser P_X_ATTR_MOD.
-
- P_X_ATTR_MOD und P_M_ATTR_MOD duerfen einen gemeinsamen kumulierten
- positiven Grenzwert nicht ueberschreiten. Dieser Grenzwert,
- CUMULATIVE_ATTR_LIMIT, ist in /sys/living/attributes.h definiert.
-
-
-BEMERKUNGEN
-===========
-
- Die Werte sollten moeglichst nicht dynamisch geaendert werden.
- Wenn doch, muss mit TestLimitViolation() am Spieler auf Validitaet
- geprueft und ggf. mit UpdateAttributes() an ihm upgedatet werden.
-
-
-BEISPIELE
-=========
-
- // Dem Spieler, der das Objekt benutzt, wird 2 von A_INT abgezogen und
- // dafuer 1 auf A_STR aufaddiert.
- SetProp(P_M_ATTR_MOD, ([A_INT:-2, A_STR:1]) );
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_X_HEALTH_MOD, P_M_HEALTH_MOD, P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
- P_TIMED_ATTR_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-02.02.2016, Gloinson
diff --git a/doc/sphinx/man/props/P_M_HEALTH_MOD b/doc/sphinx/man/props/P_M_HEALTH_MOD
deleted file mode 100644
index cdc3fd4..0000000
--- a/doc/sphinx/man/props/P_M_HEALTH_MOD
+++ /dev/null
@@ -1,64 +0,0 @@
-
-P_M_HEALTH_MOD
-**************
-
-
-NAME
-====
-
- P_M_HEALTH_MOD "magic_health_modifier"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- Mapping, mit dem die maximalen Lebenspunkte und Magiepunkte eines
- Spielers veraendert werden, der diese Ruestung/Waffe traegt/benutzt. Im
- Gegensatz zu P_M_ATTR_MOD erfolgt hier jedoch keine Blockade.
-
- Zu beachten: P_M_HEALTH_MOD kann problemlos durch ein SetProp() gesetzt
- werden, es wird nur beruecksichtigt, wenn die Ruestung/Waffe
- getragen/benutzt wird. Beim tragen/ausziehen/zuecken/wegstecken wird im
- Spieler automatisch UpdateAttributes() aufgerufen.
-
- Fuer Krankheiten etc. verwendet man besser die Property P_X_HEALTH_MOD.
-
- Bitte beachten: Die positiven Modifier werden nicht mehr 1:1 auf die
- Lebens- und Magiepunkte draufaddiert. Stattdessen wird nur noch ein
- gewisser Teil dort hinzuaddiert, der mit groesserer Menge von Punkten
- zunimmt, und im unteren Bereich grob dem Wert entspricht. Das
- theoretische Maximum ist insgesamt 149.
-
-
-BEMERKUNGEN
-===========
-
- Die Werte sollten moeglichst nicht dynamisch geaendert werden.
- Wenn doch, muss mit TestLimitViolation() am Spieler auf Validitaet
- geprueft werden und mit UpdateAttributes() an ihm ggf. upgedatet.
-
-
-BEISPIEL
-========
-
- SetProp(P_M_HEALTH_MOD,([P_HP:5,P_SP:-5]));
- // Dem Spieler, der das Objekt benutzt, wird P_MAX_HP um 5 erhoeht und
- // P_MAX_SP um 5 erniedrigt.
-
-
-SIEHE AUCH
-==========
-
- P_X_HEALTH_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, balance
-
-
-LETZTE AeNDERUNG
-================
-
- Fre,11.05.2007, 00:20 von Humni
diff --git a/doc/sphinx/man/props/P_NAME b/doc/sphinx/man/props/P_NAME
deleted file mode 100644
index 1fdc261..0000000
--- a/doc/sphinx/man/props/P_NAME
+++ /dev/null
@@ -1,84 +0,0 @@
-
-P_NAME
-******
-
-
-NAME
-====
-
- P_NAME "name"
-
-
-DEFINIERT IN
-============
-
- <thing/description.h>
-
-
-BESCHREIBUNG
-============
-
- In dieser Property wird der Name eines Objektes vermerkt. Wenn der Name
- regelmaessig dekliniert wird, reicht ein einfacher String. Wird der
- Name unregelmaessig dekliniert, so kann man ein Array von vier Strings
- mit dem Namen im Nominativ, Genitiv, Dativ und Akkusativ (in dieser
- Reihenfolge) angeben.
-
- Die Funktion name() behandelt recht viele Sonderfaelle; man sollte den
- Namen also erst einmal in der Form eines einzelnen Strings pruefen.
-
- Eine Sonderrolle nehmen Unit-Objekte ein: Hier kann man einen Namen
- fuer den Singular und einen Namen fuer den Plural vergeben.
-
- Setzt man P_NAME eines Unit-Objekts auf einen einfachen String, so wird
- dieser als Name sowohl im Singular als auch im Plural verwendet.
-
- Uebergibt man ein Array von Strings, so wird der erste Eintrag fuer den
- Singular und der zweite Eintrag fuer den Plural benutzt.
-
- Bei Unit-Objekten ist es nicht moeglich, auch noch zwischen den
- verschiedenen Faellen zu unterscheiden.
-
-
-BEMERKUNGEN
-===========
-
- Diese Property sollte nur den reinen Namen enthalten; will man dem
- Namen noch Adjektive voranstellen, so sollte man dies mit P_NAME_ADJ
- bewerkstelligen, also statt
-
- SetProp(P_NAME, ({ "alter Hut", "alten Huts",
- "alten Hut", "alten Hut" }) );
-
- besser
-
- SetProp(P_NAME, "Hut");
- SetProp(P_NAME_ADJ, "alt");
-
- Bei Lebewesen wird lower_case(P_NAME) (bei Arrays das erste Element
- daraus) automatisch als LivingName gesetzt.
-
-
-BEISPIELE
-=========
-
- Ein regelmaessig deklinierbarer Name:
-
- SetProp(P_NAME, "Arkshat");
-
- Hier ein Beispiel fuer einen unregelmaessig deklinierbaren Namen:
-
- SetProp(P_NAME, ({ "Drache", "Drachen", "Drachen", "Drachen" }));
-
- Und schliesslich der Name eines allseits bekannten Unit-Objektes:
-
- SetProp(P_NAME, ({ "Muenze", "Muenzen" }));
-
-
-SIEHE AUCH
-==========
-
- /std/thing/description.c, name(), P_NAME_ADJ, set_living_name(),
- find_living(), find_livings()
-
-Last modified: 19. Okt. 2015, Arathorn.
diff --git a/doc/sphinx/man/props/P_NAME_ADJ b/doc/sphinx/man/props/P_NAME_ADJ
deleted file mode 100644
index c4cc4a4..0000000
--- a/doc/sphinx/man/props/P_NAME_ADJ
+++ /dev/null
@@ -1,72 +0,0 @@
-
-P_NAME_ADJ
-**********
-
-
-NAME
-====
-
- P_NAME_ADJ "name_adj"
-
-
-DEFINIERT IN
-============
-
- <thing/description.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt ein oder mehrere Adjektive in Form eines Arrays
- von Strings. Es ist nur der Wortstamm anzugeben! Die Adjektive werden
- von der Funktion name() dekliniert und vor den Namen gesetzt, wirken
- also als Aufzaehlung von Adjektiven vor dem Namen.
-
- Die hier angegebenen Adjektive dienen nur zur Ausgabe! Soll sich das
- Objekt auch ueber Adjektive ansprechen lassen, muss man diese mit
- AddAdjective() uebergeben.
-
- Soll das Objekt nur ein einzelnes Namensadjektiv besitzen, kann man dem
- SetProp()-Aufruf auch einen String uebergeben; gespeichert wird die
- Property aber in jedem Fall als Array.
-
- Wenn ein Adjektiv unregelmaessig ist, kann man die vier Faelle auch
- als Array uebergeben. Man muss dann aber Arrays schachteln, damit von den
- mehrfachen Adjektiven unterschieden werden kann.
-
-
-BEISPIELE
-=========
-
- SetProp(P_NAME, "Hut");
- SetProp(P_NAME_ADJ, "alt");
-
- name(WESSEN,1) => "des alten Huts"
-
-
- // Zwei Adjektive, gleichrangig zu Substantiv
- SetProp(P_NAME_ADJ, ({"alt", "gammelig"}));
-
- name(WESSEN,1) => "des alten, gammeligen Huts"
-
-
- // Zwei Adjektive, erstes ist Attribut zu zweitem
- falsch: SetProp(P_NAME_ADJ, ({"gruen", "gestreift"}));
- name(WESSEN,1) => "des gruenen, gestreiften Huts"
- richtig: SetProp(P_NAME_ADJ, ({"gruen gestreift"}));
- name(WESSEN,1) => "des gruen gestreiften Huts"
-
- // Unregelmaessiges Adjektiv
- SetProp( P_NAME_ADJ,({({"rosa","rosa","rosa","rosa"})});
- name(WESSEN,1) => "des rosa Huts"
- // Ohne inneres Array haette man 4 mal rosa als Adjektiv
- // => "des rosaen, rosaen, rosaen, rosaen Huts"
-
-
-SIEHE AUCH
-==========
-
- /std/thing/description.c, name(), P_NAME, DeclAdj()
-
-23.April 2007 Rumata
diff --git a/doc/sphinx/man/props/P_NEEDED_QP b/doc/sphinx/man/props/P_NEEDED_QP
deleted file mode 100644
index 2df4c78..0000000
--- a/doc/sphinx/man/props/P_NEEDED_QP
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_NEEDED_QP
-***********
-
-
-NAME
-====
-
- P_NEEDED_QP "needed_qp"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- APs, die man fuer den Seherstatus braucht
-
- Diese Property ist mittlerweile obsolet. Die
- aktuell geltenden Seher-Anforderungen stehen in
- /secure/lepmaster.h
-
-
-LETZTE AENDERUNG
-================
-
- 2006-09-30, Zook.
diff --git a/doc/sphinx/man/props/P_NETDEAD_ENV b/doc/sphinx/man/props/P_NETDEAD_ENV
deleted file mode 100644
index 2e46f5d..0000000
--- a/doc/sphinx/man/props/P_NETDEAD_ENV
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_NETDEAD_ENV
-*************
-
-
-NAME
-====
-
- P_NETDEAD_ENV "netdead_env"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property kann in netztoten Spielern abgefragt werden,
- um herauszufinden, in welchem Raum sie netztot geworden sind.
-
- Es wird der selbe Wert zurueckgegeben, den die Mudlib benutzen
- wuerde, um die Spieler beim reconnect wieder an den richtigen
- ort zu bringen. Das ist normalerweise das Raumobjekt oder der
- Dateiname des Raums (zum Beispiel so dieser ein clone war).
-
- Bei nicht netztoten Spielern wird 0 zurueckgegeben.
-
-
-BEMERKUNGEN
-===========
-
- Diese Property ist read-only.
-
-
-SIEHE AUCH
-==========
-
- P_NETDEAD_INFO
-
-2009-08-04 Rumata
diff --git a/doc/sphinx/man/props/P_NETDEAD_INFO b/doc/sphinx/man/props/P_NETDEAD_INFO
deleted file mode 100644
index fe96ac6..0000000
--- a/doc/sphinx/man/props/P_NETDEAD_INFO
+++ /dev/null
@@ -1,120 +0,0 @@
-
-P_NETDEAD_INFO
-**************
-
-
-NAME
-====
-
- P_NETDEAD_INFO "netdead_info"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Wird im Raum X gesetzt und wirkt nur, falls dieser Raum ein '#' im
- object_name() hat (normale Clones, zB "/room/void#10153018").
-
-
-
- Bei Einschlafen eines Spielers in diesem Raum werden die Werte aus
- der Property im Spieler gespeichert (Netztoteninformationen).
-
- Ist beim Aufwachen des Spielers das Raumobjekt X zerstoert worden, dann
- wird bei der Blueprint von X per SetProp() die gespeicherte Information
- gesetzt. Der Rueckgabewert des SetProp wird als Pfad zu einem Ausweich-
- Aufwach-Raum interpretiert und der Spieler wird in dem Fall dorthin
- bewegt.
-
-
-BEMERKUNGEN
-===========
-
- Zum Clonen von Raeumen sollten Virtual Compiler benutzt werden:
- Wird in den erzeugten Objektnamen KEIN '#' verwendet, dann ist diese
- Property nicht sinnvoll und wird nicht verwendet. Ein ordentlicher
- VC kann Bewegen eines Spielers in dessen alten, nicht mehr existierenden
- Raum oder einen Ersatzraum beim Aufwachen selbst loesen.
-
-
-BEISPIELE
-=========
-
- // #1: geclonter Raum mit Ausweich-Aufwachraum: Klerus-Gilde
- #include <properties.h>
- inherit "/std/room";
-
-
-
- void create() {
- ::create();
-
- SetProp(P_NETDEAD_INFO, "/gilden/klerus");
- SetProp(P_LIGHT, 1);
- }
-
-
-
- // #2: komplexerer Beispielraum fuer P_NETDEAD_INFO-Funktionalitaet
- // Siehe auch: /doc/beispiele/testobjekte/netdead_info_testraum.c
- #include <properties.h>
- inherit "/std/room";
-
- void create() {
- ::create();
-
- if (clonep(this_object()))
- // setze Informationen, die im Netztoten gespeichert werden sollen
- Set(P_NETDEAD_INFO, random(5));
- else
- // Blueprint: hier kann man zu einem Cloneraum gehen
- AddExit("cloneraum", #'create_room);
-
- // Set-Method, um die Informationen aus P_NETDEAD_INFO beim Aufwachen
- // in der Blueprint auswerten zu koennen
- Set(P_NETDEAD_INFO, #'create_destiny, F_SET_METHOD);
- SetProp(P_LIGHT, 1);
- }
-
-
-
- // Raum entfernen, normalerweise so KEINE GUTE IDEE!
- void BecomesNetDead(object pl) {
- call_out(#'remove, 30);
- }
-
- // erzeuge einen Cloneraum und bewege den Spieler dahin
- int create_room(string dir) {
- object dest = clone_object(object_name(this_object()));
- this_player()->move(dest, M_NOCHECK);
- return 1;
- }
-
-
-
- // Set-Method fuer P_NETDEAD_INFO: gibt Pfad zurueck
- // benutze die Informationen aus dem jetzt aufwachenden Netztoten, um
- // einen alternativen Aufwachraum zu ermitteln, da der Einschlafraum
- // zerstoert ist
- string create_destiny(mixed val) {
- if (intp(val)) {
- switch (val) {
- case 0:
- return "/d/ebene/room/PortVain/po_haf1";
- case 1:
- return "/gilden/klerus";
- case 2:
- return "/gilden/karate";
- default:
- }
- return "/d/ebene/room/waldweg4";
- }
- }
-
-2. Jan 2012 Gloinson
diff --git a/doc/sphinx/man/props/P_NEVERDROP b/doc/sphinx/man/props/P_NEVERDROP
deleted file mode 100644
index d0cdf41..0000000
--- a/doc/sphinx/man/props/P_NEVERDROP
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_NEVERDROP
-***********
-
-
-NAME
-====
-
- P_NEVERDROP "neverdrop"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Objekte, welche diese Property gesetzt haben, werden beim Tod eines
- Lebewesens nicht automatisch in die Leiche oder in den umgebenden
- Raum (z.B. bei bei gesetztem P_NOCORPSE) transportiert.
-
-
-BEMERKUNGEN
-===========
-
- Soll das Objekt vom Lebewesen nicht weggelegt werden koennen, so ist
- die Property P_NODROP zu verwenden.
- Beide Properties zusammen stellen sicher, dass ein Objekt nicht
- weitergegeben werden kann.
-
-
-BEISPIELE
-=========
-
- Eine dauerhafte Belohnung, die auch beim Tod des Spielers bei ihm
- verbleiben soll, setzt das so:
- SetProp(P_NEVERDROP,1);
- Sollen auch Reboots ueberstanden werden, ist zusaetzlich
- P_AUTOLOADOBJ zu setzen.
-
-
-SIEHE AUCH
-==========
-
- P_NODROP, P_NOGET, P_NOCORPSE, P_AUTOLOADOBJ, /std/living/life.c
-
-Last modified: Thu Jun 14 22:26:29 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_NEVER_CLEAN b/doc/sphinx/man/props/P_NEVER_CLEAN
deleted file mode 100644
index fc568ff..0000000
--- a/doc/sphinx/man/props/P_NEVER_CLEAN
+++ /dev/null
@@ -1,53 +0,0 @@
-
-P_NEVER_CLEAN
-*************
-
-
-NAME
-====
-
- P_NEVER_CLEAN " never clean "
-
-
-DEFINIERT IN
-============
-
- /sys/rooms.h
-
-
-BESCHREIBUNG
-============
-
- Normalerweise wird ein Raum nach 2 Resets zerstoert, wenn er waerend
- dieser Zeit von keinem Lebewesen betreten wurde und wenn
- keine REFRESH_NONE- oder REFRESH_DESTRUCT-Objekte existieren, die
- nicht mehr im Raum vorhanden sind.
- Mit dieser Property kann man den sogenannten Clean-Up unterbinden.
-
-
-BEISPIEL
-========
-
- Der folgende Raum wird nicht mehr zerstoert, wenn er einmal geladen
- wurde:
- #include <properties.h>
- // #include <rooms.h> ... wird schon von properties.h included!
- inherit "std/room";
- void create()
- { ::create();
- SetProp(P_SHORT,"Ein toller Raum");
- ...
- SetProp(P_NEVER_CLEAN,1);
- ...
- }
- Man sollte die Anwendung nicht uebertreiben! Wichtig ist diese
- Funktion zum Beispiel fuer Raeume, die gleichzeitig Masterobjekte
- darstellen.
-
-
-SIEHE AUCH
-==========
-
- /std/room.c
-
-Last modified: Wed Feb 3 00:54:32 1999 by Patryn
diff --git a/doc/sphinx/man/props/P_NEWSKILLS b/doc/sphinx/man/props/P_NEWSKILLS
deleted file mode 100644
index 7cb61c7..0000000
--- a/doc/sphinx/man/props/P_NEWSKILLS
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_NEWSKILLS
-***********
-
-
-NAME
-====
-
- P_NEWSKILLS "newskills"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property sind saemtliche Skills und Spells vermerkt, die
- das Lebewesen kennt.
-
-
-BEMERKUNGEN
-===========
-
- Man sollte diese Property nicht per Hand veraendern, sondern die
- Funktionen von "/std/living/skills.c" nutzen.
-
-
-SIEHE AUCH
-==========
-
- ModifySkill(), LearnSkill(), UseSkill(), /std/living/skills.c,
- P_GUILD_SKILLS, P_SB_SPELLS
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_NEXT_DEATH_SEQUENCE b/doc/sphinx/man/props/P_NEXT_DEATH_SEQUENCE
deleted file mode 100644
index 6992a32..0000000
--- a/doc/sphinx/man/props/P_NEXT_DEATH_SEQUENCE
+++ /dev/null
@@ -1,68 +0,0 @@
-
-P_NEXT_DEATH_SEQUENCE
-*********************
-
-
-NAME
-====
-
- P_NEXT_DEATH_SEQUENCE "p_lib_next_death_sequence"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Im Spieler kann damit dessen eigene Todessequenz fuer den naechsten
- Tod festgelegt werden. Nach einem Tod (egal welche Todessequenz
- gewaehlt wurde) wird die Property geloescht und muesste neu gesetzt
- werden.
-
- Es gibt folgende gueltige Werte:
- - string: Pfad zu einer eigenen Todessequenz im gueltigen Format
- - mixed* Eine Todessequenz im Format des Todesraumes:
- ({<int gesamtlaenge>,
- ([<int index1>: <string umgebrochene Meldung1>,
- <int index2>: <string umgebrochene Meldung2>,
- ...])
- })
- - mapping In die Standard-Lars-Todessequenz einzufuegende Zeilen:
- ([<int zeitindex>: <string umgebrochener Text>])
-
-
-BEMERKUNGEN
-===========
-
- Eine Todessequenz eines Gegners, festgelegt ueber
- P_ENEMY_DEATH_SEQUENCE hat Vorrang vor dieser Property.
-
-
-BEISPIELE
-=========
-
- // Pfad zu einer eigenen DSQ
- SetProp(P_NEXT_DEATH_SEQUENCE, ".../passende_dsq.txt");
-
- // eigene DSQ im Todesraumformat:
- SetProp(P_NEXT_DEATH_SEQUENCE,
- ({ 2, ([1: "Der Tod entlaesst dich eilig.\n"])}));
-
- // Einfuegen einer Meldung in die Standard-Todessequenz
- SetProp(P_NEXT_DEATH_SEQUENCE,
- ([5: "Du fuehlst dich etwas daemlich.\n"]));
-
-
-SIEHE AUCH
-==========
-
- Tod: die(L)
- Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
- P_ZAP_MSG, P_ENEMY_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /room/death/death_room.c
-
-10. Nov 2011 Gloinson
diff --git a/doc/sphinx/man/props/P_NEXT_DISABLE_ATTACK b/doc/sphinx/man/props/P_NEXT_DISABLE_ATTACK
deleted file mode 100644
index 6a9eea3..0000000
--- a/doc/sphinx/man/props/P_NEXT_DISABLE_ATTACK
+++ /dev/null
@@ -1,52 +0,0 @@
-
-P_NEXT_DISABLE_ATTACK
-*********************
-
-
-PROPERTY
-========
-
- P_NEXT_DISABLE_ATTACK "next_diable_attack"
-
-
-DEFINIERT IN
-============
-
- combat.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property gibt an, wann der NPC das naechste Mal paralysiert
- werden kann. Ueblicherweise wird sie automatisch beim Setzen
- von P_DISABLE_ATTACK gesetzt. Sie gibt einen Zeitpunkt wie
- die Funktion time() an, an dem zum ersten Mal wieder Paralyse
- moeglich ist.
-
- Will man einen NPC schreiben, der immer paralysierbar ist und nicht erst
- nach einer gewissen Wartezeit nach der letzten Paralyse, laesst sich dies
- durch eine Set-Methode auf P_NEXT_DISABLE_ATTACK erreichen:
-
-
-
- Set(P_NEXT_DISABLE_ATTACK, function int () {return 0;}, F_SET_METHOD);
-
- Diese Set-Methode verhindert das Setzen von P_NEXT_DISABLE_ATTACK mittels
- eines SetProp-Aufrufes.
-
-
-BEMERKUNGEN
-===========
-
- Die Zeit zum Schutz vor erneuter Paralyse existiert absichtlich. Bitte
- waegt sorgfaeltig ab, bevor ihr diese Property an Gegnern/Spielern
- manipuliert.
-
-
-SIEHE AUCH
-==========
-
- P_DISABLE_ATTACK
-
-21.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/props/P_NOBUY b/doc/sphinx/man/props/P_NOBUY
deleted file mode 100644
index 27f6c70..0000000
--- a/doc/sphinx/man/props/P_NOBUY
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_NOBUY
-*******
-
-
-NAME
-====
-
- P_NOBUY "nobuy"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wenn diese Property gesetzt ist, wird das Objekt nach einem
- Verkauf im Laden zerstoert, damit es nicht wieder von einem Spieler
- gekauft werden kann.
diff --git a/doc/sphinx/man/props/P_NOCORPSE b/doc/sphinx/man/props/P_NOCORPSE
deleted file mode 100644
index 15d5de2..0000000
--- a/doc/sphinx/man/props/P_NOCORPSE
+++ /dev/null
@@ -1,51 +0,0 @@
-
-P_NOCORPSE
-**********
-
-
-NAME
-====
-
- P_NOCORPSE "nocorpse"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property ist gesetzt, wenn im Todesfall kein Leichnam
- automatisch erzeugt werden soll.
-
-
-BEMERKUNGEN
-===========
-
- In diesem Fall wird die Property P_CORPSE ignoriert, mit der man
- ein spezielles Leichenobjekt angeben kann, sofern nicht die
- Standardleiche "/std/corpse.c" verwendet werden soll.
- Da die Moerdermeldungen ueber ebendiese Objekt laufen, werden
- hierbei auch keine ausgegeben.
-
-
-BEISPIELE
-=========
-
- Das Lebewesen soll keine Leiche hinterlassen, weil es zu Staub
- zerfaellt:
- SetProp(P_DIE_MSG," zerfaellt zu Staub!\n");
- SetProp(P_NOCORPSE,1)
- Es wurde auch gleich die Sterbemeldung dementsprechend gesetzt.
-
-
-SIEHE AUCH
-==========
-
- P_CORPSE, P_ZAP_MSG, P_DIE_MSG, P_MURDER_MSG, P_KILL_MSG,
- P_NEVERDROP, /std/corpse.c
-
-Last modified: Thu Jun 14 22:26:29 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_NODRINK_MSG b/doc/sphinx/man/props/P_NODRINK_MSG
deleted file mode 100644
index a3407c7..0000000
--- a/doc/sphinx/man/props/P_NODRINK_MSG
+++ /dev/null
@@ -1,46 +0,0 @@
-
-P_NODRINK_MSG
-*************
-
-
-NAME
-====
-
- P_NODRINK_MSG "std_food_nodrink_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Konsumenten, wenn versucht wird, ein Nicht-Getraenk
- zu trinken. Sobald eine Speise einen Wert in P_FOOD setzt, gilt es als
- Nicht-Getraenk.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "@WEN1 kann man nicht trinken!"
-
-
-SIEHE AUCH
-==========
-
- P_FOOD, P_DRINK, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_NODROP b/doc/sphinx/man/props/P_NODROP
deleted file mode 100644
index 786cdea..0000000
--- a/doc/sphinx/man/props/P_NODROP
+++ /dev/null
@@ -1,60 +0,0 @@
-
-P_NODROP
-********
-
-
-NAME
-====
-
- P_NODROP "nodrop"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Ist diese Property in einem Objekt gesetzt, so kann ein Lebewesen
- das Objekt nicht weglegen.
- Als Standardmeldung kommt in diesem Fall beispielsweise:
- Du kannst <Objektname> nicht wegwerfen!
- Du kannst <Objektname> nicht weggeben.
- Man kann auch eine alternative Meldung angeben, wobei selbstaendig
- auf einen korrekten Zeilenumbruch zu achten ist.
-
-
-BEMERKUNGEN
-===========
-
- Soll ein Objekt beim Tod des Lebewesens oder bei Ende eines Spielers
- nicht in der Leiche bzw. im Raum zurueckgelassen werden, so ist
- die Property P_NEVERDROP zu nutzen.
- Beide Properties zusammen stellen sicher, dass ein Objekt nicht
- weitergegeben werden kann.
-
-
-BEISPIELE
-=========
-
- Ein schwer zu erkaempfender Dolch koennte folgendes beinhalten,
- um nicht weitergegeben werden zu koennen:
- SetProp(P_NODROP,1);
- Informativer jedoch ist eine eigene Meldung:
- SetProp(P_NODROP,
- "Den Dolch hast Du Dir hart erkaempft, nicht wegwerfen!\n");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_NOGET, P_NEVERDROP, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG,
- P_TOO_MANY_MSG, P_NOINSERT_MSG, P_NOLEAVE_MSG,
- Erfolg: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
- P_WEAR_MSG, P_WIELD_MSG
- Sonstiges: replace_personal(E), /std/living/put_and_get.c
-
-Last modified: Thu Jun 14 22:26:29 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_NOFOOD_MSG b/doc/sphinx/man/props/P_NOFOOD_MSG
deleted file mode 100644
index d195c5e..0000000
--- a/doc/sphinx/man/props/P_NOFOOD_MSG
+++ /dev/null
@@ -1,46 +0,0 @@
-
-P_NOFOOD_MSG
-************
-
-
-NAME
-====
-
- P_NOFOOD_MSG "std_food_nofood_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung an den Konsumenten, wenn versucht wird, ein Getraenk zu essen.
- Sobald eine Speise keinen Wert in P_FOOD und einen Wert in P_DRINK
- setzt, gilt es als Getraenk.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "@WEN1 kann man nicht essen!"
-
-
-SIEHE AUCH
-==========
-
- P_FOOD, P_DRINK, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_NOGET b/doc/sphinx/man/props/P_NOGET
deleted file mode 100644
index 17a6248..0000000
--- a/doc/sphinx/man/props/P_NOGET
+++ /dev/null
@@ -1,49 +0,0 @@
-
-P_NOGET
-*******
-
-
-NAME
-====
-
- P_NOGET "noget"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Ist diese Property in einem Objekt gesetzt, so kann ein Lebewesen
- das Objekt nicht nehmen.
- Als Standardmeldung kommt in diesem Fall beispielsweise:
- Du kannst <Objektname> nicht nehmen.
- Du kannst <Objektname> so nirgendwo reinstecken.
- Man kann auch eine alternative Meldung angeben, wobei selbstaendig
- auf einen korrekten Zeilenumbruch zu achten ist.
-
-
-BEISPIELE
-=========
-
- Ein Objekt, welches fest im Raum verankert ist, kann natuerlich
- nicht entfernt werden, z.B. ein angebundenes Seil:
- SetProp(P_NOGET,"Das Seil ist fest am Baum verknotet!\n");
- In einem Kommando zum Losknoten koennte man die Property dann
- loeschen, um ein Wegnehmen zu ermoeglichen.
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_NODROP, P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG,
- P_TOO_MANY_MSG, P_NOINSERT_MSG, P_NOLEAVE_MSG
- Erfolg: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
- P_WEAR_MSG, P_WIELD_MSG
- Sonstiges: replace_personal(E), /std/living/put_and_get.c
-
-Last modified: Thu Jun 14 22:26:29 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_NOINSERT_MSG b/doc/sphinx/man/props/P_NOINSERT_MSG
deleted file mode 100644
index de7d8e8..0000000
--- a/doc/sphinx/man/props/P_NOINSERT_MSG
+++ /dev/null
@@ -1,65 +0,0 @@
-
-P_NOINSERT_MSG
-**************
-
-
-NAME
-====
-
- P_NOINSERT_MSG "noinsert_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn
- jemand versucht, ein Objekt in einen Behaelter zu bewegen und der
- Behaelter dieses im PreventInsert() verhindert.
- Die Property ist im Zielbehaelter zu setzen.
- Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
- so wird die Standardmeldung ausgegeben.
- ("<Objekt> kannst Du dort nicht hineinstecken.")
- Der String in der Property wird noch durch replace_personal()
- verarbeitet, das zu bewegende Objekt wird als erstes, der Zielbehaelter
- als zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
- umgebrochen.
- Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
- ganz.
-
-
-BEISPIELE
-=========
-
- 1. Ein Kochtopf laesst im PreventInsert nur bestimmte Objekte zu, die zu
- einer Suppe gehoeren. Fuer eine passende Meldung wird im Topf jetzt die
- Property gesetzt:
- SetProp(P_NOINSERT_MSG, "Du kannst @WEN1 nicht in den Kochtopf tun, da"
- " gehoeren doch nur Suppenzutaten rein!");
- Wenn jemand jetzt versucht, eine Muenze reinzustecken, dann wuerde
- folgende Meldung erscheinen:
- Du kannst die Muenze nicht in den Kochtopf tun, da gehoeren doch nur
- Suppenzutaten rein!
-
- 2. Ein Rucksack soll in einer bestimmten Reihenfolge gepackt werden, dazu
- kann im PreventInsert die Meldung je nach Bedarf gesetzt werden:
- if (<objekt noch nicht an der Reihe>)
- SetProp(P_NOINSERT_MSG, "@WEN1 solltest du erst spaeter einpacken.");
- else if (<objekt schon im Rucksack>)
- SetProp(P_NOINSERT_MSG, "Aber @WER1 ist doch schon eingepackt!");
- else ...
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
- P_NOLEAVE_MSG, P_NODROP, P_NOGET
- Erfolg: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
- P_WEAR_MSG, P_WIELD_MSG
- Sonstiges: replace_personal(E), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/props/P_NOLEAVE_MSG b/doc/sphinx/man/props/P_NOLEAVE_MSG
deleted file mode 100644
index d2cd164..0000000
--- a/doc/sphinx/man/props/P_NOLEAVE_MSG
+++ /dev/null
@@ -1,52 +0,0 @@
-
-P_NOLEAVE_MSG
-*************
-
-
-NAME
-====
-
- P_NOLEAVE_MSG "noleave_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn
- jemand versucht, ein Objekt aus einem Behaelter zu entfernen und der
- Behaelter dieses im PreventLeave() verhindert.
- Die Property ist im verhindernden Behaelter zu setzen.
- Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
- so wird die Standardmeldung ausgegeben.
- ("Du kannst <Objekt> nicht nehmen.")
- Der String in der Property wird noch durch replace_personal()
- verarbeitet, das zu bewegende Objekt wird als erstes, der verhindernde
- Behaelter als zweites Objekt angegeben. Danach wird der String auf 78
- Zeichen umgebrochen.
- Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
- ganz.
-
-
-BEISPIELE
-=========
-
- Nur Bierschuettler sollen eine Bierflasche aus einem Kasten nehmen
- koennen, neben einer entsprechenden Behandlung im PreventLeave setzt man
- dazu die Property:
- SetProp(P_NOLEAVE_MSG, "Nur Bierschuettler duerfen das!");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
- P_NOINSERT_MSG, P_NODROP, P_NOGET
- Erfolg: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
- P_WEAR_MSG, P_WIELD_MSG
- Sonstiges: replace_personal(E), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/props/P_NOMAGIC b/doc/sphinx/man/props/P_NOMAGIC
deleted file mode 100644
index 42e51d1..0000000
--- a/doc/sphinx/man/props/P_NOMAGIC
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_NOMAGIC
-*********
-
-
-NAME
-====
-
- P_NOMAGIC "nomagic"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Angabe in Prozent, mit welcher Wahrscheinlichkeit Magie fehlschlaegt.
-
-
-
- Fuer einen Raum ist es eine generelle Aussage, wie wahrscheinlich ein
- Spell in ihm fehlschlaegt. Bei NPC zeigt es an, wie wahrscheinlich
- ein auf ihn gesprochener Spell fehlschlaegt.
-
-
-BEISPIEL
-========
-
- // in einem Raum keine Spells zulassen
- SetProp(P_NOMAGIC, 100)
-
-
-SIEHE AUCH
-==========
-
- Aehnlich: P_MAGIC_RESISTANCE_OFFSET, SpellDefend
-
-29.Dez 2007 Gloinson
diff --git a/doc/sphinx/man/props/P_NOSELL b/doc/sphinx/man/props/P_NOSELL
deleted file mode 100644
index 6141be3..0000000
--- a/doc/sphinx/man/props/P_NOSELL
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_NOSELL
-********
-
-
-NAME
-====
-
- P_NOSELL "nosell"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wenn diese Property gesetzt ist, kann das Objekt nicht in einem
- Laden verkauft werden.
- Gibt man in der Property einen String an, wird dieser ausgegeben,
- ansonsten erfolgt eine Meldung "Du kannst <NAME> nicht verkaufen!"
-
- Diese Meldung beinhaltet auch den Namen des in P_NAME einge-
- tragenen Besitzer des Ladens. Ist dies nicht gesetzt, wird per
- default 'Der Haendler' ausgegeben.
-
-
-BEISPIEL
-========
-
- SetProp(P_NOSELL,"Den Schrott behaeltst Du lieber selber.");
-
- ==> Apu sagt: Den Schrott behaeltst Du lieber selber.
- ==> Der Haendler sagt: Den Schrott behaeltst Du lieber selber.
-
- SetProp(P_NOSELL,1);
-
- ==> Apu sagt: Du kannst <name> nicht verkaufen!
- ==> Der Haendler sagt: Du kannst <name> nicht verkaufen!
-
-
-SIEHE AUCH
-==========
-
- P_NOBUY, P_NODROP, P_KEEPER
-
-03.09.2010, Zesstra
diff --git a/doc/sphinx/man/props/P_NO_ASCII_ART b/doc/sphinx/man/props/P_NO_ASCII_ART
deleted file mode 100644
index 3a143a4..0000000
--- a/doc/sphinx/man/props/P_NO_ASCII_ART
+++ /dev/null
@@ -1,35 +0,0 @@
-
-P_NO_ASCII_ART
-**************
-
-
-NAME
-====
-
- P_NO_ASCII_ART "no_ascii_art"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property kann der Spieler mit dem Befehl "grafik aus" auf
- 1 setzen. Damit zeigt er an, dass er keine ASCII Art sehen moechte.
-
- Wer ASCII-Art einsetzt, sollte an diesen Stellen die Property
- abfragen und textliche Umschreibungen oder Alternativloesungen
- einbauen.
-
-
-SIEHE AUCH
-==========
-
- grafik
-
-
- Letzte Aenderung: 2005-10-18, Zook.
diff --git a/doc/sphinx/man/props/P_NO_ATTACK b/doc/sphinx/man/props/P_NO_ATTACK
deleted file mode 100644
index 9ca4c95..0000000
--- a/doc/sphinx/man/props/P_NO_ATTACK
+++ /dev/null
@@ -1,99 +0,0 @@
-
-P_NO_ATTACK
-***********
-
-
-NAME
-====
-
- P_NO_ATTACK "no_attack"
-
-
-DEFINIERT IN
-============
-
- <living/combat.h>
-
-
-BESCHREIBUNG
-============
-
- Wenn ein NPC nicht angreifbar sein soll (weil er zum Beispiel in einer
- Gilde oder einer Quest Informationen vermittelt oder aehnlichen), sollte
- man diese Property auf einen Wert ungleich Null setzen. Sie wird immer
- abgefragt, wenn ermittelt wird, ob ein Lebewesen prinzipiell angreifbar
- ist. D.h. auch, dass nach Abfragen von P_NO_ATTACK _nicht_ immer ein
- Kampf gestartet wird und dass man dabei _nicht_ im Kampf sein muss!
-
- Gibt man hier einen String an (mit einem Satzzeichen und "\n" abge-
- schlossen), wird dieser bei direkten Angriffen ausgegeben. Bei anderen
- Datentypen wird eine Defaultmeldung ausgegeben. Die Defaultmeldung
- lautet: "<Name> laesst sich nicht angreifen!\n"
-
- Mit direkten Angriffen sind 'toete <name>' und Angriffszauber gemeint
- (bzw. alles, was living/life::Kill(), spellbook::TryAttackSpell(),
- spellbook::TryDefaultAttackSpell() und spellbook::FindEnemyVictim()
- aufruft).
-
-
-ACHTUNG
-=======
-
- 1) Zum Thema QueryMethoden auf P_NO_ATTACK
- Grundsaetzlich legt man entweder eine Query-Methode auf P_NO_ATTACK:
- Set(P_NO_ATTACK, #'my_no_attack, F_QUERY_METHOD);
- oder definiert eine Funktion _query_no_attack() im NPC.
-
- Wie muss nun eine solche Funktion aussehen? Z.B.:
-
-
-
- int|string my_no_attack() {
- if (!objectp(this_player())) return 0;
- if (opfer==getuid(this_player()) || this_player()==this_object())
- return(0);
- return(1); //nicht angreifbar
- }
-
- Diese Funktion macht den NPC nun nur fuer den Spieler 'opfer' angreifbar.
- Stattdessen kann natuerlich auch jede andere Bedingung genutzt werden.
-
- Aber warum die zweite Bedingung, this_player()==this_object()?
- Warum sollte der NPC sich selber angreifen duerfen?
-
- Das liegt an folgenden 2 Dingen:
-
- 1. Kaempfer kriegen bei eingeschaltetem Fokus Probleme, wenn man das
- nicht macht. Das liegt an folgendem: Wenn der NPC angreift, ruft er
- natuerlich Defend() im Spieler auf. Dieses schaut nach, ob der Spieler
- den Skill SK_MAGICAL_DEFENSE hat. Dieser ist bei Kaempfern das Parieren.
- Dieses schaut nach, ob der Fokus aktiv ist, wenn ja, wird dem
- ge'fokus'te Gegner besonders gut ausgewichen. Zu diesem Zweck wird die
- Liste der Feind im Raum erstellt mit PresentEnemies() abgerufen. Dieses
- fragt aber in allen (potentiellen) Gegnern P_NO_ATTACK ab und beendet
- den Kampf mit allen Gegnern, die nicht angreifbar sind. Bei dieser
- Abfrage ist jedoch TP==NPC, weil der ja angreift. Wenn er nun 1
- zurueckgibt, wird der Kampf an der Stelle beendet.
-
- 2. Wenn der NPC den Spieler angreift, wird im Spieler InsertEnemy(NPC)
- aufgerufen. Auch diesem Fall findet die Abfrage von P_NO_ATTACK statt,
- da InsertEnemy() ja erstmal rausfinden muss, ob der Gegner angreifbar
- ist, bevor er in die Feindliste eingetragen wird. Da der NPC den
- Angriff beginnt, ist TP der NPC. Wenn die Query-Methode auf P_NO_ATTACK
- hier abbricht, wird der NPC nicht in die Feindliste des Spielers
- eingetragen. Dann bekaempft der NPC den Spieler, aber der Spieler nicht
- den NPC.
-
-
- 2) P_NO_ATTACK des NPC wird z.B. beim Kampf eines Kaempfers mit dem NPC
- pro Kampfrunde um die 10mal abgerufen. Wenn der Kaempfer nur eine
- Attacke macht. Wenn er noch Sonderattacken machen, Spells ausfuehrt,
- etc. wird das noch mehr. D.h. was auch immer ihr in der Query-Methode
- im NPC macht:
- Es sollte schnell sein, jeder Tick an Rechenzeit zaehlt hier xfach!
-
-
-LETZTE AENDERUNG
-================
-
-09.11.2015, Arathorn
diff --git a/doc/sphinx/man/props/P_NO_BAD b/doc/sphinx/man/props/P_NO_BAD
deleted file mode 100644
index ae2adf2..0000000
--- a/doc/sphinx/man/props/P_NO_BAD
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_NO_BAD
-********
-
-
-NAME
-====
-
- P_NO_BAD "std_food_no_bad"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Flag, ob die Speise ewig haltbar ist.
- 0: Speise verdirbt nach der Anzahl Sekunden, die in P_LIFETIME
- angegeben ist bzw. nach einem Reset
- 1: Speise verdirbt nicht
-
-
-
- ACHTUNG: Diese Property darf nur in Absprache mit der Balance
- geaendert werden.
-
-
-DEFAULT
-=======
-
- Initial ist diese Property auf 0 gesetzt.
-
-
-SIEHE AUCH
-==========
-
- /std/food.c, wiz/food
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_NO_GLOBAL_ATTACK b/doc/sphinx/man/props/P_NO_GLOBAL_ATTACK
deleted file mode 100644
index 962186c..0000000
--- a/doc/sphinx/man/props/P_NO_GLOBAL_ATTACK
+++ /dev/null
@@ -1,33 +0,0 @@
-
-P_NO_GLOBAL_ATTACK
-******************
-
-
-NAME
-====
-
- P_NO_GLOBAL_ATTACK "no_global_attack"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Setzt man diese Property in einem NPC auf einen Wert ungleich 0, so
- wird der NPC bei einem "toete alle" nicht angegriffen.
-
- Damit kann man zB. NPCs, die dem eigenen Schutz dienen (als Folge von
- Zauberspruechen o.ae.) vor versehentlichen Angriffen schuetzen.
-
-
-SIEHE AUCH
-==========
-
- /std/npc.c, P_FRIEND
-
-Last modified: Sat May 18 15:26:28 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_NO_PARA_TRANS b/doc/sphinx/man/props/P_NO_PARA_TRANS
deleted file mode 100644
index 677f9c8..0000000
--- a/doc/sphinx/man/props/P_NO_PARA_TRANS
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_NO_PARA_TRANS
-***************
-
-
-NAME
-====
-
- P_NO_PARA_TRANS "no_para_trans"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wenn in einem Raum diese Property gesetzt ist, darf dort kein
- Wechsel in oder aus der Paralellwelt erfolgen. Objekte die so
- einen Wechsel ermoeglichen sind dafuer verantwortlich diese
- Property abzufragen.
-
-
-SIEHE AUCH
-==========
-
- P_NO_TPORT
diff --git a/doc/sphinx/man/props/P_NO_PLAYERS b/doc/sphinx/man/props/P_NO_PLAYERS
deleted file mode 100644
index 3cc88c1..0000000
--- a/doc/sphinx/man/props/P_NO_PLAYERS
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_NO_PLAYERS
-************
-
-
-NAME
-====
-
- P_NO_PLAYERS "no_players"
-
-
-DEFINIERT IN
-============
-
- /sys/rooms.h
-
-
-BESCHREIBUNG
-============
-
- Wenn in einem Raum die Property P_NO_PLAYERS auf einen Wert != 0 gesetzt
- ist, kann dieser von Spielern auf normalem Wege nicht mehr betreten werden.
- Magier und Testspieler(*) koennen den Raum betreten; Spieler muessen mit
- M_NOCHECK hineinbewegt werden.
-
- Auf diese Weise koennen Gebiete, die noch nicht offiziell angeschlossen
- sind, vor 'unbeabsichtigtem' Betreten durch Spieler geschuetzt werden.
-
- Moechte man zu einem schon angeschlossenen Gebiet nachtraeglich eine
- Parallelwelt einbauen, so sollte P_NO_PLAYERS *dringend* in den
- Parallelweltraeumen gesetzt werden, bis die Parallelwelt ausdruecklich
- fuer Spieler freigegeben wird. Andernfalls sind alle Parallelweltraeume,
- zu denen angeschlossene Normalweltraeume mit gleichem Filenamen existieren,
- automatisch durch Spieler erreichbar!
-
- (*) Ausschliesslich Testspieler, die auf den Namen eines existierenden
- Magiers markiert sind, koennen 'geschuetzte' Raeume betreten.
- Gildentesties werden wie Spieler behandelt.
-
-
-ANMERKUNG
-=========
-
- Im Gegensatz zu Bewegungen von Livings wird bei der Bewegung von Gegen-
- staenden P_NO_PLAYERS nur beim Wechsel der Welt ausgewertet, um z.B. zu
- verhindern, dass Bumerangs in noch nicht angeschlossene Gebiete fliegen.
-
- Moechte man in seinem eigenen Gebiet mit Bumerangs o.ae. testen, muss
- in diesen P_TESTPLAYER gesetzt sein. Das ist zwar eher ein Missbrauch
- der Property, aber ein Umkompieren vom Werfer war auf Dauer zu teuer. ;-)
-
-
-SIEHE AUCH
-==========
-
- P_PARA, move
diff --git a/doc/sphinx/man/props/P_NO_REGENERATION b/doc/sphinx/man/props/P_NO_REGENERATION
deleted file mode 100644
index cc672e3..0000000
--- a/doc/sphinx/man/props/P_NO_REGENERATION
+++ /dev/null
@@ -1,52 +0,0 @@
-
-P_NO_REGENERATION
-*****************
-
-
-NAME
-====
-
- P_NO_REGENERATION "no_regeneration"
-
-
-DEFINIERT IN
-============
-
- <living/life.h> und <health.h>
-
-
-BESCHREIBUNG
-============
-
- Durch das Setzen dieser Property kann man verhindern, das ein Lebewesen
- sich regeneriert.
- Es gibt sieben moegliche Werte, die man durch verodern kombinieren
- kann:
- NO_REG_HP : es werden keine HP regeneriert
- NO_REG_BUFFER_HP : es werden beim "tanken" keine HP regeneriert
- NO_REG_SP : es werden keine SP regeneriert
- NO_REG_BUFFER_SP : es werden beim "tanken" keine SP regeneriert
- NO_REG_ALCOHOL : der Alkoholspiegel wird nicht gesenkt
- NO_REG_DRINK : der Fluessigkeitsspiegel wird nicht gesenkt
- NO_REG_FOOD : der Nahrungsspiegel wird nicht gesenkt
- sowie die Konstante NO_REG, die eine Kombination aller moeglichen
- Werte darstellt (quasi das groesstmoegliche Uebel ;).
-
-
-BEISPIELE
-=========
-
- Dieses Lebewesen heilt nur beim "tanken" in der Kneipe, ansonsten
- nicht:
-
-
-
- SetProp( P_NO_REGENERATION, NO_REG_HP|NO_REG_SP );
-
-
-SIEHE AUCH
-==========
-
- /std/living/life.c
-
-Last modified: 14-05-2001 by Mupfel
diff --git a/doc/sphinx/man/props/P_NO_SCORE b/doc/sphinx/man/props/P_NO_SCORE
deleted file mode 100644
index 49cfee5..0000000
--- a/doc/sphinx/man/props/P_NO_SCORE
+++ /dev/null
@@ -1,73 +0,0 @@
-
-P_NO_SCORE
-**********
-
-
-NAME
-====
-
- P_NO_SCORE "no_score"
-
-
-DEFINIERT IN
-============
-
- /secure/scoremaster.h
-
-
-BESCHREIBUNG
-============
-
- Die Property stellt ein Flag innerhalb von Lebewesen dar, welches
- standardmaessig nicht gesetzt ist. In diesem Fall werden
- Erstkillstufenpunkte an den Angreifer vergeben, sofern er ein Opfer
- toetet.
-
- Innerhalb eines Teams koennen Erstkillstufenpunkte auch an
- Mitglieder vergeben werden, die das Lebewesen nicht selbst getoetet
- haben. Voraussetzung hierfuer ist, dass derjenige, der den letzten
- Schlag ausfuehrte, den Kill schon hat. Danach werden Mitglieder des
- Teams gesucht, welche den Kill noch nicht haben und in der Formation
- moeglichst weit vorne stehen.
-
- Mit der gesetzten Property P_NO_SCORE im Opfer erreicht man nun,
- dass diese Gutschrift fuer den/die Angreifer unterbunden wird.
-
-
-BEISPIEL
-========
-
- Folgendermassen unterbindet man die Vergabe von
- Erstkillstufenpunkten fuer den Tod eines NPC's:
-
- include "/secure/scoremaster.h"
- inherit "std/npc";
- void create() {
- ::create();
- ...
- SetProp(P_NO_SCORE,1);
- }
-
- Damit kann P_XP einen Wert haben, der eigentlich zum automatischen
- Eintragen von Erstkillstufenpunkten fuer ein Lebewesen fuehrt, und
- trotzdem wird dieser Eintrag nicht vorgenommen.
- Sinnvoll ist dies insbesondere bei Lebewesen, die nicht jeder
- Spieler erreichen kann (man moechte doch eine gewisse
- Chancengleichheit fuer das Erreichen von Stufenpunkten bieten).
-
-
-BEMERKUNGEN
-===========
-
- Auch die Vergabe von Erfahrungspunkten kann explizit unterbunden
- werden. Hierfuer gibt es die aehnlich geartete Property P_NO_XP.
-
-
-SIEHE AUCH
-==========
-
- Funktionen: GiveKillScore(), do_damage()
- Verwandt: P_NO_XP
- Sonstiges: P_XP
-
-14.Feb 2007 Gloinson
diff --git a/doc/sphinx/man/props/P_NO_STD_DRINK b/doc/sphinx/man/props/P_NO_STD_DRINK
deleted file mode 100644
index f8c2f33..0000000
--- a/doc/sphinx/man/props/P_NO_STD_DRINK
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_NO_STD_DRINK
-**************
-
-
-NAME
-====
-
- P_NO_STD_DRINK "no_std_drink"
-
-
-DEFINIERT IN
-============
-
- /sys/pub.h
-
-
-BESCHREIBUNG
-============
-
- Durch setzen dieser Property in einer Kneipe sorgt man dafuer, dass
- "Standard-Drinks" (z.B. Gluehwein im Dezember) nicht in das Menue
- der Kneipe aufgenommen werden.
-
-
-BEMERKUNGEN
-===========
-
- Keine.
-
-
-SIEHE AUCH
-==========
-
- /std/room/pub.c
-
-Last modified: Sat Mar 04 22:42:00 2000 by Paracelsus
diff --git a/doc/sphinx/man/props/P_NO_TPORT b/doc/sphinx/man/props/P_NO_TPORT
deleted file mode 100644
index 1c6de77..0000000
--- a/doc/sphinx/man/props/P_NO_TPORT
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_NO_TPORT
-**********
-
-
-NAME
-====
-
- P_NO_TPORT "tport"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Kann folgende Werte annnehmen (definiert in moving.h):
- NO_TPORT_IN = Man kann nicht in den Raum hinein teleportieren.
- NO_TPORT_OUT = Man kann nicht aus dem Raum hinaus teleportieren.
- NO_TPORT = Weder noch.
-
-
-SIEHE AUCH
-==========
-
- P_NO_PARA_TRANS
diff --git a/doc/sphinx/man/props/P_NO_TRAVELING b/doc/sphinx/man/props/P_NO_TRAVELING
deleted file mode 100644
index cd1073a..0000000
--- a/doc/sphinx/man/props/P_NO_TRAVELING
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_NO_TRAVELING
-**************
-
-
-NAME
-====
-
- P_NO_TRAVELING "no_traveling"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Hier steht der allgemeine reise-Befehl nicht zur Verfuegung.
-
-
-BEMERKUNGEN
-===========
-
- P_NO_TRAVELING wird in Transportern gesetzt wenn Spieler ihn
- nicht mehr 'automatisch' mittels des 'reise'-Befehls betreten
- koennen sollen.
-
- Sie bekommen in dem Transporter und in den Zielraeumen auch
- keinerlei Hinweise darauf, wohin sie evtl. reisen koennten.
-
-
-
- Standardmaessig ist P_NO_TRAVELING natuerlich 0.
-
-
-SIEHE AUCH
-==========
-
- reise
-
-
-LETZTER AENDERUNG
-=================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_NO_XP b/doc/sphinx/man/props/P_NO_XP
deleted file mode 100644
index b16c4ab..0000000
--- a/doc/sphinx/man/props/P_NO_XP
+++ /dev/null
@@ -1,65 +0,0 @@
-
-P_NO_XP
-*******
-
-
-NAME
-====
-
- P_NO_XP "no_xp"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Im Normalfall bekommt man im Kampf gegen einen Gegner fuer Treffer
- und beim Toeten eine XP-Gutschrift.
-
- Ist P_NO_XP gesetzt, so erhaelt man keinerlei XP-Gutschriften
- fuer den Kampf oder den Tod des NPCs.
-
-
-BEISPIEL
-========
-
- Folgendermassen unterbindet man die Vergabe von Erfahrungspunkte
- fuer den Angriff eines NPC's:
-
- include "/sys/living/life.h"
- inherit "std/npc";
- void create() {
- ::create();
- ...
- SetProp(P_NO_XP,1);
- }
-
- Damit kann P_XP trotzdem einen Wert im NPC haben, der
- Erstkillstufenpunkte fuer Lebewesen automatisch eintraegt!
-
- Auch fuer das kurzzeitige Unterbinden der Vergabe von
- Erfahrungspunkten ist diese Property sinnvoller, als P_XP im NPC
- auf 0 zu setzen.
-
-
-BEMERKUNGEN
-===========
-
- Auch die Vergabe von Erstkillstufenpunkten kann explizit unterbunden
- werden. Hierfuer gibt es die aehnlich geartete Property P_NO_SCORE.
-
-
-SIEHE AUCH
-==========
-
- Funktionen: AddExp(), DistributeExp(), do_damage()
- Properties: P_XP, P_LAST_XP
- Verwandt: P_NO_SCORE
- Sonstiges: P_TOTAL_WC, create_default_npc()
-
-14.Feb 2007 Gloinson
diff --git a/doc/sphinx/man/props/P_NPC b/doc/sphinx/man/props/P_NPC
deleted file mode 100644
index 60651d8..0000000
--- a/doc/sphinx/man/props/P_NPC
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_NPC
-*****
-
-
-NAME
-====
-
- P_NPC "is_npc"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Gesetzt bei Monstern.
diff --git a/doc/sphinx/man/props/P_NPC_FASTHEAL b/doc/sphinx/man/props/P_NPC_FASTHEAL
deleted file mode 100644
index 3c358ef..0000000
--- a/doc/sphinx/man/props/P_NPC_FASTHEAL
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_NPC_FASTHEAL
-**************
-
-
-NAME
-====
-
- P_NPC_FASTHEAL "npc_fastheal"
-
-
-DEFINIERT IN
-============
-
- /sys/pub.h
-
-
-BESCHREIBUNG
-============
-
- Durch setzen dieser Property in einer Kneipe sorgt man dafuer, dass
- bei NPCs, die dort "tanken", die Lebens- und Konzentrationspunkte
- direkt erhoeht werden und nicht, wie bei ungesetzter Property, in
- die jew. Buffer geschrieben werden.
-
-
-BEMERKUNGEN
-===========
-
- Die Benutzung dieser Property sollte nicht unbedingt zum Standard
- werden.
-
-
-SIEHE AUCH
-==========
-
- /std/room/pub.c
-
-Last modified: Wed Sep 29 13:58:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/props/P_NR_HANDS b/doc/sphinx/man/props/P_NR_HANDS
deleted file mode 100644
index a3bf299..0000000
--- a/doc/sphinx/man/props/P_NR_HANDS
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_NR_HANDS
-**********
-
-
-NAME
-====
-
- P_NR_HANDS "nr_hands"
-
-
-DEFINIERT IN
-============
-
- <weapon.h>
-
-
-BESCHREIBUNG
-============
-
- Wieviele Haende muss man frei haben, um die Waffe zuecken oder den
- Schild tragen zu koennen?
- Dieser Wert muss mindestens 1 betragen!
-
- Sollen Spieler die Waffe benutzen koennen, so sind hier nur die Werte 1
- und 2 moeglich. Falls die Waffe nur von Monstern benutzbar sein soll,
- kann man hier auch hoehere Werte eintragen (dazu muss man beim Monster
- P_MAX_HANDS entsprechend hoch setzen). Als Beispiel sei hier nur das
- vierhaendige Schwert aus dem Friedhof genannt.
-
- Defaultmaessig sind alle Waffen Zweihaender.
-
- Diese Property kann auch bei Zaubern benutzt werden, bei denen man eine
- oder mehrere Haende frei haben muss.
-
-
-SIEHE AUCH
-==========
-
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
- UseHands, FreeHands
- /std/weapon.c, /std/spellbook.c
-
-Last modified: Sun May 19 15:00:02 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_ORAKEL b/doc/sphinx/man/props/P_ORAKEL
deleted file mode 100644
index 773a80d..0000000
--- a/doc/sphinx/man/props/P_ORAKEL
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_ORAKEL
-********
-
-
-NAME
-====
-
- P_ORAKEL "orakel"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wenn diese Property gesetzt ist, kann der Wanderer in diesen
- Raum hinein.
diff --git a/doc/sphinx/man/props/P_ORIG_FILE_NAME b/doc/sphinx/man/props/P_ORIG_FILE_NAME
deleted file mode 100644
index 53243c2..0000000
--- a/doc/sphinx/man/props/P_ORIG_FILE_NAME
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_ORIG_FILE_NAME
-****************
-
-
-NAME
-====
-
- P_ORIG_FILE_NAME "original_object_name"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- In einer Leiche der Filename des Gestorbenen.
diff --git a/doc/sphinx/man/props/P_ORIG_NAME b/doc/sphinx/man/props/P_ORIG_NAME
deleted file mode 100644
index e44a06d..0000000
--- a/doc/sphinx/man/props/P_ORIG_NAME
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_ORIG_NAME
-***********
-
-
-NAME
-====
-
- P_ORIG_NAME "original_name"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- In einer Leiche der Name des Gestorbenen. (name(RAW))
diff --git a/doc/sphinx/man/props/P_PARA b/doc/sphinx/man/props/P_PARA
deleted file mode 100644
index 0a7f416..0000000
--- a/doc/sphinx/man/props/P_PARA
+++ /dev/null
@@ -1,73 +0,0 @@
-
-P_PARA
-******
-
-
-NAME
-====
-
- P_PARA "para"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Nummer der Parallelwelt, in der sich ein Spieler befindet.
-
- Ist die Property P_PARA auf Null gesetzt, so befindet sich der Spieler in
- der 'Normalwelt'. Gibt es bei einer Bewegung dieses Spielers mehrere
- moegliche Zielraeume mit identischem Namen aber unterschiedlichen Endungen
- 'name.c', 'name^1.c', 'name^2.c' etc., so wird der Spieler in den Raum
- 'name.c' bewegt.
-
- Wird die Property P_PARA auf einen Wert n>0 gesetzt, so landet der Spieler
- bei einer Bewegung im Raum 'name^n.c'. Ist kein Raum mit entsprechender
- Endung vorhanden, wird der Spieler stattdessen in den Normalweltraum
- bewegt.
-
- Diese Prop kann auch in einem Virtual Compiler gesetzt werden. In diesem
- Fall schraenkt sie die Dimensionen ein, in denen der VC Objekte erzeugt.
- Die Prop kann eine einzelne Ziffer (Int) oder ein Array von Ints
- aufnehmen, dann ist der VC fuer alle angegeben Dimensionen zustaendig.
- Ein leeres Array erlaubt gar keine Para-Objekte.
-
-
-ANMERKUNG
-=========
-
- Die Endung '^0' kennzeichnet _nicht_ die Normalwelt. So lange kein Ausgang
- explizit auf den Raum 'name^0.c' verweist, wird kein Spieler den Raum
- betreten koennen. Deshalb kann man die Endung '^0' z.B. dazu benutzen, um
- eigene Standardraeume fuer ein Gebiet zu schreiben, die dann sowohl von
- den Normal- als auch von den Parallelweltraeumen inheritet werden.
-
- Raeume mit Endungen '^n.c', bei denen 'n' keine positive ganze Zahl ist,
- werden nicht beachtet.
-
- Fuer die Entscheidung, in welchem Raum ein Spieler in Abhaengigkeit von
- P_PARA landet, ist die Funktion move() zustaendig. Als Magier muss man sich
- darum nicht gesondert kuemmern. Das heisst aber auch, dass beim Anschluss
- eines Normalweltraumes automatisch alle in dem Verzeichnis mit gleichem
- Namen vorhandenen Parallelweltraeume mit angeschlossen werden.
-
- Sollen einzelne Parallelweltraeume noch nicht angeschlossen werden, so muss
- in ihnen die Property P_NO_PLAYERS gesetzt werden. Diese Raeume sind dann
- nur durch Magier und Testspieler zu betreten (und zu testen).
-
- In Paraweltraeumen liefert P_PARA 'n' zurueck.
- Man kann also z.B. in NPCs einfach ueber environment()->QueryProp(P_PARA)
- abfragen, in welcher Parawelt sich dieser gerade befindet.
-
-
-SIEHE AUCH
-==========
-
- P_NO_PLAYERS, move, pararaeume
-
-25.Jan 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_PARRY b/doc/sphinx/man/props/P_PARRY
deleted file mode 100644
index 40ddecd..0000000
--- a/doc/sphinx/man/props/P_PARRY
+++ /dev/null
@@ -1,47 +0,0 @@
-
-P_PARRY
-*******
-
-
-NAME
-====
-
- P_PARRY "parry"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property legt fest, inwiefern eine Waffe als Parierwaffe
- genutzt werden kann. Moegliche Werte:
-
- PARRY_NOT Eine reine Angriffswaffe ohne Parierfunktion.
-
- PARRY_TOO Eine kombinierte Angriffs- und Parierwaffe.
-
- PARRY_ONLY Eine reine Parierwaffe. Diese kann zusaetzlich
- zu einer normalen Waffe gezueckt werden.
-
- Man sollte nur die in <combat.h> definierten Konstanten verwenden.
-
-
-BEMERKUNGEN
-===========
-
- Durch diese Propertie laesst sich _kein_ Parade-Bonus fuer Trves
- setzen! Alle Gilden haben etwas davon. Vor Verwendung bitte mit
- der Objekt-Balance absprechen.
-
-
-SIEHE AUCH
-==========
-
- /std/weapon/combat.c
-
-Last modified: Sat Jun 01 13:28:45 2001 by Tilly
diff --git a/doc/sphinx/man/props/P_PARRY_WEAPON b/doc/sphinx/man/props/P_PARRY_WEAPON
deleted file mode 100644
index 9ee60aa..0000000
--- a/doc/sphinx/man/props/P_PARRY_WEAPON
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_PARRY_WEAPON
-**************
-
-
-NAME
-====
-
- P_PARRY_WEAPON "parry_weapon"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Diese Property gibt an, welche Parierwaffe ein Spieler derzeit
- gezueckt hat.
-
-
-SIEHE AUCH
-==========
-
- /std/weapon/combat.c, /std/living/combat.c
-
-Last modified: Sat Jun 26 15:23:00 1999 by Paracelsus
diff --git a/doc/sphinx/man/props/P_PEACE_HISTORY b/doc/sphinx/man/props/P_PEACE_HISTORY
deleted file mode 100644
index eab38d5..0000000
--- a/doc/sphinx/man/props/P_PEACE_HISTORY
+++ /dev/null
@@ -1,62 +0,0 @@
-
-P_PEACE_HISTORY
-***************
-
-
-NAME
-====
-
- P_PEACE_HISTORY "_peace_history"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Prop wird nach Gilden getrennt gespeichet, wie oft das Lebewesen
- in letzter Zeit befriedet worden ist. Diese Information geht in die
- Chance auf eine zukuenftige Befriedung ein.
- Die Zaehler werden im Durchschnitt alle 2700s um 2-3 reduziert.
- Die Datenstruktur ist ein Array, welches einen Zeitstempel als erstes
- Element und ein Mapping als zweites enthaelt. Das Mapping enthaelt unter
- den Gildennamen als Keys den ganzzahligen Zaehler erfolgreicher
- Befriedungen von Spielern dieser Gilde.
-
-
-BEMERKUNGEN
-===========
-
- * Diese Property sollte niemals direkt geaendert werden. Bitte greift also
- nur lesend darauf zu. Sollte hiermit Schindluder getrieben werden,
- werden die Daten vor externer Aenderung geschuetzt.
- * Die Datenstruktur in dieser Prop kann in Zukunft u.U. geaendert werden.
- Daher aendert sie am besten auch nicht im eigenen NPC oder seid darauf
- gefasst, irgendwann Hand anlegen zu muessen.
- * Die Aktualisierung (auch die Reduktion) findet im Zuge eines
- QueryPacify() statt, nicht im Reset des Lebewesens.
-
-
-BEISPIEL
-========
-
- In P_PEACE_HISTORY steht:
- ({1209654597, (["zauberer": 3, "klerus": 4]) })
- Bei der Berechnung der naechsten Befriede-Chance gehen bei Zauberern also
- 3 erfolgreiche Versuche, bei Klerikern 4 erfolgreiche Versuche ein.
- Der Zeitwert an erster Stelle des Arrays wird der bei der Berechnung der
- naechsten Reduktion der Zaehler beruecksichtigt. (Genaues: s. combat.c)
-
-
-SIEHE AUCH
-==========
-
- P_PEACE_ACCEPT
- QueryPacify()
- /std/living/combat.c
-
-01.05.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_PERM_STRING b/doc/sphinx/man/props/P_PERM_STRING
deleted file mode 100644
index 373c516..0000000
--- a/doc/sphinx/man/props/P_PERM_STRING
+++ /dev/null
@@ -1,24 +0,0 @@
-
-P_PERM_STRING
-*************
-
-
-NAME
-====
-
- P_PERM_STRING "perm_string"
-
-
-DEFINIERT IN
-============
-
- /sys/player/comm.h
-
-
-BESCHREIBUNG
-============
-
- Fuer Sprachflueche, Property ist im Spieler-Objekt zu setzen. In dem
- Objekt, das in P_PERM_STRING gespeichert ist, wird bei Sprachbefehlen
- permutate_string(str) aufgerufen und der zurueckgegebene String
- stattdessen ausgegeben.
diff --git a/doc/sphinx/man/props/P_PICK_MSG b/doc/sphinx/man/props/P_PICK_MSG
deleted file mode 100644
index 76b2760..0000000
--- a/doc/sphinx/man/props/P_PICK_MSG
+++ /dev/null
@@ -1,78 +0,0 @@
-
-P_PICK_MSG
-**********
-
-
-NAME
-====
-
- P_PICK_MSG "pick_message"
-
-
-DEFINIERT IN
-============
-
- /sys/living/put_and_get.h
-
-
-BESCHREIBUNG
-============
-
- Mit P_PICK_MSG kann man die Meldung, die man beim Aufnehmen eines
- Objektes bekommt, modifizieren.
-
- Folgende Werte sind moeglich:
-
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
-
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
-
- o Ein Array aus Strings
- Der erste String wird an den Spieler ausgegeben, der zweite
- (optionale) an den Raum.
-
- Die Strings werden durch die Funktion replace_personal() geparst.
- Objekt1 - Spieler
- Objekt2 - das Objekt, das genommen wird
-
- Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
- Raum.
-
-
-BEISPIEL
-========
-
- void create() {
- ...
- SetProp( P_SHORT, "Etwas Sand" );
- SetProp( P_LONG, break_string(
- "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
-
- SetProp( P_NAME, "Sand" );
- AddId( ({"sand"}) );
- SetProp( P_GENDER, MALE );
-
- SetProp( P_PICK_MSG, ({
- "Du schaufelst @WEN2 in deine Hand.",
- "@WER1 schaufelt @WEN2 in eine Hand."}));
- ...
- }
-
- Das ganze fuehrt bei Ugars "nimm sand" zu folgenden
- Meldungen:
-
- Ugar: "Du schaufelst den Sand in deine Hand."
- Raum: "Ugar schaufelt den Sand in eine Hand."
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
- Fehler: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
- P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET
- Sonstiges: replace_personal(E), pick_obj(L), /std/living/put_and_get.c
-
-14. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_PILE_NAME b/doc/sphinx/man/props/P_PILE_NAME
deleted file mode 100644
index edb0123..0000000
--- a/doc/sphinx/man/props/P_PILE_NAME
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_PILE_NAME
-***********
-
-
-NAME
-====
-
- P_PILE_NAME "file_name"
-
-
-DEFINIERT IN
-============
-
- /sys/container/properties.h
-
-
-BESCHREIBUNG
-============
-
- In einer Leiche der Name des Gestorbenen im Dativ. (name(WEM))
- Wird vom Haufen benoetigt.
diff --git a/doc/sphinx/man/props/P_PLAYER_LIGHT b/doc/sphinx/man/props/P_PLAYER_LIGHT
deleted file mode 100644
index ce0c22d..0000000
--- a/doc/sphinx/man/props/P_PLAYER_LIGHT
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_PLAYER_LIGHT
-**************
-
-
-NAME
-====
-
- P_PLAYER_LIGHT "player_light"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Gibt den Lichtlevel an, mit dem ein Lebewesen sieht, ein Abfragen dieser
- Property kann z.B. sinnvoll sein wenn man abfragen will ob ein Spieler
- genug Licht dabei hat um ein bestimmtes Detail untersuchen zu koennen.
-
- Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
- da das Lichtlevel ggf. neu berechnet werden muss!
-
- Ein direktes setzen dieser Property ist NICHT moeglich. Es ist jedoch
- moeglich entweder eine Closure zu benutzen oder den Wert ueber einen
- P_LIGHT_MODIFIER zu veraendern.
-
- Um zu erreichen, das ein NPC Nachtsicht bekommt, gibt es nun 3 Varianten.
- - eine closure:
- Set(P_PLAYER_LIGHT, function int () {return 1;} , F_QUERY_METHOD)
- dieses bedeutet, dass der NPC in jeder Dunkelheit perfekt sehen kann.
- - das setzen von einem P_LIGHT_MODIFIER
- - das benutzen des stdskills. Hierzu schreibt man in das create() des
- NPCs einfach ein: ModifySkill(SK_NIGHTVISION, 10000);
-
-
-SIEHE AUCH
-==========
-
- P_LIGHT_MODIFIER, P_LIGHT, P_TOTAL_LIGHT, P_INT_LIGHT, CannotSee()
diff --git a/doc/sphinx/man/props/P_PLURAL b/doc/sphinx/man/props/P_PLURAL
deleted file mode 100644
index eed829f..0000000
--- a/doc/sphinx/man/props/P_PLURAL
+++ /dev/null
@@ -1,58 +0,0 @@
-
-P_PLURAL
-********
-
-
-NAME
-====
-
- P_PLURAL "plural"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/language.h
-
-
-BESCHREIBUNG
-============
-
- Mit Hilfe von P_PLURAL koennen auch nicht Unit Objekte als Pluralobjekte
- markiert werden. Bei einem Wert > 1 wird der Wert ausserdem auch noch in
- den Namen eingefuegt. Sollte man in eigenem Code zulassen wollen, das
- etwas mit bestimmten Objekten geschieht, dann sollte man die Verben
- entsprechen konjugieren.
-
-
-BEMERKUNGEN
-===========
-
- Wirkt nicht auf Todesmeldungen -> siehe dafuer P_KILL_MSG
-
-
-BEISPIELE
-=========
-
- SetProp(P_NAME, "Stiefel"); SetProp(P_PLURAL, 2);
- name(WER, 1) -> "die zwei Stiefel"
-
- SetProp(P_NAME, "Stiefel"); SetProp(P_PLURAL, 1);
- name(WER, 1) -> "die Stiefel"
-
- // Ein Beispiel fuer das konjugieren von Verben
- static int cmd_opfer(string str)
- {
- int i;
- object *obs;
- notify_fail("Was moechtest Du opfern?\n");
- if (!str || !sizeof(obs=PL->find_obs(str))) return 0;
- for (i=sizeof(obs)-1; i>=0; i--)
- if (obs[i]->QueryProp(P_VALUE)<=0)
- write(obs[i]->Name(WER)+" "
- +(ob->QueryProp(P_PLURAL) ? "sind" : "ist")
- +" doch gar nichts wert.\n");
- else obs[i]->remove();
- }
-
-26. Juni 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_POISON b/doc/sphinx/man/props/P_POISON
deleted file mode 100644
index 2ab5dc1..0000000
--- a/doc/sphinx/man/props/P_POISON
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_POISON
-********
-
-
-NAME
-====
-
- P_POISON "poison"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wie stark wir vergiftet sind (0-11)
diff --git a/doc/sphinx/man/props/P_POISON_DELAY b/doc/sphinx/man/props/P_POISON_DELAY
deleted file mode 100644
index 079efd9..0000000
--- a/doc/sphinx/man/props/P_POISON_DELAY
+++ /dev/null
@@ -1,25 +0,0 @@
-
-P_POISON_DELAY
-**************
-
-
-NAME
-====
-
- P_POISON_DELAY "poison_delay"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der heart_beats nach denen sich die Giftwirkung erneut
- zeigt. Je kleiner der Wert, desto empfindlicher ist das Lebewesen
- gegen Gift.
- Aenderungen dieser Property in Spielern beduerfen der Genehmigung
- des EMs fuer Balance.
diff --git a/doc/sphinx/man/props/P_PORTIONS b/doc/sphinx/man/props/P_PORTIONS
deleted file mode 100644
index a6bdf16..0000000
--- a/doc/sphinx/man/props/P_PORTIONS
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_PORTIONS
-**********
-
-
-NAME
-====
-
- P_PORTIONS "std_food_portions"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- In dieser Property steht die Anzahl der Portionen einer Speise.
- Es duerfen nur Werte > -1 gesetzt werden. Ist diese Property 0,
- wird die Speise als leer bzw. verbraucht angesehen und kann nicht
- konsumiert werden.
-
-
-DEFAULT
-=======
-
- Initial ist diese Property auf 1 gesetzt, die Speise ist also mit
- einem Bissen/Schluck verbraucht bzw. leer.
-
-
-SIEHE AUCH
-==========
-
- /std/food.c, wiz/food
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_POST b/doc/sphinx/man/props/P_POST
deleted file mode 100644
index 975a884..0000000
--- a/doc/sphinx/man/props/P_POST
+++ /dev/null
@@ -1,82 +0,0 @@
-
-P_POST
-******
-
-
-NAME
-====
-
- P_POST "Post"
-
-
-DEFINIERT IN
-============
-
- /mail/post.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property laesst sich die Versendeerlaubnis von Paketen
- regeln. Hierbei gibt es zum einen die postlagernden Pakete, die man
- in einer Post abholen muss, und es gibt die sogenannten
- Kurierpakete, welche direkt und unmittelbar zugestellt werden.
- Nicht immer ist es erwuenscht, dass Pakete aus der Ferne in einen
- Raum geschickt werden duerfen. Dies duerfte insbesondere innerhalb
- von Gebieten interessant sein, in welche man nur beschraenkt viele
- Objekte mitfuehren kann. Mit dieser Property nun ist es leicht
- moeglich, dies zu verbieten. Man kann auch in den Objekten selbst
- angeben, ob diese per postlagerndem Paket bzw. Kurierpaket
- verschickt werden duerfen. Dies duerfte zum Beispiel bei Komponenten
- fuer Spells oder fuer Unique-Objekte interessant sein.
- Folgende Werte sind moeglich, wobei in Raeumen und Objekten
- Standardmaessig PP_DEFAULT genutzt wird:
-
- PP_FORBIDDEN -2 // auf jeden Fall verboten
- PP_NO_EXPRESS -1 // Kurierpakete verboten
- PP_DEFAULT 0 // Default
- PP_NORMAL_ALLOWED 1 // postlagernde Pakete erlaubt
- PP_ALLOWED 2 // auf jeden Fall erlaubt
-
- Raeume, die von /std/post.c abgeleitet wurden, nutzen als Standard
- natuerlich PP_ALLOWED.
-
-
-BEISPIEL
-========
-
- Um Kurierpakete fuer einen Raum zu verbieten, nutzt man die
- Funktionalitaet dieser Property folgendermassen:
-
- include "/mail/post.h"
- ...
- void create()
- { ::create();
- ...
- SetProp(P_POST,PP_NO_EXPRESS);
- ...
- }
-
- Objekte selbst koennte man folgendermassen aus Paketen verbannen,
- welche versendet werden sollen:
-
- include "/mail/post.h"
- ...
- void create()
- { ::create();
- ...
- SetProp(P_POST,PP_FORBIDDEN);
- ...
- }
-
- In letzterem Fall funktionieren im Gegensatz zum ersten Beispiel
- auch keine postlagernden Pakete mehr.
-
-
-SIEHE AUCH
-==========
-
- /std/post.c, /std/mailcabin.c, /p/service/loco/std/mailcabin.c
-
-Last modified: Sun Sep 6 19:34:37 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_POTIONROOMS b/doc/sphinx/man/props/P_POTIONROOMS
deleted file mode 100644
index 0df158f..0000000
--- a/doc/sphinx/man/props/P_POTIONROOMS
+++ /dev/null
@@ -1,35 +0,0 @@
-
-P_POTIONROOMS
-*************
-
-
-NAME
-====
-
- P_POTIONROOMS "potionrooms"
-
-
-DEFINIERT IN
-============
-
- /sys/player/potion.h
-
-
-BESCHREIBUNG
-============
-
- Array mit den Nummern der Raeume, in denen der Spieler noch Zauber-
- traenke hat. Die Freischaltung als bekannt geschieht im Orakel.
- Die Zuordnung der Raeume und Nummern geschieht im Potionmaster.
-
- Nur lesbare _query - Property.
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: FindPotion(), AddKnownPotion(), RemoveKnownPotion(), InList()
- Props: P_KNOWN_POTIONROOMS
-
-6.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_PRAY_ROOM b/doc/sphinx/man/props/P_PRAY_ROOM
deleted file mode 100644
index ad0a469..0000000
--- a/doc/sphinx/man/props/P_PRAY_ROOM
+++ /dev/null
@@ -1,54 +0,0 @@
-
-P_PRAY_ROOM
-***********
-
-
-NAME
-====
-
- P_PRAY_ROOM "_lib_p_pray_room"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Dies ist der Raum, in den der Spieler nach dem Ende der Todessequenz
- bewegt wird, d.h. ein Raum, wo er beten kann, um einen neuen Koerper zu
- erhalten.
- Der Raum muss als String angegeben werden (kein Objekt).
-
- Diese Property wird im Spieler rebootfest gespeichert.
-
- Der jeweils gueltige Betraum wird im Spieler mittels QueryPrayRoom()
- ermittelt. Jede Rasse hat einen Default fuer diese Funktion. Wird die
- Property auf 0 dgesetzt, wird dieser Default wiederhergestellt.
-
- Von einer Ueberlagerung mittels Query- oder gar Setmethoden wird
- abgeraten. Ebenso lasst bitte die Modusbits unveraendert.
-
- Vor einer Aenderung dieser Property sollte geprueft werden, ob sie 0 ist.
- Wenn nicht, sollte von einem Setzen der Property abgesehen werden, da dann
- schon jemand anders den Betraum des Spielers geaendert hat. (Gleiches gilt
- fuers Loeschen.) Bitte niemals den Inhalt der Property woanders speichern
- und spaeter zurueckschreiben.
-
- Eine dauerhafte Aenderung des Betraums des Spielers muss mit dem EM
- Rassen und dem EM Gilden abgestimmt werden.
-
-
-SIEHE AUCH
-==========
-
- QueryPrayRoom(), SetDefaultPrayRoom()
-
-
-LETZTE AeNDERUNG
-================
-
-21.05.2013, Zesstra
diff --git a/doc/sphinx/man/props/P_PREFERED_ENEMY b/doc/sphinx/man/props/P_PREFERED_ENEMY
deleted file mode 100644
index 6b629aa..0000000
--- a/doc/sphinx/man/props/P_PREFERED_ENEMY
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_PREFERED_ENEMY
-****************
-
-
-NAME
-====
-
- P_PREFERED_ENEMY "pref_enemy"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt ein Array mit folgenden Eintraegen:
- Eintrag 1: Integerwert zwischen 0 und 100, welcher die
- Wahrscheinlichkeit dafuer angibt, dass ein
- Lebewesen bevorzugt bei einem Angriff gewaehlt
- werden soll.
- Eintraege ab 2: Lebewesen, aus welchen per Zufall eines
- ausgewaehlt wird, welches beim aktuellen Angriff
- bevorzugt wird.
- Es ist zu beachten, dass solch ein bevorzugtes Opfer natuerlich auch
- wirklich Gegner sein muss und auch im selben Raum zu stehen hat, wie
- der Angreifer. Ist dies nicht der Fall, wird dann doch irgendein
- anderer Gegner aus diesem Raum genommen.
-
-
-SIEHE AUCH
-==========
-
- QueryPreferedEnemy(), IsEnemy(), SelectEnemy(), Attack(),
- /std/living/combat.c, /std/living/life.c
-
-Last modified: Wed May 26 16:44:38 1999 by Patryn
diff --git a/doc/sphinx/man/props/P_PRESAY b/doc/sphinx/man/props/P_PRESAY
deleted file mode 100644
index 1580b5e..0000000
--- a/doc/sphinx/man/props/P_PRESAY
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_PRESAY
-********
-
-
-NAME
-====
-
- P_PRESAY "presay"
-
-
-DEFINIERT IN
-============
-
- /sys/player/description.h
-
-
-BESCHREIBUNG
-============
-
- Presay des Spielers. Erscheint vor dem Namen in Kurz/Langbeschreibung.
- Erscheint auch in name(), also in sag, ruf, teile mit usw.
diff --git a/doc/sphinx/man/props/P_PREVENT_PILE b/doc/sphinx/man/props/P_PREVENT_PILE
deleted file mode 100644
index 1ad6807..0000000
--- a/doc/sphinx/man/props/P_PREVENT_PILE
+++ /dev/null
@@ -1,34 +0,0 @@
-
-P_PREVENT_PILE
-**************
-
-
-NAME
-====
-
- P_PREVENT_PILE "prevent_pile"
-
-
-DEFINIERT IN
-============
-
- /sys/container/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wenn in einem Raum diese Property gesetzt ist, endet das Verwesen einer
- Leiche damit, dass ihr Inventar in dem Raum verteilt wird. Ist diese
- Property nicht gesetzt, entsteht ein "Haufen", der das Inventar
- enthaelt.
-
- Diese Property sollte nur in Ausnahmefaellen benutzt werden!
-
- Diese Property ist vor allem fuer "Store-Rooms" gedacht, in denen die
- Magier die Leiche eines Spieler ablegen und in denen nachher die
- gesammelten Sachen von einer anderen Stelle aus gesucht werden. In
- diesem Fall wuerden Spieler sonst die Moeglichkeit haben, einen Haufen
- als Ganzes zu bekommen, das soll aber *NIE* passieren.
-
-Last modified: Tue May 15 13:56:18 CEST 2007 by Rumata
diff --git a/doc/sphinx/man/props/P_PRE_INFO b/doc/sphinx/man/props/P_PRE_INFO
deleted file mode 100644
index 099e592..0000000
--- a/doc/sphinx/man/props/P_PRE_INFO
+++ /dev/null
@@ -1,86 +0,0 @@
-
-P_PRE_INFO
-**********
-
-
-NAME
-====
-
- P_PRE_INFO "npc_pre_info"
-
-
-DEFINIERT IN
-============
-
- /sys/npc.h
-
-
-BESCHREIBUNG
-============
-
- Ist die Property in einem NPC definiert, so wird ihr Ergebnis
- ausgewertet, bevor eine Frage an das Infosystem uebergeben wird.
-
-
-
- Moegliche Werte:
- - numerischer Wert ungleich 0
- => der NPC gibt _keinerlei_ Antwort, die Frage fuehrt sozusagen
- ins Leere
-
- - Stringwert
- => wird als Rueckgabe an den Fragenden ausgegeben, umstehende
- Personen bekommen den Text:
- "XY ist nicht gewillt, Spieler YZ zu antworten".
- Der Fragende selbst bekommt bei angegebenem Stringwert:
- "XY " + Stringwert.
-
- - Closure
- => die Antwort bzw. Reaktion des NPCs obliegt ganz der
- angegebenen Closure. Diese muss dabei einen String oder
- Ganzzahlen-Wert zurueckgeben
-
-
-BEISPIEL
-========
-
- Ein NPC der manchmal herumrennt, um z.B. eine Aufgabe zu verrichten,
- koennte so lange Chats abschalten, z.B.
-
- SetProp(P_CHAT_CHANCE,0); // NPC latscht los
-
-
-
- Und eine Weile spaeter:
-
-
-
- SetProp(P_CHAT_CHANCE,5); // NPC ruht wieder, quasselt rum
-
-
-
- Waehrend des Herumlaufens, also wenn er nicht automatisch schwatzt,
- soll er auch keinerlei Fragen beantworten:
-
-
-
- Set(P_PRE_INFO, function mixed () {
- return (QueryProp(P_CHAT_CHANCE) ? 0 :
- "hat gerade keine Zeit fuer Dich.");
- }, F_QUERY_METHOD);
-
-
-HINWEISE
-========
-
- Bitte beachten, dass der interne Name der Property "npc_pre_info"
- ist und somit nur das Ueberschreiben von _query_npc_pre_info()
- funktioniert.
-
-
-SIEHE AUCH
-==========
-
- AddInfo(), /std/npc/info.c
-
-Last modified: 01.03.2016 by Arathorn
diff --git a/doc/sphinx/man/props/P_PROMPT b/doc/sphinx/man/props/P_PROMPT
deleted file mode 100644
index 267437e..0000000
--- a/doc/sphinx/man/props/P_PROMPT
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_PROMPT
-********
-
-
-NAME
-====
-
- P_PROMPT "prompt"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Das Prompt (Nur fuer Magier).
diff --git a/doc/sphinx/man/props/P_PUB_NOT_ON_MENU b/doc/sphinx/man/props/P_PUB_NOT_ON_MENU
deleted file mode 100644
index 8618009..0000000
--- a/doc/sphinx/man/props/P_PUB_NOT_ON_MENU
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_PUB_NOT_ON_MENU
-*****************
-
-
-NAME
-====
-
- P_PUB_NOT_ON_MENU "pub_not_on_menu"
-
-
-DEFINIERT IN
-============
-
- /sys/pub.h
-
-
-BESCHREIBUNG
-============
-
- In diese Property kann man einen String schreiben, der ausgegeben
- wird, wenn der Spieler etwas bestellt, was es in der Kneipe nicht
- gibt.
-
-
-BEMERKUNGEN
-===========
-
- Die Standardmeldung ist:
- "Tut mir leid, das fuehren wir nicht! Wir sind ein anstaendiges
- Lokal!\n"
-
-
-SIEHE AUCH
-==========
-
- /std/room/pub.c
-
-Last modified: Sat Mar 04 22:46:00 2000 by Paracelsus
diff --git a/doc/sphinx/man/props/P_PUB_NO_KEEPER b/doc/sphinx/man/props/P_PUB_NO_KEEPER
deleted file mode 100644
index 55c4230..0000000
--- a/doc/sphinx/man/props/P_PUB_NO_KEEPER
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_PUB_NO_KEEPER
-***************
-
-
-NAME
-====
-
- P_PUB_NO_KEEPER "pub_no_keeper"
-
-
-DEFINIERT IN
-============
-
- /sys/pub.h
-
-
-BESCHREIBUNG
-============
-
- In diese Property kann man einen String schreiben, der ausgegeben
- wird, wenn der in P_KEEPER eingetragene NPC nicht anwesend ist.
-
-
-BEMERKUNGEN
-===========
-
- Die Standardmeldung ist:
- "Es ist niemand anwesend, der Dich bedienen koennte.\n"
-
-
-SIEHE AUCH
-==========
-
- /std/room/pub.c
-
-Last modified: Son Apr 11 19:28:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_PUB_NO_MONEY b/doc/sphinx/man/props/P_PUB_NO_MONEY
deleted file mode 100644
index 9510b07..0000000
--- a/doc/sphinx/man/props/P_PUB_NO_MONEY
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_PUB_NO_MONEY
-**************
-
-
-NAME
-====
-
- P_PUB_NO_MONEY "pub_no_money"
-
-
-DEFINIERT IN
-============
-
- /sys/pub.h
-
-
-BESCHREIBUNG
-============
-
- In diese Property kann man einen String schreiben, der ausgegeben
- wird, wenn der Spieler nicht ueber genug Geld verfuegt, um das
- gewuenschte Gericht zu bezahlen.
- Fuer den Preis kann man ein %d als Platzhalter einfuegen.
-
-
-BEMERKUNGEN
-===========
-
- Die Standardmeldung ist:
- "Das kostet %d Goldstuecke, und Du hast nicht so viel!\n"
-
-
-SIEHE AUCH
-==========
-
- /std/room/pub.c
-
-Last modified: Sat Mar 04 22:48:00 2000 by Paracelsus
diff --git a/doc/sphinx/man/props/P_PUB_UNAVAILABLE b/doc/sphinx/man/props/P_PUB_UNAVAILABLE
deleted file mode 100644
index 7eaede7..0000000
--- a/doc/sphinx/man/props/P_PUB_UNAVAILABLE
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_PUB_UNAVAILABLE
-*****************
-
-
-NAME
-====
-
- P_PUB_UNAVAILABLE "pub_unavailable"
-
-
-DEFINIERT IN
-============
-
- /sys/pub.h
-
-
-BESCHREIBUNG
-============
-
- In diese Property kann man einen String schreiben, der ausgegeben
- wird, wenn in einer Kneipe ein Getraenk oder eine Speise nicht mehr
- vorraetig ist.
-
-
-BEMERKUNGEN
-===========
-
- Die Standardmeldung ist:
- "Davon ist leider nichts mehr da.\n"
-
-
-SIEHE AUCH
-==========
-
- /std/room/pub.c
-
-Last modified: Sat Mar 04 22:44:00 2000 by Paracelsus
diff --git a/doc/sphinx/man/props/P_PURSUERS b/doc/sphinx/man/props/P_PURSUERS
deleted file mode 100644
index 05ead3b..0000000
--- a/doc/sphinx/man/props/P_PURSUERS
+++ /dev/null
@@ -1,29 +0,0 @@
-
-P_PURSUERS
-**********
-
-
-NAME
-====
-
- P_PURSUERS "pursuers"
-
-
-DEFINIERT IN
-============
-
- /sys/living/moving.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt Verfolger - nicht von Hand manipulieren!
-
-
-SIEHE AUCH
-==========
-
- AddPursuer(L), RemovePursuer(L)
-
-16.06.2016, Arathorn
diff --git a/doc/sphinx/man/props/P_PUT_MSG b/doc/sphinx/man/props/P_PUT_MSG
deleted file mode 100644
index 65624ce..0000000
--- a/doc/sphinx/man/props/P_PUT_MSG
+++ /dev/null
@@ -1,79 +0,0 @@
-
-P_PUT_MSG
-*********
-
-
-NAME
-====
-
- P_PUT_MSG "put_message"
-
-
-DEFINIERT IN
-============
-
- /sys/living/put_and_get.h
-
-
-BESCHREIBUNG
-============
-
- Mit P_PUT_MSG kann man die Meldung, die man beim Hineinstecken eines
- Objektes in einen Container bekommt, modifizieren.
-
- Folgende Werte sind moeglich:
-
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
-
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
-
- o Ein Array aus Strings
- Der erste String wird an den Spieler ausgegeben, der zweite
- (optionale) an den Raum.
-
- Die Strings werden durch die Funktion replace_personal() geparst.
- Objekt1 - Spieler
- Objekt2 - das Objekt, das irgendwohin gesteckt wird
- Objekt3 - der Container
-
- Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
- Raum.
-
-
-BEISPIEL
-========
-
- void create() {
- ...
- SetProp( P_SHORT, "Etwas Sand" );
- SetProp( P_LONG, break_string(
- "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
-
- SetProp( P_NAME, "Sand" );
- AddId( ({"sand"}) );
- SetProp( P_GENDER, MALE );
-
- SetProp( P_PUT_MSG, ({
- "Du laesst @WEN2 in @WENU3 rieseln.",
- "@WER1 laesst @WEN2 in @WENU3 rieseln."}));
- ...
- }
-
- Das ganze fuehrt bei Ugars "stecke sand in paket" zu folgenden
- Meldungen:
-
- Ugar: "Du laesst den Sand in ein Paket rieseln."
- Raum: "Ugar laesst den Sand in ein Paket rieseln."
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_WEAR_MSG, P_WIELD_MSG
- Fehler: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG,
- P_NOINSERT_MSG, P_NOLEAVE_MSG, P_NODROP, P_NOGET
- Sonstiges: replace_personal(E), put_obj(L), /std/living/put_and_get.c
-
-14. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_QP b/doc/sphinx/man/props/P_QP
deleted file mode 100644
index 9840586..0000000
--- a/doc/sphinx/man/props/P_QP
+++ /dev/null
@@ -1,29 +0,0 @@
-
-P_QP
-****
-
-
-NAME
-====
-
- P_QP "questpoints"
-
-
-DEFINIERT IN
-============
-
- /sys/player/quest.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der Questpunkte, die ein Spieler hat.
-
-
-HINWEIS
-=======
-
- Nur Abfragen der Property mit QueryProp() liefert den korrekten Wert,
- da eine Quermethode fuer die Auslieferung der Daten sorgt. Query()
- oder gar QueryProperties() enthalten u.U. einen veralteten Wert.
diff --git a/doc/sphinx/man/props/P_QUALITY b/doc/sphinx/man/props/P_QUALITY
deleted file mode 100644
index a103eaf..0000000
--- a/doc/sphinx/man/props/P_QUALITY
+++ /dev/null
@@ -1,57 +0,0 @@
-
-P_QUALITY
-*********
-
-
-NAME
-====
-
- P_QUALITY "quality"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Ruestungen und Waffen koennen im Eifer des Gefechts beschaedigt werden.
- Setzt man die Property P_QUALITY auf einen Wert n (n>0), so wird
- eine Waffe (Ruestung) bei jedem n-ten Schlag (Treffer) beschaedigt,
- d.h. P_WC (P_AC) wird um 1 erniedrigt und P_DAMAGED um 1 erhoeht.
-
-
-BEISPIEL
-========
-
- inherit "/std/weapon";
-
- ...
- #include <combat.h>
-
- create()
- {
- ...
- SetProp(P_QUALITY,200);
- ...
- }
-
- Diese Waffe wuerde bei jedem 200. Schlag etwas beschaedigt.
-
-
-BEMERKUNG
-=========
-
- Defaultmaessig ist P_QUALITY auf 0 gesetzt, d.h. die entspr.
- Waffe/Ruestung wird nicht beschaedigt.
-
-
-SIEHE AUCH
-==========
-
- /std/armour.c, /std/weapon.c, TakeFlaw(), QueryFlaw(), Damage()
-
-Last modified: Thu May 22 10:42:39 1997 by Paracelsus
diff --git a/doc/sphinx/man/props/P_QUESTS b/doc/sphinx/man/props/P_QUESTS
deleted file mode 100644
index 84fe435..0000000
--- a/doc/sphinx/man/props/P_QUESTS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_QUESTS
-********
-
-
-NAME
-====
-
- P_QUESTS "quests"
-
-
-DEFINIERT IN
-============
-
- /sys/player/quest.h
-
-
-BESCHREIBUNG
-============
-
- Liste der geloesten Quests.
diff --git a/doc/sphinx/man/props/P_QUEST_ITEM b/doc/sphinx/man/props/P_QUEST_ITEM
deleted file mode 100644
index 135954b..0000000
--- a/doc/sphinx/man/props/P_QUEST_ITEM
+++ /dev/null
@@ -1,73 +0,0 @@
-
-P_QUEST_ITEM
-************
-
-
-NAME
-====
-
- P_QUEST_ITEM "quest_item"
-
-
-DEFINIERT IN
-============
-
- /sys/quest_items.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property gibt an, ob es sich bei dem Objekt um ein Quest-
- relevantes Objekt handelt.
-
-
-BEISPIEL
-========
-
- Ein Schwert (Notung) koennte folgendermassen definiert sein:
-
- create()
- {
- ::create() ;
- SetProp(P_SHORT, "Notung das neidliche Schwert") ;
- SetProp(P_LONG, "Das aus seinen Truemmern neu geschmiedete Schwert "
- "Notung.\n");
-
- SetProp(P_NAME, "Notung");
- SetProp(P_GENDER, NEUTER);
- SetProp(P_ARTICLE,0);
- AddId(({"notung","schwert","Notung", "\nNotung"}));
-
-
-
- SetProp(P_WEAPON_TYPE, WT_SWORD);
- SetProp(P_DAM_TYPE, DT_BLUDGEON);
-
- SetProp(P_QUEST_ITEM,QI_OBJ);
- ...
- }
-
-
-
- Andere Magier koennen nun auf Notung Ruecksicht nehmen, und zum
- Beispiel davon absehen, es bei einem NPC-Spell zu destructen.
-
-
-BEMERKUNGEN
-===========
-
- Alle questrelevanten Objekte sollten auf diese Weise markiert werden.
-
-
-
- Questrelevante Objekte anderer Magier sollten immer mit Vorsicht
- behandelt werden.
-
-
-SIEHE AUCH
-==========
-
- "/sys/quest_items.h"
-
-Last modified: Thu Jul 10 07:08:32 2003 by Vanion
diff --git a/doc/sphinx/man/props/P_RACE b/doc/sphinx/man/props/P_RACE
deleted file mode 100644
index c6aebc7..0000000
--- a/doc/sphinx/man/props/P_RACE
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_RACE
-******
-
-
-NAME
-====
-
- P_RACE "race"
-
-
-DEFINIERT IN
-============
-
- /sys/living/description.h
-
-
-BESCHREIBUNG
-============
-
- Die Rasse eines Lebewesens kann ueber diese Property ermittelt bzw.
- gesetzt werden. Es empfiehlt sich hierbei, Rassen nur in Form von
- grossgeschriebenen Strings zu setzen. Leichen erhalten mittels
- dieser Property automatisch die Rasse der Lebewesen, aus denen sie
- hervorgegangen sind.
- Der Sinn des Ganzen liegt darin, das Spiel differenzierter zu
- gestalten und auf Rassenspezifika einzugehen. Zum Beispiel koennen
- Elfen weniger Alkohol vertragen als Zwerge, was in '/std/pub'
- beruecksichtigt wurde.
-
-
-BEISPIEL
-========
-
- void create()
- { ::create();
- // Definitionen
- SetProp(P_RACE,"Ork");
- // weitere Definitionen
- }
-
-
-SIEHE AUCH
-==========
-
- /std/npc.c, /std/pub.c
-
-Last modified: Mon Sep 15 21:15:49 2003 by Vanion
diff --git a/doc/sphinx/man/props/P_RACESTRING b/doc/sphinx/man/props/P_RACESTRING
deleted file mode 100644
index 2a13577..0000000
--- a/doc/sphinx/man/props/P_RACESTRING
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_RACESTRING
-************
-
-
-NAME
-====
-
- P_RACESTRING "racestring"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Gibt eine dem Geschlecht angepasste Beschreibung der Rasse zurueck
- ("Zwerg" oder "Zwergin" etc.)
diff --git a/doc/sphinx/man/props/P_RACE_DESCRIPTION b/doc/sphinx/man/props/P_RACE_DESCRIPTION
deleted file mode 100644
index ca1f576..0000000
--- a/doc/sphinx/man/props/P_RACE_DESCRIPTION
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_RACE_DESCRIPTION
-******************
-
-
-NAME
-====
-
- P_RACE_DESCRIPTION "racedescr"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Beschreibung der Vor/Nachteile einer Rasse.
diff --git a/doc/sphinx/man/props/P_RANGE b/doc/sphinx/man/props/P_RANGE
deleted file mode 100644
index 2fabc63..0000000
--- a/doc/sphinx/man/props/P_RANGE
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_RANGE
-*******
-
-
-NAME
-====
-
- P_RANGE "range"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Legt die Reichweite einer Schusswaffe fest. Ist ein Schuetze in einem
- Raum mit gueltigem P_TARGET_AREA (andere Raum) oder environment() und
- ist fuer diesen Raum P_SHOOTING_AREA festgelegt, dann kann er mit seiner
- Schusswaffe in diesen anderen Raum schiessen, wenn die P_RANGE groesser
- als P_SHOOTING_AREA ist.
-
-
-BEISPIELE
-=========
-
- // Langbogen mit 100 Reichweite
- SetProp(P_RANGE, 100);
-
-
-SIEHE AUCH
-==========
-
- Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
- Methoden: FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
- Gebiet: P_SHOOTING_AREA, P_TARGET_AREA
- Sonstiges: fernwaffen
-
-29.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/props/P_READ_DETAILS b/doc/sphinx/man/props/P_READ_DETAILS
deleted file mode 100644
index 06a7598..0000000
--- a/doc/sphinx/man/props/P_READ_DETAILS
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_READ_DETAILS
-**************
-
-
-NAME
-====
-
- P_READ_DETAILS "read_details"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Mapping mit den Daten der Details, die durch Lesen ermittelt werden
- koennen.
-
-
-BEMERKUNGEN
-===========
-
- Bitte nur mit den entsprechenden Methoden veraendern!
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddReadDetail()
- Loeschen: RemoveReadDetail()
- Aehnlich: AddDetail(), P_DETAILS
- Veraltet: P_READ_MSG
- Sonstiges: GetDetail(), break_string()
-
-27. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/props/P_READ_NEWS b/doc/sphinx/man/props/P_READ_NEWS
deleted file mode 100644
index 8c69c89..0000000
--- a/doc/sphinx/man/props/P_READ_NEWS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_READ_NEWS
-***********
-
-
-NAME
-====
-
- P_READ_NEWS "read_news"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Welche Artikel bereits gelesen wurde (frueher: in der MPA)
diff --git a/doc/sphinx/man/props/P_REAL_RACE b/doc/sphinx/man/props/P_REAL_RACE
deleted file mode 100644
index 39c196a..0000000
--- a/doc/sphinx/man/props/P_REAL_RACE
+++ /dev/null
@@ -1,95 +0,0 @@
-
-P_REAL_RACE
-***********
-
-
-NAME
-====
-
- P_REAL_RACE "real_race"
-
-
-DEFINIERT IN
-============
-
- /sys/living/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die Rasse des Livings. Sie darf nicht durch
- Shadows ueberschrieben werden.
-
-
-
- Wirklich interessant ist sie, wenn ein Spieler sich tarnt. Dort kann
- man mit dieser Property trotz Tarnung feststellen, welche Rasse der
- Spieler hat.
-
- Bei NPC enthaelt sie den gleichen Wert wie P_RACE. Wenn P_REAL_RACE
- allerdings gesetzt wird, kann man damit einen getarnten NPC simu-
- lieren, da dann P_RACE und P_REAL_RACE voneinander abweichen.
-
-
-BEISPIEL
-========
-
- Ein Zwerg mag Zwergenbrot, fuer Elfen ist es giftig. Selbst wenn der
- Elf sich als Zwerg tarnt, wird ihm durch lembas sicher uebel werden:
-
- int futter(string arg)
- {
- notify_fail("Was willst Du essen?\n");
- if(!arg || !id(arg)) return 0;
-
- notify_fail("Du kannst nichts mehr essen.\n");
- if(!this_player()->eat_food(55)) return 0;
-
- write("Du isst ein Stueck Zwegenbrot. Du versuchst es zumindest!\n");
- say(sprintf("%s beisst in ein Stueck Zwergenbrot. Zahnschmerz!!!\n",
- this_player()->Name()));
-
-
- switch( this_player()->QueryProp(P_REAL_RACE) )
- {
- case "Zwerg":
- if ((this_player()->QueryProp(P_RACE))!="Zwerg")
- write("Zur Tarnung spuckst Du etwas von dem Brot aus!\n");
- this_player()->buffer_hp(100,10);
- this_player()->buffer_sp(100,10);
- break;
-
- case "Elf":
- write("Das Zwergenbrot brennt wie Feuer auf Deiner Zunge!");
- // Getarnt?
- if ((this_player()->QueryProp(P_RACE))!="Elf")
- write(" Deine Tarnung nutzt Dir da wenig.\n"
- else write("\n");
- this_player()->restore_spell_points(-100);
- this_player()->do_damage(100,this_object());
- break;
-
- default:
- write("Du bekommst nur wenig davon herunter..\n");
- this_player()->buffer_hp(10,1);
- this_player()->buffer_sp(10,2);
- break;
- }
-
-
-
- remove();
-
-
-
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- /std/living/description.c, /sys/living/description.h, P_RACE
-
-Last modified: Mon Sep 15 21:15:49 2003 by Vanion
diff --git a/doc/sphinx/man/props/P_REFERENCE_OBJECT b/doc/sphinx/man/props/P_REFERENCE_OBJECT
deleted file mode 100644
index 9187a49..0000000
--- a/doc/sphinx/man/props/P_REFERENCE_OBJECT
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_REFERENCE_OBJECT
-******************
-
-
-NAME
-====
-
- P_REFERENCE_OBJECT "reference_object"
-
-
-DEFINIERT IN
-============
-
- /sys/player/description.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Propertie wird das aktuelle Bezugsobjekt eines Spielers
- gespeichert. Untersucht der Spieler ein Monster, so ist dies das
- Monsterobjekt, untersucht der Spieler sich selber, ist es das
- Spielerobjekt.
-
- Der Inhalt dieser Propertie besteht also immer aus dem zuletzt
- betrachteten Objekt. Sei es ein Raum, eine Ruestung, ein Monster oder
- was auch immer. Bewegungsbefehle und andere Kommandos werden nicht
- beruecksichtigt.
-
- Einzig wenn der Spieler 'schau' tippt, wird der Inhalt der Propertie
- geloescht und betraegt 0.
-
-
-SIEHE AUCH
-==========
-
- Sonstiges: P_INT_LONG, P_LONG, P_SHORT
- int_long(), long(), short(), make_invlist()
-
-Letzte Aenderung: 29.06.02, 23:50:00 h, von Tilly
diff --git a/doc/sphinx/man/props/P_REJECT b/doc/sphinx/man/props/P_REJECT
deleted file mode 100644
index 072bdab..0000000
--- a/doc/sphinx/man/props/P_REJECT
+++ /dev/null
@@ -1,72 +0,0 @@
-
-P_REJECT
-********
-
-
-NAME
-====
-
- P_REJECT "reject"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property zeigt standardmaessig nur in NPCs eine Wirkung. Mit
- ihr laesst sich sehr einfach einstellen, wie sich ein solcher NPC
- gegenueber Gegenstaenden verhalten soll, welche ihm zugesteckt
- werden. Hierbei besteht die Property aus 2 Elementen, welche
- bestimmt, was der NPC mit Dingen tuen soll, die ihm gegeben werden.
- Standardmaessig behaelt der NPC die Sachen einfach.
- Folgende Moeglichkeiten gibt es ausserdem:
- 1. Arrayelement: Art der Handlung. (aus "/sys/moving.h")
- REJECT_GIVE: Der NPC gibt das Objekt zurueck.
- REJECT_DROP: Der NPC laesst das Objekt fallen.
- REJECT_KEEP: Der NPC behaelt das Objekt doch.
- REJECT_LIGHT_MODIFIER: Der NPC nimmt keine Gegenstaende an, die
- sein Lichtlevel veraendern und damit Einfluss auf sein
- Kampfverhalten haben koennten.
- 2. Arrayelement: Meldung, mit welcher der NPC die Handlung
- kommentiert.
- Der Meldung wird nichts automatisch vorangestellt und ein
- abschliessender Zeilenumbruch ist ebenfalls selbstaendig
- vorzunehmen. Mit einem Leerstring ist somit auch gar keine
- Rueckmeldung moeglich.
-
-
-BEISPIEL
-========
-
- Der NPC schmeisst alle ihm gegebenen Gegenstaende einfach weg:
- void create()
- { ::create();
- ...
- SetProp(P_REJECT,({REJECT_GIVE,
- Name(WER)+" murmelt: Was soll ich denn damit?!\n"}));
- ...
- }
- Manchmal ist das recht nuetzlich, z.B. kann man so eigentlich schwer
- zu toetende NPCs dagegen schuetzen, dass man ihnen angezuendetes
- Dynamit oder aehnliches ueberreicht.
-
-
-BEMERKUNGEN
-===========
-
- Innerhalb von NPCs ist die Funktion give_notify() fuer die
- automatische Auswertung dieser Property verantwortlich; das sollte
- man insbesondere beim Ueberschreiben dieser Funktion beachten!
-
-
-SIEHE AUCH
-==========
-
- give_notify(), /std/npc/put_and_get.c
-
-Last modified: Mon Apr 23 16:54:07 2001 by Patryn
diff --git a/doc/sphinx/man/props/P_REMOVE_FUNC b/doc/sphinx/man/props/P_REMOVE_FUNC
deleted file mode 100644
index f5c2232..0000000
--- a/doc/sphinx/man/props/P_REMOVE_FUNC
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_REMOVE_FUNC
-*************
-
-
-NAME
-====
-
- P_REMOVE_FUNC "remove_func"
-
-
-DEFINIERT IN
-============
-
- <armour.h>
-
-
-BESCHREIBUNG
-============
-
- Falls ein Objekt eine RemoveFunc() fuer die Ruestung oder Kleidung
- definiert, so muss dieses Objekt in dieser Property eingetragen sein.
-
- Die Auswertung dieser Property erfolgt im Laufe des DoUnwear() in
- der nicht-oeffentlichen Funktionen _check_unwear_restrictions().
-
-
-BEISPIELE
-=========
-
- Siehe das Beispiel zu RemoveFunc()
-
-
-SIEHE AUCH
-==========
-
- /std/armour.c, /std/clothing.c, clothing, armours
- RemoveFunc()
-
-Letzte Aenderung: 15.02.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_REMOVE_MSG b/doc/sphinx/man/props/P_REMOVE_MSG
deleted file mode 100644
index 78a1357..0000000
--- a/doc/sphinx/man/props/P_REMOVE_MSG
+++ /dev/null
@@ -1,49 +0,0 @@
-
-P_REMOVE_MSG
-************
-
-
-NAME
-====
-
- P_REMOVE_MSG "std_food_remove_msg"
-
-
-DEFINIERT IN
-============
-
- <sys/food.h>
-
-
-BESCHREIBUNG
-============
-
- Meldung, wenn eine verdorbene Speise gerade vernichtet wird.
- Diese Meldung erscheint nur, wenn in P_DESTROY_BAD ein positiver
- Integer-Wert gesetzt ist.
- Befindet sich die Speise in einem Spieler, geht die Meldung an genau
- diesen, liegt die Speise im Raum, geht die Meldung an alle anwesenden
- Spieler.
-
-
-BEMERKUNGEN
-===========
-
- Diese Meldung wird von replace_personal mit den Argumenten:
- 1. Speise
- 2. Konsument
- verarbeitet, kann als entsprechende Platzhalter enthalten
-
-
-DEFAULT
-=======
-
- "@WER1 zerfaellt zu Staub."
-
-
-SIEHE AUCH
-==========
-
- P_DESTROY_BAD, wiz/food, replace_personal
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_RESET_LIFETIME b/doc/sphinx/man/props/P_RESET_LIFETIME
deleted file mode 100644
index bbd4bbe..0000000
--- a/doc/sphinx/man/props/P_RESET_LIFETIME
+++ /dev/null
@@ -1,52 +0,0 @@
-
-P_RESET_LIFETIME
-****************
-
-
-NAME
-====
-
- P_RESET_LIFETIME "std_food_lifetime_reset"
-
-
-DEFINIERT IN
-============
-
- /sys/food.h
-
-
-BESCHREIBUNG
-============
-
- Zeit in Resets, die die Speise haltbar ist.
- Jeder einzelne Reset wird in seiner Laenge zufaellig festgelegt und
- zu einer Gesamtanzahl von Sekunden zusammengefasst. Diese Zeit in
- Sekunden wird dann in P_LIFETIME gespeichert.
- Nach dieser Zeit wird diese Speise schlecht und je nach Konfiguration
- der Speise eventuell zerstoert. Sichergestellt wird dies durch den
- Aufruf von reset() nach dieser Anzahl "Resets".
- Moechte man eine Speise haben, die niemals verdirbt
- (genehmigungspflichtig!), nutzt man die Property P_NO_BAD
-
-
-BEMERKUNGEN
-===========
-
- Sobald der Countdown zum Schlechtwerden der Speise laeuft, also ein
- Spieler damit in Beruehrung kam, zeigt SetProp auf diese Property keine
- Wirkung mehr.
-
-
-DEFAULT
-=======
-
- Ohne Setzen von P_LIFETIME ,P_RESET_LIFETIME und P_NO_BAD verdirbt die
- Speise nach einem Reset, also zwischen 30 und 60 Minuten
-
-
-SIEHE AUCH
-==========
-
- wiz/food, P_LIFETIME, P_NO_BAD
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_RESISTANCE b/doc/sphinx/man/props/P_RESISTANCE
deleted file mode 100644
index 48e476f..0000000
--- a/doc/sphinx/man/props/P_RESISTANCE
+++ /dev/null
@@ -1,61 +0,0 @@
-
-P_RESISTANCE
-************
-
-
-NAME
-====
-
- P_RESISTANCE "resistance"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-WICHTIG
-=======
-
- DIESE PROPERTY IST VERALTET! BITTE P_RESISTANCE_STRENGTHS
- VERWENDEN! AUCH FUNKTIONIERT Set() NICHT WIE ES SOLLTE.
-
-
-BESCHREIBUNG
-============
-
- Hiermit koennen die Resistenzen eines Lebewesens sehr einfach gesetzt
- werden. Es kann ein Array mit Schadensarten gesetzt werden, jeder
- Eintrag eines Schadens verdoppelt die Resistenz gegen diesen.
-
-
-BEMERKUNGEN
-===========
-
- - P_RESISTANCE_STRENGTHS spiegelt diese Eintraege hier wieder
- - um genauere Werte anzugeben einen AddResistanceModifier() oder
- P_RESISTANCE_STRENGTHS benutzen.
- - P_RESISTANCE kann und wird nicht aus P_RESISTANCE_STRENGTHS
- upgedatet
-
-
-BEISPIELE
-=========
-
- // ein NPC mit halbierter Feuerempfindlichkeit und
- // geviertelter Windempfindlichkeit
- SetProp(P_RESISTANCE, ({DT_FIRE, DT_AIR, DT_AIR}));
-
-
-SIEHE AUCH
-==========
-
- simple Resistenz: P_RESISTANCE
- Modifikatoren: AddResistanceModifier, RemoveResistanceModifier(),
- P_RESISTANCE_MODIFIER
- Hauptmapping: P_RESISTANCE_STRENGTHS
- Berechnung: CheckResistance(), UpdateResistanceStrengths()
- anderes: balance, /std/armour/combat.c, /std/living/combat.c
-
-1.Dez 2004, Gloinson
diff --git a/doc/sphinx/man/props/P_RESISTANCE_MODIFIER b/doc/sphinx/man/props/P_RESISTANCE_MODIFIER
deleted file mode 100644
index 2a3322e..0000000
--- a/doc/sphinx/man/props/P_RESISTANCE_MODIFIER
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_RESISTANCE_MODIFIER
-*********************
-
-
-NAME
-====
-
- P_RESISTANCE_MODIFIER "rstr:mod"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Hier werden die Resistenzmodifikatoren in einem Mapping abgespeichert.
-
- Format:
-
- (["me":<Aufaddition aller Resistenz/Empfindlichkeitsmodifikationen>;0,
- "<Objektname>#<Schluessel>":<Resistenzmapping>;<Objekreferenz>,
- ...])
-
-
-BEMERKUNGEN
-===========
-
- Nur ueber AddResistanceModifier(), RemoveResistanceModifier() aendern!
-
-
-SIEHE AUCH
-==========
-
- Modifikatoren: AddResistanceModifier, RemoveResistanceModifier()
- simple Resistenz: P_RESISTANCE, P_VULNERABILITY
- Hauptmapping: P_RESISTANCE_STRENGTHS
- Berechnung: CheckResistance(), UpdateResistanceStrengths()
- anderes: balance, /std/armour/combat.c, /std/living/combat.c
-
-29.Apr 2002, Gloinson@MG
diff --git a/doc/sphinx/man/props/P_RESISTANCE_STRENGTHS b/doc/sphinx/man/props/P_RESISTANCE_STRENGTHS
deleted file mode 100644
index 4a93f08..0000000
--- a/doc/sphinx/man/props/P_RESISTANCE_STRENGTHS
+++ /dev/null
@@ -1,114 +0,0 @@
-
-P_RESISTANCE_STRENGTHS
-**********************
-
-
-NAME
-====
-
- P_RESISTANCE_STRENGTHS "resistance_strengths"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Lebewesen:
-
- Mapping mit Schadensarten, gegen die das Lebewesen resistent oder
- anfaellig ist. Durch eine _query_method werden alle existierenden
- Resistenzen hier zusammengefasst.
-
- Die Staerke der Resistenz oder Anfaelligkeit wird numerisch aus-
- gedrueckt:
- - Resistenzen gehen bis von 0 bis -1.0 (absolute Resistenz)
- - -0.5 == halbierter Schaden, -0.75 == geviertelter Schaden
- -> in % des "aufgehaltenen" Schadens interpretierbar
- - Empfindlichkeiten gehen von 0 bis MAX_INT
- - 1.0 == verdoppelter Schaden, 3.0 == vervierfachter Schaden
- -> als Faktor (x+1.0) interpretierbar
-
- Ruestungen:
-
- Mapping mit Prozentwerten der Maximalwerte fuer Ruestungen des
- entsprechenden Typs. Dabei sind positive Werte Resistenzen und
- negative Empfindlichkeiten. Dabei duerfen die Prozentwerte nur
- im Bereich von +100 bis -800 (-1000 ?!) liegen.
-
- Bei Ruestungen ist es damit unnoetig, Resistenzen mittels
- AddResistanceModifier() im Traeger zu setzen, da dies bereits
- in /std/armour automatisch gemacht wird. Der Schluessel fuer
- den Eintrag ist dabei P_ARMOUR_TYPE.
-
- Die Maximalwerte sind derzeit:
- AT_CLOAK, AT_RING, AT_AMULET: max 10% Resistenz
- AT_SHIELD, AT_ARMOUR: max 15% Resistenz
- alle anderen: max 5% Resistenz
-
-
-BEMERKUNGEN
-===========
-
- Ruestungen:
- * die Property muss _nach_ P_ARMOUR_TYPE gesetzt werden (_set-Method)
-
- Lebewesen:
- * -1.0 bedeutet bereits absolute Resistenz, bei kleineren Werten werden
- die anderen Schadensanteile im Kampf u.U. nicht mehr wie gewuenscht
- bilanziert. Bitte daher drauf verzichten. ;-)
- * Aenderungen an P_RESISTANCE und P_VULNERABILITY werden direkt in
- P_RESISTANCE_STRENGTHS gespeichert:
- -> daher niemals im Nachhinein bei fremden NPCs P_RESISTANCE_STRENGTHS
- manipulieren, dafuer gibt es AddResistanceModifier
- * QueryProp(P_RESISTANCE_STRENGTHS) enthaelt die gesamten Resistenzen
- P_RESISTANCE, P_VULNERABILITY, P_RESISTANCE_MODIFIER (_query-Method)
-
- Die Werte in P_RESISTANCE_STRENGTHS sollten nur in Ausnahmefaellen oder
- gut begruendet den Hoechstwert haben. Ein Eiswesen kann zwar sehr
- resistent gegen Kaelteschaden sein, sollte aber zu gleichem Teil auch
- anfaellig auf Feuerschaden sein.
-
- Auf dieser Property liegt eine Querymethode, welche eine Kopie der
- Daten zurueckliefert.
-
-
-BEISPIELE
-=========
-
- // ein Eistroll
- SetProp(P_RESISTANCE_STRENGTHS,([DT_FIRE:0.5,DT_COLD:-0.5,
- DT_MAGIC:0.1]));
-
- Feuerangriffe werden mit 1.5 multipliziert, magische mit 1.1 und
- der Schadenswert von Kaelteangriffen wird halbiert. Zum Beispiel
- wuerde
- Defend(100, ({DT_FIRE,DT_MAGIC}), ...)
- einen Schaden von 130 statt den normalen 100 verursachen.
-
-
- // eine Eisruestung
- SetProp(P_RESISTANCE_STRENGTHS, ([DT_COLD:50, DT_FIRE:-100]));
-
- Dieses Kettenhemd schuetzt nun mit 50% des Maximalwertes gegen
- Kaelte (also 0.5*15%=7,5% Resistenz) und macht mit dem Maximal-
- wert anfaellig gegen Feuer (1*15%=15% Empfindlichkeit).
-
- ! der Code spricht zusaetzlich von
- Empfindlichkeit=(Empfindlichkeit/4)*5 -> 15/4*5=18.75% !
-
-
-SIEHE AUCH
-==========
-
- simple Resistenz: P_RESISTANCE, P_VULNERABILITY
- Modifikatoren: AddResistanceModifier, RemoveResistanceModifier(),
- P_RESISTANCE_MODIFIER
- Berechnung: CheckResistance(), UpdateResistanceStrengths()
- anderes: balance, /std/armour/combat.c, /std/living/combat.c
-
-6.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_RESTRICTIONS b/doc/sphinx/man/props/P_RESTRICTIONS
deleted file mode 100644
index a1764b9..0000000
--- a/doc/sphinx/man/props/P_RESTRICTIONS
+++ /dev/null
@@ -1,163 +0,0 @@
-
-P_RESTRICTIONS
-**************
-
-
-NAME
-====
-
- P_RESTRICTIONS "restrictions"
-
-
-DEFINIERT IN
-============
-
- /sys/combat.h
- (Die SR_*-Parameter sind in /sys/new_skills.h definiert.)
-
-
-BESCHREIBUNG
-============
-
- Enthaelt ein mapping mit den zu pruefenden Einschraenkungen.
-
- In dieser Property lassen sich Restriktionen setzen, die vor dem
- Zuecken einer Waffe / Anziehen einer Ruestung oder Kleidung geprueft
- werden und dies gegebenfalls verhindern, ohne gleich auf eine evtl.
- vorhandene WieldFunc / WearFunc zuzugreifen.
-
- Die Auswertung erfolgt ueber den Aufruf von check_restrictions()
- in /std/restriction_checker.c
-
- Folgende Keys werden in dem Mapping ausgewertet:
-
- P_LEVEL
- Mindeststufe, die das Lebewesen besitzen muss, um die Aktion
- auszufuehren.
- P_GUILD_LEVEL
- Gildenlevel, das das Lebewesen mindestens erreicht haben muss, um die
- Aktion auszufuehren.
- SR_SEER
- Ist gesetzt, wenn das Lebewesen Seher sein muss.
- Auswertung nur fuer Interactives, NSC ignorieren das Flag.
- P_XP
- Mindestmenge an Erfahrungspunkten, die ein Lebewesen besitzen muss,
- um die Aktion auszufuehren.
- P_QP
- Mindestmenge an Abenteuerpunkten, die das Lebewesen haben muss.
- P_ALCOHOL
- Menge an Alkohol, unter der der Alkoholspiegel des Lebewesen liegen
- muss, um die Aktion noch ausfuehren zu koennen.
- P_DRINK
- Menge an Fluessigkeit, unter der der Fluessigkeitsspiegel des
- Lebewesen liegen muss, um die Aktion noch ausfuehren zu koennen.
- P_FOOD
- Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel des
- Spielers liegen muss, um die Aktion noch ausfuehren zu koennen.
- P_DEAF
- Ist gesetzt, falls der Spieler nicht taub sein darf.
- P_FROG
- Ist gesetzt, falls der Spieler kein Frosch sein darf.
- P_BLIND
- Ist gesetzt, falls der Spieler nicht blind sein darf.
- Achtung: das ist nicht gleichbedeutend mit dem Umstand, dass er evtl.
- nichts mehr sehen kann. Auch andere Gruende (zum Beispiel Dunkelheit)
- koennen bewirken, dass ein Spieler nichts mehr sieht.
- A_INT, A_DEX, A_CON, A_STR
- Jeweilige Mindesthoehe eines Attribut, um eine Aktion ausfuehren zu
- koennen.
- SR_BAD, SR_GOOD
- Gibt an, wie [minimal] boese bzw. wie [maximal] gut ein Charakter sein
- darf, um eine Aktion ausfuehren zu koennen.
- SR_MIN_SIZE, SR_MAX_SIZE
- Gibt die minimale, bzw. die maximale Groesse an, die ein Charakter
- maximal haben darf, um eine Aktion ausfuehren zu koennen.
- SR_FREE_HANDS
- Gibt an, wieviele freie Haende ein Charakter fuer diese Aktion
- besitzen muss.
- SR_EXCLUDE_RACE
- Mitglieder aller in dieser Liste aufgefuehrten Rassen koennen
- diese Aktion nicht ausfuehren.
- SR_INCLUDE_RACE
- Mitglieder aller NICHT in dieser Liste aufgefuehrten Rassen koennen
- diese Aktion nicht ausfuehren.
- SM_RACE
- Hier kann pro Rasse ein Mapping mit besonderen (nur) fuer diese Rasse
- geltenden Einschraenkungen vorgenommen werden. Als Keys sind die
- in dieser Manpage beschriebenen Keys erlaubt, wobei SM_RACE nicht
- rekursiv ausgewertet wird.
- Der Rassenname ist gross geschrieben und "*" steht fuer alle Rassen.
- SR_EXCLUDE_GUILD
- SR_INCLUDE_GUILD
- Diese beiden Keys verhalten sich wie SR_*_RACE, nur dass hier Gilden
- genannt werden.
- SR_FUN
- Hier kann eine Funktion in verschiedenen Formen zum Pruefen der
- Restriktionen angegeben werden, siehe execute_anything().
- Das kann nuetzlich sein, um andere Restriktionen zu pruefen,
- wie das Bestehen von Miniquests oder andere Faehigkeiten/Flags.
- Ist der Test nicht bestanden, gibt die Funktion einen String zurueck.
- SR_PROP
- Hier kann ein Mapping mit Properties und zugehoerigen Werten angegeben
- werden, die jeweils auf Identitaet geprueft werden. Zusaetzlich sollte
- eine Meldung angegeben werden, die als Fehlermeldung ausgegeben wird,
- wenn der Spieler die Bedingung nicht erfuellt. Es sollte immer eine
- passende Meldung fuer den Spieler eingebaut werden. Beispiel:
- ([ SR_PROP: ([P_AUSGANG_ENTDECKT: 1; "Dein Schwert fluestert "
- "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn Du "
- "Dich als wuerdig erwiesen hast!"]) ])
- Aufgrund der Meldung wird empfohlen, SR_PROP nicht in Restriktionen
- einzusetzen, die massenweise in Savefiles landen (z.B.
- Spielersavefiles).
- SR_QUEST
- Hier kann ein String-Array mit den Namen (Keys) der Quest(s) angegeben
- werden, die der Spieler bestanden haben muss, um die Aktion ausfuehren
- zu koennen.
- SR_MINIQUEST
- Hier kann entweder ein String-Array mit den Ladenamen der vergebenden
- Objekte oder ein Int-Array mit den Index-Nummern (IDs) der
- Miniquest(s) (empfohlen!) angegeben werden, die der Spieler bestanden
- haben muss, um die Aktion ausfuehren zu koennen.
-
-
-BEMERKUNGEN
-===========
-
- Diese Property eignet sich hervorragend dafuer, einige Grundbedingungen
- fuer das Nutzen der Waffe / Ruestung / Kleidung zu stellen ohne gleich
- eine Wield- oder WearFunc setzen und auswerten zu muessen.
-
- Denkbar waere der Einsatz bei hochwertigen Waffen / Ruestungen / Kleidung,
- z.B. aus der Para-Welt oder solchen, die sich nah am Limit der geltenden
- Grenzwerte fuer P_WC / P_AC bewegen oder sogar (nach Genehmigung durch
- die Balance) darueber.
-
-
-BEISPIEL
-========
-
- Mindeststufe 25: SetProp(P_RESTRICTIONS,([P_LEVEL:25]));
- Keine Menschen: SetProp(P_RESTRICTIONS,([SR_EXCLUDE_RACE:({"Mensch"})]));
- Alignment >499: SetProp(P_RESTRICTIONS,([SR_GOOD:500]));
-
- Komplexeres Beispiel
-
- Quest "Diamond Club" bestanden, magiereigene Property P_AUSGANG_GEFUNDEN
- muss gesetzt sein, Stufe 10, nicht taub, max. 45 Food:
- SetProp(P_RESTRICTIONS, ([ P_LEVEL: 10, P_DEAF: 1, P_FOOD: 45,
- SR_PROP: ([P_AUSGANG_GEFUNDEN:1]), SR_QUEST:({"Diamond Club"}) ]));
-
-
-SIEHE AUCH
-==========
-
- check_restrictions(L)
- WieldFunc(L), WearFunc(L), RemoveFunc(L), UnwieldFunc(L),
- P_WIELD_FUNC, P_WEAR_FUNC, P_REMOVE_FUNC, P_UNWIELD_FUNC
- /std/armour/wear.c, /std/weapon/combat.c, clothing, armours, weapon
-
-
-LETZTE AeNDERUNG
-================
-
-3. Januar 2014, Arathorn
diff --git a/doc/sphinx/man/props/P_ROOM_MSG b/doc/sphinx/man/props/P_ROOM_MSG
deleted file mode 100644
index 3486458..0000000
--- a/doc/sphinx/man/props/P_ROOM_MSG
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_ROOM_MSG
-**********
-
-
-NAME
-====
-
- P_ROOM_MSG "room_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/room/description.h
-
-
-BESCHREIBUNG
-============
-
- Liste mit Meldungen, die zufaellig im Raum ausgegeben werden.
-
- Hier sind nur die Textmeldungen als String-Array gespeichert.
-
-
-ANMERKUNGEN
-===========
-
- Bitte AddRoomMessage() zum Hinzufuegen/Ueberschreiben benutzen!
-
-
-SIEHE AUCH
-==========
-
- LFuns: AddRoomMessage()
- Verwandt: tell_room(), ReceiveMsg()
- Props: P_FUNC_MSG, P_MSG_PROB
-
-2.Feb 2016 Gloinson
diff --git a/doc/sphinx/man/props/P_ROOM_TYPE b/doc/sphinx/man/props/P_ROOM_TYPE
deleted file mode 100644
index 22e894e..0000000
--- a/doc/sphinx/man/props/P_ROOM_TYPE
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_ROOM_TYPE
-***********
-
-
-NAME
-====
-
- P_ROOM_TYPE "room_type"
-
-
-DEFINIERT IN
-============
-
- /sys/rooms.h
-
-
-BESCHREIBUNG
-============
-
- In P_ROOM_TYPE wird die Art des Raumes durch entsprechende Flags
- beschrieben.
-
- Bisher unterstuetzt werden:
- - RT_SHOP fuer Raeume, die /std/room/shop inheriten
- - RT_PUB fuer Raeume, die /std/room/pub inheriten
-
-
-BEISPIEL
-========
-
- Wenn ein NPC abfragen moechte, ob er sich in einer Kneipe aufhaelt (um
- selbststaendig tanken zu koennen) koennte eine Abfrage z.B. so aussehen:
-
- if ( environment() &&
- environment()->QueryProp(P_ROOM_TYPE) & RT_PUB ){
-
- ... tanken ...
- }
diff --git a/doc/sphinx/man/props/P_SB_SPELLS b/doc/sphinx/man/props/P_SB_SPELLS
deleted file mode 100644
index 1ffac9d..0000000
--- a/doc/sphinx/man/props/P_SB_SPELLS
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_SB_SPELLS
-***********
-
-
-NAME
-====
-
- P_SB_SPELLS "sb_spells"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Spellbookproperty sind saemtliche Sprueche des Spellbooks
- vermerkt. Veraendert wird sie durch AddSpell().
-
-
-BEMERKUNGEN
-===========
-
- Man sollte diese Property nicht per Hand veraendern, sondern die
- Funktion AddSpell() nutzen.
-
-
-SIEHE AUCH
-==========
-
- GObj Verwalten: LearnSkill, LearnSpell, InitialSkillAbility
- * Properties: P_GUILD_SKILLS
- Spellbook Lernen: Learn, SpellSuccess, Erfolg, Misserfolg
- * Verwalten: AddSpell, QuerySpell
- * Properties: P_GLOBAL_SKILLPROPS
- Skills: P_NEWSKILLS, spruchermuedung, skill_info_liste
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_SCREENSIZE b/doc/sphinx/man/props/P_SCREENSIZE
deleted file mode 100644
index e54ee8b..0000000
--- a/doc/sphinx/man/props/P_SCREENSIZE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_SCREENSIZE
-************
-
-
-NAME
-====
-
- P_SCREENSIZE "screensize"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Bildschirmgroesse in Zeilen (fuer More)
diff --git a/doc/sphinx/man/props/P_SECOND b/doc/sphinx/man/props/P_SECOND
deleted file mode 100644
index 69c97d6..0000000
--- a/doc/sphinx/man/props/P_SECOND
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_SECOND
-********
-
-
-NAME
-====
-
- P_SECOND "second"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Wenn diese Prop gesetzt ist, ist der Spieler ein Zweitie. Inhalt der
- Prop ist ein String mit dem (lowercase) Namen des Ersties.
-
-
-BEISPIEL
-========
-
- if (this_player()->QueryProp(P_SECOND)=="notstrom") {
- tell_object(this_player(), "Nicht alles aufessen!\n");
- }
-
-
-SIEHE AUCH
-==========
-
- Properties: P_SECOND_MARK
- Sonstiges: /secure/zweities.c
-
-Last modified: 18-Jun-2015, Arathorn.
diff --git a/doc/sphinx/man/props/P_SECOND_MARK b/doc/sphinx/man/props/P_SECOND_MARK
deleted file mode 100644
index dd2c68a..0000000
--- a/doc/sphinx/man/props/P_SECOND_MARK
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_SECOND_MARK
-*************
-
-
-NAME
-====
-
- P_SECOND_MARK "second_mark"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Gibt an, wie mit der Zweitie-Markierung eines Spielers umgegangen wird.
-
- -1 'unsichtbare' Markierung; im wer/kwer wird bei diesem Zweitie s
- oder S angezeigt.
-
- 0 'sichtbare' Markierung; im wer/kwer wird bei diesem Zweitie z oder
- Z angezeigt. Der Name des Ersties ist beim Fingern jedoch nur
- fuer Magier sichtbar.
-
- 1 Markierung 'sichtbar + Name'; wie 0, nur dass beim Fingern alle
- Spieler den Namen des Ersties sehen koennen.
diff --git a/doc/sphinx/man/props/P_SEERDOORS b/doc/sphinx/man/props/P_SEERDOORS
deleted file mode 100644
index 8ec02e7..0000000
--- a/doc/sphinx/man/props/P_SEERDOORS
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_SEERDOORS
-***********
-
-
-NAME
-====
-
- P_SEERDOORS "rw_sehertore"
-
-
-DEFINIERT IN
-============
-
- /d/seher/portale/sehertor.h
-
-
-BESCHREIBUNG
-============
-
- Sehertor-relevante Property.
-
- Enthaelt ein Mapping mit den Wertepaaren
- ([ Seher-Portal-Nummer: x ])
- mit x != 0 fuer entdeckte Tore.
-
-
-
- 0 hat ein Sonderverhalten fuer mobile Tore.
-
-
-BEMERKUNG
-=========
-
- Auf gar keinen Fall in Spielern manipulieren! Und bitte das enthaltene
- Mapping nicht von einem Spieler abfragen und P_SEERDOORS in einem
- Testspieler zuweisen!
-
-
-SIEHE AUCH
-==========
-
- P_FAO_PORTALS
-
-1.September 2008 Gloinson
diff --git a/doc/sphinx/man/props/P_SEERDOOR_ALLOWED b/doc/sphinx/man/props/P_SEERDOOR_ALLOWED
deleted file mode 100644
index 12f062b..0000000
--- a/doc/sphinx/man/props/P_SEERDOOR_ALLOWED
+++ /dev/null
@@ -1,27 +0,0 @@
-
-P_SEERDOOR_ALLOWED
-******************
-
-
-NAME
-====
-
- P_SEERDOOR_ALLOWED "rw_sehertor_erlaubt"
-
-
-DEFINIERT IN
-============
-
- /d/seher/portale/sehertor.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property muss in einem Raum gesetzt sein, soll
- ein Seher dort ein mobiles Sehertor abstellen duerfen.
- Zusaetzlich darf der Raum nicht in PARA liegen und muss
- als eigenes File existieren.
- Es ist darauf zu achten, Sehertore nicht in Questgebieten,
- direkt an Tanken oder aehnlichen Plaetzen zu erlauben.
- Es gilt die Einschaetzung des fuer den Raum Verantwortlichen.
diff --git a/doc/sphinx/man/props/P_SENSITIVE b/doc/sphinx/man/props/P_SENSITIVE
deleted file mode 100644
index c1e8051..0000000
--- a/doc/sphinx/man/props/P_SENSITIVE
+++ /dev/null
@@ -1,154 +0,0 @@
-
-P_SENSITIVE
-***********
-
-
-NAME
-====
-
- P_SENSITIVE "sensitive"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property kann in Objekten gesetzt werden, die auf bestimmte
- Schadensarten empfindlich reagieren sollen. Moegliche Anwendungsfaelle:
- - Das Lebewesen, in dessen Inventar sich ein Objekt befindet, erleidet
- einen Angriff mit der fraglichen Schadensart (Beispiel: eine
- Pusteblume, die bei Angriff mit Luftschaden auseinanderfaellt).
- - Zwei Objekte treffen im gleichen Environment aufeinander, wobei
- eines empfindlich auf eine Schadensart reagiert, und das zweite diese
- Schadensart mitbringt, d.h. die Empfindlichkeit ausloesen kann.
- (Beispiel: ein feuerempfindlicher Postsack wird angesengt, wenn eine
- brennende Fackel ins gleiche Inventar kommt.)
- Das Ausloesen dieser Empfindlichkeit ist unabhaengig davon, welches
- Objekt zuerst da war.
-
- Die Property enthaelt ein Array aus Arrays:
- ({<sensprops_1>, <sensprops_2>, ..., <sensprops_n>})
-
-
-
- wobei jeder Eintrag <sensprops> jeweils folgende Struktur hat:
- ({string list_key, string damtype, int treshold, mixed options })
-
-
-
- Die Eintraege haben dabei folgende Bedeutung:
-
-
-
- list_key: Kann einen von folgenden drei Werten annehmen
- 1) SENSITIVE_INVENTORY, passive Eigenschaft; zeigt an, dass das
- Objekt empfindlich auf aktive Objekte reagiert, die in das
- Inventory des Containers hineinbewegt werden
- 2) SENSITIVE_ATTACK, passive Eigenschaft; zeigt an, dass das
- Objekt empfindlich auf aeussere Einfluesse bzw. Angriffe
- auf ein Lebewesen reagiert, in dessen Inventar es sich befindet
- 3) SENSITIVE_INVENTORY_TRIGGER, aktive Eigenschaft; zeigt an, dass
- das Objekt eine Ausstrahlung auf andere Objekte im Inventar
- hat. Wird ausgeloest, wenn das Objekt ins Inventar hineinbewegt
- wird.
- damtype: eine Schadensart (DT_FIRE, DT_WATER, ...)
- treshold: hat zwei Bedeutungen abhaengig von dem Wert in list_key:
- 1) Fuer Objekte mit SENSITIVE_INVENTORY oder SENSITIVE_ATTCK ist
- dies der Schadenswert, ab dem das Objekt benachrichtigt werden
- soll.
- Hier wird ein Wert in "Defend-Einheiten" erwartet, d.h. das
- Zehnfache dessen, was am Ende in LP abgezogen wuerde.
- 2) Fuer Objekte mit SENSITIVE_INVENTORY_TRIGGER ist dies der
- Schadenswert, mit dem das Objekt andere bereits im Inventar
- des Containers befindliche Objekte beeinflusst, die eine
- entsprechende Empfindlichkeit gesetzt haben
- options: Optionale Daten, die der programmierende Magier selbst
- definieren kann. Werden an die in den betroffenen Objekten
- aufgerufenen Funktionen durchgereicht.
-
- Ein SENSITIVE_ATTACK-Objekt, dessen Trigger-Bedingungen erfuellt sind,
- wird durch folgenden Funktionsaufruf darueber informiert:
- trigger_sensitive_attack(object enemy, string damtype, int damage,
- mixed spell, mixed options)
-
-
-
- Ein SENSITIVE_INVENTORY-Objekt, dessen Trigger-Bedingungen erfuellt sind,
- wird durch folgenden Funktionsaufruf darueber informiert:
- trigger_sensitive_inv(object whodid, string damtype, int threshold,
- mixed options, mixed options)
-
- Die beiden Funktionen muessen selbst ge-/ueberschrieben werden.
-
-
-BEMERKUNGEN
-===========
-
- 1. P_SENSITIVE-Objekte kosten Rechenzeit bei jedem Angriff oder jedem
- move() - daher bitte sparsam verwenden
- 2. Ist P_SENSITIVE nicht statisch, sondern wird es situationsabhaengig
- geaendert, muss man das environment() jeweils selbst ueber seine
- neue Empfindlichkeit benachrichtigen. Dies geschieht mit den
- Funktionen RemoveSensitiveObject() bzw.InsertSensitiveObject(),
- siehe deren Manpages.
-
-
-BEISPIEL
-========
-
- Beispiel 1:
- Beispielcode eines Objektes mit SENSITIVE_ATTACK und SENSITIVE_INVENTORY
- siehe hier: /doc/beispiele/testobjekte/attack_busy_sensitive_testobj.c
-
- Beispiel 2:
- Ein Eiszapfen, der bei Feuerangriffen oder bei heissen Gegenstaenden im
- gemeinsamen Environment zerschmelzen soll:
-
- void create() {
- SetProp( P_SENSITIVE, ({ ({SENSITIVE_ATTACK, DT_FIRE, 100}),
- ({SENSITIVE_INVENTORY, DT_FIRE, 100}) }) );
- [...]
- }
-
- varargs void trigger_sensitive_attack() {
- remove();
- }
-
- varargs void trigger_sensitive_inv() {
- call_out("remove",0); // verzoegert, wegen move()
- }
-
- varargs int remove(int silent) {
- if(!silent) {
- object room = all_environment(this_object())[<1];
- tell_room(room, Name()+" zerschmilzt.\n");
- }
- return ::remove();
- }
-
- - wird eine Fackel mit
- SetProp(P_SENSITIVE,({({SENSITIVE_INVENTORY_TRIGGER,DT_FIRE,250})}))
- in das gleiche environment() wie dieser Zapfen bewegt wird, loest
- diese im Zapfen trigger_sensitive_inv() aus
- - wird ein Angriff mit DT_FIRE und initialem Schaden > 100 auf das
- environment() veruebt, loest dies im Zapfen trigger_sensitive_attack()
- aus
-
-
-SIEHE AUCH
-==========
-
- Properties: P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY,
- P_SENSITIVE_INVENTORY_TRIGGER
- Funktionen: InsertSensitiveObject(L), RemoveSensitiveObject(L),
- CheckSensitiveAttack(L), Defend(),
- insert_sensitive_inv(L), insert_sensitive_inv_trigger(L),
- trigger_sensitive_inv(L), trigger_sensitive_attack(L)
- Defines: /sys/sensitive.h
-
-Letzte Aenderung: 10. Januar 2015, Arathorn
diff --git a/doc/sphinx/man/props/P_SENSITIVE_ATTACK b/doc/sphinx/man/props/P_SENSITIVE_ATTACK
deleted file mode 100644
index 168c15b..0000000
--- a/doc/sphinx/man/props/P_SENSITIVE_ATTACK
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_SENSITIVE_ATTACK
-******************
-
-
-NAME
-====
-
- P_SENSITIVE_ATTACK "sensitive_attack"
-
-
-DEFINIERT IN
-============
-
- /sys/sensitive.h
-
-
-BESCHREIBUNG
-============
-
- Hier steht die Liste der zu informierenden Objekte, die potentiell
- auf einen Angriff reagieren koennten.
- Wird von InsertSensitiveObject() und RemoveSensitiveObject()
- geschrieben und in CheckSensitiveAttack() ausgewertet.
-
-
-BEMERKUNGEN
-===========
-
- Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
-
-
-SIEHE AUCH
-==========
-
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_INVENTORY_TRIGGER, P_SENSITIVE_INVENTORY
- CheckSensitiveAttack
-
-25.Apr.2001, Gloinson@MG
diff --git a/doc/sphinx/man/props/P_SENSITIVE_INVENTORY b/doc/sphinx/man/props/P_SENSITIVE_INVENTORY
deleted file mode 100644
index 418f9a1..0000000
--- a/doc/sphinx/man/props/P_SENSITIVE_INVENTORY
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_SENSITIVE_INVENTORY
-*********************
-
-
-NAME
-====
-
- P_SENSITIVE_INVENTORY "sensitive_inv"
-
-
-DEFINIERT IN
-============
-
- /sys/sensitive.h
-
-
-BESCHREIBUNG
-============
-
- Hier steht die Liste der zu informierenden Objekte, die potentiell
- auf ein anderes Objekt mit gesetztem P_SENSITIVE_INVENTORY_TRIGGER
- reagieren koennten.
- Wird von InsertSensitiveObject() und RemoveSensitiveObject()
- geschrieben.
-
-
-BEMERKUNGEN
-===========
-
- Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
-
-
-SIEHE AUCH
-==========
-
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_INVENTORY_TRIGGER, P_SENSITIVE_ATTACK
- CheckSensitiveAttack
-
-25.Apr.2001, Gloinson@MG
diff --git a/doc/sphinx/man/props/P_SENSITIVE_INVENTORY_TRIGGER b/doc/sphinx/man/props/P_SENSITIVE_INVENTORY_TRIGGER
deleted file mode 100644
index 627a582..0000000
--- a/doc/sphinx/man/props/P_SENSITIVE_INVENTORY_TRIGGER
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_SENSITIVE_INVENTORY_TRIGGER
-*****************************
-
-
-NAME
-====
-
- P_SENSITIVE_INVENTORY_TRIGGER "sensitive_inv_trigger"
-
-
-DEFINIERT IN
-============
-
- /sys/sensitive.h
-
-
-BESCHREIBUNG
-============
-
- Hier steht die Liste der aktiven Objekte, die eine potentielle
- "Ausstrahlung" auf andere Objekte haben.
- Wird von InsertSensitiveObject() und RemoveSensitiveObject()
- geschrieben.
-
-
-BEMERKUNGEN
-===========
-
- Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
-
-
-SIEHE AUCH
-==========
-
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY
- CheckSensitiveAttack
-
-25.Apr.2001, Gloinson@MG
diff --git a/doc/sphinx/man/props/P_SHOOTING_AREA b/doc/sphinx/man/props/P_SHOOTING_AREA
deleted file mode 100644
index 9339847..0000000
--- a/doc/sphinx/man/props/P_SHOOTING_AREA
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_SHOOTING_AREA
-***************
-
-
-NAME
-====
-
- P_SHOOTING_AREA "shooting_area"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Legt die 'Groesse' eines Raumes fest. Ein Schuetze kann mit seiner
- Fernkampfwaffe nur dann aus diesem Raum in einen anderen Raum schiessen,
- wenn die P_RANGE seiner Waffe mindestens gleich ist.
-
- Erreichbare Raeume sind entweder das environment() oder der in
- P_SHOOTING_AREA festgelegte Raum.
-
-
-SIEHE AUCH
-==========
-
- Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
- Methoden: FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
- Gebiet: P_RANGE, P_TARGET_AREA
- Raeume: P_NEVER_CLEAN
- Sonstiges: fernwaffen
-
-29.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/props/P_SHOOTING_WC b/doc/sphinx/man/props/P_SHOOTING_WC
deleted file mode 100644
index 6345d76..0000000
--- a/doc/sphinx/man/props/P_SHOOTING_WC
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_SHOOTING_WC
-*************
-
-
-NAME
-====
-
- P_SHOOTING_WC "shooting_wc"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Legt in einer Fernkampfwaffe UND ihrer Munition die Waffenstaerke fest.
- Bei einem Schuss wird die Summe kombiniert mit der Geschicklichkeit
- zur Berechnung der Angriffstaerke benutzt.
-
-
-BEISPIELE
-=========
-
- SetProp(P_SHOOTING_WC, 70); // Langbogen
- SetProp(P_SHOOTING_WC, 50); // Kurzbogen
-
- SetProp(P_SHOOTING_WC, 40); // Bambuspfeil
- SetProp(P_SHOOTING_WC, 60); // Aluminiumpfeil
-
- // So haetten Langbogen mit Aluminiumpfeil eine P_SHOOTING_WC von 70+60.
-
-
-SIEHE AUCH
-==========
-
- Generell: P_AMMUNITION, P_STRETCH_TIME
- Methoden: FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
- Gebiet: P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
- Waffen: P_WEAPON_TYPE, P_WC, P_EQUIP_TIME, P_NR_HANDS
- Kampf: Attack(L), Defend(L), P_DISABLE_ATTACK, P_ATTACK_BUSY
- Sonstiges: fernwaffen
-
-29.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/props/P_SHORT b/doc/sphinx/man/props/P_SHORT
deleted file mode 100644
index 49b2603..0000000
--- a/doc/sphinx/man/props/P_SHORT
+++ /dev/null
@@ -1,60 +0,0 @@
-
-P_SHORT
-*******
-
-
-NAME
-====
-
- P_SHORT "short"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die Kurzbeschreibung des Objektes als String
- oder Closure (diese muss einen String zurueckgeben).
-
- ACHTUNG: Die Kurzbeschreibung sollte dabei weder mit einem
- Satzzeichen noch mit einem "\n" abgeschlossen sein
- (dies wird von den zustaendigen Funktionen erledigt).
-
- Setzt man diese Property auf 0, so ist das Objekt unsichtbar, allerdings
- ansprechbar, wenn der Spieler eine ID des Objektes kennt. D.h. Objekte
- koennen mitgenommen, weggeworfen oder ggf. auch angegriffen werden. Will
- man dies nicht, sollte man das Objekt mit P_INVIS unsichtbar machen.
-
- Diese Property bestimmt die Ansicht des Objektes von aussen. Fuer die
- Innen(kurz)ansicht von Raeumen muss man P_INT_LONG benutzen.
-
-
-BEMERKUNGEN
-===========
-
- Die Funktion, die die Kurzbeschreibung ausgibt (short()), filtert P_SHORT
- durch process_string(). Von der Nutzung dieses Features wird in neuem
- Code abgeraten.
- Soll eine dyn. Kurzbeschreibung geschaffen werden, bitte eine
- F_QUERY_METHOD einsetzen oder short() passend ueberschreiben.
-
-
-BEISPIELE
-=========
-
- // eine Axt sieht natuerlich so aus:
- SetProp(P_SHORT, "Eine Axt");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_LONG, short()
- Sonstiges: P_INT_SHORT, process_string()
-
-27.05.2015, Zesstra
diff --git a/doc/sphinx/man/props/P_SHORT_CWD b/doc/sphinx/man/props/P_SHORT_CWD
deleted file mode 100644
index 46f0236..0000000
--- a/doc/sphinx/man/props/P_SHORT_CWD
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_SHORT_CWD
-***********
-
-
-NAME
-====
-
- P_SHORT_CWD "short_cwd"
-
-
-DEFINIERT IN
-============
-
- /sys/shells.h
-
-
-BESCHREIBUNG
-============
-
- .readme bei cd ausgeben oder nicht
diff --git a/doc/sphinx/man/props/P_SHOWEMAIL b/doc/sphinx/man/props/P_SHOWEMAIL
deleted file mode 100644
index b6cf580..0000000
--- a/doc/sphinx/man/props/P_SHOWEMAIL
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_SHOWEMAIL
-***********
-
-
-NAME
-====
-
- P_SHOWEMAIL "showemail"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Eintrag, wer die E-Mail im "finger" zu sehen bekommen soll:
- 0, "alle", "freunde"
- Kann durch "emailanzeige" (/std/player/base.c) geaendert werden.
diff --git a/doc/sphinx/man/props/P_SHOW_ALIAS_PROCESSING b/doc/sphinx/man/props/P_SHOW_ALIAS_PROCESSING
deleted file mode 100644
index 94552dd..0000000
--- a/doc/sphinx/man/props/P_SHOW_ALIAS_PROCESSING
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_SHOW_ALIAS_PROCESSING
-***********************
-
-
-NAME
-====
-
- P_SHOW_ALIAS_PROCESSING "show_alias_processing"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Arbeit des Parsers beobachten (debugging)
diff --git a/doc/sphinx/man/props/P_SHOW_EXITS b/doc/sphinx/man/props/P_SHOW_EXITS
deleted file mode 100644
index 0e00886..0000000
--- a/doc/sphinx/man/props/P_SHOW_EXITS
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_SHOW_EXITS
-************
-
-
-NAME
-====
-
- P_SHOW_EXITS "show_exits"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Im Spieler gesetzt, wenn der Spieler die offensichtlichen Ausgaenge
- immer automatisch sehen will.
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_HIDE_EXITS
- Sonstiges: AddExit(), GetExits(), int_long(), int_short()
-
-11. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_SHOW_INV b/doc/sphinx/man/props/P_SHOW_INV
deleted file mode 100644
index e982154..0000000
--- a/doc/sphinx/man/props/P_SHOW_INV
+++ /dev/null
@@ -1,32 +0,0 @@
-
-P_SHOW_INV
-**********
-
-
-NAME
-====
-
- P_SHOW_INV "show_inv"
-
-
-DEFINIERT IN
-============
-
- <thing/description.h>
-
-
-BESCHREIBUNG
-============
-
- Wenn diese Property auf einen Wert ungleich 0 gesetzt ist, wird das
- Objekt, soweit es sich in einem Spieler befindet, in dessen
- Langbeschreibung angezeigt. Zur Anzeige wird der Name des Objektes
- verwendet.
-
-
-SIEHE AUCH
-==========
-
- /std/thing/description.c
-
-Last modified: Sun May 19 20:36:05 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_SHOW_MSG b/doc/sphinx/man/props/P_SHOW_MSG
deleted file mode 100644
index c19c49f..0000000
--- a/doc/sphinx/man/props/P_SHOW_MSG
+++ /dev/null
@@ -1,69 +0,0 @@
-
-P_SHOW_MSG
-**********
-
-
-NAME
-====
-
- P_SHOW_MSG "show_message"
-
-
-DEFINIERT IN
-============
-
- /sys/living/put_and_get.h
-
-
-BESCHREIBUNG
-============
-
- Mit P_SHOW_MSG kann man die Meldungen, die beim Vorzeigen eines Objektes
- ausgegeben werden, modifizieren.
-
- Folgende Werte sind moeglich:
-
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
-
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
-
- o Ein Array aus Strings
- Der erste String wird an den Spieler ausgegeben, der zweite
- (optionale) an den Raum, der dritte (ebenfalls optionale) an den
- Empfaenger.
-
- Die Strings werden durch die Funktion replace_personal() geparst.
- Objekt1 - Spieler
- Objekt2 - das Objekt, das uebergeben wird
- Objekt3 - Empfaenger
-
- Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
- Raum. Beim Fehlen des dritten gibt es keine Meldung an den Empfaenger.
-
-
-BEISPIEL
-========
-
- SetProp(P_SHOW_MSG, ({
- "Du haeltst @WEM3 @WEN2 unter die Nase.",
- "@WER1 haelt @WEM3 @WENU2 unter die Nase.",
- "@WER1 haelt Dir @WENU2 unter die Nase."
- }));
-
- Das fuehrt bei Ugars "zeig peter medaille" zu folgenden Meldungen:
-
- Ugar: "Du haeltst Peter die Medaille unter die Nase."
- Raum: "Ugar haelt Peter eine Medaille unter die Nase."
- Peter: "Ugar haelt Dir eine Medaille unter die Nase."
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_DROP_MSG, P_PUT_MSG, P_PICK_MSG, P_GIVE_MSG
- Sonstiges: replace_personal(E), show(L), show_objects(L),
- show_notify(L), /std/living/put_and_get.c
-
-3. Juni 2008 Amynthor
diff --git a/doc/sphinx/man/props/P_SIBLINGS b/doc/sphinx/man/props/P_SIBLINGS
deleted file mode 100644
index 6e18f0c..0000000
--- a/doc/sphinx/man/props/P_SIBLINGS
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_SIBLINGS
-**********
-
-
-NAME
-====
-
- P_SIBLINGS "siblings"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt einen String mit den Blutsbruedern eines Spielers
- (sofern vorhanden).
diff --git a/doc/sphinx/man/props/P_SIZE b/doc/sphinx/man/props/P_SIZE
deleted file mode 100644
index aa311f3..0000000
--- a/doc/sphinx/man/props/P_SIZE
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_SIZE
-******
-
-
-NAME
-====
-
- P_SIZE "size"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Groesse des Lebewesens bzw. Laenge der Waffe (in cm).
-
- Wird keine Waffenlaenge explizit angegeben, so sind die Defaultwerte
- fuer die entsprechenden Waffentypen folgende:
-
- WT_SWORD : 100
- WT_AXE : 80
- WT_CLUB : 80
- WT_SPEAR : 180
- WT_KNIFE : 20
- WT_WHIP : 200
- WT_STAFF : 150
-
-
-BEMERKUNGEN
-===========
-
- 1. Uebertreibt es bitte mit der Groesse nicht, auch sehr grosse NPCs
- sollten nicht ueber 1000000 liegen. Sonst kriegt die Karategilde
- Probleme.
- 2. Negative Werte fuer P_SIZE sind nicht moeglich, da dies zum einen
- voellig unsinnig ist und zum anderen evtl. zu Problemen mit Waffen
- fuehrt, die Schaden in Abhaengigkeit von P_SIZE machen und sich
- darauf verlassen, dass nur positive Werte vorkommen.
-
-
-LETZTE AENDERUNG
-================
-
- 2006-09-29, von Zesstra
diff --git a/doc/sphinx/man/props/P_SKILLS b/doc/sphinx/man/props/P_SKILLS
deleted file mode 100644
index 492cbbe..0000000
--- a/doc/sphinx/man/props/P_SKILLS
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_SKILLS
-********
-
-
-NAME
-====
-
- P_SKILLS "skills"
-
-
-DEFINIERT IN
-============
-
- /sys/player/skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property sollte nicht mehr verwendet werden. Sie wurde
- vollstaendig durch P_NEWSKILLS ersetzt.
-
-
-SIEHE AUCH
-==========
-
- P_NEW_SKILLS
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_SKILL_ATTRIBUTES b/doc/sphinx/man/props/P_SKILL_ATTRIBUTES
deleted file mode 100644
index 066bd78..0000000
--- a/doc/sphinx/man/props/P_SKILL_ATTRIBUTES
+++ /dev/null
@@ -1,69 +0,0 @@
-
-P_SKILL_ATTRIBUTES
-******************
-
-
-NAME
-====
-
- P_SKILL_ATTRIBUTES "skill_attr"
-
-
-DEFINIERT IN
-============
-
- /sys/living/skill_attributes.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Prop stehen alle nicht-permanenten Modifikatoren der
- Skill-Attribute.
- Die Datenstruktur ist ein Mapping mit den SA-Namen als Schluessel und
- jeweils drei Werten pro Schluessel.
- Der erste Wert ist ein Array mit drei Werten: der Summe der stat.
- Modifier, dem Zeitpunkt an dem dies Summe ungueltig wird und der
- Gesamtzahl aktiver Modifikatoren.
- Der zweite Wert enthaelt ein Mapping mit allen statischen Modifikatoren
- und den Objekten dieser Mods als Schluessel. Die beiden Werte dieses
- Mappings sind der Wert des Modifikators (int) und die Ablaufzeit (int).
- Der dritte Wert enthaelt ein Mapping mit allen dynamischen
- Modifikatoren und den Objekten dieser Mods als Schluessel. Die beiden
- Werte dieses Mappings sind die zu rufende Closure (closure) und die
- Ablaufzeit des Mods (int).
-
- ([ SA_ATTR: ({Summe_Stat_Modifier, Zeitpunkt, AnzahlModifier, });
- ([ ob1:value;duration,
- ob2:value;duration, ...]); // stat. Modifier
- ([ ob1:closure;duration,
- ob2:closure;duration, ...]) // dyn. Modifier
- ,
- SA_ATTR2: ({...}); ([]); ([]),
- SA_ATTR3: ({...}); ([]); ([]),
- ])
-
-
-BEMERKUNGEN
-===========
-
- Diese Property darf AUF GAR KEINEN FALL per Hand manipuliert werden,
- dafuer gibt es die Funktionen ModifySkillAttribute() und
- RemoveSkillAttributeModifier().
- Zum Auslesen stehen QuerySkillAttribute() und
- QuerySkillAttributeModifier() zur Verfuegung.
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
-
-13.09.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_SKILL_ATTRIBUTE_OFFSETS b/doc/sphinx/man/props/P_SKILL_ATTRIBUTE_OFFSETS
deleted file mode 100644
index 6bfcad3..0000000
--- a/doc/sphinx/man/props/P_SKILL_ATTRIBUTE_OFFSETS
+++ /dev/null
@@ -1,49 +0,0 @@
-
-P_SKILL_ATTRIBUTE_OFFSETS
-*************************
-
-
-NAME
-====
-
- P_SKILL_ATTRIBUTE_OFFSETS "skill_attr_offsets"
-
-
-DEFINIERT IN
-============
-
- /sys/living/skill_attributes.h
-
-
-BESHREIBUNG
-===========
-
- Der Wert der Property ist ein Mapping: ([Attributname: Wert])
- In dieser Property stehen permanente Abweichungen der Skillattribute
- vom Standardwert 100.
-
- Zu den Moeglichen Attributwerten, siehe P_SKILL_ATTRIBUTES.
-
- Die Werte duerfen zwischen 10 und 1000 liegen.
-
-
-BEMERKUNG
-=========
-
- Diese Property sollte AUF GAR KEINEN FALL in einem Spieler gesetzt
- werden, ohne Ruecksprachen mit allerhoechsten Stellen!
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung, skill_info_liste
- * Properties: P_NEWSKILLS
-
-31.12.2013, Zesstra
diff --git a/doc/sphinx/man/props/P_SMELLS b/doc/sphinx/man/props/P_SMELLS
deleted file mode 100644
index 0098bd8..0000000
--- a/doc/sphinx/man/props/P_SMELLS
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_SMELLS
-********
-
-
-NAME
-====
-
- P_SMELLS "smell_details"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property entspricht dem P_DETAILS fuer Standarddetails,
- nur werden hierin Gerueche gespeichert:
- Diese Property enthaelt ein Mapping, in der Details im Objekt
- definiert werden und Beschreibungen, die ausgegeben werden, wenn man
- sich diese Details anschaut.
-
-
-BEMERKUNGEN
-===========
-
- Man sollte diese Property nicht per Hand veraendern, sondern die
- Funktionen nutzen.
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddSmells()
- Loeschen: RemoveSmells()
- Aehnlich: AddDetail(), P_DETAILS
- Sonstiges: GetDetail(), break_string()
-
-27. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/props/P_SNOOPFLAGS b/doc/sphinx/man/props/P_SNOOPFLAGS
deleted file mode 100644
index 340dde2..0000000
--- a/doc/sphinx/man/props/P_SNOOPFLAGS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_SNOOPFLAGS
-************
-
-
-NAME
-====
-
- P_SNOOPFLAGS "snoopflags"
-
-
-DEFINIERT IN
-============
-
- /sys/snooping.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_SOUNDS b/doc/sphinx/man/props/P_SOUNDS
deleted file mode 100644
index 520265b..0000000
--- a/doc/sphinx/man/props/P_SOUNDS
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_SOUNDS
-********
-
-
-NAME
-====
-
- P_SOUNDS "sound_details"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property entspricht dem P_DETAILS fuer Standarddetails,
- nur werden hierin Gerauesche gespeichert:
- Diese Property enthaelt ein Mapping, in der Details im Objekt
- definiert werden und Beschreibungen, die ausgegeben werden, wenn man
- sich diese Details anschaut.
-
-
-BEMERKUNGEN
-===========
-
- Man sollte diese Property nicht per Hand veraendern, sondern die
- Funktionen nutzen.
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddSounds()
- Loeschen: RemoveSounds()
- Aehnlich: AddDetail(), P_DETAILS
- Sonstiges: GetDetail(), break_string()
-
-27. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/props/P_SP b/doc/sphinx/man/props/P_SP
deleted file mode 100644
index fa30cb1..0000000
--- a/doc/sphinx/man/props/P_SP
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_SP
-****
-
-
-NAME
-====
-
- P_SP "sp"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- - Lebewesen
- Anzahl der Konzentrationspunkte des Wesens.
-
- - Speisen/Kneipen
- Heilwirkung einer Portion der Speise auf die Konzentrationspunkte
- des Konsumenten
-
-
-SIEHE AUCH
-==========
-
- Props: P_MAX_SP
- Veraenderung: reduce_spell_points(), restore_spell_points()
- buffer_sp()
- Speisen/Kneipen: std/pub, wiz/food, consume
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_SPECIAL_DETAILS b/doc/sphinx/man/props/P_SPECIAL_DETAILS
deleted file mode 100644
index 9b3f63c..0000000
--- a/doc/sphinx/man/props/P_SPECIAL_DETAILS
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_SPECIAL_DETAILS
-*****************
-
-
-NAME
-====
-
- P_SPECIAL_DETAILS "special_details"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Mapping von Details, die beim Anschauen eine Funktion starten.
-
-
-BEMERKUNGEN
-===========
-
- Dies ist keine "echte" Property. Die Daten werden bei der Abfrage in einer
- Querymethode dynamisch aus P_DETAILS extrahiert. Dementsprechend
- funktioniert es auch nicht, hier eine Query- oder Setmethode von aussen
- drauf zu legen.
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddDetail()
- Loeschen: RemoveDetail()
- Daten: P_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail()
- Sonstiges: GetDetail(), break_string()
-
-27. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/props/P_SPECIAL_EXITS b/doc/sphinx/man/props/P_SPECIAL_EXITS
deleted file mode 100644
index 3f2a7a5..0000000
--- a/doc/sphinx/man/props/P_SPECIAL_EXITS
+++ /dev/null
@@ -1,51 +0,0 @@
-
-P_SPECIAL_EXITS
-***************
-
-
-NAME
-====
-
- P_SPECIAL_EXITS "special_exits"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt ein Mapping (der Breite 2) mit den Ausgaengen, der Funktion,
- die jeweils gerufen wird, wenn der Ausgang benutztwird und einer
- Bewegungsmeldung.
-
-
-
- Die Bewegungsmeldung wird bei SpecialExits nicht ausgewertet, sondern
- ist nur aufgrund der gemeinsamen Datenstruktur vorhanden. Im Normalfall
- ist sie 0.
-
-
-BEMERKUNG
-=========
-
- Keine echte Property, wird bei der Abfrage aus P_EXITS erstellt.
-
-
-
- Zugriff nur mit den dafuer vorgesehenen Funktionen, nicht aendern!
-
-
-SIEHE AUCH
-==========
-
- AddExit(), AddSpecialExit(), GetExits(),
- RemoveExit(), RemoveSpecialExit(),
- GuardExit(),
- H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
-
-Letzte Aenderung: 22.12.2016, Bugfix
diff --git a/doc/sphinx/man/props/P_SPELLRATE b/doc/sphinx/man/props/P_SPELLRATE
deleted file mode 100644
index 1a3e5a2..0000000
--- a/doc/sphinx/man/props/P_SPELLRATE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_SPELLRATE
-***********
-
-
-NAME
-====
-
- P_SPELLRATE "spellrate"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- NPC-Spellrate (in %)
diff --git a/doc/sphinx/man/props/P_SPELLS b/doc/sphinx/man/props/P_SPELLS
deleted file mode 100644
index 647daf4..0000000
--- a/doc/sphinx/man/props/P_SPELLS
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_SPELLS
-********
-
-
-NAME
-====
-
- P_SPELLS "spells"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- NPC-Spells
diff --git a/doc/sphinx/man/props/P_SP_DELAY b/doc/sphinx/man/props/P_SP_DELAY
deleted file mode 100644
index aa74360..0000000
--- a/doc/sphinx/man/props/P_SP_DELAY
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_SP_DELAY
-**********
-
-
-NAME
-====
-
- P_SP_DELAY "sp_delay"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der heart_beats, bis die Magiepunkte um einen Punkt steigen.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
diff --git a/doc/sphinx/man/props/P_START_HOME b/doc/sphinx/man/props/P_START_HOME
deleted file mode 100644
index fd80124..0000000
--- a/doc/sphinx/man/props/P_START_HOME
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_START_HOME
-************
-
-
-NAME
-====
-
- P_START_HOME "start_home"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Raum, in dem der Spieler nach dem Einloggen landen soll
diff --git a/doc/sphinx/man/props/P_STD_OBJECT b/doc/sphinx/man/props/P_STD_OBJECT
deleted file mode 100644
index 7c66296..0000000
--- a/doc/sphinx/man/props/P_STD_OBJECT
+++ /dev/null
@@ -1,59 +0,0 @@
-
-P_STD_OBJECT
-************
-
-
-NAME
-====
-
- P_STD_OBJECT "std_object"
-
-
-DEFINIERT IN
-============
-
- /sys/v_compiler.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt den Namen eines Files welches als Standard-Objekt fuer den
- Virtual Compiler gelten soll.
-
- In diesem File werden das generelle Aussehen, Ausgaenge, Funktionen
- usw. der VC-generierten Raeume / Objekte festgelegt.
-
- Dieses File ist ein 'normales' .c - File, welches geclont wird und
- anschliessend umbenannt wird.
-
-
-
- Ganz wichtig: Falls euer Standardobjekt (direkt oder indirekt) von
- /std/room.c erbt, solltet ihr darauf achten, dass euer Objekt ausser dem
- create() noch eine weitere (beliebige) Funktion hat.
- Ansonsten wuerde das Programm eures Standardobjekts automatisch durch
- /std/room.c ersetzt, was in der Regel zu schwer zu findenen Bugs fuehrt.
-
-
-BEISPIEL
-========
-
- (create eines VCs)
- protected void create() {
- ...
- SetProp(P_STD_OBJECT,"/d/region/magier/vc/std_raum");
- ...
- }
-
- Was in diesem std_raum.c nun steht, wird in jedem VC-Clone
- verfuegbar. Sei es Details, Gerueche, auch Objekte die per
- AddItem eingebunden sind, ...
-
-
-SIEHE AUCH
-==========
-
- P_COMPILER_PATH, virtual_compiler
-
-Letzte Aenderung: 22.10.07 von Zesstra
diff --git a/doc/sphinx/man/props/P_STORE_CONSUME b/doc/sphinx/man/props/P_STORE_CONSUME
deleted file mode 100644
index 8a9afd9..0000000
--- a/doc/sphinx/man/props/P_STORE_CONSUME
+++ /dev/null
@@ -1,69 +0,0 @@
-
-P_STORE_CONSUME
-***************
-
-
-NAME
-====
-
- P_STORE_CONSUME "store_consume"
-
-
-DEFINIERT IN
-============
-
- /sys/bank.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property ist entscheidend dafuer, wieviel Prozent an Objekten
- bei jedem Reset in einem Lager eines Ladens vernichtet werden. Dies
- geschieht aus Speicher- und Laggruenden. Es verbleibt dabei jedoch
- eine Grundmenge an Objekten, deren Anzahl in der Property
- P_MIN_STOCK festgehalten ist. Standardwert fuer P_STORE_CONSUME ist
- hierbei 30%, aber in oft benutzten Laeden kann man dort ruhig einen
- hoeheren Wert eintragen. Erlaubt sind Werte zwischen 0% und 100%.
- Aufgeraeumt werden jedoch keine Objekte, die mittels AddItem() im
- Lager eingebunden wurden. Mittels der Ladenfunktion AddFixedObject()
- als staendig verfuegbar markierte Objekte werden natuerlich auch
- nicht beruecksichtigt.
- Beide hier erwaehnten Properties sollten ueberigens nur mittels
- QueryProp/SetProp ausgelesen bzw. veraendert werden.
-
-
-BEISPIEL
-========
-
- Ein eigener haeufig benutzter Laden koennte ein Lager in folgender
- Form erhalten:
- // myStore
- #include <bank.h>
- inherit "std/store";
- void create()
- { ::create();
- SetProp(P_STORE_CONSUME,90);
- // keine weiteren Beschreibungen, Spieler sollen da drin
- // schliesslich nicht rumwuseln
- }
- Um das Lager dem Laden zuzuweisen, nutzt man folgendes:
- // myShop
- inherit "std/laden";
- void create()
- { ::create();
- SetStorageRoom("pfad/myStore");
- // Beschreibungen folgen
- ...
- }
- Es werden hierbei waehrend jedes Lager-Resets 90% der im Lager
- befindlichen Objekte vernichtet.
-
-
-SIEHE AUCH
-==========
-
- P_MIN_STOCK, SetStorageRoom(), /std/store.c, /std/shop.c
- AddItem(), RemoveItem(), AddFixedObject(), RemoveFixedObject()
-
-Last modified: 19-Jun-2015, Arathorn
diff --git a/doc/sphinx/man/props/P_STRETCH_TIME b/doc/sphinx/man/props/P_STRETCH_TIME
deleted file mode 100644
index 1b38b7e..0000000
--- a/doc/sphinx/man/props/P_STRETCH_TIME
+++ /dev/null
@@ -1,34 +0,0 @@
-
-P_STRETCH_TIME
-**************
-
-
-NAME
-====
-
- P_STRETCH_TIME "stretch_time"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Enthaelt die Zeit in Runden (2s), die man braucht, um eine Fernwaffe zu
- spannen/benutzen. Zaehlt seit dem letzten Schuss oder der Zeit des
- Zueckens (P_EQUIP_TIME).
-
-
-SIEHE AUCH
-==========
-
- Generell: P_AMMUNITION, P_SHOOTING_WC
- Methoden: FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
- Gebiet: P_RANGE, P_SHOOTING_AREA, P_TARGET_AREA
- Sonstiges: fernwaffen
-
-29.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/props/P_SUBGUILD_TITLE b/doc/sphinx/man/props/P_SUBGUILD_TITLE
deleted file mode 100644
index 83515d7..0000000
--- a/doc/sphinx/man/props/P_SUBGUILD_TITLE
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_SUBGUILD_TITLE
-****************
-
-
-NAME
-====
-
- P_SUBGUILD_TITLE "subguild_title"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt eventuelle Zusatztitel eines Spielers, den er
- innerhalb einer Gilde traegt. Das kann z.B. ein Clan sein, ein Zweig oder
- einfach nur der Gildenrang.
-
-
-BEMERKUNGEN
-===========
-
- Inhalt der Property kann 0 sein oder ein String. Ein Zusatztitel kann
- mittels P_VISIBLE_SUBGUILD_TITLE vorgetaeuscht werden.
-
-
-SIEHE AUCH
-==========
-
- P_GUILD_TITLE, P_VISIBLE_SUBGUILD_TITLE
-
-26. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_SYNTAX_HELP b/doc/sphinx/man/props/P_SYNTAX_HELP
deleted file mode 100644
index a796fb5..0000000
--- a/doc/sphinx/man/props/P_SYNTAX_HELP
+++ /dev/null
@@ -1,62 +0,0 @@
-
-P_SYNTAX_HELP
-*************
-
-
-NAME
-====
-
- P_SYNTAX_HELP "lib_p_syntax_help"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/commands.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property kann man fuer Spieler eine ausfuehrliche Syntaxhilfe zu
- den Kommandos eines Objektes ablegen. Diese wird angezeigt, wenn der
- Spieler das Kommando "synxtaxhilfe <objekt>" eingibt.
- Die Property kann verschiedene Datenstrukturen enthalten:
-
- 1) ein String
- Der String wird angezeigt, hierbei ggf. umgebrochen, vorhandene
- Zeilenumbrueche werden beibehalten.
-
- 2) ein Array: ({hilfetext, bedingungen})
-
- <hilfetext>:
- * ein string:
- Der String wird angezeigt, hierbei ggf. umgebrochen, vorhandene
- Zeilenumbrueche werden beibehalten.
- * eine lfun-closure:
- Diese erhaelt beim Aufruf das betreffende Objekt als Argument.
- Wenn diese dann einen String zurueckliefert, wird dieser dem Spieler
- angezeigt. Hierbei wird ggf. umgebrochen, vorhandene Zeilenumbrueche
- werden beibehalten.
-
- <bedingungen>, welche erfuellt sein muessen, damit dem Spieler die Hilfe
- angezeigt wird. Die Bedingungen sind entweder:
- * ein Mapping fuer check_restriction()
- * eine lfun-closure
- Diese erhaelt beim Aufruf das betreffende Objekt als Argument und darf
- eine 0 fuer 'erlaubt', 1 fuer 'nicht erlaubt (mit Standardtext)' oder
- einen string fuer 'nicht erlaubt mit individuellem Text' sein.
-
-
-BEMERKUNGEN
-===========
-
- Hat ein Objekt keine Syntaxhilfe, wird das Kommando "syntaxhilfe" aus dem
- Objekt wieder entfernt (d.h. die Property muss gesetzt sein, bevor der
- erste Spieler das Kommando eingibt).
-
-
-SIEHE AUCH
-==========
-
- AddCmd
diff --git a/doc/sphinx/man/props/P_TARGET_AREA b/doc/sphinx/man/props/P_TARGET_AREA
deleted file mode 100644
index 614320f..0000000
--- a/doc/sphinx/man/props/P_TARGET_AREA
+++ /dev/null
@@ -1,95 +0,0 @@
-
-P_TARGET_AREA
-*************
-
-
-NAME
-====
-
- P_TARGET_AREA "target_area"
-
-
-DEFINIERT IN
-============
-
- <combat.h>
-
-
-BESCHREIBUNG
-============
-
- Kann in einem Raum gesetzt werden, um einen anderen, von dort aus mit
- Fernkampfwaffen beschiessbaren Raum als Objekt oder Objektnamen (zu
- einem geladenen Objekt) festzulegen.
-
-
-BEMERKUNGEN
-===========
-
- Ein Schuetze kann nur in den anderen Raum schiessen, wenn die P_RANGE
- seiner Waffe mindest gleich der P_SHOOTING_AREA des Raums (nicht des
- Zielraums) ist.
-
- Idealerweise sollte in mit P_TARGET_AREA angegebenen Raeumen auch
- P_NEVER_CLEAN gesetzt sein.
-
-
-BEISPIELE
-=========
-
- // #1 Ein Baum-Raum (/std/room)
- void create() {
- ::create();
- SetProp(P_INT_SHORT, "Auf einem Baum");
- SetProp(P_INT_LONG, break_string("Du hockst auf einem Baum und kannst "
- "auf die Lichtung unter Dir sehen.\n");
-
- AddExit("unten", RAEUME("lichtung"));
-
- SetProp(P_TARGET_AREA, RAEUME("lichtung")); // Lichtung beschiessbar
- SetProp(P_SHOOTING_AREA, 15); // 15 Entfernung
- }
-
- // #2 Ein Elefanten-Transporter (/std/transport)
- // Er trampelt durch mehrere Raeume durch und der Schuetze kann vom
- // Ruecken des Elefanten aus auf Gegner draussen schiessen.
- void create() {
- ::create();
- SetProp(P_NAME, "Kampfelefant");
- AddId(({"elefant", "kampfelefant")});
- SetProp(P_GENDER, MALE);
- SetProp(P_SHORT, "Ein Kampfelefant");
- SetProp(P_INT_SHORT, "Auf einem Kampfelefanten");
- // P_LONG, P_INT_LONG
-
- SetProp(P_ENTERCMDS, ({"kletter", "erkletter"}));
- SetProp(P_LEAVECMDS, ({"verlass", "verlasse"}));
-
- SetProp(P_ARRIVEMSG, ({"Der Elefant trampelt in einen Raum.\n",
- "Ein Kampfelefant trampelt herein.\n"}));
- SetProp(P_DEPARTMSG, ({"Der Elefant trampelt weiter.\n",
- "Der Kampfelefant trampelt weiter.\n"}));
-
- SetProp(P_SHOOTING_AREA, 8); // weiter als 8 sollte man schiessen
-
- AddRoute(RAEUME("schlachtfeld"), 20+random(10), 6, "Schlachtfeld");
- AddRoute(RAEUME("burgtor"), 20+random(10), 6, "Burgtor");
- AddRoute(RAEUME("burghof"), 20+random(10), 6, "Burghof");
- AddRoute(RAEUME("halle"), 20+random(10), 6, "Halle");
- AddRoute(RAEUME("bresche"), 20+random(10), 6, "Bresche");
- // ...
-
- Start();
- }
-
-
-SIEHE AUCH
-==========
-
- Generell: P_AMMUNITION, P_SHOOTING_WC, P_STRETCH_TIME
- Methoden: FindRangedTarget(L), shoot_dam(L), cmd_shoot(L)
- Gebiet: P_RANGE, P_SHOOTING_AREA
- Raeume: P_NEVER_CLEAN
- Sonstiges: fernwaffen
-
-29.Jul 2014 Gloinson
diff --git a/doc/sphinx/man/props/P_TEAM b/doc/sphinx/man/props/P_TEAM
deleted file mode 100644
index 4f853e8..0000000
--- a/doc/sphinx/man/props/P_TEAM
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_TEAM
-******
-
-
-NAME
-====
-
- P_TEAM "team"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Liefert das Teamobjekt, falls Spieler in einem Team ist, sonst 0.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
- P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
- P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TEAM_ASSOC_MEMBERS b/doc/sphinx/man/props/P_TEAM_ASSOC_MEMBERS
deleted file mode 100644
index b57a276..0000000
--- a/doc/sphinx/man/props/P_TEAM_ASSOC_MEMBERS
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_TEAM_ASSOC_MEMBERS
-********************
-
-
-NAME
-====
-
- P_TEAM_ASSOC_MEMBERS "team_assoc_members"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Array mit den zugeordneten NPCs des Spielers bzw. der Spieler,
- dem dieser NPC zugeordnet ist.
- Zugeordnete NPCs sind automatisch im Team des Spielers.
-
-
-BEMERKUNG
-=========
-
- Der Zugriff auf diese Property sollte ueber AssocMember()
- bzw. DeAssocMember() erfolgen.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
- P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
- P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TEAM_ATTACK_CMD b/doc/sphinx/man/props/P_TEAM_ATTACK_CMD
deleted file mode 100644
index b7993e7..0000000
--- a/doc/sphinx/man/props/P_TEAM_ATTACK_CMD
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_TEAM_ATTACK_CMD
-*****************
-
-
-NAME
-====
-
- P_TEAM_ATTACK_CMD "team_attack_cmd"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Angriffsbefehl des Spielers, nicht setzbar.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_AUTOFOLLOW,
- P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
- P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TEAM_AUTOFOLLOW b/doc/sphinx/man/props/P_TEAM_AUTOFOLLOW
deleted file mode 100644
index 0e8c45f..0000000
--- a/doc/sphinx/man/props/P_TEAM_AUTOFOLLOW
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_TEAM_AUTOFOLLOW
-*****************
-
-
-NAME
-====
-
- P_TEAM_AUTOFOLLOW "team_autofollow"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Folgewunsch des Spielers, nicht setzbar.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
- P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TEAM_COLORS b/doc/sphinx/man/props/P_TEAM_COLORS
deleted file mode 100644
index a855035..0000000
--- a/doc/sphinx/man/props/P_TEAM_COLORS
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_TEAM_COLORS
-*************
-
-
-NAME
-====
-
- P_TEAM_COLORS "team_colors"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Grenzwerte fuer farbige Anzeige im Teaminfo.
- Array mit 4 Werten: ({ lp_rot, lp_gelb, sp_rot, sp_gelb })
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
- P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TEAM_LEADER b/doc/sphinx/man/props/P_TEAM_LEADER
deleted file mode 100644
index b4927f3..0000000
--- a/doc/sphinx/man/props/P_TEAM_LEADER
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_TEAM_LEADER
-*************
-
-
-NAME
-====
-
- P_TEAM_LEADER "team_leader"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Liefert das Teamobjekt, falls Spieler Anfuehrer eines Teams ist.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_NEWMEMBER,
- P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TEAM_NEWMEMBER b/doc/sphinx/man/props/P_TEAM_NEWMEMBER
deleted file mode 100644
index da89b70..0000000
--- a/doc/sphinx/man/props/P_TEAM_NEWMEMBER
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_TEAM_NEWMEMBER
-****************
-
-
-NAME
-====
-
- P_TEAM_NEWMEMBER "potential_team_member"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt das Objekt des Teamleaders, sobald ein Spieler um
- Teamaufnahme gebeten hat, sonst 0.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_TEAM, P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD,
- P_TEAM_AUTOFOLLOW, P_TEAM_COLORS, P_TEAM_LEADER,
- P_TEAM_WANTED_ROW, P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TEAM_WANTED_ROW b/doc/sphinx/man/props/P_TEAM_WANTED_ROW
deleted file mode 100644
index ba94af4..0000000
--- a/doc/sphinx/man/props/P_TEAM_WANTED_ROW
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_TEAM_WANTED_ROW
-*****************
-
-
-NAME
-====
-
- P_TEAM_WANTED_ROW "team_wanted_row"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Gewuenschte Reihe des Spielers (von 1 bis MAX_TEAMROWS)
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
- P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
- P_TEAM_WIMPY_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TEAM_WIMPY_ROW b/doc/sphinx/man/props/P_TEAM_WIMPY_ROW
deleted file mode 100644
index 90bfacb..0000000
--- a/doc/sphinx/man/props/P_TEAM_WIMPY_ROW
+++ /dev/null
@@ -1,46 +0,0 @@
-
-P_TEAM_WIMPY_ROW
-****************
-
-
-NAME
-====
-
- P_TEAM_WIMPY_ROW "team_wimpy_row"
-
-
-DEFINIERT IN
-============
-
- /sys/living/team.h
-
-
-BESCHREIBUNG
-============
-
- Fluchtreihe des Spielers, von 1 bis MAX_TEAMROWS.
-
-
-BEMERKUNG
-=========
-
- Wenn die Fluchtreihe <=1 ist, ist die Flucht in eine hintere Reihe
- deaktiviert.
-
-
-SIEHE AUCH
-==========
-
- Uebersicht: teamkampf
- Properties: P_ASSOC_MEMBERS, P_TEAM_ATTACK_CMD, P_TEAM_AUTOFOLLOW,
- P_TEAM_COLORS, P_TEAM_LEADER, P_TEAM_NEWMEMBER,
- P_TEAM_WANTED_ROW
- Bewegung: IsTeamMove, TeamFlee
- Mitglieder: IsTeamLeader, TeamMembers
- Kampf: DeAssocMember, InsertEnemyTeam, SelectNearEnemy,
- SelectFarEnemy
- Positionen: PresentPosition, PresentRows, PresentEnemyRows,
- PresentTeamPosition, SwapRows
- Sonstiges: TeamPrefix, teamkampf_intern
-
-Last modified: 16-08-2010, Gabylon
diff --git a/doc/sphinx/man/props/P_TELNET_RTTIME b/doc/sphinx/man/props/P_TELNET_RTTIME
deleted file mode 100644
index b781bea..0000000
--- a/doc/sphinx/man/props/P_TELNET_RTTIME
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_TELNET_RTTIME
-***************
-
-
-NAME
-====
-
- P_TELNET_RTTIME "p_lib_telnet_rttime"
-
-
-DEFINIERT IN
-============
-
- /secure/telnetneg.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Properties steht die letzte gemessene 'round-trip' Zeit
- (in Mikrosekunden) einer 'Telnet timing mark' vom MUD zum Client und
- zurueck.
-
- Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
- Telnetnegotiations unterstuetzt und 'telnet keepalive' eingeschaltet
- ist, ansonsten bleibt diese Property 0.
- Die meisten Telnets/Clients antworten zumindest eine Ablehnung auf
- die 'timing marks', so dass trotzdem eine Zeit bestimmt werden kann.
-
- Die Prop kann nicht gesetzt werden bzw. es hat keinen Effekt.
-
-
-SIEHE AUCH
-==========
-
- P_TTY_COLS, P_TTY_ROWS, P_TTY_SHOW, P_TTY, P_TTY_TYPE
-
-
-LETZTE AeNDERUNG
-================
-
- 03.02.2013, Zesstra
diff --git a/doc/sphinx/man/props/P_TESTPLAYER b/doc/sphinx/man/props/P_TESTPLAYER
deleted file mode 100644
index bf0c765..0000000
--- a/doc/sphinx/man/props/P_TESTPLAYER
+++ /dev/null
@@ -1,48 +0,0 @@
-
-P_TESTPLAYER
-************
-
-
-NAME
-====
-
- P_TESTPLAYER "testplayer"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Gesetzt, wenn der Spieler ein Testspieler ist. Enthaelt die UID des
- Magiers, dem dieser Testie (momentan) gehoert.
-
-
-
- Bei Testspielern duerfen Skills geaendert werden, sie duerfen gezappt
- werden und - ihre eigentliche Aufgabe - nicht angeschlossene Gebiete
- testen.
-
- AUSNAHMEN: Gildentesties duerfen nur sehr eingeschraenkt manipuliert
- werden werden, da sie im ganzen Mud rumlaufen koennen,
- Spielerkontakt haben und nach Abschluss der Tests ggf. sogar
- die Testiemarkierung entfernt werden kann.
-
-
-
- Fuer Spielertesties, die von einem Spieler kontrolliert werden, gelten
- teilweise besondere Regeln, s. 'spielertesties'.
-
-BEMERKUNGEN:
- P_TESTPLAYER kann nur per SetProp() gesetzt werden und das auch nur
- ein Mal! Geloescht werden kann das Flag nur von EM+.
-
-
-ZULETZT GEAeNDERT
-=================
-
-05.01.2010, Zesstra
diff --git a/doc/sphinx/man/props/P_TIMED_ATTR_MOD b/doc/sphinx/man/props/P_TIMED_ATTR_MOD
deleted file mode 100644
index fa7db3f..0000000
--- a/doc/sphinx/man/props/P_TIMED_ATTR_MOD
+++ /dev/null
@@ -1,78 +0,0 @@
-
-P_TIMED_ATTR_MOD
-****************
-
-
-NAME
-====
-
- P_TIMED_ATTR_MOD "timed_attr_mod"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property werden Attribut-Modifikatoren gespeichert, die
- nicht ueber laengere Zeit wirksam sein sollen.
- Die Wirksamkeit der Modifikatoren kann an Zeit und Objekte
- gebunden werden.
-
- Intern werden die Modifikatoren in einer Datenstruktur der Form
-
- ({
- ({ Ablaufzeiten }),
- ([ Key : Ablaufobjekt ]),
- ([ Key : ([ Mapping mit den Modifikatoren ]);
- Ablaufzeit ; Ablaufobjekt ; Nachrichtenempfaenger
- ])
- })
-
- gespeichert mit:
- * Ablaufzeiten: Zeit in Sekunden seit 1. Jan 1970, 0.0:0 GMT
- * Ablaufobjekte: Objekte, an deren Existenz die Attribut-
- veraenderungen gebunden sind
- * Nachrichtenempfaenger:
- Objekte/Klassen, welche ueber abgelaufene Attributveraenderung
- durch den Aufruf von "NotifyTimedAttrModExpired" (mit key als
- Argument) benachrichtigt werden.
-
- Das Setzen der Werte erfolgt NUR ueber die Methoden SetTimedAttrModifier
- und DeleteTimedAttrModifier.
-
- Die Daten zu einem Key koennen ueber QueryTimedAttrModifier abgefragt
- werden. Die Abfrage mittels QueryProp liefert eine Kopie der gueltigen
- Datenstruktur, die per Query nicht (siehe Bemerkungen).
-
- Die Bedingungen fuer die ueber P_TIMED_ATTR_MOD gesetzten
- Attributveraenderungen werden im Heartbeat in der Funktion
- attribute_hb ueberprueft. Eine verminderte Funktionalitaet im
- Falle von Magiern ist somit kein Fehlerfall.
-
-
-BEMERKUNGEN
-===========
-
- Keine echte Property. Die Methode _query_timed_attr_mod() in
- /std/living/attributes.c stellt die Daten zusammen.
-
- ACHTUNG: Bitte nur die bereitgestellten Methoden zur Manipulation
- benutzen! Setzen als Property hat keinen Effekt.
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS, P_ATTRIBUTES_MODIFIER,
- P_X_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-Last modified: Tue Jul 27 20:00:20 2004 by Muadib
diff --git a/doc/sphinx/man/props/P_TIMEZONE b/doc/sphinx/man/props/P_TIMEZONE
deleted file mode 100644
index 7e4ce7d..0000000
--- a/doc/sphinx/man/props/P_TIMEZONE
+++ /dev/null
@@ -1,23 +0,0 @@
-
-P_TIMEZONE
-**********
-
-
-NAME
-====
-
- P_TIMEZONE "timezone"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Ein Integer-Wert, der bei der Uhrzeitmeldung und beim Befehl
- "(uhr)zeit" beruecksichtig wird. Gibt die Anzahl der Stunden
- Zeitabweichung von Berliner Zeit an.
diff --git a/doc/sphinx/man/props/P_TITLE b/doc/sphinx/man/props/P_TITLE
deleted file mode 100644
index 555e26a..0000000
--- a/doc/sphinx/man/props/P_TITLE
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_TITLE
-*******
-
-
-NAME
-====
-
- P_TITLE "title"
-
-
-DEFINIERT IN
-============
-
- /sys/player/description.h
-
-
-BESCHREIBUNG
-============
-
- Titel des Spielers. Erscheint hinter dem Namen in Kurz/Langbeschreibung.
diff --git a/doc/sphinx/man/props/P_TOO_HEAVY_MSG b/doc/sphinx/man/props/P_TOO_HEAVY_MSG
deleted file mode 100644
index c2a40ea..0000000
--- a/doc/sphinx/man/props/P_TOO_HEAVY_MSG
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_TOO_HEAVY_MSG
-***************
-
-
-NAME
-====
-
- P_TOO_HEAVY_MSG "too_heavy_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
- versucht, ein Objekt in einen Behaelter zu legen, fuer den dieses Objekt
- zu schwer ist.
- Die Property ist im Behaelter zu setzen.
- Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
- so wird die Standardmeldung ausgegeben.
- ("<Objekt> passt in <Behaelter> nicht mehr rein.")
- Der String in der Property wird noch durch replace_personal()
- verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
- zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
- umgebrochen.
- Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
- ganz.
-
-
-BEISPIELE
-=========
-
- SetProp(P_TOO_HEAVY_MSG, "Wenn du @WEN1 noch in den Beutel stecken"
- " wuerdest, wuerde er reissen.");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_ENV_TOO_HEAVY_MSG, P_TOO_MANY_MSG, P_NOINSERT_MSG,
- P_NOLEAVE_MSG, P_NODROP, P_NOGET
- Erfolg: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
- P_WEAR_MSG, P_WIELD_MSG
- Sonstiges: replace_personal(E), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/props/P_TOO_MANY_MSG b/doc/sphinx/man/props/P_TOO_MANY_MSG
deleted file mode 100644
index fd1ffe9..0000000
--- a/doc/sphinx/man/props/P_TOO_MANY_MSG
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_TOO_MANY_MSG
-**************
-
-
-NAME
-====
-
- P_TOO_MANY_MSG "too_many_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/moving.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt eine Meldung, die ausgegeben wird, wenn jemand
- versucht, ein Objekt in einen Behaelter zu legen, der schon die maximale
- Anzahl an Objekten enthaelt.
- Die Property ist im Behaelter zu setzen.
- Ist diese Property nicht oder auf einen nicht-String-Wert gesetzt,
- so wird die Standardmeldung ausgegeben.
- ("Dafuer ist nicht mehr genug Platz in <Behaelter>.")
- Der String in der Property wird noch durch replace_personal()
- verarbeitet, das zu bewegende Objekt wird als erstes, der Behaelter als
- zweites Objekt angegeben. Danach wird der String auf 78 Zeichen
- umgebrochen.
- Das Setzen eines leeren Strings unterdrueckt die Ausgabe einer Meldung
- ganz.
-
-
-BEISPIELE
-=========
-
- SetProp(P_TOO_MANY_MSG, "Aber der Korb hat doch nur drei Faecher, die"
- " sind alle schon voll.");
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_TOO_HEAVY_MSG, P_ENV_TOO_HEAVY_MSG, P_NOINSERT_MSG,
- P_NOLEAVE_MSG, P_NODROP, P_NOGET
- Erfolg: P_PICK_MSG, P_DROP_MSG, P_GIVE_MSG, P_PUT_MSG,
- P_WEAR_MSG, P_WIELD_MSG
- Sonstiges: replace_personal(E), /std/living/put_and_get.c
diff --git a/doc/sphinx/man/props/P_TOTAL_AC b/doc/sphinx/man/props/P_TOTAL_AC
deleted file mode 100644
index baa9cf9..0000000
--- a/doc/sphinx/man/props/P_TOTAL_AC
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_TOTAL_AC
-**********
-
-
-NAME
-====
-
- P_TOTAL_AC "total_ac"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert der Abwehrstaerke des Wesens.
- Dieser wird durch Aufaddieren der P_AC aller getragenen Ruestungen
- bestimmt. Aus diesem Grund ist das Abfragen dieser Property ziemlich
- teuer. Falls das Ergebnis mehrfach kurz hintereinander gebraucht wird,
- sollte die Property auf jeden Fall nur einmal abgefragt und der Wert
- gespeichert werden.
-
-
-BEMERKUNGEN
-===========
-
- Auf diese Property sollte nicht mittels Query() oder Set() zugegriffen
- werden, das Setzen von Query- oder Setmethoden bitte auf jeden Fall
- unterlassen.
-
-
-SIEHE AUCH
-==========
-
- P_AC
-
-05.09.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_TOTAL_LIGHT b/doc/sphinx/man/props/P_TOTAL_LIGHT
deleted file mode 100644
index f4f0083..0000000
--- a/doc/sphinx/man/props/P_TOTAL_LIGHT
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_TOTAL_LIGHT
-*************
-
-
-NAME
-====
-
- P_TOTAL_LIGHT "total_light"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Gibt das Lichtlevel an, das von einem Objekt ausgeht. Hierzu wird das
- eigene Lichtlevel P_LIGHT mit dem gesamten Inhalt eines Containers
- verrechnet.
-
- Bitte _nur_ ueber QueryProp auf diese Property zugreifen,
- da das Lichtlevel ggf. neu berechnet werden muss!
-
- Ein direktes setzen dieser Property ist NICHT moeglich, hierzu bitte
- P_LIGHT benutzen!
-
-
-BEMERKUNGEN
-===========
-
- Das ist die VON einem Objekt ausgehende Lichtstaerke. Fuer das IN einem
- Raum herrschende Licht bitte P_INT_LIGHT abfragen!
-
-
-SIEHE AUCH
-==========
-
- P_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
diff --git a/doc/sphinx/man/props/P_TOTAL_OBJECTS b/doc/sphinx/man/props/P_TOTAL_OBJECTS
deleted file mode 100644
index 4e2d009..0000000
--- a/doc/sphinx/man/props/P_TOTAL_OBJECTS
+++ /dev/null
@@ -1,32 +0,0 @@
-
-P_TOTAL_OBJECTS
-***************
-
-
-NAME
-====
-
- P_TOTAL_OBJECTS "total_objects"
-
-
-DEFINIERT IN
-============
-
- /sys/container.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der Objekte im Container. Diese Property kann man nur abfragen!
- Es werden nur Objekte gezaehlt, deren Methode short() einen
- Wert != 0 zurueckgibt. Insofern koennen Spielern beliebig
- viele unsichtbare Objekte gegeben werden ohne sie zu behindern.
-
-
-SIEHE AUCH
-==========
-
- P_MAX_OBJECTS
-
-26.Jan 2005 Gloinson
diff --git a/doc/sphinx/man/props/P_TOTAL_WC b/doc/sphinx/man/props/P_TOTAL_WC
deleted file mode 100644
index 19349f0..0000000
--- a/doc/sphinx/man/props/P_TOTAL_WC
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_TOTAL_WC
-**********
-
-
-NAME
-====
-
- P_TOTAL_WC "total_wc"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Property wird der numerische Wert der Angriffsstaerke
- eines Lebewesens registriert.
- Hierzu werden die P_WC von P_WEAPON bzw. P_HANDS sowie die Kraft des
- Lebewesens beruecksichtigt.
- Nicht eingerechnet in die Angriffsstaerke sind natuerlich Extraspells und
- -skills des Angreifers.
- Braucht man den Wert mehrfach kurz hintereinander, sollte man die Prop aber
- nur einmal abfragen und den Wert speichern (sofern sich in der Zwischenzeit
- nichts an der Waffe, den Hands oder den Attributen des Lebenwesens aendert).
-
-
-BEMERKUNGEN
-===========
-
- Auf diese Property sollte nicht mittels Query() oder Set() zugegriffen
- werden, das Setzen von Query- oder Setmethoden bitte auf jeden Fall
- unterlassen.
-
-
-SIEHE AUCH
-==========
-
- P_HANDS, P_WC, P_XP
-
-05.09.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_TOTAL_WEIGHT b/doc/sphinx/man/props/P_TOTAL_WEIGHT
deleted file mode 100644
index bdb72f6..0000000
--- a/doc/sphinx/man/props/P_TOTAL_WEIGHT
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_TOTAL_WEIGHT
-**************
-
-
-NAME
-====
-
- P_TOTAL_WEIGHT "total_weight"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/restrictions.h
-
-
-BESCHREIBUNG
-============
-
- Gewicht incl. Inhalt in Gramm. P_WEIGHT_PERCENT wird beruecksichtigt.
diff --git a/doc/sphinx/man/props/P_TOUCH_DETAILS b/doc/sphinx/man/props/P_TOUCH_DETAILS
deleted file mode 100644
index f4345db..0000000
--- a/doc/sphinx/man/props/P_TOUCH_DETAILS
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_TOUCH_DETAILS
-***************
-
-
-NAME
-====
-
- P_TOUCH_DETAILS "touch_details"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property entspricht dem P_DETAILS fuer Standarddetails,
- nur werden hierin Gerueche gespeichert:
- Diese Property enthaelt ein Mapping, in der Details im Objekt
- definiert werden und Beschreibungen, die ausgegeben werden, wenn man
- sich diese Details anschaut.
-
-
-BEMERKUNGEN
-===========
-
- Man sollte diese Property nicht per Hand veraendern, sondern die
- Funktionen nutzen.
-
-
-SIEHE AUCH
-==========
-
- Setzen: AddTouchDetail()
- Loeschen: RemoveTouchDetail()
- Aehnlich: AddDetail(), P_DETAILS
- Sonstiges: GetDetail(), break_string()
-
-27. Jan 2013 Gloinson
diff --git a/doc/sphinx/man/props/P_TPORT_COST_IN b/doc/sphinx/man/props/P_TPORT_COST_IN
deleted file mode 100644
index f2e51a9..0000000
--- a/doc/sphinx/man/props/P_TPORT_COST_IN
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_TPORT_COST_IN
-***************
-
-
-NAME
-====
-
- P_TPORT_COST_IN "tport_cost_in"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- In einem Raum mit Sehertor: Kostenanteil, um sich in den Raum zu
- teleportieren
diff --git a/doc/sphinx/man/props/P_TPORT_COST_OUT b/doc/sphinx/man/props/P_TPORT_COST_OUT
deleted file mode 100644
index c97c752..0000000
--- a/doc/sphinx/man/props/P_TPORT_COST_OUT
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_TPORT_COST_OUT
-****************
-
-
-NAME
-====
-
- P_TPORT_COST_OUT "tport_cost_out"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- In einem Raum mit Sehertor: Kostenanteil, sich aus dem Raum heraus
- zu teleportieren
diff --git a/doc/sphinx/man/props/P_TRANK_FINDEN b/doc/sphinx/man/props/P_TRANK_FINDEN
deleted file mode 100644
index a3e270d..0000000
--- a/doc/sphinx/man/props/P_TRANK_FINDEN
+++ /dev/null
@@ -1,22 +0,0 @@
-
-P_TRANK_FINDEN
-**************
-
-
-NAME
-====
-
- P_TRANK_FINDEN "trank_finden"
-
-
-DEFINIERT IN
-============
-
- /sys/player/potion.h
-
-
-BESCHREIBUNG
-============
-
- Wenn die Property auf 1 steht kann immer ein Zaubertrank gefunden
- werden, auch wenn er nicht in der Liste des Spielers steht.
diff --git a/doc/sphinx/man/props/P_TRANSPARENT b/doc/sphinx/man/props/P_TRANSPARENT
deleted file mode 100644
index 56c0558..0000000
--- a/doc/sphinx/man/props/P_TRANSPARENT
+++ /dev/null
@@ -1,46 +0,0 @@
-
-P_TRANSPARENT
-*************
-
-
-NAME
-====
-
- P_TRANSPARENT "transparent"
-
-
-DEFINIERT IN
-============
-
- /sys/container.h
-
-
-BESCHREIBUNG
-============
-
- ist != 0, wenn in einen Container hinein (offen) oder aus einem
- hinausgeschaut werden kann.
-
- Schaut man aus einem hinaus, erhaelt der Spieler normalerweise die
- Meldung 'Ausserhalb siehst Du:'. Diese kann jedoch durch eine eigene,
- stimmigere Meldung ersetzt werden, wenn in P_TRANSPARENT ein String
- mit dieser Meldung angegeben wird.
-
-
-BEISPIEL
-========
-
- SetProp(P_TRANSPARENT,1); -> normale Meldung
-
- SetProp(P_TRANSPARENT,"Vom Ruecken des Pferdes aus siehst Du:\n");
-
- Diese Meldung ist natuerlich nur dann sinnvoll, wenn es sich
- auch tatsaechlich um ein Pferd handelt :-)
-
-
-SIEHE AUCH
-==========
-
- int_long()
-
-Last modified: Mon Jul 18 24:00:00 2001 by Tilly
diff --git a/doc/sphinx/man/props/P_TRAVEL_CMDS b/doc/sphinx/man/props/P_TRAVEL_CMDS
deleted file mode 100644
index 3f9b0d5..0000000
--- a/doc/sphinx/man/props/P_TRAVEL_CMDS
+++ /dev/null
@@ -1,62 +0,0 @@
-
-P_TRAVEL_CMDS
-*************
-
-
-NAME
-====
-
- P_TRAVEL_CMDS "travel_cmds"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Ein Array mit Befehlen, die zum Verlassen UND Betreten des Trans-
- porters fuehren.
-
-
-BEISPIEL
-========
-
- void create()
- {
- ::create();
-
- SetProp(P_TRAVEL_CMDS,({ "steig","steige" }) );
-
- }
-
- Als Parameter werden hier ausschliesslich 'auf,in' und 'von,aus'
- verarbeitet.
-
- steige auf|in <xxx> fuehrt also zum Betreten des Transporters,
- steige von|aus <xxx> dagegen fuehrt zum Verlassen desselben.
-
-
-BEMERKUNGEN
-===========
-
- Um /std/transport.c nicht aufzublaehen, werden weitere Parameter wie
- etwa 'steige auf|in das|die|den xxx' _nicht_ unterstuetzt!
-
- Hier muss der verantwortliche Magier schon eine eigene Loesung finden
- und in seinen Transporter schreiben.
-
-
-SIEHE AUCH
-==========
-
- P_LEAVEFAIL, P_ENTERFAIL, P_ENTERCMDS, P_LEAVECMDS, transporter,
-
-
-LETZTER AENDERUNG
-=================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_TRAVEL_INFO b/doc/sphinx/man/props/P_TRAVEL_INFO
deleted file mode 100644
index 720e9ec..0000000
--- a/doc/sphinx/man/props/P_TRAVEL_INFO
+++ /dev/null
@@ -1,53 +0,0 @@
-
-P_TRAVEL_INFO
-*************
-
-
-NAME
-====
-
- P_TRAVEL_INFO "travel_info"
-
-
-DEFINIERT IN
-============
-
- /sys/transport.h
-
-
-BESCHREIBUNG
-============
-
- Array mit Informationen zur vom Spieler gewuenschten Reiseroute.
-
- [0] Der Raum (object), in dem die Reiseroute momentan
- 'aktiv' ist. Nur hier wird sie beruecksichtigt.
-
- [1] Das gewuenschte Transportmittel (object) falls
- gewaehlt. Ansonsten 0.
-
- [2] Der gewuenschte Zielort (string) oder 0 (ziellos).
-
- [3] Der gewuenschte Zielort als Richtung (string), falls
- gewaehlt (z.B. 'zur Feuerinsel'). Sonst 0. Wird aus
- P_HARBOUR des Zielraumes ausgelesen.
-
-
-BEMERKUNGEN
-===========
-
- Diese Property wird von /std/transport.c sowie std/player/travel.c
- verwendet, und sollte NICHT von anderen Objekten oder per Hand
- veraendert werden!
-
-
-SIEHE AUCH
-==========
-
- /std/transport.c, /std/player/travel.c, reise
-
-
-LETZTER AENDERUNG
-=================
-
- Don, 24.01.2002, 10:15:07h von Tilly
diff --git a/doc/sphinx/man/props/P_TRAY b/doc/sphinx/man/props/P_TRAY
deleted file mode 100644
index 0c394d4..0000000
--- a/doc/sphinx/man/props/P_TRAY
+++ /dev/null
@@ -1,21 +0,0 @@
-
-P_TRAY
-******
-
-
-NAME
-====
-
- P_TRAY "tray"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/sphinx/man/props/P_TTY b/doc/sphinx/man/props/P_TTY
deleted file mode 100644
index 87841fd..0000000
--- a/doc/sphinx/man/props/P_TTY
+++ /dev/null
@@ -1,45 +0,0 @@
-
-P_TTY
-*****
-
-
-NAME
-====
-
- P_TTY "tty"
-
-
-DEFINIERT IN
-============
-
- /secure/telnetneg.h
-
-
-BESCHREIBUNG
-============
-
- Name der Terminalemulation, die der Spieler nutzt.
- Es existieren bisher "dumb", "vt100" und "ansi".
-
-
-ANMERKUNG
-=========
-
- Farben duerfen ausschliesslich bei P_TTY=="ansi" benutzt werden.
- Bei nicht farbfaehigen Terminals koennen ANSI-Codes die gesamte
- Ausgabe zerschiessen!
-
- Die Attribute fett, unterstrichen, blinkend und invers koennen auch
- schon von vt100-Terminals dargestellt werden. Aber nicht ueberall
- sind alle Attribute/Farben implementiert.
-
- Bei allen ANSI-Codes sind drei Sachen zu beachten:
-
-
-
- 1) Sparsam benutzen! Aufgezwungene Hervorhebungen koennen
- Spieler ganz schnell nerven.
-
- 2) Nicht jeder benutzt dieselbe Hintergrundfarbe!
-
- 3) Sparsam benutzen! Beser noch: nur im Notfall!
diff --git a/doc/sphinx/man/props/P_TTY_COLS b/doc/sphinx/man/props/P_TTY_COLS
deleted file mode 100644
index 8780417..0000000
--- a/doc/sphinx/man/props/P_TTY_COLS
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_TTY_COLS
-**********
-
-
-NAME
-====
-
- P_TTY_COLS "tty_cols"
-
-
-DEFINIERT IN
-============
-
- /secure/telnetneg.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Properties steht die Anzahl der Spalten, die das
- Terminalfenster des Spielers derzeit hat.
-
- Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
- Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
- leer.
- Das Setzen der Property aendert die Fenstergroesse des Spielers
- natuerlich nicht.
-
-
-SIEHE AUCH
-==========
-
- P_TTY_ROWS, P_TTY_TYPE, P_TTY_SHOW
-
-
-LETZTE AeNDERUNG
-================
-
- Sat, 06.02.1999, 14:00:00 von Paracelsus
diff --git a/doc/sphinx/man/props/P_TTY_ROWS b/doc/sphinx/man/props/P_TTY_ROWS
deleted file mode 100644
index 7289109..0000000
--- a/doc/sphinx/man/props/P_TTY_ROWS
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_TTY_ROWS
-**********
-
-
-NAME
-====
-
- P_TTY_ROWS "tty_rows"
-
-
-DEFINIERT IN
-============
-
- /secure/telnetneg.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Properties steht die Anzahl der Zeilen, die das
- Terminalfenster des Spielers derzeit hat.
-
- Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
- Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
- leer.
- Das Setzen der Property aendert die Fenstergroesse des Spielers
- natuerlich nicht.
-
-
-SIEHE AUCH
-==========
-
- P_TTY_COLS, P_TTY_TYPE, P_TTY_SHOW
-
-
-LETZTE AeNDERUNG
-================
-
- Sat, 06.02.1999, 14:00:00 von Paracelsus
diff --git a/doc/sphinx/man/props/P_TTY_SHOW b/doc/sphinx/man/props/P_TTY_SHOW
deleted file mode 100644
index a43076f..0000000
--- a/doc/sphinx/man/props/P_TTY_SHOW
+++ /dev/null
@@ -1,35 +0,0 @@
-
-P_TTY_SHOW
-**********
-
-
-NAME
-====
-
- P_TTY_SHOW "tty_show"
-
-
-DEFINIERT IN
-============
-
- /secure/telnetneg.h
-
-
-BESCHREIBUNG
-============
-
- Bei Telnets, die Telnetnegotiations unterstuetzen, wird eine Aenderung
- der Fenstergroesse dem Spielerobjekt mitgeteilt. Steht in P_TTY_SHOW
- ein Wert ungleich Null, wird dem Spieler diese Aenderung mitgeteilt.
-
-
-SIEHE AUCH
-==========
-
- P_TTY_ROWS, P_TTY_COLS, P_TTY_TYPE, telnegs
-
-
-LETZTE AeNDERUNG
-================
-
- Sat, 06.02.1999, 14:00:00 von Paracelsus
diff --git a/doc/sphinx/man/props/P_TTY_TYPE b/doc/sphinx/man/props/P_TTY_TYPE
deleted file mode 100644
index 5842cb2..0000000
--- a/doc/sphinx/man/props/P_TTY_TYPE
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_TTY_TYPE
-**********
-
-
-NAME
-====
-
- P_TTY_TYPE "tty_type"
-
-
-DEFINIERT IN
-============
-
- /secure/telnetneg.h
-
-
-BESCHREIBUNG
-============
-
- In dieser Properties steht der Terminaltyp, den ein Spieler lokal auf
- seinem Rechner verwendet.
-
- Voraussetzung hierfuer ist allerdings, dass das Telnet des Spielers
- Telnetnegotiations unterstuetzt, ansonsten bleibt diese Property
- leer. Die meisten Telnets/Clients geben ihren Terminaltyp allerdings
- nicht preis.
- Das Setzen der Property aendert den Terminaltyp des Spielers
- natuerlich nicht.
-
-
-SIEHE AUCH
-==========
-
- P_TTY_COLS, P_TTY_ROWS, P_TTY_SHOW
-
-
-LETZTE AeNDERUNG
-================
-
- Sat, 06.02.1999, 14:00:00 von Paracelsus
diff --git a/doc/sphinx/man/props/P_UNIT_DECAY_FLAGS b/doc/sphinx/man/props/P_UNIT_DECAY_FLAGS
deleted file mode 100644
index 25a5ed1..0000000
--- a/doc/sphinx/man/props/P_UNIT_DECAY_FLAGS
+++ /dev/null
@@ -1,90 +0,0 @@
-
-P_UNIT_DECAY_FLAGS
-******************
-
-
-NAME
-====
-
- P_UNIT_DECAY_FLAGS "unit_decay_flags"
-
-
-DEFINIERT IN
-============
-
- /sys/unit.h
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Prop kann das Zerfallsverhalten gesteuert werden, entweder
- fuer alle Clones durch Setzen in der Blueprint oder fuer einzelne Clones.
-
- In dieser Prop koennen momentan 4 Flags gesetzt werden:
- - NO_DECAY:
- Zerfall ist abgeschaltet.
- - NO_DECAY_UNTIL_MOVE:
- Der Zerfall ist solange ausgesetzt, bis dieses Objekt in ein anderes
- Env bewegt wird. Setzt also ein NPC beim AddItem() diese Prop,
- zerfaellt seine Unit nicht, bis sie bewegt wurde (Leiche, Spieler
- etc.). Hierbei zaehlt das move() nicht, wenn das Objekt noch kein
- Env hatte, es zaehlen nur Moves von einem Env in ein anderes Env.
- Dieses Flag sollte nur in Clones gesetzt werden.
- - INACCURATE_DECAY
- Sollen z.b. 45.34 Einheiten zerfallen, wird der Rest von 0.34
- normalerweise als Wahrscheinlichkeit aufgefasst, dass eine
- zusaetzliche Einheit zerfaellt. Dieses Flag sorgt dafuer, dass
- dieser Rest weggeworfen wird und einfach 45 Einheiten zerfallen.
- Gleichzeitig wird bei diesem Flag aber _immer min_ 1 Einheit
- zerstoert!
- - ABSOLUTE_DECAY
- P_UNIT_DECAY_QUOTA wird nicht als prozentualer Anteil aufgefasst,
- sondern als absolute Zahl, d.h. es zerfallen immer einfach
- P_UNIT_DECAY_QUOTA Einheiten.
-
- Diese Flags koennen z.B. genutzt werden, den Zerfall fuer einzelne
- Objekte temporaer oder dauerhaft abzuschalten, auch wenn alle anderen
- Clones weiterzerfallen.
-
- Diese Prop kann in der Blueprint gesetzt werden. In diesem Fall wird
- allerdings NO_DECAY_UNTIL_MOVE ignoriert, weil die BP ja nie bewegt
- wuerde. NO_DECAY in der BP schaltet den Zerfallsprozess (temporaer) fuer
- alle Clones aus. Ist nie ein Zerfall gewuenscht, sollte in der Blueprint
- aber besser P_UNIT_DECAY_INTERVAL auf 0 gesetzt werden!
-
- Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
- liefert ein klon->QueryProp(P_UNIT_DECAY_FLAGS) den in der Blueprint
- eingestellten Wert zurueck.
-
-
-BEMERKUNGEN
-===========
-
- * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus der
- Blueprint zurueckgeben. Hierbei wird allerdings ein NO_DECAY_UNTIL_MOVE
- ausgefiltert, da dies den Zerfall fuer alle Objekte dauerhaft stoppen
- wuerde, weil BPs nicht bewegt werden.
- * Die Flags koennen "verodert" werden:
- SetProp(P_UNIT_DECAY_FLAGS, NO_DECAY_UNTIL_MOVE | ABSOLUTE_DECAY);
-
-
-BEISPIEL
-========
-
- // Dieser NPC hat tolle Pfeile, die sollen aber nicht zerfallen, solange
- // sie im Inventar des NPCs sind:
- AddItem("/d/tolleregion/tollermagier/obj/pfeile", REFRESH_NONE,
- ([ P_AMOUNT: 50+random(50),
- P_UNIT_DECAY_FLAGS: NO_DECAY_UNTIL_MOVE ]) );
-
-
-SIEHE AUCH
-==========
-
- unit
- P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_MIN
- DoDecay, DoDecayMessage
- /std/unit.c
-
-14.10.2007, Zesstra
diff --git a/doc/sphinx/man/props/P_UNIT_DECAY_INTERVAL b/doc/sphinx/man/props/P_UNIT_DECAY_INTERVAL
deleted file mode 100644
index e0118c3..0000000
--- a/doc/sphinx/man/props/P_UNIT_DECAY_INTERVAL
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_UNIT_DECAY_INTERVAL
-*********************
-
-
-NAME
-====
-
- P_UNIT_DECAY_INTERVAL "unit_decay_interval"
-
-
-DEFINIERT IN
-============
-
- /sys/unit.h
-
-
-BESCHREIBUNG
-============
-
- Diese Prop bestimmt, wie oft ein Zerfall der entsprechenden Unitobjekte
- durchgefuehrt wird. Das Intervall ist in Sekunden anzugeben (int).
- Die Prop muss in der Blueprint der entsprechenden Unitobjekte gesetzt
- werden, in Clones kann sie nicht gesetzt werden.
- Die Blueprint resettet dann in diesem Intervall und ruft in allen ihren
- Clones (und denen alter Versionen der gleichen BP!) DoDecay() auf,
- woraufhin die Clones den Zerfall durchfuehren.
- Ist die Prop in der Blueprint nicht gesetzt, erfolgt kein Zerfall.
-
-
-BEMERKUNGEN
-===========
-
- * Ist die Blueprint nicht geladen, erfolgt kein Zerfall der Clones.
- * Ein Setzen dieser Prop beinhaltet immer auch einen Aufruf von
- set_next_reset() auf das ensprechende Intervall.
- * Die Prop kann in den Clones abgefragt werden und liefert das in der
- Blueprint eingestellte Intervall.
- * Von einer Manipulation per Set() wird dringend abgeraten.
- * Die Prop kann nur vom Objekt selber, vom Programmierer des Objekts, vom
- RM der entsprechenden Region, von einem Weisen oder von einem Objekt
- gesetzt werden, welches die gleiche UID hat.
-
-
-BEISPIEL
-========
-
-
-SIEHE AUCH
-==========
-
- unit
- P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_MIN
- DoDecay(), DoDecayMessage()
-
-13.10.2007, Zesstra
diff --git a/doc/sphinx/man/props/P_UNIT_DECAY_MIN b/doc/sphinx/man/props/P_UNIT_DECAY_MIN
deleted file mode 100644
index b78a735..0000000
--- a/doc/sphinx/man/props/P_UNIT_DECAY_MIN
+++ /dev/null
@@ -1,71 +0,0 @@
-
-P_UNIT_DECAY_MIN
-****************
-
-
-NAME
-====
-
- P_UNIT_DECAY_MIN "unit_decay_min"
-
-
-DEFINIERT IN
-============
-
- /sys/unit.h
-
-
-BESCHREIBUNG
-============
-
- Diese Prop bestimmt, wieviele Einheiten der Unitobjekten mindestens
- uebrig bleiben sollen.
- Faellt die Menge eines Unitobjekts unter diesen Wert, zerfaellt diese
- Unit solange nicht weiter, bis der Wert wieder ueberschritten wird.
- Die Prop kann in der Blueprint und in den einzelnen Clones gesetzt
- werden.
- Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
- liefert ein QueryProp(P_UNIT_DECAY_MIN) den in der Blueprint
- eingestellten Wert zurueck und die Unit zerfaellt bis zu dieser
- Mindestmenge..
- D.h. man sollte diese Prop in der Blueprint setzen und in einzelnen
- Clones nur soweit diese abweichende Werte haben sollen.
- Es sind nur Werte zwischen 0 und 100 zulaessig. Auf diese Art laesst sich
- die minidestens uebrig bleibende Menge aller Clones durch Aendern einer
- Prop in der Blueprint aendern.
-
-
-BEMERKUNGEN
-===========
-
- * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus er
- Blueprint zum Zerfall benutzt.
- * Will man fuer ein bestimmtes Unitobjekt kein Minimum haben, also dass
- dieses Objekt zerfaellt, bis nichts mehr da ist, die Blueprint hat aber
- einen Minimalwert gesetzt, sollte diese Prop im betreffenden Objekt auf
- -1 gesetzt werden.
- * Diese Prop sollte vorsichtig angewandt werden, da Spieler so den
- Zerfall von Units stoppen koennen, indem sie die Units entsprechend
- aufteilen, so dass jedes Einzelobjekt unter dem Minimum liegt.
-
-
-BEISPIEL
-========
-
- // es soll min. 1 Einheit uebrig bleiben.
- SetProp(P_UNIT_DECAY_MIN, 1);
-
- // die Blueprint hat ein Minimum von 10 gesetzt, dieser Clone soll
- // aber zerfallen, bis nix mehr da ist.
- klon->SetProp(P_UNIT_DECAY_MIN, -1);
-
-
-SIEHE AUCH
-==========
-
- unit
- P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA
- DoDecay, DoDecayMessage
- /std/unit.c
-
-14.10.2007, Zesstra
diff --git a/doc/sphinx/man/props/P_UNIT_DECAY_QUOTA b/doc/sphinx/man/props/P_UNIT_DECAY_QUOTA
deleted file mode 100644
index 0b4c9a6..0000000
--- a/doc/sphinx/man/props/P_UNIT_DECAY_QUOTA
+++ /dev/null
@@ -1,69 +0,0 @@
-
-P_UNIT_DECAY_QUOTA
-******************
-
-
-P_UNIT_DECAY_QUOTA (int)
-========================
-
-
-NAME
-====
-
- P_UNIT_DECAY_QUOTA "unit_decay_quota"
-
-
-DEFINIERT IN
-============
-
- /sys/unit.h
-
-
-BESCHREIBUNG
-============
-
- Diese Prop bestimmt, welcher Anteil der einzelnen Unitobjekte pro Zerfall
- zerstoert wird. Dieser Anteil wird als ganze Zahl zwischen 0 und 10000
- ausgedrueckt. 1 entspricht einem Zerfall von 0.01%, 10000 entspricht
- 100%.
- Momentan sind keine Werte < 0 zulaessig, die einem Zuwachs entsprechend
- wurden.
-
- Falls das Flag ABSOLUTE_DECAY (s. P_UNIT_DECAY_FLAGS) gesetzt ist, steht
- die Zahl in dieser Prop fuer die absolute Anzahl an zu zerstoerenden
- Einheiten.
-
- Die Prop kann in der Blueprint und in den einzelnen Clones gesetzt
- werden.
- Ist die Prop in einem einzelnen Clone nicht explizit gesetzt,
- liefert ein QueryProp(P_UNIT_DECAY_QUOTA) den in der Blueprint
- eingestellten Wert zurueck und die Unit zerfaellt zu diesem Anteil.
- D.h. man sollte diese Prop in der Blueprint setzen und in einzelnen
- Clones nur soweit diese abweichende Zerfallsraten haben sollen.
-
-
-BEMERKUNGEN
-===========
-
- * Setzt man diese Prop in einem Clone auf 0, wird der Wert aus er
- Blueprint zum Zerfall benutzt.
- * Will man den Zerfall fuer ein bestimmtes Unitobjekt abschalten, sollte
- man P_UNIT_DECAY_FLAGS benutzen.
-
-
-BEISPIEL
-========
-
- // pro Zerfallsintervall sollen 12% zerfallen.
- SetProp(P_UNIT_DECAY_QUOTA, 1200);
-
-
-SIEHE AUCH
-==========
-
- unit
- P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_MIN
- DoDecay, DoDecayMessage
- /std/unit.c
-
-14.03.2008, Zesstra
diff --git a/doc/sphinx/man/props/P_UNWEAR_MSG b/doc/sphinx/man/props/P_UNWEAR_MSG
deleted file mode 100644
index 0b2e89a..0000000
--- a/doc/sphinx/man/props/P_UNWEAR_MSG
+++ /dev/null
@@ -1,78 +0,0 @@
-
-P_UNWEAR_MSG
-************
-
-
-NAME
-====
-
- P_UNWEAR_MSG "unwear_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/armour.h
-
-
-BESCHREIBUNG
-============
-
- Zweiteiliges Array mit Meldungen, die beim Ausziehen einer Ruestung
- oder Kleidung an den Spieler und die Umgebung ausgegeben werden.
- Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
- Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
- jedoch beruecksichtigt.
-
- Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
- man replace_personal()).
-
- [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
- moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
- in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
- den Waffennamen.]
-
-
-BEISPIELE
-=========
-
- SetProp(P_NAME, "Mantel");
- SetProp(P_UNWEAR_MSG,
- ({"Du reisst Dir @WEN2 vom Leib.",
- "@WER1 reisst sich @WENU2 vom Leib." }));
-
- -> beim Ausziehen durch Urk:
- Urk bekommt: Du reisst dir den Mantel vom Leib.
- Der Raum: Urk reisst sich einen Mantel vom Leib.
-
- SetProp(P_UNWEAR_MSG,
- ({"Dir wird furchtbar warm. So eine Hitze aber auch. Schnell "
- "schluepfst Du aus Deiner dicken Ruestung. Aaaah, was fuer "
- "eine Wohltat.",
- "@WEM1 scheint ploetzlich warm zu werden. Schnell schluepft "
- "@WERQP1 aus @WEMQPPFS1 dicken Ruestung. Du hoffst instaendig, "
- "das es noch etwas waermer wird ... "}));
-
- -> beim Ausziehen durch Urk:
- Urk bekommt: Dir wird furchtbar warm. So eine Hitze aber auch.
- Schnell schluepfst Du aus Deiner dicken Ruestung.
- Aaaah, was fuer eine Wohltat.
- Der Raum: Urk scheint ploetzlich warm zu werden. Schnell
- schluepft er aus seiner dicken Ruestung. Du hoffst
- instaendig, das es noch etwas waermer wird ...
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_WEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
- P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
- Funktionen: WearFunc, UnwearFunc
- Sonstiges: replace_personal(E), /std/armour/wear.c, armours
- clothing, /std/clothing.wear.c
-
-
-LETZTE AeNDERUNG
-================
-
-15.02.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_UNWIELD_FUNC b/doc/sphinx/man/props/P_UNWIELD_FUNC
deleted file mode 100644
index 4466ec0..0000000
--- a/doc/sphinx/man/props/P_UNWIELD_FUNC
+++ /dev/null
@@ -1,32 +0,0 @@
-
-P_UNWIELD_FUNC
-**************
-
-
-NAME
-====
-
- P_UNWIELD_FUNC "unwield_func"
-
-
-DEFINIERT IN
-============
-
- <weapon.h>
-
-
-BESCHREIBUNG
-============
-
- Falls ein Objekt eine UnwieldFunc() fuer die Waffe definiert, so muss
- dieses Objekt in dieser Property eingetragen werden.
-
- Die Auswertung dieser Property erfolgt in DoUnwield().
-
-
-SIEHE AUCH
-==========
-
- /std/weapon.c, UnwieldFunc()
-
-Last modified: Sun May 19 15:44:08 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_UNWIELD_MSG b/doc/sphinx/man/props/P_UNWIELD_MSG
deleted file mode 100644
index d1d1668..0000000
--- a/doc/sphinx/man/props/P_UNWIELD_MSG
+++ /dev/null
@@ -1,77 +0,0 @@
-
-P_UNWIELD_MSG
-*************
-
-
-NAME
-====
-
- P_UNWIELD_MSG "unwield_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/weapon.h
-
-
-BESCHREIBUNG
-============
-
- Zweiteiliges Array mit Meldungen, die beim Wegstecken einer
- Waffe an den Spieler und die Umgebung ausgegeben werden.
-
- Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
- Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
- jedoch beruecksichtigt.
-
- Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
- man replace_personal()).
-
- [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
- moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
- in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
- den Waffennamen.]
-
-
-BEISPIELE
-=========
-
- SetProp(P_NAME, "Streitkolben");
- SetProp(P_UNWIELD_MSG,
- ({ "Du steckst @WEN2 zurueck und atmest erstmal tief durch.",
- "@WER1 steckt @WENU2 zurueck und atmet erstmal tief durch." }));
-
- -> beim Wegstecken durch Urk:
- Urk bekommt: Du steckst den Streitkolben zurueck und atmest erstmal
- tief durch.
- Der Raum: Urk steckt einen Streitkolben zurueck und atmet erstmal
- tief durch.
-
- SetProp(P_UNWIELD_MSG,
- ({"Du steckst die schwere Keule zurueck. Zufaellig landet sie "
- "dabei auf Deinem Fuss. Laut schreiend humpelst Du in der "
- "Gegend herum.",
- "@WER1 steckt eine schwere Keule zurueck. Dummerweise landet diese "
- "direkt auf dem eigenen Fuss. Aua, das tat sicher weh ... nicht "
- "umsonst humpelt @WERQP1 jetzt schreiend durch die Gegend."}));
-
- -> beim Wegstecken durch Urk:
- Urk bekommt: Du steckst die schwere Keule zurueck. Zufaellig landet
- sie dabei auf Deinem Fuss. Laut schreiend humpelst Du in
- der Gegend herum.
- Der Raum: Urk steckt eine schwere Keule zurueck. Dummerweise
- landet diese direkt auf dem eigenen Fuss. Aua, das tat
- sicher weh ... nicht umsonst humpelt er jetzt schreiend
- durch die Gegend.
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_WIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
- P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
- Funktionen: UnwieldFunc, WieldFunc
- Sonstiges: replace_personal(E), /std/weapon/combat.c
-
-29. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_UNWIELD_TIME b/doc/sphinx/man/props/P_UNWIELD_TIME
deleted file mode 100644
index e93a24b..0000000
--- a/doc/sphinx/man/props/P_UNWIELD_TIME
+++ /dev/null
@@ -1,33 +0,0 @@
-
-P_UNWIELD_TIME
-**************
-
-
-NAME
-====
-
- P_UNWIELD_TIME "unwield_time"
-
-
-DEFINIERT IN
-============
-
- /sys/weapon.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt den Zeitpunkt zu dem ein Living eine Waffe weggesteckt hat und
- ist im Living gesetzt.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: P_WEAPON, P_WIELDED, DoUnwield()
- P_LAST_USE
- Sonstiges: P_EQUIP_TIME
- time()
-
-10.Feb 2005 Gloinson
diff --git a/doc/sphinx/man/props/P_USED_HANDS b/doc/sphinx/man/props/P_USED_HANDS
deleted file mode 100644
index b90bd61..0000000
--- a/doc/sphinx/man/props/P_USED_HANDS
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_USED_HANDS
-************
-
-
-NAME
-====
-
- P_USED_HANDS "used_hands"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-BESCHREIBUNG
-============
-
- Anzahl der Haende in Benutzung.
- Effektiv nur ein sizeof(P_HANDS_USED_BY).
-
-
-BEMERKUNGEN
-===========
-
- Keine echte Property. Die Methode /std/living/combat::_query_used_hands
- stellt die Daten zusammen. Nicht setzen!
-
-
-SIEHE AUCH
-==========
-
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_FREE_HANDS
- UseHands, FreeHands
-
-1. Okt 2012, Gloinson
diff --git a/doc/sphinx/man/props/P_VALID_GUILDS b/doc/sphinx/man/props/P_VALID_GUILDS
deleted file mode 100644
index f431e7b..0000000
--- a/doc/sphinx/man/props/P_VALID_GUILDS
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_VALID_GUILDS
-**************
-
-
-NAME
-====
-
- P_VALID_GUILDS "valid_guilds"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die zugelassenen Gilden in Form von
- kleingeschriebenen Gildennamen, welche in einem Array
- zusammengefasst sind. Sie ist nur fuer den Gildenmaster selbst von
- Bedeutung.
-
-
-BEISPIELE
-=========
-
- Abfrage der zugelassenen Gilden:
- find_object("/obj/gildenmaster")->QueryProp(P_VALID_GUILDS)
- Das ergibt zum Beispiel:
- ({"abenteurer","zauberer","klerus","kaempfer"})
-
-
-SIEHE AUCH
-==========
-
- P_GUILD, /obj/gildenmaster.c
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_VALUE b/doc/sphinx/man/props/P_VALUE
deleted file mode 100644
index cb48202..0000000
--- a/doc/sphinx/man/props/P_VALUE
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_VALUE
-*******
-
-
-NAME
-====
-
- P_VALUE "value"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- - Objekte
- Wert des Objektes in Goldmuenzen. Diesen Wert erhaelt man beim
- Verkauf. Kaufen kostet ein Vielfaches hiervon.
-
- - Speisen/Kneipen
- Wert einer Portion der Speise.
-
-
-BEMERKUNGEN
-===========
-
- In tragbaren Speisen (erben von /std/food) setzt man mit SetProp
- den Wert _einer_ Portion. Per QueryProp erhaelt man aber den Gesamt-
- wert der Speise inclusive des eventuell vorhandenen Behaelters. Der
- Wert des Behaelters wird dabei aus P_EMPTY_PROPS[P_VALUE] gelesen.
-
-
-SIEHE AUCH
-==========
-
- Speisen: std/pub, wiz/food, P_EMPTY_PROPS
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_VALUE_PER_UNIT b/doc/sphinx/man/props/P_VALUE_PER_UNIT
deleted file mode 100644
index 3ff1b3c..0000000
--- a/doc/sphinx/man/props/P_VALUE_PER_UNIT
+++ /dev/null
@@ -1,29 +0,0 @@
-
-P_VALUE_PER_UNIT
-****************
-
-
-NAME
-====
-
- P_VALUE_PER_UNIT "value_per_unit"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Wert in Goldstuecken pro Untereinheit.
-
-
-BEMERKUNGEN
-===========
-
- Deprecated. Bitte SetCoinsPerUnits() (U_CPU) benutzen.
-
-25.Aug 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_VARIABLES b/doc/sphinx/man/props/P_VARIABLES
deleted file mode 100644
index 52a979c..0000000
--- a/doc/sphinx/man/props/P_VARIABLES
+++ /dev/null
@@ -1,28 +0,0 @@
-
-P_VARIABLES
-***********
-
-
-NAME
-====
-
- P_VARIABLES "variables"
-
-
-DEFINIERT IN
-============
-
- /sys/magier.h
-
-
-BESCHREIBUNG
-============
-
- Interne Variable der Magiershell in dem die mit dem 'Set'-Befehl
- gesetzten Variablen gespeichert werden.
-
-
-
- NICHT VON HAND VERAENDERN! IMMER 'SET' VERWENDEN!
-
-Letzte Aenderung: 13.02.2003 22:00:00 von Mandragon
diff --git a/doc/sphinx/man/props/P_VISIBLE_GUILD b/doc/sphinx/man/props/P_VISIBLE_GUILD
deleted file mode 100644
index 92de8b7..0000000
--- a/doc/sphinx/man/props/P_VISIBLE_GUILD
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_VISIBLE_GUILD
-***************
-
-
-NAME
-====
-
- P_VISIBLE_GUILD "visible_guild"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die sichtbare Gilde des Lebewesens in Form eines
- kleingeschriebenen Strings, also die Gilde, die bei Spielern zum
- Beispiel bei 'kwer' oder 'finger' angezeigt wird. So kann man fremde
- Gilden testen und trotzdem nach aussen hin in der gleichen Gilde wie
- zuvor bleiben.
-
-
-BEISPIEL
-========
-
- Wenn man gerne nach aussen hin Zauberer bleiben moechte:
- pl->SetProp(P_VISIBLE_GUILD,"zauberer");
- Nach aussen hin bleibt man jetzt auch Zauberer, wenn P_GUILD eine
- andere Gilde angibt.
-
-
-SIEHE AUCH
-==========
-
- P_GUILD, P_DEFAULT_GUILD
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/P_VISIBLE_SUBGUILD_TITLE b/doc/sphinx/man/props/P_VISIBLE_SUBGUILD_TITLE
deleted file mode 100644
index e0e5c83..0000000
--- a/doc/sphinx/man/props/P_VISIBLE_SUBGUILD_TITLE
+++ /dev/null
@@ -1,39 +0,0 @@
-
-P_VISIBLE_SUBGUILD_TITLE
-************************
-
-
-NAME
-====
-
- P_VISIBLE_SUBGUILD_TITLE "visible_subguild_title"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property dient dazu, als Magier einen Zusatztitel innerhalb einer
- Gilde vorzutaeuschen, ohne den tatsaechlichen P_SUBGUILD_TITLE zu
- aendern.
-
-
-BEMERKUNGEN
-===========
-
- Inhalt der Property kann 0 sein oder ein String.
- Wenn der Inhalt 0 ist, wird bei QueryProp der P_SUBGUILD_TITLE
- durchgereicht.
-
-
-SIEHE AUCH
-==========
-
- P_GUILD_TITLE, P_SUBGUILD_TITLE
-
-Last modified: Mon Aug 13 21:20:00 2001 by Nachtwind
diff --git a/doc/sphinx/man/props/P_VISUALBELL b/doc/sphinx/man/props/P_VISUALBELL
deleted file mode 100644
index 8a3d836..0000000
--- a/doc/sphinx/man/props/P_VISUALBELL
+++ /dev/null
@@ -1,58 +0,0 @@
-
-P_VISUALBELL
-************
-
-
-NAME
-====
-
- P_VISUALBELL "visualbell"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Die Property stellt ein Flag innerhalb von Spielern dar, welches
- standardmaessig nicht gesetzt ist. In diesem Fall werden Toene,
- welche innerhalb einiger Funktionen erzeugt werden, auch wirklich an
- den Spieler geschickt.
- Setzt man die Property, so erhaelt der Spieler keine Toene mehr.
-
-
-BEISPIEL
-========
-
- Pieptoene werden durch den ASCII-Code 0x7 praesentiert. Ausgeben
- kann man diesen folgendermassen:
- if(!IS_WIZARD(caster)&&!victim->QueryProp(P_VISUALBELL))
- tell_object(victim,sprintf("%c",7));
- Das waere beispielsweise ein Codestueck aus einem Piepspell. :)
- Das Opfer bekommt den Piepton hierbei nur ab, wenn der Caster ein
- Magier ist oder das Spieleropfer die Property P_VISUALBELL gesetzt
- hat (kann mit Kommando 'ton' vom Spieler beeinflusst werden).
-
-
-BEMERKUNGEN
-===========
-
- Achtung: P_VISUALBELL steht auf 1, wenn der Spieler _keine_ Piepstoene
- hoeren will!
- Die Funktionalitaet dieser Property wirkt nur soweit, wie sie auch
- von tonerzeugenden Befehlen selbst unterstuetzt wird. Es ist darauf
- zu achten, dass P_VISUALBELL zu diesem Zweck grundsaetzlich
- ausgewertet wird! Eine Ausnahme sei hierbei zugelassen: Magier
- koennen Spielern grundsaetzlich Toene zusenden.
-
-
-SIEHE AUCH
-==========
-
- ton, wecke, erwarte, P_WAITFOR, /std/player/base.c
-
-Last modified: 07.02.2007 by Zesstra
diff --git a/doc/sphinx/man/props/P_VULNERABILITY b/doc/sphinx/man/props/P_VULNERABILITY
deleted file mode 100644
index f0e3abb..0000000
--- a/doc/sphinx/man/props/P_VULNERABILITY
+++ /dev/null
@@ -1,62 +0,0 @@
-
-P_VULNERABILITY
-***************
-
-
-NAME
-====
-
- P_VULNERABILITY "vulnerability"
-
-
-DEFINIERT IN
-============
-
- /sys/living/combat.h
-
-
-WICHTIG
-=======
-
- DIESE PROPERTY IST VERALTET! BITTE P_RESISTANCE_STRENGTHS
- VERWENDEN! AUCH FUNKTIONIERT Set() NICHT WIE ES SOLLTE.
-
-
-BESCHREIBUNG
-============
-
- Hiermit koennen die Empfindlichkeiten eines Lebewesens definiert
- werden. Es kann ein Array mit Schadensarten gesetzt werden, jeder
- Eintrag eines Schadens verdoppelt die Empfindlichkeit gegen
- diesen.
-
-
-BEMERKUNGEN
-===========
-
- - P_RESISTANCE_STRENGTHS spiegelt die Eintraege hier wieder
- - um genauere Werte anzugeben einen AddResistanceModifier() oder
- P_RESISTANCE_STRENGTHS benutzen.
- - P_VULNERABILITY kann und wird nicht aus P_RESISTANCE_STRENGTHS
- upgedatet
-
-
-BEISPIELE
-=========
-
- // ein NPC mit verdoppelter Eisempfindlichkeit und
- // vervierfachter Wasserempfindlichkeit
- SetProp(P_VULNERABILITY, ({DT_COLD, DT_WATER, DT_WATER}));
-
-
-SIEHE AUCH
-==========
-
- simple Resistenz: P_RESISTANCE
- Hauptmapping: P_RESISTANCE_STRENGTHS
- Modifikatoren: AddResistanceModifier, RemoveResistanceModifier(),
- P_RESISTANCE_MODIFIER
- Berechnung: CheckResistance(), UpdateResistanceStrengths()
- anderes: balance, /std/armour/combat.c, /std/living/combat.c
-
-1.Dez 2004, Gloinson
diff --git a/doc/sphinx/man/props/P_WAITFOR b/doc/sphinx/man/props/P_WAITFOR
deleted file mode 100644
index 301838e..0000000
--- a/doc/sphinx/man/props/P_WAITFOR
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_WAITFOR
-*********
-
-
-NAME
-====
-
- P_WAITFOR "waitfor"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Die Erwarte-Liste. Ein Array mit den Namen der Erwarteten.
-
-
-SIEHE AUCH
-==========
-
- erwarte
- P_WAITFOR_REASON, P_WAITFOR_FLAGS
-
-16. Feb 2008 Gloinson
diff --git a/doc/sphinx/man/props/P_WAITFOR_FLAGS b/doc/sphinx/man/props/P_WAITFOR_FLAGS
deleted file mode 100644
index 5e616b7..0000000
--- a/doc/sphinx/man/props/P_WAITFOR_FLAGS
+++ /dev/null
@@ -1,34 +0,0 @@
-
-P_WAITFOR_FLAGS
-***************
-
-
-NAME
-====
-
- P_WAITFOR_FLAGS "waitfor_flags"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Ein Int. Bisher bekannte Flags:
-
-
-
- 0x01 - "erwarte aus"
-
-
-SIEHE AUCH
-==========
-
- erwarte
- P_WAITFOR, P_WAITFOR_REASON
-
-16. Feb 2008 Gloinson
diff --git a/doc/sphinx/man/props/P_WAITFOR_REASON b/doc/sphinx/man/props/P_WAITFOR_REASON
deleted file mode 100644
index 1d997d8..0000000
--- a/doc/sphinx/man/props/P_WAITFOR_REASON
+++ /dev/null
@@ -1,35 +0,0 @@
-
-P_WAITFOR_REASON
-****************
-
-
-NAME
-====
-
- P_WAITFOR_REASON "waitfor_reason"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Ein Mapping mit den Erwarteten als Schluessel und einem Grund als
- Key, zB:
-
-
-
- (["Zook":"muh muh"])
-
-
-SIEHE AUCH
-==========
-
- erwarte (erwarte <wen> wegen <was>)
- P_WAITFOR, P_WAITFOR_FLAGS
-
-16. Feb 2008 Gloinson
diff --git a/doc/sphinx/man/props/P_WANTS_TO_LEARN b/doc/sphinx/man/props/P_WANTS_TO_LEARN
deleted file mode 100644
index 639ab61..0000000
--- a/doc/sphinx/man/props/P_WANTS_TO_LEARN
+++ /dev/null
@@ -1,25 +0,0 @@
-
-P_WANTS_TO_LEARN
-****************
-
-
-NAME
-====
-
- P_WANTS_TO_LEARN "wants_to_learn"
-
-
-DEFINIERT IN
-============
-
- /sys/player/base.h
-
-
-BESCHREIBUNG
-============
-
- Gesetzt, wenn der Magier die Filenamen sehen will.
- (Nur fuer Magier). Wird diese Property auf 0 gesetzt, gehen auch
- einige andere Dinge nicht mehr - verfolge zB. Eigentlich sollten
- dann auch die Magierbefehle wie "goto" usw unterbunden werden -
- das kommt vielleicht noch.
diff --git a/doc/sphinx/man/props/P_WATER b/doc/sphinx/man/props/P_WATER
deleted file mode 100644
index 79742c1..0000000
--- a/doc/sphinx/man/props/P_WATER
+++ /dev/null
@@ -1,130 +0,0 @@
-
-P_WATER
-*******
-
-
-NAME
-====
-
- P_WATER "water"
-
-
-DEFINIERT IN
-============
-
- /sys/fishing.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt den Gewaessertyp. Kann in Raeumen, Angeln und Wasserbehaeltern
- verwendet werden. Die verfuegbaren Optionen und Funktionsweisen sind in
- den nachfolgenden Abschnitten aufgefuehrt.
-
- Raum:
- *****
- Legt den Typ des Gewaessers fest, das es in diesem Raum gibt. Von
- diesem Typ haengt ab, welche Arten von Fischen es hier standardmaessig
- gibt und welche Arten von Angeln verwendet werden koennen.
-
-
-
- Beispiel:
-
- SetProp(P_WATER, W_HARBOR);
-
-
-
- Folgende
- Typen stehen zur Verfuegung, von denen in Raeumen nur einer gesetzt
- werden darf:
-
- Salzwasser:
- W_BEACH Strand: Scholle, Flunder, Rochen, Seezunge, Katzenhai
- W_HARBOR Hafen: Dorsch, Rochen, Seezunge, Hering, Katzenhai
- W_OCEAN Ozean/Meer: Hai, Thunfisch, Kabeljau, Schwertfisch, Seehase,
- Seeteufel, Seewolf
-
- Suesswasser:
- W_RIVER Fluss: Piranha, Lachs, Forelle, Bachsaibling
- W_POOL Teich: Stichling, Goldfisch, Schlei, Karpfen, Goldorfe
- W_LAKE See: Karpfen, Barsch, Hecht, Seesaibling
- W_ROCK Bergbach: Lachs, Forelle, Bachsaibling
- W_STREAM Bach: Stichling, Bachforelle, Neuauge, Bachsaibling
-
- Sonstige:
- W_USER wenn dieser Gewaessertyp gesetzt wird, MUSS der Raum
- zusaetzlich die Funktion GetAquarium() definieren, die
- eine Liste der hier fangbaren Fische zurueckgeben muss.
- Beispiel:
-
- string* GetAquarium(){
- return ({"/d/ebene/fraggle/angel/fisch"});
- }
- W_DEAD Lebloses Wasser. Enthaelt keine Fische, man kann
- aber die Standardflasche fuellen.
-
- W_OTHER 1024 // Flasche enthaelt Fluessigkeit!=Wasser
-
-
- Angel:
- ******
- Angeln sind ueblicherweise auf bestimmte Anwendungsbereiche ausgelegt.
- Ob eine Angel in einem Gewaesser benutzt werden kann, haengt davon ab,
- ob P_WATER in der Angel den Gewaessertyp des Raumes enthaelt. Von den
- oben genannten Typen koennen mehrere ver-ODER-t gesetzt werden.
- Verwendung einer fuer das oertliche Gewaesser ungeeigneten Angel fuehrt
- zu einer um 60+random(60) Sekunden verlaengerten Wartezeit beim Angeln.
-
-
-
- Beispiel: Setzt man den Gewaessertyp mit
-
- SetProp(P_WATER, W_HARBOR|W_OCEAN);
-
- schaltet das die Angel sowohl fuer Haefen, als auch fuer offene Meere
- (Ozeane) frei.
-
- Folgende kombinierte Gewaessertypen sind fuer einfache Angeln
- vordefiniert:
-
- Kurze Standardangeln:
- W_SHORT W_HARBOR|W_RIVER|W_POOL|W_LAKE|W_ROCK|W_USER|W_OCEAN|W_STREAM
- Spezielle Strandruten:
- W_LONG W_BEACH|W_USER
- funktioniert in allen Salzgewaessern:
- W_SALT W_HARBOR|W_OCEAN|W_BEACH
- funktioniert in allen Suessgewaessern:
- W_SWEET W_RIVER|W_POOL|W_LAKE|W_ROCK|W_STREAM
-
- Hinweis: W_DEAD ist in diesen Kombinationen nicht enthalten, da es
- in solchen Gewaessern ohnehin keine Fische gibt.
- Die Kombi-Typen enthalten W_USER, um bei entsprechenden Gewaessern
- zu vermeiden, dass es dort standardmaessig einen Malus auf die
- Wartezeit gibt. Standardwert fuer P_WATER in Angeln ist ebenfalls
- W_USER.
-
- Koeder:
- *******
- Auch Koeder koennen fuer die Verwendung in bestimmten Gewaessern besser
- geeignet sein als in anderen, z.B. eine Seeschnecke fuer Salzwasser,
- ein Mehlwurm hingegen fuer Suesswasser. Gesetzt wird P_WATER hierfuer
- auf die oben aufgefuehrten Werte.
- Verwendung eines ungeeigneten Koeders fuehrt zu einer um 60+random(60)
- Sekunden laengeren Wartezeit beim Angeln.
-
- Wasserbehaelter:
- ****************
- Die Property gibt an, ob der Behaelter Wasser enthaelt oder nicht.
- Der Wert sollte immer auf den Typ jenes Gewaessers gesetzt sein, aus
- dem der Behaelter aufgefuellt wurde.
-
-
-SIEHE AUCH
-==========
-
- Properties: P_FISH
- Methoden: GetAquarium(L)
-
-Zuletzt geaendert: 2014-Aug-21, Arathorn
diff --git a/doc/sphinx/man/props/P_WC b/doc/sphinx/man/props/P_WC
deleted file mode 100644
index cfa18e4..0000000
--- a/doc/sphinx/man/props/P_WC
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_WC
-****
-
-
-NAME
-====
-
- P_WC "wc"
-
-
-DEFINIERT IN
-============
-
- /sys/weapon.h
-
-
-BESCHREIBUNG
-============
-
- Die Waffenklasse (engl: weapon class), also die Staerke der Waffe,
- stellt einen numerischen Wert dar, der umso groesser ist, desto mehr
- Schaden eine Waffe im Kampf anrichtet. Beim Zuecken oder Wegstecken
- einer Waffe durch ein Lebewesen wird innerhalb des Lebewesens auch
- die Property P_TOTAL_WC aktualisiert, welche somit immer die
- aktuelle Angriffsstaerke enthaelt. Beim Zuecken erhaelt sie hierbei
- die Waffenklasse der Waffe und beim Wegstecken die Angriffsstaerke
- aus der Property P_HANDS (Kaempfen mit blossen Haenden).
- Die Waffenklasse von einhaendigen Waffen sollte 150 nicht
- ueberschreiten, die Obergrenze fuer zweihaendige Waffen liegt bei
- 200. Ausnahmen von dieser Regel beduerfen der Absprache mit der
- Balance.
- Negative Werte bewirken keinen Schaden, allerdings auch keine
- Heilung.
-
-
-BEMERKUNGEN
-===========
-
- Query- und Setmethoden auf P_WC sollten unbedingt vermieden werden. Sie
- fuehren in der Regel zu massiven Inkonsistenzen im Mechanismus der
- Ruestungsbeschaedigung und -reparatur.
- Auch mit einer HitFunc() duerfen die Obergrenzen nicht ohne
- Absprache ueberschritten werden! Ausserdem ist es ratsam, die
- zusaetzlichen Kampfeigenschaften in P_EFFECTIVE_WC gesondert
- anzugeben.
-
-
-SIEHE AUCH
-==========
-
- /std/weapon.c, /std/weapon/combat.c
- P_DAMAGED, P_EFFECTIVE_WC, P_WEAPON_TYPE
- Damage()
-
-14.02.2017, Bugfix
diff --git a/doc/sphinx/man/props/P_WEAPON b/doc/sphinx/man/props/P_WEAPON
deleted file mode 100644
index a7f68b2..0000000
--- a/doc/sphinx/man/props/P_WEAPON
+++ /dev/null
@@ -1,31 +0,0 @@
-
-P_WEAPON
-********
-
-
-NAME
-====
-
- P_WEAPON "weapon"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Momentan gezueckte Waffe. Im Living gesetzt.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: P_ARMOURS
- Waffen: P_WC, P_WEAPON_TYPE, P_DAM_TYPE, P_NR_HANDS, P_PARRY
- Sonstiges: P_UNWIELD_TIME, P_EQUIP_TIME, P_LAST_USE
-
-10.Feb 2005 Gloinson
diff --git a/doc/sphinx/man/props/P_WEAPON_TEACHER b/doc/sphinx/man/props/P_WEAPON_TEACHER
deleted file mode 100644
index ebeb788..0000000
--- a/doc/sphinx/man/props/P_WEAPON_TEACHER
+++ /dev/null
@@ -1,29 +0,0 @@
-
-P_WEAPON_TEACHER
-****************
-
-
-NAME
-====
-
- P_WEAPON_TEACHER "weapon_teacher"
-
-
-DEFINIERT IN
-============
-
- combat.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property wird in einem Azubi gesetzt (zur Zeit nur fuer die
- Kaempfer-Gilde), der selbst ueber die allgemeinen Waffenskills
- verfuegt.
-
- In diese Property wird der Name eines Kaempfergilden-Ausbilders
- eingetragen.
-
- Unter Anleitung des Ausbilders lernt der Azubi dann etwas schneller
- die allgemeinen Waffenskills.
diff --git a/doc/sphinx/man/props/P_WEAPON_TYPE b/doc/sphinx/man/props/P_WEAPON_TYPE
deleted file mode 100644
index d200054..0000000
--- a/doc/sphinx/man/props/P_WEAPON_TYPE
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_WEAPON_TYPE
-*************
-
-
-NAME
-====
-
- P_WEAPON_TYPE "weapon_type"
-
-
-DEFINIERT IN
-============
-
- <weapon.h>
-
-
-BESCHREIBUNG
-============
-
- Um was fuer eine Waffe handelt es sich? Es stehen verschiedene
- Typen zur Auswahl. Man sollte hier nur die in <combat.h> definierten
- Konstanten verwenden:
-
- WT_AMMU Munition fuer Fernkampfwaffen
- WT_AXE Axt
- WT_CLUB Keule
- WT_HANDS blosse Haende
- WT_KNIFE Messer, Dolch
- WT_RANGED_WEAPON Fernkampfwaffe
- WT_SPEAR Speer
- WT_STAFF Kampfstab
- WT_SWORD Schwert
- WT_WHIP Peitsche
- WT_MISC Sonstiges
-
- Der Waffentyp WT_MISC ist schnoedem Tand und nutzlosem Kram vorbehalten.
- Waffen dieses Typs duerfen keine P_WC > 0 besitzen oder kampfrelevante
- Bedeutung haben.
-
-Letzte Aenderung: 27. Mai 2015, Arathorn.
diff --git a/doc/sphinx/man/props/P_WEAR_FUNC b/doc/sphinx/man/props/P_WEAR_FUNC
deleted file mode 100644
index d288187..0000000
--- a/doc/sphinx/man/props/P_WEAR_FUNC
+++ /dev/null
@@ -1,44 +0,0 @@
-
-P_WEAR_FUNC
-***********
-
-
-NAME
-====
-
- P_WEAR_FUNC "wear_func"
-
-
-DEFINIERT IN
-============
-
- <armour.h>
-
-
-BESCHREIBUNG
-============
-
- Falls ein Objekt eine WearFunc() fuer die Ruestung / Kleidung definiert,
- so muss dieses Objekt in dieser Property eingetragen sein.
-
- Die Auswertung dieser Property erfolgt in Laufe eines DoWear() in der
- nicht-oeffentlichen Funktion _check_wear_restrictions()..
-
-
-BEISPIELE
-=========
-
- Siehe das Beispiel zu WearFunc()
-
-
-SIEHE AUCH
-==========
-
- armours, clothing, /std/clothing/wear.c, /std/armour/wear.c
- WearFunc(), InformWear()
-
-
-LETZTE AeNDERUNG
-================
-
-15.02.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_WEAR_MSG b/doc/sphinx/man/props/P_WEAR_MSG
deleted file mode 100644
index 69fbf44..0000000
--- a/doc/sphinx/man/props/P_WEAR_MSG
+++ /dev/null
@@ -1,82 +0,0 @@
-
-P_WEAR_MSG
-**********
-
-
-NAME
-====
-
- P_WEAR_MSG "wear_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/armour.h
-
-
-BESCHREIBUNG
-============
-
- Zweiteiliges Array mit Meldungen, die beim Anziehen einer Ruestung oder
- Kleidung an den Spieler und die Umgebung ausgegeben werden.
- Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
- Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
- jedoch beruecksichtigt.
-
- Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
- man replace_personal()).
-
- [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
- moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
- in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
- den Waffennamen.]
-
-
-BEISPIELE
-=========
-
- SetProp(P_NAME, "Helm");
- SetProp(P_WEAR_MSG,
- ({"Du stuelpst die @WEN2 ueber.",
- "@WER1 stuelpt sich @WENU2 ueber."}));
-
- -> beim Anziehe durch Urk:
- Urk bekommt: Du stuelpst dir den Helm ueber.
- Der Raum: Urk stuelpt sich einen Helm ueber.
-
- SetProp(P_WEAR_MSG,
- ({"Als Du Dir den langen Mantel ueberziehst, steckst Du erstmal "
- "mit Deinem dicken Schaedel fest. Doch nach einem kraeftigen "
- "Ruck bist Du endlich durch und siehst wieder etwas.",
- "@WER1 zieht sich einen langen Mantel ueber und bleibt "
- "prompt mit dem dicken Schaedel stecken. Doch nach einem "
- "kraeftigen Ruck kann @WERQP1 wieder etwas sehen und grinst Dich "
- "verlegen an."}));
-
- -> beim Anziehen durch Urk:
- Urk bekommt: Als Du Dir den langen Mantel ueberziehst, steckst Du
- erstmal mit Deinem dicken Schaedel fest. Doch nach einem
- kraeftigen Ruck bist Du endlich durch und siehst wieder
- etwas.
-
- Der Raum: Urk zieht sich einen langen Mantel ueber und bleibt
- prompt mit dem dicken Schaedel stecken. Doch nach
- einem kraeftigen Ruck kann er wieder etwas sehen und
- grinst Dich verlegen an.
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
- P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
- Funktionen: WearFunc, UnwearFunc, InformWear()
- Sonstiges: replace_personal(E), clothing, /std/clothing/wear.c
- armour, /std/armour/wear.c
-
-
-LETZTE AeNDERUNG
-================
-
-15.02.2009
diff --git a/doc/sphinx/man/props/P_WEIGHT b/doc/sphinx/man/props/P_WEIGHT
deleted file mode 100644
index 4c37e46..0000000
--- a/doc/sphinx/man/props/P_WEIGHT
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_WEIGHT
-********
-
-
-NAME
-====
-
- P_WEIGHT "weight"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/restrictions.h
-
-
-BESCHREIBUNG
-============
-
- - Objekte
- Das Gewicht eines Objetes in Gramm.
-
- - Speisen
- Gewicht einer Portion der Speise.
-
-
-BEMERKUNGEN
-===========
-
- In tragbaren Speisen (erben von /std/food) setzt man mit SetProp
- das Gewicht _einer_ Portion. Per QueryProp erhaelt man aber das
- Gesamtgewicht der Speise inclusive des eventuell vorhandenen Behaelters.
- Das Gewicht des Behaelters wird dabei aus P_EMPTY_PROPS[P_WEIGHT]
- gelesen.
-
-
-SIEHE AUCH
-==========
-
- Speisen: wiz/food, P_EMPTY_PROPS
-
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
diff --git a/doc/sphinx/man/props/P_WEIGHT_PERCENT b/doc/sphinx/man/props/P_WEIGHT_PERCENT
deleted file mode 100644
index a4d0506..0000000
--- a/doc/sphinx/man/props/P_WEIGHT_PERCENT
+++ /dev/null
@@ -1,47 +0,0 @@
-
-P_WEIGHT_PERCENT
-****************
-
-
-NAME
-====
-
- P_WEIGHT_PERCENT "weight_percent"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property gibt an, wieviel Prozent des Gewichts des Inhaltes
- "nach aussen" wiedergegeben werden.
-
-
-BEMERKUNGEN
-===========
-
- Alle Werte die < 50% liegen sollten sehr gut begruendet und mit Vor-
- sicht verwendet werden. Hier koennten dann zum Beispiel P_MAX_OBJECTS
- auf einen kleinen Wert begrenzt werden.
-
- Container die hier einen Wert ueber dem des Postpakets haben, sollten
- auch schwer zu erreichen sein. Auf jeden Fall mit dem Regionsmagier
- besprechen!
-
-
-BEISPIELE
-=========
-
- Um sich zu orientieren kann das Postpaket von Loco als Beispiel hin-
- zugezogen werden (/p/service/loco/obj/parcel).
-
-
-SIEHE AUCH
-==========
-
- P_MAX_OBJECTS, P_MAX_WEIGHT, P_LIGHT_TRANSPARENCY, container
diff --git a/doc/sphinx/man/props/P_WEIGHT_PER_UNIT b/doc/sphinx/man/props/P_WEIGHT_PER_UNIT
deleted file mode 100644
index c777b65..0000000
--- a/doc/sphinx/man/props/P_WEIGHT_PER_UNIT
+++ /dev/null
@@ -1,29 +0,0 @@
-
-P_WEIGHT_PER_UNIT
-*****************
-
-
-NAME
-====
-
- P_WEIGHT_PER_UNIT "weight_per_unit"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Gewicht in Gramm pro Untereinheit.
-
-
-BEMERKUNGEN
-===========
-
- Deprecated. Bitte SetGramsPerUnits() (U_GPU) benutzen.
-
-25.Aug 2015 Gloinson
diff --git a/doc/sphinx/man/props/P_WIELDED b/doc/sphinx/man/props/P_WIELDED
deleted file mode 100644
index 26bcff7..0000000
--- a/doc/sphinx/man/props/P_WIELDED
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_WIELDED
-*********
-
-
-NAME
-====
-
- P_WIELDED "wielded"
-
-
-DEFINIERT IN
-============
-
- <weapon.h>
-
-
-BESCHREIBUNG
-============
-
- Ist diese Property gesetzt, dann ist die Waffe gerade gezueckt. Der
- Traeger ist in der Property vermerkt.
-
-
-BEMERKUNGEN
-===========
-
- Diese Property laesst sich nur abfragen!
-
-
-SIEHE AUCH
-==========
-
- /std/weapon.c
- P_WEAPON
-
-Last modified: 2015-Jul-11, Arathorn
diff --git a/doc/sphinx/man/props/P_WIELD_FUNC b/doc/sphinx/man/props/P_WIELD_FUNC
deleted file mode 100644
index fbe49a7..0000000
--- a/doc/sphinx/man/props/P_WIELD_FUNC
+++ /dev/null
@@ -1,38 +0,0 @@
-
-P_WIELD_FUNC
-************
-
-
-NAME
-====
-
- P_WIELD_FUNC "wield_func"
-
-
-DEFINIERT IN
-============
-
- <weapon.h>
-
-
-BESCHREIBUNG
-============
-
- Falls ein Objekt eine WieldFunc() fuer die Waffe definiert, so muss
- dieses Objekt in dieser Property eingetragen werden.
-
- Die Auswertung dieser Property erfolgt in wield_me().
-
-
-BEISPIELE
-=========
-
- Siehe das Beispiel zu WieldFunc()
-
-
-SIEHE AUCH
-==========
-
- /std/weapon.c, WieldFunc()
-
-Last modified: Sun May 19 15:40:02 1996 by Wargon
diff --git a/doc/sphinx/man/props/P_WIELD_MSG b/doc/sphinx/man/props/P_WIELD_MSG
deleted file mode 100644
index fa9dafc..0000000
--- a/doc/sphinx/man/props/P_WIELD_MSG
+++ /dev/null
@@ -1,74 +0,0 @@
-
-P_WIELD_MSG
-***********
-
-
-NAME
-====
-
- P_WIELD_MSG "wield_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/weapon.h
-
-
-BESCHREIBUNG
-============
-
- Zweiteiliges Array mit Meldungen, die beim Zuecken einer Waffe an den
- Spieler und die Umgebung ausgegeben werden.
- Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
- Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
- jedoch beruecksichtigt.
-
- Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
- man replace_personal()).
-
- [Wegen Abwaertskompatibilitaet ist auch noch der Platzhalter %s
- moeglich, wobei in der eigenen Meldung %s fuer den Waffennamen steht,
- in der an den Raum das erste %s fuer den Spielernamen, das zweite fuer
- den Waffennamen.]
-
-
-BEISPIELE
-=========
-
- SetProp(P_NAME, "Streitkolben");
- SetProp(P_WIELD_MSG,
- ({"Du zueckst @WEN2 und stoesst einen markerschuetternden Schrei aus.",
- "@WER1 zueckt @WENU2 und stoesst einen markerschuetternden Schrei "
- "aus." }));
-
- -> beim Zuecken durch Urk:
- Urk bekommt: Du zueckst den Streitkolben und stoesst einen
- markerschuetternden Schrei aus.
- Der Raum: Urk zueckt einen Streitkolben und stoesst einen
- markerschuetternden Schrei aus.
-
- SetProp(P_WIELD_MSG,
- ({"Du zueckst den klobigen Streitkolben und fuchtelst damit "
- "wild vor Deiner Nase herum.",
- "@WER1 zueckt einen klobigen Streitkolben und fuchtelt "
- "damit wild vor der eigenen Nase herum. Hoffentlich verletzt "
- "@WERQP1 sich dabei nicht ..."}));
-
- -> beim Zuecken durch Urk:
- Urk bekommt: Du zueckst den klobigen Streitkolben und fuchtelst
- damit wild vor Deiner Nase herum.
- Der Raum: Urk zueckt einen klobigen Streitkolben und fuchtelt
- damit wild vor der eigenen Nase herum. Hoffentlich
- verletzt er sich dabei nicht ...
-
-
-SIEHE AUCH
-==========
-
- Aehnliches: P_UNWIELD_MSG, P_WEAR_MSG, P_UNWEAR_MSG
- P_DROP_MSG, P_PUT_MSG, P_GIVE_MSG, P_PICK_MSG
- Funktionen: UnwieldFunc, WieldFunc
- Sonstiges: replace_personal(E), /std/weapon/combat.c
-
-29. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/props/P_WIMPY b/doc/sphinx/man/props/P_WIMPY
deleted file mode 100644
index d0ba078..0000000
--- a/doc/sphinx/man/props/P_WIMPY
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_WIMPY
-*******
-
-
-NAME
-====
-
- P_WIMPY "wimpy"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Numerischer Wert. Das Lebewesen flieht, wenn die Lebenspunkte
- unter diesen Wert sinken.
-
-
-SIEHE AUCH
-==========
-
- P_WIMPY_DIRECTION
-
-Letzte Aenderung: Mon Feb 12 17:50:47 2001 von Tilly
diff --git a/doc/sphinx/man/props/P_WIMPY_DIRECTION b/doc/sphinx/man/props/P_WIMPY_DIRECTION
deleted file mode 100644
index 11bedeb..0000000
--- a/doc/sphinx/man/props/P_WIMPY_DIRECTION
+++ /dev/null
@@ -1,40 +0,0 @@
-
-P_WIMPY_DIRECTION
-*****************
-
-
-NAME
-====
-
- P_WIMPY_DIRECTION "wimpy_dir"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Fluchtrichtung eines Spielers oder NPCs
-
-
-BEMERKUNGEN
-===========
-
- Die Fluchtrichtung kann nicht nur ein Ausgang (sueden, osten, ...)
- sein, sondern auch ein Kommando, welches der Spieler beim Anschlagen
- ausfuehrt (z.b. <kletter seil hoch> oder <rufe Elender Mist!>).
-
- Ausgefuehrt wird die Fluchtrichtung per command(), wenn die LP des
- Lebewesens unter die mit <vorsicht> angegebe LP-Grenze sinkt.
-
-
-SIEHE AUCH
-==========
-
- P_WIMPY
-
-Letzte Aenderung: Mon Feb 12 17:46:47 2001 von Tilly
diff --git a/doc/sphinx/man/props/P_WIZ_DEBUG b/doc/sphinx/man/props/P_WIZ_DEBUG
deleted file mode 100644
index 0bea2ad..0000000
--- a/doc/sphinx/man/props/P_WIZ_DEBUG
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_WIZ_DEBUG
-***********
-
-
-NAME
-====
-
- P_WIZ_DEBUG "std_p_wizdebug"
-
-
-DEFINIERT IN
-============
-
- /sys/player/comm.h
-
-
-BESCHREIBUNG
-============
-
- Gesetzt, wenn der Magier (oder ein Testspieler) Debugmeldungen wahrnehmen
- moechte.
- Debugmeldungen sind Nachrichten, die mit dem Typ MT_DEBUG an ReceiveMsg()
- uebergeben werden.
-
-
-
- Die Werte von P_WIZ_DEBUG sind zur Zeit 0 oder 1, das kann sich aber
- jederzeit aendern.
- Magier aendern diese Prop bitte ueber "mschau".
-
-
-SIEHE AUCH
-==========
-
- mschau
- P_WANTS_TO_LEARN
diff --git a/doc/sphinx/man/props/P_WORN b/doc/sphinx/man/props/P_WORN
deleted file mode 100644
index 999ab76..0000000
--- a/doc/sphinx/man/props/P_WORN
+++ /dev/null
@@ -1,63 +0,0 @@
-
-P_WORN
-******
-
-
-NAME
-====
-
- P_WORN "worn"
-
-
-DEFINIERT IN
-============
-
- <armour.h>
-
-
-BESCHREIBUNG
-============
-
- Mittels dieser Property laesst sich ermitteln, ob eine Ruestung bzw.
- Kleidung derzeit getragen wird und wenn ja, von wem.
-
- Entweder enthaelt die Property den Wert 0, oder sie enthaelt den
- Traeger der Ruestung / Kleidung (als Objekt).
-
-
-BEMERKUNGEN
-===========
-
- Diese Property laesst sich nur abfragen!
-
-
-BEISPIELE
-=========
-
- Eine DefendFunc() koennte dem Traeger der Ruestung wie folgt etwas
- mitteilen:
-
- // Die Ruestung gibt Schutz gegen Feuer
- int DefendFunc(string *dtyp, mixed spell, object enemy)
- {
- if (member(dtyp, DT_FIRE) != -1) {
- // P_WORN ist auf jeden Fall gesetzt, da sonst die
- // DefendFunc ueberhaupt nicht aufgerufen wuerde!
- tell_object(QueryProp(P_WORN),
- "Die Flammen zuengeln nur leicht ueber die Ruestung.\n");
- return 10;
- }
- return 0;
- }
-
-
-SIEHE AUCH
-==========
-
- clothing, /std/clothing.c, armour, /std/armour.c
-
-
-LETZTE AeNDERUNG
-================
-
-15.02.2009, Zesstra
diff --git a/doc/sphinx/man/props/P_XP b/doc/sphinx/man/props/P_XP
deleted file mode 100644
index 649f4e0..0000000
--- a/doc/sphinx/man/props/P_XP
+++ /dev/null
@@ -1,81 +0,0 @@
-
-P_XP
-****
-
-
-NAME
-====
-
- P_XP "xp"
-
-
-DEFINIERT IN
-============
-
- /sys/living/life.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt die Anzahl der Erfahrungspunkte, die ein
- Lebewesen erreicht hat. Dies geschieht insbesondere durch
- Kampfhandlungen, wobei es sowohl fuer Einzelschlaege als auch fuer
- das Toeten eines Opfers Punkte gibt.
-
- Bei einzelnen Schlaegen ist die Vergabe von Erfahrungspunkten davon
- abhaengig, wie stark man das Opfer getroffen hat, und welche
- Gesamtwaffenklasse es hat (damage*P_TOTAL_WC/10).
-
- Beim Todesschlag erhaelt man zusaetzlich die Erfahrungspunkte des
- Opfers geteilt durch 100 (P_XP/100). Dieser Wert wird allerdings
- gegebenenfalls auf ein Team aufgeteilt, sofern der Angreifer sich in
- einem solchigen befindet.
-
-
-BEISPIEL
-========
-
- NPC's gibt man im allgemeinen einen levelabhaengigen Sockelwert an
- Erfahrungspunkten mit, da sie nicht allzuoft selbst Gegner toeten
- und somit kaum die Moeglichkeit haben, diese Punkte selbst
- anzusammeln. Trotzdem sollen sie ja dem Spieler eine gewisse Anzahl
- an Erfahrungspunkten liefern, wenn sie getoetet werden:
-
- include "/sys/living/life.h"
- inherit "std/npc";
- void create() {
- ...
- SetProp(P_XP,25000000);
- }
-
- Beim Toeten gibt es nun 25.000.000/100 = 250.000 Erfahrungspunkte.
- Damit wird der NPC sogar automatisch fuer die Vergabe von
- Erstkillstufenpunkten vorgesehen.
-
- Die Funktion create_default_npc() setzt P_XP und andere Eigenschaften
- auf geeignete Werte.
-
-
-BEMERKUNGEN
-===========
-
- Die Vergabe von Erstkillstufenpunkten kann man ueber die Property
- P_NO_SCORE unterbinden, die Vergabe von Erfahrungspunkten ueber
- P_NO_XP. Automatisch werden Lebewesen fuer Erstkillstufenpunkte
- vorgesehen, sofern sie eine der folgenden Grenzen ueberschritten
- haben:
- SCORE_LOW_MARK: 200000 (1 Stufenpunkt)
- SCORE_HIGH_MARK: 600000 (2 Stufenpunkte)
- Definiert sind die Konstanten in "/secure/scoremaster.h".
-
-
-SIEHE AUCH
-==========
-
- Funktionen: AddExp(), do_damage()
- Verwandt: P_NO_XP, P_LAST_XP
- Sonstiges: P_NO_SCORE, create_default_npc()
- P_TOTAL_WC
-
-14.Feb 2007 Gloinson
diff --git a/doc/sphinx/man/props/P_X_ATTR_MOD b/doc/sphinx/man/props/P_X_ATTR_MOD
deleted file mode 100644
index 14ab9a4..0000000
--- a/doc/sphinx/man/props/P_X_ATTR_MOD
+++ /dev/null
@@ -1,68 +0,0 @@
-
-P_X_ATTR_MOD
-************
-
-
-NAME
-====
-
- P_X_ATTR_MOD "extern_attributes_modifier"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- Mapping, das die Attribute des Spielers veraendert, der das Objekt bei
- sich hat.
-
- Zu beachten:
- Diese Property bitte _ausschliesslich_ mit SetProp aendern, weil damit
- gleichzeitig UpdateAttributes() im Lebewesen aufgerufen und ggf. das
- Objekt als Statmodifizierer registriert wird.
-
- Diese Property ist fuer Krankheiten, Flueche etc. gedacht. Bei
- Waffen/Ruestungen, die die Attribute beeinflussen sollen, verwendet
- man besser P_M_ATTR_MOD.
-
- P_X_ATTR_MOD und P_M_ATTR_MOD duerfen einen gemeinsamen kumulierten
- positiven Grenzwert nicht ueberschreiten. Dieser Grenzwert,
- CUMULATIVE_ATTR_LIMIT, ist in /sys/living/attributes.h definiert.
-
-
-BEMERKUNGEN
-===========
-
- Die Methode /std/thing/restrictions::_set_extern_attributes_modifier()
- benachrichtigt tragende Livings ueber Aenderungen.
- Bitte beim "Loeschen" der Prop nicht den Wert des jew. Attributes im
- uebergebenen Mapping als 0 uebergeben, sondern das Key/Werte-Paar ganz
- entfernen und bzw. ein leeres Mapping oder 0 uebergeben.
-
-
-BEISPIEL
-========
-
- // Dem Lebewesen, das das Objekt bei sich hat, wird 2 von A_INT abgezogen
- SetProp(P_X_ATTR_MOD,([A_INT:-2]));
-
- // Stats wiederherstellen:
- SetProp(P_X_ATTR_MOD,([]));
-
-
-SIEHE AUCH
-==========
-
- QueryAttribute(), QueryRealAttribute(), QueryAttributeOffset(),
- SetAttribute(), SetRealAttribute(), UpdateAttributes(),
- SetTimedAttrModifier(), QueryTimedAttrModifier(),
- DeleteTimedAttrModifier(),
- P_X_HEALTH_MOD, P_M_HEALTH_MOD, P_ATTRIBUTES, P_ATTRIBUTES_OFFSETS,
- P_TIMED_ATTR_MOD, P_M_ATTR_MOD, P_M_ATTR_MOD, /std/living/attributes.c
-
-02.02.2016, Gloinson
diff --git a/doc/sphinx/man/props/P_X_HEALTH_MOD b/doc/sphinx/man/props/P_X_HEALTH_MOD
deleted file mode 100644
index 69aafab..0000000
--- a/doc/sphinx/man/props/P_X_HEALTH_MOD
+++ /dev/null
@@ -1,60 +0,0 @@
-
-P_X_HEALTH_MOD
-**************
-
-
-NAME
-====
-
- P_X_HEALTH_MOD "extern_health_modifier"
-
-
-DEFINIERT IN
-============
-
- /sys/living/attributes.h
-
-
-BESCHREIBUNG
-============
-
- Mapping, mit dem die maximalen Lebenspunkte und Magiepunkte eines
- Spielers veraendert werden, der dieses Objekt bei sich traegt.
-
- Zu beachten: Diese Property bitte _ausschliesslich_ mit SetProp
- aendern, weil damit gleichzeitig UpdateAttributes() im
- Lebewesen aufgerufen und ggf. das Objekt als Statmodifizierer
- registriert wird.
-
- Bei Ruestungen/Waffen, die diese Wirkung entfalten sollen, verwendet
- man besser P_M_HEALTH_MOD.
-
-
-BEMERKUNGEN
-===========
-
- Bitte bei "Loeschen" der Prop nicht den Wert des jew. Attributes im
- uebergebenen Mapping als 0 uebergeben, sondern das Key/Werte-Paar ganz
- entfernen und ggf. ein leeres Mapping oder 0 uebergeben.
-
-
-BEISPIEL
-========
-
- // Dem Spieler, der das Objekt bei sich traegt, wird P_MAX_HP um 5
- // erhoeht und P_MAX_SP um 5 erniedrigt.
- SetProp(P_X_HEALTH_MOD,([P_HP:5,P_SP:-5]));
- // Stats wiederherstellen:
- SetProp(P_X_HEALTH_MOD,([]);
-
-
-SIEHE AUCH
-==========
-
- P_M_HEALTH_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, balance
-
-
-LETZTE AeNDERUNG
-================
-
- Sat, 06.02.1999, 14:00:00 von Paracelsus
diff --git a/doc/sphinx/man/props/P_ZAP_MSG b/doc/sphinx/man/props/P_ZAP_MSG
deleted file mode 100644
index 6f9c7ce..0000000
--- a/doc/sphinx/man/props/P_ZAP_MSG
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_ZAP_MSG
-*********
-
-
-NAME
-====
-
- P_ZAP_MSG "zap_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Die Property enthaelt ein dreielementiges Array mit den folgenden
- Eintraegen:
- 1.) Meldung, die der Magier beim Zappen bekommt.
- 2.) Meldung, die die Spieler im Raum beim Zappen bekommen.
- 3.) Meldung, die das Opfer beim Zappen bekommt.
-
- Mit @@wer@@, @@wessen@@, ... kann der Name des Opfers und mit @@ich@@
- der Name des Magiers in die Meldung eingewoben werden.
-
- Die Property ist in Magiern gesetzt und gilt nur dort.
-
-
-SIEHE AUCH
-==========
-
- Tod: die(L)
- Todesmeldungen: P_KILL_NAME, P_KILL_MSG, P_DIE_MSG, P_MURDER_MSG
- P_ENEMY_DEATH_SEQUENCE
- Sonstiges: P_CORPSE, P_NOCORPSE, /room/death/death_room.c
-
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
diff --git a/doc/sphinx/man/props/U_REQ b/doc/sphinx/man/props/U_REQ
deleted file mode 100644
index 1594c4f..0000000
--- a/doc/sphinx/man/props/U_REQ
+++ /dev/null
@@ -1,83 +0,0 @@
-
-U_REQ
-*****
-
-
-NAME
-====
-
- U_REQ "u_req"
-
-
-DEFINIERT IN
-============
-
- /sys/unit.h
-
-
-BESCHREIBUNG
-============
-
- Die Prop kann in Unitobjekten gesetzt werden.
- Sie gibt die Anzahl der Einheiten an, die an der Unit manipuliert werden
- sollen, falls mit weniger als P_AMOUNT umgegegangen werden soll.
-
-
-
- Die Prop wird automatisch gesetzt, wenn id() an einem Unitobjekt gerufen
- wird und die ID grundsaetzlich zutreffend ist, die aus der ID ermittelte
- Zahl aber kleiner als P_AMOUNT ist.
- Sie kann auch manuell mittel SetProp() (aber nicht Set()) gesetzt werden.
-
- U_REQ wird beim Bewegen und Zerstoeren, bei Ermittlung von Wert und
- Gewicht beruecksichtigt.
-
- U_REQ wird vom Unitobjekt automatisch wieder auf P_AMOUNT gesetzt, wenn
- sich query_verb() oder debug_info(DINFO_EVAL_NUMBER) veraendert haben.
- (DINFO_EVAL_NUMBER ist eine Zahl, die sich jedesmal erhoeht, wenn der
- Driver eine neue Berechnung/Ausfuehrung beginnt. Diese Nummer wird fuer
- jeden vom driver initiierten Aufruf von LPC-Code erhoeht, z.B. bei jedem
- Kommando, call_out, heart_beat etc. Details s. debug_info().)
-
- Ebenso wird U_REQ bei der Vereinigung mit einem anderen (gleichen)
- Objekt auf P_AMOUNT des vereinigten Objektes gesetzt.
-
-
-BUGS
-====
-
- Viele. Dies ist ein uebler Hack. Geht aber nicht ohne.
- Diese Prop war endlos lang gar nicht dokumentiert. Hier beschrieben ist
- das Verhalten, was zur Zeit vorliegt. Dies mag unterschiedlich zu dem
- irgendwann intendierten sein.
-
-
-BEISPIELE
-=========
-
- object o = clone_object("unitobjekt");
- o->SetProp(P_AMOUNT, 100); // ab jetzt hat o 100 Einheiten.
- o->move(npc, M_GET); // ob mit 100 Einheiten wird bewegt
- o->SetProp(U_REQ, 50);
- o->move(anderernpc, M_GIVE); // 50 Einheiten werden bewegt, 50 verbleiben
- (Technisch: das Objekt wird auf 50 Einheiten geaendert, bewegt und in der
- alten Umgebung wird ein neues Objekt mit 50 Einheiten erzeugt.)
-
- o->SetProp(U_REQ, 42);
- o->remove(1); // 42 Einheiten von den 50 werden zerstoert.
- (Technisch: P_AMOUNT wird einfach um U_REQ reduziert.)
-
- # gib 18 muenzen an blupp
- Hierbei wird ob->id("18 muenzen") gerufen, was U_REQ im Geldobjekt auf 18
- setzt. Bei der Bewegung bekommt blupp daher das Objekt mit P_AMOUNT==18
- und der Rest wird im Abgebenden neu erzeugt.
- # gib geld an flubbel
- Das U_REQ aus dem verherigen Kommando ist jetzt nicht mehr gueltig. Zwar
- ist es das gleiche Kommandoverb, aber DINFO_EVAL_NUMBER ist jetzt
- anders.
-
-
-ZULETZT GEAeNDERT
-=================
-
-16.01.2015, Zesstra
diff --git a/doc/sphinx/man/props/gildenprops/P_GLOVE_FINGERLESS b/doc/sphinx/man/props/gildenprops/P_GLOVE_FINGERLESS
deleted file mode 100644
index 0485c9a..0000000
--- a/doc/sphinx/man/props/gildenprops/P_GLOVE_FINGERLESS
+++ /dev/null
@@ -1,30 +0,0 @@
-
-P_GLOVE_FINGERLESS
-******************
-
-
-NAME
-====
-
- P_GLOVE_FINGERLESS "fingerfreie_handschuhe"
-
-
-DEFINIERT IN
-============
-
- /p/katzenkrieger/kkrieger.h
-
-
-BESCHREIBUNG
-============
-
- So gekennzeichnete Handschuhe sind fingerlos und koennen
- waehrend "krallenschlag" getragen werden.
-
-
-SIEHE AUCH
-==========
-
- Verwandt: P_ARMOUR_TYPE, AT_GLOVE
-
-10.Okt 2006 Gloinson
diff --git a/doc/sphinx/man/props/gildenprops/P_Z_AUTOSHIELD b/doc/sphinx/man/props/gildenprops/P_Z_AUTOSHIELD
deleted file mode 100644
index 994abad..0000000
--- a/doc/sphinx/man/props/gildenprops/P_Z_AUTOSHIELD
+++ /dev/null
@@ -1,43 +0,0 @@
-
-P_Z_AUTOSHIELD
-**************
-
-
-NAME
-====
-
- P_Z_AUTOSHIELD "z_autoshield"
-
-
-DEFINIERT IN
-============
-
- /p/zauberer/wiznpc.h
-
-
-BESCHREIBUNG
-============
-
- Mit dieser Property kann man einen automatischen
- Schutzzauber in Zauberer-NPCs einstellen, dessen
- Vorhandensein dann in jeder Kampfrunde ueberprueft
- wird, z.B. "schutz","schutzhuelle","zauberschild".
-
-
-BEMERKUNGEN
-===========
-
- "zauberschild" ist ein Magisterspruch und kann nur in
- bestimmten Zeitabstaenden benutzt werden. Wer also als
- Autoshield nur Zauberschild benutzt, blockiert damit
- alle anderen Spells, solange der Magisterspruch nicht
- gesprochen werden kann.
- Abhilfe: _query_next_master_spell_time() return 0; }
-
-
-SIEHE AUCH
-==========
-
- /p/zauberer/text/wiznpc.doku
-
-21.Okt 2006 Chagall
diff --git a/doc/sphinx/man/props/gildenprops/P_Z_INFO b/doc/sphinx/man/props/gildenprops/P_Z_INFO
deleted file mode 100644
index 654c768..0000000
--- a/doc/sphinx/man/props/gildenprops/P_Z_INFO
+++ /dev/null
@@ -1,73 +0,0 @@
-
-P_Z_INFO
-********
-
-
-NAME
-====
-
- P_Z_INFO "z_info"
-
-
-DEFINIERT IN
-============
-
- /p/zauberer/wiznpc.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property muss gesetzt werden, wenn man den
- Zauberergilden-Standard-NPC nutzt. Sie setzt die
- Grundeinstellungen des NPCs und generiert das
- Newskills-Mapping.
-
- Die Property ist wie folgt aufgebaut:
-
- * MIN (minimale Skillability im Bereich von 0 - 10000)
- * MAX (maximale Skillability im Bereich von 0 - 10000)
- * LEV (Gildenlevel)
- * ZWEIG (Gildenzweig)
-
-
-BEMERKUNGEN
-===========
-
- Fuer die Argumente LEV und ZWEIG stehen folgende Auswahl-
- moeglichkeiten zur Verfuegung.
-
- LEV:
-
- Z_ANFAENGER 0
- Z_LEHRLING 1
- Z_MEISTER 2
- Z_ERZMEISTER 3
-
- ZWEIG:
-
- ZZW_ANGRIFF 1
- ZZW_ABWEHR 2
- ZZW_ILLUSION 4
- ZZW_BEHERRSCHUNG 8
- ZZW_HELLSICHT 16
- ZZW_VERWANDLUNG 32
- ZZW_SCHWARZ 64 INAKTIV
- ZZW_WEISS 128
- ZZW_ALLE 511
-
-
-BEISPIEL
-========
-
- SetProp(P_Z_INFO, ({9000, 9500, Z_ERZMEISTER, ZZW_ANGRIFF|ZZW_ABWEHR}));
- erzeugt einen Erzmagister-PC, der alle Lehrlings- sowie die Magister und
- Erzmagister-Sprueche Angriff und Abwehr mit 90-95% beherrscht.
-
-
-SIEHE AUCH
-==========
-
- /p/zauberer/text/wiznpc.doku
-
-21.Okt 2006 Chagall
diff --git a/doc/sphinx/man/props/gildenprops/P_Z_NO_MATERIAL b/doc/sphinx/man/props/gildenprops/P_Z_NO_MATERIAL
deleted file mode 100644
index cda514a..0000000
--- a/doc/sphinx/man/props/gildenprops/P_Z_NO_MATERIAL
+++ /dev/null
@@ -1,34 +0,0 @@
-
-P_Z_NO_MATERIAL
-***************
-
-
-NAME
-====
-
- P_Z_NO_MATERIAL "npc_braucht_keine_kmp"
-
-
-DEFINIERT IN
-============
-
- /p/zauberer/zauberer.h
-
-
-BESCHREIBUNG
-============
-
- Setzt man diese Property in einem NPC, so benoetigt er fuer die
- Sprueche der Zauberergilde keine Komponenten.
-
-
-BEMERKUNGEN
-===========
-
- NIEMALS diese Property einfach so in einem Spieler setzen.
-
-
-SIEHE AUCH
-==========
-
-21.Okt 2006 Chagall
diff --git a/doc/sphinx/man/props/gildenprops/P_Z_NO_NOCONN b/doc/sphinx/man/props/gildenprops/P_Z_NO_NOCONN
deleted file mode 100644
index 6cd0024..0000000
--- a/doc/sphinx/man/props/gildenprops/P_Z_NO_NOCONN
+++ /dev/null
@@ -1,42 +0,0 @@
-
-P_Z_NO_NOCONN
-*************
-
-
-P_Z_NO_NOCON
-============
-
-
-NAME
-====
-
- P_Z_NO_NOCON "no_nocon"
-
-
-DEFINIERT IN
-============
-
- /p/zauberer/wiznpc.h
-
-
-BESCHREIBUNG
-============
-
- Der Standardzauberergildennpc setzt SI_NO_CONSEQUENCES, damit
- die Gildenpcs nicht den negativen Auswirkungen beim Misslingen
- der Sprueche geschuetzt sind. Setzt man diese Property vor
- P_Z_INFO auf 0, wird das Flag nicht gesetzt.
-
-
-BEMERKUNGEN
-===========
-
- Muss vor P_Z_INFO gesetzt werden, damit es wirksam ist.
-
-
-SIEHE AUCH
-==========
-
- /p/zauberer/text/wiznpc.doku, P_Z_INFO
-
-21.Okt 2006 Chagall
diff --git a/doc/sphinx/man/props/gildenprops/P_Z_NO_SPELL_SUPPORT b/doc/sphinx/man/props/gildenprops/P_Z_NO_SPELL_SUPPORT
deleted file mode 100644
index 74860f6..0000000
--- a/doc/sphinx/man/props/gildenprops/P_Z_NO_SPELL_SUPPORT
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_Z_NO_SPELL_SUPPORT
-********************
-
-
-NAME
-====
-
- P_Z_NO_SPELL_SUPPORT "zauberer_ruestung_unterstuetzt_noch_nicht"
-
-
-DEFINIERT IN
-============
-
- /p/zauberer/zauberer.h
-
-
-BESCHREIBUNG
-============
-
- Normalerweise unterstuetzt eine Ruestung den Zauberer, sobald sie im
- entsprechenden Ruestungsmaster eingetragen ist. Moechte man allerdings
- die Unterstuetzung an bestimmte Bedingungen knuepfen, z.B. das loesen
- einer Miniquest, so kann man diese Property auf 1 setzen. Die Ruestung
- unterstuetzt dann nicht. Um die Unterstuetzung wieder zu aktivieren,
- setzt man die Property wieder auf 0.
-
-
-BEMERKUNGEN
-===========
-
- NIEMALS diese Property einfach so in fremden Zaubererruestungen
- setzen. Sollte der Gildenmagier erfahren, dass z.B. ein NPC
- einfach so die Unterstuetzung der Ruestungen ausschaltet, wird
- diese Property wieder deaktiviert.
-
-
-SIEHE AUCH
-==========
-
-21.Okt 2006 Chagall
diff --git a/doc/sphinx/man/props/gildenprops/kaempferboni b/doc/sphinx/man/props/gildenprops/kaempferboni
deleted file mode 100644
index 0d34e98..0000000
--- a/doc/sphinx/man/props/gildenprops/kaempferboni
+++ /dev/null
@@ -1,270 +0,0 @@
-
-kaempferboni
-************
-
-Kaempferboni und deren Implementation
-
-======================================================================
-
-Bei den Kaempfern gibt es einige Properties, die, in Waffen oder
-Ruestungen gesetzt, der Kampfverlauf eines Spielers erheblich
-beeinflussen koennen.
-
-Zu beachten ist, dass die Abnahme von Waffen oder Ruestungen mit
-Kaempferboni allein der Balance obliegt. Der Gildenmagier der Kaempfer
-steht aber gerne mit Rat und Tat zur Seite.
-
-Abschnitt A
-
-In Waffen koennen nachfolgende, in /p/kaempfer/kaempfer.h definierten,
-Properties gesetzt werden. Die meisten davon fungieren als 'Boni' und
-werden dem Spieler auch mittels 'schaetz <waffe>' angezeigt
-
-1 Waffenschlagbonus - K_BRAWLING_WC (INT) - "k_brawling_wc"
-
- Wenn die Waffe eine zusaetzlich gefaehrliche Stelle besitzt - z.B.
- einen harten Dorn am Stielende, eine Spitze am Ruecken einer
- Axtklinge, Zacken am Dolchgriff - kann man der Waffe einen
- Waffenschlagbonus geben. Dies bedeutet, dass der Waffenschlag um
- ein paar Prozente verstaerkt wird, da der Spieler natuerlich
- versucht, immer genau mit diesem 'feature' den Waffenschlag
- auszufuehren (der Waffenschlag ist kurz gesagt ein unerwarteter
- Schlag, der nicht mit dem 'normalen' Waffenende ausgefuehrt wird,
- der Gegner wird dadurch ueberrascht -> mehr Schaden). Da solch ein
- 'feature' doch recht auffaellig ist, sollte es in der
- Langbeschreibung der Waffe auf jeden Fall erwaehnt werden.
-
- Interessant zu wissen waere noch, dass Zweihandwaffen einen
- generellen zusaetzlichen Bonus auf den Waffenschlag bekommen und
- dass es eine Abstufung gibt, nach der die Waffengattungen die Hoehe
- des Basiswertes gesetzt bekommen, wobei Speere den hoechsten und
- Messer den niedrigsten besitzen
-
- Speere - Kampfstaebe - Aexte - Keulen - Schwerter - Messer
-
- Der max. Bonus fuer diese Property betraegt 30, wobei 1-10 ->
- geringer Bonus, 11-20 -> guter Bonus, 21-30 -> sehr guter Bonus.
-
- Bitte beachten ein Zweihand-Speer mit max. P_WC und max.
- K_BRAWLING_WC haut entsprechend gut rein und sollte nur schwer zu
- ergattern sein, bzw. noch andere Auflagen haben (ggf. unique,
- personalisiert, etc.)
-
-2 Waffenschlagschaden - K_BRAWLING_DT (STRING) - "k_brawling_dt"
-
- Wenn die Waffe, mit der der Kaempfer einen Waffenschlag ausfuehrt,
- ein 'feature' hat, mit dem er diesen Schlag ausfuehrt, kann dieses
- 'feature' einen anderen Waffenschlagschaden besitzen. Z.B. kann ein
- Schwert, welches normalerweise DT_SLASH macht, besonders lange und
- spitze Parierstangen besitzen, die vielleicht auch noch vergiftet
- sind. Dann kann der Magier ({DT_PIERCE,DT_POISON}) setzen, so dass
- beim Waffenschlag immer ein Mischschaden aus Stiche und Gift
- erfolgt.
-
-3 Waffenschlagsmeldung - K_BRAWLING_MSG (STRING/STRING*) -
-k_brawling_msg"
-
- In diese Property kann man hineinschreiben, mit welchem Teil der
- Waffe der Waffenschlag ausgefuehrt wird. Angenommen, es bietet sich
- an, mit einer Waffe stets den Waffenschlag mit einem grossen Knauf
- am Griff auszufuehren, wird schlicht und einfach "mit einem grossen
- Knauf am Griff der Schlachtaxt" in die Property gesetzt. Sollte
- sich bei der Programmierung ergeben, dass es sich anbietet, der
- Waffe mehr als nur eine guenstige Stelle anzudichten mit der man
- den Waffenschlag ausfuehren kann, so setzt man ein Array, z.B.
- ({"mit einem grossen Knauf am Griff der Schlachtaxt","mit der
- breiten Seite der " "Schlachtaxtklinge"}). Insgesamt ist darauf zu
- achten, dass die Meldungen 'vollstandig' sind. Das Array kann
- beliebige Groesse annehmen, es wird dann zufaellig eine Meldung
- beim Schlag ausgesucht.
-
- Es empfiehlt sich, jede Waffe mit dieser Property zu schmuecken,
- die K_BRAWLING_WC gesetzt haben, da die Waffenschlagmeldungen damit
- im Kampf 'individualisiert' werden. In der Praxis wird es jedoch
- daran scheitern, dass es viel zu viele alte Waffen gibt, die keiner
- mehr anfassen moechte. Daher wird auf Standardmeldungen
- zurueckgegriffen, sollte diese Property nicht gesetzt sein.
-
-4 Waffenbruchbonus - K_WEAPON_SHATTER (INT) - "k_weapon_shatter"
-
- Waffen, die besonders fuer den Waffenbruch konstruiert wurden,
- koennen einen Bonus einbringen, der in dieser Property angegeben
- wird. Natuerlich eignen sich die verschiedenen Waffentypen wieder
- unterschiedlich gut fuer einen Waffenbruch Keulen (meist aufgrund
- ihres Gewichts) am besten, Messer am schlechtesten, alle anderen
- dazwischen (Axt - Schwert - Stab - Speer). Dabei kriegen alle
- Waffen, die u.a. Schlagschaden verursachen, nochmal einen kleinen
- Bonus obendrauf.
-
- Der max. Bonus fuer diese Property betraegt 50, wobei 1-10 ->
- geringer Bonus, 11-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
-
- Bei gut gelungenem Waffenbruch wird die Waffe des Gegners
- beschaedigt, wenn die Technik sehr gut gelingt, kann es auch sein,
- dass dem Gegner die Waffe aus der Hand geschlagen wird (der Spieler
- kann sie allerdings nicht aufheben und der NPC zueckt sie nach ein
- paar Kampfrunden wieder).
-
-5 Bonus fuer Finte/Waffentrick - K_DISTRACTING_WEAPON (INT) -
- "k_distracting_weapon"
-
- Waffen, die fuer den Gegner aufgrund ihrer Bauweise besonders
- irritierend sein koennen, koennen einen Bonus fuer Finte und
- Waffentrick haben. Dabei wird der Gegner bei einer Finte bzw. einem
- Waffentrick NOCH mehr verwirrt, als er es ohnehin schon nur durch
- die angewandte Technik wird. Ein gutes Beispiel hierfuer ist z.B.
- der Kriegshamster ein Hamster, der auf einem Holzstab aufgespiesst
- ist, sollte fuer den Gegner schon SEHR irritierend sein ;). Die
- Waffengattung hat nur wenig Einfluss auf Finte/Waffentrick.
-
- Der max. Bonus fuer diese Property betraegt 50, wobei 1-10 ->
- geringer Bonus, 11-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
-
-6 Todesstossbonus - K_CRITICAL_HIT (INT) - "k_critical_hit"
-
- Man stelle sich eine Waffe mit besonders spitzer, langer Klinge vor
- oder eine magische Waffe, die dem geschwaechten Gegner die Seele
- entreisst. Diese Eigenschaften verleihen dem Spieler beim
- Todesstoss einen entsprechenden Bonus von bis zu 100%.
-
- Es ist moeglich, dass ein und dasselbe 'feature' sowohl dem
- Waffenschlag als auch dem Todesstoss den Bonus stellt, z.B. zwei
- Hiebklingen auf dem Klingenruecken einer grossen Axt. Auch dies
- sollte man deutlich aus der Langbeschreibung herauslesen koennen.
-
- Der max. Bonus fuer diese Property betraegt 100, wobei 100 eine
- Verdopplung der P_WC beim Todesstoss bedeutet! Ansonsten bedeutet
- 1-20 -> geringer Bonus, 21-60 -> guter Bonus, 61-100 -> sehr guter
- Bonus.
-
-7 Waffenwurfbonus - K_THROWING_WEAPON (INT) - "k_throwing_weapon"
-
- Wenn eine Waffe besonders gut zum Werfen geeignet ist, z.B. ein
- Wurfdolch, dann kann diese Property gesetzt werden. Natuerlich ist
- der Grundwert wieder von der Waffengattung abhaengig. Es gilt, dass
- man Messer und Speere grundsaetzlich am besten werfen - und dabei
- gut Schaden machen - kann, am schlechtesten schneiden Keulen und
- Kampfstaebe ab.
-
- Der max. Bonus fuer diese Property betraegt 50, wobei 1-20 ->
- geringer Bonus, 21-40 -> guter Bonus, 31-50 -> sehr guter Bonus.
-
- Zu beachten ist hierbei, dass ein sehr hoher Bonus nur bei Waffen
- mit etwas geringerer P_WC vergeben werden sollte. Ein reines
- Wurfmesser ist nunmal im normalen Kampf nicht die gefaehrlichste
- aller Waffen (speziell ausbalanciert, keinen richtigen Griff,
- etc.). Natuerlich kann es einen Wurfspeer mit max. P_WC und sehr
- hohem Waffenwurfbonus geben, allerdings mit den ueblich hohen
- Restriktionen.
-
-8 KO-Schlag-Bonus - K_KO (INT) - "k_ko"
-
- Waffen, die besonders fuer einen KO-Schlag geeignet sind, koennen
- einen Bonus mit dieser Property bekommen. Eine entsprechende Waffe
- koennte z.B. ein lederumwickelter Pruegel sein, denn man will den
- Gegner ja nur KO schlagen und nicht gleich toeten.
-
- Der max. Bonus fuer diese Property betraegt 50, wobei 1-20 ->
- geringer Bonus, 21-30 -> guter Bonus, 31-50 -> sehr guter Bonus.
-
-9 Kein Waffenschaerfen - K_NO_HONING (INT) - "k_no_honing"
-
- Wenn eine Waffe aus irgendeinem Grund nicht geschaerft werden kann
- oder darf, muss man diese Property auf 1 setzen. Eine Erklaerung
- dafuer sollte in der P_LONG bzw. P_INFO erfolgen.
-
-Abschnitt B
-
-Die beiden Properties, P_EFFECTIVE_AC und P_EFFECTIVE_WC, welche in
-<combat.h> definiert sind, sind eigentlich nur dazu da, um Ruestungen
-und Waffen, die eine DefendFunc() bzw. HitFunc() besitzen, korrekt vom
-Spieler einschaetzen lassen zu koennnen.
-
-Das Kaempferspellbook verwendet diese Properties darueberhinaus wie
-folgt
-
-1 Schutzboni in Waffen - P_EFFECTIVE_AC (INT) - "effective_ac"
-
- Ist diese Property in einer Waffe gesetzt, geht das
- Kaempferspellbook davon aus, dass diese Waffe mehr oder weniger die
- Faehigkeit besitzt, auch wie eine Ruestung schuetzen zu koennen. Da
- man eine Waffe aber nicht anziehen, sondern nur vor sich hertragen
- kann, kann auch der max. Ruestungsschutz einer Waffe nur gleich dem
- max. Ruestungsschutz eines Schildes entsprechen. Eine gesetzte
- P_EFFECTIVE_AC in einer Waffe wird dem Spieler als mehr oder
- weniger gute 'Paradewaffe' im 'schaetz' angezeigt und geht sowohl
- bei der Waffenparade als auch beim Block als Bonus mit ein.
-
- Z.B. koennte ein leichtes Schwert, was aufgrund seiner Bauweise
- mehr fuer den defensiven Kampf ausgelegt ist (extralange
- Parierstangen, verstaerkter Handschutz im Griffbereich, ...) wie
- ein maessiges Schild wirken. Die Vorteile liegen auf der Hand der
- Spieler bekommt verstaerkten Schutz, kann aber weiterhin eine
- Zweihandwaffe fuehren.
-
- Der max. Bonus fuer diese Property betraegt 40, wobei 1-20 ->
- geringer Bonus, 21-30 -> guter Bonus, 31-40 -> sehr guter Bonus.
-
- Zu beachten ist hier, dass sehr gute Parierwaffen mit
- P_EFFECTIVE_AC > 30 moeglichst deutlich unter der max. WC liegen
- sollten.
-
- Anmerkungen Eine gesetzte P_EFFECTIVE_AC in einem Schild kann den
- Bonus fuer die Schildparade nach oben oder unten beeinflussen.
- Moechte man ein Schild herstellen, welches speziell bei der
- Schildparade der Kaempfer besser als 'normal' schuetzt, sollte man
- hier einen Wert eintragen, der deutlich groesser als die P_AC des
- Schildes ist.
-
- Eine gesetzte P_EFFECTIVE_AC in einer anderen Ruestung hat nur den
- Nutzen, auf deren erhoehten (und nicht sofort sichtbaren)
- Verteidigungswert hinzuweisen, der durch eine DefendFunc()
- realisiert wird.
-
-2 Angriffsboni in Ruestungen - P_EFFECTIVE_WC (INT) - "effective_wc"
-
- Fuer die Kaempfer koennen folgende Ruestungstypen modifiziert
- werden AT_TROUSERS (Hosen), AT_HELMET (Kopfbedeckung), AT_BOOT
- (Fusskleidung), AT_ARMOUR (Koerperruestung), AT_SHIELD (Schilde).
- Ist in einer dieser Typen P_EFFECTIVE_WC gesetzt, so macht diese
- Ruestung bei einem Angriff mit einer Spezialattacke (Kniestoss,
- Kopfstoss, Fusstritt, Ellbogenschlag und Schildstoss) entsprechend
- mehr bzw. weniger Schaden als ohne diese Property. Eine
- entsprechende Begruendung fuer eine Verstaerkung oder Schwaechung
- sollte auch hier fuer den Spieler offensichtlich sein (Dornen am
- Schild, verstaerkter Kniebereich, Zacken am Helm, etc.).
-
- Wenn man der Ruestung einen Bonus geben moechte, muss man darauf
- achten, dass P_EFFECTIVE_WC hoeher ist als die P_AC der Ruestung!
- Sollte P_EFFECTIVE_WC niedriger als P_AC sein, wird dennoch
- P_EFFECTIVE_WC als Angriffswert genommen. Dies stellt natuerlich
- eine Schwaechung der Spezialattacke dar. Moeglicherweise ist aber
- genau das gewollt, wenn eine Ruestung, die sehr gut schuetzt, nur
- geringen Kaempferbonus aufweisen soll.
-
- Beispiel ein Schild aus Hartgummi kann recht gut Schlaege aller Art
- abfangen (-> P_AC 35). Will der Kaempfer jedoch einen Schildstoss
- damit machen, fehlt ihm aufgrund der Beschaffenheit die Wucht, eher
- daempft es den Schildstoss noch ein wenig (-> P_EFFECTIVE_WC 25).
-
- Der Maximalwert fuer die P_EFFECTIVE_WC bei Kaempfern ist der
- jeweils doppelte maximale P_AC-Wert (s. 'man ruestungen').
-
- Die Angabe eines Schadenstyps (P_DAM_TYPE) in einer Ruestung kann
- dann sinnvoll sein, wenn bei der Spezialattacke ein spezieller
- Schaden gemacht werden soll. Beispielsweise sollten Flammenstiefel
- logischerweise DT_FIRE und DT_BLUDGEON oder DT_PIERCE bei einem
- Kampftritt verursachen. Es MUSS (logischerweise) mindestens ein
- physikalischer Schadenstyp enthalten sein. Wird kein Schadenstyp
- angegeben, wird auf Standardtypen zurueckgegriffen.
-
-
-SIEHE AUCH
-==========
-
- Waffen: P_WC, P_TOTAL_WC, P_EFFECTIVE_WC, HitFunc()
- Ruestungen: P_AC, P_TOTAL_AC, P_EFFECTIVE_AC, DefendFunc()
- Files: /std/weapon.c, /std/weapon/combat.c
- Balance: waffen, ruestungen, properties
-
-26.10.2012, Gabylon
diff --git a/doc/sphinx/man/props/obsolete/P_BALANCED_WEAPON b/doc/sphinx/man/props/obsolete/P_BALANCED_WEAPON
deleted file mode 100644
index 83a2fc4..0000000
--- a/doc/sphinx/man/props/obsolete/P_BALANCED_WEAPON
+++ /dev/null
@@ -1,59 +0,0 @@
-
-P_BALANCED_WEAPON
-*****************
-
-********************* UNGENUTZTE PROPERTY
-***************************** * Diese Property wird von der Mudlib
-NICHT ausgewertet und kann * * als veraltet gelten.
-* * Momentan ist auch keine Gilde bekannt, die mehr macht, als sie
-* * auszugeben.
-* *******************************************************************
-****
-
-
-NAME
-====
-
- P_BALANCED_WEAPON "balanced_weapon"
-
-
-DEFINIERT IN
-============
-
- /sys/weapon.h
-
-
-BESCHREIBUNG
-============
-
- Die Property gibt an, ob eine Waffe ausbalanciert ist oder nicht.
- Die beiden moeglichen Werte sind logischerweise:
-
- WP_BALANCED balanciert
- WP_UNBALANCED unbalanciert
-
- Die WP_* sind ebenfalls in <weapon.h> definiert.
-
-
-BEISPIELE
-=========
-
- a) Eine ausbalancierte Waffe ist z.B. ein Kampfstab.
-
- SetProp(P_BALANCED_WEAPON,WP_BALANCED);
-
- b) Eine nicht ausbalancierte Waffe ist z.B. eine Keule.
-
- SetProp(P_BALANCED_WEAPON,WP_UNBALANCED);
-
-
-SIEHE AUCH
-==========
-
- P_TECHNIQUE, /std/weapon/combat.c
-
-
-LETZTE AeNDERUNG
-================
-
-15.02.2009, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_DEFAULT_INFO b/doc/sphinx/man/props/obsolete/P_DEFAULT_INFO
deleted file mode 100644
index 9a16169..0000000
--- a/doc/sphinx/man/props/obsolete/P_DEFAULT_INFO
+++ /dev/null
@@ -1,50 +0,0 @@
-
-P_DEFAULT_INFO
-**************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-nicht mehr in neuem Code nutzen. * **********************************
-*************************************
-
-
-NAME
-====
-
- P_DEFAULT_INFO "default_info"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Default-Antwort eines Npc, wenn er auf das Schluesselwort durch den
- Spieler kein AddInfo parat hat.
-
-
-BEMERKUNG
-=========
-
- Diese Property sollte nicht mehr benutzt werden. Stattdessen bitte
- AddInfo(DEFAULT_INFO,...) verwenden.
- Dem in dieser Prop angegeben String wird immer der Name des Npc
- vorausgestellt. Will man dies verhindern, muss man sie ueberschreiben.
-
-
-BEISPIEL
-========
-
- SetProp(P_DEFAULT_INFO,"bohrt gelangweilt in der Nase.\n");
-
-
-SIEHE AUCH
-==========
-
- AddInfo
-
-17.08.2010, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_EXTRA_LOOK b/doc/sphinx/man/props/obsolete/P_EXTRA_LOOK
deleted file mode 100644
index 203fb8e..0000000
--- a/doc/sphinx/man/props/obsolete/P_EXTRA_LOOK
+++ /dev/null
@@ -1,57 +0,0 @@
-
-P_EXTRA_LOOK
-************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-benutzt sie NICHT mehr, sondern * * stattdessden AddExtraLook().
-* *******************************************************************
-****
-
-
-NAME
-====
-
- P_EXTRA_LOOK "extralook"
-
-
-DEFINIERT IN
-============
-
- /sys/living/description.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property enthaelt einen String. Sie wird entweder in Lebewesen
- direkt oder in Objekten gesetzt wird, die im Besitz von Lebewesen
- sein koennen.
- Diese Strings erscheinen dann zusaetzlich in der Langbeschreibung
- des Lebewesens bzw. des Besitzers (wenn das Objekt sich direkt im
- Lebewesen befindet, jedoch nicht in einem Behaelter im Lebewesen).
- Fuer den Zeilenumbruch muss man selbst sorgen.
-
-
-BEISPIEL
-========
-
- Ein Spieler hat eine Pfeife im Mund. In dieser Pfeife setzt man z.B.
- in der Funktion zum Pfeife Rauchen folgendes:
- SetProp(P_EXTRA_LOOK,break_string(
- this_player()->Name(WER)+" ist ganz umnebelt.",78);
-
-
-BEMERKUNG
-=========
-
- BITTE NICHT MEHR BENUTZEN!
-
-
-SIEHE AUCH
-==========
-
- long(), /std/living/description.c, /std/player/base.c
- AddExtraLook(), RemoveExtraLook()
-
-13.05.2007, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_LAST_KILLER b/doc/sphinx/man/props/obsolete/P_LAST_KILLER
deleted file mode 100644
index 199a878..0000000
--- a/doc/sphinx/man/props/obsolete/P_LAST_KILLER
+++ /dev/null
@@ -1,37 +0,0 @@
-
-P_LAST_KILLER
-*************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet und wird
-bald aus der Mudlib entfernt. * ************************************
-***********************************
-
-
-NAME
-====
-
- P_LAST_KILLER "last_killer"
-
-
-DEFINIERT IN
-============
-
- /sys/player.h
-
-
-BESCHREIBUNG
-============
-
- Letzter Moerdes des Wesens.
- Diese Property wurde nur in Spielern gesetzt und auch dann nicht immer.
- Bitte stattdessen P_KILLER abfragen, welche in NPC und Spielern gesetzt
- wird.
-
-
-SIEHE AUCH
-==========
-
- P_KILLER, die()
-
-05.09.2008, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_LAST_PEACE_TIME b/doc/sphinx/man/props/obsolete/P_LAST_PEACE_TIME
deleted file mode 100644
index f8aea49..0000000
--- a/doc/sphinx/man/props/obsolete/P_LAST_PEACE_TIME
+++ /dev/null
@@ -1,41 +0,0 @@
-
-P_LAST_PEACE_TIME
-*****************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet und wird
-bald aus der Mudlib entfernt. * ************************************
-***********************************
-
-
-PROPERTY
-========
-
- P_LAST_PEACE_TIME "last_peace_time"
-
-
-DEFINIERT IN
-============
-
- /std/living/combat.c
-
-
-BESCHREIBUNG
-============
-
- Diese Property gibt an, wann zuletzt versucht wurde, einen NPC zu
- befrieden. Bitte nach Moeglichkeit nur lesend verwenden. Des weiteren
- wird sie nur im ueblichen Verhalten von QueryPacify gesetzt, und nur
- dann, wenn P_ACCEPT_PEACE nicht gesetzt ist.
-
-
-SIEHE AUCH
-==========
-
- QueryPacify, P_ACCEPT_PEACE
-
-
-LETZTE AENDERUNG
-================
-
- 2004-03-17, 14:30 von Humni
diff --git a/doc/sphinx/man/props/obsolete/P_LOG_FILE b/doc/sphinx/man/props/obsolete/P_LOG_FILE
deleted file mode 100644
index ed57133..0000000
--- a/doc/sphinx/man/props/obsolete/P_LOG_FILE
+++ /dev/null
@@ -1,69 +0,0 @@
-
-P_LOG_FILE
-**********
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property wird nicht mehr
-ausgewertet. * ******************************
-*****************************************
-
-
-NAME
-====
-
- P_LOG_FILE "log_file"
-
-
-DEFINIERT IN
-============
-
- /sys/thing/properties.h
-
-
-BESCHREIBUNG
-============
-
- Enthaelt einen String auf einen Filenamen.
-
- Werden zu dem Objekt (Raum, Monster, ...) Fehlermeldungen abgesetzt,
- werden diese in das angegebene File umgeleitet. Die Eintragung in
- die per Default fuer Fehlermeldungen vorgesehenen Dateien erfolgt
- nicht.
-
-
-BEMERKUNGEN
-===========
-
- P_LOG_FILE wird ausgewertet wie log_file().
-
- Das heisst, es wird AUF JEDEN FALL nach /log geschrieben!
-
- Direkt in /log kann NICHT geschrieben werden, es muss also ein
- Unterverzeichnis mit Eurem Magiernamen vorhanden sein.
-
-
-BEISPIELE
-=========
-
- SetProp(P_LOG_FILE,"tilly_log"); // FALSCH, es wuerde versucht,
- das File /log/tilly_log
- anzulegen
- SetProp(P_LOG_FILE,"/log/tilly_log"); // FALSCH, es wuerde versucht,
- das File /log/log/tilly_log
- anzulegen
- SetProp(P_LOG_FILE,"/d/ebene/tilly_log"); // FALSCH, s.o.
-
- SetProp(P_LOG_FILE,"tilly/tilly_log"); // RICHTIG!
-
- Im letzten Beispiel werden alle Eintraege in das File tilly_log ge-
- schrieben, das sich im Verzeichnis /log/tilly/ befindet.
-
- Das Unterverzeichnis /tilly in /log muss zuvor angelegt werden.
-
-
-SIEHE AUCH
-==========
-
- P_LOG_INFO, write_file(), log_file(),
-
-Letzte Aenderung: 13.09.04 Tilly@MorgenGrauen
diff --git a/doc/sphinx/man/props/obsolete/P_NEXT_SPELL_TIME b/doc/sphinx/man/props/obsolete/P_NEXT_SPELL_TIME
deleted file mode 100644
index 300a766..0000000
--- a/doc/sphinx/man/props/obsolete/P_NEXT_SPELL_TIME
+++ /dev/null
@@ -1,49 +0,0 @@
-
-P_NEXT_SPELL_TIME
-*****************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-nicht mehr in neuem Code nutzen. * **********************************
-*************************************
-
-
-NAME
-====
-
- P_NEXT_SPELL_TIME "next_spell"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Wann kann das naechste Mal gezaubert werden?
- Dies ist eine globale Spruchermuedung/-Sperre.
- Flexiblere Sperren koennen mittels SetSpellFatigue/CheckSpellFatigue()
- verwaltet werden.
-
- Diese Property ist keine echte Property, sondern liefert nur das
- Ergebnis von von CheckSpellFatigue() zurueck bzw. ruft beim Setzen
- SetSpellFatigue(<spruchsperre>, 0) auf.
- Diese Prop sollte _nicht_ mittels Query- oder Setmethoden manupuliert
- werden, da sonst Inkonsistenzen zum Ergebnis von CheckSpellFatigue()
- auftreten.
-
-
-SIEHE AUCH
-==========
-
- SetSpellFatigue(L), CheckSpellFatigue(L)
- spruchermuedung
-
-
-ZULETZT GEAeNDERT
-=================
-
-14.03.2010, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_READ_MSG b/doc/sphinx/man/props/obsolete/P_READ_MSG
deleted file mode 100644
index 2331508..0000000
--- a/doc/sphinx/man/props/obsolete/P_READ_MSG
+++ /dev/null
@@ -1,56 +0,0 @@
-
-P_READ_MSG
-**********
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-nicht mehr in neuem Code nutzen. * **********************************
-*************************************
-
-
-NAME
-====
-
- P_READ_MSG "read_msg"
-
-
-DEFINIERT IN
-============
-
- /sys/properties.h
-
-
-BESCHREIBUNG
-============
-
- Diese Property ist veraltet. Ihre Funktion wird von
- AddReadDetail(SENSE_DEFAULT, ...) uebernommen.
-
-
-
- Hier koennen Informationen gespeichert werden, die beim Lesen
- des Objektes ausgegeben werden.
-
-
-
- Fuer das Identifizieren des zu lesenden Objektes wird der gleiche
- Mechanismus benutzt wie fuer lesbare und andere Details.
-
- Die Benutzung von process_string() ist in dieser Prop nicht mehr erlaubt.
-
-
-BEISPIEL
-========
-
- AddId(({"rolle", "schriftrolle"}));
- SetProp(P_READ_MSG,
- "Du oeffnest die Rolle und liest: LOREM IPSUM ...\n");
-
-
-SIEHE AUCH
-==========
-
- Details: AddReadDetail(), RemoveReadDetail(), P_READ_DETAILS
- Sonstiges: break_string()
-
-09.12.2012, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_TECHNIQUE b/doc/sphinx/man/props/obsolete/P_TECHNIQUE
deleted file mode 100644
index a556ce6..0000000
--- a/doc/sphinx/man/props/obsolete/P_TECHNIQUE
+++ /dev/null
@@ -1,70 +0,0 @@
-
-P_TECHNIQUE
-***********
-
-********************* UNGENUTZTE PROPERTY
-***************************** * Diese Property wird von der Mudlib
-NICHT ausgewertet und kann * * als veraltet gelten.
-* * Momentan ist auch keine Gilde bekannt, die mehr macht, als sie
-* * auszugeben.
-* *******************************************************************
-****
-
-
-NAME
-====
-
- P_TECHNIQUE "technique"
-
-
-DEFINIERT IN
-============
-
- /sys/weapon.h
-
-
-BESCHREIBUNG
-============
-
- Die Technik(en), mit denen eine Waffe im Kampf eingesetzt werden
- kann. Folgende Techniken stehen zur Verfuegung:
-
- TQ_STROKE Streichtechnik
- TQ_THRASH Schlagtechnik
- TQ_THRUST Stosstechnik
- TQ_WHIP Peitschtechnik
-
- Die Techniken sind ebenfalls in <weapon.h> definiert und auf der
- man-page 'techniken' naeher erlaeutert.
-
-
-BEMERKUNGEN
-===========
-
- Man kann einer Waffe eine oder mehrere Techniken zuweisen.
-
-
-BEISPIELE
-=========
-
- a) Eine Waffe, die nur mit einer Peitschtechnik eingesetzt wird,
- also typischerweise eine Peitsche, aber auch ein Morgenstern:
-
- SetProp(P_TECHNIQUE,TQ_WHIP);
-
- b) Eine Waffe, die sowohl mit der Schlag- als auch der Stosstechnik
- eingesetzt wird, also z.B. eine Hellebarde:
-
- SetProp(P_TECHNIQUE,({TQ_THRASH,TQ_THRUST}));
-
-
-SIEHE AUCH
-==========
-
- techniken, P_BALANCED_WEAPON, /std/weapon/combat.c
-
-
-LETZTE AeNDERUNG
-================
-
-15.02.2009, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_TMP_ATTACK_HOOK b/doc/sphinx/man/props/obsolete/P_TMP_ATTACK_HOOK
deleted file mode 100644
index 6bd5130..0000000
--- a/doc/sphinx/man/props/obsolete/P_TMP_ATTACK_HOOK
+++ /dev/null
@@ -1,95 +0,0 @@
-
-P_TMP_ATTACK_HOOK
-*****************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-nicht mehr in neuem Code nutzen. * **********************************
-************************************* P_TMP_ATTACK_HOOK
-
-
-NAME
-====
-
- P_TMP_ATTACK_HOOK "attack_hook"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Mittels dieser Property koennen die Attacken eines Livings ggf.
- abgebrochen werden noch bevor Waffen oder Skills zum ausgewertet
- wurden.
-
- Es wird an dem Living die Property als mindestens 3-elementiges Array:
- ({zeitpunkt, objekt, methode, ...})
- gesetzt und die Methode 'methode' wird dann waehrend des Attack() des
- Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
-
- Der Methode wird als Parameter der Gegner uebergeben.
-
- Gibt die Methode 0 als Rueckgabewert zurueck, wird die Attacke sofort
- kommentarlos abgebrochen.
-
-
-BEMERKUNGEN
-===========
-
- - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
- - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
- Property auf 0 gesetzt
- - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
- pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
- im Code anderer und ist andererseits unfair gegenueber ihnen
-
-
-BEISPIELE
-=========
-
- *** der Spieler erhaelt eine Verwundung, die ihn manchmal behindert ***
- if(!pointerp(tmp=TP->QueryProp(P_TMP_ATTACK_HOOK)) ||
- sizeof(tmp)<3 || tmp[0]<=time()) {
- TP->SetProp(P_TMP_ATTACK_HOOK,
- ({time()+3600, this_object(), "test_hurt"}));
- ...
-
- // die entsprechende Methode, die bei jedem Angriff ueber Attack()
- // gerufen wird ...
- int test_hurt(object enemy) {
-
- // mit 10% Chance generell und 20% Chance bei groesseren Gegnern
- // bricht der Angriff ab ... previous_object() ist natuerlich
- // der Angreifer
- if(!random(10) ||
- (enemy->QueryProp(P_SIZE)>previous_object()->QueryProp(P_SIZE) &&
- !random(5)) {
-
- tell_object(previous_object(),
- "Deine Wunde schmerzt dich zu sehr um anzugreifen.\n");
- tell_room(environment(previous_object()),
- previous_object()->Name(WER,1)+" zuckt vor Schmerzen zusammen.\n",
- ({previous_object()}));
- return 0;
- }
-
- // ansonsten geht der Angriff weiter
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Angriff: Attack(L)
- Schutz: Defend(L)
- Verwandt: InternalModifyAttack(L), P_TMP_ATTACK_MOD
- Hooks: P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK, P_TMP_DEFEND_HOOK
- neue Hooks: std/hooks
-
-08.12.2008, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_TMP_ATTACK_MOD b/doc/sphinx/man/props/obsolete/P_TMP_ATTACK_MOD
deleted file mode 100644
index df10409..0000000
--- a/doc/sphinx/man/props/obsolete/P_TMP_ATTACK_MOD
+++ /dev/null
@@ -1,134 +0,0 @@
-
-P_TMP_ATTACK_MOD
-****************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-nicht mehr in neuem Code nutzen. * **********************************
-************************************* P_TMP_ATTACK_MOD
-
-
-NAME
-====
-
- P_TMP_ATTACK_MOD "attack_mod"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Mittels dieser Property koennen die Attacken eines Livings temporaer
- veraendert werden.
-
- Es wird an dem Living die Property als mindestens 3-elementiges Array
- ({zeitpunkt, objekt, methode, ...})
- gesetzt und die Methode 'methode' wird dann waehrend des Attack() des
- Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
-
- Der Methode wird beim Aufruf ein Kopie des Mappings uebergeben, in dem
- die bisherigen Werte des Angriffes vermerkt sind.
- Aufbau von Mapping 'ainfo':
- ([ SI_ENEMY : object Angreifer, (-> Defend)
- SI_SPELL : 0/1/array Spellparameter, (-> Defend)
- P_WEAPON : - oder Waffe,
- SI_SKILLDAMAGE_MSG: string Angriffsmeldungsende an Raum,
- SI_SKILLDAMAGE_MSG2: string Angriffsmeldungsende an Kaempfende,
- SI_SKILLDAMAGE: int Schaden in Zehntel HP (Skills bis auf Rasse
- drin!) (-> Defend),
- SI_SKILLDAMAGE_TYPE: string/string* Schadenstypen, (-> Defend)
- P_WEAPON_TYPE: string Waffentyp (combat.h),
- P_WC: - oder int WC der Waffe/Hand,
- P_NR_HANDS: - oder int Hands der Waffe/Hand,
- ]);
-
- Gibt die Methode:
- - 0 oder kein Mapping zurueck, fuehrt das zum Abbruch der Attacke
- -> da inzwischen Waffen abgefragt wurden, koennen schon Meldungen
- von diesen ausgegeben worden sein
- - ein leeres Mapping ( ([]) ) zurueck, fuehrt das zu keiner Modifikation
- - ein Mapping mit veraenderten Werten zurueck, werden diese in das
- Angriffsmapping kopiert
- Die geaenderten Werte werden teilweise von SkillResTransfer() in
- den eigentlichen Angriff uebernommen.
-
-
-BEMERKUNGEN
-===========
-
- - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
- Property auf 0 gesetzt
- - vor dem Setzen immer auf die Existenz eines gueltigen Modifiers
- pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
- im Code anderer und ist andererseits unfair gegenueber ihnen
-
-
-BEISPIELE
-=========
-
- *** ein besonder heisser Segen modifiziert die Attacken des Spielers ***
- int action_segen() {
- ...
- mixed *tmp;
-
- // pruefen, ob nicht ein anderer Modifier existiert
- if(!pointerp(tmp=TP->QueryProp(P_TMP_ATTACK_MOD)) ||
- sizeof(tmp)<3 || tmp[0]<=time()) {
-
- object wield;
- wield=TP->QueryProp(P_WEAPON);
-
- write(break_string(
- "Der Priester der Flamme weiht "+
- (wield?wield->name(WEN,1):"deine Haende")+".", 78));
-
- // setzen des Modifiers .. 30-40 Sekunden gueltig
- TP->SetProp(P_TMP_ATTACK_MOD,
- ({time()+30+random(10), this_object(), "modfun"}));
- } else ...
- ...
- return 1;
- }
-
- // die eigentlich Methode, die waehrend des Angriffs gerufen wird
- mapping modfun(mapping ainfo) {
- mapping ret;
-
- // Returnwert ist immer ein Mapping, damit die Attacke weitergeht
- ret=m_allocate(0,1);
-
- // magische Waffen oder Sprueche werden nicht verbessert
- if(ainfo[P_WEAPON_TYPE]!=WT_MAGIC) {
- // sonst Verbesserungen ... Feuer addieren ...
- ret[SI_SKILLDAMAGE_TYPE]=(ainfo[SI_SKILLDAMAGE_TYPE]||({}))+
- ({DT_FIRE});
- // ... und bei Waffe Meldungen anpassen
- if(ainfo[P_WEAPON]) {
- ret[SI_SKILLDAMAGE_MSG]=
- " mit sengendem "+ainfo[P_WEAPON]->name(RAW);
- ret[SI_SKILLDAMAGE_MSG2]=
- " mit sengendem "+ainfo[P_WEAPON]->name(RAW);
- }
- }
-
- return ret;
- }
-
-
-SIEHE AUCH
-==========
-
- Angriff: Attack(L)
- Schutz: Defend(L)
- Verwandt: InternalModifyAttack(L)
- P_TMP_ATTACK_HOOK
- P_TMP_DEFEND_HOOK
- Sonstiges: SkillResTransfer(L)
- Hooks: P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK
-
-10.Feb 2005 Gloinson
diff --git a/doc/sphinx/man/props/obsolete/P_TMP_DEFEND_HOOK b/doc/sphinx/man/props/obsolete/P_TMP_DEFEND_HOOK
deleted file mode 100644
index f29d342..0000000
--- a/doc/sphinx/man/props/obsolete/P_TMP_DEFEND_HOOK
+++ /dev/null
@@ -1,131 +0,0 @@
-
-P_TMP_DEFEND_HOOK
-*****************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-nicht mehr in neuem Code nutzen. * **********************************
-************************************* P_TMP_DEFEND_HOOK
-
-
-NAME
-====
-
- P_TMP_DEFEND_HOOK "defend_hook"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Mittels dieser Property koennen die Abwehren eines Livings temporaer
- veraendert werden.
-
- Es wird an dem Living die Property als mindestens 3-elementiges Array
- ({zeitpunkt, objekt, methode, ...})
- gesetzt und die Methode 'methode' wird dann waehrend des Defend() des
- Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
-
- Der Methode werden die Parameter der Defend() uebergeben:
- int dam, mixed dam_type, mixed spell, object enemy
- - spell ist definitiv ein Mapping - ein an Defend() uebergebener
- int-Wert wurde aequivalent umgesetzt.
- - dam_type ist definitiv ein Array von Schadenswerten oder einem Wert
-
- Zudem findet der Aufruf der Methode nach dem Abarbeiten der P_DEFENDERS
- statt, diese koennen also weitere Modifikationen vorgenommen haben.
-
- Gibt die Funktion:
- - 0 zurueck, wird Defend() abgebrochen (und damit der Schaden voellig
- abgefangen) - nur noch die Flucht wird geprueft
- - ein 3-elementiges Array ({schaden, schadenstypen, spell}) zurueck,
- werden diese Werte in der Defend() an Stelle der uebergebenen Werte
- verwendet
- - weder noch zurueck, wird das Ergebnis ignoriert und die Defend laeuft
- regulaer weiter
-
-
-BEMERKUNGEN
-===========
-
- - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
- - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
- Property auf 0 gesetzt
- - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
- pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
- im Code anderer und ist andererseits unfair gegenueber ihnen
-
-
-BEISPIEL
-========
-
- *** ein gruener Schutzzauber ***
- // Setzen der Prop
- ...
- tmp=TP->QueryProp(P_TMP_DEFEND_HOOK);
-
- // ein etwas ausfuehrlicher Check, ob wir ueberschreiben koennen,
- // Existenz && Gueltigkeit
- if(pointerp(tmp) && sizeof(tmp) && intp(tmp[0]) && (time()<tmp[0]))
- write("Der Zauber klappt nicht!\n");
- else {
- // der Zauber gilt eine Stunde
- TP->SetProp(P_TMP_DEFEND_HOOK,({time()+3600,TO,"abwehrfun");
- write("Ein Zauber legt sich auf dich.\n");
- }
- ...
-
- // die gerufene Methode
- mixed abwehrfun(int dam, string* dam_type, mapping spell, object en) {
- // keine rekursiven Schaeden abfangen ... mindestens ein magischer
- // muss auch dabei sein
- if((!mappingp(spell) || !spell[SP_RECURSIVE]) &&
- sizeof(filter(dam_type,MAGICAL_DAMAGE_TYPES))) {
-
- // mit 10% Whkeit schuetzt der Zauber total
- if(!random(10)) {
- tell_object(previous_object(),
- "Dein Zauber gleisst rund um dich gruen auf.\n");
- tell_room(environment(previous_object()), break_string(
- previous_object()->Name(WESSEN)+" Haut gleisst rund um "+
- previous_object()->QueryPronoun(WEN)+" gruen auf.",78),
- ({previous_object()}));
-
- // manchmal geht der Zauber dabei endgueltig kaputt
- if(!random(10)) previous_object()->SetProp(P_TMP_DEFEND_HOOK, 0);
-
- return 0; // volles Abfangen des Angriffs
- }
-
- // der Zauber schuetzt auf jeden Fall immer ein bischen
- tell_object(previous_object(),
- "Dein Zauber flackert rund um dich gruen auf.\n");
- tell_room(environment(previous_object()), break_string(
- previous_object()->Name(WESSEN)+" Haut flackert rund um "+
- previous_object()->QueryPronoun(WEN)+" gruen auf.",78),
- ({previous_object()}));
- dam=(7+random(2))*dam/10; // Schaden reduzieren
-
- return(({dam, dam_type, spell}));
- }
-
- // der Zauber schuetzt dann gar nicht ...
- return 1;
- }
-
-
-SIEHE AUCH
-==========
-
- Angriff: Attack(L)
- Schutz: Defend(L)
- Verwandt: InternalModifyDefend(L), P_TMP_ATTACK_MOD
- Hooks: P_TMP_DIE_HOOK, P_TMP_MOVE_HOOK, P_TMP_ATTACK_HOOK
- neue Hooks: std/hooks
-
-08.12.2008, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_TMP_DIE_HOOK b/doc/sphinx/man/props/obsolete/P_TMP_DIE_HOOK
deleted file mode 100644
index f4008cb..0000000
--- a/doc/sphinx/man/props/obsolete/P_TMP_DIE_HOOK
+++ /dev/null
@@ -1,91 +0,0 @@
-
-P_TMP_DIE_HOOK
-**************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-nicht mehr in neuem Code nutzen. * **********************************
-************************************* P_TMP_DIE_HOOK
-
-
-NAME
-====
-
- P_TMP_DIE_HOOK "die_hook"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Mittels dieser Property kann der Tod eines Livings abgewendet werden.
-
- Es wird an dem Living die Property als mindestens 3-elementiges Array
- ({zeitpunkt, objekt, methode, ...})
- gesetzt und die Methode 'methode' wird dann waehrend des die() des
- Lebewesens in 'objekt' aufgerufen, solange time()<'zeitpunkt'.
- Bei Geistern wird der Hook nicht gerufen.
-
- Der Methode wird ein int uebergeben, ob das Living Opfer von Gift
- (P_POISON) war.
-
- Gibt die Funktion einen Wert != 0 zurueck, wird die() sofort abgebrochen
- und das Living stirbt nicht.
-
-
-BEMERKUNGEN
-===========
-
- - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
- - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
- Property auf 0 gesetzt
- - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
- pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
- im Code anderer und ist andererseits unfair gegenueber ihnen
-
-
-BEISPIELE
-=========
-
- *** ein besonderer Giftschutz .. wirkt beim Tod ***
- // pruefen, ob nicht ein anderer Modifier existiert
- if(!pointerp(tmp=TP->QueryProp(P_TMP_DIE_HOOK)) ||
- sizeof(tmp)<3 || tmp[0]<=time()) {
- TP->SetProp(P_TMP_DIE_HOOK,
- ({time()+120+random(10), this_object(), "prevent_die"}));
-
- // die gerufene Methode
- int prevent_die(int poison) {
- int ret;
-
- if(poison) {
- tell_object(previous_object(),
- "Ein Zauber reinigt im Moment des Todes dein Blut!\n");
- tell_object(environment(previous_object()),
- previous_object()->Name(WER,1)+" wird von Lichtern umhuellt.\n",
- ({previous_object()}));
-
- ret=1;
- }
-
- // wir helfen nur einmal ... und ein Tod vernichtet die Hilfe auch
- previous_object()->SetProp(P_TMP_DIE_HOOK, 0);
-
- return ret;
- }
-
-
-SIEHE AUCH
-==========
-
- Tod: die(L)
- Sonstiges: P_POISON, P_KILLS, P_GHOST
- Hooks: P_TMP_MOVE_HOOK, P_TMP_ATTACK_HOOK, P_TMP_DEFEND_HOOK
- neue Hooks: std/hooks
-
-08.12.2008, Zesstra
diff --git a/doc/sphinx/man/props/obsolete/P_TMP_MOVE_HOOK b/doc/sphinx/man/props/obsolete/P_TMP_MOVE_HOOK
deleted file mode 100644
index 8f1aa77..0000000
--- a/doc/sphinx/man/props/obsolete/P_TMP_MOVE_HOOK
+++ /dev/null
@@ -1,65 +0,0 @@
-
-P_TMP_MOVE_HOOK
-***************
-
-********************* VERALTETE PROPERTY
-****************************** * Diese Property ist veraltet. Bitte
-nicht mehr in neuem Code nutzen. * **********************************
-*************************************
-
-
-NAME
-====
-
- P_TMP_MOVE_HOOK "move_hook"
-
-
-DEFINIERT IN
-============
-
- /sys/new_skills.h
-
-
-BESCHREIBUNG
-============
-
- Mindestens 3-elementiges Array ({zeitpunkt, objekt, funktion, ...}).
- Die Funktion wird im 'objekt' mit den gleichen Parametern wie move()
- nach der Abfrage auf P_NO_TPORT aufgerufen, wenn der 'zeitpunkt'
- noch nicht ueberschritten ist. Wenn die Funktion etwas anderes als ein
- 5-elementiges Array ({dest, methods, direction, textout, textin})
- oder -1 zurueckgibt, wird move() normal ausgefuehrt, ansonsten werden die
- 5 move-Parameter durch die Array-Eintraege ersetzt bzw. wird bei einem
- Rueckgabewert von -1 das move() abgebrochen. In letzterem Fall ist
- die Funktion dafuer verantwortlich, eine entspr. Meldung an den
- Spieler auszugeben!
-
-
-HINWEIS
-=======
-
- Falls man einem Spieler einen Move-Hook setzt, ist es ratsam, im
- Move-Hook zu pruefen, ob das Spielerobjekt nach Abarbeitung der Hook-
- Funktion noch lebt. Ansonsten wird ein doppeltes move() ausgefuehrt:
- in den Todesraum und direkt wieder zurueck zur Leiche.
-
-
-BEMERKUNGEN
-===========
-
- - Bitte das neuere Hooksystem (s. Manpage std/hooks) benutzen.
- - falls die Zeit abgelaufen oder das Objekt zerstoert ist, wird die
- Property auf 0 gesetzt
- - vor dem Setzen immer auf die Existenz eines gueltigen Hooks
- pruefen, einfaches Ueberschreiben fuehrt einerseits zu Fehlern
- im Code anderer und ist andererseits unfair gegenueber ihnen
-
-
-SIEHE AUCH
-==========
-
- Bewegung: move(L), NotifyMove(), PreventMove()
- Hooks: P_TMP_DIE_HOOK, P_TMP_DEFEND_HOOK, P_TMP_ATTACK_HOOK
- neue Hooks: std/hooks
-
-08.12.2008, Zesstra
diff --git a/doc/sphinx/man/props/skill_info_liste b/doc/sphinx/man/props/skill_info_liste
deleted file mode 100644
index a8ad089..0000000
--- a/doc/sphinx/man/props/skill_info_liste
+++ /dev/null
@@ -1,355 +0,0 @@
-
-skill_info_liste
-****************
-
-
-SI_*
-====
-
-
-DEFINIERT IN
-============
-
- /sys/newskills.h
-
-
-BESCHREIBUNG
-============
-
- Die folgende Liste der SI-Typen ist grob nach Gueltigkeit fuer Skills
- und Spells sortiert.
-
-
-
- Anwendungsorte der SI_-Werte sind:
- - /std/living/combat und von dort gerufene Skills (Kampf)
- - /std/gilden_ob und in Gilden lernbare Spells/Skills
- - /std/spellbook und von Spellbooks ausgefuehrte Spells
- - /std/living/life und von dort gerufene Skills (Alkohol)
- - /std/shells/* und entsprechende Rassenskills
-
- Im Skillsystem unter /std/living/skills wird vor auf Informationen
- aus dem Teil #1 Ruecksicht genommen. Einige dieser Werte
- werden auch permanent im Spieler gespeichert (wie zB die
- SI_SKILLABILITY).
-
-AKTUELLE LISTE: (5. Oktober 2011)
- #1 Skills und Spells:
- SI_SKILLFUNC: string
- Beinhaltet den Namen der Methode, die die eigentliche
- Funktionalitaet des Skills/Spells implementiert. Falls nicht
- angegeben, wird bei Spells durch UseSpell() das Verb, das der
- Spieler eingegeben hat, als Spell-Methodenname angenommen. Im
- Gildenobjekt kann hier abweichend von Spell-Namen stehen, wie
- die Spellfunktion im Spellbook heisst.
-
- SI_CLOSURE: closure
- Optimiert den Zugriff fuer den internen Gebrauch, indem die
- gefundene Spell/Skillfunktion darin direkt gespeichert wird
- und so lange gueltig ist, bis das/die Objekt(e)/Closure(s)
- zerstoert sind. Kann theoretisch auch fuer externe Skills
- durch (Autoload-)Objekte benutzt werden.
-
- SI_SKILLABILITY: int
- Faehigkeit, den Spell/Skill zu benutzen. Normal ist von
- -MAX_ABILITY bis MAX_ABILITY.
-
- SI_SKILLDAMAGE_TYPE: string*
- Art des Schadens eines Angriffs: siehe Schadenstypen in
- /sys/combat.h
-
- SI_SKILLDAMAGE_MSG: string
- Meldung anstatt der Waffe oder Haende-Meldung.
-
- SI_SKILLDAMAGE_MSG2: string
- Meldung anstatt der Waffe oder Haende-Meldung fuer den Raum.
-
- SI_INHERIT: string
- Enthaelt den Namen des Skills/Spells, von dem geerbt wird.
- Das bedeutet einerseits, das LearnSkill() auch diesen
- uebergeordneten Skill beeinflusst und andererseits, dass bei
- Skills auch dieser uebergeordnete Skill im Rahmen einer
- Skill-Anwendung gerufen wird.
-
- SI_DIFFICULTY: int / [Spells: mixed]
- Schwierigkeit eines Skills/Spells. Beeinflusst die jeweils
- oberen Schranken fuer das Lernen eines Skills/Spells in
- Abhaengigkeit von Spielerlevel. Wenn in einem Spell-Info-
- Mapping kein Wert steht wird bei Spells automatisch
- SI_SPELLCOST genommen, der Wert im Spell-Info-Mapping geht
- beim Lernen aber immer vor Parametern.
-
- FACTOR(SI_DIFFICULTY): int / mixed OFFSET(SI_DIFFICULTY): int /
- mixed
-
- Nur fuer Spellbooks/Spells. Der mixed-Parameter kann
- Funktionen enthalten. Siehe unten bei SI_SPELLCOST.
-
- SI_LASTLIGHT: int
- Zeitpunkt, bis wann der Standardskills SK_NIGHTVISION den
- Spieler sehen laesst.
-
- SI_TESTFLAG: int
- Wenn gesetzt, dann soll der Skill nicht genutzt, sondern nur
- getestet werden, ob er erfolgreich waere. Entspricht also in
- etwa dem Aufruf von SpellSuccess() in Spellbooks, wird aber
- bei UseSkill() als Skill-Parameter uebergeben. Der Skill muss
- entsprechend implementiert sein!
-
- SI_GUILD: string
- Angabe der Gilde, aus der der Skill stammt. Sinnvoll, wenn
- der Skill nicht aus der aktuellen P_GUILD stammt. Fuer
- generelle Skills/Spells zB waere das "ANY". Gilt nicht fuer
- Spells!
-
- SI_ENEMY: object
- Aktuelles Feindesobjekt, wird bei Skill-Anwendung aus dem
- Kampf heraus von std/living/combat.c an den Skill uebergeben.
- Beispiel: Standardwaffenskills, SK_MAGIC_DEFENSE,
- SK_MAGIC_ATTACK,
-
- SK_TWOHANDED, SK_SPELL_DEFEND, SK_INFORM_DEFEND und
- SK_DEFEND_OTHER.
-
- SI_FRIEND: object
- Zu verteidigendes Freundesobjekt, wird bei Skill-Anwendung
- aus dem Kampf heraus von std/living/combat.c an den Skill
- uebergeben. Beispiele: SK_INFORM_DEFEND und SK_DEFEND_OTHER.
-
- SI_MAGIC_TYPE: string*
- Enthaelt ein Array der Magietypen, die zum Einsatz kommen.
- Die Angabe geschieht zB im Spellbook und beeinflusst
- SpellDefend().
-
- SI_LAST_USE: int (eventuell obsolet)
- Letzte Nutzung des Skills.
-
- SI_LEARN_PROB: int (eventuell obsolet)
- Lernwahrscheinlichkeit.
-
- SI_SKILLDURATION: int
- Dauer des Skills/Spells. Momentan nicht allzu verbreitet in
- Nutzung.
-
- #2 nur fuer Spells:
- SI_SPELLBOOK: string
- Kann direkt das enthaltende Spellbook fuer einen Spell
- enthalten.
-
- SM_RACE: mapping
- Mapping, das als Key die Rasse und als Value ein Mapping X
- enthaelt. Dieses Mapping X wird direkt zu sinfo hinzugefuegt
- und ueberschreibt damit bei Bedarf Defaultwerte durch
- rassenspezifische Werte.
-
- SI_SPELLCOST: int / mixed FACTOR(SI_SPELLCOST): int / mixed
- OFFSET(SI_SPELLCOST): int / mixed
-
- Beinhaltet die Werte, die fuer die Berechnung der Spellkosten
- zustaendig sind. Dabei gilt: Realkosten = OFFSET(COST) +
- (COST * FACTOR(COST))/100 Die einzelnen Eintraege koennen
- anstatt eines fixen Wertes auch den Verweis auch eine
- Funktion in Form von Closure/Methodenname/Array mit
- Objekt/Objektname und Methodenname enthalten. Siehe dazu auch
- execute_anything().
-
- SI_TIME_MSG: string
- Meldung, die dem Spieler mitteilt, dass er noch nicht wieder
- einen Spell casten kann. Falls dieser Eintrag nicht gesetzt
- ist, wird ein Standardtext ausgegeben.
-
- SI_SP_LOW_MSG: string
- Meldung, die dem Spieler mitteilt, dass er zu wenige
- Konzentrationspunkte besitzt, um den Spell zu casten. Falls
- dieser Eintrag nicht gesetzt ist, wird ein Standardtext
- ausgegeben.
-
- SI_PREPARE_MSG: string
- Meldung, die dem Spieler ausgegeben werden soll, wenn er
- einen Spell vorbereitet. Ansonsten wird ein Standardtext
- ausgegeben.
-
- SI_PREPARE_BUSY_MSG: string
- Meldung, die dem Spieler ausgegeben werden soll, wenn er
- schon diesen Spell vorbereitet. Ansonsten wird ein
- Standardtext ausgegeben.
-
- SI_PREPARE_ABORT_MSG: string
- Meldung, die dem Spieler ausgegeben werden soll, wenn er die
- Vorbereitung dieses Spells durch einen anderen Spell
- unterbricht. Ansonsten wird ein Standardtext ausgegeben.
-
- SI_NOMAGIC: int
- Wert zwischen 0 und 100 (oder mehr), der gegen die P_NOMAGIC-
- Wirkung eines Raumes wirkt. Je hoeher der Wert ist, desto
- unwahrscheinlicher ist es, dass ein Raum den Spell durch
- Antimagie stoert. Ein Raum sollte nur Werte zwischen 0 und
- 100 gesetzt haben. Ist der Wert des Raums groesser als der
- hier angegeben, dann blockiert er Magie mit einer gewissen
- eben seiner angegebenen Wahrscheinlichkeit.
-
- SI_NOMAGIC_MSG: string
- Meldung, die bei Fehlschlag durch P_NOMAGIC des Raumes
- ausgegeben wird. Ansonsten wird ein Standardtext ausgegeben.
-
- SI_SPELLFATIGUE: int / mixed FACTOR(SI_SPELLFATIGUE): int /
- mixed OFFSET(SI_SPELLFATIGUE): int / mixed
-
- Werte, die fuer die Berechnung der Wieder-Cast-Zeit benutzt
- werden. Die Berechnung und die moeglichen Angaben (Closure
- etc.) sind identisch zu SI_SPELLCOST. Das Spellbook gibt bei
- Nicht-Wieder-Bereitschaft SI_TIME_MSG aus.
-
- SI_X_SPELLFATIGUE: mapping mit ([string key: int val])
- Werte, die fuer die Berechnung der Wieder-Cast-Zeit benutzt
- werden. Spellbook-Casten: Mapping wird durch Aufruf von
- CheckSpellFatigue(<key>) am Caster gefiltert. Nur wenn das
- resultierende Mapping leer ist (kein <key> hat einen
- gueltigen Fatigue-Eintrag), ist Spell castbar, sonst Ausgabe
- von SI_TIME_MSG. Nach Spellbook-Casten: Setzen der Fatigue
- fuer alle <val> > 0 mit <key>.
-
- SI_SKILLLEARN: int / mixed FACTOR(SI_SKILLLEARN): int / mixed
- OFFSET(SI_SKILLLEARN): int / mixed
-
- Werte, die fuer die Berechnung der Lerngeschwindigkeit
- benutzt werden, normalerweise pro A_INT/2 je 0.01% (also 1
- von MAX_ABILITY). Die Berechnung und die moeglichen Angaben
- (Closure etc.) sind identisch zu SI_SPELLCOST.
-
- SI_LEARN_ATTRIBUTE: mapping
- Mapping, welches die Attribute, nach denen gelernt werden
- soll als Keys enthaelt. Der Value legt die Gewichtung fest,
- denn bei mehreren Attributen wird ein Mittelwert gebildet.
- Der Normalfall entspraeche ([A_INT: 1]) fuer
- SI_LEARN_ATTRIBUTE.
-
- SI_NO_LEARN
- Wenn man (temporaer!) nicht will, dass dieser Skill gelernt
- wird. Muss von den Spellbooks beachtet werden. Sollte niemals
- im Spieler abgespeichert werden. Oder permanent in
- Gilde/Spellbook gesetzt sein. Sondern im Laufe einesr Nutzung
- in der jew. Kopie von sinfo gesetzt werden, die gerade
- genutzt wird.
-
- SI_SKILLARG: string Beinhaltet den Text, den der Spieler nach
- dem Spellkommando eingegeben hat. Z.B. stuende bei
- "krallenschlag ork 2" der Text "ork 2" im Parameter.
-
- SI_SKILLRESTR_USE: mixed
- Einschraenkungen fuer das Nutzen des Spells. Wird
- normalerweise direkt im Spellbook fuer den Spell eingetragen.
- Die einzelnen Moeglichkeiten werden in der manpage zu
- "check_restrictions" erlaeutert.
-
- SI_SKILLRESTR_LEARN: mixed
- Einschraenkungen fuer das Lernen des Spells. Wird
- normalerweise direkt im Gildenobjekt fuer den Spell
- eingetragen. Die einzelnen Moeglichkeiten werden in der
- manpage zu "check_restrictions" erlaeutert.
-
- SI_SKILLINFO: string SI_SKILLINFO_LONG: string
-
- Beschreibung des Spells. Wird im Gildenobjekt eingetragen und
- SI_SKILLINFO wird von SkillListe angezeigt.
-
- SI_SKILLDAMAGE: int / mixed FACTOR(SI_SKILLDAMAGE): int / mixed
- OFFSET(SI_SKILLDAMAGE): int / mixed
-
- Werte, die fuer die Schadenshoehenberechnung des Spells
- benutzt werden (random ueber den Gesamtwert normalerweise).
- Die Berechnung und die moeglichen Angaben (Closure etc.) sind
- identisch zu SI_SPELLCOST.
-
- SI_SKILLDAMAGE_BY_ROW
- Ein Mapping mit Boni fuer den Angriff aus bestimmten
- Kampfreihen. Funktioniert nur bei Verwendung von
- TryDefaultAttackSpell-Spells aus dem Spellbook. Der Key steht
- fuer eine bestimmte Reihe, sein Wert fuer den randomisierten
- Bonus fuer Lebewesen, die aus dieser Reihe casten.
-
- OFFSET(SI_SKILLDAMAGE_BY_ROW)
- Ein Mapping mit fixem Wert fuer Row-Boni im Kampf.
-
- Beispiel: AddSpell("feuerball", 20,
- ([SI_SKILLDAMAGE:50,
- OFFSET(SI_SKILLDAMAGE):100,
- SI_SKILLDAMAGE_BY_ROW:([2:40,3:20}),
- OFFSET(SI_SKILLDAMAGE_BY_ROW):([2:20]), ...
-
- gibt
- Reihe 1: random(50)+100; Reihe 2:
- random(50)+100+random(40)+20 Reihe 3:
- random(50)+100+random(20)
-
- ACHTUNG: Hier gilt nicht die selbe Struktur wie bei
- SI_SPELLCOST!
-
- SI_SPELL: mapping
- Dieser Eintrag enthaelt verschiedene Unterwerte, die den
- Spell gerade fuer Angriffs-Spells genauer beschreiben. Siehe
- Defend() fuer eine Beschreibung der verschiedenen Eintraege
- (die so auch in das Spellbook uebernommen werden koennen).
-
- SI_COLLATERAL_DAMAGE: int
- Hiermit kann man einen Prozentwert von SI_SKILLDAMAGE
- (inklusive Offsets und Factor) fuer Kollateralschaden an
- Freunden im definierten Bereich eines Flaechenspells
- (TryGlobalAttackSpell()) angeben. 10 bedeutet bei
- OFFSET(SI_SKILLDAMAGE)=100 zB 10% von 100 = 10 = 1 LP an mit
- reduce_hit_points() verursachtem Schaden.
-
- SI_NUMBER_ENEMIES, SI_NUMBER_FRIENDS: int
- Wird von TryGlobalAttackSpell() im Spell gesetzt und enthaelt
- die Anzahl der im angegebenen Bereich befindlichen Feinde und
- Freunde. Ist dementsprechend von informativem Nutzen fuer den
- Angegriffenen und das Spellbook NACH Aufruf von
- TryGlobalAttackSpell().
-
- SI_DISTANCE, SI_WIDTH, SI_DEPTH: int
- Limitiert die Entfernung, Tiefen und Breite der Wirkung eines
- TryGlobalAttackSpell()
-
- SI_SKILLHEAL: int
- Konvention fuer Spells im Spellbook, dort den Heilwert zu
- hinterlegen, hat keine Auswirkungen unter /std/.
-
- SI_USR: mixed
- Fuer selbst definierte Infos, spellbookabhaengig.
-
- SI_PREPARE_TIME: int
- Dauer der Zeit fuer zu praeparierende Spells.
-
- SI_ATTACK_BUSY_MSG: string
- Meldung, die dem Spieler mitteilt, dass er schon zu
- beschaeftigt mit einem Angriff ist, um einen Spell zu casten.
- Falls dieser Eintrag nicht gesetzt ist, wird ein
- Standardtext ausgegeben.
-
- SI_NO_ATTACK_BUSY: int
- Enthaelt als Flag NO_ATTACK_BUSY_QUERY wenn der Spell NICHT
- wie eine Spezialwaffe die Aktionen einschraenkt. Siehe
- P_ATTACK_BUSY.
-
- SI_ATTACK_BUSY_AMOUNT: int
- Menge des P_ATTACK_BUSY fuer diesen Spell. Falls dieser Wert
- nicht gesetzt ist, aber auch SI_NO_ATTACK_BUSY nicht mit
- NO_ATTACK_BUSY_QUERY ausgezeichnet ist wird 1 angenommen.
-
-
-SIEHE AUCH
-==========
-
- Skills Lernen: LearnSkill, ModifySkill, LimitAbility
- * Nutzung: UseSpell, UseSkill
- * Abfragen: QuerySkill, QuerySkillAbility
- * Modifikation: ModifySkillAttribute, QuerySkillAttribute,
- QuerySkillAttributeModifier, RemoveSkillAttributeModifier
- * Properties: P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS
- * sonstig: spruchermuedung
- * Properties: P_NEWSKILLS
- Spellbook: UseSpell, Learn, SpellSuccess
- Gilden: gilden-doku
- Kampf: Defend
-
-7. Nov 2012 Gloinson
diff --git a/doc/sphinx/man/sefun.index b/doc/sphinx/man/sefun.index
deleted file mode 100644
index 6d9564f..0000000
--- a/doc/sphinx/man/sefun.index
+++ /dev/null
@@ -1,137 +0,0 @@
-
-sefuns (simulated efuns)
-************************
-
-sefuns sind Funktionen, die aehnlich wie echte efuns im Driver allen
-Objekten (ausser dem Masterobjekt) zur Verfuegung stehen ohne dass die
-explizit geerbt werden muessen. Sie sind allerdings in LPC
-implementiert und damit langsamer als efuns.
-
-Es ist moeglich, sefuns mit demselben Namen wie efuns zu erstellen,
-diese wird dann anstelle der efun gerufen. Will man ausnahmsweise aber
-die efun mit dem Namen rufen, so kann dies mit der Syntax
-"efun::function()" erreichen.
-
-Verzeichnis der dokumentierten sefuns im Morgengrauen:
-
-* CountUp()
-
-* _notify_fail()
-
-* break_string()
-
-* broken_count_bits()
-
-* cindent()
-
-* debug_info()
-
-* deep_present()
-
-* dtime()
-
-* dump_netdead()
-
-* enable_commands()
-
-* file_time()
-
-* find_living()
-
-* find_livings()
-
-* find_netdead()
-
-* find_player()
-
-* getuuid()
-
-* iso2ascii()
-
-* log_file()
-
-* lowerchar()
-
-* lowerstring()
-
-* m_copy_delete()
-
-* match_living()
-
-* md5()
-
-* mkdirp()
-
-* notify_fail()
-
-* object_info()
-
-* old_explode()
-
-* process_call()
-
-* process_string()
-
-* query_editing()
-
-* query_idle()
-
-* query_input_pending()
-
-* query_ip_name()
-
-* query_ip_number()
-
-* query_limits()
-
-* query_mud_port()
-
-* query_next_reset()
-
-* query_once_interactive()
-
-* query_shadowing()
-
-* query_snoop()
-
-* query_wiz_grp()
-
-* query_wiz_level()
-
-* read_data()
-
-* replace_personal()
-
-* restore_object()
-
-* save_object()
-
-* send_room()
-
-* set_heart_beat()
-
-* set_light()
-
-* set_living_name()
-
-* set_object_heart_beat()
-
-* sha1()
-
-* shadow()
-
-* shout()
-
-* time2string()
-
-* update_actions()
-
-* upperstring()
-
-* uptime()
-
-* wizlist()
-
-* wizlist_info()
-
-* write_data()
diff --git a/doc/sphinx/man/sefun/CountUp b/doc/sphinx/man/sefun/CountUp
deleted file mode 100644
index 9e55d69..0000000
--- a/doc/sphinx/man/sefun/CountUp
+++ /dev/null
@@ -1,40 +0,0 @@
-
-CountUp()
-*********
-
-
-FUNKTION
-========
-
- public varargs string CountUp( string *s, string sep, string lastsep );
-
-
-ARGUMENTE
-=========
-
- *s
- Array von Strings mit Woertern.
- sep
- String, der zwischen den Woerten in der Aufzaehlung eingefuegt wird.
- Standard: ", "
- lastsep
- String, der zwischen dem vorletzten und letzten Element eingefuegt wird.
- Standard: " und "
-
-
-BESCHREIBUNG
-============
-
- Die Woerter Wort_1 bis Wort_n aus dem Stringaray werden als
- Aufzaehlung in der Form
- Wort_1<sep>Wort_2, ... Wort_n-1<lastsep>Wort_n
- zusammengesetzt. Mit Standardwerten also:
- Wort_1, Wort_2, ... Wort_n-1 und Wort_n
-
-
-RUeCKGABEWERT
-=============
-
- String als Aufzaehlung der einzelnen Woerter.
-
-15.03.2008, Zesstra
diff --git a/doc/sphinx/man/sefun/_notify_fail b/doc/sphinx/man/sefun/_notify_fail
deleted file mode 100644
index a9801ef..0000000
--- a/doc/sphinx/man/sefun/_notify_fail
+++ /dev/null
@@ -1,35 +0,0 @@
-
-_notify_fail()
-**************
-
-simul_efun::_notify_fail(E)
-
-
-FUNKTION
-========
-
- void _notify_fail(string str)
-
-
-ARGUMENTE
-=========
-
- str
- umgebrochener Fehlermeldungsstring
-
-
-BESCHREIBUNG
-============
-
- Identisches Verhalten zu notify_fail(E), bis darauf, dass bei bereits
- gesetzter Fehlermeldung _keine_ neue Fehlermeldung gesetzt wird.
-
-
-SIEHE AUCH
-==========
-
- notify_fail(E), P_ACTUAL_NOTIFY_FAIL
- add_action(E), AddCmd(L), AddAction(L),
- query_verb(E)
-
-24 Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/sefun/break_string b/doc/sphinx/man/sefun/break_string
deleted file mode 100644
index 8e3017d..0000000
--- a/doc/sphinx/man/sefun/break_string
+++ /dev/null
@@ -1,112 +0,0 @@
-
-break_string()
-**************
-
-
-FUNKTION
-========
-
- string break_string(string str)
- string break_string(string str, int width)
- string break_string(string str, int width, string indent)
- string break_string(string str, int width, int space)
- string break_string(string str, int width, string indent, int flags)
- string break_string(string str, int width, int space, int flags)
-
-
-ARGUMENTE
-=========
-
- str - umzubrechender String
- width - optional: maximale Zeilenlaenge (default 78)
- indent - optional: String, der vor jeder umgebrochenen Zeile erscheint
- space - optional: Anzahl der Leerzeichen vor jeder umgebrochenen Zeile
- flags - optional: hiermit laesst sich das Verhalten von break_string()
- aendern; moegliche Flags siehe Punkt 'Beschreibung'
-
-
-BESCHREIBUNG
-============
-
- In der ersten Form wird der String 'str' durch Einfuegen von "\n" so um-
- gebrochen, dass bei einer anschliessenden Ausgabe keine Zeile laenger
- als 'width' Zeichen ist. Eventuell schon in 'str' vorhandene "\n" werden
- dabei vorher entfernt.
-
- Gibt man zusaetzlich noch einen String 'indent' an, so wird dieser vor
- jede der umgebrochenen Zeilen gesetzt.
-
- Analog wird bei der Angabe der Zahl 'space' ein String mit 'space' Leer-
- zeichen vor jede umgebrochene Zeile gesetzt.
-
- Zusaetzlich gibt es folgende optionale Flags, die man beliebig kombinieren
- kann:
-
- BS_LEAVE_MY_LFS - schon im Text vorhandene "\n" werden beibehalten
- BS_SINGLE_SPACE - doppelte Leerzeichen sowie Leerzeichen nach Zeilen-
- umbruechen werden entfernt
- BS_BLOCK - der Text wird im Blocksatz formatiert
- BS_NO_PARINDENT - bei Blocksatz mit vorgegebenen Zeilenumbruechen
- (BS_BLOCK|BS_LEAVE_MY_LFS) werden Zeilen nach "\n"
- normalerweise mit einem Leerzeichen begonnen.
- Um das Einfuegen des fuehrenden Leerzeichens zu
- unterdruecken, muss BS_NO_PARINDENT angegeben werden
- BS_INDENT_ONCE - die erste Zeile des Textes wird mit vorangestelltem
- 'indent' ausgegeben; alle folgenden Zeilen bekommen
- einen Leerstring vorangestellt
- BS_PREPEND_INDENT - der Ident wird dem Text vorangestellt sofern der
- Indent + Text laenger als eine Zeile ist. Der Text
- wird um ein Leerzeichen eingerueckt, was mittels
- BS_NO_PARINDENT verhindert werden kann.
-
-
-RUECKGABEWERT
-=============
-
- Der umgebrochene Text.
-
- Laufzeit-Fehler, wenn der Indent laenger ist als die vorgegebene Breite.
-
-
-BEISPIELE
-=========
-
- write(break_string("Dies ist ein laengerer Text. Nur so als Beispiel.",27));
-
- => Dies ist ein laengerer
- Text. Nur so als Beispiel.
-
- write(break_string("Mit indent sieht das so aus", 30, "Wargon sagt: "));
-
- => Wargon sagt: Mit indent sieht
- Wargon sagt: das so aus
-
- write(break_string("Mit indent sieht das so aus", 30, "Wargon sagt: ",
- BS_INDENT_ONCE));
-
- => Wargon sagt: Mit indent sieht
- das so aus
-
- write(break_string("Mit Leerzeichen sieht das so aus", 30, 2));
-
- => Mit Leerzeichen sieht das so
- aus...
-
- write(break_string("Ich will es\naber vorformatiert!",60,
- "Wargon sagt: ", BS_LEAVE_MY_LFS));
-
- => Wargon sagt: Ich will es
- Wargon sagt: aber vorformatiert!
-
- write(break_string("Ich will es\naber vorformatiert!",30,
- "Wargon sagt: ", BS_PREPEND_INDENT));
-
- => Wargon sagt:
- Ich will es aber
- vorformatiert!
-
-
-SIEHE AUCH
-==========
-
- senderwiederholung
diff --git a/doc/sphinx/man/sefun/broken_count_bits b/doc/sphinx/man/sefun/broken_count_bits
deleted file mode 100644
index de01e96..0000000
--- a/doc/sphinx/man/sefun/broken_count_bits
+++ /dev/null
@@ -1,48 +0,0 @@
-
-broken_count_bits()
-*******************
-
-
-SYNOPSIS
-========
-
- int count_bits (string str)
-
-
-DESTRIPTION
-===========
-
- Count the number of set bits in bitstring <str> and return the number
- as result.
-
-
-NOTE
-====
-
- Bitstrings store 6 Bits per Character. Consequently, the functions for
- manipulating bitstrings (see below) do generally not work on most
- strings. An exception is this (s)efun. It accepts strings which are
- not correct bitstrings (like getuid(PL)), BUT: It does NOT work
- correctly on them! The results are NOT the correct number of bits!
- Additionally, count_bits() in LDMud rejects such strings with an error
- instead of returning false results, as all the other functions for
- bitstrings do as well.
-
-
-EXAMPLES
-========
-
- string s;
-
- s = set_bit("", 3); s = set_bit(s, 15);
-
- count_bits(s) --> returns 2
-
-
-SEE ALSO
-========
-
- clear_bit(E), set_bit(E), test_bit(E), next_bit(E), last_bit(E),
- or_bits(E), xor_bits(E), invert_bits(E), copy_bits(E)
-
-19.12.2006, Zesstra
diff --git a/doc/sphinx/man/sefun/cindent b/doc/sphinx/man/sefun/cindent
deleted file mode 100644
index e0e16af..0000000
--- a/doc/sphinx/man/sefun/cindent
+++ /dev/null
@@ -1,22 +0,0 @@
-
-cindent()
-*********
-
-
-SYNOPSIS
-========
-
- int cindent(string file)
-
-
-DESCRIPTION
-===========
-
- Indent a file using an LPC-enhanced version of the GNU indent
- program, which is modelled after the Berkeley indent(1).
-
-
-SEE ALSO
-========
-
- ed(E)
diff --git a/doc/sphinx/man/sefun/debug_info b/doc/sphinx/man/sefun/debug_info
deleted file mode 100644
index 02e02b8..0000000
--- a/doc/sphinx/man/sefun/debug_info
+++ /dev/null
@@ -1,508 +0,0 @@
-
-debug_info()
-************
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- #include <debug_info.h>
-
- mixed debug_info(int flag)
- mixed debug_info(int flag, mixed arg)
- mixed debug_info(int flag, mixed arg2, mixed arg3)
-
-
-BESCHREIBUNG
-============
-
- Sammelt entsprechend den Angaben in <flag> gewisse intere Debuginfos
- des Treibers. <flag> kann dabei folgende in debug_info.h definierte
- Werte enthalten:
-
- DINFO_OBJECT (0): Angezeigt werden Informationen zum in <arg>
- spezifizierten Objekt, zum Beispiel heart_beat,
- enable_commands etc. Die Funktion liefert 0 zurueck.
-
- DINFO_MEMORY (1): Angezeigt werden Informationen zu
- Speicherbelegung und -ausnutzung des in <arg> spezifizierten
- Objekts, zum Beispiel Anzahl Strings, Variablen, geerbte Files,
- Objektgroesse etc. Die Funktion liefert 0 zurueck.
-
- DINFO_OBJLIST (2): debug_info() liefert Objekte aus der globalen
- Objektliste. Wenn <arg2> nicht angegeben wird, wird das erste
- Element aus der Objektliste gelierfert, wenn <arg2> eine Zahl n
- ist, das n-te Element. Ist <arg2> ein Objekt, werden die
- nachfolgenden Objekte in der Objektliste zurueck geliefert.
- Das optionale Argument <arg3> bezeichnet die Anzahl zurueck
- gelieferter Objekte. Wenn <arg3> 0 ist, wird ein einzelnes
- Objekt zurueck geliefert. Wenn <arg3> eine Zahl m enthaelt, wird
- ein Array mit hoechstens m Elementen zurueck geliefert. Auf
- diese Weise kann ein Array mit saemtlichen Objekten im Spiel
- erzeugt werden, wenn fuer <arg3> __INT_MAX__ gesetzt wird (eine
- entsprechende maximale Arraygroesse vorausgesetzt).
-
- DINFO_MALLOC (3): Entsprichend der Eingabe des 'malloc'-Kommandos.
- Es muessen keine weiteren Argumente angegeben werden.
-
- DINFO_STATUS (4): Angezeigt wird die Statusinformation des Drivers.
- Optional kann das Argument <arg> die Werte 0, "tables", "swap",
- "malloc" oder andere vom Driver akzeptierte Argumente enthalten.
- Das Resultat ist ein druckbarer String, der die Statusinformation
- enthaelt, oder 0, wenn ein ungueltiges Argument angegeben wurde.
-
- DINFO_DUMP (5): Die durch <arg2> angeforderte Information wird
- in ein File geschrieben, das man mit <arg3> angeben kann. Wird
- <arg3> nicht angegeben, wird eine Standarddatei verwendet.
- debug_info() ueberprueft mittels master->valid_write(), ob es
- das File schreiben kann. Falls bereits eine entsprechende Datei
- existiert, wird diese ueberschrieben. Die Funktion liefert 1
- bei Erfolg, 0 sonst.
-
- <arg2> == "objects": liefert Informationen ueber alle Objekte im
- Spiel und schreibt diese standardmaessig in die Datei
- /OBJ_DUMP, dem valid_write() wird 'objdump' uebergeben.
- Die Datei enthaelt fuer jedes Objekt eine Zeile, in der
- jeweils folgende Informationen aufgelistet sind:
- - Name des Objekts (object_name)
- - Groesse im Speicher, gemeinsamer genutzter Speicher nur
- einmal gezaehlt
- - Groesse im Speicher, wenn es keine gemeinsam genutzte
- Daten geben wuerde
- - Anzahl Referenzen
- - 'HB', wenn das Objekt einen heart_beat hat, sonst nichts.
- - der Name der Umgebung oder '--', wenn das Objekt keine
- Umgebung hat
- - in Klammern die Anzahl der durch das Objekt verursachten
- Verarbeitungsschritten (execution ticks)
- - der Swap-Status:
- > nichts, wenn das Objekt nicht geswapt wurde
- > 'PROG SWAPPED', wenn nur das Programm geswapt wurde
- > 'VAR SWAPPED', wenn nur die Variablen geswapt wurden
- > 'SWAPPED', wenn beide geswapt wurden
- - die Zeit, zu der das Objekt geladen wurde.
-
- <arg2> == "destructed": liefert Informationen ueber alle
- zerstoerten Objekte und schreibt diese standardmaessig in
- die Datei /DEST_OBJ_DUMP, dem valid_write() wird 'objdump'
- uebergeben. Die Datei enthaelt fuer jedes Objekt eine Zeile,
- in der jeweils folgende Informationen aufgelistet sind:
- - Name des Objekts (object_name)
- - Anzahl der Referenzen
- - 'NEW', wenn das Objekt in diesem Verarbeitungszyklus
- zerstoert wurde, nichts wenn es bereits fruehre zerstoert
- worden war.
-
- <arg2> == "opcodes": liefert Nutzungsinformationen ueber die
- opcodes. Standardmaessig wird in die Datei /OPC_DUMP
- geschrieben. valid_write() wird 'opcdump' uebergeben.
-
- <arg2> == "memory": liefert eine Liste aller allokierten
- Speicherbloecke.
- Standardmaessig wird in die Datei /MEMORY_DUMP geschrieben;
- valid_write() wird 'memdump' uebergeben. Existiert die
- Datei bereits, werden die neuen Daten angehaengt.
- Wenn der Allokator einen Speicherabzug nicht unterstuetzt,
- wird keine Datei geschrieben und immer 0 zurueckgegeben.
- Diese Funktion ist am nuetzlichsten wenn der Allokator
- mit MALLOC_TRACE und MALLOC_LPC_TRACE kompiliert
- wurde.
-
-
- DINFO_DATA (6): Liefert Rohdaten ueber gewisse, durch <arg2>
- spezifizierte Aspekte des Treibers. Das Resultat der Funktion ist
- ein Array mit der Information oder 0, falls <arg2> keinen
- gueltigen Wert enthalten hat.
- Ist <arg3> eine Zahl, die kleiner ist als die Anzahl Elemente im
- Resultat-Array, liefert die Funktion nur das entsprechende
- Element zurueck.
- Zulaessige Werte fuer <arg2> sind: DID_STATUS, DID_SWAP und
- DID_MALLOC.
-
- <arg2> == DID_STATUS (0): Liefert die "status" und "status table"
- Information. Folgende Indizes sind definiert:
- - int DID_ST_BOOT_TIME
- die Zeit (time()), zu der das Mud gestartet wurde
- - int DID_ST_ACTIONS
- - int DID_ST_ACTIONS_SIZE
- die Anzahl und Groesse im Speicher der allozierten
- Actions.
- - int DID_ST_SHADOWS
- - int DID_ST_SHADOWS_SIZE
- Anzahl und Groesse im Speicher aller allozierten
- Shadows.
- - int DID_ST_OBJECTS
- - int DID_ST_OBJECTS_SIZE
- Anzahl und Groesse im Speicher aller Objekte.
- - int DID_ST_OBJECTS_SWAPPED
- - int DID_ST_OBJECTS_SWAP_SIZE
- Anzahl und Groesse im Speicher der geswapten
- Variablenbloecke der Objekte
- - int DID_ST_OBJECTS_LIST
- Anzahl Objekte in der Objektliste
- - int DID_ST_OBJECTS_NEWLY_DEST
- Anzahl der frisch zerstoerten Objekte (d.h. Objekte,
- die in diesem Verarbeitungszyklus zerstoert wurden)
- - int DID_ST_OBJECTS_DESTRUCTED
- Anzahl der zerstoerten, aber noch immer referenzierten
- Objekte, ohne die unter DID_ST_OBJECTS_NEWLY_DEST
- bereits gezaehlten.
- - int DID_ST_OBJECTS_PROCESSED
- Anzahl der gelisteten Objekte, die im letzten
- Verarbeitungszyklus verarbeitet wurden.
- - float DID_ST_OBJECTS_AVG_PROC
- Durchschnittlicher Anteil der pro Zyklus verarbeiteten
- Objekte, ausgedrueckt in Prozent (0 .. 1.0)
- - int DID_ST_OTABLE
- Anzahl eingetragener Objekte in der Objekttabelle
- - int DID_ST_OTABLE_SLOTS
- Anzahl von Hashplaetzen, die von jeder Objekttabelle
- bereitgestellt werden
- - int DID_ST_OTABLE_SIZE
- Durch die Objekttabelle belegter Speicher
- - int DID_ST_HBEAT_OBJS
- Anzahl Objekte mit einem heart_beat()
- - int DID_ST_HBEAT_CALLS
- Anzahl aktiver heart_beat() Zyklen bisher (d.h.
- Zyklen, in denen mindestens eine heart_beat() Funktion
- aufgerufen wurde)
- - int DID_ST_HBEAT_CALLS_TOTAL
- Gesamtzahl von heart_beat() Zyklen bisher.
- - int DID_ST_HBEAT_SLOTS
- - int DID_ST_HBEAT_SIZE
- Anzahl und Groesse aller allozierten Eintraege in der
- heart_beat() Tabelle.
- - int DID_ST_HBEAT_PROCESSED
- Anzahl heart_beat()s im letzten Zyklus
- - float DID_ST_HBEAT_AVG_PROC
- Durchschnittlicher Anteil der pro Zyklus aufgerufenen
- heart_beat()s, ausgedrueckt in Prozent (0 .. 1.0)
- - int DID_ST_CALLOUTS
- Anzahl und Groesse aller laufenden call_out()s
- - int DID_ST_ARRAYS
- - int DID_ST_ARRAYS_SIZE
- Anzahl und Groesse aller Arrays
- - int DID_ST_MAPPINGS
- - int DID_ST_MAPPINGS_SIZE
- Anzahl und Groesse aller Mappings
- - int DID_ST_PROGS
- - int DID_ST_PROGS_SIZE
- Anzahl und Groesse aller Programme
- - int DID_ST_PROGS_SWAPPED
- - int DID_ST_PROGS_SWAP_SIZE
- Anzahl und Groesse der geswapten Programme
- - int DID_ST_USER_RESERVE
- - int DID_ST_MASTER_RESERVE
- - int DID_ST_SYSTEM_RESERVE
- Momentane Groesse der drei Speicherreserven
- - int DID_ST_ADD_MESSAGE
- - int DID_ST_PACKETS
- - int DID_ST_PACKET_SIZE
- Anzahl Aufrufe von add_message(), Anzahl und Groesse
- der versendeten Pakete.
- Wenn der Driver nicht mit COMM_STAT kompiliert wurde,
- liefern alle drei Werte immer -1 zurueck.
- - int DID_ST_APPLY
- - int DID_ST_APPLY_HITS
- Anzahl Aufrufen von apply_low(), und wie viele davon
- Cache-Treffer waren. Wenn der Driver nicht mit
- APPLY_CACHE_STAT kompiliert wurde, liefern beide
- Werte immer -1.
- - int DID_ST_STRINGS
- - int DID_ST_STRING_SIZE
- Anzahl unterschiedlicher Strings in der Stringtabelle,
- sowie ihre Groesse
- - int DID_ST_STR_TABLE_SIZE
- Groesse der String Tabelle
- - int DID_ST_STR_REQ
- - int DID_ST_STR_REQ_SIZE
- Gesamte Anzahl von String Allokationen, und ihre
- Groesse
- - int DID_ST_STR_SEARCHES
- - int DID_ST_STR_SEARCH_LEN
- Anzahl Suchvorgaenge in der Stringtabelle und die
- Gesamtlaenge des Suchstrings
- - int DID_ST_STR_FOUND
- Anzahl erfolgreicher Suchvorgaenge
- - int DID_ST_STR_ENTRIES
- Anzahl Eintraege (Hash Ketten) in der String Tabelle
- - int DID_ST_STR_ADDED
- Anzahl zur String Tabelle bisher hinzugefuegter
- Strings
- - int DID_ST_STR_DELETED
- Anzahl aus der String Tabelle bisher geloeschter
- Strings
- - int DID_ST_STR_COLLISIONS
- Anzahl zu einer existierenden Hash Kette hinzugefuegte
- Strings
- - int DID_ST_RX_CACHED
- Anzahl gecacheter regulaerer Ausdruecke (regular
- expressions)
- - int DID_ST_RX_TABLE
- - int DID_ST_RX_TABLE_SIZE
- Anzahl Plaetze in der Regexp Cache Tabelle und
- Speicherbedarf der gecacheten Ausdruecke
- - int DID_ST_RX_REQUESTS
- Anzahl Anfragen fuer neue regexps
- - int DID_ST_RX_REQ_FOUND
- Anzahl gefundener regexps in der regexp Cache Tabelle
- - int DID_ST_RX_REQ_COLL
- Anzahl angefragter regexps, die mit einer bestehenden
- regexp kollidierten
- - int DID_ST_MB_FILE
- Die Groesse des 'File' Speicherpuffers
- - int DID_ST_MB_SWAP
- Die Groesse des 'Swap' Speicherpuffers
-
- <arg2> == DID_SWAP (1): Liefert "status swap"-Information:
- - int DID_SW_PROGS
- - int DID_SW_PROG_SIZE
- Anzahl und Groesse der geswappten Programmbloecke
- - int DID_SW_PROG_UNSWAPPED
- - int DID_SW_PROG_U_SIZE
- Anzahl und Groesse der nicht geswappten Bloecke
- - int DID_SW_VARS
- - int DID_SW_VAR_SIZE
- Anzahl und Groesse der geswappten Variablenbloecke
- - int DID_SW_FREE
- - int DID_SW_FREE_SIZE
- Anzahl und Groesse der freien Bloecke in der
- Auslagerungsdatei
- - int DID_SW_FILE_SIZE
- Groesse der Auslagerungsdatei
- - int DID_SW_REUSED
- Gesamter wiederverwendeter Speicherplatz in der
- Auslagerungsdatei
- - int DID_SW_SEARCHES
- - int DID_SW_SEARCH_LEN
- Anzahl und Gesamtlaenge der Suchvorgaenge nach
- wiederverwendbaren Bloecken in der Auslagerungsdatei
- - int DID_SW_F_SEARCHES
- - int DID_SW_F_SEARCH_LEN
- Anzahl und Gesamtlaenge der Suchvorgaenge nach einem
- Block, der frei gemacht werden kann.
- - int DID_SW_COMPACT
- TRUE wenn der Swapper im Compact-Modus laeuft
- - int DID_SW_RECYCLE_FREE
- TRUE wenn der Swapper gerade einen freien Block
- wiederverwendet
-
- <arg2> == DID_MEMORY (2): Liefert die "status malloc"-Information:
- - string DID_MEM_NAME
- Der Name des Allokators: "sysmalloc", "smalloc",
- "slaballoc"
- - int DID_MEM_SBRK
- - int DID_MEM_SBRK_SIZE
- Anzahl und Groesse der Speicherbloecke, die vom
- Betriebssystem angefordert wurden (smalloc, slaballoc)
- - int DID_MEM_LARGE
- - int DID_MEM_LARGE_SIZE
- - int DID_MEM_LFREE
- - int DID_MEM_LFREE_SIZE
- Anzahl und Groesse der grossen allozierten bzw.
- freien Bloecke (smalloc, slaballoc)
- - int DID_MEM_LWASTED
- - int DID_MEM_LWASTED_SIZE
- Anzahl und Groesse der unbrauchbaren grossen
- Speicherfragmente (smalloc, slaballoc)
- - int DID_MEM_CHUNK
- - int DID_MEM_CHUNK_SIZE
- Anzahl und Groesse kleiner Speicherbloecke (chunk
- blocks; smalloc, slaballoc)
- - int DID_MEM_SMALL
- - int DID_MEM_SMALL_SIZE
- - int DID_MEM_SFREE
- - int DID_MEM_SFREE_SIZE
- Anzahl und groesse der allozierten bzw. freien
- kleinen Speicherbloecke (smalloc, slaballoc)
- - int DID_MEM_SWASTED
- - int DID_MEM_SWASTED_SIZE
- Anzahl und Groesse der unbrauchbar kleinen
- Speicherfragmente (smalloc, slaballoc)
- - int DID_MEM_MINC_CALLS
- - int DID_MEM_MINC_SUCCESS
- - int DID_MEM_MINC_SIZE
- Anzahl Aufrufe von malloc_increment(), Anzahl der
- erfolgreichen Aufrufe und die Groesse des auf diese
- Art allozierten Speichers (smalloc, slaballoc)
- - int DID_MEM_PERM
- - int DID_MEM_PERM_SIZE
- Anzahl und Groesse permanenter (non-GCable)
- Allokationen (smalloc, slaballoc)
- - int DID_MEM_CLIB
- - int DID_MEM_CLIB_SIZE
- Anzahl und Groesse der Allokationen durch Clib
- Funktionen (nur smalloc, slaballoc mit SBRK_OK)
- - int DID_MEM_OVERHEAD
- Overhead fuer jede Allokation (smalloc, slaballoc)
- - int DID_MEM_ALLOCATED
- Der Speicher, der durch die Speicherverwaltung
- alloziert wurde, inklusive den Overhead fuer die
- Speicherverwaltung (smalloc, slaballoc)
- - int DID_MEM_USED
- Der Speicher, der durch den Driver belegt ist, ohne
- den durch die Speicherverwaltung belegten Speicher
- (smalloc, slaballoc)
- - int DID_MEM_TOTAL_UNUSED
- Der Speicher, der vom System zur Verfuegung gestellt,
- aber vom Treiber nicht benoetigt wird.
- - int DID_MEM_AVL_NODES (smalloc, slaballoc)
- Anzahl der AVL-Knoten, die zur Verwaltung der
- freien grossen Speicherbloecke verwendet werden
- (nur smalloc). Dieser Wert kann in Zukunft
- wieder verschwinden.
- - mixed * DID_MEM_EXT_STATISTICS (smalloc, slaballoc)
- Detaillierte Statistiken des Allokators sofern
- diese aktiviert wurden; 0 anderenfalls.
-
- Dieser Wert kann in Zukunft wieder verschwinden.
-
- Das Array enthaelt NUM+2 Eintraege, wobei NUM
- Anzahl der verschiedenen 'kleinen'
- Blockgroessen ist. Eintrag [NUM] beschreibt
- die uebergrossen 'kleinen' Bloecke, Eintrag
- [NUM+1] beschreibt summarisch die 'grossen'
- Bloecke. Jeder Eintrag ist ein Array mit
- diesen Feldern:
-
- int DID_MEM_ES_MAX_ALLOC:
- Maximale Anzahl allokierter Bloecke dieser
- Groesse.
-
- int DID_MEM_ES_CUR_ALLOC:
- Derzeitige Anzahl allokierter Bloecke dieser
- Groesse.
- Current number of allocated blocks of this size.
-
- int DID_MEM_ES_MAX_FREE:
- Maximale Anzahl freier Bloecke dieser
- Groesse.
-
- int DID_MEM_ES_CUR_FREE:
- Derzeitige Anzahl freier Bloecke dieser
- Groesse.
-
- float DID_MEM_ES_AVG_XALLOC:
- Durchschnittliche Zahl von Allokationen pro
- Sekunde.
-
- float DID_MEM_ES_AVG_XFREE:
- Durchschnittliche Zahl von Deallokationen pro
- Sekunde.
-
- Die Durchschnittsstatistiken schliessen interne
- Umsortierungen der Blocklisten nicht ein.
-
-
- DINFO_TRACE (7): Liefert die 'trace' Information aus dem
- Call Stack entsprechend der Spezifikation in <arg2>. Das Resultat
- ist entweder ein Array (dessen Format nachstehend erlaeutert ist)
- oder ein druckbarer String. Wird <arg2> weggelasen entspricht
- dies DIT_CURRENT.
-
- <arg2> == DIT_CURRENT (0): Momentaner Call Trace
- == DIT_ERROR (1): Letzter Fehler Trace (caught oder
- uncaught)
- == DIT_UNCAUGHT_ERROR (2): Letzer Fehler Trace, der nicht
- gefangen werden konnte (uncaught)
-
- Die Information wird in Form eines Array uebergeben.
-
- Die Fehlertraces werden nur geaendert, wenn ein entsprechender
- Fehler auftritt; ausserdem werden sie bei einem GC (Garbage
- Collection) geloescht. Nach einem Fehler, der nicht gefangen
- werden konnte (uncaught error), weisen beide Traces auf das
- gleiche Array, sodass der ==-Operator gilt.
-
- Wenn das Array mehr als ein Element enthaelt, ist das erste
- Element 0 oder der Name des Objekts, dessen heart_beat() den
- laufenden Zyklus begonnen hat; alle nachfolgenden Elemente
- bezeichnen den Call Stack, beginnen mit der hoechsten
- aufgerufenen Funktion.
-
- Alle Eintraege im Array sind wiederum Arrays mit folgenden
- Elementen:
- - int[TRACE_TYPE]: Der Typ der aufrufenden Funktion
- TRACE_TYPE_SYMBOL (0): ein Funktionssymbol (sollte nicht
- vorkommen)
- TRACE_TYPE_SEFUN (1): eine simul-efun
- TRACE_TYPE_EFUN (2): eine Efun Closure
- TRACE_TYPE_LAMBDA (3): eine lambda Closure
- TRACE_TYPE_LFUN (4): eine normale Lfun
- - int[TRACE_NAME]
- _TYPE_EFUN : entweder der Name der Funktion oder der
- Code einer Operator-Closure
- _TYPE_LAMBDA : die numerische Lambda-ID
- _TYPE_LFUN : der Name der Lfun
- - string[TRACE_PROGRAM]: Der Name des Programms mit dem Code
- - string[TRACE_OBJECT]: Der Name des Objekts, fuer das der
- Code ausgefuehrt wurde
- - int[TRACE_LOC]:
- _TYPE_LAMBDA : Der Offset des Programms seit Beginn des
- Closure-Codes
- _TYPE_LFUN : Die Zeilennummer.
-
- <arg2> == DIT_STR_CURRENT (3): Liefert Informationen ueber den
- momentanen Call Trace als druckbarer String.
-
- <arg2> == DIT_CURRENT_DEPTH (4): Liefert die Zahl der Frames auf
- dem Control Stack (Rekursionstiefe).
-
- DINFO_EVAL_NUMBER (8): gibt die Nummer der aktuellen Berechnung
- zurueck. Diese Nummer wird fuer jeden vom driver initiierten
- Aufruf von LPC-Code erhoeht, also bei Aufruf von:
- - Kommandos (die per add_action hinzugefuegt wurden)
- - heart_beat, reset, clean_up
- - Aufrufe durch call_out oder input_to
- - master applies, die auf externe Ereignisse zurueckgehen
- - driver hooks genauso
- - Rueckrufen von send_erq
- - logon in interaktiven Objekten
-
- Dieser Zaehler kann z.B. benutzt werden, um zu verhindern, dass
- bestimmte Aktionen mehrfach innerhalb eines heart_beat()
- ausgefuehrt werden. Eine andere Anwendungsmoeglichkeit sind
- Zeitstempel zur Sortierung zur Sortierung von Ereignissen.
-
- Es ist zu beachten, dass der Zaehler ueberlaufen kann, insbesondere
- auf 32-bit-Systemen. Er kann demzufolge auch negativ werden.
-
-
-GESCHICHTE
-==========
-
- Seit 3.2.7 liefert DINFO_STATUS die Information zurueck, anstatt sie
- nur auszugeben.
- DINFO_DUMP wurde in 3.2.7 eingefuehrt.
- LDMud 3.2.8 fuegte die Datengroesse des Objekts zum Resultat von
- DINFO_MEMORY hinzu, ausserdem die DINFO_DATA Abfrage und die
- verschiedenen DID_MEM_WASTED Statistiken.
- LDMud 3.2.9 fuegte DINFO_TRACE, das Indizierungs-Feature von
- DINFO_DATA, den 'destructed'-DINFO_DUMP, die DID_MEM_CLIB*,
- die DID_MEM_PERM*, ausserdem DID_ST_OBJECTS_NEWLY_DEST,
- DID_ST_OBJECTS_DEST, DID_MEM_OVERHEAD, DID_MEM_ALLOCATED,
- DID_MEM_USED, DID_MEM_TOTAL_UNUSED, DID_ST_HBEAT_CALLS_TOTAL
- und die found / added / collision Stringstatistiken.
- LDMud 3.2.10 fuegte die Erzeugungszeit zu DINFO_DUMP:"objects" hinzu,
- entfernte DID_MEM_UNUSED aus DINFO_DATA:DID_MEMORY, fuegte
- DINFO_DATA:DID_STATUS DID_ST_BOOT_TIME, DID_ST_MB_FILE und
- DID_ST_MB_SWAP hinzu und entfernte DID_ST_CALLOUT_SLOTS daraus,
- fuegte das dritte Argument zu DINFO_OBJLIST hinzu, und veraenderte
- die Bedeutung von DID_ST_CALLOUT_SIZE und DID_ST_HBEAT_SIZE
- bzw. _SLOTS.
- LDMud 3.3.533 fuegte DID_MEM_AVL_NODES zu DINFO_DATA:DID_MEMORY
- hinzu.
- LDMud 3.3.603 fuegte DID_MEM_EXT_STATISTICS zu DINFO_DATA:DID_MEMORY
- hinzu.
- LDMud 3.3.718 fuegte DIT_CURRENT_DEPTH to DINFO_TRACE hinzu.
- LDMud 3.3.719 fuegte DINFO_EVAL_NUMBER hinzu.
-
-
-SIEHE AUCH
-==========
-
- trace(E), traceprefix(E), malloc(D), status(D), dumpallobj(D)
diff --git a/doc/sphinx/man/sefun/deep_present b/doc/sphinx/man/sefun/deep_present
deleted file mode 100644
index c3f673a..0000000
--- a/doc/sphinx/man/sefun/deep_present
+++ /dev/null
@@ -1,40 +0,0 @@
-
-deep_present()
-**************
-
-
-FUNKTION
-========
-
- object deep_present(string what)
- object deep_present(object what)
- object deep_present(string what, object ob)
- object deep_present(object what, object ob)
-
-
-ARGUMENTE
-=========
-
- what - Objekt oder ID des Objektes, nach dem gesucht werden soll
- ob - Objekt, in dem gesucht werden soll
-
-
-BESCHREIBUNG
-============
-
- deep_present() sucht in this_object() (oder in ob, falls angegeben)
- nach dem Objekt what oder einem Objekt, das auf what anspricht.
- Im Gegensatz zu present() wird aber das komplette Inventory berueck-
- sichtigt (also zB. auch der Inhalt von Beuteln).
-
-
-RUECKGABEWERT
-=============
-
- das gefundene Objekt oder 0
-
-
-SIEHE AUCH
-==========
-
- present(E)
diff --git a/doc/sphinx/man/sefun/dtime b/doc/sphinx/man/sefun/dtime
deleted file mode 100644
index dac7dd0..0000000
--- a/doc/sphinx/man/sefun/dtime
+++ /dev/null
@@ -1,49 +0,0 @@
-
-dtime()
-*******
-
-
-FUNKTION
-========
-
- string dtime(int time)
-
-
-ARGUMENTE
-=========
-
- time - Umzuwandelndes Datum in Sekunden seit 1.1.1970, 0:0:0h
-
-
-BESCHREIBUNG
-============
-
- Wandelt das Datum time in einen deutschsprachigen String der Form
- "<wtag>, <tag>. <mon> <jahr>, <std>:<min>:<sek>" um.
-
-
-RUECKGABEWERT
-=============
-
- Der String mit dem umgewandelten Datum.
-
-
-BEMERKUNGEN
-===========
-
- Als time wird meistens das Ergebnis von time() benutzt.
- strftime() stellt eine wesentlich flexiblere Moeglichkeit der Ausgabe von
- Zeiten dar.
-
-
-BEISPIELE
-=========
-
- datum = dtime(time());
- => datum = "Mon, 6. Mar 1994, 15:00:08"
-
-
-SIEHE AUCH
-==========
-
- ctime(E), strftime(E), time(E)
diff --git a/doc/sphinx/man/sefun/dump_netdead b/doc/sphinx/man/sefun/dump_netdead
deleted file mode 100644
index b5b480a..0000000
--- a/doc/sphinx/man/sefun/dump_netdead
+++ /dev/null
@@ -1,29 +0,0 @@
-
-dump_netdead()
-**************
-
-
-FUNKTION
-========
-
- string *dump_netdead()
-
-
-BESCHREIBUNG
-============
-
- Gibt ein Array mit den Namen aller zur Zeit netztoten Spieler
- zurueck.
-
-
-RUECKGABEWERT
-=============
-
- Ein Stringarray mit den Namen der netztoten Spieler.
- gibt.
-
-
-SIEHE AUCH
-==========
-
- find_netdead(E)
diff --git a/doc/sphinx/man/sefun/enable_commands b/doc/sphinx/man/sefun/enable_commands
deleted file mode 100644
index 593fb31..0000000
--- a/doc/sphinx/man/sefun/enable_commands
+++ /dev/null
@@ -1,42 +0,0 @@
-
-enable_commands()
-*****************
-
-
-SYNOPSIS
-========
-
- void enable_commands();
-
-
-BESCHREIBUNG
-============
-
- Erlaubt dem Objekt, Kommandos zu verwenden, die normalerweise Usern
- zugaenglich sind. Der Aufruf markiert das Objekt als "living". Dies
- wird fuer Spieler und alle von /std/npc abgeleiteten Objekte
- bereits von der Mudlib erledigt und sollte nicht nochmals gemacht
- werden.
-
- Diese Funktion darf nicht ausserhalb von create() (oder reset(0) im
- Compat-Modus) aufgerufen werden, weil der Kommandogeber auf dieses
- Objekt gesetzt wird.
-
-
-BEISPIEL
-========
-
- void create()
- {
- enable_commands();
- ...
- }
-
- Dies markiert das Objekt als "living".
-
-
-SIEHE AUCH
-==========
-
- command(E), living(E), disable_commands(E), native(C), hooks(C)
- set_living_name(E)
diff --git a/doc/sphinx/man/sefun/file_time b/doc/sphinx/man/sefun/file_time
deleted file mode 100644
index ddaefce..0000000
--- a/doc/sphinx/man/sefun/file_time
+++ /dev/null
@@ -1,13 +0,0 @@
-
-file_time()
-***********
-
-
-FUNKTION
-========
-
- int file_time(string filename);
-
-Liefert den Zeitpunkt der letzten Modifikation des Files in Sekunden
-seit dem 1.1.1970, 0:00. Kann per ctime() in ein lesbares Format
-gebracht werden.
diff --git a/doc/sphinx/man/sefun/find_living b/doc/sphinx/man/sefun/find_living
deleted file mode 100644
index 5930695..0000000
--- a/doc/sphinx/man/sefun/find_living
+++ /dev/null
@@ -1,42 +0,0 @@
-
-find_living()
-*************
-
-
-SYNOPSIS
-========
-
- object find_living(string str)
-
-
-BESCHREIBUNG
-============
-
- Findet das erste "lebende" Objekt, welches per set_living_name() den
- Namen <str> setzte.
-
-
-
- Das Objekt muss ausserdem per enable_commands() als Lebewesen
- markiert worden sein. Dies ist fuer alle von /std/npc erbenden NPCs
- _automatisch_ der Fall und sollte daher nicht nochmal explizit gemacht
- werden.
-
-
-BEISPIEL
-========
-
- object ob;
- ob = find_living("Public Enemy");
-
-
-SIEHE AUCH
-==========
-
- find_player(E), enable_commands(E), set_living_name(E)
-
-
-LETZTE AeNDERUNG
-================
-
-09.10.2011, Zesstra
diff --git a/doc/sphinx/man/sefun/find_livings b/doc/sphinx/man/sefun/find_livings
deleted file mode 100644
index 7f8f9b1..0000000
--- a/doc/sphinx/man/sefun/find_livings
+++ /dev/null
@@ -1,49 +0,0 @@
-
-find_livings()
-**************
-
-
-FUNKTION
-========
-
- object *find_livings(string name)
-
-
-ARGUMENTE
-=========
-
- name - der living_name der gesuchten Lebewesen
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion liefert ein Array mit allen Lebewesen, die den gleichen
- living_name haben.
-
-
-RUECKGABEWERT
-=============
-
- Array mit den Lebewesen oder 0, wenn es kein Lebewesen diesen Namens
- gibt.
-
-
-BEISPIELE
-=========
-
- ob = find_livings("herkules");
- => ob = ({ [/human:herkules],
- [/d/inseln/wargon/luftschloss/mon/herkules] })
-
-
-SIEHE AUCH
-==========
-
- find_living(E), set_living_name(E), find_player(E), find_netdead(E)
-
-
-LETZTE AENDERUNG
-================
-
-19. Okt. 2015, Arathorn
diff --git a/doc/sphinx/man/sefun/find_netdead b/doc/sphinx/man/sefun/find_netdead
deleted file mode 100644
index 8686436..0000000
--- a/doc/sphinx/man/sefun/find_netdead
+++ /dev/null
@@ -1,46 +0,0 @@
-
-find_netdead()
-**************
-
-
-FUNKTION
-========
-
- object find_netdead(string name)
-
-
-ARGUMENTE
-=========
-
- name - Name des gesuchten Spielers
-
-
-BESCHREIBUNG
-============
-
- Falls der Spieler name netztot ist, liefert diese Funktion das Spieler-
- objekt zurueck.
-
- Akzeptiert auch die UUID statt einer UID. In diesem Fall erfolgt aber
- nur eine Pruefung, ob die UID des gefundenen Spielers zur angegebenen
- UUID passt (d.h. "jof_-1" wuerde dann ggf. auch das Spielerobjekt Jof
- zurueckliefern, wenn das die UUID "Jof_1234" hat).
-
-
-RUECKGABEWERT
-=============
-
- Der netztote Spieler oder 0, falls es keinen Netztoten diesen Namens
- gibt.
-
-
-SIEHE AUCH
-==========
-
- find_living(E), find_player(E)
-
-
-LETZT AeNDERUNG
-===============
-
-06.01.2009, Zesstra
diff --git a/doc/sphinx/man/sefun/find_player b/doc/sphinx/man/sefun/find_player
deleted file mode 100644
index 048b105..0000000
--- a/doc/sphinx/man/sefun/find_player
+++ /dev/null
@@ -1,60 +0,0 @@
-
-find_player()
-*************
-
-
-FUNKTION
-========
-
- object find_player(string uid)
-
-
-BESCHREIBUNG
-============
-
- Findet den Spieler mit dem Namen bzw. der User-ID <uid>.
-
-
-
- Akzeptiert auch die UUID statt einer UID. In diesem Fall erfolgt aber
- nur eine Pruefung, ob die UID des gefundenen Spielers zur angegebenen
- UUID passt (d.h. "jof_-1" wuerde dann ggf. auch das Spielerobjekt Jof
- zurueckliefern, wenn das die UUID "Jof_1234" hat).
-
- Rueckgabewert ist das Spielerobjekt (wenn Spieler anwesend),
- ansonsten 0.
-
-
-BEISPIEL
-========
-
- object ob;
- ob = find_player("deepthought");
-
- if(ob)
- tell_object(ob,"Tach Du!\n");
-
- oder auch
-
- if(ob = find_player("deepthought"))
- tell_object(ob,"Tach Du!\n");
-
-
-ANMERKUNGEN
-===========
-
- Via find_player() werden auch unsichtbare Magier gefunden. In
- Objekten, die fuer Spieler gedacht sind, muss dies dann extra
- per Abfrage auf if(ob->QueryProp(P_INVIS)) getestet werden.
-
- Netztote Spieler und Monster werden nicht gefunden da find_player
- den Namen aus set_living_name() verwendet, der in player.c ge-
- setzt wird.
-
-
-SIEHE AUCH
-==========
-
- find_living(E), set_living_name(E), find_object(E), find_netdead(E)
-
-Letzte Aenderung: 06.01.2009, Zesstra
diff --git a/doc/sphinx/man/sefun/getuuid b/doc/sphinx/man/sefun/getuuid
deleted file mode 100644
index 63ea31e..0000000
--- a/doc/sphinx/man/sefun/getuuid
+++ /dev/null
@@ -1,29 +0,0 @@
-
-getuuid()
-*********
-
-
-SYNOPSIS
-========
-
- string getuuid(object ob)
-
-
-DESCRIPTION
-===========
-
- Liefert eine eindeutige (get unique uid) UID fuer einen Spieler.
- Wird zusammengesetzt aus der UID des Spielers und seinem
- Erstlogin-Datum.
-
- Nach einer Selbstloeschung und neuem Login erhaelt der Spieler eine
- neue UUID, bei einer Restaurierung behaelt er seine alte UUID.
-
- Wenn die Funktion ohne Parameter aufgerufen wird, wird per Default
- this_object() genommen.
-
-
-SEE ALSO
-========
-
- getuid(E)
diff --git a/doc/sphinx/man/sefun/iso2ascii b/doc/sphinx/man/sefun/iso2ascii
deleted file mode 100644
index bd64d73..0000000
--- a/doc/sphinx/man/sefun/iso2ascii
+++ /dev/null
@@ -1,32 +0,0 @@
-
-iso2ascii()
-***********
-
-
-FUNKTION
-========
-
- public string iso2ascii( string str );
-
-
-ARGUMENTE
-=========
-
- str
- String, in welchem Zeichen ersetzt werden sollen.
-
-
-BESCHREIBUNG
-============
-
- In dem String werden alle Nicht-ASCII-Zeichen durch ASCII-Zeichen
- ersetzt, und zwar Umlaute in der bekannten Form und alle anderen
- durch ein Fragezeichen.
-
-
-RUeCKGABEWERT
-=============
-
- String mit ASCII-Zeichen.
-
-Last modified: Fri Jul 6 19:36:09 2001 by Patryn
diff --git a/doc/sphinx/man/sefun/log_file b/doc/sphinx/man/sefun/log_file
deleted file mode 100644
index a3f3cab..0000000
--- a/doc/sphinx/man/sefun/log_file
+++ /dev/null
@@ -1,59 +0,0 @@
-
-log_file()
-**********
-
-
-FUNKTION
-========
-
- int log_file(string file, string text)
- int log_file(string file, string text, int size_to_break)
-
-
-ARGUMENTE
-=========
-
- file - Name der Datei, in die geschrieben werden soll
- text - Der Text, der geschrieben werden soll
- size_to_break - Groesse, ab der ein neues File begonnen wird (optional)
-
-
-BESCHREIBUNG
-============
-
- log_file schreibt den Text text in die Datei /log/file.
- Sollte file schon mit einem /log/ beginnen, wird kein erneutes /log/ davor
- eingefuegt.
-
-
-RUECKGABEWERT
-=============
-
- 1 bei Erfolg oder 0, falls ein Fehler beim Schreiben auftrat.
-
-
-BEMERKUNGEN
-===========
-
- Wenn die Groesse von file vor dem Schreiben 50000 Bytes ueberschreitet,
- wird sie in file.old umbenannt. Eine schon vorhandene Datei file.old
- wird dabei geloescht. Der Text wird nach dem Umbenennen geschrieben.
- Wird 'size_to_break' angegeben und ist dies > 0, wird dieser Wert (in
- Bytes) statt der 50000 Bytes zum Rotieren des Logfiles benutzt.
-
-
-BEISPIELE
-=========
-
- log_file( "report/wargon.rep", "TYPO von bla in blubb:\ntest\n");
- In /log/report/wargon.rep finde ich nun die neueste Typomeldung... ;)
- log_file( "/log/report/wargon.rep", "TYPO von bla in blubb:\ntest\n");
- Gleiches Ergebnis. ;-)
-
-
-SIEHE AUCH
-==========
-
- write_file(E)
-
-29.01.2017, Zesstra
diff --git a/doc/sphinx/man/sefun/lowerchar b/doc/sphinx/man/sefun/lowerchar
deleted file mode 100644
index 8e6cfdd..0000000
--- a/doc/sphinx/man/sefun/lowerchar
+++ /dev/null
@@ -1,42 +0,0 @@
-
-lowerchar()
-***********
-
-
-FUNKTION
-========
-
- int lowerchar(int char)
-
-
-ARGUMENTE
-=========
-
- char - Das umzuwandelnde Zeichen
-
-
-BESCHREIBUNG
-============
-
- Wenn char ein Grossbuchstabe ist, so wird es in einen Kleinbuchstaben
- umgewandelt. Andere Zeichen werden von dieser Funktion nicht beein-
- flusst.
-
-
-RUECKGABEWERT
-=============
-
- Das umgewandelte Zeichen.
-
-
-BEISPIELE
-=========
-
- printf("%c\n", lowerchar('A')); => a
- printf("%c\n", lowerchar('1')); => 1
-
-
-SIEHE AUCH
-==========
-
- lower_case(E), lowerstring(E), upperstring(E), capitalize(E)
diff --git a/doc/sphinx/man/sefun/lowerstring b/doc/sphinx/man/sefun/lowerstring
deleted file mode 100644
index a483224..0000000
--- a/doc/sphinx/man/sefun/lowerstring
+++ /dev/null
@@ -1,45 +0,0 @@
-
-lowerstring()
-*************
-
-
-FUNKTION
-========
-
- string lowerstring(string str)
-
-
-ARGUMENTE
-=========
-
- str - Der umzuwandelnde String.
-
-
-BESCHREIBUNG
-============
-
- Alle Grossbuchstaben in str werden in Kleinbuchstaben umgewandelt.
-
-
-RUECKGABEWERT
-=============
-
- Der umgewandelte String.
-
-
-BEMERKUNGEN
-===========
-
- lowerstring ist mit lower_case identisch!
-
-
-BEISPIELE
-=========
-
- s = lowerstring("So, McLaud...\n"); => s = "so, mclaud...\n"
-
-
-SIEHE AUCH
-==========
-
- lower_case(E), lowerchar(E), upperstring(E), capitalize(E)
diff --git a/doc/sphinx/man/sefun/m_copy_delete b/doc/sphinx/man/sefun/m_copy_delete
deleted file mode 100644
index 9aa90f2..0000000
--- a/doc/sphinx/man/sefun/m_copy_delete
+++ /dev/null
@@ -1,68 +0,0 @@
-
-m_copy_delete()
-***************
-
-
-FUNKTION
-========
-
- mapping m_copy_delete(mapping map, mixed key)
-
-
-ARGUMENTE
-=========
-
- map - das Mapping, aus dem geloescht werden soll.
- key - der zu loeschende Eintrag
-
-
-BESCHREIBUNG
-============
-
- Aus dem Mapping map wird der Eintrag key geloescht (wenn er in map vor-
- handen ist). map wird dabei nicht veraendert.
-
-
-RUECKGABEWERT
-=============
-
- Eine (flache !) Kopie von map ohne den Eintrag key, d.h. enthaltene
- Mappings/Arrays werden nicht kopiert.
-
-
-BEMERKUNGEN
-===========
-
- Das urspruengliche Mapping wird bei dieser Operation nicht veraendert!
- Wenn man nur einen Wert aus dem Mapping loeschen will und die Kopie nicht
- braucht, bietet sich efun::m_delete(mapping,key) sehr an, da die Erstellung
- einer Kopie sehr aufwendig sein kann.
-
-
-BEISPIELE
-=========
-
- mapping m1, m2;
-
- m1 = ([ "a":1, "b":2, "c":3 ]);
-
- m2 = m_copy_delete(m1, "b");
- => m1 = ([ "a":1, "b":2, "c":3 ])
- m2 = ([ "a":1, "c":3 ])
-
- m_copy_delete(m1, "a");
- => (es hat sich nichts geaendert)
-
- m1 = m_copy_delete(m1, "a");
- => m1 = ([ "b":2, "c":3 ])
-
- Im letzten Fall sollte aber besser efun::m_delete(m1, "a") benutzt
- werden, da ansonsten das Mapping unnoetig kopiert wird und Rechen-
- leistung frisst.
-
-
-SIEHE AUCH
-==========
-
- efun::m_delete(E), mappingp(E), mkmapping(E), m_indices,(E) m_values(E),
- sizeof(E), widthof(E)
diff --git a/doc/sphinx/man/sefun/match_living b/doc/sphinx/man/sefun/match_living
deleted file mode 100644
index 5cb347b..0000000
--- a/doc/sphinx/man/sefun/match_living
+++ /dev/null
@@ -1,52 +0,0 @@
-
-match_living()
-**************
-
-match_living(sefun)
-
-
-FUNKTION
-========
-
- varargs mixed match_living( string str, int players_only,
- string *exclude)
-
-
-ARGUMENTE
-=========
-
- string str - Kuerzel, nach dem die living_names durchsucht
- werden soll
- int players_only - 1, um nur Spieler (Interactives) zu suchen
- string *exlude - welche Namen sollen ignoriert werden
-
-
-BESCHREIBUNG
-============
-
- Sucht alle Lebewesen, deren Namen mit str beginnen.
-
-
-RUECKGABEWERT
-=============
-
- Ein String, falls es ein Lebewesen mit dem Namen str gibt (der Name
- muss genau passen).
- -1, wenn es mehrere Lebewesen gibt, deren Namen mit str beginnen.
- -2, wenn es kein Lebewesen gibt, dessen Name mit str beginnt.
-
-
-BEISPIELE
-=========
-
- match_living("wargon"); => "wargon", wenn Wargon eingeloggt ist.
- match_living("war"); => "wargon", wenn es kein anderes Lebewesen
- gibt, dessen Name mit "war" beginnt.
-
-
-SIEHE AUCH
-==========
-
- find_living(E), find_player(E), find_netdead(E)
-
-27. Mai 2004 Gloinson
diff --git a/doc/sphinx/man/sefun/md5 b/doc/sphinx/man/sefun/md5
deleted file mode 100644
index f48dcc8..0000000
--- a/doc/sphinx/man/sefun/md5
+++ /dev/null
@@ -1,52 +0,0 @@
-
-md5()
-*****
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- string md5 (string arg [ , int iterations ] )
- string md5 (int * arg [ , int iterations ] )
-
-
-BESCHREIBUNG
-============
-
- Berechnet den MD5-Hashwert von <arg>.
- Das Argument kann ein String, oder ein Array von Zahlen sein (von
- welchen nur das unterste Byte betrachted wird).
-
- Das Ergebnis wird als 32-stelliger Hexadezimalwert geliefert.
-
- Ist das <iterations> Argument eine Zahl groesser 0, berechnet der
- Driver den Digest mit diese Anzahl an Wiederholungen. Fehlt die
- Angabe, fuehrt der Driver die Digest-Berechnung einmal aus.
-
-
-BEISPIEL
-========
-
- string s;
-
- s = md5("Hallo");
- s = md5( ({ 'H', 'e', 'l', 'l', 'o' }) )
- s = md5( ({ 'H', 'e', 'l', 'l', 'o' }), 2 )
-
-
-AENDERUNGEN
-===========
-
- Eingefuehrt in LDMud 3.2.9
- LDMud 3.2.12 fuehrte Zaehlenarrays als Argument ein, also auch
- die Anzahl der Wiederholungen.
-
-
-SIEHE AUCH
-==========
-
- crypt(E), md5_crypt(E), sha1(E), hash(E), hmac(E)
diff --git a/doc/sphinx/man/sefun/mkdirp b/doc/sphinx/man/sefun/mkdirp
deleted file mode 100644
index 2bb9d06..0000000
--- a/doc/sphinx/man/sefun/mkdirp
+++ /dev/null
@@ -1,42 +0,0 @@
-
-mkdirp()
-********
-
-
-FUNKTION
-========
-
- int mkdirp(string dir)
-
-
-ARGUMENTE
-=========
-
- dir - Name des zu erstellenden Verzeichnisses (absolut)
-
-
-BESCHREIBUNG
-============
-
- Erzeugt das Verzeichnis <dir>. Dies muss als abs. Pfad angegeben
- werden.
- Wenn noetig, wird die ganze Verzeichnishierarchie rekursiv erstellt.
-
-
-RUECKGABEWERT
-=============
-
- 0 - Verzeichnis konnte nicht erstellt werden
- 1 - Verzeichnis wurde erstellt oder existierte bereits
-
-
-SIEHE AUCH
-==========
-
- mkdir(E)
-
-
-LETZT AeNDERUNG
-===============
-
-26.01.2013, Zesstra
diff --git a/doc/sphinx/man/sefun/notify_fail b/doc/sphinx/man/sefun/notify_fail
deleted file mode 100644
index 85b700a..0000000
--- a/doc/sphinx/man/sefun/notify_fail
+++ /dev/null
@@ -1,107 +0,0 @@
-
-notify_fail()
-*************
-
-
-FUNKTION
-========
-
- #include <notify_fail.h>
-
- varargs void notify_fail(string str, int prio)
- varargs void notify_fail(closure cl, int prio)
-
-
-ARGUMENTE
-=========
-
- str Meldung die an den Spieler anstatt des 'Wie bitte' ausgegeben
- werden soll
- cl Closure, die bei Fehlschlag ausgefuehrt werden soll
- prio Prioritaet dieses Objekts bei diesem Setzen der Meldung
-
-
-BESCHREIBUNG
-============
-
- Merkt sich den angegebenen str und gibt ihn im Falle einer inkorrekten
- Eingabe des Spielers anstatt eines 'Wie bitte' aus.
-
- Gedacht ist notify_fail, um dem Spieler eine bessere Hilfestellung
- bei Kommandos / Eingaben zu geben, um ihn u.U. auf die richtige
- Syntax hinzuweisen.
-
- Wird notify_fail mehrfach (durch verschiedene Objekte o.ae.) auf-
- gerufen, wird der letzte erfolgreiche Aufruf gewertet. Eine Meldung wird
- dann tatsaechlich gesetzt, wenn die Prioritaet dieses Objekts gleich
- gross oder groesser ist als die Prioritaet des Objekts, was das bisher
- gueltige notify_fail() gesetzt hat. Folgende Prioritaeten sind
- vordefiniert und werden automatisch ermittelt:
- NF_NL_OWN 100 // eigenes Objekt (soul) ueberschreibt kaum was
- NF_NL_THING 100000
- NF_NL_ROOM 1000000 // Raeume ueberschreiben sonstigen Krams
- NF_NL_LIVING 10000000 // Lebewesen ueberschreiben auch Raeume
- 2 weitere vordefinierte koennen von Magier angegeben werden:
- NF_NL_NONE -1 // wird von allem ueberschrieben
- NF_NL_MAX __INT_MAX__ // hoechste Prioritaet, ueberschreibt alles
-
- Wird eine Closure als Argument gegeben, wird sie im Fehlerfall
- (also erst wenn ein Kommando endgueltig fehlgeschlagen hat)
- ausgefuehrt und hat die Fehlermeldung als Resultat
- zurueckzugeben. Die Closure erhaelt als Argument den
- originalen Befehlsgeber; in der Regel dies ist this_player(),
- was aber vom MODIFY_CMD hook geaendert werden kann.
-
- notify_fail() erkennt verschachtelte Kommandos (siehe Efun
- command()), und ein notify_fail() in einem Unterkommando
- hat keinen Einfluss auf das uebergeordnete Kommando.
-
-
-BEMERKUNGEN
-===========
-
- - solange man sich nicht absolut sicher ist, dass ein bestimmtes Objekt
- mit dem Kommando gemeint ist (Identifikation ueber id()), sollte man
- - notify_fail(str); return 0;
- nutzen anstatt mit
- - write(str) return 1;
- die Kommandoauswertung abzubrechen (und anderen Objekten die Chance
- zu nehmen das Kommando zu erfuellen)
- - Kommandos werden uebrigens oft erst vom betretenen Raum, dann von den
- Objekten abgearbeitet (je nachdem wann diese dazukamen)
- - die Prioritaet wird momentan nicht gespeichert, sie ist nur beim Setzen
- relevant. Will spaeter ein anderes Objekt eine Meldung setzen, wird
- fuer das eigene Objekt die Standardprioritaet ermittelt, auch wenn man
- eine andere hier uebergeben hat
- - Die NF_NL_* sind in /sys/notify_fail.h defniert.
-
-
-BEISPIELE
-=========
-
- Ein Raum erwartet die korrekte Eingabe von 'iss suppe':
-
- int iss_cmd(string str){
- // zu Anfang der Funktion das notify_fail definieren
- notify_fail("Moechtest Du vielleicht von der Suppe essen?\n");
-
- // Spieler hat nur 'iss' ohne Parameter eingegeben oder einen anderen
- // Parameter angegeben ... Abbruch!
- // Falls kein weiteres Objekt das Kommando erfuellt oder das
- // notify_fail() mit einer eigenen Meldung ueberschreibt, wird obige
- // Meldung an den Spieler ausgegeben.
-
- if(!str || str!="suppe") return 0;
- // ab hier ist die Eingabe dann wirklich 'suppe' und die Funktion
- // kann beliebig fortgefuehrt werden
- ...
- return 1;
-
-
-SIEHE AUCH
-==========
-
- add_action(E), AddCmd(L), AddAction(L),
- query_verb(E), query_notify_fail(E)
-
-8.Aug 2007 Gloinson
diff --git a/doc/sphinx/man/sefun/object_info b/doc/sphinx/man/sefun/object_info
deleted file mode 100644
index bee892e..0000000
--- a/doc/sphinx/man/sefun/object_info
+++ /dev/null
@@ -1,148 +0,0 @@
-
-object_info()
-*************
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- #include <objectinfo.h>
-
- mixed * object_info(object ob, int what)
- mixed * object_info(object ob, int what, int index)
-
-
-DESCRIPTION
-===========
-
- Returns some internal information about object <ob>, collected
- in an array. Argument <what> determines which information is
- returned.
-
- The result is usually an array. However, if <index> is specified,
- the result is the value from position <index> of the array which
- would have been returned normally.
-
- The possible values of <what>, and the indices of the returned
- arrays are defined in the include file <objectinfo.h>, and may
- change in future versions of the driver!
-
-
- <what> == OINFO_BASIC:
-
- This call returns basic information about <ob>:
-
- int [OIB_HEART_BEAT]: 1 if <ob> has a heart_beat, 0 else.
- int [OIB_IS_WIZARD]: 1 if <ob> has the wizard flag set,
- 0 else.
- This entry is always 0 when set_is_wizard() is not available.
- int [OIB_ENABLE_COMMANDS]: 1 if <ob> can give commands, 0 else.
- int [OIB_CLONE]: 1 if <ob> is a clone, 0 else.
- int [OIB_DESTRUCTED]: 1 if <ob> is destructed, 0 else.
- int [OIB_SWAPPED]: 1 if <ob> is swapped, 0 else.
- int [OIB_ONCE_INTERACTIVE]: 1 if <ob> was once interactive, 0 else.
- int [OIB_RESET_STATE]: 1 if <ob> is (still) reset, 0 else.
- int [OIB_WILL_CLEAN_UP]: 1 if <ob> will call clean_up(), 0 else.
- int [OIB_LAMBDA_REFERENCED]: 1 if <ob> has lambdas, 0 else.
- int [OIB_SHADOW]: 1 if <ob> has a shadow structure tied
- to it, 0 if not.
- int [OIB_REPLACED]: 1 if the program for <ob> was replaced,
- 0 else.
- int [OIB_NEXT_RESET]: time of the next reset
- int [OIB_TIME_OF_REF]: time of the last call to <ob>
- int [OIB_NEXT_CLEANUP]: time of the next data cleanup
- int [OIB_REF]: number of references to <ob>
- int [OIB_GIGATICKS] and [OIB_TICKS]: together, these numbers
- give the accumulated evaluation cost spend in <ob>
- int [OIB_SWAP_NUM]: the swap number for <ob>s program,
- or -1 if not swapped.
- int [OIB_PROG_SWAPPED]: 1 if <ob>'s program is swapped, 0 else.
- int [OIB_VAR_SWAPPED]: 1 if <ob>'s variables are swapped, 0 else.
- int [OIB_NAME]: <ob>'s object name.
- int [OIB_LOAD_NAME]: <ob>'s load name.
- object [OIB_NEXT_ALL]: next object in the object list.
- object [OIB_PREV_ALL]: previous object in the object list.
-
-
- <what> == OINFO_POSITION:
-
- This call returns information about <ob>'s position in the
- global list of objects:
-
- object [OIP_NEXT]: next object in the object list.
- object [OIP_PREV]: previous object in the object list.
- int [OIP_POS]: position of <ob> in list, counting from 0 up.
-
- This call can be expensive in computing time.
-
-
- <what> == OINFO_MEMORY:
-
- This call returns information about the program <ob> uses:
-
- int [OIM_REF]: number of references to the program.
- string [OIM_NAME]: name of program.
- int [OIM_PROG_SIZE]: size of the program.
- int [OIM_NUM_FUNCTIONS]: number of functions in the program.
- int [OIM_SIZE_FUNCTIONS]: size needed for the function structs.
- int [OIM_NUM_VARIABLES]: number of variables in the program.
- int [OIM_SIZE_VARIABLES]: size needed for the variable structs.
- int [OIM_NUM_STRINGS]: number of strings in the program.
- int [OIM_SIZE_STRINGS]: size needed for the string pointers.
- int [OIM_SIZE_STRINGS_DATA]: size needed for the string data,
- scaled down according to the extend of
- data sharing.
- int [OIM_SIZE_STRINGS_TOTAL]: unmodified size needed for the
- string data.
- int [OIM_NUM_INCLUDES]: number of included files in the program.
- int [OIM_NUM_INHERITED]: number of inherited programs.
- int [OIM_SIZE_INHERITED]: size needed for the inherit structs.
- int [OIM_TOTAL_SIZE]: total size of the program.
- int [OIM_DATA_SIZE]: total size of the values held in the
- object's variables, scaled down
- according to the extend of data
- sharing.
- int [OIM_DATA_SIZE_TOTAL]: unmodified total size of the values
- held in the object's variables
- int [OIM_NO_INHERIT]: 1 if the program can't be inherited.
- int [OIM_NO_CLONE]: 1 if the program/blueprint can't be
- cloned.
- int [OIM_NO_SHADOW]: 1 if the program's functions can't be
- shadowed.
- int [OIM_SHARE_VARIABLES]: 1 if clones of this program share
- their initial variable values with
- the blueprint.
-
- This call swaps in the program if necessary.
- Note that the OIM_SIZE_xxx entries only give the size spent on
- the structures and pointers, not the size of the variable data,
- function code, and strings themselves.
-
-
-HISTORY
-=======
-
- Introduced in LDMud 3.2.6.
- Changes in LDMud 3.2.7:
- - new basic result OIB_REPLACED.
- - basic result OIB_IS_WIZARD is always 0 if set_is_wizard()
- is not available.
- - basic result OIB_APPROVED is gone.
- LDMud 3.2.8 added OIM_DATA_SIZE to the result of OINFO_MEMORY.
- LDMud 3.2.9 added the index mechanism, OIM_NUM_INCLUDES,
- OIM_NO_INHERIT, OIM_NO_SHADOW, OIM_NO_CLONE, OIM_SIZE_STRINGS_DATA,
- OIM_SIZE_STRINGS_TOTAL, and OIM_DATA_SIZE_TOTAL to the result
- of OINFO_MEMORY.
- LDMud 3.3.378 added the OIM_SHARE_VARIABLES to the result
- of OINFO_MEMORY.
- LDMud 3.3.654 added the OIB_NEXT_CLEANUP to the result of OINFO_BASIC.
-
-
-SEE ALSO
-========
-
- debug_info(E)
diff --git a/doc/sphinx/man/sefun/obsolete/exclude_alist b/doc/sphinx/man/sefun/obsolete/exclude_alist
deleted file mode 100644
index 5d1aace..0000000
--- a/doc/sphinx/man/sefun/obsolete/exclude_alist
+++ /dev/null
@@ -1,11 +0,0 @@
-
-exclude_alist()
-***************
-
-
-SYNOPSIS
-========
-
- mixed *exclude_alist(int i, mixed *alist)
-
-Remove element i from alist.
diff --git a/doc/sphinx/man/sefun/obsolete/remove_alist b/doc/sphinx/man/sefun/obsolete/remove_alist
deleted file mode 100644
index fceac4f..0000000
--- a/doc/sphinx/man/sefun/obsolete/remove_alist
+++ /dev/null
@@ -1,7 +0,0 @@
-
-remove_alist()
-**************
-
-mixed >>*<<remove_alist(mixed key, mixed >>*<<alist)
-
-Removes element associated by key key from alist.
diff --git a/doc/sphinx/man/sefun/old_explode b/doc/sphinx/man/sefun/old_explode
deleted file mode 100644
index 357e838..0000000
--- a/doc/sphinx/man/sefun/old_explode
+++ /dev/null
@@ -1,53 +0,0 @@
-
-old_explode()
-*************
-
-
-FUNKTION
-========
-
- string *old_explode(string str, string del)
-
-
-ARGUMENTE
-=========
-
- str - Der String, der aufgespaltet werden soll.
- del - Der String, nach dem str aufgespalten werden soll.
-
-
-BESCHREIBUNG
-============
-
- Durch Ausschneiden von del wird der String str in ein Array von Strings
- zerlegt. Dieses Array wird anschliessend zuruckgegeben.
-
-
-RUECKGABEWERT
-=============
-
- Das Array mit den Bestandteilen der Zerlegung.
-
-
-BEMERKUNGEN
-===========
-
- Das Verhalten von old_explode() entspricht dem dem explode()-Verhalten,
- das in /doc/efun/explode als "altes" Verhalten bezeichnet wird, d.h.
- Leerstrings an Anfang und Ende des zerlegten Strings werden entfernt!
-
-
-BEISPIELE
-=========
-
- strs = explode( "nimm alles", " "); => strs = ({ "nimm", "alles" })
- strs = explode( "abc", "abc" ); => strs = ({ })
- strs = explode( "ein test", "" ); => strs = ({ "ein test" })
- strs = explode( "a b", "a"); => strs = ({ " b" });
-
-
-SIEHE AUCH
-==========
-
- explode(E), new_explode(E), efun::explode(E), sscanf(E)
- implode(E), regexplode(E)
diff --git a/doc/sphinx/man/sefun/process_call b/doc/sphinx/man/sefun/process_call
deleted file mode 100644
index cd43faf..0000000
--- a/doc/sphinx/man/sefun/process_call
+++ /dev/null
@@ -1,38 +0,0 @@
-
-process_call()
-**************
-
-simul_efun::process_call(E)
-
-
-FUNKTION
-========
-
- int process_call()
-
-
-BESCHREIBUNG
-============
-
- Gibt zurueck, ob die Ausfuehrung zum derzeitigen Zeitpunkt durch
- process_string() ausgerufen wurde.
-
-
-BEISPIELE
-=========
-
- process_string("@@current_long@@");
- ...
- string current_long() {
- if(process_call())
- return("Dieser String wurde durch ein process_string eingefuegt.");
- else return("Du hast die Funktion direkt gerufen!");
- }
-
-
-SIEHE AUCH
-==========
-
- notify_fail(E), process_string(E), replace_personal(E)
-
-28. Maerz 2004 Gloinson
diff --git a/doc/sphinx/man/sefun/process_string b/doc/sphinx/man/sefun/process_string
deleted file mode 100644
index fbc7018..0000000
--- a/doc/sphinx/man/sefun/process_string
+++ /dev/null
@@ -1,77 +0,0 @@
-
-process_string()
-****************
-
-process_string(E)
-
-
-FUNKTION
-========
-
- string process_string(string str)
- string process_string(closure cl)
-
-
-BESCHREIBUNG
-============
-
- Durchsucht den String str nach Vorkommnissen von Substrings, die "Wert
- durch Funktionsaufruf zu ersetzen" andeuten. Die Form ist: @@, gefolgt
- durch einen impliziten Funktionsaufruf.
-
- Der zu ersetzenden Substring hat die Form:
- @@function[:filename][|argument1|argument2]@@
-
- Die entsprechende Funktion muss einen String zurueckgeben, oder der
- process_string() uebergebene String str wird nicht modifiziert.
-
- process_string() arbeitet nicht rekursiv, object_name und argument sind
- optionale Werte.
-
- Falls eine Closure angegeben wurde, wird diese lediglich gerufen
- und nicht gefiltert.
-
-
-ANMERKUNGEN
-===========
-
- - Die Funktion, die gerufen werden soll, _muss_ mit einem Buchstaben
- anfangen, '_' ist nicht moeglich!
- - folgendes Properties und Details werden bei der Abfrage ueber
- process_string() gefiltert:
- P_LONG, P_SHORT, P_READ_MSG, AddReadDetail()-Details und NPC-Chats
- P_INT_LONG ueber int_long(), P_INT_SHORT ueber int_short()
- - die Nutzung kann zu Sicherheitsproblemen fuehren, siehe auch
- process_call()
-
-
-BEISPIEL
-========
-
- // komplette Ersetzung ...
- SetProp(P_LONG,"@@current_long@@");
- ...
- string current_long() {
- if(x) return(break_string("Die Beschreibung."));
- else return(break_string("Die andere Beschreibung."));
- }
-
- -> bei Abfrage: "Die Beschreibung." oder "Die andere Beschreibung."
-
-
- // Teilersetzung
- SetProp(P_SHORT, "Ein @@farbenfun|huebsch@@ Ding");
- ...
- string farbenfun(string str) {
- return(str+" "+"gelbes");
- }
-
- -> bei Abfrage: "Ein huebsch gelbes Ding."
-
-
-SIEHE AUCH
-==========
-
- notify_fail(E), process_call(E), replace_personal(E)
-
-22. Nov. 2006 Arathorn
diff --git a/doc/sphinx/man/sefun/query_editing b/doc/sphinx/man/sefun/query_editing
deleted file mode 100644
index 32358ed..0000000
--- a/doc/sphinx/man/sefun/query_editing
+++ /dev/null
@@ -1,29 +0,0 @@
-
-query_editing()
-***************
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- mixed query_editing(object ob);
-
-
-BESCHREIBUNG
-============
-
- Liefert 1, wenn <ob> interaktiv ist (das heisst, es gibt einen realen
- Benutzer mit einer Socketverbindung zum Mud) und gerade mit ed() eine
- Datei bearbeitet. Wenn ed() mit einem Funktionsnamen als zweites
- Argument aufgerufen wird, wird das Objekt, aus dem ed() aufgerufen
- wurde, geliefert, sonst 0.
-
-
-SIEHE AUCH
-==========
-
- ed(E)
diff --git a/doc/sphinx/man/sefun/query_idle b/doc/sphinx/man/sefun/query_idle
deleted file mode 100644
index 7deccee..0000000
--- a/doc/sphinx/man/sefun/query_idle
+++ /dev/null
@@ -1,21 +0,0 @@
-
-query_idle()
-************
-
-
-SYNOPSIS
-========
-
- int query_idle(object ob);
-
-
-BESCHREIBUNG
-============
-
- Gibt an, seit wie vielen Sekunden ein Player Objekt <ob> idle ist.
-
-
-SIEHE AUCH
-==========
-
- interactive(E)
diff --git a/doc/sphinx/man/sefun/query_input_pending b/doc/sphinx/man/sefun/query_input_pending
deleted file mode 100644
index c40c355..0000000
--- a/doc/sphinx/man/sefun/query_input_pending
+++ /dev/null
@@ -1,27 +0,0 @@
-
-query_input_pending()
-*********************
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- object query_input_pending(object ob);
-
-
-BESCHREIBUNG
-============
-
- Wenn <ob> interaktiv und ein input_to() haengig ist, so liefert die
- Efun das Objekt zurueck, welches den input_to() aufgerfuen hat. Ist
- kein input_to() haengig, liefert die Funktion 0.
-
-
-SIEHE AUCH
-==========
-
- input_to(E), find_input_to(E), input_to_info(E), remove_input_to(E)
diff --git a/doc/sphinx/man/sefun/query_ip_name b/doc/sphinx/man/sefun/query_ip_name
deleted file mode 100644
index 76de80f..0000000
--- a/doc/sphinx/man/sefun/query_ip_name
+++ /dev/null
@@ -1,28 +0,0 @@
-
-query_ip_name()
-***************
-
-
-GESCHUETZT
-==========
-
-
-SYNOPSIS
-========
-
- string query_ip_name(object ob);
-
-
-BESCHREIBUNG
-============
-
- Liefert den IP-Namen des Users <ob> oder des aktuellen Benutzers, wenn
- <ob> nicht angegeben wurde. Der IP-Name wird durch den asynchronen
- Prozess hname ermittelt. Wenn der IP-Name nicht ermittelt werden kann,
- liefert query_ip_name() die IP-Nummer zurueck.
-
-
-SIEHE AUCH
-==========
-
- query_ip_number(E)
diff --git a/doc/sphinx/man/sefun/query_ip_number b/doc/sphinx/man/sefun/query_ip_number
deleted file mode 100644
index d09bc88..0000000
--- a/doc/sphinx/man/sefun/query_ip_number
+++ /dev/null
@@ -1,43 +0,0 @@
-
-query_ip_number()
-*****************
-
-
-GESCHUETZT
-==========
-
-
-SYNOPSIS
-========
-
- string query_ip_number(object ob);
- string query_ip_number(mixed & ob);
-
-
-BESCHREIBUNG
-============
-
- Liefert die IP-Nummer des Benutzers <ob> oder des aktuellen Benutzers,
- wenn <ob> nicht angegeben wurde.
-
- Wenn <ob> als Referenz angegeben wird (dann muss es ein gueltiges
- Objekt sein), wird dieses bei der Ausgabe auf die struct sockaddr_in
- gesetzt. struct sockaddr_in ist ein Integer-Array, mit einem Integer
- pro Adressbyte:
-
- ob[0 .. 1] : sin_family
- ob[2 .. 3] : sin_port
- ob[4 .. 7] : sin_addr
- ob[8 ..15] : nicht definiert.
-
-
-AENDERUNGEN
-===========
-
- Die Rueckgabe von struct sockaddr_in wurde in 3.2.1@81 eingefuehrt.
-
-
-SIEHE AUCH
-==========
-
- query_ip_name(E)
diff --git a/doc/sphinx/man/sefun/query_limits b/doc/sphinx/man/sefun/query_limits
deleted file mode 100644
index 8af988f..0000000
--- a/doc/sphinx/man/sefun/query_limits
+++ /dev/null
@@ -1,82 +0,0 @@
-
-query_limits()
-**************
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- #include <sys/rtlimits.h>
-
- int *query_limits();
- int *query_limits(int default);
-
-
-BESCHREIBUNG
-============
-
- Liefert ein Array mit den momentan gueltigen Laufzeit Limiten bzw.
- die standardmaessigen Laufzeit Limiten, wenn <default> wahr ist.
- Die Eintraege im gelieferten Array bedeuten:
-
- int[LIMIT_EVAL]: die maximalen Eval Kosten
- int[LIMIT_ARRAY]: die maximale Anzahl Array Eintraege
- int[LIMIT_MAPPING]: die maximale Anzahl Mapping Eintraege
- int[LIMIT_BYTE]: die maximale Anzahl Bytes, die mit read_bytes()
- /write_bytes() bearbeitet werden koennen
- int[LIMIT_FILE]: die maximale Anzahl Bytes, die mit read_file()
- /write_file() bearbeitet werden koennen
- int[LIMIT_CALLOUTS]: die maximale Anzahl gleichzeitiger call_out()s
- int[LIMIT_COST]: wie die aktuellen Kosten einzurechnen sind
-
- Ausser fuer LIMIT_COST ein Limit von '0' (auch LIMIT_UNLIMITED)
- bedeutet 'keine Limit'.
-
- LIMIT_COST hat diese Bedeutungen:
-
-
-
- wert > 0: Maximal <wert> fuer als Kosten fuer die aktuelle Ausfuehrung
- verwendet, ungeachtet wie lange sie tatsaechlich dauert.
- = 0: ist die derzeite LIMIT_EVAL groesser als die vorherige
- LIMIT_EVAL, kostet die aktuelle Ausfuehrung nur 10
- Ticks; andernfalls werden die gesamten Kosten angerechnet.
- < 0: (-wert)% der aktuellen Ausfuehrungskosten werden
- angerechnet.
-
-
-BEMERKUNGEN
-===========
-
- "Aktuelle Kosten" bei LIMIT_COST hat im Falle der Benutzung von
- limited() die Bedeutung von "im limited verbrauchte Kosten", steuert
- also, wieviel der im Durchlaufen der Funktion im limited()
- verbrauchten Ticks mit dem Ende von limited() angezogen wird.
-
-
-BEISPIELE
-=========
-
- query_limits()
- --> liefert die momentan gueltigen Laufzeit Limiten.
- query_limits(1)
- --> liefert die standardmaessigen Laufzeit Limiten.
-
-
-AENDERUNGEN
-===========
-
- Eingefuehrt in LDMud 3.2.7.
- LIMIT_CALLOUTS wurde in LDMud 3.2.9 eingefuehrt.
-
-
-SIEHE AUCH
-==========
-
- limited(E), set_limits(E)
-
-16.05.2007, Zesstra
diff --git a/doc/sphinx/man/sefun/query_mud_port b/doc/sphinx/man/sefun/query_mud_port
deleted file mode 100644
index de4c1e2..0000000
--- a/doc/sphinx/man/sefun/query_mud_port
+++ /dev/null
@@ -1,39 +0,0 @@
-
-query_mud_port()
-****************
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- int query_mud_port(void)
- int query_mud_port(object user)
- int query_mud_port(int num)
-
-
-DESCRIPTION
-===========
-
- Returns the port number the parser uses for user connections.
-
- If no argument is given, the port for this_player() is
- returned. If this_player() is not existing or not interactive,
- the first port number open for connections is returned.
-
- If an user object is given, the port used for its connection
- is returned.
- If a positive number is given, the <num>th port number the
- parser uses for connections is returned (given that there are
- that many ports).
- If -1 is given, the number of ports open for connections is
- returned.
-
-
-SEE ALSO
-========
-
- query_udp_port(E)
diff --git a/doc/sphinx/man/sefun/query_next_reset b/doc/sphinx/man/sefun/query_next_reset
deleted file mode 100644
index 528ae56..0000000
--- a/doc/sphinx/man/sefun/query_next_reset
+++ /dev/null
@@ -1,47 +0,0 @@
-
-query_next_reset()
-******************
-
-simul_efun::query_next_reset(E)
-
-
-FUNKTION
-========
-
- varargs int query_next_reset(object ob)
-
-
-ARGUMENTE
-=========
-
- ob - das interessierende Objekt; wenn nicht angegeben, wird
- this_object() verwendet
-
-
-BESCHREIBUNG
-============
-
- Diese sefun gibt den Zeitpunkt des naechsten Resets des Objektes ob
- zurueck. Die Angabe erfolgt in Sekunden, die seit dem 01. Januar 1970
- 00:00:00 GMT verstrichen sind, analog zu time().
-
- In der Regel erfolgt der Reset im naechsten Backend-Zyklus nach dem
- Faelligkeitszeitpunkt, d.h. momentan in den nachfolgenden 2s.
- Allerdings kann dies auch mal nen Zyklus laenger dauern (4s), wenn der
- Driver viel zu tun hat.
-
-
-BEMERKUNGEN
-===========
-
- Diese sefun ist object_info()-Abfragen vorzuziehen, da die Parameter und
- Rueckgabewerte von object_info() bei verschiedenen Gamedriverversionen
- variieren koennen.
-
-
-SIEHE AUCH
-==========
-
- call_out(E), object_info(E), reset(L), set_next_reset(E), time(E)
-
-28.07.2014 Arathorn
diff --git a/doc/sphinx/man/sefun/query_once_interactive b/doc/sphinx/man/sefun/query_once_interactive
deleted file mode 100644
index bfb8b55..0000000
--- a/doc/sphinx/man/sefun/query_once_interactive
+++ /dev/null
@@ -1,21 +0,0 @@
-
-query_once_interactive()
-************************
-
-
-SYNOPSIS
-========
-
- int query_once_interactive(object obj);
-
-
-BESCHREIBUNG
-============
-
- Wahr, wenn <obj> interaktiv ist oder dies einmal war.
-
-
-SIEHE AUCH
-==========
-
- remove_interactive(E)
diff --git a/doc/sphinx/man/sefun/query_shadowing b/doc/sphinx/man/sefun/query_shadowing
deleted file mode 100644
index aadf109..0000000
--- a/doc/sphinx/man/sefun/query_shadowing
+++ /dev/null
@@ -1,38 +0,0 @@
-
-query_shadowing()
-*****************
-
-
-DEPRECATED
-==========
-
-query_shadowing(E)
-
-
-FUNKTION
-========
-
- object query_shadowing(object obj)
-
-
-BESCHREIBUNG
-============
-
- Die Funktion gibt das derzeit vom Objekt <obj> beschattete Objekt
- victim oder 0 zurueck.
-
-
-BEISPIELE
-=========
-
- // B beschattet A
- query_shadowing(find_object(B)) == A
-
-
-SIEHE AUCH
-==========
-
- Generell: shadow(E), unshadow(E)
- Rechte: query_allow_shadow(M), query_prevent_shadow(L)
-
-23.02.2016, Zesstra
diff --git a/doc/sphinx/man/sefun/query_snoop b/doc/sphinx/man/sefun/query_snoop
deleted file mode 100644
index 94e598a..0000000
--- a/doc/sphinx/man/sefun/query_snoop
+++ /dev/null
@@ -1,26 +0,0 @@
-
-query_snoop()
-*************
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- object query_snoop(object victim)
-
-
-DESCRIPTION
-===========
-
- Returns the user who currently snoops victim. The calling
- object must be privileged by the master object.
-
-
-SEE ALSO
-========
-
- snoop(E)
diff --git a/doc/sphinx/man/sefun/query_wiz_grp b/doc/sphinx/man/sefun/query_wiz_grp
deleted file mode 100644
index fe01fbd..0000000
--- a/doc/sphinx/man/sefun/query_wiz_grp
+++ /dev/null
@@ -1,34 +0,0 @@
-
-query_wiz_grp()
-***************
-
-
-FUNKTION
-========
-
- query_wiz_grp(string wiz)
- query_wiz_grp(object wiz)
-
-
-ARGUMENTE
-=========
-
- wiz - Spieler, dessen Magierlevelgruppe ermittelt werden soll
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion ermittelt die Magiergruppe, der der Spieler wiz angehoert.
-
-
-RUECKGABEWERT
-=============
-
- Die Magierlevelgruppe des Spielers.
-
-
-SIEHE AUCH
-==========
-
- /secure/wizlevels.h
diff --git a/doc/sphinx/man/sefun/query_wiz_level b/doc/sphinx/man/sefun/query_wiz_level
deleted file mode 100644
index 3645035..0000000
--- a/doc/sphinx/man/sefun/query_wiz_level
+++ /dev/null
@@ -1,70 +0,0 @@
-
-query_wiz_level()
-*****************
-
-
-FUNKTION
-========
-
- int query_wiz_level(object ob)
- int query_wiz_level(string ob)
-
-
-ARGUMENTE
-=========
-
- ob - Der Spieler/das Objekt, dessen Magierlevel ermittelt werden soll.
- Es kann auch eine UID (z.B. "zesstra", "d.inseln.zesstra") als String
- uebergeben werden.
-
-
-BESCHREIBUNG
-============
-
- query_wiz_level() liefert den Magierlevel des Objekts ob zurueck.
- Normale Spieler haben einen Magierlevel von 0, Seher normalerweise
- einen von 1 (auf jeden Fall < 10).
- Objekte bekommen folgende Level:
- /d/ - 25
- /p/ - 21
- /obj/ - 0
- /std/ - 0
- /gilden/ - 30
- /spellbooks/ - 30
- /players/ - entsprechend Magier, 20 - 111
- /secure/ - 100
-
-
-RUECKGABEWERT
-=============
-
- Der Magierlevel des Spielers/Objekts.
-
-
-BEMERKUNGEN
-===========
-
- Wird als Parameter ein String mit einem Spielernamen uebergeben, so
- kann auch der Magierlevel eines nicht eingeloggten Spielers heraus-
- gefunden werden.
-
-
-BEISPIELE
-=========
-
- lv = query_wiz_level(find_player("jof"))
- => lv = 111, falls Jof eingeloggt ist.
- lv = query_wiz_level("jof")
- => lv = 111 in jedem Fall.
-
-
-SIEHE AUCH
-==========
-
- /secure/wizlevels.h
-
-
-LETZTE AeNDERUNG
-================
-
-15.10.2007, Zesstra
diff --git a/doc/sphinx/man/sefun/read_data b/doc/sphinx/man/sefun/read_data
deleted file mode 100644
index 1756890..0000000
--- a/doc/sphinx/man/sefun/read_data
+++ /dev/null
@@ -1,34 +0,0 @@
-
-read_data()
-***********
-
-
-SYNOPSIS
-========
-
- string read_data(string file, int start, int anzahl)
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion macht genau das, was read_file() tut (also siehe dort),
- allerdings stellt sie sicher, dass <file> immer mit einem /data/
- beginnt (setzt es also notfalls davor).
- Es wird also immer irgendwo unterhalb von /data/ gelesen.
-
-
-BEISPIEL
-========
-
- # read_data("/d/ebene/zesstra/blupp");
- -> liest das File /data/d/ebene/zesstra/blupp.
- # read_data("/data/d/ebene/zesstra/blupp");
- -> tut dasselbe.
-
-
-SIEHE AUCH
-==========
-
- write_data()
- read_file(E), write_file(E), read_bytes(E), write_file(E)
diff --git a/doc/sphinx/man/sefun/replace_personal b/doc/sphinx/man/sefun/replace_personal
deleted file mode 100644
index 3804be3..0000000
--- a/doc/sphinx/man/sefun/replace_personal
+++ /dev/null
@@ -1,113 +0,0 @@
-
-replace_personal()
-******************
-
-
-FUNKTION
-========
-
- varargs string replace_personal(string str, mixed *obs [, int caps]);
-
-
-DEFINIERT IN
-============
-
- /secure/simul_efun.c
-
-
-ARGUMENTE
-=========
-
- str - zu bearbeitender String
- obs - Liste von Objekt1, Objekt2, ..., Objekt9
- (Objekte oder Strings)
- caps - 1 fuer Grossschreibung des Ersetzten nach Satzenden (.,?,!,")
- 0 sonst
-
-
-BESCHREIBUNG
-============
-
- Ersetzt in Strings
- @WERx, @WESSENx, @WEMx, @WENx durch
- Objectx->name(<casus>, 1);
- @WERUx, @WESSENUx, @WEMUx, @WENUx durch
- Objectx->name(<casus>);
- @WERQPx, @WESSENQPx, @WEMQPx, @WENQPx durch
- Objectx->QueryPronoun(<casus>);
- @WERQAx, @WESSENQAx, @WEMQAx, @WENQAx durch
- Objectx->QueryArticle(<casus>, 1, 1);
- @WERQPPGNx, @WESSENQPPGNx, @WEMQPPGNx, @WENQPPGNx durch
- Objectx->QueryPossPronoun(<gender>, <casus>, <number>);
- oder den entsprechenden String bei "Objektx".
-
-
-BEMERKUNGEN
-===========
-
- x steht fuer die Position des Objekts/Strings in *obs, beginnend bei 1.
-
-
-
- Besonderheiten beim Possessivpronomen (@WERQPPGNx):
- G muss durch das Geschlecht (M, F oder N) und N durch den Numerus (S
- oder P) ersetzt werden.
- Alle Angaben, auch der CASUS, beziehen sich dabei auf das Objekt, welches
- besessen wird, nicht auf den Besitzer! Dieser ist bereits durch x
- bestimmt.
-
-
-RUeCKGABEWERT
-=============
-
- durchersetzter String
-
-Beispiele
-
- replace_personal("@WER1", ({find_player("gloinson")})) ==
- "Gloinson"
-
- replace_personal("@WEMQP1", ({find_player("gloinson")})) == "ihm"
-
- // unbestimmter und bestimmter Artikel: replace_personal("@WER1
- zueckt @WENU2 und verhaut @WEN3.",
-
- ({find_player("gloinson"),
- find_object("/obj/mpa"), find_object("/obj/wanderer")}))
-
- == "Gloinson zueckt eine Zeitung und verhaut den Wanderer."
-
- // Beim Possessivpronomen beziehen sich WEN, F und P (Akkusativ, //
- Femininum, Plural) auf die Taschen, nicht auf Kessa:
- replace_personal("@WER1 steckt @WESSEN2 Turnschuhe in @WENQPPFP1 "
-
- "Taschen.", ({find_player("kessa"),
-
- find_player("gloinson")}))
-
- == "Kessa steckt Gloinsons Turnschuhe in ihre Taschen."
-
- // Ein Beispiel mit laengerem >>*<<obs: replace_personal("@WER1
- zieht @WENQPPMP1 neuen Turnschuhe an. @WER2 ist "
-
- "so beeindruckt, dass @WERQP2 @WEMQP1 @WENU3 auf die " "@WEN4
- haut und die Schuhe in @WEMQPPFS2 Tasche " "verschwinden laesst.
- @WERU5 schaut zu und kichert " "irre. Wenn das @WER6 gesehen
- haette!", ({find_player("gloinson"),
-
- find_player("kessa"), find_object("/obj/mpa"), "Birne",
- find_object("/obj/wanderer"), find_netdead("jof")}),1)
-
- == "Gloinson zieht seine neuen Turnschuhe an. Kessa ist so
- beeindruckt, "
- "dass sie ihm eine Zeitung auf die Birne haut und die Schuhe in
- ihrer " "Tasche verschwinden laesst. Ein Wanderer schaut zu und
- kichert " "irre. Wenn das Jof gesehen haette!"
-
-
-SIEHE AUCH
-==========
-
- AddCmd(L)
-
-5. September 2015, Arathorn
diff --git a/doc/sphinx/man/sefun/restore_object b/doc/sphinx/man/sefun/restore_object
deleted file mode 100644
index 631252d..0000000
--- a/doc/sphinx/man/sefun/restore_object
+++ /dev/null
@@ -1,31 +0,0 @@
-
-restore_object()
-****************
-
-
-SYNOPSIS
-========
-
- mixed restore_object(string name);
-
-
-BESCHREIBUNG
-============
-
- Diese Simul-Efun unterscheidet sich in einigen Details von der
- Driver-Efun restore_object() (s. auch dort! Wichtig!).
-
- 1. diese sefun restauriert auch die mit F_SAVE markierten Properties
- eines Objektes, sofern das Savefile von sefun save_object erstellt
- wurde (was die efun des Driver nicht tut!).
- 2. Sofern ein Pfad angegeben wird und dieser NICHT mit /data/ beginnt,
- wird das Savefile als erstes immer unter /data/+name gesucht. Erst wenn es
- dort nicht gefunden wird, wird unter name gesucht.
-
-
-SIEHE AUCH
-==========
-
- save_object(E), restore_object(E), save_value(E)
-
-29.01.2017, Zesstra
diff --git a/doc/sphinx/man/sefun/save_object b/doc/sphinx/man/sefun/save_object
deleted file mode 100644
index fc8175f..0000000
--- a/doc/sphinx/man/sefun/save_object
+++ /dev/null
@@ -1,35 +0,0 @@
-
-save_object()
-*************
-
-
-SYNOPSIS
-========
-
- mixed save_object(string name);
-
-
-BESCHREIBUNG
-============
-
- Diese Simul-Efun unterscheidet sich in einigen Details von der
- Driver-Efun save_object() (s. auch dort! Wichtig!).
- 1. diese sefun speichert auch die mit F_SAVE markierten Properties
- eines Objektes ab (was die efun des Driver nicht tut!).
- 2. Sofern ein Pfad angegeben wird und dieser NICHT mit /data/ beginnt,
- wird /data/ vorangestellt, d.h. das Savefile wird immer unter /data/
- erstellt.
- 3. das Format, in dem gespeichert wird, kann bei der sefun nicht
- ausgewaehlt werden (ist aber auch nicht noetig!), sondern ein
- mudlib-weiter Standard wird benutzt.
- 4. will man nicht in einem File speichern, sondern das, was im File
- stehen wurde, als String zurueckhaben, muss man 0 als 'name'
- uebergeben.
-
-
-SIEHE AUCH
-==========
-
- save_object(E), restore_object(E), save_value(E)
-
-29.01.2017, Zesstra
diff --git a/doc/sphinx/man/sefun/send_room b/doc/sphinx/man/sefun/send_room
deleted file mode 100644
index 7ddf43d..0000000
--- a/doc/sphinx/man/sefun/send_room
+++ /dev/null
@@ -1,42 +0,0 @@
-
-send_room()
-***********
-
-
-FUNKTION
-========
-
-varargs void send_room(object|string room, string msg, int msg_type,
- string msg_action, string msg_prefix, object >>*<<exclude, object
- origin)
-
-
-BESCHREIBUNG
-============
-
- Sendet msg an alle Objekte in room durch Aufruf von ReceiveMsg() mit
- den uebergebenen Argumenten.
- Zur Bedeutung der Argumente siehe Manpage von ReceiveMsg().
-
- Wenn das Raumobjekt mit seinem Namen angegeben ist, wird das Objekt
- unter diesem Namen gesucht und und geladen, falls notwendig.
-
- Mit dem Array <*exclude> kann man verhindern, dass die Nachricht an
- die darin enthaltenen Objekte gesendet wird.
- Das ist sinnvoll, wenn zB ein Spieler Ausloeser einer Meldung ist
- und diese selbst nicht erhalten soll.
-
- origin gibt an, welches Objekt die Meldung ausloest (muss nicht das
- sendende Objekt selber) und wird vor allem fuer die Ignorierepruefung
- verwendet. Default ist das sendende Objekt.
-
- Letztendlich ist die sefun vergleichbar zu tell_room().
-
-
-SIEHE AUCH
-==========
-
- ReceiveMsg(L)
- tell_object(E), tell_room(E), say(E), write(E)
-
-13.03.2016, Zesstra
diff --git a/doc/sphinx/man/sefun/set_heart_beat b/doc/sphinx/man/sefun/set_heart_beat
deleted file mode 100644
index a304181..0000000
--- a/doc/sphinx/man/sefun/set_heart_beat
+++ /dev/null
@@ -1,41 +0,0 @@
-
-set_heart_beat()
-****************
-
-
-SYNOPSIS
-========
-
- int set_heart_beat(int flag);
-
-
-BESCHREIBUNG
-============
-
- Schaltet den Heartbeat ein (1) oder aus (0). Der Treiber wendet die
- Lfun heart_beat() auf das aktuelle Objekt alle __HEARTBEAT_INTERVAL__
- Sekunden an, wenn der Heartbeat eingeschaltet ist. Ein Shadow
- auf der Lfun wird ignoriert.
-
-
-
- Der Heartbeat sollte immer ausgeschaltet werden, wenn er nicht
- gebraucht wird. Das reduziert die Systemauslastung.
-
- Liefert '1' bei Erfolg, '0' bei Fehler.
-
- Das Abschalten eines bereits abgeschalteten Heartbeats (und umgekehrt
- das Einschalten eines bereits eingeschalteten Heartbeats) zaehlt
- als Fehler.
-
-
-BEMERKUNGEN
-===========
-
- __HEARTBEAT_INTERVAL__ ist in MG = 2 Sekunden
-
-
-SIEHE AUCH
-==========
-
- heart_beat(A), call_out(E)
diff --git a/doc/sphinx/man/sefun/set_light b/doc/sphinx/man/sefun/set_light
deleted file mode 100644
index b9dfc9c..0000000
--- a/doc/sphinx/man/sefun/set_light
+++ /dev/null
@@ -1,32 +0,0 @@
-
-set_light()
-***********
-
-
-SYNOPSIS
-========
-
- int set_light(int n)
-
-
-DESCRIPTION
-===========
-
- An object is by default dark. It can be set to not dark by
- calling set_light(1). The environment will then also get this
- light. The returned value is the total number of lights in
- this room. So if you call set_light(0) it will return the
- light level of the current object.
-
-
-
- Note that the value of the argument is added to the light of
- the current object.
-
-
-BUGS
-====
-
- This handling of light by the parser is inappropriate for most
- purposes: If you put a burning candle into a safe, the safe
- will start to emit light.
diff --git a/doc/sphinx/man/sefun/set_living_name b/doc/sphinx/man/sefun/set_living_name
deleted file mode 100644
index e588e6e..0000000
--- a/doc/sphinx/man/sefun/set_living_name
+++ /dev/null
@@ -1,41 +0,0 @@
-
-set_living_name()
-*****************
-
-
-SYNOPSIS
-========
-
- void set_living_name(string name)
-
-
-BESCHREIBUNG
-============
-
- Setzt einen "Lebewesennamen" fuer das Objekt, indem Name und Objekt in
- eine Tabelle eingetragen werden, welche von find_living() durchsucht
- wird. Nach Setzen des Namens kann das Objekt per find_living()
- gefunden werden.
-
- Das Objekt muss ausserdem per enable_commands() als Lebewesen
- markiert worden sein. Dies ist fuer alle von /std/npc erbenden NPCs
- _automatisch_ der Fall und sollte daher nicht nochmal explizit gemacht
- werden.
-
- Alle von /std/npc erbenden NPCs setzen ebenfalls automatisch einen
- LivingName, der lower_case(P_NAME) entspricht.
-
- Ein Objekt kann nur einen Namen haben, mit dem es per find_living()
- gesucht werden kann.
-
-
-SIEHE AUCH
-==========
-
- find_living(E), find_livings(E), find_player(E), enable_commands(E)
-
-
-LETZTE AeNDERNG
-===============
-
-19.10.2015, Arathorn
diff --git a/doc/sphinx/man/sefun/set_object_heart_beat b/doc/sphinx/man/sefun/set_object_heart_beat
deleted file mode 100644
index caecca2..0000000
--- a/doc/sphinx/man/sefun/set_object_heart_beat
+++ /dev/null
@@ -1,34 +0,0 @@
-
-set_object_heart_beat()
-***********************
-
-
-FUNKTION
-========
-
- int set_object_heart_beat(object ob, int on)
-
-
-ARGUMENTE
-=========
-
- ob - Objekt, dessen heart_beat veraendert werden soll
- on - Soll der heart_beat ein- oder ausgeschaltet werden?
-
-
-BESCHREIBUNG
-============
-
- Der heart_beat des Objektes wird ein- (on=1) oder aus- (on=0) geschaltet.
-
-
-RUECKGABEWERT
-=============
-
- 1, wenn das Setzen geklappt hat, ansonsten 0.
-
-
-SIEHE AUCH
-==========
-
- set_heart_beat(E), heart_beat(L), call_out(E)
diff --git a/doc/sphinx/man/sefun/sha1 b/doc/sphinx/man/sefun/sha1
deleted file mode 100644
index ef3b10e..0000000
--- a/doc/sphinx/man/sefun/sha1
+++ /dev/null
@@ -1,44 +0,0 @@
-
-sha1()
-******
-
-
-DEPRECATED
-==========
-
-
-SYNOPSIS
-========
-
- string sha1 (string arg)
- string sha1 (int * arg)
-
-
-BESCHREIBUNG
-============
-
- Berechnet den SHA1-Hashwert von <arg>.
- Das Argument kann ein String, oder ein Array von Zahlen sein (von
- welchen nur das unterste Byte betrachted wird).
-
-
-BEISPIEL
-========
-
- string s;
-
- s = sha1("Hello");
- s = sha1( ({ 'H', 'e', 'l', 'l', 'o' })
-
-
-HISTORY
-=======
-
- Eingefuehrt in LDMud 3.3.523.
- LDMud 3.3.712 fuehrte Zaehlenarrays als Argument ein.
-
-
-SIEHE AUCH
-==========
-
- crypt(E), md5(E)
diff --git a/doc/sphinx/man/sefun/shadow b/doc/sphinx/man/sefun/shadow
deleted file mode 100644
index 2b7032c..0000000
--- a/doc/sphinx/man/sefun/shadow
+++ /dev/null
@@ -1,162 +0,0 @@
-
-shadow()
-********
-
-
-FUNKTION
-========
-
- object shadow(object ob, int flag)
-
-
-ARGUMENTE
-=========
-
- object ob - das vom shadow betroffene Objekt
- int flag - 0 fuer eine Shadow-Existenzabfrage
- 1 fuer Shadow durch previous_object()
-
-
-BESCHREIBUNG
-============
-
- Wenn <flag> nicht 0 ist, wird das aktuelle Objekt dem Objekt obj
- als Shadow uebergeworfen. Bei Erfolg wird das geshadowte Objekt
- zurueckgegeben, sonst 0.
- Wenn <flag> 0 ist, wird entweder 0 oder das geshadowte Objekt
- zurueck gegeben.
-
- Wenn ein Objekt A ein Objekt B beschattet, werden alle call_other() fuer
- B auf A umgeleitet. Wenn die an B gerufene Funktion in A existiert, so
- wird sie in A gerufen, bei Nichtexistenz in B.
- A ist das einzige Objekt, welche die beschatteten Funktionen mit
- call_other() in B aufrufen kann, selbst B kann nicht per call_other()
- diese Funktion rufen.
- Alle intern verwendeten Funktionen arbeiten jedoch weiterhin normal.
-
- Das aufrufende Objekt muss vom Master-Objekt die Erlaubnis haben,
- als Shadow zu wirken.
-
- Es gibt folgende Kriterien fuer eine erfolgreiche Beschattung:
- - das zu beschattende Objekt ob:
- - ist weder ein access_rights-Objekt noch ein ROOT-Objekt
- - gibt beim Aufruf von query_prevent_shadow(beschatter) eine 0
- zurueck
- - beschattet selbst niemanden
- - hat kein '#pragma no_shadow' gesetzt
- - der Beschatter:
- - wird nicht selbst (direkt) beschattet
- - beschattet noch niemanden (sonst folgt direkter Abbruch)
- - hat kein environment()
- - definiert/beschattet keine Methode, die im beschatteten Objekt ob
- als nomask definiert ist
-
- Beschattet man ein Objekt A mit einem Objekt B und dann das Objekt A
- zusaetzlich mit einem Objekt C, so wird eine Beschattungshierarchie
- erstellt:
-
- B macht shadow(A, 1)
- B->A
- C macht shadow(A, 1)
- C->B->A
-
-
-BEISPIELE
-=========
-
- // wenn: B beschattet A, dann
- shadow(find_object(A), 0) == B
-
-
- // 3 Objekte beschatten in Hierarchie (liegt auch im Pfad)
- --- aa.c ---
- void fun() {
- printf("%O [a] fun()\n", this_object());
- }
-
- void fun3() {
- printf("%O [a] fun3()\n", this_object());
- }
-
- --- bb.c ---
- int fun() {
- printf("%O [b] fun()\n", this_object());
- find_object("/doc/beispiele/shadow/aa")->fun();
- }
-
- void fun2() {
- printf("%O [b] fun2()\n", this_object());
- find_object("/doc/beispiele/shadow/aa")->fun3();
- this_object()->fun3();
- }
-
- void do_shadow(object target) { shadow(target, 1); }
-
- --- cc.c ---
- int fun() {
- printf("%O [c] fun()\n", this_object());
- find_object("/doc/beispiele/shadow/aa")->fun();
- }
-
- void fun3() {
- printf("%O [c] fun3()\n", this_object());
- }
-
- void do_shadow(object target) { shadow(target, 1); }
-
- // darauf arbeitender Code
-
- object a, b, c;
-
- destruct("/doc/beispiele/shadow/aa");
- a = load_object("/doc/beispiele/shadow/aa");
- destruct("/doc/beispiele/shadow/bb");
- b = load_object("/doc/beispiele/shadow/bb");
- destruct("/doc/beispiele/shadow/cc");
- c = load_object("/doc/beispiele/shadow/cc");
-
- b->do_shadow(a);
- c->do_shadow(a);
- printf("--- a->fun() ---\n");
- a->fun();
- printf("--- b->fun() ---\n");
- b->fun();
- printf("--- c->fun() ---\n");
- c->fun();
- printf("--- b->fun2() ---\n");
- b->fun2();
-
- // ... und seine Ausgabe:
-
- --- a->fun() ---
- /doc/beispiele/shadow/cc [c] fun()
- /doc/beispiele/shadow/bb [b] fun()
- /doc/beispiele/shadow/aa [a] fun()
- --- b->fun() ---
- /doc/beispiele/shadow/cc [c] fun()
- /doc/beispiele/shadow/bb [b] fun()
- /doc/beispiele/shadow/aa [a] fun()
- --- c->fun() ---
- /doc/beispiele/shadow/cc [c] fun()
- /doc/beispiele/shadow/bb [b] fun()
- /doc/beispiele/shadow/aa [a] fun()
- --- b->fun2() ---
- /doc/beispiele/shadow/bb [b] fun2()
- /doc/beispiele/shadow/aa [a] fun3()
- /doc/beispiele/shadow/cc [c] fun3()
-
- // Der erste Aufruf von b::fun2() in a findet sofort a::fun3()! Der
- // Driver nimmt an, dass alle Shadows ab c bei Rufen von b nach a
- // schon ihre Chance hatten.
- // Der zweite Aufruf allerdings ist auf b und wird beim Durchgeben
- // an a von c uebernommen.
-
-
-SIEHE AUCH
-==========
-
- Generell: shadow(E)
- Rechte: query_allow_shadow(M), query_prevent_shadow(L)
- Informationen: query_shadowing(E)
-
-8.Aug 2007 Gloinson
diff --git a/doc/sphinx/man/sefun/shout b/doc/sphinx/man/sefun/shout
deleted file mode 100644
index 0d38abb..0000000
--- a/doc/sphinx/man/sefun/shout
+++ /dev/null
@@ -1,93 +0,0 @@
-
-shout()
-*******
-
-
-FUNKTION
-========
-
- varargs void shout( string text, mixed where )
-
-
-DEFINIERT IN
-============
-
- /secure/simul_efun.c
-
-
-ARGUMENTE
-=========
-
- text
- Der Text, der ausgegeben werden soll
-
- where [optional]
- Wo soll man den Text ueberall hoeren koennen?
-
-
-BESCHREIBUNG
-============
-
- Der Text 'text' wird an alle Spieler in einem Gebiet ausgegeben.
- Wird der Parameter 'where' weggelassen bzw. ist er null, so geht der
- Text an alle Spieler im Mud. Das catch_tell() von NPCs wird nicht
- ausgeloest.
-
- Ist 'where' eine Zahl != 0, so wird der Text nur an Spieler ausgegeben,
- die sich im selben Gebiet aufhalten wie this_player(). Dabei wird die
- Zugehoerigkeit zum selben Gebiet an den ersten zwei Ebenen des Pfades
- der Raeume festgemacht. Befindet sich this_player() z.B. in
- "/d/ebene/irgendwo", so geht der Text an alle Spieler, deren Aufenthalts-
- orte in "/d/ebene/*" liegen.
-
- Fuer 'where' kann auch direkt ein Pfad angegeben werden. So wuerde ein
- 'shout( txt, "/players/" )' an alle Spieler gehen, die sich in
- (eigentlich nicht erwuenschten) Raeumen in /players/* befinden.
-
- Um mit einem Aufruf gleich mehrere Pfade abzudecken, kann auch ein Array
- von Strings uebergeben werden. Alle Pfade werden als 'regular expression'
- interpretiert. Dadurch ist es moeglich, die Zielraeume auf einfache Art
- sehr genau einzuschraenken.
-
- HINWEIS: Bitte ueberleg vor jedem shout() genau, ob es wirklich noetig
- ist, dass _jeder_ etwas davon mitbekommt oder ob es nicht vielleicht
- sinnvoller ist, das Zielgebiet etwas einzuschraenken. Im Zweifelsfall
- sollte der zustaendige RM aufpassen, dass die Spieler nicht durch allzu
- zahlreiche shouts belaestigt werden.
-
-
-RUeCKGABEWERT
-=============
-
- keiner
-
-
-BEISPIELE
-=========
-
- shout( "Du spuerst, wie ein Zittern durch das MorgenGrauen geht.\n" );
- Der allseits bekannte Text wird an alle Spieler im MG ausgegeben.
-
- shout( "Du hoerst eine gewaltige Explosion.\n", 1 );
- Von der Explosion bekommen alle Spieler in derselben Gegend etwas mit,
- aber nicht am anderen Ende des Muds.
-
- shout( "Irgendwo ist ein Baum umgefallen.\n", "/d/vland/" );
- ... gibt eine Meldung aus, die keinen wirklich interessiert. Aber es
- trifft eh nur Leute in einem unwichtigen Teil des MorgenGrauen. ;-)
-
- shout( "Aufwachen Du Idler!\n", "/players/.*/workroom" );
- Mit Hilfe von regular expressions kann man recht einfach z.B. alle
- Workrooms auf einmal adressieren.
-
- shout( "Halloooooo, Echoooooo!\n", ({ "/d/gebirge/", "/d/ebene/" }) );
- Wenn der Spieler hoch oben auf dem Berg laut genug ruft, hoert man
- ihn auch noch weit in der Ebene.
-
-
-SIEHE AUCH
-==========
-
- write(), say(), tell_object(), tell_room(), regexp()
-
-Last modified: Sun Nov 28 03:00:00 1999 by Tiamak
diff --git a/doc/sphinx/man/sefun/time2string b/doc/sphinx/man/sefun/time2string
deleted file mode 100644
index 4acd1a2..0000000
--- a/doc/sphinx/man/sefun/time2string
+++ /dev/null
@@ -1,75 +0,0 @@
-
-time2string()
-*************
-
-
-FUNKTION
-========
-
- string time2string( string format, int time )
-
-
-ARGUMENTE
-=========
-
- format: String, der das Format der Zeitausgabe festlegt.
- time: Eine Anzahl von Sekunden, die ausgegeben werden soll.
-
-
-ERGEBNIS
-========
-
- Zeit in String-Form.
-
-
-BESCHREIBUNG
-============
-
- Der Formatstring wird zurueckgegeben, wobei bestimmte Ersetzungs-
- symbole durch passende Daten, die aus der Zeit berechnet werden,
- ersetzt werden. Die Ersetzungssymbole funktionieren aehnlich
- denen aus 'printf' bekannten Symbolen. Insbesondere kann eine
- Feldbreite mit angegeben werden.
-
- Folgende Ersetzungssymbole sind erlaubt:
- %% wird durch ein Prozent (%) ersetzt.
- %n, %w, %d, %h, %m, %s
- werden durch die Anzahl der Monate, Wochen, Tage, Stunden, Minuten oder
- Sekunden ersetzt. Die Funktion erkennt, welches die groesste benutzte
- Zeiteinheit ist und rechnet die keineren so um, dass sie zwischen 0 und
- jeweiligen Maximum der Zeiteinheit liegen (59, 23 etc.) liegen.
- %N wird durch die Worte 'Woche' oder 'Wochen' ersetzt,
- je nachdem welchen Wertd %n haette.
- %W wird durch die Worte 'Woche' oder 'Wochen' ersetzt,
- je nachdem welchen Wert %w haette.
- %D wird durch die Worte 'Tag' oder 'Tage' ersetzt,
- je nachdem welchen Wert %d haette.
- %H,%M,%S
- werden durch die Worte 'Stunde(n)', 'Minute(n)' bzw. 'Sekunde(n)'
- ersetzt.
- %X wird durch die groesste Zeiteinheit ersetzt, die nicht Null ist. Wenn
- bei %X die Feldbreite 0 angegeben wird (also %0X), dann wird nicht der
- ausgeschriebene Name, sonder eine Abkuerzung fuer die Zeiteinheit
- ausgegeben. (Das sind dann 'd','h','m' oder 's'.)
- %x wird durch den numerischen Wert dieser Zeiteinheit
- ersetzt.
-
-
-BEISPIELE
-=========
-
- time2string( "%m %M", 60 ) -> "1 Minute"
- time2string( "%m %M", 120 ) -> "2 Minuten"
- time2string( "%s %S", 125 ) -> "125 Sekunden"
- time2string( "%m %M und %s %S" ) -> "2 Minuten und 5 Sekunden"
- time2string( "%d:%02h:%02m:%02s", 10000 ) -> "0:02:46:40"
- time2string( "%x %X", 3600 ) -> "1 Stunde"
- time2string( "%x %0X", 3600 ) -> "1 h"
- time2string( "%x %X", 360000 ) -> "4 Tage"
- time2string( "%x %0X", 360000 ) -> "4 d"
-
-
-SIEHE AUCH
-==========
-
- sprintf(E)
diff --git a/doc/sphinx/man/sefun/update_actions b/doc/sphinx/man/sefun/update_actions
deleted file mode 100644
index b25c07c..0000000
--- a/doc/sphinx/man/sefun/update_actions
+++ /dev/null
@@ -1,63 +0,0 @@
-
-update_actions()
-****************
-
-
-FUNKTION
-========
-
- void update_actions()
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Falls eine Aktion ein add_action() ausgeloest hat, werden mit dieser
- Funktion die neuen Befehle bei allen Lebewesen im aufrufenden Objekt
- bzw. in der Umgebung des aufrufenden Objektes aktiv.
-
-
-RUECKGABEWERT
-=============
-
- keiner
-
-
-BEMERKUNGEN
-===========
-
- Diese Funktion wird eigentlich nur benoetigt, wenn man mit add_action()
- anstelle von AddCmd() arbeitet (zB. bei Objekten, die nicht
- /std/thing/commands inheriten).
-
-
-BEISPIELE
-=========
-
- /* Normalerweise sollte man es SO gerade nicht machen. Stattdessen
- * sollte die "kletter"-Funktion pruefen, ob die Luke geoeffnet ist,
- * und sich im Fehlerfall beschweren.
- * So aber dient es als schoenes Beispiel fuer update_actions() ;)
- */
- int oeffne(string str)
- {
- if( str == "luke" ) {
- write( "Du oeffnest die Luke. Du kannst jetzt nach unten klettern.\n");
- add_action("kletter", "kletter", 1);
- update_actions();
- return 1;
- }
- return 0;
- }
-
-
-SIEHE AUCH
-==========
-
- add_action(E), AddCmd(L), RemoveCmd(L)
diff --git a/doc/sphinx/man/sefun/upperstring b/doc/sphinx/man/sefun/upperstring
deleted file mode 100644
index 416c90d..0000000
--- a/doc/sphinx/man/sefun/upperstring
+++ /dev/null
@@ -1,39 +0,0 @@
-
-upperstring()
-*************
-
-
-FUNKTION
-========
-
- string upperstring(string str)
-
-
-ARGUMENTE
-=========
-
- str - Der umzuwandelnde String.
-
-
-BESCHREIBUNG
-============
-
- Alle Kleinbuchstaben in str werden in Grossbuchstaben umgewandelt.
-
-
-RUECKGABEWERT
-=============
-
- Der umgewandelte String.
-
-
-BEISPIELE
-=========
-
- s = upperstring( "Na, Sterblicher!\n") => s = "NA, STERBLICHER!\n"
-
-
-SIEHE AUCH
-==========
-
- lowerstring(E), lower_case(E), capitalize(E)
diff --git a/doc/sphinx/man/sefun/uptime b/doc/sphinx/man/sefun/uptime
deleted file mode 100644
index 4c007a3..0000000
--- a/doc/sphinx/man/sefun/uptime
+++ /dev/null
@@ -1,37 +0,0 @@
-
-uptime()
-********
-
-
-FUNKTION
-========
-
- string uptime()
-
-
-ARGUMENTE
-=========
-
- keine
-
-
-BESCHREIBUNG
-============
-
- Liefert die aktuelle Uptime des MorgenGrauens.
-
-
-RUECKGABEWERT
-=============
-
- Die Uptime als Zeitstring.
-
-
-BEISPIELE
-=========
-
- ut = uptime() => ut = "14 Tage, 9 Stunden, 3 Minuten und 7 Sekunden."
-
-
-SIEHE AUCH
-==========
diff --git a/doc/sphinx/man/sefun/wizlist b/doc/sphinx/man/sefun/wizlist
deleted file mode 100644
index f81b9b8..0000000
--- a/doc/sphinx/man/sefun/wizlist
+++ /dev/null
@@ -1,84 +0,0 @@
-
-wizlist()
-*********
-
-
-SYNOPSIS
-========
-
- varargs void wizlist(string name, int sortkey )
-
-
-DESCRIPTION
-===========
-
- wizlist() liefert eine Liste mit verschiedenen Verbrauchsdaten
- zu Magiern. Es werden dabei normalerweise 21 Eintraege ausgegeben:
- 10 vor <name>, <name> selbst und 10 nach <name>.
-
- Die Liste ist dabei folgendermassen aufgebaut:
-
- 1. WL_NAME
- Gesammelt werden die Daten pro UID. Hierbei zaehlt aber jede EUID, nicht
- nur die von Magiern.
- Das heisst, Objekte unter /d/polar/vanion/eispalast
- werden nicht unter "vanion" sondern unter "d.polar.vanion"
- abgerechnet.
-
- 2. WL_COMMANDS
- Anzahl der diesem Objekt zugeordneten commands.
-
- 3. WL_COMMANDS * 100 / total_cmd
- Prozentualer Anteil an den gesamt verbrauchten commands.
-
- 4. WL_COST (links in der eckigen Klammer)
- Anzahl der verbrauchten eval ticks. Dies ist zeitlich gewichtet, d.h.
- nimmt im Lauf der Zeit ab, wenn nichts mehr dazu kommt.
-
- 5. WL_TOTAL_GIGACOST (rechts in der eckigen Klammer)
- Anzahl der insgesamt verbrauchten eval ticks in Giga-Ticks.
- Nicht zeitlich gewichtet.
-
- 6. WL_HEART_BEATS
- Anzahl der ausgeloesten heart beats.
-
-
-
- 7. WL_ARRAY_TOTAL
-
- 8. WL_MAPPING_TOTAL
-
-PARAMETERS:
- Wird name angegeben, wird erzwungen, dass die erwaehnte EUID mit in
- der Liste dargestellt wird. Wird name nicht angegeben, wird es
- automatisch auf this_player()->query_real_name() gesetzt.
-
- Wird als name "TOP100" angegeben, wird die Top-100-Liste
- ausgegeben.
-
- Wird als name "ALL" angegeben, wird die vollstaendige Liste aus-
- gegeben.
-
- Durch Angabe von sortkey kann die Liste nach einer der Spalten
- sortiert werden. Gueltige Werte sind die in /sys/wizlist.h ange-
- gebenen Defines.
-
-EXAMPLE
- > xeval wizlist("vanion", WL_HEART_BEATS)
- Erzwingt Vanions Eintrag in der Liste und sortiert die Liste
- anhand der durch die EUIDs ausgefuehrten heart beats.
-
- > xeval wizlist("ALL", WL_EVAL_COST)
- Zeigt die komplette Liste nach eval ticks-Verbauch sortiert an.
-
-
-SEE ALSO
-========
-
- wizlist_info(E)
-
-
-LAST UPDATED
-============
-
- 09.05.2015, Zesstra
diff --git a/doc/sphinx/man/sefun/wizlist_info b/doc/sphinx/man/sefun/wizlist_info
deleted file mode 100644
index 0c86434..0000000
--- a/doc/sphinx/man/sefun/wizlist_info
+++ /dev/null
@@ -1,58 +0,0 @@
-
-wizlist_info()
-**************
-
-
-GESCHUETZT
-==========
-
-
-SYNOPSIS
-========
-
- #include <sys/wizlist.h>
-
- *mixed wizlist_info();
-
-
-BESCHREIBUNG
-============
-
- Liefert ein Array mit Eintraegen aus der Wizlist (der internen
- Magierliste). Die Benutzung muss durch das Masterobjekt erlaubt
- werden.
-
- Das Resultat ist ein Array mit einem Eintrag fuer jeden Magier (uid).
- Jeder Eintrag enthaelt wiederum ein Array mit folgenden Elementen:
-
- string w[WL_NAME] Name des Magiers
- int w[WL_COMMANDS] Gewichtete Anzahl Kommandi, die von
- Objekten dieses Gottes ausgefuehrt
- wurden
- int w[WL_COSTE] Gewichtete Summe der Eval-Kosten
- int w[WL_GIGACOST] Gewichtete Summe der Eval-Kosten
- int W[WL_TOTAL_COST] Totale Summe der Eval-Kosten
- int w[WL_TOTAL_GIGACOST] Totale Summe der Eval-Kosten
- int w[WL_HEART_BEAT] Gewichtete Anzahl der heat_beat()s
- int w[WL_CALL_OUT] Reserviert fuer call_out()s
- (bisher nicht implementiert)
- int w[WL_ARRAY_TOTAL] Totale Groesse aller Arrays in
- Elementen
- mixed w[WL_EXTRA] Die eigentliche Wizlist-Info
-
- Die "gewichteten" Werte verfallen pro Stunde um 10%.
-
-
-AENDERUNGEN
-===========
-
- LDMud 3.2.10 trennte das alte WL_EVAL_COST in WL_COST und WL_GIGACOST,
- um laengeren Uptimes gerecht zu werden. Ausserdem wurde
- WL_TOTAL_COST und WL_TOTAL_GIGACOST eingefuehrt.
-
-
-SIEHE AUCH
-==========
-
- privilege_violation(M), set_extra_wizinfo_size(E),
- get_extra_wizinfo(E), set_extra_wizinfo(E)
diff --git a/doc/sphinx/man/sefun/write_data b/doc/sphinx/man/sefun/write_data
deleted file mode 100644
index b8f0d4f..0000000
--- a/doc/sphinx/man/sefun/write_data
+++ /dev/null
@@ -1,39 +0,0 @@
-
-write_data()
-************
-
-
-SYNOPSIS
-========
-
- string write_data(string file, int start, int anzahl)
-
-
-BESCHREIBUNG
-============
-
- Diese Funktion macht genau das, was write_file() tut (also siehe dort),
- allerdings stellt sie sicher, dass <file> immer mit einem /data/
- beginnt (setzt es also notfalls davor).
- Es wird also immer irgendwo unterhalb von /data/ geschrieben.
-
- Die Benutzung dieser sefun wird dringend empfohlen, falls Daten
- ausserhalb von Spielerobjekten gepeichert werden, damit Daten und
- Code getrennt abgelegt sind. Dies vereinfacht z.B. die
- Datensicherung.
-
-
-BEISPIEL
-========
-
- # write_file("/d/ebene/zesstra/blupp", "Testdaten.\n");
- -> schreibt in das File /data/d/ebene/zesstra/blupp.
- # write_file("/data/d/ebene/zesstra/blupp", "Testdaten.\n");
- -> tut dasselbe.
-
-
-SIEHE AUCH
-==========
-
- read_data()
- read_file(E), write_file(E), read_bytes(E), write_file(E)